Hmm… If that’s the case, that’s news to me. I’ll admit I don’t do much with Fedora, I’ll have to take a closer look at them.

Fedora is not rolling at all, it just has a fast release cycle

And I don’t care, so whatever

I mean, that’s definitely a downside to long term stable distros. So, basically, the choice is between that and a rolling release which has the downside of the possibility of things breaking on update and never really having an easily reproducible build

It is not randomly frozen as Mint does follow Ubuntu’s LTS releases, every new version they put out is based on whatever the current Ubuntu LTS is. Their release cadence isn’t linked that closely as a new LTS usually takes a few months to spawn a new Mint release based on it, but they aren’t just freezing some arbitrary point in time of development.

If you mean Ubuntu is randomly frozen, it isn’t either. It follows a release schedule, determines a roadmap, and at a certain predetermined point in developing a new release, they do freeze for new versions so they can complete testing and ensure everything works together in time to release on schedule. It’s certainly not “random”.

And that’s also not what stability means. Stability means functionality doesn’t change, so an up to date Mint 21.3 installed on release is going to be the same as one installed and updated now, functionally speaking. This is accomplished by only backporting important security patches and bug fixes to the version of the software that’s used by the system rather than getting it with new versions where there are new features and changes to existing functionality that can break things based on the previous version. This does not mean it gets all fixes, just the ones they deem worth the effort of backporting.

But it’s not randomly frozen, it’s tied to Ubuntu’s LTS builds. And they didn’t say “stable” is the same as “works well”, they said Mint is both (which is true from my experience at least)

If you need newer packages with Mint, Flatpak is a good way to go (yes it has its own issues, but they do work well for a lot of people)

I mean, you should be careful with destructive changes and commands whether the interface names can change or not… And since they won’t change outside of a reboot, I’ve yet to run into a scenario where that becomes a problem as I’m looking at and making sure I’m talking to the correct device before starting anyway

You know Linux isn’t just used by enterprise sysadmins, right?

And even speaking as an enterprise sysadmin myself, I’ve not had need or use for deterministic interface naming once in my career. I have no clue how common that is, but most of the servers, both physical and virtual, that I’ve worked on only had one Ethernet port connected.

I see the purpose of this, but don’t see a reason why it should be the default, or why it couldn’t have been implemented like HHD/SSD UUIDs where the old dev names were left intact for easy use outside of fstab and the like where consistency could become a problem

ETA: you also seemed to miss the part of my initial reply to you about it being something that can be enabled by those who need it… And if you’re going to say that the enterprise professionals who need it shouldn’t have to turn it on every time they spin up a system, I’ll remind you that enterprise admins working at that level where they’re setting up enough servers for that to be a hassle are probably using orchestration like Ansible, Chef, or Puppet, and can just add that into their configs once

Considering how much systemd breaks the concept of “everything is a file”, this would not surprise me in the least

But the SSD/HDD solution doesn’t replace /dev/[s|h]da# entirely, just adds a consistent way to set them in configs like fstab. You can still use the old device names so working with them at the command line is still easy for the most part.

Yes, because everyone has need of this solution, and wants to have to copy and paste interface names every time they need to touch them, rather than having deterministic naming be an option to enable for those who actually need it…

Couldn’t they be configured to always set each interface to a particular name? I’d think that would be the better solution anyway…

Microsoft at least isn’t trying to be a walked garden (at least, they didn’t used to)

It’s not much, but the bar to be “better than Apple” from that perspective ain’t exactly high

(Also, since they didn’t mention Microsoft at all or make some statement about how Apple was the worst, I don’t see how it even implies that… If you inferred that, I think that’s on you)

Does that make it better?

Pretty sure it’s just about the shared name

Since my other systems were unaffected, I’m pretty sure it’s something on my PC, possibly an update for the Wi-Fi drivers introduced a bug that affects the 5.8 channels

It’s been stable since switching so it’s more academic at this point, I have no burning need to be connected to the 5ghz channels

It seems to be an issue with using a 5.8 gigahertz WiFi endpoint, which has worked fine up until a couple days ago when it started dropping packets going outside my local network: I could watch a continuous ping start failing for a couple minutes while using Synergy to control my laptop that was connected to my work VPN without issue, so it only seemed to be an issue routing outside my network, which is really weird. Switching to the 2.4 gigahertz channels seems to have fixed it entirely.

What I need to do is look up the JournalD commands to be able to read the logs correctly and find what I’m after… Might also spin up a VM to see if that goes out at the same time, would be interesting if the VM can still work while the host is dropping packets…

Not sure what’s extravagant about it… Fully object oriented pipeline in a scripting language built on and with access to the .NET type class system is insanely powerful. Having to manipulate and parse string output to extract data from command results in other shells just feels very cumbersome and antiquated, and relies on the text output to remain consistent to not break

PowerShell, it doesn’t matter if more or less data is returned, as long as the properties you’re using stay the same your script will not break

Filtering is super easy

The Verb-Noun cmdlet naming convention gets a lot of (undeserved) hate, but it makes command discovery way easier. Especially when you learn that there’s a list of approved verbs with defined meanings, and cmdlets with matching nouns tend to work together.

It actually follows the Unix philosophy of each cmdlet doing one thing (though sometimes a cmdlet winds up getting overloaded, but more often than not that’s a community or privately written cmdlet)

It’s easily powerful enough to write programs with (and I have)

And it works well with C#, and if you know some C#, PowerShell’s eccentricities start to make way more sense

Also, I mainly manage Windows servers for work running in an AD domain, so it’s absolutely the language of choice for that, but I’ve been using it for probably close to 14 years now and I can basically write it as easily as English at this point

I’ll probably give it a spin anyway, might be I find some benefit and it looks like an interesting project. Being Rust based instead of C# .NET based could theoretically make it a lot faster (though I’ve not really had an issue of speed in PowerShell)

V1 never actually shipped with any version of Windows

Windows 7 shipped with V2, 8 with V3, 8.1 with v4, and 10 with v5 and later 5.1.

5.1 is the latest (and last) version of Windows PowerShell.

All versions after that are just PowerShell (or PowerShell Core for version 6)

Not sure why they don’t bundle it by default, but starting at v7.2 it can be updated by Windows update