Quoting: MohandevirBut what I would like to know is how many people, in Steam user pool, are like me:

One computer for work, supplied by the company that hired them and a personnal gaming rig that is used only for that: gaming. Everything else is done on smartphones nowadays... My daughter has a Win10 laptop and it's barely used anymore. Little gaming, here and there and all else, from video editing to photos/photo editing is done on cell phone too... Similar for my son, except he's more of a gamer. Are we weird phenomenons?

I hear the eternal "photoshop gig" to explain why Linux is not catching up on the desktop, but is it still that much true? I have the feeling that we are in an era where the versatility of desktops is mainly exploited at work... Am I wrong to think so?

Ah yes, every single Windows user out there seems to be working in advanced design and imaging considering how often Photoshop is brought up as as stop gap :). Meanwhile not a single person at my office have ever opened any image application ever...

I think that you probably represent how most people use machines today, young people tend to use their phones the way we older people use laptops basically. Myself I cannot stand to use a phone for most things and use a computer for everything but I know that I'm the exception.

View this comment - View article - View full comments

Quoting: Mohandevir

Quoting: elmapul

Quoting: MohandevirExcept you can't run Stadia or Stadia games locally, on any hardware. The hardware platform is not relevant, in this particular case. Sorry if it wasn't clear enough.

no you are not clear at all.
you tried to justify that android didnt helped the linux desktop because android is (mostly) arm devices...
but then you quoted stadia as if it was in the same category as android, and its not...

No. Don't try speaking on my behalf, you are totally wrong... Please read again my sentence in my first post. That's not how it's constructed. There is absolutely no mention of ARM in the whole Stadia sentence. You made a shortcut or misunderstood. Sorry.

Edit: The same category you are referring to is not "ARM"... It's "no interrelation with the desktop". That was my intent from the start.

Well you did write "You are comparing ARM hardware with x86... There is absolutely no hardware interrelations between them. Same for Stadia, there are no interrelations with the desktop", it's quite easy to be confused with the "Same for Stadia" that just followed the whole ARM vs x86.

Not really sure what ARM vs x86 have to do with the issue either since all Android apps are written in Java/Dalvik and not ARM anyway.

View this comment - View article - View full comments

Quoting: Anza

Quoting: F.UltraThe fork done by the FreeBSD team (libressl) was done because the FreeBSD devs wanted more control over such a central piece of software that had gotten stale. Due note that the funding that happened due to this went to OpenSSL and not to LibreSSL and while LibreSSL was the better library for a short while, the OpenSSL project got rejuvenated in the process and LibreSSL is now basically only used by FreeBSD and the distros and projects that went with LibreSSL are close to all back to using OpenSSL again.

It was actually done by OpenBSD folks, though porting it to FreeBSD might have been faster than to Linux. After all FreeBSD and OpenBSD share same 386BSD ancestry. Linux is it's own thing and thus is not by default compatible with things developed on other operating systems. Same thing applies on other direction too.

LibreSSL threw away lot of legacy things in order to improve security. So the goal wasn't just add features on top of OpenSSL. Which might explain why supporting LibreSSL hasn't been always that easy. Which might explain why supporting LibreSSL as OpenSSL replacement might have not been worthwhile once OpenSSL started to be good enough again.

Not that forking hasn't stopped to LibreSSL. Both Tink(Google) and S2N(Amazon) seem to roughly follow same ideals. I noticed that both share same license with OpenSSL, Apache 2.0. So they are able to share code if necessary. LibreSSL seems to be stuck with the older OpenSSL license.

Yeah sorry about that, my memory somehow confused OpenBSD with FreeBSD there. Yes they threw away a lot of legacy stuff to make the code easier to work with, uncertain if any of the stuff they threw out improved security in any way but of course a more easy code base to work with can lead to improved security.

