clord

"Book author" is at least closer to the truth. There are editions and old copies floating out there, it's hard to estimate completion dates, and authors have many of the same copyright problems. The difference is that software must live in a dynamic and shifting 'house' where everything gets rearranged by vendors, probed for weaknesses by attackers, and new features are constantly demanded by the users. Solutions to all of this are tacked on as an endless stream of appendices. Throw in patents for extra insanity. Both analogies strain to fit this reality.

Edit: That brings me back to the article. "Finishing software" just means we should act more like authors. Very hard to achieve when you think of the differences above.

With what we know now about beneficial bacteria, I wonder if, in addition to the pathogens, we're killing probiotics? And perhaps the lack of exposure to mild bacteria mean we're more susceptible to immune diseases?

Of course getting rid of the pathogens is a great thing, but perhaps chlorination plays a role in causing some modern problems that are related to the immune system and the gut biome? Anyone have links to studies done on this topic?

I think jahnu was referring to obtaining the private keys for a trusted signing authority, which would enable said agency to create valid-looking certificates for the purpose of MITM. Weak algorithms are also concerning, but not really the subject of OP.

It might help prevent crap-tastic apps on the store because it changes the incentive structure. If the subscription is doled out in proportion to time spent in-app, the incentive on developers would be to maximize engagement time, which might be a good thing for users. For paid apps such a scheme would be a problem since it would likely reduce income, but as a way to get money to fund free apps, not a bad idea actually.

We're in the final stages of migrating a large non-web system to react for a client right now (we're up to ~200kLOC of JS) first big project our new company is doing. Next time I'd use an immstruct layer for maintaining state, and maybe a thinner vdom library instead of react. Not a fan of flux at this scale, it's too easy to have components being dependent on their position in the tree, so we tend to have lots of wrapper-boilerplate that just pulls data out of the store and pass it to immutable components. I'd rather just have a module dedicated to the task, and have immstruct sort out how to dispatch updates efficiently, acting as a 'JSON-view' of the server's state.

On the other hand, some clients seem to have heard of react now, so that's a big plus of using it. We'll probably end up doing more.

Exactly. Clang makes platform-specific lowerings and bakes in some ABI-specific gunk. Granted not so much as the object code on the other side of the back-end. Enabling target-specific vectorization and whole-program optimization are probably the goal.

Not saying I think gold is a good investment or that the system is in any danger, but it's obvious why gold is still important. Just as with bitcoin and unlike fiat currency or IOUs, it's quite hard to forge metal (or proof-of-work) into existence. Having something unforgable is a hedge against inflation, not against catastrophe.

It's worth noting that lately there has been talk[0] of using the cashless society in order to implement negative real rates. Negative real rates are a way to fight inflation (by removing money directly from bank accounts), but typically such rates are not possible because people will just hold gold and physical cash against negative rates. In the past such behaviour is what prevents rates from going negative.

[0]: http://www.bloomberg.com/news/articles/2015-04-10/citi-econo...

> The question then becomes: why would anyone do them, and (somewhat linked) what are the chances that anyone will do them to you?

Let me rephrase the items from the GP comment:

1. A company that your boss hires will tell him when you lie about being sick.

2. Your insurance company pays to find out how often you do risky things when not driving

3. where-is-she.com charges 29.99 per month to report on someone's location at any time, using open drone surveillance data.

The point is, all of this can be turned into businesses and government services. In my opinion it's damned scary. I like Snowden's remarks on the topic:

> Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say.

> Anyone who would pursue IBM in hopes of 'incubating a startup scene' is, not to put too fine a point on it, grossly incompetent

Could be they are geniuses: banking on IBM laying off tech workers in order to get the startup scene going in the wake. Scratch that. Having seen some of these legislative bodies at work, that's too advanced.

