Indeed
zarenki @ zarenki @lemmy.ml Posts 0Comments 104Joined 1 yr. ago
On Switch, no game cards support writing of save data or anything else. It's a departure from 3DS and all previous Nintendo cart formats for as long as games have supported saving at all.
That change is probably done to help tie saves to user accounts, enable cloud saves even when the card is not inserted, accommodate variable-size user data features like level creation, and mitigate the risk of game save based exploits like Twilight Hack spreading from user to user.
Unfortunately that (plus inability to put saves on SD card) means that backing up your own save data requires either being able to run homebrew on the system that has the save or having another Switch that can and relying on Nintendo servers to perform the transfer. Either way, having a Switch that runs homebrew means you don't need this dumper.
I've been using it since it felt usable enough in GNOME to me. Around 2015-ish, give or take a year. GNOME leading on Wayland support is a big part of why I switched to it from Xfce back then. Nowadays KDE and others have plenty good Wayland support too (better in some ways like allowing server-side decorations and global shortcuts) but I just haven't felt like trying to properly experiment to see what I like.
I've always avoided Nvidia on my desktops. Stuck with either radeon or intel and never had any exceptionally big issues with them on Wayland. Though other things like hardware accelerated video decoding have had a history of being spotty on some drivers/GPUs.
I've avoided RGB-lit stuff for everything else, except for my wireless headset. A Logitech G733. In every other respect I love it, but it has bright lights on the front that drain the battery and reflect in my glasses. They default to constantly changing random colors until host software sends a command to control the light. Thankfully there exist tools to control it on Linux (HeadsetControl) but adjustments reset on every power cycle.
The mouse in OP (M510, I've had a few of them myself) doesn't have those problems. There does exist specialized software to manage device pairing for the included "unifying receiver" but it comes by default pre-paired so the software is only particularly helpful for the niche use case of having other wireless logitech devices and wanting to save USB ports by making them all share one receiver.
The readme file, gitmodules file, and other links within that repo all still reference the now-dead gitlab links. The builds don't seem to be present at all.
That will all probably be fixed soon enough but right now that mirror which seems to have just been pushed as-is isn't entirely usable.
The first I tried was Ubuntu 7.04 but I didn't stick with it and went back to XP. Until I ended up with a hardware setup that wouldn't work on Windows XP (widescreen monitor + Intel graphics driver with no widescreen mode options) but worked perfectly on Ubuntu 9.10. I never truly went back to Windows since.
Tried a few other distros in 2011 then switched to Arch for a couple years, Xubuntu for a couple years, Ubuntu GNOME for 7-8 years, and finally switched to Fedora last year.
The act of tipping itself is a cultural thing it needs to be addressed culturally. If you can’t tip someone for something, complications in the law arise that may disallow giving money to people in general. For example how do you distinguish between tipping a server for a meal and giving the server a dollar as a gift?
If you are a customer at a food or retail business and opt to give one worker there a cash gift while they are on the clock, how can that not be a tip? Current US laws like FLSA already have a very clear definition of tipped wages which would include anything matching that description.
Even if you want to allow that sort of cash "gift", eliminating tips for credit card payments should be enough to shift the norms and expectations. Namely, prohibit payment terminals from prompting for a tip as part of the same credit card transaction and prohibit the tip lines on receipts. Majority of Americans don't pay with cash. If a business says they accept credit card, customers clearly aren't expected to give a decent tip and by extension the advertised meal prices and wage amounts should reflect what the customer is expected to pay and what the staff should expect to earn independent of customer whims.
microtransactions rule
You joke, but it really exists: the company that acquired uTorrent 17 years ago now sells an ad-free version of their current torrent client as "BitTorrent Pro" for USD$20/year, or alternatively as part of a VPN service bundle for $70/year.
Needless to say, stick with FOSS clients like qBittorrent/Deluge/etc instead.
microtransactions rule
Nonfree media codecs like HEVC/h265 are affected by US software patents. Distributing them from US servers without paying license fees to MPEG LA can put the host at risk of lawsuit. VLC, deb-multimedia (Debian), and RPM Fusion (Fedora) all avoid that by hosting in France, but even with those sources enabled patent issues can break things like hardware acceleration. Free codecs like AV1/VP9/Opus avoid all these problems.
Microsoft is US-based and can't avoid those per-install fees. They could cut the profit from every single Windows license but apparently chose not to.
That's actually a choice you're offered during Debian's interactive install. When you're offered the option to set a root password, if you leave it empty the system will disable direct root login and instead give your first normal user sudo
access.
Debian. I was in a similar boat to OP and just a couple weeks ago migrated my almost 8-year-old home server setup from Ubuntu LTS to Debian Stable. Decided to finally move away from Ubuntu because I never cared for snap (had to keep removing it with every upgrade) and gradually gained a few smaller issues with Ubuntu. Seems good to me so far.
I considered RHEL/Rocky but decided against them largely because I wanted btrfs for my rootfs, which their stock kernel doesn't have, though I use a few Red Hat developed tools like podman and cockpit. Fedora Server and the like have too fast a release lifecycle for my liking, though I use Fedora for my desktop. That left Debian as the one remaining obvious choice.
I also briefly considered throwing a Debian VM into TrueNAS Scale, since I also use this system as a ZFS NAS, but setting that up felt like I was fighting against the "appliance" nature of what TrueNAS tries to be.
Every single other browser is Chromium.
One exception I'm aware of: GNOME Web (aka epiphany-browser) uses WebKitGTK, which is based on Apple's WebKit rather than Google's Chromium/Blink. But it's Linux desktops first and foremost. Not on mobile platforms, not exactly intended for Windows (might be usable with Cygwin/WSL) or macOS (seems to be on MacPorts) either, and even on non-GNOME desktops like KDE it might seem a bit out of place.
I daily drive Firefox but Epiphany is my first choice fallback on the rare occasion I encounter a site that's broken on Firefox.
The main reason people use Fandom in the first place is the free hosting. Whether you use MediaWiki or any other wiki software, paying for the server resources to host your own instance and taking the time to manage it is still a tall hurdle for many communities. There already are plenty of MediaWiki instances for specific interests that aren't affected by Fandom's problems.
Even so, federation tends to foster a culture of more self-hosting and less centralization, encouraging more people who have the means to host to do so, though I'm not sure how applicable that effect would be to wikis.
There's one more repo worth archiving that isn't included in this, was taken down at the same time as the others, is needed to build yuzu, and is a submodule in yuzu, yuzu-android, and yuzu-mainline: https://github.com/merryhime/dynarmic.git
I found one copy of it at https://github.com/ihaveamac/dynarmic
Most other submodules are from huge projects with no real risk of vanishing (mozilla, khronos, libusb, etc.), but a few others that might be worth noting (all still online in github) include: merryhime/oaknut, bylaws/libadrenotools, and lat9nq/tzdb_to_nx
I just uploaded a mirror of the wiki to https://codeberg.org/zarenki/yuzu-wiki/src/branch/master/Building-for-Linux.md
Downloaded it a week ago, so might not be the most recent change.
The passive adapters that connect to DP++ ports probably still rely on this HDMI specific driver/firmware support for these features.
Not OP, but the one thing that bugs me most is that Firefox Android does not have a tablet UI. Other browsers like Chrome have a tab bar and other desktop-like UI features when run on Android tablets.
But on phone I've never run into a case of wanting a feature that it lacks.
Ethically, I agree with you. More than that, using a lockpick on a lock you bought shouldn't make you a thief. Unfortunately, DMCA has abysmal anti-circumvention measures that make the legality of using a device you own in ways you should be able to become questionable under US law, in the digital equivalent of Master Lock suing you for picking a lock you bought from them.
instructing users how to extract the prod.keys from their own switch
Yuzu's quick start guide links to the old download link for Lockpick RCM from the same repo that is still inaccessible ever since Nintendo's DMCA takedown last year (source: arstechnica). They never updated the page to link to any mirrors of Lockpick RCM or any other options to extract the keys; the guide doesn't even work right now. You can see in Yuzu site's changelog on github that the only changes made to that page in the last year are to minimum/recommended hardware requirements.
It seems even more absurd to argue that instructions are somehow infringing when the allegedly infringing part of them has already been broken for almost a year. Even the standing for taking down Lockpick RCM in the first place seems questionable, and telling users to use it with a broken link seems several layers further detached from that.
If you're assuming "as long as the hardware will function" in the first place: even digital copies, DLC, and updates installed on the system before the servers shutdown will continue working even without hacks. There's no check-in requirement except for the subscription-locked things like SNES games.
However, the result of a nonrepairable hardware failure when you have no hacks nor official servers is rather bad no matter how your games are obtained: OFW does not allow you to transfer save data from one system to another without going through Nintendo servers and a vast majority of cartridge games are incomplete without updates or DLC.
As someone who used to use Arch a decade ago: I still use pacman for devkitpro at least, and I do miss how fast its parallel downloads get, but the tool I use to manage packages is far from the most important difference between distros to me, even if you assume not needing AUR.