The content on HN is upvoted by the community. If it appears on the homepage that means by nature it is of interest to the community.

This is usally due to DKMS (dynamic kernel module system). Each time you upgrade your kernel, the nvidia portion needs to be recompiled. If this goes wrong, you end up in a state where you cannot boot.

This is why everyone in the linux world has a very sour taste for nvidia. It's not their fault per-say, but they did opt to go this route versus contributing their drivers to the kernel like everyone else.

That makes sense. Of interest, this was actually an easy fix; go to GRUB, and pick an older kernel! Ty for pointing me to the kernels.

In the future or even today with immutable distros, you'll be able to roll back the entire OS the same way you can roll back the kernel to undo any change that breaks the system.

The author's point here is great, but the post does (imho) a poor job illustrating it.

The tl;dr on this is: stop sprinkling guards and if statements all over your codebase. Convert (parse) the data into truthful objects/structs/containers at the perimieter. The goal is to do that work at the boundaries of your system, so that inside of your system you can stop worrying about it and trust the value objects you have.

I think my hangup here is on the use of terms parse vs validate. They are not the right terms to describe this.

I understand where you're coming from, but these terms seem fine to me:

This is exactly what, for example, Rust's str::parse method is for. The documentation gives the example:

    let four: u32 = "4".parse().unwrap();

You will so very often have text and want typed information, and parse is exactly how we do that transformation exactly once. Whereas validation is what it looks like when we try to make piecemeal checks later.

Coming from a more "average imperative" background like C and Java, outside of compiler or serde context, I don't think "parse" is a frequently used term there. The idea of "checking values to see whether they fulfill our expectations or not" is often called "validating" there.

So I believe the "Parse, Don't Validate" catchphrase means nothing, if not confusing, to most developers. "Does it mean this 'parse' operation doesn't 'validate' their input? How do you even perform 'validation' then?" is one of several questions that popped up in my head the first time I read the catchphrase prior to Haskell exposure.

Something like "Utilize your type system" probably makes much more sense for them. Then just show the difference between `ValidatedType validate(RawType)` vs `void RawType::validate() throws ParseError`.

The crucial design choice is that you can't get a Doodad by just saying oh, I'm sure this is a Doodad, I will validate later. You have to parse the thing you've got to get a Doodad if that's what you meant, and the parsing can fail because maybe it isn't one.

    let almost_pi: Rational = "22/7".parse().unwrap();

Here the example is my realistic::Rational. The actual Pi isn't a Rational number so we can't represent it, but 22 divided by 7 is a pretty good approximation considering.

I agree that many languages don't provide a nice API for this, but what I don't see (and maybe you have examples) is languages which do provide a nice API but call it validate. To me that naming would make no sense, but if you've got examples I'll look at them.

The point is parse and validate are interchangeable words for the most part. If you’re parsing something you expect to be an int, but it’s a float or the letter “a” is that not invalid? Is this assessment a form of validating expectations? The line between parsing and validating doesn’t exist.

But they plainly aren't interchangeable? Just asserting that it's true doesn't make it true.

The circumstances where you would use one or the other are vastly different. A dataframe is an optimized datastructure for dealing with columnar data, filtering, sorting, aggregating, etc. So if that is what you are dealing with, use a dataframe.

The goal is more about cleaning and massaging data at the perimeter (coming in, and going out) versus what specific tool (a collection of objects vs a dataframe) is used.

We got social credit on GitHub before GTA 6.

this is the enshittification of the world. players like taboola.com are responsible for this.

have u ever been to truth social? it's the most user-hostile experience since the days of limewire and bonzai buddy - https://truthsocial.com/@realDonaldTrump

I would argue the contrary - most home routers are running a DNS server of some kind. They forward to upstream, but will resolve local names like your printer and whatnot.

dnsmasq is the defacto tool on these embedded devices for dhcp+dns. probably a billion deployments. it's up there with sqlite for most used tech.

IIRC a resolver is what people would think of as a DNS server only it's not an authority for any domains. Like you said, they're used to get load off of authoritative servers and are very common. I think dnsmasq is mentioned explicitly in the O'Reilly locust book but it's been a while.

cold = contracted vessels etc = less fluid movement = yawn required.

happens to me a lot when i am on shrooms too