> this work is focused on laptops with Snapdragon X2 Series. It does not currently cover desktop form factors, earlier Snapdragon X platforms, or other development boards. Readiness also varies by OEM design and Snapdragon X2 Series variant.
So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.
I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.
"I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob."
add in swappable batteries like older laptops and phones, and I would as well. not now though.
As a KDE Connect user for a few years I know it doesn't always work without reconnecting especially with sleep cycles on the phone and the laptop but it does everything on Android at least - clipboard sync, notifications, sms, calls, remote control and media playback control. Must be iOS restrictions that made the author go through the admirable effort.
IOW Linux ecosystem has better vertical integration without any direct ties with Android :)
My absolute favorite feature in KDE Connection is full audio device output / input control remotely so I can silence notifications without getting up or start playing music through the speakers.
Writing linkers must be incredibly rewarding - go has its own, there's mold, there's LLD, there's the OG GNU bfd LD and now Zig has one too! I am sure there's a Rust one too - Wild!
Every one of them is faster than the others too lol! Mold for one tries really hard to be GNU ld and to be useful as an independent linker most have to - I guess Zig/Go ones are purpose built so at least those don't duplicate GNU ld compatibility.
Sure, but one might imagine that linkers are generic and reusable, so you can just pick one off the shelf instead of making a new one 1-1 for each language. Empirically this line of reasoning seems to be incorrect.
Different programming languages are very obviously not the same thing - different cp command implementations are similar conceptually to having different linker implementations that all do the same thing. But you knew that so not sure if there was a point you were trying to make there.
> Different programming languages are very obviously not the same thing
It isn't obvious to me at all. The difference between Java, C# and Go is about as important as the difference between Makita and Bosch for power tools. Yes, some people swear by one or the other, but by the end of the day it really doesn't matter
Now they only need to make sure that a supply chain for replacement batteries exists, there is regulation and competition and options remain available for a reasonable price.
There are plenty of old Dell and HP laptops with replaceable batteries which can only be found on eBay or some random seller that does who knows what under the refurbishing process.
Exactly. I had phones and laptops with replaceable batteries in the past. I liked the idea of it, but in practice there was no OEM-quality replacement available by the time I wanted one. The device would have been usable to me still, but not with a random black market battery that may well be a fire hazard.
Having thought about this long term, I think the only solution to this would be mandating standardized battery cells. Rather than every phone model having a bespoke cell that is manufactured once and then obsoleted, they need to have standardized shape and electrical characteristics so that batteries being produced for new phones would also be useful to rehabilitate old phones.
I expect we'll see a spike in cell phone battery fires starting about a year after this goes into effect. Same deal as cheap external battery-powered travel power banks, which are already a problem.
> Now they only need to make sure that a supply chain for replacement batteries exists, there is regulation and competition and options remain available for a reasonable price.
No, they won't do the hard part. Just the minimum plus a ton of PR and back patting then move on.
I am a full time KDE/Arch user and since Plasma 6 haven't had any HiDPI issues including monitors with different DPI or X11 apps - of which there are very few nowadays.
Fedora 43 with KDE - have been using 140% scaling with my Dell Ultrasharp 32" 4k monitor - no issues whatsoever. I've noticed that the Dells do a pretty good job with Linux - I have used monitors of various sizes ranging from 27" to 43" and never had any issues on Linux.
> Tesla’s fix will involve an additional redundancy to keep the lightbar affixed to the windshield, should the glue fail.
Good news - it only affects 6000 vehicles with the optional lightbar which is dealer installed. Bad news - Tesla finds it ok to let its dealers do glued lightbar installations and can't really fix the glue failing part so they are adding redundancy.
I meant the I have no interest in knowing anything about any company's internal tech stack and also no interest in tying my application to one company's internal stack. Much of it sounded like lock-in to me.
> The bidding model is elegant, but it’s insufficient to route network requests. To allow an HTTP request in Tokyo to find the nearest instance in Sydney, we really do need some kind of global map of every app we host.
So is this a case of wanting to deliver a differentiating feature before the technical maturity is there and validated? It's an acceptable strategy if you are building a lesser product but if you are selling Public Cloud maybe having a better strategy than waiting for problems to crop up makes more sense? Consul, missing watchdogs, certificate expiry, CRDT back filling nullable columns - sure in a normal case these are not very unexpected or to-be-ashamed-of problems but for a product that claims to be Public Cloud you want to think of these things and address them before day 1. Cert expiry for example - you should be giving your users tools to never have a cert expire - not fixing it for your stuff after the fact! (Most CAs offer API to automate all this - no excuse for it.)
I don't mean to be dismissive or disrespectful, the problem is challenging and the work is great - merely thinking of loss of customer trust - people are never going to trust a new comer that has issues like this and for that reason move fast break things and fix when you find isn't a good fit for this kind of a product.
I was referring to the "HTTP request in Tokyo to find the nearest instance in Sydney" part which felt to me like a differentiating feature- no other cloud provider seems to have bidding or HTTP request level cross regional lookup or whatever.
The "decision that long predates Corrosion" is precisely the point I was trying to make - was it made too soon before understanding the ramifications and/or having a validated technical solution ready? IOW maybe the feature requiring the problem solution could have come later? (I don't know much about fly.io and its features, so apologies if some of this is unclear/wrongly assumes things.)
fwiw, I'm happily running a company and some contract work on fly literally as aws, but what if it weren't the most massively complex pile of shit you've ever seen.
I have a couple reasonably sized, understandable toml files and another 100 lines of ruby that runs long-running rake tasks as individual fly machines. The whole thing works really nicely.
Bye Microsoft - I'm already on Linux on all my desktop and workstation machines and working on migrating off of the MacBook Pro.
It's only going to get more and more unpleasant in the commercial desktop OS landscape - need to start contributing money and effort to few OSS projects to keep the dream alive.
So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.
I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.
reply