I would much rather have a talented H1-B person working on Windows than a mediocre U.S. Citizen.
With that attitude, you'll always have mediocre U.S. citizens. You get better through experience and if you need to retain the Americans, you'll be more likely to train them.
Disclaimer: I came in to the US on an H1B back in 1997 and now have permanent residency. My company spent a lot of money advertising for my position but nobody would take it. They then went to Canada to get me.
The whole point of the GP post is there may not be.
If, in the next 5 years, some alternate format offering real benefits came to be and was widely implemented in digital cameras and other devices that use JPEG, it's likely that as a proportion of the number of images stored, usage of JPEG drops. Sooner or later it'll drop so low that it's not worth maintaining the code to read them - and even if it does get maintained, who knows if bugs have been introduced that can't easily be tested for because not enough people have a large archive of JPEGs to test against.
(To be fair, JPEG's a bit of an extreme example, but I'd be happy to bet against Word.doc files being easy to read in 20 years time).
Word isn't easy to read now!:-).
As for JPEGs, it's not that extreme. HD Photo could take off soon, and likely will. From February, 2008:
"The Joint Photographic Experts Group decided earlier this week to officially endorse the Microsoft HD Photo file format as the eventual heir apparent to the JPEG standard. In order to be adopted, the format has lost its vendor-specific name and other Microsoft proprietary controls to ensure universal compatibility. The new format will hence be known as JPEG XR whereby XR stands for eXtended Range.
Microsoft believes that wide-spread use of this file format could begin in about a year."
Assuming that we get bonuses this year, I'm putting it toward a better archival system. Right now, my strategy at home is: make many, many copies, and store them in different places. A tape system would be a nice improvement.
I've got a tape drive at home. A Colorado T3000 that connects to a floppy controller and holds 1.6GB of uncompressed data. Yours if you want to come get it. I think it's about 15 years old. Great archive device with about zero chance of me getting anything off of any of the old media I may have lying around in a fireproof lockbox.
Personally, I'm using a combination of multiple copies of my data in my house (automatic backups via Windows Home Server), daily live backups to the "cloud" (KeepVault) and an occasional off-site copy sitting in my office desk drawer when I remember to bring the drive home and update it.
The people who think that storing a tape drive offsite with their tapes for long-term archival may also get an unpleasant surprise when they come to realize that systems 10 or 20 years from now won't even have the physical interface necessary to connect that tape drive. How many of your systems have a floppy interfaces to connect that T3000?
Your post sums up exactly why a long-term backup is not an archive. I have to explain this to my user community several times per year.
I help manage hundreds of terabytes of storage at work - so many I don't even regularly keep track and don't blink an eye when we place an order for 10-20 additional terabytes. I also helps manage the backups for that data. And get the requests for restores of the form "it was named something like this, existed somewhere around this time, and might have been on this server or in transit to this other server, might have been processed and renamed, but it's really, really important and I need it back in an hour". And why don't we do full backups of everything every day and keep the media onsite forever?
The OP asked for an archive that would span decades. You're referring things like HTML that haven't been around for 2 decades, and let's not even get into the discussion as to how long specific versions have been out - of the 22 elements in the original public specification, only 13 still exist.
You may think VMs are the answer, but they're not. Hardware platforms change. You may not have an x86 VM emulator in 20 years. There aren't good enough emulators for the hardware that was around 20 years ago.
Let history be your lesson. Look at what was out 20 years ago that you can do useful stuff with today. Why should the future be so much different?
JPEGs in 10 years - probably. 30 years? probably not. GIFs, less likely.
Word processing documents? Most formats will not survive.
PostScript? Unlikely to survive - how many people really know how to code in PostScript? I've had professional developers wonder why they send HTML directly to a printer and scream bloody murder when I politely tell them that printers don't do HTML (and seriously, printing HTML from Outlook is not the same thing!).
Pretending a backup is an archive for just data for 5-10 years isn't that hard. Maintaining applications is even harder. Extending it to "decades" is nearly impossible for the average person to accomplish.
Scrap all attempts at native documents and save exclusively in something like PDF or JPEG or TIFF. Yeah, you might have something useful. But you'll lose a lot of intelligence out of the data set, and frankly, the vast majority of users won't do it. They'll save natively and call it a day.
I recently built my own cheap backup server using OpenSolaris and ZFS. I used my old SATA drives (6x400GB), a $75 motherboard and AMD Athlon X2 combo, 4GB of DRAM ($69) and an old tower case. I did add two SATA 5-bay hot-swappable disk bays ($110 each) so that I can easily replace/upgrade my disks. Once a week I update data from my main server (also Solaris) to the backup server using ZFS incremental snapshots.
My PC's and Mac's all mount their user directory from my main server, and I rsync my laptop every day. The main server also serves as a SunRay server so I do most of my daily chores on a SunRay. I run Windows inside VirtualBox and I rarely ever turn on my windows PC anymore (the Windows instance in VBox also mounts from my main server). Inside my main server I have 2x 1TB drives, in a ZFS mirror setup, for the user directories and 2x400GB for the OS and scratch directories (all drives are SATA).
I'm very confident in this setup, also because I can yank out my drives in under 30 seconds in case of fire. The only thing I still have to do is put my backup server in a different room from the main server - that is a todo project for the near future.
Problem 1: If you are not home and your power supply decides to catch fire, you have lost everything.
Problem 2: If you are home, you better be spending those 30 seconds trying to get your butt out of the fire, not running after hard drives.
If you think your DR plan relies on yanking drives out, you're in serious trouble. One B&E or a fire and your data is gone. Now this may be perfectly acceptable to you. It is to a lot of small companies, until it happens to them.
Personally, I vault offsite on a daily basis as well.
Having a tape around for 20 years doesn't do you any good. 20 years ago, I was writing to 1600 and 6250bpi tapes. Today, my data center doesn't even have a drive that can physically read them.
Today's tape technology is no different. 3 years ago was writing to SDLT tapes. By next year, I won't even have an SDLT drive in my data center, having migrated everything over to LTO.
Yeah, I have round tapes in my offsite storage. I have 4mm and DAT tapes out there. We're just wasting money storing the media, since we have nothing that can read them.
If I could read the old media and extract a really old database, would today's database app be able to read it? Probably not. And could I install that app on today's OS? Probably not. And could I install the OS from many years ago on today's hardware? Probably not. Could I compile source from 20 years ago with today's compilers? In many cases, actually I can't. And if it really did all magically get compiled, is anybody around that can still knows how to run the app?
Don't forget that 20 years ago, many systems didn't have TCP/IP installed. In 1988, mine didn't - it was a combination of RS232-attached terminals and XNS-attached graphics workstations. Drive sizes were 80-160MB. A couple of MB of memory was a lot.
For those of you not still in school, ask around and see how many folks in your IT department can name the server that held your financial data 10 years ago.
There is absolutely nothing that you can put away for decades and expect to be useful. Your requirements are not simple - they'll actually very, very hard to meet, even if you want to throw a lot of money at the problem.
You don't know that a jpeg, for example, will be readable in 30 years. The format may be so deprecated that there might not even be a viewer available. Like my old Microsoft Works 4.0 documents - although I have the data, I have nothing that can read them unless I want to spin up an old Windows image, assuming that I can generate a virtualized environment that can support an old Windows (Windows XP probably won't even boot on any PC being produced 30 years from now). And some of that data is only a few years old, not decades old.
You should store not only the data, but also the applications that created the data. And the computer you need to run those applications. And backups of those. And then every few years, pull it all back and validate it and update as required.
You may have only 500GB now, but 10 years from now that will be 5TB. And then you need a way to actually be able to find something you added to your "archive".
I deal with this at work regularly. An archive is not a backup that you keep for a long time. It's much, much more than that. Once you start thinking about all of the issues that come up, you'll see that the media is the least of your problems.
Don't let the fact that this install won't be legal stop you. Pirate.
Just because you can technically do something does not mean that the vendor has granted you permission to do it. You are violating the license agreement if you do this and the copy is no more legal than if you just pirated the whole darn thing. Why even bother paying for an upgrade license if the result is still an illegal installation?
It's much better than that. It's mostly DCL that has the year 9999 issue. For those of you who like history lessons and how to design real operating systems (and customer support, back when it actually existed), read this article:
38 Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?
COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n
LAST TECHNICAL REVIEW: 06-APR-1988
SOURCE: Customer Support Center/Colorado Springs
QUESTION:
Why is Wednesday, November 17, 1858 the base time for VAX/VMS?
ANSWER:
November 17, 1858 is the base of the Modified Julian Day system.
The original Julian Day (JD) is used by astronomers and expressed in days since noon January 1, 4713 B.C. This measure of time was introduced by Joseph Scaliger in the 16th century. It is named in honor of his father, Julius Caesar Scaliger (note that this Julian Day is different from the Julian calendar named for the Roman Emperor Julius Caesar!).
Why 4713 BC? Scaliger traced three time cycles and found that they were all in the first year of their cyle in 4713 B.C. The three cycles are 15, 19, and 28 years long. By multiplying these three numbers (15 * 19 * 28 = 7980), he was able to represent any date from 4713 B.C. through 3267 A.D. The starting year was before any historical event known to him. In fact, the Jewish calendar marks the start of the world as 3761 B.C. Today his numbering scheme is still used by astronomers to avoid the difficulties of converting the months of different calendars in use during different eras.
So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858. The Modified Julian Day uses the following formula:
MJD = JD - 2,400,000.5
The.5 changed when the day starts. Astronomers had considered it more convenient to have their day start at noon so that nighttime observation times fall in the middle. But they changed to conform to the commercial day.
The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser- vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was launched. The Julian day was 2,435,839 on January 1, 1957. This is 11,225,377 in octal notation, which was too big to fit into an 18-bit field (half of its standard 36-bit word). And, with only 8K of memory, no one wanted to waste the 14 bits left over by keeping the Julian Day in its own 36-bit word. However, they also needed to track hours and minutes, for which 18 bits gave enough accuracy. So, they decided to keep the number of days in the left 18 bits and the hours and minutes in the right 18 bits of a word.
Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven centuries. Using only 17 bits, the date could possibly grow only as large as 131,071, but this still covers 3 centuries, as well as leaving the possibility of representing negative time. The year 1858 preceded the oldest star catalog in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations.
This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and VAX/VMS. Given this base date, the 100 nanosecond granularity implemented within VAX/VMS, and the 63-bit absolute time representation (the sign bit must be clear), VMS should have no trouble with time until:
31-JUL-31086 02:48:05.47
At this time, all clocks and time-keeping operations within VMS will suddenly stop, as system time values go negative.
Note that all time display and manipulation routines within VMS allow for only 4 digits within the 'YEAR' field. We expect this to be corrected in a future release of VAX/VMS sometime prior to 31-DEC-9999.
So now sex offenders can't own a TiVo or have to register its use with the parole board and allow them to install monitoring software on it. Ditto for the new HD DVD player. Or your gaming console. Or a new cell phone. Are you going to ban them public libraries too?
I think I see this law as being extremely short-sighted... I don't object to what they're trying to do, but it isn't going to work.
If you want them in jail, put them there. But applying restrictions like these on them isn't going to save anybody.
In Chess, a stalemate is a position such that *NEITHER* side can win. From Wordnet: "a situation in which no progress can be made or no advancement is possible;"
I think the Sony CEO is an idiot - this war *will* be won. By who or when is definitely up for debate, but it *will* be won. Given that he thinks that neither side *can* win suggests that he is no longer trying. He has just conceded..../Ed
You make a good point but forgot to point out that the original article being linked to made no distinction between "corporate Linux" and "community Linux". Whoever posted that to/. simply made that up. And s/he got it very, very wrong..../Ed
My Roomba was great when it worked. It's now been acting as a doorstop for the last 2 months while iRobot tries to find a friggin' battery. Yup, deader than a doornail, they've acknowledged the battery needs to be replaced under warranty, but they keep saying they're back-ordered. They're still selling new ones (and I assume they have batteries) but they're screwing their existing customers. I've recommended the Roomba to a bunch of people that have bought one but am now telling everybody who will listen to avoid the company. Avoid them until they can get their act together!.../Ed
Yeah, but believe it or not, but Windows will prevent you from shooting yourself in the foot better than a standard Linux distro will.
Try rm -Rf / from a bash shell and see if your system is bootable. Try to remove the Windows directory on a Windows XP or 2k3 system and see if your system is bootable.
For those not interested in building virtual machines to prove this, the answers are no and yes in that order.
In the same light, you can't fdisk your boot disk on Windows you can repartition your boot disk on Linux.
We actually ran into this at a Veritas meeting on their Bare Metal Restore product. One user group member had to bork a Solaris system and one a Windows system so Veritas could demo BMR. The sad part was that it actually hard to bork the Windows system.
For quality hardware, 3 years is *NOTHING*. I've got production servers that were purchased in 1996 and are still working fine. My mail servers are in the process of being upgraded, but they're about 5 years old now (when Red Hat Linux 6.1 and 6.2 were current). Good hardware runs almost forever. If you're replacing hardware every 2 years, you're buying junk.
And you can't chroot in ssh (at least in openssh) like you can with just about every FTP server popular today. Let a person at your ssh server and they'll grab your password file (no passwords but they have a list of all valid users on the system), fill/var and/or/tmp, and you're in for a major world of hurt.
Just say no to sftp and ssh servers for untrusted users.
Availability through LULU
on
The New C Standard
·
· Score: 5, Informative
Have you considered making the book available through http://www.lulu.com/? It's a print-on-demand service that allows people an easy way to get a properly bound printed copy of your book, and for you optionally to get some money for your efforts. No cost to you to get set up either.
No, I don't work for lulu or have any financial connections to them. I just know one of the guys that works there (Jeremy Hogan, formerly from Red Hat).
Do they not realize that a mediocre command of written English makes them appear less intelligent? - Only people who hold grammar and language skills in high esteem feel this way, well that or they are pretentious. I have never had anyone other than a teacher or Mr. Ianal on forums point out my spelling/grammar mistakes.
Personally, I don't point out people's poor use of grammar or spelling mistakes. However, I have a tendency to ignore mailing list requests for help from people who refuse to do basic sanity checking on their posts. I have a lot of sympathy for people whose native language is not English but little patience or sympathy from English people who can't figure out if it's "its" or "it's". I almost always ignore people who think they're cool by referring to Microsoft Windows as Winblows or some other derogatory term.
Although your poor English may not result in correction, it may result in you not getting the help when you need it. I've seen procmail rules from other users who feel the same way.
For what it's worth, English is not my native tongue although it's the only language I know today.
If you give some RedHat CDs to a complete goof off and have them install it on a system that is going to be directly exposed to the internet, that box is going to get rooted eventually. It might take longer to get rooted than a Windows box, but it will be cracked.
Actually, if you installed RHEL 3 with all its defaults the day it shipped in October, 2003, it would not yet have been rooted. There have been *ZERO* remotely-exploitable holes in RHEL 3 in its default configuration.
I was responsible for a 6 node VAX cluster that topped out at over 3300 simultaneous interactive users running All-in-1 (e-mail, word processing) and database applications.
Slashdot Mirror
For brevity, a book I once read had this nice farewell "letter": "Upshove job asswards".
It doesn't need to say any more after that...
I would much rather have a talented H1-B person working on Windows than a mediocre U.S. Citizen.
With that attitude, you'll always have mediocre U.S. citizens. You get better through experience and if you need to retain the Americans, you'll be more likely to train them.
Disclaimer: I came in to the US on an H1B back in 1997 and now have permanent residency. My company spent a lot of money advertising for my position but nobody would take it. They then went to Canada to get me.
The whole point of the GP post is there may not be.
If, in the next 5 years, some alternate format offering real benefits came to be and was widely implemented in digital cameras and other devices that use JPEG, it's likely that as a proportion of the number of images stored, usage of JPEG drops. Sooner or later it'll drop so low that it's not worth maintaining the code to read them - and even if it does get maintained, who knows if bugs have been introduced that can't easily be tested for because not enough people have a large archive of JPEGs to test against.
(To be fair, JPEG's a bit of an extreme example, but I'd be happy to bet against Word .doc files being easy to read in 20 years time).
Word isn't easy to read now! :-).
As for JPEGs, it's not that extreme. HD Photo could take off soon, and likely will. From February, 2008:
"The Joint Photographic Experts Group decided earlier this week to officially endorse the Microsoft HD Photo file format as the eventual heir apparent to the JPEG standard. In order to be adopted, the format has lost its vendor-specific name and other Microsoft proprietary controls to ensure universal compatibility. The new format will hence be known as JPEG XR whereby XR stands for eXtended Range.
Microsoft believes that wide-spread use of this file format could begin in about a year."
full article
Assuming that we get bonuses this year, I'm putting it toward a better archival system. Right now, my strategy at home is: make many, many copies, and store them in different places. A tape system would be a nice improvement.
I've got a tape drive at home. A Colorado T3000 that connects to a floppy controller and holds 1.6GB of uncompressed data. Yours if you want to come get it. I think it's about 15 years old. Great archive device with about zero chance of me getting anything off of any of the old media I may have lying around in a fireproof lockbox.
Personally, I'm using a combination of multiple copies of my data in my house (automatic backups via Windows Home Server), daily live backups to the "cloud" (KeepVault) and an occasional off-site copy sitting in my office desk drawer when I remember to bring the drive home and update it.
The people who think that storing a tape drive offsite with their tapes for long-term archival may also get an unpleasant surprise when they come to realize that systems 10 or 20 years from now won't even have the physical interface necessary to connect that tape drive. How many of your systems have a floppy interfaces to connect that T3000?
Your post sums up exactly why a long-term backup is not an archive. I have to explain this to my user community several times per year.
I help manage hundreds of terabytes of storage at work - so many I don't even regularly keep track and don't blink an eye when we place an order for 10-20 additional terabytes. I also helps manage the backups for that data. And get the requests for restores of the form "it was named something like this, existed somewhere around this time, and might have been on this server or in transit to this other server, might have been processed and renamed, but it's really, really important and I need it back in an hour". And why don't we do full backups of everything every day and keep the media onsite forever?
The OP asked for an archive that would span decades. You're referring things like HTML that haven't been around for 2 decades, and let's not even get into the discussion as to how long specific versions have been out - of the 22 elements in the original public specification, only 13 still exist.
You may think VMs are the answer, but they're not. Hardware platforms change. You may not have an x86 VM emulator in 20 years. There aren't good enough emulators for the hardware that was around 20 years ago.
Let history be your lesson. Look at what was out 20 years ago that you can do useful stuff with today. Why should the future be so much different?
JPEGs in 10 years - probably. 30 years? probably not. GIFs, less likely.
Word processing documents? Most formats will not survive.
PostScript? Unlikely to survive - how many people really know how to code in PostScript? I've had professional developers wonder why they send HTML directly to a printer and scream bloody murder when I politely tell them that printers don't do HTML (and seriously, printing HTML from Outlook is not the same thing!).
Pretending a backup is an archive for just data for 5-10 years isn't that hard. Maintaining applications is even harder. Extending it to "decades" is nearly impossible for the average person to accomplish.
Scrap all attempts at native documents and save exclusively in something like PDF or JPEG or TIFF. Yeah, you might have something useful. But you'll lose a lot of intelligence out of the data set, and frankly, the vast majority of users won't do it. They'll save natively and call it a day.
I recently built my own cheap backup server using OpenSolaris and ZFS. I used my old SATA drives (6x400GB), a $75 motherboard and AMD Athlon X2 combo, 4GB of DRAM ($69) and an old tower case. I did add two SATA 5-bay hot-swappable disk bays ($110 each) so that I can easily replace/upgrade my disks. Once a week I update data from my main server (also Solaris) to the backup server using ZFS incremental snapshots.
My PC's and Mac's all mount their user directory from my main server, and I rsync my laptop every day. The main server also serves as a SunRay server so I do most of my daily chores on a SunRay. I run Windows inside VirtualBox and I rarely ever turn on my windows PC anymore (the Windows instance in VBox also mounts from my main server). Inside my main server I have 2x 1TB drives, in a ZFS mirror setup, for the user directories and 2x400GB for the OS and scratch directories (all drives are SATA).
I'm very confident in this setup, also because I can yank out my drives in under 30 seconds in case of fire. The only thing I still have to do is put my backup server in a different room from the main server - that is a todo project for the near future.
Problem 1: If you are not home and your power supply decides to catch fire, you have lost everything.
Problem 2: If you are home, you better be spending those 30 seconds trying to get your butt out of the fire, not running after hard drives.
If you think your DR plan relies on yanking drives out, you're in serious trouble. One B&E or a fire and your data is gone. Now this may be perfectly acceptable to you. It is to a lot of small companies, until it happens to them.
Personally, I vault offsite on a daily basis as well.
Having a tape around for 20 years doesn't do you any good. 20 years ago, I was writing to 1600 and 6250bpi tapes. Today, my data center doesn't even have a drive that can physically read them.
Today's tape technology is no different. 3 years ago was writing to SDLT tapes. By next year, I won't even have an SDLT drive in my data center, having migrated everything over to LTO.
Yeah, I have round tapes in my offsite storage. I have 4mm and DAT tapes out there. We're just wasting money storing the media, since we have nothing that can read them.
If I could read the old media and extract a really old database, would today's database app be able to read it? Probably not. And could I install that app on today's OS? Probably not. And could I install the OS from many years ago on today's hardware? Probably not. Could I compile source from 20 years ago with today's compilers? In many cases, actually I can't. And if it really did all magically get compiled, is anybody around that can still knows how to run the app?
Don't forget that 20 years ago, many systems didn't have TCP/IP installed. In 1988, mine didn't - it was a combination of RS232-attached terminals and XNS-attached graphics workstations. Drive sizes were 80-160MB. A couple of MB of memory was a lot.
For those of you not still in school, ask around and see how many folks in your IT department can name the server that held your financial data 10 years ago.
There is absolutely nothing that you can put away for decades and expect to be useful. Your requirements are not simple - they'll actually very, very hard to meet, even if you want to throw a lot of money at the problem.
You don't know that a jpeg, for example, will be readable in 30 years. The format may be so deprecated that there might not even be a viewer available. Like my old Microsoft Works 4.0 documents - although I have the data, I have nothing that can read them unless I want to spin up an old Windows image, assuming that I can generate a virtualized environment that can support an old Windows (Windows XP probably won't even boot on any PC being produced 30 years from now). And some of that data is only a few years old, not decades old.
You should store not only the data, but also the applications that created the data. And the computer you need to run those applications. And backups of those. And then every few years, pull it all back and validate it and update as required.
You may have only 500GB now, but 10 years from now that will be 5TB. And then you need a way to actually be able to find something you added to your "archive".
I deal with this at work regularly. An archive is not a backup that you keep for a long time. It's much, much more than that. Once you start thinking about all of the issues that come up, you'll see that the media is the least of your problems.
Just because you can technically do something does not mean that the vendor has granted you permission to do it. You are violating the license agreement if you do this and the copy is no more legal than if you just pirated the whole darn thing. Why even bother paying for an upgrade license if the result is still an illegal installation?
> Why would artists need compensating for when people make *legal* copies?
More importantly, why should an artist be compensated when I burn my spreadsheets to a blank CD?
The stupid assumption is that the blank media will be used to store music only. A levy on "data storage" makes no sense at all.
> VMS has been Y10K-compliant for over a decade.
.5 changed when the day starts. Astronomers had considered it more
It's much better than that. It's mostly DCL that has the year 9999 issue. For those of you who like history lessons and how to design real operating systems (and customer support, back when it actually existed), read this article:
38 Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?
COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n
LAST TECHNICAL REVIEW: 06-APR-1988
SOURCE: Customer Support Center/Colorado Springs
QUESTION:
Why is Wednesday, November 17, 1858 the base time for VAX/VMS?
ANSWER:
November 17, 1858 is the base of the Modified Julian Day system.
The original Julian Day (JD) is used by astronomers and expressed in days
since noon January 1, 4713 B.C. This measure of time was introduced by
Joseph Scaliger in the 16th century. It is named in honor of his father,
Julius Caesar Scaliger (note that this Julian Day is different from the
Julian calendar named for the Roman Emperor Julius Caesar!).
Why 4713 BC? Scaliger traced three time cycles and found that they were
all in the first year of their cyle in 4713 B.C. The three cycles are 15,
19, and 28 years long. By multiplying these three numbers (15 * 19 * 28
= 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.
The starting year was before any historical event known to him. In fact,
the Jewish calendar marks the start of the world as 3761 B.C. Today his
numbering scheme is still used by astronomers to avoid the difficulties of
converting the months of different calendars in use during different eras.
So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858.
The Modified Julian Day uses the following formula:
MJD = JD - 2,400,000.5
The
convenient to have their day start at noon so that nighttime observation times
fall in the middle. But they changed to conform to the commercial day.
The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser-
vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites
with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was
launched. The Julian day was 2,435,839 on January 1, 1957. This is
11,225,377 in octal notation, which was too big to fit into an 18-bit field
(half of its standard 36-bit word). And, with only 8K of memory, no one
wanted to waste the 14 bits left over by keeping the Julian Day in its own
36-bit word. However, they also needed to track hours and minutes, for which
18 bits gave enough accuracy. So, they decided to keep the number of days in
the left 18 bits and the hours and minutes in the right 18 bits of a word.
Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as
large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven
centuries. Using only 17 bits, the date could possibly grow only as large as
131,071, but this still covers 3 centuries, as well as leaving the possibility
of representing negative time. The year 1858 preceded the oldest star catalog
in use at SAO, which also avoided having to use negative time in any of the
satellite tracking calculations.
This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and
VAX/VMS. Given this base date, the 100 nanosecond granularity implemented
within VAX/VMS, and the 63-bit absolute time representation (the sign bit must
be clear), VMS should have no trouble with time until:
31-JUL-31086 02:48:05.47
At this time, all clocks and time-keeping operations within VMS will suddenly
stop, as system time values go negative.
Note that all time display and manipulation routines within VMS allow for
only 4 digits within the 'YEAR' field. We expect this to be corrected in
a future release of VAX/VMS sometime prior to 31-DEC-9999.
So now sex offenders can't own a TiVo or have to register its use with the parole board and allow them to install monitoring software on it. Ditto for the new HD DVD player. Or your gaming console. Or a new cell phone. Are you going to ban them public libraries too?
I think I see this law as being extremely short-sighted... I don't object to what they're trying to do, but it isn't going to work.
If you want them in jail, put them there. But applying restrictions like these on them isn't going to save anybody.
http://www.engadget.com/2007/11/30/comcast-ceo-sees-160mbps-internet-in-2008/
See also LightReading:
Comcast Closes In on 100 Mbit/s
Comcast may not be the fastest today, but they don't appear to be sitting around doing nothing either.
In Chess, a stalemate is a position such that *NEITHER* side can win. From Wordnet: "a situation in which no progress can be made or no advancement is possible;"
.../Ed
I think the Sony CEO is an idiot - this war *will* be won. By who or when is definitely up for debate, but it *will* be won. Given that he thinks that neither side *can* win suggests that he is no longer trying. He has just conceded.
You make a good point but forgot to point out that the original article being linked to made no distinction between "corporate Linux" and "community Linux". Whoever posted that to /. simply made that up. And s/he got it very, very wrong. .../Ed
My Roomba was great when it worked. It's now been acting as a doorstop for the last 2 months while iRobot tries to find a friggin' battery. Yup, deader than a doornail, they've acknowledged the battery needs to be replaced under warranty, but they keep saying they're back-ordered. They're still selling new ones (and I assume they have batteries) but they're screwing their existing customers. I've recommended the Roomba to a bunch of people that have bought one but am now telling everybody who will listen to avoid the company. Avoid them until they can get their act together! .../Ed
Yeah, but believe it or not, but Windows will prevent you from shooting yourself in the foot better than a standard Linux distro will.
Try rm -Rf / from a bash shell and see if your system is bootable.
Try to remove the Windows directory on a Windows XP or 2k3 system and see if your system is bootable.
For those not interested in building virtual machines to prove this, the answers are no and yes in that order.
In the same light, you can't fdisk your boot disk on Windows you can repartition your boot disk on Linux.
We actually ran into this at a Veritas meeting on their Bare Metal Restore product. One user group member had to bork a Solaris system and one a Windows system so Veritas could demo BMR. The sad part was that it actually hard to bork the Windows system.
For quality hardware, 3 years is *NOTHING*. I've got production servers that were purchased in 1996 and are still working fine. My mail servers are in the process of being upgraded, but they're about 5 years old now (when Red Hat Linux 6.1 and 6.2 were current). Good hardware runs almost forever. If you're replacing hardware every 2 years, you're buying junk.
And you can't chroot in ssh (at least in openssh) like you can with just about every FTP server popular today. Let a person at your ssh server and they'll grab your password file (no passwords but they have a list of all valid users on the system), fill /var and/or /tmp, and you're in for a major world of hurt.
Just say no to sftp and ssh servers for untrusted users.
Have you considered making the book available through http://www.lulu.com/? It's a print-on-demand service that allows people an easy way to get a properly bound printed copy of your book, and for you optionally to get some money for your efforts. No cost to you to get set up either.
No, I don't work for lulu or have any financial connections to them. I just know one of the guys that works there (Jeremy Hogan, formerly from Red Hat).
Personally, I don't point out people's poor use of grammar or spelling mistakes. However, I have a tendency to ignore mailing list requests for help from people who refuse to do basic sanity checking on their posts. I have a lot of sympathy for people whose native language is not English but little patience or sympathy from English people who can't figure out if it's "its" or "it's". I almost always ignore people who think they're cool by referring to Microsoft Windows as Winblows or some other derogatory term.
Although your poor English may not result in correction, it may result in you not getting the help when you need it. I've seen procmail rules from other users who feel the same way.
For what it's worth, English is not my native tongue although it's the only language I know today.
Actually, if you installed RHEL 3 with all its defaults the day it shipped in October, 2003, it would not yet have been rooted. There have been *ZERO* remotely-exploitable holes in RHEL 3 in its default configuration.
Not only is stupidity not illegal, it can frequently get you elected.
I was responsible for a 6 node VAX cluster that topped out at over 3300 simultaneous interactive users running All-in-1 (e-mail, word processing) and database applications.
You don't need 20 nodes if 6 can do the job.