Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I'm not sure if UEFI just disables the cores after it's done its thing, or if it doesn't touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.

How much Doritos dust are you willing to inhale?

I can't speak for these specific laptops, but unlike x86, ARM generally doesn't have a way for an OS to discover the available hardware, and most ARM platforms historically didn't do anything to help. There is a standard for UEFI on ARM where the UEFI is supposed to tell the OS about the hardware, but as far as I know this is only a thing on ARM servers and these laptops might not support it.

Without any way of probing for hardware or getting the information from UEFI, Linux has to somehow be compiled with all the info about the hardware built-in. And the build will be model-specific (there's a way to pass a file describing the hardware to Linux from the bootloader which enables a single kernel to be used on multiple models and have just a small part of the bootloader be model-specific, but somebody still needs to make that file and the manufacturers clearly don't intend to do that).

If it is an Arch-based distro (sorry, I don't recognize the package manager), then this might just be the recent Wine update that made it 700 MB smaller (which would mean the rest of your system grew 300 MB)

I made a post here about it: this one

Btw, is there a way to link to a post in a way that resolves on everyone's separate instance instead of hard coding it to my instance?

By taking away the MicroSD slot to force users towards expensive cloud storage?

While I agree with your view (at least when it comes to firmware, especially given that hardware that doesn't require a firmware upload on boot generally just has the very same proprietary firmware on a built-in memory, so the only difference is that you don't get to even touch the software running on it), the point of this project is to remove non-libre components from coreboot/libreboot.

It doesn't differentiate itself from upstream in any other way, so if it fails to do the one thing it was made to do, then that's in fact a newsworthy fact.

However, for most people, the 5-a-day limit might actually provide a better framework for taking high-quality images. This limit makes you think more about your shots, so it could be useful to improve. your composition, timing, and framing.

See, it's pro-consumer. Lol

From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…

That's almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env... Not quite, because coreutils is actually a single package unlike systemd.

The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that's on them.

You can now turn on the “autoscrolling” feature of the Libinput driver, which lets you scroll on any scrollable view by holding down the middle button of your mouse and moving the whole mouse

Am I crazy, or did this used to be a feature? And not just in Firefox

It's a Windows feature that never really made it to Linux. I used to miss it but honestly, middle click paste feels way more useful to me now

They would have to sign another contract for another 24 months to get it, nobody was getting an upgrade on the existing contract because it's just a bundle of Google services (One, YT Premium etc.) and financing on the phone. And if you don't care about the services, Google's two year financing is cheaper than this bundle.

Probably a bit of a TL:DR of the other answer, but the short answer is: the execute bit has a different meaning for directories - it allows you to keep going down the filesystem tree (open a file or another directory in the directory). The read bit only allows you to see the names of the files in the directory (and maybe some other metadata), but you cannot open them without x bit.

Fun fact, it makes sense to have a directory with --x or -wx permissions - you can access the files inside if you already know their names.

Edit: not a short answer, apparently

I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.

The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.

Generally yes. The Fn key is usually handled either by the keyboard itself or by the BIOS, and the OS just sees the resulting key presses as if the keyboard had all the buttons. Can you not find such a switch in your BIOS? Saying what vendor it is might also help someone help you.

Convenience (after you install it, all you have to do is enter the code and you're connected, no other setup required), familiarity (it's the default name people will think of or find if they want remote access - that alone means they can get away with pushing their users slightly more) and - IMHO most importantly - connectivity: if two computers can connect to the TeamViewer servers, they will be able to connect to each other.

That's huge in the world of broken Internet where peer to peer networking feels like rocket science - pretty much every consumer device will be sitting behind a NAT, which means "just connecting" is not possible. You can set up port forwarding (either manually or automatically using UPnP, which is its own bag of problems), or you can use IPv6 (which appears to be currently available to roughly 40% users globally; to use it, both sides need to have functional IPv6), or you can try various NAT traversal techniques (which only work with certain kinds of NAT and always require a coordinating server to pull off - this is one of the functions provided by TeamViewer servers). Oh, and if you're behind CGNAT (a kind of NAT used by internet providers; apparently it's moderately common), then neither port forwarding or NAT traversal are possible. So if both sides are behind CGNAT and at least one doesn't have IPv6, establishing a direct link is impossible.

With a relay server (like TeamViewer provides), you don't have to worry about being unable to connect - it will try to get you a direct link, but if that fails, it will just act as a tunnel and pass the data between both devices.

Sure, you can self host all this, but that takes time and effort to do right. And if your ISP happens to use CGNAT, that means renting a VPS because you can't host it at home. With TeamViewer, you're paying for someone else to worry about all that (and pay for the servers that coordinate NAT traversal and relay data, and their internet bandwidth, neither of which is free).

I mean, it's called "LaTeX by example", so there's a pretty good chance it's written in LaTeX, which you do indeed compile to get the PDF or whatever output you want.

Also, just having access to the source doesn't make it open source - that requires more freedoms. For example, here's GitLab Enterprise Edition source code, fully functional and ready to be used. And also officially described as the proprietary edition of GitLab by the GitLab company itself. Why? Because its license pretty much boils down to "you can use this only for testing and development, unless you have paid for it".

What's Steve?

The data collection can just as easily be done by the game itself, the launcher doesn't have any special privileges

You're supposed to use fingers

If a thief knows your PIN (by watching an earlier unlock), Android is now requiring “biometrics for accessing and changing critical Google account and device settings, like changing your PIN, disabling theft protection or accessing Passkeys, from an untrusted location.”

Sounds great for Pixel 6 series with their reportedly highly reliable fingerprint sensors /s

Honestly, I'm not sure what to think about this - extra protection against unauthorized access is good, but requiring biometric verification with no apparent alternative irks me the wrong way.

Maybe that's just because of my experiences with Nokia 5.3 and its awful rear fingerprint sensor with like 10% success rate. But then again, there will eventually be phones with crappy sensors running Android 15.

They're not doing a recall, but that doesn't mean they won't somehow compensate big OEMs for their warranty issues.