HN user

pta2002

476 karma
Posts3
Comments128
View on HN

Google’s phones are pretty good nowadays, I feel like they carry that ethos more than modern OnePlus phones anyway. Plus they can be unlocked trivially, which is officially supported, and you can install GrapheneOS on them.

Ryanair has only ever lost a plane once, due to a bird strike with only some injuries, and they are one of biggest airlines by number of flights (if not the biggest).

Turns out plane accidents are expensive, and the reputation loss as well. Don't even need to lose the plane, just the plane being stuck on the ground is expensive (they are also one of the most timely airlines because of this). Really can not afford to have accidents!

Honestly I just don't really care to anymore. I used to flash custom ROMs on all my phones because I could only afford cheap (100-200€) phones that were filled with bloatware, but ever since I started being able to afford a decent mid-range phone (Pixel 6a was the first one I didn't reflash) I just found out I wasn't actually missing anything, and I definitely enjoy things like contactless payments, and not having something randomly break every time I update.

Same with me, apparently three different models think I am a minor football player. Looking it up, I am not the first result for my full name, but there also is no minor football player with that name, so…

Also have an extremely common name in Portugal (just in my company there are 4 people with my name, including my previous manager), only slightly helped by the fact that we’re one of the few countries that inherits last names from both parents, which helps with differentiation. At least I did snag pedroalves.pt when I found it available!

EDIT: Username does better, but for some reason Kimi seems to think I do algorithmic competitions, and Llama 3.1 thinks I am a German football club (no longer just a player, a whole club now!)

They’ve got external kernel modules that they use for some hardware that is not supported upstream, namely the GPU, but also some things like Ethernet I think. Everything else is upstream though, so the situation is similar to a regular NVIDIA GPU.

Who would’ve thought that NVIDIA started upstreaming stuff once they realized how much money Linux is making them?

Nowadays upstream Linux with UEFI mostly works, with their out of tree drivers. I’ve managed to make it work in NixOS with the stock kernel. Look at the open embedded L4T project, they have some recipes for building that. No need to use nvidia’s kernel anymore!

Also, supposedly on the second half of 2026 they were going to be moving even more stuff out of their Jetson-specific drivers as they already do for their slightly newer chips (so you could use the standard drivers, and standard CUDA builds). Let’s see how that turns out.

I assume a selfish benefit is that OpenAI and Google don't want the models to train on their own data. There is just /so much/ AI generated content online that they definitely need to filter it out somehow when assembling the training data. This is a pretty effective way to do that, with the nice bonus of being mostly good from a PR standpoint.

Update: I was wrong, check max-m's sibling comment! The satellites just move really fast across the camera because they're in LEO, so they can traverse rather large distances before there's a new exposure and a small gap.

Probably exactly that. If you take a single 10 minute exposure (or really, anything more than a few seconds) you'll get noticeable star trails if you don't put your camera on a rotating mount. Stacking multiple exposures also has other nice benefits such as noise canceling itself out and being able to remove satellite trails.

Last time I did astrophotography was a few years ago, before Starlink made the problem considerably worse, but satellite trails were relatively easy to remove with stacking. I'm sure it's harder now but definitely still possible, so I'm assuming in this case leaving them in was done on purpose to highlight the problem.

EDIT: Looking better at the picture, I belive this was taken with a star tracker and then composited with a shorter exposure of the foreground. Notice how the foreground, even far away, looks considerably blurrier than the stars, and how the tower in the background has some light streaks. This is exactly what you'll see if you use a star tracker. Rather than star trails, you'll have "foreground trails". This would explain why there are relatively few gaps in the satellite trails, since the exposures can be much longer.

I work on automotive software (not Tesla), and it's like this partially because it makes development _way easier_. Rather than needing to get a whole car to the dev team, you just give them the specific part that they're working on. Anything that needs outside features usually just fails gracefully (e.g. no speedometer or no location for maps). These are usually mocked for testing, or you add the specific ECU that provides it for your testing setup if needed.

Modern cars have tens of ECUs, so if you had to have all of them for testing, that would get unwieldy extremely quickly. Not to mention that cars are pretty resilient to having random parts failing, you don't want to lose the entire dashboard just because the ECU that provides camera data failed, or something.

That’s not really incompatible with this? That’s just how secure boot works. You can re-enlist keys for a different root of trust, or disable it and accept the trade-off there.

As of this past year (6.15+), most stuff you’d need for a regular desktop is upstreamed. Collabora has been working pretty hard on getting the chip mainlined, so it’s on a very good place compared to something like the Pi 5, which is not at all what the experience used to be in the past!

It doesn’t really. Server side mods don’t touch rendering code at all, and most client side mods also don’t come anywhere near it. I last did Minecraft mod development some 7 years ago but even then you would basically never reach into the raw drawing calls unless you were implementing shaders or something.

Considering the vast majority of mods are just adding some items or creatures, they don’t need to worry. This won’t be more than the regular API changes in between versions that they’re already used to, unless it’s a more graphics heavy thing like a shader mod.

