Ideas in this (virtual) directory have been implemented by me or by somebody else.
Serial terminals are typically very expensive -- often two to three times the price of a far more capable PC. There's still a market for them because they're more reliable and compact than a general-purpose machine.
I'd suggest producing a "terminal on a chip" using an FPGA -- a serial port, a VGA output and a PS/2 or USB keyboard input. The resulting circuit board would only be a couple of inches square, so could easily be glued to the back of a cheap LCD monitor. Even adding Ethernet support (for telnet/ssh) shouldn't be much more difficult, since there are existing TCP stacks for FPGAs.
(The reason I wanted this was so I could mount a WRT54G board in a SPARCstation IPX case, as a low-power-consumption Linux workstation...)
The Briel PockeTerm is essentially what I was thinking of here, implemented using a Parallax Propeller chip.
I've got a number of record sleeves that are quite attractive, and I'd like to be able to have on the wall. Since they're a standard size, I'm sure it's already occurred to someone else to sell a twelve-inch-square picture frame that you can put an empty record sleeve into.
The C64 DTV is a modern (and extremely cheap) clone of the Commodore 64 with a set of built-in games -- and keyboard and disk interfaces. To provide persistent storage and thus make it a useful C64 system, it would be neat to have a flash-based storage device that emulated a 1541 disk drive. Since this would only need a small microcontroller and a flash chip, it could probably be made small enough to fit inside the original DTV case.
Looks like Jim Brain had the same idea: his uIEC is a Compact Flash-based 1541 emulator.
Filtering proxies like Privoxy are extremely useful for people who want to alter the content of web pages before they see them, but they can't currently do anything about pages served by SSL: SSL proxies just pass TCP connections through. With a bit of certificate manipulation, though, it would be possible to alter the content of SSL pages in a proxy.
The trick would be for the proxy to be a CA. The user would grab a CA client certificate from the proxy (using a magic URL) and install it in their browser as a trusted CA. The proxy could then generate synthetic certificates on the fly for SSL sites that the browser would trust. This would allow real SSL proxying: the browser would talk via SSL to the proxy using certificates generated by the proxy, and the proxy would talk via SSL to the requested sites using (and verifying) their own certificates.
It would even be possible for the proxy to deal with existing clients
CONNECT for SSL proxies, by starting an SSL session and
accepting the incoming HTTP request. Institutions that want to guarantee
CONNECT proxies are only being used for real HTTP might
find this useful.
This has apparently (as of 2009) been implemented in Palo Alto Networks' PA-4000 -- although the fact that I heard about it through RISKS Digest suggests it's perhaps not a terribly good idea...
My third-year project was an IP stack for RMoX. In fact, I wrote it as a userspace process on Linux talking to the Linux IP stack using SLIP, and Fred later ported it to RMoX.
Obviously, it'd be useful to have a proper IP stack. occamnet as it currently stands has a few good features (I've done all the tedious stuff, like coming up with headers and writing code to do IP checksums properly) and a lot of bad ones (no TCP, at least one obscure bug in UDP, incomplete ICMP, dubious user API). Beating this into shape, and writing some network card drivers for RMoX so that it's actually useful, will be a useful project.
One of my specific plans is to make use of the new nested mobiles support to have a less clumsy representation of IP packets.
(And this is exactly what I did in the first year of my PhD.)
If I'm sending email and I've used the word "attached" in the message, it's likely that I intend to attach a file before I send. Since in many mail clients (for instance, in Mutt) the process of editing text is separated from the menu where you can attach files, I sometimes forget to actually attach the file before sending the message. If I've said I'm going to attach a file and I try to send the message without doing so, my mail client should warn me.
Internationalising this might prove to be an interesting challenge.
post-mode implements this for Emacs, and KMail has done it for ages according to a correspondant, so I think this idea's been thoroughly done now...
(This was pssc's idea.)
An X server which can change its root window size on the fly. This would be useful to enable resolution-switching in X which still maintaining sane window placement (i.e. not needing to scroll around); you could keep the virtual desktop size the same, but disable scrolling, and make the window manager aware that the root window size can change.
The RandR extension implements this now.
Tim suggested that I should have an RSS feed saying when my software releases happen; this could quite easily be done by just watching the listing of my files directory for changes. This could be generalised to produce an RSS feed that watched for changes in any web page, showing the changes in diff format.
There are sites around already that will mail you when a web page changes, but I'm not aware of any that do RSS. It'd be sort-of useful to support both; perhaps some generic Python module that accepted events, and either added them to an automatically-rotated RSS file, or mailed them somewhere. The first bit of functionality would certainly be generally useful.
Eliram Haklai pointed out that feed43.com seems to implement this now.
With a two-tier FTP setup, the FTP data connection might as well be made to the backend server (either by splicing the TCP connection, or via port forwarding). The idea is to have a single "frontend" machine which does intelligent routing and handles the FTP control connection; the FTP data connections are made to/from the appropriate backend using SNAT (for active FTP) or DNAT (for passive FTP).
This is much harder to do for protocols that don't use multiple connections; you'd have to move the existing connection from one host to another.
DrFTPd does pretty much this, although they don't have a NAT machine in front, so they have to extend the protocol to support passive connections.
TCP Connection Passing allows you to move TCP connections between hosts.
ROX-Filer could do with an option that controls how directory symlinks are followed. Currently, if you click on a symlink, you'll end up at the symlink's target; it would be more useful for me if it navigated into the symlink.
ROX-Filer 2 now never follows symlinks unless explicitly told to, which is close enough for my use.