You can just as easily run pirated games on real hardware as you can a steamdeck, and vice-versa. You're conflating emulation and piracy. Emulation does not mean piracy as it is perfectly legal (and moral) to dump a game that you own so that you can play it on your preferred hardware.
Running pirated games on real hardware requires tracking down a hackable Switch, which is not completely simple. I've seen torrents floating which contain Switch games alongside pre-setup emulators so you can just download and go.
I play my switch games on my PC completely legally. All the games I play are owned by me, and all of them were backed up using my own switch and my own prod.keys.
The majority of HN makes a living from software that by nature can’t be pirated, so they have little sympathy for people who work on software that can be pirated.
Nintendo bring this in themselves with their own policies.
There are so many hardware platforms I can support, and one that hardly ever does sales and refuses to bring their games to other platforms is not that appealing.
I buy games on PC, I buy games on XB, I've even rebought some games between the platforms to play couch co-op with my kid.
Steam and XB have enough sales to make this an option, Nintendo on the other hand is adamant about wringing every last penny from you.
These days I don't have time for Nintendo's nonsense. They want to live in their walled garden, they can have it.
I'm a little confused. So that long list of requirements is useless for PWAs?
Some people will actually believe this. I'm utterly disgusted by Apple and their arrogance regarding the DMA, and the way they've managed all of this. My perception of them has completely changed. However, they seem very obedient when China asks them to censor apps or, for example, limit AirDrop when there's a protest going on.
I see he's emulating Nintendo Switch games, which is a game console actually being sold, same as the games. I see no mention of him actually buying the games he's emulating, so this effectively is piracy.
> I see no mention of him actually buying the games he's emulating, so this effectively is piracy.
No, we don't know if the author bought the games or not and there's no reason to expect him to say it. Just as you didn't say you bought the computer you wrote that message on rather than steal it.
I buy Switch games and play them on my Switch (bought and playing Super Mario Wonder on it right now), but I also would like to play them on my Steam Deck as well (haven't gone through that process to get Switch games working yet, only older systems, but I will eventually).
For some games, it would be nice to only have to bring one portable system with me (like I own Advance Wars Reboot, but I think I'd prefer playing it on Steam Deck and being able to bring it with me along with the rest of my Steam library).
Same with older systems. I own tons of retro games, but I'd rather play them on Steam Deck (especially since it has integration with Retro Achievements) than dig out my old consoles.
I emulate the switch games I own as well because the emulator can play the games in 4k with less frame drops on my gaming PC.
I still play my switch on the go tho.
They don't provide any mitigations of the sort I was clearly referencing. Specifically, for restricting malicious code or users that already has access to the system, exploiting insecure software that was not compiled with pledge support.
The technologies I listed are not sandboxing, as that term refers to a different category of technology.
And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.
Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.
It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct.
> The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.
That's why there are things like, for example, SELinux permissive mode, where you run the software as needed and observe the permissions it needs, and then grant it those permissions while denying everything else.
I mean the typical term used for such things is “mandatory access control” but they always get used to implement a sandbox so that’s what I call them.
Also, watching a program to see what it does is exactly the issue I’m talking about. You’re stuck with whatever behaviors you tested and everything else that you didn’t hit will fail (loudly if you’re lucky, silently if you’re not). There are platforms that do exactly what you’re talking about and believe me working on these rules is miserable. You’ll have reports on your desk like “the profiler doesn’t work anymore” (nobody tested this) or “on desktop controls don’t render anymore” (someone changed the implementation and it needs something you didn’t include in your rules). Again, this is when you control the stack, doing this for arbitrary programs is an order of magnitude harder.
Some implement role based access control or other access control paradigms as well. I just don't think sandbox is a good term, but I see where you're coming from.
I agree initial setup can be cumbersome, but I think it's worthwhile. I'm a fan of RSBAC personally, it's as powerful as SELinux but a lot simpler. If people run in permissive mode and test properly, not just run it and do a few things, but test every function exhaustively before setting up permissions, it should be good.
Really, it only has to be done once, and I think it's a worthwhile investment given the security gained.
That's what I was saying higher up in the thread though. OpenBSD is known for having good, simple implementations of complex stuff like this, so if they ever were itnerested in implementing a version, it would probably be amazing.
Not my experience at all, it works very well with a new Acer laptop I own: the graphics work (Intel Xe - 12th gen processor), audio, touchpad, keyboard (and special keyboard keys like brightness), wifi... All I had to do is to download the firmware with fw_update, nothing more.
Also I was pleasantly surprised to hear they support Apple M1/M2 Macs. Asahi Linux gets a lot of press around here but I had no idea OpenBSD supported it.
GNOME applications look so... mobile. Large controls, large title bars that lack maximize/minimize, simplistic layouts. It might be good for this kind of frontend apps but I can't see software like Krita or KDEnlive being done for GTK4/GNOME as of today (for reference: https://kdenlive.org/wp-content/uploads/2022/01/271174170_10...)
I believe the apps are designed this way so that they’re easily adaptable to GNOME shell on mobile[1].
I think the UI elements could be a tad smaller on desktops, but I’m still happy with how they look. Easily the best UI design out of any Linux desktop environment right now. At least in terms of clarity and consistency.
You can't be serious about Gnome, the UI elements are all over the place, inconsistent styling, sizes, spacing, not to mention the system apps are inconsistent with each other.
Gnome is the most ghetto desktop environment out there.
I am serious! I really do think GNOME looks the best by default of the DEs I have used and seen.
> inconsistent styling, sizes, spacing
I’m going to be honest, I have not noticed these things at all. But I am not a UI designer, and mostly look at these things from the perpective of a regular user. However, I have noticed those inconsistencies with Plasma. I’m not denying that there may be such inconsistencies in GNOME as well, but if they’re small enough that I don't notice them, then I’m fine with them. The most important thing for me is that the apps/components, individually, are easy to look at and interact with. I think GNOME does this well.
That may be the case, but microscopic controls are how some of us want our GUIs to look. Using Windows 7 with the classic theme on a 1920x1080 display was near perfection. Even for Aero, I'd have my toolbar set to small icons and CTRL+MW_DOWN on the desktop to shrink my icons. The closest I can get now is to up my display resolution to offset the giant bars that take up more of my screenspace than they need to. Not having the option really sucks.
I like GNOME because of its design choices in 3.x+. I really appreciate the aforementioned large controls, title bars (often integrated as toolbar menus) and resignation of menus in favour of dedicated pop-overs. IMHO it is a step forward in providing simpler UI, but yes - it has some drawbacks too.
Ironically, I see the designers of macOS built-in applications (e.g. Finder.app or System Settings.app) are following their GNOME counterparts rather than the other way around. Since Maverick, Apple has lagged behind in terms of UI innovation and it is the GNOME designers, who are pushing forward with new ideas. The addition of a header bar in Finder.app and Nautilus made them much more usable for me [0] [1]. The same can be said for System Settings.app [2], which now follows the design and layout of the GNOME Control Center. GNOME has been a copycat for many years, its UI was inspired by macOS/iOS, but now the roles are reversed.
The missing piece of the puzzle is searchability, which GNOME 3.x+ lacks and which GNOME excelled at in the days of Unity DE. Hopefully GNOME 40+ will bring some improvements in this area.
> I really appreciate the aforementioned large controls, title bars (often integrated as toolbar menus) and resignation of menus in favour of dedicated pop-overs.
Heh, those are all on my list of things I hate about Gnome. Funny how different people can be.
