For me, some projects I start by writing a readme.txt by hand. That saves me time in cases I realize I'd be making something pointless. (I don't use chatbots when coding though)
I shall now drive my fart car back to my cozy meatcave from the public meatspace so that I can do some good old ape coding with my smelly carbon-based friends in peace.
Who isn't collecting biometric data using shady sites nowadays? Even Hetzner wanted to match my id with a selfie using some really shady site that almost certainly violates gdpr… What's next, will I have to send a stool sample to view posts on Twitter?? Funny how that's not even unlikely nowadays, with slippery slope becoming less of a fallacy and more of a universal law…
ejabberd is so much easier to set up than prosody, especially containerized. I would highly recommend checking multiple servers out before settling on one tbh.
Oh I can't get enough those blog posts written in such confident language that it's easy to filter them out instead of having to realize midway reading how wrong every bold claim they put forward is… :þ
I don't really use Windows OS much, but why not just use MinGW? Then you have Clang on all platforms you can think of: Android, all the various Darwin flavors and of course Linux and Windows; as well as on platforms you can't think of like FreeBSD or even Haiku maybe? Like honestly what's the point of supporting MSVC at all?? Maybe I'm just not enough of a Windows nerd to understand? (so I'm basically wondering if mingw has any drawbacks)
If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.
Ah, binary-only dependencies, right… That's very specific though, so unless you need to drive some proprietary hardware, why bother using stuff that forces you into MSVC hell lol? Also wouldn't LLVM based MinGW benefit from Clang's MSVC compat? Not sure about this at all, that's why I'm asking, heh… ^^"
Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.
The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.
And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.
systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.
No, one complaint (out of many) against SystemD is that it moves too much complexity into PID 0 which is a very special process on Linux that must not crash ever or the whole system goes down with it. The init system is one thing that SystemD insists on running under PID 0 even though it could be designed otherwise.
But PID 0 on Linux is the idle task…? Init is (usually) PID 1, PID 0 kinda just means that nothing is running on a given CPU (with caveats), also killing 0 has special meaning because well it's not a real process…
Varlink is everything that the usual systemd detractors should want; no binary formats, simpler mechanisms, based on stdout/stdin of processes.
Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.
Funny how you chose `ioctl` specifically to illustrate your point, when that's quite uniquely just a syscall inside a syscall… Ideally, high level library devs should abstract ioctl while treating libc as the stable userland kernel ABI, as has always been the case for the BSD's.
I think the real problem is GNU libc devs' unwillingness to stabilize it (not sure why, perhaps the menace of HURD still haunting them?)
I chose "ioctl" precisely because it has maximum simplicity, in order to show that in "nolibc" it needs externally provided syscall numbers.
Some other syscall wrappers from "nolibc" may be somewhat more complex, by doing some processing on the arguments, before invoking a generic syscall wrapper like "my_syscall3", "my_syscall5" etc. (where the number from the name of the generic syscall wrapper refers to the number of syscall arguments).
Ioctls are the single most complex example for API design, cause like, that's another opaque interface inside one opaque interface. Ioctls will be routed to the desired kernel module (driver) depending on the FD, after all.
Basically all I'm saying is that a syscall "ABI" is but a red herring for everyone but the [mainline] Linux devs themselves.
GenAI is only useful to bump terrible up to mediocre, so it'd be really stupid to spend time honing one's prompting skills. And as you noticed, so far 96% of the population agrees.
It’s really not going to bump up terribles to mediocres. It’s only going to mask the terribles and make it harder to assess intelligence and talent. Underlying human intelligence is not going to get a boost from AI. Intelligence is mostly innate. I would even argue that AI will make average humans marginally dumber for the most part.
Yeah, also, isn't it already proven that offloading thinking onto chat bots causes some kind of irreversible brain damage/dementia? (also BTW "mediocre" is still not "acceptable" despite Slophauses trying to convince people otherwise)
reply