I had to hold my nose and paste some commands like this in order to reinstall Composer [1] and Drupal Console [2] earlier this week. Ugh, it feels so dirty, but it's often the first and/or the easiest, if not the only, way that software like this documents how it's to be installed.
None of those commands are so long that you shouldn't just be retyping them by hand. It's obviously not an ideal way to install anything, but it's much safer than copy and pasting.
for instance, if I know you are using VI I can create a series of characters that will escape out of insert mode and run a shell command (note: ^[ is ESC (ascii 27))
I ran into this for the first time just recently when installing ruby and was very surprised and hesitant to follow the instructions ( see here https://www.digitalocean.com/community/tutorials/how-to-inst... ). Glad to see people speaking out against it.
Or, for that matter, a source download. Or one you've hashed (how do you know the hash hasn't been tampered with?), a microprocessor (have you looked at the microcode? the masks), a circuit, etc.
Turtles^H^H^H^H^H^H^HTrust all the way down.
I'm not being entirely facetious, either, given the advice about disposing of electronics after visiting certain countries.
Luckily both can be installed almost as easily without the curl pipe hack... Not sure why so many projects want to reduce install steps from three to one with a shell script. I could understand if you have 90 steps (in which case I would recommend you figure out a better install process in general), but not for simple 'download something, move it to a path, run a command, and you're done'. See my roles for both of the packages you mentioned above on Ansible Galaxy for more info; I tend to avoid doing the curl pipes for sanity even more so than security.
I want to know what I'm doing with my server when I'm installing packages or other software!
On the other hand, if it's over SSL, you're just as well off as installing the software any other way. Although, I noticed the Drupal console installer isn't even on SSL.
On one hand, I'm glad people are working on easier ways to install software. On the other, everyone is ignoring distro package managers.
Docker gets it right [1] and then gets it wrong [2] - depends which set of instructions you read.
I know creating distro packages and self-hosted repos is difficult, maybe we should be attacking that as a problem instead of writing hundreds of different shell scripts.
I did a "cat >/dev/null" before pasting so I could see what it was. Clever masked/hidden content, with embedded shell commands and newline to commit the commands.
I'm not understanding this approach. Cat is for files. How would you use it to protect against this trick? Do you mean you pre-typed "> /dev/null" and then pasted his git command where the cat is?
No, I just put my terminal into a mode where I could see what I pasted without any possibility executing it. If you don't give cat any arguments, it reads from stdin and writes to stdout.
I could have just as easily opened vim/emacs/notepad and done the same, or for that matter, written the contents to an actual file instead of redirecting the contents to /dev/null.
Like many Unix commands, if you don't give cat any files to read, it reads from stdin instead. So first he runs the command (as he typed it), and then while cat is waiting for input he pastes in whatever he copied from the website.
Another handy convention is the magic "-" filename (which is not actually a file). Many tools interpret that to mean stdin/stdout. For example here is a trick to copy a tree of files:
I'm glad I asked, I wasn't realizing that `cat` would read from stdin in this case. Makes sense, given the Unix piping philosophy (which I use to great effect on buffers in vim).
But wrt your trick to copy a tree of files, what's wrong with `cp -r src dest`, or `scp -r src desthostname:/dest` if it's over a network? Is there some advantage this way?
It's not quite the same as `cp -r`. Tar will create the directories if necessary, but it will also drop the files into an existing folder hierarchy. So you could use it to create/update a few entries in an existing tree of files. For instance you could deploy updates to a website like this (locally):
cd ~/src/mysite && tar cf - . | (cd /var/www/public_html && tar xvf -)
or this (remotely):
cd ~/src/mysite && tar czf - . | ssh mysite 'tar xvzf - -C /var/www/public_html'
I would probably actually use rsync for this, but there have been times the tar approach came in handy.
A long time ago, in the dark ages of version control, I used to use tar for rollback-able deployments: I would create a tarball of the files in development to be deployed, and I would create a tarball of the files in production to be overwritten. Then I could just explode one tarball to deploy and the other to rollback. Not something I'd do today, but we didn't always have such nice tools. :-)
A good terminal should show you the full pasted text in a confirmation popup before executing it. Also should never accept new lines from a paste. Or rather; if and when the paste contains new lines, it should show a confirmation popup so you know what the hell you're executing.
Something like windows?
It should treat any newline signs in the pasted text as starts of new lines, not as "enter command". The person would need to press enter after pasting.
Why especially in open source? The leap of faith is larger with a binary blob. (Although I admit it doesn't make much difference in practice, most people don't audit source code).
I think the argument is that open source is based on the fundamental ideal of trust - I put this software out into the world so that people can better it, tweak it, make it their own. If those people don't trust you, and have to audit everything they install, the model breaks.
Re binary blobs - honestly, for me at least, if I'm installing a blob it's probably because I purchased the software. Maybe it's naive but I more or less assume no company is going to actively screw over a paying customer
> That was a bad idea. Don't copy code from websites you don't trust!
Or indeed, download software from websites you don't trust.
I guess the worry would be that hackers would, as an example, take over brew.sh and do bad stuff with installation url. As opposed to taking over brew.sh (in an alternate world where brew.sh hosts a dmg file or something) and hosting an entirely different file.
Bar the relative ease of hiding bad stuff in copy paste compared to making a fake dmg file, this seems to be basically the same situation no?
Most terminal users these days are intelligent enough not to download a random executable from a google result and run it locally under root (without researching it). We've been well inundated not to ever run sketchy programs that you've never heard of.
However, a huge portion of people (who this article is targeting), will freely copy and paste a terminal command from a random google result. That makes it a great attack vector for, say, intro to CS students who just want to make this linux thing work right.
I'm not so sure we're really capable of distinguishing between "random executable" and everything else. What do you have to go on in making the distinction? Let's say you're installing a new version of Sublime, or curl, or Chrome. These aren't 'random executables' - or are they? If someone poisons DNS, they could be. If someone MITMs them, they could be.
What about stack overflow? Surely they are trustworthy. But if someone hacks them, and inserts an attack like the OP's, then you are in trouble.
There are two problems. First, the hardware we own is almost comically powerful, both in compute and network bandwidth. Second, that same hardware mediates between us and everything that is important to us: our lovers, friends, business partners, banks, and so forth. A subtle enough hacker might get into our system and we might not know it, ever. (Indeed, if the hardware manufacturer put some secret code into their stuff then such a hack might be very subtle and very universal indeed.)
I'm not throwing my hands up and saying it's all pointless. But consider that your typical gigabyte program has a tremendous amount of surface area to check. And no, you can't discount "dumb" resources like images and videos because they aren't executable. A smart attacker will encode instructions in, say, a viral YouTube video that will trigger those hidden CPU instructions that will load a steganographically encoded program. For now we have to be practical, and not freak out. For the future, we have to move toward smaller, more efficient software that makes unexpected computation and resource usage obvious from an outside observer. This means small code, short call-chains, and minimal screen, network or disk interaction.
(I'm particularly worried by the trend for basically all software to be constantly connected to multiple unknown external hosts, any of which could be controlling code on my machine at the same level as the program I installed!)
Of course there's always going to be attack vectors, but clearly it's safer to execute a known program (Firefox) from a trusted website (firefox.com) than it is to use an unknown program (Jons Legit Calculator App) from an unknown website (some bit.ly link). Sure there's still attack vectors at play, but you've mitigated the easy ones. This is the same thing. Everyone needs to know not to go copying terminal commands unless they really trust the source. Obviously there's still a security issue there, but its significantly lower, and that's really all we can aim for.
It was somewhat hyperbolic, showing the first line of /etc/psswd. With a normal user account that doesn't actually give you much, while giving the impresion that your password has been revealed (certainly those were my first thought upon reading the message). I imediately saw there was more going into the terminal than I expected (and was surprised) but it would have needed me to actually type a password to do much harm. (OK, some securtiy expert point can probably point out where I am wrong, but as a general rule....)
Should I consider my browser betraying me by selecting stuff that's outside the viewport without a hint / warning ? (absolute positioned element, (-100,-100)). It's simply too convenient to copy/paste from the browser.
P.S. I have a paranoid habit of pasting copied text into the address bar or a notepad to quickly check for unwanted characters. For once, I don't feel like I'm crazy.
Start programming editors and you will understand. What you see in a rich text editor contains hundreds of debugging flags and formatting tweaks. When copying, you want to copy something clean which will paste nicely in Word or Excel. And you want to add some metadata, so you can trace is source if it's pasted back in one of your editors.
It's because for the browser the visual selection is not the same as the textual selection. I'd say this qualifies as a browser bug rather than a user failure. What you see is not what you get.
I think it's incredible that most of the comments here seem to accept or even defend that this is just the way things are, even explaining all the ways they work around it, rather than considering that this is a serious browser security issue and violates the idea that software should generally do what the user expects.
Aside: its not sufficient to look at a file you 'curl | bash' into bash via your browser. It is very trivial to detect curl/wget's UA (mine has: "User-Agent": "curl/7.43.0") and dynamically modify files depending on the request's UI.
if 'curl' in request.UA:
return 'something malicious'
else:
return 'something nice'
Always create a local file with the content, read it, then perhaps run it.
I'm pretty sure wget still makes it's http requests as version 1.0 rather than 1.1 (which nearly everything else uses), and if you want to change that you need to patch it.
of course. There are also other differences. Actually, I have no idea why it even matters unless you are specifically exploiting curl. And they are not in this case. You can redirect wget output to stdout too...
No. Totally possible to serve the "bad stuff" only some of the time.
Browser exploit kits commonly will return different stuff depending on user agent, and will track what IPs they have interacted with so that if after someone clicks the link you try to look at it, you'll get something harmless. Nasty business. The only way to be sure is to save it, inspect what you saved (make sure you use something that will show tricky escape sequences trying to hide things), then maybe run it.
I'm not sure why you're taking about browser exploit kits when we're talking specifically about using curl or wget to pipe an HTTP payload into a shell.
Ok. Someone posed a scenario where an attacker uses the User-Agent to differentiate between a victim vetting the URL via a regular browser and someone using curl/wget to pipe it to the shell. I suggested a simple solution to this specific scenario.
There are any number of scenarios where any given solution could be broken. Why not point out that you OS might be compromised and the wget/curl binary that you're using is patched to present the wrong information to you?
It's not changing what you copy, rather when you highlight that, it's also selecting text that you can't see because it's been positioned outside of the viewport.
Shouldn't have to be a pain? Browser plugin to paste content to editor window. Then something that runs the document its pasted into when you've read it?
However, copy, paste, (save as a script|paste in terminal), run isn't exactly the most strenuous task in the history of man either. So it'd be a fairly meaningless chain of plugins for close to zero benefit.
CTRL-X CTRL-E will take you into your editor[1] from the command line, where you can paste away and see/edit if necessary. Once you exit from the editor the commands that were entered will be run.
So (if vi): CTRL-X CTRL-E i CTRL-V[2] ESC :wq
[1] at least in bash, possibly others.
[2] or whatever your paste shortcut is, and then edit if necessary
If you bother to compose half a page on a software problem, might as well provide a solution, no?
runCb(){ cb; echo -e '\n\nGo on? (y/n)'; read -sn 1 ans; if [ "$ans" = y ]; then eval "`cb`"; else true; fi; } #cb should output the contents of your clipboard
Or another option would be to switch your terminal to editing mode (v in the normal mode of `set -o vi`), paste it there, and do `:wq` to run it.
I personally do web stuff in GUI with a mouse (I have vimium chrome extension, but old habits die hard) and select text by multitap: 60% of the time it works all the time. When it does not work I just drag-select and paste to terminal. Seems rather safe, as this does not work on this example.
tripple-tap on both urls give "git://git.kernel.org/pub/scm/utils/kup/kup.git" (with the exception that the first one contains a newline), and in such cases I am too lazy to reselect and just prepend the url with muscle memory git clone.
"Oh, and it seems that other people wrote a detailed text about this issue in 2008."
Well ... yeah. We've known about this. And yes, we need to keep making people aware. I'm also amused by all the young people and their containers: always doing things in a root shell. I'm waiting for that to implode in a few more years.
My point here is that maybe it's time we started designing some curricula around these things that people keep rediscovering: Why you do indeed want a relational database manager and probably not a 'NoSQL' store; and when you do want a NoSQL store. Multiplexing existing systems with VMs; how your VPS works and why it worked so well on mainframes back in the day. (and oh, btw did you know that you can just pull hardware, including CPUs, right out of the mainframe and it'll keep doing its job?) Dangerous things we've all done at some point and prime (hands-on) examples of the failures that might ensue...
And no, I don't mean (necessarily) to teach in schools. Maybe an online collection. "So you wanna 'do computers' without getting hacked and without re-inventing everything..."
As someone who develops high-performance systems and is continually learning, I think this is a fantastic idea!
Honestly, something that seems desperately needed as that knowledge is currently spread out among hundreds of thousands of blog posts, forums and threads -- diamonds in the rough.
I'm going to try to get something published on gumroad (and open-sourced on github) in this vein, if you're interested let me know and I'll reach out when it's done :)
Further from the main topic but related to your sentiment. One of the best ways to deal with this is to have more experienced guys who have faced these difficulties hanging around.
I am a theorist in an experimental laser group, and the group head remarked on a possible counter-intuitive arcing between two separated plates (for the sake of making an electric field) when pumping out the air in a chamber. One would expect that pumping out the air reduces the "stuff" (air) that could support a current between the plates, but due to other physics (longer mean-free path) actually allows a sweet point in which the plates can arc, possibly ruining equipment like power supplies. No one thinks about this until it happens because it's physically counter-intuitive, and its too late...it really is one of those "never happens until it happens" sort of unexpected catastrophes that even if you read it in a book, you'd probably never remember it. He said this is why it's important to have newer grad students work with senior graduate to provide continuity and experience so these mistakes don't reoccur...that, I suppose, the horrific memory of destroying expensive power supplies helps the senior grads remember it better compared to someone reading a list of warning labels in a manual...
I'm assuming if you're a small start-up, you don't have more experienced people unless you hire them. So yeah, something like the C++-faq for general hacking suggestions is fun, if someone reads it.
Not entirely sure about that; my first intuition here was "temperature and pressure do pretty similar things to chromodynamic interactions—so if materials become more conductive [or even superconductive] at low temperature, then gas media probably become more conductive [or even superconductive] at low pressures, too."
(don't want to nitpick) Chromodynamic? As in QCD? We certainly are not probing anywhere near those regimes :) Also, conductivity is not the thing to think about, arcing has to do with dielectric breakdown. I guess my loosey-goosey explanation (less stuff to support current, as in less valence electrons to get stripped off to actually make a current from negative to positive plates) confused it a little.
I made a very similar suggestion, perhaps less well articulated, just a few minutes ago on HN re: instragram v2 going to multi-DC;
When there is a write up of "We just did this super awesome scaling migration to the new hotness!" -- there will be mini-how-to articles in them... or at least more in-depth reasons why and for what problem they were specifically solving.
A how-to-wiki-gist? with "this is how you connect X with Y over ABC service in order to eliminate problem XYZ" would be great and allow for people to contribut to the how-to...
Don't jump to conclusions; my comment says nothing about sudo. There's a time to use the root shell, and a time to sudo; the key is knowing the difference. Dismissing advice because "it's never caused me a problem before" or "you don't know what you're talking about" will cause problems at some point.
If you can elucidate the reasons (plural), you need to be in a root shell, by all means use a root shell. If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience. In any case, always using a root shell is the Wrong Thing To Do.
>Don't jump to conclusions; my comment says nothing about sudo
Yeah sure this has nothing to do with sudo. Right, gotcha.
> If you can elucidate the reasons (plural)
"Reasons" means plural where I come from(denoted by the "s"). There is no reason to repeat yourself. I decline your request for an elaboration. The "don't use a root shell crowd" has clearly won the popularity contest in the same way TSA now has a significant presence at larger US airports.
> If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience.
Don't jump to conclusions. There are few people here who can truthfully claim more experience than I could. Regardless of our experience levels, it bears no weight in the validity of my statement.
> In any case,
Not really.
> always using a root shell is the Wrong Thing To Do.
Generally I take a "Trust, but Verify" approach to most everything, and luckily, modern browsers have a nifty "search google for..." context menu option that lets me check anything that I highlight out on google (what a wonderful world), so the second I right clicked on what was highlighted the 'hidden' content was revealed.
Another reason against copy-pasting from the web is using unicode characters that look like ASCII ones. This was on HN a week or so ago, but it doesn't hurt to repeat.
Example shell command:
eⅽho 'hello world'
Copy-pasting the above command will fail with the message `eⅽho: command not found`. The reason? 'ⅽ' in 'eⅽho' is a unicode character "SMALL ROMAN NUMERAL ONE HUNDRED" that looks identical to regular ascii 'c'.
The above can also be mis-used for any programming language, not just shell commands.
There are some good clipboard viewers on most platforms. I've used Butler on OS X, Klipper on Linux w/ KDE, and Ditto on Windows. A quick keyboard shortcut will show you what's in your clipboard and tons of recent clipboard entries.
This is properly viewed as a bug in bash (and most other shells). Shells can tell terminals to do "bracketed paste": the start and end of a pasted block is marked with escape sequences. The correct behavior is to use bracketed paste, and to treat newlines inside pastes as multiline text input, not as a ready-to-execute signal.
Apparently that hasn't happened because of compatibility problems with broken terminals, plus perhaps a bit of work that no one's stepped up to do. If anyone wants to tackle this, the GNU readline library would be the place to do it.
Bracketed paste can save you from accidental damage, but not from malicious pastes. As the fine article says, the end sequence can be inside the text you paste unless your terminal emulator filters out the bracketed paste characters (and last time I checked, at least urxvt didn't).
Besides, teaching shell about bracketed paste could only help for pasting directly to shell; it won't help if you're pasting to vim (think of "^[:q!echo pwned^J") or cat (think of "^Decho pwned^J").
Ok, sounds like it's two bugs - terminals definitely shouldn't pass through a bracketed paste end-marker, and probably shouldn't pass any control characters at all (ie, no esc or ^D). Passing special control characters through the clipboard is already unreliable, so I don't think this change would break anything legitimate.
For those trying to find it...the added code is injected in the space character between "git clone" and "git://git.kernel.org/pub/scm/utils/kup/kup.git"
256 comments
[ 3.3 ms ] story [ 259 ms ] threadI had to hold my nose and paste some commands like this in order to reinstall Composer [1] and Drupal Console [2] earlier this week. Ugh, it feels so dirty, but it's often the first and/or the easiest, if not the only, way that software like this documents how it's to be installed.
1. https://getcomposer.org/doc/00-intro.md#globally
2. http://drupalconsole.com
for instance, if I know you are using VI I can create a series of characters that will escape out of insert mode and run a shell command (note: ^[ is ESC (ascii 27))
git status
^[
:!echo foo
The real problem is that this is nothing different than trusting a binary download -- which many more millions (billions) do.
Turtles^H^H^H^H^H^H^HTrust all the way down.
I'm not being entirely facetious, either, given the advice about disposing of electronics after visiting certain countries.
I want to know what I'm doing with my server when I'm installing packages or other software!
On the other hand, if it's over SSL, you're just as well off as installing the software any other way. Although, I noticed the Drupal console installer isn't even on SSL.
Docker gets it right [1] and then gets it wrong [2] - depends which set of instructions you read.
I know creating distro packages and self-hosted repos is difficult, maybe we should be attacking that as a problem instead of writing hundreds of different shell scripts.
1: https://docs.docker.com/engine/installation/ubuntulinux/
2: https://docs.docker.com/v1.8/installation/ubuntulinux/#insta...
Bonus: https://twitter.com/mjg59/status/655812609715769349
I did a "cat >/dev/null" before pasting so I could see what it was. Clever masked/hidden content, with embedded shell commands and newline to commit the commands.
I could have just as easily opened vim/emacs/notepad and done the same, or for that matter, written the contents to an actual file instead of redirecting the contents to /dev/null.
Another handy convention is the magic "-" filename (which is not actually a file). Many tools interpret that to mean stdin/stdout. For example here is a trick to copy a tree of files:
But wrt your trick to copy a tree of files, what's wrong with `cp -r src dest`, or `scp -r src desthostname:/dest` if it's over a network? Is there some advantage this way?
A long time ago, in the dark ages of version control, I used to use tar for rollback-able deployments: I would create a tarball of the files in development to be deployed, and I would create a tarball of the files in production to be overwritten. Then I could just explode one tarball to deploy and the other to rollback. Not something I'd do today, but we didn't always have such nice tools. :-)
as:
git status
^D
echo foo
Then switches to running things in the terminal. We already saw your 'trick' in step 1 when viwed in our Snippets Notepad file...
Re binary blobs - honestly, for me at least, if I'm installing a blob it's probably because I purchased the software. Maybe it's naive but I more or less assume no company is going to actively screw over a paying customer
> That was a bad idea. Don't copy code from websites you don't trust!
Or indeed, download software from websites you don't trust.
I guess the worry would be that hackers would, as an example, take over brew.sh and do bad stuff with installation url. As opposed to taking over brew.sh (in an alternate world where brew.sh hosts a dmg file or something) and hosting an entirely different file.
Bar the relative ease of hiding bad stuff in copy paste compared to making a fake dmg file, this seems to be basically the same situation no?
However, a huge portion of people (who this article is targeting), will freely copy and paste a terminal command from a random google result. That makes it a great attack vector for, say, intro to CS students who just want to make this linux thing work right.
What about stack overflow? Surely they are trustworthy. But if someone hacks them, and inserts an attack like the OP's, then you are in trouble.
There are two problems. First, the hardware we own is almost comically powerful, both in compute and network bandwidth. Second, that same hardware mediates between us and everything that is important to us: our lovers, friends, business partners, banks, and so forth. A subtle enough hacker might get into our system and we might not know it, ever. (Indeed, if the hardware manufacturer put some secret code into their stuff then such a hack might be very subtle and very universal indeed.)
I'm not throwing my hands up and saying it's all pointless. But consider that your typical gigabyte program has a tremendous amount of surface area to check. And no, you can't discount "dumb" resources like images and videos because they aren't executable. A smart attacker will encode instructions in, say, a viral YouTube video that will trigger those hidden CPU instructions that will load a steganographically encoded program. For now we have to be practical, and not freak out. For the future, we have to move toward smaller, more efficient software that makes unexpected computation and resource usage obvious from an outside observer. This means small code, short call-chains, and minimal screen, network or disk interaction.
(I'm particularly worried by the trend for basically all software to be constantly connected to multiple unknown external hosts, any of which could be controlling code on my machine at the same level as the program I installed!)
P.S. I have a paranoid habit of pasting copied text into the address bar or a notepad to quickly check for unwanted characters. For once, I don't feel like I'm crazy.
Copy-Paste as WYSIWYG should be default, Copy-Special should be an expert-only option.
As other have suggested, there are still possible ways to trick you, but it's getting more and more remote.
Browser exploit kits commonly will return different stuff depending on user agent, and will track what IPs they have interacted with so that if after someone clicks the link you try to look at it, you'll get something harmless. Nasty business. The only way to be sure is to save it, inspect what you saved (make sure you use something that will show tricky escape sequences trying to hide things), then maybe run it.
There are any number of scenarios where any given solution could be broken. Why not point out that you OS might be compromised and the wget/curl binary that you're using is patched to present the wrong information to you?
https://ma.ttias.be/terminal-escape-sequences-the-new-xss-fo...
http://joeyh.name/code/moreutils/
However, copy, paste, (save as a script|paste in terminal), run isn't exactly the most strenuous task in the history of man either. So it'd be a fairly meaningless chain of plugins for close to zero benefit.
So (if vi): CTRL-X CTRL-E i CTRL-V[2] ESC :wq
[1] at least in bash, possibly others.
[2] or whatever your paste shortcut is, and then edit if necessary
Edit: seems this is also possible for zsh but needs some config first: http://nuclearsquid.com/writings/edit-long-commands/
Try copying the Hello World text in this fiddle and paste it in a text editor:
http://jsfiddle.net/teleclimber/8q6sp5ga/
(Tested in Chrome)
tripple-tap on both urls give "git://git.kernel.org/pub/scm/utils/kup/kup.git" (with the exception that the first one contains a newline), and in such cases I am too lazy to reselect and just prepend the url with muscle memory git clone.
"Oh, and it seems that other people wrote a detailed text about this issue in 2008."
Well ... yeah. We've known about this. And yes, we need to keep making people aware. I'm also amused by all the young people and their containers: always doing things in a root shell. I'm waiting for that to implode in a few more years.
My point here is that maybe it's time we started designing some curricula around these things that people keep rediscovering: Why you do indeed want a relational database manager and probably not a 'NoSQL' store; and when you do want a NoSQL store. Multiplexing existing systems with VMs; how your VPS works and why it worked so well on mainframes back in the day. (and oh, btw did you know that you can just pull hardware, including CPUs, right out of the mainframe and it'll keep doing its job?) Dangerous things we've all done at some point and prime (hands-on) examples of the failures that might ensue...
And no, I don't mean (necessarily) to teach in schools. Maybe an online collection. "So you wanna 'do computers' without getting hacked and without re-inventing everything..."
Honestly, something that seems desperately needed as that knowledge is currently spread out among hundreds of thousands of blog posts, forums and threads -- diamonds in the rough.
I'm going to try to get something published on gumroad (and open-sourced on github) in this vein, if you're interested let me know and I'll reach out when it's done :)
I am a theorist in an experimental laser group, and the group head remarked on a possible counter-intuitive arcing between two separated plates (for the sake of making an electric field) when pumping out the air in a chamber. One would expect that pumping out the air reduces the "stuff" (air) that could support a current between the plates, but due to other physics (longer mean-free path) actually allows a sweet point in which the plates can arc, possibly ruining equipment like power supplies. No one thinks about this until it happens because it's physically counter-intuitive, and its too late...it really is one of those "never happens until it happens" sort of unexpected catastrophes that even if you read it in a book, you'd probably never remember it. He said this is why it's important to have newer grad students work with senior graduate to provide continuity and experience so these mistakes don't reoccur...that, I suppose, the horrific memory of destroying expensive power supplies helps the senior grads remember it better compared to someone reading a list of warning labels in a manual...
I'm assuming if you're a small start-up, you don't have more experienced people unless you hire them. So yeah, something like the C++-faq for general hacking suggestions is fun, if someone reads it.
Not entirely sure about that; my first intuition here was "temperature and pressure do pretty similar things to chromodynamic interactions—so if materials become more conductive [or even superconductive] at low temperature, then gas media probably become more conductive [or even superconductive] at low pressures, too."
When there is a write up of "We just did this super awesome scaling migration to the new hotness!" -- there will be mini-how-to articles in them... or at least more in-depth reasons why and for what problem they were specifically solving.
A how-to-wiki-gist? with "this is how you connect X with Y over ABC service in order to eliminate problem XYZ" would be great and allow for people to contribut to the how-to...
But we've been saying this for 15+ years... :-)
Ah yes. The sudo high horse. I knew I'd see you again.
Viva La #
If you can elucidate the reasons (plural), you need to be in a root shell, by all means use a root shell. If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience. In any case, always using a root shell is the Wrong Thing To Do.
Yeah sure this has nothing to do with sudo. Right, gotcha.
> If you can elucidate the reasons (plural)
"Reasons" means plural where I come from(denoted by the "s"). There is no reason to repeat yourself. I decline your request for an elaboration. The "don't use a root shell crowd" has clearly won the popularity contest in the same way TSA now has a significant presence at larger US airports.
> If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience.
Don't jump to conclusions. There are few people here who can truthfully claim more experience than I could. Regardless of our experience levels, it bears no weight in the validity of my statement.
> In any case,
Not really.
> always using a root shell is the Wrong Thing To Do.
You are free to hold whatever opinion you wish.
If you click outside the text and drag across it, this page makes a lot more sense.
Example shell command:
Copy-pasting the above command will fail with the message `eⅽho: command not found`. The reason? 'ⅽ' in 'eⅽho' is a unicode character "SMALL ROMAN NUMERAL ONE HUNDRED" that looks identical to regular ascii 'c'.The above can also be mis-used for any programming language, not just shell commands.
Apparently that hasn't happened because of compatibility problems with broken terminals, plus perhaps a bit of work that no one's stepped up to do. If anyone wants to tackle this, the GNU readline library would be the place to do it.
Besides, teaching shell about bracketed paste could only help for pasting directly to shell; it won't help if you're pasting to vim (think of "^[:q!echo pwned^J") or cat (think of "^Decho pwned^J").
https://news.ycombinator.com/item?id=4247566
TL:DR "Just paste this obscure python code into the console!"
I'm still surprised, looking back at that thread today.