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

help-circle

  • If you’d like to look into it further. the +i flag in chattr is setting an attribute making the file (everything in Linux is a file, so yes this even means directories) immutable. When a file is immutable, it isn’t possible to change the ownership, group, name, or permissions of the file, nor will you be able to write, append, or truncate the file.

    It’s been a while since I’ve used it, but I don’t believe it’s possible to have an immutable directory where you can still modify the contents therein, but I may be misremembering that. It would seem unlikely since adding content to the directory should require that you modify the links for the directory, which shouldn’t be allowable with an immutable object?

    It’s possible that the +a chattr attribute may achieve what you’d prefer. I believe that flag will make it so that files (and again, everything in Linux is a file) can be created and modified, but never deleted. I’ve actually never used this one, but I can foresee how this still may not be ideal for your wishes since updates to games may expect to be able to delete old content which would be thwarted here. 🤷



  • If gaming with Nvidia hardware is your primary concern, then maybe Bazzite would suit you. It’s based on Immutable Fedora, with tweaks to give it a SteamOS like experience. It offers Gnome or KDE for the desktop, and supposedly has everything dialed in for gaming. I’ve heard a bunch about it doing great with Nvidia cards and gaming in general, I suspect that you’d be able to do everything else you might need via the desktop it provides, but I have no knowledge of how it handles multiple monitors so maybe therein lies the fatal flaw.


  • If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad).

    According to the researchers

    The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term decloaking to refer to this effect. Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

    Killswitches are insufficient protection since the TunnelVision attack never disables the VPN tunnel. The TunnelVision attackers are instructing your physical layer connection to route everything through a node of their choosing rather than killing your VPN connection, and since the VPN connection never drops, a killswitch will never engage. The VPN stays up, thinking it is doing a good job, but in the meantime your network interface has been instructed to route no traffic through the VPN and instead route everything to the location of the attacker’s choosing. I have heard that a couple of VPNs think their clients are not vulnerable here, but I haven’t seen independent conclusive proof one way or the other yet.

    I suspect that your “Solution” also fails to mitigate the issues in TunnelVision because it allows LAN access to the physical interface. In a TunnelVision attack the hostile has to be on your LAN (or rather the same LAN you are on since I suspect that “The coffee shop wi-fi” is the more likely network for an attack like this) already, so if they’re going to tell your interface to route traffic somewhere else, in all likelihood that somewhere else will already be in the same LAN you are and their exfiltration will be allowed under your configuration.



  • One has already been pulled, though seemingly for unrelated copyright issues?

    That said, I’m surprised that things have gotten to this point, I suppose time will tell once the property holders get involved how committed Apple is to this whole change, there’s still a lot of room to interpret the clause about conforming to all laws for the content that is being run in the app.

    Given that I didn’t think ANY emulators would make it into the Appstore, I’m going to retract my position. However, I think that we’re still in the “Fuck around” stage of things and there may yet be some “Find out” to come.



  • Dolphin requires JIT compilation and that is still verboten under these new guidelines.

    Further, the rule change says that these apps are allowed to “Download” ROMs, it doesn’t say that they can just play anything they want, it in fact says that they have to provide an index of everything their software might run and where it is downloaded from. The rules are not going to allow emulators as we know and love them. It says specifically that the software offered under the guidelines must be offered via In App Purchases, so in all,

    A) Emulators can exist

    B) They can download ROMs

    C) You have to comply with all applicable laws while you offer an emulator that allows people to download ROMs ಠ_ಠ

    D) “Software offered in apps under this rule must: use in-app purchase in order to offer digital goods or services to end users.”

    Which in whole means that they’ve allowed (for example) Sega to offer an Emulator app that will run ROMs of games that Sega owns, but they have to sell the ROMs to you individually via IAPs.

    Feel free to read their guidelines at https://developer.apple.com/app-store/review/guidelines/#third-party-software, because there isn’t any way in my reading to interpret those rules as allowing something like Higan to exist on the app store, the new rules are such a narrow carve out that it’s hard to imagine that anyone is able to provide an emulator for iOS any time soon. They’ve opened a door that basically nobody could walk through and the people who could walk through it wouldn’t need to because they could just distribute the ROMs with the emulator to begin with, it’s business as usual for Apple.


  • I’ve dabbled with Linux on Mac hardware a couple of times and I’ve got to say that Linux DEs generally hew closer to Windows conventions than Mac ones and I found using the Mac keyboard with Linux to be a dreadful experience without the fact that the chiclet keyboards are the worst shit I’ve ever put my fingers on.

    I very quickly snagged a standard mechanical qwerty 104 key with brown switches and cursed every moment that I had to use that abominable keyboard built into the stupid MacBook. Apple seems determined to do things different for the sake of different as much as they possibly can and trying to adapt all their nonsense to the Win/Lin way of doing things made my life worse in numerous ways (most DEs have great remapping for keys and such, but it gets messy fast if you’ve got apps from different paradigms.)

    I’d very much recommend against going out of your way to get a Mac keyboard for using Linux unless you enjoy fighting against things. But hey, if that’s your kink, then a Mac keyboard with Linux would be my recommended way to go.


  • The original Game Boy Color has a screen that is only 160 pixels x 144 pixels at a 6bit color depth. That color depth means it can keep track of 6bits of color information for each pixel (technically the GBC screen CAN display 15bits of color information, but it’s limited in software to 6bits absent certain tradeoffs.)

    This isn’t exactly how it all works, but I’m going to just do some quick and dirty math really quickly that sorta simply illustrates how this works. To adequately display a 60fps image on the GBC display at the 6bit color depth of the screen, we’d need to be able to process 23,040 pixels (each with 6 bits of color data) every 60th of a second. To simplify further, there’s 138,240 bits of data to process every 16.6ms just to “drive” the display, or put another way 138,240 bits of data to process to ensure that the display gets all the information it needs to build a complete picture every 60th of a second.

    So for a 1600x1440 display, you’re looking at 2,304,000 pixels, and the Analogue Pocket has a 16bit color depth, so you’re going to need to be able to process 36,864,000 bits of data every 16.6ms to “drive” that display.

    Getting a GPU/CPU/FPGA that can handle 138,240 bits of data every 16.6ms is a fairly easy task these days. Getting a GPU/CPU/FPGA that can handle 36,864,000 bits of data every 16.6ms is also a pretty easy undertaking these days, but it’s much more power intensive and it’s going to cost a bunch more. All of which is beside the shader calculations the Pocket adds in to do things like emulating the pixel fade of old LCDs or other effects that further emulate the properties of the original displays which requires further processing.

    The tradeoff is that you can build a more detailed image with all those extra pixels, but you’re going to pay for it both in electrical power spent, heat generated, and costs sunk.


  • Honestly the 1600x1440 screen on the Analogue Pocket and the ability to drive it is what you’re paying for when you buy it.

    There’s not going to be a device that can drive all those pixels at less than the Analogue Pocket’s price for some time yet. Sure, none of the Game Boy systems used anywhere near that many pixels, but the fact that the Analogue Pocket screen is so ridiculously pixel dense it can emulate the original attributes of the OG screens from the devices that their FPGA is mimicking means you’re going to pay a premium for that (or any) device doing full hardware replication at that level.

    Honestly seeing the Analogue Pocket emulate the way that the original DMG GameBoy screen pixels seemed to slightly hover over the background (slightly casting a shadow) was mind-blowing. You can’t get that unless your screen actually has those original pixel attributes or you’ve built a display with enough resolution to emulate what those characteristics looked like. See: https://cdn.arstechnica.net/wp-content/uploads/2021/12/PXL_20211213_155424062.jpg (Seriously, zoom in and notice the mimicry of the shadows under darker pixels, it’s just crazy to see in person.)




  • A process running as root does not need a prompt or any user interaction to do whatever the hell it wants on most (nearing ALL, but I’d be wary of absolutes with Linux) systems. I’m unaware of any means that a Desktop Environment could restrict a process running with root permissions by requiring an interactive prompt of some sort for anything. If your DE is running as root, all of its children are also running as root (unless you’ve rigged things up to run explicitly as other users) which means just about anything you are doing could be running rampant malicious actors on your system and nothing would seem amiss until it made itself evident.

    Now, it does seem unlikely that anyone has written any malicious code that would run in a browser expecting to be root on a Linux system, so that’s likely the saving grace here, but that’s only security through obscurity and that’s not much to hang your hopes on for any system you care about.





  • Your Mastodon data is already an open book to Meta if they care to have it. The protocol is open, they could already be black-ops scooping up everything that’s fit to federate without turning on Threads federation, so them doing that really changes nothing. And what I mean by that is that they could already have set up unknown instances to leech whatever data they want out of the Fediverse, which instances masquerade as normal mom and pop installs just federating and sucking up everything without bringing anything back to the table. There’s literally nothing stopping them from leeching everything out of the Fediverse at any time other than people being better at detecting their activity (and actively thwarting that activity) than Meta is at keeping it off the radar.

    In this case they’re making it so that I might have a chance to follow and interact with people already in the Meta/Instagram/Threads atmosphere without having to convince those people to leave the confines of what they’re comfortable with and find a Mastodon instance to sign up for. Maybe they’ll be more comfortable with leaving Meta after dipping their toes in the open spec?

    How is that not a win? If Meta/Threads decide that they want to fracture the protocol and go do their own thing later, so what? We’ll go right back to where we were before they brought their users into the Fediverse. If people decide that they value the Threads extras/connections more than they value the purity of the ActivityPub protocol then maybe Meta is actually providing something that matters and we’ve lost by not supplying that need before the corporate interest figured out that it existed. In that case we’ll deserve the death that causes in use of the open spec, but the open spec will still be there and people who want to do their own thing with it can’t be stopped now. The code to run an open ActivityPub Mastodon instance is already out there and it’s impossible to take it back now.

    Everyone is out here decrying this as a subtle takeover of the Fediverse by Meta, but did Facebook “takeover” the HTTP spec when they started operating facebook (dot) com on the world wide web over the HTTP protocol? It’s an insane assertion. I’ve been running my own opensource web servers since well before Facebook was a thing and I’ve continued to do so despite most people opting to depend on a mega-corp to be steward of their online presence. That Meta has a very successful and popular website that I’ve never been a fan of has never impacted my ability to use the open protocol they operate on to continue doing my own thing. The same thing will be true here.

    It really seems like people are just upset that Threads might bring ActivityPub to the mainstream and force them to contend with the realization that a diaspora of open spec implementations already lost the war to Meta/Facebook. We had that once before. It was called the World Wide Web and you could go and find forums, fan pages, company websites, and everything else back then that has since moved to Facebook (or other content aggregator sites) because people value the network effects and homogenization more than they care about one big company being in charge of it all. (…and not to belabor the point, but most of that stuff is still out there, it’s just waned in popularity because the network effects are not there.) Here we are with a chance to try and break things out again and people are seemingly worried that we can’t if we let the Meta users in? Maybe they’re right, maybe it’s impossible to achieve victory here, but gatekeeping the standard and enacting some purity test for which providers are allowed on the protocol isn’t going to tip the scales in favor of the open standards implementation.

    If the protocol is truly open, then how can a corporation embracing it be a danger? We’re all free to adopt any changes or not at any point in the journey so it’s impossible to lose, you’re free to keep doing your own thing any way you look at it. Tell me how any of this is untrue.

    TL;DR: Threads coming to the Fediverse is a good thing. It’ll make it possible to expand the network effects of an open protocol far faster and more than any amount of Fedinerds proselyting the gospel of ActivityPub ever will. The only thing that is at risk of being lost is that we’ll refuse to adapt to what end users want fast enough to keep a large corporation from bending the spec to their ends. Which loss again only means that you’d be cutting yourself off from those who WANT to embrace the revised spec by not adopting those changes yourself. That option (to just not adopt changes to the spec) can’t be taken away from you in the future, so worrying is only warranted if you feel like your ideal ActivityPub implementation can’t win out in the marketplace of ideas and that you’re owed that victory even if others are able to expand it in ways that people actually want to use enough to dismiss whatever downsides it contains.


  • I’ve a Mazda with Android Auto that doesn’t use a touch screen. It’s all controlled with a joystick/knob/button setup that is actually really nice. I wish my Nissan had a similar setup all the time.

    In the Mazda I know how many physical interactions will get me the result I want, it takes barely more than a glance at the screen to know what’s up. With the touch interface I have to put my eyes on the screen to confirm that the car didn’t bounce when I went to tap a “button” and/or confirm that the tap was actually registered. I know that GM has to know that Android Auto supports non touchscreen interactions. If they’re concerned about how unsafe touchscreens are, just add a knob to the center console that doubles as a 4-way joystick like Mazda has and all those concerns go away. It’s really that simple and it IS miles better than using touch for everything.