Programming thread

Rust "alleviates the cognitive burden" of managing allocation lifetimes the way that wearing a diaper "alleviates the cognitive burden" of going to the bathroom to take a shit.
Gronk like not to think about memory of living sand but still want best result. Better?
However, the cleverness that you have to wrap in "unsafe" does help your performance, and things like intrusive doubly-linked lists are not, in fact, unsafe in any way
I see no problem with using unsafe blocks, especially for things like this that are verifiably safe, but only violate rust's ownership model. Whoever implemented std::collections::LinkedList agrees.
No offense, but the people I have met who shill the borrow checker the hardest are the ones who either have comparatively little experience with either C or C++ and aren't good at dealing with manual memory management. They get on their high horse about how easy it should be to get your code to compile (exactly as you did) if you are an experienced C programmer. However, if you are an experienced C programmer, you understand that the approach you are forced to use is not the best one.
I would have rather shilled all of the reasons I like rust for, but "the borrow checker" is what is relevant to the discussion, not the incredible expressiveness of the type system or the enums or the pattern matching or the monadic error handling or the cross platform standard library or the closures or slices. "The borrow checker" or the promise of memory safety is not the reason I keep using rust for, it just incidentally makes that promise alongside being a great programming language for general programming. I don't like shilling for muh borrow checker, in fact I hate shilling for muh borrow checker, but it is still fantastic and worth it when it saves your ass, but most importantly people on The Internet are wrong about it and must be corrected.
the borrow checker bans them and the community of Rust shills screams "they aren't that useful anyway"
They are not banned by "the borrow checker" and using unsafe blocks does not bypass "the borrow checker", all it really does is make undefined behavior legal, and in order to satisfy rust's borrowing rules to implement a proper doubly linked list, you must write some code that does some accessing of memory through a raw pointer which is classified as undefined behavior, but in reality the raw pointer is created from an existing non-nullable pointer anyways, so the use of unsafe is totally fine. The cult will scree and cry and shit themselves over this because muh safety (you did the heckin' unsaferino!) but really it's just an interesting note about the internals of a data structure that is used less and less these days thanks to performance gains from using contiguous arrays that fit into the cache lines of modern CPUs. Abstract data structures like graphs, trees and linked lists are a guaranteed cache miss, but we still need abstract data structures anyways, and most of them can be expressed easily within rust's type system and ownership model without the need for undefined behavior for no additional runtime performance cost.
 
I remember that I was going to criticize something I read from Steve Klabnik last year. The guy can't write worth a shit.

Here's a joke I haven't been able to use yet. APL is the only language that allows one to run a train on his data.

It's a nonstandard form of tacit programming that's pretty neat but, like most extensions, GNU APL doesn't support it and so I have no experience with it.
COBOL was also an extremely popular language, but it has aged very poorly because it has no dynamic memory allocation and the syntax was created when programming languages were not completely figured out yet.
when programming languages were not completely figured out yet.
:story:
 
Anybody fuck with kubernetes 1.31 and this CRI adherence shit?
Probably going to start with containerd as a runtime- docker engine needs a CRI adapter and that just sounds like more breakable trash.
 
TIL that Swift has automatic reference counting. I'm sold.
I don't get this widespread boner for reference counting. It's got to be the worst form of GC you can find: Shit throughput, shit latency, can't handle cycles. Its only advantage is that you can gradually introduce it in unmanaged code, but that doesn't matter when it's part of a managed language. Why do people love it so much?
 
Fundamentally, it's because there's nothing in the code that guarantees that there's no dangling cycle of objects. For most GCs, back pointers aren't a problem but linked lists that become a cycle sort of are a problem.
Maybe we're using different definitions of GC, but are you thinking more about reference counting?

I don't consider something a GC until it can fully handle proper cycles. Like the classical example of GC to me is a mark and sweep GC, and then anything that's feature-wise equivalent to that (but perhaps more efficient in some ways).

Even with doubly linked lists, if you have a dangling cycle, mark and sweep would have no problem detecting and freeing an abandoned cycle because the mark and sweep starts from the stack and traces everything reachable from there.
I don't get this widespread boner for reference counting. It's got to be the worst form of GC you can find: Shit throughput, shit latency, can't handle cycles. Its only advantage is that you can gradually introduce it in unmanaged code, but that doesn't matter when it's part of a managed language. Why do people love it so much?
Reference counting is valuable when a full GC is too expensive computationally.

