Oh, dear: I'm very aware of source control systems. "The particular diff tool" should, in my opinion, be considered a part of the source control suite: it's built into the various 'diff' commands built into the source control suite. And even GNU diff's reasonable handling of whitespace was not well incorporated into systems like Subversion until quite recently. (I recently had to spend way too much time with a 1.1.x installation for RHEL 4, with an engineering acquaintance who refuses to upgrade anything "unless he has to".)
Oh, MS-Word would be absolutely horrid. But even in LaTeX, the difference between the printed version and the source code can be quite significant.
I recently saw some five your old code, edited by several different people, each of whom had entirely different settings for their tabs and indenting even opening and closing curly brackets. We had to set up a procedure of "check out the revisions, run them through GNU indent with these settings, and compare _that_" to see their actual changes.
Little things matter. When designing hardware, when building software, getting those little details right helps prevent errors and failures later on. The ranting about the wood screws dominated the original post: failing to correct that would help make anyone else who repeated the rant look like, well, like someone who shouldn't be trusted with a screwdriver.
Getting those details right can help your credibility quite a lot when you fill out a bug report, a blog, or even a letter to family.
The author is apparently not that familiar with screws. "Not being countersunk" has little to do with what type of screw something is. Neither does being a "wood screw" have much to do with bing flush with a surface. It has to do with the screw being "pan-head", and whether the surface has been drilled to allow the screw to fit into it. (That's the 'counter-sunk' part.)
To see if it's a "wood screw", a "machine screw", or a "sheet metal screw", you'd have to see the threads and especially the tip. Wood screws have broadly gapped threads, and a sharp tip, and generally a bit of a taper along their length to the point, designed to gouge themselves into the wood as you screw in but without splitting the wood. Sheet metal screws have closer spaced threads, a sharp tip, and much less taper or none: they're used to screw into soft metal like aluminum and gouge their way in, but you generally have to pre-drill a hole for them. Machine screws have closely spaced threads, no taper, no sharp tip, and require the hole to be pre-threaded to work.
Counter-sinking takes time and a bit of skill to get just right without overdrilling and making the case weak. Merely tapping, or pre-threading is quicker: I can easily believe that a prototype would not be countersunk.
One big problem is that the content would need to be in a consistent format that minimizes the size of diffs, or it will blowup immediately. Line breaks, indentation, page breaks, and other artifacts of formatting need to be ignored to make it intelligible. I'm not aware of any version control system that does this. Is anyone else?
You may not like it: RHEL is several years behind the leading edge of technology, especially for laptops and the latest home gear such as video cards and sound chipsets, and software such as OpenOffice or FireFox. The 'Fedora' testing platform for RedHat is frankly much more usable now due to the significant updates in these components.
But feel free to try it and see what you like: please actually experiment rather than taking my word on Slashdot.
Well, now, that depends on how you use it. POP is just a bad idea in this day and age: its historican inability to handle folders consistently from multiple client locations makes it unusable, along with its tendency for every client to automatically delete _everything_ off of the upstream server when first connected. So if you'd like to flush all your email off of gmail anyway, go ahead, use a POP client. And oh, yes, the adventures to get your POP client to talk to your set of Gmail folders is messy indeed.
IMAP is reasonable, althought the Gmail IMAP access has historically had some odd behavior (like being unwilling to let you not subscribe to the 'Trash' folder). Have they fixed that yet?
Walking in a publicly accessible system is looking around Sourceforge, or reading Slashdot. Breaking into one, poorly secured or not, is going into the privileged access required log files, files, databases, etc. That's not walking in, and you know it.
Once he's in the US, they can add charges. This includes the capital crime of espionage: it's a reason many countries are cautious about extradition to the USA. (This is particularly true of our neighbors in Canada.) But I'll bet it's been a factor in his extradition hearings.
Also, what a person is guilty of is often far more than the charges being made that day in court. For example, the crime you are first charged with can open the doors to get warrants and subpoenas and investigate other crimes. Remember, they got Al Capone for tax evasion, not for being a murdering crime boss. In this case, the US government claims he deleted critical operating system files. And if you've never had to clean up after a cracker, let me tell you, many of them do far, far more damage than they admit, even script kiddies.
You first. I'm not saying it's a good idea. But this is not an innocent person pointing out the security hole, this is someone who themselves used the hole. He's not innocent. Also, if you *break* the lock or even the door on my house, and I need to replace it, I can easily see making you pay for the carpenter to come repair the door and the locks. And I can see making you pay for better locks and doors, to discourage the next idiot from using the same vulnerable-to-attack.
Let's be clear. He didn't walk in a publicly accessible system, he broke into a poorly secured one. That's not an open door, that's a thief committing forced entry.
My dear sir or madam, I myself try to plan regular reboots (once every six months) just to allow kernel updates and hardware tests, especially with so-called "high availability" systems. But my corporate partners rarely see things this way: some of them brag about their 730 day uptimes. But even planned reboots are one of the most likely times for hardware, or creeping software changes, to show up fatally. (That opinion is based on decades of harsh and painful experience.)
It keeps a failure of the network stack from forcing a restart of the filesystems, and vice versa. It also allows the the upgrade of almost all of the drivers without calling for a complete hardware reboot. Hardware reboots are notoriously risky in production environments, especially for systems that haven't had one in several years (which is fairly common on conservatively managed production environments). System reboots are _bad_ in high-reliability or even in normal user environments. What's acceptable in a laptop or desktop environment to upgrade drivers is extremely bad behavior in a most production environments, and are one of the reasons so many production environments have kernels that are woefully, woefully out of date.
Just because a driver is loadable in Linux land doesn't protect the underlying kernel from crashes caused by that driver: I can vouch for that with numerous hardware drivers for all sorts of odd peripherals I've had to deal with over the last 10 years. And please, let's not make *any* claims for anything based on HURD. HURD never worked well enough to make any comparisons between it and anything remotely usable. (I did some work with it 10 years ago and 5 years ago: little has changed, except that the people who might have made it usable turned to Linux and BSD development because there was actually something to work with.)
Let's face it: the more drivers you load, and the more complex they become, the more likely they are to crash catastrophically. It's a living tribute to the Linux kernel developers' quality of code, and to Linus's excellent judgment of what is acceptably stable, that it has so few crashes. But I've had to do various development and integration tasks, and let me say, crashes still happen and endanger production services by taking down _everything_ in their wake.
Also, please note, I'm not saying that microkernels are an overall perfect approach. There are performance advantages of the monolithic kernels, and Linux overall works quite well. But the approach was at least feasible.
He didn't "tell everyone that some houses have a big fucking gap". He was caught rooting around their files, looking for UFO secrets. That's trespass and theft and, due to the federal computers involved, espionage. And he wasn't graceful about it, he caused system disruption doing it and exposed the vulnerabilities to others. So yes, he has considerable responsibility for creating an even bigger risk for those computer owners.
This also provides plenty of fascinating legal grounds for extradition.
I'm afraid that hardware detection may well be required, because critical services (such as NFS exports or MySQL) which rely on mounted partitions in most large-scale environments must have those directories already mounted before running 'exportfs' or before starting the relevant services, or they can create incredible chaos. And the flushing of/tmp/ is tricky: it's much safer to do at a well-defined init step, before the other services are running, and not potentially scrub weird components out from under people. It's not that people shouldn't write these components more sensibly: it's that they don't bother because init scripts are often an afterthought. I suspect you've not personally run into some of the potential adventures of/var/lib/mysql not being mounted when you start the MySQL daemon. It's an adventure.
I completely agree with you about material being in the wrong init levels frequently, and the need for dependency management. (RedHat has some old mistakes in handling wifi devices _after_ network initialization, which causes real chaos.) And forcing network file systems such as NFS or CIFS to wait until the network is running would make complete sense.
> The BIOS - take a look at the LinuxBIOS or OpenBIOS work to see where that can be improved. But oh, my dear goodness, it can be improved. > Incredible masses of new hardware that do need detection and configuration at boot time. That's been a sore point: it takes time to scan for all that hardware, and you can optimize it by leaving out tools, but people do like having their network cards and USB drives and graphics tablets work automatically at boot time. That's not the fault of the kernel: that's the fault of the time taken to detect and configure low-level hardware components, such as RAID controllers, which may be necessary to begin to load _any_ kernel with the actual drivers to run the operating system. > Masses of init scripts starting up many, many, many services in a very lengthy sort of way. Those can be optimized far more than they are, and parallelized: but it takes a rewrite of the 'init' procedures to do so, and that's not the kernel's fault.
I'd like to see all of these improved: all of them are, in fact, plagued by bloat. But they're not hte kernel.
Not exactly. Go take a look at Minix: the kernel itself is _tiny_, and its supported kernel level interfaces, quite few. The result is amazing stability, since the next layer of interactions is in various modules that the kernel can load and reload, that can fail but the kernel remain intact.
Linus rejected this approach a long time ago, for various fairly good reasons. But the Linux kernel is now paying the price.
I will make that conclusion. The Apple sales people I've seen were low key, helped their customers find solutions, and actually listened to their customer's needs to get them the right product, and pushed for quality of components. The PC sales staff I've encountered were frequently in over their heads with the blizzard of subtly incompatible or irrelevant components, far too many versions of PC's with very confusing and all slightly different specifications, and were pushing MS Office and Vista like their jobs depended on it (which they did), even as I struggled to avoid Vista.
This was last weekend, and six months ago, at the local larger computer sales stores. Having to try to sell Vista has been deadly for PC sales people and their ethics.
No, there are many historical reasons Microsoft has its leadership position. It has, in fact, been convicted for many of them.
Active Directory is useful: its management interfaces are very useful for modest size environments. Scaling it down to small shops that can't spare dedicated, expensively licensed servers or scaling it up to large environments that require subtler control and redundancy, however, is extremely painful. Its underlying technologies are all more manageable with a more intelligent database behind it and a superior auto-configuration setup. These components are:
DNS DHCP Kerberos (authentication) LDAP (user account and machine resource management)
That's basically it. And given its lack of sanity checking of its own configurations, the difficulty of scripting its operations, and its mishandling of the addition or re-configuration of new resources, I don't recommend it for large environments.
Oh, my. I remember lawsuits involving Jack Kirby and Marvel of the 1980's, when he was still alive.
For those of you who've not made friends with authors and artists, it's very common for companies to really screw the authors who create their most valuable intellectual properties. For any of us who've worked on a major software or hardware project and had it dropped by a VP whose goals it doesn't fit, or have a mediocre middle manager take credit for it, you can sympathize with what happens to these artists.
This doesn't mean that Jack's heirs have a real case, but be aware that Marvel and Jack had some serious disagreements about intellectual property and artwork ownership during his lifetime, and a lot of artists believed that Jack was screwed, really hard, by Marvel's last generations of leadership during his life.
Oh, my dear fellow, replacing the "bug tracking system selected by the VP to generate pretty charts" is often a social art form of the highest importance and the greatest difficulty. And the manager often has tremendous power to game the system, by deciding what the engineer's priority list or success criteria should be.
And getting the code into that source control and bug tracking system is often a huge project that "the bottom line" doesn't justify, at least in smaller environments. This is especially the case when the manager wrote the original code, and didn't put it in source control, so you can't prove the goofs are theirs. I just saw that happening, in a case I mentioned in another post: the manager's code wasn't under source control to start with, and cleaning up the mess introduced new bugs or tripped over strange, undocumented workarounds that the developer was blamed for.
Unfortunately, the document neglects to mention bad management counter-tactics. I just watched an engineer get guided away from everything productive he did into a "primary focus" of a project to re-write the manager's old project, saw the manager completely ruin the work because it wasn't written exactly the way the manager had done it (which was dangerous stuff, and the point of the project), and block the engineer from closing any other work orders until the primary project was done. The result was that it _killed_ the engineer's productivity on all those little pie charts and project ticket reports, and got him "encouraged to resign". And it kept around that old piece of dirty garbage code, which only that manager knows how to maintain.
I'd love to go directly after the manager for this, but it's hard. The manager knows how to play the paperwork game and the blame game and I'm not even from his company. It won't help the engineer much: I've written him recommendations and am trying to guide him to better work, but the field is still not hiring much.
I went down the current list of comments, and for all the people who write their own rsync tools, please go review 'rsnapshot'. It's quite efficient: it's major flaw is that it lists snapshots as 'hostname.1', 'hostname.2', etc., instead of 'hostname.YYYYMMDD', which would ease things for users grabbing their own old files from online.
Slashdot Mirror
Oh, dear: I'm very aware of source control systems. "The particular diff tool" should, in my opinion, be considered a part of the source control suite: it's built into the various 'diff' commands built into the source control suite. And even GNU diff's reasonable handling of whitespace was not well incorporated into systems like Subversion until quite recently. (I recently had to spend way too much time with a 1.1.x installation for RHEL 4, with an engineering acquaintance who refuses to upgrade anything "unless he has to".)
Oh, MS-Word would be absolutely horrid. But even in LaTeX, the difference between the printed version and the source code can be quite significant.
I recently saw some five your old code, edited by several different people, each of whom had entirely different settings for their tabs and indenting even opening and closing curly brackets. We had to set up a procedure of "check out the revisions, run them through GNU indent with these settings, and compare _that_" to see their actual changes.
Little things matter. When designing hardware, when building software, getting those little details right helps prevent errors and failures later on. The ranting about the wood screws dominated the original post: failing to correct that would help make anyone else who repeated the rant look like, well, like someone who shouldn't be trusted with a screwdriver.
Getting those details right can help your credibility quite a lot when you fill out a bug report, a blog, or even a letter to family.
The author is apparently not that familiar with screws. "Not being countersunk" has little to do with what type of screw something is. Neither does being a "wood screw" have much to do with bing flush with a surface. It has to do with the screw being "pan-head", and whether the surface has been drilled to allow the screw to fit into it. (That's the 'counter-sunk' part.)
To see if it's a "wood screw", a "machine screw", or a "sheet metal screw", you'd have to see the threads and especially the tip. Wood screws have broadly gapped threads, and a sharp tip, and generally a bit of a taper along their length to the point, designed to gouge themselves into the wood as you screw in but without splitting the wood. Sheet metal screws have closer spaced threads, a sharp tip, and much less taper or none: they're used to screw into soft metal like aluminum and gouge their way in, but you generally have to pre-drill a hole for them. Machine screws have closely spaced threads, no taper, no sharp tip, and require the hole to be pre-threaded to work.
Counter-sinking takes time and a bit of skill to get just right without overdrilling and making the case weak. Merely tapping, or pre-threading is quicker: I can easily believe that a prototype would not be countersunk.
One big problem is that the content would need to be in a consistent format that minimizes the size of diffs, or it will blowup immediately. Line breaks, indentation, page breaks, and other artifacts of formatting need to be ignored to make it intelligible. I'm not aware of any version control system that does this. Is anyone else?
You may not like it: RHEL is several years behind the leading edge of technology, especially for laptops and the latest home gear such as video cards and sound chipsets, and software such as OpenOffice or FireFox. The 'Fedora' testing platform for RedHat is frankly much more usable now due to the significant updates in these components.
But feel free to try it and see what you like: please actually experiment rather than taking my word on Slashdot.
With 3 bras on, all with significant amounts of gas-blocking filter material? I'd look "endowed" too.
But did anyone else watching the sword swallower shout out to their computer display "Don't hiccup!"?
Well, now, that depends on how you use it. POP is just a bad idea in this day and age: its historican inability to handle folders consistently from multiple client locations makes it unusable, along with its tendency for every client to automatically delete _everything_ off of the upstream server when first connected. So if you'd like to flush all your email off of gmail anyway, go ahead, use a POP client. And oh, yes, the adventures to get your POP client to talk to your set of Gmail folders is messy indeed.
IMAP is reasonable, althought the Gmail IMAP access has historically had some odd behavior (like being unwilling to let you not subscribe to the 'Trash' folder). Have they fixed that yet?
"Well, if you don't trust the machine you're working on, you shouldn't be using it."
[ quote from Subversion developers about their practice of storing passwords locally in clear-text ]
Walking in a publicly accessible system is looking around Sourceforge, or reading Slashdot. Breaking into one, poorly secured or not, is going into the privileged access required log files, files, databases, etc. That's not walking in, and you know it.
Once he's in the US, they can add charges. This includes the capital crime of espionage: it's a reason many countries are cautious about extradition to the USA. (This is particularly true of our neighbors in Canada.) But I'll bet it's been a factor in his extradition hearings.
Also, what a person is guilty of is often far more than the charges being made that day in court. For example, the crime you are first charged with can open the doors to get warrants and subpoenas and investigate other crimes. Remember, they got Al Capone for tax evasion, not for being a murdering crime boss. In this case, the US government claims he deleted critical operating system files. And if you've never had to clean up after a cracker, let me tell you, many of them do far, far more damage than they admit, even script kiddies.
You first. I'm not saying it's a good idea. But this is not an innocent person pointing out the security hole, this is someone who themselves used the hole. He's not innocent. Also, if you *break* the lock or even the door on my house, and I need to replace it, I can easily see making you pay for the carpenter to come repair the door and the locks. And I can see making you pay for better locks and doors, to discourage the next idiot from using the same vulnerable-to-attack.
Let's be clear. He didn't walk in a publicly accessible system, he broke into a poorly secured one. That's not an open door, that's a thief committing forced entry.
My dear sir or madam, I myself try to plan regular reboots (once every six months) just to allow kernel updates and hardware tests, especially with so-called "high availability" systems. But my corporate partners rarely see things this way: some of them brag about their 730 day uptimes. But even planned reboots are one of the most likely times for hardware, or creeping software changes, to show up fatally. (That opinion is based on decades of harsh and painful experience.)
It keeps a failure of the network stack from forcing a restart of the filesystems, and vice versa. It also allows the the upgrade of almost all of the drivers without calling for a complete hardware reboot. Hardware reboots are notoriously risky in production environments, especially for systems that haven't had one in several years (which is fairly common on conservatively managed production environments). System reboots are _bad_ in high-reliability or even in normal user environments. What's acceptable in a laptop or desktop environment to upgrade drivers is extremely bad behavior in a most production environments, and are one of the reasons so many production environments have kernels that are woefully, woefully out of date.
Just because a driver is loadable in Linux land doesn't protect the underlying kernel from crashes caused by that driver: I can vouch for that with numerous hardware drivers for all sorts of odd peripherals I've had to deal with over the last 10 years. And please, let's not make *any* claims for anything based on HURD. HURD never worked well enough to make any comparisons between it and anything remotely usable. (I did some work with it 10 years ago and 5 years ago: little has changed, except that the people who might have made it usable turned to Linux and BSD development because there was actually something to work with.)
Let's face it: the more drivers you load, and the more complex they become, the more likely they are to crash catastrophically. It's a living tribute to the Linux kernel developers' quality of code, and to Linus's excellent judgment of what is acceptably stable, that it has so few crashes. But I've had to do various development and integration tasks, and let me say, crashes still happen and endanger production services by taking down _everything_ in their wake.
Also, please note, I'm not saying that microkernels are an overall perfect approach. There are performance advantages of the monolithic kernels, and Linux overall works quite well. But the approach was at least feasible.
He didn't "tell everyone that some houses have a big fucking gap". He was caught rooting around their files, looking for UFO secrets. That's trespass and theft and, due to the federal computers involved, espionage. And he wasn't graceful about it, he caused system disruption doing it and exposed the vulnerabilities to others. So yes, he has considerable responsibility for creating an even bigger risk for those computer owners.
This also provides plenty of fascinating legal grounds for extradition.
I'm afraid that hardware detection may well be required, because critical services (such as NFS exports or MySQL) which rely on mounted partitions in most large-scale environments must have those directories already mounted before running 'exportfs' or before starting the relevant services, or they can create incredible chaos. And the flushing of /tmp/ is tricky: it's much safer to do at a well-defined init step, before the other services are running, and not potentially scrub weird components out from under people. It's not that people shouldn't write these components more sensibly: it's that they don't bother because init scripts are often an afterthought. I suspect you've not personally run into some of the potential adventures of /var/lib/mysql not being mounted when you start the MySQL daemon. It's an adventure.
I completely agree with you about material being in the wrong init levels frequently, and the need for dependency management. (RedHat has some old mistakes in handling wifi devices _after_ network initialization, which causes real chaos.) And forcing network file systems such as NFS or CIFS to wait until the network is running would make complete sense.
What? No, that's not the kernel. That is:
> The BIOS - take a look at the LinuxBIOS or OpenBIOS work to see where that can be improved. But oh, my dear goodness, it can be improved.
> Incredible masses of new hardware that do need detection and configuration at boot time. That's been a sore point: it takes time to scan for all that hardware, and you can optimize it by leaving out tools, but people do like having their network cards and USB drives and graphics tablets work automatically at boot time. That's not the fault of the kernel: that's the fault of the time taken to detect and configure low-level hardware components, such as RAID controllers, which may be necessary to begin to load _any_ kernel with the actual drivers to run the operating system.
> Masses of init scripts starting up many, many, many services in a very lengthy sort of way. Those can be optimized far more than they are, and parallelized: but it takes a rewrite of the 'init' procedures to do so, and that's not the kernel's fault.
I'd like to see all of these improved: all of them are, in fact, plagued by bloat. But they're not hte kernel.
Not exactly. Go take a look at Minix: the kernel itself is _tiny_, and its supported kernel level interfaces, quite few. The result is amazing stability, since the next layer of interactions is in various modules that the kernel can load and reload, that can fail but the kernel remain intact.
Linus rejected this approach a long time ago, for various fairly good reasons. But the Linux kernel is now paying the price.
I will make that conclusion. The Apple sales people I've seen were low key, helped their customers find solutions, and actually listened to their customer's needs to get them the right product, and pushed for quality of components. The PC sales staff I've encountered were frequently in over their heads with the blizzard of subtly incompatible or irrelevant components, far too many versions of PC's with very confusing and all slightly different specifications, and were pushing MS Office and Vista like their jobs depended on it (which they did), even as I struggled to avoid Vista.
This was last weekend, and six months ago, at the local larger computer sales stores. Having to try to sell Vista has been deadly for PC sales people and their ethics.
No, there are many historical reasons Microsoft has its leadership position. It has, in fact, been convicted for many of them.
Active Directory is useful: its management interfaces are very useful for modest size environments. Scaling it down to small shops that can't spare dedicated, expensively licensed servers or scaling it up to large environments that require subtler control and redundancy, however, is extremely painful. Its underlying technologies are all more manageable with a more intelligent database behind it and a superior auto-configuration setup. These components are:
DNS
DHCP
Kerberos (authentication)
LDAP (user account and machine resource management)
That's basically it. And given its lack of sanity checking of its own configurations, the difficulty of scripting its operations, and its mishandling of the addition or re-configuration of new resources, I don't recommend it for large environments.
Oh, my. I remember lawsuits involving Jack Kirby and Marvel of the 1980's, when he was still alive.
For those of you who've not made friends with authors and artists, it's very common for companies to really screw the authors who create their most valuable intellectual properties. For any of us who've worked on a major software or hardware project and had it dropped by a VP whose goals it doesn't fit, or have a mediocre middle manager take credit for it, you can sympathize with what happens to these artists.
This doesn't mean that Jack's heirs have a real case, but be aware that Marvel and Jack had some serious disagreements about intellectual property and artwork ownership during his lifetime, and a lot of artists believed that Jack was screwed, really hard, by Marvel's last generations of leadership during his life.
Oh, my dear fellow, replacing the "bug tracking system selected by the VP to generate pretty charts" is often a social art form of the highest importance and the greatest difficulty. And the manager often has tremendous power to game the system, by deciding what the engineer's priority list or success criteria should be.
And getting the code into that source control and bug tracking system is often a huge project that "the bottom line" doesn't justify, at least in smaller environments. This is especially the case when the manager wrote the original code, and didn't put it in source control, so you can't prove the goofs are theirs. I just saw that happening, in a case I mentioned in another post: the manager's code wasn't under source control to start with, and cleaning up the mess introduced new bugs or tripped over strange, undocumented workarounds that the developer was blamed for.
Unfortunately, the document neglects to mention bad management counter-tactics. I just watched an engineer get guided away from everything productive he did into a "primary focus" of a project to re-write the manager's old project, saw the manager completely ruin the work because it wasn't written exactly the way the manager had done it (which was dangerous stuff, and the point of the project), and block the engineer from closing any other work orders until the primary project was done. The result was that it _killed_ the engineer's productivity on all those little pie charts and project ticket reports, and got him "encouraged to resign". And it kept around that old piece of dirty garbage code, which only that manager knows how to maintain.
I'd love to go directly after the manager for this, but it's hard. The manager knows how to play the paperwork game and the blame game and I'm not even from his company. It won't help the engineer much: I've written him recommendations and am trying to guide him to better work, but the field is still not hiring much.
I went down the current list of comments, and for all the people who write their own rsync tools, please go review 'rsnapshot'. It's quite efficient: it's major flaw is that it lists snapshots as 'hostname.1', 'hostname.2', etc., instead of 'hostname.YYYYMMDD', which would ease things for users grabbing their own old files from online.
Youngsters. You don't _smoke_ magic dust. You drip it into sugar cubes.
Those of us who remember products from the 1970's unfortunately now have to watch our waist lines a lot more than we used to back then.