Latest Comments by LoudTechie
Palworld dev details the patents Nintendo and The Pokemon Company are suing for
11 Nov 2024 at 7:51 am UTC
As such I used anecdotal evidence and the stats to measure religious zeal.
My primary anecdotal "evidence". In this story the artist tells about their interactions with Japanese culture including some religious aspects. [External Link]
My secondary anecdotal evidence is the persistence of religious themes in Japanese media such as manga and anime. Reincarnation in the form of those Shonen stories, gods and even the occasional kami, the common theme of slaying and becoming Gods(uncommon in western media, since in western religious practice gods are supposed to be immortal(has its root in the early days of Christianity and greek philosopher discussions), while in Shinto one can become and kill a god), the mention of Ki(although more in Korean media, but that's the most neighboring country to Japan so some cultural overlap is to be expected), etc.
Third I thought to be aware of several japanese technical steps based on the avoidance of certain themes thanks to their religion, such as high quality alternatives to leather seating, due to a high view of Animals and other pieces of nature and that their local high end watch brand produces watches themed on local nature, because of that same view.
It's at least big enough in Japan: to rebel against [External Link].
This is of course no proof, but now you can see how I came to a contrary conclusion to you.
11 Nov 2024 at 7:51 am UTC
Quoting: Purple Library GuyThat is really hard to see from statistics and I'm not Japanese myself.Quoting: LoudTechieI think most Japanese people's caring about religion is limited to going to a temple at New Year's and deciding whether they want wedding pictures taken in a traditional Japanese look or a Christian/Western style bridal gown look.Quoting: KlaasWell, since they're Japanese upwards mobilized peasants, I would guess they're practitioners of both Buddhism and Shintoism.Quoting: PenglingNintendo behaving like they are here won't change any opinions over on that side of the fence, unfortunately.That is unfortunately very obvious, since this is not the first time that they do what they usually do.
And it is the reason that I'm amused by the data-breach. Like the weird Sgt in It Ain't Half Hot Mum says – Oh dear, how sad, never mind. I wonder if they believe in Karma…
Specifically I think that they're Japanese pure land Buddhists and Shintoists.
Shintoism has no real definition of an afterlife.
Buddhism is quite clear about Karma and reincarnation.
Shintoists believe in ascension through effort.
I think they do believe in Karma, but my knowledge about Japanese religious practice is insufficient to determine whether this results in positive or negative Karma in their eyes if they do.
As such I used anecdotal evidence and the stats to measure religious zeal.
My primary anecdotal "evidence". In this story the artist tells about their interactions with Japanese culture including some religious aspects. [External Link]
My secondary anecdotal evidence is the persistence of religious themes in Japanese media such as manga and anime. Reincarnation in the form of those Shonen stories, gods and even the occasional kami, the common theme of slaying and becoming Gods(uncommon in western media, since in western religious practice gods are supposed to be immortal(has its root in the early days of Christianity and greek philosopher discussions), while in Shinto one can become and kill a god), the mention of Ki(although more in Korean media, but that's the most neighboring country to Japan so some cultural overlap is to be expected), etc.
Third I thought to be aware of several japanese technical steps based on the avoidance of certain themes thanks to their religion, such as high quality alternatives to leather seating, due to a high view of Animals and other pieces of nature and that their local high end watch brand produces watches themed on local nature, because of that same view.
It's at least big enough in Japan: to rebel against [External Link].
This is of course no proof, but now you can see how I came to a contrary conclusion to you.
Palworld dev details the patents Nintendo and The Pokemon Company are suing for
9 Nov 2024 at 9:11 pm UTC
Specifically I think that they're Japanese pure land Buddhists and Shintoists.
Shintoism has no real definition of an afterlife.
Buddhism is quite clear about Karma and reincarnation.
Shintoists believe in ascension through effort.
I think they do believe in Karma, but my knowledge about Japanese religious practice is insufficient to determine whether this results in positive or negative Karma in their eyes if they do.
9 Nov 2024 at 9:11 pm UTC
Quoting: KlaasWell, since they're Japanese upwards mobilized peasants, I would guess they're practitioners of both Buddhism and Shintoism.Quoting: PenglingNintendo behaving like they are here won't change any opinions over on that side of the fence, unfortunately.That is unfortunately very obvious, since this is not the first time that they do what they usually do.
And it is the reason that I'm amused by the data-breach. Like the weird Sgt in It Ain't Half Hot Mum says – Oh dear, how sad, never mind. I wonder if they believe in Karma…
Specifically I think that they're Japanese pure land Buddhists and Shintoists.
Shintoism has no real definition of an afterlife.
Buddhism is quite clear about Karma and reincarnation.
Shintoists believe in ascension through effort.
I think they do believe in Karma, but my knowledge about Japanese religious practice is insufficient to determine whether this results in positive or negative Karma in their eyes if they do.
Palworld dev details the patents Nintendo and The Pokemon Company are suing for
8 Nov 2024 at 4:23 pm UTC
8 Nov 2024 at 4:23 pm UTC
Quoting: stormtuxIn Palworld this was possible before the patent got filled...patents covers game mechanics like catching creatures and riding creaturesFunny, in Ultima Online it was already possible to do this a few decades ago :grin:
Palworld dev details the patents Nintendo and The Pokemon Company are suing for
8 Nov 2024 at 4:16 pm UTC
Every video game company can come after the Pong creator
Palworld was already doing these things, before Nintendo patented them, but according to Nintendo Palworld copied their technology.
In other words according to the things I know about patents this is claiming the defendant has a time machine.
8 Nov 2024 at 4:16 pm UTC
Quoting: YuehSo Pong creator can pursue every video game companies...It's much more fun if Nintendo is right.
Every video game company can come after the Pong creator
Palworld was already doing these things, before Nintendo patented them, but according to Nintendo Palworld copied their technology.
In other words according to the things I know about patents this is claiming the defendant has a time machine.
Manjaro Linux want your system info with their new data collection tool
6 Nov 2024 at 8:25 am UTC
They use reproducible and peer reviewable anecdotes(issues and pull requests) and expert review.
What you present here is a false dilemma.
What you two are comparing is the advantages and disadvantages of using telemetry yes/no, but in this case that doesn't mean they would use different statistics, so although it's true for all statistics it's not "true for all statistics though."
Edit: to put it in the mortal words of Ronald Munroe that's a false dichthomy. [External Link]
6 Nov 2024 at 8:25 am UTC
Quoting: BrokattMost open source projects don't use statistics(, because they've no data).Quoting: KlaasI agree. That is true for all statistics though.Quoting: BrokattTruth is telemetry is really useful for developers and without it's way too easy to make the wrong assumptions.And it is even easier to make wrong assumptions due to telemetry. Calling it a double-edged sword even with consent is putting it mildly.
They use reproducible and peer reviewable anecdotes(issues and pull requests) and expert review.
What you present here is a false dilemma.
What you two are comparing is the advantages and disadvantages of using telemetry yes/no, but in this case that doesn't mean they would use different statistics, so although it's true for all statistics it's not "true for all statistics though."
Edit: to put it in the mortal words of Ronald Munroe that's a false dichthomy. [External Link]
Manjaro Linux want your system info with their new data collection tool
6 Nov 2024 at 8:12 am UTC
On the second I disagree.
A. pc specs can be more personal than you think. HWID's are unique and personally identifying, BIOS release date is a good indicator of when you bought the device and with that of when you had a personal shift requiring more fancy hardware, IP is enough to determine at least your nation, accesibility settings inform about someone's medical condition, Mac adresses inform whose hardware you bought, your device name is often your name, etc.
B. One of the primary selling points of Linux distros is their lack of spying. Lots of people use it, so their data doesn't get send to other parties. These people already made their choice and "opt-ed out" and now they have to do it another time.
C. For debugging it's mostly useless feature request and crash reports help much better there, because it clearly communicates customer demand and what's missing.
It's mostly useful for UI development and prioritization.
Prioritization currently happens on: "how easy is it to find volunteers and/or funds for it" and I don't think devs would like to let that power slip.
It's really useful for UI development, but a better fix for that is to sucker users into doing their own development by providing a forum and desktop setting sharing tools.
Also I don't actually believe they've the data analysis talent available to interpret this data.
It's not really something Os developers are known for.
Edit:
For me the base requirement for any telemetry to be considered acceptable it needs to be opt-in and employ differential privacy. [External Link]
6 Nov 2024 at 8:12 am UTC
Quoting: AdutchmanOn your first point I agree.Quoting: dpanterIn the Netherlands this is the case as well. Why would it be a human rights violation? You're not alive anymore when they do it. You can also always opt-out and this is widely known. The problem is that most people forgot or didn't bother to opt-in, which was costing lives.Quoting: CZiNTrPTIn my country real organ donorship is opt-out and that's right approach as wellWhich country is that? Sounds like human rights violation to me.
As for the telemetry, it doesn't have to be all bad. Telemetry is important for devs to improve a project and like someone earlier in the thread has said, most people that don't care won't opt-in and the ones that do will opt-out. If they make it a clear toggle which is on by default and the data is non-personal, I don't see the issue. We're talking about PC specs here, not address info.
On the second I disagree.
A. pc specs can be more personal than you think. HWID's are unique and personally identifying, BIOS release date is a good indicator of when you bought the device and with that of when you had a personal shift requiring more fancy hardware, IP is enough to determine at least your nation, accesibility settings inform about someone's medical condition, Mac adresses inform whose hardware you bought, your device name is often your name, etc.
B. One of the primary selling points of Linux distros is their lack of spying. Lots of people use it, so their data doesn't get send to other parties. These people already made their choice and "opt-ed out" and now they have to do it another time.
C. For debugging it's mostly useless feature request and crash reports help much better there, because it clearly communicates customer demand and what's missing.
It's mostly useful for UI development and prioritization.
Prioritization currently happens on: "how easy is it to find volunteers and/or funds for it" and I don't think devs would like to let that power slip.
It's really useful for UI development, but a better fix for that is to sucker users into doing their own development by providing a forum and desktop setting sharing tools.
Also I don't actually believe they've the data analysis talent available to interpret this data.
It's not really something Os developers are known for.
Edit:
For me the base requirement for any telemetry to be considered acceptable it needs to be opt-in and employ differential privacy. [External Link]
Manjaro Linux want your system info with their new data collection tool
5 Nov 2024 at 8:27 pm UTC
You opt-out here. [External Link]
5 Nov 2024 at 8:27 pm UTC
Quoting: BlackBloodRumMay 2020. [External Link]Quoting: Mountain ManWith all this doom and gloom talk about the end of Manjaro, I have to ask, what's the best alternative?Gentoo.
(Of course every Linux distro seems to be surrounded by pronouncements of its impending demise, but it rarely comes to pass.)
I know that feels like a meme, but it's really not. This thing is rock solid stable like a mountain, and man switching to it was the best choice I ever made. I don't even get all those little "odd bugs" you normally get on other distros.
You compile all the packages yourself which means you can patch out forced telemetry yourself or disable it at compile time (I do this for KDE). Binary packages are available now, but you lose some customizability.
Anything done in a way you don't like can basically be changed, no questions asked.
Quoting: spymastermattSay what now? I'm from the UK and was last told it was opt-out. I wasn't informed it changed to opt-in. When did this change, and how do I opt out? (My organs are buggered from drinking too much to be useful. Heck, my organs probably couldn't keep a human alive for more than a day.)Quoting: CZiNTrPTIn my country real organ donorship is opt-out and that's right approach as wellYeap. Here in the UK organ donation was swapped to opt-in for the same good reason Manjaro should use opt-in for their telemetry. Lots of people who aren't bothered either way, will never opt-in, but those who care will always opt-out
You opt-out here. [External Link]
EA / Respawn now block Apex Legends from running on Linux and Steam Deck
1 Nov 2024 at 1:54 pm UTC Likes: 2
Theoretical and practical.
Theoretical:
In theory kernel side checking doesn't actually add much.
It can always be edited out in the binary and mathematically users with physical access have root.
In that sense Linux openness doesn't do much damage.
Techinical:
If you ask the anti-cheat makers like easy anti-cheat and battle eye. They will tell you. "No problem."
This hides a lot of complexity here's a small slice of the technical state of the matter:
There're ways to do anti-cheat in a system you don't have superior control over, but each of these ways work on Windows too.
Server side code.
Obfuscation.
Captcha's.
sgx
etc.
Some of these ways are currently in use and others aren't.
Yet Windows has a significant amount of cheaters, so apparently it doesn't work.
I currently suspect only one way of doing this that might be Linux specific and nobody has tried it yet in that sense.
Ring 0- resource hogging(My hypothesis is that you might be able to hash check entire resource states in ways that would if subverted on the same system result in detectable longer load times. You're allowed to ask further I'm pretty proud of the trick.).
On Windows you can't do much you can't do on Linux as an anti-cheat writer, but you can feel safe knowing that you're one of the few with access to the kernel, while in Linux that number is potentially infinite.
By the way:
Kernel checks still work on Linux they're just slightly less effective.
Market-political:
Personally I suspect this is currently what we're encountering.
There're several players in the industry to which Linux gaming is not a profitable business anyway(not enough market share), but an interesting chess piece you can freely move.
EA has chosen to move against Valve who has incorporated the piece in their strategy, so breaking Linux is a good business move.
A comparable much bigger problem in this case is hardware attestation Android keyboxes:
Basically all android phones have hardware backed keys deep in the firmware(TEE).
These keys are the root of trust used for drm, custom Rom blocking, anti-cheat etc..
Each android phone Vendor has their own keys.
In the past Google(Seller of Pixel and Winedivine drm) has revoked several vendor keys(keyboxes), because the devices proved vulnerable to attack and the keys could be extracted out of the device, breaking all the functions reliant on these keys.
Not long ago someone pulled this on the beta version of the Pixel phone. At first Google revoked these key too, but that significantly angered their customers who want to be able to use a phone as such they reinstated the key and now there is a consistent crack for all these functions I mentioned before.
The same has happened before with all Qualcomm devices until 2013.
Google could revoke all these keys, but they would do too much collateral damage and as such they accept the damage.
For this problem I see two fixes(I'm a programmer not a marketer)
Positive reinforcement: grow the Linux userbase and general Linux gaming profit margin.
Negative reinforcement: Launch a fork of Proton/wine that specifically fixes detection attempts in blocked games.
My conclusion: the current primary obstacle for anti-cheat on Linux is market-political and the currently employed method against it is growing the Linux gamer userbase.
Edit:
Also a true and tested way nobody uses to do anti-cheat would be to utilize ASLR(Address space layout randomization).
This works on both Linux and Windows, but with the right features enabled in the kernel Linux does it much better.
It's easy to test for.
This is also something a motivated programmer/Valve could do to make Linux stronger in general and more attractive to anti-cheat.
Implement distribution time ASLR in to their choice a game engine or the Linux kernel.
Currently ASLR is implemented at boot or compile time.
Neither case would be enough for anti-cheat.
Compile time makes people capable of cracking it for entire distros and a bootkit could crack boot ASLR.
What you would need is a distribution script that implements a new seed every download and if you implement it for the kernel also a way to check that we're dealing with a kernel with the feature enabled.
The best way I can think off is a distro signed cryptographic secure hash of the seed used.
Implementing it in the kernel has as "benefit" that it doesn't benefit Windows.
Implementing it in a game engine is more freedom preserving(you can make code modifications of specifically the game hard instead of the entire kernel)
Boot ASLR can be kind of for checked for by checking the bootloader.
The real problem is detecting compile time seed generation and seeds that are distributed with the kernel.
Compile time seed generation can be pretty well detected with a blacklist(the only issue was that it could be too predictable), Seeds distributed with the kernel can be pretty well detected with signing an arbitrary part of the ASLR'ed kernel.
A way this could be improved would be to create assymetric ASLR, so not only verified distros can launch anti-cheat compatible kernels, but that is a dream. I'm not yet convinced that's even possible.
ASLR was designed against return-to-libc attacks. I don't actually think this is the best way(I would advise for VAC(voluntary access control) if programs themselves clearly state what they don't need they can prevent themselves from being exploited with tricks they don't use themselves.
1 Nov 2024 at 1:54 pm UTC Likes: 2
Quoting: TurkeysteaksGenuinely asking here, what is the path forwards for this situation? I do not see how it can be solved. I love linux and the fact it is completely open, but that of course means it's also undoubtedly going to be easier to be malicious in. I will never switch to windows as I haven't for the few decades I've been alive (and we never had many of these games working on linux without a headache back then, aside from ID software <3). I am wondering however if my playable library is going to keep dwindling when it comes to multiplayer games. I love PVP shooters; I have many hours in Titanfall 2, COD WWII, Urban Terror & Wolfenstein, Q3A, even a chunk in Apex and Battlefield 4/V/1 which of course is no longer possible to play.I have several conflicting answers.
Unless something like PlaysafeID actually takes off - and let's be real, how many of us really want to submit our ID to play games? I don't see the pathway to take. Server side anticheat is unfortunately a dream (Poor Counter Strike), and cheats only keep getting more sophisticated. Is this problem solvable?
Theoretical and practical.
Theoretical:
In theory kernel side checking doesn't actually add much.
It can always be edited out in the binary and mathematically users with physical access have root.
In that sense Linux openness doesn't do much damage.
Techinical:
If you ask the anti-cheat makers like easy anti-cheat and battle eye. They will tell you. "No problem."
This hides a lot of complexity here's a small slice of the technical state of the matter:
There're ways to do anti-cheat in a system you don't have superior control over, but each of these ways work on Windows too.
Server side code.
Obfuscation.
Captcha's.
sgx
etc.
Some of these ways are currently in use and others aren't.
Yet Windows has a significant amount of cheaters, so apparently it doesn't work.
I currently suspect only one way of doing this that might be Linux specific and nobody has tried it yet in that sense.
Ring 0- resource hogging(My hypothesis is that you might be able to hash check entire resource states in ways that would if subverted on the same system result in detectable longer load times. You're allowed to ask further I'm pretty proud of the trick.).
On Windows you can't do much you can't do on Linux as an anti-cheat writer, but you can feel safe knowing that you're one of the few with access to the kernel, while in Linux that number is potentially infinite.
By the way:
Kernel checks still work on Linux they're just slightly less effective.
Market-political:
Personally I suspect this is currently what we're encountering.
There're several players in the industry to which Linux gaming is not a profitable business anyway(not enough market share), but an interesting chess piece you can freely move.
EA has chosen to move against Valve who has incorporated the piece in their strategy, so breaking Linux is a good business move.
A comparable much bigger problem in this case is hardware attestation Android keyboxes:
Basically all android phones have hardware backed keys deep in the firmware(TEE).
These keys are the root of trust used for drm, custom Rom blocking, anti-cheat etc..
Each android phone Vendor has their own keys.
In the past Google(Seller of Pixel and Winedivine drm) has revoked several vendor keys(keyboxes), because the devices proved vulnerable to attack and the keys could be extracted out of the device, breaking all the functions reliant on these keys.
Not long ago someone pulled this on the beta version of the Pixel phone. At first Google revoked these key too, but that significantly angered their customers who want to be able to use a phone as such they reinstated the key and now there is a consistent crack for all these functions I mentioned before.
The same has happened before with all Qualcomm devices until 2013.
Google could revoke all these keys, but they would do too much collateral damage and as such they accept the damage.
For this problem I see two fixes(I'm a programmer not a marketer)
Positive reinforcement: grow the Linux userbase and general Linux gaming profit margin.
Negative reinforcement: Launch a fork of Proton/wine that specifically fixes detection attempts in blocked games.
My conclusion: the current primary obstacle for anti-cheat on Linux is market-political and the currently employed method against it is growing the Linux gamer userbase.
Edit:
Also a true and tested way nobody uses to do anti-cheat would be to utilize ASLR(Address space layout randomization).
This works on both Linux and Windows, but with the right features enabled in the kernel Linux does it much better.
It's easy to test for.
This is also something a motivated programmer/Valve could do to make Linux stronger in general and more attractive to anti-cheat.
Implement distribution time ASLR in to their choice a game engine or the Linux kernel.
Currently ASLR is implemented at boot or compile time.
Neither case would be enough for anti-cheat.
Compile time makes people capable of cracking it for entire distros and a bootkit could crack boot ASLR.
What you would need is a distribution script that implements a new seed every download and if you implement it for the kernel also a way to check that we're dealing with a kernel with the feature enabled.
The best way I can think off is a distro signed cryptographic secure hash of the seed used.
Implementing it in the kernel has as "benefit" that it doesn't benefit Windows.
Implementing it in a game engine is more freedom preserving(you can make code modifications of specifically the game hard instead of the entire kernel)
Boot ASLR can be kind of for checked for by checking the bootloader.
The real problem is detecting compile time seed generation and seeds that are distributed with the kernel.
Compile time seed generation can be pretty well detected with a blacklist(the only issue was that it could be too predictable), Seeds distributed with the kernel can be pretty well detected with signing an arbitrary part of the ASLR'ed kernel.
A way this could be improved would be to create assymetric ASLR, so not only verified distros can launch anti-cheat compatible kernels, but that is a dream. I'm not yet convinced that's even possible.
ASLR was designed against return-to-libc attacks. I don't actually think this is the best way(I would advise for VAC(voluntary access control) if programs themselves clearly state what they don't need they can prevent themselves from being exploited with tricks they don't use themselves.
Steam Deck - SteamOS 3.6 officially out with improved performance, Mura Compensation, lots more
28 Oct 2024 at 2:35 pm UTC
You're right to be upset I phrased this really poorly, sorry for that.
Second:
For the developers.
I meant for their own system.
Producing stable software is an admirable goal a lot developers have, but especially for those an unstable distro is a good system to develop on.
The best way to produce a stable outcome is to develop it in an unstable environment until it stays stable even in such harsh conditions(ever changing dynamic libraries, buggy drivers, etc).
For the gamers:
Here I was even worse(, to in the level this is in retrospect actually irrelevant for the point I was trying to make).
I didn't define the level of stability.
You want your system to never crash, lag or experience trouble, while in use.
There a lot of situations when your system isn't in use and you've no issue with it crashing, updating and generally figuring stuff out.
The kind of stability I was referring is the kind NASA or a big cloud provider needs: fire and forget.
There's not a situation the system isn't in use and as such we can't have reboots for updates, we can't have any data corruption ever, etc.
Also for both I threw them in big boxes that don't correspond to everybody in that group.
The point I was trying to make is that stability is just a single feature and one that thanks to the different requirements of different people isn't always the one with the most priority especially when it costs functionality and this isn't bad, but good because we've devised ways to make them benefit from each other.
I failed at that, but now you can at least see a second attempt.
28 Oct 2024 at 2:35 pm UTC
Quoting: tuubiFirst:Quoting: LoudTechieStability is something sysadmins salivate over, but there are lots of other parties like Gamers and developers that don't care about stability and want the newest of the newest tools.That's such an absurd thing to say. I wouldn't want to work with a developer who doesn't care about stability. Nor would I want to be their customer.
And as a gamer, I don't see why I'd want anything but a stable and predictable platfrom to enjoy my games on. That's actually one of the reasons I run Linux.
You're right to be upset I phrased this really poorly, sorry for that.
Second:
For the developers.
I meant for their own system.
Producing stable software is an admirable goal a lot developers have, but especially for those an unstable distro is a good system to develop on.
The best way to produce a stable outcome is to develop it in an unstable environment until it stays stable even in such harsh conditions(ever changing dynamic libraries, buggy drivers, etc).
For the gamers:
Here I was even worse(, to in the level this is in retrospect actually irrelevant for the point I was trying to make).
I didn't define the level of stability.
You want your system to never crash, lag or experience trouble, while in use.
There a lot of situations when your system isn't in use and you've no issue with it crashing, updating and generally figuring stuff out.
The kind of stability I was referring is the kind NASA or a big cloud provider needs: fire and forget.
There's not a situation the system isn't in use and as such we can't have reboots for updates, we can't have any data corruption ever, etc.
Also for both I threw them in big boxes that don't correspond to everybody in that group.
The point I was trying to make is that stability is just a single feature and one that thanks to the different requirements of different people isn't always the one with the most priority especially when it costs functionality and this isn't bad, but good because we've devised ways to make them benefit from each other.
I failed at that, but now you can at least see a second attempt.
Steam Deck - SteamOS 3.6 officially out with improved performance, Mura Compensation, lots more
28 Oct 2024 at 11:42 am UTC
I do know what I guessed:
Valve is/was trying pull a bunch of sprints to compete with Microsoft, Nintendo, Asus and Sony and as such needed to do a lot of innovation.
Why is this easier: faster release cycle and access to the latest and greatest software ready to break on a first moments notice.
I think you're right though in your statement that this could indicate a change in policy.
Maybe they think they've catched up with the competition and are trying to slow down to a stable walk.
We've seen more tactical changes of Valve in the recent past.
Developing features for SteamOS on other devices than the SteamDeck.
ARM investments.
VR tests.
I suspect they plan to release a non-steamdeck vr device running ARCH/GNU/LINUX/Aarch64 and don't want to invest too heavily on SteamDeck maintenance in the future.
Also I severely disagree with @Stella.
Stability is something sysadmins salivate over, but there are lots of other parties like Gamers and developers that don't care about stability and want the newest of the newest tools.
These people are Linux users too and actually pretty useful for these same sysadmins(from the perspective of a sysadmin these people are testers), but they don't know and don't care that it means "well tested".
This is why we have beta releases in the first place.
Once the code passes its development(alpha) tests we throw it to a group of people who don't care about occasional breakage as long it works most of the time and get their crash rapports and patch them.
This is how the xz-backdoor was found and this is why most "beginner friendly" distros are rolling release(they need all kind of cutting edge stuff to look like windows/mac and they were apparently willing to risk losing their data and bricking their computer).
It's also one of the many ways we make certain the "tide lifts all boats".
The people who need software stability get cheap testing and the people who need cutting edge tools get enterprise grade software for cheap(so those enterprises don't have to deal with the bugs).
28 Oct 2024 at 11:42 am UTC
Quoting: EikeI don't know what "people guessed".Quoting: StellaThat's the opposite of what people guessed why Valve's using Arch now, though.Quoting: Mountain ManYup, I'd rather have older stuff that works properly than bleeding edge with tons of bugsQuoting: AsciiWolfNice, but I wonder why they didn't go with Mesa 24.2. Mesa 24.1 is already quite old at this point.As a Linux user, you should know that "old" means "thoroughly tested and stable".
I do know what I guessed:
Valve is/was trying pull a bunch of sprints to compete with Microsoft, Nintendo, Asus and Sony and as such needed to do a lot of innovation.
Why is this easier: faster release cycle and access to the latest and greatest software ready to break on a first moments notice.
I think you're right though in your statement that this could indicate a change in policy.
Maybe they think they've catched up with the competition and are trying to slow down to a stable walk.
We've seen more tactical changes of Valve in the recent past.
Developing features for SteamOS on other devices than the SteamDeck.
ARM investments.
VR tests.
I suspect they plan to release a non-steamdeck vr device running ARCH/GNU/LINUX/Aarch64 and don't want to invest too heavily on SteamDeck maintenance in the future.
Also I severely disagree with @Stella.
Stability is something sysadmins salivate over, but there are lots of other parties like Gamers and developers that don't care about stability and want the newest of the newest tools.
These people are Linux users too and actually pretty useful for these same sysadmins(from the perspective of a sysadmin these people are testers), but they don't know and don't care that it means "well tested".
This is why we have beta releases in the first place.
Once the code passes its development(alpha) tests we throw it to a group of people who don't care about occasional breakage as long it works most of the time and get their crash rapports and patch them.
This is how the xz-backdoor was found and this is why most "beginner friendly" distros are rolling release(they need all kind of cutting edge stuff to look like windows/mac and they were apparently willing to risk losing their data and bricking their computer).
It's also one of the many ways we make certain the "tide lifts all boats".
The people who need software stability get cheap testing and the people who need cutting edge tools get enterprise grade software for cheap(so those enterprises don't have to deal with the bugs).