That’s easy: you don’t go to high-school anymore.

I agree and disagree.

The premise is solid: unify config so it’s standardized and machine parse-able for better integrations like an easier-to-build UI/UX. It could even have ramifications for cloud-init and older IaC tech like Puppet.

The problem is Linux itself. Or rather, the subsystems that are cobbled together to make Linux a viable OS. You’re not going to get all the different projects to pivot to a common config scheme, so this YAML standard would need a backend to convert to/from whatever each little deamon and driver requires. This creates a few secondary problems like community backlash (see systemd), and having multiple places where config data must be actively synchronized.

I think the current crop of GUI config systems are aleady well down the most pragmatic path: each config panel touches one or more standard config files, wherever they are, and however they are structured. It’s not pretty under the hood, and it’s complicated, but it works. These tools just need a lot more polish on the frontend.

I would argue that vim is fantastic for a lot of editing and coding tasks, just not all of them.

Where it utterly fails is with deep trees of files in codebases, like you see in Java or some Javascript/Typescript apps. Even with a robust suite of add-ons, you wind up backing into full-bore IDE territory to manage that much filesystem complexity. Only difference is that navigating and managing a large file tree w/o a mouse is kind of torture.

echo "text file content goes here" >> myfile.txt

In a professional context (e.g. work/office), O365 and related technologies make a lot of sense. It solves all kinds of real problems, especially for a remote/hybrid workforce. It’s by no means the best answer for any one application, but it’s a very comprehensive platform and gets the job done.

For the home user? Constantly forcing OneDrive into everyone’s field of view on OS upgrades is intrusive advertising for a thing nobody asked for.

Put any distro in front of me and provided I don’t need to master it, I’m good. Ubuntu is fine. Debian is fine. RedHat is fine. Fedora is fine. I even have a tiny low-end system that is using Bohdi. Whatever. We’re all using mostly the same kernel anyway.

90% of what I do is in a container anyway so it almost doesn’t matter; half the time that means Alpine, but not really. That includes both consuming products from upstream as well as software development. I also practically live in the terminal, so I couldn’t care less what GUI subsystem is in play, even while I’m using it.

First off, boating is a losing situation in the real world. Boats are super expensive and require a ton of maintenance constantly. You never own a boat; you own a money pit to maintain.

I just want to back up this statement. OP, this is the exact reason why having a boat is a flex. Nature is constantly assaulting everything man-made in this world, and water is by far the most destructive element in that fight.

Is that MIT (munch it today) or GPL (generally pleasing w/lettuce) licensed?

I’ve been in situations where I wanted to retain credit/ownership of ideas and code, but wanted to be able to use them in the workplace. So building a MIT/BSD licensed library on the weekend and then importing it on Monday was the only game in town. I get the portfolio piece and my job is easier as a result. But I stick to non-novel and non-patentable stuff - “small” work really, as Stallman is quoted here..

In some work environments, GPL or “GPL with an exception” would never get the kind of traction it should. Lots of places I’ve worked lack the legal and logistical framework for wrangling licenses and exceptions. It’s hard to handle such cases if there’s literally nobody to talk to about it, while you have automated systems that flag GPL license landmines anyway. The framing is a kind of security problem, not a license problem, so you never really get to start.

The two licenses have distinct use cases, and only overlap for some definitions of “free” software. I also think both the comic artist and OP set up a fallacious argument. I’ll add that in no way do I support Intel’s shenanigans here.

The comic author takes one specific case of an MIT licensed product being used in a commercial product, and pits it against another GPL product. This ignores situations where MIT is the right answer, where GPL is the wrong one, situations where legal action on GPL violations has failed, and all cases where the author’s intent is considered (Tanenbaum doesn’t mind). From that I conclude that this falls under The Cherry Picking Fallacy. While humorous, it’s a really bad argument.

But don’t take it from me, learn from the master of logic himself.

commonly referred to as “cuck licenses”

This sentiment makes the enclosing sentence an Ad-hominem fallacy, by attacking the would-be MIT license party as having poor morals and/or low social standing. Permissive licenses absolutely do allow others to modify code without limit, but that is suggested to be a bad thing on moral grounds alone. That said, I’d love to see a citation here because that’s the first I’ve heard of this pejorative used to describe software licensing.

