namingthingsiseasy

Not necessarily! I always run ln -s '/usr/bin/$EDITOR' $(which $EDITOR) after a fresh install, so I have a valid executable on the path called $EDITOR.

Of course, then I have to make sure to add export EDITOR=\$EDITOR to my .bashrc. (Obviously.)

I believe you're thinking of Gentoo. But it seems that you can get precompiled kernels in Gentoo these days.

+1. systemd is something the Linux ecosystem really needs, but its execution is abysmal. We should be designing around standards so the best product can win. We should not be designing around singular implementations that could make it easy for Red Hat to execute a EEE strategy to consolidate Linux on the workstation.

I can't wait till a crowdstrike-like flaw is exposed in systemd so we can all see how terrible^W wonderful monocultures can be.

I dunno. I’m a believer that there is real benefit to diverse teams and there is some evidence in support of this.

You're 100% right! But good luck convincing the bean counters.

The full write-up can be found here and should be fairly readable for users of this forum.

Some quotes that I thought were interesting:

With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc's addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.

So 64-bit systems seem to be a bit more resistant to this it seems? But I can't be completely sure given how much I've read about this yet.

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).

And OpenBSD wins again it seems.

I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.

By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.

That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.

Your Steam games will go to the grave with you

Great, then I'll finally have some time to play them....

I assume you're trying to imply in your comment that people are not going to use it if it's not easy.

It's unfortunate, but sometimes, having nice things can be a little hard. If people want to use the easiest thing under the sun, then they'll just have to accept the downsides that come with it. Sometimes, that means private companies will use private photos of people's underage children in AI training models that can generate deepfake pornography. What can you do? Convenience comes at a cost sometimes.

I'm not saying I agree with this of course, but that's just how things are in the world where all rules must follow the dollar.

Well of course, that's true of any and all publicly accessible data. At least with self-hosting, your private channels still don't get mined against your wishes

Everyone in this thread is saying that this comes as no surprise, and that is certainly true. But the thing is, a lot of management types do know this already but they simply don't care for two reasons:

1. They care more about leverage/control over employees than they do about actual good work being done. You cannot understate at all how important employee control can be for managers and how seriously they're willing to destroy their own business to keep this kind of power.

2. RTO is basically a layoff program. As much as I love working remotely, it's very important to keep in mind that remote workers are the first ones that will get laid off when the business wants to cut back - purely because of how easy it is to do. They can just mandate RTO without actually calling it a layoff and know many workers will outright quit, and the business won't have to comply with whatever local regulations are in place around layoffs. Still, this shouldn't sound like comfort for employees that do work in the office - there's a good chance that once RTO is in place, another round of layoffs will strike when the company doesn't meet its cut targets. So tl;dr: any time a business announces return to office, it means that there's a good chance that layoffs will follow too.

Xournal - a great way to draw on pdfs

Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.

But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up... Java, C++, Python, etc.

Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement Runnable these days. Before, if you wanted to run a thread, you needed a separate object that inherited Thread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)

Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.