• 0 Posts
  • 19 Comments
Joined 2 years ago
cake
Cake day: March 23rd, 2025

help-circle

  • Not really. Games have very similar security implications as any other server/client software.

    You are right now reading on exactly such a system, which is open source, and still you don’t see massive amounts of hacks targeting lemmy or piefed.

    The premise is simple: Never trust the client. The border you have to defend isn’t the border between the client software and the user, but the one between the client and the server. Always treat the client software as compromised.

    In terms of games that means:

    • All game state calculation happens on the server. The client sends to the server what it wants to do, the server sends what happens. So instead of the client sending “The player is now at position XY”, it sends “The player is walking forwards”. The server calculates the speed, distance and new position and returns that to the client.
    • The server only sends the client things the player should know. If the enemy unit is not visible, it is not sent to the client.

  • That’s what buggs me about the situation. Physical media doesn’t matter one bit.

    There’s nothing about physical media that conferrs any kind of ownership over the copy. Already way back in 2012 I bought an used copy of Skyrim only to find out when trying to install it that it used Steam and the CD key was already tied to the previous owner’s Steam account. I had the physical media, but it was worthless to me.

    What we should be fighting (or put our money towards) is DRM-free copies, like what GOG sells. If you really fetishize plastic disks nobody’s stopping you from burning a copy of the DRM-free installer onto one, or you can put it on your NAS, the cloud or where the sun don’t shine.


  • That’s a bit of a weird argument to make.

    We were talking about PCs with preinstalled OSes. How often do you come across DIY-built PCs with preinstalled OS?

    If you select your own components you never have a preinstalled OS.

    Also, most people who switch from Windows to Linux do so on existing hardware. It’s rare for people to buy a completely new PC to try out an OS. Maybe if €1000+ is something you shell out on a whim, but not if you actually work for your money.

    For existing hardware you always have the hardware lottery on Linux.

    Perhaps the perceived problem would fade if we taught people that computers and operating systems are not all equal, and that just as MacOS is more likely to run on a machine made for it, Linux is more likely to run on a machine made for it. (Edit: The same is true for Windows, for what it’s worth.)

    Congratulations, you just happened to get the point that I made. And for some reason you thought that was a gotcha.

    My argument was that if Linux came preinstalled on machines (apart from the current selection of tiny boutique manufacturers), these machines would be configured by the manufacturer to include only components that work well with Linux, which is not the case if you use a device that doesn’t have manufacturer support for Linux.


    All in all you ended up at the whole point I was making, but somehow you first had to claim that it’s all nonsense.


  • The “doesn’t come preinstalled” part is still huge, combined with the “doesn’t have first-party device manufacturer support”.

    If you buy a PC with Windows preinstalled, that doesn’t only mean that you don’t have to install Windows, but also the whole set of hardware in there will work just fine under Windows. They don’t put a fingerprint reader in there that doesn’t have a Windows driver, or a GPU with bad Windows driver support.

    And yes, most hardware natively works pretty well under Windows, but the manufacturer taking care that they only select components that work fine under Windows is a big part of why there isn’t a hardware lottery under Windows.


  • Yeah, that’s mostly a regulation/legal incentives situation, combined with lack of education on the side of the execs.

    It is possible to sell devices as “defective”, even if they aren’t defective. That way you don’t have warranty or other legal obligations.

    Similar story with the “Scrap the whole device for data privacy reasons”. That’s not a thing. Scrapping the storage media, sure, totally. Scrapping the mainboard, case and power supply? That’s crap.

    But the main issue is that there’s no incentive for companies to reuse devices versus scrapping them. So they scrap the whole thing without regards to anything else, because it’s a single decision that requires no further thought und it’s cheap enough that it doesn’t matter.

    If they’d have to pay for full recycling cost, so the cost for actually turning 100% of the device back into usable raw components, then they will instantly start giving those away for free.



  • He’s using simple examples that everyone knows and understands instantly. It’s like using a minimal test case to report a bug. In most cases a minimal test case is also nonsensical on its own, but it’s used to show an issue that occurred in a more complex context without overloading the reader with useless garbage info that doesn’t contribute to the point at hand.




  • I’m kinda surprised that pretty much nobody who commented here seems to have understood the point of the post.

    It wasn’t about readability at all.

    It was about designing APIs that the IDE can help you with.

    With RTL syntax the IDE doesn’t know what you are talking about until the end of the line because the most important thing, the root object, the main context comes last. So you write your full statement and the IDE has no idea what you are on about, until you end at the very end of your statement.

    Take a procedural-style statement:

    len(str(myvar))

    When you type it out, the IDE has no idea what you want to do, so it begins suggesting everything in the global namespace starting with l, and when you finish writing len(, all it can do is point out a syntax error for the rest of the line. Rinse and repeat for str and myvar.

    Object-oriented, the IDE can help out much more:

    myvar.tostring().length()

    With each dot the IDE knows what possible methods you cound mean, the autocomplete is much more focussed and after each () there are no open syntax errors and the IDE can verify that what you did was correct. And it you have a typo or reference a non-existing method it can instantly show you that instead having to wait until the end of the whole thing.



  • Did we read the same blog post?

    Not a single time did OOP talk about readability. That was not a point at all, so I don’t know why you are all about readability.

    It was all about having a language that the IDE can help you write in because it knows what you are talking about from the beginning of the line.

    The issue with the horrible one-liner (and with your nicely split-up version) is that the IDE has no idea what object you are talking about until the second-to-last non-whitespace character. The only thing it can autocomplete is “diffs”. Up until you typed the word, it has no idea whether sum(), all(), abs(), <, >, or for-in actually exist for the data type you are using.

    If you did the same in Java, you’d start with diffs and from then on the IDE knows what you are talking about, can help you with suggesting functions/methods, can highlight typos and so on.

    That was the whole point of the blog post.


  • The argument is not silly, it totally makes sense, and your point even proves that.

    A lot of libraries use module-level globals and if you use from imports (especially from X import *) you get exactly that issue.

    Yes, many more modern APIs use an object-oriented approach, which is left-to-right, and that’s exactly what OOP is argueing for. If you notice, he didn’t end the post with “Make good languages” but with “Make good APIs”. He highlights a common problem using well-known examples and generalizes it to all APIs.

    The auther knows full well that this blog post will not cause Python to drop the List comprehension syntax or built-in functions. What he’s trying to do is to get people to not use non-LTR approaces when designing APIs. All the points he made are correct, and many are even more pressing in other languages.

    For example, for a hobby project of mine I have to use C/C++ (microcontrollers). And this problem is huge in C libraries. Every function is just dumped into the global name space and there’s no way to easily find the right function. Often I have to go to google and search for an external documentation or open up the header files of a project to find a function that does what I want, instead of being able to just follow the IDE autocomplete on an object.

    And sure, if I know every library and framework I use inside out and memorized all functions, methods, objects, variables and fields, then it’s easy, but unless you work 30 years in a bank where you maintain the same old cobol script for decades, that’s not going to happen.


  • It’s got nothing to do with being a beginner. I’ve been working as a professional software developer for ~15 years now and still I have to use new libraries/frameworks/in-house dependencies quite frequently. I know how to get the length of a string, and so does the author of the article.

    But that’s why it’s a simple example and nothing more, and it applies to everything else. We write left to right, and IDEs autocomplete left to right, so it makes sense for languages to be designed to work that way.

    There’s a lot of reasons why Java works much better with IDEs than python, and this is one of them.


    Besides that, it is best practice to show problems on simple, easy to follow use cases that highlight exactly the problem in question without further fluff. It’s expected that a non-beginner can abstract that problem into more difficult use cases, so I don’t think OOP did anything wrong with choosing string length as an example.