i’m lizard

  • 0 Posts
  • 34 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2024

help-circle


  • The PS2 Ace Combat games (4/5/Zero) are still best-in-genre as far as I’m concerned, and have held up exceedingly well in general. Aerial dogfighting with good controls, good mission design and interesting story.

    Sky Odyssey is a more “relaxed” little flight game that I also like, still got game-like controls but no combat, just missions where you fly through hard situations.


  • I’ve also been playing this, even though it’s well out of what I normally play. I’d describe it as being closer to an ARPG than a MOBA, and for both better and for worse, it feels like a roguelike version of mid-seasonal gameplay in ARPGs. Couple of buttons on relatively short cooldowns backed up by buildcrafting meant to make those buttons utterly broken with lots of good opportunities available. There’s okay variance between runs. Buildcrafting is super flexible in general, you can move all of your ability upgrades around to other abilities at any time with no cost, you can even give almost everything to friends in co-op.

    Not all is good. The game was review-bombed at launch due to the metaprogression and cooldown changes from the demo, and honestly, that was probably correct. The balancing work and the per-character XP requirements ruined some of the fun that the demo had. The worst was hotfixed within a day, even adding a compensation system for demo players, and progress is like 3X faster now, but it still feels like it’s too slow and not fluid enough. I sorta settled on having a “main” in a genre that’s more fun if you swap between characters to keep things fresh. The devs will probably find a solution sooner than later.

    There’s some other problems like the performance absolutely tanking in lategame regardless of what you’re playing on (my trusty RX 580 performs about as well as my friend’s RTX 4080, and that’s a pretty universal complaint), there’s some multiplayer bugs like a boss attack that only the host can survive, some questionable balancing here and there, one of the 8 characters feels unfinished (Shell), but overall it’s been pretty good, fills a pretty unique role and the problems don’t really detract from what I’m getting out of it.




  • Tends to change by playthrough but 50% water scale/150% water coverage/~200% resource frequency+size+richness is my go-to. Creates lots of natural chokepoints, available resources end up feeling like they’re similar to default map settings, gives you enough area to build a reasonable bus starter base at the start but eventually pushes towards a more train spaghetti playstyle.


  • scripts mix configuration with logic and this was a big reason why a lot of distributions switched to systemd in the first place

    What was really wrong with the old BSD-style rc/init systems is that they mixed configuration with the logic required to start/stop the service at all, and that that logic was running in the same session it was being executed from (inheriting the environment, FDs and the like). These daemontools-style supervisors don’t have that problem, the run script is essentially just systemd’s ExecStart= and it gets forked off from the supervisor itself and is then managed by it. Lots of them are just #!/bin/sh \n exec coolservice.

    There’s plenty more things that systemd does pretty well that this doesn’t do (dependency management seems to be sorely lacking here in particular), but this kind of approach is much closer to it than the old rc scripts.


  • Even with the current thumbs up/down people get it wrong. Give it a thumbs up but write a scathing review.

    I’ve done that and it’s a result of not having more options than good/bad. Always the same cause: I really wanted to write a 3* review for a game that has a lot to praise but its core is fundamentally flawed, but Steam doesn’t let me give a 3*, so I try to correct for the review score bracket I think the game should be in.


  • For the benefit of people that can’t watch this horrible video:

    This is really about them being able to change the already extremely vague terms of service and you having no recourse other than voiding your purchase if you don’t like it. There is some focus on a gun thing early on, but it’s just an example where they flip-flopped multiple times over the years based on vague wording in the ToS that was changed after the fact. Commercial modded server owners were the main ones that had to make changes because of that rule, often taking guns away from players that had them, but it’s generally enforced very inconsistently.

    But the main thing they’re focusing on in the lawsuit is the mass deletion of legitimately bought Minecraft copies when they stopped Mojang account migration in 2023 (everyone that didn’t migrate then no longer owns Minecraft according to Microsoft; no refunds). That, too, was effectively a one-sided ToS change. And to make matters worse, the old ToS had an explicit clause that you could keep playing the game in singleplayer even without agreeing to any new ToS.

    This lawsuit is being done in Sweden. I don’t know if this kind of ToS/contract validity has actually been tested there before.

    I think this is the first time I ever watched a video at 0.5 speed. “this was done due to retention purposes for the video to maximize spread potential”. Yeeeaaaah. No. Checked reddit, it’s downvoted to the negatives over form. Checked a different place that would be all over this, entire topic is discussing the form and there’s not one mention of what it’s about because nobody got that far. The exact kind of person that might take time out of their day to join a class action is not going to watch this garbage. I think it’s good to have this tested, but I straight up don’t trust this guy. Supposedly maximizing views while getting zero information through to anyone is not going to help the cause.



  • All true, wanted to add on to this:

    Note that smart peeps say that the docker socket is not safe as read-only.

    That’s true, and it’s not just something mildly imperfect, read-only straight up does nothing. For connecting to a socket, Linux ignores read-only mount state and only checks write permission on the socket itself. Read-only would only make it impossible to make a new socket there. Once you do have a connection, that connection can write anything it wants to it. Traefik and other “read-only” uses still have to send GET queries for the data they need, so that’s happening for legitimate use cases too.

    If you really need a “GET-only” Docker socket, it has to be done with some other kind of mechanism, and frankly the options aren’t very good. Docker has authorization plugins that seem like too much of a headache to set up, and proxies don’t seem very good to me either.

    Or TLDR: :ro or stripping off permission bits doesn’t do anything aside from potentially break all uses for the socket. If it can connect at all, it’s root-equivalent or has all privileges of your rootless user, unless you took other steps. That might or might not be a massive problem for your setup, but it is something you should know when doing it.