I know the “Arch BTW” meme exists for a reason, but one of the reasons I haven’t been able to drag myself away from Arch-based distros in recent years is that it allows me to always have current versions of my software while also just not having to care about all this appimage/flatpak/snap brouhaha.
I guess it’s somewhat of a “pick your poison” kind of situation, but I find dealing with the typical complaints about Arch based distros to be both less of a problem than detractors would have you believe, and less of a headache than having to pick one of three competing alternative packaging approaches, or worse, to use a mix of them all. Standing on the sidelines of the topic it seems like a small number of people really like that these options exist, and I’m happy for those people. But mostly I’m grateful that I don’t have to care about this kind of thing.
Edited to add: Seeing how this thread has developed in the past 5 hours convinces me anew that “on the sidelines” is where I want to stay on this topic. 😁
I think if we could drag users (at least gamers) away from these Debian/Ubuntu based distros we could have developers just shipping packages that wouldn’t need to be compatible with some ancient LTS library release, and maybe we wouldn’t need appimage/flatpak/snap at all anymore (or at least only in rare cases).
What about in unstable or testing? I moved to Arch from Debian because I wanted faster releases and it just made sense to move to rolling instead of testing Debian install.
I think Debian has a place in the Desktop market, it’s just not gamers or anyone wanting anything new (unless they of course go the flatpak route). Not a perfect analogy, but it’s kinda like gaming on Windows 7 these days because it “just works” for you. Sure you can, but you’re not getting the best of anything that way and all the underlying libraries are outdated and some things just aren’t going to work at all.
From my perspective as someone who is both getting into gaming on Linux and also not much of a power user, Arch would have to make the installation and maintenance process a lot simpler to attract more people, and I’m not sure that’s something they actually want to do.
Looking at the official Arch installation guide, the average gamer may be overwhelmed by the process here, especially if they’re not comfortable with the terminal. Something like Linux Mint, on the other hand, has a built-in GUI installer with reasonable partitioning defaults, and it comes packaged with stuff like an app manger and update manager, something that will feel much more familiar to someone coming from windows.
100% all this. Canonical has been pushing snaps for awhile, and I wonder if the 12 year LTS for Ubuntu is part of that strategy - want something newer? It’s in the snap store. snap is terrible, worse than flakpak and appimage - but just as you say, as an arch user I don’t have to care. Whatever I want is probably in the AUR if not the main repos. Rolling distros, done right (arch), are an amazing experience.
I distribute an app I made for Linux, macOS and Windows. The Linux version I only have available as a .deb. Released recently and has about 200 users so far, but definitely exists. No Arch user contacted me yet.
When folks start wanting it, someone will package it for the AUR, or if it becomes even somewhat mainstream it will end up in the main repos eventually.
Possibly, though I wonder how updates would work then. Currently I have a Debian repository that contains a single package, and installing the .deb from my website also installs the repository so you get updates as with any other package.
If someone repackages it on AUR, I guess they will also need to update it every time I update the .deb, so it’s always behind? Of course it would be better if I provided a first party package for AUR, but I can spend time on that when there is actual interest. Most of my users are on Windows anyway.
Usually what you describe is what they do. Someone “owns” the AUR package (and it’s not quite literally any random user IIRC - you have to be accepted as an AUR maintainer I think) and they then take on the responsibility to repackage it whenever the author (you) releases a new version. There is also a mechanism for users to flag the AUR package as out of date in case that maintainer misses a release, and if they abandon it (or even if folks just don’t like how they package it) someone else can package it, assuming someone else wants to.
Sometimes the AUR maintainer is the dev themselves. I can’t think of a good example currently, but I know I’ve seen it before.
I don’t know the process for how things end up in the official repos, but I would guess it’s similar to however any other distros identify software they want to officially package.
I know you already got another answer, but - it’s very rare that any software for Linux exists that is both 1) not present in the official Arch repos, and also 2) not packaged by a user for the AUR.
Probably 99% of what a typical user (I know we all define that differently) will want doesn’t even require AUR access - it will be in the official Arch repositories and will be up to date to within a few weeks of release.
There are some potentially substantial downsides to the AUR (it’s the Arch USER Repository - so these are not official arch packages) but IME the real world problems are minimal. I would suggest anyone who is new to the Arch way of distributing software should hit up the relevant page on the Arch wiki and make up their own mind before using the AUR - but it’s about being aware of what you are doing more than it is a real warning, if that makes sense. I suspect few Arch or Arch-based users don’t have at least a smidgen of AUR packages on their system. (Edit: That page is very thorough. I think it makes installing from the AUR sound much harder than it needs to be. For most people the command is just “yay -S packagename.” There are gui options that handle all packages including AUR, and yay is not the only cli option, either.)
Interestingly, there are some AUR packages that work by pulling down the deb and deconstructing it for installation on your system - AFAIK it can be that, RPM, a true “compile from source” situation, or I’m guessing some AUR packages are deconstructing snaps\flatpaks\appimages during the install. Whatever the origin of the files, they include a pkgbuild file that tells your system how to either compile or deconstruct and install the software.
I know I ran into this years ago. I think it was some collection manager app for a trading card game that someone had on GitHub and only had .deb releases. Eventually you will want to install something niche.
Nah, it’s repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can’t imagine having to go through that again.
You can install Arch directly from a UEFI shell over the Internet: archlinux.org/releng/netboot/
If your BIOS has a UEFI shell that supports DHCP, HTTP and IPv4 PXE you can load the ipxe-arch.efi over HTTP and start installing.
Depends on the version. All of them (the newer ones with networking) have TFTP. Some even have HTTPS. I think HP Servers even have HTTPS-Boot with client TLS certificates.
None of it works with Wifi though. iPXE has wifi support for some devices but you obviously can’t start it over the Internet. You need to flash a ROM you don’t need or use a USB drive to load it. Then you can boot Linux from the Internet. (That also works if you don’t have a UEFI Shell in BIOS). netboot.xyz can also boot other OSes than Arch.
I haven’t done a vanilla arch install for years either, because if that sort of thing is fun for some folks great, but it was only fun once or twice for me. I think a lot of the vanilla arch faithful end up scripting it for fresh installs.
But, FWIW there’s always endeavouros, manjaro, and I’m sure other Arch derivatives I’ve forgotten about. I just did an endeavouros install on new hardware I was given last weekend, and it’s certainly no harder to install than Ubuntu.
That’s a link to the most recent release of Firefox and the security vulnerabilities that were fixed.
You’ll notice the first one listed says, “This issue could allow an attacker to perform remote code execution and sandbox escape.”
So if you visited a site that exploited that bug, it escaped the sandbox and ran whatever code it wanted to. Since you were running as root it could do anything it wants. Your device is now the property of someone else. Potentially all your data has been stolen. You probably didn’t even notice.
Now. Realistically. You probably didn’t get exploited. Your device may not be vulnerable to that particular bug. But new bugs are found, and fixed, and created every day. Can you be sure you weren’t exploited?
Let’s look at it a different way. Think of it like driving a car with no seatbelt or airbags. As long as you don’t crash, you’re fine. The car still works fine without seatbelts and you have more freedom to move your arms around.
Let’s look at it a different way. Do you ever lock the door to your home/apartment? Heck do you even close the door? Why not leave it wide open?
At the end of the day security is about layers and the trade offs for convenience. You can run KDE as root, and you can run Firefox as root. You’ll probably be fine. It’s like driving without a seatbelt or leaving your front door wide open, but you can do it. If you do drive with a seatbelt and at least close your front door, you can probably run KDE and Firefox as a regular user.
I'm guessing this is because of more sales of the Steam Deck, haven't got myself one yet but I'd love to as everyone that has gotten ones has said it's worth the money as well as is a great way to get through your games on the go.
6 of the top 10 are verified or playable or 43% of the top 1000 games. But verified and playable is only a subset of the games that work, quite a few unsupported games do as well. If you go by medals the 7 of the top 10 are silver ranked or better (minor issues but generally playable) and 88% of the top 1000. So there are a lot of games that are playable that are still listed as unsupported on the deck.
You can see the numbers for various different things at www.protondb.com as well as different reports for all the games (including some tips on how to get things to work or work better).
TBH I’ve yet to come across any game I haven’t been able to play (aside from the obvious VR/occasional anti-cheat), most unsupported games just haven’t been tested for most cases
Edit: out of curiosity I actually went through my library to see just how many unsupported games I could download and try (again, not the VR ones lol).
I ended up getting caught up playing Revita all day and it says unsupported but it definitely works! For anyone else interested in that game, it is having some development quirks but there’s a public beta branch of it that seems to be the “definitive” version of the game.
Uploaded a control scheme template for the beta since there wasn’t one I liked :D
Then I tried an old DOS game Litil Divil which also worked just fine. I’d have tried some others but like I said, addicting game be addicting
Same, I’m not a big multiplayer person so most of the time it works out. My latest has been Lethal Company, my first new multiplayer game this year 😂. Been a blast.
You may be right in that people are seeing how viable Linux is for gaming due to the success of the Steam Deck.
I’m not sure if steam deck is counted under Arch, but it’s definitely not Ubuntu, Mint, or Manjaro. It looks like the increase in Linux desktop is traditional desktop gaming.
Add the article says, the surge is entirely thanks to the Deck. There was a 35% surge in overall use but 43% of that use is the Deck so PC/laptop use has actually dropped.
It’s great to see that Pipewire has reached this milestone. Personally I’ve been using it since 0.3.35 for very basic audio needs and it’s been a very smooth transition. After installation I never had to tinker with it anymore. “It just works”^TM^
There was a Lemmy post with a video about how things have changed, which I even commented on, but I can’t find anymore.
What I remember was that yes they did address most of the concerns. There were some issues still (unrelated to data collection iirc), and there’s one other fork that’s being maintained if you don’t want that
Edit: I think the was the video, I don’t want to watch it again but I’ll link my TLDW if I find it: m.youtube.com/watch?v=QfmDn1IaDmY
There’s a very nice (albeit somewhat outdated) talk here.
In a nutshell, both X11 and Wayland are protocols that define how software should communicate to (hopefully) display stuff on your screen.
Protocols as in there’s a bunch of documentation somewhere that says which function a program must call to create a window, without specifying how either program or function should be implemented.
This is great because it allows for independently written software to be magically compatible.
X11 is the older protocol, and was working fine good enough for many years, but has issues handling a bunch of modern in-deman technologies - issues which can’t be fixed without changing the protocol in a way that would make it incompatible with existing software (which is the entire point).
Plus its most used implementation - Xorg, consists of a huge and complex codebase that fewer and fewer people are willing to deal with.
Wayland is the newer protocol, that mostly does the exact same thing, but better, in a way that allows for newer tech, and completely breaks compatibility in order to do so.
The trouble with the whole situation was that in order to replace X with Wayland basically the entire Linux graphics stack had to be rewritten - and it was, with raging debates and flame wars and Nvidia being lame.
They also wrote a compatibility layer called Xwayland that lets you keep using older X-only apps which somehow manages to outperform Xorg.
Now we’re at the point where major distributions are not only switching to Wayland by default, but also dropping support for Xorg completely, and announcing that they’ll no longer maintain it, which is why posts about it keep popping up.
Handles graphics drivers, printer drivers, looks like a windows without the influence of advertisers, what I consider a consistent theme, and best of all it is mind numbingly boring. Prepare yourself for the heart pounding activity of predictable updates, uncomplicated booting, running familiar applications, doing work, being productive, not even actively thinking about your OS.
My serious answer, not an argument: Use d-feet to inspect what’s available on the system and session buses. That’ll show the benefit of introspection and a common serialization mechanism.
About the security comments: Some access control mechanisms aren’t just allow/deny, and many need more than socket permissions. Those benefit from DBus policies, and PolicyKit integration helps for more complex needs. You can always DIY it, that’s Linux/FOSS life, but these are great tools to have in your toolbox. I’ll avoid credential passing via sockets whenever I can and have something else do it.
Great point about policies! Setting permissions on sockets only gets you so far… I guess if you really wanted to, you could create an individual socket for every method of every resource, and have granular permissions that way. But that would be quite messy
I’m learning a lot, so I’m not a fan of the people flaming and downvoting OP for having genuine confusion. I want us to incentivize more posts like this.
A new component “systemd-bsod” has been added to show logged error messages full-screen if they have a “LOG_EMERG” log level. This is intended as a tool for displaying emergency log messages full-screen on boot failures. Yes, BSOD in this case short for “Blue Screen of Death”. This was worked on as part of Outreachy 2023. The systemd-bsod will also display a QR code for getting more information on the error causing the boot failure.
Hibernation into swap files backed by Btrfs are now supported.
Actually looking forward to the btrfs swapfile hibernation; I have tried setting it up on my machine before but the documentation was never clear on whether it would work (or why mine wasn’t).
They may have been, things were far more trusting back then.
X servers, for example, would accept any connections. So we would often “export DISPLAY=friendscomputer:0.0” in the computer lab and then open windows of embarrassing content. Which at the time would likely be ASCII art…
One of my favourite wars was to open audio files on other people’s SPARCs, somebody had the loudest bag pipe music that usually ended things.
Access to the SPARCs was normally restricted to third year but if you knew the right person you could get an account created pretty easily. Had the fastest access to the internet at the time within the uni as well.
I used to work at a company that did distributed QA. Other people’s tests would run on your desktop. It worked surprisingly well. But occasionally a test of some audio resource would play on your speakers “The discrete cosine is a real, discrete version of the fast Fourier transform.”
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.