I mean no disrespect. This is more of a rant at how things are today. It is telling that over-complicated solutions have become so common that, for the current generation of devs, Kubernetes is the obvious way of doing stuff and a simple systemd service is the obscure one. I am sure there are good reasons for this, but it still feels like a loss when simplicity is no longer obvious.
I wasn't an early adopter of Copilot, but now the VSCode plugin can use Claude models in Agent mode. I've had success with this.
I don't "vibecode" though, if I don't understand what it's doing I don't use it. And of course, like all LLMs, sometimes it goes on a useless tangent and must be reigned in.
No, Rust is in the kernel for driver subsystems. Core linux parts can't be written in Rust yet for the problem you mention. But new drivers *can* be written in Rust
As an init manager, systemd is the best thing that has happened to the wider linux ecosystem. Being able to indicate dependencies, document order and being able to let an application tell the init manager it is done and dependents of it can be started makes starting up way better.
I understand the downsides people have of systemd, but I have the feeling the huge upside is often overlooked.
I've worked with init.d style init systems that had those features using special comments and sourced helper functions, but I bet if you wanted to do it all properly you'd end up with something like systemd. Or GNU Shepherd!
It is more than merely an "init manager". And I disagree that it is the best thing ever - it is perfectly possible to operate linux without systemd.
> but I have the feeling the huge upside is often overlooked.
It is fine to objectively compare trade-offs. However had, it has to be a fair comparison; we can not start with "init manager" because systemd does a lot more, so how can a comparison to any software with less code be fair then? runit doesn't do much more than for initializing.
That sounds like what Drew DeVault does (did?). He made sway, aerc, and others but largely doesn't work on them now AFAIK, passing off work to other people such as emersion.
The language and the compiler infrastructure is for me the biggest problem. It's very hard to understand what is going wrong when it goes wrong. Most advice feel like copy pasting existing code without knowing what it does.
Learning this also complicates things as I am feeling overwhelmed with all the things needed for simple configuration structures instead of starting out with a simple program.
Kobo Sync as it's called in the documentation (https://github.com/janeczku/calibre-web/wiki/Kobo-Integratio...) works very well, and is very easily enabled (updating a single line in a config file on the ereader that appears when you mount it on your computer).
It will convert books to Kepub automatically and you can select to only sync certain shelfs.
There is no difference to a .Add() function, that's true but even for strings you wouldn't have an Add function. It would be an Append() most likely which explains much more what is happening.
And verbosity helps, forcing users verbosity helps the general level of quality. Programmers could overestimate themselves and think they are doing it correctly. Looking back in my code from a year ago I see things I should have done differently. I like languages that avoid me making real dumb mistakes
