Slashdot Mirror
10 Things Apple Did To Make Mac OS X Faster
bariswheel writes "This kernelthread article seeks to investigate further to the inner core of OS X and the improvements therein. The subtopics are the following: BootCache, Kernel Extensions Cache, Hot File Clustering, Working Set Detection, On-the-fly Defragmentation, Prebinding, Helping Developers Create Code Faster, Helping Developers Create Faster Code, Journaling in HFS Plus, and Instant-on."
OS X is the only OS I"ve ever installed that subsequent versions speed up my older computers. Amazing... I'm waiting for an Apple Intel Tower and I'll retire my G4 Tower.
Damn ADC interface.. what am i to do with this big ass cinema display?!?!!?
Check this: http://developers.slashdot.org/article.pl?sid=04/0 6/03/130214
GNOME has become increasinly faster with each release. It's not just Mac OS X. You don't get out much, do you? GNOME 2.14 is supposed to be extremely fast in comparison to previous releases, which were also faster than their predecessors.
Offtopic, but slashdot is telling me that this story has "2 of 1 comment". heh.
The website even has a link to the old slashdot story: http://developers.slashdot.org/developers/04/06/03 /130214.shtml
If Apple is going to bother optimizing other stuff on the OS, they should at least give you a way to turn off some of the extras when it comes to the GUI.
I don't need high resoution icons, drop shadows, dragging window effects, minimize effects...etc. In windows land, you can turn most of these eyecandy effects off and performance is greatly improved. You'd think that Apple would have considered this when releasing a computer with 256mb of ram on the base model (G4 mac mini). I love the computer, but it is SLOW.
what about Linux? Could it obtain benefits implementing some of the improvements made into MacOS X? I've heard about BeOS and the incredible perfomance due to multithreading, it's very dificult to adapt an BeOS kernel to the Linux features (multiuser, drivers...) maintaining the perfomance?
I updated from Panther(10.3) to Tiger(10.4) and my machine seemed slower. I decided to do a fresh install, and things improved, as always the fresh install is better than an update.
I still think that Panther was running a bit faster tahn Tiger, maybe it is the widgets..........
silly widgets!
This was all done on a PowerBook G4(TiBook).
Linux gets faster too.
Kernel 2.4 to 2.6 was a pretty big jump in speed. I just upgraded to the latest KDE and a bunch of other updates, and got another performance jump. Once they shake the bugs out of the Radeon drivers for X.org, I'll get accelerated X, and another big speed boost.
In fact, of the major OSs, it's pretty much only Windows that keeps getting slower.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Read Slashdot articles the day before on digg. What is needed now is a RSS reader that will weed out duplicate stories from the feeds I subscribe to.
I much preferred Mac OS back in the OS 9 days. OS 9 screamed in comparison to OS X. It had its problems, sure, but at the time it was the only mainstream OS that was not built on technology besides itself.
Nowadays everything is built on some form of *nix. Even MS is originally based on VMS, so in fact, everything is based on some form of *nix.
Like I said, I preferred OS 9 and when OS X came out, I used it for about a year, sold both my Macs and moved over to Linux. I cannot justify $129 for an OS. Paying for the hardware is bad enough.
somebody made a list about ten things that don't work as well as they should (and as a mac admin I agree) : Ten More Things I Hate About Mac OS X
a while back, when OSX.2 had recently came out, and I was still running on an iMac G3 (with 256mb of RAM), I got OSX. it ran much smoother than OS9 did.
I never used OS X, but getting faster with a new version is not new to me. ... it runs much, much faster. ... faster kernel and faster gnome. Besides, gnome is the one application that allways improve, since 2.2, there have always been speed improvements.
Having debian sarge inn my celeron 1000 laptop, upgraded to etch a few days ago and
There are 2 reasons, mainly
Steve B.: But they can't match our rate of innovation! I've got over 12000 developers working on Windows OS alone! Their staff is a small fraction of that!
Mr. CIO: That's why we're moving to OS X.
Consider the following a sampling of such optimizations, in no particular order
I'm somewhat concerned that an optimisation geek did not order his data set.
OS 9 only screamed when you only ran one-maybe two applications at the same time. I would never have dreamed of trying to run the 15-20 explicitly instantiated applications (plus only God knows how many system instantiated processes) on an OS 9 box and expect it to be fast. And that is not counting the number of reboots I would have to make throughout the day.
I'll take OS X any day over OS 9.
For all the talk about the speed of OS X, Apple has never addressed the most obvious issue: on a machine that can run either OS 9 or OS X, OS 9 is very much faster. They took an OS written from the ground up in the early 80s to be graphical, and replaced it with an OS written the 70s to be textual, with the GUI glued on top of it.
And then even worse, the people who wrote Carbon, the MacOS backward-compatibility layer, had no idea how to write it to be fast - simple calls like HLock which used to be two instructions on the original 128K Mac are now thousands of cycles under OS X. (And Apple's answer to this? "Remove your HLock calls; they don't do anything anyway.")
Don't get me wrong; they've done great things, given what they started with. But they threw out the baby with the bathwater when they ditched MacOS.
(sig) The last bug isn't fixed until the last user is dead. (/sig)
It used to be that OSX had a brain-dead ABI that resulted in not all of the PPC registers being used 'properly', in order to maintain a 68k 'compatability' mode ..
Has this been changed? Are all the registers of the PPC being used properly now? Is the PC register actually being used as a program counter, rather than one of the generic 32-bit registers?
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
From the article: I hoped that by pointing out rough edges in the user interface, readers would say, "I never noticed that before, but you know, that really is very annoying and should be fixed." Boy was I naive.
The article touched a nerve with many Apple apologists and set off a firestorm of controversy.
And that is precisely why I will never ever even consider getting a Mac. The users.
(Ok, so there are more reasons, like I don't see any win, but rather a loss of freedom and a step backwards on an interoperable world if I buy into the proprietary system of any vendor. But that goes for many others, not only Macs. These users are pretty much a monopoly though).
One problem... Gnome sucks.
Before OSX, the mac had the reputation of the machine that crashed all the time. By comparison, Windows was actually pretty reliable (this was before all the spyware/malware/crap that affects it recently, remember). Linux was best, of course...
Now you're just displaying your ignorance
newsflash:when you need to do more work because you're in a far-more-capable and complex environment, it can take more machine-instructions to perform the task. This is just griping - the world has moved on from buggy, insecure, crappy-old OS9. Move with it.
They didn't throw any babies away, they did what they needed to do (ditch the abortion that was OS9) and move onto a new platform which provided the security, flexibility, and reliability that any modern OS provides. A brave decision, under the circumstances, and one well-conceived and executed.
Simon
Physicists get Hadrons!
The HFS plus approach seems like a good idea, but I'm wondering if there is a performance cost, both in CPU cycles and drive wear and tear. It also looks to me like the system could be defragging files that are already contiguous, but I may be wrong. Given that modern journaling filesystems (supposedly) are not likely to become fragmented in the first place, is this feature worth it?
Ideology: A tool used primarily to avoid the bother of thinking.
Oh, and I recognized this article as a dupe within seconds, yet CowboyNeal couldn't at all? Ouch.
Well, the original Amiga OS is considerably faster than Mac OS 9, the problem is there is no task isolation, memory protection, or security to speak of.
The classic Mac OS is even worse off, because the system API was not designed for a pre-emptively multitasking environment, let alone kernel / user mode separation. Too much application level access to systems globals at fixed addresses in particular.
In any case, whatever the problem is, it cannot be blamed on on adapting to "textual" OS. Adapting an insufficiently forward looking design to the modern world is more like it.
As long as you're waxing rhapsodic about that OS "written from the ground up in the early 80s to be graphical", you might also remember that it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security.
Any of those things that were added on later were major hacks to the system. Some, like the non-preemptive MultiFinder (switcher) were ingenious hacks, but hacks nontheless. Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?
Or that, since you mentioned HLOCK, why a modern OS should have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application. Or why a program needs me to allocate more memory to it when there's a half-gig free?
Or perhaps you can explain just why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?
I mean, if you really take the time to actually think about it, you might find that the "good old days" are in fact nothing but a fond, hazy memory... and far removed from the truth.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Mod this up.
for better or worse, no machine running OS X should be with less than 512 MB. that may be a deficiency on apples part for shipping it that way, but its way it is. Fair warning.
If you do graphics stuff, a gig minimum.
While Windows gradually slows down with Service Packs, and completely grinds to a hault on all but fairly new systems with new versions, OS X actually manages to speed up due to developer optomization. Good strategy...
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
for good reason they ditched baby. If by faster, the system would crash if you farted into the wind, yes it was faster. C
certainly not more stable, and thus more productive.
If find not rebooting 3 times a day makes me faster at everything.
XFS supports defragmentation. In the xfsdump package there is a tool called "xfs_fsr", which works great on running systems.
On all my servers I use XFS on all the non-os partitions. Same on my desktops. I run xfs_fsr nightly out of cron, and everything stays very fast. Even with the dozens of VMWare disk images I have all over the place.
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
Journalling makes files accesses slower. The only time it speeds anything is in the error case of unsafe reboots (crashes). And I get those so rarely, I'm sure that I come out way behind on performance due to journalling.
http://lkml.org/lkml/2005/8/20/95
> They didn't throw any babies away, they did what they needed to do (ditch the abortion that was OS9)
> and move onto a new platform which provided the security, flexibility, and reliability that any modern OS
> provides. A brave decision, under the circumstances, and one well-conceived and executed.
Yeah, they switched to an essentially clean and elegant UNIX base, and then proceeded to add more bloat and cruft on top of the bloat and cruft previously added by NeXT. They made the OS slower by tacking on a ton of shit, and then "optimized" it by hacking away some of the wasted cycles and disk operations.
Want a summary of how Apple "speeded up" OS X? Here it is: "caches and kludges."
I'm typing this from a Dell C810 laptop running Win2K, SP4, and every freaking hot fix know to man -- and it's every bit as fast as it was when I bought it four years ago (used) from Dell.
wicked, wicked slow. Something about the mach 'microkernel'.
My mac is so slow, it takes half an hour to move a 17MB file. Actually, not *that* slow, but it's hella slower than my linux pc. The weird thing is, I don't even know why it's slow, we recently upgraded it from 10.2 to 10.4 (wipe and install) to make it not slow, but it is still slow. It's an 800MHz G4 with 256MB of PC133 and a GeForce4MX with 32MB. My PC is a 1.3GHz Celeron with 256MB of PC100 and an Intel i810 Integrated Graphics "sharing" 2MB from main memory. And yet, with 2.6, when I have GIMP, several emacs windows, like at least 25 firefox tabs across multiple windows, VLC, Rhythmbox, GAIM, xchat, and I can't remember what-all else, it doesn't skip when I start playing movies in MPlayer. Whereas this mac, skips unless I quit out of half the programs.
Maybe Apple should ditch XNU and use Linux?
Please, somebody, debug that!
Rethinking email
Hi, I use mac stuff since may 2005, I sold my boring/noisy/energy hungry/ugly... 2.4Gh P4 for a mac mini witch I sold last month for a core duo iMac. Sine then, I never had to defrag my disk or do anything else that Windows still needs not to sink. Since Windows can now run, with some work on your part, on a mac, why not then consider buying a mac instead of a regular Windows machine? After all, VISTA will probably not ship until 2007 or later. To this date, VISTA has been announced for 2003, 2005, 2006 and now 2007!!! ans OSX is there NOW "Happy macking !"
My machine can run both OS 9 and OS 10.1+. OS 9 is not faster. Why? I have dual processors, which OS9 does not use very well, or I should say, much at all. OS 9 is dog slow compared to 10.2 and up.
Choosing the lesser of two evils is a choice for evil.
since I screwed up, here's the rest:
e nts" which now expands their one collumn to occupy most of the window.
I'm not sure I agree with all or even most of his points of contention.
In issue 1 for example he complains that each open/save dialouge starts out the exact same way and then goes on to complain further in the article that the OS isn't always consistant. It's consistant for each dialouge to remain the same size by default until the user specifies a change. Furthermore since the size of the dialouge can be set per application, that size would need to be specified by the application making having a universal override obnoxious.
In his 2nd point he's descirbes a senario which is at best extremely uncommon and then describes a process which is obnoxious and complicated when it's easier for most people to either have an automator script to open specific things they want or even better for his senario and automator script which asks where he is and then opens the appropriate applications. A simple applescript for the applications one doesn't need all the time with a prompt at the begining to ask whether to launch the remaining apps and then placing that script in the login items folder seems more useful and less annoying than check boxes to enable and disable each item that you must do before loging out the previous time.
point 3 he's correct on
point 4 he's correct on the disapearing sidebar but on the issue of double clicking the boarder, it's a rather difficult task to accomplish accidently so I am sure anyone doing it would notice the dimple before and after.
point 5 he's moving away from his consistancy argument again. With the column view you set the size of the columns and the number of columns, and if you chose to physicaly change the display you can. What he's suggesting is a display system which dynamicaly changes size to fit the content of the display which while it could be benneficial to some people seems overly complicated and a major violation of the consistancy guideline. It's concieveable to see a situation there where all of a sudden you would go from having 4 collumns displayed to having 2 or 1 because you have one file in the display such as "com.apple.Components2.LocalCache.QuickTimeCompon
point 6 he's correct on
point 7 he's got a point but at the same time, with the addition of the PDF abilities and the fact that faxing IS handled with PDFs it does make sense to put it under the PDF button. In the end I don't find it much more of an abstraction than his recomendation to make it an availible printer.
point 8 I can see a method to the madness in that if the next set of startup items require the server, it's important for you to know that the server is not availible BEFORE those apps launch and fail. There may be a better way, but I don't agree that it's a failing.
in point 9 the views update for the column view I think is a good thing. While it's not 100% consistant, in this case it would be irritating for a directory I'm working with to rename and then immediately move out of my working view until I indicate being done with the directory either by being idle or moving to a new object.
The size information I would assume is an updating routine thats scheduled rather than called.
in point 10 if he cant see a situation where a user might unknowingly or mistakenly change their file extention then he needs to think harder. The checkbox would be nice though but it's also nitpicking at this point. It's a potentialy destructive action, and a user should be reminded to think before they do it. Being able to permanently dismiss such reminders is what gives viruses and other malicious programs a better chance of succeeding.
T Money
World Domination with a plastic spoon since 1984
Doesn't Apple use gcc?
I know gcc itself improved a very great deal over the same time period, and I have always assumed that the speed gains were (largely? mostly?) due to that, rather than wondrous new algorithms on Apple's part.
Linux and KDE sped up a lot too, over the same timeframe.
Windows 95 actually sped up a lot of work and applications on the then current generation of hardware, IF you had what was then tons of ram and a big CPU [1] and made sure you weren't running anything that made it revert to timeslice multi-tasking etc... I can't really remember the details and I'm sure I don't want to, but I do remember that many multimedia and multi-tasking (Which in win 3.x was really more like task-switching) worked much better than in 3.x Don. 1: You know big fast machine, like a 486DX80 with 24 megs of ram or something, and a four or five hundred megabyte hard-drive.
My favorite was the IWM or Incredible Woz Machine. It was the disk controller used in Apple IIs and early Macs that slowed down the drive motor when the disk was accessing the outer tracks, which allowed it to squeeze in a few extra sectors. Of course, it also made Apple/Mac floppies unreadable on systems that didn't have similar special hardware....
Well, not exactly, but here is the list of gripes and complaints I've accumulated over six months of using a Mac Mini (G4 1.2Ghz, 512MB RAM) as my primary machine for the last 10 months or so. I live in Israel and need Hebrew for daily work, so some complaints are specific to that.
.DS_Store and perhaps others. I don't want these files on my Windows machine!
OS and GUI
* Mouse cursor moves sluggishly. Requires purchased software (USB Overdrive) to make it move as expected, i.e. speed of cursor is proportional to the speed at which I move the mouse.
* SMB can't network share anything but user directory (what about mounted disk images, CD's, single folders?)
* Can't FTP share anything but a complete user directory. Gives remote user far too many privileges (user can switch to root directory, other user directories, etc).
* GUI: Red "close" button has inconsistent behavior: hide (Mail)/close (Safari)/quit app (iPhoto).
* GUI: Configuration menus are inconsistent. Some are "ok/cancel" like Windows, others are "change anything and it changes immediately, no second chances".
* If "Show Item Info" is selected for the Desktop view, the volume icons only update their free space at restart (or when Finder crashes).
* Data CDs burned in Finder with MP3 files will not play well in the car MP3 player. The car player will take over a minute mounting the disc and is slower at changing tracks. I have no idea why this occurs, but I'm burning my CDs on the PC.
* Hebrew file names don't work well and are not always compatible with Windows file naming. Downloaded files may or may not have garbled names. In SMB shares, Windows sees Hebrew names as garbage.
* Finder pollutes write-enabled SMB shares it accesses with garbage files like
* Finder: No right-click > open command prompt here (well, neither does Windows, but easy to add with a Powertoy).
* Finder: Can't easily know the size of the contents of a directory (without "get info"), or the total size of more than one selected item (even "get info" doesn't help there). Windows Explorer is superior here.
* 90-degree screen rotation is supported as a display option but is horribly slow and effectively unusable.
* Inconsistent installation of applications. Some are dragged to the apps folder, others have an installer. Many things added with an installer have no uninstaller anywhere, so you're stuck with them (how do I cleanly get rid of X11? and XCode? Without using the command prompt?). Also, when removing an application it is difficult to remove its traces (in the Library folder and others).
* There is no easy way to categorize applications. Everything is bundled up together in the "Applications" folder. You can add subfolders manually, but that makes updating and installing new applications more complicated.
* Marking text and then attempting to drag the selected text elsewhere - sometimes works, sometimes doesn't (the drag operation simply selects some more text).
* An application (for example, MPlayer OSX) can render the sound system completely unusable (to OpenGL/SDL games and applications, but not system sounds) such that not even a reboot helps. Only playing a regular 16-bit, 44.1kHz sound file in MPlayer solves the problem, or editing a setting in the obscure Utilities\Audio MIDI Setup.
* My machine never crashes nor is ever powered down without a proper shutdown, and yet I have had several cases of files being corrupted, lost completely or simply set to "Zero KB", for no apparent reason. I have lost photos, audio files and others.
* Network operations are unbelievably slow when talking to the other machines in the house. This is a 100Mbit wired LAN, but the speeds I'm actually getting are more like 10 Mbit/s for data flowing from the Mac to a PC and 200kbit/s in the opposite direction. Affects any kind of network operation (SMB, FTP, etc). I've tried various fixes suggested on various forums, no improvement.
Applications
* NeoOffice/J is unbelievably slow, taking as much as 30 seconds to load
QUICKSILVER
:( )
Get it
Use it
Good
( P.S. Caps Lock would have been autopilot for COOL, but the lameness filter caught me
Apple has been contibuting to GCC too you know. Objective C support, PowerPC optimizations, etc (scroll down to optimizations). Another advantage of OSS. The improvements on their hardware were due to their own efforts, and much more radical than the increases to x86 Linux.
Unfortunately, on the Intel side, Apple is going with the Intel compiler, probably because it's faster than GCC Intel. No OSS. But maybe Apple doesn't need to contribute to that because Intel will keep doing good work.
Lies about crimes
The kernel of Mac OS X was not written in the seventies, and has in fact been in active development since the late 80's (roughly). It's a descendant of Carnegie Mellon's Mach kernel , which is well designed and was written from the ground up for SMP and preemptive multitasking - two concepts that OS 9 and it's predecessors were more or less totally ignorant of.
What OS 9 managed successfully (most of the time) was the appearance of speed, as the gui was relatively light weight and the frontmost process got most of the CPU. Try running the webstar webserver on OS 9, and a couple of network shared folders, and then see how fast OS 9 is - my OS X box can handle the same load and still be a usable machine - something that was not possible on OS 9.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
The article is an interesting read, and it's definitely the type of article I wish Slashdot linked to more often. Dupe or not, thanks.
The bits on the bus go on and off... on and off... on and off...
Only one small nitpick with your rebuttal. On security, I think you're half right. In-person, at-the-computer security, you are spot on. No login - turn it on, and you're in, unless you had some 3rd-party security tools installed. If security was at all a concern, your physical security is what made any difference. However... It had no command-line, no SSH, no telnet, no http, no ftp, etc. No real network services (by default) at all. That, by default, made the original branch of Mac OS *very secure* from a *network* security standpoint.
ask any a+ student who's passed in the past couple of years, they don't cover ME. basically, don't use it. it sucks. it is not recgonized as an actual opertating system. they used to test based on win98, win98SE, win2000sp2-sp4, and winXP. inherient stability in ME is bad.
however, don't bash the system restore point utility, sure it created a backup of a lot of system files for emergency rollbacks, but i don't know of anyone who complained about it in win2000sp4 or winXP. and as for the disk recovery, you can get a copy of win2000 with the same ability, or winXP has it on all the versions (i believe).
and as for windows ME eating souls, yes it does. it likes a bit of ketchup to go along, they are kindof dry anymore.
I don't think I completely agree with whole unix analogy, a lot of work has been done since the '70's...
It's like saying saying I was "written" when I was born, I wonder how many of my cells are still around since 1958?
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
That you're still calling it NeoOffice/J shows you're using an older version of NeoOffice. They've dropped the "/J" and are just calling it NeoOffice. They recently released NeoOffice 1.2. The major change in it is that is uses JRE 1.4 instead of JRE 1.3. JRE 1.4 uses Cocoa to draw widgets where as 1.3 used or mostly used Carbon. The recent release is slightly faster on startup and quite a bit faster in use as they removed a lot of reliability hacks that were needed when they were using JRE 1.3. Menus and widgets in particular are quite a bit improved.
I think the recent release of NeoOffice will still irritate you but maybe not as badly.
Go to your OS X machine and start up Activity Monitor.
(/Applications/Utilities/Activity Monitor)
Then pop open your widgets, then switch back to your desktop.
It looks like the little buggers seem to stay loaded, consuming RAM and virtual ram space even when idle.
For people loading up a bunch of widgets and then running their system, it looks like idle widgets can eat up megabytes of RAM very quickly.
Not good if you only have 256MB!
Close out all the widgets using the little (X) and the RAM goes free again.
Use a widget and then close it, not just hide it.
That when it comes to preventing dupes, a community approach is no better than an editorial approach. Thus let's have the end of the "Digg is teh better" trolls.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
Helping Developers Create Code Faster,
Helping Developers Create Faster Code
I can think of a few other useful permutations:
Helping Create Code Developers Faster
Helping Create Faster Code Developers
Helping Code Create Developers Faster
Helping Code Create Faster Developers
Helping Faster Developers Create Code
Helping Faster Code Developers Create
Helping Faster Code Create Developers
Developers Helping Code Create Faster
Developers Helping Create Faster Code
Developers Helping Code Create Faster
Developers Helping Faster Code Create
Developers Create Helping Code Faster
Developers Create Faster Helping Code
Create Helping Code Developers Faster
Create Developers Helping Faster Code
Create Code Helping Developers Faster
Create Code Helping Faster Developers
Create Code Faster, Helping Developers
Create Faster, Helping Developers Code
Create Faster Developers, Helping Code
Create Faster Code, Helping Developers
Code Helping Developers Create Faster
Code Helping Create Developers Faster
Code Helping Create Faster Developers
Code Helping Faster Developers Create
Code Developers Helping Create Faster
Code Developers Create Faster Helping
Code-Faster Developers Helping Create
Faster-Helping Developers Create Code
Faster-Helping Code Create Developers
Faster Developers Helping Create Code
Faster Developers Helping Code Create
Faster Developers Create Helping Code
Faster Code Helping Developers Create
Faster Code Helping Create Developers
Faster Code Developers Helping Create
Choose a research topic! Lucrative grants to be won! (Topics involving procreation by/of developers expected to go quickly.)
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Pining for OS 9 is the A #1 best way to spot a hardcore Apple fanboy. Only people who truly fetishize the company and its history miss that OS (or any that preceded it). Those of us who like to get stuff done with our Macs love OS X now.
(Written on an iBook G4 w/10.3, as someone still running a Powermac 6100 with OS 8.6 in my study...but that's because I'm cheap, not because I think it was great.)
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
"You see that?! Your Stupid Minds!
Stupid! Stupid!"
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
...in OS X uses a sharper acceleration curve than on Windows. Nudge the mouse, and the pointer moves a couple of pixels. Jerk it the same distance, and it'll fly across a hi-def Cinema display. It can actually move much faster than the Windows pointer.
It's a matter of re-learning your hand-eye-mouse coordination. If the USB Overdrive behavior were the default, millions of graphic artists, and anyone who needs fine control, would cry out in anguish.
The US free market: two halves of a government-granted duopoly are free to set the market price.
Wonder if anyone noticed, but this site has already been /.'ed. OS X must be pretty damn fast if people are still talking about the speed after two years. Hell, I even use it and it seems fast. Anyway, semes a little weird what stories get posted and which don't...
How is an honest dissenting opinion "flamebait"? AFAICT this is an accurate summary of how Mac OS X grew - they fattened it up and then trimmed some of the fat!
performance under load? As reported here: http://www.anandtech.com/mac/showdoc.aspx?i=2520 OSX has to this time had severe performance problems under load for Web applications, does it look like the improvements in this article will help?
Does locating so many files that are accessed so often in one part of the disk cause that section to fail more quickly than if all of the "hot" files were to be left where they were? I'm wondering what this does to the life of mechanical drives.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
There was no such chip as a 486DX80.
"it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security."
Incorrect. It was designed to allow 3-bit color, actually - the quickdraw headers defined 8 colors, not two.
"Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?"
The overhead of swapping out a hundred low-level globals in 2006 is, oh, about a hundred cycles. Oops: swap, so 200. Whoop-de-doo. People complained about that when a lot of the user base still had 68000-base machines running at 8MHz, but it's just not a factor these days. Even so, you could re-write OS 9 not to have so many globals without the extensive re-write that was OS X.
"why should a modern OS have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application."
Oh, so the OS causes your app to crash? I could respond that multi-threading causes so many hard-to-understand bugs that it's responsible for half the crashes, but I'm against the shirking of responsibility.
As for Handle-based, Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory - albeit at the expense of slow compactions from time to time. Not so far removed from Java, actually, though without the benefit of automatic garbage collection. The OS X equivalent - to just use Ptr-based memory instead, and swap a lot, is one of the reasons OS X requires a lot more RAM than OS 9 does. (Well, it doesn't actually need the RAM; but you'll swap a lot without it.)
"Perhaps you can explain why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?"
The system resource, process-slicing kernel of the OS doesn't need to be graphical. And indeed the nanokernel inside PowerPC Macs was not. But layering graphics APIs on top of file-based IPC mechanisms introduces dramatic inefficiencies. Networking and file management had a pretty solid base under OS 9, just not a fast one. (file access is one of the few things where OS X is notably and dramatically faster, incidentally - e-mail database rebuilds are about 2x faster under OS X.)
(sig) The last bug isn't fixed until the last user is dead. (/sig)
Agreed. I don't know how I survived prior to discovering Quicksilver years ago :)
Here's a link for the less initiated: http://quicksilver.blacktree.com/
Note that there are a number of plugins that you'll want to look at and probably install, including the Spotlight-inspired interface, the calculator (handy for quick calcs), email, chat and others. Look in the preferences to download and install them.
This is retarded. Mac OS X - which is based on one of the slowest operating systems in the history of UNIX (Mach) - performs terribly. Microkernels were a terrible idea in practice; that's why everyone moved their shit into kernel space (and gave up the benefit of having a microkernel in the first place).
p =1
It took Apple until the Tiger release to make the kernel's locking scheme any finer than ONE network lock, and ONE "everything else" lock. Reminds me of the days of cli()/sti()/lock_kernel() in Linux. (In Tiger, there are something like 5 or 6 locks -- still a disaster.)
The funny thing is when Anandtech did a Tiger review some time back to measure the performance. Considering the delta between modern Linux and OS X (Linux measuring in at ten times faster in some places), it's outstandingly shocking that anyone would say OS X performs at all. Windows puts up a *much* better fight.
http://www.anandtech.com/mac/showdoc.aspx?i=2436&
Any of those things that were added on later were major hacks to the system. Some, like the non-preemptive MultiFinder (switcher) were ingenious hacks, but hacks nontheless.
One of my favorite hacks, introduced with System 7.1, is the Fonts folder.
Prior to System 7.1, all fonts were resources stored in the System suitcase. Since the System suitcase is always open, its resources are available to all applications, so any application can use any fonts that are in the System suitcase. If you were to use ResEdit to copy a font resource into a text file and open it in SimpleText, the font would be available in SimpleText as long as the document was open, even if the font was not installed in the System.
Prior to System 7, the typical way of managing them was to use the Font/DA Mover application to move font and desk accessory resources between suitcase files; System 7 added support for this in the Finder. A bit of trivia: the only time you'll ever see a "Move" progress bar in the Finder is when moving something into/out of a suitcase, since there's no UI to move a file between volumes (you can only copy, then delete later).
System 7.1 introduced the Fonts folder. All resources in any file placed in the Fonts folder that looks like it should be a font (i.e. a font file or a font suitcase) will be loaded as if they were in the System suitcase, and accessible to all applications. Notice I said all resources, not just all font resources. So, if you were to create an empty font suitcase, and use ResEdit to copy non-font resources (such as icons) to it, then drop the font suitcase in the Fonts folder, all those resources will be loaded as if they were in the System suitcase.
Yeah, I'm a Mac nerd.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Network transfers. We chose Dell 1425s running Fedora instead of XServes running 10.4 largely because our benchmarks found the XServes had a huge network latency. It took us almost ten times longer to emit packets in some cases.
I found the comment about "instant-on" sleep to be amusing.
Yes, we're fully aware that Apple systems can shut down everything execept the components necessary to refresh the DRAM.
The author of the article, apparently, has never used a PC notebook or desktop. Practically every well-behaved system made in the past 5 years, from the $150 eMachines desktops to my generic Compal notebook, supports the ACPI S3 state, which does exactly what Apple's "sleep" mode.
What's really slick about Windows is that the system can wake from S3 suspend and hibernate itself after a certain period of time. My system is set for 6 hours, which means that I don't have to wait for the system to restore during the day, but if I leave my system overnight or longer, I don't have to worry about suspend draining my battery (approx. 20% per day). I can even have different settings if the system is plugged in.
simple calls like HLock which used to be two instructions on the original 128K Mac are now thousands of cycles under OS X
This is highly unlikely. HLock originally only ever set a flag. It now doesn't even need to do that, since a Handle never moves under OS X, but if it did, it still would only need to set a flag. Even allowing the overhead of calling through a shim into Carbon this wouldn't amount to a huge call. There may be other APIs that do exhibit the behaviour you mention, but this was a very bad example to pick.
IBM shipped MVS in 1974, DEC began development of VMS in 1975, therefore MVS (and it's predecessor MVT or OS/VS) was the first widely used commercial operating system with virtual memory support
I don't know about UNIX, maybe it was before 1974?
Ask Me About... The 80's!
For all practical purposes it was B&W unless you were printing, and even then you had to jump through hoops. To get color onscreen we needed the nearly complete rewrite that was Color Quickdraw on the Mac II. And which nitpicking ignores the rather more serious "single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security" issues.
"The overhead of swapping out a hundred low-level globals ... but it's just not a factor these days."
Right. Because when you're switching application contexts a thousand times a second you really want to waste time moving hundreds of discontinuous memory locations. Heck, these days just swapping out the stack is a performance hit that has systems designers gnashing their teeth.
"Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory".
And we still had an entire cottage industry devoted to memory managers and debuggers that tried to track down the bugs that system encouraged. And still ignores the fact that just one of those bugs could crash not just that application but the entire system. And still ignores those wonderful fixed-size partitions.
Face the facts. If "rewriting" a few parts of the system were that easy they would have down it. The system design was perfect for a 128K Mac, and horrendous as you attempted to scale it. System globals were scattered everywhere and the non-protected patitioned memory scheme was attrocious.
Worse, practically no system call of any consequence could be done in a preemptive environment. Attempting to do so caused all sorts of bottlenecks and deadlocks, and the existing SystemTask-based swapping system allowed a single resource-hogging app to bring the system to its knees.
Like I said, you need to take off those rose-colored glasses. True, the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
I have to respectfully disagree. I go to a highschool with 1 OS X computer and something like 15 OS 9 computers in the library. So from experience, I can say that OS X is much faster. Granted, school computers are always slower, but when things like dragging a window cause a redraw of most of the screen, it's time for a change.
> This is highly unlikely. HLock originally only ever set a flag. It now doesn't even need
> to do that, since a Handle never moves under OS X, but if it did, it still would only
> need to set a flag. Even allowing the overhead of calling through a shim into Carbon
> this wouldn't amount to a huge call. There may be other APIs that do exhibit the
> behaviour you mention, but this was a very bad example to pick.
I can't tell if you're clueless to the horrible Carbon implementation under OS X, or just baiting me.
I was one of the people involved in the port of Mac Office to OS X, at Microsoft, during 2001/2002. My particular job was to make Entourage perform fast under X, and one of the things that repeatedly came up when running Apple's sampling profiler tools was time spent inside HLock/HUnlock. Apple's answer, rather than making HLock/HUnlock faster, was "just remove your calls to HLock and HUnlock, since they don't do anything anyway."
Unfortunately the code in question came from a third-party text rendering engine, and the locked-or-not state of handles was actually important, so I couldn't just get rid of the calls. But the time I spent reducing the frequency of them being called made things much faster.
Later on I talked with the author of iTunes about this, and he remarked that he was able to just #define away his HLock/HUnlock calls, for OS X iTunes. (OS 9 iTunes still needed them, of course) He said it made the app smaller, and about 10% faster.
(sig) The last bug isn't fixed until the last user is dead. (/sig)
> For all practical purposes it was B&W unless you were printing, and even then you had to
... but it's just not a
> jump through hoops. To get color onscreen we needed the nearly complete rewrite that was
> Color Quickdraw on the Mac II.
Yes. But you know what? That didn't require a ground-up rewrite. And they added a lot more than color: support for multiple screens and support for third-party graphics cards, for example. And if you wanted run the screen in black-and-white, you could still do it - something you can't do in OS X.
> "The overhead of swapping out a hundred low-level globals
> factor these days."
>
> Right. Because when you're switching application contexts a thousand times a second you
> really want to waste time moving hundreds of discontinuous memory locations. Heck, these
> days just swapping out the stack is a performance hit that has systems designers gnashing
> their teeth.
I wish more of those systems designers worked at Apple.
hundreds of discontinuous memory locations... OK, let's say 100 4-byte values plus 100 2-byte values. That's 600 bytes.
Now let's look at the bare minimum of what a PowerPC has to swap: 32 32-bit registers plus 32 64-bit floating-point registers plus 32 128-bit AltiVec registers, plus the 32-bit PC and 32-bit condition-code register. That's 32 * (4+8+16) + 32 + 32, or 960 bytes.
You remind me of the folks who used to complain about Apple's "Ticks" low-mem global, which kept track of how many 60ths of a second had elapsed since system startup. They complained because it wasn't aligned on a 4-byte boundary - yet it was accessed so often - read and written to!
The reality is, it just doesn't take that much longer to increment a mis-aligned longword. On later PowerPCs it makes absolutely no difference, in fact.
By contrast under OS X, if you want to read the value of Ticks, you have to call TickCount(). But under OS X, that first makes a call which determines the number of microseconds since start, turns that into a floating-point variable, and then turns it back into an integer. Old OS X programs (like Metrowerks CodeWarrior) called TickCount() a lot to see if enough time had elapsed to check for user interaction; those programs had to be re-written because suddenly the call to TickCount() was a bottleneck!!!
> And we still had an entire cottage industry devoted to memory managers and debuggers
> that tried to track down the bugs that system encouraged.
I believe there is still a cottage industry for memory managers and debuggers on Windows and Linux. No?
> If "rewriting" a few parts of the system were that easy they would have down it.
Now you're hitting on the true problem. This ceased to be true after System 7 shipped. Apple's development organization became convinced that to truly take the machine forward, they would require a totally new OS. So a small group of people continued to maintain System 7, while the "real" work went into Pink, which became Taligent. And when that failed, into Copland. And when that failed, into OS X. And OS X shipped way, way, way late.
Time and time again, Apple's large teams, working on the "next big thing", failed, while the small group of people (Blue Meanies et al) working on 7.x, 8.x, and 9.x were actually delivering the incremental improvements that people needed. Had Apple put together a small team to "hack on" memory protection into System 7, it would have been done long ago. But Apple's management preferred to build empires of superteams working on a new revolutionary OS, so they could say, "I lead a team of 200 programmers".
"the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one."
The car you drive is a series of incremental improvements on the Model-T. Even after all these years, the basic design laid down back then is the one we still use: conveyor-belt-style assembly of a car wi
(sig) The last bug isn't fixed until the last user is dead. (/sig)
That's true. But a good portion of that reasoning lay in the fact that to get to preemptive you needed to rewrite the kernel, event manager, memory manager, file manager, good portions of quickdraw and the graphics engine, device drivers, etc., to make them reentrant. So, by the time you've done that you've rewritten practically the entire OS, and then the real question becomes: do we want to do all of that work, only to fundamentally end up back where we started? And can we even do that without breaking half the applications out there that depend on some obscure bit of functionality or behavior?
"The car you drive is a series of incremental improvement..."
I don't think you want to go down that road, because if you do, we can start talking about the decades of incremental improvements that have gone ito Unix, BSD and Mach. (grin)
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
> "Apple's development organization became convinced that to truly take the machine
> forward, they would require a totally new OS."
>
> That's true. But a good portion of that reasoning lay in the fact that to get to
> preemptive you needed to rewrite the kernel, event manager, memory manager, file
> manager, good portions of quickdraw and the graphics engine, device drivers, etc.,
> to make them reentrant. So, by the time you've done that you've rewritten practically
> the entire OS, and then the real question becomes: do we want to do all of that work,
> only to fundamentally end up back where we started? And can we even do that without
> breaking half the applications out there that depend on some obscure bit of
> functionality or behavior?
Ah, now we're getting somewhere. I think that's roughly the reasoning they followed - since we have to rewrite it anyway, why not *really* rewrite it?
The answer is pretty simple: because there's a lot of good stuff in what had been written - for example, a graphics engine that had been written at a very low level to run efficiently on very slow hardware. (Consider that on the original Mac, menus were drawn on-demand, as the user interacted with them. Same on Windows. But on OS X it's so slow to draw the menus that they have to draw them in advance and cache the resultant bitmaps) And the flipside is there, too: there's no guarantee that the new design you come up with won't have its own fundamental flaws and shortcomings. It's a choice between the beast you know and the beast you create. In my experience it's easier to fix the beast you know. (At least, as long as the beast you know has as many good points as Mac OS had.)
The insight that no one ever had was that rather than fix it from the inside, you could treat the whole thing as a virtualization and fix it from the outside: Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations. That is to say, imagine multiple copies of Classic running alongside each other. Each is memory-protected from the other; each can crash horribly and not affect the rest of the OS. Each can be pre-emptively scheduled against the other. If you approach the problem from that direction, the need to re-write everything disappears. Of course, it would still be a lot of work; the file manager and device manager would have to be stubbed out and put in a central place for example. But it would be a lot less work than a complete rewrite. A lot of the work to stub out the file system was done already for A/UX, Apple's first attempt at a Unix-based Mac, and just needed to be carried over.
> "The car you drive is a series of incremental improvement..."
>
> I don't think you want to go down that road, because if you do, we can start talking
> about the decades of incremental improvements that have gone ito Unix, BSD and Mach.
> (grin)
To the contrary; I think that's an excellent point. If I were a user of BSD, I would look at OS X and be quite happy with what Apple's done with it - preserving the good parts of BSD while adding a lot of extra value. Heck - you can even boot a Mac in single-user mode with no GUI if you want to! If only the experience for old Mac people could have been as positive, or had a similar way to turn the new OS X-isms off!
(sig) The last bug isn't fixed until the last user is dead. (/sig)
The problem with Microkernels is that Mach has become the model for "what microkernels are".
Microkernels aren't about putting every component into its own memory and execution context.
Microkernels are about having a consistent API for both system and user components to communicate with. Typically you have a message queue, and standardised messages that can be (but not necessarily are) marshalled across address space boundaries.
There's no reason that a processor context switch has to happen, nor even that a message actually needs to be queued and dequeued in another thread, it just has to be possible for that to happen. When you make a call-with-wait (so you're suspended until the return packet gets back), the entire operation can happen in your own execution context.
OR, the operation could involve a round-trip across a network link.
The key is that the API doesn't distinguish between these two cases, it all depends on what's registered to handle that message.
So there's no reason a microkernel OS can't be as fast as a monolithic kernel. In fact microkernels an microkernel-like designs are not exactly rare in the control systems industry, where the performance and latency requirements are much tighter than they are in a desktop OS. The most microkernel-like personal computer OS, AmigaOS, was noted for its high performance and responsiveness.
Mach, no, that was a mistake. But microkernel design isn't the reason why.
Lack of hibernation in Mac OS, in my opinion, hurts. For those who don't know, "Hibernation" is the term Microsoft uses for a state in which all of the contents of memory are saved to the hard drive and the system completely shuts down. When the system is booted up, that cache is read from the hard drive (and is almost always much faster than a full-on boot). Considering all the things that could go wrong, it works excedingly well. It's sort of like a better sleep, hence the name.
As to why it's needed: battery life. I can hibernate my Dell, unplug it for a business trip and it's still got the same juice a day or two later when I turn it on. When I do the same with my Powerbook G4, the battery often dies while it's asleep.
I'm hoping it's one of the things they add for 10.5.
ACK! He says, mentally running through the point of contacts with the hardware, events, file system, networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it, and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to write an entire OS to put beneath it... which, from a certain perspective, is what they did.
As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84, I'm pretty happy with the current version. Finder stills needs work, and I remain less than thrilled that O/C is the language of choice, but overall, they've done a pretty good job, and extended the system in ways where Vista is still struggling to catch up.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
You know, that was an interesting comment & all, but the thing that made me happiest is that you know how to properly use "it's" and "its." I feel like I've never seen that on slashdot.
You might be surprised.
The original Atari ST's OS (TOS) was based on GEM and fairly similar to the original Mac OS: it could only run one application (plus up to 6 desk accessories) at once, no memory protection, simple and proprietary font support, rudimentary printer support, 8.3 filenames, simple B&W GUI, etc.
Since then, projects such as MultiTOS, MiNT, MagiC, and NVDI have replaced part or all of the OS, giving full pre-emptive multi-tasking, memory protection, true colour and much higher resolutions, full scaling font support (TrueType etc.), long filenames and large drives, networking, pretty good Unix compatibility, a greyscaled 3D look along with new file selectors and proportional scrollbars etc., object linking, and many other improvements giving a much more modern system. And yet, the new system is much faster than the original; and almost all the old applications still work unchanged, in most cases better than before. It's amazing what they managed to achieve.
Now, that may not translate directly to the Mac. The ST came out a year later than the Mac, and may have taken advantage of some of the Mac's experience, resulting in a slightly cleaner system. By the time Apple were considering OS rewriting, Mac OS 8 was probably a much bigger system than the Atari's, with many more dependencies, and many more ancient apps with dirty coding that couldn't work with the new features.
But it does tend to agree with the parent message's suggestion that incremental improvements should have been possible. Maybe going for a new OS was a choice rather than a necessity (though that may not have been apparent at the time).
OTOH, despite all the setbacks and failures, the Mac now has a pretty good modern OS, so with hindsight maybe it was the right decision after all!
Ceterum censeo subscriptionem esse delendam.
Yes, there was, there were DX80 and DX50 and DX40, chips as well, not just the 33 and 66 we all remember. (They were cyrix and maybe AMD)
And then there's the fact that I just today figured out how to prevent chronic fatal drive thrashing cycles on my sidekick iMac G3 (running Tiger): format the drive HFS non-journaled.
I hate Grammar Nazi's
> "Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations."
>
> ACK! He says, mentally running through the point of contacts with the hardware, events, file system,
> networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it,
> and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to
> write an entire OS to put beneath it... which, from a certain perspective, is what they did.
Yes, my point exactly: they had to do this in order to handle the "Classic" mode anyway. But instead of putting in a shim that the ClassicOS talks to, they should have put in a shim that the ClassicOS *apps* talk to.
And given that a lot of the performance issues under Carbon in OS X don't happen under Classic, they probably could have avoided them in a "MultiClassic" environment too.
Ah well. Looks like the spirit of killing pre-OS X technologies lived long enough to kill Classic on the Intel Macs, so I think it'll only get harder to actually ever make something like this happen.
> As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84
Wow, you did Lisa development? Man, I'd love to see a Virtual Lisa, to show people who believe that the Mac started it all. (I always hated that Apple was so tight on its restrictions as to who was allowed to develop for Lisa.)
(sig) The last bug isn't fixed until the last user is dead. (/sig)
NT3.51 was in theory much more stable than Win95 (except that it didn't include working power management drivers, because it pretended to be a "Server operating system, not a Desktop operating system", so it would blue-screen when your laptop ran low on battery and sent power-management interrupts, which was unfortunately strongly correlated with whether I caught the express train or the slower local train to work :-)
Win2000 was fairly stable, though unfortunately some time around NT4 or Win2K they moved the graphics system into the kernel for performance reasons, so it could still die in ugly mysterious ways, but it was at least much nicer than older Win95-derived versions. WinXP actually works really well for me - it's fast and relatively stable, though it still dies every couple of weeks on my laptop: almost never with an actual bluescreen unless my hardware's acting cranky, but usually with something stalling the window system or the mouse when it's waking up from hibernation.
WinME convinced me that I should have no guilty feelings about pirating Microsoft operating systems - I'd bought Win98SE because it promised that Internet Connection Sharing would let me actually share my Internet Connection (lies!), and I bought WinME because it promised that the new version of Internet Connection Sharing would let me actually share my Internet connection (this time for sure!) (lies again), and that it would be more stable (lies! though 98SE has been more stable than 98.) I had half a dozen lab machines with 98SE, and had no qualms about reusing it when the hardware died, especially since I was running Linux on most of those machines anyway. On the other hand, XP's copy protection looks sufficiently workable that I decided to buy a separate copy of XP for my mother-in-law's machine, which had a WinME version sufficiently infested with spyware, IE Toolbar "helpers", popups, etc. that it was much cleaner to wipe it out to bare metal rather than attempt to reinstall ME cleanly.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Of course, the faster-than-Moore's-law changes in RAM and disk sizes and prices during that time period don't hurt either - my machines really did go a *lot* faster with 512MB of RAM and an uncrowded 120GB disk drive than 128MB and 2GB, and even though BitTorrent music downloading has made the disk drive no longer empty, it's still enough larger that it's usually much less fragmented and installations are a lot cleaner.
The next big performance jump is likely to be use of Flash memory as disk cache - you can get 2GB for under $100 these days, and even crude steps like installing all of the OS and libraries onto flash is likely to be a big win, because you eliminate disk-rotation and disk-seek latency from your typical system performance - doing more intelligent things with caching programs or translucent file systems or possibly even putting journaling onto flash may be make a bigger difference, though especially journalling needs to be done carefully to avoid overuse of flash's write cycle limits (though I gather that's much less of a problem with newer flash technology than older stuff.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Of course, nobody'd going to do a better job than some of the capability-based operating systems like EROS or its predecessor KeyKos - friends of mine had fun at trade shows in the 80s unplugging their hardware while it was running, plugging it back in again and having the same applications running from where they left off, much to the annoyance of the "fault-tolerant computer" vendors at the next booth who weren't willing to risk doing the same.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
After looking 3-4 levels deep into the web page, I still can't say what Quicksilver does or why I'd want it. It seems to be for the Mac, and it seems to be some kind of code launcher, but I can't tell what it really does or why it does something better than the native Mac tools.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks