Granted, on last reading, the USNO master clock was only five nanoseconds fast of UTC, as computed by the BIPM (by averaging many different atomic clock's reading of UTC).
GMT is what it says it is: the mean solar time on Greenwich meridian (after correction of the Earth's nutation and pole displacement). It is also called UT1, or Universal Time. This time standard is obsolete and deprecated, because it is an astronomical standard, and is subject to many irregularities.
The current time standard is UTC, or Universal Time Coordinated, which is defined as offset by a certain number of seconds with respect to TAI (the international atomic time, maintained by averaging a number of atomic clocks around the world), currently UTC=TAI-32s. This offset is changed occasionally by inserting a leap second in UTC, so that the difference UTC-UT1 never exceeds 0.9s in absolute value (currently it is around -0.3s).
For nearly all real-life practices, UT1 and UTC can be assimilated under the general name ``Greenwich Mean Time'' or (more correctly) ``Universal Time'', but the correct term is ``Universal Time Coordinated''.
The times are given un universal coordinated time and apply to 2000/01/21. Add or substract your time zone correction.
The time, of course, does not depend on the place. The eclipse is visible from wherever on Earth it happens to be night at the time in question. (Naturally, since there is an eclipse, the moon is full, so it is night precisely when the moon is visible, atmospheric perturbations excluded.)
Anyone notice? Potato is not only release 2.2 of Debian GNU/Linux, it's also the long-expected version 0.3 of GNU/Hurd (the first of Debian GNU/Hurd). Check the binary-hurd-i38 6 directory. Admittedly, many (if not most) Hurd deb packages are actually binary-all packages (and some are plain useless under the Hurd) — one Hurd developper jokingly said the Hurd would take its revenge by committing a lot of Hurd-specific binary-all packages.
True, the Hurd is still far from stable now (and moving this tree from frozen to stable will sound something like a joke), but this is an important landmark nonetheless.
lynx has this big advantage, also, that it can make something sensible out of Unicode. Netscape is just fscking worthless in this respect: it doesn't even understand — (the em-dash character). Unfortunately, I use — regularly in my web documents (no bugware!), so they're about unreadable with Netscape. Same for “ (the English-style open quotes) and so on (though I tend to compromise and use `` instead of “ or possibly the French double quotes ).
lynx run in an xterm with wide chars enabled and a fixed-width Unicode font is so far the best solution I've found to viewing Unicode characters correctly.
(Note: Unicode is not just useful in foreign languages. Some punctuation signs like the ellipsis, or, as I mentioned above, the em-dash and the quotes, are to be found in Unicode. As a matter of fact, Unicode is more useful for English than for French, because nearly all the French characters are in ISO-8859-1, and the French-style quotes are there, whereas the English-style quotes are far away in Unicode tables.)
lynx has its irritating features, though. It can't render tables, and that's a pain. w3m at least does that correctly. Also, lynx displays <i> as underline: that's stupid, <i> is italics, not emphasis (emphasis is <em>), and if it can't do italics, it should do nothing and ignore the tag. And it doesn't understand <dfn> (now that should probably be underlined).
And lynx completely ignores CSS. Agreed, in text mode, there isn't much you can get from CSS, but at least the margin definitions wouldn't be too hard to implement, and that would be useful.
Evidently The Matrix is strongly influenced by the philosophy of Socrates (at least as far as Plato tells us about it). The bit about the Oracle just makes it a tad too obvious: the wise saying ``know yourself'' (``GNOTHI SEAUTON'' in Greek — now I wonder why the makers of the movie decided to translate it in Latin: ``NOSCA TEMET'') was carved in front of the real Oracle, in Delphi, and Socrates adopted it as his motto. (Socrates, it seems, went to see the Oracle in Delphi and thus discovered about his own wisdom: ``the only thing I know is that I know nothing'' (``en oida ho ti ouden oida'').)
The whole film reeks of the parable of the cavern, told by Socrates in Plato's Republic. Recall that it goes something like this: some men are prisoners in a cavern, and are bound so that all they can see is a wall in front of them, and the shadows on that wall made by objects moving behind them. The prisoners think that the shadows are the real objects and give names to them. But one day a prisonner is unchained and goes out of the cavern. At first he is blinded by the sun, but after some time he gets accustomed to Reality. He goes back to the cavern and tries to convince his fellow prisoners that what they see are only shadows of the real objects. And so on. (If you want the full story, read The Republic.)
Now Plato has a very elitist vision of mankind. He was strongly opposed to democracy (two of his uncles were part of the Thirty Tyrants, the antidemocratic regime imposed upon Athens when it lost the Peloponnesian war against Sparta). The whole idea of The Republic, if I dare summarize it in just a few words, is that philosophers (those who can see further than the shadows of the parable's cavern) should be in charge of ruling the (city-)state. I think (I hope) that The Matrix has a more democratic vision of things, that the idea is to free mankind — all of mankind, not just a select happy few.
Another intersting point which is made, albeit briefly, in The Matrix, is when whatshisname discusses about the taste of things, how they might taste in reality, and how they taste in the Matrix: of course, the cavern's shadow-world is a projection of reality, but it is only a projection, and there is nothing to say that the reality is not vastly different from the projection (or vice versa).
I don't think this comparison is all that important, but it certainly fun to think how a science-fiction film of the end of the XXth century could have been greatly influenced by the writings of a philosopher nearly 25 centuries earlier.
(PS: Here in France we have philosophy courses in high school. I think that is a good idea.)
> Unless HURD does things that other OS's cannot do.
Well, of course, anything that any OS can do, a Turing machine can do. So it's more a question of relative ease.
If we imagine the Hurd as more or less finish, it can do all the things that Linux does, perhaps slower (though it is hard to predict by how much), especially on single-processor systems. But here is a concrete use that the Hurd might have which would not work on Linux: it would make it possible to sell computing power on a machine (for example to put a web server on it), including root access (something which is often desirable), to several different clients without any interaction between them, and without compromising the system security. Because Hurd can be virtualized. This is an example something which could provide motivation to get the Hurd working.
I'd say the debugging is easier, except that what you're trying to debug is much more complex, so that as a whole the whole debugging process is more difficult. Essentially, because the Hurd servers are heavily multithreaded programs that pass messages to each others in all sorts of ways. That is always hard to debug, even in user space.
I don't think this is really the reason why the Hurd has progressed so slowly, though, no matter what Stallman may say. Or at least, there are other factors in play.
Good point. Moreover, as I pointed out, the monolithic kernel vs microkernel debate is exactly a library vs client/server system, at a sufficiently abstract level.
Clearly there is nothing you can do with a library that you can't do with a client/server system. But in fact, the converse is also mostly true. It would be quite possible, IMHO, to have the Hurd features on a monolithic kernel system: essentially, the monolithic kernel provides the capacity-based security model, and the filesystems are integrated in a set of dynamic libraries rather than in a set of servers. This requires the concept of setuid (or rather, ``acquire capability'') libraries, but there is nothing fundamentally impossible with this.
So, the microkernel issue should not be judged as providing the Hurd functionality but rather, on its own grounds (replacing a library-alike calling system by a client/server model). I am not competent to judge in this matter, but one thing is certain, namely that the entire issue is not completely clear-cut. The official ``Tunes'' rant on the microkernel issue might not be completely wrong (despite the author's numerous deliberately provotating statements).
This is due to the way the communication works. On a monolithic kernel, when a process needs, say, to perform a filesystem read, it will invoke a processor trap to go in kernel mode (protection level 0), then perform the task as a privileged task (from the processor's point of view). The overhead is just a trap call, which is comparatively low: even the branch prediction mechanisms are not invalidated by this. On a microkernel, on the other hand, the process needs to send a message to the server task. Essentially, things proceed thus: the client task writes the message to a memory page, then goes in kernel mode to ``send'' the message to the server task (all that is just as fast as for a monolithic kernel); then it starts waiting for the reply. But that means it is unscheduled and another task (presumably the server task) is scheduled in its stead. The reschedule may be slow, since it involves replacing all the registers, but that is not the worst part. The worst part is that the paging register is changed (the virtual memory layout is unique to each task, so a task change must change the paging register, CR3 on an Intel), and that means that the TLB (``Translation Lookaside Buffer'', the cache for the paging mechanism) gets flushed. This is why processes are so much more costly than threads (which share the same address space), and this is why RPC calls are so costly. There are two context switches (TLB flushes) for each single message sent from the client to the server (plus, possibly, its reply).
At a sufficiently abstract level, a monolithic kernel is nothing else but an I/O access library which is shared by every process and which enjoys certain specific rights. In a way, every process ``carries its own copy of the kernel'' with it. On the other hand, for a microkernel, the ``library'' approach is replaced by a ``client/server'' approach.
There are possible ways around the problem. A microkernel architecture like QNX uses a single address space. Since user tasks operate at the same privilege level, they are not protected the ones from the others. It may be possible to put the device drivers at ring 1 (between the kernel at ring 0 and the user processes at ring 3), I think NT does this; but this contradicts the basic principles of symmetry which the Hurd tries to enforce. Segmentation might also help things, but it is hard to work with. Or, simply, more modern processor architectures might not enforce a TLB flush with each change of address space, but simply mark TLB entries with the address space with which they are associated (or some such thing), or some such thing. I think the Alpha does something of the kind.
On a SMP machine, the cost of an RPC call is not nearly so high: imagine the client task is running on processor A while processor B is idle; when the request is sent, processor B immediately starts executing the server task, and when the client task starts waiting, it is not replaced by another task because no other task is waiting, processor A just waits until processor B finishes execution, so no context switch occurs on either processor if the scheduler is good enough. Essentially, we have not used two processors, but merely the fact that two processors have two TLB's.
It may also be possible to group requests as much as possible before unscheduling the client. But that is rather hard to do. This is what the Xlib does for the X protocol, but I do not see how the libc (which is the analog of the Xlib for the Hurd protocol) could do the same, considering the semantics it has to obey (notably that each call must return an error code).
Since a few people seem to be interested, I will recapitulate the overall HURD status, from my personal experience and my reading of the debian-hurd and bug-hurd mailing lists.
First, is it usable? Well, it depends for what. It is still quite unstable. Filesystems are under active development, but there are still some problems with them (the ``native'' Hurd filesystem, if that means anything, is ext2 just like Linux, but the ext2 demon still has problems, one of them being that sometimes entire file blocks are replaced by zeroes — this will be fixed soon). The TCP/IP stack is a copy of that of Linux (but the Hurd maintainers are having trouble keeping up with the changes made to the Linux networking code). The security mechanisms are extremely flexible but that sometimes causes problems (for example, the Hurd has one more set of file permissions besides user, group and other permissions, the ``not-logged-in'' permissions, and no tools yet exist that will allow to manipulate these permissions). There are also some strange limitations: for example, Hurd will not work on a partition of more than 1Gb, and it crashes rapidly if not given a swap partition.
X Windows will work with a set of patches. Some other programs cause problems, and sometimes it's the program's fault (because it makes assumptions about the Unix-like nature of the system which are not verified under the Hurd).
On the other hand, the Hurd is stable enough to bootstrap itself (compiler, microkernel, libraries, demons) and perform tasks that do not have stringent hardware requirements.
The Hurd shares the same libc as Linux (the GNU libc, currently version 2.1.2). So eventually it should be binary compatible with Linux (right now it is not, but there is no severe problem with that, it is only a matter of time). This is one of the great hopes of Hurd, the possibility of making the transition completely smooth.
The slowness of the progress on the Hurd is due to nobody working on it full time. Some very competent programmers are devoting a lot of time to it (Thomas Bushnell, Brent Fulgham, Roland McGrath, Marcus Brinkmann and certainly a few I'm forgetting), but they are overwhelmed by the immensity of the task.
In theory, though, the Hurd should be easier to develop than Linux, because it is more inherently modular, and because of the fantastic possibilities of gdb under the Hurd. Also, you do not need to reboot to test changes to the ``kernel'', and you can debug a live kernel without problem; plus, you can test some experimental features without endangering the base system. So, there is no reason that Hurd can't become very solid and stable — quite the contrary in fact. But they just need more volunteers. And the FSF unfortunately cannot affort to hire someone on it full time (say, why not write a check to the FSF specifying that you would like to see it employed for Hurd development?).
On the other hand, in the domain of performance, it is probable that a microkernel architecture can never be at par with a monolithic kernel, at least on single-processor machines. For the moment, the Hurd is horribly slow with filesystems (rm -rf is just a nightmare), but this is mostly because it is completely unoptimized. Still, even when it is, it will probably remain noticeably slower than Linux. It has been claimed, however, that the difference may be significantly less than expected; but it is yet too early to see.
The main advantage of the Hurd is its flexibility. User-land filesystems are part of that. In fact, you do not even need to be root to write a filesystem. (That is one of the things which angers me the most about Linux, the need to be root to mount a simple loopback file.) The Hurd is completely virtualizable, whereas Unix hardly is (well, there is a ``user-mode Linux'', but it is even more experimental than the Hurd), so any user can set up her own virtual sub-hurd with its own set of users, permissions and so on. The security system is soooo flexible: much better than access control lists, it uses capabilities (àla Eros) in the form of Mach ports. If this were made practical, this would be a huge gain on the security side, because you would practically never need to be root for anything, just introduce the ad hoc capabilities and permissions. And the virtualization possibilities let you surround dangerous demons by ``sanitary cords'', making the system much harder to break into. So, theoretically, the Hurd can be a very secure system. Finally, the whole translator system can be used in yet unthought-of ways to provide wondrous communication mechanisms between programs.
However, the real question now is whether binary compatibility with Linux plus the great extra features and flexibility can be sufficient motivation for people to move to the Hurd when it is more stable, and, in the mean time, for more developpers to draw their attention to it. The lack of hardware support, on the other hand, is not a big problem: Roland McGrath has an experimental project for making the Mach microkernel run with the Flux OSKit, so that all the Linux hardware support would immediately benefit the Hurd.
First, as I explain in another post in this disucssion, e-.com or microsoft-.com are not illegal domain names. Just read RFC1035: the title of section 2.3.1 is ``Preferred name syntax'': this is a SHOULD, not a MUST.
If someone decides to register this domain, it's their problem. If it breaks programs like TELNET, it's also their problem (``their'' refers to the people who registered, not to the programs): they took the risk to register that domain, knowing that they might have problems, and if their customers get angry because they can't access the domain, it't their problem.
The programs SHOULD, according to the RFC, do the best to be ``liberal in what they accept'', and accept all the names they can to pass them to the resolver library. The resolver library SHOULD accept any kind of characters, binary characters included, and pass them verbatim to the name servers (they shouldn't even change the letter case, only the nameservers are permitted to make the final decision on this subject).
Within their own domain, people are permitted to do whatever they want, including using binary characters in (sub)domain names, not being case-insensitive, or any other stupid thing on the same line. It will break everything, but, again, it's their problem.
I agree with the ICANN's decision to register this. Nowhere in the RFC's does it say they may not (at least, as far as I know). All this, as far as they're (to be) concerned, is ``somebody else's problem''. Just like it is if the IP address you give them as primary nameserver is invalid or does not work.
The other point is RFC1591, which (meta-)specifies the way the three-letter TLD's are organized. Note in particular that nowhere in it is it stated that the.org domain is for non-profit organizations, contrary to what is frequently claimed. But the ICANN is to be blamed for not respecting this RFC on several counts (notably for the.net domain; also, something like un.org should be un.int).
I whish this ``www.[any word].com'' nonsense would stop. My suggested solution would be to invent another, better adapted, distributed data base, to transform a word or phrase to a URL, call it, say, ``true names''; then add a truename:// URL scheme, which gets relocated using the ``true names'' database to the correct URL. Integrate that scheme in every popular browser, and make it the default URL scheme. Then DNS names can become again what they are supposed to be: computer names, not resource names. Admittedly, I am only suggesting displacing the problem, but maybe the other database I mention can be better attuned to the kind of problems we have with the DNS, and which the DNS was not designed to handle.
The reference is RFC1035 (``Domain Names — Implementation and Specification'') by Mockapetris. But read it carefully: the section 2.3.1 is entitled ``Preferred name syntax'' (emphasis is mine). There is nothing illegal about names not following this convention; in fact, RFC1035 domain names can contain arbitrary characters, even binary (including the dot character, the null character, and mixed case!). The RFC essentially restates the golden rule: be liberal in what you accept and conservative in what you send (i.e. use the suggested conventions if possible when creating domain names, but be prepared to accept any kind of data when you receive a domain name). The RFC suggests the conventions you name precisely for compatibility with mail and TELNET (see the notes at the beginning of section 2.3.1), so you are putting the cart before the horses (``illegal'' names are ``illegal'' because they break TELNET, not the other way around).
A domain name is not supposed to start with a digit, but this rule is violated in the very RFC for the IN-ADDR.ARPA domain. Arguably, this is not a problem because you can't TELNET directly to an IN-ADDR.ARPA domain host (I find it rather unfortunate that I can't type telnet t.z.y.x.in-addr-arpa as a substitute for telnet x.y.z.t, I've never understood why that is disallowed).
I wonder, with all the fad on Unicode, whether Unicode characters will end up being allowed in domain names. Then every trademark-owning company would rush to register their name in every possible script. Or, worse even, get their logo added to the Unicode tables and register the <logo>.com domain. Fortunately, the Unicode Consortium has decided never to include logos in the official Unicode tables (but they might get added in the user-reserved areas if some vendor (i.e. Micro$oft) is influential enough to provide a kind of standard in this domain). Imagine people not knowing how to write any more, just choosing the company's logo in a huge table, and pasting it in the location bar of their browser...
Excuuuuse me? What in the world does it mean for a lunar eclipse to be ``in (for) North America''?
This would make sense for a solar eclipse, since solar eclipses are very localized, but a solar eclipse happens at the new moon, whereas a lunar eclipse happens at the full moon (for obvious reasons).
A lunar eclipse is visible throughout the hemisphere where it is night (which, of course, is the same as the hemisphere where the moon is visible, since the moon and the sun are in opposition), so at best the ``north'' in ``North America'' is out of place.
This fact (that lunar eclipses are visible from half the world whereas solar eclipses are visible from such a small region) makes lunar eclipses seem much more common than solar eclipses; in fact, the contrary is true. The last total solar eclipse in the world was on August 11, 1999 in Europe (I was there), and the next one is next year in Madagascar.
Reminds me of a similar occurrence in a math course some years ago:
Professor: so this proves theorem (X). Now you may wonder whether statement (Y), the converse of theorem (X), is true. But statement (Y) is not true, as the following counter-example shows: (counter-example Z). On the other hand, the following modified version of statement (Y) is correct: (theorem T).
Me: excuse me, Sir, but counter-example Z also contradicts your proposed theorem T.
Professor appears confused, thinks for a while, and then changes the counter-example!
This is no Y2k bug, it's merely that your wtmp file has been rotated or wiped, so the last login is listed as the Unix Epoch (the date you state is precisely Thu Jan 01, 1970 at midnight UTC, i.e. the Unix Epoch).
It happens to me all the time (because I rotate my wtmp files faster than I should, I guess). Except that since I'm in the +0100 time zone, the date printed is more immediately recognizable as the Unix Epoch.
Let's have some fun splitting these hairs in real tiny pieces.
There are several standards used for keeping track of time. The most important, by far, is Universal Time Coordinated (UTC), sometime known as GMT (Greenwhich Mean Time). This is the standard time for Earth, and it is with respect to this time that local time is defined (offset by a certain number of seconds, generally a multiple of 3600, i.e. an integer number of hours).
UTC does not flow linearly. That is, the interval between time t1 UTC and time t2 UTC is not always t2-t1. This is because leap seconds get inserted occasionally in UTC, so as to keep it more or less synchronized with the sun. More precisely: there are 86400 SI seconds in an SI day; but the mean solar day is approximately 2 milliseconds longer, because the Earth's rotational period is getting longer (the Earth is slowing down) at an order of magnitude of 1 millisecond per day per century. Terrestrial Time (sometime called Ephemeris Time) is the astronomical time: it is currently 0.184 seconds (roughly) fast of UTC. And UTC will be corrected so as to always keep it to within 0.9 seconds of TT (i.e. the sun should always be overhead on Greenwhich meridian to within 0.9 seconds at noon UTC).
Adding a leap second can take place after December 31 or June 31 (or possibly also March 31 or September 31, but that has never occurred), in the following form: after 23:59:59UTC comes 23:59:60UTC and after that comes 00:00:00UTC. The last leap second happened after December 31, 1998, and there will be no leap second after December 31, 1999 (today). It is the International Earth Rotation Service that is in charge of deciding when a leap second should be inserted. (Theoretically, a second can also be substracted, but that has never happened and presumably never will.)
The other important time standard is the Temps Atomique International (this is in French because the Bureau International des Poids et Mesures is in Sèvres, France), TAI for short. Contrary to UTC, TAI is a linear time scale (to the best of the precision we can achieve, that is, i.e. to within a few dozens of nanoseconds per year). TAI ticks one second every SI second, and it is maintained by averaging over about 50 atomic clocks around the world (there is no Master clock for TAI); the calculated offsets of the atomic clocks wrt TAI can be found in this FTP directory.
The Temps Atomique International and the Universal Time Coordinated are offset one to the other by an integer number of SI seconds (since 1972). This offset increases by one every time a leap second is inserted in UTC. Currently (since January 1, 1999 and at least to June 31, 2000) TAI is 32 seconds fast of UTC (so by the time UTC reaches January 1, 2000, 00:00:00, TAI will read January 1, 2000, 00:00:32).
So TAI will say Y2k precisely 32 seconds before UTC says so. (There is also GPS time, which is exactly 19 seconds back of TAI, but never mind that one. And, of course, there is Terrestrial Time, which nearly coincides with UTC, but not by a round number.)
Now, which of these times should be used on computers? Well, if you look in the/usr/share/zoneinfo/ directory of a GNU system, you will notice that there is a right/ subdirectory which contains nearly identical zone info files. The difference is this: the zone info files in the right/ directory account for leap seconds, whereas the ones outside this directory do not. Thus, if your/etc/localtime points to a right/ time zone, exactly 32 seconds will be substracted from your system clock before it is corrected by the time zone offset.
System time should be a linear time. If clocks were precise enough, it would be inadmissible to skew the clock by as much as one second (even by diluting the effect over a certain period). Thus, system time should be put to TAI (and not to UTC, let alone local time). This is why the right/ time zones are there: if you set your system clock to TAI and set your/etc/localtime to point to a right/ time zone, then your local time (as returned by the localtime() library function call) will be offset to UTC, as it should.
On the other hand, the POSIX standard (see POSIX.1, Annex B, 2.2.2) specifies that the time() system call should measure the difference between the current UTC time and the UTC time of the Epoch (January 1, 1970 at 00:00:00UTC). This is most unfortunate, because a difference of UTC times is not a number of seconds elapsed. And it is especially unfortunate since the rules for computing UTC from TAI were rather complicated before January 1, 1972 (at which time UTC was resynchronized to TAI-10s). Thus, the Unix Epoch, though it is January 1, 1970 at 00:00:00UTC, is actually January 1, 1970 at 00:00:08.000082TAI, and although on January 1, 2000 at 00:00:00UTC (January 1, 2000 at 00:00:32TAI) exactly 946684823.999918 seconds (as measured with respect to TAI) will have elapsed since the Unix Epoch, the time() function will return 946684800.
This being so, either the POSIX standard is mad, or the right/ timezones are wrong. I would tend to say that POSIX is crazy, and that system clocks should measure TAI and leave out the leap seconds. But since system clocks are synchronized by NTP, and since NTP gives UTC (while skewing the system clock to somehow jam in the leap seconds), the POSIX standard is followed de facto. (As a compromise, I would suggest moving the Epoch back in time by 82 microseconds to avoid these funky non-integer figures.)
If I recall correctly, VMS measures time using the Modified Julian Date. This is also synchronized with UTC. January 1, 2000 will be julian day 2451544.5, so MJD 51544.
To summarize, I say that Y2k is when the Unix time() function returns 946684800, which is exactly 946684823.999918 second of atomic time after the Unix Epoch.
Another stupid bit of trivia: according to ISO (the ISO8601:1988 standard), Y2k doesn't start until the first monday of the year, i.e. January 3, 2000. As for January 1, 2000, it is still ``day 6 of week 52 of 1999''. See your local emacs for information on what this day is in various other calendars.
Please provide more info on these ``GPL0 virii'', I'm curious. Does ``GPL0'' refer to operation at ring 0 (like, in the kernel)?
I can quite see that you probably can do many things with the microcode, but what I'm saying is that it's much harder and on the whole far less efficient than using a backdoor in a network card. There's no question that you can do everything, but you are stuck to the neck in a Turing tar-pit.
And, in fact, no, you can't do anything you want. Another instance of this ``computation in hostile environment'' I've been ranting about in Slashdot these past few weeks: it would theoretically be quite possible to have the computer operate on encrypted data, without being able to learn anything useful from the manipulations, even if the OS and the microchip are in enemy hands. Naturally, the encryption and the decryption have to take place elsewhere.
Apart from that, it's all a question of deciding whom you trust, and of trusting Trust itself. The paranoid can even imagine a back door in the laws of physics itself (that some physicist discovers without telling anybody): grounds for a good science fiction, I guess. The compiler may have a back door, that you can't detect without reading the assembly code, that isn't present in the sources, but that inserts itself everytime you recompile the compiler. Maybe every C compiler in the world has such a back door: I don't think anyone ever had the patience of reading the entire assembly output of any C compiler — ever. Maybe it's at an even lower level: maybe the microchips all have a back door in them, and this back door is so subtle that whenever a new microchip is designed (by means of some computer, presumably), the back door in the computer that does the designing will add the back door to the computer being designed.
After all, that is what we are: a self-replicating back door on the surface of the Earth. It took evolution billions of years to design us, but maybe back doors in cyberspace evolve faster.
Another time capsule I very much like: go to ftp://ftp.digital.com/pub/DEC/sim/ and download the PDP emulator from the sources/ subdirectory. Then download the files from the software/ directory: uv5swre.tar.Z is an image of a PDP-11 disk running Unix version 5. That's really something worth trying out. You can also download Unix versions 6 and 7, and some old version of RSTS/E, and a few other dusty programs of the kind. Including a copy of the Lisp interpreter (with source), by L. Peter Deutsch, for the PDP-1.
One thing I would also very much like is to be able to run ITS, the fabled hackers' operating system that ran on the PDP-10. I found the sources, but I don't have a PDP-10 emulator capable of running that thing.
This is plain paranoia. There's no way changes in the microcode could represent a security threat: it's DoS at worse. Something as low-level as microcode has no way of knowing what's going on inside the computer, or draw any useful information from what it sees, let alone communicate it outside.
In any case, loading the microcode, on the Pentium processors, can only take place in real mode (virtual 8086 mode won't do it). Linux runs in protected mode. (Of course, we only have Intel's word on the subject.)
You can also imagine a backdoored network card that occasionally sends a special ethernet frame containing a random page of your physical memory.
If you want to be that paranoid, you can also imagine that there's a back door in gcc. I suggest you read Ken Thompson's excellent Turing Award lecture on the subject, Reflections on Trusting Trust.
For example: the basic problem is that people are dishonest. The Wrong solution is to use passwords and such; the Right Thing would be to make everyone perfect. But I am not Richard Stallman to continue using 'rms' or the empty string as a password because that is the Right Thing. I use passwords even though they are the Wrong Thing. So, obviously, I can only be joking when I make this claim.
Still, it should at least make yourself wonder if there isn't a better way to deter people from cheating, like, try to persuade them that it isn't fun and that it spoils others' pleasure, or ban them if they are caught at it. Or some such thing. I'm not saying it will work, but I think it should at least be considered before jumping to solutions like are being proposed.
In any case, the essential point is that a binary loader just makes it slightly more difficult to cheat. I'm sure someone can easily come up with an (open source?) program that will spoof the loader in a systematic way. (As I pointed out, all it takes is a ptrace().)
``Never let your sense of morals prevent you from doing what is right.'' -- Salvor Hardin
There is no patent on CSS technology, because they wanted to keep it secret. Therefore, the DVD Copy Control Association cannot sue on patents ground.
The encryption was a trade secret, but none of the plaintiffs ever signed a non disclosure agreement over anything.
It is not true that the primary use of DeCSS is to copy DVD's. Even if it were, such a copy is not necessarily illegal; and it certainly doesn't make the code illegal. (After all, photocopy machines aren't illegal as far as I know.)
Reverse engineering for the sake of interoperability is permissible.
Some of the defendents live outside the Court's domain of jurisdiction and their sites also; some are even outside the US.
The defendents have only been notified by email.
This is just too obviously bogus. Evidently they are only trying to spread FUD.
They might have had a case against Derek Fawcus, although even that seems dubious. Now that he retracted, they have no case against anyone.
...is just something that has never worked, will never work, and cannot work. Every now and then someone tries to use it (the DVD Consortium for example), arguing that ``yes, in general security through obfuscation is bad, but in this particular case it will work''; wrongo: it always fails.
This is made abundantly clear in Bruce Schneier's famous book on cryptography.
This is not an open source vs. proprietary software problem, it is a disclosed source vs. obfuscation problem. This is not an ethical issue, it is a completely practical one, and it seems that the lesson needs to be learned one more time.
Carmack's suggested closed-source binary loader can be spoofed much more easily than by using a proxy. Indeed, it contains an obvious race condition: how is the loader to check that the program hasn't been altered between the time it is checksumed and the time it is run? A simple ptrace() should do the trick for that, and, in fact, anything invented along similar lines.
As another poster pointed out, what we need is to have Quake clients act as simple 2D rendering clients. But that means the server would have to perform all the 3D calculations and that is hopeless. We want the client to perform the calculations without being able to spoof them; so the problem amounts to the following:
(``Computing in `hostile environment' ''). You are given a powerful computer and you want to use it to perform a computation. However, you cannot trust the computer. You want to perform the computation in such a way that the computer should be (a) unable to fool you (i.e. give a wrong answer and make you think it is the right answer), and (b) unable to learn anything from the computation (in the Quake case, learn more than the final, 2D, result). The computer can refuse to carry out the computation, of course, and you cannot prevent this, but it cannot make you think it carried out the computation whereas in fact it is fooling you.
This is a purely theoretical problem, and it has been studied. A cryptologist told me (but was unable to give a reference, unfortunately) that the problem is solved in the theoretical sense: computation in hostile environment is possible (using strong crypto). This makes it theoretically possible to have a solution to the problem using just one secret key, stored on the server and everything else being disclosed (basically: the server sends the encrypted computation to the client, the client performs the computation without knowing what it is calculating, sends it back to the server, the server verifies that the computation was correctly carried out, and sends the decrypted result to the client). Unfortunately, this solution is completely unpractical (the bandwidth required is simply too large).
So, the Right Thing fails. IMHO, this is not, however, an excuse to do the Wrong Thing. If the problem has no solution, then the problem is not a problem!
Slashdot Mirror
Actually, the time lords are rather the Bureau International des Poids et Mesures (International Weights and Measures Bureau) for TAI (atomic time) and the International Earth Rotation Service for UTC (who make the decision of when to add leap seconds for example).
Granted, on last reading, the USNO master clock was only five nanoseconds fast of UTC, as computed by the BIPM (by averaging many different atomic clock's reading of UTC).
GMT is what it says it is: the mean solar time on Greenwich meridian (after correction of the Earth's nutation and pole displacement). It is also called UT1, or Universal Time. This time standard is obsolete and deprecated, because it is an astronomical standard, and is subject to many irregularities.
The current time standard is UTC, or Universal Time Coordinated, which is defined as offset by a certain number of seconds with respect to TAI (the international atomic time, maintained by averaging a number of atomic clocks around the world), currently UTC=TAI-32s. This offset is changed occasionally by inserting a leap second in UTC, so that the difference UTC-UT1 never exceeds 0.9s in absolute value (currently it is around -0.3s).
For nearly all real-life practices, UT1 and UTC can be assimilated under the general name ``Greenwich Mean Time'' or (more correctly) ``Universal Time'', but the correct term is ``Universal Time Coordinated''.
See this page I wrote for more information.
The exact times are:
The times are given un universal coordinated time and apply to 2000/01/21. Add or substract your time zone correction.
The time, of course, does not depend on the place. The eclipse is visible from wherever on Earth it happens to be night at the time in question. (Naturally, since there is an eclipse, the moon is full, so it is night precisely when the moon is visible, atmospheric perturbations excluded.)
Hair splitting alert ON.
The number of (different) pages on the web is actually infinite. Here is a sample infinite component.
(Actually it's finite because the maximal accepted length for a URL is finite. But it's way above the billions.)
Note that these are not dynamical pages. Dynamical pages (i.e. pages whose content changes for the same URL) don't count: they're cheating.
(The source used to generate this infinite number of pages is available under the GPL.)
Anyone notice? Potato is not only release 2.2 of Debian GNU/Linux, it's also the long-expected version 0.3 of GNU/Hurd (the first of Debian GNU/Hurd). Check the binary-hurd-i38 6 directory. Admittedly, many (if not most) Hurd deb packages are actually binary-all packages (and some are plain useless under the Hurd) — one Hurd developper jokingly said the Hurd would take its revenge by committing a lot of Hurd-specific binary-all packages.
True, the Hurd is still far from stable now (and moving this tree from frozen to stable will sound something like a joke), but this is an important landmark nonetheless.
lynx has this big advantage, also, that it can make something sensible out of Unicode. Netscape is just fscking worthless in this respect: it doesn't even understand — (the em-dash character). Unfortunately, I use — regularly in my web documents (no bugware!), so they're about unreadable with Netscape. Same for “ (the English-style open quotes) and so on (though I tend to compromise and use `` instead of “ or possibly the French double quotes ).
lynx run in an xterm with wide chars enabled and a fixed-width Unicode font is so far the best solution I've found to viewing Unicode characters correctly.
(Note: Unicode is not just useful in foreign languages. Some punctuation signs like the ellipsis, or, as I mentioned above, the em-dash and the quotes, are to be found in Unicode. As a matter of fact, Unicode is more useful for English than for French, because nearly all the French characters are in ISO-8859-1, and the French-style quotes are there, whereas the English-style quotes are far away in Unicode tables.)
lynx has its irritating features, though. It can't render tables, and that's a pain. w3m at least does that correctly. Also, lynx displays <i> as underline: that's stupid, <i> is italics, not emphasis (emphasis is <em>), and if it can't do italics, it should do nothing and ignore the tag. And it doesn't understand <dfn> (now that should probably be underlined).
And lynx completely ignores CSS. Agreed, in text mode, there isn't much you can get from CSS, but at least the margin definitions wouldn't be too hard to implement, and that would be useful.
Evidently The Matrix is strongly influenced by the philosophy of Socrates (at least as far as Plato tells us about it). The bit about the Oracle just makes it a tad too obvious: the wise saying ``know yourself'' (``GNOTHI SEAUTON'' in Greek — now I wonder why the makers of the movie decided to translate it in Latin: ``NOSCA TEMET'') was carved in front of the real Oracle, in Delphi, and Socrates adopted it as his motto. (Socrates, it seems, went to see the Oracle in Delphi and thus discovered about his own wisdom: ``the only thing I know is that I know nothing'' (``en oida ho ti ouden oida'').)
The whole film reeks of the parable of the cavern, told by Socrates in Plato's Republic. Recall that it goes something like this: some men are prisoners in a cavern, and are bound so that all they can see is a wall in front of them, and the shadows on that wall made by objects moving behind them. The prisoners think that the shadows are the real objects and give names to them. But one day a prisonner is unchained and goes out of the cavern. At first he is blinded by the sun, but after some time he gets accustomed to Reality. He goes back to the cavern and tries to convince his fellow prisoners that what they see are only shadows of the real objects. And so on. (If you want the full story, read The Republic.)
Now Plato has a very elitist vision of mankind. He was strongly opposed to democracy (two of his uncles were part of the Thirty Tyrants, the antidemocratic regime imposed upon Athens when it lost the Peloponnesian war against Sparta). The whole idea of The Republic, if I dare summarize it in just a few words, is that philosophers (those who can see further than the shadows of the parable's cavern) should be in charge of ruling the (city-)state. I think (I hope) that The Matrix has a more democratic vision of things, that the idea is to free mankind — all of mankind, not just a select happy few.
Another intersting point which is made, albeit briefly, in The Matrix, is when whatshisname discusses about the taste of things, how they might taste in reality, and how they taste in the Matrix: of course, the cavern's shadow-world is a projection of reality, but it is only a projection, and there is nothing to say that the reality is not vastly different from the projection (or vice versa).
I don't think this comparison is all that important, but it certainly fun to think how a science-fiction film of the end of the XXth century could have been greatly influenced by the writings of a philosopher nearly 25 centuries earlier.
(PS: Here in France we have philosophy courses in high school. I think that is a good idea.)
> Unless HURD does things that other OS's cannot do.
Well, of course, anything that any OS can do, a Turing machine can do. So it's more a question of relative ease.
If we imagine the Hurd as more or less finish, it can do all the things that Linux does, perhaps slower (though it is hard to predict by how much), especially on single-processor systems. But here is a concrete use that the Hurd might have which would not work on Linux: it would make it possible to sell computing power on a machine (for example to put a web server on it), including root access (something which is often desirable), to several different clients without any interaction between them, and without compromising the system security. Because Hurd can be virtualized. This is an example something which could provide motivation to get the Hurd working.
I'd say the debugging is easier, except that what you're trying to debug is much more complex, so that as a whole the whole debugging process is more difficult. Essentially, because the Hurd servers are heavily multithreaded programs that pass messages to each others in all sorts of ways. That is always hard to debug, even in user space.
I don't think this is really the reason why the Hurd has progressed so slowly, though, no matter what Stallman may say. Or at least, there are other factors in play.
Good point. Moreover, as I pointed out, the monolithic kernel vs microkernel debate is exactly a library vs client/server system, at a sufficiently abstract level.
Clearly there is nothing you can do with a library that you can't do with a client/server system. But in fact, the converse is also mostly true. It would be quite possible, IMHO, to have the Hurd features on a monolithic kernel system: essentially, the monolithic kernel provides the capacity-based security model, and the filesystems are integrated in a set of dynamic libraries rather than in a set of servers. This requires the concept of setuid (or rather, ``acquire capability'') libraries, but there is nothing fundamentally impossible with this.
So, the microkernel issue should not be judged as providing the Hurd functionality but rather, on its own grounds (replacing a library-alike calling system by a client/server model). I am not competent to judge in this matter, but one thing is certain, namely that the entire issue is not completely clear-cut. The official ``Tunes'' rant on the microkernel issue might not be completely wrong (despite the author's numerous deliberately provotating statements).
This is due to the way the communication works. On a monolithic kernel, when a process needs, say, to perform a filesystem read, it will invoke a processor trap to go in kernel mode (protection level 0), then perform the task as a privileged task (from the processor's point of view). The overhead is just a trap call, which is comparatively low: even the branch prediction mechanisms are not invalidated by this. On a microkernel, on the other hand, the process needs to send a message to the server task. Essentially, things proceed thus: the client task writes the message to a memory page, then goes in kernel mode to ``send'' the message to the server task (all that is just as fast as for a monolithic kernel); then it starts waiting for the reply. But that means it is unscheduled and another task (presumably the server task) is scheduled in its stead. The reschedule may be slow, since it involves replacing all the registers, but that is not the worst part. The worst part is that the paging register is changed (the virtual memory layout is unique to each task, so a task change must change the paging register, CR3 on an Intel), and that means that the TLB (``Translation Lookaside Buffer'', the cache for the paging mechanism) gets flushed. This is why processes are so much more costly than threads (which share the same address space), and this is why RPC calls are so costly. There are two context switches (TLB flushes) for each single message sent from the client to the server (plus, possibly, its reply).
At a sufficiently abstract level, a monolithic kernel is nothing else but an I/O access library which is shared by every process and which enjoys certain specific rights. In a way, every process ``carries its own copy of the kernel'' with it. On the other hand, for a microkernel, the ``library'' approach is replaced by a ``client/server'' approach.
There are possible ways around the problem. A microkernel architecture like QNX uses a single address space. Since user tasks operate at the same privilege level, they are not protected the ones from the others. It may be possible to put the device drivers at ring 1 (between the kernel at ring 0 and the user processes at ring 3), I think NT does this; but this contradicts the basic principles of symmetry which the Hurd tries to enforce. Segmentation might also help things, but it is hard to work with. Or, simply, more modern processor architectures might not enforce a TLB flush with each change of address space, but simply mark TLB entries with the address space with which they are associated (or some such thing), or some such thing. I think the Alpha does something of the kind.
On a SMP machine, the cost of an RPC call is not nearly so high: imagine the client task is running on processor A while processor B is idle; when the request is sent, processor B immediately starts executing the server task, and when the client task starts waiting, it is not replaced by another task because no other task is waiting, processor A just waits until processor B finishes execution, so no context switch occurs on either processor if the scheduler is good enough. Essentially, we have not used two processors, but merely the fact that two processors have two TLB's.
It may also be possible to group requests as much as possible before unscheduling the client. But that is rather hard to do. This is what the Xlib does for the X protocol, but I do not see how the libc (which is the analog of the Xlib for the Hurd protocol) could do the same, considering the semantics it has to obey (notably that each call must return an error code).
Since a few people seem to be interested, I will recapitulate the overall HURD status, from my personal experience and my reading of the debian-hurd and bug-hurd mailing lists.
First, is it usable? Well, it depends for what. It is still quite unstable. Filesystems are under active development, but there are still some problems with them (the ``native'' Hurd filesystem, if that means anything, is ext2 just like Linux, but the ext2 demon still has problems, one of them being that sometimes entire file blocks are replaced by zeroes — this will be fixed soon). The TCP/IP stack is a copy of that of Linux (but the Hurd maintainers are having trouble keeping up with the changes made to the Linux networking code). The security mechanisms are extremely flexible but that sometimes causes problems (for example, the Hurd has one more set of file permissions besides user, group and other permissions, the ``not-logged-in'' permissions, and no tools yet exist that will allow to manipulate these permissions). There are also some strange limitations: for example, Hurd will not work on a partition of more than 1Gb, and it crashes rapidly if not given a swap partition.
X Windows will work with a set of patches. Some other programs cause problems, and sometimes it's the program's fault (because it makes assumptions about the Unix-like nature of the system which are not verified under the Hurd).
On the other hand, the Hurd is stable enough to bootstrap itself (compiler, microkernel, libraries, demons) and perform tasks that do not have stringent hardware requirements.
The Hurd shares the same libc as Linux (the GNU libc, currently version 2.1.2). So eventually it should be binary compatible with Linux (right now it is not, but there is no severe problem with that, it is only a matter of time). This is one of the great hopes of Hurd, the possibility of making the transition completely smooth.
The slowness of the progress on the Hurd is due to nobody working on it full time. Some very competent programmers are devoting a lot of time to it (Thomas Bushnell, Brent Fulgham, Roland McGrath, Marcus Brinkmann and certainly a few I'm forgetting), but they are overwhelmed by the immensity of the task.
In theory, though, the Hurd should be easier to develop than Linux, because it is more inherently modular, and because of the fantastic possibilities of gdb under the Hurd. Also, you do not need to reboot to test changes to the ``kernel'', and you can debug a live kernel without problem; plus, you can test some experimental features without endangering the base system. So, there is no reason that Hurd can't become very solid and stable — quite the contrary in fact. But they just need more volunteers. And the FSF unfortunately cannot affort to hire someone on it full time (say, why not write a check to the FSF specifying that you would like to see it employed for Hurd development?).
On the other hand, in the domain of performance, it is probable that a microkernel architecture can never be at par with a monolithic kernel, at least on single-processor machines. For the moment, the Hurd is horribly slow with filesystems (rm -rf is just a nightmare), but this is mostly because it is completely unoptimized. Still, even when it is, it will probably remain noticeably slower than Linux. It has been claimed, however, that the difference may be significantly less than expected; but it is yet too early to see.
The main advantage of the Hurd is its flexibility. User-land filesystems are part of that. In fact, you do not even need to be root to write a filesystem. (That is one of the things which angers me the most about Linux, the need to be root to mount a simple loopback file.) The Hurd is completely virtualizable, whereas Unix hardly is (well, there is a ``user-mode Linux'', but it is even more experimental than the Hurd), so any user can set up her own virtual sub-hurd with its own set of users, permissions and so on. The security system is soooo flexible: much better than access control lists, it uses capabilities (àla Eros) in the form of Mach ports. If this were made practical, this would be a huge gain on the security side, because you would practically never need to be root for anything, just introduce the ad hoc capabilities and permissions. And the virtualization possibilities let you surround dangerous demons by ``sanitary cords'', making the system much harder to break into. So, theoretically, the Hurd can be a very secure system. Finally, the whole translator system can be used in yet unthought-of ways to provide wondrous communication mechanisms between programs.
However, the real question now is whether binary compatibility with Linux plus the great extra features and flexibility can be sufficient motivation for people to move to the Hurd when it is more stable, and, in the mean time, for more developpers to draw their attention to it. The lack of hardware support, on the other hand, is not a big problem: Roland McGrath has an experimental project for making the Mach microkernel run with the Flux OSKit, so that all the Linux hardware support would immediately benefit the Hurd.
First, as I explain in another post in this disucssion, e-.com or microsoft-.com are not illegal domain names. Just read RFC1035: the title of section 2.3.1 is ``Preferred name syntax'': this is a SHOULD, not a MUST.
If someone decides to register this domain, it's their problem. If it breaks programs like TELNET, it's also their problem (``their'' refers to the people who registered, not to the programs): they took the risk to register that domain, knowing that they might have problems, and if their customers get angry because they can't access the domain, it't their problem.
The programs SHOULD, according to the RFC, do the best to be ``liberal in what they accept'', and accept all the names they can to pass them to the resolver library. The resolver library SHOULD accept any kind of characters, binary characters included, and pass them verbatim to the name servers (they shouldn't even change the letter case, only the nameservers are permitted to make the final decision on this subject).
Within their own domain, people are permitted to do whatever they want, including using binary characters in (sub)domain names, not being case-insensitive, or any other stupid thing on the same line. It will break everything, but, again, it's their problem.
I agree with the ICANN's decision to register this. Nowhere in the RFC's does it say they may not (at least, as far as I know). All this, as far as they're (to be) concerned, is ``somebody else's problem''. Just like it is if the IP address you give them as primary nameserver is invalid or does not work.
The other point is RFC1591, which (meta-)specifies the way the three-letter TLD's are organized. Note in particular that nowhere in it is it stated that the .org domain is for non-profit organizations, contrary to what is frequently claimed. But the ICANN is to be blamed for not respecting this RFC on several counts (notably for the .net domain; also, something like un.org should be un.int).
I whish this ``www.[any word].com'' nonsense would stop. My suggested solution would be to invent another, better adapted, distributed data base, to transform a word or phrase to a URL, call it, say, ``true names''; then add a truename:// URL scheme, which gets relocated using the ``true names'' database to the correct URL. Integrate that scheme in every popular browser, and make it the default URL scheme. Then DNS names can become again what they are supposed to be: computer names, not resource names. Admittedly, I am only suggesting displacing the problem, but maybe the other database I mention can be better attuned to the kind of problems we have with the DNS, and which the DNS was not designed to handle.
The reference is RFC1035 (``Domain Names — Implementation and Specification'') by Mockapetris. But read it carefully: the section 2.3.1 is entitled ``Preferred name syntax'' (emphasis is mine). There is nothing illegal about names not following this convention; in fact, RFC1035 domain names can contain arbitrary characters, even binary (including the dot character, the null character, and mixed case!). The RFC essentially restates the golden rule: be liberal in what you accept and conservative in what you send (i.e. use the suggested conventions if possible when creating domain names, but be prepared to accept any kind of data when you receive a domain name). The RFC suggests the conventions you name precisely for compatibility with mail and TELNET (see the notes at the beginning of section 2.3.1), so you are putting the cart before the horses (``illegal'' names are ``illegal'' because they break TELNET, not the other way around).
A domain name is not supposed to start with a digit, but this rule is violated in the very RFC for the IN-ADDR.ARPA domain. Arguably, this is not a problem because you can't TELNET directly to an IN-ADDR.ARPA domain host (I find it rather unfortunate that I can't type telnet t.z.y.x.in-addr-arpa as a substitute for telnet x.y.z.t, I've never understood why that is disallowed).
I wonder, with all the fad on Unicode, whether Unicode characters will end up being allowed in domain names. Then every trademark-owning company would rush to register their name in every possible script. Or, worse even, get their logo added to the Unicode tables and register the <logo>.com domain. Fortunately, the Unicode Consortium has decided never to include logos in the official Unicode tables (but they might get added in the user-reserved areas if some vendor (i.e. Micro$oft) is influential enough to provide a kind of standard in this domain). Imagine people not knowing how to write any more, just choosing the company's logo in a huge table, and pasting it in the location bar of their browser...
Flamebait, but I won't bite. Ever learned how to read? I was talking about South America.
Excuuuuse me? What in the world does it mean for a lunar eclipse to be ``in (for) North America''?
This would make sense for a solar eclipse, since solar eclipses are very localized, but a solar eclipse happens at the new moon, whereas a lunar eclipse happens at the full moon (for obvious reasons).
A lunar eclipse is visible throughout the hemisphere where it is night (which, of course, is the same as the hemisphere where the moon is visible, since the moon and the sun are in opposition), so at best the ``north'' in ``North America'' is out of place.
This fact (that lunar eclipses are visible from half the world whereas solar eclipses are visible from such a small region) makes lunar eclipses seem much more common than solar eclipses; in fact, the contrary is true. The last total solar eclipse in the world was on August 11, 1999 in Europe (I was there), and the next one is next year in Madagascar.
Reminds me of a similar occurrence in a math course some years ago:
Professor: so this proves theorem (X). Now you may wonder whether statement (Y), the converse of theorem (X), is true. But statement (Y) is not true, as the following counter-example shows: (counter-example Z). On the other hand, the following modified version of statement (Y) is correct: (theorem T).
Me: excuse me, Sir, but counter-example Z also contradicts your proposed theorem T.
Professor appears confused, thinks for a while, and then changes the counter-example!
This is no Y2k bug, it's merely that your wtmp file has been rotated or wiped, so the last login is listed as the Unix Epoch (the date you state is precisely Thu Jan 01, 1970 at midnight UTC, i.e. the Unix Epoch).
It happens to me all the time (because I rotate my wtmp files faster than I should, I guess). Except that since I'm in the +0100 time zone, the date printed is more immediately recognizable as the Unix Epoch.
Let's have some fun splitting these hairs in real tiny pieces.
There are several standards used for keeping track of time. The most important, by far, is Universal Time Coordinated (UTC), sometime known as GMT (Greenwhich Mean Time). This is the standard time for Earth, and it is with respect to this time that local time is defined (offset by a certain number of seconds, generally a multiple of 3600, i.e. an integer number of hours).
UTC does not flow linearly. That is, the interval between time t1 UTC and time t2 UTC is not always t2-t1. This is because leap seconds get inserted occasionally in UTC, so as to keep it more or less synchronized with the sun. More precisely: there are 86400 SI seconds in an SI day; but the mean solar day is approximately 2 milliseconds longer, because the Earth's rotational period is getting longer (the Earth is slowing down) at an order of magnitude of 1 millisecond per day per century. Terrestrial Time (sometime called Ephemeris Time) is the astronomical time: it is currently 0.184 seconds (roughly) fast of UTC. And UTC will be corrected so as to always keep it to within 0.9 seconds of TT (i.e. the sun should always be overhead on Greenwhich meridian to within 0.9 seconds at noon UTC).
Adding a leap second can take place after December 31 or June 31 (or possibly also March 31 or September 31, but that has never occurred), in the following form: after 23:59:59UTC comes 23:59:60UTC and after that comes 00:00:00UTC. The last leap second happened after December 31, 1998, and there will be no leap second after December 31, 1999 (today). It is the International Earth Rotation Service that is in charge of deciding when a leap second should be inserted. (Theoretically, a second can also be substracted, but that has never happened and presumably never will.)
The other important time standard is the Temps Atomique International (this is in French because the Bureau International des Poids et Mesures is in Sèvres, France), TAI for short. Contrary to UTC, TAI is a linear time scale (to the best of the precision we can achieve, that is, i.e. to within a few dozens of nanoseconds per year). TAI ticks one second every SI second, and it is maintained by averaging over about 50 atomic clocks around the world (there is no Master clock for TAI); the calculated offsets of the atomic clocks wrt TAI can be found in this FTP directory.
The Temps Atomique International and the Universal Time Coordinated are offset one to the other by an integer number of SI seconds (since 1972). This offset increases by one every time a leap second is inserted in UTC. Currently (since January 1, 1999 and at least to June 31, 2000) TAI is 32 seconds fast of UTC (so by the time UTC reaches January 1, 2000, 00:00:00, TAI will read January 1, 2000, 00:00:32).
So TAI will say Y2k precisely 32 seconds before UTC says so. (There is also GPS time, which is exactly 19 seconds back of TAI, but never mind that one. And, of course, there is Terrestrial Time, which nearly coincides with UTC, but not by a round number.)
Now, which of these times should be used on computers? Well, if you look in the /usr/share/zoneinfo/ directory of a GNU system, you will notice that there is a right/ subdirectory which contains nearly identical zone info files. The difference is this: the zone info files in the right/ directory account for leap seconds, whereas the ones outside this directory do not. Thus, if your /etc/localtime points to a right/ time zone, exactly 32 seconds will be substracted from your system clock before it is corrected by the time zone offset.
System time should be a linear time. If clocks were precise enough, it would be inadmissible to skew the clock by as much as one second (even by diluting the effect over a certain period). Thus, system time should be put to TAI (and not to UTC, let alone local time). This is why the right/ time zones are there: if you set your system clock to TAI and set your /etc/localtime to point to a right/ time zone, then your local time (as returned by the localtime() library function call) will be offset to UTC, as it should.
On the other hand, the POSIX standard (see POSIX.1, Annex B, 2.2.2) specifies that the time() system call should measure the difference between the current UTC time and the UTC time of the Epoch (January 1, 1970 at 00:00:00UTC). This is most unfortunate, because a difference of UTC times is not a number of seconds elapsed. And it is especially unfortunate since the rules for computing UTC from TAI were rather complicated before January 1, 1972 (at which time UTC was resynchronized to TAI-10s). Thus, the Unix Epoch, though it is January 1, 1970 at 00:00:00UTC, is actually January 1, 1970 at 00:00:08.000082TAI, and although on January 1, 2000 at 00:00:00UTC (January 1, 2000 at 00:00:32TAI) exactly 946684823.999918 seconds (as measured with respect to TAI) will have elapsed since the Unix Epoch, the time() function will return 946684800.
This being so, either the POSIX standard is mad, or the right/ timezones are wrong. I would tend to say that POSIX is crazy, and that system clocks should measure TAI and leave out the leap seconds. But since system clocks are synchronized by NTP, and since NTP gives UTC (while skewing the system clock to somehow jam in the leap seconds), the POSIX standard is followed de facto. (As a compromise, I would suggest moving the Epoch back in time by 82 microseconds to avoid these funky non-integer figures.)
If I recall correctly, VMS measures time using the Modified Julian Date. This is also synchronized with UTC. January 1, 2000 will be julian day 2451544.5, so MJD 51544.
To summarize, I say that Y2k is when the Unix time() function returns 946684800, which is exactly 946684823.999918 second of atomic time after the Unix Epoch.
Another stupid bit of trivia: according to ISO (the ISO8601:1988 standard), Y2k doesn't start until the first monday of the year, i.e. January 3, 2000. As for January 1, 2000, it is still ``day 6 of week 52 of 1999''. See your local emacs for information on what this day is in various other calendars.
Please provide more info on these ``GPL0 virii'', I'm curious. Does ``GPL0'' refer to operation at ring 0 (like, in the kernel)?
I can quite see that you probably can do many things with the microcode, but what I'm saying is that it's much harder and on the whole far less efficient than using a backdoor in a network card. There's no question that you can do everything, but you are stuck to the neck in a Turing tar-pit.
And, in fact, no, you can't do anything you want. Another instance of this ``computation in hostile environment'' I've been ranting about in Slashdot these past few weeks: it would theoretically be quite possible to have the computer operate on encrypted data, without being able to learn anything useful from the manipulations, even if the OS and the microchip are in enemy hands. Naturally, the encryption and the decryption have to take place elsewhere.
Apart from that, it's all a question of deciding whom you trust, and of trusting Trust itself. The paranoid can even imagine a back door in the laws of physics itself (that some physicist discovers without telling anybody): grounds for a good science fiction, I guess. The compiler may have a back door, that you can't detect without reading the assembly code, that isn't present in the sources, but that inserts itself everytime you recompile the compiler. Maybe every C compiler in the world has such a back door: I don't think anyone ever had the patience of reading the entire assembly output of any C compiler — ever. Maybe it's at an even lower level: maybe the microchips all have a back door in them, and this back door is so subtle that whenever a new microchip is designed (by means of some computer, presumably), the back door in the computer that does the designing will add the back door to the computer being designed.
After all, that is what we are: a self-replicating back door on the surface of the Earth. It took evolution billions of years to design us, but maybe back doors in cyberspace evolve faster.
Another time capsule I very much like: go to ftp://ftp.digital.com/pub/DEC/sim/ and download the PDP emulator from the sources/ subdirectory. Then download the files from the software/ directory: uv5swre.tar.Z is an image of a PDP-11 disk running Unix version 5. That's really something worth trying out. You can also download Unix versions 6 and 7, and some old version of RSTS/E, and a few other dusty programs of the kind. Including a copy of the Lisp interpreter (with source), by L. Peter Deutsch, for the PDP-1.
One thing I would also very much like is to be able to run ITS, the fabled hackers' operating system that ran on the PDP-10. I found the sources, but I don't have a PDP-10 emulator capable of running that thing.
This is plain paranoia. There's no way changes in the microcode could represent a security threat: it's DoS at worse. Something as low-level as microcode has no way of knowing what's going on inside the computer, or draw any useful information from what it sees, let alone communicate it outside.
In any case, loading the microcode, on the Pentium processors, can only take place in real mode (virtual 8086 mode won't do it). Linux runs in protected mode. (Of course, we only have Intel's word on the subject.)
You can also imagine a backdoored network card that occasionally sends a special ethernet frame containing a random page of your physical memory.
If you want to be that paranoid, you can also imagine that there's a back door in gcc. I suggest you read Ken Thompson's excellent Turing Award lecture on the subject, Reflections on Trusting Trust.
Ha, ha, only serious. Yes, I was saying that in a tong-in-cheek way.
For example: the basic problem is that people are dishonest. The Wrong solution is to use passwords and such; the Right Thing would be to make everyone perfect. But I am not Richard Stallman to continue using 'rms' or the empty string as a password because that is the Right Thing. I use passwords even though they are the Wrong Thing. So, obviously, I can only be joking when I make this claim.
Still, it should at least make yourself wonder if there isn't a better way to deter people from cheating, like, try to persuade them that it isn't fun and that it spoils others' pleasure, or ban them if they are caught at it. Or some such thing. I'm not saying it will work, but I think it should at least be considered before jumping to solutions like are being proposed.
In any case, the essential point is that a binary loader just makes it slightly more difficult to cheat. I'm sure someone can easily come up with an (open source?) program that will spoof the loader in a systematic way. (As I pointed out, all it takes is a ptrace().)
``Never let your sense of morals prevent you from doing what is right.'' -- Salvor Hardin
So, let us summarize this:
This is just too obviously bogus. Evidently they are only trying to spread FUD.
They might have had a case against Derek Fawcus, although even that seems dubious. Now that he retracted, they have no case against anyone.
E pur si muove!
...is just something that has never worked, will never work, and cannot work. Every now and then someone tries to use it (the DVD Consortium for example), arguing that ``yes, in general security through obfuscation is bad, but in this particular case it will work''; wrongo: it always fails.
This is made abundantly clear in Bruce Schneier's famous book on cryptography.
This is not an open source vs. proprietary software problem, it is a disclosed source vs. obfuscation problem. This is not an ethical issue, it is a completely practical one, and it seems that the lesson needs to be learned one more time.
Carmack's suggested closed-source binary loader can be spoofed much more easily than by using a proxy. Indeed, it contains an obvious race condition: how is the loader to check that the program hasn't been altered between the time it is checksumed and the time it is run? A simple ptrace() should do the trick for that, and, in fact, anything invented along similar lines.
As another poster pointed out, what we need is to have Quake clients act as simple 2D rendering clients. But that means the server would have to perform all the 3D calculations and that is hopeless. We want the client to perform the calculations without being able to spoof them; so the problem amounts to the following:
(``Computing in `hostile environment' ''). You are given a powerful computer and you want to use it to perform a computation. However, you cannot trust the computer. You want to perform the computation in such a way that the computer should be (a) unable to fool you (i.e. give a wrong answer and make you think it is the right answer), and (b) unable to learn anything from the computation (in the Quake case, learn more than the final, 2D, result). The computer can refuse to carry out the computation, of course, and you cannot prevent this, but it cannot make you think it carried out the computation whereas in fact it is fooling you.
This is a purely theoretical problem, and it has been studied. A cryptologist told me (but was unable to give a reference, unfortunately) that the problem is solved in the theoretical sense: computation in hostile environment is possible (using strong crypto). This makes it theoretically possible to have a solution to the problem using just one secret key, stored on the server and everything else being disclosed (basically: the server sends the encrypted computation to the client, the client performs the computation without knowing what it is calculating, sends it back to the server, the server verifies that the computation was correctly carried out, and sends the decrypted result to the client). Unfortunately, this solution is completely unpractical (the bandwidth required is simply too large).
So, the Right Thing fails. IMHO, this is not, however, an excuse to do the Wrong Thing. If the problem has no solution, then the problem is not a problem!