Quoting: eldaking

Quoting: CatKiller

Quoting: TermyI'm just confused that the judge didn't ask for any sort of evidence (which wolfire wouldn't be able to provide of course) - guess he wants to keep enough work for the court going? ^^

Quite the opposite. This is a motion to dismiss, which is to get cases sorted out quickly (and cheaply for the parties). In a ruling on dismissal, the judge assumes that everything the plaintiff says is true, and then sees if there's a reasonable likelihood that they could win: if not, the case gets thrown out. Which is how it got thrown out before. That time, the judge let Wolfire amend their complaint and try again, which is how we're at this point where the case has mostly been thrown out.

Seeing if what the plaintiff has said is actually true comes later.

So it was pretty much a case so stupid that even if Wolfire could prove absolutely everything they would lose, so the court wasn't even bothering, and now it is a case of "if they can get proof then maybe, so I guess we have to do it".

Basically yes, now they will soon enter discovery which is the phase where either party will ask the court to force the other party to hand over private information.

View this comment - View article - View full comments

Quoting: Mountain Man

Quoting: GuestIt isn't about selling steam keys cheaper elsewhere, it's about selling a (non-steam) game elsewhere cheaper has threats to delist the game on steam. It seems the judge has ruled that this is a plausible scenario, and is thus allowing the case to proceed.

The judge is not saying it's happening or not. Just that it's possible, and so a trial can proceed to determine the matter.

Wolfire was supposedly told that Valve will "delist any games available for sale at a lower price elsewhere, whether or not using Steam keys", which is demonstrably false.

What I want to know is if Wolfire changed their allegations or if this is just a change in reporting. In their initial complaint they claimed that they had heard this from a 3d party that they would be delisted from Steam of they added their game to a Humble Bundle with discounts. But now it's being reported as Valve telling this directly to Wolfire.

View this comment - View article - View full comments

I think you people are a bit to negative here. Fully understandable with the experience from EA and other big firms but Embracer Group, at least so far, looks to be genuinely interested in producing games and having the studios run independently.

In their Annual Reports each studio is presented individually with a list of what games they currently sell and what they are working on for the future, zero mentioning of "consolidation goals" or "business optimization". I also note that they buy studios by way of share issues so each studio becomes shareholders of Embrace Group.

They are also no big venture capital owners of the company, 61.12% of the votes are owned by 3 people Lars Wingefors from Nordic Games (that became THQ Nordic that become Embracer) and Matthew Karch and Andrey Iones that founded Saber Interactive.

https://embracer.com/wp-content/uploads/2021/08/Embracer-Annual-Report-and-Sustainability-Report-2021.pdf [External Link]

In my belief, a key factor to our success is that entre-
preneurs who become part of Embracer maintain their
creative and operative freedom while they can go faster
and boost their growth by being docked into our growing
eco-system and available resources. We are steadily
seeing more cooperation between the independent oper-
ating groups – for the simple reason that it makes sense
for everyone. We hope that access to the Embracer eco
system will be an even more decisive reason when gam-
ing entrepreneurs chose to become part of the Embracer
family in the future.

Lars Wingefors
Co-founder & CEO

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: F.Ultra

Quoting: slaapliedje

Quoting: user1

Quoting: scaineThat's a great turnaround from a few years ago, when the threatened removal of 32-bit libraries would have crippled the O/S from a gaming perspective.

A better gaming experience in what is still an incredibly popular "entry" distro is superb news.

You know what I think? Making a SNAP Steam is exactly the first step towards removal of the last few remaining 32 bit libraries in Ubuntu (the original plan was to remove ALL 32 bit libraries, but because of backlash, the final decision was to keep a few 32 bit libraries used by popular software). I mean think about it, Steam and Wine are the 2 most popular pieces of software that still require 32 bit dependencies. By making a SNAP Steam, Canonical will then be able to proceed removing those remaining 32 bit libraries (and also removing .deb Steam in the process). Regarding Wine, I heard it's also available as a Snap.

I'm surprised nobody here is asking himself the question what is even the benefit of having a SNAP Steam, when .deb Steam is working perfectly?
So to me it seems that in the case of creating a SNAP Steam, Canonical is just masquerading itself as "caring about gamers", but under the hood it's just part of the plan to remove the final remaining 32 bit libraries and push their SNAP garbage.

I'm so tired of Canonical's bull**** and so glad I've switched to Fedora after a few years of mainly using Ubuntu based distros.

I stopped using Ubuntu before it was cool to do so.

Ha, they stopped being relevant to me when the changed their 'let's be Debian, with the latest Gnome and 6 month release cycles to match Gnome's purpose they had at the beginning.

I am positive their push for ditching 32bit support was because they figured if Apple could do it, why can't they? There is no technical reason for Ubuntu to do so, unlike for Apple as they knew they were moving toward ARM... pretty sad to see the amount of native mac games that won't run after Mojave.

Someone mentioned Arch ditching 32bit support? Pretty sure they have always had the separate multi architecture repo, similar to Debian needing to add it in.

There are actual programs that simply can't be ported to 64bit (or it would take some significant effort" so dropping it is the equivalent of trashing all that past work. Part of why there are software preservation groups these days.

Of course there are technical reasons for ditching 32-bit support (I'm a maintainer for the software my company distributes and I decided to ditch 32-bit support due to technical reasons). It takes time and resources to build an entire arch of your distribution, on top of which you have to provide actual support, for an arch where you have very few users. That Canonical reversed their decision when there was a backlash indicates to me that they simply didn't understand the need for 32-bit libs to support games, they obviously only thought that it was about running Ubuntu on 32-bit hardware.

Those aren't technical reasons. Those are resource reasons.

True, got me there, does it matter though? The point I was trying to make is that they had reasons which was not "let's screw gamers and Steam".

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: user1

Quoting: scaineThat's a great turnaround from a few years ago, when the threatened removal of 32-bit libraries would have crippled the O/S from a gaming perspective.

A better gaming experience in what is still an incredibly popular "entry" distro is superb news.

You know what I think? Making a SNAP Steam is exactly the first step towards removal of the last few remaining 32 bit libraries in Ubuntu (the original plan was to remove ALL 32 bit libraries, but because of backlash, the final decision was to keep a few 32 bit libraries used by popular software). I mean think about it, Steam and Wine are the 2 most popular pieces of software that still require 32 bit dependencies. By making a SNAP Steam, Canonical will then be able to proceed removing those remaining 32 bit libraries (and also removing .deb Steam in the process). Regarding Wine, I heard it's also available as a Snap.

I'm surprised nobody here is asking himself the question what is even the benefit of having a SNAP Steam, when .deb Steam is working perfectly?
So to me it seems that in the case of creating a SNAP Steam, Canonical is just masquerading itself as "caring about gamers", but under the hood it's just part of the plan to remove the final remaining 32 bit libraries and push their SNAP garbage.

I'm so tired of Canonical's bull**** and so glad I've switched to Fedora after a few years of mainly using Ubuntu based distros.

I stopped using Ubuntu before it was cool to do so.

Ha, they stopped being relevant to me when the changed their 'let's be Debian, with the latest Gnome and 6 month release cycles to match Gnome's purpose they had at the beginning.

I am positive their push for ditching 32bit support was because they figured if Apple could do it, why can't they? There is no technical reason for Ubuntu to do so, unlike for Apple as they knew they were moving toward ARM... pretty sad to see the amount of native mac games that won't run after Mojave.

Someone mentioned Arch ditching 32bit support? Pretty sure they have always had the separate multi architecture repo, similar to Debian needing to add it in.

There are actual programs that simply can't be ported to 64bit (or it would take some significant effort" so dropping it is the equivalent of trashing all that past work. Part of why there are software preservation groups these days.

Of course there are technical reasons for ditching 32-bit support (I'm a maintainer for the software my company distributes and I decided to ditch 32-bit support due to technical reasons). It takes time and resources to build an entire arch of your distribution, on top of which you have to provide actual support, for an arch where you have very few users. That Canonical reversed their decision when there was a backlash indicates to me that they simply didn't understand the need for 32-bit libs to support games, they obviously only thought that it was about running Ubuntu on 32-bit hardware.

View this comment - View article - View full comments

Quoting: Samsai

Quoting: RichardYao

Quoting: damarrinI'd be happier with snaps if at least they started faster. 10 secs for FF from an NVMe drive, 40 seconds from a spinning drive in a recent Ubunt is a joke.

The downside of duplicating shared libraries is that it does not take advantage of the system page cache (or ARC for ZFS), so load times are higher. :/

From what I heard, the main problem with load times is that a cold Snap package first needs to be decompressed (fully, I guess?) before it is launched. But I guess duplicated libraries would also affect page cache.

However, that doesn't need to be the case. If the runtime uses similar shared libraries with other packages, it would be possible to deduplicate that stuff either on the package technology level (like Flatpak runtimes) or on the filesystem level with online or offline dedupe and reflinks. I don't know enough about Snap to make strong claims about how effectively or ineffectively it uses these methods. Considering Flatpaks seemingly don't have the same cold start delays, I am guessing at least not very effectively.

By all likelihood it's the decompression. Shared libs and cache sounds very implausible, for one it does not take 10s+ to load some shared libs and secondly Firefox as a deb/rpm already bundled special versions of the libs anyway so it loaded only a limited number of shared libs.

The old deb contained these bundled libs for Firefox:
 
/usr/lib/firefox/gmp-clearkey/0.1/libclearkey.so
/usr/lib/firefox/gtk2/libmozgtk.so
/usr/lib/firefox/libfreeblpriv3.chk
/usr/lib/firefox/libfreeblpriv3.so
/usr/lib/firefox/liblgpllibs.so
/usr/lib/firefox/libmozavcodec.so
/usr/lib/firefox/libmozavutil.so
/usr/lib/firefox/libmozgtk.so
/usr/lib/firefox/libmozsandbox.so
/usr/lib/firefox/libmozsqlite3.so
/usr/lib/firefox/libmozwayland.so
/usr/lib/firefox/libnspr4.so
/usr/lib/firefox/libnss3.so
/usr/lib/firefox/libnssckbi.so
/usr/lib/firefox/libnssutil3.so
/usr/lib/firefox/libplc4.so
/usr/lib/firefox/libplds4.so
/usr/lib/firefox/libsmime3.so
/usr/lib/firefox/libsoftokn3.chk
/usr/lib/firefox/libsoftokn3.so
/usr/lib/firefox/libssl3.so
/usr/lib/firefox/libxul.so
/usr/lib/firefox/minidump-analyzer
/usr/lib/firefox/omni.ja
/usr/lib/firefox/plugin-container

Granted the snap Firefox contains those (which is about 256MB) and an additional 65M of libs that otherwise would be shared.

View this comment - View article - View full comments

Quoting: SchattenspiegelRemember the time basically every major application had a .deb package available and most the disk space was available for games and data and stuff, because applications where small and started nearly instantly and... actually...worked...?

I mean seriously, what is the goal of this? To accelerate climate change by being intentionally wasteful? To incite social unrest by creating an atmosphere comparable to a traffic jam whenever one opens an application?

The goal is most likely to create a shared common framework for game devs to write games for so they don't have to bother with which versions of a specific library exists in your or mine distribution of the week, and to sandbox the whole thing so that it doesn't matter that the bundled libs are old and insecure.

Now I'm by no means defending snaps here, I hate the "new" type of distribution regardless of if it's snap, flatpack, appimage, docker or whater. But if there are two applications in particular where it at least makes some sense then Firefox and Steam is it since both where already bundling custom compiled versions of various dependencies so the overhead and different vs a plain deb isn't that much.

Of course unbundling Firefox would have been the preferred way IMHO but I think solving world peace and world hunger would be the easier option (and also far more worthy a cause).

View this comment - View article - View full comments

Quoting: PikoloSteam as a snap package? That is very unwelcome - I hate applications updating behind my back. Mozilla provide an official Firefox PPA, but I hope Canonical don't mess with the Steam APT package.

The Mozilla Team PPA is not by Mozilla, it's by a voluntary group inside Canonical (or at least they where some years ago). Mozilla are the ones that build the snap for Ubuntu.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: F.Ultra

Quoting: whizse

Quoting: frykBut what I never want to go back to, is having to read all that conversation on screen. Voice-Over please :-)

Hah! I'm very much the opposite. Zero patience for voice. I finish reading. I click to skip. :tongue:

What I never get is why they voice the replies that my character does, I mean I read the entire reply when choosing to click it so why did I just have to spend time hearing it as well?

Especially since they always get someone to do the voice that doesn't sound like me at all. Terrible research on their part! :grin:

Hard to tell since I don't know how you sound ;)

View this comment - View article - View full comments

Quoting: whizse

Quoting: frykBut what I never want to go back to, is having to read all that conversation on screen. Voice-Over please :-)

Hah! I'm very much the opposite. Zero patience for voice. I finish reading. I click to skip. :tongue:

What I never get is why they voice the replies that my character does, I mean I read the entire reply when choosing to click it so why did I just have to spend time hearing it as well?

View this comment - View article - View full comments