Also, even with shaders, it’s fairly straight forward to port a shader from OpenGL to Vulkan (for the most part Vulkan just gives more flexibility in that regard). The stuff around it is the hard part.

Yep, that's what I'm referring to.

For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return:

- Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver

- The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver

- The Tyr GPU driver for Arm Mali GPUs - https://rust-for-linux.com/tyr-gpu-driver

I suspect the first one of those to be actually used in production will be the Tyr driver, especially since Google's part of it and they'll probably want to deploy it on Android, but for the desktop (and server!) Linux use-case, the Nova driver is likely to be the major one.

A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).

I have an X1 extreme. I’ve never gotten it to last over 2h on Windows. On Linux it can last an hour or so more if I turn off the NVIDIA GPU, but otherwise it’s still abysmal.

Then there’s the stupid BIOS warning that requires you to press ESC for the computer to boot if it’s not plugged in to the official charger, which means that if it ever reboots at night it’ll just keep you awake (because the power management hasn’t been initialized yet so it’s stuck at 100% CPU) until you go press ESC.

Oh and it thermal throttles all the time so the CPU performance is good for a few minutes and then it’s just awful.

Unfortunately the TPM story for the raspberry pi… isn’t, really. It doesn’t come with one, and while it does support secure boot, it’s incredibly limited and more akin to what you’d find in a microcontroller (you can burn vendor keys to EEPROM). So all that to say, it would be kind of pointless, unfortunately.

I’d you’re interested in this, I know systemd has been working pretty hard on getting TPM-provisioned credentials usable on Linux though!

I've encountered systems that only have bash in /bin/bash, or in /usr/bin/bash, and it's a hell of a pain to have to fix every script when using different distros (I think it must've been an old Fedora and Ubuntu?).

Nowadays, most distros are moving towards having /bin be a symlink to /usr/bin, so it's mattering less and less, but I see no reason not to just do /usr/bin/env which is supposed to be on the same place on every distro.

Seconding the other user saying that I also use AirPods Pro (2nd gen) in Teams at least twice a day, on macOS, iOS, and Windows (and had used them on android before, as well). Absolutely no issue whatsoever, and everyone mentions I usually have by far the best audio out of anyone else in the call.

What would Apple even gain out of this? They don’t have a competitor to MS Teams, FaceTime is hardly targeting the same segment.

I do want to point out, as someone who uses the WhatsApp app (to me, it’s slightly more convenient than the web version) that the old native windows app was /awful/. It looked native enough, but it just didn’t work. For as long as I remember it would randomly stop accepting input into the text field and I’d have to restart the app, and this was insanely frequent. Typing dead keys was also randomly broken with accents not coming through, which is really annoying if you’re trying to sound professional on a language that requires them.

The new electron app does take more resources, but at the very least it works.

The location access is often needed for the app to be able to find the WiFi networks in the neighborhood. This is because that can be used to triangulate your location, so they bundle it in with the same permission (unfortunately, there isn't a very good way to separate this, since it theoretically can be used to locate you and therefore you should let the user know that).

The alternatives are all closed-source protocols. A ton of things are backed by Google. It doesn't mean that they have anything to do with it other than them being consulted in its design and providing some official support. And considering Google makes the most popular mobile OS, and also the most popular TV OS (which is relevant considering it's smart home), it's good that they're in on it. Otherwise you end up with a fractured situation like you currently have with things like Airplay, Chromecast and Miracast, which are all the same thing with slightly different implementations because they couldn't agree on a protocol.

And I'd vastly prefer it that Google (and Apple, and Amazon, and Home Assistant, and IKEA, and Philips, and...) all agree on the same protocol than each vendor making up its own thing.

I found the whole site a very interesting (and fairly quick) read. I don't really have anything else to add, but I'm glad the owner manages to be honest and take good lessons from the whole thing.

It's interesting to me how from his account, everyone is fairly sympathetic to him regarding his charges (he mentions his employer showing up to his interview in a sports jersey in reference to his charges!), and how he mentions he knows several actual sports players used his site. It really goes to show the state of modern streaming.

While you could do that, the hub needed to implement the logic to actually convert the different "APIs" that the products spoke. E.g. imagine an IKEA remote sends "button_on" to turn on the light, but the Philips remotes send "light_on" or something. Philips lights will work with their remotes but not with IKEA remotes, since they wouldn't know what to do with "button_on". Zigbee2mqtt and ZHA are great projects that implement a compatibility layer to all of this, but they do have to explicitly support every device (and they support basically _every_ device there is, thanks to a ton of community work, they're genuinely great projects and something that wouldn't really be possible without open source). You mention that you can pair between different vendor's products, but that's not quite the case - you can pair different vendor's products to the hub, and the hub can translate between them. But while you can pair an IKEA remote to an IKEA bulb without a hub, you can't really do that between different brands.

Matter simplifies this. It defines the API layer. You can use Thread without Matter, at which point you basically have Zigbee + IPv6, but the power comes with Matter since now every device is speaking the same language and can actually understand each other.