A communication protocol used in microchips, small modules & embedded devices that uses 2 wires. Think something like USB, but dead simple.

If they have it on a hat, in real life, then it’s linked to their real identity. They might just want to keep it separate from Lemmy.

I’d still say that it’s better.

With “delete after reading”, the recipient has to delete the email manually, so the email is kept if no action is taken. But with the methods listed in the post, the content disappears unless action is taken to save it in some form.

Yes, the content can be easily saved & you should never trust that no clients are malicious, but people are forgetful & lazy. If you need the recipient to perform an action each time, there’s a good chance that they won’t.

I still understand your point. You can’t get around the analog gap unless you transmit everything directly ro the brain. And even if you could do that, with text, it’s easy to reproduce from memory.

As you said, it’s FOSS, so why would its country of origin cause ethical problems?

How would other types of taxes, like in you example, gift tax, be handled?

It’s being built up starting with the foundations. As I understand it, most of the work so far has been adding support for Rust-written GPU drivers into the kernel. I’d guess that they’re going to look at Nvidia’s open kernel drivers to avoid reverse-engineering everything, but it seems like they’re not just copying it. Unlike both official Nvidia drivers, NOVA will talk with the NVK Vulkan driver in Mesa, not Nvidia’s closed userspace drivers. This will likely make it more compatible with parts of the Linux ecosystem that Nvidia has historically had issues with, like Wayland. Even if they don’t look at the official open driver, NOVA will be a lot simpler than Nouveau, as it only supports GPUs with a GSP, to which Nvidia has moved a lot of the magic that used to be in the kernel driver.

I’d like to take it more seriously, but I don’t really feel confident about being able to finish it.

Thanks. I’m still not completely serious about it, but I’ve given some thought to how the project would be laid out. I have some code, but not that much, under a few thousand loc. I wonder if it would be accepted into the extra repository. In Arch, the AUR is completely unofficial. The wiki documents many things related to it, but otherwise, the tooling kind of pretends that it doesn’t exist & it’s completely “unsupported” officially. The rules of the extra repository specify that pacman wrappers aren’t allowed, but doesn’t mention the AUR, IIRC. This wouldn’t be a wrapper, but would support the AUR. I wonder how it would be handled, or would AUR support be patched out?

As you use Cachy, you probably already knew, but Arch compiles for x86_64_v1 (all 64-bit x86 CPUs). While some packages (glibc, I think & codecs, for example) use compiler magic & assembly to use vector instructions when available, most packages compiled for Arch cannot make use of them. Some programs feel much faster when compiling them myself.

I wonder if clear Linux (Intel’s distro) would have any noticeable improvement i performance? I think that Cachy might use a few of their patches.
Note: I’m very much not an Intel shill. I wouldn’t want to actually use it, just interested in the performance.

Do you have a reason not to use systemd? Yes, it might be slower to boot than other inits, but the units are so nice. (Not trying to convert you, just curious about why you seem to avoid it)

Installing Gentoo is fun! It can be done without install media. Just extract the stage3 archive to a partition, mount system directories correctly & just chroot in! Now you can have the handbook open in a browser next to the chroot. Though, I haven’t finished the install yet. I’ve had it in a half-done state for a while.

I can program in C++ & don’t have much against it, I just love Rust. Also, for security, Rust is just better. Everyone makes misrakes, so why not make the compiler check your work? Especially when it comes to concurrency. With Rust, never I have to about worry race conditions & data races again. (Kind-of trying to convert you, but Rust isn’t perfect, or ready for everything yet, sadly)

With the compilation, I was wondering how good the support for partially compiling dependencies was. For example:
packages: foo, bar, baz
bar depends on foo
baz depends on bar

What happens if I compile bar myself?
If foo updates, I may need to rebuild bar, I need to do that manually on Arch.
What about baz? It depends. It might work with my locally compiled bar, or it might not. Either way, pacman doesn’t care.

I’ve been toying around with a new Rust-written™®© package manager that would support that. It’s still very early in development & I have a few other personal projects in the way, too.
A few thoughts I have about it:

