For good reason. Last time I checked (this year), Alyx crashes Mesa (i.e. your Vulkan layer) when the player enters an in-game load zone. This happens with native linux and the proton windows version.
It doesn't just crash Mesa but freeze the entire GPU last I tried. Kinda surprised that Valve has cared so little to fix this considering how much effort they have been putting in those drivers and into the game in the first place.
That's something people should run themselves. I run Adguard Home on my router. Unlike the main Adguard product, Adguard Home is fully FOSS. It's been rock-solid for me, and improves on pi-hole in various ways - like full IPv6 support.
> That's something people should run themselves. I run Adguard Home on my router.
I'll second this. People should really be flashing their routers. OpenWRT is simple enough that if you're on HN I think you'll easily be able to do it. And like most routers, you set it up and forget it.
But you'll also get a bunch more benefits from OpenWRT, to make it worth your while.
- I was able to buy a router for <$100 that was WiFi 7 capable (W1700K[0]) and had better hardware than most consumer routers. You can find plenty of cheaper routers that are flashable and more capable.
- Adguard Home
- Split tunneling/VLANs: Since we're talking Mullvad, you can put devices behind Mullvad on a VLAN. So activate Mullvad by changing SSIDs.
- Trivial to put IOT devices on a VLAN (can make one directional too so you can access from your main network but they can't reach back. I throttle everything IOT)
- Tailscale
- QoS (Control the speed and prioritization of different connections)
- It's a fucking computer, you can even run shell scripts
[0] You don't need something like this unless you're getting >1Gbps from your ISP. Big thing I wanted is the 2 10G ports.
It's probably the software I trust the most on my network to 'just work', and with the local caching I can use slower upstream dns providers and still have sub 1ms average latency (no performance worries by excluding google and cloudflare). I don't use it for dhcp, but it is a good fit that it's available as well. Couldn't be happier.
There's also Orion browser, but I found it to be a bit more glitchy, especially around sites like YouTube (fuck the app, I'm not watching videos there): https://orionbrowser.com/
Yes, I use Firefox on Android with ublock origin, it works great. But using adblocking DNS on your phone will also block most in-app ads which is a big quality of life improvement.
I could also use a VPN to keep my phone always on my home network and thus behind my own ad blocking DNS but Mullvad's adblocking DNS was really nice and convenient.
Really? I never found it effective unless I messed with certs on my phone.
For example, DNS blocking isn't going to block YouTube ads if you're using the app since they don't need to respect your DNS, but it will if you're in browser because they can't control that.
Ads from providers like Google AdMob and AppLovin are blocked. Apps could bundle their own DNS or DoH resolver or use hardcoded static IP addresses but in my experience most do not.
Youtube ads do not get blocked by DNS adblock because Youtube ads are served from the same domains as the content and thus DNS blocking would be counterproductive. I don't think it has anything to do with respecting DNS.
I don't have the Youtube app installed to test but the Internet suggests that at least in 2023 it was very possible to block the Youtube android app (content and all) via DNS, which hints it does not bypass system DNS. [1]
Are you explaining my comment or rebuting it? I really can't tell what the intent is. Maybe the internet has trained me poorly in thinking most replys are generally rebuttals. But it really does seems like you're just explaining my comment.
Mostly a clarification of what I find DNS ad blocking works for on Android, which seems to be somewhat different from your experience (probably we use different apps).
A weak rebuttal of the reason why DNS adblock doesn't work for Youtube and the Youtube app.
I've been using NextDNS [0] for a long time. It's worth the price because you can set up all kinds of different blocking profiles and have different ones on different devices, allows you to have overrides for local network items (or internals like on a Tailnet, Pangolin, Wireguard, etc) and a lot more. The ad blocking ends up working so well a lot not only are ads blocked on web pages but it works with some streaming audio ads as well as VoD that has ads injected. Highly recommend.
I stopped recommending anything I host myself for those people. When it breaks I'm the support team, and I'd rather not be. NextDNS free tier is what I give them now, takes two minutes, and I never hear about it again.
I'd argue you don't need to run DoT/DoH yourself if it is just for your local network.
Setting up a local resolver, such as a Pi-Hole or Unbound on a firewall can serve unencrypted responses to your devices. Those resolvers in turn can use DoT/DoH with their upstream resolvers to encrypt the requests that go through untrusted networks on the Internet.
This is the best of both worlds, the simplicity of unencrypted DNS while encrypting traffic where it matters.
I honestly think the kernel interface is by far the easiest part of building a MacOS compat layer. The userland is gigantic, super complex, and totally closed source. That's the hard part.
AFAIK all macos software only talks to the kernel via userland APIs - so there's no particular benefit to basing ravynOS on XNU anyway. (Just the opinion of a layman.)
The illustration that Chrome uses Mach ports is a counterexample to an (implied) insinuation that nothing in running in macOS user space uses Mach ports. Outlier or not, the fact there is at least one (albeit also very useful and very popular) application that uses them ties back to the conversation about how they're a kernel feature worth having for Mac compatibility.
Don't know much about driver maintenance but if it is working why remove it?
What I read in the link was that it was removed because LLM was making suggestions to improve the code/bring it up to modern standards but since it was rarely used no-one wanted to review it not that it was buggy.
>In recent months we have seen a lot of old kernel code removed stemming from that AI/LLM noise.
This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.
Because more-or-less all code in the kernel increases the attack surface and makes general security improvements more difficult. Removing code of all types makes maintainability easier, so old, unmaintained code is an easy sell for removal.
>This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.
That would only happen if the linux project was happy to accept LLM-generated fixes without human review - which they aren't. If human review is necessary, then unleashing LLMs to produce fixes and improvements to thousands of linux drivers is a detriment, not a benefit. The amount of code would just be too much, and reviewers would be swamped.
No, not even close. Totally different projects. This one is for experts only, or those who want to become experts. The type of person who has been toying with the idea of building a LFS system but doesn't really want to go through all the work and headache (and it's a ton, to build a full system.) It also supports cross compiling to other architectures, which LFS does not.
This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed.
There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner.
No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
The low level API of process isolation on Windows is Job Objects, that provide the necessary kernel APIs for namespacing objects and controlling resource use.
AppContainers, and Docker for Windows (the one for running dockerized windows apps, not running linux docker containers on top of WSL) is using this API, these high-level features are just the 'porcelain'
Windows containers are actually quite nice once you get past a few issues. Perf is the biggest as it seems to run in a VM in windows 11.
Perf is much better on Windows server. It's actually really pleasant to get your office appliances (a build agent etc) in a container on a beefy Windows machine running Windows server.
With a standard windows server license you are only allowed to have a two hyperv virtual machines but unlimited "windows containers". The design is similar to Linux with namespaces bolted onto the main kernel so they don't provide any better security guaranies than Linux namespaces.
Very useful if you are packaging trusted software don't want to upgrade your windows server license.
Because latency matters when gaming in a way which doesn't matter with AI inference?
Plus cloud gaming is always limited in range of games, there are restrictions on how you can use the PC (like no modding and no swapping savegames in or out).
Yep those are exactly the same considerations. LLM providers will have inconsistent latency and throughput due to batching across many users, while training with cloud GPU servers can have inconsistent bandwidth and delay for uploading mass training data. LLM providers are always limited in how you can use them (often no LoRAs, finetuned models, prompt restrictions)