We went through this at my former employer (not MS) just before i left. In fact the politics surrounding it drove me to seek relative sanity of doing a startup. When I started working on it, there really were two camps: clang emitting house IR instead of LLVM IR, or translating LLVM IR either early (right out of clang) or late (as a target after all optimization). I was working on the prototypes for the latter pair of options before another constraint was added that invalidated all of those paths.

The problem was that clang is quite intertwined with LLVM IR. ABI is spread all over the place, both FE and BE. It was proving hard to get something the house optimizers/code generators would be happy with. So a more radical path was chosen — wiring clang's parser + ASTs to another C++ front-end's AST and then using the old IR generator to get all of the idiosyncrasies right for the target. It was wacky, but seemed to be half-way working when I left, such that major open source code was compiling.

The whole idea of taking just parts of clang/llvm reeks of a half-measure anyway. It's probably better to either keep the existing compiler stack, or cut it right out and put the secret sauce into LLVM as add-in modules.

That was my first thought too. Since sometimes these are sub-second trades, it'd be interesting to look at whether they're physically possible (i.e. whether speed of light is respected.) Would explain stuff like [0].

[0]: http://www.washingtonpost.com/blogs/wonkblog/wp/2013/09/24/t...

That was exactly my point. thank you. Humans last longer than machines because we self-repair and acquire our own energy. Last I checked, human-made machines do neither of these things. Not sure why I was down voted for pointing that out?

Unlikely. It was a terrible thing that is being taken advantage of by politicians to advance their agenda of increasing their own power.

Um, Last I checked, not many human machines can continuously operate up to 100 years. Most robots and machines like cars are considered "long life" if they last 30. Seems to me the human body is built to last.

It's interesting work. I wonder how much input energy is required to mine, refine, and build the required silicon and titanium oxide nanowires? If it's less than 1 to 1 with the lifetime output, then the tech will need more work to be a real solution. Hopefully it scales.

DPI of final print, not the sensor. Large format cameras could even have larger DPI than an SLR and still get vastly better pictures. Large format CCDs exist, but are very expensive, and of course have different performance characteristics than film.

It's certainly complicated and my answer probably does not apply to such a trivial example code that is using mostly stdlib functions. But the potential gain for Haskell is with loop fusion. The user could implement all of those functions themselves (sum, take, etc) and then loop fusion will bind them into a single performant loop that the lower optimizers will turn into a straight-line code, whereas in procedural languages only stdlib functions and certain patterns of general functions get the fusion treatment. Worse, throw in an unfortunate alias into the procedure and the whole thing collapses into sequential loops.

Wouldn't a carpet-block defeat the purpose of keeping greatfire on the site? Might as well just remove the offending content, since the attack would have achieved it's goal: preventing people in China from accessing content on github.

If someone has a recent clone and the licence was compatible, is there a reason a fork can't be started?

Not always true. For a trivial example, in fortran code, we'd often see people wanting to write code that calls runtime methods directly because it leads to clearer implementations. The language rules were such that we could prove invariants on these runtime calls that were much stronger and farther reaching than the general bitcode optimizer could do, resulting in a class of matrix operations going to n*lg(n) from n^3, and we could also switch the stride direction to make better use of cache because of the algorithm change. This sort of thing was only possible because language knowledge was exploited — generic optimizers will miss this stuff.

I think the future of languages like haskell are bright in terms of performance, because they are so loosey goosey with what gets evaluated when, which gives language-aware optimizers a lot of meat to chew. An aggressive optimizer could turn out versions of the same code that run screaming-fast single-threaded, or that fully exploit massive parallel machines, or even version for all of those.

Also worked on compilers at a major chip company. Generally it's better to have clear code than fast code. For that reason I would say that the future of optimization are things like whole-program optimization that exploits language features to improve the asymptotic costs of mechanically provable algorithms. For a primitive example, consider taking a simple Haskell program that is provably correct but needs O(n^3). Put it through some 'equivalent optimal implementation' system that provably spits out an algorithm that does the same task in O(n lg n).

We did stuff like this for simple matrices in Fortran and C, but I think it is generalizable to more problems than that.

