Avoid putting . or ~/bin in your PATH if possible.
Huh? I can understand not putting . in your PATH-- icky nasty security issues abound-- but what's wrong with ~/bin?
Don't hit Ctrl-Alt-Backspace.
Again, why not? I've seen labs with notices to hit Ctrl-Alt-Backspace before leaving. (That's the only way to logout that works across WMs.)
I also would expect that it's a good idea to hit it before logging in, to make sure you're really looking at XDM. This is why you hit Ctrl-Alt-Delete to log into NT: apps can't intercept it.
As far as that goes one of your tips is to lock your box, another is to never hit C-A-BS. In a lab environment, these can be mutually exclusive. Many times, somebody will walk off and leave their computer locked, so C-A-BS can be the only way for somebody else to use the computer.
Hmmm... I'm not sure that Comcast would take well to devices other than their own reading the schedule data. It's irrational, I know, but I never expect content pipelines to be rational.
A) less redundant equipment to increase costs B) a smaller bill every month from your cable company
These seem to be the same thing stated two different ways. The settop box is a free rental with my cable company. They charge no less if I don't use it. As an example, I'm entitled to two settop boxes, but only have one. You think my cable bill is any less for it?
C) 1 less remote in your living room
Seeing as how I keep the cable box remote in storage anyways, since the TiVo controls the cable box, I don't really care.
D) 1 less thing to break
As opposed to a single point of failure? When my cable box breaks, I can still get the analog channels (75% of what I record). When my TiVo breaks, I can still watch TV.
E) Less power used
Okay, since I have a heat problem in my A/V cabinet, I'm with you on that one.
It also makes the cost of the hardware cheaper since TiVo wouldn't need to buy an expensive hardware MPEG encoder.
Actually, it would. Even on digital cable, channels 2-96 are analog feeds. The digital feeds are the channels 100 and up. (The bands for 97, 98, and 99 (IIRC) are used for the digital signal.)
The advantage is that recorded shows have exactly the same quality as live TV unlike a regular Tivo where there is some quality loss.
The disadvantage is the lack of quality control. I keep a lot on my TiVo, and use the quality setting quite a bit to manage space. Cooking shows? Basic. Action flicks? High or Best. Most stuff? Medium. Requiring everything to be at (effectively) Best means that-- while quality is better-- you lose space.
I have a TiVo fed by a settop. My settop is included in my cable package. I'm fine with that; it doesn't matter to me that the TiVo can't decode directly. Why do I care about OpenCable?
most geeks are afraid of girls. You don't think they're going to be even more afraid of lonely, burly men?
They keep filling the prisons with potheads and geeks instead of Bubbas. The geeks will be around other geeks to talk geek, the potheads will have others around who'll listen to their disjointed philosophical tangents, and the prison guards won't have to worry about escapes.
Yay, everybody wins! (Well, except the people on the outside where all the violent Bubbas now are...)
Following on this matter, STU-III phones (secure encrypted phones) require a physical token to go secure. The token holds the crypto key; without it, the phone is unclassified.
The token is shaped like a key. This way, everybody knows that it's supposed to be protected, just like a key.
my definition of "real" GC is that it has to be a NON-conservative, compacting, ephemeral collector.
Why is this? I'm a Lisp hacker, so I work with quite a number of different GCs. I don't particularly think that what you list is required for "real"ness.
I read those articles. The first one doesn't say anything about their relative toxicities; I expect that Dr. Cohen expected Mr. Nader to cease ingestion of caffeine at a point that would still be safe for both of them.
The second says that, under certain conditions, caffeine can be more toxic. It doesn't discuss the conditions.
The third was best. It stated that the chemical toxicity of caffeine was greater than that of plutonium, but I didn't see anything to back it up.
The fourth didn't address the issue. Dr. Cohen clarified what he said previously, and discussed ingestion vs inhalation, but regarding relative toxicities only said: "eating plutonium is about equal in danger to eating the same quantity of caffeine", but I couldn't find where he explains that claim. (Admittedly, since it's a 17-chapter book, I didn't finish the whole thing.)
The final link again makes the claim that caffeine is more toxic than plutonium, but doesn't discuss it further.
Now, I took it upon myself to do a bit of research, using TOXNET (which doesn't handle deep linking well). I couldn't find any toxicity reports regarding ingestion of plutonium. But there are a number of intravenious studies of both caffeine and plutonium.
It looks like the LDLo (smallest dose recorded to kill) of intravenious caffeine on a dog is 4 mg/kg, while the LD50 (50% kill) of intravenious plutonium citrate is merely 300 ug/kg. Note that since this is comparing an LDLo to an LD50, it doesn't tell us the relative toxicities, but it does seem to suggest that plutonium is more toxic. (Sources: plutonium citrate, caffeine).
To compare LD50 to LD50, we can first look at [JPETAB Journal of Pharmacology and Experimental Therapeutics. (Williams & Wilkins Co., 428 E. Preston St., Baltimore, MD 21202) V.1- 1909/10- Volume(issue)/page/year: 82,89,1944]. This paper establishes the LD50 of caffeine administered intraveniously to a rat at 105 mg/kg. Now, [Venugopal, B. and T.D. Luckey. Metal Toxicity in Mammals, 2. New York: Plenum Press, 1978. 169 (peer reviewed)] establishes the LD50 for plutonium administered intraveniously to a rat at
0.0014 uCi/g. Now, since 5 ug of plutonium has a radioactivity of 0.3 uCi (reference), this figure is equivalent to 8.4e-5 mg/kg.
Perhaps the absorption rate of plutonium is 1e6 times less than that of caffeine. There are suggestions that plutonium is not absorbed easily. But 1e6 still seems like a lot, lacking any other evidence.
But pointing the other way, remember that plutonium builds up on the bones, leading to a chronic toxicity which is higher than its acute toxicity.
So, I'm going to remain skeptical for the time being. I'm not saying it's right or wrong, just that I'm not sure that I agree with that statement.
I think you misunderstand the attack. You send, say, ten people on flights, without arms. Repeat a couple of times if you want. See who's getting screened and who's not. Pick the one who's getting screened the least, since CAPPS apparently feels that he is safe.
So:
1) it could come out that they get busted on the test run and reveal the whole plot.
I don't think they'd be carrying explosives during CAPPS probes. Besides, the one guy who did get revealed is not the one they'd pick to perform the operation, since he got screened during the probes. With proper compartmentalization, the TSA now has one guy who was expendable, not the whole plot. And that's assuming you were doing something naughty during the probes in the first place; keep clean during the probes, and you don't get busted.
2)the longer it takes for them to find a successfull canidate the better chances are that they get stopped and the longer it takes to put together an attack.
These probes can be done in parallel. Also, attacks can take quite some time to prepare; you don't put somebody through flight school overnight. The few days to make probes isn't going to make a big difference. Depending on the rest of your schedule, you may be able to execute the probes before you do the "big chatter" stuff that's likely to get the Feds curious.
3) so lets say the get a guy who is the anti-sterotype of a terrorist - he may do other things that trigger the system.
Huh? If you deliberately pick an anti-stereotype, that assumes that you know what CAPPS uses, so you know what things trigger the system. That's a white-box bit of work, and requires no probes. But CAPPS is black-box, and the attack is against it as a black box: you just look and see who doesn't trigger the system.
in the end there is nothing you can do to stop a terrorist or any other criminal for that matter. but you can make it harder for them.
The point of the paper is that CAPPS may be making things slightly harder (because you have to probe), but also less likely to get caught and stopped (because you can execute an attack with a lower-than-random chance of getting busted).
Personally, I'd rather attacks against me and mine be easy and unlikely to succeed, than difficult and likely to succeed.
Obviously, if we were to take this critique too seriously on its face it would support the conclusion that locks should not be used because locksmiths (or burglars with locksmithing knowledge) can defeat them.
I've got to disagree. True, the fact that measure X can be defeated does not make it un-worthwhile. But CAPPS determines the distribution of searches. This does make it possibly worse than the alternatives (e.g., random searching).
Suppose that out of 100 people, the airport has resources to search 10. With a random search, then each person has a 10% chance of getting searched. No getting around that.
Now, let's say that CAPPS will determine that 5% of the passengers must be (100% chance) searched, and the rest of the searches are random. That means that the other 95% of the passengers now each have a 5% chance of getting searched.
With a probable system, you can determine who in your cell has that 5%, and who has the 100% chance. Who would you send?
In organized terrorism, assuming fixed resources (i.e. you don't get to hire more people just because you're profiling), profiling actually gives the attackers a way to lower their operatives' chances of being searched.
It's not hard to write a random sentence generator that can deal with those rules. In fact, it's pretty much part of any Prolog class. And you can still make them semantically meaningless with a high probability.
Besides, who said this stuff had to be generated? A lot of what I saw when these random sentences first started hitting the spam was extracted from public domain texts. Politicians aside, not many people are likely to find a sentence from "Alice in Wonderland" offensive.
As for the CLI itself--it's not that CLIs can't be user-friendly, it's that they simply aren't.
I just wrote a post that says the same thing, and I'm going to
elaborate on it here. I use a decades-old OS called Genera as my
example. It's absolutely amazingly easy to use. What a concept: put
a Help key, labeled "Help", on the keyboard! And the UI is based
around the idea that you are a human. The default messages are based
around the idea that you're a programmer (in its stock configuration,
it's a programmer's machine), but a human nonetheless.
When you first turn it on, after the version and copyright herald,
you see in a plain, clear, proportional font, with special characters
like (R) and named keys (I have to approximate it in ASCII):
You are typing to
Dynamic Lisp Listener 1.
Control characters are interpreted as commands to edit input.
Press Control-[Help] for a list of input editor commands.
Type "Help Commands" for a list of Command Processor commands.
Press [Select] D to select Document Examiner(R) to read online documentation.
Press [Select] [Help] for a list of programs.
Press [Function] [Help] for a list of asynchronous and window operations.
Hold down Shift and click the rightmost mouse button to select the System Menu of programs and window operations.
Press Symbol-[Help] for a list of special function keys and special character keys.
Please login. Command:
At the bottom of the screen, I see:
Mouse-R: Menu To see other commands, press Shift, Control, Meta-Shift, or Super. [Mon 12 Apr 4:15] CL USER: User Input
Any time that there's an operation taking place, a progress bar
appears on the bottom (in a slightly different place depending on
what's going on, for advanced users) and "User Input" changes to
whatever it's doing.
So I type "help commands". It's echoed as I type, and so I can see
which parameters are what, and what the defaults are. They're all in an easy-to-read table in real life, but slashdot doesn't seem to want to format it correctly.
Command: Help (with [default All]) Commands
The User command table has nine commands of its own and inherits additional commands from these command tables: Access Control File Printer Maintenance Activities File System Process Breakpoint Flavors Programming Tools Callers Fonts Remote terminal user CLOS Garbage Collection Session [snip- joelh]
Command:
If I move my mouse over one of these command tables (including where it says "User" at the top), it lights up with a box around it. The status line changes:
Mouse-L: Show all commands; Mouse-M: Describe command table; Mouse-R: Menu To see other commands, press Shift, Control, Meta-Shift, or Super.
I can click it, and see what commands are in that category (again, in nice columns in RL):
The Mail Reading/Sending command table contains these commands: Initialize Mail Send Mail Save Mail Buffers Show Mail Scan Mail Show Zmail Status
Command:
The highlighted box and mouse status board tell me I can (among
other things) left-click on the "Send Mail" command to execute it, or
middle-click to see the documentation, so I middle-click. Note that I
don't have to use the mouse; there's a command available if I feel
like typing, and Genera helpfully fills it in at my Command:
prompt.
Command: Show Documentation Send Mail Command
Send Mail
Command Send Mail recipientkeywords
Prompts for the text of the message and sends it as electronic mail
to recipient.
With command lines, you need to know the commands, and the options, before starting.
I have a computer here that's CLI-based, and I learned to use it without knowing the commands.
I pushed the "Help" button (it's not an IBM keyboard; it actually has a "Help" button). It gave me some ways to get started. I can always press Help to get context-specific help, or I can press Complete to see possible completions of my command. If I type "Help (with) Commands" then it'll give me a categorized list of commands available.
Yes, the Unix CLIs we have today suck. That doesn't mean that CLI == suck.
A fair bit of phk's code is under the Beer-ware license:
/* * "THE BEER-WARE LICENSE" (Revision 42): * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp */
(Some formatting changed for the lameness filter)
In all likelyhood, I'll never meet phk, so I reckon I can donate instead of buying him a beer directly.
The OP is an old Mac troll... originally around the System 7 days, IIRC; you can see versions from six years ago online.
It evolved over time, and became a BSD troll by way of OS X. I found out about it because I fell for it about a year ago.:-)
But I do have a couple of comments about your post:
Copying a 17 meg file should not take _any_ time as all it requires is an update to the file systems tables.
No, copying a file (as in, using cp) does duplicate all the data blocks. It sounds like you're thinking of making a hard link, which is just a directory update. But on my box (1400 MHz AMD, UW160 SCSI) it takes 3.3 sec to copy a file that's not in cache, on the same filesystem.
are you trying to copy a file to a recursive symlink?
If an operation goes through MAXSYMLINKS (32) links, then it's aborted with an ELOOP, so you don't have to worry about it.
Are you trying to copy/dev/random to/dev/null?
I know this isn't how you meant it, but just for interest, copying 17 MB from/dev/random to/dev/null takes 0.9 sec on my box.
But yeah, the OP with his 20+ minute 17 MB copy is a load of BS.
Avoid putting . or ~/bin in your PATH if possible.
Huh? I can understand not putting . in your PATH-- icky nasty security issues abound-- but what's wrong with ~/bin?
Don't hit Ctrl-Alt-Backspace.
Again, why not? I've seen labs with notices to hit Ctrl-Alt-Backspace before leaving. (That's the only way to logout that works across WMs.)
I also would expect that it's a good idea to hit it before logging in, to make sure you're really looking at XDM. This is why you hit Ctrl-Alt-Delete to log into NT: apps can't intercept it.
As far as that goes one of your tips is to lock your box, another is to never hit C-A-BS. In a lab environment, these can be mutually exclusive. Many times, somebody will walk off and leave their computer locked, so C-A-BS can be the only way for somebody else to use the computer.
Hmmm... I'm not sure that Comcast would take well to devices other than their own reading the schedule data. It's irrational, I know, but I never expect content pipelines to be rational.
A) less redundant equipment to increase costs B) a smaller bill every month from your cable company
These seem to be the same thing stated two different ways. The settop box is a free rental with my cable company. They charge no less if I don't use it. As an example, I'm entitled to two settop boxes, but only have one. You think my cable bill is any less for it?
C) 1 less remote in your living room
Seeing as how I keep the cable box remote in storage anyways, since the TiVo controls the cable box, I don't really care.
D) 1 less thing to break
As opposed to a single point of failure? When my cable box breaks, I can still get the analog channels (75% of what I record). When my TiVo breaks, I can still watch TV.
E) Less power used
Okay, since I have a heat problem in my A/V cabinet, I'm with you on that one.
It also makes the cost of the hardware cheaper since TiVo wouldn't need to buy an expensive hardware MPEG encoder.
Actually, it would. Even on digital cable, channels 2-96 are analog feeds. The digital feeds are the channels 100 and up. (The bands for 97, 98, and 99 (IIRC) are used for the digital signal.)
The advantage is that recorded shows have exactly the same quality as live TV unlike a regular Tivo where there is some quality loss.
The disadvantage is the lack of quality control. I keep a lot on my TiVo, and use the quality setting quite a bit to manage space. Cooking shows? Basic. Action flicks? High or Best. Most stuff? Medium. Requiring everything to be at (effectively) Best means that-- while quality is better-- you lose space.
Using the "IR dongle thingy" I've had poor luck. I now use the serial interface and it's fast and accurate. No problems.
But yes, for those without serial capability, I can see that direct decoding would be good.
Why do I care?
I have a TiVo fed by a settop. My settop is included in my cable package. I'm fine with that; it doesn't matter to me that the TiVo can't decode directly. Why do I care about OpenCable?
most geeks are afraid of girls. You don't think they're going to be even more afraid of lonely, burly men?
They keep filling the prisons with potheads and geeks instead of Bubbas. The geeks will be around other geeks to talk geek, the potheads will have others around who'll listen to their disjointed philosophical tangents, and the prison guards won't have to worry about escapes.
Yay, everybody wins! (Well, except the people on the outside where all the violent Bubbas now are...)
Research indicates
Do you happen to have references handy?
secure it like you do your own house/car/etc
Following on this matter, STU-III phones (secure encrypted phones) require a physical token to go secure. The token holds the crypto key; without it, the phone is unclassified.
The token is shaped like a key. This way, everybody knows that it's supposed to be protected, just like a key.
my definition of "real" GC is that it has to be a NON-conservative, compacting, ephemeral collector.
Why is this? I'm a Lisp hacker, so I work with quite a number of different GCs. I don't particularly think that what you list is required for "real"ness.
Exactly.
(Why does /. think that it should take me at least 20 seconds to type "Exactly", or that I didn't know what I was going to say before I hit "Reply"?)
Sorry Jim Bob, I done tried that onced before, and tain't gonna stop them revenuers.
Cablepokerface hopelessly checks keyboard to see distance between S and C to claim a typo.
Psst... tell 'em you're using a Maltron.
I read those articles. The first one doesn't say anything about their relative toxicities; I expect that Dr. Cohen expected Mr. Nader to cease ingestion of caffeine at a point that would still be safe for both of them.
The second says that, under certain conditions, caffeine can be more toxic. It doesn't discuss the conditions.
The third was best. It stated that the chemical toxicity of caffeine was greater than that of plutonium, but I didn't see anything to back it up.
The fourth didn't address the issue. Dr. Cohen clarified what he said previously, and discussed ingestion vs inhalation, but regarding relative toxicities only said: "eating plutonium is about equal in danger to eating the same quantity of caffeine", but I couldn't find where he explains that claim. (Admittedly, since it's a 17-chapter book, I didn't finish the whole thing.)
The final link again makes the claim that caffeine is more toxic than plutonium, but doesn't discuss it further.
Now, I took it upon myself to do a bit of research, using TOXNET (which doesn't handle deep linking well). I couldn't find any toxicity reports regarding ingestion of plutonium. But there are a number of intravenious studies of both caffeine and plutonium.
It looks like the LDLo (smallest dose recorded to kill) of intravenious caffeine on a dog is 4 mg/kg, while the LD50 (50% kill) of intravenious plutonium citrate is merely 300 ug/kg. Note that since this is comparing an LDLo to an LD50, it doesn't tell us the relative toxicities, but it does seem to suggest that plutonium is more toxic. (Sources: plutonium citrate, caffeine).
To compare LD50 to LD50, we can first look at [JPETAB Journal of Pharmacology and Experimental Therapeutics. (Williams & Wilkins Co., 428 E. Preston St., Baltimore, MD 21202) V.1- 1909/10- Volume(issue)/page/year: 82,89,1944]. This paper establishes the LD50 of caffeine administered intraveniously to a rat at 105 mg/kg. Now, [Venugopal, B. and T.D. Luckey. Metal Toxicity in Mammals, 2. New York: Plenum Press, 1978. 169 (peer reviewed)] establishes the LD50 for plutonium administered intraveniously to a rat at 0.0014 uCi/g. Now, since 5 ug of plutonium has a radioactivity of 0.3 uCi (reference), this figure is equivalent to 8.4e-5 mg/kg.
Perhaps the absorption rate of plutonium is 1e6 times less than that of caffeine. There are suggestions that plutonium is not absorbed easily. But 1e6 still seems like a lot, lacking any other evidence.
But pointing the other way, remember that plutonium builds up on the bones, leading to a chronic toxicity which is higher than its acute toxicity.
So, I'm going to remain skeptical for the time being. I'm not saying it's right or wrong, just that I'm not sure that I agree with that statement.
Well, according to all the making-of stuff on the Abyss DVD, they really submerged a rat in the stuff and filmed it breathing.
First, rats have a different respiratory system than humans.
Second, last I heard, they haven't figured out how to get the rat out of the liquid without suffocating him. Once he goes in, he's in for life.
So:
1) it could come out that they get busted on the test run and reveal the whole plot.
I don't think they'd be carrying explosives during CAPPS probes. Besides, the one guy who did get revealed is not the one they'd pick to perform the operation, since he got screened during the probes. With proper compartmentalization, the TSA now has one guy who was expendable, not the whole plot. And that's assuming you were doing something naughty during the probes in the first place; keep clean during the probes, and you don't get busted.
2)the longer it takes for them to find a successfull canidate the better chances are that they get stopped and the longer it takes to put together an attack.
These probes can be done in parallel. Also, attacks can take quite some time to prepare; you don't put somebody through flight school overnight. The few days to make probes isn't going to make a big difference. Depending on the rest of your schedule, you may be able to execute the probes before you do the "big chatter" stuff that's likely to get the Feds curious.
3) so lets say the get a guy who is the anti-sterotype of a terrorist - he may do other things that trigger the system.
Huh? If you deliberately pick an anti-stereotype, that assumes that you know what CAPPS uses, so you know what things trigger the system. That's a white-box bit of work, and requires no probes. But CAPPS is black-box, and the attack is against it as a black box: you just look and see who doesn't trigger the system.
in the end there is nothing you can do to stop a terrorist or any other criminal for that matter. but you can make it harder for them.
The point of the paper is that CAPPS may be making things slightly harder (because you have to probe), but also less likely to get caught and stopped (because you can execute an attack with a lower-than-random chance of getting busted).
Personally, I'd rather attacks against me and mine be easy and unlikely to succeed, than difficult and likely to succeed.
I'll only be happy if there's a legal recourse for those wrongfully fingered and can't get the information fixed.
Is the TSA exempt from the auspices of the Privacy Act?
Obviously, if we were to take this critique too seriously on its face it would support the conclusion that locks should not be used because locksmiths (or burglars with locksmithing knowledge) can defeat them.
I've got to disagree. True, the fact that measure X can be defeated does not make it un-worthwhile. But CAPPS determines the distribution of searches. This does make it possibly worse than the alternatives (e.g., random searching).
Suppose that out of 100 people, the airport has resources to search 10. With a random search, then each person has a 10% chance of getting searched. No getting around that.
Now, let's say that CAPPS will determine that 5% of the passengers must be (100% chance) searched, and the rest of the searches are random. That means that the other 95% of the passengers now each have a 5% chance of getting searched.
With a probable system, you can determine who in your cell has that 5%, and who has the 100% chance. Who would you send?
In organized terrorism, assuming fixed resources (i.e. you don't get to hire more people just because you're profiling), profiling actually gives the attackers a way to lower their operatives' chances of being searched.
It's not hard to write a random sentence generator that can deal with those rules. In fact, it's pretty much part of any Prolog class. And you can still make them semantically meaningless with a high probability.
Besides, who said this stuff had to be generated? A lot of what I saw when these random sentences first started hitting the spam was extracted from public domain texts. Politicians aside, not many people are likely to find a sentence from "Alice in Wonderland" offensive.
I know the one in RWC (my ex-roommate used to work next door), but where's the one in Santa Clara?
As for the CLI itself--it's not that CLIs can't be user-friendly, it's that they simply aren't.
I just wrote a post that says the same thing, and I'm going to elaborate on it here. I use a decades-old OS called Genera as my example. It's absolutely amazingly easy to use. What a concept: put a Help key, labeled "Help", on the keyboard! And the UI is based around the idea that you are a human. The default messages are based around the idea that you're a programmer (in its stock configuration, it's a programmer's machine), but a human nonetheless.
When you first turn it on, after the version and copyright herald, you see in a plain, clear, proportional font, with special characters like (R) and named keys (I have to approximate it in ASCII):
At the bottom of the screen, I see:
Any time that there's an operation taking place, a progress bar appears on the bottom (in a slightly different place depending on what's going on, for advanced users) and "User Input" changes to whatever it's doing.
So I type "help commands". It's echoed as I type, and so I can see which parameters are what, and what the defaults are. They're all in an easy-to-read table in real life, but slashdot doesn't seem to want to format it correctly.
If I move my mouse over one of these command tables (including where it says "User" at the top), it lights up with a box around it. The status line changes:
I can click it, and see what commands are in that category (again, in nice columns in RL):
The highlighted box and mouse status board tell me I can (among other things) left-click on the "Send Mail" command to execute it, or middle-click to see the documentation, so I middle-click. Note that I don't have to use the mouse; there's a command available if I feel like typing, and Genera helpfully fills it in at my Command: prompt.
With command lines, you need to know the commands, and the options, before starting.
I have a computer here that's CLI-based, and I learned to use it without knowing the commands.
I pushed the "Help" button (it's not an IBM keyboard; it actually has a "Help" button). It gave me some ways to get started. I can always press Help to get context-specific help, or I can press Complete to see possible completions of my command. If I type "Help (with) Commands" then it'll give me a categorized list of commands available.
Yes, the Unix CLIs we have today suck. That doesn't mean that CLI == suck.
A fair bit of phk's code is under the Beer-ware license:
(Some formatting changed for the lameness filter)
In all likelyhood, I'll never meet phk, so I reckon I can donate instead of buying him a beer directly.
YHBT.
The OP is an old Mac troll... originally around the System 7 days, IIRC; you can see versions from six years ago online. It evolved over time, and became a BSD troll by way of OS X. I found out about it because I fell for it about a year ago. :-)
But I do have a couple of comments about your post:
Copying a 17 meg file should not take _any_ time as all it requires is an update to the file systems tables.
No, copying a file (as in, using cp) does duplicate all the data blocks. It sounds like you're thinking of making a hard link, which is just a directory update. But on my box (1400 MHz AMD, UW160 SCSI) it takes 3.3 sec to copy a file that's not in cache, on the same filesystem.
are you trying to copy a file to a recursive symlink?
If an operation goes through MAXSYMLINKS (32) links, then it's aborted with an ELOOP, so you don't have to worry about it.
Are you trying to copy /dev/random to /dev/null?
I know this isn't how you meant it, but just for interest, copying 17 MB from /dev/random to /dev/null takes 0.9 sec on my box.
But yeah, the OP with his 20+ minute 17 MB copy is a load of BS.