• 0 Posts
  • 35 Comments
Joined 1 year ago
cake
Cake day: July 23rd, 2023

help-circle



  • I did some cursory searches to find the actual arguments and came up blank. It’s important to note this isn’t the standard “video games cause violence” lawsuit that has absolutely no merit. This is different. The summary presented in articles is that this gun manufacturer explicitly marketed their product for things like this using a sophisticated campaign. If I understand the summary correctly, it therefore hinges on both the marketing of this specific gun and its presence across the digital landscape. The parents aren’t going after shooting in games; they’re going after a company that actively markets its products on social media and in video games.

    It’s novel. I’m kinda skeptical because the solution would have to limit product placement and advertisement which has a massive lobby. There’s also nothing that really says “this specific gun leads to violence” without implicitly relying on the whole “video games cause violence” which is bullshit.






  • This doesn’t appear to cover the cost of the electricity it would take to keep your stuff running. There is no way to pay anything out at all. Seems like a pretty straightforward pump-and-dump where the end users are collecting imaginary points while some company abuses their resources. Every blog and Reddit post I looked at to try to understand this was full of referral links. Equally classic sign of pump-and-dump pyramid scheme.




  • I don’t think the contention is that the title is wrong. I think the contention is that the conclusion you draw is wrong. The implication of people playing games released more than six years ago is that the game is over and done. Live service games with regular releases do not fit the traditional definition of a game release so it is difficult to compare the player base of Half-Life 2, CS:GO, LoL, Borderlands 3, and Fortnite. A huge playerbase for an offline game with no updates is a big deal. A huge playerbase for an online game with regular updates just doesn’t seem like a proper comparison.

    The article touches this to an extent.



  • My stance has been that, just as long as I’m interviewing with someone, I’m happy to do it, up to an undetermined time threshold. A screening interview, a tech screen, and then a bunch of panels is what I expect from a solid firm. Just as long as I’m interviewing with someone, I have a lot of opportunities to learn myself. I will also occasionally do a take home if and only if there’s a novel problem I want to solve related to that take home (eg I want to learn a library related to the task) but this is very rare.

    As a hiring manager, I try to keep things to a hiring screen, a tech screen, a team interview, and a culture interview. My team is small. I don’t want to spend more than three hours of someone’s time (partially because I can’t really afford to spend more than that myself per candidate or lose more team hours than that). My tech screens are related to the things I actually need people to do, not random problems you’ll never see.

    My assumption is that a good dev has lots of opportunity and I am in competition with everywhere else. I need to present the best possible candidate experience. Big companies with shitty employee experience telegraph that by presenting a shitty candidate experience, which is where the employee experience begins. You can’t have a good customer focus without starting from a good employee focus.





  • The issue here is that Canonical pushed the snap install without warning about its reduced functionality. I don’t think highlighting a wildly different experience between a snap install and the Docker experience people are used to from the standard package install is “bashing it just because it’s popular to hate on snap.” For example, if you take a fresh Ubuntu server 22 install and use the snap package, not realizing that snaps have serious limitations which are not explicitly called out when the snap is offered in the installation process, you’re going to be confused unless you already have that knowledge. It also very helpfully masks everything so debugging is incredibly difficult if you are not already aware of the snap limitations.


  • This is really dependent on whether or not you want to interact with mounted volumes. In a production setting, containers are ephemeral and should essentially never be touched. Data is abstracted into stores like a database or object storage. If you’re interacting with mounted volumes, it’s usually through a different layer of abstraction like Kibana reading Elastic indices. In a self-hosted setting, you might be sidestepping dependency hell on a local system by containerizing. Data is often tightly coupled to the local filesystem. It is much easier to match the container user to the desired local user to avoid constant sudo calls.

    I had to check the community before responding. Since we’re talking self-hosted, your advice is largely overkill.


  • I made the same comment when I saw it was nominated. It’s Fallout 4 in space with both free base building (outposts) and grid base building (ships). The procedural generation of locations is reminiscent of Arena. The class system is a simpler version of Skyrim and Fallout 4. The story is cliche science fiction using mechanics from earlier Bethesda titles. The dogfights are decades old. The drudgery of running around forever for a simple objective hails back to earlier titles like Assassin’s Creed: Odyssey and similar Ubisoft map objectives.

    I have no idea what Starfield innovated. It’s just like every other Bethesda game with some new things done better elsewhere. I am in the minority that love it because it is exactly what you would expect from the studio that’s been rereleasing the same game for over a decade.