How did a situation get created where you can't make copies of open source software for free?
No such situation has been created. You can still make all the copies of the open source software you like for free.
This is not incompatible in any way with the concept of a company selling the software. The fact that they sell it does not prevent you from copying it.
The hooks to get you to buy what you could otherwise get for free are support (when used in conjunction with Red Hat Enterprise Linux), and some bundled non-open-source software.
What would it take to replace the proprietary parts of Red Hat's distro with open source software?
It's already been done. It's called Fedora Core, or Debian, or Gentoo, or Suse, or Mandrake, etc.
The first software I install on a Windows machine is Linux, usually Fedora Core 1.
If there's some reason I can't install Linux natively, I install VMware and install Linux inside that. Though my preference, by far, is to install Linux natively (and run Windows in VMware if necessary).
If I absolutely had to run Windows, I install Mozilla, GNU Emacs, Cygwin (or MinGW/MSYS), SecureCRT, TortoiseSVN, 7-Zip, OpenOffice, Acrobat Reader, and sometimes Ghost.
We just need the Federal equivalent of Utah's recently enacted spyware law.
Although we should try to make sure our congresscritters don't pass a weaker one
that overrides better protections at the state level.
LWN ran a story about the Utah anti-spyware law
last month. A number of parties objected, but don't appear to have any
legitimate grounds for complaint. The law doesn't ban spyware outright, but
requires that spyware explain to the user what it will do, and obtain the
user's consent before doing it. Only naughty people/companies should have
a problem with that.
Ordinary electric motors are typically more than 90% efficient already, except when they are operated at less than half of their rated load. In order to save 80% of the energy, the motor has to be made five times as efficient, which would be 450%. Unless the laws of thermodynamics are found not to hold, you can't get more than 100% efficiency.
If his claims are based on making the motor more efficient under a light load, the same result can be accomplished by using a lower-rated motor.
Shopping channels get a disproportionate share of cable and satellite bandwidth to the number of actual viewers because the carrier gets a cut of the sales. In an a la carte pricing model, this would be fixed because the revenue from providing a channel that many subscribers want would exceed the revenue they get from a shopping channel.
Although there were rumors about an Intel Yamhill 64-bit x86 part for many years, they didn't announce an 64-bit x86 architecture extension until February 18, 2004, and it was announced sheepishly as a very minor point in a press release rather than amid great fanfare as AMD had done. Intel still has not released any product incorporating this extension. Thus they've had more than 3 1/2 years to develop their own 64-bit x86 based on the AMD specifications. No need whatsoever for reverse-engineering. In fact, reverse engineering would have taken much longer, because they would have had to wait to get their hands on working AMD silicon.
it is clear that Intel reverse-engineered the AMD64.
How is Mr. Halfhill able to conclude that, when Intel could just as easily have simply read the x86-64 documentation which was released more than two years before Intel announced their version? His only evidence is that Intel left out two instructions which were not in the early AMD documentation; that actually suggests Intel simply used the AMD documentation, and did no reverse-engineering at all.
Or perhaps Mr. Halfhill is confused about what the term "reverse-engineering" means. Specifically, it is reconstructing specifications and design information from a finished product. Designing a new, compatible product from published documentation is not in any sense reverse engineering.
However, due to the fact that the new Xeon is not an exact copy of the AMD64's microarchitecture, Intel has not broken the law.
It's not clear that Intel would have broken the law even if they HAD made an exact copy of AMD's microarchitecture.
Microarchitecture per se is not protected by law, though aspects of it could be patented. But Intel and AMD have patent cross-licenses, to that is not an issue. A specific mask layout may be protected by copyright law, but it's quite possible to copy microarchitecture without copying mask layout.
It is also possible that AMD may have provided the x86-64 architecture documentation to Intel under NDA well before the public release. The very name, "x86-64", was suprisingly vendor-neutral. I suspect that AMD only renamed it to AMD64 after they believed they had been unsuccessful at convincing Intel to produce compatible processors. Intel denied for years that they would offer a 64-bit extension of any kind for the x86, despite the widespread rumors to the contrary.
Mr. O'Dowd of Green Hills Software obviously didn't really learn anything when reading Ken Thompson's paper, or he would realize that the trust problem Thompson described is just as severe with commercial closed-source software. Actually, the compiler trojan Thompson described was for commercial, closed source software.
In fact, open-source software may have a slight advantage here, because it's less of a monoculture. Presumably Microsoft always uses their own Visual C++ compiler to build Windows, so if there were a trojan in the compiler that compromised the resulting Windows executables, it would be present in all copies of Windows that Microsoft distributed. But open source software is by its nature built on many different platforms using different compilers, so a compiler trojan would only affect a portion of the deployed copies of the open source software. And it is possible that a trojan introduced by one particular compiler would be found due to the executable it produces being different in some noticable way from the executable produced by a different compiler. For instance, strace might show the trojaned executable making extra system calls.
How does Mr. O'Dowd propose to assure us that his company's operating systems and compilers are more secure than Linux, xBSD, GCC, etc? Is he certain that none of his employess who have written code incorporated into his products have ever installed trojans? If so, how has he gained this certainty? Has he scrutinized every line of source code himself? Including those of the compilers that compiled the compilers, back all the way to the machine-code only origin of the system? Somehow I doubt it.
It is a matter of historical fact that far more trojan and back door exploits have been present in commercial, closed source software than in open source software. Just two days ago Cisco had to issue a security advisory regarding a back door found in their WLSE and HSE products. Would Mr. O'Dowd conclude that foreign agents and terrorists are responsible for that? Would he really have us believe that these shadowy figures can compromise open source software developed in the public eye more easily than they could subvert a commercial closed-source software package for which the source code and development process get no public scrutiny?
One is forced to conclude that Mr. O'Dowd feels his company's business model is threatened, and rather than change that model to reflect changes in the marketplace, he prefers to use "the sky is falling" proclamations in an attempt to scare customers into sticking with his products.
Many open source projects suffer from an informality that causes CIOs anxiety. Most IT executives want a clear roadmap for products so that they can better plan for their future and select vendors.
Most proprietary software vendors don't offer any roadmap, and where they do, it's usually too vague. The roadmap usually changes dramatically over time, and the software is often years late. Look at what happened with the mythical "Cairo" release of Windows NT, and now with "Longhorn".
How is this sort of roadmap of any use to CIOs and IT executives?
Open source software typically doesn't make any promises, so there are none to be broken. But where there is a roadmap, in my experience the open source projects do a better job of meeting it than proprietary software does. Still often behind schedule, but typically not by as much.
Although not as vile as the typical anti-open-source journalism, this is nevertheless just a FUD story.
Eric
Roads? Where we're going, we don't need roads!
-- Emmett "Doc" Brown, Back to the Future
NFS is a pathetic excuse for a distributed file system. File systems are fundamentally stateful, so trying to map them onto a stateless protocol is utterly insane.
NFS works OK (not great, IMO) now, but in the early days it was absolutely awful. We called it the Nightmare File System. From 1991-1995 I worked for a company running a big network of Sun 4s (and a few Sun 3s). NFS mounts failed all the time, leaving kernel data structures inconsistent and requiring machines to be rebooted to recover. We had terrible problems with corruption of RCS files (and later, CVS). This was tracked down to the fact that Sun deliberately had turned off UDP checksums in a misguided attempt to get better performance.
These days anyone with any sense runs NFS over TCP, and most of the egregious problems have been fixed.
NFS caught on because at the time there wasn't really any available alternative. There are alternatives to Java, and if Sun doesn't get their act together, people will migrate to them.
I'm not claiming that Java will wither up and die overnight. But I believe Java would be much more successful if Sun turned the specifications over to a standards body, and released the implementation as open source. This would benfit Sun, not harm it.
OpenOffice?"
Like it or not, Sun is a big contributor to open source.
Sun is definitely to be commended for releasing OpenOffice. However, they did this only when it became apparent that StarOffice as a proprietary product was going nowhere.
Yes. C# and CLI have been standardized by ECMA, as ECMA-334 and ECMA-335. ECMA also published a technical report on CLI, ECMA TR84. ISO/IEC JTC 1 has standardized these as ISO/IEC 23270, ISO/IEC 23271, and ISO/IEC 23272.
Where are the standard Java and JVM specifications? There aren't any. There are only the proprietary Sun specifications. Sun claims to have a community process, but getting any non-trivial changes made through that appears to at least four years. And I though standards bodies were slow! On the other hand, Sun feels free to introduce arbitrary changes that break compatability at the drop of a hat. Sun's claim of "write once, run everywhere" is a joke; I've got dozens of Java programs that were published as open source that worked fine on earlier releases of the Java SDK but won't even compile now.
No, this doesn't make Microsoft's implementation freely available. But the specifications are completely open, and not nearly as subject to arbitrary and capricous changes as proprietary specifications.
He said that although he respected Raymond, he felt the advocate was off base in his letter and noted Sun's many years in managing technology development among multiple parties.
"We've been around the block many times on open interfaces, open systems implementation, compatibility. Nobody has more experience on community development," he said.
And most of those open interfaces and open systems have gone nowhere, because they weren't truly open standards. When was the last time you used Suntools? OpenLook? NeWS?
Sun has quite a history of inventing new interfaces, then abandoning them because competing open standards achieved more traction in the marketplace. If they're not careful, C# will do exactly that.
since the Martians shot down the orbiters many years ago.
Need ability to moderate Slashdot stories
on
Melting Europa
·
· Score: 1, Informative
This one would be -1, Troll.
There are certainly some legitimate concerns, but perhaps attempting to show a little more open-mindedness in writing the stories might be more conducive to reasonable discourse.
For instance, rather than phrasing questions about the effects of RTGs in a deliberately scary way ("I wonder how long the time lag will be between the probe finding life, and a leak in the radioactive heater wiping all of it out."), one could ask what the expected lifetime of the RTG vessel would be under the expected temperature and pressure conditions, and what effect the leak of radioactive material from a comparable RTG could cause in the Earth's oceans.
Since RTGs launched on spacecraft are designed to withstand catastrophic uncontrolled reentry into the Earth's atmosphere without breaking up and distributing radioactive material, I would expect that they should last a very long time in conditions they would encounter on Europa. However, I'll be the first to admit that I don't have any solid information.
If we knew the expected containment lifetime, and the composition and mass of the radioactive material, we could make a reasonable guess as to the answer to the second question. But bandying about phrases such as "wiping all of it out" does not promote any reasonable analysis.
That's not to say that we shouldn't have some degree of healthy skepticisim.
You're completely wrong, since Alvin Toffler used "prosumer" to mean something entirely different than Sony did.
Toffler was combining "producer" with "consumer", referring to the processes of production and consumption. Sony was combining "professional" with "consumer", referring to grades of equipment without regard to whether the equipment was used for production or consumption.
I can't find any usage of the term "Prosumer" predating the 1986 announcement of ED Beta. When did they introduce Profeel? Did they actually use the term "Prosumer" in marketing literature or press releases?
It's a term Sony invented when their marketing department was trying to figure out how to get customers to pay $3000 for an ED-Beta VCR. They couldn't call it pro, so they came up with an intermediate level.
The only way I see to use this device is to buy a CD, and if I can't rip it, I'll have to [break the law and] download the MP3-file via file-sharing.
I have no idea about the laws in Germany, but here in the U.S. that would almost certainly be considered fair use, and not breaking the law.
The copyright owner does not have any right to prevent you from listening to the music on the CD you've purchased, nor to require you to listen using only "approved" equipment. If you have to download the (mostly) equivalent bits on the internet in order to listen to the music you have purchased, so be it.
Even the DMCA does not override fair use, though media companies claim it does. The DMCA, U.S. Public Law 105-304, specifically amends 17 U.S.C. 1201 to state:
Nothing in this
section shall affect rights, remedies, limitations, or defenses to
copyright infringement, including fair use, under this title.
Slashdot Mirror
This is not incompatible in any way with the concept of a company selling the software. The fact that they sell it does not prevent you from copying it.
The hooks to get you to buy what you could otherwise get for free are support (when used in conjunction with Red Hat Enterprise Linux), and some bundled non-open-source software.
It's already been done. It's called Fedora Core, or Debian, or Gentoo, or Suse, or Mandrake, etc."People of Earth, I am Lrrr of the planet Nintendu 64. Tremble in fear at our three different kinds of ships!" -- Futurama, "Anthology of Interest II"
If there's some reason I can't install Linux natively, I install VMware and install Linux inside that. Though my preference, by far, is to install Linux natively (and run Windows in VMware if necessary).
If I absolutely had to run Windows, I install Mozilla, GNU Emacs, Cygwin (or MinGW/MSYS), SecureCRT, TortoiseSVN, 7-Zip, OpenOffice, Acrobat Reader, and sometimes Ghost.
LWN ran a story about the Utah anti-spyware law last month. A number of parties objected, but don't appear to have any legitimate grounds for complaint. The law doesn't ban spyware outright, but requires that spyware explain to the user what it will do, and obtain the user's consent before doing it. Only naughty people/companies should have a problem with that.
The LWN story links to an excellent analysis of the law by Benjamin Edelman.
If his claims are based on making the motor more efficient under a light load, the same result can be accomplished by using a lower-rated motor.
Shopping channels get a disproportionate share of cable and satellite bandwidth to the number of actual viewers because the carrier gets a cut of the sales. In an a la carte pricing model, this would be fixed because the revenue from providing a channel that many subscribers want would exceed the revenue they get from a shopping channel.
Fluorinert does the same thing, and it's been around for many years. That's what was used in some Cray machines.
Although there were rumors about an Intel Yamhill 64-bit x86 part for many years, they didn't announce an 64-bit x86 architecture extension until February 18, 2004, and it was announced sheepishly as a very minor point in a press release rather than amid great fanfare as AMD had done. Intel still has not released any product incorporating this extension. Thus they've had more than 3 1/2 years to develop their own 64-bit x86 based on the AMD specifications. No need whatsoever for reverse-engineering. In fact, reverse engineering would have taken much longer, because they would have had to wait to get their hands on working AMD silicon.
Or perhaps Mr. Halfhill is confused about what the term "reverse-engineering" means. Specifically, it is reconstructing specifications and design information from a finished product. Designing a new, compatible product from published documentation is not in any sense reverse engineering.
It's not clear that Intel would have broken the law even if they HAD made an exact copy of AMD's microarchitecture.Microarchitecture per se is not protected by law, though aspects of it could be patented. But Intel and AMD have patent cross-licenses, to that is not an issue. A specific mask layout may be protected by copyright law, but it's quite possible to copy microarchitecture without copying mask layout.
It is also possible that AMD may have provided the x86-64 architecture documentation to Intel under NDA well before the public release. The very name, "x86-64", was suprisingly vendor-neutral. I suspect that AMD only renamed it to AMD64 after they believed they had been unsuccessful at convincing Intel to produce compatible processors. Intel denied for years that they would offer a 64-bit extension of any kind for the x86, despite the widespread rumors to the contrary.
In fact, open-source software may have a slight advantage here, because it's less of a monoculture. Presumably Microsoft always uses their own Visual C++ compiler to build Windows, so if there were a trojan in the compiler that compromised the resulting Windows executables, it would be present in all copies of Windows that Microsoft distributed. But open source software is by its nature built on many different platforms using different compilers, so a compiler trojan would only affect a portion of the deployed copies of the open source software. And it is possible that a trojan introduced by one particular compiler would be found due to the executable it produces being different in some noticable way from the executable produced by a different compiler. For instance, strace might show the trojaned executable making extra system calls.
How does Mr. O'Dowd propose to assure us that his company's operating systems and compilers are more secure than Linux, xBSD, GCC, etc? Is he certain that none of his employess who have written code incorporated into his products have ever installed trojans? If so, how has he gained this certainty? Has he scrutinized every line of source code himself? Including those of the compilers that compiled the compilers, back all the way to the machine-code only origin of the system? Somehow I doubt it.
It is a matter of historical fact that far more trojan and back door exploits have been present in commercial, closed source software than in open source software. Just two days ago Cisco had to issue a security advisory regarding a back door found in their WLSE and HSE products. Would Mr. O'Dowd conclude that foreign agents and terrorists are responsible for that? Would he really have us believe that these shadowy figures can compromise open source software developed in the public eye more easily than they could subvert a commercial closed-source software package for which the source code and development process get no public scrutiny?
One is forced to conclude that Mr. O'Dowd feels his company's business model is threatened, and rather than change that model to reflect changes in the marketplace, he prefers to use "the sky is falling" proclamations in an attempt to scare customers into sticking with his products.
when will I be able to get a Smelloscope? I hope I don't have to wait until the year 3000!
Open source software typically doesn't make any promises, so there are none to be broken. But where there is a roadmap, in my experience the open source projects do a better job of meeting it than proprietary software does. Still often behind schedule, but typically not by as much.
Although not as vile as the typical anti-open-source journalism, this is nevertheless just a FUD story.
Eric
Roads? Where we're going, we don't need roads! -- Emmett "Doc" Brown, Back to the FutureNFS works OK (not great, IMO) now, but in the early days it was absolutely awful. We called it the Nightmare File System. From 1991-1995 I worked for a company running a big network of Sun 4s (and a few Sun 3s). NFS mounts failed all the time, leaving kernel data structures inconsistent and requiring machines to be rebooted to recover. We had terrible problems with corruption of RCS files (and later, CVS). This was tracked down to the fact that Sun deliberately had turned off UDP checksums in a misguided attempt to get better performance.
These days anyone with any sense runs NFS over TCP, and most of the egregious problems have been fixed.
NFS caught on because at the time there wasn't really any available alternative. There are alternatives to Java, and if Sun doesn't get their act together, people will migrate to them.
I'm not claiming that Java will wither up and die overnight. But I believe Java would be much more successful if Sun turned the specifications over to a standards body, and released the implementation as open source. This would benfit Sun, not harm it.
Sun is definitely to be commended for releasing OpenOffice. However, they did this only when it became apparent that StarOffice as a proprietary product was going nowhere.Where are the standard Java and JVM specifications? There aren't any. There are only the proprietary Sun specifications. Sun claims to have a community process, but getting any non-trivial changes made through that appears to at least four years. And I though standards bodies were slow! On the other hand, Sun feels free to introduce arbitrary changes that break compatability at the drop of a hat. Sun's claim of "write once, run everywhere" is a joke; I've got dozens of Java programs that were published as open source that worked fine on earlier releases of the Java SDK but won't even compile now.
No, this doesn't make Microsoft's implementation freely available. But the specifications are completely open, and not nearly as subject to arbitrary and capricous changes as proprietary specifications.
Sun has quite a history of inventing new interfaces, then abandoning them because competing open standards achieved more traction in the marketplace. If they're not careful, C# will do exactly that.
since the Martians shot down the orbiters many years ago.
There are certainly some legitimate concerns, but perhaps attempting to show a little more open-mindedness in writing the stories might be more conducive to reasonable discourse.
For instance, rather than phrasing questions about the effects of RTGs in a deliberately scary way ("I wonder how long the time lag will be between the probe finding life, and a leak in the radioactive heater wiping all of it out."), one could ask what the expected lifetime of the RTG vessel would be under the expected temperature and pressure conditions, and what effect the leak of radioactive material from a comparable RTG could cause in the Earth's oceans.
Since RTGs launched on spacecraft are designed to withstand catastrophic uncontrolled reentry into the Earth's atmosphere without breaking up and distributing radioactive material, I would expect that they should last a very long time in conditions they would encounter on Europa. However, I'll be the first to admit that I don't have any solid information.
If we knew the expected containment lifetime, and the composition and mass of the radioactive material, we could make a reasonable guess as to the answer to the second question. But bandying about phrases such as "wiping all of it out" does not promote any reasonable analysis.
That's not to say that we shouldn't have some degree of healthy skepticisim.
You're completely wrong, since Alvin Toffler used "prosumer" to mean something entirely different than Sony did. Toffler was combining "producer" with "consumer", referring to the processes of production and consumption. Sony was combining "professional" with "consumer", referring to grades of equipment without regard to whether the equipment was used for production or consumption.
I can't find any usage of the term "Prosumer" predating the 1986 announcement of ED Beta. When did they introduce Profeel? Did they actually use the term "Prosumer" in marketing literature or press releases?
It's a term Sony invented when their marketing department was trying to figure out how to get customers to pay $3000 for an ED-Beta VCR. They couldn't call it pro, so they came up with an intermediate level.
... then they shouldn't drop the requirement. Just let the CMU entry go it alone.
And hopefully they haven't programmed it with hundreds of conflicting directives.
The copyright owner does not have any right to prevent you from listening to the music on the CD you've purchased, nor to require you to listen using only "approved" equipment. If you have to download the (mostly) equivalent bits on the internet in order to listen to the music you have purchased, so be it.
Even the DMCA does not override fair use, though media companies claim it does. The DMCA, U.S. Public Law 105-304, specifically amends 17 U.S.C. 1201 to state:
How is that a troll? It's true of all software that gets lots of stuff added. I'm not picking on MS, it happens with Linux, Gnome, KDE, Emacs, etc.