They think giving us a choice between ffmpeg forks will make us all jump to jessie, and just put up with the systemd/gnome3 abomination?

Not likely.

IMO, characterizing cryptocurrencies as either "the future" or "a passing nerd fad" is going too far. I expect they'll be with us for a long time, though they'll remain largely a nerd thing.

As for these online wallet services that keep getting hacked, taking the money and running, or otherwise failing... trusting your cryptocurrency to some random website is pretty much exactly like trusting your cash to some guy standing on a street corner with a sign declaring himself a banker. And, lest any object to "some random website", I must point out that "most users of FooCoins use BarExchange, therefore they must be trustworthy" is exactly as stupid as it sounds.

I think it's clear that, at least for now , if you're not enough of a nerd to be able to store your own wallet with enough encryption and redundancy to keep it safe from theft and data loss, you shouldn't be using cryptocurrencies for any sum of money that will hurt to lose. Wait till either they become popular enough that sufficiently-trustworthy-and/or-accountable banks or bank-like entities offer cryptocurrency-denominated accounts, or until some crypto-genius finds a technical solution to the problem of letting an untrustworthy entity keep your money in such a way they (or someone who hacks them) can't spend it.

And of course, having posted this, I go back to the main page, and see an article that (1) clarifies any question about this poll's intent, and (2) is really the right place to have posted the above... And it turns out you (bryan) even linked it in the post I replied to.

*hangs head*

I love approval and range voting, think they're generally the best option for choosing a single winner, and am delighted to see pipedot using one of them.

But , in a poll on "which features are the most important", I'm not sure approval's the right answer.

Of course, it depends on what exactly you plan to use the results for -- if the idea is to only implement features that a certain fraction of voters approve, approval's good. But if the idea is that you aim for feature-parity with /, so all these features are to be implemented eventually, but you're seeking to prioritize the order of feature implementation according to community feedback, I think using a rank ballot with Kemeny-Young counting would be better. To me, the poll title suggests the latter, but I could be misinterpreting it...

The thing about approval voting is that (provided the voter is smart about their own threshold of approval) it's good at reflecting the strength of preferences (even though it quantizes them to 1 bit!) -- if you can't stand any but your two favorites, you won't accidentally contribute to the election of the guy you put as number 3. But the flip side is, it loses the order of preference between any two candidates you do approve, and between any two candidates you don't approve. So in a case where all candidates are winning, we just want to sort them, the information of preference order is IMO more important than preference strength.

For example, suppose 60% of voters approve both items A and B (may also approve others, but at least those two), 30% approve neither -- with approval voting, you're letting the remaining 10% decide which order to tackle these two features in (by the difference of (A, !B) vs. (!A,B) votes). But using a rank ballot, you get the priorities of all voters. Of course the 10% with mixed votes will have a known preference, but the 60% block gets to specify which of these two beloved features they find most important, and the 30% block gets to specify which of these useless-to-them features they care least about... end result, Kemeny-Young spits out an order of tackling the features that makes the most people happiest.

Consider it a test of your faith and/or the mod system...

Mod system: passed
Scott's faith: failed

Beware, for thou'rt strayed from the path, and thy UID mayest receive an additional digit if thou dost not reform thy ways.

Well, SoylentNews is down.

So I guess it's time to troll pipedot.

All your frosty piss are belong to us!

First, let me say that anyone the slightest interest in the topic of liquid fueled rocketry needs to read John D. Clark's Ignition! (pdf) . It's only 200-some pages, and well worth it.

Anyway, regarding methane, the ease of manufacture is definitely part of it, but there's more.

Two important, and largely at-odds, characteristics of a rocket fuel are that it must produce low-molecular-weight exhaust products, which maximizes Isp, and that it must be high-density, so a smaller volume is required, so the tankage weighs less. In the same vein, cryofuels are slightly worse than noncryos of the same density, because of the added mass of insulation required.

Hydrogen is a popular choice (particularly for upper stages) because its exhaust products (H2O, H2*) are the lightest you can get in a practical** chemical rocket.
Kerosene is also popular (particularly for 1st stages) because it's about 7x as dense as hydrogen, and not a cryofuel.
Methane is a chance to split the difference -- it's roughly 6x as dense as liquid hydrogen (it still has the cryofuel insulation penalty, though), but it has relatively light exhaust gases (2:1 H2O/CO ratio) compared to long hydrocarbons (H2O/CO ratios approach 1:1 for long-chain alkanes, and are 1:1 for simple cycloalkanes).

* fuel-rich mixtures are generally used for a combination of reasons (see Ignition!) including better exhaust mixture (H2 vs. H2O, or for hydrocarbons CO vs. CO2).

** such devices as Rocketdyne's test motor burning liquid lithium, liquid fluorine, and gaseous hydrogen (see Ignition!) are fascinating when viewed from a sufficient distance, but if that's what you would term practical, please tell me where you live and/or work so I can stay well clear.

Well, the second one was aimed at Debian. I wouldn't describe slackware in quite such terms -- there's a lot of people, and then there's a lot of people. And I really don't know enough about the organization to know what impact Pat getting run over by a bus would have. (And I hope I never have to find out.)

For your distro to last, you need one of two approaches:

1. one dictator who's such a tough son-of-a-bitch that he not only can defy ordinary counting sequences but also survives mysterious illnesses that every doctor misdiagnoses.
2. lots of people, and a sufficiently robust community governance model to make any of them expendable.

The distros that have followed one of these models have outlasted every distro that hasn't.

At this point, they're going for landing the 1st stage, with an eye to eventually reusing it. Full reusability (i.e. including the 2nd stage), probably is waiting till the next generation.

Of course it's all a bit experimental at this point -- nobody's ever soft-landed their heavy-lift liquid-fuel boosters (though the SSMEs are close, in a way), so what sort of damage they receive and what economical refurbishing practices will look like is not really known... depending on how many (and which) components turn out to be cheaper to replace every flight than to overbuild and maintain for repeated uses, "full" reuse may never happen.

I love Bo Diddley , you insensitive clod!

(I actually prefer the cover by George Thorogood and The Destroyers , but credit where credit's due...)

FUCK BETA