Slashdot Mirror

It seems like some people don't know the story there.

Back in the mid-90s, Apple developed their own port of Linux running on Power Mac hardware. It was called MkLinux. Apple shipped a number of developer releases.

The problem was that, compared to the work Apple was doing on what would eventually become XNU, the Linux work was just not very encouraging, particularly in the area of device drivers. The Linux modular kernel model was also inferior to XNU's. So when it came time to choose a kernel for their new operating system, Apple dropped Linux like a hot potato and chose XNU with I/O Kit instead.

This Web page gives a decent very high-level overview of how XNU was designed, explaining why it was a better fit than Linux for a robust, general-purpose, reliable operating system. Of course, Apple's Darwin documentation is the best source for up-to-date information.

Don't know what you people are smoking who modded me down; everyone knows OS X is based on OpenStep. It's not exactly a secret. Try programming in Cocoa sometime; it's extremely similar even down to the naming scheme.

"It would be an understatement to say that OS X is derived from NEXTSTEP and OPENSTEP. I many respects, it's not just similar, it's the same. One can think of it as OpenStep 5 or 6, say. This is not a bad thing at all - rather than create an operating system from scratch, Apple tried to do the smart thing, and used what they already had to a great extent. However, the similarities should not mislead you: Mac OS X is evolved enough that what you can do with it is far above and beyond NEXTSTEP/OPENSTEP."

--from A Brief History of OS X

mouse wheel - Page up and page down keys, placed on a mouse. That's what that was. Was it done before? I don't know, but I someone somewhere must have had a 5 button mouse and assigned 2 buttons to pageup and pagedown. They popularized it though.

control panel, - You're kidding right? MS didn't invent this. The Mac had this in '92 (for sure), and I'm pretty sure it had one back in '84 when it launched. In fact, there is a screenshot of the origional controll panel from the ORIGIONAL MacOS here.

MS didn't innovate many things, they just tooks things that looked good and used 'em. Just like KDE and Gnome. And how do you know the person who started a controll panel in KDE didn't do it because of the one in the Mac? You're an anti-MS troll. When Honda introduced the Odyssey, it had a fold down rear seat that would fold away. EVERYONE copied them because it was A GOOD IDEA. There is nothing wrong with copying GOOD IDEAS; or should every car compnay have to reinvent the wheel, the steering system, etc.

Yes there is a BSD subsystem that runs in kernel space.

Read your history before you start trolling. Mac OS X is a Unix-based operating system, derived from NEXTSTEP. The command line is included so that way Unix users and former NEXTSTEP and OPENSTEP users can feel comfortable in Mac OS X.

When Apple bought out NeXT Computer, they realized that not only they need to keep the interface of the OS Mac-like, but they also need to make the OS Unix-like, too; what would have been the point of buying a Unix-based operating system if the resulting product wasn't going to take advantage of what Unix offers, anyways?

As was partially approached in this post, the newfound "snappiness" one experiences from a minor update on older Macs almost always has more to do with the prebinding that occurs at the tail-end of the update than actual code tweaks within the software itself.

This article about OsX performance (IIRC) was a slashdot item recently... how soon they forget.

BugBear

And what will it do for all other objects? There is a difference between an intuitive interface and one that takes a metaphor to damn literal.

And finaly:

Since the original Macintosh had no hard disk, and a single floppy drive, it was expected that users will typically use several diskettes while working on the Macintosh. A convenience feature of the system was that it cached (in memory) the list of files on a diskette even after it had been ejected. This was indicated by a grayed-out icon for that diskette on the Desktop, clicking on which would prompt the user to insert the appropriate diskette in the drive. If a user wanted to free-up the memory used by a diskette's cache, he would have to drag the grayed-out icon to the trash.

Thus, even if a user intended to permanently eject a diskette, two actions were required: the eject command, and dragging an icon to the trash. The redundancy was removed by combining these actions to a single action: dragging an "active" (non-grayed-out) icon to the trash caused the disk to be ejected, and its cache to be deleted.

You should take a look at HFS+ Fragmentation.

After six months of use, the average fragmentation was under 1% for 5 different types of users. I know, I know, this is on a Mac. But I'm sure there are other modern file systems that don't fragment, such as ext3 or reiser. I just haven't looked it up.

and found this which looked to be fairly indepth about the history of the Mac OS, including some information on what was taken from what and went into what.

