Here's a question: Why would a CA add randomization, instead of forcing at least SHA1?

Actually, yes it is. You just need a strong enough cipher.

The way I understand it, for example, 4096-bit RSA either requires a dramatically new approach (quantum computing), or, with current technologies, requires every atom in the Universe to be assembled into a massive compute cluster, and that cluster needs to run for longer than the heat death of the Universe.

Botnets do change some things, but they don't change basic mathematics.

Thus rendering large portions of the SSL-enabled Web inaccessible, or at least having them throw up certificate warnings.

There really isn't a good solution here, given how poorly trained most users are, and how difficult it is to actually push updates to them.

Which means the apps on that distro disk will be chosen by who needs the money, or who's paid the bribe, not which app I actually need. What's more, even if done properly, it will have a bias towards hardware autodetection, disk compression, hacks like unionfs, installation, and recovery tools -- things like ntfsresize and friends.

So, again, there's the problem of packages now being chosen for more reasons than just "it belongs in the base distro".

This would work, except most users aren't going to know which packages they mean. I know I don't. To which package does credit go for KDE4's mount/eject system? What about the fact that the system tray displays an icon to show when updates require a reboot, or when I must restart Firefox?

Those are pretty lame examples, but you get the idea. Would credit for integrated desktop search go to something like Beagle, or something like GNOME?

There's also two other, larger problems with this that I don't see going away: There's now a massive incentive for forking, because if the fork is successful, not only do you get the credit, you potentially get the money. Now, most people can't effectively do that, but some are in a position where they can if needed -- Debian's Iceweasel and Ubuntu's abrowser are good examples; Firefox has great branding, but I'm guessing most Ubuntu users aren't going to replace their browser without at least opening the default once.

So, in the case of something like Iceweasel, who gets the money? Debian? The Iceweasel team? Or Firefox?

The other large problem it creates is an incentive to have large numbers of small packages. Maybe that's a good thing (the Unix philosophy), but some things actually do go together, and I can see people avoiding sensible metapackages (empty package which depends on the components of the app it's named after) in favor of pretending these things have as little as possible to do with each other.

And that gets worse, the more user interaction you have -- because if the user makes the connection, they might decide to give just one donation to the parent project, rather than five to the children. And this is true even if you say "I want to donate $60, divided however I divide it", because there's still the difference between giving $30 to Samba and $30 to OpenOffice, vs giving $20 to Samba, $20 to Writer, and $20 to Calc.

That seems reasonable, but I think you'd really have to just put it as another program in the list. Eat your own dogfood. If you're not making enough from those donations to stay open, that means either your system isn't working very well, or you don't really matter.

But I don't think the political problems are really solvable. I think it's easier just to stick PayPal buttons all over the place, and make it as easy as possible to donate $1 or $5 when a project makes me happy. Beyond that, I'd donate to the distro -- a good distro will contribute at least some work back to the projects they use.

I would guess it depends on the game. I imagine in some games it might make sense to instead have the client transmit updated coordinates, and have the server calculate the vector and determine if it's an allowed vector. I'm also guessing that's more work for the server -- but I haven't done any of the math.

A sensible assumption, I would think, is to buy it preloaded with Linux. And this has worked fairly well. I've had weird issues with the nvidia drivers and KDE4, but that's to be expected -- KDE4 is still beta. (Oh, they'll tell you it's a stable 4.1, but that's like Vista claiming to be released...)

Other than that, though, it's been perfect, as far as compatibility goes. I'm starting to think my next system won't be Dell, though. Optical drive died, and it took them three trips (first trip was the wrong drive, second trip it was damaged) -- though they were nice enough to include Vista install media (WTF? I ordered Ubuntu!) on one of those trips. Currently, the battery is not charging (stuck at 26%, will discharge, but won't charge again) -- probably will involve replacing the motherboard, which means another trip or three.

And I bought this thing less than three months ago.

