This isn’t the first time I’ve blogged about the dearth of truly great PC laptops out there, and I suspect it won’t be the last.
This is a bit of a rant; feel free to skip it if you’re here for the KDE content. This isn’t the first time I’ve blogged about the dearth of truly great PC laptops out there, and …Adventures in Linux and KDE
Here is a quick series of frequently asked questions about the X11 session kissing us goodbye. Shoutout to Nate from which I copied the format of the post. Is Xorg unmaintained and abandoned? No,...Jordan Petridis (Rust in Peace)
Hello there! Here's the thing: I got some old HDD for my Debian home server, and now that I have plenty of disk space I want to keep a backup of the OS, so that if something accidentally breaks (either SW or HW) I can quickly fix it.
now the question is: which directory should I include and which should I exclude from the backup? I use docker a lot, is there any docker-specific directory that I should back up?
I now reside in Germany and my current employer pays 50% of this so called Deutschland-Job-Ticket. There is no physical card but travel information you download to an android wallet, but apparently google wallet is the only available option. See the picture:
Google is a company I don’t trust with my data, neither do I expect your regular public transportation authority employee to care about his privacy (he looked at me as I was asking if 2 + 2 equal 4). I am not aware of non google based wallets where I can download the travel information.
I tried some f-droid and droidify options but it turns out they’re pure crap.
The site: abo.ride-ticketing.de/app/ I log in with my username and password, get my travel information and on the bottom the picture I uploaded.
Any workarounds?
This being Germany, shouldn’t there be an alternative to those who refuse google? Don’t I have that right as a consumer?
Another question: I screenshot my logged in session on the link I provided where you see my qr code and my billing data. The public transportation employee told me that’s not allowed (wtf?). Can anyone here provide a rationale?
cross-posted from: lemmy.ml/post/33213275
I know android is minimally related to linux and the question doesn't resemble a typical question for a linux forum but each time I've asked here you've provided valuable information:I now reside in Germany and my current employer pays 50% of this so called Deutschland-Job-Ticket. There is no physical card but travel information you download to an android wallet, but apparently google wallet is the only available option. See the picture:
Google is a company I don’t trust with my data, neither do I expect your regular public transportation authority employee to care about his privacy (he looked at me as I was asking if 2 + 2 equal 4). I am not aware of non google based wallets where I can download the travel information.
I tried some f-droid and droidify options but it turns out they’re pure crap.
The site: abo.ride-ticketing.de/app/ I log in with my username and password, get my travel information and on the bottom the picture I uploaded.
Any workarounds?
This being Germany, shouldn’t there be an alternative to those who refuse google? Don’t I have that right as a consumer?
Another question: I screenshot my logged in session on the link I provided where you see my qr code and my billing data. The public transportation employee told me that’s not allowed (wtf?). Can anyone here provide a rationale?
they laugh.
All the old people are fucked and have to fumble with (from their pov) alien technology (a smartphone).
At least thats what I've heard from the family of friends that live in Germany.
Do you trust any other provider? Amex used to have a payment type app but I'm not sure I'd call it a wallet. From what I remember Amex wasn't well used in Germany.
You're better of looking in the degoogle communities. Sorry, I still haven't learned to cite the communities here properly (there seem to be two forms). Type degoogle into a community search box (all one word, no hyphens)
I'm using fWallet for Eurostar, plane tickets, etc anything with PkPass. Very minimalist, just does the job.
A beautiful cross-platform wallet application for your transport tickets, discouf-droid.org
By Mera Aladam
Published date: 14 July 2025 11:50 BST | Last update:~08:00 EDT
According to the UN agency for #Palestinian refugees (UNRWA), "truckloads of food and medical supplies are waiting in warehouses" outside #Gaza."Stop the starvation. Lift the siege. Let the #UN, including #UNRWA, do its lifesaving work," they said in a post on X.
Israeli forces killed more than 130 Palestinians in Gaza in a single day, including several children who were attempting to collect water for their hungry families in the besieged enclave.Mera Aladam (Middle East Eye)
cross-posted from: lemmy.ml/post/33173703
By Mera Aladam
Published date: 14 July 2025 11:50 BST | Last update:~08:00 EDT
According to the UN agency for #Palestinian refugees (UNRWA), "truckloads of food and medical supplies are waiting in warehouses" outside #Gaza."Stop the starvation. Lift the siege. Let the #UN, including #UNRWA, do its lifesaving work," they said in a post on X.
Israeli forces killed more than 130 Palestinians in Gaza in a single day, including several children who were attempting to collect water for their hungry families in the besieged enclave.Mera Aladam (Middle East Eye)
reshared this
Miro Collas reshared this.
Jeremy Scahill
Jul 14, 2025
Immediately after Trump announced what he called the “final proposal” for a Gaza deal, Prime Minister Benjamin Netanyahu undermined the negotiating process, repeatedly announcing—in public—his intent to continue the war after securing the release of ten living Israeli captives in a temporary 60-day truce and to forge ahead with his ethnic cleansing campaign to force the surviving Palestinians out of Gaza. “After the pause, we will transfer the population in the Strip southward and impose a siege [on the rest of Gaza],” Netanyahu told far-right cabinet minister Bezalel Smotrich recently, according to Israel’s Channel 12.
Trump again claimed a Gaza deal may be imminent as Netanyahu continues his campaign of sabotage.www.dropsitenews.com
cross-posted from: lemmy.ml/post/33162300
Jeremy Scahill
Jul 14, 2025Immediately after Trump announced what he called the “final proposal” for a Gaza deal, Prime Minister Benjamin Netanyahu undermined the negotiating process, repeatedly announcing—in public—his intent to continue the war after securing the release of ten living Israeli captives in a temporary 60-day truce and to forge ahead with his ethnic cleansing campaign to force the surviving Palestinians out of Gaza. “After the pause, we will transfer the population in the Strip southward and impose a siege [on the rest of Gaza],” Netanyahu told far-right cabinet minister Bezalel Smotrich recently, according to Israel’s Channel 12.
Trump again claimed a Gaza deal may be imminent as Netanyahu continues his campaign of sabotage.www.dropsitenews.com
I realized my VLC was broke some point in the week after updating Arch. I spend time troubleshooting then find a forum post with replies from an Arch moderator saying they knew it would happen and it's my fault for not wanting to read through pages of changelogs. Another mod post says they won't announce that on the RSS feed either. I thought I was doing good by following the RSS but I guess that's not enough.
I've been happily using Arch for 5 years but after reading those posts I've decided to look for a different distro. Does anyone have recommendations for the closest I can get to Arch but with a different attitude around updating?
like this
Mordikan and themadcodger like this.
Arch is definitely not "an experimental distro". It doesn't just break, and all the software in their repos is considered stable.
If you have been using Arch for any meaningful amount of time, the massive output from OPs upgrade should be glaring.
en.wikipedia.org/wiki/Principl…
Someone should inform whoever made that change. If a package is split in a new release, the initial state should match the final as closely as possible, in this case by installing the new optional dependencies automatically. (Although I'm not sure why they'd want to split everything out like that anyway; no other VLC distribution does that, so splitting is itself a violation.)
Maybe Manjaro might be an alternative? I haven't personally used it. I don't like this kind of surprise, so I stick to boring distros like Debian. I used to use CentOS but it was too boring.
You just gave me words for something that was previously just vague internal grumbling and emotions.
Manjaro knows how to aesthetically please me with their color choices and background art. I've got a negative impression from various podcasts and forum posts but I'm realizing I need to look into that more because I can't recall specifics besides something about a past issue with package distribution.
i would recommend against manjaro or endeavorOS and such similar arch based distributions. they’re neat and more stable but have similar issues sometimes, for example the manjaro maintainers are generally known as pretty egregiously irresponsible.
arch is kind of a clusterfuck. the user experience is really poor for a modern linux distribution and the community has an insular attitude of calling everything a skill issue.
i used and maintained a bunch of arch systems for a long time. if you do this you inevitably end up using AUR packages, as some utilities a normal person would use for home and server shit are only available through AUR. updating gets fucky and it’s way more annoying bc you end up needing to constantly read long ass changelogs bc some dude changed the formatting in one UI element and pushed to main at 3AM and it won’t just updated with -Syu or similar args.
i was talking about this earlier on lemmy as an example of terrible UX and all the arch fanboys came to downvote me and write paragraphs in droves talking about how it’s actually just the user’s fault for using the AUR and that i don’t know how pacman works. one guy claimed it’s like Debian PPAs. uh no, the AUR is far less optional lmfao. and i do know how yay and pacman work, i had no trouble, i was just pointing out it was annoying to deal with constantly when using a system like a normal person.
when an OS has no user in mind when designing it… its kind of a shit OS and apparently forms a shit culture around it too, in my experiences the past few years on the internet.
Manjaro is significantly worse with updates breaking.
I used for a little while in 2018 and again in 2019, both times ended because it once became stuck in a boot loop after updates, and another time couldn’t boot after updates.
the initial state should match the final as closely as possible, in this case by installing the new optional dependencies automatically
Sometimes. Some of us out there have use cases where we really, really don't want our systems making choices for us and would rather read the notes every time. One could equally well argue that an OS whose entire purpose is letting the user make the choice suddenly doing something automatically without asking for input is the break in state that users would find astonishing.
I'd say you want Linux from Scratch then, but even then the Linux kernel maintainers are making choices for you.
But Linus is very firm in that they never break userspace, so you should never see an issue like this when updating the kernel.
I second Debian Testing. The only issues I have are updates slow down during package freezes and sometimes, a package you are using becomes a victim of a package transition. Both are symptoms of Testing being exactly what it says, so I can't blame them, but still a valid annoyance.
The worst example was FreeCAD had a dependency being transitioned, so FreeCAD disappeared from Testing for a while, meaning my system wouldn't update if I wanted to keep FreeCAD. In the end, I just gave up and used the Flatpak. (I probably could have installed from Unstable, but whatever.)
Truth be told, I kind of wish there was a project to keep some new packages flowing to Testing users during freezes. I get why Debian themselves doesn't do it - it would be a nightmare to maintain - but an outside community project would be amazing. It wouldn't exactly be easy, but such a project wouldn't need to necessarily do every package (just desired ones), and they would only need to maintain them a couple months until new versions start flowing into Testing again. I think the biggest difficulty is not going too far ahead of what will end up in Testing post-freeze.
debian testing is for testing purposes only. you should never daily drive debian testing (unless you know what you're doing)
also, we're about to get a new debian release (trixie), this is literally the worst time you could choose to daily drive debian testing
gonzo-rand19 likes this.
Arch is really for those who like to troubleshoot and actively maintain things when they break.
I’m pretty decent with linux and for the most part, I can fix arch when it breaks, but I don’t have the time for that. For that reason, I use Fedora and recommend mint.
yup, the syntax is (from within the distrobox)
distrobox-export --app appname
I've been using arch for almost a decade, and haven't had the system break.
I also don't use aur helpers as I don't like or trust them - I do tend to read PKGBUILDs before using them.
Still shocked that OP thought a new opt-depends was "lost in pages and pages of changelogs".
I’m sorry, I thought about it more and remember the reason I had trouble with arch the last time.
It was that I could not get hardware decoding to work when playing videos in Firefox.
Everything reported that it should be working, but it didn’t.
I sometimes forget or delay updates because of life and have over 500 updates. Skim through them if they are patches, minors or majors, and just run. In any case, my disk's are brtfs and I have timeshift for backups. If anything breaks horribly a live USB can restore it, if anything is weird I can restore it via UI. It autoruns every time I run Pacman and stores 5 copies of the "before" state. It also creates a daily copy for the last 5 days so 10 copies in total.
It's more than enough that if something fails I'll have something to go back to, and since it internally works with something akin to hardlinks snapshots don't take that much space.
I've not had issues since setting it up, so, great.
Fedora if you do not gain joy from troubleshooting
Debian sid if you do.
I don't mind trading upfront effort for stability. I enjoyed setting up Arch and I'm still benefiting from insights gained from choosing my setup packages there.
Having nearly latest versions of packages is important to me because I can get into a flow after the initial excitement of a new feature being released but if I have to wait long to get my hands on it that won't happen. In this case, a smaller loss of my excitement to watch a video happened in the time it took me to figure out what was up with VLC.
Opensuse Tumbleweed has made my list to try out.
Thanks for CachyOS. This is my first time hearing of it so I've got some reading to do.
CachyOS and Endeavour OS are the two common Arch derivatives - basically “Arch in easy mode”. They’re both very good.
Manjaro is another but it brings its own set of problems that I never have the time or patience to deal with.
I’m using CachyOS now since October. I’m enjoying it and haven’t come across any issues yet that weren’t easily fixed.
This is the first time in 5 years I haven’t been on opensuse.
I like having Timeshift in place for if I can't figure out what went wrong.
In this case, I didn't use VLC until days after I had updated so my mind didn't go to an issue from updating right away. I make a high amount of accidental inputs while using laptops and I don't always notice so a lot of my issues end up being unintentional configuration changes from weeks or months ago.
I've been using Ubuntu/Kubuntu since 2004 and I've always been happy and had very little problems.
It's a good, no hassle distro that works and is fairly up to date, especially if you use the non-LTS ones. I prefer staying with LTS though. At least my OS is stable and I don't have to spend my free time troubleshooting anything.
My first experience with Linux was Ubuntu back in 2007! I thought it was interesting but didn't become a Linux user until 12 years later when I realized gaming was possible without dual booting.
Something I experience a lot is getting excited for new features. It gives me an energy I can use to start a project I wouldn't have done otherwise. I need to be able to start soon after hearing about the new feature or I risk losing the excitement and missing out on the energy it would have provided.
I've been enjoying Guix for the last 8 days. You declare your OS and home config in a file and you can check them into source control. It was originally a fork of NixOS, but has diverged a lot.
The CLIs and APIs are pretty nice. They have a concept of "channels", which are git repos you can download software from. The default official channel only hosts FOSS software, but you can trivially add non-FOSS channels and they work just as well as the first-party channels.
Each channel update and package install, removal, update get put on a log, which you can trivially jump between. guix package --switch-genereation=28 and boom you're at that generation (it's like a git commit). The software and config changes get saved in the generation so the jump is clean and atomic. I actually bisected my OS yesterday to track a bug! That was cool. You can also create and share isolated, reproducible environments.
Guix works with Flatpak and distrobox as well, in case some software isn't available in existing channels. I got HiDPI, Zoom, Logseq, Syncthing, and Tailscale working.
The biggest drawback for me so far is that it doesn't use systemd. Not sure if it's a dealbreaker for me yet. Systemd does way more than just manage system services, so GNU Shepherd (which Guix uses) isn't a real replacement.
Guix is a distribution of the GNU operating system. Guix is technology that respects the freedom of computer users. You are free to run the system for any purpose, study how it works, improve it, and share it with the whole world.guix.gnu.org
Installing Guix as a Complete GNU/Linux System - System Crafters
Trying out Guix for the first time! Waiting for packages to download.I'm a long time Arch user. Any tips?!
I've heard there aren't as many packages for Guix as other distros, but I was thinking Flatpak and distrobox will help bridge the gap for me.
like this
gonzo-rand19 likes this.
like this
themadcodger likes this.
I enjoyed getting to pick out a lot of the small details by choosing what was going on my system. Something about having the minimum amount needed to meet my needs eases a variety of my computing related anxieties.
I've always managed to solve issues I've encountered but reading that forum post made me realize I may have been attributing issues from updates to Linux in general instead of my distro choice.
it is
...if you're willing to put in the effort to play linux
i believe you. also, my great uncle has smoked since he was 13 and he's now 86 and is still alive
seriously, though, if you do everything right, arch is a great system. it is really well put together and very stable all things considered. the problem is the "doing everything right" part. what happened to op is pretty common if you stop reviewing your updates one by one for a week or two. if you're used to that, then arch is perfect. otherwise, it's a chore
what happened to op is pretty common if you stop reviewing your updates one by one for a week or two
This is just not true. Its pretty rare that you have to manually intervene when updating.
i really don't think that's true about arch, but in general i get that there is a spectrum of how much ppl want to be active in the maintenance of their computer.
i use EndeavourOS, but for my wife i give her Kalpa, which is atomic and much more "less fuss, just use computer."
maybe @makeitwonder would like an immutable distro.
nixos-rebuild... If something suddenly breaks in an update, I just boot into my previous generation, roll back my flake.lock and wait a few days for a fix to be available...
Having dailied both as well, I only agree once you're over the very significant learning curve. And even then, I'd say initial setup is pretty similar, if not a bit easier on Arch.
Arch and NixOS are kind of like C and Rust. Arch/C give you the power and flexibility to do pretty much whatever you want, but also will let you do it in very stupid ways that will come back to bite you. NixOS and Rust give you the same amount of power, but with a higher barrier to entry that ensures you have a pretty good idea of what you're doing, which results in a much more stable experience.
debian
fedora
opensuse tumbleweed (which happens to also be rolling release)
gentoo and lfs make it very clear they're demanding distros. arch is just a little easier, but it's closer to gentoo than to debian
Installing the dependencies did fix it.
I decided I wanted to switch because in the time it took for me to figure that out I lost the excitement for what I was about to watch.
New optional dependencies also happen in other distributions, just happens a lot less as they aren't rolling release distributions.
Learning to parse terminal output for what's relevant is a good and sometimes necessary skill.
You're probably right, this is a issue that isn't unique to Arch. In this case, I would have been fine if a default had been chosen for people who didn't do the reading. Something like installing a plugin that will keep basic functionally of the app working.
I agree that reviewing terminal output is a valuable skill. I'm often lacking the attention or energy to pay attention to every update. I wish that wasn't the case because I believe I have higher than average emotional reactions when things go unexpectedly but the lack of attention -> unexpected event -> emotional reaction loop is a pattern of my life I've come to accept.
Please note that I wasn't passing judgement with my comment, I'm just stating that it will happen with pretty much all Linux distributions.
For example, when upgrading major Debian versions, the same will happen - but you'll usually get thrown into a full screen TUI with interactive buttons asking you how to proceed. So it isn't really possible to leave the system in a non-functional state.
Definitely check out a different, stability first distro. However, note that you will then have the problem of software being old when you want a new feature!
Rule of Thumb: if your use case is not satisfied by your current Distro, then move to the one that does.
Arch or rolling release distros are great if you want latest version of software/packages as soon as possible. Downside is you need to put more effort/time to maintain it by yourself.
On the other hand, fixed release distros (e.g. Debian) doesn't offer latest packages immediately. But, given that packages are tested for distro release, so you will have a more stable (in relative term) system for yourself with minimal effort.
I used to like rolling release distros on my college days as I had plenty of time back then. Now, I'm settled on fixed release ditro as it suits my current use case.
Would a flatpak would survive this update?
I do use arch on some computers but with several flatpaks for some applications that I feel will be safer - but i don't really know.
Maybe i just update and see what happens.
Surely that can be OPs choice.
If a user has a large number of programmes they might not want to hand hold updates of all of them each time.
If they choose only the handful they want from arch repo or aur then they might have a quicker update and find it easier to stay awake.
I'd think it should be up to them if they want to trade off bloat vs the burden of an update.
I find, especially for AUR stuff the update can become vexatious.
Of course it's his choice, it's his system.
The general advice is that handpicking updates from main repos is a big no-no. There are only a couple of reasons you would ever need that, like updating archlinux-keyring on a very outdated system.
Even on my 13 year old install with many thousands of packages, it's not hard to spot if anything is out of the ordinary when doing huge upgrades. You should pay attention.
That being said, I often just do pacman -Syu --noconfirm && poweroff these days. It's so rare that anything breaks and I can very easily fix it if it does.
Debian is my go to for setting up a new server because of the stability and project longevity.
The excitement of features from the cutting edge gives me free energy to start new projects that I don't experience if I wait for the stable release.
The excitement of features from the cutting edge
I don't understand how Debian limits that. You can use Debian for your distribution BUT for whatever you want to be cutting edge, use whatever alternative method you want. It can be alternative package managers, e.g. am but if you want the absolute bleeding edge, go on the repository of the project, get a specific branch, build, install, use. That's absolutely no problem with even Debian stable.
I'm genuinely confused at comments implying that have a stable distribution means having outdated software.
knowing my software is up to date
Wouldn't that be solved with random notifications saying software X has been updated to version Y.Z even though it might not be true?
I can totally understand that. In case you still want to give it a chance, I can highly recommend EndeavorOS. It's basically pre-styled, pure Arch. But it has a welcome dialog, where you have a warning banner at the top if you need to be careful regarding an update. This directly links you to their Gitlab and forum with the steps you'd need to take to not break anything. This saved me multiple times already and I never broke my system, despite not even reading the Arch RSS feed or changelogs.
Besides the EndeavorOS forum is waaaay friendlier compared to the Arch one.
I prefer Debian-Testing. Basically, a rolling release, but not unstable. Arch is akin to Debian -Sid, which is unstable. The latest packages are brought in to -Sid after some rudimentary testing on -experimental. But only the stuff that make it and are solid on -sid, make it to -testing. Basically, Debian has 2 layers of siphoning bugs before they even make it to -testing. And that's why the -stable branch is so solid, because whatever makes it there, has to go through the 3 branches.
So if you like rolling releases with much newer packages, consider -testing. The easiest way is to wait for the Trixie release, and then do the manual update to -testing by changing the repository names (there are online tutorials about it). The other way is to get a -testing iso, but these usually are broken because most people "upgrade" their installed distro to testing instead of just install it outright.
I've been using -testing for over a year now with 0 problems. Even Google is using -testing internally! I also have had Arch installed and endeavouros, and have had 3 problems that I had to fix in 5 months.
They are included in the updates to -testing.
Only after they meet the requirements to be moved from unstable.
From the wiki:
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable.
and
Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.
- wiki.debian.org/DebianTesting
There is some advice on that page about how to deal with security updates for testing and I'm wondering how people who use testing take that advice, and what changes they make to get security updates. Or maybe you don't bother. That's what I mean.
The other way is to get a -testing iso, but these usually are broken because most people “upgrade” their installed distro to testing instead of just install it outright.
I’ve installed Debian testing from ISO a handful of times and never had any issues.
that's exactly how updates should work in every desktop distro. as an option of course.
systemd made it possible to install updates on shutdown.
packagekit enabled kde software to automatically obtain and prepare the updates.
plasma does the final touch nowadays to ask you on the reboot/shutdown dialog whether you want to install them.
Basically all the system is in place, with code from widely used parties. packagekit can even integrate with your filesystem to make a snapshot before install. It's wonderful. yet, it seems as if only fedora supports this full setup right now? or is there anything else?
As long as they're not for the core Fedora projects why not? Bugs for those should be scarce and there are many other users to report them anyway.
Using and contributing to FOSS is hardly scabbing regardless. Unless you're donating to the project I wouldn't consider even bug reporting as directly supporting IBM. The tangible profit to them is pennies if that.
Telemetry, but I don't know if many Linux user doesn't turn it off. But I also don't know if many Linux user doesn't fill bug reports.
Also, if you use Fedora you may recommend it to people that will leave telemetry and/or file bug report. And you also contribute to make the red hat ecosystem relevant, potentially bringing paid customers for RHEL. It's a drop in the ocean of course, but personally I don't want to contribute to it.
Based on what you describe, I would strongly recommend going with OpenSUSE Tumbleweed. It's just as bleeding-edge as Arch, but all packages go through automatic testing to ensure they won't break anything, and if some manual actions are required, it will offer options right before update. Moreover, snapper in enabled by default on btrfs partitions, and it makes snapshots automatically before updates, so even if something breaks somehow, reverting takes a few seconds.
One small footnote is that you'll need to add separate VLC repo or Packman for VLC to have full functionality - proprietary codecs are one of the rare things official repos don't feature for legal reasons.
On Arch rant: I've always been weirded out by this "Arch is actually stable, you just have to watch every news post for manual interventions before every update, oh, and you better update very often" attitude.
Like, no, this is not called stable or even usable for general audience. Updating your system and praying for it not to break while studying everything you need to know is antithetical to stability and makes for an awful daily driver.
like this
Bombastic likes this.
you just have to watch every news post for manual interventions before every update, oh, and you better update very often
You have to watch the factory mailing list and make any manual interventions for Tumbleweed, and frankly, you should be watching the news and taking any action required no matter the os.
taking any action required no matter the os
This is not really true for fixed release distros. I can’t remember when was the last time I had to read through the release note before Ubuntu version upgrade, or upgrading any package.
Just to reiterate the same point - in fixed release, a package version is not released until all known issues are resolved.
At no point, it is end user responsibility to bother checking anything before installing a new version.
Bugs are of two types - known (found during testing by Distro maintainer) and unknown.
Fixed release fixes known bugs before pushing packages.
It is following the standard development life cycle.
Fixed release fixes known bugs before pushing packages.
So do rolling releases. What's your point?
in fixed release, a package version is not released until all known issues are resolved.
That's not really true. It's more important that the issues are known. Sometimes they actually wait longer to fix issues since it would introduce changes
Anyone who is not curious enough to type yay -Pw before typing yay should probably stick with something like Windows. And even then, you should watch out for the rare manual intervention.
Edit: Tone.
FFS dude. It's not lazy want updates to be as simple and pain free as possible. The entire point of these universal machines is to automate shit so we don't have to think about it so much. We have different distros to run them because people prefer different ways of doing things. The one you pick doesn't make you better or worse in any way. OP found out Arch is more work than they want to put up with for their daily driver and the benefits aren't worth the cost. That's a pretty big fucking club to be calling everyone in it lazy.
This kind of elitism is the most unnecessary, useless, vacuous, tedious horseshit and hurts Linux by pushing people away for nothing. Stop it.
I don't think it makes sense to gatekeep Linux only to those who has time, energy, and dedication to continuously check for necessary interventions and to familiarize themselves with all the terminal utilities in the first place.
That is a sort of elitism we need to carefully avoid - one, because otherwise it would halven the desktop Linux community, and two, because there's a huge group of people out there who need what Linux offers, but cannot dedicate themselves to it in the way enthusiasts do.
For them, there must be an option to push the button and get a smooth update, with everything resolved automatically or prompted in a user-friendly way. Arch is not that.
You feel comfy doing this - alright, no one stops you, Arch is great and has a purpose. But we should never put blame on users for not using their system The Arch Way™, because it's too technical, too engaged, and is just a poor fit for most. People will not and should not accommodate for this just to use their system. There's no need to.
If someone chose Arch and complains that it breaks things, it could be useful to point out Arch doesn't have required guardrails to make it operable in a way they expect, and direct the user to other distributions that have them and potentially least painful ways to migrate.
Having tried Arch and its derivatives, and recognizing their strong points, I can absolutely tell the person needs another distribution, and that's alright! Whatever fits anybody is up to them. And for stable rolling release experience without the need for manual checking (but also without some of the power features of Arch mainly geared toward enthusiasts) there's OpenSUSE Tumbleweed.
Edit: Tone.
I don't use Arch, I use Endeavour because they took Arch and made it better. As to why I used yay as my example, there are two reasons:
I see!
I do, in fact, use Endeavour on my desktop as well, simply because I like snappiness and choice of Arch and similarly don't wanna bother with the pure one (and also EndeavourOS forums are more friendly in my experience). I run OpenSUSE Slowroll (an experimental Tumbleweed build, same idea as Manjaro, but actually done right) on my other laptop, so can speak from the experience on both ends.
With Slowroll (and my gf's Tumbleweed) I've only once faced the need for manual intervention, and it was simply to resolve a dependency change by choosing which package to leave - literally enter one number, and then it went on peacefully and correctly installing 1460 updates (yeah, they pushed a big Tumbleweed dump, 3.5 gigs total). On Arch and EndeavourOS, the last intervention was just recently, that's the one OP talks about, and they do happen more often and are more complicated than I'd like.
I'd say one issue in 8 years is a stellar track record!
But I agree they should have warned users a better way.
Anyway, I like how btrfs is treated within Tumbleweed - snapper is fully configured and enabled by default, and you can load a snapshot and rollback into it from the boot menu - all that would take you less than a minute, and any faulty update will be gone for good. With ext4, though, you might need Timeshift. But then, all that can be done within Arch with just a few more tweaks!
I’d say one issue in 8 years is a stellar track record!
Yeah, it's a pretty good track record. It was definitely a failure of communication in that instance, but iirc, they ended up rolling the change back a couple of days later.
I'm running Arch for a very long time. I agree this is not a distro for general audience. I disagree, however, that it is not stable. When I'm doing work I don't update my system. I enjoy my stable configuration and when I have time, I do update, I curiously watch which amazing foss software had an update. And I try them. I check my new firefox. I check gimp's new features. etc.. or if I have to do something I easily fix it, like in no time because I know my OS. Then I enjoy my stable system again.
Do you want to know what's unstable? When I had my new AMD GPU that I built my own kernel for, because the driver wasn't in mainline. And it randomly crashed the system. That's unstable.
Or when I installed my 3rd DE in ubuntu and apt couldn't deal with it, it somehow removed X.org. And I couldn't fix it. That's also something I don't want. Arch updates are much better than this.
Guess we simply apply different meaning to the word "stable". (you do you, though, and if it's alright with your workflow, yay!)
To me, stable means reliably working without any special maintenance. Arch requires you to update once in a while (otherwise your next update might get borked), and when you update, you may have to resolve conflicts and do manual interventions.
Right now, I run OpenSUSE Slowroll (beta, not released yet) on one of my machines and EndeavourOS on the other. The former recently had to update 1460 elements, and one intervention was required - package manager asked me if I want to hold one package for a while to avoid potential dependency issues. Later, it was fixed, and otherwise it went without a hitch. This is the worst behavior I've seen on this distribution, and so to me it renders "acceptably unstable" for general use (although I wouldn't give that to my grandma).
I upvoted you, I am a fellow openSUSE fan and contributor.
But I need to point out that if you install VLC from a repository outside of Factory, then it's not auto-tested.
Moreover, Packman is external to the openSUSE project altogether. If you use it, you are supposed to "just trust" that everything will be fine.
You are better off installing VLC through Flatpak.
like this
Bombastic likes this.
Fair point! Honestly, that's exactly what I ultimately went for, I just know there are people around who strongly prefer native packages.
Flatpak contains all codecs etc., and works flawlessly.
opi with zypper, and then running opi codecs, which will add all the necessary repos and install everything. After that VLC (and h.264 etc) will work like a charm.
Start your Endeavour with a lightweight Arch-based, terminal centric system ready to personalise and a stellar community at your side...EndeavourOS
+1 for Garuda. It's nice that they have their own way of updating (garuda-update), which also handles situations like this one. It was very satisfying to not have to do anything when the linux-firmware change happened a couple of weeks back.
Oh, also snapshots by default are a chef's kiss
I also noticed vlc has broken (installed last week apparently)
Using the pacman syntax:
pacman -Q -i -d vlc
showed a conflict with the vlc-plugin (which appeared to be uninstalled already) and no vlc-plugin-#### installed.
The dependencies were fully explained in the list, including the vlc-plugins-all dependency. I'm lazy so that's the dependency I installed on my EndeavourOS.
After having a similar feeling as yours I went for NixOS.
My thoughts then : if it breaks I can rollback, and the unstable channel is quite comparable to what arch offers.
Now : I've moved to stable channel, because it's updated enough and allows me to only deal with breaking changes twice a year. Moving to NixOS was time consuming (but fun) because it required to rewrite all my dotfiles and learn something new.
I've been an Arch user for more than a decade and I'll usually be first in line to defend it from dodgy claims about unreliability.
But that forum response is bizarre. Literally the last two RSS items right now are about how splitting packages will require intervention for some users (plasma and Linux firmware). VLC is an officially supported package, and surely this change would impact almost every VLC user?
New opt-depends is a nice pacman feature, but it hardly implies that things have been removed from the base package.
Literally the last two RSS items right now are about how splitting packages will require intervention for some users (plasma and Linux firmware).
Maybe a nitpick, but the linux-firmware situation is different, it's not about needing to install extra packages (they turned the existing package into a meta package or whatever it's called), but about that coinciding with some changes that can break the upgrade process and require you to force uninstall a package before proceeding.
But yeah, good point about plasma, the only differences I can even think of are that plasma is probably more popular, and definitely more important to have working.
Manjaro has been pretty quiet for a long time. There's gotta be a point where we forgive and forget. I like Manjaro and used it as my entry point to Arch. It sets a lot more up for you out of the box and has manjaro-specific package bundles that just work on install.
According to Manjarno, its been just under three years since their last mistake, and that was just forgetting to renew the SSL cert for their archived forums. Probably about time we let it back into the Arch family.
I got burned by something like this on Manjaro when a rolling update completely borked my graphics card. The devs reacted in a similar way and it made me realise that my priority is stability over bleeding edge and tinkering.
On that day I moved to Fedora. Stable as hell, no fuss. My main OS should just work and not kill itself.
I still love it but jumped over to Bazzite Gnome recently, which is like Fedora with a few bells on top, coupled with having a read-only root-filesystem (stability, man!). It also comes with distrobox, which will let you run arch natively in a container if you need the AUR.
sudo pacamn -S vlc-plugins-all to get VLC to play video files back, but man, that should have been in the news imo.
The guy is not saying hello, goodbye, thank you. You think those people are tech support? They're volonteers. I would be rude too.
Beside, if an dependency issue arise, just fix it. Are you mad because your ego got hurt? There's a solution in your forum post, idiot.
So to be clear, you are willing to upend your entire system and potentially your workflow because a single package update was mishandled and because somebody was a little too direct on a forum?
Have you considered Mac OS? Yes, I'm being snarky, but the Linux world isn't fully user friendly. If you're unwilling to roll with the punches, it may not actually be for you.
EDIT: I guess tough love from somebody who ran slackware from a stack of physical representations of save buttons is unwelcome. Noted.
I’m being snarky, but the Linux world isn’t fully user friendly. If you’re unwilling to roll with the punches, it may not actually be for you.
I guess you're an Arch user, but this is exactly the wrong thinking. Yes, stuff sometimes break for pretty much every distro, but that doesn't mean we should dismiss people who want stuff to "just work" (which OP went above and beyond). We should absolutely strive to not break stuff, and if it does be humble and polite. Unless you literally want Linux to never become mainstream...
And btw I've been using Fedora for ages now, don't have to follow anything, and when stuff breaks they are generally apologetic about it and try to fix stuff.
Yes, I'm an arch user. But that's not the point. Even using something like mint, you still have to pay attention. Someone who's not willing to do that needs a curated operating system. Simple as that.
I also like to watch locally hosted videos from time to time. I also had the problem with VLC. 10 minutes later I had my answer, the problem was fixed, and I went on with my day. I didn't need to whine about the attitude of someone providing free tech support to someone else, and I didn't whine about a simple package adjustment.
I'll say it again. Linux isn't for everybody. Not yet. It still takes a little bit of grit.
You've got it right. I appreciate the directiness of the forum moderator because it was a clear signal to me that the Arch community doesn't value my experience at the level I would like.
Supporting iMacs for 8 years taught me Apple doesn't value my experience either. I'm happy to upend my system and workflow if it means I'm a step closer to living in the world I want to exist. Most of my life is chosen for me so I want the decisions I have control over to be meaningful to me.
I'm truly sorry that's the takeaway you got from all this. My (attempted) point was along the lines of "Linux is still the wild west." If you're looking for appreciation from random people on the internet, you might be in the wrong place.
Most of my life is chosen for me so I want the decisions I have control over to be meaningful to me.
I get it, probably more than most (my handle isn't random). But from that very perspective, IMO you have to be able to withstand a few assholes and pick your battles. An asshole in a forum that isn't even replying to me specifically doesn't exceed that threshold.
I've tried Endeavour (after failing miserably to do stuff in Arch) and ended up breaking it really bad.
I just went back to Fedora, and haven't looked back (in 3 months, until the distro-hop urge kicks in again 😁)
I’ve only once had a broken firmware update in years and it was an easy fix.
I’m not sure how people can recommend other distributions when they all have issues of one sort or another and you just have to do the bare minimum sometimes to fix them.
Judging from how hasty you are to dismiss a distribution based on a singular event, I would say it will be hard to find other distributions that can be what you wish them to be.
Not gate keeping here, but even in Windows/Mac there are issues which require some research to fix, sometimes even harder than linux ones.
like this
sfera likes this.
If that happened to me I'd not want to deal with that again either.
What has made arch work for me is BTRFS filesystem with the grub module grub-btrfs. It gives you BTRFS snapshots you can load into at grub and with snapper and auto snap it will automatically create a restore point before updating.
It's worked flawlessly and thanks to BTRFS black magic the snapshots don't take up much storage space. I also recommend BTRFS assistant in the aur if you don't mind using a gui.
If you want an easy arch setup + friendly community forums + easy BTRFS setup I can't recommended EndevourOS enough.
the x264 av1 file plays only audio on vlc but works with flaws on mpv: on mpv I get audio and video, but every 5 to 6 seconds it's like instead of getting 24 fps I get 22, the user noticing the missing frames.
Is this a hardware issue? software?
debian 12.11, vlc 3.0.21 flatpak, mpv 0.40.0 flatpak
what do I do?
Check using e.g. top for your CPU (nvidia-smi or amd-smi for your GPU) or System Monitor on KDE if any of your resource is being maxed out. If so then most likely you found the culprit.
Regarding what the actual codec is being used you can use ffprobe but anyway what matters if resource bottleneck and thus if you can have hardware acceleration for it.
It's probably worth investigating so that you don't keep on getting video files too big for your computer to handle. I imagine it's something very high resolution with very recent compression. If so, look for something less demanding, e.g. x265 720p and if that's still leading to performance hiccups the older x264 720p or even 480p.
It's rate that the media player itself, e.g. VLC or mpv, actually is the bottleneck.
Hi, I recently finished setting up my Asustor NAS, and I found the snapshotting setup in it a bit confusing, so I'm writing this as a quick reference that might be hopefully useful to others.
For context, my device is a AS1102TL, and it's running ADM 4.3.3, but I imagine it should apply to all recent Asustor devices.
First of all, the reason I picked Asustor instead of e.g. Synology... it's because it was not clear if the latter actually supported LUKS full disk encryption on an external usb hd. In Asustor you have to ssh into your NAS, but you can definitely do it.
The only gotcha: If you created the LUKS volume recently on another system, it's likely that it'll be using Argon2 for key stretching. A memory-intensive algorithm, for which the 1GB of memory provided by my AS1102TL is not enough. The solution is simply to add another key with a different algo, e.g. PBKDF2, or just create the volume on your Asustor. Either way, you're going to be able to read and write it both from the NAS and another Linux on your pc.
$ sudo $(which cryptsetup) luksOpen /dev/sdb1 encrypted # "encrypted" is just the name that I gave to the device, pick anything... remember the `-S` flag if you need to select a key in a different slot
$ sudo mount /dev/mapper/encrypted /mnt/USB1
... do what you want ...
$ sudo umount /mnt/USB1/
$ sudo $(which cryptsetup) luksClose encryptedNormally, mounted external drives are available on paths like /share/USB0, /share/USB1. Maybe it could be possible to mount (or symlink your mount point for) your disk there, to make it usable to ADM, but by default /share is an immutable loop mount of /volume0/.@system/sharebase.loop
$ lsattr -d /share/
-----i------- /share/btrfs send functionality, so it's not very interesting for our purposes anyhow).Now, you have two different approaches to accomplish incremental backups of btrfs snapshots, one where you just create them yourself from the CLI, and one where you can try to reuse the snapshots created in ADM.
sudo btrfs subvolume snapshot -r /volume1 /volume1/.@snapshots/v20250710-0951sudo btrfs send -p /volume1/.@snapshots/v20250710-0936 /volume1/.@snapshots/v20250710-0951/ | sudo btrfs receive -v /mnt/USB1/I recommend the -v verbose flag for btrfs receive, otherwise you're not going to see progress while the operation is ongoing.
That's it! Of course, the first send will have to happen without specifying a parent with -p, to do a full clone.
There are two problems with this: the snapshots created by ADM are not read-only and they are mounted right under the toplevel.
To address these issues:
sudo mount /dev/md1 -o subvol=/ /mnt/rootvol
sudo btrfs property set /mnt/rootvol/v2025079-2324/ ro truesudo btrfs send -p /mnt/rootvol/v2025079-0824/ /mnt/rootvol/v2025079-2324 | sudo btrfs receive -v /mnt/USB1/-p and -v flags as needed. That's it!If you're wondering why did we have to mount the / subvol, you can try without:
You can mount the snapshots directly in ADM's Snapshot Center, by toggling the Preview toggle for a snapshot. In that case, they are still going to be RW, though mounted as RO. You can deal with that by remounting: sudo mount -o remount,rw /volume1/.@snapshots/v2025079-2324/ && sudo btrfs property set /volume1/.@snapshots/v2025079-2324/ ro true,
You can then try to send the changes, but what you're going to get is:
$ sudo btrfs send -p /volume1/.@snapshots/v2025079-0824/ /volume1/.@snapshots/v2025079-2324
ERROR: not on mount point: /volume1/.@snapshots/v2025079-2324btrfs subvolume list.$ sudo btrfs subvolume list /volume1 -qua
ID 256 gen 159842 top level 5 parent_uuid - uuid cbc37b20-901f-b043-8cf1-59b814814140 path <FS_TREE>/base
ID 258 gen 151914 top level 5 parent_uuid - uuid 5039c206-1a89-dc45-a9fe-43f8959cb672 path <FS_TREE>/.iscsi
ID 259 gen 159840 top level 5 parent_uuid - uuid 06d46207-9aa2-2944-ba38-e5736963ec12 path <FS_TREE>/.@plugins
ID 2758 gen 157876 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 256c36c5-7033-a945-a2db-b6a334a8419f path <FS_TREE>/v2025079-0824
ID 2759 gen 157859 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 88942ee6-8b52-3d4d-b972-5de2d6764728 path <FS_TREE>/v2025079-2324
ID 2762 gen 159833 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 6d636914-35a0-3f42-9486-bf5d673b94c5 path base/.@snapshots/v20250710-0936
ID 2763 gen 159836 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid e99df217-4946-a740-bba9-99f64f1a0d69 path base/.@snapshots/v20250710-0951$ sudo btrfs subvolume list /mnt/rootvol/ -qua
ID 256 gen 159867 top level 5 parent_uuid - uuid cbc37b20-901f-b043-8cf1-59b814814140 path base
ID 258 gen 151914 top level 5 parent_uuid - uuid 5039c206-1a89-dc45-a9fe-43f8959cb672 path .iscsi
ID 259 gen 159840 top level 5 parent_uuid - uuid 06d46207-9aa2-2944-ba38-e5736963ec12 path .@plugins
ID 2758 gen 157876 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 256c36c5-7033-a945-a2db-b6a334a8419f path v2025079-0824
ID 2759 gen 157859 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 88942ee6-8b52-3d4d-b972-5de2d6764728 path v2025079-2324
ID 2762 gen 159833 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 6d636914-35a0-3f42-9486-bf5d673b94c5 path <FS_TREE>/base/.@snapshots/v20250710-0936
ID 2763 gen 159836 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid e99df217-4946-a740-bba9-99f64f1a0d69 path <FS_TREE>/base/.@snapshots/v20250710-0951top level 5 and if you list them under /volume1 (which is just the mount point for the /base subvolume), they are not found directly underneath (despite them being mounted there), which is why you see them being under their own <FS_TREE>.Conversely, the ones that you can create directly from the cli under volume1, appear as top level 256 and they are under /base if you list the subvolumes under /mnt/rootvol.
I hope this has been useful.
PS, while I was closing the dozens of tabs that I opened to investigate how everything fits together, a note on what I wrote earlier:
this doesn’t mean that once mounted, the disk will be integrated in the ADM ui (you’re not going to be able to see it in the “External Devices” ui, nor be able to select it as a destination in the “Backup & Restore” ui).
mounting the disk on a path already accessible by ADM file explorer doesn't work because of permission issues, similar to the immutable flag that you can see with lsattr... but someone on Reddit had another workaround:
reddit.com/r/asustor/comments/…
I mounted the opened device to another path already accessible by ADM file explorer. I don't think it will matter where really. But in my case I made two partitions on an external USB drive. The first partition is a small exFat formatted (10GB). The second partition takes up the rest of the drive and is formatted with cryptsetup (LUKS). Finally, to use this I open the LUKS device and mount it to a location in the first partition (which is automatically mounted by ADM)
The Linux community seems like it's filled with so much drama! How do we make sense of it all? Is Fedora going to kill my games? Did you hear the latest thing Linus said? Is GNOME really blocking a...AbnormalBeingsTube
like this
Andreas Gütter likes this.
Thats the Point of having an Open Source OS where everyone can have a voice. So you can talk about something if its a pile of dogshit.
Is the next video going to be „Why is there so much drama in the bundestag“?
So sitrep:
Newish desktop
- i7-13700K
- 64Gb DDR5 6000Mhz
- RTX 3070Ti
- MSI PRO Z790-P
(WiFi is not a factor, permanent ethernet connection.)
Needs:
- Gaming
- Music composing
- Coding (Mostly python)
- Video editing
I've been using Linux on and off throughout the years, but lately I've fallen out of the loop somewhat. Started with Slackware around 1998, Kubuntu in the 2000's, Ubuntu 2010's, Kali and Mandrake 2020's -> on my laptop, Ubuntu server on my RasPi. At work, we have a few Fedora servers I have to maintain. So not a complete novice, but somewhat obsolete info.
I have been looking at the immutable distros, like Bazzite and Pop!_OS as I've done the whole song and dance of constantly repairing my distro because of various issues, and I'd like my main recreational machine & distro to be low maintenance, I get to fix linux servers at work enough already, I don't want to bring that home.
With gaming, I've understood that linux has come a loooooong way since I last tried sometime around TBC Launch for WoW when Wine barely worked with it.
Music composing is a little annoying, since apparently both Ableton and FL studio are not an option. I've heard good things about Reaper, but I'll have to do some more research. Feel free to educate me on this topic if you have some insider info. I don't play live sets, just compose and mix.
Video editing, currently I use Davinci Resolve, and apparently it works fine on Linux, just some limitations and shenanigans with codecs. Alternatives are welcome, I don't need 90% of what resolve offers, I can make do with a simpler software as well.
Thank you kindly in advance for departing thine wisdom.
I would say, that Fedora and Debian are mostly care-free if you go with the defaults. Fedora can enable Flatpak as part of the installation and for Debian the installation guide can be found on Flathub. In both cases you can then install packages using gnome-software.
I have edited videos with Blender, it has a video editor built-in which is very intuitive. And you can explore compositing with it later. Text and graphics for videos I created with Inkscape (export them to PNGs). The graphics are just linked, so if you need to correct a spelling mistake in Inkscape you can overwrite the original PNG and Blender will pick it up. I think with Blender you can use all video codecs that are supported by ffmpeg.
For music you can have a look at Ardour. I did not use it in a long time, but previous version were enough for me to master a track.
Games: Just install Steam through Flatpak (gnome-software). But it depends mostly on the game whether it will be playable on Linux; check protondb.
Thanks for the alternative take. Good to know that Fedora supports Flatpak that easily.
Blender has a video editor?! Geez, used it back in the day for 3D rendering, but didn't even cross my mind for videos. Inkscape is a great idea!
Had a couple of recommendations for Ardour from other folks as well, will have to give it a go. Free is free after all.
Games fortunately I have the most experience with lately, was in another country with my ancient T530, and was bored, so did some gaming on Ubuntu, got mostly everything working pretty quickly.
Blender has a video editor?! Geez, used it back in the day for 3D rendering, but didn’t even cross my mind for videos.
it is surprisingly good, when i first found out about it i was kinda blown away with how competitive it is with stuff like Kdenlive and the ancient version of sony vegas i used to use
linuxiac.com/new-to-linux-stic…
If you want a quick answer: Linux Mint Cinnamon Edition
Your first Linux distro matters! Here is my advice to avoid frustration and make a more informed switch to this outstanding OS.Bobby Borisov (Linuxiac)
If your primary usecase is going to be music (so a need for realtime capabilities for stuff like recording, VSTs and DAWs) then I do not reccomend immutable distros for a simple reason: you will probably/eventually need to hack something up to get it to work and at that moment, the immutability is just extra work.
As far as I have tried fiddling with the music stack on Linux (which is not that much), the whole pipewire/JACK/carla stack is a bit messy and I can't imagine it working with flatpacks due to the sandboxing/permissions.
Aye, audio latency was a big question I didn't find a good answer for during my research period. It is a headache on Windows as well.
You do make a really good point I didn't think about the immutables for music stuff. Cheers for that.
Throw a dart, pick a distro. My God these "help me pick a distro" posts are irritating. You're not special. Your usecase is not special. Distros are "similar but different".
What do you use at work? Use that one.
Mordikan likes this.
What always gets me is recommendations for what seem like weird obscure distros that I've never heard of.
What should I use for gaming?
Well, for that you need Fizzlegit!
It was released in 2025, is a derivative of a derivative of a derivative, and uses the same repos, but it has Steam preinstalled. Its totally next-gen!
Does the dickish attitude come with the package or is it extra?
It's free, just for you.
Your question was bad and you got bad answers. What did you expect?
Hey - I would like to get into your hobby and have done literally no research about it - which is the best to get to start with?
Mordikan likes this.
Honestly, Bazzite seems to fit like a glove:
- RTX 3070Ti
Nvidia can be an ass to work with on a lot of distros, but Bazzite delivers the right drivers OOTB.
Needs:
- Gaming
Bazzite is setup for gaming OOTB; it's bundled with Steam and Lutris, makes use of custom kernels/schedulers to optimize performance for gaming and contains many other goodies like excellent controller/peripheral support.
- Coding (Mostly python)
Provides a specialized DX (i.e. Developer Experience) image that comes with all the goodies you might expect.
- Video editing
Has a built-in just script that downloads, installs and sets up Davinci Resolve for ya: ujust install-resolve
- Music composing
This is the only I'm not 100% sure yet because you haven't provided explicitly yet what you'd like to use. But, I can't image it would be harder to get this running on Bazzite compared to other distros.
And last, but not least:
I'd like my main recreational machine & distro to be low maintenance
Through utilizing the bootc model, Bazzite is as low maintenance as they come.
Bazzite DX brings the best of Linux to your workstation, with GDX catered to game developers!dev.bazzite.gg
Linux GPU Configuration And Monitoring Tool. Contribute to ilya-zlobintsev/LACT development by creating an account on GitHub.GitHub
Jujutsu is essentially an alternative front-end or "porcelain" to git, both magnificiently simplified and powerful.
I tried it after using Emacs Magit for about six or seven years, and jujutsu is really easier to use than git and useful if one wants a tidy public history of changes (with "tidy" and "public" as Linus Torvalds recommends). Plus it is fully compatible to git as backend - other contributors will not even note you are using it.
like this
Badabinski likes this.
other contributors will not even note you are using it.
Ooooh, that's interesting.
Another useful property is that while jujutsu does have worktrees, like git, in many cases where one would use git worktrees (for example when writing accompanying documentation ) it is just easier to use another line of changes (what is a branch in git).
Alas, that jujutsu does not store local change sets automatically on a remote git repo (this happens only when you update and push a git branch), means that still-mutable local changes are not automatically transferred to another computer you work on. And unpublished changes are naturally mutable in jujutsu. But you can safely copy a jj repo via rsync, as changes in jj metadata are thread-safe and atomic. The other way is of course to push a work-in-progress ("WIP") git branch which can mutate and is therefore not allowed to be merged by other people.
That’s not really how one would use worktrees in git. Worktrees are useful in the case when e.g. you are working on version 0.15 of your software that has many breaking changes to version 0.14 (perhaps even on a build system level) and you need to release a 0.14.1 patch. Worktrees separate directories which means you don’t need to stash or do a wip commit, nor clear you 0.15 build artefacts. Just cd to a different worktree, checkout the 0.14 branch, create and checkout the 0.14.1 branch, clear build artifacts in a different directory from your main development one, and start working.
When done, just cd back and keep working again without switching branches, clearing artifacts, or doing full rebuilds of the in-development 0.15 version.
Plus, git does not store change sets or branches or anything on any remote unless you push them either, so if you’re having that problem just stop pushing things you don’t want to push. You can totally rsync a git repo, just ensure it’s at rest. Otherwise do what you should be doing anyway: set the repo on another machine as a remote of the other repo, so you can git pull my_private_machine feature/my_private_branch without needing to push to a central repo.
I’m sure jujutsu has many advantages, but it also reads to me like you’re misunderstanding the git model. Which can be a fair critique of git to be fair, but then we would need to talk about what about the git model people have trouble with, why, and how to address those issues, and so far I haven’t seen any kind of research in that direction from jujutsu (not that I’ve been looking particularly hard)
One difference between using worktrees and branches in git is that in git you usually have uncommited stuff that's not finished, and worktrees are a way to avoid committing this. And you want to avoid committing early because it is hard to clean-up later. This hesistsnce to commit is not necessary at all in jujutsu - any change to the source files is already captured and will be restored once you go back to that changeset. There are other cases where you use worktrees in git e.g. to isolate a build and an hour-long integration test running it in parallel to your ongoing work, and in thar cases, you'd use workspaces in jujutsu like you'd in git.
but then we would need to talk about what about the git model people have trouble with, why
Too many commands that do subtly and irreversivly things on the repo, with potentially messed-up interim states, only to do the conceptually much simpler task to edit and manipulate the directed acyclic graph of commits.
In short, jujutsu is a commit graph editor and does the same with perhaps 10% of the complexity of git. The man pages on the git reset, branch and merge commands are already larger than the whole - and detailed!- documentation of jujutsu.
Steve Klabnik explains this much better than I can here in his blog that I posted.
It is simply not my experience that cleaning up commits after committing early is difficult in git. Amending a commit is a single -a flag away from the git commit command. The opposite problem is when you do too much work and want to split it into multiple commit rather than a huge one, in which case git add -p is again a single flag away from git add.
In general, git’s entire model is to allow you to work first, and do administrative tasks (including tidying up your commit history etc) later.
And almost nothing is truly destructive in git, the vast majority of cases can be fixed by judicious use of git reflog.
The only cases I’ve ran into where git repos became corrupted were caused by external tools, mainly GUIs that label buttons with git commands that do something different when clicked (like the button labeled push actually doing git push —all for no good reason, and such things) with users that have no idea how git works that have been trained just by telling them “click this to save your work, click this to get the last version of the code”
Sickday likes this.
Technically true - but it looks like jj does a lot of history re-writing which would require a lot of care to be taken when working on a shared codebase.
The page on remotes has some cautions in it.
We need the --allow-backwards flag to set the trunk branch to the previous commit because it is a dangerous operation: if we had pushed trunk, things would get weird when we try and push now. We've kept it all local, so there's no issues with doing this.
jj by default refuses to change any commits on published branches such as a master branch that has been pushed. The details are configurable.
BTW that's why I linked Linus Torvalds mail on when and why to rewrite history - it is good advice.
Hrm... It looks interesting but it seems too dedicated to crafting "the perfect commit".
Changing our description changed the commit ID! This is why we have both IDs: the change ID has not changed, but the commit ID has. This allows us to evolve our commit over time, but still have a stable way to refer to all versions of it.
I don't want to "evolve a commit" - I want to capture my changes over time. If I decide later that I want to prepare the commit for merging I will.
I hate it because it's different - but even trying to give it a "benefit of the doubt" I really can't see this as better. It's not like it's difficult to create a "tidy" commit with git as is.
And as far as "easier to use goes"... well... Here's how you get a list of anonymous branches
jj log -r 'heads(all())'jj new pzoqtwuv yykpmnuq -m "merge better documentation"
# vs.
git merge my_branch_Namejj undo looks neat (and also crazy dangerous unless you can undo an undo?).
And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?
No trouble, you can still name branches if you want. And no, you don't have to type the whole changeset hash, the first one to three letters are usually sufficient.
Also, branch names are not a permanent thing, they disappear after you merged them.
If you want, to can put an empty commit with the description of what you want to do at the top of your changes, and then use "jj split" to move changes to different commits before it.
There are several common work flows which are explained in Klabnik's blog post.
Yeah you can undo undo and also resurrect undone states.
If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it's possible that jj does not give you enough advantage. Everyone works different.
If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it’s possible that jj does not give you enough advantage. Everyone works different.
I mean... It does and I will use git to manage commit histories as necessary. I don't see jj as solving that problem or even making it easier. Doing a single squash-commit or a rebase -i when I merge a branch is relatively trivial.
And from what I can tell it's much easier to do a git pull upstream master than to do jj new skdfsld dskfjas since you'll likely have to lookup those hashes? I mean I wouldn't remember them.
And from what I can tell it's much easier to do agit pull upstream masterthan to dojj new skdfsld dskfjassince you'll likely have to lookup those hashes? I mean I wouldn't remember them.
One takes them from the last commit log and uses the first few letters. Steve Klabnik shows how they are used in practice. It makes no sense to repeat it here.
One takes them from the last commit log and uses the first few letters
So - it's not the length of the random garbage that is the issue it's the fact that it's random garbage that I have no chance of remembering after 5 seconds and switching between branches. All my branches are instead random hashes that I'll need to lookup or remember.
I've read through the blog. It sounds like they've taken the minor inconvenience of doing a git merge --squash and distributed that pain across every-single-commit you're ever going to make instead. All to get "tidy commits" which were possible before anyway.
I was actually rather interested in the idea of jj being something that made history-rewriting easier (e.g. for removing bad commits with passwords and the like). But the fact that it almost completely throws out the entire concept of working on named branches (yes you can have them - but "One interesting thing about branches in jj that's different than branches in git is that branches do not automatically move." - genius) is just ridiculous. And to claim that it's now simpler just seems like gaslighting.
I'm looking for a music player on Pop!_OS that supports playlists, repeating a single track while still being able to swap tracks in the playlist, and also supports fading between songs and when stopping playback. And ideas on what to try?
So far I've tried VLC, Audacious, and Rhythmbox, but none of those seem to support all of those requirements. (Rhythmbox was close but the repeat one from the toolbar plugin doesn't work.)
Edit: Got it working in Rhythmbox after toggling the repeat options a few more times. Still curious if there are other options out there though.
like this
Endymion_Mallorn likes this.
Just a general recommendation for that kind of question:
(Guix package manager can be helpful if your distro does not have this native package; it can without any problem run on top of your distro.)
Having used the wiki, you can even claim you are an Arch user! 😉
SheeEttin
in reply to tubbadu • • •If you need to restore it, back it up.
How do you plan to restore if the whole drive dies?
tubbadu
in reply to SheeEttin • • •thanks for the reply!
good point: I guess if the problem is that I messed something up I may just run the backup script in reverse? if the problem is HW then I'd have to reinstall and then restore the backupped directory probably
is there a "standard" way?
CocaineShrimp
in reply to tubbadu • • •I usually only keep documents and media. Programs can be redownloaded and reinstalled (and it might be better to reinstall them in case you move to a new OS anyway to ensure compatibility).
For docker specifically, only keep stuff that's specific for your instance; which you normally setup as an external volume anyway. Docker is designed such that you should be able to nuke the container, and all persistent data is restored via an external volume on the host. If you're not doing that, you should immediately go and set that up now (to get the data out safely, setup a volume connection such that the container path is new - that way you don't accidentally destroy what's there, copy the stuff you need out, then readjust the path so it's correct)
tubbadu
in reply to CocaineShrimp • • •