That's the problem with public companies: they aren't pro-active.

They don't get the potential of a platform or a device, they just see the figures. They'll only port on platform that are already selling millions (Nintendo, PlayStation, Microsoft), they don't have the luxury to believe in something and I think this is a shame.

That is the fundamental difference between Valve and Ubisoft. Valve is trying things that might fail, but at least they are trying. They are not merely following the market trends.

View this comment - View article - View full comments

I like Aniszczyk's quote at the end. So true.

View this comment - View article - View full comments

I am so happy to see this news! This is exactly what I imagined years ago back when they started Steam OS. I was wondering why they would invest in Linux so much? Steam For Linux, Steam Controller, Steam Link, Proton.. I said that a handheld gaming device makes the most sense. It is good to have a vision and see it being realized :grin:

Other than that, the price is a bit high, but I really like the concept and the look of it. I'll wait and see how it comes out though.. I was one of the poor dudes buying the Ouya on Kickstarter. It won't happen again!

View this comment - View article - View full comments

Quoting: elmapulunreal is source code avaliable though

As Liam said, it's still proprietary.
And as for Unity, you can browse the C# code here: https://github.com/Unity-Technologies/UnityCsReference [External Link]

Indeed, you don't have access to the C++, but you can take a deeper look into what's happening (and Unity is using C# more and more over C++)

View this comment - View article - View full comments

I wonder... Do they have to pass the conformance tests for both OpenGL and Vulkan?

View this comment - View article - View full comments

Wouldn't be surprised if this was one of the hundreds of project in development right now. Would not mean that it will be released though..

View this comment - View article - View full comments

Also, as a reminder, you don't actually own what you buy on Steam, as per the Steam Subscriber Agreement you get a license to play it.

@Liam legally, you never own a game, even if you buy a hard copy. The same goes for music and movies. You have a license to listen/watch/play them, but you don't own them as you don't have any rights on the intellectual property.

But I think you wanted to point out that owning a copy of a game is different than buying a game on Steam, as Steam games can have DRM which prevent you from playing offline.

View this comment - View article - View full comments

I'm disappointed because they don't explain the rational behind this decision in their blog post [External Link].

Is it because users were confused by the sliders? Have they even done some survey even before starting to develop the new feature?

As most people here, I'm no longer really excited about Humble.

It used to be a bold offer, proposing independent games and, in exchange, you'd give to the devs and to charities. And for the very first bundles some games would even go open source if they were to reach a certain amount.

Most of that is lost and Humble became a mere Steam store with the possibility to give to charities at the same time.

But I can do both on my own, thank you.

View this comment - View article - View full comments

Quoting: MagicMyth

Quoting: Creak

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support [External Link]

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

It does indeed take some disk space (especially the runtimes which are the base for every other packages).

I ran some test using `flatpak info APP_ID`:

Runtimes:
* org.freedesktop.Platform: 736.8 MB
* org.gnome.Platform: 948.8 MB
* org.kde.Platform: 992.1 MB

Applications:
* com.transmissionbt.Transmission: 3.9 MB
* com.obsproject.Studio: 49.3 MB
* org.inkscape.Inkscape: 238.9 MB
* com.valvesoftware.Steam: 40.6 MB
* org.pitivi.Pitivi: 197.3 MB
* org.videolan.VLC: 81.8 MB

But it's the price to pay to have sandboxed applications (I know it's not perfect yet, not completely sandboxed bla bla bla... some pieces of the puzzle need to settle down so that access right will be easier to manage and, overall, the system is rather new, but it has improved drastically in just a couple of years).

And also, I'd rather use Flatpak to run the closed source applications such as Steam, Teams, Slack, Unity Hub, etc..

You may not be checking the true file size correctly there. Flatpak uses OStree and it de-duplicates files. Most runtimes only add a few files ontop of the core freedesktop runtime. To get the correct size you have to do something like:
 
du -sh "org.gnome.Platform/x86_64/3.38" "org.freedesktop.Platform/x86_64/20.08"
You should see then that the first folder is roughly as you said but the next will be much smaller (would be good if flatpak info could do that for you). An app plus its runtime should not use much more space than a native package when you add up all the native system components it depends on. Especially once you have many flatpak apps using the same runtime. Also don't forget to run `flatpak uninstall --unused` from time to time to remove old unused runtimes.

I think I remember reading at some point that SNAPS' developers intend to add similar de-duplication features. No idea where I might have read that though! :grin:

Thank you! I also thought at first that de-duplication would give smaller figures, but as I watched the `flatpak info` outputs, I figured it wasn't what I expected, and instead of tweaking the numbers to fit my theory, I preferred to tell my discovery as it is.

I didn't think about using `du -hs` though, but it would makes sense, so I tried it and here are the results:

$ cd /var/lib/flatpak
$ du -hs runtime/org.freedesktop.Platform/x86_64/20.08/ runtime/org.gnome.Platform/x86_64/3.38 runtime/org.kde.Platform/x86_64/5.15/
672M runtime/org.freedesktop.Platform/x86_64/20.08/
265M runtime/org.gnome.Platform/x86_64/3.38
308M runtime/org.kde.Platform/x86_64/5.15/
$ du -hs app/com.transmissionbt.Transmission/ app/com.obsproject.Studio app/org.inkscape.Inkscape app/com.valvesoftware.Steam app/org.pitivi.Pitivi/ app/org.videolan.VLC 
4.4M app/com.transmissionbt.Transmission/
51M app/com.obsproject.Studio
236M app/org.inkscape.Inkscape
40M app/com.valvesoftware.Steam
182M app/org.pitivi.Pitivi/
80M app/org.videolan.VLC

As you can see, except for the GNOME and KDE runtimes where sizes are indeed smaller, the sizes of the Freedesktop runtime and of all the apps are pretty much the same.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support [External Link]

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

It does indeed take some disk space (especially the runtimes which are the base for every other packages).

I ran some test using `flatpak info APP_ID`:

Runtimes:
* org.freedesktop.Platform: 736.8 MB
* org.gnome.Platform: 948.8 MB
* org.kde.Platform: 992.1 MB

Applications:
* com.transmissionbt.Transmission: 3.9 MB
* com.obsproject.Studio: 49.3 MB
* org.inkscape.Inkscape: 238.9 MB
* com.valvesoftware.Steam: 40.6 MB
* org.pitivi.Pitivi: 197.3 MB
* org.videolan.VLC: 81.8 MB

But it's the price to pay to have sandboxed applications (I know it's not perfect yet, not completely sandboxed bla bla bla... some pieces of the puzzle need to settle down so that access right will be easier to manage and, overall, the system is rather new, but it has improved drastically in just a couple of years).

And also, I'd rather use Flatpak to run the closed source applications such as Steam, Teams, Slack, Unity Hub, etc..

View this comment - View article - View full comments