i’m lizard 🦎

  • 1 Post
  • 47 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle



  • Lemmy (and Kbin for that matter) very much do the same thing for posts. I don’t think they fetch URL previews for links in comments, but that doesn’t matter: posts and comments are both fairly likely to end up spreading to Mastodon/etc anyway, so even comments will trigger this cascade.

    Direct example: If you go to mastodon.social, stick @fediverse@lemmy.world in the search box at the topleft and click for the profile, you can end up browsing a large Mastodon server’s view of this community, and your very link has a preview. (Unfortunately, links to federated communities just result in a redirect, so you have to navigate through Mastodon’s UI.)


  • If you’re a gamedev trying to make a decent mobile game, you’re competing on all the usual fronts like price and perceived quality, but competing for attention has gotten a whole lot harder when [arbitrary card game] has a hour of dailies, [arbitrary gacha game] always has a special campaign going and [arbitrary fake gambling game] is about to have its battle pass end and they’re only halfway through. And that has gone up by so, so much over the past decade. It was never good but it’s gotten absolutely egregious. At this point, even any generic snake clone will have a battle pass.

    Every person that ends up committed to a couple of those long-term-commitment games ends up having much less time for other games. And they make a lot of money, which means they also end up having a hell of a marketing budget.



  • Storj is blockchain stuff with the storage and bandwidth provided by individual node operators. They’ve kinda tried to bury the whole blockchain stuff and generally keep it removed from their main signup/pricing/usage flow; customers pay in USD and never have to see any of it. But it’s still there in the background and it’s still the main reward system for node operators.

    There’s some clickwrapped T&Cs for operators that set some minimum requirements, they’ve made sure one node leaving doesn’t cause data loss, but I’d still be very wary of using them for anything irreplaceable. It only takes one crypto crash or the like for the whole thing to die out, and while they might end up suing some guys running an old NAS out of their garage, that’s not gonna get your data back.


  • I don’t think Factorio is suitable for a first-time gamer. The way the inventory, hotbar and the map work aren’t immediately obvious if you’ve never played a game. If you do try, at least turn biters off. The time pressure that’s added by having to set up defense would be difficult enough to handle, but offensive combat is quite the struggle if you’re still trying to learn basic gaming controls. You’d be dealing with things like swapping hotbars to one with grenades & stuff, control schemes changing the moment you get into a vehicle and weird targeting quirks. And by the time you get to trains or advanced oil cracking quite a lot of people tend to drop off the game in general.

    I’d start with something like Minecraft on peaceful difficulty, then give easy or normal a try after a couple of hours if that goes well. Peaceful leaves time to learn all the basic controls and is fun enough to run around in by itself, and you’re not going to get blasted by a creeper that fell behind you.


  • It’s difficult because you have a 50/50 of having a manager that doesn’t respect mistakes and will immediately get you fired for it (to the best of their abilities), versus one that considers such a mistake to be very expensive training.

    I simply can’t blame people for self-defense. I interned at a ‘non-profit’ where there had apparently been a revolving door of employees being fired for making entirely reasonable mistakes and looking back at it a dozen years later, it’s no surprise that nobody was getting anything done in that environment.



  • Even worse than that, they need to be able to make an arbitrary container from an arbitrary attacker-provided Dockerfile, or make fairly arbitrary calls to the Docker daemon (in which case you’ve already lost).

    They’re rather uninteresting for anyone self-hosting containers as the runc vuln doesn’t offer a way to escape from within an already running container, while the BuildKit vulns all have fairly odd preconditions or require passing untrusted input. Quite the annoyance if you’re running some kind of public cloud or public CI/CD service, though.


  • DMA-BUF being marked as “unstable” for a decade was a fucking joke. It’s a protocol that’s required to get any kind of meaningful hardware accel going, which nearly every app does nowadays. Within Wayland circles, it’s been understood it’s not going to change for years, as doing so would break nearly every single existing app, yet all kinds of bikeshedding prevented it from being moved to stable.

    Hopefully this marks a turning point for many other similarly important protocols stuck in unstable/staging hell too, like pointer constraints and text input. If devs can’t rely on basic functionality to be present and it takes more than say three years to commit to it, it’s time to admit that either the process or the protocol is broken.



  • There are community backports (like Sury’s Debian builds) for PHP, including a branch of PHP 5.6 originally released in 2014. Most other notable languages and major packages have something likewise as well, right down to major packages like Drupal 6. It’s not always easy, but it’s doable and the work is usually either already done or can be paid for.

    Weird things that are truly too difficult to support are also often excluded. Eg Spectre/Meltdown fixes were non-trivial and had to be backported to a fairly wide range of things but that only went so far back. Some old systems just never got those fixes and instead have to be ran with a workaround (“don’t run untrusted code”). I don’t know how things are with the new offering but large complicated packages with lots of moving parts like OpenStack used to be excluded from the full extended support cycle before as well.


  • Windows software running in Wine/Proton can bypass the Windows layer and call Linux stuff directly. This is fine; Wine isn’t intended to be a security layer by itself. Some of the Proton bits that Valve made to build a bridge between Windows games & the Linux Steam client does this, as well as pretty much every other bit of Wine internals.

    Easy Anti-Cheat detects that it’s running in Wine and if the game dev enabled Wine support, it downloads a binary that knows how to do that. That version of EAC doesn’t run at kernel level, but it does scan your Linux userspace for cheats, or whatever Epic feels like doing today. As with every userland anti-cheat, the company making it can update it more or less anytime you’re playing the game and since it’s running in the context of the game, it has access to everything the game does. Same thing for most anti-cheat software really.




  • Realistically, there is only a trivial pure security difference between logging in directly to root vs sudo set up to allow unrestricted NOPASS access to specific users: the attacker might not know the correct username when trying to brute force. That doesn’t matter in the slightest unless you have password auth enabled with trivial passwords.

    But there is a difference in the ability to audit what happened after the fact if you have any kind of service storing system logs remotely or in a tamper-proof way. If there’s more than one admin user on a service, that is very very important. Knowing where the compromise happened is absolutely essential to make things safe.

    If there’s only ever going to be one administrative user (personal machine), logging in directly as root for manual administrative tasks is fine: you already know who the user is. If there’s any chance there might be more administrative users later (small but growing business), you should consider doing it right from the start.


  • You’re most likely booted, otherwise you might need a live USB. Hopefully, the system isn’t in read-only mode. What I’d recommend doing is:

    cp /etc/fstab /etc/fstab.backup
    
    

    To make a copy once. Then, nano /etc/fstab to run nano, a basic CLI editor. You can use the arrow keys to navigate and type freely in it. The hints like ^O shown on the bottom mean ctrl+o.

    You’d use the arrow keys to go down to the line that probably says /dev/md0 /mnt/raid morecrap, put a # in front of it, press ctrl+w then enter to save. If that worked, ctrl+x to exit and try a reboot again.

    Obviously can’t promise this is “the” error preventing the system from booting, but it’s generally a good idea to disable broken stuff like this to get the system working again, then fix it from there. Hopefully, this does the trick. Your RAID setup will not be activated on reboot after you do this but it’s not going to permanently delete data or anything.


  • The RAID1 seems to be failing according to that screenshot. That breaks the “Local File Systems” task and since quite a lot of things tend to depend on that, many things usually end up failing in an annoying cascade failure. It’s also failing with a timeout instead of a strict error, which is odd.

    Either way, I’d try commenting that line for /mnt/raid in /etc/fstab for now and seeing if that makes the system boot. It’s possible that journalctl -u dev-md0.service or systemctl status dev-md0.service might tell you more, but it’s 50/50 if it’ll be anything useful.