However, it looks like redistribution of Minix is permitted as long as you keep the Minix license in the file.
That is from a later release of Minix than the one available when Linus developed Linux. At the time he did so, Minix was a commercial product from P-H, with strict limits on the number of copies you could make.
It doesn't matter, because Linux is not derived from Minix, see my previous comment for details of why.
"When you have task-switching, a file-system, and device drivers, that's Unix" -- or at least its kernel. Linux was born."
That not only describes the process, but makes the point that Unix is fundamentally a set of ideas, not a bunch of computer code -- and exactly how you implement those ideas isn't all that important.
Virtually every operating system created since around 1980 has a file system that is functionally equivalent to the UNIX file system. Maybe it has enhancements or maybe it's implemented differently or has different data structures, but it provides the same kind of files and the same kind of operations on files. The only exceptions I can think of are the original pre-HFS Mac file system, and MS/DOS before 2.11. All the rest: NT, OS/2, AmigaDOS, Windows, BeOS... they have all copied the UNIX file system.
Multitasking? There's a FEW more exceptions there - you can add GEM to the list, for example - but again virtually every OS has that.
Device drivers? Guess what?
UNIX is more than those things. Now, I personally consider it to not be a whole lot more, but that's because I'm only interested with whether I can treat the OS as basically UNIX (perhaps with frills) and from that basis successfully use it, configure it, write code for it, and so on. I don't know what Linus' definition of UNIX is, but I can't imagine it's as broad as Mr. Murphy implies.
But that's not the domain we're in here. We're in the domain of the law, and in that domain UNIX has a specific definition, one for which this fragmentary comment of Linus (presented out of context) has no relevance even if it was meaningful.
And Murphy is making a much stronger claim than that:
The reason Tannenbaum apparently gave Linus a "C" for his kernel hack probably wouldn't have been that the code was bad or derivative, but that he disapproved of sacrificing design elegance for a performance benefit available only on the x86.
The reason Tannenbaum gave Linux a metaphorical C was that the design of the Linux kernel was radically different, from the ground up, from Minix. There was not only any Minix code in it, there was nothing in the design that contained any elements of the design of the Minix kernel. Claiming that Linus based Linux on the Minix kernel because it provided the same basic functionality is like claiming that an electric car must be using a gasoline engine because it has four wheels and a driver's seat.
The microkernel-versus-monolithic-kernel distinction, which was the basis for the infamous Torvalds-Tannenbaum debate, is probably the biggest distinction you can make between kernel implementations in an OS today. There is no easy way to take a kernel of one kind and turn it into the other. The best one can do without doing far more work than simply starting from scratch is to embed one in another, the way single-server Mach-based kernels like Tru64 or Mac OS X do it, like a kind of hybrid gasoline-electric car.
And Linux isn't any such thing. The most casual inspection of the design, even if you weren't aware of the contempt Linus holds for such schemes, would tell you that.
No, there's far more similarities between the OS/2 kernel and the Linux kernel than between the Linux kernel and Minix, and yet nobody would claim Linus based Linux on OS/2. The similarities between Linux and Minix are all in the sheetmetal and steering wheel, the wheels and tires. NOT the engine.
Torvalds was working in an open, academic environment within the scope of both Tannebaum's intent and the Prentice Hall source license for Minix.
This is irrelevant: if Linux was a derived work of Minix it would still be subject to the Prentice-Hall license, which did not permit unlimited redistribution.
Murphy argues Linux is a derived work of Minix because (he claims) Linus started with the Minix source tree and modified it until he had removed every piece of original code, but that this relationship is irrelevant because of Prenti
When any two idiots can burn 8GB of random data onto two DVD's and send secure text messages to each other for the rest of their lives, what the hell use is a complex physically secure network like this one?
Copying data from a DVD that you've intercepted or otherwise gained access to isn't hard. Once you've done that you can not only read any new messages they send, you can decode all the old messages you've already intercepted. And they have no way of knowing you've stolen the pad.
Hard as it is to imagine, the current US president makes me nostalgic for Nixon. Seriously. I don't think the US has had a president like George W Bush since Andrew Jackson promoted "spoilsmanship".
At any rate, you are of course right that there is more to it then just a scheduler and priority management.
Which I think is where I boarded this train...
I'll just say one thing about what UNIX is. UNIX is not Thompson and Ritchie's source tree, UNIX is a family of operating systems that provide a common core set of system calls as their native API. FreeBSD is UNIX. Linux is UNIX. OS/9 and QNX and Regulus are or were UNIX. Interix is a hosted UNIX.
UNIX-like? You have to dig pretty far these days to find an OS that isn't UNIX-like, that hasn't mined UNIX heavily for its design. Wherever your file system is a directed graph, wherever file names are simple strings with no internal structure, wherever files are a simple stream of bytes, wherever you use the same system calls for all files, wherever the shell is just another program, there's another system that's borrowed from UNIX. Because all these things were controversial innovations that UNIX was mocked for using, they were slapdash lazy ideas that real operating systems with structured disks and structured files and user areas and monitors and job control languages would never consider. Creating processes willy-nilly? Inefficient! Flat files? No record management services? Never catch on!
OS/2 is a UNIX-like OS, so are NT and BeOS and AmigaOS and, well, you have to go back to VMS or look in an IBM dinosaur pen for something that isn't.
Then, realtime class != realtime priority. Priority of realtime class processes in handled differently, but is not exactly higher.
Ah, beg pardon then.
OS/2 has a monolithic kernel as well, that has nothign to do with this whatsoever.
OS/2's kernel is not really similar to the traditional UNIX monolithic kernel. The original design had no kernel threads at all, let alone any way for a driver to schedule any, and virtually all traditional UNIXes (including Linux) use the same model today.
The thing that has everything to do with this is deciding which of the processes that is runnable at a given moment gets time.
We're not talking about processes competing against processes, we're talking about processes competing against device drivers. UNIX device drivers are not processes, tasks, or threads, and they are not scheduled, they are not handled or managed by the scheduler. The interrupt handler (lower half) triggers what's effectively a "software interrupt" that handles the longer term operations in the kernel context but doesn't normally involve a switch to a different process context. The scheduler doesn't "see" the driver at all.
Fixing that is a problem that would need to be dealt with before any change in the UNIX scheduler could have any effect on contention between I/O and CPU.
The guy who hates his ex-girlfriend but is still talking about her years later.
That's because this "ex-girlfriend" is inescapable. We can't turn around but she's there, hammering on our firewalls, following us to work, annoying our friends and relatives and even living in their houses... and talking them into trying to get us back together again "just this once, she really needs your help, I think she has a virus."
If someone claims two applications of a new technology that are so extremely unrelated to each other in one sentence I find it hard to take him/her seriously.
Yeh, it's easy to respond to someone says or the care they take with their messages, instead of digging deeper, and get the wrong impression.
Screening airport baggage would be a lot easier with a small portable radiation source that could be used to make the existing scanners lighter. This is a smaller neutron source than ones currently used.
The efficiency of a reaction drive in a spacecraft is better the higher the velocity of its exhaust, other things being equal. Again, a small light radiation source could be used in a low-power high-impulse drive. As I understand it, this device isn't particularly efficient at the moment but that might not be an inherent problem.
I don't think I see how it could be used for automobile propulsion, perhaps you might elaborate on that.
It's not exactly plain text - this is troff format, some kind of markup language.
The whole point to a markup language like Troff is that it's basically plain text. And it's not like this should have been a surprise... this format is native to OS X, it's older than OS X, the Macintosh, or Apple Computer.
If Spotlight doesn't have an importer it should be able to fall back to plain text. At the very least there should be some place you can tell it how you want stuff indexed.
In fact, that is not a real example. If you were looking for the "man" manual page for "fork," you would open a terminal window and type "man fork."
And if I were looking for a mail message from "Joe Smith", I'd pull up Mail and search there, right? So why does Spotlight bother indexing mail. Well, that's because sometimes you don't know exactly where the information you want is, right? That's why you have a universal search in the first place.
The problem here is that it doesn't understand format of man pages in it's current state, so it cannot index content of man pages and this is rather disappointing.
Um, why should it need to "understand the format of man pages" to index it?
It's plain text. Plain text is about the most basic and common format out there. Most of my documents are in plain text, or formats I can't imagine Spotlight will have any way to deal with as anything more than plain text. If it can't index plain text, what good is it?
It also pointed out that "writing and installing kernel-mode code is vastly more complicated" than using an existing raw socket feature,
Yeh, that's why the majority of people doing this use an widely available rootkit or equivalent to do it for them.
and that if malware did make it into the kernel of a Windows machine, the user would have more serious concerns than just SYN attacks launched from their machines.
"If malware can execute code on a Windows machine, the user has more serious concerns than just SYN attacks launched from their machines. That's why Windows doesn't bother trying to close local exploits."
I remember "Steve Gibson" was bashed and debunked for talking about raw sockets in 2000 or 2001.
Indeed. Everyone pointed out that raw sockets were a basic tool, and how Steve was just plain wrong about where the problem was. Microsoft decided that this security problem was real and the design of IE was just fine. Doesn't that just bake your cookies?
Slashdot Mirror
However, it looks like redistribution of Minix is permitted as long as you keep the Minix license in the file.
That is from a later release of Minix than the one available when Linus developed Linux. At the time he did so, Minix was a commercial product from P-H, with strict limits on the number of copies you could make.
It doesn't matter, because Linux is not derived from Minix, see my previous comment for details of why.
"When you have task-switching, a file-system, and device drivers, that's Unix" -- or at least its kernel. Linux was born."
That not only describes the process, but makes the point that Unix is fundamentally a set of ideas, not a bunch of computer code -- and exactly how you implement those ideas isn't all that important.
Virtually every operating system created since around 1980 has a file system that is functionally equivalent to the UNIX file system. Maybe it has enhancements or maybe it's implemented differently or has different data structures, but it provides the same kind of files and the same kind of operations on files. The only exceptions I can think of are the original pre-HFS Mac file system, and MS/DOS before 2.11. All the rest: NT, OS/2, AmigaDOS, Windows, BeOS... they have all copied the UNIX file system.
Multitasking? There's a FEW more exceptions there - you can add GEM to the list, for example - but again virtually every OS has that.
Device drivers? Guess what?
UNIX is more than those things. Now, I personally consider it to not be a whole lot more, but that's because I'm only interested with whether I can treat the OS as basically UNIX (perhaps with frills) and from that basis successfully use it, configure it, write code for it, and so on. I don't know what Linus' definition of UNIX is, but I can't imagine it's as broad as Mr. Murphy implies.
But that's not the domain we're in here. We're in the domain of the law, and in that domain UNIX has a specific definition, one for which this fragmentary comment of Linus (presented out of context) has no relevance even if it was meaningful.
And Murphy is making a much stronger claim than that:
The reason Tannenbaum apparently gave Linus a "C" for his kernel hack probably wouldn't have been that the code was bad or derivative, but that he disapproved of sacrificing design elegance for a performance benefit available only on the x86.
The reason Tannenbaum gave Linux a metaphorical C was that the design of the Linux kernel was radically different, from the ground up, from Minix. There was not only any Minix code in it, there was nothing in the design that contained any elements of the design of the Minix kernel. Claiming that Linus based Linux on the Minix kernel because it provided the same basic functionality is like claiming that an electric car must be using a gasoline engine because it has four wheels and a driver's seat.
The microkernel-versus-monolithic-kernel distinction, which was the basis for the infamous Torvalds-Tannenbaum debate, is probably the biggest distinction you can make between kernel implementations in an OS today. There is no easy way to take a kernel of one kind and turn it into the other. The best one can do without doing far more work than simply starting from scratch is to embed one in another, the way single-server Mach-based kernels like Tru64 or Mac OS X do it, like a kind of hybrid gasoline-electric car.
And Linux isn't any such thing. The most casual inspection of the design, even if you weren't aware of the contempt Linus holds for such schemes, would tell you that.
No, there's far more similarities between the OS/2 kernel and the Linux kernel than between the Linux kernel and Minix, and yet nobody would claim Linus based Linux on OS/2. The similarities between Linux and Minix are all in the sheetmetal and steering wheel, the wheels and tires. NOT the engine.
Torvalds was working in an open, academic environment within the scope of both Tannebaum's intent and the Prentice Hall source license for Minix.
This is irrelevant: if Linux was a derived work of Minix it would still be subject to the Prentice-Hall license, which did not permit unlimited redistribution.
Murphy argues Linux is a derived work of Minix because (he claims) Linus started with the Minix source tree and modified it until he had removed every piece of original code, but that this relationship is irrelevant because of Prenti
When any two idiots can burn 8GB of random data onto two DVD's and send secure text messages to each other for the rest of their lives, what the hell use is a complex physically secure network like this one?
Copying data from a DVD that you've intercepted or otherwise gained access to isn't hard. Once you've done that you can not only read any new messages they send, you can decode all the old messages you've already intercepted. And they have no way of knowing you've stolen the pad.
Excuse me Sir, did you vote Nixon in 1972?
Hard as it is to imagine, the current US president makes me nostalgic for Nixon. Seriously. I don't think the US has had a president like George W Bush since Andrew Jackson promoted "spoilsmanship".
in the future this technology may be used in devices to detect bioterrorism chemicals
I call the authors cynical, beabling on about "Homeland Security" because that's currently a good way to get funding.
I think this is going to be more useful for medicine, as another tool for quicker and more accurate diagnostic tests.
At any rate, you are of course right that there is more to it then just a scheduler and priority management.
Which I think is where I boarded this train...
I'll just say one thing about what UNIX is. UNIX is not Thompson and Ritchie's source tree, UNIX is a family of operating systems that provide a common core set of system calls as their native API. FreeBSD is UNIX. Linux is UNIX. OS/9 and QNX and Regulus are or were UNIX. Interix is a hosted UNIX.
UNIX-like? You have to dig pretty far these days to find an OS that isn't UNIX-like, that hasn't mined UNIX heavily for its design. Wherever your file system is a directed graph, wherever file names are simple strings with no internal structure, wherever files are a simple stream of bytes, wherever you use the same system calls for all files, wherever the shell is just another program, there's another system that's borrowed from UNIX. Because all these things were controversial innovations that UNIX was mocked for using, they were slapdash lazy ideas that real operating systems with structured disks and structured files and user areas and monitors and job control languages would never consider. Creating processes willy-nilly? Inefficient! Flat files? No record management services? Never catch on!
OS/2 is a UNIX-like OS, so are NT and BeOS and AmigaOS and, well, you have to go back to VMS or look in an IBM dinosaur pen for something that isn't.
I heard they were putting flash into PDF, but into a CAN? Is the world ready for animated product labels on grocery shelves?
They've renamed products before because of conflicts like this.
They don't have a file extension or a uti which means Spotlight can't touch them.
Neither do most of my files. Finder doesn't seem to have any difficulty opening them as text files, though.
The entry "A Bedtime Story" actually does more to explain what the hell is UP with people in the Empire than all five of the movies put together.
Then, realtime class != realtime priority. Priority of realtime class processes in handled differently, but is not exactly higher.
Ah, beg pardon then.
OS/2 has a monolithic kernel as well, that has nothign to do with this whatsoever.
OS/2's kernel is not really similar to the traditional UNIX monolithic kernel. The original design had no kernel threads at all, let alone any way for a driver to schedule any, and virtually all traditional UNIXes (including Linux) use the same model today.
The thing that has everything to do with this is deciding which of the processes that is runnable at a given moment gets time.
We're not talking about processes competing against processes, we're talking about processes competing against device drivers. UNIX device drivers are not processes, tasks, or threads, and they are not scheduled, they are not handled or managed by the scheduler. The interrupt handler (lower half) triggers what's effectively a "software interrupt" that handles the longer term operations in the kernel context but doesn't normally involve a switch to a different process context. The scheduler doesn't "see" the driver at all.
Fixing that is a problem that would need to be dealt with before any change in the UNIX scheduler could have any effect on contention between I/O and CPU.
The guy who hates his ex-girlfriend but is still talking about her years later.
That's because this "ex-girlfriend" is inescapable. We can't turn around but she's there, hammering on our firewalls, following us to work, annoying our friends and relatives and even living in their houses... and talking them into trying to get us back together again "just this once, she really needs your help, I think she has a virus."
If someone claims two applications of a new technology that are so extremely unrelated to each other in one sentence I find it hard to take him/her seriously.
Yeh, it's easy to respond to someone says or the care they take with their messages, instead of digging deeper, and get the wrong impression.
Screening airport baggage would be a lot easier with a small portable radiation source that could be used to make the existing scanners lighter. This is a smaller neutron source than ones currently used.
The efficiency of a reaction drive in a spacecraft is better the higher the velocity of its exhaust, other things being equal. Again, a small light radiation source could be used in a low-power high-impulse drive. As I understand it, this device isn't particularly efficient at the moment but that might not be an inherent problem.
I don't think I see how it could be used for automobile propulsion, perhaps you might elaborate on that.
It's not exactly plain text - this is troff format, some kind of markup language.
The whole point to a markup language like Troff is that it's basically plain text. And it's not like this should have been a surprise... this format is native to OS X, it's older than OS X, the Macintosh, or Apple Computer.
If Spotlight doesn't have an importer it should be able to fall back to plain text. At the very least there should be some place you can tell it how you want stuff indexed.
In fact, that is not a real example. If you were looking for the "man" manual page for "fork," you would open a terminal window and type "man fork."
And if I were looking for a mail message from "Joe Smith", I'd pull up Mail and search there, right? So why does Spotlight bother indexing mail. Well, that's because sometimes you don't know exactly where the information you want is, right? That's why you have a universal search in the first place.
OK, now I'm confused. If it can't index plain text files, why is it indexing /Developer/Examples/Xgrid/GridMandelbrot/GMMainWin dowController.m ???
The problem here is that it doesn't understand format of man pages in it's current state, so it cannot index content of man pages and this is rather disappointing.
Um, why should it need to "understand the format of man pages" to index it?
It's plain text. Plain text is about the most basic and common format out there. Most of my documents are in plain text, or formats I can't imagine Spotlight will have any way to deal with as anything more than plain text. If it can't index plain text, what good is it?
It also pointed out that "writing and installing kernel-mode code is vastly more complicated" than using an existing raw socket feature,
Yeh, that's why the majority of people doing this use an widely available rootkit or equivalent to do it for them.
and that if malware did make it into the kernel of a Windows machine, the user would have more serious concerns than just SYN attacks launched from their machines.
"If malware can execute code on a Windows machine, the user has more serious concerns than just SYN attacks launched from their machines. That's why Windows doesn't bother trying to close local exploits."
Advanced users are going to have an Administrator or root account on the Windows machine and therefore should have access to raw sockets, no?
Most users who want to do stuff like install software and play games are logged in to that account at all times anyway.
I remember "Steve Gibson" was bashed and debunked for talking about raw sockets in 2000 or 2001.
Indeed. Everyone pointed out that raw sockets were a basic tool, and how Steve was just plain wrong about where the problem was. Microsoft decided that this security problem was real and the design of IE was just fine. Doesn't that just bake your cookies?
D-M-C-A... just watch out for the D-M-C-A
Young man, young man, are you listening to me?
Young man, young man, even this parody is illegal.
Not only is it a dup(), but it fork()ing accept()ed the bogus conclusion from the NYT pipe() about it being an energy /src/.
You'd probably need to use Flash for that.
And i am not implying any wrong doing i am infact quite impresed and just a bit impatiant as i would like to enjoy these enhancments asap.
You have the source to Konqueror, you have the patches, you have a compiler, what else do you need?
Optimise for corner cases, and it possible that all you'll get are really well rendered corner cases.
In fact getting the corners rendered correctly was one of the cases that he had to fix.