> Update 1 - I know I can simply change the MX record to someone else but It has its own challenges.

I don't quite get that attitude. He's describing that he needs his business emails. Not just getting a mail server back online for that, even as interim solution, points to the opposite. In the time it takes for MX TTL to expire he could easily just throw up a postfix+dovecot on some VPS, with enough time to spare to add something like sogo if he feels fancy.

That's the page mostly dedicated to BBQ lighting: https://web.archive.org/web/20000511170940/http://ghg.ecn.pu...

He used to have that video on his website - which I've discovered via a Usenet discussion not too long after it happened. It was one of the first videos I've downloaded via a web browser, and almost certainly the first video made with a digital camera I've ever seen.

Comments URL: https://news.ycombinator.com/item?id=47618176

Points: 175

# Comments: 40

You can limit the access of distrobox, but it's a bit annoying, as they didn't think about isolation when designing it. Personally I'm not doing much with distrobox - I've been using LXC for ages to run some applications (like browsers) somewhat isolated, with only specific directories shared between home and the container.

Few years ago I started switching some of them to podman as that makes it easier to pre-build and share containers between systems, with a custom wrapper script to mount in resources as needed (directories, wayland socket, pulse/pipewiresocket, ...) - with my approach the opposite of distrobox: allow nothing per default, and specify resources that should be available.

So when I switched to immutable systems I had everything ready already to not have to rely on either system packages or flatpack and distrobox too much.

Overall I'm very please with the progress there - suse microos is pretty much everything we were hoping to achieve with our phone OS back at Jolla 15 years ago, but for most of the things were just not ready. We did use btrfs with snapshots to allow roll back for updates, though we didn't do a full read only root - and ran into issues with btrfs just not being stable enough at that point.

Things like /etc are writeable, so you don't need to reboot for simple configuration changes.

You can run it just like always with all packages installed - it's just not recommended as the additional complexity on updates increases the risk that manual intervention is needed, and tooling is good enough that for a lot of stuff you don't really need it there. Like, toolbox or distrobox as podman based containers running in the host namespace (either as user or root), allowing persistent installation of debug tools, without having to reboot.

I'm also doing some things where I don't think LLMs are not a good fit - but I'm doing it because I care to see about things like failure behaviour, how to identify when it is looping (which can be sometimes hard to see when using huge context models) and similar stuff - which results in more knowledge about when it makes sense to use LLMS. No such learnings visible at many customers, even if LLMs do something stupid.

Quite a few of the projects I always wanted to do have components or dependencies I really don't want to do. And as a result, I never did them, unless they eventually became viable to do in a commercial setting where I then had some junior developer to make the annoying stuff go away.

Now with LLMs I have my own junior developer to handle the annoying stuff - and as a result, a lot of my fun stuff I was thinking about in the last 3 decades finally got done.

One example from just last week - I had a large C codebase from the 90s I always wanted to reuse, but modern compilers have a different idea of how C should look like. It's pretty obvious from the compiler errors what you need to do each case, but I wasn't really in the mood for manually going through hundreds of source files. So I just stuck a locally running qwen coder in yolo mode into a container, forgot about it for a week, and came back to a compiling code base. Diff is quick to review, only had a handful of cases where it needed manual intervention.

But I typically start emacs at boot, and then it runs until I reboot. I usually have one GUI frame, and one tui frame running in tmux so I can easily attach to my emacs session from a different computer. I have an emacsclient wrapper that opens stuff from the command line in my running emacs (and also mail wrappers, so clicking on a mail link in a browser opens a mail compositor in emacs).

I'm using eyebrowse with a bunch of own convenience features for workspaces in emacs - stuff like "when I switch to a buffer it'll switch to the workspace wher e that buffer is open unless I tell it I want it here". Combine that with some custom SSH entry points and especially on the notebook where I only have one screen it's way more comfortable to use than the OS window management for a terminal/ssh session messy like me.

I even have exactly the same discussion after it messed up, like "My code is working, ignore that failing test, that was always broking, and I definitey didn't break it just now".

15 years ago I was working in an environment where they had lots of Indians as cheap labour - and the same thing will show up in any environment where you go for hiring a mass of cheap people while looking more at the cost than at qualifications: You pretty much need to trick them into reading stuff that are relevant.

I remember one case where one had a problem they couldn't solve, and couldn't give me enough info to help remotely. In the end I was sitting next to them, and made them read anything showing up on the screen out loud. Took a few tries where they were just closing dialog boxes without reading it, but eventually we had that under control enough that they were able to read the error messages to me, and then went "Oh, so _that's_ the problem?!"

Overall interacting with a LLM feels a lot like interacting with one of them back then, even down to the same excuses ("I didn't break anything in that commit, that test case was never passing") - and my expectation for what I can get out of it is pretty much the same as back then, and approach to interacting with it is pretty similar. It's pretty much an even cheaper unskilled developer, you just need to treat it as such. And you don't pair it up with other unskilled developers.

They don't really like you using that and keep annoying you to stop doing that, but I don't think they'll fully get rid of that - those are filling some accessibility niches as well.

I stopped using banking apps on my phones a few years ago - they got more and more annoying, and I don't buy into the "the device is secure and should be used as a trust token". So I'm now back to banking only on my computer, with a hardware token for TAN generation.

A surprising amount of embedded SoCs target the Arduino IDE either as the main IDE, or one of the main ones. And for those the setup is still pretty easy for non technical users - "Download IDE, paste this into the boardmanager, compile the sketch, upload". That's the main reason I'm still using the Arduino IDE for stuff I publish and expect less technical people to use.

The problem with the IDE is that it doesn't offer a gradual path to more advanced usage. You're pretty much stuck with a single file main project. You can split off functionality into libraries, but the way library resolving works is way worse compared to "proper" build systems. There are projects to provide makefiles for Arduino projects, but it's a bit of a pain to set up - I use that for CI on some of my stuff, but it clearly is on the other end of difficulty scale.

And of course the editor is horrible - but thanks to file watching and automatic reloads that isn't much of an issue nowadasy.

I intentionally made a few interesting choices for my stuff, just to see how far you can push it, and to make sure no sane person would ever use that in production (like, from before Markdown was around, I was wondering how far you can get with doing a simple markup language parsed by using regexp only. Turns out, surprisingly far, but if something doesn't parse as expected later on you have a bit of a problem)