131–140 of 148 posts
Earlier quoted context omitted.
[flagged]
My M1 mac Mini had constant wifi headaches, effectively the wifi did not work since disconnecting every few seconds wrecks your Zoom experience. Both Location Services and a thing called AWDL would just come in and destroy your wifi link over and over again. It took Apple over 2 years to ship a fix. https://systemstatus.ucla.edu/status?id=status_record&servic...
Earlier quoted context omitted.
Macs are not a replacement for a Linux desktop, laptop or a server. They do not provide the same options nor allow you do the same things. There is some overlap, but same as you wouldn't use a Linux desktop to run the Adobe suite, Macs are poorly suited for servers, development , power users, etc. - outside of the Apple ecosystem of course, because it's literally the only choice. For anything else, any recent Linux d…
> Macs are poorly suited for … development, power users… Am I misunderstanding you or does this not describe the vast majority of Mac users in Silicon Valley?
Earlier quoted context omitted.
Those problems are valid, but LAR is currently often unable to detect the correct location. Even though it seems to fail to a very restrictive default, it might not, potentially causing even worse problems than a (rare) manual override would. It also doesn't seem to be that much of an issue for other vendors to allow the user to configure their regulatory locale, it definitely raises the question how necessary this c…
> In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated. Fully agreed with all this. If there's no existing pa…
Earlier quoted context omitted.
Macs are not a replacement for a Linux desktop, laptop or a server. They do not provide the same options nor allow you do the same things. There is some overlap, but same as you wouldn't use a Linux desktop to run the Adobe suite, Macs are poorly suited for servers, development , power users, etc. - outside of the Apple ecosystem of course, because it's literally the only choice. For anything else, any recent Linux d…
Did you really need to flag my post? I don’t think it’s fair to flag a post just because you disagree with me.
Earlier quoted context omitted.
No I don't think it's in kernel support, I think that Nobara linux has been patched to support it. It's not a recommendation to go and buy a Realtek card, I was just sharing my anecdote.
Ok so yeah that is my main complaint about the Realtek cards. If the out of tree driver becomes unmaintained / incompatible with future kernels, you are SoL. Also dkms is kind of a headache to deal with. Not sure if Nobara builds the module for you, but on traditional distros you would have to build the module via dkms on each kernel update, which again I have to repeat is not guaranteed to actually succeed.
Earlier quoted context omitted.
> In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated. Fully agreed with all this. If there's no existing pa…
My regulatory.db (and regulatory.db.p7s) lives in /lib/firmware; have you tried copying it there? And I make "iwlwifi" a loadable module, so the userspace firmware loader can pick up the various firmware blobs once the rootfs is loaded (not a big fan of initrds).
The kernel sees them, and compiles them, and it WORKS with other things requiring a firmware like i915 with the HuC and the GuC, but not for regulatory.db
Earlier quoted context omitted.
> It's incredible how well WiFi works for the amount of power it uses. Actually, WiFi disproves that we'd have a tragedy of the commons. > Having a limit across the board for all mass manufactured devices prevents an escalating spiral of vendors selling 30, then 40, then 50dbm etc routers. No, the AP and the device both have a strong interest to limit the power used: not just to limit interference with other devices…
> No, the AP and the device both have a strong interest to limit the power used: not just to limit interference with other devices inside the home, but also to increase battery life!! For home routers this is a weak argument. Since most people download more than they upload, you could probably send a weaker signal from mobile devices and drown the air with signal from anything plugged into a wall socket. > I just don…
How exactly is your mobile device going to ACK those received packets? The mobile device needs to transmit as loudly as the AP for its ack to be received.
Boosting the transmit power higher than your receiving device can transmit leads to very bad wifi links, where the mobile device is receiving a good signal but it's own messages are not received back.
Earlier quoted context omitted.
Windows regularly puts and leaves radios in various low-power states that linux doesn't know about, so I generally need to cleanly shut down windows completely before booting into linux.
I posted this solution elsewhere recently: https://news.ycombinator.com/item?id=35113567 I think it is what you've been seeing.
Earlier quoted context omitted.
> No, the AP and the device both have a strong interest to limit the power used: not just to limit interference with other devices inside the home, but also to increase battery life!! For home routers this is a weak argument. Since most people download more than they upload, you could probably send a weaker signal from mobile devices and drown the air with signal from anything plugged into a wall socket. > I just don…
> you could probably send a weaker signal from mobile devices and drown the air with signal from anything plugged into a wall socket. How exactly is your mobile device going to ACK those received packets? The mobile device needs to transmit as loudly as the AP for its ack to be received. Boosting the transmit power higher than your receiving device can transmit leads to very bad wifi links, where the mobile device is…