I like to think that my contact lenses give me cyborg eyes (eg. technology that is so integrated with a person that it becomes an extension of their own body, while offering enhanced capabilities) - not only do they give me perfect vision but they're also UV protective:)
Plus I use dailies so I don't have to worry about cleaning or losing them.
Can't be doing with contact lenses though. Went for a trial, couldn't even keep my eye open for them to put the test lens in, so that was the end of that. Ugh, actually putting something on to the surface of one's eye? *shudder*
There's a trick I use where instead of going straight for the pupil (damn brain's all like "nope!" and shuts my eyelid), I place it to one side then shift it round a bit. A few blinks later and it's centred itself. Again to take it off I shift it round first before grabbing at it so my eye doesn't see my finger while I'm doing it.
Here are tons of smart people, I don't see anybody talking about training eyes - recovering without surgery. but I know that I it is possible to get very good results without altering your body irreversible.
Becquerels are tiny units. In the first 3 months after the accident 14 Quadrillion (1.5x10^16) becquerels were released. For comparison Chernobyl released 14 Quintillion (1.4x10^19) becquerels in total. (source).
Compared to that, 1 trillion (1.1x10^12) becquerels is a big improvement in rate of release and according to Wolfram Alpha represents around 300mg of Cs-137.
I'm not convinced webP is better, I've done a quick comparison and to my eyes JPEG beats it on like for like file sizes:
40k jpeg vs 40k webP (images converted to png for your viewing convenience)
Compared to the lossless original (one of Google's own webP comparison images) the webP version has lost more chroma resolution, leading to desaturation in parts and blurring of strong colour details like the red arm band.
It would be nice as a replacement for PNGs with alpha channels though.
The number 1 priority of the Raspberry Pi foundation was a price of $35 and $25 for the 2 models, as that's the price they determined people would pay for a "disposable" computer for kids. Everything else is secondary, that's why all those more powerful clones out there end up costing more.
It's more like the Sikorsky X2. The dual rotors are an important feature; With a single rotor as you increase forward speed you lose lift on one side of the rotor as it slower relative airspeed, until it's basically going backwards. Having contra-rotating rotors means that one side will always have blades going "forwards" regardless of airspeed.
I have no idea what the solution is, but I suspect that we need to do some fundamental rethinking of secure architectures and user interfaces. Architectures need to more safely isolate data and logical functionality, and interfaces need to more safely mediate users interaction with devices. I confidently assert that the current architectures simply can't be secured, no matter how much junk is kludged to the task. Prove me wrong, please.
On the other hand this specific issue could be easily solved by * prefixing all filenames with./
So far I've not heard of anything that would break, and it's silly arguing that this specific problem is part of required functionality and not something that can/should be fixed when it appears to have such a simple solution.
Since one is root, one can do anything anyway so why bother with all this misdirection?
Because you can trick a more privileged user into executing commands for you by writing files into your own folder. Most the examples given were of admin housekeeping tasks run against a user writeable folder.
If computers were conceived to execute user commands, then why is a command for matching file and dictionary names returning them in such a form that they become executable parameters, when they could easily be explicit filenames by adding./ at the beginning?
Is making what should be basic and safe housekeeping functions like chmod * and tar * dangerous really something you actually want in Linux?
Right, so an admin tarballing the content of a user's folder is an idiot because he didn't check to make sure the shell he was using wouldn't pass any of the file names as executable attributes instead of, you know, file names?
The one line summary for this story is bad things happen to people who use a command without knowing what the command does.
The definition of the unix wildcard when used in the shell is:
"The character * is a wildcard and matches zero or more character(s) in a file (or directory) name."
Note that the definition doesn't include anything about translate filenames into other kinds of executable parameters.
Probably because anybody who's used the various Bourne-style shells for a while considers it a feature, not a bug. This is a case where the Principle of Least Surprise comes up with different answers for novice users and for experts: "What? A * can expand into an unintended command argument?" "Yeah, what *else* would it do - the shell is just globbing, it doesn't know for sure what the command will do with the parameter".
Who asked for this feature? Can anyone give me a legitimate use case for "tar cf archive.tar *" evaluating as
tar cf archive.tar admin.php ado.php --checkpoint=1 "--checkpoint-action=exec=sh shell.sh"
instead of
tar cf archive.tar "./admin.php" "./ado.php" "./--checkpoint=1" "./--checkpoint-action=exec=sh shell.sh"
Slashdot Mirror
Hardly being blasted by a jet afterburner though is it?
I like to think that my contact lenses give me cyborg eyes (eg. technology that is so integrated with a person that it becomes an extension of their own body, while offering enhanced capabilities) - not only do they give me perfect vision but they're also UV protective :)
Plus I use dailies so I don't have to worry about cleaning or losing them.
Can't be doing with contact lenses though. Went for a trial, couldn't even keep my eye open for them to put the test lens in, so that was the end of that. Ugh, actually putting something on to the surface of one's eye? *shudder*
There's a trick I use where instead of going straight for the pupil (damn brain's all like "nope!" and shuts my eyelid), I place it to one side then shift it round a bit. A few blinks later and it's centred itself. Again to take it off I shift it round first before grabbing at it so my eye doesn't see my finger while I'm doing it.
Here are tons of smart people, I don't see anybody talking about training eyes - recovering without surgery. but I know that I it is possible to get very good results without altering your body irreversible.
Maybe because all the medical studies done on vision training for myopia have failed to find any evidence that it has any physical effect?
Are you confusing it with vision therapy for eye movement and co-ordination disorders?
> Ever lose a lens or contact?
I use daily contact lenses so when I lose one it's only around 50p wasted :)
1 trillion Bq is about 0.3g worth of Cs-137.
You wouldn't want to swallow it, but it's not going to be "cooking" anything.
Becquerels are tiny units. In the first 3 months after the accident 14 Quadrillion (1.5x10^16) becquerels were released. For comparison Chernobyl released 14 Quintillion (1.4x10^19) becquerels in total. (source).
Compared to that, 1 trillion (1.1x10^12) becquerels is a big improvement in rate of release and according to Wolfram Alpha represents around 300mg of Cs-137.
I'm not convinced webP is better, I've done a quick comparison and to my eyes JPEG beats it on like for like file sizes:
40k jpeg vs 40k webP (images converted to png for your viewing convenience)
Compared to the lossless original (one of Google's own webP comparison images) the webP version has lost more chroma resolution, leading to desaturation in parts and blurring of strong colour details like the red arm band.
It would be nice as a replacement for PNGs with alpha channels though.
The number 1 priority of the Raspberry Pi foundation was a price of $35 and $25 for the 2 models, as that's the price they determined people would pay for a "disposable" computer for kids. Everything else is secondary, that's why all those more powerful clones out there end up costing more.
Integrated audio is a bit of a running joke, see Goat Simulator system requirements...
US patent D690249, granted on September 24, 2013 to Mark Finnie of La Palma, California, for a “Motorcycle wheel with seven bifurcated spokes”.
But that's a design patent which just protects the cosmetic look of the product, which is perfectly legitimate for designer alloy wheels.
It's more like the Sikorsky X2. The dual rotors are an important feature; With a single rotor as you increase forward speed you lose lift on one side of the rotor as it slower relative airspeed, until it's basically going backwards. Having contra-rotating rotors means that one side will always have blades going "forwards" regardless of airspeed.
Is it really a single board computer, if the SoC is on a separate board?
Looks more like a mini, more powerful version of the Raspberry Pi Compute Module with a Raspberry Pi like breakout board.
Those SoC modules themselves could be useful on their own if they sell the sockets to use on custom circuit boards...
Hmm, good point, didn't think of messing around with filenames in a for loop.
* could still use ./ as an escape code just for files beginning with - , that seems to me to be more of a step forward than a step back
... is there an example you can point to?
I have no idea what the solution is, but I suspect that we need to do some fundamental rethinking of secure architectures and user interfaces. Architectures need to more safely isolate data and logical functionality, and interfaces need to more safely mediate users interaction with devices. I confidently assert that the current architectures simply can't be secured, no matter how much junk is kludged to the task. Prove me wrong, please.
On the other hand this specific issue could be easily solved by * prefixing all filenames with ./
So far I've not heard of anything that would break, and it's silly arguing that this specific problem is part of required functionality and not something that can/should be fixed when it appears to have such a simple solution.
The problem is that the * expansion is done by the shell, and the shell doesn't know the difference between file names and arguments.
But it could very easily make them explicit filenames by prefixing them with ./, and I can't think of anything that would break.
This is because the linux commands do not respect what the manual says:
man rm...
rm [OPTION]... FILE...
but in realitiy it's rather:
rm [OTION|FILE]...
And what happens if the malicious filename is first in the list?
Since one is root, one can do anything anyway so why bother with all this misdirection?
Because you can trick a more privileged user into executing commands for you by writing files into your own folder. Most the examples given were of admin housekeeping tasks run against a user writeable folder.
If computers were conceived to execute user commands, then why is a command for matching file and dictionary names returning them in such a form that they become executable parameters, when they could easily be explicit filenames by adding ./ at the beginning?
Is making what should be basic and safe housekeeping functions like chmod * and tar * dangerous really something you actually want in Linux?
Is a basic feature of how unix shells work, and there's no way to change it.
How about adding ./ to the beginning of each filename output by *? Is there a single thing that would break by doing that?
The examples given are potential admin tasks doing filesystem maintenance on a user's folder.
Right, so an admin tarballing the content of a user's folder is an idiot because he didn't check to make sure the shell he was using wouldn't pass any of the file names as executable attributes instead of, you know, file names?
The one line summary for this story is bad things happen to people who use a command without knowing what the command does.
The definition of the unix wildcard when used in the shell is:
"The character * is a wildcard and matches zero or more character(s) in a file (or directory) name."
Note that the definition doesn't include anything about translate filenames into other kinds of executable parameters.
Probably because anybody who's used the various Bourne-style shells for a while
considers it a feature, not a bug. This is a case where the Principle of Least
Surprise comes up with different answers for novice users and for experts:
"What? A * can expand into an unintended command argument?" "Yeah, what *else*
would it do - the shell is just globbing, it doesn't know for sure what the
command will do with the parameter".
Who asked for this feature? Can anyone give me a legitimate use case for "tar cf archive.tar *" evaluating as
tar cf archive.tar admin.php ado.php --checkpoint=1 "--checkpoint-action=exec=sh shell.sh"
instead of
tar cf archive.tar "./admin.php" "./ado.php" "./--checkpoint=1" "./--checkpoint-action=exec=sh shell.sh"
That's not true, unless you're talking about building a large receiver right next to their transmitter and physically blocking the signal.