_hl_

> But when we actually attempt to do something in Nix, we run into countless bugs and problems, including inaccurate documentation.

This is really unfortunate. Unless you invest time into learning which paths to walk, you're not going to have a great experience with Nix. That just doesn't scale to modern engineering teams, you can't expect everyone to know everything.

> Plus, a coworker pointed out that while its supposed to be pure and functional, many recipes still basically wrap a shell script. So its not that far from the build system we already have...

It's true that a lot of nix expressions boil down to a shell script. But by default they're running in a sandboxed environment that can be exactly replicated and guarantees (mostly) reproducible results. And that's great - after some ceremony to set everything up, Nix lets you work with the tools you already know, but puts them into a reproducible environment.

> Error messages that tell you absolutely nothing about what went wrong were pretty common.

Maybe I'm holding it wrong, but I almost never get useful error messages from Nix (NixOS and NixOps). Almost every error is deep within some module with no trace to the option I set. Just nix barfing its 300-line eval traceback where my own code doesn't even appear.

> Curious about the toxicology report

The report alone wouldn't be sufficient proof either. You can murder someone with fentanyl.

The constants are enormous enough that you'd never want to use these algorithms in practice - for now, at least. There's a key problem that uf resolved would allow quite efficient implementations of this family of algorithms even on the GPU, something that previously wasn't really possible for such graph algorithms.

I spent some (too many) months looking into this domain so I can maybe give some context.

The astonishing improvement here is that we can compute exact flows in almost-linear time. Previous algorithms for computing almost-optimal flows in almost-linear time have been known for some time, and hence it was expected that someone would eventually find an algorithm that finds optimal flows in almost-linear time. Well, looks like it's finally here!

I've only skimmed the paper but it seems to me that the authors draw on a set of techniques established for the almost-optimal case. These come with rather enormous constants, so it is unlikely that there will be a practical implementation of this algorithm any time soon.

xi-editor has some reasonably sophisticated handling for large files

Absolutely. Emacs is a great UX layer, only lacking a modern UI rendering layer. Would be nice to have emacs with a DOM-based rendering engine.

Right now we're still in closed beta, but we'd love to chat!

Awesome! Would love to chat if you find the time and learn more about how we can make this process easier; email is in my profile.

Hi all,

Super excited to share what we've been building over the past few months. We are CellAware, a tool that brings automated verification from software to spreadsheets. Think symbolic execution et al, but applied to spreadsheets. Our software analyses your spreadsheets to identify constraints (e.g., revenue should be >0) by pattern-matching to our internal database, and then uses sophisticated secret sauce to identify errors in your formulas. Initial testing showed this to work much better than we would have originally anticipated, catching a large number of errors that would otherwise be difficult or tedious to track down.

Looking forward to hear your thoughts!

Notable alternative for emacs users: Github supports rendering .org files, so you can have a README.org using babel (just remember to execute all code blocks before pushing).

Because they receive additional information from the environment through highly sensitive sensors producing massive amounts of information. Whereas the information you get from a cheap sensor effectively discretizes to a few bits.

You cannot conjure information out of thin air. Even with infinite data and a hypothetical wormhole CPU that runs everything in O(1) and solves the halting problem, you still couldn't do this. So to answer your question, the reason is effectively (A). Sensor resolution might be the wrong term but it's the general idea.

What's next, a database in pure bash? It's really impressive what some people can do with a couple of shell scripts.

But that's just, like, your opinion, man.

I think Windows is crap and yet it has billions (!) of users.

Usually job queue libraries provide other niceties like tight language integrations. While you could probably build a job queue with a decent API in pure postgres, it wouldn't even come close to e.g. just slapping @task in front of your method like in the post.

It's fairly standard practice to hack in some "green thread" behaviour using gevent or similar. It's far from perfect but gets you away from the single-process-per-request bottleneck. If it even is much of a bottleneck in the first place - isolating each request in its own process worked well enough back in the CGI days. I suspect the real reason is that autoscaling doesn't generally play well with having thousands of mostly idle processes.

