lemmyvore

@lemmyvore@feddit.nl · Joined ⁨Jun⁩ ⁨2023⁩

Replying to an earlier post

But this is a best case scenario: bugs accumulated over the years are being spotted automatically and reviewed by experienced devs. It was normal to have a few updates that are very large due to all the accumulated cruft.

The bigger deal that will be an issue going forward is the bogus bug reports, not the good ones. The legit reports will dwindle eventually, bullshit reports will keep coming.

Replying to an earlier post

I keep seeing “escape the container” mentioned like it’s a very common occurance. Is it really? I’ve looked up escape CVE’s and they seem to be few and far apart, they’re usually tricky to pull off, and when one comes out it’s a big deal and they get fixed right away (obv).

Actually my issue isn’t “do escape CVE’s exist”, it’s more like, should I really waste my time planning for it? It’s like planning for file permissions not to work, or logins to be bypassed.

I get that shit happens and why defense in depth is a thing but how do you defend from something so fundamental? If you operate under the assumption that containerization can be by bypassed, and virtualization can be bypassed, where do you draw the line and what do you do, run each app on a standalone physical box?

Replying to @⁨Krzd@lemmy.world⁩

People that can rub two neurons together have figured out they can get their 10yr old nephew to install something for them… so the included OS means nothing besides how it affects the final price. They’ll buy a laptop with Windows/Linux/no OS or whatever on it. In markets that don’t allow computing devices to be sold without an OS it doesn’t even have to be Linux, the vendors and manufacturers will happily slap FreeDOS on it to bypass the regulation.

Replying to @⁨pelya@lemmy.world⁩

Unfortunately most companies don’t have a software culture or even understand it. Heck there are entire nations (like Japan) that are culturally at odds with software. It doesn’t stop them from making software (you can’t NOT make software in today’s day and age), they just go about it in furtive, roundabout and ultimately very inefficient ways.

It’s weird because modern software development borrows heavily from industrial process optimizations (some of which were invented and perfected in Japan, ironically) and there are clear, proven benefits to cooperation upstream in projects like Linux… and yet they still fight it every step of the way in the name of “IP”.

It doesn’t help either that there are countries (US, Japan, what do you know) that nurture the concept of software patents that have a chilling effect on sharing.

Replying to @⁨douglasg14b@lemmy.world⁩

Literally all knowledge and understanding requires memorization of some sort and the understanding of reality and prior information.

But is that what schools are teaching? When’s the last time you heard of a school that prioritizes the way its students think and focuses on improving their reasoning and cognitive skills?

I’m not knocking memorization but it shouldn’t be the main or only token by which learning is evaluated.

Replying to @⁨Sirdubdee@piefed.social⁩

Why go to school if you’re just going to use AI? What are you paying for?

You could also ask what good is a school that only teaches you things that can be reliably answered by AI.

Or, if you prefer, why is the school curriculum defining and evaluating progress in a way that can be passed by an AI.

IMHO it shows that certain subjects rely way too much on rote memorization and loose cognitive associations and should maybe take this moment to rethink their approach.

Replying to @⁨InternetCitizen2@lemmy.world⁩

Sharing code makes sense for everybody. It lets them spend a lot less resources on fixing shit if everyone else is also doing that somewhere upstream. With FOSS you can have your cake and eat it too. At some point Google calculated that committing one developer upstream for the Linux kernel can save a company the equivalent of a couple dozen specialist developers downstream in bug prevention and feature alignment across vendors alone.

Unfortunately many companies continue to think about code as if it were potatoes. It doesn’t fucking matter who owns the code, it’s a functional spec. But hey, look at all the trouble we have explaining why standards are good – nevermind opening code.

Replying to @⁨steel_for_humans@piefed.social⁩

In Docker’s case is a non-issue because they were careful to use completely different names for all their packages. It’s only when the external repo uses the same names as the core that the dependency resolver can get confused.

Rant:

apt should either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.

I’m guessing that letting external repos “hijack” a package name was once upon a time seen as a feature and then they never got around to fixing it.

Replying to @⁨steel_for_humans@piefed.social⁩

You say that but sometimes they come up with stuff that’s really useful and it can be very annoying to not have it. Like when they integrated compose into the main.

Also, if you later decide to switch to the official version you’ll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.

Mind you, this can also happen by tinkering with stuff in /etc/docker/daemon.json, which is how I originally learned to back up my shit.