924 karma · joined September 19, 2010
Activity stream (mostly code) is at stream.debu.gs.
But you're correct in that the current algorithm (or any sufficiently transparent algorithm) does lend itself to gaming. It might be harder to game if you didn't mind penalizing comments based on the quality[1] of replies they generate, then sorting based on the thread's average quality would mean that there's less incentive to post in the top thread just to get exposure, since your new, karma-less post will drag down its average and subsequently could drag down the thread. That could get prohibitively expensive to calculate for huge threads, but would be less prone to gaming, I think.
[1] If we can hand-wave "karma" to mean "quality"; I get way more upvotes when I am flippant but technically correct than I do when I try to be thoughtful.
I do agree, though, that the USB adapters are nice. I have a couple of PSX adapters and an SNES adapter. The Japanese console manufacturers seem to do a much better job with input devices than the PC-oriented crowd over here. (Although that could just be personal bias; I did almost all my gaming on consoles and in arcades before the first time I tried plugging something made by Gravis into my MIDI port.)
Compiler optimization be a harsh mistress.
This is DMR's website. Good job criticizing a dead man on not "keeping up" or writing CSS so that you don't have to customize your default styles.
If you've never done it, it is a couple of hours of reading and fiddling, but very quick if you have set up DNS before. I'm actually a bit curious about why people (even some sysadmins!) tend to spend time clicking on some clunky web interface to update records manually when it's actually easier to do it yourself. (Mail servers, on the other hand...)
I had hopes that all these different resolutions/DPIs/sizes for screens would stop designers trying to force a pixel-perfect layout into a browser, but the end result seems to have just been "CSS media queries".
The price paid is that sometimes a poorly designed site has text that spills out of a fixed-size box, but I can cope with that much more easily than with trying to read something that is 7px tall.
But for the usual case where it is I/O-constrained, you can often get files across more quickly by throwing CPU at reducing the total amount of bandwidth required by, e.g., using something like bzip or pbzip:
pbzip2 < file | nc $host $port
nc -l $port | pbzip2 -d > filewm/sh -c 'load std mpexpr;while{}{unicode -t ${expr 2571 1 rand +}}'
I can't be the only one to hear Dr. Strangelove's voice every time documentation is missing, can I?
I've tried without success to dig up an email from Linus Torvalds (on the LKML?) where, responding to an email complaining that a particular implementation of ARM does not breaking any interesting ground, he goes on a mini-tirade about the lack of appreciation for a simple thing done well. I think Go fits the description nicely.
[...]
> Would open-source prevent this kind of thing? Probably.
I don't think I could have made the argument better than you have.
The point isn't that all closed source software does this, or even that most does it. The point is that when you cannot control the software, the abuse can happen. Anyone who has power can abuse it, which means that if you cede control over software in your router to Cisco, you have to trust Cisco not to abuse it. If you don't, then you don't have to worry.
A lot of people will probably not like this answer, but Go's "tools" are the Acme editor and the shell. If you're running on Windows, Acme-SAC (https://code.google.com/p/acme-sac/, or just running Acme under "vanilla" Inferno) is a viable option, and is written in Limbo, a precursor to Go. (It still has some features Go lacks, but is roughly comparable.)
I wouldn't hold my breath on getting former Bell Labs guys to work on a graphical debugger or Eclipse support, so the language is somewhat unlikely to be developed together with those tools.
I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast.
The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library.
I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it.
As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.
On the other hand, I have written a few web applications in C. It's not that bad! :) The nice thing about it is that if you link statically, write CGI programs, and ignore memory management (or, rather, malloc all you care to and delegate garbage collection to the OS when your process goes away), you can get something that runs quickly with minimal hassle on a small device. I don't recommend it unless you have some bizarre constraints, but it's really not that bad! That approach doesn't seem possible with this server, sadly.