Latest Comments by EagleDelta
Putting games across multiple stores is not easy, as developers keep noting recently
24 January 2019 at 4:53 pm UTC
24 January 2019 at 4:53 pm UTC
I'll probably get slapped by a gamedev somewhere, but.... why not have a CI or Build pipeline that does this work for you (where possible of course). Hit a button and the uploads to the different stores starts.
The Linux market share on Steam is at a 14 month high as of September 2018
2 October 2018 at 3:03 pm UTC Likes: 2
2 October 2018 at 3:03 pm UTC Likes: 2
I think it's important to remember that these numbers are only for the Steam Hardware Survey, which still seems to be pretty sporadic on how often it appears to Linux users. Where Proton will make most of its difference is in reports to developers on Linux users.
Action-adventure platformer 'Chasm' has finally finished production
28 June 2018 at 4:56 pm UTC Likes: 3
It doesn't make sense because we're reading it backwards. For some reason the comments read from bottom up rather than top down. Discord Games LLC is replying to the comment below it asking about XBone and Switch.
28 June 2018 at 4:56 pm UTC Likes: 3
Quoting: liamdaweQuoting: TiedemannI don't understand the difference between the May comment and this:That makes literally no sense. I will reach out to them again.
https://www.kickstarter.com/projects/discordgames/chasm/posts/2218048
It doesn't make sense because we're reading it backwards. For some reason the comments read from bottom up rather than top down. Discord Games LLC is replying to the comment below it asking about XBone and Switch.
A Linux version of Cosmic Star Heroine is still planned, moving to a higher priority
4 June 2018 at 3:33 am UTC
4 June 2018 at 3:33 am UTC
It took them a year to get just the PS4/PSVita versions done since release and still have to do XBone, Linux, and Mac. They've even mentioned a Switch version, but also noted that it'd have to be outsourced as they don't have enough time to also do an in-house Switch version with the other stuff on their plate. To add to that, I think one of the main developers and his wife (who also work on the games) had a kid during the last year or just before release, which (I can attest to) probably significantly reduced their ability to work on Zeboyd Games projects.
We’ve teamed up with GOG for the Ubuntu 18.04 release, we have some keys to give away
27 April 2018 at 11:55 am UTC
27 April 2018 at 11:55 am UTC
I personally am excited for today's release of System76's Pop!_OS 18.04.
Also, "I love DRM free games!"
Also, "I love DRM free games!"
Steps we're taking as a site for GDPR compliance
21 April 2018 at 5:12 am UTC
That's not exactly accurate yet. The GDPR rules are so broad in their wording with too many questions on what it covers and doesn't could limit innovation. Distrubuted systems that store "personal data" like username/email/etc for history reasons (like Git) could be seen as required to be compliant. The problem is there is absolutely no way to enforce that.
In case readers don't know, Git is a source code control system that is designed to be largely de-centralized. Every user working on a git project keeps their own copy apart from the server. In the case of many FOSS projects, there are also many copies on a server(s). Github, Gitlab, Atlassian, etc could be forced to removed references to names/emails in the git history, but that would break every copy of that project everywhere else AND the forced change could simply be undone by a user with permissions force-pushing to an existing branch to an entirely new branch that still contains the user data (in this case a name/username and an email). Additionally, Github/Gitlab/etc could not force those changes downstream to a developer's Desktop/Laptop/Server without breaking the exact law they were trying to be compliant with.
So, how does GDPR apply to distributed data systems?
21 April 2018 at 5:12 am UTC
Quoting: callciferOnly if your "innovation" is based on harvesting people's data without their consent and/or against their will. GDPR simply asks you to:
- have an actual, justifiable use case for using personal data
- obtaining explicit, narrow, opt-in constent (so no pre-checked checkboxes), separately for all use cases
- and disallowing you from refusing service to users who don't consent to your data collection
Basically, the regulation says don't do creepy shit with people's personal data and if your "innovation" depends on doing just that, I'm perfectly happy for it to get out of the EU.
---
All that said, it's highly unlikely for any member state to actively go after mom and pop businesses; compliance is expected from everyone but the fines are mostly aimed at data collecting giants like Google, Facebook, Microsoft etc who will most definitely be complying as none of them want to be made an example of.
That's not exactly accurate yet. The GDPR rules are so broad in their wording with too many questions on what it covers and doesn't could limit innovation. Distrubuted systems that store "personal data" like username/email/etc for history reasons (like Git) could be seen as required to be compliant. The problem is there is absolutely no way to enforce that.
In case readers don't know, Git is a source code control system that is designed to be largely de-centralized. Every user working on a git project keeps their own copy apart from the server. In the case of many FOSS projects, there are also many copies on a server(s). Github, Gitlab, Atlassian, etc could be forced to removed references to names/emails in the git history, but that would break every copy of that project everywhere else AND the forced change could simply be undone by a user with permissions force-pushing to an existing branch to an entirely new branch that still contains the user data (in this case a name/username and an email). Additionally, Github/Gitlab/etc could not force those changes downstream to a developer's Desktop/Laptop/Server without breaking the exact law they were trying to be compliant with.
So, how does GDPR apply to distributed data systems?
Steps we're taking as a site for GDPR compliance
20 April 2018 at 3:18 pm UTC Likes: 2
20 April 2018 at 3:18 pm UTC Likes: 2
Far worse than backups (I just thought about this) is the Right to Erasure in something like Git.
Git being a distributed system used by many FOSS projects and Companies to version source code, simply cannot easily adhere to the right to erasure, if at all.
Simply take a popular project on Github that has been forked over 100 times just on Github (not counting local forks that companies and/or people have). To erase a user from all the history would not only be difficult, but nigh impossible and even then, simply changing git history breaks every copy of that codebase on Github, Gitlab, local git, etc and can be undone by a user simply doing a force push to a new branch.
Not sure how projects, companies, and services will handle data models like Git.
Git being a distributed system used by many FOSS projects and Companies to version source code, simply cannot easily adhere to the right to erasure, if at all.
Simply take a popular project on Github that has been forked over 100 times just on Github (not counting local forks that companies and/or people have). To erase a user from all the history would not only be difficult, but nigh impossible and even then, simply changing git history breaks every copy of that codebase on Github, Gitlab, local git, etc and can be undone by a user simply doing a force push to a new branch.
Not sure how projects, companies, and services will handle data models like Git.
Steps we're taking as a site for GDPR compliance
20 April 2018 at 2:50 pm UTC Likes: 6
20 April 2018 at 2:50 pm UTC Likes: 6
While I applaud the EU for actually doing something about privacy, some of these measures in GDPR show that they don't understand how technology works. There are simply some forms of data that cannot be removed or hidden without breaking applications or websites. Database backups come to mind with the right to remove all data from all time. That's simply not financially feasible for many companies.
Think about this, a company is required by a non-EU state to keep certain data from all records of visitors that logged into a site in the last 24 months. An EU citizen requests all their data to be removed, that would include not just their data, but any data that links to them (including backups). As many backups are not stateful pieces of data you can just open and delete data from, a company/org now has to have enough money to pay for the processing power to:
Now, I have an issue with the way many companies handle our private data, but there is a certain point at which privacy IS the responsibility of the user in question, NOT the company or service they use. A Public Facebook profile is just that: PUBLIC. Once that information is out there, no amount of data removal will remove it entirely from the internet. It may remove it from Facebook's servers (for example), but any number of other people could have gathered that data easily (without needing any special API keys or access), ESPECIALLY if a user made that data available on a public page.
Think about this, a company is required by a non-EU state to keep certain data from all records of visitors that logged into a site in the last 24 months. An EU citizen requests all their data to be removed, that would include not just their data, but any data that links to them (including backups). As many backups are not stateful pieces of data you can just open and delete data from, a company/org now has to have enough money to pay for the processing power to:
- Delete a user's data (not a big deal)
- Delete links to that user in other user's data (a bit more difficult, depending on how those links exist)
- Delete all history of that user. This last one is incredibly difficult as it requires the ability to restore/open every backup from the entire history since that user was created, delete their data, then save NEW backups.... all without losing service.
Now, I have an issue with the way many companies handle our private data, but there is a certain point at which privacy IS the responsibility of the user in question, NOT the company or service they use. A Public Facebook profile is just that: PUBLIC. Once that information is out there, no amount of data removal will remove it entirely from the internet. It may remove it from Facebook's servers (for example), but any number of other people could have gathered that data easily (without needing any special API keys or access), ESPECIALLY if a user made that data available on a public page.
Intel launches their new CPUs with Radeon RX Vega M Graphics along with two new 'NUC' mini-pc models
10 January 2018 at 5:02 pm UTC
However, this is a case where the semantics of "Design flaw" vs "Bug" is important. A "Bug" implies the core issue can be fix though some sort of code update (be that firmware or software). The fact that it is a design flaw means that Intel cannot fix the issue now without stopping all business, which would probably cause a loss of sales too high to continue. What they did (outside of PR) is the best thing they could've done in the circumstances: Notify Software vendors and help with patches that mitigate or block the design flaw, followed by steps to designing new chips to not have that flaw..... the key problem with that is this: Designing, building, coding and releasing new CPUs is a multi-year process and we won't see a CPU from Intel for some time that no longer has that flaw.
I can't (and won't) argue with this. All I can say is that I require hard facts before I will make this assumption, right now all we have is circumstantial evidence and bad PR, neither of which would hold up in court (I still stand by the mantra of "Innocent until proven guilty in a court of law" ).
10 January 2018 at 5:02 pm UTC
Quoting: scaineJust to be clear here - Meltdown is a vulnerability that takes advantage of a bug in Intel's chips. Call it a "design flaw" if you're feeling kind, but it's a hardware bug.
However, this is a case where the semantics of "Design flaw" vs "Bug" is important. A "Bug" implies the core issue can be fix though some sort of code update (be that firmware or software). The fact that it is a design flaw means that Intel cannot fix the issue now without stopping all business, which would probably cause a loss of sales too high to continue. What they did (outside of PR) is the best thing they could've done in the circumstances: Notify Software vendors and help with patches that mitigate or block the design flaw, followed by steps to designing new chips to not have that flaw..... the key problem with that is this: Designing, building, coding and releasing new CPUs is a multi-year process and we won't see a CPU from Intel for some time that no longer has that flaw.
Quoting: scaineAnd yes, I am assuming that Intel knew about this years ago. I'm assuming that based on the "conspiracy theory" I mentioned in my earlier comment. Might be true, no idea.
I can't (and won't) argue with this. All I can say is that I require hard facts before I will make this assumption, right now all we have is circumstantial evidence and bad PR, neither of which would hold up in court (I still stand by the mantra of "Innocent until proven guilty in a court of law" ).
Intel launches their new CPUs with Radeon RX Vega M Graphics along with two new 'NUC' mini-pc models
9 January 2018 at 3:06 am UTC Likes: 1
Again, you're assuming that Intel, AMD, and ARM knew about the risk/flaw before they were notified of it. I can tell you now that in most cases they don't know until someone notifies them. There are specific procedures for reporting bugs/flaws that lead to vulns/exploits. To the point where the MSSP I work for has explicity told me that the one thing I cannot do when contributing back upstream is open an issue/ticket on a public issue tracker if the issue is security related. It must be researched, evaluated, and sent to the project/organization/company directly until the risk of the issue is known and can be safely released to the public.
Are there other things Intel should have done related to how the PR was handled regarding the Meltdown and Spectre exploits - absolutely. But don't pretend to know all the ins and outs of how this works. I'm in the InfoSec field and even I don't know everything.
9 January 2018 at 3:06 am UTC Likes: 1
Quoting: scaineApart from someone trying to use Twitter to explain such a technical subject, I completely agree with you. BUT, while that design decision was made as long ago as 1995 when security was 99th on a list 100 priorities, this is 2018 now and Intel (and AMD and probably to a certain extent ARM) can only be described as wilfully negligent in overlooking this behaviour in the modern day.
As I said earlier, I suspect that Intel knew about this much earlier than June, probably for years and kept a lid on it. Their pushing KASLR so hard (for unrelated attacks, such as KRACKS and the whole Intel ME cock up) was probably done in the hope that a software remedy would be found and accepted early, so that they wouldn't have to acknowledge the extent, reach and scope of this hardware design flaw.
Again, you're assuming that Intel, AMD, and ARM knew about the risk/flaw before they were notified of it. I can tell you now that in most cases they don't know until someone notifies them. There are specific procedures for reporting bugs/flaws that lead to vulns/exploits. To the point where the MSSP I work for has explicity told me that the one thing I cannot do when contributing back upstream is open an issue/ticket on a public issue tracker if the issue is security related. It must be researched, evaluated, and sent to the project/organization/company directly until the risk of the issue is known and can be safely released to the public.
Are there other things Intel should have done related to how the PR was handled regarding the Meltdown and Spectre exploits - absolutely. But don't pretend to know all the ins and outs of how this works. I'm in the InfoSec field and even I don't know everything.
- Steam Controller 2 is apparently a thing and being 'tooled for a mass production' plus a new VR controller
- Unofficial PC port of Zelda: Majora's Mask, 2 Ship 2 Harkinian has a big new release out
- Half-Life: Blue Shift remake mod Black Mesa: Blue Shift - Chapter 5: Focal Point released
- Linux kernel 6.12 is out now with real-time capabilities, more gaming handheld support
- Steam Deck OLED: Limited Edition White and Steam Deck Australia have launched
- > See more over 30 days here
-
S.T.A.L.K.E.R. 2: Heart of Chornobyl review - works on …
- Shmerl -
S.T.A.L.K.E.R. 2: Heart of Chornobyl review - works on …
- Trias -
S.T.A.L.K.E.R. 2: Heart of Chornobyl review - works on …
- Shmerl -
S.T.A.L.K.E.R. 2: Heart of Chornobyl review - works on …
- Trias -
S.T.A.L.K.E.R. 2: Heart of Chornobyl review - works on …
- Shmerl - > See more comments
- Types of programs that are irritating
- Cyril - Weekend Players' Club 11/22/2024
- StoneColdSpider - Our own anti-cheat list
- Liam Dawe - Spare gog keys
- on_en_a_gros - What do you want to see on GamingOnLinux?
- dpanter - See more posts
View cookie preferences.
Accept & Show Accept All & Don't show this again Direct Link