Markaos @ Markaos @lemmy.one

Posts

6

Comments

217

Joined

2 yr. ago

Automatically and silently through Google Play if you are on Android 12+. You most likely already have this update.

I believe a USB WiFi dongle will be a better idea than modifying live images of various distros, and others are already pointing you in the correct way for that, but I feel the need to correct one thing:

Okay, so maybe I can add some driver files to the LiveUSB or something? . . . nope. Not a good idea, because the other part of the whole fix is installing firmware, which has to be in place before the drivers will work -- but this chip is also still being used by the onboard Mac OS.

The WiFi module doesn't have any persistent memory for firmware, which is why the system needs to bring its own firmware - it is uploaded to the chip on every boot as part of driver initialization. So there is no risk of interfering with macOS here.

The installation in the guide refers to putting the firmware in a place where the driver will be able to find it. In other words, you would be installing the firmware on the Linux system, not onto the WiFi module.

Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

There's no limit on the number of concurrent connections on a single port, and SSH runs completely on the one port it is configured to use. Otherwise allowing just the port 22 in firewall wouldn't be enough to have a functional SSH connection with default settings.

You can verify that quite easily for example by spinning up three barebone Debian VMs connected to a single virtual network, configuring the firewall on the "server" VM to drop everything other than port 22 and then connecting from both client VMs - it will work just fine.

Maybe you're confusing it with the fact that only one process can listen on a given port at a time? But that's only for establishing new connections. Existing connections can be passed off to another running process or a child process just fine, and that's how SSH handles separation between connections.

Edit: oh, you're talking about the high port OP is wondering about. That's just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH "moving connections over"

you might want to maybe try a different distro image to verify, maybe a simple kernel with a net image or something.

This part actually makes me wonder... Do you think SerenityOS uses the Linux kernel? Because it does not, it's its own completely separate thing. And the hardware support for anything other than the standard emulated machine is very iffy, so it doesn't seem too surprising that it would get tripped up by something on an old computer.

If anything went wrong with its USB stack for example, the kernel would have no way to find the root filesystem that's stored on a USB drive.

I haven't done that, lemmy.one doesn't even have downvotes

Yep

I mean, there is the whole 128/8 for localhost, kinda hard to beat that with crazy allocations. And OP still has another /12 and /16 networks available even if they refuse to further divide them.

Usually the problem isn't that the changes are big, but that the new way simply isn't compatible with the old way to do things, and you can't just make a change that will break existing applications in minor versions (well, there's nothing technically stopping you, and unintentional compatibility breaking bugs have definitely happened in the past, but people are gonna get real mad at you if you do that). Even if you break that change up into thousand tiny changes over many minor versions, the end result is that at some point, you break old apps.

The solution is to take note of all the things that are either badly designed or became obsolete and once in a while go "hey, let's make a new major version and fix all of this crap". With a new major version, you don't have to worry about old applications and are free to improve your library in any way you wish, and you also get the option to keep updating the old major version with some maintenance bugfixes so that the old apps keep working well enough.

Yes in the sense that the APIs were made because of flatpak, but not in the sense that devs would need to keep two separate code paths for flatpak vs non-flatpak - portals work everywhere.

No, kernel immediately stops execution of all normal processes once it gets into a kernel panic, and there's no way for processes to hook into this functionality. It is intended to be the emergency stop state when the kernel realizes it doesn't know what's going on and it would be dangerous to continue executing. So it does the bare minimum to report the issue and then stops even its own execution.

There's also a softer variant of the kernel panic called kernel oops that should let the user choose to continue if they think the risk of data corruption doesn't outweigh losing all data currently in memory. But just like the kernel panic, it is handled completely inside the kernel and userspace is frozen until the user chooses to continue.

This is intended for situations where systemd runs into an unrecoverable issue while booting (for example you have misconfigured fstab and a required disk is missing). Without this, you just get thrown into the terminal with some error messages that might not make much sense to you if you don't have a decent understanding of Linux. Now, you get a more newbie friendly message and a QR code that should bring you somewhere you can learn more about possible causes and troubleshooting steps.

Well, this goes the other way than ray tracing - it degrades graphical fidelity but improves performance. That should result in better FPS at the same power consumption or lower power consumption at the same FPS in games, and mobile gamers will probably welcome both effects.

Google isn't the entity that discovered this bug, random beta testers did during the public beta and reported their issues.

No, face unlock on Pixels doesn't do anything to illuminate your face, it simply refuses to work if the lighting's too dim. It's actually worse than the face unlock in Google Smart Lock in dealing with low light environments.

Have you tried fully discharging it? It depends on the specific battery management system in your phone, but my Pixel 7a doesn't take being kept at 30-60% battery too well and loses track of the actual charge level. AccuBattery was reporting about 80% capacity on it after two months.

Then I decided to let it fully discharge and found out that the thing just refuses to die at 1% - that last percent took me about the same time to discharge as going from 20% to 1%. And now I'm back to 98% capacity reported by AccuBattery and the actual battery life has improved noticeably.

Yeah, 24 hours of SoT is impossible with Pixel 7 series. I mean, the idle drain alone will kill my 7a in 48 hours, and any amount of active use will just make it worse.

This is after two days of sporadically checking email and taking a few photos (about 40 total, no video) on stock Android 14:

Fairphone doesn't seem to care much about security (they use public keys for signing their OS afterall!), so they may be fine with those compromises.

Any source for that claim? Digital signing works with key pairs - a private one for signing and a public one for verifying that something was signed by the corresponding private key. So I take it you're saying they publish the private keys used for signing somewhere?

Nowadays, even the cheapest phones are sufficient in terms of power for the most demanding regular user activities such as social media , watching videos, taking good enough pictures and light gaming.

Eh, try doing that with HMD's Nokia 5.3 - Instagram was a PITA with frequent long stutters and the official YouTube app was nearly unusable (NewPipe for the rescue). Oh and its camera app also kept randomly forgetting to actually save the photos I took after updating to Android 11 (which came with a year long delay behind upstream, so I was already out of warranty once it hit), and Android 12 update earlier this year did nothing to fix the issues but made it so that factory resetting would permanently brick the phone, so that troubleshooting option was also gone.

There were other issues with unreliable rear fingerprint sensor and touchscreen towards the tail end of me owning the phone, but I'm willing to consider those hardware issues with just my unit.

Yes, I'm a tiiiiny bit salty about that, mostly because Nokia is the last cheap way to get close to stock Android and now I just have zero trust in them and am forced to pay more for a Pixel.

Nokia 5.x wasn't even the lowest product range, they also made corresponding 3.x phones, but maybe those were better thanks to Android Go?

The thing is that they've clearly promised 7 years now, walking back on the promise would cause them massive issues with consumer protection agencies everywhere they sell - they might be toothless in the US, but Google also sells Pixels in Japan and the EU.

I'd love it too with my 7a, but there's no way Google does something nice just 'cause. They've already sold the phones with a shorter support window and they gain nothing by releasing more updates for those devices.

Infinity did pretty much the same thing a few weeks ago. Now I'm a happy Eternity (previously Infinity for Lemmy) user.