bergkvist

Or deciding where to send a drone attack to take out a political opponent

If you are using an Apple Silicon laptop and you want to deploy to an x86-64 Linux box, this can get a bit annoying due needing to deal with cross compilation in nix.

Golang is not a replacement for C. It is a much higher level language, which doesn't play well with systems programming/embedded development etc.

Yeah, I remember in the early days, when I installed Spotify it would scan my computer for music and upload everything it found. I imagine this is basically how they bootstrapped

See https://news.ycombinator.com/item?id=37920655

Note that it is in Swedish, and one of the articles is behind a paywall.

- https://www.aftonbladet.se/nyheter/a/on2Rpg/uppgifter-krimin...

- https://sverigesradio.se/artikel/kriminella-kan-skriva-sig-p...

Shootings through apartment doors is relatively common, here are a few of the incidents from 2023:

- https://www.incharts.se/en/shootings/shooting/stockholm-2023...

- https://www.incharts.se/en/shootings/shooting/malmo-2023-10-...

- https://www.incharts.se/en/shootings/shooting/jarfalla-2023-...

- https://www.incharts.se/en/shootings/shooting/botkyrka-2023-...

- https://www.incharts.se/en/shootings/shooting/stockholm-2023...

- https://www.incharts.se/en/shootings/shooting/upplands-bro-2...

- https://www.incharts.se/en/shootings/shooting/sodertalje-202...

- https://www.incharts.se/en/shootings/shooting/stockholm-2023...

But you can't look it up anonymously. You have to authenticate with your national ID number, and the person will be notified about who looked up their income.

Actually addresses being public are causing issues. Sweden has a lot of problems with gang violence, and gang members often register their public addresses to other peoples addresses, causing innocent people to be killed. The address you enter is in no way being verified beyond it needing to be a valid address.

ptrdiff_t is a signed integer type - which means you can subtract these numbers without worrying about underflow

`fetchTarball` with a github archive link is much faster than `fetchGit` for bootstrapping nixpkgs.

Yes, you are right - I misremembered this detail. My problem at the the time was I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons). So I had to unstage and restage it every time I created a new commit.

A derivation is simply an attrset with `type = "derivation"` as a key-value pair in it

My use case here is not using pkgs.fetchgit etc - but rather when developing a package locally and rebuilding it.

Let's say I'm working on a huge monorepo locally, with GBs of code and data in it, most of which I want to ignore in my nix build. Let's say the files I actually care about are also not in a single subfolder. Then I can't just move the flake.nix to that subfolder either.

The biggest show-stoppers for me with flakes is:

Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later.

Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time than I'd like to admit wondering why what I'm building doesn't include my latest change.

Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms.

This kind of copying would likely be a lot more acceptable if it was specified explicitly in flake.nix, rather than implicitly. Then you could also use your own filters for ignoring files, rather than relying on the coupling to git and its staging area.

I feel like looking at the first working versions of a big successful project is a great way to understand how it works.

Usually it will only contain the most important core features without a lot of abstractions/generalizations. So it is actually manageable to read through all of the code in a couple of days.

Also the ability to connect to external displays is missing - which is a pretty big one.

It is funny because it is the exact opposite of what you should do if you want to stop corruption.

Deregulation is the best cure for corruption, because it makes the gatekeepers obsolete. There would be no reason to bribe them because you don't need their approval in the first place.

No amount of abstraction is going to save you from the problem of 2 processes manipulating the same state machine.

I was expecting this to be about economic bubbles for some reason

I have to disagree that fork is evil. fork is great because of copy-on-write. I guess my particular use case is not very typical/common though.

I'm running powerflow simulations on a power grid model (several GB of memory to store the model). Copy-on-write means I can make small modifications to this model and run simulations in parallel. Thanks to fork/copy-on-write, I can run 32 simulations in parallel, each will small modifications without requiring 32 times as much memory.

Inheritance in OOP is what I like to think of as "structured patching".

When you create a .patch-file with `git diff`, you are essentially creating an inheritance hierarchy. Imagine having 5 patch files that are applied to the same code file in sequence. This is analogous to an inheritance hierarchy with 5 levels.

patches/inheritance is a very useful tool when you want to make some changes to third party code you depend on before using it - while minimizing the maintenance burden of these changes.

Inheritance/patches is also a very useful tool for describing/representing changes to your own code, but only as a temporary measure - you want to flatten out the levels of inheritance/patching for readability. With .patch-files, this can be done automatically. With OOP/inheritance, this is more of a manual (although still straight forward) process.

A git repository with 1000 commits is essentially an inheritance hierarchy with 1000 levels. Note that git will automatically flatten out these patches when you check out a certain commit - which is what makes git such a great/usable tool. Imagine if git could not do this flattening automatically. Code bases would quickly become unmaintainable if they wanted to retain their change history.

The biggest limitation of using Docker for building images is that it does not allow for composition. You can't simply say you want to combine a Python and Rust image for example.

With dockerTools from nix (https://nix.dev/tutorials/building-and-running-docker-images), this kind of composition is easy. You also end up with significantly smaller image sizes - containing only exactly the dependencies needed for the image to work, which is also good from a security perspective - since it decreases the attack surface.

Nope, should be open to access for anyone. But I posted the wrong link. This one should work: https://hub.docker.com/r/bergkvist/lib-lagraph