The way I see it, breaking things is bad, but the cost of breaking things is the price we pay for not having a centrally managed kernel system. Then again, the analagy really isn't accurate-- Microsoft doesn't have brand new (and recently experimental) kernels available, so I can't just try throwing an XP kernel on my win98se install. And as distributers are ready, they'll begin to deal with 2.6.0. I'm hoping that by 2.6.1, there will be a short guide to migrating my Debian desktop to the new kernel.
In the offhand chance your software is found in violation of the GPL, you are not FORCED into opening your own source. It is a valid way to recieve a liscence, but if found guilty of not having one, thet courts cannot force you to open your code up, nor force you to GPL your code. The copyright holder can ask for money, or ask that you halt distrobution of infringing materials, and maybe ask for legal fees. As the lawyers have said, those legal remedies are plenty to stop most would be gpl thieves.
All this is of course assuming your bugaboo scenario involving a blurred distinction of 'using' and distributing derivitive works is somehow ruled on to make the above scenario continue in court.
Circa one year ago. You'll just have to trust me I suppose, but my roommate trashed his install pretty quickly by accidentally unplugging his computer FROM THE UPS. Hilarious. He spilled water on the floor next to a surge protector that powered his guitar amplifier, water heater and stereo. Went to pull that from the UPS (not sure why it was in there--"extra sockets" he says) and pulled the computer out. Rebooted and x crashed to console, the emacs file was full of zeros, and various other nuisances. All his user files were intact, thankfully. Sure would suck to lose the art he was workin on.
In contrast, I didn't bother with a UPS. Just ran ext3, and every time some jackass thinks its funny to pull the plug, or when the shitty middle of kansas power grid fails me, it just means an fsck on reboot.
The lesson is that not all Journallings are made equal. You can set ext3 to suck just as much as xfs, but it seems foolish. XFS only journals the meta data, rather than the data itself. Since I'm enlightening the ignorant, I'll go ahead and even link to SGI's faq on the subject. Basically their excuse is "thats a feature not a bug." Go figure.
XFS will ruin your day if you unplug the computer by accident, nosy dog or act of northeastern powergrid. Ext3 will just take a minute longer to reboot than normal.
Are you nuts? I know there's actually more than three sentences in the article-- I read it myself -- but do please try from time to time to read the damn thing. Linus emphatically does not believe "that anything that uses interface to kernel is derived work." Linux offers two levels of intimacy with the kernel. One has very few entry points for module to kernel, something you might expect from a driver that really doesn't use the kernel. The other, the one with the "gpl symbols" offers access to a wide set of toys.
Also watch out when using the word "use," its vague and open to interpretation. The GPL itself uses the word 4 times in specific contexts; two of these are in the "CAPITAL TEXT WARNING - NOT FIT FOR HUMAN CONSUMPTION" clauses. The kerneltrap.org article had a posting concerning this very word. Since I like to encourage reading, you'll have to do the homework as an extra credit exercise.
The deal with telling where the kernel stops and the driver module originates with Alan Cox's complaints about nvidia drivers really screwing the whole damn kernel up; users submitting bugs swearing that the nvidia drivers weren't installed, and Mr. Cox unable to fathom where the origin of certain oft repeated bugs lie. From this arose the "tainted" variable. If non GPL'd code is insmod'd into the kernel, it gets set (and apparently gets set again on athlon smp). I agree with Mr. Cox's approach; if Nvidia can't be bothered to release the source to the community then they should either be prepared to support their own buggy drivers or lose community appeal to other companies willing to take their place (ATi comes to mind).
Personally, I'd be pissed if 2.6 dropped binary module support -- I just finally got those damned nvidia drivers to work properly! Its nice to go from 50 glxgears frames to 800 (why no more? im guessing the cpu is the bottleneck, or possibly ram). While I'd love to see open source drivers for nvidia chipsets that work well, when forced to chose between shitty drivers and binaries drivers, I'll choose binaries, thank you. I've had my fill of nv.
I'm working on a minor in embedded systems. These days you don't use much assembler. Of course, most of your code looks like a C version of assembler, and you'll need to know how to READ ASM because the compilers occasionally screw up. Few people build assembler programs from the ground up, its too time consuming versus letting a C compiler do most of the work for you and taking over when desperately needed. Most of the actual coding done in assembler isn't very algorithmic, or "software engineered."
Its pretty fun when everything works the way you think its supposed to, but other times the compiler and development environment conspire against you to disable the XBus on your kitCON 167 so that all CAN communication fails. But on the bright side, after about the fifth binary to hex conversion you get pretty good at it.
High proliferation. High profile. People talk about how windows is awful with self propagating security exploits, but some forms of Linux can also be comprimised via a single point of entry. If done properly you could probably infect a wide swath of people and make it stick, similar to that old trick about compiling a login prompt and compiling the compiler.
Of course, it doesn't take that much motivation to try something like this. I mean, why do people TK in counter-strike?
First, apparently in the US there are laws about giving legal advice; just to be on the safe side, I am not a lawyer, and the following is hardly sound legal advice!
Its important to seperate the appeals process from the concept of a retrial. Lets make sure we both understand eachother before we go around making brash claims about double jeopardy and UN Human Rights things. The appeals process is built to handle the very problems you've cited with juries and evidence. Very rarely are trials reheld, but its frequent that parts of the original trial are made invalid as part of the appeals process.
I'm not sure what you mean by needing to be proven guilty in every court trial up to the highest court. For starters, prosecution and defense can appeal the trial. An appeal is not a retrial. An appeal is a request for review of the process that led to judgement. Appeals can be denied if the higher court decides that the appeal is baseless. Secondly, you don't retry cases, at least in America, in a higher court. It goes straight back to the same level it started in.
All of this is a complete waste of time though. When did Open Source simply become a way to avoid paying for Windows?
Shortly after Wired decided that Linux was the Desktop Savior. You'll notice Wired is hardly unbiased when it comes to technological issues. Instead they try to find small nuggets of future trends and cater to them, resulting in an amplification and a self fullfilling prophesy. They had a long going series on MP3 files and how revolutionary it was to steal music. Of course this doesn't always work and we end up with short lived propaganda about DNA computing and biological chips.
Biological chips are hardly computational. In nature those devices are experimental tools--they aid in the process of experimentation. They are one shot devices to indicate the presence of a wide variety of DNA samples. They will not make your computer think harder, faster or cheaper. But it was a new angle on "computing," and they have a readership to keep.
Actually, I think there's a good chance knoppix won't be including this. Its a chicken and egg type problem: the ntfs driver will likely be stored on an ntfs partition. In a normal linux installation you can fix this by mounting the ntfs drive as read only and moving the core driver elsewhere. Then just unmount the drive and remount with the ntfs binary hack.
On the other hand, Knoppix defaults to read only on all writable media. This is for safety reasons, so you can't screw things up by just reading the drive. I'm pretty sure it can read NTFS, but it wouldn't have many places to put the driver. Knoppix can't include the binary itself, since its copyrighted by MS (and probably backed by several patents).
Note that if you have no way of reading NTFS at all, you're almost completely hosed, since the ntfs.sys file will be on an ntfs partition. Fortunately Free implementations of NTFS exist and are reasonably stable in read only mode.
The TI 92 is like a portable computer. Symbolic manipulation? Check. Indefinite integration? Done. graphing? Yes. The thing has a qwerty keyboard underneath the display. The 89 is essentially a 92 in regular TI style. I can't recall which language you program the both in, but I'd imagine it has the standard TI BASIC at least. The UI is menu based, similar to the TI 85/86 with more visual description.
Since its got a keyboard, you won't have to look up many key functions, unless you have a hard time with the alphabet.
Actually, rotational storage is very different from standard memory. Its considered inefficient not to use as much RAM as possible because using one page is as useful as the next. There's a uniform cost across all areas of RAM. In contrast, one prefers linear writes in a disk because it improves throughput. Each page on disk is not identical in usage cost. What we're paying here is the oppertunity cost if we use a specific page in disk.
On the other hand, I agree that a marked for deletion queue makes a great use of "extra" disk space on a desktop system. But this use should not be forced on a filesystem that's used in a wide variety of different situations. Ideally, this idea can be done on top of the file system.
Makes me wonder how such problems could be addressed in the future. I mean, its easy enough to see that "Bounds checking on do_brk()" should be classified as a 'security fix' (and possibly a correctness fix). Could a simple classification of each patch help identify security holes and do so well enough to justify the additional work?
Well, I'm no Bruce Perens (I'm no lawyer either), but if I recall the GPL correctly, the 3 year limitation applies to written offers only; I don't think courts see offers displayed on screen the same way. And if I recall correctly, thats the only one that expires. The gpl covers this quite well, so you might take yourself a half day and work through the meaning of the GPL. Especially since this code is 10 years old (apparently if you don't specify a version, any version may be applied, though figuring out if you actually provided a liscence file or not may be difficult).
But this is largely irrelevant; you own the copyright. The GPL applies to people you distribute to. I suppose you could sue yourself for infringement, but you hold the copyright, and can do whatever you see fit with it, including releasing it to others under the GPL. And moreover, as a person you don't have much to offer people who want to sue you. Usually people are looking for the source code. They can't sue that out of you if its gone. Since the code is gone, you're not providing access to GPL'd code.
Some people don't really feel safe enough with latest stable kernels. Sometimes this means running a few weeks behind the latest kernel.org stable release, sometimes this means running a point release behind (unless something serious is uncovered). Sometimes it means basing your entire distrobution on a kernel from the previous stable branch (the Debian installer defaults to 2.2 still... though that will change soon)!
Myself I don't think I'll be upgrading immediately to 2.6. I know the developers feel confident in the 2.6 tree, but quality release needs stress testing, in the kind of volume you might find in a point-oh release. Save any show stoppers, I'll probably join in the 2.6 fun in 2.6.1 or so. I know that its not a safety guarentee; 2.4.18 or so had a vulnerability in pthread I hear.
Well, Debian automagically adds things to the menu, but they have an integrated installer. And frankly, its a bit of a mess. Fortunately there's two menus, the popular tools menu and the "everything installed" submenu. Debian just might be the answer to your RPM problems.
Of course, then you'll have real problems about installation. Its not very user friendly, but if you can make your way through the text based installers (easy if you're at home with consoles), then day to day operations are simple and mostly pain free. There's still some rough edges around binary only programs like drivers, but thats hardly a Debian only situation.
Spiffy but a little late. I've allready built gaim without making a package, so there's no package ro remove. Reinstalling a new version via checkinstall falls victom to the same things a normal debian install does. I'll consider it in the future, though.
The situation I was decribing hit me in Debian. As best I can tell, I'm stuck with managing my own gaim compiles, or figuring out how to remove every last trace of the local install.
Indeed it can. The default settings are wierd, but I've found a fun combination that looks nice. The first thing to fixing the usual GNOME config is to remove the bottom bar. Especially if you're keyboard oriented. Sure, theres a button to slide it off screen, but why leave the button?
Then put a few applets in the top bar like gweather and the clock/calendar. Minimal, yet fully functional.
Since I've gotten ahold of one of those rare BSD advocates running in the wild, let me ask a question. I'll bring up an example that has come up for me.
Lets say a new version of gaim just came out, supporting some cool new feature my friends use now. Lets also say its not in ports yet. So I download gaim and do it by hand. When the new gaim hits the ports tree, how is this handled?
Slashdot Mirror
The way I see it, breaking things is bad, but the cost of breaking things is the price we pay for not having a centrally managed kernel system. Then again, the analagy really isn't accurate-- Microsoft doesn't have brand new (and recently experimental) kernels available, so I can't just try throwing an XP kernel on my win98se install. And as distributers are ready, they'll begin to deal with 2.6.0. I'm hoping that by 2.6.1, there will be a short guide to migrating my Debian desktop to the new kernel.
In the offhand chance your software is found in violation of the GPL, you are not FORCED into opening your own source. It is a valid way to recieve a liscence, but if found guilty of not having one, thet courts cannot force you to open your code up, nor force you to GPL your code. The copyright holder can ask for money, or ask that you halt distrobution of infringing materials, and maybe ask for legal fees. As the lawyers have said, those legal remedies are plenty to stop most would be gpl thieves.
All this is of course assuming your bugaboo scenario involving a blurred distinction of 'using' and distributing derivitive works is somehow ruled on to make the above scenario continue in court.
Circa one year ago. You'll just have to trust me I suppose, but my roommate trashed his install pretty quickly by accidentally unplugging his computer FROM THE UPS. Hilarious. He spilled water on the floor next to a surge protector that powered his guitar amplifier, water heater and stereo. Went to pull that from the UPS (not sure why it was in there--"extra sockets" he says) and pulled the computer out. Rebooted and x crashed to console, the emacs file was full of zeros, and various other nuisances. All his user files were intact, thankfully. Sure would suck to lose the art he was workin on.
In contrast, I didn't bother with a UPS. Just ran ext3, and every time some jackass thinks its funny to pull the plug, or when the shitty middle of kansas power grid fails me, it just means an fsck on reboot.
The lesson is that not all Journallings are made equal. You can set ext3 to suck just as much as xfs, but it seems foolish. XFS only journals the meta data, rather than the data itself. Since I'm enlightening the ignorant, I'll go ahead and even link to SGI's faq on the subject. Basically their excuse is "thats a feature not a bug." Go figure.
Another comparison I can vouch for by experience
XFS will ruin your day if you unplug the computer by accident, nosy dog or act of northeastern powergrid. Ext3 will just take a minute longer to reboot than normal.
Are you nuts? I know there's actually more than three sentences in the article-- I read it myself -- but do please try from time to time to read the damn thing. Linus emphatically does not believe "that anything that uses interface to kernel is derived work." Linux offers two levels of intimacy with the kernel. One has very few entry points for module to kernel, something you might expect from a driver that really doesn't use the kernel. The other, the one with the "gpl symbols" offers access to a wide set of toys.
Also watch out when using the word "use," its vague and open to interpretation. The GPL itself uses the word 4 times in specific contexts; two of these are in the "CAPITAL TEXT WARNING - NOT FIT FOR HUMAN CONSUMPTION" clauses. The kerneltrap.org article had a posting concerning this very word. Since I like to encourage reading, you'll have to do the homework as an extra credit exercise.
The deal with telling where the kernel stops and the driver module originates with Alan Cox's complaints about nvidia drivers really screwing the whole damn kernel up; users submitting bugs swearing that the nvidia drivers weren't installed, and Mr. Cox unable to fathom where the origin of certain oft repeated bugs lie. From this arose the "tainted" variable. If non GPL'd code is insmod'd into the kernel, it gets set (and apparently gets set again on athlon smp). I agree with Mr. Cox's approach; if Nvidia can't be bothered to release the source to the community then they should either be prepared to support their own buggy drivers or lose community appeal to other companies willing to take their place (ATi comes to mind).
Personally, I'd be pissed if 2.6 dropped binary module support -- I just finally got those damned nvidia drivers to work properly! Its nice to go from 50 glxgears frames to 800 (why no more? im guessing the cpu is the bottleneck, or possibly ram). While I'd love to see open source drivers for nvidia chipsets that work well, when forced to chose between shitty drivers and binaries drivers, I'll choose binaries, thank you. I've had my fill of nv.
I'm working on a minor in embedded systems. These days you don't use much assembler. Of course, most of your code looks like a C version of assembler, and you'll need to know how to READ ASM because the compilers occasionally screw up. Few people build assembler programs from the ground up, its too time consuming versus letting a C compiler do most of the work for you and taking over when desperately needed. Most of the actual coding done in assembler isn't very algorithmic, or "software engineered."
Its pretty fun when everything works the way you think its supposed to, but other times the compiler and development environment conspire against you to disable the XBus on your kitCON 167 so that all CAN communication fails. But on the bright side, after about the fifth binary to hex conversion you get pretty good at it.
And the famous corrolary, "If the birds are in the sky and upside down, you're drunk and lying on the ground." Courtesy Bill Engvall.
High proliferation. High profile. People talk about how windows is awful with self propagating security exploits, but some forms of Linux can also be comprimised via a single point of entry. If done properly you could probably infect a wide swath of people and make it stick, similar to that old trick about compiling a login prompt and compiling the compiler.
Of course, it doesn't take that much motivation to try something like this. I mean, why do people TK in counter-strike?
Sounds pretty juicy for Norweigian lawyers! Kinda makes you wonder how taxes are there...
First, apparently in the US there are laws about giving legal advice; just to be on the safe side, I am not a lawyer, and the following is hardly sound legal advice!
Its important to seperate the appeals process from the concept of a retrial. Lets make sure we both understand eachother before we go around making brash claims about double jeopardy and UN Human Rights things. The appeals process is built to handle the very problems you've cited with juries and evidence. Very rarely are trials reheld, but its frequent that parts of the original trial are made invalid as part of the appeals process.
I'm not sure what you mean by needing to be proven guilty in every court trial up to the highest court. For starters, prosecution and defense can appeal the trial. An appeal is not a retrial. An appeal is a request for review of the process that led to judgement. Appeals can be denied if the higher court decides that the appeal is baseless. Secondly, you don't retry cases, at least in America, in a higher court. It goes straight back to the same level it started in.
All of this is a complete waste of time though. When did Open Source simply become a way to avoid paying for Windows?
Shortly after Wired decided that Linux was the Desktop Savior. You'll notice Wired is hardly unbiased when it comes to technological issues. Instead they try to find small nuggets of future trends and cater to them, resulting in an amplification and a self fullfilling prophesy. They had a long going series on MP3 files and how revolutionary it was to steal music. Of course this doesn't always work and we end up with short lived propaganda about DNA computing and biological chips.
Biological chips are hardly computational. In nature those devices are experimental tools--they aid in the process of experimentation. They are one shot devices to indicate the presence of a wide variety of DNA samples. They will not make your computer think harder, faster or cheaper. But it was a new angle on "computing," and they have a readership to keep.
Actually, I think there's a good chance knoppix won't be including this. Its a chicken and egg type problem: the ntfs driver will likely be stored on an ntfs partition. In a normal linux installation you can fix this by mounting the ntfs drive as read only and moving the core driver elsewhere. Then just unmount the drive and remount with the ntfs binary hack.
On the other hand, Knoppix defaults to read only on all writable media. This is for safety reasons, so you can't screw things up by just reading the drive. I'm pretty sure it can read NTFS, but it wouldn't have many places to put the driver. Knoppix can't include the binary itself, since its copyrighted by MS (and probably backed by several patents).
Note that if you have no way of reading NTFS at all, you're almost completely hosed, since the ntfs.sys file will be on an ntfs partition. Fortunately Free implementations of NTFS exist and are reasonably stable in read only mode.
Is tylenol and bengay allowed in marathon video gaming?
The TI 92 is like a portable computer. Symbolic manipulation? Check. Indefinite integration? Done. graphing? Yes. The thing has a qwerty keyboard underneath the display. The 89 is essentially a 92 in regular TI style. I can't recall which language you program the both in, but I'd imagine it has the standard TI BASIC at least. The UI is menu based, similar to the TI 85/86 with more visual description.
Since its got a keyboard, you won't have to look up many key functions, unless you have a hard time with the alphabet.
Actually, rotational storage is very different from standard memory. Its considered inefficient not to use as much RAM as possible because using one page is as useful as the next. There's a uniform cost across all areas of RAM. In contrast, one prefers linear writes in a disk because it improves throughput. Each page on disk is not identical in usage cost. What we're paying here is the oppertunity cost if we use a specific page in disk.
On the other hand, I agree that a marked for deletion queue makes a great use of "extra" disk space on a desktop system. But this use should not be forced on a filesystem that's used in a wide variety of different situations. Ideally, this idea can be done on top of the file system.
Makes me wonder how such problems could be addressed in the future. I mean, its easy enough to see that "Bounds checking on do_brk()" should be classified as a 'security fix' (and possibly a correctness fix). Could a simple classification of each patch help identify security holes and do so well enough to justify the additional work?
Well, I'm no Bruce Perens (I'm no lawyer either), but if I recall the GPL correctly, the 3 year limitation applies to written offers only; I don't think courts see offers displayed on screen the same way. And if I recall correctly, thats the only one that expires. The gpl covers this quite well, so you might take yourself a half day and work through the meaning of the GPL. Especially since this code is 10 years old (apparently if you don't specify a version, any version may be applied, though figuring out if you actually provided a liscence file or not may be difficult).
But this is largely irrelevant; you own the copyright. The GPL applies to people you distribute to. I suppose you could sue yourself for infringement, but you hold the copyright, and can do whatever you see fit with it, including releasing it to others under the GPL. And moreover, as a person you don't have much to offer people who want to sue you. Usually people are looking for the source code. They can't sue that out of you if its gone. Since the code is gone, you're not providing access to GPL'd code.
Some people don't really feel safe enough with latest stable kernels. Sometimes this means running a few weeks behind the latest kernel.org stable release, sometimes this means running a point release behind (unless something serious is uncovered). Sometimes it means basing your entire distrobution on a kernel from the previous stable branch (the Debian installer defaults to 2.2 still... though that will change soon)!
Myself I don't think I'll be upgrading immediately to 2.6. I know the developers feel confident in the 2.6 tree, but quality release needs stress testing, in the kind of volume you might find in a point-oh release. Save any show stoppers, I'll probably join in the 2.6 fun in 2.6.1 or so. I know that its not a safety guarentee; 2.4.18 or so had a vulnerability in pthread I hear.
Well, Debian automagically adds things to the menu, but they have an integrated installer. And frankly, its a bit of a mess. Fortunately there's two menus, the popular tools menu and the "everything installed" submenu. Debian just might be the answer to your RPM problems.
Of course, then you'll have real problems about installation. Its not very user friendly, but if you can make your way through the text based installers (easy if you're at home with consoles), then day to day operations are simple and mostly pain free. There's still some rough edges around binary only programs like drivers, but thats hardly a Debian only situation.
But apple claims that was just cough medication. On the other hand, the Dell d00d has been implicated in public record.
Spiffy but a little late. I've allready built gaim without making a package, so there's no package ro remove. Reinstalling a new version via checkinstall falls victom to the same things a normal debian install does. I'll consider it in the future, though.
The situation I was decribing hit me in Debian. As best I can tell, I'm stuck with managing my own gaim compiles, or figuring out how to remove every last trace of the local install.
Indeed it can. The default settings are wierd, but I've found a fun combination that looks nice. The first thing to fixing the usual GNOME config is to remove the bottom bar. Especially if you're keyboard oriented. Sure, theres a button to slide it off screen, but why leave the button?
Then put a few applets in the top bar like gweather and the clock/calendar. Minimal, yet fully functional.
Since I've gotten ahold of one of those rare BSD advocates running in the wild, let me ask a question. I'll bring up an example that has come up for me.
Lets say a new version of gaim just came out, supporting some cool new feature my friends use now. Lets also say its not in ports yet. So I download gaim and do it by hand. When the new gaim hits the ports tree, how is this handled?