Cf. the story (possibly apocryphal) of a woman shot in the abdomen by a stray bullet in the Civil War. Later discovers she was pregnant. Conclusion is that the bullet passed through the testicles of the soldier it was aimed at.
However it's not uncommon among sportsmen who exchange a lot of air after a session. In the 80s or early 90s many who practiced orienteering (sports scouting) died due to that disease.
I'm not sure how orienteering is particularly well-correlated with "exchang[ing] a lot of air after a session". Tents?
Anyone who sits in a closed car with anyone else with the external venting off is exchanging all their air, so that would be where I'd go for a correlation.
What they really want to know is, if you can get an insect-vectored disease from sexual contact, can you get a sexually-vectored disease from sitting on a toilet seat? Or AIDS from shaking hands? And so on...
Wikileaks broke Amazon's rules. The fact that it also broke the law is beside the point. At least here.
Amazon enforced its rules. I guess enforcing the rules on Wikileaks is some sort of blasphemy or something, because I can't see why else to retaliate against Amazon. But I'm not religious, so I don't recognize blasphemy as having any inciteful value.
No worries. Nobody needs Amazon for anything, and they're borderline evil..
If one of these goes on the fritz because some drunk pounds it with a rebar he found lying on the road, it's going to strand commuters.
On the other hand, since it doesn't involve any sort of slot to insert or swipe anything, that's one less point of weakness. You can plant the NFC transceiver behind an inch of HDPE (plastic decking, e.g.) and it'll never feel a thing.
The ticket-printer slot is still going to be there. Unless the ticket is also electronic and someone wanting to check it can NFC your phone to know if you're riding privileges are intact.
No, wait. Rigor tells me that's just a stick-figure of a zombie. It doesn't even have Feynman's accent, semi-decayed larynx or not.
Mythbusters is to science what tee-ball is to MLB.
Yes, they may be testing things, but no, they famously fail to prove or disprove anything with many of the tests because they don't always understand what science is and why it's how things really get tested to find out if they're real effects or illusions.
And they almost never explain the science behind a phenomenon correctly.
Yup. And more importantly, he knows from experimental evidence what sort of shit doesn't blow up even if the formula said it should.
Development = turning theory into reality, by removing all the parts the theory got wrong, and adding all the parts the theory left out, but only until someone says "that works for me."
Computers were switch-and-lamp based for decades before they had the power to support character-based i/o, and even that involved manual or mechanical punching of holes in paper media.
If the CRT had come sooner than it did, and TVs had developed a pointer interface (vernier knobs and a dot and a button for selecting channel frequencies from an analog on-screen scale, for example), we might have had the mouse and GUI before we ever had text i/o, and we'd have done object orientation and GUI-centrism the right way, instead of being all scripty like we are.
Actually, as I think about it, a radio dial is an ideal example of a GUI, albeit one with only one displayable dialog.
But we went digital so hard that instead of porting over those elegant i/o modalities we decided to scale-up the digitalism and use letters and words built out of our 2-bit numbers. And we thought we were pretty smart about it, too. Now we're paying for it.
All you're getting out of that last bit is that the program doesn't have to remember its functions, the user does. So instead of starting a program, clicking on a menu, and selecting the thing I want, I have to read a manual, then start a program, telling it the thing I want.
So the manual is the menu. Only it's not part of the program. And I can't just click on the thing I find in it to make it happen, I have to go enter the words in a generic program interface (a shell prompt). Which, it turns out, did know the function after all, because that's how it matches the word to the code module to run.
So all you've done there is to add this subprocess of making the user refer to external information then copy it manually into the program that already knows it but refuses to admit it. (And no, having the full usage info dump when you do "foo --help" isn't really a fix, because the user still has to enter the command; the program, again, knows the magic word well enough to say it, and to recognize it, but doesn't know enough to just use it as an input device).
The Unix CLI did an awful job of pretending that the CLI was the API. VxWorks' shell does it somewhat more faithfully, but botches a lot of other stuff so I wouldn't recommend it as an example.
I couldn't even tell you how to get to a command line on my Android phone (though I know it's possible), and yet I can do everything I want to do on my phone.
CLI exists, the way VMS exists. But most of us, we've evolved past it.
Wouldn't it be cool if the thing before the colon were a language the CLI was expecting, not a disk-drive letter parameterizing the defaults to only a few strings you might enter on the CLI?
Bill Gates was a total idiot, except for the part where he stole that code from Seattle Micro, and then didn't sell it to IBM, which he did before he even stole it.
I'd bet any amount of money that you were taught how logic and functions work by someone drawing pictures on a chalkboard, and then telling you how to arrange words to make that picture happen in the computer.
BTW, ever look inside a computer? They're basically drawn, then printed as drawn, from the circuit board to the CPU chip. The words in there are just so the people building them know where the pick-and-place machine screwed up.
It may use a scripting language, but there's no reason that couldn't be a programming language or a visual-programming system. Once you're done developing it, it gets stuck in a scheduler database and run by the machine with no interaction.
I didn't read the article because I know what it says, and I've forgotten more about being a sys admin than most of the sys admins here will ever know (and that isn't just a boast it's also likely true, because i knew essentially everything about it at one time and haven't bothered much beyond personal dicking around in about 10 years).
Most of what you want to do as a sysadmin goes into CLI and scripts because that stuff was all built for CLI back when CLI was a pretty neat way to make your computer interact with you, and that stuff wasn't changed to do GUI because all of the first GUIs were just programs run from the CLI.
Until Windows did away with that. But it doesn't feel like it because of all that text that scrolls up the screen when you start your Windows machine.
You do realize, to get to a CLI on Windows these days you have to wait for the GUI to give you the opportunity to start a shell that will take CLI input, right?
As for Linux, it's basically the identical system to what existed before Windows, and the people developing for it have never thought to just do away with the CLI because then it won't be Linux at all, it will be a Linux Kernel that boots to a GUI no matter what, and all that shit in section 1 of the manual will be dead.
But even in Windows there's still CLI-isms. The way a desktop link formats the command string with options is really a DOS CLI command. It's the only way they knew how to do execution of one program from within another program, so it's how they did it. They just didn't think to do away with that methodology.
Are you seriously pretending that a CLI can do "every possible thing"?
Can a CLI edit a movie interactively?
That's not even a mentally complicated thing. It's a very simple one. Can you imagine trying to do that from a CLI?
There are very, very good reasons that CLI's started to disappear into the back of the drawer when GUI programming got easier. And one TFA with a contrary view is not going to make even a slight dent in that. It's more likely that at some point we could do away with CLI entirely, if we can build enough self-modifiability into a GUI.
I'm not the first to think that. Look up a programming language/system called "G2". 15 years ago it was very popular for building factory-control systems, because its visual analogue to a dataflow graph was a lot like the sort of process graphs that factory designs are built from.
how about you type "about:config" into your browser's address bar and hit Enter
Now you have a filter (grep), the column headings (sort), and you don't need uniq because you don't have to save the configs to a file to edit later and then be merged into the main config file, because you can just click on the configs right there and make your changes directly, which is what you really want.
Or you could take your "results.csv", which is a spreadsheet file in text form, and load it into a GUI called "Excel" or something like that, and filter it, sort it, modify it, print it, transpose it, operate on it globally or locally, change its colors, automate its cells so that several change when you change one, yadda, yadda, yadda
Slashdot Mirror
Cf. the story (possibly apocryphal) of a woman shot in the abdomen by a stray bullet in the Civil War. Later discovers she was pregnant. Conclusion is that the bullet passed through the testicles of the soldier it was aimed at.
However it's not uncommon among sportsmen who exchange a lot of air after a session. In the 80s or early 90s many who practiced orienteering (sports scouting) died due to that disease.
I'm not sure how orienteering is particularly well-correlated with "exchang[ing] a lot of air after a session". Tents?
Anyone who sits in a closed car with anyone else with the external venting off is exchanging all their air, so that would be where I'd go for a correlation.
Dude didn't wipe or cover the seat at a Wal-Mart. His answers are not the answers I'm looking for.
What they really want to know is, if you can get an insect-vectored disease from sexual contact, can you get a sexually-vectored disease from sitting on a toilet seat? Or AIDS from shaking hands? And so on...
And who quit for a very dumb reason, probably getting a hearty "good riddance" on the way out the door.
http://online.wsj.com/article/SB10001424052748703377504575651321402763304.html
Wikileaks broke Amazon's rules. The fact that it also broke the law is beside the point. At least here.
Amazon enforced its rules. I guess enforcing the rules on Wikileaks is some sort of blasphemy or something, because I can't see why else to retaliate against Amazon. But I'm not religious, so I don't recognize blasphemy as having any inciteful value.
No worries. Nobody needs Amazon for anything, and they're borderline evil..
Howcome they didn't rate in the top half on their own poll?
Seriously.
Desktops are about a year away from becoming landfill.
In two years anyone using a keyboard will be shot on sight.
Not really. Just hopefully.
And I don't just mean that figuratively.
If one of these goes on the fritz because some drunk pounds it with a rebar he found lying on the road, it's going to strand commuters.
On the other hand, since it doesn't involve any sort of slot to insert or swipe anything, that's one less point of weakness. You can plant the NFC transceiver behind an inch of HDPE (plastic decking, e.g.) and it'll never feel a thing.
The ticket-printer slot is still going to be there. Unless the ticket is also electronic and someone wanting to check it can NFC your phone to know if you're riding privileges are intact.
Bite me.
On the next episode of Mythbusters!
Aaah! Zombie!
No, wait. Rigor tells me that's just a stick-figure of a zombie. It doesn't even have Feynman's accent, semi-decayed larynx or not.
Mythbusters is to science what tee-ball is to MLB.
Yes, they may be testing things, but no, they famously fail to prove or disprove anything with many of the tests because they don't always understand what science is and why it's how things really get tested to find out if they're real effects or illusions.
And they almost never explain the science behind a phenomenon correctly.
Actually, they built a lead and scotch-tape balloon.
A nothing-but-lead balloon that would be stable in transportation, filling, and flight would need more space and gas.
A little rigor would help them get there.
Yup. And more importantly, he knows from experimental evidence what sort of shit doesn't blow up even if the formula said it should.
Development = turning theory into reality, by removing all the parts the theory got wrong, and adding all the parts the theory left out, but only until someone says "that works for me."
For instance, if they're throwing yellow birds, you want to be in a glass house. If it's little blue birds with MIRV capability, any wood will do.
Computers were switch-and-lamp based for decades before they had the power to support character-based i/o, and even that involved manual or mechanical punching of holes in paper media.
If the CRT had come sooner than it did, and TVs had developed a pointer interface (vernier knobs and a dot and a button for selecting channel frequencies from an analog on-screen scale, for example), we might have had the mouse and GUI before we ever had text i/o, and we'd have done object orientation and GUI-centrism the right way, instead of being all scripty like we are.
Actually, as I think about it, a radio dial is an ideal example of a GUI, albeit one with only one displayable dialog.
But we went digital so hard that instead of porting over those elegant i/o modalities we decided to scale-up the digitalism and use letters and words built out of our 2-bit numbers. And we thought we were pretty smart about it, too. Now we're paying for it.
All you're getting out of that last bit is that the program doesn't have to remember its functions, the user does. So instead of starting a program, clicking on a menu, and selecting the thing I want, I have to read a manual, then start a program, telling it the thing I want.
So the manual is the menu. Only it's not part of the program. And I can't just click on the thing I find in it to make it happen, I have to go enter the words in a generic program interface (a shell prompt). Which, it turns out, did know the function after all, because that's how it matches the word to the code module to run.
So all you've done there is to add this subprocess of making the user refer to external information then copy it manually into the program that already knows it but refuses to admit it. (And no, having the full usage info dump when you do "foo --help" isn't really a fix, because the user still has to enter the command; the program, again, knows the magic word well enough to say it, and to recognize it, but doesn't know enough to just use it as an input device).
The Unix CLI did an awful job of pretending that the CLI was the API. VxWorks' shell does it somewhat more faithfully, but botches a lot of other stuff so I wouldn't recommend it as an example.
I couldn't even tell you how to get to a command line on my Android phone (though I know it's possible), and yet I can do everything I want to do on my phone.
CLI exists, the way VMS exists. But most of us, we've evolved past it.
Wouldn't it be cool if the thing before the colon were a language the CLI was expecting, not a disk-drive letter parameterizing the defaults to only a few strings you might enter on the CLI?
Bill Gates was a total idiot, except for the part where he stole that code from Seattle Micro, and then didn't sell it to IBM, which he did before he even stole it.
I swear the man has a working time machine.
I'd bet any amount of money that you were taught how logic and functions work by someone drawing pictures on a chalkboard, and then telling you how to arrange words to make that picture happen in the computer.
BTW, ever look inside a computer? They're basically drawn, then printed as drawn, from the circuit board to the CPU chip. The words in there are just so the people building them know where the pick-and-place machine screwed up.
Your process doesn't use a CLI, either.
It may use a scripting language, but there's no reason that couldn't be a programming language or a visual-programming system. Once you're done developing it, it gets stuck in a scheduler database and run by the machine with no interaction.
My answer to that was always "but it's got an e".
"Everything can be done in a GUI"
False.
Without an example, your claim is unfounded.
"I don't see why not".
True.
Of course, or I wouldn't have said so.
Can't post a screenshot here. But I can describe it.
Hold your hand up, palm facing away from you. Now fold down your first, third, and fourth fingers and lap your thumb over your folded index finger.
There. Can you see it?
I didn't read the article because I know what it says, and I've forgotten more about being a sys admin than most of the sys admins here will ever know (and that isn't just a boast it's also likely true, because i knew essentially everything about it at one time and haven't bothered much beyond personal dicking around in about 10 years).
Most of what you want to do as a sysadmin goes into CLI and scripts because that stuff was all built for CLI back when CLI was a pretty neat way to make your computer interact with you, and that stuff wasn't changed to do GUI because all of the first GUIs were just programs run from the CLI.
Until Windows did away with that. But it doesn't feel like it because of all that text that scrolls up the screen when you start your Windows machine.
You do realize, to get to a CLI on Windows these days you have to wait for the GUI to give you the opportunity to start a shell that will take CLI input, right?
As for Linux, it's basically the identical system to what existed before Windows, and the people developing for it have never thought to just do away with the CLI because then it won't be Linux at all, it will be a Linux Kernel that boots to a GUI no matter what, and all that shit in section 1 of the manual will be dead.
But even in Windows there's still CLI-isms. The way a desktop link formats the command string with options is really a DOS CLI command. It's the only way they knew how to do execution of one program from within another program, so it's how they did it. They just didn't think to do away with that methodology.
I'm thinking of ways to do away with it.
Larf!
Are you seriously pretending that a CLI can do "every possible thing"?
Can a CLI edit a movie interactively?
That's not even a mentally complicated thing. It's a very simple one. Can you imagine trying to do that from a CLI?
There are very, very good reasons that CLI's started to disappear into the back of the drawer when GUI programming got easier. And one TFA with a contrary view is not going to make even a slight dent in that. It's more likely that at some point we could do away with CLI entirely, if we can build enough self-modifiability into a GUI.
I'm not the first to think that. Look up a programming language/system called "G2". 15 years ago it was very popular for building factory-control systems, because its visual analogue to a dataflow graph was a lot like the sort of process graphs that factory designs are built from.
one that implements grep, sort, and uniq
how about you type "about:config" into your browser's address bar and hit Enter
Now you have a filter (grep), the column headings (sort), and you don't need uniq because you don't have to save the configs to a file to edit later and then be merged into the main config file, because you can just click on the configs right there and make your changes directly, which is what you really want.
Or you could take your "results.csv", which is a spreadsheet file in text form, and load it into a GUI called "Excel" or something like that, and filter it, sort it, modify it, print it, transpose it, operate on it globally or locally, change its colors, automate its cells so that several change when you change one, yadda, yadda, yadda