it is a stupidly simple working demo of DRM circumvention
A much more simpler method is to just use Streamfab. No need for nVidia, a second PC etc.
it is a stupidly simple working demo of DRM circumvention
A much more simpler method is to just use Streamfab. No need for nVidia, a second PC etc.
In my experience (W11 + Fedora on UEFI Thinkpad), I’ve seen it actually get rid of the Fedora entry from the UEFI boot list. Reinstalling GRUB from chroot didn’t fix it, so I used EasyUEFI and manually added the Fedora EFI file to the boot list and that worked.
So it wasn’t simply changing the boot order, it actually nuked Fedora from the UEFI boot list.
Well, if you’re using Mullvad’s malware/ad filters etc there’s really no need for a PiHole in the first place (unless you’re doing some funky custom filtering).
Mullvad’s DNS. It’s available for non-subscribers as well, and their privacy policy explicitly claims they do not log DNS requests in any way. https://mullvad.net/en/help/no-logging-data-policy/
They support both DoT and DoH, and also have various servers for blocking ads, trackers etc (if you wish to use them): https://github.com/mullvad/dns-blocklists
Oh. I was expecting Okonomiyaki.
Ooh, does Latte Dock work under Wayland now?
Looks nice! How did you get/make the top panel, and what are you using for the dock?
How are you finding it so far? As in is it actually usable for day-to-day stuff (like decent battery life, working suspend/resume, hardware accelerated video playback etc)?
Asahi kernel, so most likely a MacBook M1 or something.
Does it handle application updates as well?
Just tested and confirm it doesn’t work on Fedora 38. When you run it, you get an error saying:
bash: fork: retry: Resource temporarily unavailable
.
It still does the loop, but doesn’t slow down the system or anything, and you can easily close the terminal window.
As I said before, systemd imposes cgroup limits per user so fork bombs no longer work.
A fork bomb no longer works on modern distros which use systemd btw, since systemd imposes limits on the user and system cgroups (IIRC, a user can’t have more than ~10,000 tasks or something).
Actually, it’s already useful for some folks. Sure, if you’re after a 100% feature parity to say XP, that’s not happening any time soon, but there are already folks using ReactOS in niche cases like embedded systems, especially in old systems like CNC machines, scientific instruments, industrial/factory machines and so on.
The main problem with old machines like that isn’t that they were running Windows NT4 or XP, but the fact that the hardware they’re using is breaking down and it’s getting increasingly difficult to replace it whilst maintaining compatibility. ReactOS is basically the only “supported” OS that still is compatible with those old specialised drivers and apps, while still being compatible with somewhat modern hardware.
The whole sudden shutting down of source code repos thereby putting the future of Rocky/Alma at risk, leading to a follow-on effect of sysadmins migrating away from Rocky/Alma and swearing off RH/RH-derived stuff in general.
SuSE needs a better package manager. Zypper was cool back in the day, but no longer cuts it, especially when you compare it to the likes of dnf5.
Then it’ll probably shock you even more when you realise that this thing is hosted on Github, a site owned by Microsoft… :)