Drivers in the Mac OS X kernel (xnu) use IOKit, an object object orientated device driver framework using embedded C++ (C++ minus exceptions, templates, mutliple inheritance + other stuff).

In this case using C++ at this level in the kernel allows devices to simply inherit most features from base classes (ie/ an ethernet driver can subclass IOEthernetController).

see http://www.kernelthread.com/mac/osx/arch_xnu.html

All of the standard UNIX utilities and scripting languages are included in Mac OS X: editors such as emacs, vim and pico; file management tools such as cp, mv, ls and gnutar; shell scripts including bash (the default shell), tcsh (csh) and zsh; and scripting languages such as Perl, PHP, tcl, Ruby and Python. Python users can also script the powerful Quartz compositing engine.

Take a look at this page.

Come to think of it, HFS+ might be using inodes to reference to the directories/files in these operations internally.

Mod parent up. "Macintosh" the computer is a misspelling of "McIntosh". According to this story(search on "McIntosh") it was deliberate.

Has anyone installed linux on these yet? I swear, you can install Unix on anything these days. Just the other day I noticed someone got one on a GameBoy Advanced. (Link bellow) http://www.kernelthread.com/publications/gbaunix/

You might as well ask why some people love diabolical puzzles - it's simply something they enjoy doing. While there may well be a learning experience involved, the sheer joy of seeing a command prompt on some oddball specialized hardware after 90 hours of hacking really is enough for some people.

As long as it's not a RAW screendump or uncompressed TIFF file or something, there's going to be some interpretation of the file's content to produce the human-consumable output. And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit.

That's basically EVERY file format.

Even text can be dangerous. Ever heard of a terminal or ANSI bomb? (scroll down in link).

The only "safe" viewer is a hex editor. Or less (maybe, you get the idea).

In comparision to the Gameboy, probably not that much....

looking at the relevant page of the FAQ the last model (PDP-11/94) got above 18mhz...which was approx 4x the original speed.

Looking the specs on the link mentioned in the article the GBA has a 16.76 mhz ARM processor (no memory management or cache in this model) *and* a 4mhz or 8mhz Z80 to run the old GB games.

As to your point about NetBSD, the arm port26 runs on the very earliest commericial ARM machines so I see no reason why it couldn't run on a GBA........

ooh now I do, the arm26 port needs 8MB ram.....only 256k on a GBA........but if you can use gampak ram that will give you plenty..

Sadly it seems that people here are very ignorant about the connection between FreeBSD, and Mac OS X, especially where the Mac OS X kernel is concerned. There are a few people here that are claiming that there is not FreeBSD code in the Darwin kernel, only in the Mac OS X command line apps, and this is blatantly untrue.

In order to better see just how much FreeBSD code there is in the Darwin/Mac OS X kernel, and how relevant this work in FreeBSD will be to Mac OS X, please read the following links:

http://www.kernelthread.com/mac/osx/
http://gobsd.com/code/darwin/xnu/
http://www.apple.com/ca/macosx/features/darwin/
http://developer.apple.com/darwin/

Seriously, with so much documentation available, it's unacceptable for supposedly technical people involved with BSD to not know just how important BSD code is to the kernel of a very nice, and hardly secret or obscure operating system like Mac OS X.

Ah, yes... Copeland, Gerswin, Yellow Box, Blue Box, A/UX, ProDOS, Blue, Pink, and Red. MkLinux, MacOS, OS X, System 7, and even GS/OS! Is it just me, or has little old Apple developed more Operating Systems than Microsoft?

There's more about Apple's OS history including Copeland.

Ah, yes... Copeland, Gerswin, Yellow Box, Blue Box, A/UX, ProDOS, Blue, Pink, and Red. MkLinux, MacOS, OS X, System 7, and even GS/OS! Is it just me, or has little old Apple developed more Operating Systems than Microsoft?

There's more about Apple's OS history including Copeland.

This guy installed every operating system out there on his Mac OS X using Virtual PC. His website includes screen shots of each OS, plus what he had to do to get it working. I would like to see a public archive of OS images people can download and try (minus proprietary stuff). That would be pretty cool.

Urm ... are you sure you know what *you* are talking about? Any pointer to evidence to the contrary to what he's saying?

Until then, I'd rather believe him because I think he knows what he's talking about more than you can comprehend. Try to read some of the material in these links:

www.kernelthread.com/mac

