I faced pretty much the exact same choice, except I was given four of them, each with 8 GB of RAM.

Unfortunately they were two different hardware revisions, so the most I could achieve was two servers with 16 GB each.

They sound like a Jet taking off when powered up and the BIOS doesn’t support lower fan speeds.

Instead after months of deliberation I decided to go with a SFF Lenovo, 32 GB, 2 x 1 TB NVME, Ryzen 7, and bought this:

https://www.officeworks.com.au/shop/officeworks/p/lenovo-ideacentre-ryzen-7-32gb-2tb-desktop-lenic00aau

It’s whisper quiet and running Proxmox.

To get VM video passthrough to work I installed an extra video card, though, you could install a desktop on the host OS instead if you prefer.

The video card I used to fit inside is this:

https://www.msy.com.au/product/msi-geforce-gt-1030-4gd4-low-profile-oc-graphics-card-geforce-gt-1030-4gd4-lp-oc-73092

No idea. I have two accounts, one on Lemmy, one on Mastodon. Presumably somebody is mirroring this community to Mastodon, or perhaps the other way around, I’m not sure.

I’m typing this on Lemmy, not Mastodon.

The issue is not packaging, it’s users circumventing security out of ignorance, willful or not, still ignorance.

As Linux gains popularity, the users will need to learn, often the hard way, how to go about installing stuff. Running a random script off the internet is not how it’s done.

Uhm … no.

Linux had permissions from day one, neither Windows nor Apple did until much more recently.

I use Apple, since there’s many versions of its OS and only¹ the one based on BSD has permissions.

The entire Linux ecosystem is permissions based, it’s baked into the kernel and while bugs continue to be discovered and patched, they’re visible to everyone, where that’s not the case with either Windows nor Apple.

Permissions aren’t new. Unix has had them from the early days, as have operating systems like VMS, BSD and OS/400 to name a few.

As for exploits, the level of user social engineering exploits is exploding with the growth of Linux, since most new users come from operating systems with poor security.

In my opinion Mac OS is hurting itself by making inexplicable security choices, causing pain where none is required, resulting in people actively disabling security to their own detriment.

As for actual exploits, they’re getting more and more ubiquitous since more and more operating systems are running the same code, think python, nginx, bash, etc.

Finally, I’d point out that your attempt at dispelling what you call a myth does not appear to be backed up by facts or sources.

I’ve been in this industry for over 40 years and while it’s far from perfect, I am comfortable stating that Linux is more secure than many operating systems and I suspect that it will continue to be the case for the foreseeable future.

I also note that it has a significantly larger user base than any other OS. Don’t believe me? Heard of Android, same Linux kernel.

¹ There was a brief A/UX hybrid OS that had permissions, based on Unix System V and BSD. It was discontinued in 1995.

https://xkcd.com/927/

If you’re not going to show the source code, there’s absolutely no point in using GitHub.

As for getting paid, I hadn’t seen gumroad before, nice, but failing the access to the source, it’s unlikely I’d buy/pay for unknown software and install it sight unseen on anything I care about.

From a security perspective, in my opinion this is a disaster waiting to happen.

Pandoc will convert markdown to a PDF in portrait or landscape and there’s even “beamer” support, aka data projector or presentation support.

Why run Docker Desktop when it’s installable as a cli service?

What are you actually trying to achieve?

As a creator, I’d be much more interested in a way to get paid into my actual bank account in such a way that didn’t involve Bitcoin (et. al.), PayPal or Stripe.

Tah. I’ll have a look see.

Not sure how, or if, I’d want to install an Arch package under Debian, but it’s my understanding that the package I’ve raised a bug for under Debian implements, or is supposed to at least, the functionality you’re describing.

What I haven’t found is a recipe that documents exactly how it’s supposed to work (not to mention, in a Debian way).

I’d love to discover something that doesn’t start with instructions to remove all pipewire packages and install from source, since that completely defeats the purpose of running Debian Stable as the host.

In my adventures I did look at this, but it appears to require that you install support for this inside the guest, which is possible for modern guests, but not for ancient ones like say Debian Wheezy or Win98se.

I’d be surprised if they had been updated at all after their installation was signed off.

Globally we’ve agreed that the ASCII code for a space is 32, 65 for the letter A.

Unicode characters are also globally defined, so when someone uses an agreed upon code, everyone sees the same thing, like this grimace smiley 😁

A private area is a place that we’ve all agreed is for “private use”. If a trademark owner wants to use their special character in their documentation, they can define one area to represent their character, but the only people who will see it in the same way, are people who installed their particular font.

Anyone without that font would see whatever the font on their own machine displayed.

Putting random stuff in such a place is no more than putting gobbledygook in a text and it might even be used as a way to fingerprint text.

I’m not sure what you want to “detect” or “mitigate”.

While this doesn’t answer your question, I use Docker for this exact purpose, since you can throw away everything if it fails, whilst keeping a recipe for success documented in a Dockerfile.

And how is an operating system defined in that law?

Should this be handled at the BIOS level, the kernel level, the init level, the packaging level, the GUI level, the user login level, the user desktop level, or somewhere else entirely, like a derivative distribution with its own layers, some of which will be different from the base distro?

I’m asking because each of those levels are pretty much handled by different groups of individuals, groups and organisations in different jurisdictions, cultures and countries.

While we’re talking about options on where to put this “feature”, who is liable for it not being implemented?

You might have an opinion on where it “should” be, but I can guarantee you that there are at least as many opinions on where it should be as people you ask.

That’s why the Debian Project is doing what it is.

Asking an expert for their opinion, even if that expert is a lawyer, is not “lawyering up”, nor is their any evidence whatsoever that the Debian Project or the SPI is going to “probably sue over it”.

The summary under the heading “TL;DR” was nothing more than an inflammatory opinionated interpretation of the headline and as interpretations go, it was not in any way, shape, or form, anything that might be considered a summary, which is what the “TL;DR” implied.

Hence my “WTF?” response and subsequent top level reply with the actual text and its source as sent by the DPL.

I note that the issue of “age verification” is an extremely troubling trend and I think that discussion about it needs to be considered and nuanced, neither of which were in evidence.

This is what the DPL actually wrote on the subject:

Recent discussions have started around new age verification legislation that may affect free software operating systems. In particular, the California Digital Age Assurance Act (AB 1043), expected to take effect in 2027, raises questions about whether operating systems and package distribution mechanisms could be required to provide age-related information to applications. In parallel, a recently adopted law in Brazil appears to introduce similar requirements and is already in force, with initial interpretations suggesting it could apply to components such as package management tools. These developments are currently under discussion within Debian and other projects, and SPI has initiated efforts to obtain legal guidance. At this stage, the situation remains unclear, and further analysis is ongoing.

From a non-lawyer perspective, it is not yet clear how such regulations apply to a non-commercial, volunteer-driven project like Debian, which does not sell software and provides it in a highly decentralized way. It seems plausible that obligations, if any, may primarily affect redistributors or commercial entities building products on top of Debian. In such cases, Debian would as usual be open to contributions that help downstreams meet their requirements, while keeping such features optional and respecting the needs of users in other jurisdictions. However, this is an area where proper legal analysis is still required.

Source: https://lists.debian.org/debian-devel-announce/2026/04/msg00001.html

WTF?