finaard

Same here, I was very confused for a bit.

I'm currently polishing one of my packages for publication, and for that do a lot of testing in a vanilla Emacs. It's shocking how many of even (to me) absolute core functionality is actually customization I did a decade or two ago, and then forgot about.

And the yet again I got told over and over again that Bambu didn't really mean to, and if they did they learned their lesson, and after all you can still keep them offline. And spending more for a prusa obviously is silly.

I'm really getting too old dealing with morons who didn't learn anything after the same patterns repeating for decades now.

I assumed he just had DNS at AWS, but after re-reading I guess he has DNS _and_ domain registrations at AWS, which would be a special kind of stupid. That's something we were advising customers against already back when cloud wasn't a thing yet to enable fast transfers when stuff goes south

(to clarify: DNS+domain at the same service can be OK, as long as you have nothing else there. As soon as you start having other stuff, keep the DNS there, but move the domain registration away. Depending on which domain make sure you have auth keys, access to the admin domain or whatever would enable moving the domain without registrar cooperation. In my hosting days I did my fair share of emergency transfers and infrastructure to help companies get their basics online again after a SNAFU - totally doable to have first mail coming in again within a working day)

I'm not running a spam business. I've been operating my own mailservers (and related infrastructure) for more than 25 years now, without issues.

I've been in a similar situation - a surprising amount of companies really just click to create instances. Last time I've encountered that at a customer I improved things a bit by creating templates, and scripting instance creation based on those templates - but ideally we'd have had the templates themselves as well as the network side generated by ansible.

But that's the problem: The complexity of doing that properly is pretty much the same as just doing your own hardware (which is what I'm working with most of the time - handling stuff on physical servers). And at that point the question should be why you're paying AWS so much money and pay your people to automate AWS workflows when you could just pay them to automate workflows on physical hardware, which would be way cheaper to run than the AWS instances.

My business email system still does not work.

This is always the weird things in those rants. He's complaining that after 4 days his mails are offline.

Now I'm doing a mix of physical servers in rented rackspace, and rented servers - but even there I can have billing mixups where they deactivate servers for no good reason. And to get email working again the limiting factor would be the DNS TTL - new servers would be online somewhere else within hours of it going down. (And yes, I tested that just last year - one hoster threatened cutoff due to non-payment on a paid invoice, which prompted me to move the mail server just in case while getting this resolved).

I've found a lot of issues come through somewhat naive networking setup - which is encouraged by the "just yolo it" installation instruction in the documentation. If you want to start understanding what's going on you'll end up in very weird corners very quickly. Also, if you don't want the API endpoints available to the world the documentation is not much help.

I've found things more stable if you can give a dedicated interface just for internal k3s communication. It can be a bridge interface on top of a vlan interface - but not the vlan interface itself, or some things will break in very interesting ways. Also, even when using IPv6, just stick with internal IPs and nat everything - touching internal IP ranges is no fun. Plus, if there's a chance you'd ever want to use dual stack, set it up with internal v6 addresses, and just don't use the v6 addresses for now. There's also a lot of unintuitive behaviour around dual stack networking - and lots of areas where documentation is just plain wrong.

I'm scripting our stuff with ansible - one of the more useful things was the realisation that in some areas changes which shouldn't break anything can lead to cluster communication being interrupted, which is a very interesting thing to deal with, especially when you can't pin it to that change that didn't touch anything close to that, and therefore should not be responsible. I've learned, and sprinkled checks to make sure all members can still reach each other in there now, so that at least when I break it on changes I directly know why.

The last time (that I remember) people wanted to talk in a game, but could not teamspeak showed up.

Back in the early 90s I've discovered that there's not really any backchannel happening when printing to a dot matrix printer over the parallel port. And adding multiple ISA parallel port cards set to same IO address wouldn't cause any hardware issues, but just spit out the same data on all cards.

Which meant, as long as no paper was jamming, I could send data all three printers I had access to at the time could understand, and would save 1/3rd of printing time by having everything spit out in parallel.

My mother (parents bedroom adjacent to mine) did not think that'd qualify as ASMR at 2 in the morning.

I didn't read much of the page - just was scrolling a bit to see what the fuck that thing is doing, and that was more than enough to know that I'll never touch whatever those people are doing.

On the one hand, moving from assembly language to C made programmers less effective in some ways and more effective in others. On the other hand, the transition from writing code by hand to using AI is arguably a bigger shift,

I think that's a bad comparison, mainly for two reasons:

We still have people dealing with assembly for building the compilers. We don't quite have that for AI - which became very clear with the claude code leak: We just have people trying to get the correct behaviour, but without understanding why.

The second reason has more practical implications: I generally rely on my compiler to be deterministic, and not introduce security issues (which they sometimes do, by optimising away safeguards placed by the programmer - but that is relatively rare, and we can trace and fix that). But generally as a developer I can rely on my compiler to produce machine or byte code I don't have to think about.

