I like Flatpaks. They provide a reasonable compromise between compatibility guarantees and disk space usage thanks to runtimes, integrate fairly well while also providing decent sandboxing features and are easy to manage and typically get updated fairly regularly. I think they definitely should be embraced more, especially for the newbies, since you won't break your DE and display manager by installing them.

Flatpak is obviously not ready (at least yet) to be the sole software source. A fair amount of things like terminal utilities and developer tools either aren't installable through Flatpak or otherwise have some quirks and integration issues. At least for me on Fedora Silverblue, the best approach to software development right now is to run my IDE, linters, compilers and library dependencies off of a Toolbx container. So, I don't think Flatpak will be replacing distribution-specific package managers in the short-term for this sort of system-level software.

But when it comes to day-to-day graphical application programs, the stuff majority of people would actually use, Flatpaks work just fine and provide a less fragile environment with a slight bit more safety guarantees and with a better way to target more distributions with a single package. AppImages might have their place for repository-less software distribution of, say, proprietary software that you just download off some website somewhere, but I've found AppImages to be often of poor quality and not actually meeting the cross-distro compatibility they often claim, plus they necessarily suffer from more library duplication than Flatpaks. Snaps on the other hand seem to win Flatpak in terms of being able to install terminal utilities and daemons, but beyond that they seem worse than Flatpaks in most ways, so it would probably be better if Flatpak just gained the ability to better install and use utilities.

Not that long ago I was still fully on-board with the distro-specific packaging approach, where software developers develop and package maintainers package, but I think this approach ultimately has too many drawbacks. It creates a potential for manpower issues, since either the developer needs to do much packaging work to target a multitude of distributions, or they need to rely on package maintainers to have the time and energy to do the packaging for them, which either way results in much duplicate work. It also reduces initial visibility, as software needs to filter through more layers before being generally available to users and increases the time between a new version being released and it being available to users, because some distros will freeze or hold back packages for varying amounts of time for varying reasons. If we want more developers to make application software for Linux, we need to make the process as smooth as possible and reduce the amount of work needed to get your software in front of as many users as possible.

View this comment - View article - View full comments

Quoting: BielFPs

QuoteTotal War: WARHAMMER III gets a short hype-trailer for The Daemon Prince

You can easily defeating him by using kill -9

Bold of you to assume it doesn't have Restart=always enabled.

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: Anza

Quoting: slapinHow come early access launch can fail?

I would assume that early access is both important for feedback and funding. That Kickstarter funding alone doesn't last long with team of 35.

Less than £6000 per person, that would be roughly one month pay for a highly skilled dev over here. Yeah that won't last long.

edit: and the studio is really from "over here" as well.

Even junior devs you wouldn't be able to have for more than a couple months and that's stretching it. So, the crowdfunding money probably ran out already by early 2020 and they probably ran on savings and maybe goodwill for almost two years until they got some money from Early Access, but not enough to cover the losses.

Hopefully the 25 being let go find something else.

View this comment - View article - View full comments

I played it for 20 minutes and had to stop because I was about to puke. Someone in my stream chat said that the game was an insult to the semi-conductor industry. I have hard time disagreeing. It was pretty wacky and absurd though. 10/10

View this comment - View article - View full comments

I tried Ashes 2063 for about an hour last Friday and it seemed very solid to me. They have pulled off a post-apocalyptic aesthetic pretty well and the guns and enemies seemed fun. Definitely need to play more of it in the future and also check out Afterglow.

View this comment - View article - View full comments

