It's hard to say, because those courts have usually decided in favor of rights holders, and they are how we got a copyright cartel in the first place.

I'm finding that ZFS is stupid, and I'm thinking about switching to normal dmraid.

Notably, if you really load it up for a while such that it has a chance to fill up its buffers, it doesn't save any I/O for anything else. The whole system just gets punched right in the fucking balls and becomes completely unusable while the cache empties. Maybe there's some way to tune this tendency out of it, but...SANE DEFAULTS!!! If your project doesn't have them, you're a fuckup! Allowing one process to make a system unusable, that's a fuckup!

When you combine that with the raging arrogant attitudes of about 50% of ZFS think-they're-experts and all of the things which ZFS should be able to do which you're told not to do (like rotating a disk from a 3-way mirror as a short term backup strategy) it becomes clear that it's actually a big joke. The proponents say ZFS can do everything, then they tell you not to do thing after thing and it becomes clear it can only do about half of what they claim.

We had discussions about this here at the time. You may feel free to locate and review them so we don't have to have them again. TL;DR: no clue about Arch, but Debian pushed the decision through with less consensus than usual to support the new GNOME, which depended on it, and which statistically no one was asking for.

It's a bunch of utilities that depend on the same libraries and one another, you cannot just separate out any pieces you want and use them independently, some of them come in packs and using one implies using the next, or having a real bad time. That is the root of the complaint about systemd not following the Unix way.

Yes, the KDE devs are smarter and more competent than the GNOME devs.

But no, you can't. This becomes immediately apparent when you try to talk to them in the way you would talk to a normal person. You ask them for something which should be simple because what you want to know is what most people would want to know. You ask it the simple question and it frequently takes the most obscure view of the question possible. So then you have to rephrase the question once or twice to be incredibly specific in a way that would be unnecessary if you were talking to a human, since they are also humans and know what specifics you were expecting to have addressed.

How much energy does it take to drive to a laundromat and back?

