Slashdot Mirror
Linus vs Mach (and OSX) Microkernel
moon_unit_one writes "Linus Torvalds apparently doesn't think much of the Mach mirokernel and says so in his new autobiography called Just for Fun: The Story of an Accidental Revolutionary. See what he says in this ZDNet UK article." The age old mach debate resurrected once again. Anyone have the old Minix logs with Linus? Thats a fun one too.
Quite wrong you are, I'm afraid.
Darwin (and hence macosx) run the mach microkernel, and run a monolithic BSD 4.4 derived server process. This gets you all the disadvantages of a microkernel (more overhead) and all the disadvantages of a monolithic kernel (different subsystems in the kernel can scribble all over each other). The only advantage is the microkernel buzzword.
To see more reasonable microkernel designs, look at Windows NT (before version 4.0 only), QNX, and BeOS (except they've been backpedaling a bit recently with the network stack). To see another example of the same kind of stupidity that Darwin shows, see xMach or mkLinux.
Where's my 200 MIPS 64M Sparcstation-5?
I feel cheated
,dirty
and used.
MacOS X's hardware requirements are, I suspect, 'so ludecrous' because they didn't want to take the time and money to support X on older machines with completely different architectures, motherboards, collections of drivers, versions of Open Firmware, blah blah blah blah blah.
However, there were, within a week of X being released, two well-known hacks for getting X running on older machines. It works all right, for the most part. (Check out www.xlr8yourmac.com, there are links to these on there somewhere.)
Sheesh. Post something on Slashdot and you immediately have three dozen people who are 'experts on the subject' pop out of the woodwork. Problem is, you have to figure out which of them actually has half a clue.
And any comparison of OSX to anything when you have to run a great deal of your existing software in OS-9 mode is just foolish.
IMHO/YMMV
Put down the crack pipe! This statement is utter bollocks.
Had they adopted a "virtual box" approach as Apple has, they'd probably have a much better OS today.
This is exactly what they did with NT around ten years ago. DOS and 16-bit windows apps run in a shared but separate memory space from the rest of the system. In fact, you can run multiple copies of these 16-bit subsystems if you want (for different memory or environment settings, or just to protect programs from each other).
It's called Windows On Windows, and it's what those wowexec entries are in task manager.
threads ("processes are faster", sez he)
Ummm... no. If anything, Linux has done away with processes. Linux processes are kind of a fattened up version of the fundamental schedulable kernel entity -- what is typically called a kernel thread. I.e., at the kernel level, thread and process are built from a common abstraction. Among other things, that means that userland context switches between user processes and between user threads occur at much more similar latencies than in most other OSes (e.g., traditional UNIX or NT.) That means that, while Linux fully supports kernel threads, 1:1 user/kernel threads (aka LWPs), n:1 user threads, and IBM is working on n:m threading, developers are not forced into choosing multi-threaded applications as soon as they are with many other OSes. There are definite design tradeoffs between multi-threads and multi-processes, and Linus is well aware of them.
message-passing
Care to provide some evidence that Linus categorically rejects message passing? Or that message-passing necessarily pays context switch costs? Else I just see an architect making a reasonable design choice.
version-control systems
Then why was he seen at the just completed Kerenl Developers Conference paying considerable attention to two different version-control systems proposed for use by Linux kernel developers? Yes, up until now he hasn't seen a clear cut case for using CVS and its inherent compromises of the development culture that has grown up around the Linux kernel; perhaps you'd care to argue with the success of that development effort?
I followed the links and read. I saw nothing that supports your claim. All I saw was Linus posting his opinion of commonly accepted facts and someone claiming counter without any substance; though well thought. In short, everything there looks like two people talking and NOTHING more. Perhaps I should take the same pill that you did before I read it next time....
NT was never a strict microkernel system, and the modular architecure was in no way compromised by the decision to move GDI/USER from a protected-mode subsystem into kernel mode (and, actually, portions of GDI relating to printing were moved from kernel mode into user-mode client processes in Windows 2000).
NT does use certain aspects of a microkernel: the division of the system into various modules (servers in Mach terminology, subsystems in NT terminology), and the ability to support multiple OS personalities concurrently. However, most performance-critical components (e.g. the I/O Subsystem, including the networking code) have always run in kernel mode (the exception was the video display software, although portions of it ran in kernel mode from the start).
Even though a lot of NT runs in kernel mode, it remains fundamentally modular in design (it would be easy, for instance, to move most modules into user-mode subsystems), which is the main thing that differentiates it from UNIX/Linux. It also remains very architecture-neutral, unlike Linux (much of which has to be re-written for each 'port').
The comment about moving GDI/USER to kernel mode contributing to instability is mostly wrong. GDI/USER ran in a system-critical process in NT 3.x, and if that process crashed (it never once did in all the time I used NT 3.x), it would bluescreen the system. What really caused problems for NT 4.0 was that it was much more popular than 3.x, so many more third-party hardware drivers were available. Unfortunately, most hardware developers had no experience with NT, and were used to Windows 3.x/9x, where performance/features were generally valued above stability. As a result, a lot of these third-party drivers proved to be of poor quality (especially video drivers), hence the major push towards driver signing and testing/verification in Windows 2000 (which has been further advanced with Windows XP). Even now, you'll often see video companies offering unsigned (i.e. buggy) drivers with all the new features supported, along with signed (i.e. stable) drivers which lack support for a lot of features. Users who care about stability either choose the latter, or stick with drivers supplied by Microsoft (which are generally rock-solid).
You could also consider NT. The NT kernel was mostly written in 1989 and 1990 by half a dozen developers, and has been largely unchanged since then. All the graphical Win32 stuff took a lot of effort after that, so the full Windows NT system wasn't released until 1993 (and Win32 has evolved considerably since), but the NT kernel itself, which is analogous to Linux, was developed rapidly and correctly. From the start, the NT kernel supported SMP, Unicode, threads, multiple OS environments, a modular architecture and other modern features. After more than ten years of development, the Linux kernel's SMP support isn't as good as what a small team of NT developers produced more than a decade ago. Similarly, multi-language support in Linux is generally very poor, lagging not only behind NT, but behind commercial UNIX as well.
If your only measure of success is survival, then yes, the Linux model has been able to survive, but it's obviously one of the worst ways to manage development of an operating system.
Before joining Microsoft in September 1991, Dr. Rashid held the position of professor of computer science at Carnegie Mellon University. After becoming a CMU faculty member in September 1979, he directed the design and implementation of several influential network operating systems, and published dozens of papers in the areas of computer vision, operating systems, programming languages for distributed processing, network protocols and communications security. During his tenure at CMU, Dr. Rashid developed the Mach multiprocessor operating system. The Mach operating system has been influential in the design of many modern operating systems and remains today at the core of a number of commercial systems.
One of the biggest advantages of a microkernel comes when you have multiple processors. Since the microkernel itself is restricted to a set of core operations, it's far easier to scale to multiple processors. However, most users still use only a single CPU (and an x86 to boot), so that advantage never panned out. Also, SVR4 and SunOS 5 proved that you can redesign a monolithic kernel in such a way that it provides solid SMP support. Nevertheless, after years of tinkering, Linux and BSD still aren't as good at SMP as microkernel-based systems designed and implemented more than a decade ago.
Microsoft is aggressive at selling Microsoft products, of course, but is perfectly happy to support profitable platforms besides Windows (e.g. Mac OS).
Microkernel vs Monolithic System Most older operating systems are monolithic, that is, the whole operating system is a single a.out file that runs in 'kernel mode.' This binary contains the process management, memory management, file system and the rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, MULTICS, and many more. The alternative is a microkernel-based system, in which most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing. The kernel's job is to handle the message passing, interrupt handling, low-level process management, and possibly the I/O. Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the not-yet-released Windows/NT.
Lets look at his examples of 'the future' of operating systems:
RC4000 -- wow, now there's a winner.
Amoeba -- research toy.
Chorus -- ditto
Windows NT -- saw very little success until they ditched the microkernel and moved networking and GDI/User into the kernel.
Mach -- are there any mach based OSes that don't run just one monolithic uber-server under mach?
How about some examples he didn't give (they wern't around yet, or were off his radar for various reasons):
QNX -- in the top 5 in the RTOS market, attempt to push into desktop market (by bizzare scam involving the 5 remaining amigans) seems to have petered out.
BeOS -- desperately searching for a market. Claim to fame is scheduling latency, but has been outdone there by both QNX (obviously) and Linux.
As if we needed more reasons not to ask academics for real world advice.
You completely neglected where microkernels have their real advantage.
SMP and reliability.
In a 'clean' monolithic kernel, the entire kernel is locked when processing. This is perfectly fine in a uniprocessor case. But for multiprocessor systems, it sucks bigtime because your other processors are sitting in a spin-loop waiting for the kernel lock.
Now the obvious way around that is to create exceptions to the rule. But that quickly becomes a nightmare to maintain. I'm sure that this is major reason the reason the 2.4 kernel was so very late.
Now if you purport that we'll be stuck with uniprocessor or 2way processors for a long time. Thats very shortsighted. I see 16way systems moderately commonplace in 4-5 years. Linus doesn't really deal with huge n-way systems, so thats probably where is lapse comes into play.
Now the reliability aspect of a microkernel comes from its rigid policies - making code proofs&verification easier to do. The spaghetti code monolithics that i've seen, heh, as with verifying any spaghetti code, good luck!
It should also be noted that there is not a black-and-white distinction between a monolithic kernel and a microkernel. Any well-engineered design should have trade-offs to perform well in many environments. For instance, some microkernels give a pass to the graphics code running in kernel space. And monolithics will implement some message passing thing so that the network drivers play nice with everyone else.
Tom
Torvalds seems to be busting on Mach and microkernel architecture in general (which is hardly news), not Mac OS X itself, though it's hard to tell from the mucho-sketchy article. If he's truly referring to the implementation of Mach in Mac OS X/Darwin, however, he hasn't done his homework. Yes, Mac OS X is based on Mach, but it isn't running a true microkernel. It's closer to being a so-called "message-passing kernel"--a monolithic-microkernel hybrid. From Apple's Inside Mac OS X: Kernel Environment (PDF, Google-ized text-only version)
Because of its hybrid nature, the Xnu kernel in OS X provide some of the architectural benefits of Mach without as much of the overhead. Of course, you needn't take my word for it. Apple goes into greater detail in the PDF, and the kernel's design is documented elsewhere on the Web as well.
I've noticed the advantage of open source is that your users can be programmers at the same time. Users who are programmers can be massively more helpful for certain types of bugs.
Well, considering that GNU HURD is still not exactly ready, I don't think I'd call 10 years "close to not being around".
The more you know, the less you understand.
heh. si, for such a stupid piece of shit you sure can be funny sometimes.
"shop smart:shop s-mart" ash
The reason it's so slow is that the CPU is being forced to do almost everything for Quartz. By MWNY, Apple should have Quartz sending most of that shit to the 3D card to do all the vector graphics. This should eliminate all the slowness with resizing and scrolling.
.2 release(or in this case, 10.1, which should be at MWNY. .1 = .0.1, and .2 = .1)
Other slowness is just Apple needing to optimize. They are working like NeXT used to, and will optimize for speed on the
Oh they tried, they tried for the better part of 10 years make that happen, and finally gave up, settling on Rhapsody for new apps and BlueBox (now known as Classic) for legacy apps.
The stroke of genius that is allowing Apple to perform the impossible for a second time (ie a major architechural change without more than trivial backwards compatability issues) is Carbon. A subset of the old API which can be multithreaded and memory protected. So, rather than ask Adobe to rewrite Photoshop, Illustrator, et al. from the ground up, they only have to tweak the existing code a little, recompile, and they've got an OS X app. I'm sure that in time Photoshop will be rewritten with the Cocoa API, as will many other major apps (ProTools, with it's...memory issues...almost certainly requires it) but Carbon puts a stepping stone in the middle of that river so that everyone can migrate at a speed more in line with their comfort level.
Don Negro
Don Negro
Perl 6 will give you the big knob. -- Larry Wall
The fundamental problem is hardware. Task switchs, under *any* OS, take a long time.
At the time of the Tannenbaum/Torvalds debate, the primary CPU in use was still the 386- which took 300 to 500 clock cycles to task switch. No, that's not a typo- three to five *hundred*.
The situation has imporved enormously- Pentium class CPUs only take ~50 clock cycles to task switch. Of course, this is disregarding any TLB misses which are incurred.
The task switch overhead is what caused NT to move the graphics calls into kernel space in 4.0 (causing a large improvement in performance and a huge decrease in reliability). The hardware costs of task switching is what kills "true" microkernel OSs on performance. And don't bother to whine about "poor processor design"- people (including me) want an OS that runs well on the hardware they have.
The best operating systems are the "mutts"- not true microkernels nor true monolithic kernels. Which is how linux evolved- kernel modules for many if not most things, virtual file systems, etc.
Apparently there's an issue with lack of memory protection? I can't believe that would be true, I certainly haven't read anything about it in the reviews of mac os X
OS X has memory protection. The old MacOS doesn't. The problems will be with old apps that 'got away' with memory violations from time to time (due to dumb luck in some cases) and seemed OK. Now, they will die on a SEGV. That's a good thing since they were broken from the start, but will take some fixing.
Not that there's a sharp line once you have loadable kernel modules.
There's still a sharp line. Modules in Linux have very little to do with microkernel. In microkernel, the equivilant of modules would be more like daemons.
f all the apps on an OS were written in a language that didn't allow arbitraty pointer arithmetic (like Java, etc.), and the compiler was trusted (and not buggy) then seperate address spaces between apps (and the kernel) are not necessary.
Someone somewhere will find a way to assemble badly behaving code (deliberatly or not). We might as well call passwords and firewalls unnecessary because all we really need is an internet where people don't go where they're not invited and don't try to crash servers.
n a 'clean' monolithic kernel, the entire kernel is locked when processing. This is perfectly fine in a uniprocessor case. But for multiprocessor systems, it sucks bigtime because your other processors are sitting in a spin-loop waiting for the kernel lock.
The issue of lock granularity is not really a micro vs monokernel. Linux 2.0.x had the big kernel lock, and SMP suffered a good bit because of it. The newer kernels are much more finely grained.
microkernel doesn't make that issue go away. Taking a sub-system out of the kernel and making it a user process doesn't eliminate the need to access it's data serially, it just shifts the problem to the scheduler. In effect, it turns every spinlock into a semaphore. The Linux kernel uses semaphores now for cases where the higher cost is offset by the benefit of having the other CPU(s) do something besides spin. The spinlocks are used in cases where the cost of trying to take a semaphore (failing and going it the queue) are higher than the cost of spinning until the lock is released.
However, all of that is incidental to the defining difference between a mono and microkernel.
Now if you purport that we'll be stuck with uniprocessor or 2way processors for a long time. Thats very shortsighted. I see 16way systems moderately commonplace in 4-5 years.
I purport no such thing. While I do expect to see more multi-processor systems, I don't think they'll be SMP.
Now the reliability aspect of a microkernel comes from its rigid policies - making code proofs&verification easier to do. The spaghetti code monolithics that i've seen, heh, as with verifying any spaghetti code, good luck!
Microkernel does tend to force cleaner and sharper divisions and interfaces. The same thing can and SHOULD be done in a monokernel, but temptation to bend the rules can be quite strong.
It should also be noted that there is not a black-and-white distinction between a monolithic kernel and a microkernel.
Agreed completely! There's nothing I hate more than a system design with an acedemic axe to grind. There are a few places in the Linux kernel where a very microkernel-esque approach is taken. CODA comes to mind. Also NBD. We also see the opposite in khttpd.
In that sense, monokernel itself is a compromise on the spectrum between completely monolithic systems (mostly embedded systems, Oracle on bare metal, etc.), systems with no memory protection (on purpose!) and cooperative multi-tasking, monokernel, microkernel. I'm not honestly sure where to place exokernel on the spectrum.
I stand by the thought that the biggest potential advantage to microkernels is in cluster systems.
a) their small, minimalist design allows for fewer bugs, greater flexibility, etc, etc(all the old arguments you hear about them)...
No arguement about the flexibility. I look forward to one day having enough free time to play with and enjoy that feature.
The minimalist design allowing for fewer bugs is somewhat a red herring. By focusing on a smaller piece of code, you'll naturally find fewer bugs there vs. a larger piece of code (all else being equal). Once you add in the sevvices, the bug count is back up to where it was.
There is some benefit that at least the bugs are isolated from each other, and thus more limited in the damage they can do. However, if the service is a critical one, the system will still be dead.
b) the fact that very little code is in the kernel allows for better realtime performance. The less time that must be spent in kernel mode(where interrupts are disabled), the more time can be devoted to actual work and servicing devices.
Interestingly, RTLinux is a good example of that approach. It makes the entire kernel pre-emptable for the real time services.
L4 and EROS kernels are even faster than previous generation microkernels.
L4 is a good example of improvements in the area of microkernels. It's on my list of things to check out when I get that mythical free time. EROS is also very interesting. A microkernel with persistant objects to replace nearly everything! It's also on my list.
IMO, overhead penalty invloved with context switching in a u-kernel OS is totally worth it, especially for a desktop system. And QNX proves that it can be done right.
Our conclusions are not too far apart. I'm not so much saying that microkernel is bad or that it won't work, I just don't think it's time is here just yet, and Mach in it's current form isn't it. I do look forward to the HERD being ready for prime time. The 1.0 version will probably perform poorly vs. Linux, but it will provide a good platform to build from in the Free Software world. (yep, it's on my list :-)
I dunno, the article (mentioned by someone in an earlier comment) lists L3 at handling round trip IPC in 10 usec on a 50Mhz 486.
The equation is quite different for a 486 than a PIII. The real cost isn't in simply executing the instructions, but in effects from flushing the TLB and cache misses. On a 486 it's not as big of a problem since the memory compared to the CPU isn't as dismally slow as with a PIII (for example).
How fast do system calls need to be? (Really, I don't know) With "low end" machines at least 10 times that speed today, this doesn't seem like very much overhead at all.
Faster is better :-) It really depends on the application. Some number crunching apps read their data in one big gulp, then spend many hours just crunching without a system call in sight. IO intensive apps on the other hand will spend most of their time in system calls. Probably the worst hit in a microkernel environment are apps that are heavy on IO, but must actually look at the data they are moving. A database is a good example. That's why Oracle is so interested in running on the bare metal.
and where every cycle counts, you probly want EVERYTHING in the kernel, FULLY debugged. Not that that's possible or anything ;)
Absolutely! :-)
Is this not less of an issue with newer CPUs? Just look at the rate at which the CPU/bus speed ratio is increasing. Much of the time a modern CPU spends is spent waiting for data from memory (granted this depends on the application.) If the CPU has to spend some extra time switching between rings then it shouldn't have much of an overall impact on speed - much of it's time is spent waiting anyway. This will only increase in the future.
It's the context switches that kill, and the CPU to memory ratio makes it worse. Switching contexts churns the cache and causes more misses. One of the biggest optimization opportunities in a microkernel is minimising the cache and TLB effects of the task switches. A really tempting approach is to make the service run in the client process's context but in a different ring. That looks a lot like a highly modular monokernel.
I'm not even sure it is harder then making a CPU where the MMU can't be bypassed in user mode. Except for the one little detail that most people want more then one programming language (thus more then one compile), or that p-code is very slow.
Really it is harder. The MMU has the advantage that it can see exactly where things are RIGHT NOW, and make a decision. Code verifiers have to look at the initial state and prove that given that initial state, the code, and any possable input, it cannot generate an access that violates the segmentation. What you end up with is expert system vs a natural intelligence. In the case of accidental violations, its back to "Nothing is foolproof because fools are so ingenious."
Point taken, except the compiler (not code verifier) can choose to insert bounds checks, it just won't be "as fast".
The problem with that is that any user might compile a program, then hand patch the bounds check out of the bytecode (or just use an unapproved compiler). That might be malicious, or just someone who wants their code to run faster and is "sure" there aren't any bugs that require the bounds checking.
The MMU on a modern processor is a complex beast. Most of the complexity is for performance rather than bounds checking. It at least has the benefit that the basic concept of 'just in time' bounds checking is conceptually a lot simpler than checking by proof.
Evidence to the contrary need not be presented. At least, not until someone comes up with a reason for microkernels being bad/wrong/sucky.
Good point! The biggest problem for microkernels is that they have to switch contexts far more frequently than a monokernel (in general).
For a simple example, a user app making a single system call. In a monokernel, The call is made. The process transitions from the user to the kernel ring (ring 3 to ring 0 for x86). The kernel copys any data and parameters (other than what would fit into registers) from userspace, handles the call, possably copies results back to userspace, and transitions back to ring3 (returns).
In a microkernel, the app makes a call, switch to ring 0, copy data, change contexts, copy data to daemon, transition to ring3 in server daemon's context, server daemon handles call, transitions to ring 0, data copied to kernelspace, change contexts back to user process, copy results into user space, transition back to ring3 (return).
Those extra transitions and context switches have a definite cost. A CPU designed with that in mind can help (a lot!), but on current hardware, it can be a nightmare. That's why a monokernel tends to perform better in practice.
Kernel modules in Linux are nothing like microkernel. They are just bits of a monokernel that are dynamically linked at runtime. In order to be a microkernel, each module would be a process and would reside in some ring other than 0 (possably 3, but not necessarily). In order to fully realise the microkernel module, users would be able to do the equivilant of insmod and get a private interface. Other users might or might not choose to access that module, and might insmod a different version with the same interface. This would not present a security problem.
There may well be places where the overhead is a worthwhile trade off for the features (clustered systems might be a good example). Cray takes an approach like that (not exactly that, just like that) in mkUnicos for the T3E (possably others, but I've not used those).
Some microkernels do a better job at efficiency than Mach (L3 for example). At some point, the hardware might actually get fast enough that the trade-off is nearly always worth while. Even then, monokernels will still have a place for situations where every cycle counts I don't anticipate those situations ever going away.
One interesting thing to note is that the idea of porting MacOS over to the Linux kernel was presented....
The Linux kernel itself is incredibly mature, enoughso that it could be used in a modern operating system just as well as any other kernel. The Linux distributions that are out there admittedly aren't as friendly. Whenever you read "Linux", ask yourself "Linux OS, or Linux kernel?"
(note to the purists: Linux OS is abbreviated from Linux-based OS)
When talking about technical merits, it might be more valid to compare BSD kernel to Linux kernel. When talking about usability and friendliness, you're talking about MacOS vs. Gnome-KDE/X (basically).
Inconceivable!
The log from the Minix mailing list can be found in the book
Open Sources: Voices from the Open Source Revolution, Appendix A.
---
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
You are simply on crack.
The engineering choices made by Linus have not hampered the ability of Linux to make MonopolyWare look crappy and pathetic. Linux is already starting to cave in Microsoft's balls. If it weren't for the Lemming effect, Microsoft would never have lasted in the server market long enough for their share to be eroded by Linux.
The inclusion of Solaris into this discussion is simply pointless. It was never the intent of Linus to replace the likes of Solaris.
With the relative portability between Unixen in general, there simply isn't any need for a particular Unix to impose itself as a monopoly.
A Pirate and a Puritan look the same on a balance sheet.
What kind of drugs are you on?
You should really share.
Actually, Microsoft does really quite poorly with making it "just work". They have the entire PC industry conspiring with them and they still can't get it quite right much of the time.
OTOH, Linux has to depend on the kindess of strangers. If hardware vendors don't cooperate, Linux users have to develop their drivers THE HARD WAY. Microsoft never has this problem.
Also, this whole "recompiling the kernel" bit is simply the ingorant ramblings of a Lemming. Linux distros haven't required a full kernel recompile to enable sound for quite some time now.
That you bring up this little element of FUD merely demonstrates what sort of dishonest little troll you really are.
Linux has had kernel module based sound drivers readily available since before convential media outlets paid it any attention.
A Pirate and a Puritan look the same on a balance sheet.
Mebbe the guy that's trying to save money on hardware...
A Pirate and a Puritan look the same on a balance sheet.
...they didn't even smear it with Applesauce.
They smeared it with Nextsauce.
A Pirate and a Puritan look the same on a balance sheet.
So? So apple takes their old frontend and BOLTS it to the underlying mkisofs/cdrecord/burnlib infastructure that's in place on top. What's supposed to be the big deal? Apple ALREADY is supposed to have the good eyecandy.
This should not be a holdup for them.
A Pirate and a Puritan look the same on a balance sheet.
Actually, NT5 isn't all that. As a desktop, it seems to be LESS stable under some light loads than Win98. Meanwhile, NT server marketshare in general is still relatively stagnant.
OTOH, Linux gets more usable by the day. Meanwhile, we wait for Win/DOS/NT to get genuinely stable while hoping that we don't need to buy new hardware just to the next forced upgrade.
This is the 3rd major version of NT that was promised to be a Unix-killer and Unix is still alive and well.
The stock market doesn't alter this.
A Pirate and a Puritan look the same on a balance sheet.
Apple's little OS installs easily on a CONSOLE, how impressive...
Make a no-option Linux installer and only target one set of hardware and it will get similar results.
A Pirate and a Puritan look the same on a balance sheet.
Quite.
Microsoft has to deal with thousands of possible random combinations. Whereas Apple has a nice short list of supported models. Most of them are variants of each other.
When a MacOS install can succeed in the fact of ISA and VL cards, not to mention generic hardware you've never even heard of, then wake us.
A Pirate and a Puritan look the same on a balance sheet.
...yet you mention none of these areas where Linux is substandard.
A Pirate and a Puritan look the same on a balance sheet.
Unix does infact have better application mobility than does Win2k. That whole "symlink design flaw" is actually a handy way to address the problem if the application is poorly coded.
However, even problems such as those are imposed by the developer and not by the system itself. The fact that Unix applications don't depend on a toy database make them more robust in general. The greater likelihood that you can safely move a Unix application is merely a side effect of this.
Also, Unix applications are less of a black box. If an application is tied to it's place in the filesystem in some way, it's usually quite a bit more obvious. Other dependencies are also typically less hidden. ldd is a great example of this.
The WinDOS problem is not just overcomplicating things but trying to hide all of those details from the end user.
A Pirate and a Puritan look the same on a balance sheet.
Actually, Linux is MUCH more relevant to the common man than the designer of the Corvette. The common man is MUCH more likely to be using the result's of Linus' (directly or indirectly) work than a Corvette.
This is true of ANY server OS.
A Pirate and a Puritan look the same on a balance sheet.
As a Unix user, I have a wider choice of what alternate platform I might run should I decide to suddenly dump my PC. This is the real "problem". Does anyone really want to dump their PC over Apple OpenStep? This is true for Unix users as well as PC desktop users.
Alphas and Sparcs are cost competitive these days. There's no reason to limit onesself to PPC. Unless you work in an area that was currently Apple dominated, the 3rd party support issues could favor either platform (Linux/x86 vs. Apple).
A Pirate and a Puritan look the same on a balance sheet.
...which is the same as the Microsoft Windows GUI circa 2001? Big deal?
The Mac GUI is an imitation of NeXTstep circa 1988. Your delusion of progress isn't consistent with reality.
So's my Linux GUI but you're to ignorant to be aware of such things.
A Pirate and a Puritan look the same on a balance sheet.
I could be wrong but I believe QNX managed to get much faster context switches on 486's.
sigs are a waste of space
no, but then who would have been able to imagine linus working paul allen?
I remember, back when I was a kid, walking through the video store and looking at the covers of all the cool movies I wanted to watch.
There was one in particular that stands out.
It was called "The Exterminator". The cover had this arnold schwarzeneger looking guy in fatigues with this huge flame thrower, trying to blow torch the camera taking his picture.
I used to look at that picture and think, "damn, that guy must be trying to start a flame war."
I get the same feeling when taco posts stories like this.
This is, of course, exactly the same technique that NT4 and 2000 use for 16 bit apps.
Let me note here that this approach is inferior to the one OS/2 took for running DOS and win16 apps. It can give all those apps their own protected memory space so that they are not only separated from modern apps but also from each other. The "shared-memory-space" approach was also an option, of course this requires less memory.
"Somehow I feel that Linus' viewpoint would be slightly different than the average web reporter reviewing MacOS X. There's a big difference between educated users and Uber-developers/Kernel hackers."
Linus doesn't have any deeper insight on this than any semi-informed correspondent. Almost every review has pointed out these problems, by noting that "Classic" apps don't take advantage of OS X's "advanced features", such as protected memory and pre-emptive multi-tasking.
"Also, I'm sure the reviewers have mentioned lack of support for CD/DVD stuff... That's what this article infers is being affected by the memory protection."
That is not what the article implies, although it does seems to be what you inferred. The lack of support for DVD playback has nothing to do with memory protection. It has to do with development time: there wasn't enough. There is no technical reason why OS X cannot support DVD playback and CD burning, these are just features which weren't added in time for the March 24th launch date.
Come on people, read The OS X Kernel docs. BSD, the file system, networking and mach all live in the same address space: it's not implemented as a microkernel.
Having a kernel based on Mach and having a monolithic kernel is not a contradiction. It is simply that Darwin's kernel can be described as 'Mach+BSD+Apple extensions' and is therefore NOT a microkernel.
Linux: My SBLive and Ensoniq 1370, and generic onboard sound card (Chips&Technologies???) are all detected and configured out of the box.
Windows 2000: 2 of these work out of the box
WinME/Win98: None of these work out of the box
Everybody's experience is different but I haven't recompiled a kernel for sound support since 1998.
No, not at all. Linus' dislike of Mach has been known for *years*. When I first heard his complaints, I wasn't entirely convinced. Mach appeared to offer so much, but as time has progressed, I've foud myself siding with Linus more and more. An OS is the one place where you really don't want extreme flexibility at the expense of performance.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Linux isn't so monolithic these days. Its been possible to add and remove klm on a live Linux box for quite a while now.
If you look at the changes in Linux from 0.1 to 0.9 to 1.x to 2.x, I think it's pretty clear that its been moving from a plain mono-kernel to a hybrid kernel.
It's no different than AMD using RISC like features in the Thunderbird CPUs and Moto using CISC like functions in the PowerPC chips.
Even if a modern CPU can task switch faster, wouldn't the much higher difference between CPU and memory speed as we see today make task switch even worse?
The thing is you will not be a happy user you have a buggy device driver for video/disk/network no matter what kind of kernel you're using. So does it really matter if a device driver can bring down the kernel?
Kill'em! Kill'em all!
Er, what?
If it is an old app it will run under classic with the other old apps, and have no memory protection.
If it is a new app one assumes it will be debugged under OSX and not get through QA with a ton of memory violations. (that's not guaranteed, it could use the Carbon API, and have been debugged under OS9, and "assumed" to work under OSX -- but I think you can check the "run under classic" box for them if you really really want).
Clearly it isn't easy to do it right because so many JVMs have screwed up. Boroughs has been doing it for a long time, and even they have some failures 20 or so years back. But it isn't impossible.
I'm not even sure it is harder then making a CPU where the MMU can't be bypassed in user mode. Except for the one little detail that most people want more then one programming language (thus more then one compile), or that p-code is very slow.
Actually the local computer stores sell Wintel boxes for $599, I forget how much RAM, but they have a 1Ghz CPU, which sounds better to Joe-sixpack then anything Apple offers in the iMac (unless they are sucked in by the look). Of corse you will have to add a monitor to the WinTel box, but that is still cheaper then the iMac.
That's for sure. That's why I own a Mac for the first time in my life. My OSX PowerBook G3 makes a better web surfing toy then my Viao with Win98 did.
P.S. I find it amusing that Apple spell checker (which the web browser can use) knows what a Mhz is, but not a Ghz. :-)
Point taken, except the compiler (not code verifier) can choose to insert bounds checks, it just won't be "as fast". (after all, the MMU is merely a bounds checker with some extra grot to send "well formatted" messages on violations)
On the other hand the MMU has a ton of difficulties as well. If you look at pipeline diagrams of modern CPUs the MMU tends to get a full pipestage, or two. It is one of the more complex parts of modern CPUs. The transistor count is behind that of a decently sized cache, but (including the TLB) ahead of everything else. The raw complexity it probably behind the modern reordering systems, but ahead of pretty much everything else. It is insanely complex.
On the Bouroghs system, and the IBM AS/400 machines executable are not editable at all. I don't recall if root can edit them or not, or if they are actually uneditable, or if they stop being executable when they are changed (much like the set-uid bit on Unix OSes).
Exactly. The complexity in compiler based bounds checking is also all in the attempts to make it fast. Otherwise it would just add two (or more) CMP and Bcc instructions (or whatever the equivalent for the CPU is) before each memory reference.
Yes it does. Although it has to rely on a normally fairly complex OS to set the MMU up right (and with some CPUs handle TLB shoot down, and cache invalidation).
I'm not so sure. It's pretty darned clear that for (at least short term) success Apple needs to be able to eventually convince three important constituencies to move to OSX: their current userbase (who need Classic to run their dusty-deck apps), their current developer base (who need something like Carbon to preserve at least part of their existing codebase), and new developers (who get all hot and bothered over a neat API like Cocoa.) The flexibility of Mach is what allows them to provide all those personalities in a workable fashion.
I'd like to have a "never launch classic" checkbox, so this doesn't happen.
I was thinking the exact same thing earlier. I'd call this an "excellent shareware opportunity."
I don't know - I'd agree that OS X is a giant step backwards in UI. Aside from eliminating some of the nicer features that took years to evolve on the Mac with features that never even had the opportunity to grow on NeXT, the graphics system is so bogged down now that responsiveness is poor, which is a major screwup when it comes to good UI. (or else users tend to overcorrect, or perceive the system as slow even if it's only the graphics that are, or think it hangs)
I mean, I've been putting together a list over the past couple of weeks and the UI flaws outweigh UI improvements by about 10:1.
As for Quartz, DPS was often very slow at many things, so I'm hardly surprised. But try running the little Quartz utility in the dev tools. You'll see what thrashes around on the cpu and what doesn't, and how slow it can get.
Lastly, I've had maybe 10 freezes and 2 kernel panics with totally vanilla hardware.
OS X is a lame, lame OS. It's keeping me on MacOS 9 for now, for despite the crashiness, it's _useful_. The future will likely be Win2K, which is at least no worse than OS X, and a lot cheaper all around, with more stuff and more of a future, despite the evilness of the parent company.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
And I had a home system that never crashed under 9, and a work system that crashes routinely under 9. If someone asked me 'Is 9 stable?' I'd tell them no: i've seen it crash way too much to call it stable.
And I'd have to give the same answer for X. I have no doubt that some people will never get a crash or a lockup or anything. But if you can thump on it hard enough and get one, that makes it basically unstable. Given that I'm not even doing anything intensive on the X system that I'm trying out (like booting, which has panicked twice) there really should not be crashes.
It's not an acceptable piece of software for many reasons, and the one advantage we've been sold on for a decade hasn't even materialized.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
So basically, it'll still be another few months from release to when it's done. Isn't it funny how OS X is NEVER done? Ever? Hell, it was supposed to be out in '99, but Steve weasled his way out of it with OS X Server.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
So basically, it'll still be another few months from release to when it's done. Isn't it funny how OS X is NEVER done? Ever? Hell, it was supposed to be out in '99, but Steve weasled his way out of it with OS X Server.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
Erm, mach is a microkernel.
-sjf
Torvald's notoriety is much greater than his actual contribution. Linux owes more to GNU than Linus.
OSX isn't mach. Mach started life as an academic project, just like, erm Linux. It was an experiment: would this microkernel approach work ? It wasn't an optimised, it wasn't a commercial offering.
OSX's 'mach' kernel bears little relation to CMU's experiment. It has been optimised, it has been turned into something you would want in a real world OS. It's not perfect, it will get better. Hell, we all know that only Linus is capable of perfection.
-sjf
But MacOS X uses a modified Mach uK. Many of the OS services (ahem, filesystem) are directly provided by the BSD subsystem and skip the uK all together. The criticizm of Mach has to deal with these same issues, which is why Apple decided not to use Mach for every service. BSD doesn't just run as a strict server for Mach, it often bypasses it -- and as such, the opponents of Mach can still be vocal without attacking Apple's particular implementation.
MacOS X is a hybrid, much like some are prone to call the Linux kernel itself.
The wheel is turning but the hamster is dead.
The wheel is turning, but the hamster is dead.
Mach, in its less complex forms, makes a good OS research tool. The modularity makes it easy to try out a new idea without having to muck about with the entire system.
There. I've said something good about Mach.
The enemies of Democracy are
---
---
The high chief of the Little-endians has made statements that disparage the Big-endians.
"They're unnatural and generally suck monkey ass." he said. "I think they also beat their children."
The response from the Big-endians was quite clear- "The Little-endians are insane and represent a threat to the very fabric of our society."
In a poll of 2000 randomly selected indviduals, none had an opinion on the subject, with a +-4% margin for error.
Maybe not as many people would work on HURD because it is a totally different architecture, but the exact opposite could also have happened.
--
Monolithic kernels are simply easier to build and it follows that the less code you have the fewer bugs you will have.
Also the way that microkernels have many subsystems that they need to send/receive messages from adds another layer of complexity.
Warmonger? Have you never heard the saying "Never burn bridges behind you" as a metaphor for not pissing off the people you work for when you move on to another job? Maybe English isn't your first language or this metaphor isn't common in your country...
Sheesh.
Point.
I was just giving a common justification for the use of monolithic kernels.
How about a pot-somking kernel hacker?
Linus really needs to get a job at a company not working on linux, so he can see all the design mistakes in linux
Linus works at Transmeta. Transmeta designs chips. Linus is given time to work on Linux by Transmeta, but he does no work with the company on Linux.
Kernel debuggers, file system VMM issues relating the journaled FS's, RAS
I have to admit that I haven't heard the great outcry for kernel debuggers, except by kernel developers, who clearly like the design of Linux or they wouldn't be developing it. Linux has a journaling FS. Period. Go get it from teh usual sources.
Linux will be prime time when you can sit it down next to a commercial OS like AIX, Solaris, or Win2k and do a feature by feature comparison
Been there, done that. Check the /. archives. Linux compares favourably.
without having to install 200 conflicting kernel patches that make half ass untested unstable changes to 20 different builds of the kernel.
I haven't updated the kernel or installed a patch in over a year. Call me a Luddite, but 2.3 works quite well.
Soap operas have higher writing standards.
Steven E. Ehrbar
Linus is either ignorant about the way Mac apps work or unrealistic about Apple's ability to dictate to its developers.
Not at all; you're misreading the article. Linus is of the opinion that the way Mac Classic apps work was a problem for the people developing OS X, which is why he didn't want to work on OS X.
Steven E. Ehrbar
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
will everyone please quit feeding the "BSD is dying troll"?
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Quit beating around the bush and just tell us what you really think about OSX! No need to mince words. We can take it.
If tits were wings it'd be flying around.
As a mission statement, "hate Microsoft" isn't a bad one. It seems to be working pretty well for both Oracle and Sun.
If tits were wings it'd be flying around.
Linus: Hey Steve, kernel 2.4 is going to come out when I think it's good and ready.
Steve Jobs: FUCK FUCK GODDAMN FUCK FUCK SHIT WHORE KILL MICROSOFT FUCK FUCK FUCK
Linus: Hey Jobs, You're a piece of crap
If tits were wings it'd be flying around.
There has been some confusion over this. Yes, it is Mach. But the BSD code is running in the same address space as the Mach stuff. A crash in the BSD code would crash the whole kernel (um ... big whoop, having only Mach running doesn't do you a whole lot of good). So basically, MOSX/Darwin aren't using Mach as a microkernel, they're using it as the basis for a nicely modular but "monolithic" kernel.
This was all covered pretty well in the Ars Technica review of MOSX that was linked off Slashdot a couple of days ago.
--
Ben "You have your mind on computers, it seems."
Linus can believe what he likes (not that he's right or wrong). He's got something good going for him, as Linux has exploded from a small start 10+ years ago, but he's also been wrong before. Remember his opinion on 1394?
He might just be an egotist, but we'll need to look a bit farther than the title of his book to prove it.
Ita erat quando hic adveni.
No OS is crash proof.
Can you read? This is why I said "modulo bugs and crappy drivers." Obviously no OS is crash-proof, but some do a pretty good job of preventing apps from bringing the system down, while others (Mac OS and Win9x) are much easier for one app to crash.
Point taken. However, if this page is correct, there are efforts under way to port it, and OpenBSD apperantly has been ported. The bottom line is that BSD is plenty available on PPC hardware, and if Apple had wanted to use a different flavor they could have done so.
Well, that's a bit more reasonable, but not much. Keep in mind that Classic is a userland program like any other. From an fundamental OS design standpoint, there's no reason it should matter. OS X is a pure Unix implementaiton that happens to have Classic as one of the apps that runs on it.
The fact that VMWare runs on Linux doesn't make Linux a bad OS. It's precisely the same issue. From an OS design standpoint, classic apps don't exist. There just happens to be a userland application called "classic."
So I'd say Linus is still pretty ignorant about the whole issue.
This is a good point.
.sit files got opened by classic stuffit. I'd like to have a "never launch classic" checkbox, so this doesn't happen.
However, in some cases classic starts up automatically when a classic app gets launched, and short of removing the actual program I haven't found a way to change that.
This particularly annoying because often it will pick a classic app when you open a document-- some PDFs open with classic acrobat even though I've got Preview, and in the beta at least
Darwin is Apple's buzzwordy name for the core of their OS. It didn't exist until Apple bought out Next and opened up their code. So Darwin is an Apple-created Unix-flavored OS that lies beneath the pretty GUI in OS X. Darwin was *not* developed by CMU or anyone else. It was written by Next developers using BSD as a starting point, but wasn't called Darwin until Apple bought the company and opened the source in ~99.
Darwin is as much a BSD as any of the other flavors. It's built atop Mach because that's how Next did it, and they continued in that tradition. Mach is a microkernel, atop which rests a layer that implements a BSD interface.
I'm pretty sure BSD *does* run on PPC hardware. NetBSD certainly does, and I think FreeBSD does as well. And there's certainly no reason that Apple couldn't have ported one of the to PPC hardware if they'd wanted to. The reason they didn't is that they were starting with Next technologies, so they used the Next kernel.
I'm pretty sure what he's saying is that classic apps don't have memory protection from one another, which is true but irrelevant-- the way classic Mac apps are written, most of them would break if you tried to protect them from one another-- they're used to stomping on each others' memory at will.
The solution Apple hit upon was the next best thing-- put them in their own memory space all together, but protect them from other non-classic apps. There really isn't much you can do about this. OS X *is* a real Unix and is therefore (modulo kernel bugs and bad drivers) crash-proof. The classic environment crashes a fair amount, but with a little refinement it's not likely to be any worse than OS 9.
Linus is either ignorant about the way Mac apps work or unrealistic about Apple's ability to dictate to its developers. Apple has an enourmous installed base of applications designed for OS 9, and if they were to throw those out, there would be essentially no software for the new OS. If, on the other hand, they had tried to design an OS that would support classic apps natively, they likely would have had to sacrifice system stability and performance to do it. Not only that, but if classic apps are supported natively, there's no incentive for developers to carbonize their apps, and therefore it's unlikely that the new API's will be widely used. This would greatly cripple Apple's ability to move the platform forward in the future.
This plan is a sensible middle path. It allows a migration path to fully buzzword compliant Carbon and Coacoa apps in the future. With any luck, all the important apps will have carbon versions by this time next year, and by the time OS XI (or whatever) ships, they can disable classic by default and run only native apps.
Look how long it's taken Microsoft to wean the Win 9x line of 16-bit apps-- they *still* have some hooks down to the lower levels of the OS 6 years after Win95 debuted. This is undoubtedly one of the causes of the OS's crappy stability and sluggish performance. Had they adopted a "virtual box" approach as Apple has, they'd probably have a much better OS today.
The preceeding link is courtesy of Google. They mirror and grep for you.
I agree with the original poster -- for all intents and purposes, Linus is a moron. Before you moderators start handing out (-1, blah) points, hear me out. Sure, he's a great programmer and has made a great contribution in the form of the Linux kernel, but it's fairly clear from listening to him that he doesn't understand any developments in systems research since about 1960, with the possible exception of copy-on-write. Don't get me wrong -- I've used Linux since 1994, and it's better than most desktop operating systems. However, Linus' absolutely hubristic rejection of (barely) modern concepts which he doesn't understand, such as
- threads ("processes are faster", sez he)
- message-passing
- version-control systems
just to name three easy ones, is doing little for the Linux community or for people who want to deploy Linux in a serious environment. If you don't believe me, just compare Linux performance to Solaris x86. Sure, Linux has gotten faster with 2.4, but it still can't hold a candle to systems designed by people who haven't ignored the last 40 years of systems research.It's time for Linus to get out of the way and let someone else serve as "CVS with taste" for the kernel -- after that, Linux has a chance of becoming a rock-solid, lean, and efficient kernel.
Mea navis aericumbens anguillis abundat
I'm pretty sure that the shared/segmented memory space was up to the user even on NT 3.5 (can't remember about 3.1) via an option in the Program Manger.
It's basically a question of stability versus DDE/OLE working properly.
--
Business. Numbers. Money. People. Computer World.
Oops, I forget to say that OS/2 VDM certainly had a some geeky-cool aspects. Being able to boot any version of DOS or CP/M was need, and there was even a commercial version of NetWare that ran on it. I have no doubt that if IBM gave a shit, it would be possible to get Win95 working on it.
Just that practically it wasn't the best way to do something that was horridly ugly but necessary, run Win3.1 apps.
--
Business. Numbers. Money. People. Computer World.
I have a Win16 proggy on my Windows 2000 system (TOPO! map software), and I can verify the "Run in a seperate memory space" is still an option in shortcut properties (default==off).
--
Business. Numbers. Money. People. Computer World.
Unfortunately, most of the old 3rd party OpenStep apps were swollowed up by Sun in a mercy killing tactic when they shifted to their Java strategy. OpenStep itself should be considered a failed product, and if officially killing it got MS IE and Office ports, that was a business decision that had to be made.
As you indicate, most Mac developers have legacy codebases and are using Carbon and don't have interest in ObjC and Cocoa.
Most old NeXT developers have either moved on or are too busy still pissing and moaning about the whole OpenStep thing to be developing new stuff for Cocoa or GnuStep.
The upshot of all this is that while OpenStep was a cool idea, there's very little legacy or new code out there to port. Thus the whole idea of GnuStep as a compatibility environment pretty much has 0 market utility now and for the next few years. Pretty much the only thing that you'd want is Omniweb. Not to say that the people working on GnuStep aren't following a worthy cause which could stand up on it's own right.
--
Business. Numbers. Money. People. Computer World.
This is, of course, exactly the same technique that NT4 and 2000 use for 16 bit apps.
No it isn't. NT uses an application layer called WOW to translate Win16 API calls into Win32 API calls. 16-bit apps essentially run as full peers under NT (although interapp communication stuff like OLE doesn't work between 16 and 32).
Windows 9x on the other hand runs a bastardized 16/32-bit kernel that pretty much keeps the whole of Windows 3.1 intact inside of the rest of the OS.
A better comparision for Classic was how OS/2 ran Windows 3.1 apps by booting a virtual dos machine. Both approaches even have the same windowborder problem. Another comparison is the Mac on Unix environment in A/UX, and I'd expect that exactly where the hooks for Classic came from.
--
Business. Numbers. Money. People. Computer World.
If you frequent the kernel mailing list, you will find it a frequent topic that the kernel API is always changing and backwards compatibility is of little concern. Perfection in its nearest state is more important to them.
This attitude, of course, just means that all the back-compatible cruft gets pushed into glibc (which Linus has repeatedly referred to as "crap"). Of course, the Linux kernel is virutually unusable without glibc (or some other crappy variant), so you end up with "perfection" with a big pile of crap stuck on top of it.
This sort of user/kernel duality has even filtered down to the attitudes of the relatively non-technical advocate crowd. A typical featuritus Linux-based OS is not a very good Unix system, in a lot of people's opinions, and the response usually is "don't look there, look over here at our perfection-oriented kernel". I think the lesson of NT and OS X is that kernal internals are really a minor part of the OS's total utility.
--
Business. Numbers. Money. People. Computer World.
Actually, as I replyed above, OS X and OS/2 seem to the exact same methodology for back-compatible support.
OS/2 created a virtualized x86 machine emulation, booted a modified DOS 5.0 on that machine, and then booted a relatively unmodified Windows on top of DOS. (There were some hooks into WINOS2 so that DDE could work between environments and there was a special seemless windows video driver, but otherwise as the blue box versions showed, it was pretty much virgin Win 3.1).
AFAICT, Mac OS X does the same. You can even see a window showing the MacOS booting.
IMO, the NT approach is better (not to get in the way of your random OS/2 advocacy!). OS/2 wasn't really a "Better Windows than Windows" because OS2WIN had all the same flaws as regular Windows (and there were a fucking shitload of flaws there), plus some added incompatibility. The "features", such the ability to do hardware-oriented stuff (like comm software) from WINOS2 were usually so fubared that you'd be crazy to try.
Because NT translates Win16 API calls into Win32 API calls, a whole mess of bugs in the underlying system are resolved, and furthermore the WOW environemnt made problems like the "resource pools" to just go away. Compatibility and speed were a little worse, but back when I was running NT 3.5 on a low-end pentium, I really had less problems with 16-bit apps than I did with OS/2 on similar hardware.
--
Business. Numbers. Money. People. Computer World.
A quote:
> Of course 5 years from now that will be
> different, but 5 years from now everyone will
> be running free GNU on their 200 MIPS, 64M
> SPARCstation-5.
Yep, and I picked it up in my flying car!
I don't mean to diminish what Linus has done, but RMS has done a boatload more for the "revolution" than Linus did.
--
Wade in the water, children.
On the other hand, Mac OS X has been in the news a lot recently, and the PR staff of the book's publisher may have encouraged an article like like this for the PR value. Controversy sells.
uh....
huh?
What?! Linus hates microkernels? Big news there!
C-X C-S
But somehow any old guy on the street can add modifications into OpenBSD?
Uhh...Yeah, actually he can.
His patches might not get into the main tree, but he is free to fork the whole damn thing if he likes.
There's nothing stopping you from adding to any of the BSDs, you just won't necessarily get into the official tree.
Linux is the same way, pretty much.
I kinda like the comittee better, as personal bias ("I think foo sucks and won't consider any ideas from foo, regardless of how good they may be") is less of a factor in deciding what goes in or not.
C-X C-S
... how Linux loadable kernel modules are conceptually different from low-level Mach services. They seem pretty similar to me.
Is this essentially a "Ford vs. Chevy" argument?
I believe the argument is with Mach, not with OS X. It's pretty clear that Linus has never been one to keep quiet in the presence of a bad idea. He's more entitled to have an opinion than many in this forum, that's for sure.
But somehow any old guy on the street can add modifications into OpenBSD? I didn't think so. There's little difference in governance between a kernel with one gatekeeper, and an OS with a committee of gatekeepers.
OS X is only currently a threat to Linux PPC; it would have to be available on x86 and alpha to really be a threat to Linux as a whole.
Your right to not believe: Americans United for Separation of Church and
I'm aware that both can be forked, thanks. I'm just trying to figure out how "Linus Torvalds has been described as a benevolent dictator; the modifications he likes are added" is any different from "The OpenBSD team has been described as a benevolent dictator; the modifications they like are added". I've got nothing against OpenBSD or Linux, but I don't think that it makes Linux any worse that it only has one guy running the show, rather than several. All I ask is that the trolls make a little bit of sense, OK !?
(Personally I'm afraid of anything designed by a committee, but I don't hold that against OpenBSD because it's pretty clearly proved its worth.)
Your right to not believe: Americans United for Separation of Church and
I don't really know much about how the hardware interacts with the OS. I am somewhat confused by the comments i have seen talking about how the *hardware* performs context changes, or the *hardware* is poor at memory paging. I mean, i can accept the idea that the hardware's capabilities directly influence whether such seemingly OS-level concepts as threading or paged memory are realistic or not, but i am not quite sure why the idea is true. So if you respond, please try to do so as if you are talking to someone who does not quite understand what you are talking about.
Anyway: you, and really everyone else throughout this /. discussion, seem to be confining your discussion of whether Mach is good as a microkernel to its performance on the x86 hardware-- i.e., the 386 being poor at context swaps vs. the modern Pentium being poor at context swaps. But the pentium really isn't *relevant*, is it? Since what we are discussing now is Mac OS X, and it as of now only runs on one single hardware platform-- the
PPC macintosh. Alright, so to a person interested in Darwin it is relevant whether the Pentium is a good chip to be using with the Mach microkernel, but with Mac OS X in general the Pentium is not an option. (Really funny, isn't it-- Start looking and you'll realize that Mac OS X is, from the ground up, at several levels, the most portable operating system ever created. The thing makes a few minor performance sacrifices in the name of portability. And yet it only runs on one single hardware platform. Wheee.)
So i guess my question is, ok, so the ability of the hardware to context swap bears a major role in the superiority of monolithic vs microkernel architectures. This is an excellent point. Could you explain what this means in relation to the hardware apple is currently using? Is the *PowerPC* good at context swaps? Can we assume that the PPC is intrinsically better at running either type of kernel than an x86 chip would be, or no? And if Darwin is what you're going to be running, are there any non-x86-compatible chips other than the PPC which might be capable of running Darwin/mach even better?
And in all of these questions: why?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Here's the only couple of real things i can think of that are holding GNUStep and OSX apart-- let me know if you can think of any others:
That being said, the idea of apple releasing (as NeXT did) runtimes that would allow you to run recompiled Cocoa apps on windows xp or linux or whatever is not wholly unrealistic, although i don't think Steve wants to do it. Still, i could forsee a future where Redhat or somebody dumps a whole bunch of money into making GNUStep for Windows and Linux 100% cocoa compatible, and then trying to go to all the OS X software companies and convince them to include x86 GNUStep ports in their shrinkwrapped boxes (hey, look, it's just a recompile!)
At the VERY least, though, I think it is VERY likely that at some point in the near future we will see GNUStep trying to pander to developers of OS X software as a very quick method of porting OS X software to other platforms. And despite any stigma there may still be with linking into a GNU framework, if a development house has become enamored with Cocoa, the idea of developing in that first and then porting to GNUStep for instant Windows and Linux ports would more than likely be *very* appealing.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
I for one upgraded to 384 MB before the final version came out, and no doubt the issues i had with the public beta running on a 128 MB machine are softened by now, but let me just explain something to you: Everything you see in Mac OS X is being rendered through a display layer known as Quartz-- essentially Display PDF. Everything on the screen is a PDF object. This is a bit of a performance hit, but not so much as you'd get under, say, Display Postscript (since Postscript is actually its own little stack-based programming language and requires a somewhat computationally expensive runtime. Quartz gives you the potential for some simply AMAZING things (for the moment the main sign of its existence is the ominpresent drop shadows and semitransparent menus in OS X, but the whole concept is EXTREMELY powerful and i think that five years from now most of the huge selling points of os x will be things made possible by quartz), and in the end the whole system is a probably good bit more sane than, say, X.
However THE PROBLEM WITH THIS IS that Quartz, as (in the words of the developers) a "per-pixel mixer, not a per-pixel switcher", offers FREE BUFFERING to all windows, and almost all apps accept. What this means is that when the display server draws a pixel, it can't just figure out which window owns the pixel and ask the window to draw it; it has to keep track of each window independently by itself, consider which pixels from which windows to take into consideration (and some of these windows may have elements smaller than a pixel..), and indepdendently mix them appropriately at every pixel on the screen.
SO: If you are going to run OS X, GET A BUNCH OF RAM, and MAKE SURE that you have a huge block of unfragmented free disk space for os x to use. And if you don't do these things, don't go around blaming the slow system responsiveness on the microkernel or the Objective C messaging architecture or the complex multitiered layout of the OS. And if you don't want to pay for the hardware needed to make all this stuff usable, well.. Be isn't *quite* bankrupt yetThe performance hit from this really isn't as bad as one would think, but **because Quartz stores the image of pretty much *every window on the screen***, *including* the ones you can't see, in RAM, it does mean you need RAM. Because if you don't supply enough RAM, it means that os x will start dipping into Virtual Memory.
I for one am going to sit around and wait for apple to get some Multiprocessor machines out on the market. Whoo!
(Classic only adds to all this pain, and to be honest as of right now (while you don't HAVE to run Classic, and i for one don't) the app support is such that either you are a GNU-head who will wind up living in Terminal most of the time or you will have several very important tasks you will find can *only* be provided by Classic mac apps. Come july that may change, but still..)
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
It's on ebay waiting for you. :)
I have one in a niche in my desk, actually...it's a great headless server.
"If ignorance is bliss, may I never be happy.
-- Veni, vidi, dormivi
Wouldn't that rather be the superiority of the Tru64 SMP code, combined with the definite superiority of the Compaq C compiler ?
The angry man always thinks he can do more than he can. -- Albertano of Brescia
Well, as a long time user of DOS, UNIX of many flavors (mainly IRIX), MacOS, and Windows, as well as some various others OS/2 etc...I have quite a favorable opinion of OSX. I have been running it for some time now and it is rock solid, beautiful in its handling of text, and the PDF integration is awesome. I have had crashes of applications (primarily Internet explorer) but the system rocks on. Additionally, all the CLI is there allowing all of us hard core users access to all of the goodies while still remaining easy enough for my mom to use.
And as I have said in previous posts the Developer tools included with OSX (for free)are second to none in their ease of use and power, and many UNIX apps I have seen simply need to be recompiled with only minor changes to work on OSX. In short, I can easily see OSX becoming the productivity platform for a huge audience including hard core programming geeks, multimedia folks, scientists etc.... I'll go even further than that. This OS is so good, I forsee OSX essentially taking all of the low to midrange workstation market away from Sun and SGI as well as gaining back market share from Windows given that the PowerPC can continue its development.
Visit Jonesblog and say hello.
It would be fairly simple to create a userfriendly piece of software if you knew the exact hardware that it was going to be running on. With everyone and their mother making hardware for the x86 platform there is no way to include drivers for software that hasn't been written yet.
I've never used a Mac but I never seen any really arcane hardware for it, everyone seems to use pretty much the same things aross the board. Then again maybe I'm a biased x86 person and don't know what I am talking about.
From what I read at fsf.org a couple of months back, it sounds like they are now adopting Linux for that role. As best I can recall the claim went something like -
--
Sheesh, evil *and* a jerk. -- Jade
I don't care what anybody says about Mac OS X. It's better than Mac OS 9.1.
--
InstantCool
Linus wasn't even *asked* about OS-X, and he's not judging it whatsoever.
He was asked specifically about Mach, and he says it's a piece of crap, and he has his reasons. This does not reflect on the quality of the OS, it's stability, or anything else.. not even the particular implementation in OSX. It has only to do with MACH.
In fact, that's one of the worst pieces of sensationalized journalism I've ever seen. They very effectively make it look like linux says OS-X is a piece of crap, when in fact, he said no such thing.
Just like every other argument of this nature.
Risc -vs -Cisc
Microkernel -vs- Monolithic kernel...
There's a theoretical side, and a 'reality' side.
Is RISC cooler? Yes. Does that mean a chip is better because it's risc? No.
Are there pros and cons between microkernels and monolithic kernels? Certainly, of course there are. Does that mean that linux is better than OSX simply because one is monolithic? No.
When apple releases CoreFoundation and AppKit for LinuxPPC... So to answer your question, never... Unless you are talking about command line OSX apps, which I don't expect many of. Even though they run on the same processor and both are unix based OS's, the library compatability is going to be a problem. GNUstep might be an option, except that it has a completely different structure. It could be made to work, but I don't see anyone volunteering to do it in the near future (near future being from now to, say infinity).
The PPC port of gcc still has a ways to go in terms of optimizing for the platform. It's not bad, but not quite there yet. As for darwin, who knows... The darwin compiler is still the old next port of gcc. It's fairly well optimized, but it's a bit outdated. There are a few folks at apple working on bringing it up to date with current gcc, but that may be a while yet.
This from the guy who does not believe in revision control :)
Silberschatz (bell labs) has posted and excellent older chapeter (pdf) on Mach at
http://www.bell-labs.com/topic/books/os-book/mach- dir/mach.pdf ---->or here if your trusting
What are we supposed to think of this article? It lacks detail. In fact the only argument it puts forward are some vague remarks of linus (probably taken out of context) way back in 1997. Apparently there's an issue with lack of memory protection? I can't believe that would be true, I certainly haven't read anything about it in the reviews of mac os X (and they weren't that positive alltogether). This is typical for zdnet, inflamatory title, some vague bits and pieces. No facts, no details, and yet it makes it onto slashdot. I'd love to see how mac os x performs, I'm interested in benchmarks, comparisons, design issues. None of that can be found in this article.
Jilles
What the article fails to mention, is that OSX is much better than any other mainstream consumer OS. It's way better than the old MacOS which has zero memory protection, and it's a billion times better than anything MS has to offer. It's more stable, and the GUI was made for the computer illiterate. Yeah, Mach might suck compared to linux or most other unices, but think of the alternatives.
Some of you are going to say "what about Linux??!!?", but in all honesty, nothing is ready for mainstream until your mom or a pot-smoking graphic designer can figure it out.
Need Free Juniper/NetScreen Support? JuniperForum
Actually, being the said webmaster, Caleb Jaffa is one of my best friends. He's now out on a LDS mission in Maryland. The idea was to get his face posted all over the 'net so when people see him, they'll recognize him from Slashdot
Of course, that was 1992. Everyone (even Microsoft!) thought microkernels were the way to go. Flash forward 8 years, now no one will admit to being associated with microkernels (not even Microsoft!) and we now find Linus trashing Mach.
Personally, I don't blame him. His opinions are pretty well grounded. In 1992, the research indicated that microkernels would eventually leave monolithic kernels far behind, performance wise; in practice it turned out differently. In fact, I have a lot more respect for Linus since he has changed his opinion - there's nothing worse than a pompus ass who would rather continue to defend a position that had been proven wrong rather than admit that he made a mistake. I'm just pointing out the (unrealized to CmdrTaco) irony of the "anyone have the Minix logs?" statement.
Why is slashdot so full of them...
To recap the extend of BSD'ism in MacOSX quickly
The kernel is Next's version of Mac2.5 upgraded to included the featurs of Mac3.0.. and Mach itself is based on one of BSD releases at berkley.. so Mach IS BSD based.
The BSD kernel, does not run like typical servers in a microkernel, it runs in the same memory/address space as mach. It came from Openstep, took some source from Netbsd, and FreeBSD
All the user space utilities, have come from next, and merged with their corresponding (Free/Net)BSD utilitites..
As far as linus' quotes.. they are old people..
And Mach also is not the best microkernel implementation ( some have mentioned L3 as being a prettyy decent one), so that's why the BSD kernel runs in the same space as Mach, to address the performance issues.
Please people, read a little, yes MacOS X is based on BSD code, why is that such an issue? do you think linux is the be-all of everything? damn people, GROW UP!!!!
Task switch is bad due to memory overhead if we need a cache flush during task switch. For all I understand, everything after 486 won't require a cache flush for that. Then it boils down to the amount of memory required for both the server and the client in a micro-kernel, and the total amount of memory required for both the kernel and the user in a monolithic kernel. In that case I can't see where a micro-kernel lose to a monolithic one.
MacOS X is mach3 at it's lowest level. On top of that is BSD and on top of that is the apple/next stuff.
So the kernel is relly mach, which might be a bad choise but thats how next did it and apple have continued on that line.
De lyckliga slavarna är frihetens bittraste fiender, legalisera!!!
even though my humble self agrees with him, there could have been a better way of saying it than this.. "Frankly, I think it's a piece of crap," Torvalds says of Mach, the microkernel on which Apple's new operating system is based. "It contains all the design mistakes you can make, and manages to even make up a few of its own." although there is a lot to be said about being frank.
.sig wanted: Must be concise, funny, and display my cleverness.
To be blunt, they all suck. Just look here.
I don't want knowledge. I want certainty. - Law, David Bowie
while I agree with Linus' assertion wrt performance, today's processors are more than able to handle microkernels. The flaws that Linus derides were conscious design decisions to provide as much efficiency & protection as possible.
Classic applications in OS X will, of course, not be protected by the nature of their environment, but they are still protected from affecting the OS as a whole. This was the whole point. Of course OS X is NOT perfect, but then again, neither were/are linux kernels 0.xx, 1.xx, 2.2.xx, 2.4.x, and 2.5.xx. No OS will ever be perfect. They will always offer tradeoffs. Are WINE applications completely protected? If they are, does each single WINE run application run in its own context? This increases the basic system requirements v. running all WINE apps under a single controlling architecure, e.g. classic in OS X.
Monolithic kernels, also increase the basic system requirements of a system. They require resources for each and every "feature" run at compile times, and add in opportunities for poorly written code to run amok as more and more pieces of the OS are always running, and loaded at startup. Even the lauded mod architecture is susceptible to this flaw, in the same way that microkernel architectures are by dynamically loading needed/required components. There exists NO perfect OS/kernel design, and there never will be one. Selection of the base OS type is dependent upon the designers needs and requirements, which at the time Linus originally developed linux were efficiency and speed v. current processor design and efficiency. (Same as other readers have pointed out in the CISC v. RISC debates.)
This entire discussion should be dropped. If monolithic kernels meet your requirements, great, if not use a microkernel design, a hybrid, or something entire NEW! This should be the crux of this argument, as it is EXTREMELY important that we not fixate and religisize a particular development environment, kernel, OS, whatever, etc. Diversity (not the PC kind) is what drives technological advancement, unless all of you truly wish to live in a wintel world!
Perhaps this entire article was really designed to provoke this kind of discussion...
Side notes: the 80386 was not REALLY designed to handle a multitasking environment, and hence was not optimized to provide optimal context switchin performance. I hazard to guess (I have not studied this closely, mind you) that the 680X0, MIPS, SPARC, etc. architectures provide a lower penalty for context switched v. x86 designs as they were intentionally designed to operate in multitasking environments. i.e. let us also not be so architecturually centric in our discussions
--- C00l
Well, the poster could've read the thread a bit more to see that it probably wasn't Linus that posted it, but an April Fools joke by someone posing as Linus (the headers indicated it came from Washington State and was written using MS Outlook).
Troll may not have been the best choice for it, but there was no "jumped to conclusions" reason either.
"Ooooh...the Linux guy HATES OS X! He must be threatened by it!" media frenzy. That single out-of-context quote, combined with "Linux as insofar failed to bring UNIX to the desktop, which is what Apple believes OS X WILL do", makes it even worse.
This is, unfortunately, how many journalists work. They try to stir up controversey. They must think the facts are boring. I think these people are in the wrong line of work. They should be writing soap operas.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
Steve Job's glittery eye candy provides little functionality
I doubt you've used OSX for any extended period of time (if at all), otherwise you probably wouldn't be saying that. They really thought the UI out. There are a number of very clever improvements in the functionality of the UI.
too many CPU cycles to render it.
Yeah, it's really hard to put a bitmap on the screen. Come on, this is 2001. I think we can afford to "waste" a few cycles on drop shadows and transparencies. Not everything has to look like TVWM.
The fact that it lacks stability means Apple has a piss-poor staff of people admining their programmers.
Ummmm, I haven't see a kernel panic on OSX yet. I ran the public beta for 7+ months. I'm running the GM on three separate machines. Not everyone is having problems. They might just be hardware issues that have to be ironed out. Heck, I've seen poor hardware cause Solaris to panic.
There is NO EXCUSE for such a lame product!
I agree. Fortunately, Mac OS X is a great OS.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
Thanks for explaining why the system requirements for Mac OSX are so ludicrous.
Mac OS X's requirements are "so ludicrous" because it has to run two OSs at once: Mac OS X itself and Mac OS 9 via the "Classic" environment. If you're only running native apps (which the are relatively few at this second, but many are coming this summer), then you'll probably do just fine on 64MB of RAM. Last time I checked, this is pretty comparable to GNOME or KDE.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
- Linux Ultra
- Linux Non Plus Ultra
- Linux Final Conflict
- Linux Meta ('doh!)
- TransMinux (please don't kill me Linus)
- Linux Meta-Mecha
- LinuXtreme
- Omega
- Linux Server Edition
- Linux for Dummies
- Linux X
- LinuXP
- Lucy
- Linux Blue
- Yellow-bellied rat bastard (ok, that one's not so good)
- LinuX-men
- Jurassic Linux
- Episode II
- Linux Classic
- Micro$oft Sux!
- Liquinux
- Quinine (is not a quine)
- Linux Air
- C:\con\con Air
- Evil Dead II
- Linux - Ghost in the Machine
- FreeBSD ('doh! somebody slap me! damn just kidding
;-)
OK, not completely great. There's a reason why I'm not a comedy writer. But it's free. If you don't like it do better.Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
Facts are simple
and facts are straight.
Facts are lazy
and facts are late.
Facts don't come with points of view.
Facts don't do what I want them to.
David Bryne.
War is necrophilia.
"I will take the Ring," he said, "though I do not know the way."
MacOS X doesn't need Linus. It's not like Linus is the world's only capable kernel Unix hacker out there. There are plenty of people capable of developping MacOS X as a good OS (heck there're even plenty of them to develop *BSD, Solaris, QNX or BeOS).
Perhaps Linus is jealous that someone has created a version of Unix that's highly userfriendly,
personal opinion about your intelligence deleted...
So far Linus has spent his time working on the kernel. Not user space programs. Not desktop environments. No user interfaces.
It's like saying Alfred Hitchcock envies Linus for havin such a successfull kernel...
Linus' interests (and his notion of "fun") have nothing to do with the user-friendlyness of a particular piece of software...
From Tanenbaum...
Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project.
This is just one of a million statements in that article that show how truly clueless the man was about the future of computing back then. But then again just about everyone else was too. If you said then that the free software movement would spawn the more business minded/less political open source movement, which is the big darling of the computing world today, they would have probably laughed at you.
I agree that managing a widely spread open source project is a nontrivial excercise, but Tanenbaum acts as if it is impossible. Clearly the success of many modern examples proves that while it may be damn difficult, it is NOT impossible.
I also agree that the many eyes make bugs shallow thing is kinda crap. It's many USERS that make bugs easy to find, not many people staring at the source
I think the real problem with that theory is not that the idea doesn't work in principle, because I believe it could. The real problem is that few people ever actually look at the source to any program they download. If every linux user pored over the source of every app they downloaded, sure bugs would be smashed with amazing speed, but no one really cares that much. I know me personally, if I want a new app, I do an apt-get install, and if that doesn't work, download the tarball. Only if things dont work with ./congigure;make do I start trying to figure out anything about how the program works.
.. that Linus knows anything beyond his own kernal?
He doesn't grok EROS, either. He made a complete ass of himself trying to debate the merits of message-passing with Shapiro.
(You can find it at eros-os.org)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
There was some dabbling with microkernels from Mach in the early BSD days (Lites 1.0), but I don't think that's continued much, or was the source branch for MacOS/X.
Have a look at Eric Levenez' Unix family tree here.
Quartz isn't a window manager. It is a display system, analogous to DPS on NeXT or X on Unix.
You can get a new iMac for $899. To run OS X you'll need a memory upgrade (why Apple is still shipping 64 meg machines when OS X's minimum requirements are 128 is a mystery to me), but you're still under $1000, which is hardly out of reach for the average consumer. Yes, I know you can buy a motherboard+case+power supply+graphics card+CPU in the Wintel world for half the price, but that's not something normal people have the ability or inclination to do.
There's a quite enlightened synopsis of the state of the OS wars here
That article is incorrect in a number of areas, especially this line: "The market for Mac OS X is simply a subset of the overall Mac market because not all Mac users will upgrade." Many Unix and Windows users who would never have considered Macs before are very interested in Mac OS X. Just count the number of Slashdot articles on OS X in the past month.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
If the problem with Unix is that it's 30 years old... Mach (and other kernels like it, such as pre-version-4 NT) is over 10 years old. As microkernels go, it's considered to be quite bloated nowadays.
If you want to see a kernel that's truly modern in design, look at Chorus, QNX or BeOS.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
We can also tell by the number of bugs found in things developed with a development model like Linux that the "many eyes make all bugs shallow" philosophy is crap as well; most bugs aren't obvious programming errors, and if they are in your project, find new developers.
-bugg
"you think linus gives a crap about fuckin eyecandy GUI like Aqua/MacOSX?"
Envious or not, Linus must "give a crap" or he wouldn't have mentioned it.
Well since Linus was talking about the Mach microkernel, as opposed to userland/Aqua, he in fact DID NOT mention it.
"You are only young once, but you can be immature forever." -www.animemusicvideos.org
Cmdr. Taco should be posting boring stories that his typical audience doesn't care about.
I hear that they're trying to bring the Teenage Mutant Ninja Turtles back. Discuss.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
I think RMS' and GNUs most important and revolutionary work is not only defined by the tools they wrote, but the Free Software philosophy that builds the base for the development process we use in Free Software and Open Source projects today.
RMS raised awareness among people about the problems they face with proprietary software and changed the way many people think about these kind of closed systems.
rose
Um... I was always under the impression that they feel the Linux kernel is a transitional solution -- only intended until the GNU Hurd kernel is complete. As an astute AC commented below, that hasn't progressed very far since Linux took the world by storm.
What?! Presumably you're saying that Linux wouldn't even have existed if the GNU kernel had been finished in 1992. Okay, maybe, but I don't think the GNU kernel is even "ready" now! Or if so, quite recently... So, yeah, it seems as if there was only an 8 year window of opportunity where Linux could have come about :)
You're forgetting Microsoft has the power of size and money, allowing it to dictate some standards (WinModems?) and since it is the defacto desktop on millions of computers around the world, developers must write good drivers for them. Not that they all do (ATi, especially under Win200, what I'm writing from now).
If I could only live my life with my threshold at 4...
heheheheh..... that's exactly what I have running in my rack @ home. interesting.
Thanks for explaining why the system requirements for Mac OSX are so ludicrous.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
OS X and OS 9 running on top of Darwin running on top of Mach. Sheesh, it's amazing it can even run on current hardware at all!
note: I'm only kidding, I haven't tried it yet, but I do plan to soon on the beast of a mac we have here at the office.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
far from beeing a microsoft evangelist:
;) )
symbolic links - point, not there.. - bad!
mountable partitions - done.. works - but the unix way is clearly the better
The ability to move an application - not possible...
The ability to uninstall an app without reboot. - no problem (with limitations when lowlevel hardware drivers are involved)
nfs - come on.. they just decided to have their own filesharing protocol (their problem
dynamically loadable drivers - more then ever - less then in linux, correct.
poix compliance - they have (since nt 3.1) but who cares?
PAT
SEO Test: TIGI und SEBASTIAN - Online Shop - V
Linus wasn't talking about the desktop shell. He was referring to the kernel, which is based on Mach. Maybe you should read the article before commenting on what linus may or may not have been talking about.
ESPECIALLY if, like apple, you then just use it to run one monster server daemon
I suppose you're talking about the BSD layer.
Most users, however, are far more concerned about running Classic, Carbon, or Cocoa apps. Classic is a Mach process inside of which each Classic app is executed. Carbon and Cocoa apps are each individually Mach processes. So are system servers like the window server, pasteboard server, etc.
Hmm... What should I do with that Intel box? Come to think of it, I've never installed BSD on a i386 system... On the other hand, SQL Server 2000 isn't that bad...
What's your point? That Linus, because of his hard-earned status as a programmer extraordinare, should not comment on other people's programs? What crap. Linus should say whatever he damn well pleases. And I'm sure he will.
--Lawrence Lessig for Congress!
You say you'd like to see how Mac OS X performs? I've seen how Mac OS X performs. On a dual G4, no less. Lots of shiny objects on the screen. I saw that dual G4 slow to a crawl running nothing more complicated than an email client. It sucked eggs beautifully.
--Lawrence Lessig for Congress!
I just saw OS X today. It blew chunks. Brightly colored pulsating translucent chunks to be sure, but chunks none the less. It crapped out on a dual G4 running no more than the provided email client, a xterm, and bbedit. I'm talking 10's of seconds to regain control of the screen.
I completely agree with you. Let's forget about theory and examine how well things really work.
--Lawrence Lessig for Congress!
Uh.. right. The UI has nothing to do with it, this discussion is about the kernels.
Sigs are awesome huh?
2First Dell slams apple as the next SGI, and now Linus piles on. What's everyone so nervous about?
good thought
Linus' MS-inspired FUD tatics are really just a poorly disguised attack on consumer's freedom of choice! This isn't all too surprising given his previous actions. By developing a new OS for outmoded, poorly designed hardware, typically accompanied by an enforced payment to Microsoft (unsurprisingly his employer's new found ally), he ensured the dominance of a deficient computer architecture. Then he ends up working for people who will happily sell you things to make it work better. Typical embrace and extend. Lock the consumer in and then make sure you can extract money from their wallet.
And we trust this guy with the kernel sources?
:) if you don't get it)
(oh, here's a big
Check out this. It cleary states that Darwin is running on top of Mach, and thus OS X is on top of Darwin is on top of mach.
> Linux isn't so monolithic these days. Its been possible to add and remove klm on a live Linux box > for quite a while now.
It still is. Yes, you can now change the size of the monolith (kernel) at runtime, but it still works "monolithic". E.g. a buggy module can crash the system.
> It's no different than AMD using RISC like features in the Thunderbird CPUs
Yes, but since there is no "reduced instruction set" they are no RISC CPUs and have to work around the problems with that weird x86 ISA (e.g. no orthogonal and small register set, different sizes of instructions and so on...)
A. Darwin is a version of the BSD UNIX operating system
Q. How does Darwin relate to Mac OS X?
A. Darwin is the core of Mac OS X
Nicer from an idealogical and design perspective, not a practical perspective is what he was trying to say.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
The biggest benefit for microkernels is twofold:
a) their small, minimalist design allows for fewer bugs, greater flexibility, etc, etc(all the old arguments you hear about them)...
and another point which I thought was very valid,
b) the fact that very little code is in the kernel allows for better realtime performance. The less time that must be spent in kernel mode(where interrupts are disabled), the more time can be devoted to actual work and servicing devices.
Some microkernels do a better job at efficiency than Mach (L3 for example). At some point, the hardware might actually get fast enough that the trade-off is nearly always worth while.
L4 and EROS kernels are even faster than previous generation microkernels. And it's not a matter of hardware getting faster; it's damn fast right now and the context switching algorithms used are so much better that's it's not even slow anymore. The problem is getting somebody to do ia u-kernel right and to build an actual system on it. While the people working on L4 are doing great work, they're doing it for research purposes so it's not going anywhere practical, anytime soon.
IMO, overhead penalty invloved with context switching in a u-kernel OS is totally worth it, especially for a desktop system. And QNX proves that it can be done right.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
Even outside the Valley, he's gaining visibility: Time Digital's Digital 50: #4 Linus Torvalds.
Anyone paying attention to technology - tech investors, business leaders, etc., has at least heard of Linus Torvalds. The days of obscurity are gone. Just as people know who Jobs and Ellison are, they now know who Torvalds is.
Read the EFF's Fair Use FAQ
I understand that absolutely. Linus started Linux and has worked on it for years out of self-interest. No doubt about it.
What I'm getting at is that (unfortunately or not) Linus represents Open Source to the world at large. While most Linux afficionados know about Stallman, ESR, Perens, et. al., the lightening rod for Open Source right now is Linus Torvalds.
Whether he likes it or not, he represents Open Source to the non-hacker world. What I was getting at with my initial post is that even though Open Source movement and Linus Torvalds are two separate and distinct entities, that is not the perception.
The development of Linux shouldn't be run like a business, I wholeheartedly agree. But Torvalds has an effect far beyond just Linux. His straight up honesty is one of the things that has helped Linux come so far. It's one of the things that, by all accounts, makes him a good person.
But Open Source as a movement is bigger than Linus, and if we take Linux out of the equation for a moment, we can see that without Linux, Open Source wouldn't really have a flagship "product", regardless of what Stallman says. I mean, Apache is great and all, but a successful operating system is an order of magnitude more important when you're selling Open Source as a viable process for building software.
So now we have a situation where the de facto spokesman for Open Source might not be interested in taking on that role.
Where does that leave Open Source advocates who do care about presenting Open Source as a viable option (with or without Linux).
Read the EFF's Fair Use FAQ
I think that's why the press has latched onto this story, and why some of us find it particularly interesting. We all know that hackers flame each other, that for any technology to really matter, it has to originate from passionate individuals.
But the rest of the non-geek world doesn't know this, isn't familiar with hacker culture and how ideas are discussed. The business world operates differently, and in the business world, attacks like his attack on Mach are often interpreted as signs of fear or weakness.
It may be even more puzzling to the general public because they've been lead to believe that the Open Source community has always been interested in allowing many different technologies to flourish in a relatively benign environment.
I applaud Linus for the tremendous work he's done over the years in developing Linux and championing Open Source, but if you want to convince folks that Open Source is a kinder, gentler way to compute, saying Mach is crap might not be the best approach.
Read the EFF's Fair Use FAQ
This is pretty offtopic, but in response to your comment about the "beautiful" Aqua, I have to disagree. The great part about X interfaces is that most of them enable you to make it look pretty well exactly the way you want. Granted, out of the box, Aqua's better looking than the default Gnome UI. But do you really think the non-flush dock is attractive? I did for a while, but now, I just think it's shitty design. It doesn't go all the way to the edges, and it's hideous! Window Maker and other OpenStep-type themes are waay better looking!!
toeslikefingers.com - because
The Suse FAQ shows how to pronounce it.
Is this the same as this Rick Rashid: Senior Vice President of Microsoft Research?
If so interesting stuff. When I worked there i knew he was a bright buy (did a good deal of the physics for Allegiance - the game) and was WAY to into Star Trek, but i didn't know he did OS design.
-Jon
Streamripper
this is my sig.
well.. i bet these zdnetters are juss trying to make our linus look idiotic. Its a conspiracy to create anger in the community towards linux. No wonder they are sponsored by M$. Almost everybody who read KT knows that linus prefers monolithic kernels. And i think someone out there is taking some of his comments too far. That could have just come out of a long paragraph. Without looking into the whole picture we would never know. I believe that the Apple's Mac OS X is a wonder( based on its GUI features). Linus would be probably loooking at its kernel. And kernel wise linux might be much better. But duh!.. "its crap "" ????? the kernel might be crap compared to linux. but not the whole OS itself right. .. A kernel is not an OS . you need a few others to make it an a true OS. And some of these are where Mac OS X outshines linux. But not its' kernel. Linus has every right to criticize other kernels. He created one of the best kernels outthere. I'm taking his word for it.
The thing is that this document here didnt' give enough information on the comparison between Linux and MINIX , feature wise. I would just love find an article/document on the advantages of linux as a monolithic kernel vs. another kernel which is micro. This document here gave us just a comparison between linux and minix, on freeness, price, portability, patching the kernel and issues that were only relevant in 1992. Anybody has a newer document about this stuff ?
I agree with the author of this thread. While Linus and many others (myself included) may consider this Apple implementaion of BSD UNIX kernel software crap, the articles do not mention that Torvalds said nothing about the operating system as a whole, only that the kernel code was written in a less-than-optimum way. Yes, the kernel is the core of the system, but linus bashed the way it was developed, not strictly the outcome of the code itself. This also brings up another question: How much of the BSD code will apple give up? This kind of thing is an LGPL lawyer's nightmare ;-)
-----------------------------------------
-----------------------------------------
Perversely greped and groped by PowerPenguin
I read the article at El Reg before it popped up here. The way this story is being presented by ZDNet, the Register, AND Slashdot is terribly misleading. As near as I can tell, Linus has nothing bad to say about OS X in particular...just it's usage of the Mach microkernel which he (and lots of other kernel hackers) have dismissed as crap.
Reading anything else to it just turns the whole thing into a "Ooooh...the Linux guy HATES OS X! He must be threatened by it!" media frenzy. That single out-of-context quote, combined with "Linux as insofar failed to bring UNIX to the desktop, which is what Apple believes OS X WILL do", makes it even worse.
I say humbug.
El riesgo vive siempre!
This is total froth. Whipping up a little OS flamery and fishing for referrals from /. and the Mac sites.
Whussumatta? Running out of XP screenshots? And it shouldn't have made any editors' cut at this noble forum.
illegitimii non ingravare
Apple has done this, and from what I've seen, has done it really well. But hey, thats just my opinion.
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
What clown of a moderator marked this parent as a troll? Because I pointed out a flaw of Linux? Fuck you, ass!
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design) is that the most popular implementation of the concept (Mach) is also one of the most inefficient and badly designed.
In Joseph Liedtke's 1995 paper, On Microkernel Construction he points out that the myth of Microkernels being more inefficient and thus slower than monolithic kernels is because most benchmarks were done against the Mach microkernel. He stated that the Mach performed poorly at both address switching and context switching and also failed to take processors into account and be optimized thusly. As a test, Liedtke wrote a Microkernel OS called L3 in which he showed that a call to getpid which took 800 cycles of kernel time on the Mach to be performed took 15 - 100 cycles on the L3.
Also he also disproved the notion that using a microkernel leads to memory degradation due to a large number of cache misses a dissects a number of benchmarks from Chen and Bershad's paper The Impact of Operating System Structure on Memory System Performance.
Read his paper if you get the chance, it's very enlightening.
The ideas behind microkernel design are very sound and some of them have found their way into most mainstream OSes (Linux kernel modules can be seen as a take on the Microkernel architecture). Basically, having an OS where everything is hot swappable including memory management, process scheduling and device drivers is kind of cool. Also the fact that the usual OS level APIs can now be swapped out meaning you can have both POSIX layer and a Win32 layer on the same OS is rather nice.
If Mac OS X wasn't based on Mach 3.0, it wouldn't have been possible to implement the Quartz window manager which depends on Mach's advanced ipc and shared memory features. So Linux, because of its limitations, will only have X or direct to framebuffer implementations, neither of which aren't as good. -- Richard
My understanding of the many eyes make bugs shallow quote is that, once you find a problem/bug, the solution is likely to be obvious to one of the many eyes. (my rememberance was more along the lines of 'many eyes make all problems shallow')
--
Free Software: Like love, it grows best when given away.
If a piece of code works the way you want it to, there's no real need to look at the source code... I too have downloaded dozens of pieces of source code, and I've only really looked at a small handfull of them. I have, however, looked at a few, and even submitted patches. In truth, that's all that's really needed for the stats to work in favour of the 'all eyes' conjecture.
If every person who uses open software only ever submitted one fix, that would be tens of millions of bug fixes for a few thousand programs -- in other words, thousands of bug fixes per program.
--
Free Software: Like love, it grows best when given away.
Reading a Slashdot article such as the one that I am replying to always makes me curious at the responses the Slashdot community comes up with.
I have been following Slashdot daily for almost 5 years now and one thing that is very, very, very clear to me (not trolling here) is that everyone here is a...
1. Genius computer programmer who knows everything about everything about everything and no matter how much you argue with them you will always be wrong because apparently they all have Ph.D's or 45 years job experience behind them to counter you
2. Whenever an argument is made here at Slashdot there is almost never any real, hard facts to back up a statement, which is always made to be taken as a fact. Always links to some obscure website or such, but when it comes to actually being able to say with full conscience and confidence that "I have sat down, at my own computer, actually compiled the code myself without downloading a binary, ran the appropriate tests, and have a full and professional analysis completed with cold, hard facts in hand...Everyone on Slashdot falls flat on their face.
I used to work on and with NextStep 3.0 and OpenStep 4.0 exclusively before changing careers a few years back. I am very interested in OSX and would be very interested in finding out what OSX has as far as problems and concerns. I am not talking about fluffy crap, like what Slashdot usually spews out when people talk about this sort of topic, but actual, honest to God comments about exact coding design flaws with Apple Mach and Apple BSD implementations and exact design flaws that Apple may have already fixed. Oh, you can't have OSX source code...that is also crap. Simply go to http://www.opensource.apple.com//, download the Darwin source, look through every line of code, compile it, and then give an informed opinion about Mach Microkernel vs (for example here) the Linux Monolithic Kernel design.
To be honest, who really cares in Linus doesn't like MicroKernel architecture? If/when Darwin gets ported to other architectures such as Intel and if/when Apple would port their GUI, Linux will vanish forever. Linux is not as easy to use as a Macintosh and I don't see it ever being as easy. People use it now, in it's current form because they have no better choice.
Please post intelligent, informed responses about Mach, Apple, and BSD and hopefully this article and the Slashotdot communities responses to it would make for a great, enlightening experience for everyone. Please download the source and prove Apple wrong about Linux. But, if you can't, then at least admit when you have your tail between your legs.
PS-Please don't post any links unless they are results of the above mentioned items I pointed out. The usual Slashdot reponse to an opinion like mine is to think I am trolling, call me a Microsoft lover, claim millions of links to other articles mostly getting their information from other articles (repeat indefinitely), or try and make the response seem like an uneducated post looking for a flame war. Does anyone here have an actual experience with Mach or what Apple has done with it and where they can go with it. Mach can't be that bad in it's current implementation, because I truly fail to believe Apple would have made a mistake that stupid.
yawn.
So, I would say the answer is probably "yes."
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
How many copies would "Just For Fun: The Story of the Guy Who Wrote the Original Code, and Still has a Heavy Hand in, Linux" sell? How interested would the media be in reviewing the book, and how much would it do to promote Linux? A little exaggeration is not necessarily bad.
Also, I agree with what the guy above says about him being a revolutionary, not "leader of the revolution." You could argue (I don't want to argue about this, so choose your own names if you disagree) that Thomas Paine was less important to the American Revolution than George Washington or Thomas Jefferson. However, he was still a revolutionary.
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Other than that, I think Mach gives up much too much speed for its feature set. The rest of OSX could easily be ported to Linux or a BSD OS, and I think Apple should do so!
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
Undoubtedly Linus had a lot of job offers. It's naive to think that he decided to turn down Jobs (or jobs) based on some inner fire and drive. Linus is accustomed to being the reluctant hero of a charismatic movement, a job which Steve Jobs already holds at Apple. Transmeta allowed Linus to a) be a l33t coder, b) continue as the figurehead for Linux kernel development, and c) not take sides on the desktop OS issue, which would have been politically unwise. I'm sure the choice was not as difficult as these sensationalist articles and writeups would have us believe.
Apperantly humans never can.
"If anyone needs me, I'm in the angry dome."
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design)
Hmm, well let me elaborate on that comment. IIRC, both user mode and kernel mode drivers can be done in NT. Before NT4, it was all user mode drivers. After that, it became optional, presumably for efficiency's sake. Oreilly has a good sample chapter page on the NT I/O subsystem:
http://www.oreilly.com/catalog/wininternals/chapte r/ch04.html
heh mackgay, for a moron who just fucked up his AC posting, you sure can kiss my ass.
--
Je t'aime Stéphanie
Linus declares : "OS X kicks ass, Mach is a superior architecture, Linux has a lot of catch up to do, heck, why not switch right away, I find the dalmatian iMac particulary tempting since I started smoking crack"
--
Je t'aime Stéphanie
"...linux is monolithic, and I agree that microkernels are nicer..."
"...From a theoretical (and aesthetical) standpoint linux looses..."
Thank you.
quotes
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
I give it about a year. 6 months if there are a few geeks on a mission.
Basically it would take binfmt_macho to be written, maybe an extended hfs (if we don't have an osxvfsshim module). And the syscall translation shim.
And how long until it goes the other way? Add elf support (plus elf shared libs) and the linux syscall shim to Darwin? Maybe the same time.
At some point they will cross and then Darwin will be subjected to natural seleciton.
I already can run the Gimp on OS X.
It is a bit silly to have a modular kernel and then always have to include the same modules. Meanwhile monolithic linux has modules that install devices, filesystems, almost everything (Until I had some hiccups with late 2.3, my kernel had a ramdisk and cramfs, and loaded the rest, I really should revisit that).
At some point, probably 2-3 years, Darwin and Linux will either merge or become so cross compatible that one might all but disappear.
5) Cowboy Neal ;-)
That is just the problem, the idea behind Mach is beautifull.... But in the real world it just doesn't work and probably never will. Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Let's see, Linus has a strong opinion of another kernel for an operating system, this is news? Or is this another "Slow news day so let's create something that can get the people riled enough to create news" type posting?
Are we going to see the counter point by Apple?
DanH
Cav Pilot's Reference Page
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
That's the funniest part of the article: Steve Jobs thinks Linus would be more interested in working on OSX vs working on Linux. The assumption is that he would be more interested in hurting Microsoft, rather than actually having full control in creating an OS that has merits in it's own right. I guess it was worth a try, but purely machiavellian.
I understand companies like Apple, Sun, Oracle wanting to compete with microsoft, but i don't like it when CEOs just are slapping at each other and getting in pissing matches.
Plus, can you imagine Linus working for Jobs?
Yeah, it's soooo much more modular that it doesn't even have a decent mechanism for dynamically loadable/unloadable modules. In comparison, ugly monolithic Linux has got this since version 2.0, that is, since July 96.
I never said that Linux was first, but since it didn't exist when the technology appeared, it would have been hard for Linux to be first. What I'm saying is that this technology has been implemented very rapidly under Linux and is working very well, while NeXtStep and now MacOS X (that is, Darwin) never had it. I know that many Darwin luminaries would like to have dynamic modules, but the truth is that it is a god damn pain in the ass to implement, however "modular" Mach may have claimed to be.
I'm sure anybody in the GNU project will tell you that the HURD became a low priority as soon as Linux came out. It's taken this long to become useable because there is already a GPL'd kernel available, so people are working on it because it's interesting, rather than urgently required.
If you take that into consideration, the "window of opportunity" shrinks somewhat, and we could well have been a year or so away from using GNU/HURD rather than GNU/Linux.
--I have read a whole bunch of posts here today and the moderators are fucking nuts. Perfectly valid posts are getting Troll and perfectly inane posts are getting Insightful.
--Who ever is moderating today should have their mod points stricken for life. This is one of the worst days I have ever seen. Jesus.
---
This
Yes, but only until he was struck in the head with a flying PDA. Say, did anyone every substantiate that "Get these damn scribble pads out of my office" quote?
--
ALL YOUR KARMA ARE BELONG TO US
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Linus trashing Mach? This is the same guy that is proud of a kernel that last year had to be recompiled to use a zip drive? Who is this guy fooling? This is the guy that could barely get a butt-ugly GUI working (with the world helping) while Avie and NeXT had a multimedia email application that ran on a fast, elegant, and superior OS. He may have his reasons but it sounds to me like a bit of sour grapes. Linux folks no longer can speak ill of the newest Mac OS. In a matter of a few years Apple has created a mix of industrial strength UNIX and consumerized it. Something Linux WILL NEVER DO! This is off topic, but too many Linux programmers and users take great pride that Linux is difficult to administer. That is why Linux will never be user-friendly. Nobody wants to make it easier to use or admin. As I said, Linus Torvalds or Avie Tevanian? I take Avie any day of the week and twice on Sunday.
Somebody mod this up!
Doug Alcorn
I think he was talking about application compatability between os releases with different kernels.....
Time for some tasty Shiner Bock!
Carbon is the 'yellow brick road' to lead developers into OSX territory. It greatly diminishes porting time, allows developers to work with what is basically the same code base, and they can release a single binary that will run under OS8.6 and later with the carbon library, or that will run under OSX. While it is still semi-flakey at this point, it is still the path developers need, and are willing to take. Adobe isnt going to throw away years of code to support an OS that is mainly run by early adopters (at this point). With carbon, they dont have to. They can recode the 15-30% needed for carbon (probably a bit more for an adobe app), and be up and running within months at the most.
At the same time, Apple can be introducing developers to cocoa, which is truly a nice dev environment. So they can use carbon to get their stuff up and running, while they develop cocoa versions of their app. This may sound unlikely, but I really think this is what will happen. Cocoa has some nice hooks into the system that carbon just can't provide, and developers of course will be the first to realize this and want to take advantage of it. IMHO Carbon is the initial path that devs will take, but cocoa will be the true road to the 'promised land'
Time for some tasty Shiner Bock!
He isnt saying the g4 is a bad processor (i think) he is saying motorola is having some troubles, which is totally true. They have had a few rounds of layoffs in the past 2 months, with probably more to come. The chip may rock, but that doesnt help us if the company making it goes under.
Time for some tasty Shiner Bock!
I am running osx, on a dual g4 500, with 256mb ram. the damn thing flies. I had previously been running the beta on an ibook as a toy/experiment. the performance was lackluster, to say the least.
I installed OSX on the tower about 5 minutes after I got it. and I too was disappointed with the speed. Altho it was on its own 20 gig partition, with it's own os9.1 system for classic, it seemed a bit sluggish. I just dumped everything I had installed on this fairly new machine onto a dvd-ram disk (oh so handy for backups!), reformatted, installed my apps, and it was like a whole new computer. There must have been a lot of debugging code in the beta still. heh.
OSX does still have its flaws, and it is still teething, but it is plenty fast if installed right, at least on this machine, and it has plenty of room to grow.
I cant wait...
Time for some tasty Shiner Bock!
Darwin, or the NeXT code as it stands today, has been overhauled every which way since the last NeXTSTEP/OPENSTEP release. Check out the developer docs at developer.apple.com
Linus tears MacOS a new asshole, and you guys get off on it. If Gates did the same to Linux you would tear HIM a new asshole.
You fucking hypocrites piss me off to no end.
Quick now!
What type kernel do you favor?
1. Micro
2. Monolithic
3. Exo
4. Other (Please specify.)
----
From Apple's open documentation on the kernel structure:
[BEGIN]
The fundamental services and primitives of the Mac OS X kernel are based on Mach 3.0. Apple has modified and extended Mach to better meet Mac OS X functional and performance goals.
Mach 3.0 was originally conceived as a simple, extensible, communications microkernel. It is capable of running as a standalone kernel, with other traditional operating-system services such as I/O, file systems, and networking stacks running as user-mode servers.
However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do RPCs between separate tasks. This modular structure results in a more robust and extensible system than a monolithic kernel would allow, without the performance penalty of a pure microkernel.
[END]
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
I'd like to know what version of Mach the Liedtke paper is using for comparison. Later versions of Mach (e.g. 3.0) used a form of continuation passing to speed up context switches.
Also, as I recall both L3 and L4 have large sections coded in hand-tuned assembly language. It seems a bit unfair to compare a micro-kernel designed purely for high-performance on a single architecture to one designed for greater portability at the expense of some speed.
It's no secret that Linus doesn't like microkernel architectures. What is really going on here is the press trying to create some buzz, get some hits on their web sites and sell some books. Many sites headlines are saying that Torvalds said OS X is crap, not the Mach kernel which, of course, is false. Read the article.
If you were Apple, the decision going micro or monolithic was a no-brainer in my opinion. Ignoring the Tevanian-Mach connections, going monolithic with OS X would be putting too many eggs in one basket given the shaky CPU ground they're standing on. Mach gives them more alot more flexibility to jump the Motorola ship if forced to.
[shudder]
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
Just what is Linus trying to say; he seems at a loss for words....
there are no stupid questions, but there are a lot of inquisitive idiots
Yup indeed. It's just that the "in black and white, THIS IS A SPOOF", seemed to be missed by most people. As it was missed I though't I'd make it even more obvious. It was not your intelligence I was insulting, you don't need to worry :-)
FP.
--
Also FatPhil on SoylentNews, id 863
It's a great spoof post - the last line gives it away though...
"
Also, I have submitted this to slashdot with the title "A Proposed Remedy Involving Lingering Fud and Organizational Objections to Linux Systems." Be on the lookout for it.
"
or more briefly
A. P. R. I. L. F. and O. O. to L. S.
geddit?
--
Also FatPhil on SoylentNews, id 863
I guess its no longer surprising that a slashdot discussion about microkernels (and the Mach microkernel in particular) would not include any mention of the HURD. As far as I'm concerned I would take RMS's opinion on software architecture over Linus' any day. Writing one piece of software doesn't make Linus an authority on all software. In any case it is unfortunate that some youthful sparing with a stuffy professor would be dredged back up to form the basis of a discussion on this ostensibly tech-oriented site. So, can we have a technical discussion or have we all turned into script kiddies? Lets start by asking this: Presumably the linux kernel sucked when the comment was made compared to what it is today. Can the same be said of Mach? What about the implementation of threads on these two kernels? Seems like a microkernel would be better suited for multithreading. Am I wrong? Anybody home?
When I first posted that OS X was crap, I got -1; flaimbait. Now that Linus is saying it to, suddenly it's interesting and newsworthy :)
I just want to make something clear - this is "-1", because it says the linux gui sucks. Whatever.
The Linux gui does suck. Have fun with your 'hobbyist' OS.
So, I don't really know about adoption, RMS just doesn't have anything against it as it doesn't go against his beliefs.
One shall speak only if what one has to say is more beautiful than silence
Everyone knows it, but why do people always keep quoting it when they know perfectly well that its faults have long since been exposed and corrected in other microkernels? Is it perhaps that they use the misery that is Mach to spread FUD about microkernels?
You dont have to run all services for a microkernel in different protection domains, but its nice to have the choice of doing it when you want to.
In mainstream culture he's an unknown. Gates they know. The rest? Nope. Linus is less relevant to the culture in general than, say, the designer of the Corvette.
Unless, of course, you build hot-rods. Which is precisely the place in our culture that Linux has taken up: now you soup-up computers instead of souping-up '57 Chevys. Growing up I knew and cared about Chrysler's hemi just like most here care about Linux or the latest Intel offering.
Don't forget that Solaris is a Mach microkernel OS. (The old SunOS wasn't). Sun had real performance problems when it first came out - but it seems OK now.
/..sig file not found - permission denied.
Is it really task switches, or process switches?
If the overhead is in switching the virtual memory state over, then that is really unnecessary. It's really just a hardware expense to support poor software. If all the apps on an OS were written in a language that didn't allow arbitraty pointer arithmetic (like Java, etc.), and the compiler was trusted (and not buggy) then seperate address spaces between apps (and the kernel) are not necessary.
/..sig file not found - permission denied.
How true, so very true. I must speak out here as a core developer for Apple for a number of years. I don't wish to flame the debate about the Mach (or simple M as the dev team calls it) and the Linux kernel, we all know the differences and have read all the debates. The thing that really bothers me is that Apple fans have been treated as outcasts for years and treated with disrespect by all the hardcore computer people. They have suffered through the whole "one button mouse" fiasco and crash after crash due to the lack of any true memory protection and yet they have stayed true to their Macs.
Now we finally get a real OS to run on our PPC's and we are still shuned and mistreated by the computer industry. We fianlly get beyond all the jokes about the pretty iMac's and the box thing and now we have to deal with Linux calling the M crap. Just remember Linus, it could have been the Linux kernel if you had been willing to play ball with us, and you know what I'm talking about.
Yours,
Bob
All the best,
--Bob
Pot Kettle Black
Linus vs. Tanenbaum
It's not politically correct to make money selling software, but I guess it's OK to cash in on whatever fame being an open source guru brings you.
Because he felt Linux would well surpass OS X, at least for the target audience. And it has. What would the world be like had Linus said 'Sure, Ill work on OS X, Linux can hold off for a while?' Well, It would still exist im sure, But that early it may not be what we have today.
Linux: Because a PC is a terrible thing to waste.
James Brents
Modern microkernel development has come along a fair bit since suffering such bad press in the 90's. L4, the successor to L3, now refers to a family of kernels based on the L4 API. Jochen Liedtke's implementation for 486s had a very restrictive license. Others have addressed this by offering GPL'd implementations. This list of L4s is a good starting point for thos interested in the topic.
In real terms, the idea of Mach is much better in that the OS is more modular. On the other hand it took a lot longer to get it going.
The advantage of Linux, it it was relatively easy to get off the ground and easier to run development in an ad-hoc fashion.
Linus was just having his fun. Even Gurus, like to troll sometimes.
See my journal, I write things there
Please correct me if I am wrong, but I thought the Mach Kernel was a derivative of BSD. Please set me right if I am wrong.
THANKS!
On a side note, isn't one of the features of a microkernel architecture that you can replace the microkernel? Does anyone else know about the viability of replacing Mach with something better?
This
I like how I got moderated down cuz I said something bad about Linus! Good job, dumbass!
---
evil adrian
Oh please stop, you're hurting my feelings.
---
evil adrian
The only thing more pathetic than a "second post fool on slashdot" is an anonymous coward who responds to them... Which makes me... Oh dear.
It Is the Nature of Information to Transgress Artificial Boundaries
Ironically, if I stayed online two more minutes, I would have replied earlier.
For the two or three of you that will read this, I'll state useful and relative information.
The actual conflict here isn't Torvalds versus Jobs or Linux versus BSD. This is about OS-philosophy, or microkernel versus "macrokernel," as a better term has yet to be adopted. Now there is some personality conflict, as Job actually thought our benevolent dictator would give up work, or even aside Linux and help to create an operating system that *might* take market share from Microsoft.
Now, many of you know about how Linus' teacher's frustration with Minix, a microkernel system, caused him to create Linux, a "macrokernel" system. Mach, much like Minix, is a kernel that requires little RAM loading and refers all function to modular components that are not, in any way, a part of the kernel itself, unlike the Linux modular components which branch off of the kernel.
One of the biggest problems, as stated by Linus in the article is the memory managment and application reference capabilities that kernel possesses, unlike Linux, which, as we all know, can do infinite loops in somewhere around five seconds. Naturally, many microkernels come with this and a few other flaws, but Apple increased the scale of less preferable design ontop of the already obvious flaw--legacy compatablity.
"Classic" Macintosh applications were not designed for a Unix-based environment, and, having talked with a few people who have used MacOS X since beta, the emulator is somewhat laggy and incomplete, and I emphasize, I can not speak from experience, except with my experience using Basilisk like a large number of you in Unix-based operating systems.
Linux, on the other hand, is about placing as much machine-intergrated function as possible into the kernel. Download the latest kernel, it's probably upto twenty-five megabytes, and once you modulate it for your box or system, you're still probably using four to eight megabytes at minimum, and that's being loaded into RAM, unlike Mach, which is designed to only load up somewhere between two to twenty kilobytes, a number I pulled out of my A*, stored there from when that was still current information.
Granted, Linux isn't perfect, especially depending on what distro-base your kernel is using, but perfection can only come based on preference. You want secure, go with OpenBSD. You want portability, NetBSD. You want extensive, Unix; highly supported, Windows 2000; extreme stability, Linux; extremely user friendly, MacOS; a toy that no one knows much about, Amiga (watch the flame mail fly for that one).
Now I could go into all the details of how the kernels work, how they're affected by fily-structures and systems and the difference what type of partition they're loaded on, but I think I've pointed out sufficiently what you need to understand. So, MacOS X users, be not offended, as this is not much different than a Humanist meeting a Freudian; it's all philosophical, and both philosophies are applicable to some extent.
I release this article under the GLP, so, if you have someone all in a huff about what Linus said, you'll be able to settle them...a little. Let's be honest, non-MS users are very fanatical about their OS preference, even if, technically speaking, they're using a totally different OS without realizing it.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
Hopefully, this will be fixed in meta-moderation. As I stated in my own post, people who use non-MS OS's tend to have a fanatasism greater than those who do. I'm sure a lot of the marking has been the result of many moderators' private agendas.
Frankly, this isn't merely an editor's choice, but goes all the way to ZD-Net itself. The article writer (had they any valid background in the unix-based world) would have gone out on a limb and discussed the philosophy, theory and design behind the kernels and operating systems of Apple's BSD-take-off versus Linux.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
I should have said GNU/Linux, but most of you don't really care, so, I won't get prissy over it.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
The Q kernel, I'm actually allowed to change how it works and the OS will adapt. You can have everything, just not perfect.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
A point a made in a different article was about how the Linux OS is structured. You have the kernel, then the shell, the the graphic managment, then the virtual machines, then the gui. A well constructed, though more massive shell, could have everything but the kernel, and, if anyone wants to do what MS started doing, shove said shell et ref. into the kernel in a cute little modular format.
A point I feel I should make is that the running the COSE, classic-os-emulator (normally LOSE for Legacy...wonder why that never caught on) is in fact optional, and will become unnecessary within two years as all your favourites, and even the lesser known, will be ported over to Unix-base soon enough. What many of you should be looking forward to is the accessibility you'll have to great progammes that were never before intended for a unix-based environment.
Personally, I like Linux, but I haven't tried OS X, myself, though, I could download an Aqua like GUI and get the general idea of what it's like. What I'm hoping to be released (one day real soon I hope) from Apple is the Classic emulator they use, which, in theory, must be better than Basilisk.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
We all know my theory...
IT'S ENOCH ROOT!
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
G4 having the power it has and it flexibility...how is it a shakey CPU? Not only would I prefer a G4 to Intel, but AMD as well.
Now Crusoe...that's a processor you can put an egg on...and not cook it!
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
Linus Torvalds has been described as a benevolent dictator; the modifications he likes are added. (taken from Daemon News)
One would figure someone like Linus would embrace the OS X concept, or abide by the old saying... "If you don't have anything good to say don't say it at all." or maybe he read articles like this and was offended.
Or maybe its because some authors claim OSX is a threat to Linux users somehow... I dont see how it could be a threat, but maybe he just needed to vent some frustration. I also don't know how he managed to make time to say that since he seems so busy releasing kernels every week
powered by OpenBSD
360 degrees of Karma
Again, more fallacious information there. At least you could point out something to support your broad statements. When Time Warner was purchased by AOL did that mean TW was going out of business? So what BSDi was purchased... doesn't mean they went out of business. FYI BSDi also makes software OS's for firewalls so don't go thinking its going anywhere any time soon. Instead of posting such unsustantiated bullshit you should post relevant links to support this bs you spew.
360 degrees of Karma
http://get.qnx.com >500mb iso, worth the d/l, will install loopback in windows, the QNX version of loadlin (it doesn't have a name...) _should_ work under dosemu I hear, so go ahead and copy it over after install or use VMware.
SoL
my Karma ran over my Dogma
What ever happened to good software??? Now its "if its open, its good, closed its bad" I like source cause its more efficient, knowing how its made to learn and maybe help out is great too. A kernel that is working and good is way better than one that is just mono or micro.
/dev/null, maybe one day when I become a guru I won't like it, but I'm happy for now...), win98 and QNX.
I use Linux (RedHat, because it was good as a newbie and isn't bad now that I know my ass from
Win98 is out of necessity, most of the ppl I fix boxes for use windows, and I plan to phase it out when I get DSL, by testing all irreplacable apps in wine.
QNX is a microkernel and its great, very stable too, but that cause of the good coding. QNX is older than Linux in fact, it was concieved in '82 as QUNIX and became a released product in 84 with QNX 1.0. It does lack many of the preinstalled apps of Linux and is very poor in the area of having things you are used to in *nix be installed standard, the packaging system is one I actually like as opposed to RPM.
But Linux is a partially monolithic kernel, and is configurable to be otherwise an extent, but still a mono at heart, that still doesn't make it bad, good code beats attributes you think inherently makes something good.
my Karma ran over my Dogma
For once I'm tired of Linus bashing every microkernel out there before giving it a second look. Linus is certainly opinionated on this issue but the truth is microkernels are ready for prime time and are eating linux for breakfast. Mr. Torvalds should pick up a Free copy of QNX Rtp (free as in "our programmers don't want to work for kudos") and check it out. It should be a real eye opener for him.
Your pizza just the way you ought to have it.
linus is afraid of losing his importance. With OS X shipping on millions of Macs by June - with awesome development tools included - AND an open source OS foundation, Linus is just lashing out at anything that makes him less important (and less famous and less valuable). John
Sarchasm is, I believe, defined to be "the gap between the listener and the intelligence level needed to realize a witticism has just been uttered."
"Hardly used" will not fetch you a better price for your brain.
if i refrained from using or experimenting with an OS because the visible figure head was an egotistical ass, who thought they were mental giants... mac and windows would have been scratched off a long time ago...and now i'd have to scratch off linux.....NOT.... i'll keep on using all three os's and others...and i'll be damned if i let those mental giants' pissing match affect my views of technology. i don't have to think highly of jobs or gates to use their creations, sure i can begrudgingly respect them for where they have brought us. now this torvalds opinion...who cares. he's just one man. screw him.
And it will.
that's just it. it's Mr. Torvalds' opinion. i have my own on whether or not the Mach microkernel architecture is "crap" or not, and everybody else has theirs - i wouldn't take it to heart.
erm, heh.