Quoting: Glog78[
So in the end ... the user still needs to decide what he wants and not wants -> if a user can't decide in the first place if something is harmful how can he decide now? Will it stop him from doing harmful things ? Will it help him to understand the dependencies and why they are used ? Will it make him understand what is happen right now ? ... Most likely not and we might become a situation like under windows where user don't check anymore if they get an admin promt at all ... they just click it's fine someone on the internet told me to do so ... I would go so far that since you as someone who want to help can't be sure which packages are blocked by which frontend -> we will tell them to do on the commandline overruling the distribution protection ... Thats why i think we are on a complete stupid path currently ... we don't fix anything but we make it more overhead for people who are able to support those systems.

There is only so much you can do to prevent PEBCAK, but on this level I think we had room to push a bit further without any meaningful harm to any existing users, so I don't really understand all the push-back. None of this has ever been about preventing all wrong decisions or making the user learn things they don't want to learn. We are incapable of those things. But what we can do is deploy reasonable measures that make certain classes of stupid mistakes less likely to happen.

Also, I don't see how we are increasing the amount of overhead. The vast majority of situations where we support users don't involve removal of essential packages. In fact, regular users who just want to use their computer should be able to do so basically completely without ever worrying about a single essential package. They should only need to lift the veil if they are actually curious. If a user just wants to install Steam, that should never involve the removal of essential packages and we can make sure that doesn't happen either by deploying sanity checks that make sure those kinds of packaging mistakes don't happen or by having sanity checks performed by package managers so that they don't install faulty packages.

View this comment - View article - View full comments

Quoting: Glog78Ok very slowly ... if someone of you can tell me how you want to solve the problem which programs are essential to a user in the user environment i would agree with this solution. Here again some question which might make it more obvious from a "scenario" which can happen:

The questions you present are edge cases that might not be solved by the existing solution, but that doesn't negate the value of the solution. But sure, I'll take a stab at the issues.

Quoting: Glog78If someone removes Network Manager -> is this package essential with systemd networkd still being around or not ?

If a user explicitly removes Network Manager, there is no issue. The package manager may employ some fail-safe mechanisms to dissuade users from uninstalling it, since it can be vital for the existence of networking, but when the user explicitly orders the removal of NM then that becomes their problem. No user-level application should be able to uninstall Network Manager as part of its dependency resolution process, particularly if NM is active.

Quoting: Glog78Question 2 to make it hard -> if one distribution says it is essential and the other says it isn't -> what would you as an developer of a none distribution package choose as an answer ? (in this case kde discover?)

Make the best and probably most conservative decision the default, provide mechanisms for distributions to provide better information about which packages to consider essential. Since Discover uses the distribution's package management tools underneath, we can probably defer some responsibility to the underlying tools.

Quoting: Glog78Question 3 to make it completly lost -> what if the user wants to exchange network manager against wicd ?

If two packages provide roughly equivalent functionality which would cause them to conflict at installation time, then I would be okay with the user being able to swap one essential package for another if the user has explicitly ordered an installation of that essential package. Package managers already exist which allow one package to cover other packages as dependencies. For example, the pipewire-pulse package provides the pulseaudio dependency under Arch Linux, allowing you to fairly seamlessly switch between the two without breaking the dependencies of all applications that depend on Pulseaudio. We could also decide to require satisfying the fail-safe mechanism in this instance, since switching from NM to wicd is a fairly niche use-case and people that would actually want to knowingly do that can probably figure out what they need to do to accomplish it. Alternatively, we could simply say that NM and wicd should not conflict in the first place and have the issue be resolved on service management level. I've got Network Manager installed in parallel with systemd-networkd, but I simply have the NetworkManager service disabled.

So, really, none of these scenarios is somehow impossible to overcome and solving these three arbitrary scenarios isn't even a requirement for the existing solution to be valid.

View this comment - View article - View full comments

Quoting: NociferWell, this change is actually all about completely preventing the package manager from uninstalling essential packages when told to do so, either explicitly or implicitly. What produced the error Linus faced was trying to install a misconfigured package combined with his/the system's failure to first update the package listings before he tried to install it; it's just that this misconfigured package ended up firing apt's "remove essential package" routine and from thereon there was nothing to prevent apt from doing exactly as ordered, beyond that one silly "fail-safe" (which shouldn't ever have been implemented in the first place).

I am aware of the scenario. Apt still retains the ability to uninstall essential packages and that counts as having the ability to explicitly order such a removal for me. The only difference is that now the fail-safe mechanism is stronger and will better dissuade users who don't actually know what they are doing.

View this comment - View article - View full comments

Quoting: Glog78I think we should discuss those solutions not agree to them by default or hype them. All what we have currently presented is in my eyes just "acitvism" which in the end we all might more suffer than win.

I agree with the solution because I see no obvious flaw that would lead to harm. The solutions implemented in Discover and apt seem to address a real, although somewhat niche, problem. They don't measurably increase complexity nor do they meaningfully harm usability, because the protection essentially only applies in situations where things are likely starting to go wrong already.

I've yet to see a convincing argument against the current implementation. The only arguments I've seen is that this somehow negatively affects the ability to tinker, which it doesn't, or that it doesn't solve every problem in the problem space of problems. It would be great if Discover and apt updates solved the world hunger, but I think expecting them to do that is maybe a bit unreasonable.

I don't know what to do with that activism comment. You seem to be vaguely gesturing at some sort of a slippery slope, but all I am seeing is developers looking at a problem and writing a small fix to prevent it from happening. I guess we could consider this activism of some kind, but that probably makes an activist of all of us programmers.

View this comment - View article - View full comments

Quoting: Glog78Hi Samsai -> you are a programmer. I didn't check the implementation but from my current understanding of the issue ... either this protection should cry on nearly every installed program , cause from a user standpoint the can be essential or it does cry only on very few situations which leaves alot of loopholes and scenarios which makes it no real protection.

So, is your argument that we shouldn't accept any solution that is less than perfect? I think you'll find that suddenly life becomes very very difficult if you start rejecting solutions simply because they are not total solutions. The world runs on compromises, and computers and their software are by themselves a massive pile of compromises built on compromises.

Sure, some users may consider certain packages essential which others would not. However, I think we can establish a fairly agreeable layering, where we designate software that is foundational and without which the normal operation of the system becomes difficult or impossible. In that grouping we can include things like bootloaders, display managers, desktop environments, init systems, package management tools and the core dependencies of the previously mentioned items. After all, I think it's common sense that some user-level application getting accidentally removed is a less of a hassle than your system not booting or entirely losing your graphical environment.

View this comment - View article - View full comments