Sounds like you're looking for partial evaluation for JS. From a quick search, prepack.io might suit your needs?

Fermat's little theorem. I'm not aware of an intuitive explanation unfortunately.

On the face of it not, no. But when you consider the immense power and versatility of it (you can do anything from setting up simple virtual envs to automatically deploying a multi-container setup on AWS), it starts to become a lot simpler than the sum of all the other tools that it replaces. Nix is a single principled idea, but can be used in so many different contexts.

> "Diverse" people use what ever panders to their race or sexuality the most, and Google panders to them far more than Mozilla ever could.

At the risk of sounding ignorant, how the fuck can a browser, the most universal platform we have right now, cater to any specific minority group? I'd get it if you were talking about accessibility, but what does the browser have to do with your race or sexuality?

Tangential, but from the cutter website:

> No Java involved.

What an odd thing to advertise as a feature.

I believe I know what you're referring to but can't find the link anymore now.

The main takeaway for me was that by busting a major drug ring, you are only helping the other major players b removing competition. They will fight each other (brutally!) to take over what was left behind by the now defunct ring, and instead of two or more large drug rings, you now have one massive monopolistic drug ring, and everyone is worse off.

I'm not sure what a solution here is. The more you fight organised crime, the more they fight back, and the situation escalates and becomes more violent to everyone involved. Perhaps decriminalisation along with better support infrastructure for victims and addicts could help?

> to jitter the system clock to spread out any radio interference caused by the motherboard

Fascinating! That seems very counterintuitive, where can I learn more about this?

I think it's folly to try and grasp the nuances of "Dummheit" as Bonhoeffer used it 80 years ago from our modern usage of the word. It depends on how the word was used at the time. Even today it depends on context, although generally you are right that it leans a little bit towards silly.

My reading of it is that it's essentially one-to-one (up to minor constant factors), they took the binary circuit for xorshift128 and replace the xor gates by functionally equivalent NN blocks, and then trained the weights.

The proof accounts for that. You can even allow for the ANN being totally wrong on "almost all" seeds except for a non-negligible fraction, the definition of a CSPRNG allows for that. If it is wrong for all but a negligible fraction of seeds, then you haven't gained much over random guessing. So the only way that an ANN could help is if the ANN approximation is sufficiently bad that it doesn't give you any significant speedup in cracking the CSPRNG.

Of course, this is assuming that practical CSPRNGs conform to the theory, but we're just debating theory here.

> That's somewhat equivalent of partially seeing the secret internal state

Not just partially, xorshift128 is designed such that the output depends only on the last 4 results. So this is "just" learning the output function of xorshift as a neural network.

The argument is fairly straightforward: Let n be the number of seed bits of the CSPRNG. Assume there exists an ANN that approximates the CSPRNG so that the number of possibly wrong output bits is at most polylogarithmic in n (otherwise you haven't really gained much insight from the ANN). Assume further that the ANN is sufficiently small so that a forward pass through the ANN takes at most polynomial time in n. Then you can create a polynomial-time algorithm that (i) runs the ANN on the observed CSPRNG samples/by querying the oracle, and then (ii) brute-forces the possible error bits in polynomial time, thereby recovering the full seed. But this is a contradiction with the assumption that the CSPRNG is secure, i.e. that it admits no polynomial-time adversary, q.e.d.

What they are doing is essentially encoding the binary circuit of the xorshift128 PRNG as a neutal network. The fact that you can encode abritrary binary circuits as neural networks is well-known, so it's not surprising that it is possible to do this.

The interesting and perhaps surprising result is the demonstration that it is possible to train this network using standard gradient methods, when choosing the proper loss function for the problem and designing the network with the required domain-knowledge of the algorithm it is supposed to model. In other words, this can be seen as an example of how well-educated network design and choice of loss function massively impacts the performance of your fancy ML model.

For more "real-world" problems, it is often very difficult to come up with a network design that encodes the implicit constraints of the problem, mostly because these constraints are not even known (that's why we use ML!), but results like the recent AlphaFold show that even for these problems, thoughtful design of the model architecture goes a very long way.