I think what burns people the most is that after Photoshop 5 or so, GIMP stopped keeping up with all the improvements in the later Photoshop versions. People making the jump from 2024 Photoshop to 1996 Photoshop UI/UX are gonna have a bad time.

Edit: as a software developer I can say that I’ve never seen a user more frustrated, sometimes even irrationally so, when they are forced to re-learn muscle memory to perform a familiar task. I’ve also seen people practically riot at the mere suggestion that this will happen. If you wish to curry favor with your userbase, never ever, remove keyboard accelerators, move toolbars around, break workflow, etc.

Yes. Not enough daydreaming about winning arguments, mixed with intrusive thoughts and general self-loathing.

If it’s open, looks don’t matter. Also doesn’t matter if the drivers are trash, or if it runs zero games. It’s all fixable trash - that’s the point.

(Also, that’s not a GPU, but it’s the thought that counts)

For us Americans, I feel like that’s a small blessing. An up-to-date graph would be less moldy, but still painful to consume.

A few things come to mind here.

1. MS tried to ship a renegade JDK with proprietary features, back in the 90’s. That didn’t go very well for them, as they drew the ire of Sun Microsystems which was a decently sized player at the time. It was a clear licensing issue, and they lost the case. Point being: they’re historically not great at this kind of thing.
2. The GPL is designed to thwart this scenario, specifically for things like paid software (e.g. Windows). MS would have to move to a “free Windows software, paid service” model before any of this could happen. But the service must be optional, and they’d have to provide the source to anyone that wants it. That said, they’re on track to make Windows free (as in beer), so who knows?
3. Nvidia gets to ship binary Linux drivers, so closed-source binary packages for MS proprietary components on top of Linux might be possible. But again, I don’t think they get to charge for that.
4. WRT to drivers/packages, RedHat famously charges for access to their package repository, making automated patching and upgrading a nightmare if you go without. This is one hell of a GPL loophole and worthy of far more corporate exploitation. I can easily see MS following this path.
5. “The net treats censorship as a defect and routes around it.” - John Gilmore - (Many) People will just fork away or happily sit somewhere else in the GNU family tree, far from anything MS builds. If the need arises, compatibility layers like WINE will show up eventually.

I mean, I like WSL for what it is. Having suffered through the limitations of MinGW32 and Cygwin, I appreciate that the WSL simply “just works.” But I’m also not kidding myself, as one could get the same experience from VirtualBox and a little more elbow-grease. I also like how the WSL automatically exposes a host-only SMB mount, making the Linux filesystem a lot more accessible from the very start.

What I don’t appreciate is that the WSL places the Linux firewall outside the Windows firewall. Locking that thing down can be daunting for a novice, if it’s ever done at all. Considering that the main use-case for this is development, that means there can be a lot of WSL setups out there with exposed and vulnerable web services on 'em.

Oh right, that actually makes sense. He had a voice acting part in the last game IIRC.

I ended up booting from my phone (android app for iso booting)

Impressive. I had no idea that was a thing. That’s easily the most “Star Trek” sounding fix I’ve heard in a good while.

back up in around 40 mins […] on a root shell with no training.

… and you intuited that fix, or at least pulled it together from scratch/google with no training? Doubly impressive.

There really should be a hotkey for “move window to primary display” or somesuch. The worst is when just the top “cleat” of the window is inaccessible, making it impossible to simply move the window yourself.

Alternately, a CLI tool to just trash a specific app’s window settings, or a system control panel that lets you browse these settings, would be incredible.

At one point, my laptop’s Nvidia drivers were all tangled up. The package dependency graph had portions of the screwy, we-don’t-need-your-stinking-standard-version-scheme, binary blob drivers both in front of and behind the currently installed version. I had to basically gut everything Nvidia related, by performing surgery on the filesystem and Apt database, and then build it back. At one point, I was flying in text mode only; not hard, but worth mentioning since it shows how deep a cut this was.

Related: getting the above nonsense to cooperate with containers that also want to do GPU things. As much as I wanted this work with coding up a one-and-done solution (e.g. docker-compose or BASH script), you can’t get away with mounting the host Nvidia driver and tools via volumes. The software on the container image itself must be built against the specific version you’re running - no exceptions. So, I now rebuild these containers after every Nvidia package upgrade (from the author’s git repo), which is a stupid way to achieve containerization. If Nvidia had a stable API/ABI across releases, this would just work. /rant