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.
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.
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 withbootc
+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 withostree
. 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.
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?
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.
Freedom FTW!
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.