Slashdot Mirror
100 Years of Macintosh
Zero seconds on the Mac OS system clock is January 1, 1904. The Mac OS epoch hits 100 years ... now. That's assuming you live in the Pacific time zone, anyway: the Mac OS epoch is unique in that it is time zone-specific. Of course, none of this applies unless you are running Mac OS, and all you Mac users are using Mac OS X, right? (Geek note: the Mac OS epoch is unsigned, which is why it can count over 100 years from 0 seconds, and 32-bit Unix can't, though it can count backward to 1901.)
I've been using my older Mac all evening (I know, boring life). Right now it claims it's "2:01:22 AM 1/1/2004". Seems to be OK to me.
Who the hell passe's this article? MAC's start counting from August 1956. wot's with the 1904 stuff?
Just try it. take out they're battery and theyl reset to 1956.
it refers to the fact that when something caused the old MacOS to lose the current date and time, it would default to 1/1/1904. it's the date in the old PROM that is used as a base starting value. much like epoch in UNIX(TM)
Mac OS epoch is unique in that it is time zone-specific.
It is unique, in the sense that it is crappy.
On Unix, the epoch is an extremely well-defined moment in time, so then is any point in time measured in epoch-seconds is also extremely well-defined.
On the Mac, the epoch-seconds depends on the time zone, meaning that in order for a measurement of time in macos-epoch-seconds to be meaningful, you also need to know the time zone. To me, that kind of ruins the whole point...
No, 2^31 passed. 2^32 would be in 2040.
I once looked at the Apple website's downloads section, and it was full of files that said "Fix for buffer overflow" this and "Unauthorized code" that. I got the impression that a lot of Mac users would see that and not realize how serious it was.
I looked at the site again just now and they seem to be a little more discrete about it. Where they used to label fixes as "Fix buffer overflow in <some component>", they now just say "Security Update".
People take it for granted that cars work reliably, just as they take it for granted that computers don't. Back when I started using PCs around the time of Windows 3.1, I took it for granted that errors occurred (actually, I remember, though perhaps inaccuratley, 3.1 being surprisingly stable; 95 was where the real issues started) and that I'd have to hit the power switch every so often. That was my accepted norm.
So too, opinion seems to be that security holes are entirely the fault of the attacker, never of the software designers. Do people hold MS responsible when they get infected with a virus? Sure, they grumble, but I see no class-action lawsuits, no new legislation, no nothing. Perhaps I am confusing reliability--resilience against failure in the course of normal use--with security--resilience against intentional attacks--but when Ford Pintos started blowing up because some jackass wired the turn signals through the gas tank, Ford paid (quite dearly, as well, thanks to punitive damages).
I don't remember the specifics of the defects I've seen Apple accused of having ignored, but I imagine plenty are simple fixes (a fix of a buffer overflow on the screen-saver lock took a long time, if I remember right; this should be a simple matter of adding a boundary check on the input). The point is, if software companies were liable for any serious defects, they might try harder. And if they were liable for ignoring those defects, I betcha they'd be able to find someone to get to work on it. Getting that next release out on time, adding that flashy new feature, and staying under budget are natural priorities for software makers. We, the public simply need to weigh in with some careful legislation to balance those priorities with stability, reliability, and maturity. It should not be more profitable to spend money on advertising security than on actually building it.
and all you Mac users are using Mac OS X, right?
No, actually. You forgot that OS X is optimised for G4 architecture and newer. Even a fast G3 box is often brought to its knees by Jaguar due to its lack of specific hardware features. OS 9 is not dead: that is apple marketing hype. sure, its becoming more of a niche platform, and eventually the market will drive it to being a "retro platform" or whatever but thats another couple years at least. but its preferred if you don't have a particular need for a UNIX environment and/or you really need to eek out every last bit of performance from your hardware... and even if you did need a unix environment, what not just use linux? oh yeah, no itunes, my bad...
don't get me wrong. OS X is a tight platform, and i can't wait till the day i buy a brand new g5 or whatever and run OSX full-time. but come on: i'm one mac user thats not gonna bow down to the cult... my G3/800 MHz w/ 512 MB ram screams in OS 9.2.2 but feels like a 286 when i'm in jaguar (10.2.6), and sorry but i just don't have the time or mental energy to have to be waiting on my computer when i'm trying to get stuff done quickly.
alright, i'm done ranting. =) oh, and btw, i've had more than one Mac come up w/ 1856 (not 19--) when the battery dies...
It doesn't download updates without user intervention by default; it just checks for them and pops up a window listing what it finds.
This space unintentionally left unblank.
quicker execution is almost always the most important factor, the only exception is ease of development,
Think XML: it is not even close to being efficient, but its purpose is not for speed but for portability and flexibility (roughly).
but freform text parsing is much more messy than that to.
Nobody said anything about freeform text parsing. If you define a fixed text pattern to represent date/time, then parsing is extremely easy. ie. All you need to do is look for space separators and separate into tokens. Token1=month, token2=day, token3=year, token4=hour, token5=minute, token6=second, token7=millisecond, token8=GMT offset
Sample: 1 1 2003 7 26 0 0 -8
are you suggesting... standardizing on a certain text format?
Exactly.
So, assuming you put that in little endian format (to be able to sort), prefix zeros (to be able to sort), and specify the offset in army time (not all timezones work that nice):
2003 01 01 07 26 00 00 -800
This only sorts easily (alphabetically) if comparing times from the same timezone. Otherwise, some different sorting algorithm is required.
Additionally, this requires 27 bytes (versus 4), and...
The times are not unique!
Consider daylight savings time.
-- I was raised on the command line, bitch