And of course, I agree that most of the time no one really cares except HPC.

I imagine the multinationals get to play both sides of the negotiation — they can lobby it to both governments. Hence it's probably mostly all carrot ("Sign and you'll get lower barriers to your own products"). I can imagine there may be some stick too: Sign this or you'll lose access to Disney and pharmaceuticals.

Ok this did it for me. That's incredible. It's almost into the audible spectrum. That means they're churning them out at something like that rate too. And then realize that not too long ago any one of those iphones would have been the most powerful computer on earth. Seems like a waste of effort? Why are we making smartphones with all of those resources? We could be doing something... less repetitious.

The only thing I can think of: a good HFT algo might be able to exploit leap seconds to somehow gain an advantage over those that are ignorant of them (or vice versa).

You're assuming resources are liquid (meaning: able to be relocated for low cost). This is only true if you're trading, and civilizations trading energy can't really be separate civilizations.

The only civilization we're stealing resources from does not exist yet because it's in the future. We have one global civilization that is pooling a single resource base via highly liquid trade. There might be civil war between factions, but don't think a real resource war can occur under the current environment. Now, might we split into an 'eastern empire' and a 'western empire' like the Romans did? Quite Possible.

Although the naturalistic fallacy is real, please remember that the foundations of naturalism have some merit, so it's not a universal fallacy. In fact often-times biasing to 'natural' is the best way to get the right outcome.

This article is a great example of my point: Although there is a war going on in the womb that wastes resources, there are some very important side-effects that can only come of that war. The embryo is robustly tested for viability, cancerous growth is averted, and the embryo manages to get more resources. These are difficult goals to achieve any other way.

Other examples abound: Our diet is normally a delicate balance between cravings, metabolism requirements, our gut flora's needs, and so many more factors. Probably a war similar to the womb plays out in our gut, and probably with similar tradeoffs and benefits. The only way to duplicate this complicated machine is to let the battle play its course properly. So the question is, how do we do that? One answer is to look to the environment where this system evolved — in other words to adopt a naturalistic view.

Interference in these systems leads to the balance being upended, and problems developing. We even see this problem with software! When I worked for a large company doing maintenance on very old compilers, we would not interfere in the code too much for fear of triggering one of these imbalances. I think they arise because architects through the years are at war with each-other to impart their 'wisdom'. The result is a carefully orchestrated dance between enemy code, mediated by testcases.

Naturalism captures the idea that we just aren't smart enough to tackle these problems head-on. And even if we were, it might just be cheaper to allow the war to play out instead of duplicating all of its effects. It's only a fallacy because once in a while we are smart enough.

I'm just starting off working with nixops. quite nice IMO, although not getting into the meat of it yet (i.e., trying real deployments). Nix solves the dependency problem really nicely, and I can spin up machines from scratch really fast. Also curious about comparisons here. If this is a tight implementation of something like nixops I am stoked.

This puts incredible power in the hands of the financial industry. It is the most clear evidence I've ever seen for the shape of the coming (already here?) plutocratic era.

The far right has been rising across Europe lately[1]. And the far left for that matter[2][3].

[1]: http://www.huffingtonpost.com/elinadav-heymann/sudden-rise-o...

[2]: https://www.youtube.com/watch?v=hEKr_sDUPTE&list=UUZaT_X_mc0...

[3]: https://www.youtube.com/watch?v=U1MYMVfyHi0&list=UUZaT_X_mc0...

You're right, that reported failure rate is way too low, I'd be glad to only have 26 corrupt files. I have one disk with about 300gb of CR2 files (HFS+). Not long ago I did a similar procedure as in the article (except that I also had the files on a ZFS mirror (I was cleaning up the HFS disk and checking for duplicates before formatting) and found 250 files with bit errors compared to the reference. Fortunately only about 1 in 3 of the bit errors resulted in corrupt files.

Needless to say I no longer keep anything of consequence on non-checksummed filesystems now.