hosay123

I don't support anything this guy said, but clearly some of it was sarcasm, and as for the rest of it, differences of opinion are entropy, and every time we suppress them, the universe gets that little bit colder and humanity dies that little bit quicker..

There are no winners here. I find everything about this episode a disgrace on both sides.

As I understand it, creating a proof becomes increasingly more complex in proportion to program size. You'll notice in this project, their proof only covers a few hundred lines of code. That's not because their program just happened to be a few hundred lines of code, but because they designed it to allow a practical proof.

Or at the very least, preserving the time offset.

It's also not possible to occasionally listen and unlisten.. that causes the hash modulus to change, sending traffic to the wrong sockets and (most likely) resetting all existing connections

"Computer, create a rule for my car."

"OK. Which car? Do you mean Red Toyota Purchased 1997?"

"Yes."

"OK."

"Computer, when car is at location House, then boil kettle."

"Do you mean Kettle in Kitchen of 48 My Road?"

"Yes."

"OK. Is that all?"

"No. Computer, this rule is only valid on weekdays."

"OK. So when car Red Toyota Purchased 1997 is at location 48 My Road on Monday, Tuesday, Wednesday, Thursday, Friday, boil Kettle in Kitchen of 48 My Road?"

"Yes, but only if my iPhone was not inside the car."

"Do you mean Jemima's Apple iPhone 4Gs?"

"Yes."

"OK."

...

Callbacks are in no way "this generation's goto", they do not in any way inhibit the ability to analyse or prove correct a program, and all alternatives to callbacks amount to incredibly fancy syntax sugar for hiding what is really happening behind the scenes anyway.

A callback is a function call, or put another way, a specification of an exact set of arguments grouped in a formal specification that is sent to a deterministic little machine (the function) to execute immediately. On completion the machine will provably produce the result it promised to return in its owner's manual (i.e. the declared return code).

None of this is "goto" in any way. In goto land, without knowing the exact set of inputs a program receives and whole-system simulation, it is utterly impossible to make assumptions about even the most minimal pieces of state in the program at any given moment.

Contrast to a function call. A function call is a fixed guarantee about the state of the system at the point a machine begins executing. Furthermore a function call has a vastly restricted set of valid behaviours: at some point it must terminate, and prior to termination, update the system state (stack) to include its return value. And upon termination, result in the calling machine to resume operation.

All this syntax sugar shit is whack. Great, you typed 24 characters instead of 3 lines to declare a lambda. Hyper productive, go you. How does this progress toward the point where I can say "computer, make me a coffee!"?

If you're genuinely interested in what this generation's Goto might look like, take 30 minutes to watch http://vimeo.com/71278954 .. our UIs are utterly trapped in pre-1970s thinking, our communication networks are so utterly idiotic that we STILL have to write custom code to link disparate chunks of data and logic together, we're STILL writing goddamned function calls in a freaking text editor (something that was solved LONG ago). All the things like this.

I can't ask my computer to make me a cup of coffee, and it responds. I can't describe in restricted English a simple query problem and have the millions of idle machines around the world coordinate meaningfully to answer my question (and our best chances of this.. freebase.com.. got bought up by Google and left to rot as some vestigial appendage of their antispam dept no doubt).

Computing is in a sad state today, but not because of fucking callbacks. It's in a sad state today because we're still thinking about problems on this level at all.

Node.js wasn't an innovation. It was shit that was solved 60 years ago. I wish more people would understand this. Nothing improves if we all start typing 'await' instead of defining callbacks.

Innovation in our industry has been glacial since at least the early 90s.

Edit: and as a final note, I wholeheartedly welcome you to nitpick the hell out my rant, wax verbose on the definitions of provability, the concept of a stack, the use of English versus American language, why Vim is awesome, and in the process once more demonstrate the amoeba-like mentality 90% of our industry is trapped in.

Go and build a programming language your Mom can use. Preferably by talking to her computer. Please, just don't waste it on any more of this insanity.

Edit: it wasn't IRC, it was the comments here: http://lwn.net/Articles/560424/

Sometime later when this repository was noticed on Github, someone noticed the source was a derivation of one of the existing Linux FAT filesystem drivers. In other words, under the terms of the GPL it is derived code. The fact it was only previously distributed in binary form does not excuse this: Samsung were distributing GPL derived code in violation of the license.

So this clears things up a little bit. What I don't understand now is the usefulness of this code. For example, could it potentially be merged upstream? If not, then why not? If it can be distributed under the GPL independently, I don't understand why it couldn't get shipped with Linux.

The fact this driver exists "legitimately open source" now, yet is still covered by patents, confuses me a bit.

Consider a network server running a Twisted main loop, serving static files from cold mechanical disk. In this case, you could have 80 or more disk IO worker threads running without feeling any contention, assuming they're asleep for a minimum of 12ms/request, which would be an ideal seek time assuming the disks weren't under any load.

Assuming one disk, those 80 sleeping threads do something particularly useful that's difficult to accomplish without threads: they let the kernel IO scheduler reorder the requests to minimize seeks, and in a much more general way than the large variety of crappy AIO APIs available on UNIX.

There's a trillion uses like this for threads in Python.

For any given series of boring events, the most fantastical explanation that ties them all together must obviously be true.

As another comment points out, why bother when you already coordinate a massive sniffing effort affecting large chunks of the globe?

This would have made sense to me a decade ago, but back then I just wouldn't have understood the amount of work involved. You simply cannot produce a fully generalized container OS without producing a fully generalized OS.

That aside, I actually like the central idea of a better approach to managing/updating a large group of host machines. I just don't think it warrants yet another bikeshedded support/security/certifiability nightmare (and lets face it, this is bikeshedding, there's absolutely no value in the core claim of "it's just Linux", but it gives unfettered license to reinvent the same old wheels all over yet again).

When you're done there, now try plugging your nice new machine into the corporate DC. Oh it seems it needs to support VLAN tagging. No problem, better just write some new code for that.

Time to migrate a bunch of performance sensitive services. Uh oh, no support for FusionIO PCI SSDs! Better write some more code.

Time to migrate your remote sites, only policy dictates certain services must be physically encrypted. No problem, better just cutpaste Debian's cryptsetup scripts and be done with it.

Oops, turns out we deployed 1000 machines with a duff BIOS setting. No problem, I'm sure the server vendor has a support package for CoreOS..

We could come up with examples until we've basically reinvented a modern Redhat/Debian initramdisk and boot environment.

You can look at CoreOS the same way as the Xen hypervisor and VMWare ESX: the more flexible these became (new hardware drivers, supported configurations, etc. etc) the more they began to look like general purpose operating systems. At which point, why not start with one? (Kvm followed the same logic)

I'd much rather see the guts of CoreOS available as e.g. a RHEL or Debian package. As it stands, throwing away 20 years of distribution experience just to avoid installing a few files on my server seems far from worth it.