By Default, Signal Doesn't Recall
ferric_carcinization @ ferric_carcinization @lemmy.ml Posts 0Comments 129Joined 4 mo. ago
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?
The Vita has some good games, and it has built-in support for psp & ps1 games, which is not emulation IIRC. It can be a nice portable emulation machine, especially the Vita 1000 model, with the OLED display. The 2000 isn't as nice due to the worse display.
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.
Isn't it more like death by a thousand stabs or something? Each one just seems a bit too deep to just call a "cut".
I doubt that he can either german or read well enough. But he may have quite a few copies of a special picture book version there instead, like with 1984, the handmaid's tale & animal farm.
Isn't 300lb approximately equal to 1 stackoverflow user?
(I'm not USAian, so my conversion may have higher error bars than usual)
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.
If only moonlight could use the USB connection, like vitastick.
Do the triggers from bluetooth controllers work with moonlight? I don't remember if you can normally connect controllers to the vita, but there's this plugin that makes the vita think that it's a pstv, which makes it support multiple gamepads.
I haven't used moonlight on the vita, can you map touch input to L2/R2/L3/R3? The back touch-area would probalby be good for the triggers & L3/R3 aren't used that often, so the touchscreen might work for that.
What's the latency like?
Neither, bat or neovim.
Don't forget:
- Legacy consumption interface (for ancient mouths/hardware)
- Password-protected can contents
- Multiple cans connected in parallel
- Multiple cans connected in series
- Usage with backup cans
- Safe can disposal following current best practices
- Making the can look pretty
Pretty sure that's what they're doing, I'm having a hard time believing that people can be so inept.
Last I heard, concrete is supposed to be real & tangible, unlike the action they're threatening.
I doubt whatever they're using is up to code.
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:Sorry for the arch/tune rant.