If the code really was released under GPL and the FreeDOS people used only GPL code, there was no such clause. The GPL has no such clause.
If the code was released under another license and re-released under the GPL by the author of the derived work, and the original license was incompatible with some term of the GPL, then the author of the derived work exceeded his rights in re-releasing it under the GPL.
What is the license they started with? All I've found is this:
This doesn't seem to be compatible with the GPL. Source code distributed under this license could only be released under the GPL if the copyright holder did so.
Hierarchy isn't inherent in HTML or HTTP: relative URLs make it a little more convenient to organize a site hierarchially... but only a little, and the web as a whole isn't hierarchical: it's a directed graph. A Wiki isn't hierarchical, it's a directed graph. Many web sites are organized relationally, with internal links managed by treating CGI variables as table columns.
I'm appalled that, in 2005, we still have to jump through hoops to include arbitrary objects in arbitrary documents.
I agree, the lack of an "include" mechanism in HTML is ludicrous, and was ludicrous 10 years ago. As is the opposite problem... you should be able to define a frame entirely within the body of a document, easily, without having to do things like having Javascript write into a blank frame.
I'd like servers to keep a database of all their referrable objects and their URLs, so an object whose URL changes (moved internally, externally or deleted) can simply return the response code so indicating.
In the real world device drivers hardly ever crash the system 'cos they're kernel mode, they crash it because the hard-hang the system or denigh the kernel the resources to dig itself out of the hole.
In many cases you're right, and the ability of microkernels to dig themselves out of driver lockups is given more importance than it really warrants. However, it's not entirely irrelevant, as you're implying, nor is it the only way a microkernel design makes it easier to build a robust and fail-soft system.
if it hadnt been for tanenbaum refusing to give the source code to linus to study
That didn't happen.
The reasons Linus implemented Linux rather than improving Minix are far more complicated than just the license on Minix, and in any case the license on Minix was far less restrictive than you imply.
16MB ram in the requirements... all I can say is WOW.
What hardware do I need to run MINIX 3?<br> You need an Intel 386 or higher with 4 MB of RAM, an IDE hard disk with 100 MB of free disk space, and an IDE CD-ROM for booting.
Microkernels don't have any more problems deciding how to implement paging through the file system than monolithic kernels... remember that UNIX implementations didn't support paging to a file until well into the '80s.
There are no fundamental reasons why microkernels must inherently incur more overhead than monolithic kernels. There are several reasons why traditional academic microkernels like Minix have poor performance, but in the real-time world things are very different.
1. Academic kernels typically establish a separate protection domain for every process. This makes them easier to reason about and implement, but it means that every message requires switching page tables. This is expensive, but no more necessary than having a separate kernel layer to match each layer of the ISO protocol model.
2. Academic kernels typically use messages as the only IPC mechanism, eschewing shared access to shared resources like buffer pools. This doesn't actually hurt your traditional microkernel all that much, because you can't really take advantage of this until you solve the first point.
3. Avoiding bottlenecks can be difficult, and at least needs explicit design. If the file system is a single thread with no internal request management or queuing, then only one process can be reading from the file system ar a time. In a traditional kernel you automatically get a separate process for each synchronous request, so when it's blocked on some resource other processes can continue to use the file system.
Basically, Minix performance was poor because it was designed as a teaching tool, so it avoids muddying the waters by throwing everything you need to do to make a microkernel really cook away. Its limitations are similar in origin to the limitations in Pascal. Would you argue against strong typing and type checks because Pascal's type system doesn't include a variable length array? Or against structured programming because Pascal doesn't support separate compilation and linking?
Finally, microkernels are not automatically more reliable than monolithic kernels, they just have failure modes that are normally easier to diagnose and trace.
You can be "on about intentionality" all you want, but what you're describing is as imaginary as the "soul". It's distinction that exists in the observer, not the observed.
I can write a 20 line program that displays exactly the same kind of "intentionality". The only diference between it and the virus is what you know about how that goal was achieved.
Re:Puppeteers were unavailable for comment
on
Deep in the Core
·
· Score: 1
Luckily, this means we probably don't need to worry about the core explosion... the wave front from that would have passed us billions of years ago. The Long Shot must have gone back in time or something.
The only intentionality that exists in the actions of a virus is that put there by the act of analyzing its actions in the process of looking for "intentionality". You can't prove that this "intentionality" exists in a virus, any more than you can prove that a virus has a soul, pneuma, ka, ba, noos, thumos, spirit, life-force, or any other mythical, philosophical, or mystical abstract attribute that magically separates the quick from the dead.
That was my immediate reaction. Think about REAL battles between ships aremed with explosives and incindiaries. What did they try to ignite? The hull? Or the rigging?
Hey, I spent a month and a half figuring out how to install some software on a Linux box that required an older version of Java. If Java is really portable, and useful, over the long term it HAS to get to the point ehwre it shouldn't matter if your version is 1 month old, 6 months old, or 6 years old.
Seriously.
Because that's what the competition (the monopoly OS) gives you. I can buy a typical non-gaming software package off the shelf, today, and have a reasonable expectation that I can run it on Windows XP, Windows 2000, or Windows 98... or even Windows 95 if I have a recent version of IE.
The downside to this is that Microsoft can't ever get rid of even horrific design flaws, which is one of the reasons that they have so many security problems. The upside is that for the end user it's a safe purchase.
Linux, Mac OS X, FreeBSD, Java, none of these have the same kind of bloody-minded (or bloody-stupid) commitment to forwards and backwards compatibility. But Java seems to be particularly fragile, there, and it doesn't have to be. IT RUNS IN A SANDBOX, so it's in a unique position of being able to maintain bug-compatible releases without them becoming security flaws.
I found that there's nothing uniquely available to the platform that I need.
I think you will find that like myself you are an "edge consumer" in this domain.
Also, unless "I've bought Apple computers in the past" refers to a past recent enough that they were running OS X when you bought them, they might as well have been in a different universe.
(sluggish Java? There's Java that isn't sluggish? That must be in an alternate reality as well)
Hey, there's plenty of manufacturors for all those parts.
You already covered that with points "b" and "c", and I agreed with you on points "b" and "c". These points do mitigate the effect of point "a" on non-apple hardware, but repeating them over again doesn't actually make it a stronger point.
For the moment at least MacOS and Windows aren't the only choices
If you're only interested in running open source software, that's true. Now, there's a good argument for only running open source software. I was primarily running, as well as writing, what was not yet called open source software myself on a variety of operating systems back when Richard Stallman was still working on Emacs and the Free Software Foundation wasn't even a gleam in his eye. But not having the kind of tools available on proprietary platform begins to pall after a decade or two, even for someone like me.
And on the other hand, someone like me (or, I would guess, your good self) who is capable of handling the limited choice of application software that results from picking free UNIX (whether Linux- or BSD- based) is also capable of handling the limited hardware availability that results from picking OSX. It's simply a matter of which limitation one is willing to put up with.
You can pick the monopoly OS, and put up with the lousy security model that makes bodged like "anti-virus software" seem reasonable.
You can pick the other commercial OS, and put up with a limited hardware selection.
You can pick a non-commercial OS (and packaging it in a cardboard box with a manual doesn't change what it is) and put up with a limited software selection.
a) You're right. Intel, for example, would never hardwire the clock speed into a chip so you can't overclock it. HP would never add components to a printer to decrease its performance. You'll never find a motherboard with a NIC but no RJ45, Firewire support and no Firewire socket, but with traces for both leading to empty vias. It'd never happen, because only Apple ever reduces the capabilities of their computers. That's why people are so upset with Apple over shipping Mac minis that could have a faster CPU or more VRAM but they're disabled... oh, sorry, they're not disabled, and people are upset with Apple over that. I guess they can't win.
b+c) Competition is good, I agree. It's a shame that the rules of the intellectual property game have been written so as to make an OS monopoly more or less inevitable, but at least you've got hardware choice if you choose the monopoly OS.
Why can't a PC boot into target mode like a Mac can? Same answer, the hardware manufacturer(s) haven't implemented it.
would Mac owners be happier with this change if their machines could?
Only the few crazy people who want to boot off an iPod.
The reason Mac users want Firewire is that Firewire is faster and more reliable than USB. Theoretically USB2 should be a little faster than FW400, but practically it's slower, and USB1.1 (and many USB2 devices and hubs are really USB1.1) is a lot slower. And it's a LOT less reliable, possibly because of contention with all the other devices on the serial bus, possibly because the USB protocol has more overhead, I don't know... I just know that I have more problems with USB.
Every Apple computer sold in the past 5 years has Firewire.
Very few Windows based computers do.
Whether that's a result or a cause of the poor Windows support and good MacOS support for firewire, you're just demonstrating my point: by dropping Firewire Apple is abandoning the best possible support for their own computers... which makes sense if they're selling more iPods to Windows users.
How does this footprint differ from cellular broandband?
Who the hell cares?
Cellular broadband is under the thumb of cellphone companies. If you think that's not a deal-killer for any hope of sane pricing right there, you must work for a cellphone company -- in their sales department. Nobody else would possibly be willing to shut down their critical facilities to that degree.
Slashdot Mirror
If the code really was released under GPL and the FreeDOS people used only GPL code, there was no such clause. The GPL has no such clause.
w ww.drdos.net/faq/license.txt
If the code was released under another license and re-released under the GPL by the author of the derived work, and the original license was incompatible with some term of the GPL, then the author of the derived work exceeded his rights in re-releasing it under the GPL.
What is the license they started with? All I've found is this:
http://web.archive.org/web/20021022095633/http://
This doesn't seem to be compatible with the GPL. Source code distributed under this license could only be released under the GPL if the copyright holder did so.
Hierarchy isn't inherent in HTML or HTTP: relative URLs make it a little more convenient to organize a site hierarchially... but only a little, and the web as a whole isn't hierarchical: it's a directed graph. A Wiki isn't hierarchical, it's a directed graph. Many web sites are organized relationally, with internal links managed by treating CGI variables as table columns.
I'm appalled that, in 2005, we still have to jump through hoops to include arbitrary objects in arbitrary documents.
I agree, the lack of an "include" mechanism in HTML is ludicrous, and was ludicrous 10 years ago. As is the opposite problem... you should be able to define a frame entirely within the body of a document, easily, without having to do things like having Javascript write into a blank frame.
I'd like servers to keep a database of all their referrable objects and their URLs, so an object whose URL changes (moved internally, externally or deleted) can simply return the response code so indicating.
Um, that's already in HTTP.
In the real world device drivers hardly ever crash the system 'cos they're kernel mode, they crash it because the hard-hang the system or denigh the kernel the resources to dig itself out of the hole.
In many cases you're right, and the ability of microkernels to dig themselves out of driver lockups is given more importance than it really warrants. However, it's not entirely irrelevant, as you're implying, nor is it the only way a microkernel design makes it easier to build a robust and fail-soft system.
if it hadnt been for tanenbaum refusing to give the source code to linus to study
That didn't happen.
The reasons Linus implemented Linux rather than improving Minix are far more complicated than just the license on Minix, and in any case the license on Minix was far less restrictive than you imply.
Microkernels don't have any more problems deciding how to implement paging through the file system than monolithic kernels... remember that UNIX implementations didn't support paging to a file until well into the '80s.
There are no fundamental reasons why microkernels must inherently incur more overhead than monolithic kernels. There are several reasons why traditional academic microkernels like Minix have poor performance, but in the real-time world things are very different.
1. Academic kernels typically establish a separate protection domain for every process. This makes them easier to reason about and implement, but it means that every message requires switching page tables. This is expensive, but no more necessary than having a separate kernel layer to match each layer of the ISO protocol model.
2. Academic kernels typically use messages as the only IPC mechanism, eschewing shared access to shared resources like buffer pools. This doesn't actually hurt your traditional microkernel all that much, because you can't really take advantage of this until you solve the first point.
3. Avoiding bottlenecks can be difficult, and at least needs explicit design. If the file system is a single thread with no internal request management or queuing, then only one process can be reading from the file system ar a time. In a traditional kernel you automatically get a separate process for each synchronous request, so when it's blocked on some resource other processes can continue to use the file system.
Basically, Minix performance was poor because it was designed as a teaching tool, so it avoids muddying the waters by throwing everything you need to do to make a microkernel really cook away. Its limitations are similar in origin to the limitations in Pascal. Would you argue against strong typing and type checks because Pascal's type system doesn't include a variable length array? Or against structured programming because Pascal doesn't support separate compilation and linking?
Finally, microkernels are not automatically more reliable than monolithic kernels, they just have failure modes that are normally easier to diagnose and trace.
Another point is that what ever Wimax can do, 3G may catch up to Wimax at least to the extent that it is no worse - if not better.
And Windows Vista might be a Better UNIX than UNIX.
You can be "on about intentionality" all you want, but what you're describing is as imaginary as the "soul". It's distinction that exists in the observer, not the observed.
I can write a 20 line program that displays exactly the same kind of "intentionality". The only diference between it and the virus is what you know about how that goal was achieved.
Luckily, this means we probably don't need to worry about the core explosion... the wave front from that would have passed us billions of years ago. The Long Shot must have gone back in time or something.
The only intentionality that exists in the actions of a virus is that put there by the act of analyzing its actions in the process of looking for "intentionality". You can't prove that this "intentionality" exists in a virus, any more than you can prove that a virus has a soul, pneuma, ka, ba, noos, thumos, spirit, life-force, or any other mythical, philosophical, or mystical abstract attribute that magically separates the quick from the dead.
That was my immediate reaction. Think about REAL battles between ships aremed with explosives and incindiaries. What did they try to ignite? The hull? Or the rigging?
Hey, I spent a month and a half figuring out how to install some software on a Linux box that required an older version of Java. If Java is really portable, and useful, over the long term it HAS to get to the point ehwre it shouldn't matter if your version is 1 month old, 6 months old, or 6 years old.
Seriously.
Because that's what the competition (the monopoly OS) gives you. I can buy a typical non-gaming software package off the shelf, today, and have a reasonable expectation that I can run it on Windows XP, Windows 2000, or Windows 98... or even Windows 95 if I have a recent version of IE.
The downside to this is that Microsoft can't ever get rid of even horrific design flaws, which is one of the reasons that they have so many security problems. The upside is that for the end user it's a safe purchase.
Linux, Mac OS X, FreeBSD, Java, none of these have the same kind of bloody-minded (or bloody-stupid) commitment to forwards and backwards compatibility. But Java seems to be particularly fragile, there, and it doesn't have to be. IT RUNS IN A SANDBOX, so it's in a unique position of being able to maintain bug-compatible releases without them becoming security flaws.
I found that there's nothing uniquely available to the platform that I need.
I think you will find that like myself you are an "edge consumer" in this domain.
Also, unless "I've bought Apple computers in the past" refers to a past recent enough that they were running OS X when you bought them, they might as well have been in a different universe.
(sluggish Java? There's Java that isn't sluggish? That must be in an alternate reality as well)
You want to provide some support for this assertion, Dix? Post a picture of your nano before and after you rubbed it with "soft felt"?
Hey, there's plenty of manufacturors for all those parts.
You already covered that with points "b" and "c", and I agreed with you on points "b" and "c". These points do mitigate the effect of point "a" on non-apple hardware, but repeating them over again doesn't actually make it a stronger point.
For the moment at least MacOS and Windows aren't the only choices
If you're only interested in running open source software, that's true. Now, there's a good argument for only running open source software. I was primarily running, as well as writing, what was not yet called open source software myself on a variety of operating systems back when Richard Stallman was still working on Emacs and the Free Software Foundation wasn't even a gleam in his eye. But not having the kind of tools available on proprietary platform begins to pall after a decade or two, even for someone like me.
And on the other hand, someone like me (or, I would guess, your good self) who is capable of handling the limited choice of application software that results from picking free UNIX (whether Linux- or BSD- based) is also capable of handling the limited hardware availability that results from picking OSX. It's simply a matter of which limitation one is willing to put up with.
You can pick the monopoly OS, and put up with the lousy security model that makes bodged like "anti-virus software" seem reasonable.
You can pick the other commercial OS, and put up with a limited hardware selection.
You can pick a non-commercial OS (and packaging it in a cardboard box with a manual doesn't change what it is) and put up with a limited software selection.
There's no win-win solutions.
a) You're right. Intel, for example, would never hardwire the clock speed into a chip so you can't overclock it. HP would never add components to a printer to decrease its performance. You'll never find a motherboard with a NIC but no RJ45, Firewire support and no Firewire socket, but with traces for both leading to empty vias. It'd never happen, because only Apple ever reduces the capabilities of their computers. That's why people are so upset with Apple over shipping Mac minis that could have a faster CPU or more VRAM but they're disabled... oh, sorry, they're not disabled, and people are upset with Apple over that. I guess they can't win.
b+c) Competition is good, I agree. It's a shame that the rules of the intellectual property game have been written so as to make an OS monopoly more or less inevitable, but at least you've got hardware choice if you choose the monopoly OS.
why can't a Mac boot from USB when a PC can
Why can't a PC boot into target mode like a Mac can? Same answer, the hardware manufacturer(s) haven't implemented it.
would Mac owners be happier with this change if their machines could?
Only the few crazy people who want to boot off an iPod.
The reason Mac users want Firewire is that Firewire is faster and more reliable than USB. Theoretically USB2 should be a little faster than FW400, but practically it's slower, and USB1.1 (and many USB2 devices and hubs are really USB1.1) is a lot slower. And it's a LOT less reliable, possibly because of contention with all the other devices on the serial bus, possibly because the USB protocol has more overhead, I don't know... I just know that I have more problems with USB.
And this is different from any other computer manufacturer how?
Nobody has firewire, but everyone has USB.
... which makes sense if they're selling more iPods to Windows users.
Every Apple computer sold in the past 5 years has Firewire.
Very few Windows based computers do.
Whether that's a result or a cause of the poor Windows support and good MacOS support for firewire, you're just demonstrating my point: by dropping Firewire Apple is abandoning the best possible support for their own computers
How does this footprint differ from cellular broandband?
Who the hell cares?
Cellular broadband is under the thumb of cellphone companies. If you think that's not a deal-killer for any hope of sane pricing right there, you must work for a cellphone company -- in their sales department. Nobody else would possibly be willing to shut down their critical facilities to that degree.
the growing cellular broadband market
The what?
I know there's no rational reason for that (and they had good reasons to move on)
Like, Windows supports USB better than Firewire?
Mac OS sure doesn't. I have way more problems with USB drives on my Macs at home and at work than with firewire ones.
Bill Gates has also claimed that NT is a "Better UNIX than UNIX".
I wish it were so, but Microsoft gave up on that when they dumped Xenix.
Surely Dvorak hasn't simply ignored the possibility that people who say they use the Mac because it's better are honestly telling the truth?
It sure sounds like it.