Lethalman

I need to login to see anything. I walk away.

https://xkcd.com/927/

It was also incredibly difficult. As a kid I couldn’t go beyond the first level. It was also difficult to attack the enemy at the right time.

But still it was an amazing experience whenever I played it. I felt the pressure and the need to start again like no other game nowadays.

But maybe that’s just because I was a kid.

“Written in X”. Every time I look elsewhere when I see it. When is people starting to think about features instead of “it’s better because I rewrote it in X!!”

A web fetch is not much different than asking an MCP for its tools, right?

Wish it wasn’t rust… it’s so hard to read.

To ensure monotonicity, retrieval of the idempotency key and emitting a message with that key must happen atomically, uninterrupted by other worker threads. Otherwise, you may end up in a situation where thread A fetches sequence value 100, thread B fetches sequence value 101, B emits a message with idempotency key 101, and then A emits a message with idempotency key 100\. A consumer would then, incorrectly, discard A’s message as a duplicate.

Also check out Lamport vector clocks. It solves this problem if your producers are a small fixed number.

I think it's because the docs say "If there isn't enough memory, you can't run a JOIN." . While SQL on Hadoop solutions work also without enough RAM by spilling on disk. I don't think a comparison with JOINs would be fair in this case.

You are right. It's unfair, I'm going to modify the post to mention alpine.

The post is both about tiny images AND how to build docker images with nix. I think it was an interesting tooling to make for our community. Some Nix people are already using it for obvious reasons.

The blog post code is supposed to run with latest master since a few days. We've merged a big change that leads to reducing a lot the closure of our packages.

Nix moves fast enough, in the sense we usually do a good job at not breaking things. Yet we have to necessarily introduce innovations in our frameworks.

You don't need in fact. But sometimes you are forced to use Docker anyway.

Always liked and used LyX, and never looked back. LaTeX is not for humans in my opinion, nobody should ever write LaTeX by hand.

How Nix solved the issue:

1. Each go package has an attribute name in nix, like anything else, that is not tied to its url.

2. Each go package has an url where to fetch the source from, which is not the import path to use the package.

3. Each go package has a number of old import url aliases (e.g. "code.google.com/...")

4. Whenever a package X depends on Y with an old import url, then X is rewritten to use the new url path of Y using govers.

So the problem is solved at our packaging level.

This is not to say it's the best solution, but certainly a good alternative solution.

Sorry, where is it said they will stop development of Persona? The homepage and the service seem to be in full health, there's no warning anywhere for users of Persona.

Is there any official statement that Persona will shut down?

I've looked at knex. But I felt it not to be as composable as sqlata.

In knex operators are written with .where() itself. Also it doesn't manage table aliases apparently. And it's quite tied to an underlying connection as I can see.

But yes, all the sql bulders out there are quite similar, but there are notable differences compared to sqlata if you look deeper.

You also upgrade grub versions I hope :) Or maybe improve the grub installation scripts.

Things you must be afraid when using nix:

1) If you install a bad grub, you cannot rollback it using nix. That means, not a wrong grub line, but if grub itself is broken.

2) Anything that is not under nix control, the data: like desktop configurations, databases, ecc.

It's a different approach. That's basically an implementation using ostree. Nix is way different than that. Neither is better in my opinion, but I use Nix happily.

There's a /bin/sh because libc needs it, but we're going to remove that one too in the future somehow.

But /usr/bin/env is in nixos to make it easy for people to run scripts. But packages never use /usr/bin/env, it's just there for convenience.

How we solved it in Nix: http://lethalman.blogspot.it/2015/02/developing-in-golang-wi...

We don't need go get or any other tool, and we have about 174 packaged libraries in our repository.

So I haven't seen yet in the website a code sample showing how a simple ping-pong actors would communicate, so I can't even test quickly if this is possible with the language.

If the program can implement a lock between the two actors, then your language is not deadlock free. Even a loop by checking if some variable has changed by the other actor (if possible in this language, I still don't even know by the deep lack of examples), and the other actor doing the same thing, that can be claimed as deadlock.

Stopped being interested after reading "It's deadlock free!", "because Pony has no locks at all"... yeah but actor X waiting for actor Y which waits for actor X is a deadlock. It's not a matter of lock primitives, it's a matter of software. (yes, x-comment from reddit)

Missing Nix/NixOS/NixOps :( Which is build, continuous integration, deploy, configuration management and provisioning. Everything with a single language.

H1Z1 and PlanetSide 2 switched reddit banners: http://www.reddit.com/r/H1Z1 http://www.reddit.com/r/Planetside/

That's because PS2 says they get cheaters from H1Z1, and viceversa.

repost https://news.ycombinator.com/item?id=9207999

This is a nice algorithm and I thought about writing something that only depended on numbers and not on allocating nodes in a ring.

It works well when adding nodes, but then how does it work when removing a node in the middle? When allocating nodes in a ring it's easy, just reassign the vnodes. But what with this algorithm? Can anybody explain how does it keep track of which nodes take control of which part of the removed node?

When there was no React.js, I had in mind something like that and implemented a very simple concept like this with ghcjs. Functional languages tend to let you write this kind of code.

It felt very organized and just worked, then I looked at Elm and said: "that's exactly what I thought I'd do with ghcjs". Then with react.js: "finally somebody implemented the concept in plain javascript". Which is after all a kind of stricter mvc model for the single-page web applications. The fact is that with an haskell-like language, the kind of mvc concept is much more structured, you do less design mistakes because the language itself constraints the effects. So what react.js did is adding these constraints on top of plain js in an elegant way.

In other words: I think the addition of elm is the language itself, for those acquainted with haskell and where type checking matters a lot, compared to plain js.

On the same path, there are other libs similar to react.js that are even faster because they have stricter requirements on how data is mutated.

It's already like this, there's no initial sync.

No I've just read about it on HN today. It's interesting. I guess for millions of files you finish inodes quickly if you don't cut the history periodically. But it's a good idea.

You mean only one way from N machines to a single machine? Yes. When other machines add/change any file it will be uploaded to that single machine.