To add insult to injury, an old-ish video card, and a 100 mbit network card (no gigabit), both soldered to the motherboard.

Anyway, bitching over. To the rest of your idea:

If you can make it work, great!

But, that seems a bit difficult, considering the number of applications, and the way in which they are used. You'd need something like popularity-contest to find out which apps are actually being used -- or you could just watch that user, or allow them to automagically submit a list of apps.

Even then, there'd be questions of usefulness factoring in. If you base it on something as crude as CPU time, wall time, number of executions, or LOC, it's ripe for abuse. But if you make it subjective, it's ripe for politicking and corruption.

Slight problem here -- what should I use my wallet to vote for?

I just recently bought a Dell laptop. It came with an nvidia card -- no option for ATI. What's more, this is all new stuff -- as far as I can tell, the closed nvidia drivers are still better than any ATI Linux drivers, but that may have changed.

Since I can't afford another computer so soon, I'm kind of stuck. The video card is embedded, after all, so the best I could do is get ExpressCard video, and I doubt that will perform as well, even with a better card.

But, hindsight being 20/20, which should I have voted for? I'd think I'm voting for Linux by buying a machine with Linux preloaded. But it's more complex -- I'm apparently also voting nvidia, and since I bought XP, I'm voting that, too.

Maybe so. Personally, I'm a fan of the prototypal object system, which isn't too common. The metaprogramming is fun, too -- just pull a method off an object, store it in a local variable, capture that in a lambda which calls it later, assign the lambda to whatever you want, including the original object.

Things like Rails' alias_method_chain are much easier and much more powerful.

True enough -- however, there are Javascript parsers in Javascript. Not convenient, but it should give you what you need.

How about inserts? Offline? How are conflicts resolved? How are the indices kept in sync?

And I'm out of my depth, but you've qualified that with "linear scans" -- I take that to mean that it's possible to create SQL which doesn't scale horizontally at all.

Granted, I'm not sure Couch does splitting yet. However, indexing is pretty straightforward, and is done on just about any view. Knowing what goes into a view, in this case, is much more closely tied with being an application developer than a DBA.

Agreed.

I can see two things happening with it:

  It's still early enough that an alternative might appear. Indeed, there's more than a few takes on a "document database" -- ThruDB, for example. There's even a Ruby-specific one (RDDB), though it appears abandoned.

Or, Couch seems flexible enough that it might be adapted anyway, with or without help. I've already mentioned pipe communication, and the possibility of translating sexps to JSON -- another possibility is to use whatever binary format you want, and do something like Base64 encoding -- or something more aggressive, since JSON strings can be any Unicode character except '"' or '\' -- and deal with that in your custom view binary, leaving the JSON only for internal CouchDB stuff (document ID, revision, etc)

Obviously, that's not the best way to do it -- it would be better if we could hack it to, say, communicate the revision/docid/etc information via custom HTTP headers, and let the body be pure unadulterated binary. But hey, if we could, the problem is solved right there.

Hmm. Can you point me to a good test of this?

Print Screen tends to control screenshots, which is nice. I have F13, F14, or F15 mapped to it, but I don't remember which, and I don't really want to take a Sharpie to my shiny Apple keyboard.

And the Home key is there on my keyboard. The one that really pisses me off is Insert, because rather than just labeling it differently and making it do something different on the Mac, they've turned it into an fn key, which is handled somewhere in the keyboard. Maybe hardware -- I'm hoping firmware (yes, this keyboard has firmware), but I'm not enough of a guru to fix that.

But now that I've mentioned it, and completely offtopic -- can anyone point me to a good place to get started at hacking the firmware here, and/or writing a driver to flash it on Linux? Or, since I'm probably a year away from having a clue about that, does anyone want to do it for me?

And I don't think I'm the one who said Model M -- I like Apple's Aluminum keyboard.

No, but it's enough to be quite a bit ahead of many other languages. For that matter...

Granted, it's not as clean, but most Javascript implementations include a toSource method on the function object. Is that enough to build what you want?

