rcoder

I love the "notepad" joke implicit in that name.

Have you tried out the multivariate experiment type in Optimizer? Unlike the "classic" A/B test, there's effectively no risk of exposing the fact that someone is part of an experimental group to normal users. (Of course, HN types could still pick out the telltale JS fragments in the page source, but that's a risk with any testing that has a client-side component.)

We've been pretty happy with GWO's combination of being a) free, b) easy for marketing+management types to use for reporting, and c) integrated with our Analytics and AdWords accounts.

Just out of curiosity, though: are there competitive hosted solutions you would recommend over GWO? More options would be a good thing to know about...

I think the more reasonable standard might be this: if you wouldn't use a phrase or word in communication with your own colleagues, don't use it when talking to customers. If I got an email from a coworker talking about "synergies" and "visioning", I would likely reply with a direct and blunt request that they STFU and use real words.

That being said, having worked for a company which prepared business training materials for online MBA programs, I can tell you that the use of weasel words is literally part of the curriculum for any biz-school-trained managers. It's up to us, the somewhat-business-savvy geeks, to gently steer them back in the direction of real communication. (At the same time, we should probably listen when they tell us that "EPIC DATABASE FAIL!" is not actually a good way to describe what happened in an outage report.)

If you're thinking of operating in the USA, you should read up on Communications Assistance for Law Enforcement (CALEA). CALEA pretty much requires that you be able to associate a name with any IP on your network, so you're going to have a hard time operating as an ISP without any personally-identifying information about your customers.

Regardless, if you can figure out a way to anonymously collect payment for services online without either getting ripped off by your own customers or leaving a paper trail for law enforcement to subpoena, then you have a far more valuable commodity than simple bandwidth to offer. In fact, you would have invented "digital cash", and any number of folks (afore-mentioned law enforcement and tax agencies amongst them) will race each other to control or use it.

The GPL generally doesn't block a proprietary program from calling an open source one via a shell pipe. If it did, most commercial software running on a Linux system would run afoul of the GPL licensing of the core system commands (cp, ls, bash, etc.).

Furthermore, there are a number of more liberally-licensed binary-compatible reimplementations of Git available now (Grit and JGit spring to mind) that could be used as an alternate access layer, if you were less concerned with 100% compatibility with the latest Git features.

Forgive me if I'm just out of date here, but last time I checked, REE offered something like a 30% memory savings per forked worker. By my math (Workers_ree = Workers_mri / 0.7) that gives you something like a 1.4X increase in number of available workers.

Now, a 40% boost in running threads within the same memory is nothing to sneeze at. It's just a far cry from a 200% increase in the same metric.

Furthermore, for many deployments running on bare hardware (or even virtualized in a private datacenter), RAM isn't really the most precious resource. An modern app server can easily be packing 16-32GB of RAM, at which point CPU and I/O throughput can easily challenge memory for "most precious resource".

Why exactly do you assume that a credit card reader is a "closed box that is obviously provided by a bank"?

I've implemented point-of-sale systems before, and lemme tell you, there's nothing magical about a magstripe reader, a microcontroller, and a bit of firmware.

Think for a second about recent credit-card purchases you've made. If your habits are anything like mine, aside from gas stations (where the reader is usually integrated into the pump), most card "swipes" happen through either a peripheral device connected to a generic PC, or a compact card reader with little more than a keypad and phone jack, with no visible branding, certification, or tamper-resistant seals in sight.

Magstripe readers have been within the reach of any reasonably-clever fraudster for a long time. Attaching them to an iPhone and using audio modulation for the signal doesn't magically open the floodgates to card skimming and duplication.

This isn't even as big a threat as, say, making people acclimated to the idea of joining open wireless networks at coffee shops -- card skimming at least requires physical access to the card for a few seconds.

> It all looks and smells...of the Aerons of the late 1990s.

I'll admit that ragged on all the Aeron-acquiring startups back in '97-99, too. Then I bought one (second-hand, of course) for my home office last year, and discovered that, much to my surprise, Joel's arguments are actually sound: I can work for more hours, with better focus/less discomfort, in a really nice office chair.

Ergonomics aren't just faddish indulgence -- they can really make a difference.

