> As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id.
> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.
I think macOS makes some trade-offs to give a supposedely better user experience as long you're part of the 80%. If you're not though, yes it is painful.
For me the macOS Display management experience is absolute dreadful. I had the same issues as the author's and I even had to pay actual money for a third party application (BetterDisplay) to fix some of the issues.
The most infurienting one for me is that I can't disable the internal MacBook display when I am connected to an external monitor without closing the lid. Why you may ask? Because I want to keep using the TouchID. However this is impossible in macOS without an external app.
I think this has no virtualisation instructions right? Since AFAIK, those are restricted to the Mx series.
Of course the 8GB of RAM is also limiting for running any kind of VM, but this notebooks are almost exactly what I was looking for, except for the 8GB of memory.
The target user doesn't read hacker news. The target user is typing up papers for their history class. This absolutely kills the lower end of the market. I do not know why anyone who needs Safari and MS Office would buy anything else.
I think they very intentionally assume folks are not running VMs or doing much more than "every day" tasks. Given the pre-packaged E-Waste sold at most retailers for a similar price (or more) I think this is a really fantastic market move by Apple. This is doubly true as I read weirder and weirder things that Microsoft is doing with respect to Windows 12 and, well, in general.
<I think this is a really fantastic market move by Apple. ...as I read weirder and weirder things that Microsoft is doing with respect to Windows 12>
I think this may well be what Apple is thinking! I've only ever purchased an Apple laptop, that was refurbished, because of the, what I consider, too high pricing for their lineup of really nice laptops. (I'm not bad mouthing Apple, I'm just cheap.) IMO, if Win 12 is as bad as what some are thinking, a lot of people will switch to Apple who may be afraid of Linux. (I'm referring to folks like me who normally use a computer for the normal stuff and some semi-lite gaming.)
The Neo pricing is usually my ceiling price for a Windows laptop, so I'll be watching the reviews and HN to see I if want to purchase one. Very exciting!
To be clear, I am not complaining. I am well aware that the target demographic is students and casual users. It is just an observation.
However, the price argument doesn't make sense. I bought a EUR300 laptop for my wife 3 years ago that has a Intel Core i3 N305 CPU (https://www.intel.com/content/www/us/en/products/sku/231805/...), and that CPU, like any modern CPU from Intel, has virtualization instructions.
Heck, my Chromebook Duet with a Snapdragon 7c Gen 2, that compared to this A18 Pro chip is laughable underpowered, also has virtualization instructions (this is why Crostini, the Linux virtual environment for ChromeOS, works).
> /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.
Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
Yes of course it can break. The point is that the stuff needs to be in initramfs. "includes everything" has an implicit "when working".
What seems bad about it to you? Initrd means you only need /boot (or equivalent) to be working at boot time, which seems nice to me. And looking at mine, the image is smaller than the kernel, so it's not wasting a ton of space.
More than once I've run into weird issues with missing filesystem drivers and other important things that caused me major grief during an emergency.
Sure it could be blamed on shitty distro maintenance and development but a better architecture would be putting essential things like filesystem drivers in /boot without this extra kludge of rebuilding an initrd (that you hopefully didn't forget to do before typing reboot) which depends on a pile of config files set just right (and oh by the way different in literally every distro).
A folder in boot could still be missing drivers, though.
Rebuilding an image isn't a big factor there, it's a tradeoff between making setup a bit more annoying versus making it a bit easier to manage your boot files.
> initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.
Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.
Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.
If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.
The issue I have with `nix-shell` is that the evaluation time is long, so if you need to run the script repeatedly it may take a long time. `nix shell` at least fix this issue by caching evaluations, but I think uv is still faster.
Years of experience working in Enterprise and complex systems.
And that is all on point with the criticism: while an AI can design a new language based in an existing language like Clojure, we need actual experienced people to design new interesting languages that add new constraints and make Software Engineering as a whole better. And we are also killing with AI the possibility of new people getting up to speed and becoming a future Rich Hickey.
> And we are also killing with AI the possibility of new people getting up to speed and becoming a future Rich Hickey.
Not sure I am on board with this part... I find LLMs in particular to be great teachers specifically for getting up to speed to becoming future Rich Hickey.
it is indeed a great teacher but there are times where it hallucinates and sticks to the hallucinated content even after several iteration unless human in the loop breaks it. i've wasted hours believing what LLM hallucinated.
my learnings are a lot of microdoses of things that I usually don't work on in a day to day so i don't want to spend time reading about it but yes this sort of learning would be otherwise impossible so gotta thank LLM for that.
I am working (mostly vibecoded) a Git history explorer in Go+modernc.org/Tk9.0: https://github.com/thiagokokada/gitk-go. It is heavily inspired in gitk, this is why the name and usage of Tk for the interface.
The reason for it was because after testing multiple Git history explorers, I still think nothing beats the gitk. Sublime Merge is probably the only alternative that I would seriously consider but I don't really like the UI and the fact that it is proprietary (I am not against proprietary software but I prefer an opensource solution when available). Other alternatives have some bugs or the interface few too slow. gitk itself is mostly fine, but sadly it tries to load the whole repository in memory and this is causing issues every time I try to navigate through nixpkgs (I can see the memory consumption going through the roof while the UI slow down to a crawl).
gitk-go loads a batch of commits (1000 by default) and once you get at the end of the list it loads more. I also add a few features that I miss from gitk, for example if you do any change in the repository (change branches, add files to stash, etc) it will automatically reflect in the UI.
Again, the code is mostly vibecoded since this is the first time I decided to try this from scratch. The code works well for my use cases and it is enough to replace gitk for me, but I can't guarantee there is no bugs and the amount of tests are small. But still, it was fun to see something that I wanted to create for a while (I had this idea for a long time since the issues with gitk that I was having) finally taking form. Probably the program is not useful for anyone but me, but if anything this is a feature, not a bug.