• The “database” format used by pacman is simply insufficient. (I mean the local db, the sync db is fine, IIRC)
• It should be possible to cascade testing repo installs. (mark the extra repo compatible with extra-testing and the same with core & core-testing, with the non-testing repos having higher priority. Install extra-testing/bar, the dependencies, like foo are pulled from the testing repos, if available. This should cascade. Now, you can selectively use packages from testing without breaking anything.)
• Add new repo formats, like repo-src (official PKGBUILDs) & AUR (stored in a different way from official build scripts & different trust levels, require reviewing build script) that build when installing & cascade similiarly to the previous point.
• Allow using the legacy (current) DB format, but without support for the fancy new features
• Allow tagging paclages with extra metadata, for example to prevent packages from being rebuild (or built at all) unnecessarily.
• It should be compatible with pacman’s options & behaviour. Some tools also need to be redone, but I have already started on this.
• The Arch formats (.pkg.tar*, PKGBUILD, db) are not designed for this, at all. I think that packages can be optionally manually tagged, but this should err on the side of rebuilds, and I’d also like to redesignd both the package format & build scripts/tooling. Like I said, the db is just insufficient & needs to go.

This is still very early in development, but I’d like to get it done at sone point.

It would combine the worst parts of both Arch & Gentoo (compilation, no use flags, complex dependency solving) in a gradual way (build the fish shell [yes, I use fish. I used to use zsh with plugins, but fish just did everything, but better & faster] today, next week build ffmpeg & dependents, next month, build libc & watch most of the system get built).
It would be nice to support parallel building of unrelated packages, as not everything scales well.

Dependency cycles/conflicts/versions are going to be nightmarish to solve for repo packages, then it also needs to work for AUR.

I’m not sure if I’ll ever get the package manager to a usable state, though.

How much of a difference do you notice in practice? Do you think you could see similiar gains by compiling, for example, Wine & some libraries with -march=native & maybe -O3?

Note:
-march=native does imply -mtune=native, at least on gcc, unless you specify another tune yourself. Some people assume that it isn’t the case, but it’s stated in the man page:

When -march=native is given and no other -mcpu or -mtune is given then GCC will pick the host CPU as the CPU to tune for as well as select the architecture features from. That is, -march=native is treated as -mcpu=native.

Sorry for the arch/tune rant.

I though Void also supported systemd. Though, it would take away some advantages of Void, as it doesn’t support musl IIRC.

I’ve heard Void fans singing praises for its package manager. It’s one of the few distros where its users are really passionate about that, along with Arch, Gentoo & Alpine (IIRC). How good is the support for compiling certain repo packages yourself?

Does musl or a lack of systemd cause many problems?

Does Void have good support for ZFS? I run a small server at home & like to experiment. It’s currently running Debian, but I’m crazy enough to consider dual (or triple when I finally decide to put BSD on it) booting on a server.

All in all, sounds like it’s a lot more interesting than I thought. I’ll definitely give it a try, if not on a server, at least a desktop. Though, I still think I’ll switch to Gentoo for my daily driver.

Hope I didn’t bore ya.

Not at all! I’m a huge nerd, so I love learning about things like this. Thank you for the detailed propaganda comment!

P.S.
Do you happen to know if support for Rust (the best language at the time of writing) C standard libraries like relibc or c-gull is planned?

Edit: Fixed striketrough, I think.
Second edit: It works now. Why does each Markdown flavor have slightly different, incompatible syntax?

If your first priority is speed, would clear Linux be better? Though I can see the appeal in a more performant Arch.

Edit:

almost zero problems

What problems did you encounter? Would they also have affected Arch?

What’re the benefits of using Void over something like Arch? I’ve been interested in trying it out for a while, but haven’t really gotten around to it yet.

I didn’t mean it as recommending arch or gentoo to new Linux users.

How’s CachyOS been for you? I’ve compiled a few repo packages myself & am in the process of testing Gentoo.

Does it support whatever the thing 8 had is called, or just 8.1?

This is brilliant, but I like this & this.

If the grahical app store has asked for a password when updating, like on normal Fedora (what Nobara is based on), all programs installed with sudo dnf install <program(s)> are also updated. A update to native packages can also be ran with sudo dnf upgrade. Flatpaks can be updated from the app store or with flatpak update. (no sudo, as that just raises the privileges for the next command, like dnf)

Linux has become more user-friendly, but due to the many, many alternatives for pretty much everything, while some programs integrate well with each other, this is not the case for everything, sadly.

Sorry, I don’t know about the scroll issue. The scroll wheel on a mouse or dragging 2 fingers on a touchpad should still work.

TL;DR:
If you are prompted for a password when updating, everything’s fine. This should be the case for you, as Nobara is based on Fedora, which supports this. Otherwise, you have to run sudo dnf upgrade or the equivalent for your distributions’s package manager.

There are a few common ways to distribute software for Linux, which I’ll try to explain while leaving out the more complicated parts:

