Aqler

Preferably one that has a good WINE interface.

IIRC, Zorin OS handles that the best. Furthermore, it's actually a distro that targets beginners (like e.g. Linux Mint does). So, overall, it's a great pick.

Of course, don't just expect that all your Windows software just works on Linux with WINE. Instead, search if they're somehow available on Linux and/or work through WINE. If that's not the case, then ensure that an alternative is available that you're willing to use instead.

Finally, ensure that the distro you choose, actually works great with your hardware.

Consider taking a loot at Linux Mint's documentation. It's probably the best place for information. If there's anything in particular you'd like to ask, then please feel free to ask the community. We're here to help 😊.

Isn’t it?

No-cost RHEL is accessible for individuals or small teams up to 16 devices. RHEL is paid for enterprises and businesses because of its support; which also includes (exclusive) articles and documentation.

You made it seem as if you were regurgitating the common line of misinformation when last year Red Hat changed how access to RHEL's source code worked.

That regurgitated statement is misinformation. Besides that event, which actually didn't make RHEL paid, I'm unaware of Red Hat retroactively changing a formerly free service to cost money instead.

And for distro devs access to the source code is the only thing that matters.

Do you mean the people working on Oracle Linux, AlmaLinux OS and/or Rocky Linux? Or did you actually primarily imply others? If so, could you elaborate?

but I think you are the toxic one here.

😅. Sorry, this is just not very productive. But, I will try to be more careful with the language I use when communicating with you 😉.

You boldly accuse a kinda new Linux user that asks a question in sharing misinformation

If, with your earlier statement, you meant the whole RHEL source code fiasco from last year, then that's plain misinformation. And if you share that, then that's sharing misinformation.

I prefer open conversation in which we can communicate directly. If you're sensitive to that, then I will abstain from doing so when I'm interacting with you.

and being toxic.

At worst, I only implied it. At best, it's a general advice directed towards anyone that happens to read it. To be clear, I didn't intend to attack you. So no need to be offended. Nor should you take it personally.

~~Finally, as this comment of yours clearly shows, you're at least somewhat susceptible to misunderstand the writing of others. Ain't we all to some degree? Though..., (perhaps) some more than others. Regardless, likewise, without trying to offend you or whatsoever, I would like to propose the idea that you might have jumped to conclusions that you didn't have to necessarily.~~

Uhm what? I asked a question bruh.

The bold parts include a false claim; i.e. Red Hat made RHEL paid.. So it's perfectly possible to include a lie, piece of misinformation and/or straight up FUD within a question.

True but they still can find something to hurt everyone. Not like I think it will happen but it is a problem with centralization and a company being behind a big and important product.

I agree with you that Red Hat is indeed way too powerful in this realm. Hence, there will inevitably always be the fear that they might (somehow) misuse their power. So far, they've been mostly benevolent and I hope it will stay that way. There's no fault at being cautious, but this should never lead us towards toxic behavior.

EDIT: Why the downvotes?

Freedom FTW!

Don't spread lies, misinformation and/or FUD.

Btw can RH as the biggest contributor to systemd make it paid like it did with RHEL?

It's not. They've only made it harder for other parties to freely benefit from RHEL's hard work at the expense of RHEL.

For clarity, ~~because the obnoxious ones out there didn't get it,~~ this refers to how Arch, Debian, Fedora and most other distros just default to systemd and hence can (and probably will) make use of run0. While, on the other hand, distros like Alpine, Artix, Devuan, Void and others (including *BSD-systems) will not. For distros with no defaults (e.g. Gentoo), the user gets to decide.

Thank you for your efforts! Thank you for the links! And thank you for being open and genuine! Hopefully Mozilla Firefox will ever improve until even its toughest opponents can't ignore it. I wish ya a great day!

The article is from an old date and got no updates, security is a moving target so it is outdated.

I agree that it's not very up to date. Heck, I even said as such with "I’m aware that it’s a bit outdated. However, would you be able to confidently claim that nothing found within is relevant today?" (Yes, I'm @poki@discuss.online). That's exactly why the bold parts were included. However, instead of answering my question, you just called it outdated to dismiss all of its claims. But, that's not how it works, you should -instead- state if it's relevant or not. I.e. is everything mentioned within solved? Or are some issues still standing?

Btw, if you go about duckduckgoing stuff, I actually do. However, apart from CHEF-KOCH, I couldn't find anything on this matter. Furthermore, I couldn't find anything on CHEF-KOCH's credentials. So, why should I favor their opinion over Madaidan's (that at least works on Kicksecure and Whonix)?

a debunk is not existent, thats why I miss it.

Clear. Thank you for explaining!

