I was thinking something similar. Most distributions can be distilled down to a set of build scripts, a pointer to the master sources, and a set of patches, all of which should take up very little space (think Gentoo Portage, or BSD Ports collection)
Instead of the analog signals being cut at a certain date, I think a better approach would be to decrease the output power of the analog signal by, say, 20% a year over the course of 5 years. That way, people with existing sets won't be forced to suddenly buy new equipment. Those that don't upgrade will just get a gradually weaker signal. A weak signal will cause people to want to upgrade (or get a cheap digital -> analog converter box), where as a suddenly cut off signal will make for angry viewers.
I remember reading an article a number of years ago about how the Velcro corporation almost lost their contract with Ford when their patents expired. This was because quality was inspected into the product, and not engineered (via process) into the product. Even if the end results were the same, a well-engineered process is considered more of a guarantee of future success than a proven track record (all else being equil). It wasn't until Velcro improved their processes that Ford felt comfortable with them again. (Note, it may have been GM, not Ford, my memory is a bit foggy). So, the same line of thinking can apply to compairing Britanica with Wikipedia -- one has a process to produce consistancy, the other uses random inspection & correction.
I have to chime in with a "me to" post. There is a lot of flak given to Red Hat over RHEL, but to be honest I'm glad this option is out there. This, and possibly Suse enterprise, is the one of the bigger reasons that I'm seeing wide-spread Linux adoption with the customers I deal with. It basically comes down to that management wants the "warm fuzzys" with the software that runs their business. And I'm quiet satisfied with how Red Hat handles their update policy (minimally invasive patches against baseline package versions, etc.). Also, if you want the same distribution for a lab box but without the Red Hat support baggage, you have the option of installing one of the rebuild projects (Centos, whitebox linux, scientific linux, etc.)
Just out of curiosity, can't they follow the same business model that VCR and DVD manufactures follow? I.e., make a good product, and sell it for a profit.
> I can see you believe that a 100% unbreachable security is possible.
Well, I don't know of any bank vault or safe that is 100% unbreachable, but it doesn't stop banks from buying them. And their financial loss could be extreeme if the vault is breached.
Well, you could have a two-part system. The mic and speaker could be in the hearing aids, and they would normally work in "dumb" mode, but could be switch to a "smart" mode where they communicate wirelessly with a remote processor that you could wear like a pager. This would then open the door to a lot more processing capabilities. For example, typicall lossy audio compression that is tuned to speech also does a fairly reasonable job of filtering out non-speech sounds. As far as changing the pitch, there is a smipler method. I've used audio tools that change the speed of a sample without changing the pitch, they work by duplicating / removing select audio samples from the input. Then take that output and do a normal speedup / slowdown on the resultant waveform (it's not perfect, but quiet acceptable sound).
Another trick you can do by having an external processing unit would be to have local storage on it, so that instead of asking someone "can you repeat that", you can hit a button on your box to replay the last 10 seconds.
Personally, I'd prefer the study to be done using RedHat Enterprise. I know this may leave a bad taste in your mouth, but I've found that it is more stable (in terms of least disruptive patches). Also, especially since they moved to a model of releasing quarterly updates, it is much easier to properly baseline your systems. My policy is to update all of our systems based on the quarterly ISO's, so that you don't have too many variations within the orginization. And, if you don't want to shell out for a Redhat subscription, then you can always use one of the rebuild projects, such as CentOS or Scientific Linux (which tracks the exact same package versions)
>Have you never had a mount lock up on you that couldn't be recovered?
Here's a tip for NFS mounts. Use the option "-o intr,soft". This will allow you to kill processes that have a file open on a hung nfs mount, thereby allowing you to umount the filesystem. NFS uses "hard" mounts by default, in which case a process won't get a return from a read or write system call until that call is successfull, which has the side effect of causing processes to hang when the nfs server goes away. Soft mounts will allow a non-successful return from a read.
If you have a mounted NFS filesystem that is hung, you can also do a "mount -oremount,soft,intr/path/to/mount" to change mount options on the fly.
You do realize that you can use rdev to set the root filesystem on your kernel, don't you? That way, you can copy your "root" floppy contents to a hard drive partition, stick your boot disk in the drive, and "rdev/dev/fd0/dev/hda1". Now, next time you boot from that floppy, it will mount your hard drive partition as it's root filesystem. (ok, I'm really showing my age here:-)
I can also confirm this, as there's been times when a plastic bag has blown in the back of my F150 and it will swirl up in the air by the cab, and back down into the bed again toward the tailgate, them back repeat the cycle. The only way it gets blown out is if a cross-wind catches it.
Has there been any Audio CD drm put out that doesn't rely on the auto-run feature of Windows? I remember reading something about one method that would put defects in the disc that would be filtered out by an audio CD player, but I haven't seen any reports if that would affect cd-paranoia. In other words, since I do all my music work using Linux, do I need to worry about any of the protection methods currently out there? I'd like to see a list of all the drm methods that are "in the wild" along with their prevalence and effectiveness agains various OS's & tools.
Another thing to consider is dvd-ram, which from what I recall uses phase-change instead of a photographic dye structure, so it should be more durable (basically the same tech that MO drives use). A good low-cost drive that supports dvd-ram (along with all the other formats) is the LG-GSA4167 (around $50 or so). However the media will set you back a bit more.
> soon you'll have to run rootkit detection from a bootable CD
An alternative would be to boot up a VM first, then have that load your OS kernel. Something like a stripped-down version of VMware, or Xen. The idea being that virus / rootkit detection can go into one VM, and all your day-to-day stuff goes in a another session. Then as long as there isn't any way to breach the VM's sandbox the detection code can have it's own access to the drives without being influenced by any virus running in your main session.
I was thinking, that instead of a "hard cutover", where the analog frequencies are cut off on a particular date, there should be a phased approach where the transmit power is cut down by say 20% per year. That way, people's analog sets won't just go suddenly blank, and there will be less consumer backlash from cutting the analog signals.
Actually, I think the previous comment could be better stated as "in the absense of competition, or when a vendor has a competitive advantage, vendor profit is sticky downward". In the case of cell phones, the costs to the vendors has gone down (digital lines + compression means less bandwith taken per call, means more calls can be placed within a given frequency allocation, therefore lower cost to the provider (so they can charge a lower price to the consumer without giving up profit). Also, don't forget that if vendor profit is sticky downwards, that doesn't mean vendor profit on a per unit basis, the per unit profit can go way down if the total unis sold go up enough to more than cover the spread.
But the general sentiment is that once a consumer is used to paying a particular price, there will be less consummer pressure to push the price down.
I remember reading an opinion that there is no legal method to make anything public domain. Under current copyright law, the creator automatically gets copyright when the work is created. The only way for the creator to relinquish copyright is to sign it over to someone else, or to distribute it with a license. But this isn't the same as public domain. The only way for something to become public domain is for the copyright to expire (after, what is it now, 90 years after the authors death?)
The biggest problem I see is that any particular package may require a large number of pre-requisites, and chasing those down can be a pain. This is more of a problem with cutting-edge software such as dvr's (mythtv), etc. In these cases, about 90% of the pre-reqs are libraries of one form or another. This is where I think packages should go back to static linking for certain libraries. Any library that is included with the default install of most distributions can be dynamically linked, but if a package requires a library that most likely isn't going to be used by anything else, then those libs should be statically linked to that binary. Or, include a private library with such packages that contain the contents of all the "special" libraries, so that you still have the option of updating the libs without recompiling the package.
I've heard of cases where in some areas you can take the judgement to the local sheriff, have them go with out to the company, and you can by force remove enough assets from the companies premises up to the value of the judgement.
I know that this is true, because I read it in another Slashdot post:-)
Actually, if you want to make non-GPL licensed software for KDE then it is more expensive (due to QT). However, there is a way around that. All you have to do is write a GPL'd window-object management program, that takes commands from standard input (such as create_window, create_input_box, read_from_input_box, etc...), have it execute the appropriate QT calls, and return results to it's standard output. Then your program fork's & exec's this piece of code, which acts as an insalator between your non-GPL'd code and the GPL'd QT code (since your program isn't linked directly to QT then it isn't a derivative work). Or, write two interface libraries that have the same API, one version talks to QT and the other version talks to another similar widget library that is BSD or LGPL licensed. As long as your code dynamically links to this buffer library, then no one can claim that your code contains the GPL'd QT code, since you can turn around and say that you wrote it against the "other" library (which you've licensed under BSD or LGPL). Then it is up to the user to set the appropriate flags to have the desired library version used.
I would like to add another "covert" Linux installation method. One thing you can do is put a large hidden file, call it something like "swap.sys" or something of that nature. Boot Linux from an attached device (usb / cdrom), then use losetup to loopback mount that file, and run your normal linux install from there. This will take a bit of advanced knowledge to set up since you'd probably have to install your distro to another drive and copy it over, then set up the initial ram disk image on your boot device to do the right thing (losetup, mount, pivot_root, etc...) You'd have to make sure you have maximum firewalling turned on so that the network admins can't see your install. Also make sure you have a screen saver on when you step away to keep "them" from gaining access to your box when you step away. If they reboot it, then it will come up to the normal Windows install. If you are a bit more paranoid, you can shrink your primary partition, and point losetup to your raw drive (/dev/hda), and feed it an offset (-o option) large enough to skip over your primary partition, then use that (/dev/loop0) as your root filesystem. Add encryption for complete undetectability. Of course, both of these options are vulnerable to getting whiped out by your IT staff, so good backups are a must.
But, how many of those customers have a bunch of PC's sitting on employee desks that are idle 99% of the time? Even if the PC's are running windows, it would still be a fairly easy task to push out a colinux image via sms, and have the image automatically join the cluster. As long as the cluster software can account for nodes joining and leaving the network arbitrarily, then it could be a more cost-effective solution.
So in other words, it is similar to enclosing a page from another site in a frame with your document? Even though this is easy to block, and the content comes from the other site, courts have ruled that this is a form of infringement.
Actually, your analogy works perfect for this. Your Ford Hybrid is comprised of muliple components, but the main part that people see and feel is made by Ford, so it is a Ford, even though the kernel (hybrid drivetrain) is Honda. In the case of a typical Linux-kernel based distribution, the bulk of what you interact with (if you take out the GUI), i.e., the part that people see and feel (bash, cp, ls, gcc, emacs (ducks) is all GNU. Of course, I've left out anything related to the GUI above. To the old-timers, the GUI is nothing more than the equivilant of leather seats in your hybrid suv, but to others it is the equivalant to the Shelby modifications on a 67 Ford Mustang. Where am I going with this? Well, I think a Linux system should actually be refered to by the name of the distribution, i.e., you have a Red Hat OS, a Debian system, etc. There is a lot more that goes into putting together a distribution than just throwing together a kernel and a bunch of utilities. The only thing that should actually be called a GNU or GNU/Linux system is a distribution assembled and published by the GNU folks themselves.
Slashdot Mirror
I was thinking something similar. Most distributions can be distilled down to a set of build scripts, a pointer to the master sources, and a set of patches, all of which should take up very little space (think Gentoo Portage, or BSD Ports collection)
But, you can get a student loan, then use the reimbursement to pay for that.
Instead of the analog signals being cut at a certain date, I think a better approach would be to decrease the output power of the analog signal by, say, 20% a year over the course of 5 years. That way, people with existing sets won't be forced to suddenly buy new equipment. Those that don't upgrade will just get a gradually weaker signal. A weak signal will cause people to want to upgrade (or get a cheap digital -> analog converter box), where as a suddenly cut off signal will make for angry viewers.
I remember reading an article a number of years ago about how the Velcro corporation almost lost their contract with Ford when their patents expired. This was because quality was inspected into the product, and not engineered (via process) into the product. Even if the end results were the same, a well-engineered process is considered more of a guarantee of future success than a proven track record (all else being equil). It wasn't until Velcro improved their processes that Ford felt comfortable with them again. (Note, it may have been GM, not Ford, my memory is a bit foggy).
So, the same line of thinking can apply to compairing Britanica with Wikipedia -- one has a process to produce consistancy, the other uses random inspection & correction.
I have to chime in with a "me to" post. There is a lot of flak given to Red Hat over RHEL, but to be honest I'm glad this option is out there. This, and possibly Suse enterprise, is the one of the bigger reasons that I'm seeing wide-spread Linux adoption with the customers I deal with. It basically comes down to that management wants the "warm fuzzys" with the software that runs their business. And I'm quiet satisfied with how Red Hat handles their update policy (minimally invasive patches against baseline package versions, etc.). Also, if you want the same distribution for a lab box but without the Red Hat support baggage, you have the option of installing one of the rebuild projects (Centos, whitebox linux, scientific linux, etc.)
Just out of curiosity, can't they follow the same business model that VCR and DVD manufactures follow? I.e., make a good product, and sell it for a profit.
> I can see you believe that a 100% unbreachable security is possible.
Well, I don't know of any bank vault or safe that is 100% unbreachable, but it doesn't stop banks from buying them. And their financial loss could be extreeme if the vault is breached.
Well, you could have a two-part system. The mic and speaker could be in the hearing aids, and they would normally work in "dumb" mode, but could be switch to a "smart" mode where they communicate wirelessly with a remote processor that you could wear like a pager. This would then open the door to a lot more processing capabilities. For example, typicall lossy audio compression that is tuned to speech also does a fairly reasonable job of filtering out non-speech sounds. As far as changing the pitch, there is a smipler method. I've used audio tools that change the speed of a sample without changing the pitch, they work by duplicating / removing select audio samples from the input. Then take that output and do a normal speedup / slowdown on the resultant waveform (it's not perfect, but quiet acceptable sound).
Another trick you can do by having an external processing unit would be to have local storage on it, so that instead of asking someone "can you repeat that", you can hit a button on your box to replay the last 10 seconds.
Personally, I'd prefer the study to be done using RedHat Enterprise. I know this may leave a bad taste in your mouth, but I've found that it is more stable (in terms of least disruptive patches). Also, especially since they moved to a model of releasing quarterly updates, it is much easier to properly baseline your systems. My policy is to update all of our systems based on the quarterly ISO's, so that you don't have too many variations within the orginization.
And, if you don't want to shell out for a Redhat subscription, then you can always use one of the rebuild projects, such as CentOS or Scientific Linux (which tracks the exact same package versions)
>Have you never had a mount lock up on you that couldn't be recovered?
/path/to/mount" to change mount options on the fly.
Here's a tip for NFS mounts. Use the option "-o intr,soft". This will allow you to kill processes that have a file open on a hung nfs mount, thereby allowing you to umount the filesystem. NFS uses "hard" mounts by default, in which case a process won't get a return from a read or write system call until that call is successfull, which has the side effect of causing processes to hang when the nfs server goes away. Soft mounts will allow a non-successful return from a read.
If you have a mounted NFS filesystem that is hung, you can also do a "mount -oremount,soft,intr
You do realize that you can use rdev to set the root filesystem on your kernel, don't you? That way, you can copy your "root" floppy contents to a hard drive partition, stick your boot disk in the drive, and "rdev /dev/fd0 /dev/hda1". Now, next time you boot from that floppy, it will mount your hard drive partition as it's root filesystem. :-)
(ok, I'm really showing my age here
I can also confirm this, as there's been times when a plastic bag has blown in the back of my F150 and it will swirl up in the air by the cab, and back down into the bed again toward the tailgate, them back repeat the cycle. The only way it gets blown out is if a cross-wind catches it.
Has there been any Audio CD drm put out that doesn't rely on the auto-run feature of Windows? I remember reading something about one method that would put defects in the disc that would be filtered out by an audio CD player, but I haven't seen any reports if that would affect cd-paranoia.
In other words, since I do all my music work using Linux, do I need to worry about any of the protection methods currently out there?
I'd like to see a list of all the drm methods that are "in the wild" along with their prevalence and effectiveness agains various OS's & tools.
Another thing to consider is dvd-ram, which from what I recall uses phase-change instead of a photographic dye structure, so it should be more durable (basically the same tech that MO drives use).
A good low-cost drive that supports dvd-ram (along with all the other formats) is the LG-GSA4167 (around $50 or so). However the media will set you back a bit more.
> soon you'll have to run rootkit detection from a bootable CD
An alternative would be to boot up a VM first, then have that load your OS kernel. Something like a stripped-down version of VMware, or Xen. The idea being that virus / rootkit detection can go into one VM, and all your day-to-day stuff goes in a another session. Then as long as there isn't any way to breach the VM's sandbox the detection code can have it's own access to the drives without being influenced by any virus running in your main session.
I was thinking, that instead of a "hard cutover", where the analog frequencies are cut off on a particular date, there should be a phased approach where the transmit power is cut down by say 20% per year. That way, people's analog sets won't just go suddenly blank, and there will be less consumer backlash from cutting the analog signals.
Actually, I think the previous comment could be better stated as "in the absense of competition, or when a vendor has a competitive advantage, vendor profit is sticky downward". In the case of cell phones, the costs to the vendors has gone down (digital lines + compression means less bandwith taken per call, means more calls can be placed within a given frequency allocation, therefore lower cost to the provider (so they can charge a lower price to the consumer without giving up profit). Also, don't forget that if vendor profit is sticky downwards, that doesn't mean vendor profit on a per unit basis, the per unit profit can go way down if the total unis sold go up enough to more than cover the spread.
But the general sentiment is that once a consumer is used to paying a particular price, there will be less consummer pressure to push the price down.
I remember reading an opinion that there is no legal method to make anything public domain. Under current copyright law, the creator automatically gets copyright when the work is created. The only way for the creator to relinquish copyright is to sign it over to someone else, or to distribute it with a license. But this isn't the same as public domain. The only way for something to become public domain is for the copyright to expire (after, what is it now, 90 years after the authors death?)
The biggest problem I see is that any particular package may require a large number of pre-requisites, and chasing those down can be a pain. This is more of a problem with cutting-edge software such as dvr's (mythtv), etc. In these cases, about 90% of the pre-reqs are libraries of one form or another.
This is where I think packages should go back to static linking for certain libraries. Any library that is included with the default install of most distributions can be dynamically linked, but if a package requires a library that most likely isn't going to be used by anything else, then those libs should be statically linked to that binary. Or, include a private library with such packages that contain the contents of all the "special" libraries, so that you still have the option of updating the libs without recompiling the package.
I've heard of cases where in some areas you can take the judgement to the local sheriff, have them go with out to the company, and you can by force remove enough assets from the companies premises up to the value of the judgement.
:-)
I know that this is true, because I read it in another Slashdot post
Actually, if you want to make non-GPL licensed software for KDE then it is more expensive (due to QT).
However, there is a way around that. All you have to do is write a GPL'd window-object management program, that takes commands from standard input (such as create_window, create_input_box, read_from_input_box, etc...), have it execute the appropriate QT calls, and return results to it's standard output. Then your program fork's & exec's this piece of code, which acts as an insalator between your non-GPL'd code and the GPL'd QT code (since your program isn't linked directly to QT then it isn't a derivative work).
Or, write two interface libraries that have the same API, one version talks to QT and the other version talks to another similar widget library that is BSD or LGPL licensed. As long as your code dynamically links to this buffer library, then no one can claim that your code contains the GPL'd QT code, since you can turn around and say that you wrote it against the "other" library (which you've licensed under BSD or LGPL). Then it is up to the user to set the appropriate flags to have the desired library version used.
I would like to add another "covert" Linux installation method.
One thing you can do is put a large hidden file, call it something like "swap.sys" or something of that nature. Boot Linux from an attached device (usb / cdrom), then use losetup to loopback mount that file, and run your normal linux install from there. This will take a bit of advanced knowledge to set up since you'd probably have to install your distro to another drive and copy it over, then set up the initial ram disk image on your boot device to do the right thing (losetup, mount, pivot_root, etc...) You'd have to make sure you have maximum firewalling turned on so that the network admins can't see your install. Also make sure you have a screen saver on when you step away to keep "them" from gaining access to your box when you step away. If they reboot it, then it will come up to the normal Windows install.
If you are a bit more paranoid, you can shrink your primary partition, and point losetup to your raw drive (/dev/hda), and feed it an offset (-o option) large enough to skip over your primary partition, then use that (/dev/loop0) as your root filesystem. Add encryption for complete undetectability.
Of course, both of these options are vulnerable to getting whiped out by your IT staff, so good backups are a must.
But, how many of those customers have a bunch of PC's sitting on employee desks that are idle 99% of the time?
Even if the PC's are running windows, it would still be a fairly easy task to push out a colinux image via sms, and have the image automatically join the cluster. As long as the cluster software can account for nodes joining and leaving the network arbitrarily, then it could be a more cost-effective solution.
So in other words, it is similar to enclosing a page from another site in a frame with your document? Even though this is easy to block, and the content comes from the other site, courts have ruled that this is a form of infringement.
Actually, your analogy works perfect for this. Your Ford Hybrid is comprised of muliple components, but the main part that people see and feel is made by Ford, so it is a Ford, even though the kernel (hybrid drivetrain) is Honda.
In the case of a typical Linux-kernel based distribution, the bulk of what you interact with (if you take out the GUI), i.e., the part that people see and feel (bash, cp, ls, gcc, emacs (ducks) is all GNU.
Of course, I've left out anything related to the GUI above. To the old-timers, the GUI is nothing more than the equivilant of leather seats in your hybrid suv, but to others it is the equivalant to the Shelby modifications on a 67 Ford Mustang.
Where am I going with this? Well, I think a Linux system should actually be refered to by the name of the distribution, i.e., you have a Red Hat OS, a Debian system, etc. There is a lot more that goes into putting together a distribution than just throwing together a kernel and a bunch of utilities. The only thing that should actually be called a GNU or GNU/Linux system is a distribution assembled and published by the GNU folks themselves.