Notices by Ignas Kiela (ignaloidas@not.acu.lt)

@sun@shitposter.world just send them faxes continuously until they ask you to stop

@piggo@piggo.space @pony@blovice.bahnhof.cz bro, per area you're second highest besides Switzerland if you don't count microstates

@lanodan@queer.hacktivis.me @piggo@piggo.space idk, seems like recently here cans started to ommit the hole

@lanodan@queer.hacktivis.me @kura@hai.z0ne.social @piggo@piggo.space as I remeber an arch maintainer saying: "nobody uses arch because of AUR"

@sun@shitposter.world it's legit the "throw the passanger compartment away on a parachute meme lol

https://youtu.be/wC6tCQC8rbE

@sun@shitposter.world wasm would be a better shout, riscv seems dumb for such purpose

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place and the long term maintenence cost is higher than in other languages because of poor package managers. If long-term maintenece cost of added libraries in Node.js were as high as in C, regular projects wouldn't have hundreds of dependencies.

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place now try something that isn't a popular library that all package repos have 😉

And like, anecdotally, rougly 1 out of 3 C projects have their own linked list implementations. Sure, you can pull it in from a library, but it seems like few people do and would rather re-implement it themselves.

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place look, I'd rather have security issues all in a few, frequently used pieces of code, rather that sprinkled and copy-pasted around the entire ecosystem of re-written code. One is at least simple to definitively fix, while for the other, you fix the same damn problem in 20 different projects over several years.

Also, "code reuse in C projects is usually fine" is laughable. How many separate linked list implementations have you seen in C. Do they all need to be separate? Is re-writing yet another linked list implementation a good use of time? And this is just a single data structure. There's tons of similar stuff that's re-written time and time again because the barrier of entry for adding a library is massive, and the standard library is laughably small. C the language is not very amenable to code reuse, but add the pain in the ass that is adding some libraries to do said code reuse and you get a language where code reuse is almost the option of last resort.

Like, in Python, pulling in a library to save ~10h of work is "the right thing to do". In C, the breakpoint is somewhere over a 100h in my opinion because of how annoying it is to maintain the whole pulling in stuff.

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place Distro package managers fail for other languages because they are only built for C

It's fucking miserable to reuse code in C - you either vendor it (which is shit), or hope to hell that the code you want to reuse is common/simple enough to be included in most distros, or otherwise your program will be a massive pain for end users to install.

There are a good bunch of C libraries that are better packaged as a part of Python libraries than by themselves in distros.

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place The system's putpose is what it does. Distro package managers do OK with C and are quite shit with anything else. You can of course try managing non-C things with it, but just like trying to manage non-Python things with Conda, it isn't a good experience.

This fracturing of dependency management has lead to way lower code reuse in C programs compared to other programming languages and is essentially only left for stuff that is "too big to not reuse". I don't think this is good.

@amonakov@mastodon.gamedev.place @wolf480pl@mstdn.io I mean, sockets are in libc, aren't they?

and TLS is the kind of thing that ends up mostly getting replicated because of how much work it takes - but even then, there are multiple TLS libraries these days, with a couple different interfaces, some more compatible between them than others.

@uecker@mastodon.social @wolf480pl@mstdn.io @amonakov@mastodon.gamedev.place look, the whole mess of 15+ completely different distros each with entirely different package management system is entirely because C is shit at managing dependencies. Every single larger unix package manager is built for managing C dependencies, and they are all different kinds of shit. I'd rather get one singular package manager for a language, even if it's not great, rather than 15 different ones, when all of them are shit.

@amonakov@mastodon.gamedev.place @wolf480pl@mstdn.io With how shit C is at managing dependencies, this route would be bound to end up with 15 different socket libraries in wide use

I see zero reason to duplicate wrapper code over a million different programs besides stdlib maintainers trying to discard responsibility for stuff where a single canonical source helps the entire ecosystem.

@sandmouth@types.pl @whitequark@mastodon.social it's not that SMTLIB doesn't solve problems, but it's that it doesn't really give a good interface for many of them. A lot of the time you don't truly need the whole SMT thing to achieve good results. There are certainly things where there is enough overlap between different types of problems where SMT starts to really make sense, but without that, I think it's way better to go and use the more specialized tools, because for many, the interface is simpler and way more thought out and the performance is better.

@toast@donotsta.re heh

I read a bit on HN on this (I know, a mistake) and it's so funny how so many angry skill-issued sysadmins were on there bitching about this

@whitequark@mastodon.social maybe now you better understand why I think using pure SAT is better for prjunnamed 😉

@wolf480pl@mstdn.io @lanodan@queer.hacktivis.me @domi@donotsta.re @rozenglass@fedi.dreamscape.link apache works quite well as a project for an example of companies collaborating for common goal

if the concern is FSF style freedom, then I don't truly care? It's not like silicon vendors haven't done a whole metric ton of bullshit to prevent you building custom firmware anyways - and IMO the tide is slowly, but surely turning on the silicon vendors, and more and more openness is coming out of them.

@wolf480pl@mstdn.io @lanodan@queer.hacktivis.me @domi@donotsta.re @rozenglass@fedi.dreamscape.link shrug - imo there is space other than linux, and it's fine for other stuff to be used

and I'm honestly not sure that linux has a lot of longevity either, I don't think the maintainership culture is healthy and I doubt it would really handle a bunch of new people upstreaming stuff in the way those people need it to.

in my mind Linux is something that I'm kinda looking to jump ship from long-term, not because it's bad, but because I don't think it has a long future. There's not yet something I could jump onto, but if I feel like that changes, I'll likely switch fairly quickly

@lanodan@queer.hacktivis.me @wolf480pl@mstdn.io @domi@donotsta.re @rozenglass@fedi.dreamscape.link all these kernel CVEs combined with incoming EU product security stuff might end up being the push that most embedded products need to either mainline their drivers, or to move away from Linux