Isn't the main difference that Apple is building something like 4-16 channel memory controllers in a mobile device while you normally don't get more than 2-4 channels even on a desktop? That's a lot of transistors and (potentially) power usage but if you can get on the latest node and have a market willing to pay for giant chips it lets you get impressive amounts of bandwidth.
I don't think you need the RAM to be on the same package for that, it just makes the timings easier.
Apple appears to have a one of a kind special license for ARM (due to being a founder of the company) so they can pick and choose otherwise "required" extensions to support and add their own extensions as well. You can't directly compare an Apple design to a specific ARM version because of this.
There is a chance you're using RISC-V CPUs right now. Nvidia GPUs use them for their management logic (GSP) and Seagate/Western Digital are using them for HDD controllers. ARM used to only be used in these kinds of workloads too, you have to work your way up the stack.
LineageOS is a fork of Android, not some separate thing. You can set it up to have all those apps work, same as you can after you root a stock Android install.
This is eventually going to be a feature-complete compiler, targeting a specific rustc version. I believe the plan is to use polonius [1], presumably as an "optional" feature so they can build a stage 1 without it, use that to build polonius, then build the final compiler with it included.
PulseAudio optimizes for power consumption but tries to be adaptive to handle lower latency as well. PipeWire seems to optimize for latency but try to be adaptive to reduce power consumption as well. These are conflicting desires, lower latency requires higher power usage because you have to use shorter buffers instead of just giving the sound card a big chunk of audio to work through and putting the CPU to sleep. JACK could potentially still do better and ALSA could potentially still do better than even that but PipeWire's goal is to be close enough or even match JACK while still having all the other features people use PulseAudio for.
Raw ALSA can only have one program playing sound unless your hardware has support for hardware mixing (this would generally mean it's very old and also very expensive). More likely you are/were using ALSA's dmix plugin which is a small barebones version of the core functionality of pulseaudio or pipewire. They replace dmix but also give you things like per-program volume control, better latency, better power usage, better mixing, bluetooth support, the ability to do fancy things with audio routing without restarting every program playing audio, etc.
Zuckerberg said the FBI told Facebook they had intelligence there was going to be a Russian misinformation campaign right before the election. The FBI didn't tell them _this_ was that campaign, that was an assumption made by Facebook.
As far as I know permissions are at a process level, not a module/dependency level. This means if something in your application needs to be able to read/write a file then all of your dependencies can as well.
I remember seeing this wasn't possible because the CPU uses 16KB page tables but GPUs only know how to work with 4KB but I can't find the reference anymore. I don't know if this just requires a change in VBIOS or a whole new GPU but it would mean it's up to nvidia, AMD, or Intel to make a Mac-specific GPU even though no Apple Silicon devices have PCIe slots so it would only be for the small minority of Mac users inside the small minority of eGPU users.
Vulkan is a lower level API than Gallium so they've had to create new abstractions at the Vulkan level. This is why the ANV (Intel) driver is what everyone copy/pasted from, there was no shared code at the Vulkan level at that point. Over time they've taken the parts people were copy/pasting and turned them into generic things all the Vulkan drivers can call instead.
Gallium is still the way everything else is implemented (OpenGL, Direct3D 9, video decoding, OpenCL) for drivers. One of those drivers is Zink which implements the Gallium OpenGL state tracker on top of Vulkan and another is D3D12 which does the same on top of Direct3D 12 (for WSL2). Not every driver supports every state tracker, in general all you can count on is some version of OpenGL to be supported (4.6 for Zink, 3.3 for D3D12).
Those tools didn't work well for things that need to adjust to different screen/window sizes or even for localization causing text elements to change size. For that kind of stuff you need some kind of dynamic layout like springs & struts, flexbox, etc. I think Qt and XCode have drag and drop UI designers for layout systems that work that way, instead of picking an exact position for things you pick their location and size relative to their contents and things around them. I find just using CSS to be easier to think about than those but they're nice for trying things out.
TikTok is paying their ISP, that's who you'd look at to fund upgrades to the interconnect. Wanting to charge TikTok or the users of TikTok is just looking for a way to double dip. Or, more likely, a way for them to deprioritize YouTube TV so their own streaming live TV service looks better.
A different runtime wouldn't be able to make the compiler use a different stack allocation strategy (like Go's segmented stacks), for that the compiler needs to know what you're doing. Even if they also did that via having two ABIs for every platform (green vs native) it would essentially bake in a particular runtime as you wouldn't be able to experiment with these lower level primitives, only how you interface with them. If they ever define a stable ABI having two ABIs depending on thread type would also fragment the ecosystem at least as bad as the async runtimes do.
As far as async runtime fragmentation you can write code that is generic across runtimes, it's just less convenient to use. If your code only works with plain data and futures you're fine on any runtime, it's when you want to spawn new tasks or block on a task that you have to have a runtime dependency. Async vs sync is the classic "what color is your function" problem which green threads kind of solves but not completely so you still have to understand what is happening so you don't stall every task on a native thread with CPU heavy or blocking work.
Rust started on this route but decided easy C interop and no required runtime were more important and trying to have everything made green threads slower than native threads.
> It is Gtk and Qt that for wahtever reason decided to ditch their Xrender backends.
It was often slower and more likely to run in to driver issues than just doing software rendering and sending pixmaps. They're now moving to GL and Vulkan because they can be faster and while they have the same risk of driver issues at least that's the same stack used for video games and CAD and such so more people care about it working well.
In a world where Facebook doesn't have a freedom of speech right to remove a post without also losing section 230 protection do you think freedom of association could cover removing specific posts or only banning users outright? Would Twitter's model of banning a user until they delete their own unwanted tweet(s) be okay?
This is probably the data as they have it and instead the people responsible for inputting things in to whatever system this data came from just have a little print out taped next to their screen reminding them customer XPN305 has a 10% discount on codes that start with FJR and so on.
There is no way to "target wayland" for a tool like this. For security reasons pretty much everything this tool does is blocked on wayland. You could perhaps make a version for sway and other wlroots-using desktops that works mostly like the current tool. For GNOME you might be able to get away with rewriting it in JS as a shell extension, no idea for KDE.
This is what Microsoft Research's Singularity OS did, with the language being C#. Their argument was that the MMU's address space isolation was a 30% Unsafe Code Tax so even if C# was slower than C if they could get the slowdown to less than that it was still an overall performance win.
I'm pretty sure the discovery of Meltdown/Spectre and similar speculative execution attacks would completely wreck this model. The fix for those exploits has been to make the isolation barriers even stronger but if you don't have them at all you're wide open. If you had such an OS but then had to split it back into separate address spaces you've now lost the performance gains and just have a slower OS that is harder to develop drivers for.
The argument for high oil and gas costs sticking around this time is that the producers have realized they'll be effectively wiped out in 20-30 years, assuming we get anywhere close to meeting climate goals. There will always be a need for oil and gas but if it's not being used for most heating, transportation, or electricity generation that demand will be a pittance of what they get today. This realization has led them to essentially halt new production and lean hard in to scarcity to get all they can out of a dying market, even if doing so makes that market die faster.