Announcement

Collapse
No announcement yet.

Linux Mint 21 Is Going To Avoid systemd-oomd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • stormcrow
    replied
    Originally posted by Mahboi View Post
    To be quite honest I think Canonical has good reasons to smash some of that extremely aging legacy stuff. 64 bit was the standard over 10 years ago.

    If anything, Valve and Canonical have forced the advancement of many Linux elements moreso than any distro.

    Also will Steam actually leave its 32 bit husk someday or are we stuck with this thing forever? I know a fully native app with a marketplace connection, tons of features, friends list etc. is huge, and I imagine remaking it is a massive pain, but this is some 2003 or so software now. Surely there must be a solid dozen reasons to remake it with more modern stuff. What would a Qt5 based Steam be like?
    Valve has had more than enough time to figure out what to do and implement it as far as Steam 32bit => 64bit is concerned. Instead they sit on their ass barely doing much of anything significant with the platform. We know they can move when they're made to: ex. Apple forced the issue with dropping legacy 32 bit years ago. Otherwise they sit on their ass raking in money they no longer deserve on software with flaws and vulnerabilities that have never been fixed unless they directly affect their income. Valve was once a great developer house. Alex suggests they can still do it, but frankly, they're a shadow of what they used to be. Too big, too greedy, too sure of themselves. You'd think a company that so loves Linux would fix the glaring problems with Steam on Linux, starting with the stupidly wrong permissions it grants every game installed. Don't believe me, look at the file permissions on any given game installed by Steam. You'll find most if not all installed as "777".

    Leave a comment:


  • Ladis
    replied
    Originally posted by user1 View Post

    Remember, it's not just Steam client itself that is 32 bit. There are still tons of native 32 bit ports like tf2. I know that on MacOS Steam client is already 64 bit for quite a while, but that's because since Catalina it completely removed 32 bit compatibility, so all 32 bit Mac ports don't work anymore and Steam was of course forced to switch to 64 bit client. On Linux however, there is probably no point for Valve to switch to 64 bit client because 32 bit games need 32 bit dependencies anyway. Even if you play a 32 bit windows game on Proton, you'll still need 32 bit dependencies like i386 Mesa drivers.
    Fun fact: Catalina still supports sending x86 instructions to the CPU, so you "just" need to copy 32bit libs from the previous macOS to run 32bit apps. The paid WINE (CodeWeavers) translates pointers 32<-->64bit and thus the 32bit apps run (passes forward 32bit instruction to the CPU) and the apps call 64bit system libs (no need to use the original 32bit ones - but adds some level of slowness, especially for games, where you draw a frame tens times a second).
    Last edited by Ladis; 02 July 2022, 04:46 PM.

    Leave a comment:


  • RealNC
    replied
    Originally posted by Mahboi View Post
    Also will Steam actually leave its 32 bit husk someday or are we stuck with this thing forever?
    Steam installs both 32-bit and 64-bit versions of itself (~/.steam/bin32 and ~/.steam/bin64). The 32-bit parts are needed to run 32-bit games.

    Leave a comment:


  • Ermine
    replied
    Originally posted by sinepgib View Post
    I think it's a reasonable move. Default config seems inappropriate for the desktop and fine tuning may be more work than it's worth.

    sysvinit was broken from the beginning, and if anything the triumph of systemd was the fault of the idiots denying its issues and feeding the false dichotomy that the only choice was between those two.
    1) I wouldn't call sysvinit broken. I think 'outdated' is more suitable here. Anyway, sysvinit is apparently fine for end users, but it is a PITA for distro maintainers.
    2) Triumph of systemd has both political and technical sides. You are right. But also a) systemd provided a lot of policy that was previously handled by distros and that fast-tracked systemd adoption; b) some software, like GNOME, became dependent on systemd, so maintainers found themselves in position where they didn't choose whether to go with systemd, but how much of systemd they need to have; c) Back then, kdbus and single-writer cgroupv2 seemed inevitable. Systemd devs had plans to move udev to dbus-only interface once kdbus is merged into kernel, which meant that udev wouldn't be supported on non-systemd distros. It seemed like distros had to stick to systemd or become irrelevant.

    V. R. have written an essay which describes systemd's rise to power and has its technical critique: https://blog.darknedgy.net/technolog...2/0/index.html

    Leave a comment:


  • pabi
    replied
    Originally posted by unis_torvalds View Post
    Yes it's confusing, but only if you're constantly thinking in terms of the upstream. If you're just looking at Mint, it's fairly straightforward
    That's true, but the upstream is still important, such as when an app offers its package for multiple Ubuntu versions or you are searching the internet for a guide on how to do something, because Mint is still effectively Ubuntu and this stuff will apply to it as well in 99 % of cases.
    So you still need to remember the Ubuntu version underneath or calculate it somehow (i.e. remembering the 20-20 match or something). It would be nicer to be able to tell the Ubuntu version right away instead, even though it's not a major inconvenience.

    Leave a comment:


  • sinepgib
    replied
    I think it's a reasonable move. Default config seems inappropriate for the desktop and fine tuning may be more work than it's worth.

    Re: systemd dying... Yeah, because a non-core component not being ideal for a specific use case will make the whole useless.
    sysvinit was broken from the beginning, and if anything the triumph of systemd was the fault of the idiots denying its issues and feeding the false dichotomy that the only choice was between those two.
    There are plenty of init systems/base systems that fixed sysvinit appropriately, and many actually respected muh Unix philosophy. But defend the utterly broken against the most vocal solution instead of any of the other solutions and the vocal solution will obviously prevail. Nobody wants the broken one but a few neckbeards.
    I mean, how bad does your strategy need to be to willingly ignore* s6, runit, openrc and several others in that discussion because "sysvinit is fine"?

    *I know some did point out those options, but AFAICT they were really few compared to the defendants of the status quo.

    Re: abandoning Ubuntu.
    I don't think it'd be madness for them to stop caring about the desktop. Their income (or at least what they clearly aim for income) comes from servers and IOT, not desktop.
    The only two things they get out of providing a desktop nowadays are some development ease (you admin the same system you drive daily, so you form habits that translate between the two) and some mouth-to-mouth publicity. Considering any 32 bits Intel server out there is unlikely to upgrade and most IOT is probably using ARM or unsupported smaller arches, they could very well drop a lot of packages (say all i386) without disturbing those use cases if they were willing to ditch the desktop or at least focus on workstations only.
    It would harm consumers, of course, I'm talking about the "what's in it for me" POV of Canonical.

    Leave a comment:


  • direc85
    replied
    I used to have Linux Mint installed on my mums laptop, and as I want that thing to be rock solid without quirks, _not_ having systemd-oomd to mix things up is a good thing. I still like Linux Mint, but I need newer software (and I can't stand the complexity of .deb packaking).

    Leave a comment:


  • user1
    replied
    Originally posted by Mahboi View Post
    To be quite honest I think Canonical has good reasons to smash some of that extremely aging legacy stuff. 64 bit was the standard over 10 years ago.

    If anything, Valve and Canonical have forced the advancement of many Linux elements moreso than any distro.

    Also will Steam actually leave its 32 bit husk someday or are we stuck with this thing forever? I know a fully native app with a marketplace connection, tons of features, friends list etc. is huge, and I imagine remaking it is a massive pain, but this is some 2003 or so software now. Surely there must be a solid dozen reasons to remake it with more modern stuff. What would a Qt5 based Steam be like?
    Remember, it's not just Steam client itself that is 32 bit. There are still tons of native 32 bit ports like tf2. I know that on MacOS Steam client is already 64 bit for quite a while, but that's because since Catalina it completely removed 32 bit compatibility, so all 32 bit Mac ports don't work anymore and Steam was of course forced to switch to 64 bit client. On Linux however, there is probably no point for Valve to switch to 64 bit client because 32 bit games need 32 bit dependencies anyway. Even if you play a 32 bit windows game on Proton, you'll still need 32 bit dependencies like i386 Mesa drivers.
    Last edited by user1; 02 July 2022, 11:46 AM.

    Leave a comment:


  • Ermine
    replied
    Originally posted by andyprough View Post
    Going to be a shame to watch systemd die and everyone scrambling to update all their old sysvinit scripts.

    Who am I kidding - it's going to be hilarious.
    Of course, because there's nothing else but sysvinit and systemd?

    Leave a comment:


  • unis_torvalds
    replied
    Originally posted by Mahboi View Post
    Mint's versioning utterly confuses me.

    Ubuntu does it right with the YY:MM method. It's sweet, easy to read and once you learn that LTS is every april of an even year, you know all you need from 4 numbers.

    Honestly I wish more software and OSes would switch to a date-based model for versioning.

    Mint already copies Ubuntu in better, why go from Ubuntu 20 -> Mint 20 to Ubuntu 22 -> Mint 21? It's just needlessly confusing, and it's not like plain old versioning is a better way of doing this.
    Mint always increments versions by one, not two. But because they only base on Ubuntu LTS, it's the Ubuntu versions that jump by twos because their LTSes release biennially.
    Thus Mint 19 was based on Ubuntu 18 LTS, and Mint 18 was based on Ubuntu 16 LTS.
    Yes it's confusing, but only if you're constantly thinking in terms of the upstream. If you're just looking at Mint, it's fairly straightforward: Mint 21 succeeds Mint 20 which succeeded Mint 19 which followed Mint 18 and so on. Couldn't be simpler actually. it was just a big coincidence that Mint 20 came out in 2020 the same as Ubuntu 20 LTS, not an intentional alignment of version numbers.

    Leave a comment:

Working...
X