You can't have lots of distros planning on breaking everything and hope that Valve swoops in as a white knight to fix it - what if they don't?

It's not hoping that Valve swoops in, it's demanding that a multi-million $ company does its f****** job & fix their client. Its pathetic that isn't 64bit, yet.

View this comment - View article - View full comments

i mean, there is no reason why an pixel art indie game shouldnt work on a potato pc that some poor people have in some country who barely have eletricity and internet , let alone modern computers.

Which modern games actually run on an Athlon XP? Unity & Godot both require SSE2 & I think there is no OpenGL 3.3 AGP card.

i think we are entering another flash vs kill flash, x11 vs wayland discussion...

Flash was a security nightmare & had to die. But isn't there a new implementation even for flash?

The others are different: X11 is still supported by Wayland & 32bit will be still supported by 64bit systems. Someone will have to maintain a container runtime but old software can still run. But the burden isn't something all distributions have to shoulder.

View this comment - View article - View full comments

It is wrong to say "Steam is DRM". Steam offers a DRM system, and it offers DRM'd games as well as games without DRM. You can copy the latter games freely and use them wherever you want. (You might not be allowed to, but that's not what DRM is about.)

Steam is always DRM. Just try to start a game with the same account on two PCs. Steam DRM restricts this. There are workarounds (DRM free games can be started without Steam & or being offline) but this doesn't change the fact that Steam restricts access to all your games (even if the games are actually DRM free).

even if I do recall that there was some controversy around a title which could not be played multiplayer if it weren't launched from Galaxy (quick Brave search shows Aragami 2 and Monster Train)

Online mutliplayer is basically always DRMed, even on GOG.

View this comment - View article - View full comments

So "preservation" in this case means dropping already existing platform support. At least they package DOSBox for Linux for others, like Castles and Tex Murphy...

Sometimes there are simply no words:

https://www.gog.com/en/game/leisure_suit_larry [External Link]

https://www.gog.com/en/game/leisure_suit_larry_reloaded [External Link]

There was never a Linux or macOS release of Reloaded:

January 5, 2016 Verified owner

Although there is a native Linux port, it is still not available here on GoG for some reason, just like many other existing Linux ports of games sold here.

View this comment - View article - View full comments

Dave2D also talks again about just how good the sleep system is on SteamOS, with you being able to just tap the power button on the Legion Go S and tap it again to pick up right where you left off which just doesn't really work on Windows.

I'm completely with the complaint that Windows can't suspend / resume reliably like other operating systems. Suspending a running game is more complex (but SteamOS handles it) but if you can't reliably suspend Windows with a few applications running (browser, editor, etc) there isn't much hope for games.

It's not the operating system, it's the suspend mode.

SteamOS uses suspend-to-RAM / S3 / deep sleep & Windows prefers (or even enforces) suspend-to-idle / S2idle or standby (https://docs.kernel.org/admin-guide/pm/sleep-states.html [External Link]). You can see this in the video, too: SteamOS takes a lot longer than Windows to wake up.

They were most surprised it doesn't turn on by itself when I tuck it in the bag, such is the case for the infamous Windows sleep in laptops.

Linux has exactly the same issues as Windows & I think it's usually caused by the firmware (e.g. it got better on Lenovo ThinkPad or HP EliteBook devices after a few firmware updates). Unfortunately S3 often isn't even implemented anymore.

View this comment - View article - View full comments

The point was that there was no vulnerability which OP claimed there was.

Are you now claiming the CVEs are fake? Of course there were vulnerabilities.

We are actually wrong (shim apparently was not blocked by this update) but the main point still stands: The affected distributions are at fault.

But don't take my word for it:

[…]

SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we've seen real world examples of malware wanting to do that

[…]

The problem we've ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it's worth noting that grub is signed by individual distributions, not Microsoft, so there's no externally introduced lag here).

[…]

The outcome is that some people can't boot their systems. I think there's plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they're updating those and updating the security generation to match, because otherwise they're shipping a vector that can be used to attack other operating systems and that's kind of a violation of the social contract around all of this.

[…]

https://mjg59.dreamwidth.org/70348.html [External Link]

View this comment - View article - View full comments

Not true, the vulnerable bootloader was fixed ages ago, the thing was though that the blacklisted key was not in the bootloader package but in the shim and since only the bootloader was changed the shim was left untouched so when MS decided to block the old bootloader they instead blocked the shim (that was not vulnerable).

That's the chain of trust. The first in the chain (Microsoft) is only responsible for their link (shim) & must ensure that vulnerable links cannot boot. That's what they've done. So it doesn't matter if the bootloader was fixed as long as the old one was still bootable, this must be prevented.

edited: Some parts are actually not correct, SBAT does work differently (see my next post for more info).

View this comment - View article - View full comments

Not that I've seen. Compared to this https://wiki.bethesda.net/wiki/snapwiki/Doom/SnapHub/ [External Link]:

- There's no "SnapMap Community". Instead a "Play" tab which contains some maps to play.
- Instead of "My Snapmaps" there's a "Create" tab with the same content (but without "My published maps" & the wiki link).
- There's no "Find match".

I don't know if you can copy them from the filesystem.

View this comment - View article - View full comments

You've seen plenty of evidence in this thread. You're just obstinately ignoring it.

Which evidence? I think I've addressed all so called configuration/app store claims. I'm still waiting on your snapd.conf (no, I'm not holding my breath).

View this comment - View article - View full comments

SnapMap is actually included in the build. It's just limited to offline/single-player features.

View this comment - View article - View full comments