It seems to me that the topology.org article is so opinionated that it is mostly flamebait.
As for the parent itself, I think the real problem is not nearly as serious as the parent makes it out to be (IANAL). Of course, you may have legal difficulties if you want to make binary-only kernel modifications or kernel modules, but user-space programs should be completely unaffected since they only access the kernel via system calls, thus covered by the exception in the kernel license (since it is in the license, the developers probably agree with Linus, whatever the court thinks). Therefore, in most cases you can just put your proprietary bits into user space and only the kernel modules/modifications must be released in source form. Well, if you put everything inside the kernel itself and still want to keep things proprietary, you probably do not have much chance since this is probably a derivative work by any interpretation (especially if you don't use modules), but the kernel license had never been designed to allow for such use anyway.
Actually I do think the FSF interpretation of derivative work is too wide. They may have a good intention, but I don't think it is practical to make a program a derivative work simply by linking to a C shared library --- the resulting executable often does not contain anything substantial that is related to the library (mostly just structure offsets and maybe versioning attributes about referenced symbols)! This creates much uncertainty, and if the court disagrees with this, it would be very painful for companies like MySQL AB that more or less rely on this. I think the GPL should have limited its version of "derivative work" to things that are clearly derivative works by the court's interpretation, such as those containing substantial amounts of data (source code, binary code or otherwise) that comes from the library, and LGPL should not have existed, GPL-with-linking-exception should only be meaningful for libraries that are usually statically linked. The FSF is IMHO too ambitious ("we want to create an advantage for free software since only them can link to libreadline!") in this case, and it seems to be too late to change now.
Each line is represented by a linked list of chunks, each containing an arbitrarily long substring of the line. A chunk is split when you insert or delete at the middle of it. The lines of a document are also organized in chunks, in mostly the same way as how characters are organized into lines.
The result is a text editor that can cope with extremely long documents or lines without much difficulty, but it took 118KB of C code, 63KB of which is used to manipulate that fancy data structure.
EM waves should travel at the speed of light in air (which is pretty near the speed of light in vacuum) in coaxial cables. Of course, in optical fibers it will be significantly slower...
Regular user-level applications can only do "obvious" things. They can certainly trash the filesystem, but only when you are running them (Well, malware that are user-level applications but starts itself up automatically in obscure places are almost as bad as kernel-level malware, and should also be regulated...), and since they will easily receive the blame, few dare do that. A kernel-level driver can do much more unobvious things, such as randomly trashing the address space of WINWORD.EXE when it is running, starting from 60 days (the interval can be randomized) after installation of the malware, at the rate of once or twice modifications per day, and it will take longer (depending on the quiescent interval) for people to discover the obscure driver, and by then it is harder to know which software installed that.
Regardless of the usefulness of copy protection, such behaviors of installing things without users' knowledge just cannot be allowed, especially if it is a driver that runs with much privilege. Just imagine if one disgruntled developer in the company put some time-bomb in the code... When ordinary user-level code is used, or when kernel-level stuff is used in something like anti-virus programs, at least a moderately clueful user can know what they are installing, so they can be more careful before installing such things and not blame Microsoft if things go wrong; but in this case, people are not expected to be as careful when installing a video game as when installing some anti-virus software, at least until such practice become even more widespread than it is now.
In my opinion, such things should be categorized as malware, and should only be allowed if adequate warning is given to the user before installation.
Anyway, even when installed as a driver, it can't be fully crack-proof --- the driver can be removed, and the game code can be changed to skip the accesses to the driver. If the game is popular enough, a crack will soon be produced (probably unusable for Internet games though), and even legit users may use them so that they can get rid of the driver that is possibly destabilizing the system.
Any physically existing color (i.e. it is the response of the human eye to a light signal with a certain frequency spectrum) is in the horseshoe-shaped area in the CIE chromaticity diagram. The X, Y and Z base colors are not inside that area, thus they are impossible to produce physically using any means (unless you are going to connect the vision-related part of the brain to something other than a normal eye...).
Indeed, with a number of primary colors (which must lie in the horseshoe shape), one can only produce the colors lying in their convex closure, which is the smallest polygon containing all the points corresponding to the primary colors. Since the horseshoe shape is not a polygon, it is impossible to produce all human-observable colors by mixing a finite number of primary colors.
Although the meaning of colors like #70809E are quite strictly defined in web standards (they are sRGB colors, I believe), in reality such colors are rarely displayed accurately on real monitors with ordinary software. What if your monitors have significantly different color temperature (so the same sRGB color appears warmer on one monitor than another) or gamma settings (so the brightness of #808080 relative to #ffffff are different)? On my monitor, both are tunable.
I guess there are quite a number of software that use MD5 or SHA-1 hashes as if a collision is impossible, and indeed even when there is code to handle hash collision, it had been hard to test that code when no real collisions were known. Now, if such software is fed with two pieces of data with identical MD5 hashes, it might well break in horrible ways --- at least a DoS attack.
I agree. Most people who can type have no intrinisic problems with the command line (especially if you print the commands out using a fixed-width font so that they don't drop a space here or there). In my opinion the biggest problem is GUI tools that seem to work but doesn't sometimes, while corresponding CLI tools (which these GUI tools usually build upon, such as ifconfig) are often much more mature and reliable, and gives meaningful error messages.
You just translate the 64-bit code to equivalent 32-bit operations when they are run (just-in-time compilation, similar to what the Sun Java VM/.NET or Mono VM/qemu/valgrind/VMWare does). With some care the emulated CPU may run quite efficiently, although it will probably not beat a real 64-bit CPU (true 64-bit arithmetic will have to be emulated with multiple instructions), and you are usually better off recompiling your program on the 32-bit CPU so that it can run natively. Also, you may have a hard time dealing with 64-bit memory references efficiently, unless all pointers are effectively 32-bit, or their top 32 bits are always zero.
The native floating-pointer format used by x87 (but not SSE/SSE2) instructions is 80-bit, and you can often use it by declaring "long double" variables in C. Also, the MMX registers are 64-bit and the SSE registers are 128-bit. I don't see how the 88-bit come about.
As for using FP (or MMX/SSE) registers instead of stack/L1 cache... since IIRC you cannot move data between a FP/MMX/SSE register and a general-purpose register directly (only through memory), and you need to put the data into a general-purpose register before you can do addressing (pointer dereference) on it, this can rarely help. Even in the case it does, remember that L1 cache is super-fast (on the order of 1 cycle of latency), so it won't help much except in marginal cases.
Doing integer math in floating-pointer registers seems to be a bit more plausible, since on the Pentium 4 integer multiplication has double the latency and 1.5~2.5 times the throughput than 80-bit floating-point multiplication. This is in the category of optimizing the code for the actual CPU at runtime, which is quite possible, but I doubt they actually do it considering the 88-bit crap.
ISO9660 filesystems can be compressed (so is cramfs, but it is a bit more limited than ISO9660) using the Rock Ridge extension. You cannot add or change any files on the compressed filesystem without redoing the whole compression, but for archival purposes this should not be a problem. Personally I use this to store compressed source trees or large documentation which I take a look once in a while.
IIRC it should be something like that (foo should be a directory containing your stuff):
When you want to use the compressed file, use something like
mount -t iso9660 -o loop foo.iso/mnt/foo
You can also use automount, by adding a line like this to your automount config file (on my machine it is/etc/auto.autofs, referenced from/etc/auto.master:
foo -fstype=iso9660,loop:/baz/foo.iso
Then the compressed filesystem can be accessed as/autofs/foo, which can be symlinked to.
To avoid running out of loop devices that these filesystems use, you may want to add
options loop max_loop=64
to your/etc/modules.conf (2.4 kernel) or/etc/modprobe.conf (2.6 kernel).
Of course, huffyuv etc. should be more suitable in your case, as other posters have said, if your software can support it.
In the DOS era most viruses (including worms) are destructive, so as to satisfy their creators' appetite for destruction. Now we have harsh law against virus/worm writers, so most people who try this will be expecting some monetary gain, which can be obtained by (for example) opening a backdoor on the victims for spam companies. Destroying the victim's computer gain the cracker nothing in money.
I mostly agree with you, but my idea is that it is harder to set a good reward system for programmers than carpenters, simply because the price paid to establish such a system is much higher in the software case. The only cost of getting carpenters paid rather than having them work gratis is that the poor might not be able to afford enough wood for a shelter, which is mostly solvable by setting up a reasonable welfare system. When we want programmers to be paid in the old way (by slapping a price tag on it, and forbidding users copying/modifying/redistributing it), it not only keeps people who can't afford it from using it (same as above), but the program becomes less useful to those who can afford it as well, since the users now lose some freedom which is sometimes quite important. Personally, I have modified quite a number of open source programs to make it suit my taste (such as reduced difficulty in games), fix some problems or to implement some small new features. Most of them are less than 10 lines, often meant as a quick hack, but a few are serious code containing 100+ lines. If such things were left to be done by the software company, I would have to wait for a long time, potentially spend more time (not to mention money) on it (most of the one-liners take less than half a day to write, yet purchasing a new version usually takes as much time), and it might not get done at all since it is not useful to others and might add bloat to the software.
In order to solve this problem, open-source business models based on free-as-in-freedom software and support are invented, which is admittedly not as straightforward as the traditional model based on proprietary software and copyright, but is less costly (in terms of reduction of the usefulness of software) to implement as well. This applies whether or not the software is free-as-in-beer, although making the software free-as-in-beer reduces the I-can't-afford-it kind of cost, while reducing the programmer's reward at the same time.
I think it is all about cost. Programmers deserve to be paid, but the infrastructure to reward them should not cost too much in terms of the usefulness of the software, just like you cannot collect tax on a road by collecting money on every crossroad. If no acceptable way to pay the programmers can be found, at least we can make them government-sponsored, just like how many mathematicians are paid currently, although I doubt if this is necessary.
Actually the same applies to patents too. The current system of rewarding inventors by using patents costs rather high, too, since everyone else is shut out completely, without even the option of rewriting the code when it is copyrighted with a non-free license.
Anyway I don't hate Microsoft much, since it doesn't harm anyone who does not use their products much, at least. What I hate are DMCA backers and patent monkeys, since they make some useful software illegal, which harms people mostly unrelated with them (those who never bought or used anything from them, and those who discover their patented technology independently, sometimes without any knowledge of the patent).
Well, such frustration happens quite often when doing research, and this one isn't really that much harder. The hard part is getting the right problem and being willing to spend a lot of time on it with possibly no return. Not many people would want to spend whole days (like Huffman did as you say) on a problem if it is probably unsolvable, causing all efforts to be wasted... and even though solving the problem takes little time if you are lucky enough to be on the right track at the beginning, in average cases much time (often days) is wasted on impossible ways.
I still don't think patents are good for such cases. If 100 people in the world can solve the problem at first sight since their ways of thinking happen to suit the problem, the solution is obvious to them, but probably still nonobvious to the patent office (partly because the examiners are usually not that bright, partly because it is hard to judge obviousness a posteriori), and I don't think it is fair not to give these other people a chance, at least to use their solution.
I'm pretty sure that for a good CS researcher in the days with no compression algorithms other than Huffman coding and run-length encoding (both are relatively obvious), thinking for a whole day should probably result in something similar. I guess an undergraduate can do it with enough time and encouragement. Then why is it better to make the first discoverer monopolize on it without giving everyone else a chance? Trade secrets seem to be better, and it doesn't require government intervention for the most part.
Indeed quite a lot of patents nowadays are on inventions thought out in a day or less. A good human brain knowing all necessary background information and working for a whole day can really invent some extremely nonobvious and useful things (just ask Linus or John Carmack how many extremely clever ideas they come up with in a month), especially for people working on another field. Patents were created for fear some important inventions will not get invented until much later if the first inventor doesn't disclose its innerworkings, which may be reasonable in the old "slow" days, but is much less convincing a reason in these days with so many R&D people around to reinvent things again and again.
Maybe many linux users are a bit spoiled... but I'm quite sure that everything on these 5cd linux distros are used by quite a few people. Old schoolers like me hate to have to look for some apps (like mc) on the 'net, while the said app has always been included in the "large" distros. Even relatively new users may be bitten when they firstly try to compile some software from source and find that some necessary tools are not installed. It is the same reason why it is often better to choose the packages by hand rather than choose the big "Workstation"/"Desktop" options which often install quite different things from what you want.
Also, five CDs are not that hard to carry about, and when your all-slimed-down distribution hit the market, everyone else can use DVD-ROMs without too much difficulty (and then maybe everyone can have a 250GB hard drive so that full installs are almost always done).
Generally you should not expect the laws to help you profitting from your invention/software/whatever, just as they usually should not hinder you from making profit. People have had profit from their inventions before patents ever existed, they just have to do all the protection themselves if they want to limit the use of their technology, and one reason patent laws (and also copyright laws in this respect) are created is just because it seems to be inefficient (not really unfair) to have everyone do the protection themselves. You should also rely on yourself rather than blaming the laws not containing explicit provisions to help you.
Today quite a lot of code is still written in C or C++-like C, especially for software running by an ordinary user on a PC. Compiling such mostly low-level languages is not very difficult, and if you do things in the cleanest way (don't pass huge structs as function arguments, use g_strdup_printf() or snprintf() or memcpy() instead of slow and unsafe strcat(), have clear distinction between integer and floating-point variables to avoid unnecessary conversion, use unsigned types when it is a good idea, etc.), the compiler knows exactly what the machine should do, and produces reasonably fast code. Of course it may be a bit slower than carefully hand-optimized assembly, but the difference is very CPU-dependent and also not usually high given current compiler technologies.
In short, in C you should be able to produce good and clean code that tells the compiler how the machine should perform the job, rather than saying only the "what" part (which is hard to express well, precluding many optimizations) vaguely and rely on the compiler (which does routine jobs such as register allocation well, but is not that clever) to figure out your exact purpose.
High level languages (such as Lisp/Haskell) are currently different. Since they are so high-level, and the compiler isn't clever enough for it (so that it can optimize away some type-checking, lazy evaluation and do some function inline which is essential for acceptable performance sometimes), you often have to write code in a not-so-beautiful way if the speed matters a little. That's my pet peeve against such languages which makes me reluctant to use them if the resulting code is going to take more than a few seconds of CPU-time, although I love them dearly otherwise.
Anyway WindowMaker is quite easy to use, and have some nice keyboard shortcuts. I just set up ten virtual desktops, and give beginners Midnight Commander (within xterm) for file management, then they are immediately quite happy.
It is true that GNOME/KDE is more similar to Windows systems that most newbies are used to, but they are also more complex than WM, and also less solid and consistent (yes, the core tools can be quite stable, but beginners still get into trouble in some small parts that don't work as well). Also, since they look similar to Windows, any differences, and especially lack of features in certain parts, become more annoying. With WM plus MC, since everything is so different, beginners are rather delighted to see some of the nice features of them, such as virtual desktops and Ctrl-S in MC, and every feature mentioned just works. When they are getting mostly comfortable with the system, I encourage them to use vi/emacs instead of newer, more Windows-like but less solid and feature-filled things, just for the same reason.
My notion of "newbies" includes my classmates in a university and my parents in their 50s. They can pick up new things pretty quickly, but if anything doesn't work as advertised, or works inconsistently (I don't mean applications with different widget sets, which is ugly but acceptable to most --- my papa can use Protel 3.xx for DOS quite comfortably even though he uses Windows most of the time --- but rather things that works sometimes but doesn't work in other circumstances), even relatively experienced users like me will get annoyed, let alone beginners.
Well, I still think that disallowing or shorting software patents to 2 years is a good idea...
Personally I don't care much about small inventors. In many fields (such as the aeroplane/semiconductor industry), individuals and small players have almost never been able to compete with big players such as Intel, yet no one complains, since the law is mostly fair, it is just that small players don't have enough money to start with (actually there are also patents, but a silicon fab would cost a ton for an individual even without all IP-related things). The software industry might or might not be different, but the point holds: if you can outdo big corporations, good luck; if you can't, it is not always because the law is unfair to you.
Also, it is quite possible to profit from a software patent (if it is allowed at all) in a mere 2 years, at least for a big corporation such as MS / IBM, so why should the time be lengthened just because you can't implement and market your idea as quickly? And what's wrong with big corporations profiting from your invention after the patent expire? Everyone profit from public domain knowledge all the time --- those who can make better use of it profits more.
IANAL, but you should be able to rely on NDAs to make the company keep the thing secret, and vice versa (so that the company can get a monopoly if you want) and there should be something else in the agreement stating that profits are to be shared, etc.
In this way the government is not involved, and you can do it in any way you and the company like. You just have to decide what to disclose to the company before you sign the agreement.
I think we really must reconsider whether the benefits of patents from publication (as opposed to using trade secrets / NDAs instead) are high enough to keep the government involved in such a hard-to-get-right mess.
1. Arithmetic shifts are divisions that round downwards, which is different from the C integer division operator which rounds toward zero. Therefore the C compiler is obliged to use something more clumsy although very few people actually need that.
2. ICC8 does generate a division with "-O3 -march=pentium4", although I think it doesn't have to do strict math by default. Strange.
Slashdot Mirror
As for the parent itself, I think the real problem is not nearly as serious as the parent makes it out to be (IANAL). Of course, you may have legal difficulties if you want to make binary-only kernel modifications or kernel modules, but user-space programs should be completely unaffected since they only access the kernel via system calls, thus covered by the exception in the kernel license (since it is in the license, the developers probably agree with Linus, whatever the court thinks). Therefore, in most cases you can just put your proprietary bits into user space and only the kernel modules/modifications must be released in source form. Well, if you put everything inside the kernel itself and still want to keep things proprietary, you probably do not have much chance since this is probably a derivative work by any interpretation (especially if you don't use modules), but the kernel license had never been designed to allow for such use anyway.
Actually I do think the FSF interpretation of derivative work is too wide. They may have a good intention, but I don't think it is practical to make a program a derivative work simply by linking to a C shared library --- the resulting executable often does not contain anything substantial that is related to the library (mostly just structure offsets and maybe versioning attributes about referenced symbols)! This creates much uncertainty, and if the court disagrees with this, it would be very painful for companies like MySQL AB that more or less rely on this. I think the GPL should have limited its version of "derivative work" to things that are clearly derivative works by the court's interpretation, such as those containing substantial amounts of data (source code, binary code or otherwise) that comes from the library, and LGPL should not have existed, GPL-with-linking-exception should only be meaningful for libraries that are usually statically linked. The FSF is IMHO too ambitious ("we want to create an advantage for free software since only them can link to libreadline!") in this case, and it seems to be too late to change now.
The result is a text editor that can cope with extremely long documents or lines without much difficulty, but it took 118KB of C code, 63KB of which is used to manipulate that fancy data structure.
EM waves should travel at the speed of light in air (which is pretty near the speed of light in vacuum) in coaxial cables. Of course, in optical fibers it will be significantly slower...
Regular user-level applications can only do "obvious" things. They can certainly trash the filesystem, but only when you are running them (Well, malware that are user-level applications but starts itself up automatically in obscure places are almost as bad as kernel-level malware, and should also be regulated...), and since they will easily receive the blame, few dare do that. A kernel-level driver can do much more unobvious things, such as randomly trashing the address space of WINWORD.EXE when it is running, starting from 60 days (the interval can be randomized) after installation of the malware, at the rate of once or twice modifications per day, and it will take longer (depending on the quiescent interval) for people to discover the obscure driver, and by then it is harder to know which software installed that.
In my opinion, such things should be categorized as malware, and should only be allowed if adequate warning is given to the user before installation.
Anyway, even when installed as a driver, it can't be fully crack-proof --- the driver can be removed, and the game code can be changed to skip the accesses to the driver. If the game is popular enough, a crack will soon be produced (probably unusable for Internet games though), and even legit users may use them so that they can get rid of the driver that is possibly destabilizing the system.
Indeed, with a number of primary colors (which must lie in the horseshoe shape), one can only produce the colors lying in their convex closure, which is the smallest polygon containing all the points corresponding to the primary colors. Since the horseshoe shape is not a polygon, it is impossible to produce all human-observable colors by mixing a finite number of primary colors.
Although the meaning of colors like #70809E are quite strictly defined in web standards (they are sRGB colors, I believe), in reality such colors are rarely displayed accurately on real monitors with ordinary software. What if your monitors have significantly different color temperature (so the same sRGB color appears warmer on one monitor than another) or gamma settings (so the brightness of #808080 relative to #ffffff are different)? On my monitor, both are tunable.
I guess there are quite a number of software that use MD5 or SHA-1 hashes as if a collision is impossible, and indeed even when there is code to handle hash collision, it had been hard to test that code when no real collisions were known. Now, if such software is fed with two pieces of data with identical MD5 hashes, it might well break in horrible ways --- at least a DoS attack.
I agree. Most people who can type have no intrinisic problems with the command line (especially if you print the commands out using a fixed-width font so that they don't drop a space here or there). In my opinion the biggest problem is GUI tools that seem to work but doesn't sometimes, while corresponding CLI tools (which these GUI tools usually build upon, such as ifconfig) are often much more mature and reliable, and gives meaningful error messages.
You just translate the 64-bit code to equivalent 32-bit operations when they are run (just-in-time compilation, similar to what the Sun Java VM/.NET or Mono VM/qemu/valgrind/VMWare does). With some care the emulated CPU may run quite efficiently, although it will probably not beat a real 64-bit CPU (true 64-bit arithmetic will have to be emulated with multiple instructions), and you are usually better off recompiling your program on the 32-bit CPU so that it can run natively. Also, you may have a hard time dealing with 64-bit memory references efficiently, unless all pointers are effectively 32-bit, or their top 32 bits are always zero.
As for using FP (or MMX/SSE) registers instead of stack/L1 cache... since IIRC you cannot move data between a FP/MMX/SSE register and a general-purpose register directly (only through memory), and you need to put the data into a general-purpose register before you can do addressing (pointer dereference) on it, this can rarely help. Even in the case it does, remember that L1 cache is super-fast (on the order of 1 cycle of latency), so it won't help much except in marginal cases.
Doing integer math in floating-pointer registers seems to be a bit more plausible, since on the Pentium 4 integer multiplication has double the latency and 1.5~2.5 times the throughput than 80-bit floating-point multiplication. This is in the category of optimizing the code for the actual CPU at runtime, which is quite possible, but I doubt they actually do it considering the 88-bit crap.
IIRC it should be something like that (foo should be a directory containing your stuff):
When you want to use the compressed file, use something likeYou can also use automount, by adding a line like this to your automount config file (on my machine it isTo avoid running out of loop devices that these filesystems use, you may want to add
to yourOf course, huffyuv etc. should be more suitable in your case, as other posters have said, if your software can support it.
In the DOS era most viruses (including worms) are destructive, so as to satisfy their creators' appetite for destruction. Now we have harsh law against virus/worm writers, so most people who try this will be expecting some monetary gain, which can be obtained by (for example) opening a backdoor on the victims for spam companies. Destroying the victim's computer gain the cracker nothing in money.
In order to solve this problem, open-source business models based on free-as-in-freedom software and support are invented, which is admittedly not as straightforward as the traditional model based on proprietary software and copyright, but is less costly (in terms of reduction of the usefulness of software) to implement as well. This applies whether or not the software is free-as-in-beer, although making the software free-as-in-beer reduces the I-can't-afford-it kind of cost, while reducing the programmer's reward at the same time.
I think it is all about cost. Programmers deserve to be paid, but the infrastructure to reward them should not cost too much in terms of the usefulness of the software, just like you cannot collect tax on a road by collecting money on every crossroad. If no acceptable way to pay the programmers can be found, at least we can make them government-sponsored, just like how many mathematicians are paid currently, although I doubt if this is necessary.
Actually the same applies to patents too. The current system of rewarding inventors by using patents costs rather high, too, since everyone else is shut out completely, without even the option of rewriting the code when it is copyrighted with a non-free license.
Anyway I don't hate Microsoft much, since it doesn't harm anyone who does not use their products much, at least. What I hate are DMCA backers and patent monkeys, since they make some useful software illegal, which harms people mostly unrelated with them (those who never bought or used anything from them, and those who discover their patented technology independently, sometimes without any knowledge of the patent).
I still don't think patents are good for such cases. If 100 people in the world can solve the problem at first sight since their ways of thinking happen to suit the problem, the solution is obvious to them, but probably still nonobvious to the patent office (partly because the examiners are usually not that bright, partly because it is hard to judge obviousness a posteriori), and I don't think it is fair not to give these other people a chance, at least to use their solution.
Indeed quite a lot of patents nowadays are on inventions thought out in a day or less. A good human brain knowing all necessary background information and working for a whole day can really invent some extremely nonobvious and useful things (just ask Linus or John Carmack how many extremely clever ideas they come up with in a month), especially for people working on another field. Patents were created for fear some important inventions will not get invented until much later if the first inventor doesn't disclose its innerworkings, which may be reasonable in the old "slow" days, but is much less convincing a reason in these days with so many R&D people around to reinvent things again and again.
Also, five CDs are not that hard to carry about, and when your all-slimed-down distribution hit the market, everyone else can use DVD-ROMs without too much difficulty (and then maybe everyone can have a 250GB hard drive so that full installs are almost always done).
Generally you should not expect the laws to help you profitting from your invention/software/whatever, just as they usually should not hinder you from making profit. People have had profit from their inventions before patents ever existed, they just have to do all the protection themselves if they want to limit the use of their technology, and one reason patent laws (and also copyright laws in this respect) are created is just because it seems to be inefficient (not really unfair) to have everyone do the protection themselves. You should also rely on yourself rather than blaming the laws not containing explicit provisions to help you.
In short, in C you should be able to produce good and clean code that tells the compiler how the machine should perform the job, rather than saying only the "what" part (which is hard to express well, precluding many optimizations) vaguely and rely on the compiler (which does routine jobs such as register allocation well, but is not that clever) to figure out your exact purpose.
High level languages (such as Lisp/Haskell) are currently different. Since they are so high-level, and the compiler isn't clever enough for it (so that it can optimize away some type-checking, lazy evaluation and do some function inline which is essential for acceptable performance sometimes), you often have to write code in a not-so-beautiful way if the speed matters a little. That's my pet peeve against such languages which makes me reluctant to use them if the resulting code is going to take more than a few seconds of CPU-time, although I love them dearly otherwise.
It is true that GNOME/KDE is more similar to Windows systems that most newbies are used to, but they are also more complex than WM, and also less solid and consistent (yes, the core tools can be quite stable, but beginners still get into trouble in some small parts that don't work as well). Also, since they look similar to Windows, any differences, and especially lack of features in certain parts, become more annoying. With WM plus MC, since everything is so different, beginners are rather delighted to see some of the nice features of them, such as virtual desktops and Ctrl-S in MC, and every feature mentioned just works. When they are getting mostly comfortable with the system, I encourage them to use vi/emacs instead of newer, more Windows-like but less solid and feature-filled things, just for the same reason.
My notion of "newbies" includes my classmates in a university and my parents in their 50s. They can pick up new things pretty quickly, but if anything doesn't work as advertised, or works inconsistently (I don't mean applications with different widget sets, which is ugly but acceptable to most --- my papa can use Protel 3.xx for DOS quite comfortably even though he uses Windows most of the time --- but rather things that works sometimes but doesn't work in other circumstances), even relatively experienced users like me will get annoyed, let alone beginners.
Personally I don't care much about small inventors. In many fields (such as the aeroplane/semiconductor industry), individuals and small players have almost never been able to compete with big players such as Intel, yet no one complains, since the law is mostly fair, it is just that small players don't have enough money to start with (actually there are also patents, but a silicon fab would cost a ton for an individual even without all IP-related things). The software industry might or might not be different, but the point holds: if you can outdo big corporations, good luck; if you can't, it is not always because the law is unfair to you.
Also, it is quite possible to profit from a software patent (if it is allowed at all) in a mere 2 years, at least for a big corporation such as MS / IBM, so why should the time be lengthened just because you can't implement and market your idea as quickly? And what's wrong with big corporations profiting from your invention after the patent expire? Everyone profit from public domain knowledge all the time --- those who can make better use of it profits more.
In this way the government is not involved, and you can do it in any way you and the company like. You just have to decide what to disclose to the company before you sign the agreement.
I think we really must reconsider whether the benefits of patents from publication (as opposed to using trade secrets / NDAs instead) are high enough to keep the government involved in such a hard-to-get-right mess.
2. ICC8 does generate a division with "-O3 -march=pentium4", although I think it doesn't have to do strict math by default. Strange.