Just some Internet guy

He/him/them 🏳️‍🌈

  • 0 Posts
  • 32 Comments
Joined 1 year ago
cake
Cake day: June 25th, 2023

help-circle
  • I would literally donate money directly to Valve if I could for all the good selfless work they’re doing.

    Their work on sponsoring DXVK, and Proton’s development, their contributions to make the AMD drivers even more awesome, gamescope, they’ve been driving all the HDR and VR work on Linux, and now they’re also getting even more hands on with Wayland through frog-protocols.

    Meanwhile the others are either doing nothing at all except selling the games, or actively sabotaging Linux gaming and furthering Microsoft’s monopoly like Epic Games is doing with their intrusive anti-cheat.

    Being on Steam is being strongly pro-consumer and the first thing a developer not publishing on Steam does to me is make sure I’m very unlikely to buy their games because at least on Steam I know I won’t get ripped off.

    Couldn’t care less about whiny developers complaining they make slightly less millions in sales for overpriced AAA games, and still impose their own launcher and shit because they only treat Steam like a store and nothing else. I pick what’s good for the players not the developers. If they’re unhappy there’s dozens of indie developers in line to pick up the slack willing to make games I’m willing to pay for.

    EDIT: And a couple hours later, Valve delivers once again: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/RIZSKIBDSLY4S5J2E2STNP5DH4XZGJMR/?sort=date


  • And all that forever too. The developers don’t pay a dime after Steam’s cut to keep the game alive and downloadable and playable. Even Steam keys, you can sell as many as you want outside of Steam, for free.

    The devs can just raise the price by 30% if they feel they really need the money. I’ll pay the extra to have it on Steam and just work out of the box in Proton. Unlike Apple, it’s not a monopoly, nothing stopping anyone from just distributing on their own.


  • Epic is anti-consumer and also anti-Linux, they don’t make any effort to support other platforms, the app is shit.

    Meanwhile, Steam is

    • Actively working with the FOSS community to help preserve old games
      • Kernel improvements for better graphics performance
      • Lots of VR and HDR work
      • Many contributions to the open-source AMD drivers
    • Has been supporting Linux gaming for a decade with no signs of backing down
    • They have a portable Linux gaming console experience, and it’s intentionally left wide open for users to mess with
      • They’ve taken several community features and built them into the OS
    • Their DRM is weak and unintrusive
    • Their anticheat is ununtrusive
    • The sales are pretty good
    • They have tons of features for users:
      • Family sharing
      • Remote Play Together
      • Remote Play
      • Streaming
      • Community forums for every game
      • Mod workshop
      • Matchmaking
      • Steam Chat / Voice Chat / Streaming

    The only appealing thing for EGS is, EGS takes a lower cut from the developers who just pockets it and doesn’t even result in lower prices for users. As a Linux user, praise our Lord GabeN for all the good Valve has done for gamers. Even for the developers, most are quite happy with the services they get back from that 30% cut.

    I’d say the dislike is mainly that for the users, EGS doesn’t bring in anything new or interesting or useful that Steam didn’t already do well, and goes directly against a lot of the good Steam has been doing. It’s just a store that makes big developers slightly more happy.


  • IMO that’s more of a problem with the industry not really caring to support lower specs, or generally not seeing the deck as a real console or platform to target. People still make Switch games and the damn thing was already outdated at launch and they even underclocked it for good measures.

    At 800p you’ve got to start thinking, is most of the detail those games compute even actually visible the on screen? How many PCs does that make obsolete? If the deck can’t run it at 800p, even at 1080p you’re gonna need what, an RTX 2060 for the lowest settings on a PC?

    Some of the example titles don’t even sound like they’re the kind of titles that are made to showcase what your 4090 can do, which logically you’d want as many people as possible to be able to play it.


  • Also, lame article? 😖

    It’s pretty short, it could be improved with benchmarks or at least some examples of how that would be implemented efficiently. Maybe a bit of pros and cons, cursor pagination for example doesn’t handle “go directly to page 200” very well. I’ve also seen some interesting hacks to make offset pagination surprisingly fast with a clever subquery.

    I wouldn’t call it lame though.






  • I’m not saying to use native toolkits like Qt or GTK, those indeed have problems. What React Native does is somewhere in-between: it’s an abstraction that produces decent results between platforms including the web.

    It uses slightly higher level abstractions that work a lot like the web for rendering, you still get your boxes and a subset of CSS properties. But on web it’ll compile to flexbox or grids, on Android it’ll compile to something like a LinearLayout or some other kind of layout the OS understands. On web a <Text> will compile to a <span>, on Android it’ll compile to a native text element. On mobile where you need the performance the most, you otherwise end up rendering a web page that will then eventually end up doing the same thing back to display it natively, but with all the downsides of a web view.

    This performs way better with basically no downside for the web version, has the majority of the flexibility one needs for responsive layouts but it’s way more lightweight when you do target native. On native you can just render it all yourself for really cheap, like any native toolkit would. You’re your own toolkit.

    They will never look native, but at least all the rendering will be native. Most companies have their custom UI theme anyway, native widgets rarely gets used anyway.

    We’re talking Electron replacement after all, it’s not like apps made with it look anything native. But if at least they performed like native apps by skipping the web views and all the baggage it brings with it, that’d be great.


  • For the end user, its main weakness is that complex pages can be pretty slow to render if not coded well. It’s not that bad either. You wouldn’t be like “oh this is a React site, yuck”, they’re all like that these days for the reasons you’d expect.

    As for React Native, its main issue is the communication between the JavaScript browser-ish environment and the Java/Kotlin native environment that can be costly because every has to be serialized (meaning, converted to some type of data structure both sides can understand) and deserialized, so complex screen updates don’t scale too well.

    It’s easy for developers to accidentally trigger much bigger and much more expensive rerenders than expected. If you see whole second long page hangs on some websites as new content loads in that’s usually what happened.


    For developers, it’s complicated, you kind of need to experience it to understand the footguns.

    React was born to solve one particular problem at Facebook: how can we make it so any developer can jump on any part of the UI code and add features without breaking everything. One of the most complicated aspects of a website is state management, in other words, making sure every part of the page are updated when something changes. For example, if you read a message in your inbox, the unread count needs to update a couple places on the page. That’s hard because you need to make sure everything that can change that count is in agreement with everything that displays that count.

    React solves that problem by hiding it away from you. Its model is simple: given a set of inputs, you have a function that outputs how to display that. Every time the value changes, React re-renders every component that used that value, compares it with the previous result, and then modifies the page with the updated data. That’s why it’s called React, it reacts to changes and actions.

    The downside of that is if you’re not very careful, you can place something in a non-ideal spot that can cascade into re-rendering the entire page every time that thing updates. At scale, it usually works out relatively okay, and it’s not like rendering the whole page is that expensive. There’s an upper cap on how bad it can be, it won’t let you do re-render loops, but it can be slow.

    I regularly see startups with 25MB of JavaScript caused by React abuse and favoring new features over tracking down excessive renders. Loads the same data 5 times because “this should only render once” and that turned out to be false, but it displays correctly. I commonly see entire forms being re-rendered every character you type because the data is stored in the form’s state, so it has to re-render that entire tree.

    But it’s not that bad. It’s entirely possible to make great and snappy sites with React. Arguably its problem isn’t React itself but how much it is associated with horrible websites because of how tolerant to bad code it is. It’s maybe a little bit too easy to learn, it gives bad developers an undeserved sense of confidence.

    E: And we have better solutions to this such as signals which SolidJS, Vue and Svelte make heavy use of. Most of the advantages with less problems.


    Anyway, that part wasn’t relevant at all why I don’t like React. The point is, skip the web, you don’t really need the web. React Native skipped the whole HTML part, it’s still JSX but for native app styled components for UI building. The web backend worked very well, your boxes became divs with some styles. It pretty much just worked. Do that but entirely in Rust since Rust can run natively on all platforms. Rust gets to skip all the compromises RN needed, and skip the embedded browser entirely. Make it desktop first then make the web version, it’ll run just as well and might even generate better code than if a human wrote it. Making the web look native sucks but making native fit web is a lot easier than it looks. Letting go of HTML and CSS was a good call from React Native.


  • I wish we went the other way around: build for native and compile to HTML/CSS/WASM.

    For me the disadvantage of Electron is well, it doesn’t have any advantage or performance improvement over the browser version for 99% of use cases, and when you shove that on a mobile phone it performs as horribly as the web version.

    People already use higher level components that ends up shitting out HTML and CSS anyway, why not skip the middleman and just render the box optimally from the start? Web browsers have become good, but if you can skip parsing HTML and CSS entirely and also skip maintaining their state, that’s even better.

    I had the misfortune of developing a React Native app, and I’d say thinking in terms of rows and columns and boxes was nice. Most of RN’s problems are because they still run JS and so you have to bundle node and have the native messaging bridge, and of course that it’s tied to the turd that is React. But zero complains about the UI part when it doesn’t involve the bridge: very smooth and snappy, much more than the browser. And the browser version was no different than standard React in performance.

    I like that it’s not yet another Chromium one at least.


  • API documentation isn’t a tutorial, it’s there to tell you what the arguments are, what it does and what to expect as the output and just generally, what’s available.

    I actually have the opposite problem as you: it infuriates me when a project’s documentation is purely a bunch of examples and then you have to guess if you want to do anything out of the simple tutorial’s paved path. Tell me everything that’s available so I can piece together something for what I need, I don’t want that info on chapter 12 of the example of building a web store. I’ve been coding for nearly two decades now, I’m not going to follow a shopping cart tutorial just in the off chance that’s how you tell how the framework defines many to many relationships.

    I believe an ideal world has both covered: you need full API documentation that’s straight to the point, so experienced people know about all the options and functions available, but also a bunch of examples and a tutorial for those that are new and need to get started and generally learning how to use the library.

    Your case is probably a bit atypical as PyTorch and AI stuff in general is inherently pretty complex. It likely assumes you know your calculus and linear algebra and stuff like that so that’d make the API docs extra dense.




  • Some of those keys are public knowledge and only serves to tie what client it is (Chromium, Firefox, Safari probably) or otherwise stolen from one of those. This is a safe browsing API key, it’s used to check if sites have been marked as phishing/scam/etc and is used to warn users that the site is known to be malicious. Others are used to tie analytics or ads to the app, so it goes into the right developer’s account metrics.

    I wouldn’t call those leaked, they’re meant to be embedded into apps and aren’t considered as secret keys.

    It’s common practice to use API keys like that even if they’re not so secret, just for the sake of tracking which app is making what requests and so people can’t just openly use the API. You can easily shut down unapproved clients by just rolling out a new key, and it causes an annoying whack-a-mole game to constantly have to extract them from an APK.


  • Some of these are engineered to be addicting especially loot crates and stuff. A lot of them are just genuinely good.

    They mention Minecraft, pretty sure that one was addicting since day 1 and completely unintentionally so. It’s just genuinely fun and you can spend hours in it easily. Same with Factorio.

    Not exactly a new phenomenon, I’ve seen my own parents up at 4am just because they wanted to sneak a peek at the new level they reached. My mom had hand drawn and annotated the entire Zelda 1 map. For a little bit, that NES basically ran on a UPS to not lose their progress.

    For some reason US parents always want to shift the blame to companies for their own failures. It’s her own damn fault she let this get out of control for 10 fucking years. Just like those that park their kids on an iPad all the time and then sues because their kid spends too much time on the iPad and cry out in the news how iPad babies are so bad. Who’s given them the damn iPad?



  • Also replying to that bit:

    and job search is impossible as a person with anxiety and possibly autism?

    Don’t give up, job hunting is super fucked up right now with the market flooded with good engineers freshly laid off FAANG and other big companies.

    Autism sucks hard at times, but I don’t think I would be where I am without. Use it to your advantage, your abstract computer knowledge can grow much further than most people can possibly care to get into.


  • Story points are bullshit and I just hope it’s not the sole metric you’re judged on, or at least your team don’t see it that way. If you do, definitely try to steal a bunch of easy tickets to even out the playfield.

    How many story points can I complete? I don’t know because that’s a hard no for my team, but if we did, probably would not have many points either unless you assign like hundreds of points to my tickets. Some take me weeks and months to get through.

    Why? Because I get assigned all the incredibly cursed tickets, and those get assigned to me for a reason: they’re my kind of specialty and I’m the senior on the team with the skills to tackle them. And my performance reviews still say I exceed expectations. I complete those in record time, comparatively.

    I deal with and fix things most people don’t even dare to touch. It’s a well known fact all the way to the CTO and other senior staff of adjacent teams. It’s just, you can’t break down tasks to half day tickets when all you know is there’s a giant rabbit hole and you can’t see how deep it is until you start digging into it. I’m the guy that can just pull out GDB and strace and debug the interpreter that runs the software. My colleagues write standard PHP/NodeJS meanwhile I go browse the PHP and V8 source code to get down deep into why things break, report and fix bugs upstream. NodeJS crashing on a SIGPIPE on a socket that’s already closed? Yep, figured it out down to the exact series of syscalls that led there. Sometimes I have people from teams I never talked to reach out to me with their problems, because when you’re real stuck, you go get Max’s input on it.

    Ultimately, you should talk about that with your manager. Is your manager happy with your performance? Does your team seem frustrated with your performance? It’s very possible you get the tougher ones because people know you can handle those. If you’re struggling that badly and somehow you end up with the hard tickets, your manager is dropping the ball hard and not setting you up for success.