- But they don't actually differ, see the "no graphics API" blog post we're all commenting on :) The primary difference between mobile & desktop is performance, not feature set (ignoring for a minute the problem of outdated drivers).
And beyond that if you look at historical trends, mobile is and always has been just "desktop from 5-7 years ago". An API split that makes sense now will stop making sense rather quickly.
- well, it's a desktop GPU with desktop-class features from 2014 which makes it quite outdated relative to current mobile GPUs. The just released Switch 2 uses an Ampere-based GPU, which means it's desktop-class for 2020 (RTX 3xxx series), which is nothing to scoff about but "desktop-class features" is a rapidly moving target and the Switch ends up being a lot closer to mobile than it does to desktop since it's always launching with ~2 generations old GPUs.
- It's quite useful for things like skia or piet-gpu/vello or the general category of "things that use the GPU that aren't games" (image/video editors, effects pipelines, compute, etc etc etc)
- Only if you're ignoring mobile entirely. One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs.
- No longer needed is a strong statement given how recent the GPU support is. It's unlikely anything could accept those minimum requirements today.
But soon? Hopefully
- dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
- > Most of binder is in outright Java
None of binder is in Java. The Java binder code is just JNI bindings to the native implementation.
Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway.
> Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest.
unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc...
EDIT:
> The other libbinder (openbinder) is dead since 2006ish.
The libbinder I meant is the one in AOSP hence why I said "AOSP is right there":
https://cs.android.com/android/platform/superproject/main/+/...
That one is very definitely not dead since 2006ish.
- Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies.
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
- process-based sandboxing has hardware support and thus stronger defenses against things like spectre. So far every CPU on the market has only elected to address spectre as it relates to crossing ring or process boundaries. Nobody has added hardware spectre defenses for in-process sandboxing. Also, process-based sandboxing allows the guest to also have a full suite of security protections like ASLR. If you are doing sandboxing for defense in depth, reducing the security of what's inside the guest in turn reduces the security of your entire chain.
And I didn't say the performance penalty was because of sandboxing (although in the case of WASM there is cost as it's doing software enforcement of things that otherwise are "for free" in hardware), but just that WASM has a performance cost compared to native. If you are using WASM just for sandboxing, you still then pay a performance cost for portability you didn't need.
- WASM sacrifices guest security & performance in order to provide mediocre host sandboxing, though. It might be a useful tradeoff sometimes, but proper process-based sandboxing is so much stronger and lets the guest also have full security & performance.
- This isn't a Chinese government ban, though. It's a US export restriction, not a Chinese import restriction. So why would the Chinese government do anything at all?
- Now use rechargeable batteries that are not user replaceable
- Anecdotes etc etc but the AI tests I've been sent to review have been absolute shit. Stuff like that just calling a function doesn't crash the program. No assertions other than "end of test method reached"
Yes sometimes those tests are necessary, but it seemed to just do it everywhere because it made the code coverage percentage go up. Even though it was useless.
I have also had great experiences with AI cranking out straightforward boilerplate or asking C++ template metaprogramming questions. It's not all negative. But net-net it feels like it takes more work in total to use AI as you have to learn to recognize when it just won't handle the task, which can happen a lot. And you need to keep up with what it did enough to be able to take over. And reading code is harder than writing it.
- They meant this one supports being powered by POE: https://store.ui.com/us/en/category/all-switching/products/u...
Which is how I'm using mine actually, one less wall wart in the area I use them
- To be strictly accurate TSMC has exactly 2 fabs in China (Fab 10 & Fab 16). So it's not "none" in China, but very almost none.
- Why would you guess Chinese? Broadcom, Qualcomm, MediaTek, and Realtek are the typical answers for radio chips, no? None of whom are Chinese? There certainly are Chinese radio chips, such as from Espressif or Huawei, but they aren't especially popular in APs or anything
- And also Unifi lets you just buy stuff instead of "contact a sales rep". If I go to Netgear and filter primary port speed to 2.5g, which is hardly an enterprise spec, all 3 options are "contact a rep" which... no thanks. Who on earth wants to contact a sales rep for a 10 port 2.5gb switch?
There is now also TP-Link's Omada line at least which seems like the most comparable alternative.
- Netgear 5 port managed switch: $30 https://www.netgear.com/business/wired/switches/easy-smart/g...
Ubiquiti 5 port managed switch: $30 https://store.ui.com/us/en/category/all-switching/products/u...
Netgear 24 port managed switch: $260 (with a 1 year subscription included!) https://www.netgear.com/business/wired/switches/smart-cloud/...
Ubiquiti 24 port managed switch: $225 https://store.ui.com/us/en/category/all-switching/products/u...
Sorry, but what markup are you referring to?
I'm sure you can find price differences at different products & tiers, but quickly glancing around it sure doesn't look like Ubiquiti has any particular premium markup.
Regardless having a self-hosted, buy-it-and-own-it, non-business friendly product line absolutely has value. I loved my mikrotik switches when I was just messing around, but the single pane of glass, central management is not insignificant when time becomes a more precious resource and you just need it to work.
https://tpucdn.com/review/amd-ryzen-7-7800x3d/images/power-g...
from https://www.techpowerup.com/review/amd-ryzen-7-7800x3d/24.ht...