Sieht lecker und fleischlastig aus. Guten Appetit.

More like companion.

When the plastic eating bacteria starts endangering the existence of artificial consciousness in the machine, life on earth will be purposefully wiped out.

They are using the wrong kind of Linux! My kind of Linux is superior, because it’s broken in a different way and more difficult than yours.

As a user the license doesn’t matter for you. Even if you contribute back to a project, you will be able to use your changes in the project.

The license only matters if you want to redistribute a changed version yourself or use parts of it in your own software.

How did Your Party do?

That’s how you build the recruiting base for private fascist armies.

Fully agreed.

If you’re big enough, interoperability still costs and provides little benefit. Vendor lock-in is also a thing between distros.

https://distrowatch.com/search.php?origin=Israel shows no results.

Here‘s your list of Israeli FOSS https://github.com/lirantal/awesome-opensource-israel

It’s not in Red Hat interest to accommodate other package managers.

What software for example?

Exactly. Linux is often held high as an example of how to realize tech sovereignty. Most of it is repackaged work by Red Hat. That’s still a dependency. If the US made a law restricting export of source code, this would have immediate consequences to Linux use in Europe.

tl;dr lots of bugs fixed.

For streaming https://yarrlist.net/

Removed by mod

Removed by mod

Sure, that’s the theory. In practice code review often looks like this:

• a quick glance to see if the code plausibly does what it claims for longer patches
• A long argument about some stylistic choice for short patches

In other words – people were barely reading merge requests before. Code reviews have limited effects as well. You won’t catch all bugs or see if it actually works just by looking at the code. Code reviews mainly serve to spread knowledge about the code among the team. The more code exists in a project, the harder it is to understand. You don’t want huge areas of code, that only one person has ever seen.

Project managers don’t necessarily talk to angry customers directly. They might also choose to chase more features instead of allocating resources to fixing bugs. It depends on what the bosses prioritize. If they want AI and lots of new features, that‘s what they will get. Fixing bugs, improved stability, better performance, etc. are rarely the priority.

Realistically what happens is the code review is done under time pressure and not very thoroughly.

There are differences with hardware support. For example my keyboard backlight isn’t supported in all distros equally. From what I know so far, I suspect this has to do with kernel version and desktop environment.

Getting hardware to work that needs proprietary firmware, for example Broadcom wifi and Bluetooth, can involve several steps like adding a new repository, installing packages, and running a program, or two clicks in the UI.