Civil time is "baroque" but usable - every instant has a name, however complex the naming convention. Posix time is "broke" - it can't name every instant. Sane unix systems use a simple second count, which is both simple and usable, and can be converted to posix time when needed (hopefully never).

Civil time represents positive leap seconds as second 60:

23:59:59
23:59:60
00:00:00
00:00:01

DST is disambiguated by the Timezone name:
November 2, 2008 1:00:01 AM EST is an hour later than November 2, 2008 1:00:01 AM EDT.

You are right about the posix definition. But the posix definition is stupid and useless, because it can't unambiguously represent a timestamp - so it is ignored or reinterpreted by sane unix implementations. You can convert a sane clock (like the traditional second count) to posix time (or even most insane localtime based clocks), but not vice versa. So if anyone actually has to run a posix compatible application that is actually braindead enough to rely on time()%60 == seconds_in_minute, then they can set an environment to convert the output of time().

The linux man page for time() mentions the posix definition, and then says they made a mistake - and they really meant seconds since the epoch.

It doesn't matter how NTP protocol represents time - as long as it can be unambiguously converted to system time (i.e. just about anything except posix time could be used). The leap second flag *is* a little weird, but is just a wrinkle when converting to system time.

I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).

Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?

A posix timestamp isn't even an unambiguous time reference. I can deal with discontinuities (just convert to linear time), but the end result of POSIX is utterly and totally useless (can't be unambiguously converted to linear time). For crying out loud, keeping system time as a well defined MDYHMS would be more usable than posix time - at least you can convert to something more manageable.

IMO, everyone should just ignore POSIX time. A Unix timestamp is a plain second count - regardless of the humped monstrosity decreed by POSIX. This can be easily converted to posix time , UTC, GMT, localtime, or any other desired scheme. Posix time can't. It is a non-starter.

Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation.

The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:

$ TZ="right/US/Eastern" date; TZ="US/Eastern" date
Sun Feb 8 17:52:42 EST 2009
Sun Feb 8 17:53:06 EST 2009

The take home salary is *not* the significant cost of hiring an American worker. You have FICA, Medicare, Unemployment insurance, Workers comp, plus lots more nickle and dime costs. Let me illustrate the end result with an example from a country even worse (in this respect - of course it is a nice place in other ways): Brazil.

Brazil got a socialist government that tried to end worker exploitation by decreeing a litany of benefits for all workers. Mandatory unemployment insurance, health care, maximum weekly hours, minimum wage, you name it. If you land a legal job in Brazil, you are really well taken care of - and you even get some spending money. The problem? Very few companies can afford to hire workers following all the rules. So instead, they offer jobs "under the table". You work for us, while officially unemployed, and we'll slip you money under the table. No benefits. No guarantees. This is what most workers in Brazil end up with. The end result is the opposite of the good intentions.

A friend was a lawyer in Brazil working for a non-profit that sued companies that failed to follow all the employment rules. The catch? His law firm hired *their* workers "under the table" with no benefits - they could not afford official workers as a non-profit.

A colleague of mine provided a "translation" of HP BASIC for april fools one year (35 years ago - HP2000). PRINT became SCRIBBLE, IF became SHOULD, GOTO became LEAP, LET became MAKE

10 I = 0
20 SHOULD I = 10 LEAP 50
30 SCRIBBLE I
35 MAKE I = I + 1
40 LEAP 20

Interestingly, no one had any trouble with their assignments (programs were stored tokenized, so you saw the new keywords in the "editor").

Having spent several weeks living in a commune of about 200 people in Vermont, I can say it works very well on that small scale. It wasn't exactly marxist in that people had specialties (soap maker, clothing, gardening, etc). I didn't stay because there were no plans for a programming specialty (and there weren't any available girls I liked).

Everyone knew the leader. Even guests like me got a personal interview. There is some danger of a Jim Jones scenario, but this group was part of an international accountability structure to watch for that kind of thing.

The "secure computing" preached by MS does not protect against OS bugs, buffer overflows, or any of the myriad local or remote attacks based on software flaws. The only "security" it offers is a way to prevent end users from downloading and installing the software of their choice. I don't mean to minimize the value of this - it is an important base to cover. The "typical" Windows user sees a free screen saver and goes "Ooh! Shiny!" and installs it - thereby joining yet another botnet. When/if Linux reaches Windows marketshare, "typical" Linux users will do the same.

Of course, this turns a Windows/TPM computer into something akin to a game console. I personally don't think there is anything wrong with this - until M$ convinces the government to outlaw real computers because they are "insecure". Or more likely, convinces banks and online merchants to only do business with TPM computers.

well, in a way. The problem is that the drive makers optimized their power saving algorithms for Windows disk access patterns - as you would expect them to since it is 85% of the market. And they didn't provide knobs to twist for other OSes - including new, more efficient versions of Windows.

The irony is that Linux runs afoul of the hard drive power saving tuning because it is too efficient. The gaps between disk accesses are too long, and trigger a head unload while the OS is still active.

The best fix would be to twist a knob to adjust the inactivity timer - but that isn't available. So the simplest fix is to disable power saving on the disk - fine for laptops used as portable desktops. To keep drive power saving without unloading/loading the heads constantly, you have to configure "laptop mode", which uses memory to cache reads/collect writes so as to provide something like 30 minutes between disk accesses for typical word processing/browsing activities.

I've thought about writing a background process (in python or your favorite script language) that monitors iostat - and reads a raw sector every 9 seconds to keep the disk from thinking we are inactive. At the same time, we have our own Linux oriented inactivity timer, and stop reading the raw sectors when the system is truly inactive (other than our own reads).

There are so many good books to recommend, but perhaps the best to address this issue directly is "A Brief History of Time".

This is also the basis for thermodynamic computing - where all operations are reversible, to minimize energy use (i.e. increase in entropy). Among other things, you never simply clear a bit, dumping the charge, you move the charge to another bit - effectively swapping them. Thus, the instruction set has an XCHG opcode but no MOV opcode.

When programming such a device, you begin with memory set to known 0 and 1 bits. As computation proceeds, you accumulate bits whose state you've lost track of - and hence are effectively random. The progression of memory from "ordered" to "unordered" mirrors the progression of entropy in the universe.

Entropy was observed, defined and modeled long before quantum mechanics, and has nothing to do with randomness. Deterministic processes accumulate entropy just fine without randomness.

An abstract line is one dimensional. If one existed, you could not see it. All real representations of lines are 3-D. The property "opaque" requires 3 dimensional form - of a size significant with respect to the wavelength of whatever you are trying to bounce off it to "see" it with.

The laws of physics are all reversible, and there is no preferred direction in 4-space. The reason we perceive one is that storing information in memory increases entropy. Consequently, (only logically subsequent, mind you), we can only remember states with lower entropy. For any beings/devices with memory, the "future" will of necessity be one of higher entropy, and the "past" one of lower entropy.

I ride a bike 7 miles each way (upwind both ways). But I have an article pinned to my wall with a picture of a guy that rides his bike to the river, puts it on a row boat. Rows across the river, then bikes the rest of the way to the office.