rcoder

Two 8-bit cores != a 16-bit CPU.

By your math, every dual-core 64-bit Intel CPU would actually be a 128-bit processor, a quad-core would equate to a 256-bit system, and the Cell would be a very studly 1088-bit chip (64-bit PPE + 8x128-bit SPEs).

You appear to be confusing "linear" scaling with "exponential", which makes a serious difference.

Repeat after me: censor-ware does not work. It's like spam -- since you can't even define what constitutes offensive content in a consistent, formal way, how in the hell can you expect any system (human or algorithmic) to make an effective, fair determination about what goes in which bucket?

Apple does a great job of design, usability, hardware hacking, and recently they've even been pretty effective at getting content owners to move in the direction of reasonable licensing terms for digital distribution. However, they do not have magic pixie dust which makes them immune to brain-dead "content filtering" algorithms, whether human-mediated or not.

> ...these C libraries are always insanely convoluted...

If you haven't actually looked at the code, you might want to avoid making such a overly-general statement. CDB is a very simple data structure (basically a two-stage hash table) serialized to disk in a format that makes lookup fast. You can check the link I posted above to see a simple explanation of the format, and this page to see examples for usage (from an API-compatible reimplementation):

http://www.corpit.ru/mjt/tinycdb.html

Since the core algorithm is so simple, creating a 64-bit version should be similarly easy, at least on a UNIX-like system (trying to run code designed by Dan Bernstein on a non-UNIX system would be...interesting).

Actually, the core CDB data structure only limits keys and values to 4GB each, not in total:

http://www.unixuser.org/~euske/doc/cdbinternals/index.html

The hash algorithm used also only produces a 32-bit key, meaning you'll be limited to 2^32 total records. Again, though, unless your data is of trivial size, that gives you considerably more room to work with than a hard 4GB limit.

Edit: doh! can't use double-asterisk for exponent on HN

I'm a bit surprised at the poor showing of Tokyo Cabinet in this test, given the amount of buzz it's gathered in the last few months, but the CDB results honestly don't surprise me in the least -- it's a special-purpose datastructure wrapped in a thin library that just smokes any other DB type if your workload allows for a complete rebuild of the database on each update.

I would honestly say that they're all pretty equally terrible, across both the paid and free/OSS segments on the market. Making any of them useful for your environment requires customization, training, and plain old time.

When I was working at a school that had to pick a new LMS, we eventually settled on Moodle simply because it was the only option that was sufficiently hackable for us to turn it into something usable.

