You know that all the Wayland primitives, event handling and drawing in gnome-shell are handled in C/native code through Mutter, right ?
The JavaScript in gnome-shell is the cherry on top for scripting, similar to C#/Lua (or any GCed language) in game engines, elisp in Emacs, event JS in QtQuick/QML.
It is not the performance bottleneck people seem to believe.
Indeed, their work on WebKit, Servo, Mesa drivers, the kernel, and more is seriously impressive!
Their customers, Valve, in this case, deserve credit for being good FLOSS citizens (even if they are building a DRM walled garden on top of it :/), but the actual workers are the real unsung heroes.
Them, Codethink, Collabora, and other open-source consultancies I might have missed are doing the community a huge service."
You can ship DRM-free games on it just fine. It's up to the dev/publisher.
Additionally you can get a lot of the benefits of Steam (Proton etc.) even for titles you didn't acquire through Steam - you can add and launch third party executables through the Steam client.
Steam is not exactly a walled garden save for some rather light curation of their own store.
Valve doesn't disclose ahead of purchase whether a title has Steam DRM or not. So even if publishers don't take the option, I have no way to know that. Which means the option effectively doesn't exist.
The publisher could certainly mention it in their product blurb or in the additional notes under system requirements, if they thought to or thought the market would care.
So this is AMD catching up with Nvidia in the RT and AI upscaling/frame gen fields. Nothing wrong with it, and I am quite happy as an AMD GPU owner and Linux user.
But the way it is framed as a revolutionary step and as a Sony collab is a tad misleading. AMD is competent enough to do it by itself, and this will definitely show up in PC and the competing Xbox.
I think we don't have enough details to make statements like this yet. Sony have shown they are willing to make esoteric gaming hardware in the past (cell architecture) and maybe they'll do something unique again this time. Or, maybe it'll just use a moderately custom model. Or, maybe it's just going to use exactly what AMD have planned for the next few year anyway (as you say). Time will tell.
I'm rooting for something unique because I haven't owned a console for 20 years and I like interesting hardware. But hopefully they've learned a lesson about developer ergonomics this time around.
>Sony have shown they are willing to make esoteric gaming hardware in the past (cell architecture)
Just so we’re clear, you’re talking about a decision that didn’t really pan out made over 20 years ago.
PS6 will be an upgraded PS5 without question. You aren’t ever going to see a massive divergence away from the PC everyone took the last twenty years working towards.
The landscape favors Microsoft, but they’ll drop the ball, again.
> you’re talking about a decision that didn’t really pan out made over 20 years ago.
The PS3 sold 87m units, and more importantly, it sold more than the Xbox 360, so I think it panned out fine even if we shouldn't call it a roaring success.
It did sell less than the PS2 or PS4 but I don't think the had much to do with the cell architecture.
Game developer hated it, but that's a different issue.
I do agree that a truly unusual architecture like this is very unlikely for the next gen though.
It sold well, but there are multiple popular games that were built for the PS3 that have not come to any other platform because porting them is exceptionally hard.
Well, at least xdg-app has the concept of "runtimes" shared among applications.
If a lib/bin in a runtime has a security issued, the whole runtime might be updated. Transparently for the apps running over it.
A runtime might be FreeDesktop-1, Gnome-3.14 for example.
Lets say a 0day is discovered and patched in gtk 3.14, a new version of the Gnome-3.14 is issued and dl by the clients.
Magically (with the help of overlayfs and co) all the apps depending on this specific runtime have a secure gtk.
> No, it's not. The serverside is implemented in Scala using a JGit as a GIT library for the files and H2 database for saving the metadata.
From a quick scan of the sources, H2 seems to be an hard-coded dependency. Do you have any plan on abstracting the Slick driver to allow others DB providers ?
> Do you have any plan on abstracting the Slick driver to allow others DB providers ?
I'm not the developer of the project, but database independence was not requested so far :). I suppose if users will ask it, it will be added. H2 suits however very well all the needs, it has a web based Admin UI that can be simply reused, and it's performance is fantastic: http://h2database.com/html/performance.html
reply