Markaos

Well, feel free to click on this link then: https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en

(it's just a link to Google homepage - the point is that you really shouldn't trust the link text lol)

What's sketchy about https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en ?

Not a fair comparison IMHO - Ethernet is designed to be a connection between two or more otherwise independent peers (on L2), while USB's goal was to allow connecting simple peripheral devices to computers. There was never meant to be a situation where it's unclear which side is the Host.

Also note that the bridging "cable" is literally just two USB devices, one for each computer (although they are both on the same chip, so there's that), with some internal link to pass the data.

Yeah, it's not practical right now, but in 10 years? Who knows, we might finally have some built-in AI accelerator capable of running big neural networks on consumer CPUs by then (we do have AI accelerators in a large chunk of current CPUs, but they're not up to the task yet). The system memory should also go up now that memory-hungry AI is inching closer to mainstream use.

Sure, Internet bandwidth will also increase, meaning this compression will be less important, but on the other hand, it's not like we've stopped improving video codecs after h.264 because it was good enough - there are better codecs now even though we have the resources to handle bigger h.264 videos.

The technology doesn't have to be useful right now - for example, neural networks capable of learning have been studied since the 1940s, even though there would be no way to run them for many decades, and it would take even longer to run them in a useful capacity. But now that we have the technology to do so, they enjoy rapid progress building on top of that original foundation.

You could put your .desktop files in a separate directory and just symlink them to ~/.local/share/applications. If you want to have all your aliases together, you could have a directory like Aliases or whatever and then have Aliases/desktop for .desktop launchers, Aliases/bin for scripts or binaries (and have it in PATH), Aliases/bashrc for your bash aliases (and just put source .../Aliases/bashrc in ~/.bashrc), etc.

Of course everyone has their own opinions on how to organize stuff, but this is IMHO pretty clean for what you probably want to do.

Edit: and to quickly (re)create the symlinks, you could use a bash one-liner like for f in .../Aliases/desktop/*; do ln -s "$f" "~/.local/share/applications/$(basename "$f")"; done - put it into your bashrc as a function and remember to run it whenever you create a new .desktop launcher, and you should be golden.

You get a special unique(?) cryptographic token

I might be nitpicking, but IMHO it is perfectly reasonable to read this as questioning whether the token itself is unique, which is how I read it. The idea of non-unique NFTs then made me write a short quip about it, that's all.

~~Honestly, I'm kinda surprised that the live translation in Google Camera wasn't dependent on other Google apps before - I thought all Google apps were developed with the assumption that the apps mandated for Android certification would be available, and that losing functionality if the user starts disabling stuff is fine.~~

As to why it isn't very common: Android conditions users to think of the apps as fully self-contained units. There's no way to have Google Play suggest installing app B as an optional dependency when you install app A, and asking the user to install it during the first launch would go against common user experience wisdoms. The current best practice is to get the user up to speed as fast as possible, with every extra tap they have to make increasing the possibility of them leaving for another app.

But there are definitely apps that do use this. For example OpenTracks, a GPS tracking application, has no integrated map to show captured routes and instead expects the user to find another app that supports its API. Or GadgetBridge, an alternative companion app for many smart watches / fitness bands - it is common for these devices to have some weather forecast widget, but one of GadgetBridge's design goals is to not to have internet access (to help with trust). So it has an API for weather provider apps to make this work.

Edit: First paragraph is toast, I misread the OP

unique(?)

Now introducing: fungible NFTs

It's somewhat hidden if you don't know where to look. You have to switch to Night sight mode, turn on astrophotography in the settings, and then set the phone down on a stable surface. After a few seconds without any movement, the capture button will change from moon to three stars and pressing it will start the 4 minute capture.

The astrophotography mode on Pixels (the only way to get 4 min exposure in the default camera app) works by taking quite a few photos with shorter exposures and then matching them up in post processing.

You even get a short animation at the end where every captured photo gets processed using the rest, so you can see stars moving around during the capture.

I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.

The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.

Mandatory XKCD

Source for alt-text