Time to install to OneDrive.

This sounds like a whole lot of convoluted bullshit to use Plex locally and “looking local” through VPN solutions when you could just roll a Jellyfin instance and do things a more straightforward way…

can’t even do video playback on VLC.

I remember back in the day when I downloaded the first divx file my K6-400 couldn’t smoothly play… I had been so used to thinking of that as a powerhouse coming from my Pentium 60, which was the first one I ran Linux on.

You can use one of a few ways to use the TPM to auto decrypt on boot without passphrase. Systemd cryptenroll is my favorite.

Because it says to do so?

Proxmox uses Debian as the OS and for several scenarios it says do Debian to get that done and just add the proxmox software. It’s managing qemu kvm on a deb managed kernel

To be fair they made a lot of strides to the point where config file wrangling went from mandatory to almost never done.

But yes, Nvidia would have quirks driving people back to wrangling config file, but they got better too.

Though I’m not particularly interested in X11. The biggest thing they had was trivial application forwarding, but the architecture didn’t scale well to modern resolutions and UI design that was largely bitmaps being pushed, as well as not handling higher latency networks too well.

I don’t see anywhere where I said that…

Why do you seem convinced I can’t possibly be a software developer? Evidently your development career has given you one experience with a company that takes the task with a great deal of seriousness and I’ve seen that happen, but a lot of companies are not so diligent and either try to game things best they can either with like two people making git commits or an army of offshore developers that seem to quit within 6 months leaving little competency and plenty of opportunity for a bad actor to get in the door.

By relative volume of the known things. It’s not a guarantee, but it’s highly suggestive that the more observable instances of something, the more not yet observed instances of the same thing are out there.

There are factors that can knock that out of balance, like not having access to source code making things harder to find, but those confounding factors would hide more on the closed source side than the open source side.

Probably not. 15 years is not that long, what do I know, I’m just on senior expert level.

Longevity is not a guarantee of broad exposure. It may mean you have deep exposure, but making the rounds around the industry I can’t imagine maintaining such a universally optimistic picture of commercial management of software development.

Companies run skeleton crews on crap products that don’t make money.

Companies run skeleton crews on products when they think they can get away with it. Very high profile commercial projects with a lot of analyst attention may not be able to get away with it, but some surprisingly high profile projects without quite as much scrutiny get away with more than you would guess.

This is where your lack of knowledge about products like that shines through.

I’m speaking from familiarity with the provider side of things, wondering when a customer will catch on that they can’t seem to get that awesome support unless it’s the same guy as their peers get, and suspiciously unable to get decent support for a random week in June or something.

From what you are writing you aren’t a programmer and you haven’t worked in a software corporation before

Incorrect assumption on both counts. A few companies across a couple of decades and two of those companies extensively engaging with other companies on projects to get me some exposure to closed source development organizations even at some other companies.

If OpenSSL was for-profit, it would be a corporate project with dozens if not hundreds of developers

It seems like you don’t have a very broad exposure to closed source development. Corporations frequently have a skeleton crew working on a component or entire project. You might notice if you get escalated to development enough that it’s always like the same guy or two. It’s because they might only have a couple of guys working on it. Some companies will spend more on measures to obfuscate that reality than they would spend on actually developing. Certainly some corp closed source projects are that big, but so too are many open source projects.

Hell I’ve dealt with financial institutions using proprietary software that was abandoned by their vendor 15 years prior (came up because the software no longer worked with new stuff, and the institutions demanded wrapper software for new stuff to imitate the old stuff enough to keep using the unmaintained, unpatched, zero developer project).

I also don’t think companies are holding the proprietary vendors to quite the standard you imagine, certainly not automatically. By the same logic you propose for open source “someone else must have done it”, you also have that for big companies, if not more so. “Surely they have good security practices” or “it’s so popular someone must have done that”.

Or even a PR step

Sorry, there’s no business case for rebasing those dependencies. Please focus story points on active marketing requirements instead.

Yeah, you open a bug like that in proprietary software and it will immediately get rationalized away as having no business case to address, likely with a person with zero direct development responsibility writing a bs explanation like the small impact was due to a number of architectural changes.

Speaking as someone with years of exposure to business managed issue handling.

Evidence suggests this isn’t the case.

We know of so many more closed source backdoors despite them being harder to notice in practice. Either before they became a problem or after they have been used in an attack. So we know backdoors can get noticed even without access to source code.

Meanwhile we have comparatively fewer backdoor type findings in major open source software, despite and thanks to increased scrutiny. So many people want to pad their resume with “findings” and go hit up open source software relentlessly. This can be obnoxious because many of the findings are flat out incorrect or have no actual security implications, but among the noise is a relatively higher likelihood that real issues get noticed.

The nature of the xz attack shows the increased complexity associated with attempting to back door open source. Sneaking a malicious binary patch into test data, because the source code would be too obvious, and having to hide asking the patch in an obfuscated way in build scripts that would only apply in theory under specific circumstances. Meanwhile the closed source backdoors have frequently been pretty straightforward but still managed to ship and not be detected.

Even if we failed to detect unused backdoors, at some point someone would actually want to use their backdoor, so they should be found at some point.

Switching to Dvorak caused the gratifying result of people that would just start trying to use your keyboard without being absolutely befuddled.

The key map tends to apply to all keyboards.

The computing equivalent of a stick shift.

Funny part is I’m responsible for some software which needs just a little privilege.

The direct install option runs as a broadly unprivileged user, thanks to systemd service for imparting one, surgical ambient capability to the process.

A team that wraps it in a container however demands it be run privileged, because they say the container runtimes dont support the same granularity, so the container users end up with unreasonable privileges while the direct install users are almost completely running unprivileged.

The only way it could really do it would be for the Windows shell to get out of the way, which it won’t.

You can with effort have some sort of abomination where you get inflicted with both UI designs at the same time…