Slashdot Mirror
A 2nd Core to Keep Windows Chugging Along?
Eh-Wire writes "Almost every hardware junkie I know would give most anything to take a spin in the new dual core hot rods from Dell or one of the custom system builders. But what if you actually needed that second core to run your anti-virus, spyware detection software and firewall just to get a little gaming or Internet surfing done on the first core. Would that really be a good reason to bring home a shiny new machine? I can think of a couple of different things I could use a second core for but running an iron lung on it just to keep the machine chugging along just isn't one of them. Curiously enough, PCMag thinks that's a perfectly good reason."
Funny you should say that on today of all days. I spent a big chunk of the afternoon finalizing some of the documentation for launchd.
The traditional UNIX startup model calls for a lot of tasks to be fired off at boot time, one after the other. Whether you use init scripts or rc scripts or whatever, the model is the same.
In Panther, we created a fairly sophisticated system for firing off these tasks in parallel instead of serially. The net result was a decrease in cold-start times of about 100%.
Now we've got launchd. The idea now is that instead of making the user wait for a bunch of services to start, we let launchd fire them both in parallel and asynchronously.
I don't want to get extremely specific here for reasons I hope are obvious, but on modern (i.e., dual-G5) hardware, the time from the end of power-on tests and the initialization of Open Firmware to the menu bar and dock appearing and the system accepting user input is as little as four seconds.
Four seconds to cold-boot the operating system.
Pretty impressive, no? All it takes is a willingness to look at the traditional way of doing things, recognize massive stupidity, and correct it.
Rather than bitching, why not spend a little time figuring it out? It's pretty obvious, if you think about it. Here we go. First, choose the Tools menu, because Tools always contains configuration menu options. Next, choose Customize under tools, because Customize in is where you customize menus and toolbars in Office applications (and many other Microsoft apps as well). Click over to the Options tab, because you're looking for options (the other two, Toolbars and Commands, are obviously not what you want). Looky there! I see a checkbox for "Always show full menus"! I wonder what that could do?
Yes, it's "buried", but it's buried in a logical place if you're familiar with Office products. (disclaimer: The above steps are for Word 2003. They may be different on older versions, but probably not.)
The 244 watts figure is the power consumption of the entire system, not the chip itself.
See CSS Zen Garden for proof of that...
(and for the web illiterates out there: there are no tables in CSSZG, and the only thing that changes between two designs is the stylesheet associated with the page, the HTML file doesn't change anywhere but where it links the aforementioned stylesheets)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
As for spreadsheets, I see them more as a rapid prototyping tool (if even that). When I want to get anything done that involves large lists of data, I write a Perl script to do the job. Mind you, Perl is a lot more powerful than spreadsheet programs, and it, too, takes a lot less system resources than any given contemporary spreadsheet program.
Of course, every (wo)man has his/her own preferences, and I don't write this to encourage everyone to use emacs/LaTeX/perl, but rather to spread the fact that you don't need even a 350 MHz PII or even 64 MBs of RAM to be productive, and that it is most certainly program design that makes Open/Microsoft Office take much more resources than really necessary. While you may not need a 2 GHz machine like the GP said, you do certainly need a lot more because of the fancy GUIs and stuff.