Lots of good insight there. While I disagree with much of it, I get it.

I’m all for keeping one’s cognitive skills. However it is a fact that this decline happens, and that there is a phase of life where one has wisdom without necessarily having the same raw intelligence they had before. The wisdom is encoded in crystallized intelligence.

Yeah, realizing you have that wisdom is eye opening and it’s actually pretty powerful. I can hunt down bugs by smell now with surprising accuracy. But I’m not convinced it’s mutually exclusive to fluidity. I guess I’m just hoping my brain doesn’t petrify and am battling against it.

That was possible because those machines don’t change too much as time marches on. Because they use a stable platform, his organization was able to do better work by relying on his deep expertise. He could train those younger guys because it was the same platform he’d always used. Same dirt, same physics, mostly the same machines, same techniques, same pitfalls, etc.

It’s a poor analogy for software though. Software is an ongoing conversation. Not a device you build and forget about. User demands change, hardware changes, bugs are found, and performance is improved.

I’m honestly curious what the oldest line of code in the Linux kernel is now. I would be pretty shocked to see that anything survived 30 years. And I don’t think that’s because of enshittification.

This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work.

Why not? Because you won’t be able to hire younger devs? That is a function of this culture of pushing for change in everything.

No, because C/++ isn’t the right tool for every job. If I want to write up something quick and dirty to download a sequence of files, I’m not going to write that in C. It’s worth learning other things.

I have to admit though that the conservative approach is more suited to things like a kernel, aerospace applications, or other things with lives riding on it. But also software that doesn’t change becomes useless and irrelevant very quickly. For instance, running Windows XP is a bad call in just about any case.

But again I’m also not trying to say all software should be trend following. Just that devs should embrace learning and experiencing new things.

It’s a well-documented fact that as people get older their fluid intelligence declines.

I’m quickly approaching grey beard status. I recognize that I’m nowhere near as fluid as I was 20 years ago but I make an effort. You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other. It’s important to stay fluid because things change and change faster than we all expect.

At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.

Ensuring compatibility with greybeards’ brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.

There’s some truth to that. PHP is still in use and Wordpress is still somehow a behemoth. But the fact is that PHP has fallen out of favor, isn’t used by new projects, and there’s less demand for people with that skillset. So as a dev, it’s important to recognize that tools come and go and be flexible.

This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work. So you’ll probably have to pick up other things for your toolchain (and higher level) work which of course has changed a lot.

The good news is though, that it’s relatively easy to transfer core skills between most languages. Especially the ones with C-like syntax, which is most languages.

employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.

Middle age software engineer here. Very disagree. Hoping to code until arthritis gets me. My point wasn’t only for employment (more of a perk), but primarily self-improvement and improvement on your craft. The day I can no longer do that, that may be the end for me.

That said, I don’t know what Linux community should do about Rust adoption. I just wanted to point out that I think it’s very important for all devs to be able to embrace learning new things and expand and refine their skillset.

I never said anything about someone’s usefulness as a person. Their usefulness as a software developer was the topic at hand. Maybe it’s not your profession but a hobby but the point stands.

I think the very phrase ‘my usefulness’ is dangerous. Are we only worth something as drones?

And yet it’s drones that do one thing and only one thing their entire lives, never learn and grow.

Learning is key in this field. Being able to learn new things allows you to move from one thing to the next as needed. You also learn a lot from experiencing different things. Other ways of doing things, other points of view, other concepts that you may have not been exposed to before.

It also expands your employment potential and general usefulness. Knowing only one thing will severely limit your abilities.

“Learning something new” does not mean the thing you are learning is new. It just means it’s new to you. One of the best things you can do for yourself as a dev is to learn to be fluid and be able to adapt to new languages, protocols, and technologies.

+1 for LVM on LUKS

Many of us would prefer the article to the video.

Just because they can do X doesn’t mean you shouldn’t protect against Y.

Just as an example scenario, say border guards took my laptop out of my eyesight. A camera or USB keylogger won’t do anything in that case. Hijacking my bootloader though potentially gives them access to my machine without me having any clue.

Secure Boot is useful and worth setting up. But everyone has to decide their own level of comfort when it comes to security.

Same, but it was Hyprland that drug me over.

Woo, a benefit to me never getting my webcam drivers working.

It’s defined right there in the title. First keypress to login prompt.

No, it isn’t. A decimal is always a decimal.

I have a slight suspicion that you did intend to be a pedant.

Oh

That’s been changing for me lately. All of a sudden youtube is throwing me curve-balls and it’s great.

Here’s a resource I’ve been keeping in my back pocket for when I dive in:

https://github.com/castrojo/awesome-immutable

Even if you’re poking at a black box and are reporting that “it acts funny when I poke it this way.” I’m my opinion, a reporter should send along a script or at least explicit instructions on how to repro.

I take the report more serious since it demonstrates you have an understanding of the issue or exploit. It will also save my time and it’s likely a trivial effort for the reporter since they’ve the context and knowledge of the issue loaded up and ready to go.

Agree that people like to fluff the severity of bugs they report. It’s better for prestige and bounty payouts. But this is a little more nuanced.

“While I didn’t really intend the module to be used for any security related checks, I’m very curious how an untrusted input could end up being passed into ip.isPrivate or ip.isPublic [functions] and then used for verifying where the network connection came from.”

It’s interesting, that it would be hard to make a case that there was a “vulnerability” in the ip package. But it seems like this package’s entire purpose is input validation so it’s kind of weird the dev thinks otherwise.

Recurring incidents like these raise the question, how does one strike a balance? Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.

The researchers need to provide proofs of concept. Actual functional exploits.

As a very long time Arch user I wouldn’t say “easy” like everyone else seems to. I absolutely would not suggest it for a first distro for someone, which is what I would classify as the “easy” level.

But if you’re comfortable with using Linux, the terminal, and being able to follow written documentation you’ll be able to do it just fine maybe with a little frustration the first time. If you’re installing to a laptop, make sure to look up your model on the wiki first.