I requested such an article of Mozilla devs long ago. There is a damn bugzilla thread, which helps a bit, but it needs developer documentation or something.

Thank you for your effort! I tried finding the bugzilla thread but failed. Would you mind helping out?

Torbrowser needs to be secure. If the browser source cannot be trusted, or if Mozilla can be trusted more, then it makes sense to use it.

Fair. Someone who's actually security sensitive would run it within a disposable qube anyways. And, in that case, security would have already been solved. So, Tor Browser can focus on privacy.

The article is very outdated and possibly not complete.

Source to back this up?

ChromeOS uses Linux so you can assume it is very secure there.

Wut? I didn't get this. Could you elaborate?

I miss a debunk on the exact points by firefox devs.

Does such a debunk even exist? Or do you hope it will be made at some point? Furthermore, do you imply that it deserves a debunk; hence its content is false? If so, based on what?

But people everywhere told me madaidans article is not correct.

Have they offered you a similarly well-backed and sourced refutation/article? Or did you simply dismiss Madaidan's cited claims without anything to back it up? Do you think this is an academic/logical/sensible approach just because some randos said it's incorrect?

Torbrowser also still doesnt use Chromium for various reasons. And that is the most security critical browser there is.

Tor Browser's commitment to Firefox is probably more related to sunk cost fallacy, FOSS and trust than it's to Firefox' merits on security.

It’d be nice to see the whole list.

Close enough.

Yo OP, this is me @poki@discuss.online from another account. I had intended to leave the Lemmyverse for a while, but had to come back earlier than intended when I read your comment 😅.

So, without further a due.

Okay, I appreciate the links. I've had a chance to go over both, and I think I get the gist:

Thank you for your time!

• rpm-ostree is a work in progress, and it will be depreciated and replaced with bootc + dnf

What do you mean with "work in progress"? You've been using it relatively often in this thread (and IIRC even in others) when talking about Fedora Atomic and/or uBlue and its technologies. Like, do you consider dnf to be work in progress because dnf5 is around the corner?

I don't recall any mention of deprecating rpm-ostree, though I might be wrong. But, yeah; it will definitely lose focus in favor of bootc + dnf.

For example, I have a VPN client that is installed via a .run script, so it doesn't work with ostree. If I wanted to apply this software to my system, I'd have to create a bootable container, then rebase to that.

I'm not actually sure if it works out just like that as of right now. Creating your own image or bootable container is definitely a powerful tool that can help bypass some imposed limits; like e.g. populating files in /usr or baking in (current) rpm-ostree actions -some of which actually wouldn't work otherwise (as of right now)- directly into the image. Finally, it allows one to move from an imperative to a declarative system. However, I'm not aware if it enables one to bake-in the installation of .run files. My only experience with .run files myself was with Davinci Resolve, but that's notoriously difficult to install regardless. Thankfully, it's a popular piece of software and thus avenues have been created by which one could install it on Fedora Atomic and related projects.

So, in short, I don't see how creating your own bootable container would help you to bypass this.

But my goal isn't to create a new image, just to apply transient packages to the base Bazzite image

Exactly.

If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project?

If you achieve it through legit means (i.e. uBlue's own documentation on this or through a sister project called BlueBuild), then no.

Would I have to manually build a new container and rebase each time I wanted to check for updates?

By either of the two earlier mentioned means, the building is done automatically (on a daily basis) by GitHub. Furthermore, when you update, you just receive the latest image from your own GitHub repository in which your own image resides. Updates continue to be done automatically in the background, so you won't even notice. Finally, if it wasn't clear yet, you only have to rebase once.

I feel like I'm on the cusp of seeing the big picture, but I'm not quite getting it, and maybe that's because I haven't worked at all with services like Podman and Docker.

That's fine. Please feel free to inquire if you so desire!

Alright, having said all of that, let's get to the crux!

So, did you try the following methods when installing the .run file? If so, how did it go?

• Simply double press or right-click then install (of course, after applying chmod +x).
• Within a terminal with ./<name of .run file>.run
• Within a terminal with ./<name of .run file>.run --appimage-extract and then interacting with the AppImage.

If all of the above have absolutely failed, I only see three ways going forward:

• Creating your own Flatpak 😅.
• (OR) Taking this to COPR 😅.
• (OR) Succumb to Toolbx/Distrobox 😅. Like have you tried running the .run file within Toolbx/Distrobox? If so, how did it go?

EDIT: 😅. I had hoped you'd return with a reply soon~ish. But alas... Uhmm..., I'll be off for a couple of days and will return only next week. Just wanted to let you know*. FYI, I'll probs return with (yet) another account.