Hacker Newsnew | past | comments | ask | show | jobs | submit | pta2002's commentslogin

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.


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).


> both NixOS and Arch enable the QR code kernel panic screen

Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1)

Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.


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.


I believe Google has developed a Rust implementation of the binder driver which was recently merged, and they are apparently planning to remove the original C implementation. Considering binder is essential for Android that would be a major step too.


I can confirm that the ChromeOS debian container now has defaulted to turn off GPU acceleration, perhaps to turn on other acceleration on this Mali.


You can force a panic with echo c | /proc/sysrq-trigger


This is so cool! I love things like that, it feels like fresh air after years and years of anachronistic retro-vibes that seem to be a part of C-programming culture.


Arch never failed me. The only time I remember it panicked was when I naively stopped an upgrade in the middle which failed to generate initramfs but quickly fixed it by chroot'ing and running mkinitcpio. Back up in no time


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!


Ooh, thanks for the systemd clue. I'll see if I can find that work.


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.


Namely the fact that emergency calls can be routed through other networks that aren’t your own (in fact, you can place an emergency call without a SIM).


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.


I see the same bugs. It looks like after ICQ, writing a chat app has become an impossible computer science problem (skype, teams, whatsapp,…). How did that ancient civilisation from the 90s managed to build a functional chat app? The know how is lost to times.


> How did that ancient civilisation from the 90s managed to build a functional chat app?

By only accepting ANSI input, not encrypting any messages, and not bothering to protect users' from remote attacks.

Facebooks's GUI stack for WhatsApp may be rather buggy but on a technical level there's a lot more going on than back in the days of unencrypted TCP connections over plaintext protocols.

Meanwhile, Telegram has an excellent desktop app (despite their terrible protocol), so it's not like the knowledge was lost either.


SSL and basic encryption isn’t exactly rocket science today. I have not used the telegram desktop app but their web app is completely broken.


Secure, end-to-end, multi-device encryption isn't easy. Plenty of people try and fail to build secure messengers based on top of PGP and Signal's protocol.

I don't use the Telegram web app, but their native apps work excellently. The insertion of ads has been a major disappointment but the chat UX itself is still great, even on native Linux.


But Telegram end-to-end encryption is optional as far as I know.


It is, and it's a good reason to avoid the platform, but they do support E2EE _and_ have a good, native desktop application.


> have a good, native desktop application.

Indeed. I'm not actively using Telegram, but I tried the desktop application (made with Qt if I remember well), and it's way ahead of what Whatsapp offers. Not to mention it's fast and relatively light.


It's made with Qt indeed, the source code is here: https://github.com/telegramdesktop/tdesktop

Facebook could just take the app, change the colour's to make it green, and replace the messaging protocol with their WhatsApp library, and they'd get an actually usable chat client practically for free.


The more time passes, the more impressed I am with mIRC. It was an incredibly fully featured chat client - with hundreds of features, and its own scripting language for more advanced use. All that in a 4mb download. It probably still works great, to this day.

As a teenager, I thought we'd get better at making software over time. Not worse.


It still works great and it's still being updated! https://www.mirc.com/news.html


Modern chat apps work better and have more functionality. The knowhow is specifically for Windows chat apps. And the reason the knowledge was lost is that Microsoft sucked at platform design so people stopped learning their platforms and the people who still have the knowledge don't want to go down the career dead end of writing apps for them.

This is partly because MS became insanely complacent. The Windows team is very junior. Just ask anyone who has worked with them. They don't have the skills or resourcing that they did in the 90s.


early ICQ didn't have to support Unicode IMEs either...


If is anything like the WhatsApp Web, "works" might be optimistic choice of word.

When I switched from Windows, the thing that I missed from Windows on Linux was the native WhatsApp App. Now they killed there, so feeling better on my switch now!


The WhatsApp web app is not perfect (no software is) but I’ve never had any major issues with it. It’s snappy and very rarely does it glitch out. I find your comment surprising.


It's a ram hog if you stay the tab open for a while, with ton of messages. So from time to time I need to close the tab and open again.

Huge perf issues because of this.

Also had some serious bugs for a few week. Had to let WhatsApp Web wait for completely sync for 15 minutes~ or else it just stop responding and crashes everything.


I don't think it is Electron, it's WebView2 https://developer.microsoft.com/en-us/Microsoft-edge/webview...


Yes, also a heavy user and I'm actually excited about this change. I'm sure the Electron app won't be perfect but I am sure it won't be worse.


I agree but also: famous last words. :)


IIRC (I tried it last year and gave up) the desktop app also didn't properly deal with archived chats, and maybe some other notifications behaviors.

Maybe this will make me try the desktop app again.


Sounds like the all powerful mighty Meta didn't have capable engineering working on that app. No idea how that could happen, given that they only hire top talent ...


While I don’t have as many problems as you seem to, I did notice that it was much slower (like a minute or two) to “connect” after opening the window compared to before.


Have you tried telegram desktop to compare? I don't use whatsapp, but I have never had a performance problem with telegram desktop and I've been using it for years on underpowered machines. I usually run some variant of Debian on them.


Yeah I tried telegram. None of my contacts did though…


Yeah, I'm sure that a lot of people notice the same thing then uninstall it. It's one of the solutions to the Fermi paradox, that both people have telegram installed at the same time.


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).


Why does a fan app need to find the WiFi networks? The OS does this, and then serves an internet connection to the app. It doesn't need to know what the available networks are.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: