thousands of bucks per GB cost of an SMS

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:

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.

Motor vehicles are behind about 15% all CO2 emissions.

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.

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.

One space blanket should be enough provided that the correct side is facing outward: the one with the high infrared reflectivity and low emissivity.

That emissivity is around 0.04, which means that the apparent infrared temperature is 0.96*Te+0.04*Ts, withTe the environmental temperature and Ts your surface temperature. Example: Te=20 C, Ts=35 C: apparent temperature 20.6 C, which will drown in the noise.

Unfortunately it's difficult to tell which side is the reflective one by eye. Of the few ones that I've tested, the other side can be close to a black body radiator. The instructions "put this side inwards to reflect body heat back" are not always correct.

A typical 8 Mpix sensor would be much better as a 2 Mpix sensor of the same total detector size and sensitivity ... So if you have a crappy electron well that can hold 10^4 photoelectrons ...

That's all fine, but what really matters how many more electrons the well will hold if you make the sensor pixel 4 times larger in area and how many more photoelectrons you can generate at the same exposure settings. If both of them are scaled by a factor 4, you can just as well average four adjacent small pixels to create a lower-resolution image.

Of course this averaging should be done in the camera/phone firmware before the JPEG compression step.

By far the largest problem (IMHO) with HTC's phones is the ten different models that are all slightly different.

Yeah, much better with for example the Samsung Galaxy, Blackberry, LG, Sony... Oh wait...