"to use a single, vertically oriented digital camera with a hyperboloid mirror in front of it,"
Assuming that you mean a camera with a lens looking into the hyperboloid reflector: that would not work because such a mirror would not produce a real or virtual image plane onto which the camera could focus. Parabolic or hyperbolic reflectors can only image a point to another (virtual) point, not a plane to a plane.
In other words, you get a blurry image; in order to unblur, you would need to know the angular distribution of light intensity on each pixel; if you had such a sensor, you could just as well leave out the lens.
The blurring might be manageable if the lens is small (like a phone camera) and the reflector is very large (like a meter), but then you'd run into problems with sensor noise and resolution for a 360 degree image and there woild be no gain in portability.
There was a "study" that claimed this (coal power emits more radioactivity), but for the comparison they took the most radioactive coal that exists, orders of magnitude higher than average.
Moreover, there is no point in comparing against emitted radioactivity from a correctly functioning nuclear plant, as it is pretty close to zero. The problem is when a nuke breaks.
force equals *mass* times acceleration.... the acceleration would be the same but the force experienced by Curiosity's tires would be ~3x larger (ignoring any shock absorption).
You do have a point -- I don't agree with some of the other responders who talk about traction forces being smaller as well. Just to make it clear: what you say applies to a cart on wheels, having constant horizontal velocity and approaching a bump in an otherwise flat surface. A larger mass of the cart will result in a larger force at the wheels the moment the cart hits the bump, regardless of gravity.
However, this force is roughly F = m v^2/L, where v is the horizontal velocity of the cart, L is the travel of the suspension, and m is the moving mass. The moving mass can be just a single wheel; in that case L is the leeway in the tire rubber (less than a millimeter), or m can refer to the entire car, with L the travel of the wheel suspension.
Now, the issue of inertia is only relevant if the instantaneous extra force is larger than the gravitational force. Given that this Mars Rover has a maximum speed of 0.025 m/s, the maximum inertia-driven acceleration is about 1 m/s^2, even assuming only 0.5 mm of suspension travel. This is much less than the gravitational acceleration (10 m/s^2); therefore inertia does not make a significant difference in the wear on the wheels.
In Europe... So no tipping in many places (or minimal tipping) as people get payed by their boss for the work that they do.
You can't generalize that across all of Europe, unless "minimal tipping" means anything less than 15% in a restaurant. Tipping conventions vary quite a bit over Europe (based on the travel guides that I've seen). And for instance, in the UK, the 10% service charge on restaurant bills seems to be optional in some cases, although I don't visit the UK often enough to grasp the substle details here.
Probably you as an AC won't read this two days later, but I don't understand why you changed the subject from "in the 1490's" into the present one, in response to my post. The original subject is a reference to Columbus (that's earlier than Galileo) and in that era the only other Christian church would have been the Eastern Orthodox church.
"you can do the same thing with the European system. On the receipt you just have to break down the advertised 9.95 Euro price into merchandise and taxes."
The national sales tax (VAT, or the local-language equivalent) is always printed on the receipt in the EU. Other taxes that come to mind: tourist tax on hotel stays, which is also printed on the receipt (city-dependent fee, not always listed up-front) and "extra costs" on plane tickets which used to be treacherous but must be included in the ticket price nowadays.
There are special tariffs/duties on things like alcohol and cigarettes, but I've never seen them stated explicitly, not even in an airport duty-free shop.
"official church dogma that this was not true, and this created a climate where openly saying the earth was round was not exactly a safe position to take."
The church dogma wasn't about whether the earth was round ot not, but about whether the sun revolved around the earth or the other way around.
the encryption approach is the right one. It's fast, easy and much harder to circumvent.
If you are paranoid enough to encrypt the data locally after receipt at the phone, then you had better also examine the how the sender and the snapchat server deal with the data. Better setup a public-key system and figure out how to do the key management without discouraging Joe and Jane User.
Due to wear-leveling and the likes that is not good enough for data that is supposed to be gone forever.
You're presenting it as an all-or-nothing issue. There are a couple of shades of gray in between. The internal storage of Android devices is typically formatted as ext4, wtih the wear-leveling (I think) done by the flash memory controller. Accessing the "overwritten" data would require quite a bit more work than just analyzing a block-device image. I suspect that you might have to desolder the NAND memory modules.
And even if the file is deleted but not overwriten, I don't think it's that easy to find the right blocks in the correct sequence; compressed JPEG data past the header data looks pretty much like random data.
Maybe cheating husbands and wives who don't want to leave too many trails. Although I'd be rather suspicious if my significant other had Snapchat installed on her phone...
"cool the air to -78C and then collect the solid precipitate."
At that temperature, the vapor pressure is equal to atmospheric pressure. It would be like measuring the water content of air by cooling to just below 100 C.
any good reason not to use UDF for large flash cards?
I have no personal experience here, but this UDF compatibility matrix does not look too promising. Apparently there are five UDF versions and three variants within each version, and only the oldest versions (from 1996-1997) actually have wide OS support.
"What remains: not much, really. Some glass, stone, metals. Not much that burns well."
I'm not sure what country you're describing, but here in the Netherlands, we separate paper, glass, plastic packaging (PE, PET, PP, PS), organic waste, electrical equipment, chemical waste. Stones (e.g. from breaking down a wall) are not supposed to be mixed with household waste. Laminated materials such as potato crisp bags and milk cartons, styrofoam, discarded household items go into the "other waste" bin. I'm not sure whether I'm supposed to, but plastic with food scraps sticking onto it don't make it to my plastics container since I don't want them to rot and smell. My trash bags will burn pretty well.
For the Netherlands, I think company offices are a big contributor to incinerable waste. They separate the paper, but not the plastics. Many company restaurants are not separating compostable waste from what the employees leave on their trays.
I see the upside of SMS'es costing the sender money: it throttles the rate of incoming messages. I fear the day that the spammers figure out how to use Whatsapp for massive spam runs.
Too bad that here in Netherlands the telcos are moving to unlimited-SMS plans due to competition with Whatsapp...
tell me you are not this dumb!... ridiculous... If you are not a complete retard... nutcase born-again Christian... morons... mathematically retarded and should be removed
Rational arguments could be more convincing than strong language and ad-hominem attacks.
Unfortunately, it looks like there is no simple way to reduce CO2 emissions. Just saying "just cut all the CO2 sources except the my car, my airconditioning, and my incandescent bulbs" is a bit too easy.
I'm glad they aren't using MD5, but wish they were using at least SHA-256
What kind of security flaws do MD5 and SHA-1 have that are relevant for password hashing? As far as I understand, those weaknesses are about attackers who may specially craft pairs of messages (passwords) that have the same hash, not about constructing a message that will generate a given hash without prior knowledge of the message.
The main thing that matters is how much effort it is to find a password by brute force and in that sense, you should use no hash algorithm that is designed for computational efficiency (as explained by your bcrypt link).
That said: I used to have an encrypted home directory on a netbook with an Atom processor; the encrypted filesystem (ecryptfs) used some kind of slow hash function -- that would generate about 5 seconds delay upon login and even upon unlocking the screen. So, take it easy with those slow hash functions...
what URL? what webserver? won't work over ssh. wont work OVER your connection. it has to work VIA it to be feasible.
I'm using Gnome 2 and Compiz, so I'm not sure whether this translates to your platform, but in the Gnome file manager I can enter sftp://username@hostname:/home/username/foo.jpg . I guess the problem is figuring out as which hostname the server is accessible, which will probably mean an old-style ~/.tyls configuration file ("When logged in from 192.168.1.14, then prefix the pathnames with sftp://bob@192.168.1.5/"). Since this is completely separate from Terminology itself, one could implement this right now as a lightweight Perl script that can run on a NAS.
now to display a thumbnail i could have tyls generate small low res thumbs itself and embed the thumbnail image inside escape
Well, for remote hosts I think a generic "This is an image" or "this is a video clip" icon should do, otherwise you might be sending huge amounts of data over a 1 Mbps data connection.
I just had a look at tyls.c; it looks to me like the escape codes have the filename and a generic icon identifier ("like "application-x-tar") embedded, or no icon identifier if it is a media file. I assume that the terminal client then looks up the file and generates the thumbnail.
Why is it infeasible to use URIs rather than pathnames, so that the terminal can fetch the data? I understand that it's more work than adding three lines of code, but your wording "Haven't figured out how to sensibly do it remotely." sounds like there is a more fundamental problem.
Doesn't work over a remote shell. Has to be local atm. Haven't figured out how to sensibly do it remotely.
Do you say this as a beta tester or as a developer?
I suppose that one could implement the 'tyls' replacement for ls without all the GUI libraries (probably a 20 line perl script could do the job). Maybe without thumbnails, but at least with hyperlinked filenames. If the filenames are then encoded as, e.g., sftp://host/path/foo.jpg, then it would not be too hard to implement a handler inside terminology.
have you tried mounting the remote location and streaming with sshfs?
Yes, I tried. But things like mass re-tagging media (ogg vorbis) files are very slow if the actual file content needs to be sent back and forth over wi-fi, compared to doing the file operations locally on the media server.
I wonder whether it works if you ssh into another machine. I have been wanting something like that while logged into my media server, which doesn't have X11 applications installed. It's not mentioned in the feature list and I can't judge whether the underlying architecture would allow tunneling these functions over ssh to a box that doesn't have enlightenment installed. I'd think that a special ssh client on the client side would suffice to have simultaneous channels for command-line data and multimedia data to the host machine.
I wonder how the write times change when they become over-write times, and sectors have to be erased before they can be written.
I'm surprised no one else responded to this; TFA didn't mention it either; I recall having experienced a significant performance difference between a new and a used USB stick in the past.
I happened to have an unused USB stick (SanDisk, 4 GB) lying around, so here are the test results I get right now. Out of the box, it takes about 4 seconds to write 40 MiB, using the command
time sh -c 'cp/tmp/random_data_40MiB/media/FBDD-DDE3/rnd40M-3; sync'
Strangely, sustained writes (looping the above command) are about a factor 2 slower; maybe there is some cooling-down time to prevent overheating of the flash chip? After filling up the entire USB stick and deleting all the files again, there is no difference in performance compared to when it was fresh: 10 MiB/s for a burst write and 5 MiB/s for sustained writes.
That was my whole point: if the blanket is truly reflective for infrared, it doesn't matter much what temperature the blanket is. The problem is that usually only one side is reflective; the other side is not reflective at for thermal radiation.
Slashdot Mirror
"to use a single, vertically oriented digital camera with a hyperboloid mirror in front of it,"
Assuming that you mean a camera with a lens looking into the hyperboloid reflector: that would not work because such a mirror would not produce a real or virtual image plane onto which the camera could focus. Parabolic or hyperbolic reflectors can only image a point to another (virtual) point, not a plane to a plane.
In other words, you get a blurry image; in order to unblur, you would need to know the angular distribution of light intensity on each pixel; if you had such a sensor, you could just as well leave out the lens.
The blurring might be manageable if the lens is small (like a phone camera) and the reflector is very large (like a meter), but then you'd run into problems with sensor noise and resolution for a 360 degree image and there woild be no gain in portability.
There was a "study" that claimed this (coal power emits more radioactivity), but for the comparison they took the most radioactive coal that exists, orders of magnitude higher than average.
Moreover, there is no point in comparing against emitted radioactivity from a correctly functioning nuclear plant, as it is pretty close to zero. The problem is when a nuke breaks.
You do have a point -- I don't agree with some of the other responders who talk about traction forces being smaller as well. Just to make it clear: what you say applies to a cart on wheels, having constant horizontal velocity and approaching a bump in an otherwise flat surface. A larger mass of the cart will result in a larger force at the wheels the moment the cart hits the bump, regardless of gravity.
However, this force is roughly F = m v^2/L, where v is the horizontal velocity of the cart, L is the travel of the suspension, and m is the moving mass. The moving mass can be just a single wheel; in that case L is the leeway in the tire rubber (less than a millimeter), or m can refer to the entire car, with L the travel of the wheel suspension.
Now, the issue of inertia is only relevant if the instantaneous extra force is larger than the gravitational force. Given that this Mars Rover has a maximum speed of 0.025 m/s, the maximum inertia-driven acceleration is about 1 m/s^2, even assuming only 0.5 mm of suspension travel. This is much less than the gravitational acceleration (10 m/s^2); therefore inertia does not make a significant difference in the wear on the wheels.
You can't generalize that across all of Europe, unless "minimal tipping" means anything less than 15% in a restaurant. Tipping conventions vary quite a bit over Europe (based on the travel guides that I've seen). And for instance, in the UK, the 10% service charge on restaurant bills seems to be optional in some cases, although I don't visit the UK often enough to grasp the substle details here.
Probably you as an AC won't read this two days later, but I don't understand why you changed the subject from "in the 1490's" into the present one, in response to my post. The original subject is a reference to Columbus (that's earlier than Galileo) and in that era the only other Christian church would have been the Eastern Orthodox church.
"you can do the same thing with the European system. On the receipt you just have to break down the advertised 9.95 Euro price into merchandise and taxes."
The national sales tax (VAT, or the local-language equivalent) is always printed on the receipt in the EU. Other taxes that come to mind: tourist tax on hotel stays, which is also printed on the receipt (city-dependent fee, not always listed up-front) and "extra costs" on plane tickets which used to be treacherous but must be included in the ticket price nowadays.
There are special tariffs/duties on things like alcohol and cigarettes, but I've never seen them stated explicitly, not even in an airport duty-free shop.
"official church dogma that this was not true, and this created a climate where openly saying the earth was round was not exactly a safe position to take."
The church dogma wasn't about whether the earth was round ot not, but about whether the sun revolved around the earth or the other way around.
"2480 the universal password :} "
Only after 2580.
If you are paranoid enough to encrypt the data locally after receipt at the phone, then you had better also examine the how the sender and the snapchat server deal with the data. Better setup a public-key system and figure out how to do the key management without discouraging Joe and Jane User.
You're presenting it as an all-or-nothing issue. There are a couple of shades of gray in between. The internal storage of Android devices is typically formatted as ext4, wtih the wear-leveling (I think) done by the flash memory controller. Accessing the "overwritten" data would require quite a bit more work than just analyzing a block-device image. I suspect that you might have to desolder the NAND memory modules.
And even if the file is deleted but not overwriten, I don't think it's that easy to find the right blocks in the correct sequence; compressed JPEG data past the header data looks pretty much like random data.
"I just can't think of a situation in which I would send a photo to someone and subsequently care whether they saved it or not. "
Sending nude pictures to your (teen) lover while reducing the risk that they get to be seen by the rest of the school if the relation goes sour. Or to prevent being charged for spreading child porn, like these kids: http://www.connectsafely.org/Commentaries-Staff/teens-convictions-for-child-porn-upheld.html
Maybe cheating husbands and wives who don't want to leave too many trails. Although I'd be rather suspicious if my significant other had Snapchat installed on her phone...
"cool the air to -78C and then collect the solid precipitate."
At that temperature, the vapor pressure is equal to atmospheric pressure. It would be like measuring the water content of air by cooling to just below 100 C.
You'd need to go quite a bit lower in temperature.
http://en.wikipedia.org/wiki/Carbon_dioxide_data
I have no personal experience here, but this UDF compatibility matrix does not look too promising. Apparently there are five UDF versions and three variants within each version, and only the oldest versions (from 1996-1997) actually have wide OS support.
A bit more googling produces more comments from users about tricky incompatibilities.
"What remains: not much, really. Some glass, stone, metals. Not much that burns well."
I'm not sure what country you're describing, but here in the Netherlands, we separate paper, glass, plastic packaging (PE, PET, PP, PS), organic waste, electrical equipment, chemical waste. Stones (e.g. from breaking down a wall) are not supposed to be mixed with household waste. Laminated materials such as potato crisp bags and milk cartons, styrofoam, discarded household items go into the "other waste" bin. I'm not sure whether I'm supposed to, but plastic with food scraps sticking onto it don't make it to my plastics container since I don't want them to rot and smell. My trash bags will burn pretty well.
For the Netherlands, I think company offices are a big contributor to incinerable waste. They separate the paper, but not the plastics. Many company restaurants are not separating compostable waste from what the employees leave on their trays.
I see the upside of SMS'es costing the sender money: it throttles the rate of incoming messages. I fear the day that the spammers figure out how to use Whatsapp for massive spam runs.
Too bad that here in Netherlands the telcos are moving to unlimited-SMS plans due to competition with Whatsapp...
From this and your earlier post:
Rational arguments could be more convincing than strong language and ad-hominem attacks.
True on a world-wide scale. However, in the US, 32% of CO2 emissions is from transportation. It's harder to find numbers on motor vehicles in the US, but the closest I get within 3 minutes of Google is almost a quarter of annual US emissions of carbon dioxide (CO2). (...) The US transportation sector emits more CO2 than all but three other countries' emissions from all sources combined.
Unfortunately, it looks like there is no simple way to reduce CO2 emissions. Just saying "just cut all the CO2 sources except the my car, my airconditioning, and my incandescent bulbs" is a bit too easy.
What kind of security flaws do MD5 and SHA-1 have that are relevant for password hashing? As far as I understand, those weaknesses are about attackers who may specially craft pairs of messages (passwords) that have the same hash, not about constructing a message that will generate a given hash without prior knowledge of the message.
The main thing that matters is how much effort it is to find a password by brute force and in that sense, you should use no hash algorithm that is designed for computational efficiency (as explained by your bcrypt link).
That said: I used to have an encrypted home directory on a netbook with an Atom processor; the encrypted filesystem (ecryptfs) used some kind of slow hash function -- that would generate about 5 seconds delay upon login and even upon unlocking the screen. So, take it easy with those slow hash functions...
I'm using Gnome 2 and Compiz, so I'm not sure whether this translates to your platform, but in the Gnome file manager I can enter sftp://username@hostname:/home/username/foo.jpg . I guess the problem is figuring out as which hostname the server is accessible, which will probably mean an old-style ~/.tyls configuration file ("When logged in from 192.168.1.14, then prefix the pathnames with sftp://bob@192.168.1.5/"). Since this is completely separate from Terminology itself, one could implement this right now as a lightweight Perl script that can run on a NAS.
I just had a look at tyls.c; it looks to me like the escape codes have the filename and a generic icon identifier ("like "application-x-tar") embedded, or no icon identifier if it is a media file. I assume that the terminal client then looks up the file and generates the thumbnail.
Why is it infeasible to use URIs rather than pathnames, so that the terminal can fetch the data? I understand that it's more work than adding three lines of code, but your wording "Haven't figured out how to sensibly do it remotely." sounds like there is a more fundamental problem.
Do you say this as a beta tester or as a developer?
I suppose that one could implement the 'tyls' replacement for ls without all the GUI libraries (probably a 20 line perl script could do the job). Maybe without thumbnails, but at least with hyperlinked filenames. If the filenames are then encoded as, e.g., sftp://host/path/foo.jpg, then it would not be too hard to implement a handler inside terminology.
Yes, I tried. But things like mass re-tagging media (ogg vorbis) files are very slow if the actual file content needs to be sent back and forth over wi-fi, compared to doing the file operations locally on the media server.
I wonder whether it works if you ssh into another machine. I have been wanting something like that while logged into my media server, which doesn't have X11 applications installed. It's not mentioned in the feature list and I can't judge whether the underlying architecture would allow tunneling these functions over ssh to a box that doesn't have enlightenment installed. I'd think that a special ssh client on the client side would suffice to have simultaneous channels for command-line data and multimedia data to the host machine.
I'm surprised no one else responded to this; TFA didn't mention it either; I recall having experienced a significant performance difference between a new and a used USB stick in the past.
I happened to have an unused USB stick (SanDisk, 4 GB) lying around, so here are the test results I get right now. Out of the box, it takes about 4 seconds to write 40 MiB, using the command
time sh -c 'cp /tmp/random_data_40MiB /media/FBDD-DDE3/rnd40M-3; sync'
Strangely, sustained writes (looping the above command) are about a factor 2 slower; maybe there is some cooling-down time to prevent overheating of the flash chip? After filling up the entire USB stick and deleting all the files again, there is no difference in performance compared to when it was fresh: 10 MiB/s for a burst write and 5 MiB/s for sustained writes.
That was my whole point: if the blanket is truly reflective for infrared, it doesn't matter much what temperature the blanket is. The problem is that usually only one side is reflective; the other side is not reflective at for thermal radiation.