Now, a DJ booth, and hand-rolled rattan bench cushions...those are faddish indulgence. (I'm still jealous, of course.)

When I worked on a sizable JRuby/Rails codebase, our team had a hybrid approach: ephemeral jobs (rake tasks, migrations, autospec) all ran under MRI, while long-lived processes (app servers, CI/acceptance test runs) ran in JRuby. That gave us the best of both worlds: quick startup in cases where total runtime was an issue, and better throughput (and more predictable memory usage) for CPU-heavy workloads.

In my experience, MRI/REE fits into smaller RAM footprints only in cases where either you start up and shut down runtimes relatively regularly, or you can monitor for runaway leaks and terminate bloated processes.

I do agree that switching to a different runtime just to get access to a few libraries is probably the wrong approach, however. The big wins in using JRuby are, to me, twofold: a nice performance boost for general application code, and the availability of robust, battle-tested application servers. Mongrel, Unicorn, and Passenger are fine if you're willing to live on the edge, but if you have a more conservative ops team, or simply don't want to both with rolling your own monitoring and deployment stack, being able to drop a Rails app onto Tomcat or Glassfish as a single WAR file is pretty damn nice.

It's a network security tool used for exploiting security holes in Windows systems in order to inject a remote control payload. It does have white-hat utility, but my sense is that it's mostly used for grey and black-hat activities.

Unlike the usual "script kiddie" Linux rootkits, it is largely focused in exploration and control of a single machine, but the building blocks Metasploit provides could easily be used to construct botnets, especially in dense networks like college campuses or medium-sized businesses without a strong IT security focus.

Once you have a Javascript environment, it's not a large jump to emulate a minimal DOM -- see env.js, for example: http://ejohn.org/blog/bringing-the-browser-to-the-server/

With a stub DOM and Javascript interpreter, you can pass generated output from web application views directly into your testing environment and make assertions about the resulting behavior, dynamically-generated DOM nodes, etc.

There are a number of projects similar to this one (for which, sadly, I cannot currently pull up any bookmarks) mostly intended for a similar set of tasks. Being able to bring RSpec or Cucumber to bear on a hairy JS testing job can make the process much more enjoyable.

Have you heard of a little something called Fair Use? If you were to modify one of Apple's system utilities and then distribute it, you could easily run afoul of copyright. Simply making a local modification in-place, however, is no more illegal than installing a new hardware driver, changing your shell prompt, or downloading and using Firefox in place of Safari.

Now, if you changed some piece of the system in order to circumvent FairPlay, or some other DRM component, then you might be running afoul of the DMCA. Not the same thing as copyright violation, however.

At minimum, the fact that the core functionality is available as open source gives me some additional confidence in the platform's long-term viability:

http://www.dimdim.com/opensource/dimdim_open_source_communit...

Even if the company goes away, others can use the Community Edition source to host their own instances of the service. Also, security reviews and enhancements can be generated from the bottom up by the community, instead of being 100% dependent on Dimdim.

How about this: install Debian, 'apt-get install kvm' (okay, you'll probably have to run that through module-assistant, but still, it's only a few more presses of 'Enter' away), then run 'qemu-system-x86_64 haiku.img -m 2048'. Voila! Linux as hardware abstraction layer and virtualization engine, with Haiku running on top.

The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime.

That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is completely different from all those old things!"

Since the pickle module doesn't marshal many types of stateful objects (filehandles, functions, etc.), I'm not sure it's fair to describe it as a means of saving the "state of the Python interpreter". It really just serves to save a compact representation of data on disk, without explicitly managing packing an unpacking from the binary serialization.

In that respect, it intuitively seems like it should behave more like the ASN1 or YAML formats w.r.t. the safety of data loaded from it. I may understand the risks, and you may understand the risks, but I think that a new Python programmer could be forgiven for simply scanning the standard library documentation and thinking that the pickle format would be safe for transport across untrusted channels.

I guess it was, "no, it shouldn't be, except that the pickle module is broken by design."

I.e., data structure parsing should not require a Turing-complete language. If it does, your serialization format is broken.

But yeah, I can see the issue with my original comment.

YAML is strictly a superset of JSON in its expressiveness, since it allows tagging of serialized objects with a type name. JSON reduces everything to maps, arrays, and scalars, so any type information has to be encoded in (or inferred from) the structures themselves. I also find it to be a bit easier to read, and so prefer it for configuration files or console dumps of data structures.

However, YAML isn't quite as well-supported in the standard libraries of various programming languages, most notably Javascript. Which one to use depends largely on how heavily you expect browsers to consume your service output.

No.

Proving termination for programs written in models less powerful than a Turing machine does not require you to solve the halting problem. Programs using primitive recursion, finite automata, and regular expressions, for example, can all be proved to terminate, and can express a number of useful computations.

The problem is that the pickle module is far too permissive. In particular, the REDUCE operation invokes a Python callable with an argument tuple on the pickle stack, which means that 'pickles' are at least as powerful (in the Turing-general, halting problem sense) as Python.

Since it sounds like a number of people are maintaining local patches to this library, might it make sense to fork it on GitHub to try to get some additional contributors onboard?

I'm not sure that I 100% buy the claim that this is a new form of web navigation -- knowledge base, ticket-tracking, and e-commerce tools have had numeric quick-jump features for years. It is an interesting approach to more traditional textual page navigation, though.

  > That means that someone manually took the site down.

Since the News.YC code (which NewMogul also uses) runs in a single Scheme process, it could have shut down for any number of reasons: it might have crashed, failed to start after a server reboot, been killed by the OS or hosting provider due to a memory leak, etc.

I don't know what kind of monitoring nickb might have set up, but if he's not responding to personal email or phone calls, it seems reasonable that he simply doesn't/can't know that the site is down.

_why has never really made "products" -- in fact, as far as I know, he's never made money from any of the stuff he shared online. (Sales of physical copies of the Poignant Guide may be the one exception to this, but IIRC, he priced it exactly at his cost in order to insure the widest possible distribution.)

Have a little respect. Unlike most of us here, _why never profited directly on his online celebrity status. If he chose to remove himself from the 'net, it seems only reasonable that he would want to shut down public repositories he managed, if only to avoid the inevitable deluge of complaints about them going stale, requests for commit rights from other people, etc.

The fact that you would care more about his shepherding of repositories which have been available to everyone else all along speaks volumes to me about the kind of attitudes that probably helped to drive him offline in the first place.

_why has always been an unusual guy. He has always prized his pseudonymity online, so I'm honestly not entirely shocked to see that he has decided to simply pack it up and move on.

It's a sad day for all of us, but I hope and trust that he has good reasons for this decision. His contributions to the world of Ruby and programming-as-art will not be soon forgotten.

L4 isn't UNIX. It doesn't even have a POSIX userland, necessarily, and certainly wasn't designed with 70s hardware limitations in mind.

<speculation> The L4::Pistachio kernel provides direct access to high-resolution hardware timing interrupts, though the secure variant may restrict some timer access in order to prevent covert timing channels between threads in different security contexts. </speculation>

You're generally right about complex specification and verification being popular in the defense and aerospace industries. However, I think that you may be mistaking a secure microkernel for a real-time one.

There are hard real-time variants of L4 out there, but unless that was a primary goal of the NICTA team, I don't think you're likely to see many copies of that kernel running a ballistic missile's avionics package.

A verified secure OS kernel like this would more likely be used as a substrate for building secure servers and workstations, network routers, or mobile communications devices.

I have actually seen code like this in production. A "senior engineer" I worked with decided that C++ DOM parsing code was too verbose with so many checks for null child nodes, so he wrote a set of macros which wrapped setjmp/longjmp and trapped SIGSEGV to allow resuming any code that tried to traverse a null pointer.

If of course made debugging effectively impossible, not to mention catching all segfaults, not just those triggered by a DOM parsing error.

Java bytecode is Turing-complete, so there's nothing explicitly preventing you from implementing many of the advanced features of C# atop the JVM. As the OP stated, alternate languages running on the JVM (such as Scala) already do this.

The problem is simply that most Java shops use only the officially-blessed Java language. Because Sun has always forced "certified" implementations of the language and platform to conform to their standard, there has been little room for innovation in the source syntax and bytecode format since the release of the first JDK in 1996. In the meantime, programming languages (and the programmers who use them) have moved forward, and Java has failed to keep up.