Quoting: scaineI won't quote your post EagleDelta, but I guess time will tell. But if Canonical announce that 20.04 is the last LTS, or even 22.04... I'll be gobsmacked. Similarly, if Steam announce that their new target for compatibility is a rolling release, I'll be gobsmacked all over again.

I suppose time will tell.

I don't think they'll drop the LTS.

What I'm saying is that software is not building against LTS anymore - they build against what they need. Instead, either software packages their own deps or leave the LTS behind. Many times things like performance fixes and certain bug fixes no longer get backported unless the distro does it. Hell, the community I'm in doesn't. Part of the problem is that LTS-styles of Distro/OS will keep their system-installed languages long after those versions are EOL'd upstream because "LTS".

The idea that "Long-Term Support" is somehow more stable has actually been proven largely wrong. The issue isn't Rolling vs LTS - it's individual project's dev process. A Dev team that releases often, with small changes (as small as can be), has a much higher rate of finding and fixing bugs faster than a project that only releases things in large chunks.

There's a reason moving from Ubuntu 18.04 to Ubuntu 20.04 or from Windows 7 to Windows 10 is such a big deal, especially in enterprise. It's not because "LTS" is better, it's because the changeset is now so freaking big that there could be hundreds of bugs just waiting to hit you depending on everything from hardware configuration to software that's running. Using Pop!_OS or Manjaro and updating with each new release instead of waiting means that my potential list of bugs going from 19.10 to 20.04 is going to be far, far less than from 18.04 to 20.04 or especially from 16.04 to 20.04.

Where LTS really shines (for us) in today's world is in container images. We can atomically test a new LTS very, very quickly as we just use the same Dockerfile and change the source image. It will either work or not, but it won't affect the running containers until we are ready to roll it out. Contrast that to the past where we'd spend weeks preparing servers for upgrades from 14.04 to 18.04.

Quoting: scaineVery surprised to hear you say that the panel can be moved to a secondary monitor. I researched this problem for weeks, also raised it on our own Discord, but everyone confirmed - when you change your primary monitor, the panel instantly wants to live there. Some of the hacks allow you to manually move it over to the secondary monitor, but on restart, it rehomes itself again. Pretty frustrating.

I stand corrected. It was Dash-to-Dock that lets you do that, not GNOME itself. I've never dug too far into it. Since the panel doesn't track anything for me other than notifications, tray icons, and the log in panel I don't use it on both screens. I use the overview and workspaces to organize things. Digging through a panel because too frustrating for me. Just SUPER -> click Window is faster (for me).

Quoting: scaineAs for my "favourite" distro - well sure, that's Ubuntu, obviously. I've been a massive part of that community since 2006. At least... it was until I tried Mint again recently for the first time in about five years. It's pretty incredible and I honestly wonder if I'll ever find myself going back to Ubuntu after trying it. I also really liked Solus/Budgie. I'm going to keep track of that one, such a beautiful desktop.

I used to like Mint, but I feel that Cinnamon is buggy and just not up to snuff in the same way that GNOME is. Also, the sheer amount of work that System76 puts into making Pop!_OS feel like great UX makes it my all time favorite. Their curation of the Nvidia drivers for me, including 3rd party software I need in the Pop!_Shop (that most distros don't), their UI into the firmware updater, and their absolutely amazing recovery and OS upgrade tools blow anything that Mint, Ubuntu, or Elementary have to offer out of the water. That and GNOME has become incredibly performant and extensions like Dash-to-Panel/Dash-to-dock and Arc-Menu are just amazing. Pop!_OS 20.04 is also coming with a Tiling/launcher extension for GNOME shell built by System76.

I used to really like Solus, but kept running into issues where software I needed was missing or deemed unnecessary.

View this comment - View article - View full comments

Quoting: scaineNah, Pop is based on Gnome Shell, and their multi-monitor support means that you can't have your panel on a non "primary" display. But I need the panel to appear on the secondary display. Actually, I think the problem is the underlying GDM, because LightDM-based Unity didn't do this, while GDM-based Gnome-shell, XFCE, Unity(!) and Budgie all exhibited the same behaviour. It was just too much effort to get going.

I'm not going to try and dissuade you from your favorite distro, but GNOME does allow the panel on non-primary displays. It's an option in the system menu and in GNOME tweaks.

Quoting: scaineAs for LTS dying a death? Nah. Maybe for consumer distros... maybe. But the Redhats and Canonicals of this world need to support the concept of LTS for enterprise support. You might love rolling distros, but in my experience, they break too often, while I typically game at the cutting edge while on an LTS for periods of up to 2.5 years - or in the case of 12.04 to 16.04, just over four. They're stable and, thanks to PPAs, still cutting edge. Also, I just can't be bothered upgrading the core O/S that often. It does nothing for me. My PPAs do all the heavy lifting.

There are edge cases though, like mininova's insistence on some brand new feature of pygobject. Fair enough. I'll take that hit for the stability/reliability and convenience. And ultimately, I could upgrade it... I just don't care enough about their project to be bothered.

With the exception of really, really traditional enterprises, the "LTS" model is still becoming a slowly dying breed. Largely relegated to running old applications that can't be run on newer systems (though containers are helping with that where it's possible) and running as Hosts for Storage/Virtualization/Container clusters. And even then it's limiting as many of the container and virtualization systems require newer kernel features to perform well.

Add in the fact that security and competition has forced things to move at a faster pace.... and vendors rarely backport patches to non-system software (aside from traditional ones which are struggling to get the newer companies as customers). Simply put, while there will always be a use for LTS type systems (just like there are still COBOL apps), it will become far more rare.