• Appimage: The program & all of its dependencies are put into a special filesystem image file. (think special .iso or .zipfile) Works on any distro & does not require administrator privileges, but has a large file size. This is somewhat close to an .exe file.
• Statically compiled binary: The program is compiled in such a way, that the program file contains all dependencies. Unlike an appimage, the program file is not an archive, so it does not contain any files within itself. So, all the libraries (small program parts) are placed in a large program instead of being zipped up. Can usually be run without proper installation, like appimage & .exe files. This is also a bit like an .exe file.
• Package: The program & asset files are archived, usually compressed .tar archives, (linux equivalent of .zip/.7z/.rar) which are extracted (unzipped) during installation. Sometimes a small included script is run during install/update/removal. Usually, architecture (x86, ARM, risc-V, etc.) & dependency information is also included. Common package formats include: .deb (Debian based distributions like Ubuntu, Mint, etc.), .rpm (RHEL, OpenSUSE, Fedora & derivatives). These packages are usually somewhat distribution & version specific. For example, you might be able to install a Debian .deb on Ubuntu, but if you have incorrect versions of dependencies, it either cannot be installed (you get a warning/error) or the program won’t work correctly or at all. Often, package managers like apt, dnf & pacman get these for you, so you don’t need to think of them as files, but you can also install package files like .deb or .rpm.
• Flatpak: This one’s a bit complicated. Something of a mix of all of the above. Works anywhere, but you need to have the application flatpak installed to run programs installed this way. Flatpak programs are installed for each user, meaning that no administrator privileges are required. They also support sandboxing, meaning that a program only gets access to files & functionalities it needs, like on smartphones, but that is optional and not all programs make use of it.
• Snap: Also complicated. For an average user, mostly like flatpak. Only guaranteed to work on Ubuntu, but might work elsewhere.

So, how you installed a program may change how it works a bit. For example, the versions of dependencies you have can change the program’s behaviour. Also, some configuration can often be done when compiling a program, like specifying whether to use Qt or GTK for drawing windows, or disabling bluetooth support. Different packagers (people who make appimages, flatpaks and/or paclage files) may choose different options here.

Sometimes flatpak programs may use old versions of dependencies. Also, I’m not sure if this is the case with Firefox, but Chromium’s (Google chrome & derivatives, like Brave) sandboxing (security things) conflict with flatpak’s own, so some of Chromium’s security features are disabled in favor of using flatpak’s own ones.

If the flatpak version of Firefox caused issues, I’d recommend trying the native version (package manager) instead of one downloaded from the internet. You can either do this from the graphical app store by selecting something like native, dnf or rpm instead of flatpak, or the native package manager with sudo dnf install firefox for Nobara, I think. Unlike flatpaks, native programs are installed for all users & require you to type your password during installation.

If you use an appimage or manually downloaded .rpm file, you need to take care of updates manually, by downloading a newer version like you did during installation. I would strongly advise against this, unless necessary & you know exactly what you’re doing.

I think this answered your question, but feel free to ask if anything was unclear or you have other questions. I’m a programmer & I’ve used Linux for a while, so I should be able to answer most questions.

Edit:
Sorry for the wall of text. I hope it wasn’t too jargony.

TL;DR:
The wall of text has context & things that might br good to keep in mind, but I’d recommend removing the flatpak version & the Linux .exe equivalent you’re using, then trying sudo dnf install firefox.

Edit 2:
Nvidia can sometimes cause problems on Linux, but if a different version of Firefox worked, it is very likely not the case here. Sometimes switching from Wayland to X11 or vice versa might help a bit, at least until the next driver update. Otherwise, I’d recommend Wayland, as it’s more secure, actively developed, has fancy features X11 lacks & can be a bit more efficient.

Glad you found a way around the problem!

Not sure if I’ll be of help, but I can try. It would help to get some more information.

You’re using the Breeze cursor theme, so I’ll assume you’re using KDE Plasma. The cursor looks like it’s from Breeze 5, not 6, are you on the old Plasma 5? If you are on Plasma, you can go to settings and go to “System information” (near the bottom) or something like that. (IIRC, It was a long time ago since I last used it)

Are you using an Intel, AMD or Nvidia GPU?

Are you on X11 or Wayland? (They’re different ways to handle windows, X11 is very old, but may work better in some cases. Wayland is newer, more secure, has some features that X11 lacks, like HDR & is usually better)

You can check the windowing system (X11/Wayland) by opening the terminal (the application Konsole on Plasma) and typing echo $WAYLAND_DISPLAY and pressing enter. If you only get an empty line, you’re on X11, otherwise you’re on Wayland.

If you’re on Wayland, go to the URL about:support in Firefox. Then search (ctrl+f) for Window Protocol. This should be Wayland, otherwise it’s falling back to a X11 compatibility layer called Xwayland.