The huge stupid thing that they did though is that they froze the API to that of OpenSSL v1.0.1g but set the OPENSSL_VERSION_NUMBER define to v2.0.0 and that both broke a lot of software and people had to do some really cludgy workarounds like

 
# if (defined LIBRESSL_VERSION_NUMBER && OPENSSL_VERSION_NUMBER == 0x20000000L)
#  undef OPENSSL_VERSION_NUMBER
#  define OPENSSL_VERSION_NUMBER 0x1000107fL
# endif

And then pray and hope that LibreSSL didn't change API ever. So I'm for one glad that the days of LibreSSL is mostly over due to the maintenance headache it caused.

View this comment - View article - View full comments

Quoting: elmapulProbably, but i still cant understand why the web has an great backward compatibility (for good or for bad, regardless of consequences) and we break things so often in linux.

On the other hand this is also the reasons why browsers are bloated messes with extremely hard to maintain code full of security problems.

That said I do agree with you and have argued for years that e.g library writers should take much more care about maintaining ABI and API stability, a new incompatible interface should only be introduced if it really really is necessary and when done it should also be added GLIBC style where keep the old functions in a versioned way so that you don't break ABI compatibility with old applications.

But the main answer is that software is still a young technology that is fast moving forward.

Quoting: elmapulit helps nothing that i tried to develop myself and canonical ditched the apis they were creating (it was PWA before PWA was a thing and with more integration, i can understand why they ditched it, but it still was frustrating.

honestly as both an end user and developer, things breaking on updates pissed me of a lot, it improved a lot since i stop using non LTS ( for years no one told me that i should stay on LTS) and started keeping note on the apps that i install to better troubleshoot any problem (eg: if i install A,B,C it cause problem but if i stop at B it dont)
i would quote a few times things broke but i cant remember now, brian lunduke would give better examples than i can (im awake since yesterday)

Being an insomniac I do feel your pain. Yes it's not easy to know unless some one informs you that the echo system is separated into stable LTS distros that maintain API/ABI and behaviour for 5-10 years and the unstable ones where things constantly change.

Quoting: elmapulits just frustrating to think that, we had some native games in the past, that no longer works, and we have to install the windows version of then.
if we didnt had windows? we were screwed.

Actually those old games should be fully possible to resurrect, the reason some of them don't work on a newer system is that things like SDL have changed too much but one can gather the old versions of all the dependencies for those old games and LD_PRELOAD them in or put it all into a container. There might be some exotic old libraries that straight out refuses to work on a new system but even then it's fully possible to fork them and massage them enough to work, requires that some one steps up to do the work, but it's doable.

Quoting: elmapulnow... i didnt wanted to say "companies definitely did this on purpose" because i know it sounds ridiculous
but if there is an cost of keeping backward compatibility, and an economic incentive in breaking, what is the most logical thing to do?

There is a huge cost in maintaining backwards compatibility indefinitely since you have to orphan every single library and application for that to work. Just upgrading to the newest versions of libs and apps when you are about to release a new version of your distro is basically free in that regard so the economic incentive is not in the breaking, but in the "less amount of work that you put on your own shoulders".

Quoting: elmapullet quote some examples....

openSSL was not secure, big companies sundely realized that one critical piece of their infra structure (and used by many smaller companies too) was not properly funded...
then an fork was created, because of course it was, why fund the original project if you can fund an fork of it instead?

The fork done by the FreeBSD team (libressl) was done because the FreeBSD devs wanted more control over such a central piece of software that had gotten stale. Due note that the funding that happened due to this went to OpenSSL and not to LibreSSL and while LibreSSL was the better library for a short while, the OpenSSL project got rejuvenated in the process and LibreSSL is now basically only used by FreeBSD and the distros and projects that went with LibreSSL are close to all back to using OpenSSL again.

Quoting: elmapulPoP!OS is creating their own desktop enviroment, they said gnome developers code like monkey or something akin to that...
so, why not fund gnome foundation and ask then to hire better developers?
well, because they can just create their own solution instead, paying developers at cost of production instead of cost of production+profit for the managers, and if anyone use their solution, they might be the ones geting paid for customization/improvments instead of paying someone else.
sigh.
i think Pop is going to do the same mistakes that canonical did, meanwhile there are so many things they could make beyond an Desktop Enviroment...
if they want to be an distro for content creators, why not create something like substance painter before substance painter was a thing?

There is of course no real problem with the code of Gnome and the talk about monkeys are just hyperbole from frustrated people. The main reason that Pop!_OS want's to create their own DE is both the "how hard can it be" fallacy that so many devs fall into until they realise that the answer almost always are "quite hard" and the fact that Pop wants to have more control over how the DE looks, operates and works. The clash between Gnome and Pop is that Gnome have refused to implement several changes that Pop have asked for, now I'm in no position to say if either side (or both) are in the right/wrong but since the clash is over the direction, no amount of funding from Pop to Gnome would change anything here so that is not an option (had Gnome been propietary and the money from Pop would have been good then funding as a form of bribery would perhaps work, bit it often doesn't in Open Source projects due to devs work on them for the love of the project and not as a means to get rich [often but not always of course]).

View this comment - View article - View full comments

Quoting: ElamanOpiskelijaNow I want to give the counter-point: what if this has more impact on Linux users than anything else, at the end of the day?

After all, nobody's got the consumer Steam Deck in their hands yet. And there is a good chance that there's so much demand that Valve cannot fabricate enough consoles anyway. Hell, it's been difficult to meet demand even for niche stuff like the Aya Neo.

Well it should, if it works on the Deck it will work on your Linux. That is the difference with Stadia where the port could be (and was) locked away internally.

View this comment - View article - View full comments

Quoting: elmapul

Quoting: GuestIt's not GNU/Linux desktop, and they aren't going to magically make native games available.

as they say, when the service is free, you are the product.
why do you think companies in linux break backward compatibility all the time?
to force companies to pay for techinical support.
i hate to say that, but i think canonical and others are selling US.
want to reach those millions of ubuntu users? want to make sure that your app wont break in our next update? then pay us, because, you know, it would be a shame if anything break, right?

sorry if it sounds like conspiration theory, it is.

Yes it both sounds like and is a conspiracy theory because that is not how reality works. There are no companies that create apps from which the likes of Canonical can blackmail money from. Nor are enterprises paying Red Hat for support due to their systems breaking left and right.

View this comment - View article - View full comments

Quoting: Guest

Quoting: psy-q

Quoting: NeoTheFoxAFAIK the repo contained nothing owned or copyrighted by Take-Two, the reverse-engineering effort is clean room [...]

It wasn't clean-room, unfortunately, the team decompiled Take Two/Rockstar's binaries [External Link] to get there.

In a lawsuit Take-Two has to prove that the ones that uploaded the content actually decompiled the binaries or were aware of it (code being decompiled from binaries).
If X decompiles the binaries, send the code to Y without telling him/her that, Y publish it on, how exactly is Y guilty of something when X only told Y that he/she can do whatever he/she wants with the code received...
Y can't check a copyright claim in the case of a closed sourced code unless Y receive the code. And if X was smart enough to rename some easy to rename things (done with a simple search and replace) you end up in a situation where it's debatable if the code is stolen or not (history show us that more than one person discovered the same thing in same way).
Now if the decompiled code has been patched to fix bug situations changes dramaticaly because it's no longer looking like the original and it's no longer acting like the original... This can easily be explain by the fact that 2 people can think and code in a really similar way, but it's not identical way...
Take-Two has to prove some not easy to prove things and without providing their own code there is no real way to prove things. Once you provided that code in court things can easily go into even more similar situation showing up.

There is also another problem. What % of the code has to match to be considered breaking the law.
There are particular things that are coded in exactly same way (declaring variables, even variable names (some prefer a,b,c; others names, other a1,a2; but you will find code with same variable names doing the same blody thing), that part can't really be considered as breaking the law.
In fact it's open sourced code that you will be surprise to find out that can be found inside products that are being sold and nowhere they admit that they used open sourced code (breaking the license for that open source code. (I've found a browser game that used open sourced code and they were so dumb not to change the hardcode admin password; the admin page was exactly like in the open source code, the hardcoded admin password was the same. Illegal access if someone was going to troll delete players accounts or breaking the open source code license?)

Except of course that in this case X did all the steps (and bragged about it). X is Angelo "aap" Papenhoff that published the GitHub page and here is a YouTube video (he have since changed his username there to X) where he spends 1 hour decompiling a part of GTA and cleaning up the code: https://www.youtube.com/watch?v=22BeuOOERLo [External Link]. Take Two would have zero problems bringing up evidence like this once the case enters discovery.

View this comment - View article - View full comments

Quoting: emphy

Quoting: psy-q

Quoting: NeoTheFoxAFAIK the repo contained nothing owned or copyrighted by Take-Two, the reverse-engineering effort is clean room [...]

It wasn't clean-room, unfortunately, the team decompiled Take Two/Rockstar's binaries [External Link] to get there.

Clean room or not is irrelevant. Since it requires the original game files, it should fall under fair use.

If it doesn't, it is time to ask pointed questions to the respective law-makers on why it doesn't.

Fair use does not cover this, the project does not fulfil the four statutory factors.

View this comment - View article - View full comments

Quoting: [Linuxtayshady]I don't want to dumb down Linux for less inexperienced users, but Pop OS or Ubuntu are not good distros for beginners, Linux Mint is because it's made by people who know what they're doing.

You have two companies like System 76 and Canonical behind these distros and there's still so many bugs and issues with them. I would never recommend any GNOME based distro to any beginner, what a joke. Anyone who recommends these distros to beginners has no idea what they're talking about.

Just recommend Linux Mint, that's it.

There was this dumb shift from the community that Pop OS was the new defacto beginner distro and that was a huge mistake IMO. I heard that the developers of Pop OS want to move away from GNOME about time, GNOME3 needs to just die, fork off GNOME2 like Cinnamon did or just make something else. GNOME3 is a catastrophe and needs to be abandoned, and we need new toolkits to replace GTK so we no longer rely in anyway on the abomination that is the GNOME team. They are the worst thing to have ever happened to Linux IMO.

Sorry but that is just useless distro bashing. There is nothing inherently work with either Pop!_OS, Ubuntu or Gnome that makes them unsuitable for beginners, far from it and both Pop and Ubuntu are being successfully used right now by thousands of beginners the world over.

Gnome3 was a disaster at 1.0 but have been quite usable for several years now and while perhaps not perfect, far from "a catastrophe" and doesn't need to be abandoned. Such hyperbole is just silly and does not move any discussion forward.

View this comment - View article - View full comments

Quoting: Glog78

Quoting: F.Ultra

Quoting: Purple Library Guy

Quoting: NociferBut I do have one question: what if I intentionally do want to remove a "system critical" package like Xorg or my DE - how do I do it if package managers, both GUI and CLI, prevent me from doing so?

If you intentionally want to delete something, wouldn't you normally do it by, I dunno, using a "delete something" command of some sort, not by trying to trigger the deletion by installing a package? As far as I know, nobody's done anything to the stuff you do when you're trying to delete things.

Well it would happen if you where trying to replace say xfree with xorg or pulse with pipe-wire. Then you would remove what the disto have marked as an essential package and replace it with another which is what the Steam package tried to do here, the main issue of course is that there where no i386 version of the desktop or xorg available so apt replaced it all with nothing.

And that is something that the apt (and possible also yum/dnf/pacman) devs should take a hard look on, if a package have a hard dependency that requires it to remove packages but where the actual dependency doesn't exist it should straight out refuse to perform the action regardless of any "do as I say".

i can say for pacman --> unsatisfied dependencies are nearly impossible to install ...

I should perhaps have worded that differently. APT will not continue with a missing dependency either, the bug that happened was a bit more complex than that. What I really meant that the package manager should detect that a dependency wants to remove essential packages without replacing those with something else.

Now this is an extreme edge case, but since edge cases do sometimes happens which LTT is evidence of, if I was an APT developer I would have gotten hold of that broken steam package to see why things went the way they did and analysed if there was a way to detect it and avoid it altogether.

View this comment - View article - View full comments