finaard

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.

I've wrote this a few times, but LLM interactions often remind me of my days at Nokia - a lot of the interactions are exactly like what I remember with some of their cheap subcons there.

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".

That's not really a new thing now, it just shows differently.

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.

LLMs can be quite useful in reverse engineering - there's typically a lot of steps which are not really difficult, but are hard to script, and still require a bit of an idea what's going on. Quite a bit of that can be automated with LLMs now - so it's also a lot easier now to figure what your proprietary blob does, and either interface with it, or just publish an implementation of the functionality as open source, potentially messing with your business plan.

The last time I (EU) touched a check was in 2006 - my elderly landlord used that to refund overpaid utilities. I had to google what to do with that thing - the bank I was with wasn't handling checks at all, so I had to go to a branch of a different bank. And even there they first had to look up what to do with that thing.

I'm in Europe, and some of my banks still operate with a token just showing numbers, while others use devices with QR code readers and a colour display which then can show transaction details.

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 guess you can still do banking on your PC?

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.

> People also do not like the arduino ide because the days of easy setup and run are gone and a real way of debug is needed in most projects.

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 think it's good practise to build something CMS like for fun - as long as you don't expect it to be useful or used, outside of maybe your personal page. It's useful to experiment and learn stuff that might be useful at scale in other projects.

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)

Almost none of the FPS shooters try to to something creative, though. Duke Nukem 3D is still unbeaten for fun in multiplayer (and we still get it out now and then for that) with simple gimmicks like the holo duke, pipe bombs and laser mines.

Even just looking at "game uses 3D engine" we don't really have many great things. There's portal, and while some of the other stuff have promising ideas (like infinifactory), for all of them the controls tend to get in the way of fun.

For ease of use and fun pretty much all simulations - even as far back as the 90s - just using isometric projection are still unbeaten by attempts to go full 3D.

gnus had some massive IMAP performance improvements a few years (probably close to a decade now) ago. Before that it was quite painful to use it on large mailboxes without a local imap - I used to sync that with offlineimap. When they had a massive issue moving from python2 to python3, and keeping that running on a modern distro started getting painful I tried it without local imap - and realised those improvements made things fast enough that you can run it on remote mailboxes, and even do so in your main emacs instance.

Also check out the pull requests on that repo if there's something useful - in my case I've been using eat as single terminal instance for a while now - but for replacing stand alone terminals just opening multiple instances via multi-sh or similar isn't really helping for finding the terminals again. My solution was patching eat to allow buffer renames to the terminal title, and for ssh sessions, initially set the terminal title to the host I'm connecting to. Now I can easily find the terminals when switching buffers.

On top of that I'm using eyebrowse to have multiple workspaces, and some hooks around buffer switching that switch to the workspace a buffer is on instead modifying the current workspace.

> But, I thought Arduino had become officially evil once it joined Qualcomm.

They have - but for less technical users their IDE is not too bad, and there are way too many bits out there relying on it, including lots of stuff not arduino, plus it's open source. And as it reloads files on changes can be used with a real editor as well. So for the software side I'm inclined to stick with that thing.

For hardware side it's different - but every interesting arduino has shitloads of clones available. In the past I've been buying those only for special use cases where there were no genuine arduinos to support the project - now since they got crazy it's only clones, and whenever I touch any of my old projects I'm updating the list of materials to recommend buying clones. You can still get nano clones for just a bit over 1 EUR each, so for projects where that is enough that's hard to beat value for the money.

Nowadays there's eat as excellent terminal emulator for emacs, which should replace the need to run external terminals.

I've been using it for a w while, and recently finally got fed up about terminals on my macbook not behaving as nicely as the ones on my linux box with proper tiling window managers, so spent some effort to make SSH into a terminal with completion easy from emacs, and now mostly handle terminals in emacs.

As a EU citizen: My only complaint is that the fines are not large enough, and enforcement often takes too long.

> Python was so much easier as it was simple define the regex and then use a function on it. I suppose I should hjave spent a few days to write some wrapper in perl - doing those few days would have saved me time overall.

That's funny. I avoid python whenever possible, but one of the things I hate the most is how it is doing regex. I find the way it works in perl (both for search/replace and in conditionals) just intuitive.