maelstrom

plop - a simple opaque file portal

Plop is a simple opaque file portal written entirely in shell, for speed and for minimal dependence on extra stuff you probably don't want anyway. You share files by key (md5 checksum). To a certain extent this protects them from spiders. The shared files expire after a given period of time, by default a week. Typical invocation:

$ plopdb add pics/billy-taking-a-bath.jpg
$ echo billy-taking-a-bath.jpg | join - /usr/share/plop/db/master
361709f6fb0a1ccd7fbc94ffcf773fcf billy-taking-a-bath.jpg 1159847154
$ echo "http://nakedbillydotcom/plop.cgi?key=361709f6fb0a1ccd7fbc94ffcf773fcf" | \
  mail -s "naked pictures of our little darling" grandma@grandmas.isp

plop-1.0-beta-1.tar.gz
plop-1.0-beta-1.tar.bz2
browse the source

the y2^63 problem

From Bernstein's tai64 page:

"Integers 2^63 and larger are reserved for future extensions. Under many cosmological theories, the integers under 2^63 are adequate to cover the entire expected lifetime of the universe; in this case no extensions will be necessary."

Phew.

structure

Further thoughts on the maelstrom rewrite. One really annoying set of tags in html were the hn tags: h1, h2, h3 etc. Inevitably, you added even more outer structure to the page but had nowhere else to go: you were already using h1. Or you wanted some intermediate structure but were already using h1 and h2. Inevitably, it was search-and-replace night.

Whatever syntax I end up with, I want to avoid doing something isomorphic to this. I'd like to have a generic way to say "here's some substructure," and I don't want to worry about forgetting to close the substructure. Maybe indent level (or :set ts=2 in my case) is the way to do this. This, coupled with the ability to source in other files, allows one to define arbitrarily structured composite pages ala Wikimedia's "Main article" subsections. It's like the dual space of hypertext: rather than linking out to other pages, you can also flatten them into one big page, efficiently via some cgi / caching mechanism if need be. Over time it could acquire a sort of fractal structure as the page itself descends into tendrils of detail.

I think this will help me resist the urge to impose taxonomy on the content via some external system like categories. Things are not really hierarchical; only anal retentive human brains are hierarchical. This is why OOP is not so useful in the end...your data is usually more useful as a loosely related graph of stuff than as a rigidly defined hierarchy. Boy I'm starting to sound too Web 2.0 for my own taste here...oh yes and tagging, I absolutely need tagging! and a karma system! and proprietary magical algorithms to run on the graph of stuff that make random "fun" connections between things!

relational algebra

Been making heavy use of join(1), comm(1), cut(1) and paste(1) recently. Find myself suddenly very interested relational algebra, at least to the point where the wikipedia page is a letdown. It totally puts the cart before the horse; the math is just a thin foam over the particular implementation we all ended up with, the bizarre beast that is SQL. Surely one can construct a simpler, more exact syntax.

package management systems suck (yes, yours does too)

All package management systems suck. And by all, I mean everyone that I've ever tried. The registry / MSI of course sucks. Apt really sucks, any operation outside of the ordinary takes hours of poring through giant man pages and editing weird config files ("Pin-priority? WTF?"). pkg_src / portupgrade sucks too ("pkgdb -F? WTF?") but is a little less complex than apt, so among the package management tools I've used, it's the best of the bunch. That's not saying much though.

Now before you chime in and say oh, that's easy to do with package management system X, all you have to do is use feature Y, I don't care. Because there are frankly too many Y's. They're obscurely documented. Poorly thought out. Non-obvious. It's great that you've taken the time to learn package management system X, but to me it never seemed worth doing because they're all so needlessly complex in the first place.

So problem #1: a big percent of what a package system does is manage complexity for you. Managing complexity is a tough problem, but a boring problem to good developers. They have more interesting problems to solve. Really good developers do not write package systems. So the complexity isn't really managed very well in the end, it comes bursting out the seams in endless manpages and over-engineered config formats.

But problem #2: another large piece of a package system is managing a dependency graph, and letting you control how basic package operations interact with the graph. This is actually a somewhat interesting problem because it's graph theory. But every package system I know of gets it totally wrong. Rarely do dependency-aware operations get it right. And this is because top-notch developers do not write package management systems, so the hard problem receives a botched solution.

Somebody needs to pay a good developer to write a package management system we can all use, as an act of philanthropy to the software community, because there's no way we're getting one otherwise.

P.S. Oh yeah another gripe. Why do all these package systems use a giant lock on a package database, so you can do at most one install / deinstall at a time? Am I just a dirty freak for wanting to install several things at once, in parallel?

only administrators can use the awesome power of flash

I would like to take this moment to once again thank sweet tiny little baby jesus I'm not a Windows user anymore. It took them about 20 years to turn DOS into a sort-of multiuser OS. How much longer would you give them for adding the equivalent of

export PATH=$PATH:~grandma/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~grandma/lib

and

eh?

Maybe Vista is the answer, but probably not. As that article from May 2006 concedes:

Although virtualization allows the majority of legacy applications to run, it is a short-term measure—not a long-term solution. Not only can a lack of compliance with User Account Control affect the security of an application, but it can also reduce the application's performance, require additional end-user training, and cause application conflicts.

Boy, I can't wait. Also, I guess that makes the Flash plugin for Firefox a legacy program?