Quoting: JuliusCould you please add KDE Neon as an option: https://neon.kde.org/

Or maybe have the Kubuntu option as both, since it is very close to that and somewhat a successor to it?

Maybe a funny question would be also if the computer came with Linux preinstalled (Steam boxes, Tuxedo etc.). Additional it could have the answer, "no, but everything works out of the box with no extra configuration" or so.

KDE Neon is not in any way a successor of KUbuntu. They've different goals, while KUbuntu goes with the Ubuntu cycle and software releases even with KDE (except if you use backports, which is not officially supported), Neon does not.

I like Neon, they're doing a great job. Though, I decided to get my back to anything *ubuntu based distro. I'd have loved to see Tanglu getting more reception and developers, though, the project seems to decline (a year without release).

View this comment - View article - View full comments

Quoting: minjWell SteamOS is debian-based while Manjaro differs more from Arch than Ubuntu spins from Ubuntu. So your grouping seems a bit arbitrary, not that there's a way to both be precise and generic at the same time...

I don't think it's much more difference on Arch/Manjaro than on Ubuntu derivates.

Manjaro is basically Arch with installer, some tools and a theme. They even take the packages directly from Arch, which is why they import the arch keyring.

The only difference is that there is that they don't push to stable without testing the supported desktops. Latest seen when Qt 5.7 was released which broke unified look on GTK based desktops, where the stable updates were held back for weeks until there existed fixes for the major GTK desktops to deal with the qt-styleengine.

In my opinion this isn't something which should have been broken in a minor release which Qt 5.7 is, though, they did. Arch just rolled the packages, Manjaro held them back until there were fixes.

I've been switching distros [a lot] lately, coming from Arch to several arch-based distros (Chakra etc.), to debian / tanglu, kubuntu, neon, back to arch, and later to Manjaro. If Manjaro does not change too much, it's a distro I think I can settle now for some time.

Only thing is, that Octopi is quite bad from usability point of view, but I never used graphical package managers anyway.

View this comment - View article - View full comments

Very nice. Definitely worth supporting. Would even pay for this, 40 levels to one of my most beloved games.

View this comment - View article - View full comments

I bought it back when they were released. Though, for me the downloads seem to work properly today. Yey, sounds now I certainly hope weather will be bad this weekend.

View this comment - View article - View full comments

Need some rainy days. Have to get onwards in this game. I didn't think I'd like the game, ended up loving it.

View this comment - View article - View full comments

[quote=wvstolzing]

Quoting: MadeanaccounttocommentA really dirty trick M$ could play, though, would be to limit the use of DX12 only on UWP (or whatever it's called) applications. In that case, M$ wouldn't even have to bother sabotaging Valve; since Steam would thus be rendered irrelevant for new games, as long as those don't use Vulkan, of course.

Too risky. A lot too risky. Having a similar API like Vulkan and Steam with a huge client base, EA only publishing in their Origin that could certainly kill off DX12 in favour of Vulkan in a very small timeframe. If companies like EA do not like something it would be sharing their profits. This is why we do not see EA games on Steam anymore.

Vulkan is the threat of the Industry to Microsoft not to do anything wrong with DX. Anything like exactly this. Because then the technology becomes a business decision, a decision for or against their own profit. And porting DX12 to Vulkan is "pretty easy", not saying it isn't a good amount of time for the engine devs, but being platform agnostic already (most engines), if Microsoft goes that way that transition would be very quickly done. The business case (give away 30 % of your profit or not, in EAs case) does not even need to be calculated to know that in such a case Vulkan was to favour. Especially because most engines will have a Vulkan renderer in the future anyway, because of Android.

And killing off Vulkan is hard, because it's completely in the hands of the driver developers, and not Microsoft. And the driver developers do not have any interest in Microsoft, they're not making money because of them, but because of the games requireing high-end graphics cards. So they'd rather listen to the game industry than on Microsoft.

View this comment - View article - View full comments

Quoting: neowiz73this was a $9 billion increase in profits from the year before for Apple, while MS has been showing rocky gains and losses.

Thats wrong, its the 1st and 2nd quater 2016 the profit was declining by about 15 % for Apple.

The results were better than expected, not making it a better result compared to the years before.

View this comment - View article - View full comments

It's not a trailer, it's a teaser. I'll keep a look at this one... wondering what it turns out to be in the end.

View this comment - View article - View full comments

Quoting: CheesenessThis is very true, although I find that it's not necessarily that things were "bad", but often just that they weren't done in the way I like to do things.

Ye well, that would be bad in my definition ;-). Everything not done the way I like it must be bad. I've bit of a Torvalds-Attitude there, which can be a huge issue.

View this comment - View article - View full comments

Really cool is that one to read, mentioned in the original article (I seem to have missed it):

https://icculus.org/~icculus/dotplan/SeriousSam-CHANGELOG.txt

Daily log updates of the SeriousSam port of Ryan (icculus) Gordon, but writing not what has been done but what he's planning to do. Expect a lot of disappointment, and less "yyeeey" moments ;-).

Another interesting part is:
> Porting Is Not Software Development

porting is like fixing a huge mess of a bug with a code structure you don't like, but you have to focus on rewriting as little as possible. Which is the usual bugfix procedure (if fixing the bug of somebody else). Changing less means less possibilities to break. Had to experience that the hard way, "that's done bad, this could be done better" ending up in fixing what i "fixed" or "beautified".

I didn't port games yet, but I did port some more-or-less complex applications from Windows to Linux (codebase between 50.000 loc and 300.000 loc) knowing that very well, especially if you do know windows and are crazy enough starting to touch the windows implementation because you think you can do better with almost no effort than the windows guys who were paid for it. Never do that. Ever. Seriously. Get some fuel and a lighter, will be less pain and a faster end.

But really cool article to read, great that this one was shared. Thanks!

View this comment - View article - View full comments