I’m not sure where this idea of high profile target comes from. The sim swap attack is pretty common. People just need to be in some credentials leak DB with some hint of crypto trading or having some somewhat interesting social media account. (either interesting handle or larger number of followers)

There are now organized groups that essentially provide sim swap as a service. Sometimes employees of the telco company are in on it. The barrier to entry is not that high, so the expected reward does not need to be that much higher.

Yeah it’s pretty amazing system all things considered. It’s kind of as if 8-bit home computer systems continued to evolve, but keep the same principles of being really closely tied to the HW and with very blurry line between kernel and user space. It radiates strong user ownership of the system. If you look at modern systems where you sometimes don’t even get superuser privileges (for better of worse) it’s quite a contrast.

Which is why it reminds me of Emacs so much. You can mess with most of the internals, there’s no major separation between “Emacs-space” and userspace. There are these jokes about Emacs being OS, but it really does remind me of those early days of home computing where you could tinker with low level stuff and there were no guardrails or locks stopping you.

GNU Hurd is going to be mainstream any minute now.

I couldn’t help but think of Emacs when I was reading A Constructive Look At TempleOS. It’s like TempleOS that is actually finished, it just lacks kernel.

Perhaps it’s kind of inevitable to have some bloat. For example apps these days handle most of the languages just fine including emoji, LTR/RTL and stuff. Some have pretty decent accessibility support. They can render pretty complicated interface at 8k screen reasonably fast. (often accelerated in some way) There is a ton of functionality baked in - your editor can render your html or markdown side by side with source code as you edit it. You have version control, terminal emulator, language servers, etc…

But then there’s Electron, which just takes engine capable of rendering anything and uses it to render UI, so as a result there’s not much optimization you can do. Button is actually a bunch of DOM elements wrapped in CSS… Etc… It’s just good enough for the “hardware is cheap” approach.

I think Emacs is a good example to look at. It has a ton of built in functionality and with many plugins (either custom configuration or something like Doom Emacs) you can have very capable editor very comparable to the likes of VS Code. Decades back Emacs had this reputation of being bloated, because it used Megabytes of RAM. These days it’s even more “bloated” due to all the stuff that was added since. But in absolute numbers it does not need as much resources as its Electron based peers. The difference can easily be order of magnitude or more depending on configuration.

First of all. Thank you for civil discussion. As you say this is weird place to have such discussion, but it’s also true that these jokes often have some kernel of truth to them that makes these discussions happen organically.

So with that out of the way and with no bad intentions on my side:

I’ve noticed you use Dockerfiles and Docker Images interchangeably. And this might be the core of misunderstanding here. What I was describing is that:

• Developer builds an image (using Dockerfile or otherwise) on their laptop and then pushes that image to a Docker repository.
• This exact same image is then used in CI to do integration tests, scanning, whatever…
• If all is good, this image is then deployed to production.

So if you compare sha of the image in production and on developers laptop, they are the same checksums. Files are identical. Nix arrives to this destination kind of from the other side. Arguably in more elegant way, but in both cases files are the same.

This was the promise (or one possibility) in the early days of Docker. Obviously there are some problems with this approach. Like what if CPU architecture of the laptop differs from production server? Well that wasn’t a problem back in 2014, because ARM servers just didn’t exist. (Not in any meaningful way) There’s also this disconnection between the code that generates the image and the image itself, that goes to production. How do you trust environment (laptop) where image is built. Etc… So it just didn’t stick as a deployment pattern.

Many of these things Nix solves. But in terms of “it works on my laptop” what I wrote in previous comment applies. The environment differences themselves rather than slightly different build artefacts is what’s frequently the problem. Nix is not going to solve the problem of slightly different databases because developer is runing MariaDB locally to test, but in production we use DB managed by AWS. Developer is not going to catch this quirky behavior of how his app responds to proxy, because they do not run AWS ELB on their laptop, but production is behind it. You get the idea.

When developer says it works okay on their laptop, what it usually means is the they do not have 100% copy of production locally (because obviously they don’t) and that as a result they didn’t encounter this specific failure mode.

Which is not to say, that Nix is bad idea. Nix is great. I’m just saying that there’s more to the “laptop problem” than just reproducible builds - we had those even before Docker Images.

Hope that makes sense. And again, thanks for civil discussion.

This is programmerhumor so perhaps allow for a bit of hyperbole on my part. I wasn’t completely factual.

However the initial days of Docker were effectively promising to solve the exact same “it works on my laptop” problem. The idea was that developer builds docker image and pushes it to repository where it can pass through CI and eventually the same image gets to production.

As you can see, this effectively reproduces the EXACT content as well, because you transfer the files in a set of tar files.

It didn’t work for many reasons. One of which is the fact that it’s often not so much about the exact files, but the rest of the environment like DBs, proxies, networking, etc that is the problem. I’ve seen image misbehaving in production due to different kernel version/configuration.

Replace “nix flakes” with “Docker” and you have your answer from almost decade ago.