Even where I work, none of our applications go through a traditional release process. Everything moves forward in smaller iterations..... sometimes they can't (I.E. Once you upgrade a Kubernetes Master, it can't be downgraded easily.... and every vendor from Microsoft to Google to RedHat and others will tell you NOT to downgrade it).

• New feature work - deploy the code as soon as it's merged, even if it's inactive. Find potential bugs faster.


• Deployment bug breaking something - Fix and roll forward.


• Change in container breaking something - Fix it, build, and roll tag forward.


• Etc

Why am I saying all this? I come from a Linux Systems Engineer background and now work as a Platform Developer (doing a lot of the same things, just with code) and the traditional "LTS" method is not scalable in today's world of security and competition.

A RedHat employee I work with in an automation-based open source community was talking today about how he feels SLES and RHEL took the "LTS" concept a bit too far as he can't get things working sometimes due to library or kernel issues....... at RedHat.

View this comment - View article - View full comments

Quoting: Julius

Quoting: Liam DaweThe screenshot was taken on Manjaro, works fine there...

Odd, so Manjaro doesn't mind all the file capitalization issues that happen when developing on Windows? How do they achieve that? Hmm, maybe you used a strange filesystem that has to work around that?

Check the ModDB page. They uploaded a new AppImage fixing the initial bug. That said, I found other bugs.

View this comment - View article - View full comments

Quoting: scaine

Quoting: KallestofelesDoes it keep the games up to date or is manual patching needed when updates are released?

Nope, but I expect it's on their roadmap:

QuoteExpect to see the following issues:

• Changing the installation directory makes Minigalaxy unable to detect previously installed games


• Updating games has not been implemented yet

I'm still out of luck with this. After my disastrous multi-screen foray into Ubuntu 20.04, I ended up on Mint 19.3, which is based on Ubuntu 18.04 - which MiniGalaxy doesn't support due to, apparently, a lack of an up to date pygobject:

QuoteMinigalaxy does not ship for the following distributions because they do not contain the required version of PyGObject:

• Ubuntu 18.04


• Linux Mint 19.3


• openSUSE 15.1

It's a shame. I'd love to give it a shot.

This has been an issue with desktop for a while. To the point where Laptop/Desktop OEM System76 suggests you update every 6 months when they release their Ubuntu-based distro. To the point where they have a nice Rust-based updater that works quite well (I used it for Pop!_OS 19.04 -> 19.10 without issue). The idea here is that many desktop OSes are going to more of a rolling or semi-rolling release model. Partially due to security and partially due to the fast rate at which software moves these days. The days of the LTS on desktop are numbered, I think. At least for things like gaming.

I'd suggest trying the Pop!_OS 20.04 beta and see how that works for you.

View this comment - View article - View full comments

I've been trying to test Fractured Realms, but when I click on anything I get the following error in the log:

QuoteException of type `System.InvalidOperationException`: Unit `t2_command_relais` does not have a sequence named `icon`

Anyone else run into this?

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: EagleDelta

QuoteThe latest release put out today further improves the Wine experience.

Liam, is this a full release? Tannis pinged everyone in the Lutris discord yesterday asking to test a beta build of Lutris 0.5.6, no word of a full 0.5.6 release yet.

They asked for testing on Monday, today the release went out and confirmed again here. If it was a pre-release, I would have said so.

Nice! I missed the Twitter announcement. Been pretty heads down with work stuff lately, so if it's not in discord, slack, or mattermost I probably miss it.

View this comment - View article - View full comments

Quoting: ajgpAny link to the changelog so that I can see what changes they have made to time played tracking? I cant locate anything on website or twitter about this update.

It's a database migration changing the datatype of that field in the database itself. I would not upgrade yet if you're worried about it as the standard practice with database migrations is to roll forward, not back. It's generally safer/easier to fix a bug and roll forward than to try and figure out how to roll the DB changes back without major issues.

QuoteThe latest release put out today further improves the Wine experience.

Liam, is this a full release? Tannis pinged everyone in the Lutris discord yesterday asking to test a beta build of Lutris 0.5.6, no word of a full 0.5.6 release yet.

View this comment - View article - View full comments

Quoting: tgurrMeanwhile every game I try running with the "Steam Linux Runtime" fails with

`g_io_module_load': /usr/lib/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load
Failed to load module: /usr/lib/gio/modules/libgiognutls.so
bwrap: execvp readlink: No such file or directory
bwrap: execvp readlink: No such file or directory
pressure-vessel-wrap: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)

while they run fine without the container solution.

It's funny how containers are said to be the cure to everything by adding yet another layer of complexity.

• Not sure where you got that Containers have been pushed as the "Cure to everything". In my experience, it's all about picking the best tool for the job. Many of the Container/Kubernetes heavyweight supporters have recently stressed that containers can't solve all problems.


• The talk addresses that the containerized runtime doesn't solve all problems. Specifically it only supports the Ubuntu 12.04-based runtime and are working on a newer 2018-based runtime version with the intent of having multiple runtime versions for developers/users to choose from.


• I don't think this is using what many of us would consider "true" containers in that they aren't (AFAIK) based on LXC or ContainerD, but are Flatpak-based containers. I could be wrong though

View this comment - View article - View full comments

Hurr durr. Thanks guys, forgot about their scroll to the middle of the page thing.

View this comment - View article - View full comments

The Tower of Time giveaway doesn't seem to work right now. The link just goes back to the main store page.

View this comment - View article - View full comments