I don't really think there are many situations like that in userspace software engineering nowadays. It's probably more useful in embedded software, where the project you're working on might still be pretty complicated algorithmically, but you're going to need to deploy without full desktop / server resources.
 
Anybody fuck with kubernetes 1.31 and this CRI adherence shit?
Probably going to start with containerd as a runtime- docker engine needs a CRI adapter and that just sounds like more breakable trash.
Do you mean their "runtime must confirm with the CRI" that they're doing with 1.32? I've not had any reason to care about it since they started deprecating docker in ~1.24 and I moved to containerd. Never had any issue with the change and rarely have to interact with it directly besides using crictl to see why an image might be messed up. Have a handful of applications that need to make a socket connection on the host and their values usually default to a docker socket but so far I've not come across any that don't let you use the containerd one. I'd guess CRI-O and Mirantis probably work but I don't know anyone who's ever used Mirantis, and CRI-O was being pushed by Red Hat in like ~2019 so I avoided it out of a desire to be distanced from them as much as possible.
 
  • Informative
Reactions: Sultan Bin Jewstar
Do you mean their "runtime must confirm with the CRI" that they're doing with 1.32? I've not had any reason to care about it since they started deprecating docker in ~1.24 and I moved to containerd. Never had any issue with the change and rarely have to interact with it directly besides using crictl to see why an image might be messed up. Have a handful of applications that need to make a socket connection on the host and their values usually default to a docker socket but so far I've not come across any that don't let you use the containerd one. I'd guess CRI-O and Mirantis probably work but I don't know anyone who's ever used Mirantis, and CRI-O was being pushed by Red Hat in like ~2019 so I avoided it out of a desire to be distanced from them as much as possible.
Yep. Docs say it's mandatory fun starting at 1.31.

Pretty much in the same boat for everything. Haven't heard of anyone touching mirantis and anything Red Hat wants is dogshit.
 
Yep. Docs say it's mandatory fun starting at 1.31.

Pretty much in the same boat for everything. Haven't heard of anyone touching mirantis and anything Red Hat wants is dogshit.
I think the clouds also shifted to containerd when they pulled that docker shim out in 1.23-1.24 and if you run something like rke2 or k0s they'll bundle containerd so it looks like Red Hat lost that one.

I at least wanted to like Podman since Docker (the company) is also extremely retarded and I'd rather only deal with one tard instead of two, but like most things Red Hat it works well enough until it doesn't and then it's a total disaster. Works mostly fine for standalone stuff and I guess the systemd integration is nice but if you're ever forced to try to use their totally 100% compatible trust me bro podman compose implementation you're in for a bad time. I'd sooner make a k3s/k0s/whatever host and cleanup what kompose generates than ever try to use that again.
 
if you run something like rke2 or k0s they'll bundle containerd
Yeah. It ships with docker engin if you're installing with apt-get or dnf. That's why I was scratching my head on docker engine + cri-dockerd adapter. I haven't dug in, but there would have to be a pretty compelling argument for me to waste more of my time to get rid of something that ships with docker so I can install an adapter.

like most things Red Hat it works well enough until it doesn't and then it's a total disaster
I've wasted more time on their dogshit than anything else. The choice of jeets and bloated enterprise everywhere.
Kill openshift
behead openshift
roundhouse kick openshift into the concrete
slam dunk openshift into the trash can
send openshift a valentine's box of chocolates, but the chocolate is your shit
crucify filthy openshift
impregnate openshift's wife and let openshift believe the baby is his
launch openshift into the sun
stir fry openshift in a wok
total openshift death.
 
Yeah. It ships with docker engin if you're installing with apt-get or dnf. That's why I was scratching my head on docker engine + cri-dockerd adapter. I haven't dug in, but there would have to be a pretty compelling argument for me to waste more of my time to get rid of something that ships with docker so I can install an adapter.


I've wasted more time on their dogshit than anything else. The choice of jeets and bloated enterprise everywhere.
Kill openshift
behead openshift
roundhouse kick openshift into the concrete
slam dunk openshift into the trash can
send openshift a valentine's box of chocolates, but the chocolate is your shit
crucify filthy openshift
impregnate openshift's wife and let openshift believe the baby is his
launch openshift into the sun
stir fry openshift in a wok
total openshift death.
They seem to just be retarded, I had a similar experience trying to get proper documentation on the config.toml file. Debian and Fedora both have containerd and runc in their normal repositories and supposedly so do the others, except Red Hat of course. I know at least Fedora works without issue but I've always been using containerd from Fedora not from Docker.
 
  • Feels
