Re: [digitalradio] Re: SDR-1000
If you had .deb for the Debian based and .rpm for the Red Hat based, wouldn't that take care of most of them? Ideally, there should be a radio amateur area in the universe for the Debian's at least. I am not sure how it is maintained as it seems almost magical compared to hunting around for MS OS programs. In many cases you just type a command and the name of the program you want and it just comes to you if you have internet access. Maybe different hams could volunteer to insure that the repository has the correct versions? We should not forget that Bruce Perens, who has been a key player in the digital world of free software, project leader of Debian, Linux Standard Base, and many other organizations is also K6BP. He also founded No Code International and I am sure he saw large numbers of highly technical people who might have gotten into ham radio, but who would not because of the code. Whether these people get involved now remains to be seen, and I have often wondered how many we have lost. This doesn't affect the majority of hams who only do CW and voice, but for our digital hams, it may have made a difference. It only takes ONE person to make an enormous difference when it comes to that one program that we need. One person can make (and they have made) a sea change in the digital world. Some are on this group. 73, Rick, KV9U Walt DuBose wrote: But that still doesn't preclude amateur radio operators from have a place to store compiled applications for their distro. There would of course have to be as many major directories as Linux distros and sub directoried for the various releases of the distro. if the amateur radio application needed recompiled for the various releases. But then again, who would provide the repository? I would hope that someday the ARRL would do this...but perhaps that's too much of a dream. Walt/K5YFW Leigh L Klotz, Jr. wrote: This is just what package managers do. There are two main package managers: Debainls deb format and Red Hat's RPM. Debian historically did a better job on resolving dependencies at installation time (as opppsed to just reporting them), but part of that ability was due to Debian have a good repository infrastructure into which packages are placed and with which the dependencies can be satisfied. It isn't really true that Debian has one repository, but they do have one structure, and the divisions in them are multi-year long releases, the status (stable, testing, etc.), and the license status (essentially fully GPL or not). I am not a Debian expert so I may be shakey in this area. But the point is you install and make choices, and can satisfy dependencies through an integrated system. In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there was no repository structure integrated into RPM, no root repository, and no way even for multiple repositories to be integrated. Part of the reason the fragmentation was that Red Hat monetized the updates so making it work without their for-pay service wasn't in their interest. So with zred Hat you bought or downloaded their release ISO images and updated wholesale. When the pace of security fixes began to require something better, RedHat introduced a for-pay update service, limited to RedHat. It put the dependency calculation on their servers, just to make sure you paid for it. SuSE was no better in their pre-Novell days. They had no downloadable ISO images at all, and copyrighted their installer, so it was effectively impossible to get SuSE without paying for it. They did offer their individual RPM files for download, but mnoetized the installer. After Novell acquired them, that block went away. But there is still a separate set of RPMs for SuSE. A couple of other companies tried to get into the updater business, and they made variant versions of systems such as Gnome (or, the main version and everyone else was variant, dependong on whom you ask). Unfortunately, once you hopped on that train, you could never get off as there were version conflicts deep down, and the whole thing faltered. Aound the time Fedora split off, the Yum system came about (it grew out of a port of Red Hat to the PowerPC Mac which of necessity needed its own universe), and it allowed integration on the client of multiple repository sources. Yum offered the ability to install and update from the repositories listed. Fedora recently managed to consolidate an external package repository, and they seem to be trying to grapple with this problem, but with Yum they at least have a way ot combining them at the client. Unfortunately, since there is no authoritative source for the RPM packaged version of some library (cross-indexed with a release and status as with Debian), there is no single set of compile-time options in use. As en example, until recently, Fedora users couldn't install W1HKJ's fldigi with the default fltk RPM file on which it
Re: [digitalradio] Re: SDR-1000
Maybe this is a dumb question, but once someone compiles a program for Linux and includes the dependencies, wouldn't this be easily shared between users? Can't they then put this in their depository for that particular Linux distribution? Even if you don't have it in your particular universe can't you use a program from the multiverse. Even converting it from one of the package managers to another package manager that fits your Linux distribution? 73, Rick, KV9U Walt DuBose wrote: Thanks for the encouragement Frank. For over 2 years now Gerald had been telling me that Oh yes the SDR-1000 was going to be supported by Linux. As I told Dave, W1HJK, in a private E-Mail and I was going to address Andy's and Roger Rehr's comment. For those of us who eun Linux either just because its different or have been using it for years or hate MS or a hundred other reasons, I think that it would be nice to make amateru radio applications as simple to run under Linux as most MS amateur radio applications are under MS. skip down seven paragraphs to leave out my history But let me tell you where I'm coming from... I have been doind tactical HF communications for over 30 years, the last 8 on my own supporting the local office of emergency management and a disaster relief organization. Before that I was doing tactical HF communications for the Air Force and spend a tour in Saudi during Desert Shiled and Storm as chief of communications for the aeromedical evecuation effort. They had through that time only used HF and has just started using data mixed with voice a couple of years before Desert Shield started in August of 1990. I had worked in my civilian job with the Air Force as an IT procurement analyst and ran the a huge E-Mail system using 10 ATT 3B2 computers and then the first Air Force electronic commerce web site. A friend and one of my technical support persons suggested that I load Linux on a 386 PC and run multiple desktops rather than have 10 monitors on my desk. That was August of 1991. From the 3B2s we went to web servers using medium size Sun servers and Linux workstations. I never was anything but a Linux user and never got much into configuring Linux, etc. When I left that job in 1999, I went to another base that ran MS clients and servers. I have now over 150 MS clients and 6 MS servers to baby sit. I have had to load NT on all of our clients and servers, then W2K and last time XP on the clients. The servers still run W2K server. I can truthfully say that loading MS is a breeze...but having to load Linux on 10 different personal computers with the last two, one being Mandrake and one (the last one) being SuSe 9.?, I find that loading them NO problem but runing amateur radio applications a real pain when compaired to MS applications. End my history I believe that this is why so many hams have an objection to Linux. I find myself coming home and wanting to operate HF data modes and not having to fool around for days trying to get an applications to work or load various libraries, etc. So without pointing any fingers at the amateur radio community...since this IS for most of us a hobby or perhaps a love affair, it would be nice to have Linux applications that are easy to load and run withour compiling and go out and find various different dependencies. I think the latest and very fine example of the sort of amateur radio applications I have loaded is Fldigi by Dave, W1HKJ. Now my Mandarake distro is so old I need to update one library but that's not really a problem or a fault of the applications. And peaking of fine amateur radio things, the theory and construction of the SDR-1000 is super. For the amateur radio operator I believe that it is and will be a leader in the change from the typical radios we have available no to amateur radio operators to SDR radios. Perhaps even a more important step than the Central Electronics 10A/B and 20A/B transmitter and the Drake 2B receiver and Gonset GSB-100 transmitter. I believe that we will see building block SDR radios. Perhaps a case with a number of card slots and you plug in SDR component block cards and build you custom SDR radio. I also look for the same sort of approach for PSK and other data mode radios that are small and portable and replace the current number of QRP rigs. Further, I can see building custom high power amplifiers around various amplfier modules. All these thing will not only bring amateur radio back int the lime light in communications services but also spur iondividuals to get back into the rig building mode and since many of you have such great talent in programming that you can help us by building modular applications and show is the code and explain to us how it works so we can modify it such as Skip Teller did with PSK63 and whomever created PSK125 and like Merray and group did with MFSK-16 and all the other new modes. We need to be able
Re: [digitalradio] Re: SDR-1000
This is just what package managers do. There are two main package managers: Debainls deb format and Red Hat's RPM. Debian historically did a better job on resolving dependencies at installation time (as opppsed to just reporting them), but part of that ability was due to Debian have a good repository infrastructure into which packages are placed and with which the dependencies can be satisfied. It isn't really true that Debian has one repository, but they do have one structure, and the divisions in them are multi-year long releases, the status (stable, testing, etc.), and the license status (essentially fully GPL or not). I am not a Debian expert so I may be shakey in this area. But the point is you install and make choices, and can satisfy dependencies through an integrated system. In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there was no repository structure integrated into RPM, no root repository, and no way even for multiple repositories to be integrated. Part of the reason the fragmentation was that Red Hat monetized the updates so making it work without their for-pay service wasn't in their interest. So with zred Hat you bought or downloaded their release ISO images and updated wholesale. When the pace of security fixes began to require something better, RedHat introduced a for-pay update service, limited to RedHat. It put the dependency calculation on their servers, just to make sure you paid for it. SuSE was no better in their pre-Novell days. They had no downloadable ISO images at all, and copyrighted their installer, so it was effectively impossible to get SuSE without paying for it. They did offer their individual RPM files for download, but mnoetized the installer. After Novell acquired them, that block went away. But there is still a separate set of RPMs for SuSE. A couple of other companies tried to get into the updater business, and they made variant versions of systems such as Gnome (or, the main version and everyone else was variant, dependong on whom you ask). Unfortunately, once you hopped on that train, you could never get off as there were version conflicts deep down, and the whole thing faltered. Aound the time Fedora split off, the Yum system came about (it grew out of a port of Red Hat to the PowerPC Mac which of necessity needed its own universe), and it allowed integration on the client of multiple repository sources. Yum offered the ability to install and update from the repositories listed. Fedora recently managed to consolidate an external package repository, and they seem to be trying to grapple with this problem, but with Yum they at least have a way ot combining them at the client. Unfortunately, since there is no authoritative source for the RPM packaged version of some library (cross-indexed with a release and status as with Debian), there is no single set of compile-time options in use. As en example, until recently, Fedora users couldn't install W1HKJ's fldigi with the default fltk RPM file on which it depends because Dave's coded needed the --with-threads option required in fltk at compile time. The job of a Linux distribution is to pick in time a set of package versions and instances of them compiled with flags, and make sure (QA) that they work together. RedHat paid people to do this. Debian threw together a tree of latest and encourged people to file fix dependency problems. Neither model scaled well. Recently, the Debian and Red Hat worlds got closer, as Debian has downstream providers such as Ubuntu, who pay people to do more testing, integration, and tuning, and more like SuSE with lots of attention to the installer. RedHat/Fedora became more like Debian by relying more on a dedicated (but increasingly disenchanted) community to do testing of frequent releases. So, the upshot of all this is that both Debian's format and the RPM/Yum system do a good job of capturing dependencies and providing an environment to resolve them in, but neither can work without people compiling nd cross-testing the packages that they put into their respective repositories. With Debian, the path upstream is a little clearer so it is a little easiser to figure out where to put things, but the download this from a website and install the package option is much harder (partially because they don't want you to do that -- put it in the repository instead). All this being said, there is something called alien which will convert from .deb to .rpm format, but that doesn't at all take into account that the packages and packagings and patches in the two systems (deb's in a system, rpm's is a federation) don't align. 73, Leigh/WA5ZNU On Sun, 4 Feb 2007 6:28 am, KV9U wrote: Maybe this is a dumb question, but once someone compiles a program for Linux and includes the dependencies, wouldn't this be easily shared between users? Can't they then put this in their depository for that
Re: [digitalradio] Re: SDR-1000
Maybe this is a dumb question, but once someone compiles a program for Linux and includes the dependencies, wouldn't this be easily shared between users? Can't they then put this in their depository for that particular Linux distribution? Even if you don't have it in your particular universe can't you use a program from the multiverse. Even converting it from one of the package managers to another package manager that fits your Linux distribution? 73, Rick, KV9U Unfortunately different distros store different files in different places. Sigh. Some distros are better about redirecting apps compiles for one distro to the locations they need to be in for the new distro. The Puppy Linux folks have been working hard on an app that does this then puts the app inside an installation wrapper (PupGet or DotPup) which the user just clicks to perform the entire install. Not sure how other distros are handling this. -- Thanks! 73, doc, KD4E ~~ Projects: http://ham-macguyver.bibleseven.com Personal: http://bibleseven.com ~~
Re: [digitalradio] Re: SDR-1000
Very interesting and informative information, Leigh. I did not realize how proprietary things were in the earlier times. The merging of the ODSL (Open Source Development Labs) and the FSG (Free Standards Group) into the Linux Foundation and the attempt to try and bring increased standardization, may help. I wish that Novell was a Debian based distribution though. Then put in the mix the new Microsoft/Novell interoperability lab strategy. Considering the statements Bob Muglia made last summer about how tight they plan to build virtualization with Xen to support Linux in a very native and high performance way, it could impact the end users in a very positive way. But I am not sure if this will be anything for the desktop, since it seems geared mostly for the server. 73, Rick, KV9U Leigh L Klotz, Jr. wrote: This is just what package managers do. There are two main package managers: Debainls deb format and Red Hat's RPM. Debian historically did a better job on resolving dependencies at installation time (as opppsed to just reporting them), but part of that ability was due to Debian have a good repository infrastructure into which packages are placed and with which the dependencies can be satisfied. It isn't really true that Debian has one repository, but they do have one structure, and the divisions in them are multi-year long releases, the status (stable, testing, etc.), and the license status (essentially fully GPL or not). I am not a Debian expert so I may be shakey in this area. But the point is you install and make choices, and can satisfy dependencies through an integrated system. In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there was no repository structure integrated into RPM, no root repository, and no way even for multiple repositories to be integrated. Part of the reason the fragmentation was that Red Hat monetized the updates so making it work without their for-pay service wasn't in their interest. So with zred Hat you bought or downloaded their release ISO images and updated wholesale. When the pace of security fixes began to require something better, RedHat introduced a for-pay update service, limited to RedHat. It put the dependency calculation on their servers, just to make sure you paid for it. SuSE was no better in their pre-Novell days. They had no downloadable ISO images at all, and copyrighted their installer, so it was effectively impossible to get SuSE without paying for it. They did offer their individual RPM files for download, but mnoetized the installer. After Novell acquired them, that block went away. But there is still a separate set of RPMs for SuSE. A couple of other companies tried to get into the updater business, and they made variant versions of systems such as Gnome (or, the main version and everyone else was variant, dependong on whom you ask). Unfortunately, once you hopped on that train, you could never get off as there were version conflicts deep down, and the whole thing faltered. Aound the time Fedora split off, the Yum system came about (it grew out of a port of Red Hat to the PowerPC Mac which of necessity needed its own universe), and it allowed integration on the client of multiple repository sources. Yum offered the ability to install and update from the repositories listed. Fedora recently managed to consolidate an external package repository, and they seem to be trying to grapple with this problem, but with Yum they at least have a way ot combining them at the client. Unfortunately, since there is no authoritative source for the RPM packaged version of some library (cross-indexed with a release and status as with Debian), there is no single set of compile-time options in use. As en example, until recently, Fedora users couldn't install W1HKJ's fldigi with the default fltk RPM file on which it depends because Dave's coded needed the --with-threads option required in fltk at compile time. The job of a Linux distribution is to pick in time a set of package versions and instances of them compiled with flags, and make sure (QA) that they work together. RedHat paid people to do this. Debian threw together a tree of latest and encourged people to file fix dependency problems. Neither model scaled well. Recently, the Debian and Red Hat worlds got closer, as Debian has downstream providers such as Ubuntu, who pay people to do more testing, integration, and tuning, and more like SuSE with lots of attention to the installer. RedHat/Fedora became more like Debian by relying more on a dedicated (but increasingly disenchanted) community to do testing of frequent releases. So, the upshot of all this is that both Debian's format and the RPM/Yum system do a good job of capturing dependencies and providing an environment to resolve them in, but neither can work without people compiling nd cross-testing the packages that they put into their respective
Re: [digitalradio] Re: SDR-1000
I guess that has kinda been my thught also. Walt/K5YFW KV9U wrote: Maybe this is a dumb question, but once someone compiles a program for Linux and includes the dependencies, wouldn't this be easily shared between users? Can't they then put this in their depository for that particular Linux distribution? Even if you don't have it in your particular universe can't you use a program from the multiverse. Even converting it from one of the package managers to another package manager that fits your Linux distribution? 73, Rick, KV9U Walt DuBose wrote: Thanks for the encouragement Frank. For over 2 years now Gerald had been telling me that Oh yes the SDR-1000 was going to be supported by Linux. As I told Dave, W1HJK, in a private E-Mail and I was going to address Andy's and Roger Rehr's comment. For those of us who eun Linux either just because its different or have been using it for years or hate MS or a hundred other reasons, I think that it would be nice to make amateru radio applications as simple to run under Linux as most MS amateur radio applications are under MS. skip down seven paragraphs to leave out my history But let me tell you where I'm coming from... I have been doind tactical HF communications for over 30 years, the last 8 on my own supporting the local office of emergency management and a disaster relief organization. Before that I was doing tactical HF communications for the Air Force and spend a tour in Saudi during Desert Shiled and Storm as chief of communications for the aeromedical evecuation effort. They had through that time only used HF and has just started using data mixed with voice a couple of years before Desert Shield started in August of 1990. I had worked in my civilian job with the Air Force as an IT procurement analyst and ran the a huge E-Mail system using 10 ATT 3B2 computers and then the first Air Force electronic commerce web site. A friend and one of my technical support persons suggested that I load Linux on a 386 PC and run multiple desktops rather than have 10 monitors on my desk. That was August of 1991. From the 3B2s we went to web servers using medium size Sun servers and Linux workstations. I never was anything but a Linux user and never got much into configuring Linux, etc. When I left that job in 1999, I went to another base that ran MS clients and servers. I have now over 150 MS clients and 6 MS servers to baby sit. I have had to load NT on all of our clients and servers, then W2K and last time XP on the clients. The servers still run W2K server. I can truthfully say that loading MS is a breeze...but having to load Linux on 10 different personal computers with the last two, one being Mandrake and one (the last one) being SuSe 9.?, I find that loading them NO problem but runing amateur radio applications a real pain when compaired to MS applications. End my history I believe that this is why so many hams have an objection to Linux. I find myself coming home and wanting to operate HF data modes and not having to fool around for days trying to get an applications to work or load various libraries, etc. So without pointing any fingers at the amateur radio community...since this IS for most of us a hobby or perhaps a love affair, it would be nice to have Linux applications that are easy to load and run withour compiling and go out and find various different dependencies. I think the latest and very fine example of the sort of amateur radio applications I have loaded is Fldigi by Dave, W1HKJ. Now my Mandarake distro is so old I need to update one library but that's not really a problem or a fault of the applications. And peaking of fine amateur radio things, the theory and construction of the SDR-1000 is super. For the amateur radio operator I believe that it is and will be a leader in the change from the typical radios we have available no to amateur radio operators to SDR radios. Perhaps even a more important step than the Central Electronics 10A/B and 20A/B transmitter and the Drake 2B receiver and Gonset GSB-100 transmitter. I believe that we will see building block SDR radios. Perhaps a case with a number of card slots and you plug in SDR component block cards and build you custom SDR radio. I also look for the same sort of approach for PSK and other data mode radios that are small and portable and replace the current number of QRP rigs. Further, I can see building custom high power amplifiers around various amplfier modules. All these thing will not only bring amateur radio back int the lime light in communications services but also spur iondividuals to get back into the rig building mode and since many of you have such great talent in programming that you can help us by building modular applications and show is the code and explain to us how it works so we can modify it such as Skip Teller did with PSK63 and whomever created PSK125
Re: [digitalradio] Re: SDR-1000
But that still doesn't preclude amateur radio operators from have a place to store compiled applications for their distro. There would of course have to be as many major directories as Linux distros and sub directoried for the various releases of the distro. if the amateur radio application needed recompiled for the various releases. But then again, who would provide the repository? I would hope that someday the ARRL would do this...but perhaps that's too much of a dream. Walt/K5YFW Leigh L Klotz, Jr. wrote: This is just what package managers do. There are two main package managers: Debainls deb format and Red Hat's RPM. Debian historically did a better job on resolving dependencies at installation time (as opppsed to just reporting them), but part of that ability was due to Debian have a good repository infrastructure into which packages are placed and with which the dependencies can be satisfied. It isn't really true that Debian has one repository, but they do have one structure, and the divisions in them are multi-year long releases, the status (stable, testing, etc.), and the license status (essentially fully GPL or not). I am not a Debian expert so I may be shakey in this area. But the point is you install and make choices, and can satisfy dependencies through an integrated system. In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there was no repository structure integrated into RPM, no root repository, and no way even for multiple repositories to be integrated. Part of the reason the fragmentation was that Red Hat monetized the updates so making it work without their for-pay service wasn't in their interest. So with zred Hat you bought or downloaded their release ISO images and updated wholesale. When the pace of security fixes began to require something better, RedHat introduced a for-pay update service, limited to RedHat. It put the dependency calculation on their servers, just to make sure you paid for it. SuSE was no better in their pre-Novell days. They had no downloadable ISO images at all, and copyrighted their installer, so it was effectively impossible to get SuSE without paying for it. They did offer their individual RPM files for download, but mnoetized the installer. After Novell acquired them, that block went away. But there is still a separate set of RPMs for SuSE. A couple of other companies tried to get into the updater business, and they made variant versions of systems such as Gnome (or, the main version and everyone else was variant, dependong on whom you ask). Unfortunately, once you hopped on that train, you could never get off as there were version conflicts deep down, and the whole thing faltered. Aound the time Fedora split off, the Yum system came about (it grew out of a port of Red Hat to the PowerPC Mac which of necessity needed its own universe), and it allowed integration on the client of multiple repository sources. Yum offered the ability to install and update from the repositories listed. Fedora recently managed to consolidate an external package repository, and they seem to be trying to grapple with this problem, but with Yum they at least have a way ot combining them at the client. Unfortunately, since there is no authoritative source for the RPM packaged version of some library (cross-indexed with a release and status as with Debian), there is no single set of compile-time options in use. As en example, until recently, Fedora users couldn't install W1HKJ's fldigi with the default fltk RPM file on which it depends because Dave's coded needed the --with-threads option required in fltk at compile time. The job of a Linux distribution is to pick in time a set of package versions and instances of them compiled with flags, and make sure (QA) that they work together. RedHat paid people to do this. Debian threw together a tree of latest and encourged people to file fix dependency problems. Neither model scaled well. Recently, the Debian and Red Hat worlds got closer, as Debian has downstream providers such as Ubuntu, who pay people to do more testing, integration, and tuning, and more like SuSE with lots of attention to the installer. RedHat/Fedora became more like Debian by relying more on a dedicated (but increasingly disenchanted) community to do testing of frequent releases. So, the upshot of all this is that both Debian's format and the RPM/Yum system do a good job of capturing dependencies and providing an environment to resolve them in, but neither can work without people compiling nd cross-testing the packages that they put into their respective repositories. With Debian, the path upstream is a little clearer so it is a little easiser to figure out where to put things, but the download this from a website and install the package option is much harder (partially because they
Re: [digitalradio] Re: SDR-1000
That would be a good reason to install Puppy but as I understand it, Puppy is limited in that most don't consider it a full distribution. Walt/K5YFW kd4e wrote: Maybe this is a dumb question, but once someone compiles a program for Linux and includes the dependencies, wouldn't this be easily shared between users? Can't they then put this in their depository for that particular Linux distribution? Even if you don't have it in your particular universe can't you use a program from the multiverse. Even converting it from one of the package managers to another package manager that fits your Linux distribution? 73, Rick, KV9U Unfortunately different distros store different files in different places. Sigh. Some distros are better about redirecting apps compiles for one distro to the locations they need to be in for the new distro. The Puppy Linux folks have been working hard on an app that does this then puts the app inside an installation wrapper (PupGet or DotPup) which the user just clicks to perform the entire install. Not sure how other distros are handling this.
Re: [digitalradio] Re: SDR-1000
If you get the things into the distribution, all these problems go away. Hamish Moffat has laudably done this and is a package maintainer for several programs. He does the work, and we all benefit. At least all Debian users. Personally I don't think all that AX25 stuff is all that useful, but Linux carries it along. It got there because of the support and interest of many hams in packet radio. We need a similar focus on the new tools for digital radio. Debian would seem a likely focus, as volunteer structure is conducive to it. (Unfortunately for me I run fedora, but that may change.) Trying to have repositories of compiled code outside of the repository system for the distributions begs hosting problems and would require a lot of duplication of effort. 73, Leigh/WA5ZNU On Sun, 4 Feb 2007 6:24 pm, Walt DuBose wrote: But that still doesn't preclude amateur radio operators from have a place to store compiled applications for their distro. There would of course have to be as many major directories as Linux distros and sub directoried for the various releases of the distro. if the amateur radio application needed recompiled for the various releases. But then again, who would provide the repository? I would hope that someday the ARRL would do this...but perhaps that's too much of a dream. Walt/K5YFW Leigh L Klotz, Jr. wrote: This is just what package managers do. There are two main package managers: Debainls deb format and Red Hat's RPM. Debian historically did a better job on resolving dependencies at installation time (as opppsed to just reporting them), but part of that ability was due to Debian have a good repository infrastructure into which packages are placed and with which the dependencies can be satisfied. It isn't really true that Debian has one repository, but they do have one structure, and the divisions in them are multi-year long releases, the status (stable, testing, etc.), and the license status (essentially fully GPL or not). I am not a Debian expert so I may be shakey in this area. But the point is you install and make choices, and can satisfy dependencies through an integrated system. In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there was no repository structure integrated into RPM, no root repository, and no way even for multiple repositories to be integrated. Part of the reason the fragmentation was that Red Hat monetized the updates so making it work without their for-pay service wasn't in their interest. So with zred Hat you bought or downloaded their release ISO images and updated wholesale. When the pace of security fixes began to require something better, RedHat introduced a for-pay update service, limited to RedHat. It put the dependency calculation on their servers, just to make sure you paid for it. SuSE was no better in their pre-Novell days. They had no downloadable ISO images at all, and copyrighted their installer, so it was effectively impossible to get SuSE without paying for it. They did offer their individual RPM files for download, but mnoetized the installer. After Novell acquired them, that block went away. But there is still a separate set of RPMs for SuSE. A couple of other companies tried to get into the updater business, and they made variant versions of systems such as Gnome (or, the main version and everyone else was variant, dependong on whom you ask). Unfortunately, once you hopped on that train, you could never get off as there were version conflicts deep down, and the whole thing faltered. Aound the time Fedora split off, the Yum system came about (it grew out of a port of Red Hat to the PowerPC Mac which of necessity needed its own universe), and it allowed integration on the client of multiple repository sources. Yum offered the ability to install and update from the repositories listed. Fedora recently managed to consolidate an external package repository, and they seem to be trying to grapple with this problem, but with Yum they at least have a way ot combining them at the client. Unfortunately, since there is no authoritative source for the RPM packaged version of some library (cross-indexed with a release and status as with Debian), there is no single set of compile-time options in use. As en example, until recently, Fedora users couldn't install W1HKJ's fldigi with the default fltk RPM file on which it depends because Dave's coded needed the --with-threads option required in fltk at compile time. The job of a Linux distribution is to pick in time a set of package versions and instances of them compiled with flags, and make sure (QA) that they work together. RedHat paid people to do this. Debian threw together a tree of latest and encourged people to file fix dependency problems. Neither model scaled well. Recently, the Debian and
Re: [digitalradio] Re: SDR-1000
Thanks for the encouragement Frank. For over 2 years now Gerald had been telling me that Oh yes the SDR-1000 was going to be supported by Linux. As I told Dave, W1HJK, in a private E-Mail and I was going to address Andy's and Roger Rehr's comment. For those of us who eun Linux either just because its different or have been using it for years or hate MS or a hundred other reasons, I think that it would be nice to make amateru radio applications as simple to run under Linux as most MS amateur radio applications are under MS. skip down seven paragraphs to leave out my history But let me tell you where I'm coming from... I have been doind tactical HF communications for over 30 years, the last 8 on my own supporting the local office of emergency management and a disaster relief organization. Before that I was doing tactical HF communications for the Air Force and spend a tour in Saudi during Desert Shiled and Storm as chief of communications for the aeromedical evecuation effort. They had through that time only used HF and has just started using data mixed with voice a couple of years before Desert Shield started in August of 1990. I had worked in my civilian job with the Air Force as an IT procurement analyst and ran the a huge E-Mail system using 10 ATT 3B2 computers and then the first Air Force electronic commerce web site. A friend and one of my technical support persons suggested that I load Linux on a 386 PC and run multiple desktops rather than have 10 monitors on my desk. That was August of 1991. From the 3B2s we went to web servers using medium size Sun servers and Linux workstations. I never was anything but a Linux user and never got much into configuring Linux, etc. When I left that job in 1999, I went to another base that ran MS clients and servers. I have now over 150 MS clients and 6 MS servers to baby sit. I have had to load NT on all of our clients and servers, then W2K and last time XP on the clients. The servers still run W2K server. I can truthfully say that loading MS is a breeze...but having to load Linux on 10 different personal computers with the last two, one being Mandrake and one (the last one) being SuSe 9.?, I find that loading them NO problem but runing amateur radio applications a real pain when compaired to MS applications. End my history I believe that this is why so many hams have an objection to Linux. I find myself coming home and wanting to operate HF data modes and not having to fool around for days trying to get an applications to work or load various libraries, etc. So without pointing any fingers at the amateur radio community...since this IS for most of us a hobby or perhaps a love affair, it would be nice to have Linux applications that are easy to load and run withour compiling and go out and find various different dependencies. I think the latest and very fine example of the sort of amateur radio applications I have loaded is Fldigi by Dave, W1HKJ. Now my Mandarake distro is so old I need to update one library but that's not really a problem or a fault of the applications. And peaking of fine amateur radio things, the theory and construction of the SDR-1000 is super. For the amateur radio operator I believe that it is and will be a leader in the change from the typical radios we have available no to amateur radio operators to SDR radios. Perhaps even a more important step than the Central Electronics 10A/B and 20A/B transmitter and the Drake 2B receiver and Gonset GSB-100 transmitter. I believe that we will see building block SDR radios. Perhaps a case with a number of card slots and you plug in SDR component block cards and build you custom SDR radio. I also look for the same sort of approach for PSK and other data mode radios that are small and portable and replace the current number of QRP rigs. Further, I can see building custom high power amplifiers around various amplfier modules. All these thing will not only bring amateur radio back int the lime light in communications services but also spur iondividuals to get back into the rig building mode and since many of you have such great talent in programming that you can help us by building modular applications and show is the code and explain to us how it works so we can modify it such as Skip Teller did with PSK63 and whomever created PSK125 and like Merray and group did with MFSK-16 and all the other new modes. We need to be able to run them and do lots of beta testing and find out which ones work the best. So I AM frustrated righ now with how Linux is being presented to amateur radio but know that the talent is out there...many on this list, who have the capability so put forth simple code and OF's like me can customize applications. I am counting on everyone's individual talents be they programmer, builder, operator, etc to work in concert to being amateur radio into the leading edge of communications in the
Re: [digitalradio] Re: SDR-1000
I pushed forward to a new repository (sdr_linux) today. Frank and I did the dsp/sdr code and Eric Wachsman and Flex did just about 100% of the hardware code in support of the SDR-1000. It runs on linux, cygwin on MS and native on MS (using the MSVS 2005 express) and probably OSX. It drives both the parallel port and the USB interface control for the hardware. As a result of Eric's efforts at Flex, we will for the first time be able to control all pieces of the SDR-1000 hardware on Linux, Windows, and probably Mac OSX using the USB interface and libusb. He did this while on the clock at Flex with help from Frank and I on makefiles. Given the myriad consoles by Pereira, Melton, etc., this should result in a working GUI driven functional radio pretty quickly for these platforms independent of Flex. Frank Brickle wrote: --- In digitalradio@yahoogroups.com, Walt DuBose [EMAIL PROTECTED] wrote: I'm not going to spend $1500 for an SDR transceiver I can't run from Linux. Roger's website is the best source for information on getting started. There will be new information forthcoming by the end of the weekend. As of a couple of days ago, sdr-core and sdr-shell are now running under Mac OSX as well. I think it's accurate to say that Flex isn't going to attach any importance to real Linux support unless users demand it and demand it vocally. That's exactly what happened with CW. The importance of decent CW performance was dismissed out of hand until it became clear that the lack of it was costing them sales. Once the point was made, the CW performance was improved beyond recognition to its present high standard. We agree completely on CW since I still have the note where Gerald asked us who was complaining about CW? and disagree on Linux and Flex because Gerald is completely aware that the embedded micro in his new gold plated radio cannot run Vista for myriad reasons and has said this explicitly to Frank and I.In a multiway exchange, Gerald said explicitly that Linux would be first out of the gate on any new radio with an embedded micro for dsp/sdr in it. Time will tell. 73 Frank AB2KT 73's Bob N4HY P.S. Frank and I are not employed by or paid by Flex. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine
