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...

TLC (found in usb drives, ... ) is only 1,000.

Does that also apply to SD and micro-SD cards? Nowadays these Raspberry Pi and comparable devices use micro-SD cards to run the operating system. I have the impression that typical flash cards and USB sticks nowadays use 4 MB erase blocks and the wear leveling on these is probably not very smart, so just a /var/log/syslog on a 4 GB card that gets a line every minute will wear itself out in about 2 years.

Actually I have had a couple of sd cards fail on me (one Nokia 2 GB dead on arrival (2008), later on an 8 GB and 2 GB card on other phones in the last two years within a two years after purchase).

On a related note: I wished that manufacturers of those thumb drives and sd cards specified not only sequential read/write throughput but also write throughput for random 4 kB blocks. With many drives, throughput will drop to 20 kB/s. (Source: http://forum.micromart.co.uk/Topic413730.aspx )

I usually begin a session by telling my student that it's only gonna take 10 minutes.

Instead of the success stories, I would be more interested in how many students are like me and the guy I replied to: hours and hours of practicing to get anywhere.

Mind you, people like me are also behind the rest in dance classes, car driving (with stick shift and Dutch bicyclists everywhere) and everything else that requires motoric coordination skills.

It took an hour a day for a solid month before I could juggle three balls at all.

Sounds familiar. Then I met a woman (who ended up becoming my wife) and explained her the basics and within twenty minutes she was able to keep three balls in the air for ten throws or so.

That day, I decided to restrict myself to practicing skils that I actually have some talent for. :-)

You don't account for the sutface tension. If you squeeze the tube thin enough, the liquid may gain energy by breaking up.

Think of water running out of a tap. The stream gets thinner and thinner as it falls and then breaks up into separate droplets.