Reactions: Sultan Bin Jewstar
like most things Red Hat it works well enough until it doesn't and then it's a total disaster
Preach. I damn near lost 20TB of RAID because of how poorly documented basic-bitch operations like replacing a failed HDD are in LVM. Squarely a Red Hat problem, they've signed their name across all the manual pages and documents. Really frustrating, though I won't leave, because after a decade-plus of using LVM, I'm firmly entrenched in understanding the ecosystem, and changing involves many days of HDD thrash.

As it is, I'm going to suffer some random corruption because one drive is dying, but hopefully the RAID6 I use for all my storage copes adequately.
 
Preach. I damn near lost 20TB of RAID because of how poorly documented basic-bitch operations like replacing a failed HDD are in LVM. Squarely a Red Hat problem, they've signed their name across all the manual pages and documents. Really frustrating, though I won't leave, because after a decade-plus of using LVM, I'm firmly entrenched in understanding the ecosystem, and changing involves many days of HDD thrash.

As it is, I'm going to suffer some random corruption because one drive is dying, but hopefully the RAID6 I use for all my storage copes adequately.
All of their docs on just about everything suck and if it's not a man page they seem to be increasingly behind a paywall, and then you login to their portal and the solution is still useless. I wish I could remember what it was for but I have seen either SUSE or Red Hat link to the Arch wiki for something instead of writing up their own.

NetworkManager is another common pain point, most times it works alright but there's been some times when a machine comes back from a reboot and it just totally shits the bed and gives up leaving the interface in that state. Another one is starting around RHEL 8.6-8.7 sometimes it shuffles around devices so /dev/sda becomes /dev/sdb. Using UUIDs generally fixes it (and I should've been doing that anyways) but it's a problem I've not had for a decade previous to that release and still don't have on a non-Red Hat based distro.

All in all definitely worth the money for their "support" and definitely wouldn't be better spent on hookers and blow, which is probably what IBM is spending it on as they increasingly get more and more do not redeems.
 
NetworkManager
Ahahaha, yeah, NetworkManager is so bad it makes systemd-networkd look good. At least, when I use systemd unit files, the behaviour is what I expect. NM seems to be a fractal of bad design, doing arbitrary things for no discernible reason.

/dev/sd* is ordered in the order the devices start up. It's a kernel behaviour. IDK why you don't experience it in non-RH distroes; I've gotten it in Arch, Debian, Gentoo... I actually knew one of my drives was dying because it would occasionally take a while to start and screw up order. For everything from Grub onward, you really ought to be identifying drives at least by LABEL if not UUID. GPT PARTLABEL and PARTUUIDs are also great for this.
 
Ahahaha, yeah, NetworkManager is so bad it makes systemd-networkd look good. At least, when I use systemd unit files, the behaviour is what I expect. NM seems to be a fractal of bad design, doing arbitrary things for no discernible reason.

/dev/sd* is ordered in the order the devices start up. It's a kernel behaviour. IDK why you don't experience it in non-RH distroes; I've gotten it in Arch, Debian, Gentoo... I actually knew one of my drives was dying because it would occasionally take a while to start and screw up order. For everything from Grub onward, you really ought to be identifying drives at least by LABEL if not UUID. GPT PARTLABEL and PARTUUIDs are also great for this.
Yeah it's definitely something we should've been doing anyways but it was easier to just have the dev name when using IaC. One of those "here's a quick easy thing that will be a problem later" solutions, sometimes the saar is coming from inside the house :)

Speaking of IaC, I wish Ruby had won over Python. Yeah it's slow but it looks nicer and is really good for writing DSLs, I enjoy Chef more than Ansible even with the issues it has. I don't think I've ever interacted with something written in Python, that was more than twenty lines of code, that didn't make me angry at some level. At least that same syntax was absorbed into the newer BEAM languages, too bad the one that has a type system is being created by a Britoid and a website that feels like it came from a Rust tranny.
 
Yeah it's definitely something we should've been doing anyways but it was easier to just have the dev name when using IaC. One of those "here's a quick easy thing that will be a problem later" solutions, sometimes the saar is coming from inside the house :)

Speaking of IaC, I wish Ruby had won over Python.
Maybe for different reasons than you but I sometimes imagine an alternative universe where Ruby won out over Python for machine learning. Python isn't bad and doesn't make me rage but it definitely has more warts than Ruby and is a bit lacking in other ways too. Being able to use === to extend case statements for example is so nice. So is regular expressions being part of the syntax. (Even JavaScript gets that last one right.)
 
Back