Somehow, I like the JSON syntax better. But it's also a reasonable representation of a data structure, such that I would think it would be easy to store sexps that way.

In other words: Performance. Got it.

You realize that CouchDB scales to an arbitrary number of nodes, right? And while the queries don't yet, they easily could, and will in the future?

Yes, when I know an app is going to be on a single machine only, I'll probably use something like sqlite for the raw speed and ease of deployment. But I'd much rather have something horizontally scalable than vertically scalable -- and as a nice side effect, I get a decent imperative language that's close to what I already know how to use. And if I really have a problem with JS, I can use whatever language I want.

I could, for instance, serialize sexps to JSON, and write an engine that deserializes them and passes them to LISP view functions.

Contrast this to SQL -- maybe faster on a single machine, but how do you make it really scale? How do you know what to index, when? How do you scale your queries to thousands of nodes?

There's a certain class of application for which SQL makes perfect sense. There's also a class of application for which SQL is a constant pain in the ass, and CouchDB makes perfect sense.

So write some sort of macro engine. In fact, someone is doing that -- check out jabl, from the author of haml.

Yes, it's ugly that you have to do that -- but then, I find LISP syntax ugly; unnecessarily verbose, and homogeneous enough that it's hard to tell, at a glance, what's going on.

I don't think Couch is ready -- the two features I really want to see are a nice Ruby interface for views, and support for stacking views. That said, I doubt I'll be using SQL for much even a year from now.

Yeah, he wrote Mongrel. Great, thanks and all that -- and we've now got Passenger (faster, and easier to deploy, or so I'm told) and things like Thin (several times faster). And we've now got Rack, so no need to be tied to any particular webserver.

He's also shown the least maturity of anyone in the Rails community, including DHH. And that's saying a lot.

Also: Rails development is fast. There may have been a few valid concerns in that rant (though hard to see in all the trash-talking, name-calling, macho bullshit), and there were a few concerns which were pretty ancient history by the time he wrote the rant. But at the current rate of development, I'm not sure it's at all relevant anymore.

Nor does CouchDB. You can do relationships easily enough, but since there's no schema, it's hard to enforce foreign keys -- and since you're not using SQL, but JavaScript, you only need to use a foreign key relationship if it actually makes sense.

What's more, each "database" is a single table, though you can certainly have multiple databases. The point is that the view engine is powerful enough that there's really no reason you'd need a different table -- you can get the same effect by adding a field (call it "table name" if you like) to each document, and querying based on that.

A common example might be an article with a bunch of comments. With CouchDB, it actually becomes a reasonable option to put the comments inside the article document itself, rather than as separate records. (It's a bad example, because it means you'll have that much more contention (and chance to conflict) for the article, but you get the idea.)

How long ago was OS/2 developed? It's got to be getting close to that 15-year limit...

What? How? Does it force you to use its own audio?

Ok, first of all, does anyone here find the "Home Page" key to be useful?

Alright, I can see the point of things like volume keys. What I don't see is why it's so hard to map some unused keystroke to those anyway. I tend to map various global keystrokes with the Windows key to Amarok.

Also, WTF is a "Gaming keyboard"? Last I checked, most games are built to respond to keystrokes on a normal keyboard. As for macros, why not do it in software? If it's to foil the game's anti-cheat mechanism, wouldn't this then be considered cheating? Is WASD really that hard to use?

The media center keyboards I can kind of see, but really, it's not that difficult to just use any wireless keyboard (why do you need integrated tracking?) and learn keystrokes, or use a good old-fashioned infrared remote.

As for "clicky" keyboards, at least you've got a valid reason for those -- personally, the keyboard I'm fastest with is Apple's aluminum keyboards (I prefer the wired version), which cost me $50. Most of these are much more than that, even one of the "gamepad keyboards". I just wish someone other than Apple would make one, so I could have an insert key, and not have to swap command/option.