Thankfully, there are better, free alternatives out there to either Angel or Blackboard. Sakai (http://sakaiproject.org/) has the more substantial "big school" base, and looks like a good platform on which to build if you're okay with a Java app stack, and willing to put up with some "design by committee" architectural choices. Moodle (http://moodle.org/) on the other hand is much easier to get up and running quickly (it's just a standard PHP app), and has an active community of extension, theme, and patch contributors, albeit at the cost of some of the typical PHP framework's tendency to grow warts.

As I see it, data.gov isn't so much a source for new types of information -- it's a more approachable and usable clearinghouse for the public datasets already being made available by the federal government.

XMPP solves many of the issues with email only because it requires explicit whitelisting of message senders, and because it's still a niche ecosystem compared to email. Most users don't even try to accomplish cross-domain message sending, much less extensive file transfers or server-side storage and archiving of messages, no matter what the server capabilities might be.

As a set of protocols, SMTP and IMAP are both pretty well-suited for the task they set out to accomplish. Furthermore, the delays you mentioned in message delivery are largely due to intermediate spam filters and store-and-forward queues, not inherent issues with email as a transfer mechanism.

Starting a conversation is much easier when you have a reason to think you have something to talk about with the other person. I too find it difficult (and generally, also fairly pointless) to engage random strangers on the street in conversation, but have found on the other hand that tech meetups, volunteer opportunities, and alumni events have a relatively high chance of producing interesting conversations, especially once I've established an "anchor" group of friends and peers within a particular community.

You may also want to consider the context for the conversations when trying to determine the reason that they die out. There was an article posted here some time back on the subject of "acceptable settings for flirting", which wasn't all that informative, but did hammer on one key point: people's degree of receptiveness to conversation with strangers depends largely on context. I.e., someone sitting by him or herself in a bar or coffee shop may be a bit more open to chit-chat than they would be when sitting at a bus stop, or having lunch in a cafeteria.

Basically, you should rely on favorable settings (parties, departmental mixers, sporting events) and implied social ties (academic cohort, shared professional interest, friends in common) to get your foot in the door, then try out your best lines, rather than expecting your wit alone to forge a new relationship.

This is all very cute, but the real exploit isn't embarrassing your friends and co-workers by revealing their kinks. Imagine a phishing site which could sniff your browser history to see which bank you use, and then provide a customized login form masquerading as that same site.

Exposing browsing history via CSS color information in the DOM is a serious security hope that should be closed by browser vendors.

You have a point, but you're dangerously close to an argument that people who live in more expensive areas are intrinsically "better" than those who don't, whatever the reason.

Some of us may choose to live in more affordable cities because the quality of living is higher, or because we value being able to safely and comfortably walk or bike between home, office, and other destinations.

I personally make enough to live reasonably well in most any city in the US, and after a couple of years in the Bay Area, moved back to my native Portland because the quality of life was simply better, at least on the axes I care about.

Cost of living affects startups in a number of ways, including the price of office space (or home rental, in the "working in the basement" stage) and the minimum salary expected by your staff (once you start hiring).

However, the areas with higher cost of living also tend to be desirable places to live, with an existing concentration of business and tech-savvy people.

Knowledge of macroeconomics != personal spending discipline

> Yet another smug boomer with an overinflated sense of entitlement...

...who, to be fair, made a very public "mea culpa" about his failures in personal judgment when faced with the possibility of buying a house he couldn't really afford.

I don't necessarily think this article was all that appropriate for HN, but I did think it was a compelling piece, because of the insight it offered into how even otherwise-rational people could make bad decisions about credit.

I think the reference to gaming in the article threw me off a bit -- looking over the NaCl API docs, I don't see any references to accelerated 3D of any sort[1]. Basically, it can handle Quake, because it works with a software-only rendering pipeline, but Crysis is going to be out of reach for some time to come.

As I understand it now, NaCl is really just a way to offload CPU-bound tasks to native code with minimal overhead. It's interesting, but I'm not sure I like the trade-offs vs. a platform actually designed from the start to insure confinement of untrusted code (i.e., Java).

[1] -- Does anyone know of good literature on confinement of GPU-intensive code? I've read up x86 and Java security issues, but don't know of any good work on the security profile of code using OpenGL or DirectX...

Okay, good to know. It was unclear from the article what set of syscalls we exposed to the apps running within the NaCl sandbox.

I haven't read up on BitFrost in several months, so bits of the model may have changed by now, but as best I can recall, BitFrost is very closely tied to the Linux/POSIX process model. A core part of its process isolation model is the execution of each task under its own ephemeral user and group ID, with system-mediated IPC over DBus.

I'm failing to see how this could possibly disadvantage Microsoft at all. Since the sandboxed code runs as a native X86 app, it also uses native system calls. Games (or any desktop app delivered via NaCl) using DirectX or other native Windows system APIs would be just as tightly coupled to Windows under NaCl as they were when running standalone.

If anything, Microsoft should welcome this as a defense against the encroachment of cross-platform JS and Flash applications.

Slow startup time has been an Achilles' Heel for JRuby for a long time now. Being able to get <100 msec startup times could help a lot in making JRuby a reasonable option for short-lived systems automation scripts, cron jobs, etc.

Even the base-model Amiga had almost double the CPU speed of the IBM (7 MHz vs. 5), four times the RAM (512 KB vs. 128 KB), and a full 32-bit processor (albeit with a 24-bit address space). The Amiga was also released four years later than the PCjr. That's an entire generation in personal computer hardware.

Regardless, I'm not sure where you picked up a sense of "parody" from the original article. I see an almost touching devotion to make something useful out of a dead, useless platform. It's ridiculous, silly, and probably a waste of time, but it made me smile anyway, and brought back memories of all the time I spend playing with my own PCjr in my parents' basement 20 years ago.

Q: What happens when you combine this with the default Ruby OpenSSL certificate verification level? (Hint: the default verify setting is 'none'.)

I'm also not sure this is worth an entire blog post, given how little code is required to implement it:

  require 'open-uri'

  module Kernel
    alias :_orig_require :require
    def require(mod)
      mod =~ %r{^https?://} ? eval(open(mod).read) : _orig_require(mod)
    end
  end

Edit: I should have phrased that a little more constructively. My point was not to suggest that small snippets of code are unworthy of blog discussion; rather, it was to show that the code in question really was equivalent to any case of 'eval' applied to untrusted input. I.e., a Bad Idea.

XMPP was a core part of Twitter's feature-set from the earliest days. Delivery became a bit (cough) "spotty" in early 2008 or so, and has been turned off AFAIK for a while now. That being said, there's no reason it couldn't be a part of their product offering again, if the obvious security and peer-server throttling issues could be resolved.

OpenMicroBlogging, while an interesting idea in the abstract, suffers from combo of feature bloat (license info per post/link) and missing core items (no baked-in Atom/RSS feed support, no friend/follow listing in profile) that make it far from a "Twitter-killer" out of the box.

Furthermore, the "reference implementation" laconi.ca is a bog-standard PHP/MySQL app. Since many of the complaints about Twitter's dominance stem from frustration with their uptime and scalability, it hardly seems realistic to pin our hopes for a better, more reliable future on a collection of PHP scripts running on a bazillion cheap shared hosting boxen.

In fact, WordPress + P2 (http://wordpress.org/extend/themes/p2) seems like a much more potentially-disruptive technology to me. OMB may be much more carefully designed to preserve security, license terms, and privacy, but we've seen time and time again that normal users don't really care about those things. They want a clean, usable UI, and readily-available documentation and support for a commonly-available product.

The web browser on the Kindle is limited, but works fine for basic sites (Wikipedia, Google, Twitter, and many other mobile-optimized sites) and absolutely piggy-backs on the onboard (free) cell modem.

News.YC doesn't look terribly on it, either. ;)

I'm sorry, but...what?

The book-scanning process in Rainbows End was an obvious parable, not an attempt at plausible futurism. Even in the book, alternatives to the destructive scanning process existed, and the choice of digitization technique was a business decision, not a technical one.

Furthermore, many of my favorite authors (Stephenson, Pynchon, Murakami) work full-time as writers, and seem pretty capable of doing so without starving for source material.

I don't disagree that livestock are a serious greenhouse gas factor, but goats may have multiple uses as a stock animal, including mowing, meat, and dairy. If these animals are raised as, say, a dairy herd, and incidentally feed on grass at corporate offices rather than private ranch land, that would seem to me to be a net win in terms of carbon emissions.

And this, kids and kid-ettes, is why having someone who knows their way around your C compiler, assembler, and debugger on your team can be worthwhile, even if you're working in a high-level language like Ruby.

I see one graduate thesis, extended into a sparse handful of conference papers, then somehow converted into the holy grail of database technology: an index algorithm which can be used as a drop-in replacement for B-trees, offering a 2-order-of-magnitude increase in performance with no downsides.

What's that, you say? There must be some trade-offs involved? Well, sure, maybe...but you'll never be able to find out, because you can't look at anything other than said early research results without waiting for a sales representative to contact you. No downloads, real-world benchmarks, or testimonials from users == a pretty dubious set of claims, at least to these cynical eyes.

I'm not disputing the fact that these guys may have an honest improvement over the state of the art for certain search tasks. If they do have anything close to the 50x speedups they claim for general MySQL workloads, though, why hasn't Google simply written them a check and stuffed their great discovery away with all of the their IP portfolio?

Honestly, the registry is no worse from an end-user POV than the /etc filesystem under Linux. In point of fact, given the diversity of file formats and sources in /etc, it's probably fair to say that the registry is equally navigable and understandable to the average Windows power user as the config tree is to a Linux fan. Because keys are typed and support ACLs, it's also arguably better-protected against accidental or intentional breakage.

If you want to attack an ad-hoc config system, then perhaps talk about the mess that is OS X 'defaults', or GConf's half-assed reimplementation of the Windows registry for GNOME.

That being said, I am most certainly not a Windows partisan. The last time I worked primarily on a Windows system was when I worked for a large hardware manufacturer, and the entire company ran on Exchange + Office. That was over five years ago, and I have been almost 100% on Mac OS X + Linux in the meantime, with only occasional use of Windows in a VM to verify IE compatibility.

The reason is this: for the tools I need to be productive (Vim, Ruby, Java, Firefox, MySQL, IM client, email client) Windows is at best equally capable, and at worst a second-class host, to Linux. OS X is about as suitable a platform for those tools, but has a much smoother media (esp. online video) and mobile story. Hence, the advantages of Windows (huge application library, obscure HW compat) are largely moot, while its disadvantages (poor POSIX/UNIX compat., weird dev tools, cost) are more apparent.

Honestly, I'm most excited about the seemingly mundane parts of this update: named and default args, and package objects. The big reason that Scala appeals to me more than Haskell or ML for building non-trivial systems is the pragmatic way it approaches real-world program construction.

I think that adopting the best features of existing OO languages like Python (named/default args, first-class packages) and Ruby (flexible syntax for pseudo-DSLs, pervasive use of lambdas/blocks in stdlib for iteration and control) while running atop the JVM is a great strategy.