Again, I think that you don't understand the way that package managers (or binary loaders) work.
Package managers build the vast majority of their dependency information automatically. That is, if you download a package for mini-commander, and your package manager it depends on 12 things that you haven't got, it's not because the human packaging the software said so, it's because the package management software examined the binaries that were compiled and found those libraries to be required. And it will be *correct*. Forcing the install will not work because you will be missing libraries or symbols that are required, and the application will either crash "randomly" or not start up at all.
The "options" you list are incorrect. You should never consider a forced install to be an option unless you understand *why* the dependency exists and are *sure* you don't need it. This is unlikely to be the case unless you are a developer yourself. You have an option that will both provide you a working package and maintain the accuracy of your package database. It's a source package. If, for instance, you had an i386.rpm file that wouldn't install because of missing dependencies, then you can get the src.rpm from the distributor of the i386.rpm file and rebuild it like this:
rpm --rebuild mini-commander-0.4.2.src.rpm
The package will be built, and an i386.rpm file will result. Having been built on your system, all of the dependencies will match what you have on your system, and you will be able to install it without forcing the install.
The same things are true in reverse. That is, packagers can't compile against a "lowest version available", because in unstable packages the API changes. Compiling against an old version of a library would create a dependency on an old library, and objects or symbols may be missing on newer systems. Only when library interfaces are *stable* can you expect not to have this problem. Unfortunately, some of the libraries that GNOME applications (and it sure seems like you're talking about GNOME) don't have a stable API. Until they do, they will continue to be a headache for users. Don't blame the package managers. They aren't the problem. Distribution developers aren't doing this intentionally.
But you can't upgrade your Perl because it's tied into everything Potato in your distro.
Comments like this display a serious lack of understanding about package management.
Perl isn't a good example for this one, because the only thing that's *really* going to depend on a specific version of Perl is Perl modules, but we know where you're going with this.
Lets say instead that you needed to upgrade to a newer version of OpenSSL, because... oh, I dunno, maybe mod_ssl complains that yours is buggy. With a package manager, you would get the packages for apache, mod_ssl, and the newer OpenSSL, and tell it to update everything. If anything depended on that specific version of OpenSSL, the package manager would tell you so that you could update those packages as well, and avoid breaking your sytem. If your system lacks package management, then you would probably go right ahead and compile and update apache, mod_ssl, and OpenSSL. But, guess what?
YOUR SYSTEM, THOUGH LACKING A PACKAGE MANAGER, STILL HAS DEPENDENCIES!!!
That's right. The system with a package manager warned you what you were going to break to stop you from breaking them. The system without the package manager let you break them without any warning, and now all of the same packages that you would have been warned about are totally FUCKED. The lack of a package manager hasn't saved you any work. You STILL have to update every one of them. The difference is that you won't *know* that you need to update them until you see them break. That can be a serious problem. How do you fix a server in a remote location when you just upgraded openssl and SCREWED ssh?
There may be times when package management seems like a pain in the ass, but the alternative is *so* much worse.
Saying that "wine doesn't run on PowerPC" is close to the truth, but little informed. The wine application would be useless on the PowerPC platform, because wine was written to emulate the Win32 API, not the x86 CPU. Therefore if you were to build wine on PowerPC, it wouldn't do anything useful because you probably don't have any Win32 software compiled for PowerPC laying around. However, winelib (the core of wine) *can* be used to port Win32 software to the PowerPC platform. You would compile winelib on PowerPC, then compile your Win32 app on PowerPC. You've ported with a minimum of effort. This is what the original poster was suggesting. That MS could use winelib to port their Win32.NET platform to UNIX like platforms without rewriting everything.
The point that OS X doesn't use X Windows is totally valid. Porting the.NET GUI API to BSD would give them almost no leverage in porting to OS X. In order to port to OS X, they'd still have to do a *lot* of work to port the winelib GUI code to the Cocoa API.
Secondly, this is exactly the point of high(er) level languages: To eliminate details that are better solved by the machine, or previously by someone else.
Yes, it is, but I question whether schools should make programming too much like driving. Consider this: drivers who understand the workings of their cars are always better drivers than drivers who understand "wheel turn, gas go." Drivers who understand how the car works understand why you don't accelerate the car by flooring the gas pedal. They know why you change your oil periodically. Their cars last longer and work better.
So it is with programmers. Those who know how the machine works know why memory allocation is slow, and reusing blocks of memory is faster than allocating new ones. Those who understand the preprocessor know why defining a frequenly used value or code block will produce faster code than those who only know object fields and functions. People who understand low level operations recognise good programming practice better than those with experience only in high level language because they've had to. Their code is more reusable, more readable, faster, and less prone to bugs.
You have your analogy all backwards. The parent post was absolutely not advocating any course of action based on it's relative simplicity.
Assembly programming is like adding single digits. It's very low level. You're learning exactly what happens at the very foundation of all of the things you will go on to learn.
High level programming languages are like Calculus. It's high level. The purpose of high level operations is not to iterate through the low level operations ad nauseum. Calculus is really just a bunch of addition and subtraction expressed in a very consice manner.
Teaching calculus or high level languages to people who don't have any background with lower level operations will always produce inferior skills than the oposite.
All of the activity that's been going on in the PS2 camp of late has me sort of wondering... We've seen Linux support released, and read about Real Player, Netscape, Java and AOL coming to PS2.
So the question is this: What market is the PS2 in really? It's expanding well outside of the realm of our classic definition of a game console, deep into the territory of our PC's. But, OTOH, it doesn't suffer the clunky UI problems that our classic PC's face either. Is it a PC without the baggage of backward compatibility? Many people have thought about redesigning the PC's hardware and software from scratch to take full advantage of current technology; is the PS2 the fulfillment of that goal? If... no, when the PS2 is capable of all of the entertainment functions that we currently use our PC's for, what will the average family need a computer for?
Now, consider that this is the reason that MS is throwing in its Xbox...
If you find a buffer overflow in the current version of qmail that can give a remote intruder a shell, I'll suck your dick! That was totally unnecessary. I was trying to make a point, not issue a challenge.
You can read my reply to the original poster here:
http://slashdot.org/comments.pl?sid=01/05/30/124 25 5&cid=387
DJB's software is free in every sense of the word. Except the sense that matters to Free Software developers and the Free Sofware Foundation. Every other sense, maybe. Free Software developers value the freedom to modify Free Software and share those modifications with others, without restrictions. qmail doesn't give you that freedom. You are restricted from forking or distributing modified source or binaries. That means that qmail and djbdns DO NOT meet the Free Software guidelines. See http://www.fsf.org/philosophy/free-sw.html
Ask Debian why they don't distribute DJB's software. Ask Red Hat why they don't. DJB's software ISN'T FREE.
The GPL is certainly less restrictive than the distribution terms for qmail/djbdns. The GPL mandates only that you not deprive others of the freedoms that you have. DJB doesn't give you those freedoms to begin with.
See my reply at: http://slashdot.org/comments.pl?sid=01/05/30/12425 5&cid=387
You can't distribute modifies source, either. You can only distribute the original, unmodified source, binaries created from the original, unmodified source, and patches. That makes qmail/djbdns 100% not Free Software.
OK, but lets take this in context... The post to which you replied claimed that packages such as BIND, postfix and sendmail are more free than Qmail (and djbdns), claiming that the license of the latter prevents redistribution. From a commercial distributors' perspective, this it totally true. When the original poster made his statement, this is the meaning that I got from it, dunno about you.
You're absolutely right. DJB specifially allows you to do whatever you want with your own personal copy of qmail or djbdns. However, the original poster is not "so wrong about djbdns". His point is totally valid. The GPL and BSD licenses specifically allow you *all* of the freedoms that the original author had. DJB's software takes away your freedom. With sendmail/bind/postfix, you are free to distribute modified binaries. With djbdns/qmail you are not.
Sure, you COULD write your own code, but that just defeats the purpose of opensource
You are obviously confused. The GPL is not about "Open Source". The GPL is about Free Software. The point is to make sure that the software and any derivitave works are Free. Nowhere will you find any evidence that the GPL is about saving you (a developer) any work at all, if your software is not Free.
The point of the BSD license is open source and reuse. The point of the GPL is not.
You can copy and hack the source as much as you like
No, you can't. The distribution terms (aka: LICENSE) specifically state that you can not. As you said yourself, the distributed binaries must operate the same as the originals. That prevents patching. If, for instance, I patch qmail to write localtime rather than UTC in the headers, I can no longer distribute qmail, because its behavior has changed. If I patch qmail against a buffer overflow that gives remote intruders a shell, I can't distribute that package; it no longer operates the same as if my users had downloaded and compiled DJB's source.
Read the FAQ again. If you still don't get it, read it twice. You can not distribute modified binaries. If you think otherwise, prove it.
OK, so I followed your link and I see that "corporatism" is politics made and enforced by business. Isn't that what we're seeing, though? Take the DMCA. Who enacted this crap? Business. They caried it through our political system, so it's not a *direct* corporatism, but the law was still enacted by businesses for the benefit of businesses the way that I see it. If it sounds like a duck...
Seriously, I think Katz is correct to use the term "corporatism".
This shouldn't be a difficult issue to resolve. Just pose two questions to your managers and see if they will reconsider:
1: Will the change improve their core competency?
2: Will the change enhance their revenue?
My experience with managers in companies large and small is that if neither of those two questions can be answered "yes", then that alone will prevent any change from happening. Change costs money. If change won't make money, it won't happen.
If the lack of good reasons doesn't stop the proposed change, argue (as I'm sure you would) that it will hurt morale and productivity. Write up a petition of protest, and have your coworkers sign it. I don't know where to find any studies suggesting increased productivity in comfortable settings, but they can't be hard to find. I even recall one that suggested that students are more apt to learn if they're reclining than if they're sitting in uncomfortable desks. I spent some time working from home, and I accomplished *easily* four times as much per day as when I was working in the office (and I've got LOC counts to back it up).
What's the point? What I mean is, who would use a license like this? (I don't even understand why the Open Group does.) There are already licenses available, and in widespread use, that accomplish the goals of widespread free use and Free Software.
If you want the library to be totally open and free, use the BSD license. The BSD license and its users are all about code reuse, without regard to the manner or environment in which it's used. Free Software or proprietary, it's all OK.
If you want to allow the library to be used by Free Software developers, and still license it to proprietary developers for profit, use the GPL, ala Troll Tech. The GPL version could only be used for Free Software (that is, licensed under a GPL compatible license), but you as the developer would still be free to license the library to proprietary vendors for use in their proprietary products.
Using GPL, "large proprietary commercial empires" are already unable to "roll a truly Free piece of software into their commercial apps" or "snuff out a grass-roots open project".
Restricting the *use* of software/libraries is outside the scope of both licenses, as it should be.
does that mean... you're bound by joe schmoe license that i invented c under??
Yes. If you design a language, and place a restrictive license on it, then the people who use *your product* are bound by your license. (Although, some people may be legally allowed to reverse engineer the software) Additionally, if your language is an open specification, and you write documentation for the language that includes example code, then you may place a license on those examples. (A *lot* of docs are written this way, unfortunately) People who read your documentation are bound by the license of the example code.
If i read the source code to... diablo 2... can blizzard bust my balls cause i figured out how they did something and put it into my game? Yes. Yes they can. That's what copyright protects. That's why proprietary software engineers are generally required to stay the hell away from Free Software code, and Free Software engineers don't read proprietary code.
As an example, you won't find the Wine project accepting code from former Microsoft employees, because if those people violate the license used by their former employer, Wine as a whole may be judged to be in violation.
From the first section of the GPL, describing the intent of the license:
...a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another
language
Reading itself is not covered per se, but application of that "algorythm/way of doing it" legally constitutes a derivative work. That means that if you read GPL code to see how a thing is done, the code you write to mimick it must be GPLed itself.
He's not talking about copying the code in the sense of "cp gpl.c mynew.c", but he's copying the code all the same.
If you read code to learn from it, you're memorizing someone else's code. Applying that code to your product later may not be copying the code verbatim, but it's copying all the same. If the author of the original code can prove that you've done this (this applies to code under *any* license), then they can pursue the same legal recourse as if you'd used the original code directly.
merely because I viewed some GPL source It's not viewing the GPL'd source that will get you in trouble, it's copying it.
The thing is, if you read someone's code and copy it into your application using your memory as the medium, that's legally the same as just electronically copying the file.
In other words, if you read someone's source code, you're probably bound by the license of said code. Applying their solution to your product, whether you copy it by mind or by wire, is governed by the same licenses.
I understand, BTW, that Microsoft programmers are explicitly forbidden by their management from reading the code to any GPL products to avoid this problem.
Your link isn't to a "more accurate story", it points to a story about an entirely different crash! The story on xbox.com was written prior to E3 (see the beginning of the last paragraph), while the story on thegia.com is about a crash that happened *during* E3, almost a month later.
Do I think it's unreasonable for the box to crash? Maybe not, but at this point, late in the develpment, it sure doesn't bode well for the release of the product, does it?
Take those informative moderation points and put them where they belong... On informative (and correct) posts:-)
How so? Well, I ran Win2k at home on a box whose purpose was only playing games and viewing multimedia, with an Nvidia card. Sounds a lot like the Xbox, doesn't it? That box crashed about every other day, making Win98 more that 50 times as stable (it crashed about every two months). I originally installed Win2k because I thought I might end up doing development, but I'm not. (Not on Windows, anyway). After putting up with it for about a month and a half, my girlfriend asked me to remove it. These numbers are accurate for this installation. I've kept track because I was curious.
I'm glad Win2k is stable for you. I'd heard that it was for a lot of people, which is one of the reasons that I installed it. However, for a gaming platform, it's not even close to stable. NVidia better come out with a damn good driver for the Xbox, cuz the latest *stable* driver on their site ate my balls. At this rate, the Xbox is going to ruin a lot of otherwise good games.
His statement implied that the Xboxen had the idea that they had more memory than they really did, as if MS had told the kernel that it had 256MB of RAM, but only given it 128. This is not the case. There is no way that those machines crashed because they were trying to access "non-existant memory" except by plain old (and I'm talking OLD) Microsoft style bugs.
While you _can_ tell Linux that it has more RAM than it does, the result will not be what the previous poster implied. Linux will not boot if you lie to it.
one sentance about the X-Box crashing I don't know about you, but one crash is about all I need. Seems to me that Microsoft products seem to crash in just about every public demo that I actually attend or hear about.
namely lacking memory Now, the rep. said that the memory configuration will be different. He did not say that the final Xbox will have more memory. Since the Xbox has been switched to an Intel CPU, I'm guessing that either he meant something related to RAMBUS/SDRAM, or he was just plain spin doctoring. I'm inclined to beleive the latter, since his statement was so vague.
if I tell the kernel it has 256MB Totally m00t point. You can't *tell* the 2000 kernel how much memory the system has. You obviously know nothing about kernel design. Stop and think about this for a moment. The hecklers aren't really being immature about this, they're pointing out that their suspicions all along that the Xbox would just be another crashy MS PC are right. If this crash were due to a missing piece of hardware, they all would have crashed. Maturity has nothing to do with deriding the Xbox. What do you expect us to do? Ignore it? Buy the Xbox because Bill tells us to? Screw that. I want hardware (and software) with a proven record of stability and quality. The Xbox has neither of those. Intel/RAMBUS has had serious stability issues. Windows 2000 has serious stability issues. The Xbox has been demonstrated to be instable. Conclusion: I'm not buying one! If I did, it wouldn't be a console, it would be a Linux PC that MS generously paid most of the cost for. (If MS wants to buy me a Linux capable PC with a sweet video card to repay me for the trouble they've caused, who am I to argue!?)
As an aside, if you lie to Linux, and tell it that it has more RAM than it does, it won't complete booting. You can't break Linux this way.
Slashdot Mirror
Again, I think that you don't understand the way that package managers (or binary loaders) work.
Package managers build the vast majority of their dependency information automatically. That is, if you download a package for mini-commander, and your package manager it depends on 12 things that you haven't got, it's not because the human packaging the software said so, it's because the package management software examined the binaries that were compiled and found those libraries to be required. And it will be *correct*. Forcing the install will not work because you will be missing libraries or symbols that are required, and the application will either crash "randomly" or not start up at all.
The "options" you list are incorrect. You should never consider a forced install to be an option unless you understand *why* the dependency exists and are *sure* you don't need it. This is unlikely to be the case unless you are a developer yourself. You have an option that will both provide you a working package and maintain the accuracy of your package database. It's a source package. If, for instance, you had an i386.rpm file that wouldn't install because of missing dependencies, then you can get the src.rpm from the distributor of the i386.rpm file and rebuild it like this:
rpm --rebuild mini-commander-0.4.2.src.rpm
The package will be built, and an i386.rpm file will result. Having been built on your system, all of the dependencies will match what you have on your system, and you will be able to install it without forcing the install.
The same things are true in reverse. That is, packagers can't compile against a "lowest version available", because in unstable packages the API changes. Compiling against an old version of a library would create a dependency on an old library, and objects or symbols may be missing on newer systems. Only when library interfaces are *stable* can you expect not to have this problem. Unfortunately, some of the libraries that GNOME applications (and it sure seems like you're talking about GNOME) don't have a stable API. Until they do, they will continue to be a headache for users. Don't blame the package managers. They aren't the problem. Distribution developers aren't doing this intentionally.
But you can't upgrade your Perl because it's tied into everything Potato in your distro.
Comments like this display a serious lack of understanding about package management.
Perl isn't a good example for this one, because the only thing that's *really* going to depend on a specific version of Perl is Perl modules, but we know where you're going with this.
Lets say instead that you needed to upgrade to a newer version of OpenSSL, because... oh, I dunno, maybe mod_ssl complains that yours is buggy. With a package manager, you would get the packages for apache, mod_ssl, and the newer OpenSSL, and tell it to update everything. If anything depended on that specific version of OpenSSL, the package manager would tell you so that you could update those packages as well, and avoid breaking your sytem. If your system lacks package management, then you would probably go right ahead and compile and update apache, mod_ssl, and OpenSSL. But, guess what?
YOUR SYSTEM, THOUGH LACKING A PACKAGE MANAGER, STILL HAS DEPENDENCIES!!!
That's right. The system with a package manager warned you what you were going to break to stop you from breaking them. The system without the package manager let you break them without any warning, and now all of the same packages that you would have been warned about are totally FUCKED. The lack of a package manager hasn't saved you any work. You STILL have to update every one of them. The difference is that you won't *know* that you need to update them until you see them break. That can be a serious problem. How do you fix a server in a remote location when you just upgraded openssl and SCREWED ssh?
There may be times when package management seems like a pain in the ass, but the alternative is *so* much worse.
Saying that "wine doesn't run on PowerPC" is close to the truth, but little informed. The wine application would be useless on the PowerPC platform, because wine was written to emulate the Win32 API, not the x86 CPU. Therefore if you were to build wine on PowerPC, it wouldn't do anything useful because you probably don't have any Win32 software compiled for PowerPC laying around. However, winelib (the core of wine) *can* be used to port Win32 software to the PowerPC platform. You would compile winelib on PowerPC, then compile your Win32 app on PowerPC. You've ported with a minimum of effort. This is what the original poster was suggesting. That MS could use winelib to port their Win32 .NET platform to UNIX like platforms without rewriting everything.
.NET GUI API to BSD would give them almost no leverage in porting to OS X. In order to port to OS X, they'd still have to do a *lot* of work to port the winelib GUI code to the Cocoa API.
The point that OS X doesn't use X Windows is totally valid. Porting the
Secondly, this is exactly the point of high(er) level languages: To eliminate details that are better solved by the machine, or previously by someone else.
Yes, it is, but I question whether schools should make programming too much like driving. Consider this: drivers who understand the workings of their cars are always better drivers than drivers who understand "wheel turn, gas go." Drivers who understand how the car works understand why you don't accelerate the car by flooring the gas pedal. They know why you change your oil periodically. Their cars last longer and work better.
So it is with programmers. Those who know how the machine works know why memory allocation is slow, and reusing blocks of memory is faster than allocating new ones. Those who understand the preprocessor know why defining a frequenly used value or code block will produce faster code than those who only know object fields and functions. People who understand low level operations recognise good programming practice better than those with experience only in high level language because they've had to. Their code is more reusable, more readable, faster, and less prone to bugs.
You have your analogy all backwards. The parent post was absolutely not advocating any course of action based on it's relative simplicity.
Assembly programming is like adding single digits. It's very low level. You're learning exactly what happens at the very foundation of all of the things you will go on to learn.
High level programming languages are like Calculus. It's high level. The purpose of high level operations is not to iterate through the low level operations ad nauseum. Calculus is really just a bunch of addition and subtraction expressed in a very consice manner.
Teaching calculus or high level languages to people who don't have any background with lower level operations will always produce inferior skills than the oposite.
Nitpick: 600mm by 700mm is less than a half a meter squared. .42 meters squared, actually.
Is a mexapixel anything like those Taco Bell Mexi-Fries? I hate those things...
All of the activity that's been going on in the PS2 camp of late has me sort of wondering... We've seen Linux support released, and read about Real Player, Netscape, Java and AOL coming to PS2.
So the question is this: What market is the PS2 in really? It's expanding well outside of the realm of our classic definition of a game console, deep into the territory of our PC's. But, OTOH, it doesn't suffer the clunky UI problems that our classic PC's face either. Is it a PC without the baggage of backward compatibility? Many people have thought about redesigning the PC's hardware and software from scratch to take full advantage of current technology; is the PS2 the fulfillment of that goal? If... no, when the PS2 is capable of all of the entertainment functions that we currently use our PC's for, what will the average family need a computer for?
Now, consider that this is the reason that MS is throwing in its Xbox...
hahaha... If I had moderator points, this would be marked "Funny" right now.
If you find a buffer overflow in the current version of qmail that can give a remote intruder a shell, I'll suck your dick!
4 25 5&cid=387
That was totally unnecessary. I was trying to make a point, not issue a challenge.
You can read my reply to the original poster here:
http://slashdot.org/comments.pl?sid=01/05/30/12
DJB's software is free in every sense of the word.
Except the sense that matters to Free Software developers and the Free Sofware Foundation. Every other sense, maybe. Free Software developers value the freedom to modify Free Software and share those modifications with others, without restrictions. qmail doesn't give you that freedom. You are restricted from forking or distributing modified source or binaries. That means that qmail and djbdns DO NOT meet the Free Software guidelines. See http://www.fsf.org/philosophy/free-sw.html
Ask Debian why they don't distribute DJB's software. Ask Red Hat why they don't. DJB's software ISN'T FREE.
The GPL is certainly less restrictive than the distribution terms for qmail/djbdns. The GPL mandates only that you not deprive others of the freedoms that you have. DJB doesn't give you those freedoms to begin with.
See my reply at: http://slashdot.org/comments.pl?sid=01/05/30/12425 5&cid=387
You can't distribute modifies source, either. You can only distribute the original, unmodified source, binaries created from the original, unmodified source, and patches. That makes qmail/djbdns 100% not Free Software.
OK, but lets take this in context... The post to which you replied claimed that packages such as BIND, postfix and sendmail are more free than Qmail (and djbdns), claiming that the license of the latter prevents redistribution. From a commercial distributors' perspective, this it totally true. When the original poster made his statement, this is the meaning that I got from it, dunno about you.
You're absolutely right. DJB specifially allows you to do whatever you want with your own personal copy of qmail or djbdns. However, the original poster is not "so wrong about djbdns". His point is totally valid. The GPL and BSD licenses specifically allow you *all* of the freedoms that the original author had. DJB's software takes away your freedom. With sendmail/bind/postfix, you are free to distribute modified binaries. With djbdns/qmail you are not.
Sure, you COULD write your own code, but that just defeats the purpose of opensource
You are obviously confused. The GPL is not about "Open Source". The GPL is about Free Software. The point is to make sure that the software and any derivitave works are Free. Nowhere will you find any evidence that the GPL is about saving you (a developer) any work at all, if your software is not Free.
The point of the BSD license is open source and reuse. The point of the GPL is not.
You can copy and hack the source as much as you like
No, you can't. The distribution terms (aka: LICENSE) specifically state that you can not. As you said yourself, the distributed binaries must operate the same as the originals. That prevents patching. If, for instance, I patch qmail to write localtime rather than UTC in the headers, I can no longer distribute qmail, because its behavior has changed. If I patch qmail against a buffer overflow that gives remote intruders a shell, I can't distribute that package; it no longer operates the same as if my users had downloaded and compiled DJB's source.
Read the FAQ again. If you still don't get it, read it twice. You can not distribute modified binaries. If you think otherwise, prove it.
OK, so I followed your link and I see that "corporatism" is politics made and enforced by business. Isn't that what we're seeing, though? Take the DMCA. Who enacted this crap? Business. They caried it through our political system, so it's not a *direct* corporatism, but the law was still enacted by businesses for the benefit of businesses the way that I see it. If it sounds like a duck...
Seriously, I think Katz is correct to use the term "corporatism".
This shouldn't be a difficult issue to resolve. Just pose two questions to your managers and see if they will reconsider:
1: Will the change improve their core competency?
2: Will the change enhance their revenue?
My experience with managers in companies large and small is that if neither of those two questions can be answered "yes", then that alone will prevent any change from happening. Change costs money. If change won't make money, it won't happen.
If the lack of good reasons doesn't stop the proposed change, argue (as I'm sure you would) that it will hurt morale and productivity. Write up a petition of protest, and have your coworkers sign it. I don't know where to find any studies suggesting increased productivity in comfortable settings, but they can't be hard to find. I even recall one that suggested that students are more apt to learn if they're reclining than if they're sitting in uncomfortable desks. I spent some time working from home, and I accomplished *easily* four times as much per day as when I was working in the office (and I've got LOC counts to back it up).
What's the point? What I mean is, who would use a license like this? (I don't even understand why the Open Group does.) There are already licenses available, and in widespread use, that accomplish the goals of widespread free use and Free Software.
If you want the library to be totally open and free, use the BSD license. The BSD license and its users are all about code reuse, without regard to the manner or environment in which it's used. Free Software or proprietary, it's all OK.
If you want to allow the library to be used by Free Software developers, and still license it to proprietary developers for profit, use the GPL, ala Troll Tech. The GPL version could only be used for Free Software (that is, licensed under a GPL compatible license), but you as the developer would still be free to license the library to proprietary vendors for use in their proprietary products.
Using GPL, "large proprietary commercial empires" are already unable to "roll a truly Free piece of software into their commercial apps" or "snuff out a grass-roots open project".
Restricting the *use* of software/libraries is outside the scope of both licenses, as it should be.
does that mean ... you're bound by joe schmoe license that i invented c under??
Yes. If you design a language, and place a restrictive license on it, then the people who use *your product* are bound by your license. (Although, some people may be legally allowed to reverse engineer the software) Additionally, if your language is an open specification, and you write documentation for the language that includes example code, then you may place a license on those examples. (A *lot* of docs are written this way, unfortunately) People who read your documentation are bound by the license of the example code.
If i read the source code to... diablo 2... can blizzard bust my balls cause i figured out how they did something and put it into my game?
Yes. Yes they can. That's what copyright protects. That's why proprietary software engineers are generally required to stay the hell away from Free Software code, and Free Software engineers don't read proprietary code.
As an example, you won't find the Wine project accepting code from former Microsoft employees, because if those people violate the license used by their former employer, Wine as a whole may be judged to be in violation.
From the first section of the GPL, describing the intent of the license:
...a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another
language
Reading itself is not covered per se, but application of that "algorythm/way of doing it" legally constitutes a derivative work. That means that if you read GPL code to see how a thing is done, the code you write to mimick it must be GPLed itself.
He's not talking about copying the code in the sense of "cp gpl.c mynew.c", but he's copying the code all the same.
If you read code to learn from it, you're memorizing someone else's code. Applying that code to your product later may not be copying the code verbatim, but it's copying all the same. If the author of the original code can prove that you've done this (this applies to code under *any* license), then they can pursue the same legal recourse as if you'd used the original code directly.
merely because I viewed some GPL source
It's not viewing the GPL'd source that will get you in trouble, it's copying it.
The thing is, if you read someone's code and copy it into your application using your memory as the medium, that's legally the same as just electronically copying the file.
In other words, if you read someone's source code, you're probably bound by the license of said code. Applying their solution to your product, whether you copy it by mind or by wire, is governed by the same licenses.
I understand, BTW, that Microsoft programmers are explicitly forbidden by their management from reading the code to any GPL products to avoid this problem.
Your link isn't to a "more accurate story", it points to a story about an entirely different crash! The story on xbox.com was written prior to E3 (see the beginning of the last paragraph), while the story on thegia.com is about a crash that happened *during* E3, almost a month later.
:-)
Do I think it's unreasonable for the box to crash? Maybe not, but at this point, late in the develpment, it sure doesn't bode well for the release of the product, does it?
Take those informative moderation points and put them where they belong... On informative (and correct) posts
How so? Well, I ran Win2k at home on a box whose purpose was only playing games and viewing multimedia, with an Nvidia card. Sounds a lot like the Xbox, doesn't it? That box crashed about every other day, making Win98 more that 50 times as stable (it crashed about every two months). I originally installed Win2k because I thought I might end up doing development, but I'm not. (Not on Windows, anyway). After putting up with it for about a month and a half, my girlfriend asked me to remove it. These numbers are accurate for this installation. I've kept track because I was curious.
I'm glad Win2k is stable for you. I'd heard that it was for a lot of people, which is one of the reasons that I installed it. However, for a gaming platform, it's not even close to stable. NVidia better come out with a damn good driver for the Xbox, cuz the latest *stable* driver on their site ate my balls. At this rate, the Xbox is going to ruin a lot of otherwise good games.
His statement implied that the Xboxen had the idea that they had more memory than they really did, as if MS had told the kernel that it had 256MB of RAM, but only given it 128. This is not the case. There is no way that those machines crashed because they were trying to access "non-existant memory" except by plain old (and I'm talking OLD) Microsoft style bugs.
While you _can_ tell Linux that it has more RAM than it does, the result will not be what the previous poster implied. Linux will not boot if you lie to it.
one sentance about the X-Box crashing
I don't know about you, but one crash is about all I need. Seems to me that Microsoft products seem to crash in just about every public demo that I actually attend or hear about.
namely lacking memory
Now, the rep. said that the memory configuration will be different. He did not say that the final Xbox will have more memory. Since the Xbox has been switched to an Intel CPU, I'm guessing that either he meant something related to RAMBUS/SDRAM, or he was just plain spin doctoring. I'm inclined to beleive the latter, since his statement was so vague.
if I tell the kernel it has 256MB
Totally m00t point. You can't *tell* the 2000 kernel how much memory the system has. You obviously know nothing about kernel design. Stop and think about this for a moment. The hecklers aren't really being immature about this, they're pointing out that their suspicions all along that the Xbox would just be another crashy MS PC are right. If this crash were due to a missing piece of hardware, they all would have crashed. Maturity has nothing to do with deriding the Xbox. What do you expect us to do? Ignore it? Buy the Xbox because Bill tells us to? Screw that. I want hardware (and software) with a proven record of stability and quality. The Xbox has neither of those. Intel/RAMBUS has had serious stability issues. Windows 2000 has serious stability issues. The Xbox has been demonstrated to be instable. Conclusion: I'm not buying one! If I did, it wouldn't be a console, it would be a Linux PC that MS generously paid most of the cost for. (If MS wants to buy me a Linux capable PC with a sweet video card to repay me for the trouble they've caused, who am I to argue!?)
As an aside, if you lie to Linux, and tell it that it has more RAM than it does, it won't complete booting. You can't break Linux this way.