hell, even if you find a working "xclock" binary from that time it will be a miracle
Oh that one would be easy. Unfortunately I don't have any 1996 Linux systems sitting around or I would try it. xclock is a simple application that links to a stable and standardized API. Getting a ten year old xclock to run on a current Linux system would be a snap.
Re:Be careful how far out your ass you talk.
on
Why Windows is Slow
·
· Score: 1
You didn't even read his post, did you? You asked him to give you an example, and he did. He did. He can take an binary from his old Slackware CD and drop it in and have it run. That is your example.
It's not slow because of legacy software, it's slow because of legacy design. Windows is designed for localized single user monotasking. There's a lot of networking, multiuser and multitasking blobs and layers tacked on, but underneath it's still operating with a legacy CPM/86 mentality.
If you're only running one application, Windows is damned fast. But it starts to significantly slow down after a certain number of applications. Have an admin log in remotely for some maintenance and it starts to seriously drag. I don't have a problem with this, because I'm in the habit of keeping crap off my system tray and shutting down applications after I'm done using them. But a coworker never shuts down any application. She may have twenty or thirty different windows up on her screen, and her habit is to keep minimizing stuff until she finds what she wants. Her system is dog slow, and restoring a particular window can take two to five seconds (on a 2Ghz system).
But the exact same behavior on her Solaris workstation does not result in a slowdown. The disorganization is still there, but the cold molasses sluggishness is not.
Another example. When I compile software under Windows, that's pretty much all I can do. Every other application starts stuttering, and the whole system drags. But compiling software under my FreeBSD or OSX systems results in no noticable slowdowns. Even with three simultaneous builds going on, my FreeBSD KDE desktop is just as fast and responsive as ever.
No, this discussion is about moving Linux and Unix to the OSX model. You cannot do that because you don't have a single centrally controlled framework.
Which version of KDE do you make the core libraries? 3.5.2? What do you do when 4.0 comes out? In order not to break everyone's app bundles, you have to keep the old libraries around. Ditto for 4.1, and 4.2, and 4.3., etc, etc. Imagine doing this since KDE 1.0. And GNOME 1.0. And for all of the supplemental libraries they use. And for glibc (which breaks compatibility ever other release even though it's the closest thing to a stable API Linux has). That starts adding up to a LOT of disk space.
Application bundles work for OSX because Apple retains firm control over all aspects of the core system. The core system libraries come from *Apple*, not from third parties. It can force its own developers to retain API compatibility, but it has no say over what KDE, GNOME, GTK+, Qt, or glibc developers can do.
That's one disadvantage to Free Software. But it is made up with many many advantages. Our trains may not run on time, but that's because we have more than one train.
Why should they care if they have enough disk space and RAM to hold both versions of KDE?
Both versions? You're talking about every KDE version since 1.0! And not just the KDE libraries, but all the Qt and miscellaneous support libraries as well. Oh, and all the various glibc versions as well (they tend to break compatibility every other release). Since they are user downloaded app bundles residing in user home directories, the system cannot upgrade them. You don't know what the user has so you have to assume they have something old. It's very bad form to break applications just because you did an automatic system software update.
You mean like when OS X 10.1, 10.2, 10.3, and 10.4 came out?
That's not a problem, because Apple is in firm control of the system libraries, and more importantly, in control of the system APIs. Not being a free operating system, it doesn't have to worry about several dozen fundamental third party system libraries.
But what libraries do you standardize on? And once you standardize, how do you upgrade to a newer version? For example, currently KDE uses Qt 3.3.x. If Linux is "standardized" on 3.3.5, what happens when KDE 4.0 comes out which will use Qt 4.1.x? Neither version is compatible with the other. Do you put KDE on hold for two years while the bureaucratic standards committee argues over this? Do you tell Trolltech they can never change their API because it's been standardized?
Even if you keep the app bundle concept in a specific distro (which every distro is free to do), there's still no way to easily upgrade an individual application bundle. Which means you have to keep older libraries around forever. You have to keep them around or the users' applications will break when you upgrade the base system. In the case of KDE, that's dozens of gigabytes of old library versions since the 1.0 days.
A proprietary (in the sense that the system is controlled by a single entity) operating system does not have this problem because it can control the APIs for the system libraries. You cannot do this with free operating systems.
A package manager avoids all these problems, without adding any burden to the user.
You can see the product here: http://www.nexdisk.com/e_index.asp. Specifically it's a 128Mb USB 1.1 Nexdisk thumbdrive. There is nothing wrong with it, and it works flawlessly on all Linux, FreeBSD, OSX, Windows98, and (most) Windows XP systems. But because of a driver conflict on the developer's workstations at work, it will crash those particular systems. A few other USB drives would crash them as well. In addition, for USB drives that work, you still have to plug them in, then unplug them, then plug them in again, before you can access them.
But this is what people here on this thread want Linux distros to be. The app bundle concept works ONLY because OSX is a closed an centrally controlled system. There are solutions much more appropriate to free and open systems, such as package managers (a concept, btw, the Apple uses to distribute all of its own software).
Let's take an example desktop and examine it to see how much diskspace it would take. Let's consider the the mythical GDE desktop. It uses the GDE libraries which in turn use the QTK+ library. It also uses about a dozen other minor libraries. This is not counting the various specialized libraries that individual GDE apps might use (like libbrainz). Also, there are fifty applications and utilities in the "core" GDE distribution.
All numbers are examples pulled out of my ass:
GDE application: 5Mb GDE libraries: 15Mb QTK+ library: 10Mb Supplemental libraries: 10Mb
Total app bundle size: 40Mb Total GDE installation size: 2000MB
That's not that horrible considering the size of today's harddrives, but it's wasteful nonetheless. Consider a system that uses shared libraries instead, and it only takes up 285Mb. That's a huge difference.
I don't know what the numbers would be with real KDE or GNOME desktop, but I greatly suspect my numbers are pitifully low. This is why Apple, yes Apple, uses shared libraries for every piece of software it distributes.
Thus, if an application wants an "obscure" library and decides to bundle it, the cost to the system is minimal even if another app has the same one. The MacOS bundle is not at all the equivalent of statically linking against gtk and other "fundamental" libraries in Linux.
That's because OSX is a closed system, whose "fundamental" libraries are defined by Apple. Linux and BSD cannot do this because they are open. What do you do if the system has all the KDE 3.4 libraries installed, but you want to run a KDE 3.5.1 application? Or worse yet, how do you upgrade without a package manager when KDE 4.0 comes out?
No one here has cojones large enough to tell EVERY ONE of the thousand or so "fundamental" libraries that their APIs are static and frozen. Hell, KDE and GNOME can't even do that within the KDE and GNOME projects!
That's why app bundles won't work under free Linux and BSD systems. But it won't matter because package managers are a better solution.
...and was secretly hoping that Linux wold catch up with it's own version and take-off.
Except that Linux (and Unix in general) doesn't need it. Most package managers are extremely simple to use. Download package, double click on package, done.
The app bundle concept is nice, but it has several problems. First of all it's wasteful. Imagine every KDE application being an app bundle with their own private copies of all the KDE libraries. Second, it's more difficult to run the app bundles from scripts (most end users won't care, but most admins will). Third, you STILL have to sudo to root and install in the system wide Applications directory if you want more than one person to use the software. Fourth, this works on OSX because you have a comprehensive set of standard system libraries, something that Linux does not have. Everything that isn't glibc has to go into the app bundle. Finally, app bundles are only application for standalone applications. They don't make sense for services, daemons, and the like.
A good package manager, on the other hand, will automatically deal with dependencies. A good front end integrated into the desktop makes it a snap to use. It has the added bonus of providing a simple software upgrade path, something I've seen break in OSX in a couple of cases.
OSX has a package manager which Apple uses for ALL of its software. iTunes isn't an app bundle. If package managers are good enough for Apple, they're good enough for everyone.
You're assuming the Windows user has all of the required drivers and shit available on CDs somewhere. Lose those and suddenly even OpenBSD starts to look like an easy install for my Grandma! If you're building your own system instead of reinstalling on an OEM system, Linux and BSD can actually be easier to install. In my own experience installing FreeBSD and Gentoo on my old HP laptop was a snap compared to Windows XP, since I had lost the laptop's recovery CD.
When the Windows install works, it's easy. When it doesn't it's incredibly difficult.
People paying some attention to the Vista development may notice that during build 5000, Microsoft did basically a 180 turn and decided to throw out the new foundation of managed (.NET) code on an XP SP2 based kernel, and rather go with the Windows Server 2003 kernel.
That how large corporations work. Not only do they eat their own dog food, they pretend it's filet mignon. The politics of using an in-house tool are such that the decision cannot be questioned until it's evident that it is severely delaying the product. And even then the messenger of the bad news will still get canned.
My company decided all of our new products would incorporate a framework done by a different division. At the time we were the market leader, two years ahead of our competitors' ability to catch up. But we weren't given the option of looking elsewhere for this functionality, we were told to use it and not to question it. When the CEO, VP and director of software decided to incorporate the framework in "stages" over the span of two different product releases, all three got canned. It is now four years later, we still don't have a new product out, and it will take us at least two years to catch up to our competition. We are now in permanent "survival mode", as we keep adding cosmetic quick fixes to our legacy products in the hopes of retaining our market share.
No, as much as it sounds, I do NOT work for Microsoft:-)
The simple answer is high demand and low supply. But a closer look reveals that this isn't necessarily the case. Supply is actually very high, and the market nearly saturated. And while demand for tech books as a whole if very high, demand for any particular book is quite low (unless it's one of those few notable titles). It doesn't seem as if the tech book market is following the laws of supply and demand.
Actually it is. The problem is the people keep trying to compare it to the non-tech book markets. You cannot compare the market forces of "Learn Python on Two Euros a Day" to the market forces of "Murder on the Bullet Train" The tech book market is a *boutique* market. The consumers are highly selective, and willing to pay a premium for the right book. Which is good, because most tech titles don't sell well, so the margin on them is quite small. If the willingness to pay high prices weren't there, you would see lower prices, but you would also see a lot fewer titles.
I'm not. I'm starting to get tired of cult of victimization. Microsoft may be a 500 point gorilla, but it is a 500 pound gorilla that can't take your money without your permission. Since the days of the first IBM PC there have been alternative systems. Some of them, like the Mac, are even household words.
Whiner: "Microsoft doesn't give me any choice" Realist: "Get a Mac" Whiner: "But you can't build a Mac yourself" Realist: "So go build a PC *without* Microsoft!" Whiner: "But Macs are more expensive" Realist: "Go buy a Mac Mini" Whiner: "But it doesn't have the horsepower of a $3300 Alienware!"
Yes he did it. Yes he is responsible. I am not excusing anything. All I am doing is explaining how his psyche works. As an adult he has the obligation to curb and control his anti-social tendencies.
Society should never excuse criminal behavior by saying it wasn't the criminal's fault. Society should BEAT the criminal behavior out of him! Since we don't beat criminals anymore, I suppose incarceration is the next best thing.
The extremist hyperbole of the left is really starting to piss me off. Torturers used to saw off heads of dissidents while Saddam Hussein watched, yet it is the US who is accused of torture. Not once in the twenty years did the left get pissed at Saddam's torture, but just one false rumour of flushing a Koran down a toilet and all hell breaks loose. This moral equivalency is sickening. It's extemely common for leftists to say it would have been better if Saddam were still there. That's like arguing Hitler should have remained in power because some some US serviceman beat up a jew during the liberation.
I am not condoning the abusive treatment that occured at Abu Gharib, but it must be kept in proportion. It was abuse, but it was not torture. And the people who did have been punished. But the left keeps pretending that it was a policy ordered by Rumsfeld and signed by Bush, committed with bamboo shoots and rubber hoses, and that it is still occuring daily.
Free, open, unencumbered use of technology has been the baseline norm throughout most of human history.
That's not true. At one time only royalty could use a certain technology called "royal purple". And arcane webs of legal restrictionss (guild laws) on technical trades have been the norm for the past millenium. The famed reinheitsgebot, which governed German brewing and taverning for the past five hundred years, is a prime example. It said who could make beer, how to make beer, and how to sell beer. Until very recently for example, it was illegal to use artificial carbonation in German beer. Also, ship pilots zealously guarded their maps and logs, and were among the earliest supporters of IP laws.
Any time technology has threatened someone's livelihood it has been restricted, closed and encumbered. It is only in our modern era that technological progress has become a goal. And even today most people still don't like it.
You don't NEED to be rewarded, you WANT to be rewarded. That's why they call it a "risk". You are not going to get rewarded as much with free software as with proprietary, that is true, but so what? In our current environment of copyright, selling copyrighted software is a legitimate business endeavor. However, don't deny the rest of us from making and distributing free software. We might start cutting into your profits, but that's a risk you'll have to take.
the lawyer from the school said litteraly that I wasn't allowed to write GPL'd code on the school
If you signed a contract saying all code you wrote on the school belonged to the school, then he is indeed correct. You cannot license software if you are not the copyright holder. You cannot put the GPL on software if you aren't the owner of the software.
You can wrote code on the school, but you cannot license it as GPL on the school. Sheesh.
Slashdot Mirror
hell, even if you find a working "xclock" binary from that time it will be a miracle
Oh that one would be easy. Unfortunately I don't have any 1996 Linux systems sitting around or I would try it. xclock is a simple application that links to a stable and standardized API. Getting a ten year old xclock to run on a current Linux system would be a snap.
You didn't even read his post, did you? You asked him to give you an example, and he did. He did. He can take an binary from his old Slackware CD and drop it in and have it run. That is your example.
All this patent mess is Bush's fault!
It's not slow because of legacy software, it's slow because of legacy design. Windows is designed for localized single user monotasking. There's a lot of networking, multiuser and multitasking blobs and layers tacked on, but underneath it's still operating with a legacy CPM/86 mentality.
If you're only running one application, Windows is damned fast. But it starts to significantly slow down after a certain number of applications. Have an admin log in remotely for some maintenance and it starts to seriously drag. I don't have a problem with this, because I'm in the habit of keeping crap off my system tray and shutting down applications after I'm done using them. But a coworker never shuts down any application. She may have twenty or thirty different windows up on her screen, and her habit is to keep minimizing stuff until she finds what she wants. Her system is dog slow, and restoring a particular window can take two to five seconds (on a 2Ghz system).
But the exact same behavior on her Solaris workstation does not result in a slowdown. The disorganization is still there, but the cold molasses sluggishness is not.
Another example. When I compile software under Windows, that's pretty much all I can do. Every other application starts stuttering, and the whole system drags. But compiling software under my FreeBSD or OSX systems results in no noticable slowdowns. Even with three simultaneous builds going on, my FreeBSD KDE desktop is just as fast and responsive as ever.
Mac OS X is the model for this discussion...
No, this discussion is about moving Linux and Unix to the OSX model. You cannot do that because you don't have a single centrally controlled framework.
Which version of KDE do you make the core libraries? 3.5.2? What do you do when 4.0 comes out? In order not to break everyone's app bundles, you have to keep the old libraries around. Ditto for 4.1, and 4.2, and 4.3., etc, etc. Imagine doing this since KDE 1.0. And GNOME 1.0. And for all of the supplemental libraries they use. And for glibc (which breaks compatibility ever other release even though it's the closest thing to a stable API Linux has). That starts adding up to a LOT of disk space.
Application bundles work for OSX because Apple retains firm control over all aspects of the core system. The core system libraries come from *Apple*, not from third parties. It can force its own developers to retain API compatibility, but it has no say over what KDE, GNOME, GTK+, Qt, or glibc developers can do.
That's one disadvantage to Free Software. But it is made up with many many advantages. Our trains may not run on time, but that's because we have more than one train.
Why should they care if they have enough disk space and RAM to hold both versions of KDE?
Both versions? You're talking about every KDE version since 1.0! And not just the KDE libraries, but all the Qt and miscellaneous support libraries as well. Oh, and all the various glibc versions as well (they tend to break compatibility every other release). Since they are user downloaded app bundles residing in user home directories, the system cannot upgrade them. You don't know what the user has so you have to assume they have something old. It's very bad form to break applications just because you did an automatic system software update.
You mean like when OS X 10.1, 10.2, 10.3, and 10.4 came out?
That's not a problem, because Apple is in firm control of the system libraries, and more importantly, in control of the system APIs. Not being a free operating system, it doesn't have to worry about several dozen fundamental third party system libraries.
But what libraries do you standardize on? And once you standardize, how do you upgrade to a newer version? For example, currently KDE uses Qt 3.3.x. If Linux is "standardized" on 3.3.5, what happens when KDE 4.0 comes out which will use Qt 4.1.x? Neither version is compatible with the other. Do you put KDE on hold for two years while the bureaucratic standards committee argues over this? Do you tell Trolltech they can never change their API because it's been standardized?
Even if you keep the app bundle concept in a specific distro (which every distro is free to do), there's still no way to easily upgrade an individual application bundle. Which means you have to keep older libraries around forever. You have to keep them around or the users' applications will break when you upgrade the base system. In the case of KDE, that's dozens of gigabytes of old library versions since the 1.0 days.
A proprietary (in the sense that the system is controlled by a single entity) operating system does not have this problem because it can control the APIs for the system libraries. You cannot do this with free operating systems.
A package manager avoids all these problems, without adding any burden to the user.
You can see the product here: http://www.nexdisk.com/e_index.asp. Specifically it's a 128Mb USB 1.1 Nexdisk thumbdrive. There is nothing wrong with it, and it works flawlessly on all Linux, FreeBSD, OSX, Windows98, and (most) Windows XP systems. But because of a driver conflict on the developer's workstations at work, it will crash those particular systems. A few other USB drives would crash them as well. In addition, for USB drives that work, you still have to plug them in, then unplug them, then plug them in again, before you can access them.
Remember, this isn't a Linux distro
But this is what people here on this thread want Linux distros to be. The app bundle concept works ONLY because OSX is a closed an centrally controlled system. There are solutions much more appropriate to free and open systems, such as package managers (a concept, btw, the Apple uses to distribute all of its own software).
My god! That will use up megabytes of disk space!
Let's take an example desktop and examine it to see how much diskspace it would take. Let's consider the the mythical GDE desktop. It uses the GDE libraries which in turn use the QTK+ library. It also uses about a dozen other minor libraries. This is not counting the various specialized libraries that individual GDE apps might use (like libbrainz). Also, there are fifty applications and utilities in the "core" GDE distribution.
All numbers are examples pulled out of my ass:
GDE application: 5Mb
GDE libraries: 15Mb
QTK+ library: 10Mb
Supplemental libraries: 10Mb
Total app bundle size: 40Mb
Total GDE installation size: 2000MB
That's not that horrible considering the size of today's harddrives, but it's wasteful nonetheless. Consider a system that uses shared libraries instead, and it only takes up 285Mb. That's a huge difference.
I don't know what the numbers would be with real KDE or GNOME desktop, but I greatly suspect my numbers are pitifully low. This is why Apple, yes Apple, uses shared libraries for every piece of software it distributes.
Thus, if an application wants an "obscure" library and decides to bundle it, the cost to the system is minimal even if another app has the same one. The MacOS bundle is not at all the equivalent of statically linking against gtk and other "fundamental" libraries in Linux.
That's because OSX is a closed system, whose "fundamental" libraries are defined by Apple. Linux and BSD cannot do this because they are open. What do you do if the system has all the KDE 3.4 libraries installed, but you want to run a KDE 3.5.1 application? Or worse yet, how do you upgrade without a package manager when KDE 4.0 comes out?
No one here has cojones large enough to tell EVERY ONE of the thousand or so "fundamental" libraries that their APIs are static and frozen. Hell, KDE and GNOME can't even do that within the KDE and GNOME projects!
That's why app bundles won't work under free Linux and BSD systems. But it won't matter because package managers are a better solution.
Sorry, that's not the equivalent. Not even close.
...and was secretly hoping that Linux wold catch up with it's own version and take-off.
Except that Linux (and Unix in general) doesn't need it. Most package managers are extremely simple to use. Download package, double click on package, done.
The app bundle concept is nice, but it has several problems. First of all it's wasteful. Imagine every KDE application being an app bundle with their own private copies of all the KDE libraries. Second, it's more difficult to run the app bundles from scripts (most end users won't care, but most admins will). Third, you STILL have to sudo to root and install in the system wide Applications directory if you want more than one person to use the software. Fourth, this works on OSX because you have a comprehensive set of standard system libraries, something that Linux does not have. Everything that isn't glibc has to go into the app bundle. Finally, app bundles are only application for standalone applications. They don't make sense for services, daemons, and the like.
A good package manager, on the other hand, will automatically deal with dependencies. A good front end integrated into the desktop makes it a snap to use. It has the added bonus of providing a simple software upgrade path, something I've seen break in OSX in a couple of cases.
OSX has a package manager which Apple uses for ALL of its software. iTunes isn't an app bundle. If package managers are good enough for Apple, they're good enough for everyone.
Unless you don't hate Bill Gates or George Bush...
You're assuming the Windows user has all of the required drivers and shit available on CDs somewhere. Lose those and suddenly even OpenBSD starts to look like an easy install for my Grandma! If you're building your own system instead of reinstalling on an OEM system, Linux and BSD can actually be easier to install. In my own experience installing FreeBSD and Gentoo on my old HP laptop was a snap compared to Windows XP, since I had lost the laptop's recovery CD.
When the Windows install works, it's easy. When it doesn't it's incredibly difficult.
I have a USB thumbdrive that will crash Windows XP on every developer's workstation at my company every time it is plugged in.
People paying some attention to the Vista development may notice that during build 5000, Microsoft did basically a 180 turn and decided to throw out the new foundation of managed (.NET) code on an XP SP2 based kernel, and rather go with the Windows Server 2003 kernel.
:-)
That how large corporations work. Not only do they eat their own dog food, they pretend it's filet mignon. The politics of using an in-house tool are such that the decision cannot be questioned until it's evident that it is severely delaying the product. And even then the messenger of the bad news will still get canned.
My company decided all of our new products would incorporate a framework done by a different division. At the time we were the market leader, two years ahead of our competitors' ability to catch up. But we weren't given the option of looking elsewhere for this functionality, we were told to use it and not to question it. When the CEO, VP and director of software decided to incorporate the framework in "stages" over the span of two different product releases, all three got canned. It is now four years later, we still don't have a new product out, and it will take us at least two years to catch up to our competition. We are now in permanent "survival mode", as we keep adding cosmetic quick fixes to our legacy products in the hopes of retaining our market share.
No, as much as it sounds, I do NOT work for Microsoft
But the eagles would have made a great diversion while the budgie drops the ring in...
The simple answer is high demand and low supply. But a closer look reveals that this isn't necessarily the case. Supply is actually very high, and the market nearly saturated. And while demand for tech books as a whole if very high, demand for any particular book is quite low (unless it's one of those few notable titles). It doesn't seem as if the tech book market is following the laws of supply and demand.
Actually it is. The problem is the people keep trying to compare it to the non-tech book markets. You cannot compare the market forces of "Learn Python on Two Euros a Day" to the market forces of "Murder on the Bullet Train" The tech book market is a *boutique* market. The consumers are highly selective, and willing to pay a premium for the right book. Which is good, because most tech titles don't sell well, so the margin on them is quite small. If the willingness to pay high prices weren't there, you would see lower prices, but you would also see a lot fewer titles.
(just kidding btw)
I'm not. I'm starting to get tired of cult of victimization. Microsoft may be a 500 point gorilla, but it is a 500 pound gorilla that can't take your money without your permission. Since the days of the first IBM PC there have been alternative systems. Some of them, like the Mac, are even household words.
Whiner: "Microsoft doesn't give me any choice"
Realist: "Get a Mac"
Whiner: "But you can't build a Mac yourself"
Realist: "So go build a PC *without* Microsoft!"
Whiner: "But Macs are more expensive"
Realist: "Go buy a Mac Mini"
Whiner: "But it doesn't have the horsepower of a $3300 Alienware!"
He did it. He is responsble. End of story.
Yes he did it. Yes he is responsible. I am not excusing anything. All I am doing is explaining how his psyche works. As an adult he has the obligation to curb and control his anti-social tendencies.
Society should never excuse criminal behavior by saying it wasn't the criminal's fault. Society should BEAT the criminal behavior out of him! Since we don't beat criminals anymore, I suppose incarceration is the next best thing.
The extremist hyperbole of the left is really starting to piss me off. Torturers used to saw off heads of dissidents while Saddam Hussein watched, yet it is the US who is accused of torture. Not once in the twenty years did the left get pissed at Saddam's torture, but just one false rumour of flushing a Koran down a toilet and all hell breaks loose. This moral equivalency is sickening. It's extemely common for leftists to say it would have been better if Saddam were still there. That's like arguing Hitler should have remained in power because some some US serviceman beat up a jew during the liberation.
I am not condoning the abusive treatment that occured at Abu Gharib, but it must be kept in proportion. It was abuse, but it was not torture. And the people who did have been punished. But the left keeps pretending that it was a policy ordered by Rumsfeld and signed by Bush, committed with bamboo shoots and rubber hoses, and that it is still occuring daily.
Free, open, unencumbered use of technology has been the baseline norm throughout most of human history.
That's not true. At one time only royalty could use a certain technology called "royal purple". And arcane webs of legal restrictionss (guild laws) on technical trades have been the norm for the past millenium. The famed reinheitsgebot, which governed German brewing and taverning for the past five hundred years, is a prime example. It said who could make beer, how to make beer, and how to sell beer. Until very recently for example, it was illegal to use artificial carbonation in German beer. Also, ship pilots zealously guarded their maps and logs, and were among the earliest supporters of IP laws.
Any time technology has threatened someone's livelihood it has been restricted, closed and encumbered. It is only in our modern era that technological progress has become a goal. And even today most people still don't like it.
You don't NEED to be rewarded, you WANT to be rewarded. That's why they call it a "risk". You are not going to get rewarded as much with free software as with proprietary, that is true, but so what? In our current environment of copyright, selling copyrighted software is a legitimate business endeavor. However, don't deny the rest of us from making and distributing free software. We might start cutting into your profits, but that's a risk you'll have to take.
the lawyer from the school said litteraly that I wasn't allowed to write GPL'd code on the school
If you signed a contract saying all code you wrote on the school belonged to the school, then he is indeed correct. You cannot license software if you are not the copyright holder. You cannot put the GPL on software if you aren't the owner of the software.
You can wrote code on the school, but you cannot license it as GPL on the school. Sheesh.