Freshwater is cheap for a reason: it's abundant. It's agriculture that uses the overwhelming majority (70% of withdrawals and 80-90% of consumptive water use. Industry next (20% of withdrawals). Residential usage is way, way down the list, and washing machines are only 17% of that (well below for example lawn watering at about 30% overall, but which in some regions is over half of all consumption, and in the summer and times of water scarcity can be the vast majority). An early 1950s top-loader washing machine would use about 40-55 gal plus 0,3-0,5 kWh of electricity for the machine itself, and if your water wasn't municipally heated, heat would cost about 4,5-6,5kWh / 16-23 MJ (about 1/2 to 2/3rds of a litre of gasoline / 0,13-0,19 gallons). At the then-standard 14-15 MPG in the US, that laundromat better not be more than 2-3 miles away if you're trying to save energy (just ignoring the energy they use to heat their water!)

...who might be wrong.

We don't yet know how AI output is going to interact with copyright.

So far you cannot copyright any AI output. That means you don't have the right to specify the license for it, either, because all software licenses are powered by copyright.

Courts might even decide that the original copyrights apply. But which? The ones to code that looks the most like yours? Or every license which applied to any code which might have been involved in the creation of the output? Nobody knows yet.

As such, you run into a trap when trying to decide if the output is open source. Does it only mean that you can see the source code, or is the license relevant? Do you actually have to have legal permission to use or at least see the code? Most would say yes, if you don't have the legal right, then being able to see the code is meaningless since you can't actually use it without poisoning projects with some other license — or no license.

TL;DR: It is very much still up in the air whether it is reasonable to describe any AI generated source code as "open source".

For the record, while there may be more anti-AI backlash on the left than the right, there's an awful lot on both sides (and a lot of users on both sides). For example, Bannon-acolyte Joe Allen on stage before a Trump rally a month ago warning the crowd:

Why wouldn’t you want a mosque in your neighborhood? Well, because the people in there aren’t like me. They don’t want the same future I do. Now, if you look at the data center, this incubator for algorithmic immigrants. Already, if you look at Hugging Face, they’ve already broken out and invaded other companies. These immigrants are out of control.

Literally, this r/opensource mod set the policy: "If you don't speak English, you need to find a different community." Does that sound very "leftist" to you? Yes, his reasoning was because translators use AI, but still, that's literally the opposite of appreciating and accommodating diversity.

I cannot find anything beyond that indicating how Wesley Wolfe (r/wolvereness, the mod) votes. What I can tell you is that there was a big backlash in the sub to his actions. Some amusing, like a person asking, "What do we use now that we've banned Linux? I can't afford Windows keys for all these damned servers." A lot of people seem to just be ignoring his rules. At the top of the sub right now is a post titled, "Linus Torvalds posts his AI-assisted patch to the Linux kernel, synthetic test clocks 23x performance leap". It seems to have sparked vastly more AI discussion than it shut down.

I didn't mean to imply that it is a single monolithic application, it does consist of several, but the relations must be pretty tight for there to be an article not even about language-independence; but about support for a single additional language, one often targeted by "C but cleaned up" efforts,

I was honestly surprised to see this myself. Regardless of its reputation for being more monolithic than classic init systems it still is, and has to be, capable of interacting with basically any flavor of service you'd want a service manager to manage; and I would assume that it doesn't include a d-bus implementation in order to not be capable of abstracted inter-process communication.

No doubt there are considerations at work here that I'm not smart enough to grasp; if you aren't having a bad time handling x.509 certificates you probably aren't doing it carefully enough; but I would not have expected it to be remarkable at all for a certificate-wrangling component to be implemented in a different language than some of the other components.

I assume that this is more pragmatic than just waiting for Sam to finish lying about transcendent AGI; but it feels a little dissonant to have the botmongers going back and forth between praising the glorious natural-language suitability of their progeny and putting together an entire platform, with more apparent effort than they have dedicated to human UI/UX considerations since sometime in win7(excluding dark pattern R&D) to aid you in discovering your sins against bot comprehensibility and fixing them.

I'm not really qualified to deliver a good holy war; but it does seem like there may be something to the criticism that monolithic integration has gone a bit far if supporting one utility being written in a different language is a special feature rather than a matter of the rest of the system not knowing or caring what is on the opposite side of an interface so long as it can act as expected.

You can't really beat the fundamental economics of software development: expensive to do right but cheap to copy means that you really, really, want to share a problem with as many other people as possible(unless your whole business is being uniquely good at solving whatever the problem is; but that typically isn't the case for this sort of software). Applies to both proprietary and FOSS: relatively mass-market software is often pretty cheap for what you get; really oddball niche stuff is frequently both pricey and terrible; while your life is going to get steadily more miserable if you are personally responsible for handling backports and fixes for some internal fork of a long-EOL version of an OSS package.

The big difference, at least potentially, is that, while it tends not to be economic to DIY, licenses that give you the right to DIY also give you the right to pay someone else to do it for you; or to form a coalition of people with similar problems and have everyone pitch in to pay someone to do it for you. You still need to either eat the cost of maintaining an internal fork or putting together some sort of coalition of people with similar problems to be the openJDK 8 forever pals and share the cost of maintenance; but the vendor can't just stop selling you licenses if they want you to move to their cloud offering or whatnot.

I can get a smartphone that is not under the control of Apple or Google, they both recently ruined their maps apps with advertisements embedded getting in the way of what you are trying to search, way to go Apple & google you both shit on the only useful app you made

Random intermediate CA. They got a couple of commonly used root CAs to sign for them; and everything just works from there.

That's the problem. It's relatively easy to fire a certificate issuer; but it can get surprisingly fiddly surprisingly fast to ensure that all your stuff actually distrusts one(unless you are responsible for basically nothing but a a handful of in-support major browsers and are OK with the choices their vendors make, in which case it will be handled for you relatively quickly; and was in this case). Basically any network connected widget is going to have at least one trusted root store embedded in it somewhere, possibly not updated anymore; and a number of software packages either bring their own or only partially track the OS-provided one.

You also have very little control over what other people do; both what CAs they chose to get certs from and what...questionable...partnership decisions the root CAs you do chose to trust. It's not technically secret; but unless you are practically a full-time PKI nerd you probably didn't know until after the fact that Comodo, now Sectigo, had quietly trusted eMudhra for you.