No, the links about Mozilla show how corrupt their directives are. Peole are so eager to scrutiny competing browsers/company and their forgive every shit Mozilla or their board do.
By the way, who cares about Brave’s CEO? I don’t agree with his political views, but for me their browser it’s the best out there at the moment and the company itself isn’t politically active at all.
Did you ask any other Mozilla employee what their political views are, by the way? How can you be sure that all of them are “good persons”? Do you buy your stuff on Amazon, by any chance, knowing how evil thy are? Are you sure that your grocery store’s owner/your mechanic/your doctor/etc. isn’t an homophobe or a bad person? Please, be coherent and go and ask all the people you make deals with what their political views are.
I’m not upset. I may have been unclear. I just find funny that people in the (F)OSS/Linux community (which I’m clearly part of) are very prone to scrutinize Brave and other companies, while they pretend not to see what’s going on at Mozilla, which seems to always get a free pass.
I used to like Firefox (been using is since 2002ish…). But after a lot feature removals and, last but not least, the ugly UI redesign (despite the negative feedback in the nightly/beta phase) I just jumped ship. I’m not going to waste my time fixing it with CSSs, unfucking what Mozilla did wrong. Anyway, Brave is just faster, it performs better and has a no-shit UI.
This, plus the disappointment I’ve had with Mozilla, gives me exactly 0 reason to go back.
You might want to think twice before using unique, niche distros like GoboLinux, Alpine, or NixOS. PuppyLinux doesn’t look like a proper distro, more like the equivalent of EndeavourOS or Artix. Since you’re using Linux for the first time, why not use Linux Mint, Ubuntu or Fedora?
No not really. Gnome for me is about 2.5 gigs of Ram, XFCE 700 megabytes and the CPU load also is way lower. XFCE can be heavy or light depending on how you configure it
Heck ya to Fedora, glad to see it recommended for a first time user. It’s not much more difficult than Mint, but you can also get into the weeds instead of having to find a new distro after Mint. Mint basically has permanent training wheels, while with Fedora you can pop em off whenever it’s convient.
Edit: Fedora is also a more up to date Alpine and it’s not directly controlled by Red Hat.
I’ve updated my post with “I heard conflicting stuff over the Internet and now I’m scared” and an introduction. Those are legitimate questions for people who, like me, do a lot of research before committing to something. Some of the discussions here and in other communities might scare people off, as they might feel they’ve done the “wrong” choice or are afraid to do the “wrong” choice.
This is not a very good question. If you are concerned about security you need to think about what specifically you are trying to keep safe? Here are some examples of different security scenarios:
Do you want your computer to be safe when it is stolen?
Do you want to run lots of native apps from untrusted sources?
Do you want it to be used by many people and you don’t want them to be able to steal each others secrets?
Each one of those questions has different means of securing the computer. With question 1, it is not so much a matter of desktop environment, rather it has more to do with using full-disk encryption, setting a boot password in UEFI, and always having your lock screen enabled.
With question 2, this is a much more difficult task and you would probably be better off running apps in a VM, or carefully crafting your “Security Enhanced” Linux profile – or not using Linux at all, but using FreeBSD which allows you to run apps in jails.
With question 3, be more careful with filesystem permissions and access control lists, setup your sudoers file properly, and use a desktop environment with better security auditing like Gnome or KDE Plasma.
Never heard of these jails, like bubblejail? Its available on Linux too.
I know the question is vague and highly dependend on Threat model etc. Pre-enabled services, distribution adding stuff to it, SELinux confined user (not working with Plasma at all), xwayland support for keylogging chosen keys (Plasma).
Also GTK is widely used for rust apps, this doesnt exist on Plasma at all, not a problem though as Plasma is not Gnome and simply supports GTK normally.
I don’t think the DE itself matters, but I can recommend using an immutable OS (makes it harder to install malware) and installing flatpak apps only. You can also use software like flatseal to further lock down permissions
A mostly read only filesystem built from a limited number of packages, with other files being in a fixed number of locations mean it is harder for malware to hide.
You can achieve the exact same thing with a normal distro if you mount /var and /boot separately of /. And if you get a root exploit it’s just as harmful on either approach.
“Immutable” systems are meant for maintainer comfort not for user security.
No, you can’t : in an immutable distro I can reasonably trace almost any file in the filesystem back to the package that created it, and know with a reasonable degree of certainty that the installed version of said file has not been tampered with. That isn’t possible an a normal distro.
Sure it is, has been for decades. You can use a read-only root partition, there are many tools to ensure the integrity of everything on it, and tracing files back to their package is a very old feature.
Ublue is like rpmfusion but for image-based. Its the addition to fedora, with packages they can’t ship. They replace all the libav* with complete ffmpeg which is pretty great as its a great tool and Firefox works ootb.
For example they have -nvidia images for every image, which is the best way to use the proprietary NVIDIA drivers as you can roll back and a broken update simply wont ship to you.
They also have modded kernel images for Razer, Surface and a special Framework image.
Another cool project basing off their “starting point” toolkit to create custom images, is secureblue, a security-optimized Version including
hardened kernel and hardened_malloc
updated Chromium, maybe soon Brave
soon a hardened Chromium (currently as COPR “vanadium”) like GrapheneOS
hardened services, firewall
removed unused kernel modules
It is very security focused though, so no Firefox, no Flatpak as its currently broken, Podman (distrobox, toolbox) is currently not working and its unclear if that is actually necessary, …
Bluefin is their fancy distro with lots of Tools, a custom Desktop, integrated Developer packages and more.
I Arched for like 4 years or so, and now I NixOS. Got somewhat tired of modifying configs in 100500 places and eventually forgetting what exactly I’ve changed 😅
Nevertheless, I still think arch is great, and, as a side note, it does provide a good understanding of Linux on the upper-low level (not like LFS or even gentoo, but still very much viable).
About 3, idk what’s going on with my system, but sometimes after a big yay update, the kde login fails (something about the plasma environment failing to boot or idk I have not debugged it correctly yet), then after a reboot systemd-boot fails to load it and the efi entry dissapears. I’m forced to arch-chroot and reinstall the bootctl. After doing so, sometimes I have to do it again and other times it logs correctly.
Again, not debugged it correctly but it’s not like I did any kind of weird change to any config, just installed some flatpaks, some steam games, and lutris for League, which in the end is basically wine, and a yay update provoking this behaviour is pretty bad.
I’ve had this happen. I never did figure it out, personally. I distro hopped a bit and eventually ended up back on Arch and it didn’t happen again, so I guess it was a bugged install?
Yeah, I’ve taken the routine of logging into tty3 before kde to pipe the journal tal output into a file to debug only the error if it happens. Yeah I know I can fine tune then output to get only the last execution and so on and I have done it, but it was not that clear and this happened after a work day and I wanted to fuck off and chill so the next time it happens I’ll be more through.
I’ve personally encountered mentioned behavior with kde on both arch and kde neon, so I’m inclined to think it’s their f-up. As for sd-boot, I’m not sure: I’ve used it on arch for a short while only, and then just ditched bootloaders altogether for efistub
Yeah, it’s not that big of a deal for me, but damn if this would not be a deal breaker for a regular user, and I ensure you that a regular user would install league and steam or something of the sort xD
Like, I’m a software engineer and arch-chrooting once in a while to launch some commands is nbd, but a regular office worker that hardly runs some commands once in a while in terminals, copied from (safe) random places? Yeah good luck I bet they would just either distro hop or format and reinstall windows.
I could say inability to edit a config file is worth reevaluating of what is a failed piece of garbage here… But it won’t be fair. If you don’t want to deal with configs, go ahead and use chromeos or something :P
I’ve kind of come and gone full circle on this one. It fits in the same space as the terminal, way more useful when you know what you want.
Some config files are a lot easier to get the behavior I want, but editing a poorly formatted (or in some some cases pointlessly complicated) config is a quick nope out.
This kind of integration testing is best left up to the individual distros. Same as the integration (as in: packaging) itself.
Distros don’t want your binary package, they want your source code, build instructions and a build system that won’t make them cry. Some distros even explicitly disallow re-packaging external binary distributions.
As a distro maintainer, I appreciate your wish to do QA on all the distros but that’s just too much work. You focus on making your software better, we focus on making it work with the rest of the software ecosystem.
Providing a package for one or two distros (i.e. your favourite one) is good practice to ensure your software can be reasonably packaged but it’s not the primary way your users should receive your package in the traditional Linux distro model.
Additionally, you might want to package your software for one of the cross-distro package managers such as Flatpak, AppImage, Snap, Nix, Guix, distri or homebrew. This can serve distro maintainers as a point of reference; showing how it is intended to work so they can compare their packaging effort. If there’s some bug present in the distro package but not the cross-distro package, that’s a good sign the issue lies in the distro packaging for example.
Again, don’t put much time in this. Focus on your app.
You could do some automated/scripted installation VM-image builder thingy and release that. Would probably also save some manual work for you. (bash script fetching install image & run qemu, autounattend.xml, etc. all nicely released on github.) And it’d be auditable.
In what kind of world is a missing feature or a broken feautre due to incomplete migration to a new ecosystem, a reason to boycott that new ecosystem?? Those are simply not valid arguments to me.
They are obviously valid arguments to say, hey, this work is not completed, is not mature enough etc. So, therefore, you stay with previous ecosystem. But to boycott it because of that? That does not make sense to me at all.
I’m training a code and language model to write Linux kernel code and provide snarky comments, of course all based on Linus’s extensive commit history.
Does this mean I can stop setting MOZ_ENABLE_WAYLAND?
Or is it just enabling the compilation of Wayland sections (which I thought happened a while ago?)
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.