• 0 Posts
  • 83 Comments
Joined 1 year ago
cake
Cake day: July 18th, 2023

help-circle
  • Just a thought, but since someone else in the thread said you can stream to Chromecast via VLC, you can desktop capture natively in VLC and stream that to your Chromecast. I can’t remember if the native capture can do sound or not, but if not, you can instead use OBS virtual cam (you’ll need v4l2loopback for the virtual cam to show up), and open that as a capture device in VLC. You should be able to attach an audio source to that as well. While I haven’t personally tested it with audio, I have used OBS virtual cam with VLC before, and it worked flawlessly for me. If you can’t find a more elegant solution, then it’s worth a shot to try and see if it works


  • While I haven’t personally tried it, I’ve heard people have issues with cooling when using the M.2 hat, especially when using their Pi for intensive applications (like hosting a Minecraft server). I’d honestly recommend just getting a 2.5" USB drive enclosure and an SSD. Costs about the same amount of money without the drawback of poor cooling. You can use it with any case, since it just connects via USB. I have been running my Pi this way for years (in fact I have never used an SD card in it).




  • Matrix leaks tons of metadata, and its encryption lacks perfect forward secrecy. Additionally, it requires an email to sign up, and there are accounts with unique identifiers.

    Simplex does not have any accounts or identifiers, everything is stored entirely locally. Additionally, it is based on the double ratchet Signal protocol, with improvements made for post-quantum encryption. It does not require anything to sign up, as there are no accounts. Metadata is not leaked as it is with Matrix, as everything is encrypted or obscured. Messages are padded to 16KB, the sender/receiver is not attached to the message, and there are fake messages being sent to obscure the identity and frequency of contact of those you are talking to even under monitoring of your network. Additionally, for anonymity, SimpleX is allowing for repudiation so that you cannot prove that a specific person sent specific messages, allowing doubt if messages were to be use in a court case, for instance. It is the trend (especially from a security perspective) to implement nonrepudiation, but the SimpleX team decided to remove it to protect users (after years of it being present in SimpleX chat). This is a protection intended for journalists, but it extends to many other cases as well.

    Matrix is a nice toy, but SimpleX chat is built for anonymity above all else, and it does that job far better than Matrix ever has or will.


  • Do you not consider Alpine Linux to fall into the general category of “Linux”, then? It lacks GNU user space utilities, though there is never a world where I would not consider it a “Linux” operating system. You seem to be overgeneralizing here and making assumptions about OP’s intentions that aren’t based in fact. I don’t see the point in drawing meaningless lines, here. What you’re referring to (as described by the GNU project) is GNU/Linux, not “Linux” by itself. The two are often but not always used interchangeably, and treating them as exactly the same leads to major outliers, like Alpine. I’ve heard plenty of people use the term “Linux” in practice to describe software running on embedded devices that don’t contain GNU utilities, so this isn’t exclusive to Alpine. In fact, the only real exception that I see consistently to operating systems that run the Linux kernel is Android, so it makes much more sense to formulate a description of the generic term “Linux” as simply having an exception for Android, though I’d argue that the only reasons that Android isn’t viewed as “Linux” is because it is a mobile operating system, it is developed with the sole intention of including non-free, proprietary software (AOSP by itself isn’t meant to be the full operating system on any device, but rather a framework), and the fact that the structure of the filesystem and the way apps are run differ completely from the ways of traditional “Linux”. It seems to be an exception purely by the fact that it operates in fundamentally different ways than other “Linux” operating systems.


  • While the other user explained what polkit is from a low level, I think it’s more practical to give you a high level explanation. Polkit is responsible for the dialog box that pops up when you try to open an app like GParted that requires root permissions (it edits partitions, a rootful task). What the user you replied to is saying is that you never want to run an app as root unless it prompts you for it (like with polkit prompts), or you know in great detail what you are doing. Running random things as root can break your system and the app you’re running. Most apps you will be using are not intended to be run as root under any circumstance, and at the very least will likely experience issues because of it (UI issues, data issues because the root home directory is not your home directory, configuration/setting changes, improper scaling, etc). Unless you know for a fact that something has to be run as root (like updating packages with your package manager) or you are specifically prompted when trying to do something, you absolutely do not want to be running things as root.

    Just to further explain, even if an app isn’t started as root, it can request that permission as needed. For instance, Nautilus allows you to navigate through the root directory, and will prompt you for a password through polkit if you are trying to access something your user does not have permission to read (of course assuming your user has sudo privileges, but that’s beside the point). Unlike Windows, there is no practical use for a “run as root” option, because apps have the ability to request root access when it is necessary, and only when it is necessary. In addition to that, polkit limits the root access that an app is given to the specific actions for which it is requested (so an app can’t use root privileges to run unauthorized commands). The exception to that is when you start dealing with the terminal, but that falls into the category of “you better know what you’re doing and why”.

    The short answer as to why this isn’t a thing in Linux is that the authentication and permission system functions nothing like Windows. In Linux, a “run as root” button is not a solution, it is a problem. The only reason that run as administrator exists in Windows is because sometimes the solution to a problem in Windows is to run an app as admin. That is not the case for Linux, and never will be.

    There are many ideological differences between Windows and Linux. You’ll find many discussions here about how it is often not a good idea to try to do something the “Windows way” on Linux, because those ideologies and the software principles are incompatible. Part of learning how wonderful Linux is involves unlearning all of the horrible habits and ideological differences that Microsoft forces onto Windows users. This is one of those things that has to be unlearned, because full root privilege is not something that a regular app should ever ask for or even want in Linux. Root privilege is provided on a case-by-case basis from polkit with GUI apps; only when needed.


  • “Nani” is Japanese (in Romanji form) for “what”, and in internet culture has become a common phrase of exclamation when someone is confused. It comes from the popularization of anime in American culture, but also in internet culture as a whole. In this context, it is equivalent to asking “What?” or “Huh?”. The user you replied to likely does not know what Nala is and was expressing their confusion in their comment. It’s doubtful they were replying to your comment about an apt frontend with a Python array library that hasn’t been updated in 7 years.


  • I’d like to clarify that I didn’t intend to portray any anger in my comment, I’m sorry if it came across that way. Text is notoriously difficult to convey emotion and intention through without purposefully writing to convey it.

    With that said, I am a bit confused. I was not aware that Ansible had the ability to seamlessly roll back updates like an immutable distro, this could certainly influence my opinion. I don’t have any personal experience with Ansible myself, so I suppose I’d have to take your word for it since a quick search online didn’t provide any results. That would be very useful, indeed.

    As I have little experience with large scale deployment, I am unfamiliar with management software that could assist in managing large groups of computers. Would it be possible to use Ansible or some other sort of large scale management software in conjunction with an immutable distro? It seems like the management aspect of Ansible is quite useful and shouldn’t be distro-dependent, so I’m unsure why it would be limited to mutable distros. I feel like that could perhaps get the best of both worlds, as it would allow for consistent deployment of atomic distros that have the ability to be automatically rolled back in the event of a bad update, even if they were to be otherwise rendered unbootable (since one of the selling points of immutable distros is that it’s as simple as an arrow key down and an enter key press while booting to roll back to a bootable OS). Update rollbacks are also as simple as a single command with atomic distros. You don’t have to find a backup to restore from, as the base image is basically organized with version control software (think Git or Subversion, where each update is like a commit/pull request). You can roll back any changes individually or as a group (you can roll back to the exact image you were at during the last successful boot, for instance).

    Immutable distros also have plenty of potential for globally shared applications through simple package overlays. The documentation on installing packages through rpm-ostree is fairly competent last I checked, and would be what you’re looking for with globally installed apps like LibreOffice or Firefox. It just uses the normal Fedora repos for those packages. The actual install commands aren’t different from any other package manager, at least in the sense that all package managers have slightly different syntax, but they have a similar base structure of being able to install/remove/update packages. The backend is unique, yes, but the presentation to the end user isn’t far off from any other package manager. Of course, that comes with the caveat that you have to reboot after installing something through rpm-ostree, because the base image cannot be edited while booted in normal operation. User-specific apps can naturally be Flatpaks, as you wouldn’t want users installing system packages anyway (if you even allowed installation permission, that is).

    You’re certainly correct that traditional desktops have more documentation, and I suppose that since it is a change to the norm, it may be more work for someone experienced with mutable distros to learn how to manage immutable distros. I don’t feel as if that is an issue OP is currently considering, though. They don’t seem to have a whole lot of experience with large scale management of Linux desktops, anyway. Either option could present issues if mismanaged, but if all you need to do to fix something is to roll back a change you made, I feel like that makes immutable distros a little easier to fix (at least when the issue is caused by the user/admin).

    Also, I am unsure where uBlue claims to be in beta. I checked their site, and I didn’t see anything about their products being solely beta packages. Yes, there are beta packages available (for instance, for Fedora 40 which is still in Beta as it hasn’t released yet), but that can be said for practically any software. You can install nightly/beta builds for most packages if you so desire. If there’s somewhere on the uBlue website that confirms your point, please feel free to provide it. I don’t know a whole lot about uBlue, so I would genuinely be interested in knowing. I just know they’re based off the Fedora Atomic desktops with some extra configuration thrown in, and the information readily available on their website.

    If you really wanted consistency with ease of deployment, NixOS is also an option. It just takes time to learn how to use its configs, and I believe the wiki is currently down pending a redesign (or so I heard from another post).

    I suppose I should clarify that I used Fedora Silverblue for about a year as a test drive, and when I got a new computer I installed basic Fedora Workstation back on it. Immutable distros are particularly difficult for me to use because I do a lot of low level changes that would require a lot of complicated overlays, but I’m not the average user. I’ll give Fedora Atomic KDE a shot when Fedora 40 releases, but I’ve always imagined that the ideal scenario for atomic distros is in applications prone to breakage (like school labs where students might mess around doing something that causes issues accidentally), and situations where you want to have large scale management of computers and ensure they all behave exactly the same (though I suppose that’s the draw of Ansible as well). Atomic distros’ main selling point is fixing breakage and remaining stable and reliable (with failsafes you can fall back on when necessary).

    I suppose I don’t have the experience to really conclude whether or not the benefits outweigh any potential costs, though. I am mostly unaware of how large scale management software works, so maybe there would be a lot of disadvantages I don’t immediately see, or perhaps the advantages themselves aren’t as great as they seem in my head. I chimed in because I felt like the Fedora Atomic distros were being misrepresented. For instance, they aren’t in beta, and while they lack the testing of something like Debian, as the community grows, so does the testing userbase. I think that they are an interesting option with distinct benefits, but that of course doesn’t mean that they are the best option.


  • Fedora Silverblue was released alongside Fedora 30, which was 5 years ago; it is not “untested”, in fact it is quite extensively tested by its userbase. It also is not in beta as you claimed previously, its release with Fedora 30 was its full release, after the betas with Fedora 29. Atomic desktops have been around for longer than that, however. They are far more tested and reliable than you seem to be giving them credit for. In fact, they are far more stable and far more resilient because you can simply roll back changes when you boot. A few previous versions of the entire operating system are available to boot from in GRUB, and it’s as simple as booting into a previous version if a new one has issues. It’s actually the perfect use case for a school computer lab, because each install is perfectly consistent, can be managed and fixed easily if anything were to break (if that were the case then the OS would have broken in non-atomic versions anyway), and nothing the user does will affect the base image of the system. The base image doesn’t change unless it is updated. You can overlay things overtop of the base filesystem, but the base filesystem stays the same, so those overlays can be easily reverted.


  • It’s been a few years since my last manual install of Fedora (I’ve just been upgrading it), but I got Fedora Server to install just fine. I did it one of two ways (again, I can’t remember which): I either used the USB boot option to install to an SSD I attach via USB, or I booted the liveUSB on my laptop and installed to the USB SSD. In any case, Fedora has worked flawlessly for me for a few years on Pi now, so I would strongly recommend it.

    Just as an aside, I highly recommend against using a microSD card if you have a Pi model that can boot from USB storage. They are far less stable than an SSD, and are not designed to withstand running an operating system from. They are also dramatically slower, and much more painful to work with. Getting a cheap USB enclosure for an SSD is a far better solution, just try to pick up an SSD with a DRAM cache. It will increase throughput and increase the lifetime of the SSD, and I would not recommend running an OS from an SSD without a DRAM cache.

    EDIT: I believe this to be the easiest way to install Fedora for a Pi device. You will use a desktop/laptop Linux device, and the arm-image-installer will take an ARM ISO and install it to your storage media (SD card, microSD card, SSD, etc.). It was also the first thing I found when I looked up how to install Fedora on a Pi.



  • Last I heard, Nvidia was planning to release support in their drivers for explicit sync in Wayland in May in their 555 beta driver release actually it looks like it might not be merged until Nvidia’s 560 driver. I wouldn’t expect full support until at least then. Maybe we’ll have some support in Fedora by June? You’ll hear about it in the Linux and Linux Gaming communities on Lemmy, so look for it there. Fedora will be pretty early adopters, so it shouldn’t be long after the changes are merged until you’ll see support in Fedora. Do note that it isn’t as bleeding edge as Arch though, so expect it to lag a week behind Arch support (maybe a little more?).

    Also, if you’re between KDE and COSMIC, go with KDE. COSMIC isn’t even in alpha yet, and there are no distros that support it yet. KDE has great support and just merged a lot of performance and bug fixes in the last mega release (Plasma 6). Fedora has a KDE spin, and Plasma 6 will come with Fedora 40’s KDE spin when it releases on the 16th of this month. That will be before explicit sync support though, so I’d say there’s no rush unless you’re really interested in Linux. Nvidia on Wayland is still pretty good without explicit sync support, but explicit sync is essentially the last thing that most people are waiting on. It’s kind of like the last nail in X’s coffin before Wayland is 100% viable on Nvidia. It will fix a lot of little annoyances (flickering, stuttering, etc). KDE has VRR support and a lot of great gaming support, so it’s a good choice.



  • Since I run Fedora, the repos are very up to date. Not as bleeding edge as Arch may be, but plenty fine for learning and development. There are a lot of issues you can run into during manual installation/uninstallation, so I always use distro package managers. Plus, that ensures that software has a much greater chance of running in an environment similar to an end user, so it’s just ideal overall. I can certainly understand frustrations with Debian packages being out of date, but that’s an ideological choice, and the user should have been aware of that before choosing Debian. All I usually have to do is install the compiler/runtime, a language server for neovim, and some minor configuration for IntelliSense, then I can be up and running with a new language.

    The other side to this is that you don’t necessarily need to be using the latest version of the language to learn or develop in it. It’s often a good idea to stick with the latest LTS release of the language so that it’s most available and compatible with the runtime/environment that the end user has access to. Utilizing features only available on bleeding edge versions of the language can make it difficult for others to use your software, as they’d have to go through the hassle of manually installing the latest version, and can lead to breakage if the language changes before the next stable version is released.


  • It seems you’ve chosen a DE that is not particularly well-suited to this task. Cinnamon is meant to be simplistic, and offer an easy transition from Windows with its Windows-like layout. It is purposefully less customizable than many other DEs. I second the recommendation of KDE Plasma, as this is actually available as a shortcut without any extensions, but if you wish to customize your DE deeply like this, KDE is incredibly customizable. You can do essentially anything you want in it and get it to look however you want.

    Since you said that you’re trying out Mint, now would be a good time to switch distro so you don’t get attached to something that doesn’t suit your needs. Switching desktop environments can cause lots of issues, so it’s often best to just pick a distro with the DE you want. My personal recommendation is Fedora’s KDE spin (though there are discussions of Fedora’s default workstation switching to KDE in the future). If you’re invested into Debian, then I don’t really have any experience with Debian-based KDE distros, but I’m sure someone else could recommend you something. To be clear, the benefit of recommending Mint as a starter distro has gradually diminished as other distros have become more user-friendly. Fedora is a perfectly fine distro for someone new to desktop Linux (especially since you’re already experienced on the command line); you’ll just have to look up how to install Nvidia drivers if you have an Nvidia graphics card. AMD commits their driver to the Linux kernel, so no need to do anything if you have an AMD card. Try out some distros in a VM before you commit to anything though; it’s much less commitment than installing so it’s far easier to test distros out and see what best suits you.


  • You should really just use a browser, but I’ll at least try to answer the question.

    I’ve never tried any of them myself, as I’d just prefer using the website on desktop, but here’s a list of mobile and desktop apps for Lemmy (just look at the right column to see which ones are desktop clients).

    It looks like neonmodem is available in the AUR, though it’s a CLI utility. If you’re looking for a GUI, there’s lemoa, but it’s currently unmaintained, or lemonade which appears to be pretty minimal.

    Your options are pretty sparse, so you’re probably best off just using a browser if you’re looking for a GUI. I hate to be one of those guys, but you don’t need an app for everything; the browser can sometimes provide the best experience.