a 30" tv that had been on in the room at the time now exhibits _severe_ orange and green casts all the way out to the corners of the crt
Aha!
A couple months after moving into our present place we had a lightning induced surge that tripped all the GFIs, fried a couple of phones and zapped my wife's computer mobo and internal modem. Also the garage door opener.
Around that same time, I noticed a magnetized area on the screen of an old 26" TV monitor that we only occasionally use. I never made the connection, I'd assumed that the move might have messed it up. But yeah, could have been the EMP.
(BTW, I managed to "sweep" the magnetized area to one corner of the screen with a permanent magnet. One day Real Soon Now I'll put together a degaussing coil and do a proper job.)
this indicated power/voltage/whatever was 'bleeding' from the powerlines.
Heh, you want to see power bleeding from the powerlines, check out the transmission lines alongside US 1 in the Florida Keys. (My in-laws have a place down there).
Partly due to the moisture in the air, and the salt buildup on the insulators, and for all I know they're running the lines something above original design voltage to get power to Key West, but if it's quiet you can hear the crackle, and at night you can see 6-inch (at least) sparks streaming off the lines at the insulators just like a mini Tesla coil. I hate to think how many kilowatts are being wasted that way along the length of the line.
...the cost of the wasted effort down the wrong path.
For example, if you get a requirement wrong and spend X developer-months designing and coding a subsystem around that requirement, the cost to fix it includes that already sunk cost plus the cost of reworking the design and code to make it conform to what the spec should have said.
Or consider the case where section II.3.iv of the spec conflicts utterly with the requirements detailed in section IV.2.iii. If you don't catch that early (and assuming its a large project, given the size of the specs), you'll have two different subproject teams off designing, coding and testing to cross purposes and you'll only discover the problem at integration time.
Sure, some requirements or design bugs are trivial to fix even after coding is almost complete (you got the color of some GUI feature wrong, say). Others aren't (you missed some key requirement that radically affects the way the data should be represented and you have to change all your data structures and database tables).
I can detoxify chemical waste in a variety of ways which make it far less hazardous (insoluble arsenic salts, for example)
Fine. You eat a spoonful of "insoluble arsenic salts". We'll see how long you last.
Organics can be incinerated at very high temperatures;
Requiring yet more coal?
With radioactive isotopes
Which are also present in coal ash and flue gases. Aside from obvious stuff like radon and potassium-40, coal also contains uranium-235 and 238, polonium-210, lead-210, and thorium-232. (See this article, or this note for example.) In fact the energy content of the uranium and thorium in coal is greater than the energy you get by burning it.
plutonium, for example, in a soluble form, is the most toxic element known to man
I'm inclined to doubt that, although it may be literally true as far as elements go, but there are far more toxic substances -- most of them organic -- botulism toxin, for one (yeah, the stuff in botox).
- in insoluble form, it is still bad via emission of gamma rays
Nope, plutonium emits alpha particles, not gamma rays. Relatively harmless -- they're stopped by the layer of dead cells on your skin -- unless the plutonium gets into your lungs or bloodstream.
Okay, that may have been the case, but it wasn't the major problem. The melted fuel was puddling in the bottom of the building. I don't know if it was designed for that the way North American containment buildings are, but it still wasn't getting out into the surrounding environment.
The fact that the core was also on fire was a major problem, in that it was spewing highly radioactive smoke and ash all over the landscape. (It also made trying to get the thing under control a lot harder.)
The failed reactor at Chernobyl was spilling molten fuel out of ruptured cooling bulkheads.
Nope. The Chernobyl reactor caught fire. It used a graphite moderator (a design not used in the US) which caught fire when the coolant water boiled down low enough to expose it to air. The Chernobyl design was basically an accident waiting to happen -- it was actually worse than a meltdown. (In a meltdown you're left with a pool of radioactive metal that's no longer critical all over the floor of the containment building.)
He means that the amount of radioactive waste produced by a nuclear plant is less than the amount of radioactive waste produced by a coal-fired plant of equivalent power output.
And yes, coal is normally not considered radioactive. But it does contain traces of radioactive material, both in the coal itself and as waste rock from the mining process that isn't entirely separated. Not very much, of course -- but it takes thousands and thousands of tons of coal to produce the same power as a few pounds of uranium.
Of course, all radioactive waste eventually decays. We haven't even touched on the other stuff in coal ash that's highly toxic (like arsenic) that never decays.
I'll happily store the waste from the nuclear generated power I use in my backyard if you'll store the ash from the coal generated power you use in yours.
In a worst case scenario with a nuclear powerplant, we're talking about, what, 50,000 years until it's safe again?
Nothing like that. Heck, people still live in Hiroshima and Nagasaki, which were subjected to far worse than what a nuclear powerplant would do. (Although it's possible that cancer incidence is still slightly higher there -- lots less than the equivalent risk from, say, smoking tobacco.)
Chernobyl was just about the worst case scenario for a nuclear plant -- and that was a really stupid design with a positive void coefficient and a graphite moderator -- which caught fire when the cooling water boiled away. Chernobyl still isn't the best place to hang out for very long, but there are other places that can be naturally more dangerous (such as downhill from a lake that occasionally bubbles toxic gases, such as the one that wiped out a village in Africa some years ago, or the valleys in geologically active regions that can collect lethal levels of sulfide gases and kill the occasional unwary hiker, and so on.)
Oh, and as for "Nuklear Power plant has a jet that flies into it.", in the US and Canada at least (and probably most other places), the result is a flattened jet and maybe a few scratches and scorch marks on the (many feet thick, reinforced, densified) concrete of the containment building.
There's some performance penalty for microkernels, because you do more copying. But it pales in comparison with the penalties associated with Perl, Java, PHP, VB, etc.
Which is why kernels aren't written in Perl, Java, PHP or VB.
If someone chooses to improve development time by incurring the overhead of the languages mentioned, that's their choice (and with most interactive apps, it won't matter). Slowing down the kernel, though, is like underclocking your CPU -- it will affect everything -- including how fast those interpreted languages receive data and events to act on.
(And arguably, with Linux's loadable modules for everything from filesystems to device drivers, it's got many of the benefits of a microkernel system anyway.)
Back in the 1980s, DARPA was very unhappy with BSD because it crashed.
If you're talking about 4.2, could be. A lot of new stuff was thrown into that version. I didn't use it that much because my project moved off of a share of the VAX at about the 4.1 to 4.2 transition (onto, in succession, a PDP-11 running 2.x BSD, then System III, then a UTS partition on an IBM 3090, then Arix on a 68K-based multiprocessor box.)
If the Mach effort had come out better, UNIX history could have been quit different.
If Mach had come out better, it wouldn't have been a (quasi-) microkernel. You've no doubt read the famous exchange between Torvalds and Tannenbaum in which Linus argues that a microkernel is a bad idea for a real-world OS kernel. I'm inclined to agree with him. What successes has Mach had? NeXT, MkLinux, and now Mac OS X -- all limited, and two of those under the guidance of Avie Tevanian (who helped write it in the first place) and the backing of Steve Jobs' Reality Distortion Field. Oh, the HURD is microkernel based too, isn't it? 'Nuff said.
(OTOH, DARPA had a point. 4.2BSD was getting downright Baroque. See the keynote speech at the '86 (I think, maybe '85) Usenix.)
Yes, I know NT has been steadily copying commands and utilities from the Unix world. There are still millions of installed Windows systems out there that don't support them.
A shame, really, since there's no good reason why not. Microsoft programmers have certainly been aware of them since the very first DOS days (Microsoft's first OS was XENIX, after all), and even DOS (let alone NT) could have supported a more useful shell and basic utilities -- plenty of third parties provided such, after all. (Cygwin was hardly the first, just free.)
All part of the Microsoft primary design criterion ("what can we do to lock in the customer"), I guess.
Quite correct that mkisofs and cdrecord are Unix utilities. But they are easily invoked from the command line in a script, with no additional user interaction, no GUI needed. Most Windows apps insist on opening a GUI when started, and very seldom confine themselves to just one function (ie they'll roll the functionality of both mkisofs and cdrecord -- and perhaps a few others -- into a single app).
As ESR notes in the book, some of this is a natural result of the fact that process creation under VMS, er, Windows NT (and successors) is expensive, so programs tend to be monolithic (and occasionally internally scriptable), whereas Unix style is to separate out the functionality ('nix process creation is cheap) and use the shell to script things.
The latter is far more flexible. I can write my own program and it's easy to plug into a shell script. Writing a plug-in module for a Windows app that is then scriptable within that app is much harder, if even possible at all (depends on the app).
The difference between scripting MS Office and running a shell script is who is interpreting the script, and how easy is it to add functionality. Sure, strictly speaking the shell is an app too, but 'sh' is universally available on 'nix systems, so it's essentially part of the OS, which is not true of Office on Windows. (Now, if you could write equivalently powerful scripts in IE, you might have a point. You'd also be deeply vulnerable to every malicious URL out there. Oh, wait...)
That's still irrelevant to the original point regarding the power of the native command line interface language.
The difference is important. Someone using the CLI on Unix will have to learn almost nothing new to create a useful script. The best someone using the CLI interface on Windows can do is create a.bat file, which has nowhere near the capability of even the original Bourne shell let alone a more modern variant like Bash.
Granted, the "average user" uses the GUI far more than the CLI, but this gets far away from the original point of the comparison of Unix vs Windows for casual programmers. Look at all the things that shell scripts get used for in the average Unix/Linux system, now try to do that stuff in the Windows CLI. (I know, there are other tools to do that, just as on Unix. But the original point was the expressiveness of the native command line language.)
Not at all. There's a difference between scripting applications and scripting with applications. In the latter, the apps act as simply additional verbs in the scripting language, just as do function calls in a programming language. The only thing passed is command line arguments.
Tell me, how useful are command line arguments to word.exe?
.BAT are very limited and the syntax is ugly. Use.VBS instead
This is true, but the point was a comparison of the native CLI as a scripting language (.bat vs.sh), not what you could do with some other scripting language. I can get Perl and Tk and Python (oh my!) for Windows too, but that misses the point.
The Berkeley TCP/IP implementation wasn't the first for UNIX.
And nowhere in the paragraph you quoted does it say that it was. Nice strawman you set up there, but you could have bragged on your rewrite of UNET without it.
You're clearly confused. MS Office and OpenOffice are applications, not operating systems.
Can you, for example, write a Windows script (ie, DOS.bat program) to say, take a directory full of text files, make some simple text edits on all the files, write those to a new folder, and then create a CD-ROM with an ISO image of that folder? It's just a few lines of shell script on Unix/Linux. (Most distros include mkisofs and cdrecord as standard utilities.)
I forget who made the compiler -- I'm sure I still have it buried in a box somewhere -- but talk about s-l-o-w compiling off that 1541 floppy drive.
However, for hardware hacking you couldn't beat the VIC-20, especially when the price dropped to under $99. I used one of those to wire up a friend's photoelectric photometry observatory (15" scope). Ripped apart a potentiometer and mechanically attached it to the filter wheel to read its position (via the analog port), wired a selector switch to the joystick inputs (to specify whether the reading was of dark sky, the object of interest, or a reference object), and then ran a cable from the VIC from the observatory to the house where it pretended to be a keyboard on the Apple II that was actually logging the data (and was connected to the photon counter).
Another time I wired outputs to the motor controls of a toy tank, controlled by the joystick inputs, and put a 2.8 second delay in with a simple Basic program to simulate the delay in teleoperating something on the Moon. This was for some Space Day event. Interstingly, the older folks and very young kids adapted to the delay pretty easily. The preteens and teens, with their videogame tuned reflexes, couldn't get the hang of it.
Heh. I occasionally (very occasionally) run the DOS "Q&A" database -- on the SoftPC emulator on my Mac. I think the last time was two years ago when we looked up what my wife's sister gave us as a wedding present (back in '89, when it was running on a 286) so we could return the favor;-)
I've still got a 5.25" floppy drive from that old 286 machine (circa 1986 or 1987) running in my dual P-III linux box; I installed it to read some floppies.
Mind, I've never thrown any of the hardware out. I've still got my KIM-1 down in the workshop, but it hasn't been powered up in over a decade. (Mine's not as pretty as the picture, it's covered in jumper wires for the "TV Typewriter" I added).
The Romans had the abacus too. It may even have been invented there and moved east.
Take a look at Roman numerals and reflect upon how they're exactly how you'd represent the numbers on an abacus. Some people deride Roman numerals as being impossibly hard to do arithmetic with -- on the contrary, they make it very easy to use an abacus with.
You may recognize the last two. The first three, and some others I don't remember, I added to the Adventure game running on the campus mainframe back when. (The inspiration was a comment in some computer magazine.) Actually useful to help map the maze of twisty little passages, all alike, but that's about it (no points).
Actually it was the SUID bit. And the patent actually managed to describe it as though it could be a mechanical contrivance. (They just didn't do software patents in those days.)
Bell Labs released the patent to the public domain.
Slashdot Mirror
a 30" tv that had been on in the room at the time now exhibits _severe_ orange and green casts all the way out to the corners of the crt
Aha!
A couple months after moving into our present place we had a lightning induced surge that tripped all the GFIs, fried a couple of phones and zapped my wife's computer mobo and internal modem. Also the garage door opener.
Around that same time, I noticed a magnetized area on the screen of an old 26" TV monitor that we only occasionally use. I never made the connection, I'd assumed that the move might have messed it up. But yeah, could have been the EMP.
(BTW, I managed to "sweep" the magnetized area to one corner of the screen with a permanent magnet. One day Real Soon Now I'll put together a degaussing coil and do a proper job.)
this indicated power/voltage/whatever was 'bleeding' from the powerlines.
Heh, you want to see power bleeding from the powerlines, check out the transmission lines alongside US 1 in the Florida Keys. (My in-laws have a place down there).
Partly due to the moisture in the air, and the salt buildup on the insulators, and for all I know they're running the lines something above original design voltage to get power to Key West, but if it's quiet you can hear the crackle, and at night you can see 6-inch (at least) sparks streaming off the lines at the insulators just like a mini Tesla coil. I hate to think how many kilowatts are being wasted that way along the length of the line.
...the cost of the wasted effort down the wrong path.
For example, if you get a requirement wrong and spend X developer-months designing and coding a subsystem around that requirement, the cost to fix it includes that already sunk cost plus the cost of reworking the design and code to make it conform to what the spec should have said.
Or consider the case where section II.3.iv of the spec conflicts utterly with the requirements detailed in section IV.2.iii. If you don't catch that early (and assuming its a large project, given the size of the specs), you'll have two different subproject teams off designing, coding and testing to cross purposes and you'll only discover the problem at integration time.
Sure, some requirements or design bugs are trivial to fix even after coding is almost complete (you got the color of some GUI feature wrong, say). Others aren't (you missed some key requirement that radically affects the way the data should be represented and you have to change all your data structures and database tables).
Okay, I should have said "a design no longer used in the US".
MS is trying hard to reinvent Unix
I think you just made my point.
I can detoxify chemical waste in a variety of ways which make it far less hazardous (insoluble arsenic salts, for example)
Fine. You eat a spoonful of "insoluble arsenic salts". We'll see how long you last.
Organics can be incinerated at very high temperatures;
Requiring yet more coal?
With radioactive isotopes
Which are also present in coal ash and flue gases. Aside from obvious stuff like radon and potassium-40, coal also contains uranium-235 and 238, polonium-210, lead-210, and thorium-232. (See this article, or this note for example.) In fact the energy content of the uranium and thorium in coal is greater than the energy you get by burning it.
plutonium, for example, in a soluble form, is the most toxic element known to man
I'm inclined to doubt that, although it may be literally true as far as elements go, but there are far more toxic substances -- most of them organic -- botulism toxin, for one (yeah, the stuff in botox).
- in insoluble form, it is still bad via emission of gamma rays
Nope, plutonium emits alpha particles, not gamma rays. Relatively harmless -- they're stopped by the layer of dead cells on your skin -- unless the plutonium gets into your lungs or bloodstream.
Okay, that may have been the case, but it wasn't the major problem. The melted fuel was puddling in the bottom of the building. I don't know if it was designed for that the way North American containment buildings are, but it still wasn't getting out into the surrounding environment.
The fact that the core was also on fire was a major problem, in that it was spewing highly radioactive smoke and ash all over the landscape. (It also made trying to get the thing under control a lot harder.)
The failed reactor at Chernobyl was spilling molten fuel out of ruptured cooling bulkheads.
Nope. The Chernobyl reactor caught fire. It used a graphite moderator (a design not used in the US) which caught fire when the coolant water boiled down low enough to expose it to air. The Chernobyl design was basically an accident waiting to happen -- it was actually worse than a meltdown. (In a meltdown you're left with a pool of radioactive metal that's no longer critical all over the floor of the containment building.)
He means that the amount of radioactive waste produced by a nuclear plant is less than the amount of radioactive waste produced by a coal-fired plant of equivalent power output.
And yes, coal is normally not considered radioactive. But it does contain traces of radioactive material, both in the coal itself and as waste rock from the mining process that isn't entirely separated. Not very much, of course -- but it takes thousands and thousands of tons of coal to produce the same power as a few pounds of uranium.
Of course, all radioactive waste eventually decays. We haven't even touched on the other stuff in coal ash that's highly toxic (like arsenic) that never decays.
I'll happily store the waste from the nuclear generated power I use in my backyard if you'll store the ash from the coal generated power you use in yours.
In a worst case scenario with a nuclear powerplant, we're talking about, what, 50,000 years until it's safe again?
Nothing like that. Heck, people still live in Hiroshima and Nagasaki, which were subjected to far worse than what a nuclear powerplant would do. (Although it's possible that cancer incidence is still slightly higher there -- lots less than the equivalent risk from, say, smoking tobacco.)
Chernobyl was just about the worst case scenario for a nuclear plant -- and that was a really stupid design with a positive void coefficient and a graphite moderator -- which caught fire when the cooling water boiled away. Chernobyl still isn't the best place to hang out for very long, but there are other places that can be naturally more dangerous (such as downhill from a lake that occasionally bubbles toxic gases, such as the one that wiped out a village in Africa some years ago, or the valleys in geologically active regions that can collect lethal levels of sulfide gases and kill the occasional unwary hiker, and so on.)
Oh, and as for "Nuklear Power plant has a jet that flies into it.", in the US and Canada at least (and probably most other places), the result is a flattened jet and maybe a few scratches and scorch marks on the (many feet thick, reinforced, densified) concrete of the containment building.
There's some performance penalty for microkernels, because you do more copying. But it pales in comparison with the penalties associated with Perl, Java, PHP, VB, etc.
Which is why kernels aren't written in Perl, Java, PHP or VB.
If someone chooses to improve development time by incurring the overhead of the languages mentioned, that's their choice (and with most interactive apps, it won't matter). Slowing down the kernel, though, is like underclocking your CPU -- it will affect everything -- including how fast those interpreted languages receive data and events to act on.
(And arguably, with Linux's loadable modules for everything from filesystems to device drivers, it's got many of the benefits of a microkernel system anyway.)
Back in the 1980s, DARPA was very unhappy with BSD because it crashed.
If you're talking about 4.2, could be. A lot of new stuff was thrown into that version. I didn't use it that much because my project moved off of a share of the VAX at about the 4.1 to 4.2 transition (onto, in succession, a PDP-11 running 2.x BSD, then System III, then a UTS partition on an IBM 3090, then Arix on a 68K-based multiprocessor box.)
If the Mach effort had come out better, UNIX history could have been quit different.
If Mach had come out better, it wouldn't have been a (quasi-) microkernel. You've no doubt read the famous exchange between Torvalds and Tannenbaum in which Linus argues that a microkernel is a bad idea for a real-world OS kernel. I'm inclined to agree with him. What successes has Mach had? NeXT, MkLinux, and now Mac OS X -- all limited, and two of those under the guidance of Avie Tevanian (who helped write it in the first place) and the backing of Steve Jobs' Reality Distortion Field. Oh, the HURD is microkernel based too, isn't it? 'Nuff said.
(OTOH, DARPA had a point. 4.2BSD was getting downright Baroque. See the keynote speech at the '86 (I think, maybe '85) Usenix.)
Yes, I know NT has been steadily copying commands and utilities from the Unix world. There are still millions of installed Windows systems out there that don't support them.
A shame, really, since there's no good reason why not. Microsoft programmers have certainly been aware of them since the very first DOS days (Microsoft's first OS was XENIX, after all), and even DOS (let alone NT) could have supported a more useful shell and basic utilities -- plenty of third parties provided such, after all. (Cygwin was hardly the first, just free.)
All part of the Microsoft primary design criterion ("what can we do to lock in the customer"), I guess.
Quite correct that mkisofs and cdrecord are Unix utilities. But they are easily invoked from the command line in a script, with no additional user interaction, no GUI needed. Most Windows apps insist on opening a GUI when started, and very seldom confine themselves to just one function (ie they'll roll the functionality of both mkisofs and cdrecord -- and perhaps a few others -- into a single app).
As ESR notes in the book, some of this is a natural result of the fact that process creation under VMS, er, Windows NT (and successors) is expensive, so programs tend to be monolithic (and occasionally internally scriptable), whereas Unix style is to separate out the functionality ('nix process creation is cheap) and use the shell to script things.
The latter is far more flexible. I can write my own program and it's easy to plug into a shell script. Writing a plug-in module for a Windows app that is then scriptable within that app is much harder, if even possible at all (depends on the app).
The difference between scripting MS Office and running a shell script is who is interpreting the script, and how easy is it to add functionality. Sure, strictly speaking the shell is an app too, but 'sh' is universally available on 'nix systems, so it's essentially part of the OS, which is not true of Office on Windows. (Now, if you could write equivalently powerful scripts in IE, you might have a point. You'd also be deeply vulnerable to every malicious URL out there. Oh, wait...)
That's still irrelevant to the original point regarding the power of the native command line interface language.
.bat file, which has nowhere near the capability of even the original Bourne shell let alone a more modern variant like Bash.
The difference is important. Someone using the CLI on Unix will have to learn almost nothing new to create a useful script. The best someone using the CLI interface on Windows can do is create a
Granted, the "average user" uses the GUI far more than the CLI, but this gets far away from the original point of the comparison of Unix vs Windows for casual programmers. Look at all the things that shell scripts get used for in the average Unix/Linux system, now try to do that stuff in the Windows CLI. (I know, there are other tools to do that, just as on Unix. But the original point was the expressiveness of the native command line language.)
Not at all. There's a difference between scripting applications and scripting with applications. In the latter, the apps act as simply additional verbs in the scripting language, just as do function calls in a programming language. The only thing passed is command line arguments.
Tell me, how useful are command line arguments to word.exe?
.BAT are very limited and the syntax is ugly. Use .VBS instead
.sh), not what you could do with some other scripting language. I can get Perl and Tk and Python (oh my!) for Windows too, but that misses the point.
This is true, but the point was a comparison of the native CLI as a scripting language (.bat vs
The Berkeley TCP/IP implementation wasn't the first for UNIX.
And nowhere in the paragraph you quoted does it say that it was. Nice strawman you set up there, but you could have bragged on your rewrite of UNET without it.
You're clearly confused. MS Office and OpenOffice are applications, not operating systems.
.bat program) to say, take a directory full of text files, make some simple text edits on all the files, write those to a new folder, and then create a CD-ROM with an ISO image of that folder? It's just a few lines of shell script on Unix/Linux. (Most distros include mkisofs and cdrecord as standard utilities.)
Can you, for example, write a Windows script (ie, DOS
I forget who made the compiler -- I'm sure I still have it buried in a box somewhere -- but talk about s-l-o-w compiling off that 1541 floppy drive.
However, for hardware hacking you couldn't beat the VIC-20, especially when the price dropped to under $99. I used one of those to wire up a friend's photoelectric photometry observatory (15" scope). Ripped apart a potentiometer and mechanically attached it to the filter wheel to read its position (via the analog port), wired a selector switch to the joystick inputs (to specify whether the reading was of dark sky, the object of interest, or a reference object), and then ran a cable from the VIC from the observatory to the house where it pretended to be a keyboard on the Apple II that was actually logging the data (and was connected to the photon counter).
Another time I wired outputs to the motor controls of a toy tank, controlled by the joystick inputs, and put a 2.8 second delay in with a simple Basic program to simulate the delay in teleoperating something on the Moon. This was for some Space Day event. Interstingly, the older folks and very young kids adapted to the delay pretty easily. The preteens and teens, with their videogame tuned reflexes, couldn't get the hang of it.
Heh. I occasionally (very occasionally) run the DOS "Q&A" database -- on the SoftPC emulator on my Mac. I think the last time was two years ago when we looked up what my wife's sister gave us as a wedding present (back in '89, when it was running on a 286) so we could return the favor ;-)
I've still got a 5.25" floppy drive from that old 286 machine (circa 1986 or 1987) running in my dual P-III linux box; I installed it to read some floppies.
Mind, I've never thrown any of the hardware out. I've still got my KIM-1 down in the workshop, but it hasn't been powered up in over a decade. (Mine's not as pretty as the picture, it's covered in jumper wires for the "TV Typewriter" I added).
The system drive should have nothing on it but system. All data should be on one or more completely separate drives.
/etc) system or data? What about log files?
So, are system configuration files (the kind of stuff in
The Romans had the abacus too. It may even have been invented there and moved east.
Take a look at Roman numerals and reflect upon how they're exactly how you'd represent the numbers on an abacus. Some people deride Roman numerals as being impossibly hard to do arithmetic with -- on the contrary, they make it very easy to use an abacus with.
- a small wooden frog
- a stuffed vole
- a collection of antique toast racks
- a rusty wand
- a small bird in a wicker cage
You may recognize the last two. The first three, and some others I don't remember, I added to the Adventure game running on the campus mainframe back when. (The inspiration was a comment in some computer magazine.) Actually useful to help map the maze of twisty little passages, all alike, but that's about it (no points).Actually it was the SUID bit. And the patent actually managed to describe it as though it could be a mechanical contrivance. (They just didn't do software patents in those days.)
Bell Labs released the patent to the public domain.