www.kernelthread.com/mac/apme

Urm ... are you sure you know what *you* are talking about? Any pointer to evidence to the contrary to what he's saying?

Until then, I'd rather believe him because I think he knows what he's talking about more than you can comprehend. Try to read some of the material in these links:

www.kernelthread.com/mac

www.kernelthread.com/mac/apme

I'd never heard of MS Bob until I read this article. Wonder why it wasn't called MS Bill?

Perceived speed is actually quite important; from the perspective of a personal computer user, it is quite possibly more important than actual throughput. It influences a user's beliefs about his own productivity on the machine, which in turn affects actual productivity. I don't know about you, but on a machine where widgets just zip, I work faster... slow GUIs have the effect of insidiously slowing me down.

Somehow the responsiveness of the Panther UI leaves something to be desired. (I'm running OS X 10.3.4 on a 1GHz G4/768MB RAM)

It is a well known fact that the UI in Cocoa apps are a little sluggish, and in some cases more sluggish than in Windows apps. High-end G5 Mac users probably don't notice it, but it is actually quite obvious on midrange Macs. One gets used to it, of course, and very soon one ceases to be bothered by it--but one cannot help but feel it when one uses a Windows machine at work.

John Siracusa at ArsTechnica actually did an informal test (on scrolling and such, somewhere in this review) and recorded the results in a Quicktime movie file. He compared the speed of Cocoa controls to Win32 controls.

This is also evident if you compare Cocoa to X11. Even the UI in X11 apps running under OS X is more responsive than Cocoa, especially in scrolling. I'm not entirely sure why this is but some people attribute it to overheads in Cocoa.

In my own experience, I have come to the (unscientific) conclusion that for now, Windows apps do seem more responsive than Mac OS X apps on comparable machines (1GHz G4/768MB RAM vis-a-vis a 1.8 GHz Pentium 4/256MB RAM). That doesn't mean the Win32 apps are actually faster, mind you, just that their UIs feel that way. This would one area where Apple could make improvements on, and I think it will.

P.S. Having said all that, Mac OS X has many productivity enhancing features that compensate for its UI sluggishness: robust and fast multitasking, extensive keyboard control, aesthetically pleasant UI, automation capabailities, exceptionally well-designed tools, creatively crafted free apps (like Butler and Tofu) from the community etc. Yes, I cannot deny that I am actually more productive and creative in je ne sais quoi ways on my Mac than on Windows.... for the most part, it's just more pleasant to work on a Mac.

You're generally right about "perceived speed". This article explains how:
10 Things Apple did to make Mac OS X faster.

Emacs is more or less an OS with a bit of hacking.

The kernel is actually called XNU and is based on both FreeBSD and Mach. There's a lot more about it here.

Apple's had a bunch of failures. It's called "research and development." Whenever things get too complex and wierd to support the current appbase, they get the kuybosh and whatever's left is folded into the mainstream. In fact, I'm sure in about ten years we'll start hearing tales of all the cool OSX/iLife/iTMS/iTunes related functionality we'll never see, because it was just too wierd.

Xnu contains code based on Mach, the legendary architecture that originated as a research project at Carnegie Mellon University in the mid 1980s (Mach itself traces its philosophy to the Accent operating system, also developed at CMU), and has been part of many important systems. Early versions of Mach had monolithic kernels, with much of BSD's code in the kernel. Mach 3.0 was the first microkernel implementation.

The ipod has a 630 mAh battery. This is why there are reports that replacing the built-in battery with a third party battery, like at http://ipodbattery.com will result in greatly increased battery life - third party batteries are 20% better, or more, in the same space.

http://www.everymac.com/systems/apple/consumer_ele ctronics/stats/ipod_3rdgen.html

also

http://www.kernelthread.com/mac/ipod/

They should use HFS+.

According to your link, the filesystem, networking, and complete I/O all run within the kernel. In a true microkernel, the filesystem and networking, as well as, concievably (but not necessarily) a portion of the I/O code, would each run as a user-space server process, handling calls for each service through the microkernel. The only thing the microkernel really has to do in such a system is arbitrate calls between client processes and server processes and handle the actual mechanics of I/O.

Someone correct me if I'm wrong. But I've also got AST's book Modern Operating Systems in front of me (just started reading it, though). ``The picture painted above of a kernel that handles only the transport of messages from clients to servers and back is not completely realistic. Some operating system functions (such as loading commands into the physical I/O device registers) are difficult, if not impossible, to do from user-space programs.'' Nonetheless, the kernel should do little more than this; while OS X may indeed take a microkernel approach to design--this I don't know--it has not followed through in implementation.

OS X might be called a hybrid; it has the microkernel messaging, but doesn't really use it. Check out kernelthread for some neat info.

Incidentally--not to reply to my own post--Amit Singh has a great bit on kernelthreat about XNU, the kernel in OS X. Read it here. Basically, XNU does inherit a microkernel design from Mach, but it isn't used as such.

No it is running (part of)the bsd kernel as a task similary to all the other tasks that it is running. To understand the mix of bsd and next have a look at What is Mac OS X http://www.kernelthread.com/mac/osx/

Ideally you wouldn't see your harddrive thrash when booting...

actually, Darwin/OS X has a really nifty feature called BootCache that collects information at boot time and primes the read-ahead on subsequent boots to smooth things out... everyone found out the hard way when it was mildly broken in an update to 10.2 exactly how much difference it makes (it knocks about 2/3 off the boot time of my PowerBook).

see Amit Singh's excellent article for more info, there's a chunk on BootCache at the bottom of this page.

Ideally you wouldn't see your harddrive thrash when booting...

actually, Darwin/OS X has a really nifty feature called BootCache that collects information at boot time and primes the read-ahead on subsequent boots to smooth things out... everyone found out the hard way when it was mildly broken in an update to 10.2 exactly how much difference it makes (it knocks about 2/3 off the boot time of my PowerBook).

see Amit Singh's excellent article for more info, there's a chunk on BootCache at the bottom of this page.

The artists obviously did it because they could. If you want to preserver the "beauty of an operating system" archive them, or better yet, release them to the public free of charge (as some have already done).

This was the internet equivalent of building a model of the Eiffel Tower. Cute, but worthless. I must admit they did a fair job of accomplishing their goal, and they are obviously fairly talented with Actionscript.

That is just one of the sites that noted that it was a deal with Xerox, who thought it was failing as an idea, to give some tech to apple. note: this is not STEALING! It was expected that Apple would use the technology.

Here is a nice link on the subject: http://www.kernelthread.com/publications/virtualiz ation/

OS X is basically the latest version of NextStep/OpenStep. NextStep always had a BSD core (I believe it started with 4.4 BSD). This article provides a history of Apple's operating systems, including the transition from NextStep to Rhapsody to Mac OS X.

Actually, it's a combination of both

all the BSD developers who freely allowed us to steal^H^H^H^H^Huse your code so that we could make millions of dollars selling hardware that we couldn't even make our selves without IBM's help.

OS X uses the XNU kernel, which is based mostly on Mach--not BSD as is commonly thought around these parts. The BSD subsystem is one of many in the kernel. Click here.

"jpkunst noticed over at macslash.org they are running a story about an article on kernelthread by Amit Singh etc etc...


How do you know that jpkunst reads MacSlash?

Is it not entirely possible for someone to have discovered
the article on his own? Does it have to have been "stolen" from
MacSlash, just because it was linked from there previously?

For all you know, MacSlash or jpkunst might have "stolen" it from the RSS feed on Amit Singh's blog.

"jpkunst noticed over at macslash.org they are running a story about an article on kernelthread by Amit Singh etc etc...


How do you know that jpkunst reads MacSlash?

Is it not entirely possible for someone to have discovered
the article on his own? Does it have to have been "stolen" from
MacSlash, just because it was linked from there previously?

For all you know, MacSlash or jpkunst might have "stolen" it from the RSS feed on Amit Singh's blog.

What are the filesystems on current MACs [sic]?

Might as well join the chorus and point out this handy writeup on OS X and filesystems.

the screenshots in question are: rhapsody on intel
Yellow box on XP

the screenshots in question are: rhapsody on intel
Yellow box on XP

The screenshot of rhapsody makes me think something rather neat was lost to the world. While the inner workings of os9 hold no appeal for me I REALLY adored the look and feel of the UI. the simple raised grey windows and 'platinum' themed buttons/menus.

Personally, I'd prefer working in an environment with those windows/gui elements and the cartoonish crisp simple icon style, than that of OSX. I realise it's very much a subjective thing - pity we don't have the choice of looks in OSX to go back to that platinum look

(and no, shapeshifter themes are nothing like the real thing)