The same is not true for AI - the regularly produce insecure code. This can partially be mitigated by having another AI review it - but it's not a proper solution. Until we get proper AI which can actually understand things we need somebody in the loop who can understand the code.

I'd recommend for every developer to get one or more colourblind friends. I have some, and regularly send them screenshots of what I'm working on to get feedback what they can see and what they can read/can't read.

They've been absolutely invaluable for making sure their kind of people can't use my apps properly.

For a lot of tasks smaller models work fine, though. Nowadays the problem is less model quality/speed, but more that it's a bit annoying to mix it in one workflow, with easy switching.

I'm currently making an effort to switch to local for stuff that can be local - initially stand alone tasks, longer term a nice harness for mixing. One example would be OCR/image description - I have hooks from dired to throw an image to local translategemma 27b which extracts the text, translates it to english, as necessary, adds a picture description, and - if it feels like - extra context. Works perfectly fine on my macbook.

Another example would be generating documentation - local qwen3 coder with a 256k context window does a great job at going through a codebase to check what is and isn't documented, and prepare a draft. I still replace pretty much all of the text - but it's good at collecting the technical details.

Even if everyone eats a perfect portion for themselves, if you overestimate the total then you'll have food waste if the food can't be preserved.

That'd be just poor planning on part of the hotel/restaurant. It'd be a valid excuse when starting new, but after a few weeks that should be under control.

If you only do breakfast buffets it's a bit harder - but you monitor the situation, and as breakfast time approaches the end you reduce things you can't store or re-use otherwise. Pretty much any hotel I've been to in the last few years had that kind of items run out without restocking them when we had a late breakfast.

If you also do lunch/dinner buffets you have some more options, and can have some dishes reusing the leftovers. I've also seen that regularly - they had the planned dishes, and a few smaller pots with something they came up with to reuse whatever was left over.

How is that surprising? We've been taking that into account for any LLM related tooling for over a year now that we either can drop it, or have it designed in a way that we can switch to a selfhosted model when throwing money at hardware would pay for itself quickly.

It's just another instance of cloud dependency, and people should've learned something from that over the last two decades.

Or, maybe, don’t: when people do, they take much more than they eat. Compared with ordering from the menu, all-you-can-eat breakfasts waste more food—up to twice as much, according to one study.

Is that a cultural thing? We have pretty much zero food waste on any buffet as you can easily only take what you actually want to eat. It's just basic good education to be considerate with resources, especially food resources - and I rarely see people taking more than they actually eat, so it's not just an "our family" thing. If you do throw away a lot of foot on a buffet you're just an inconsiderate asshole - and if a restaurant location has significant food waste from that they should just start charging for leftovers.

Yubikey (and nitrokey and other HSMs) are technically smart cards, which perform crypto operations on the card. This can be an issue when doing lots of operations, as the interface is quite slow.

Anything pkcs#11 you can proxy. I'm using that on some systems - I have an old notebook with a nitrokey hsm at home. It binds pkcs11-proxy to a local wireguard interface, so I'm registering systems I want to be able to use those keys to that notebooks wireguard. They still need a pin for unlocking a session as well.

As a German, after encountering Russian bureaucracy once, I commented to my wife that the main difference between Russian and German bureaucracy is that in Russia at least you can pay your way out.

Unless I care about the meeting it gives me an easy way out. More than 5 minutes late in that case is "let's try it again another time"

I have fond memories of lending a Voodoo 2 from a friend when I was moving from a 486 to a K6 based system component by component. At that time I was still using my old ISA VGA card, which meant 2D performance was horrible, and I couldn't really watch videos on that thing - but thanks to the Voodoo I could play Unreal Tournament without problems.

It's quite entertaining to read - most of the article is pretty much elaborating a chain of bad decisions by the author which all lead to this now being a big problem. If he'd have written a similar dependency tree earlier and just thought about it for a few minutes that should've been avoidable.

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.

The archived copy of his old website has a picture from the beach: https://web.archive.org/web/20000511210957/http://ghg.ecn.pu...

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

His obituary or wikipedia page are well worth a read for what he was involved in - though he probably is best known for lighting a BBQ in under 5 seconds by use of liquid oxygen, and getting into trouble with the local firedepartment for that.

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.

The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.

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.

No, updates are done by creating a snapshot of the read only mounted root, and applying the packages via the usual package manager in there. The snapshot only becomes active at reboot, and if starting fails it'll revert automatically back to the last known working snapshot for the next boot.

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.

Yeah, I've noticed at several customers that they're just trying to cram LLMs into everything, instead of maybe first thinking if it's sensible for that specific usecase.

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.

This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me.

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.

The slowness on startup in my emacs mainly comes from my customizations - over the last almost 3 decades I've accumulated roughly 30k loc of custom lisp, plus a lot of 3rd party stuff.

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.