During an investigation today I ran across a quite long piece of base64 data which only used the 62 alphanumerics, and not + or /. "That's a weird coincidence," I thought, "what are the odds of that? Surely you'd expect a + or / by chance sooner or later."

Turns out: not very unlikely at all. + and / translate to binary 111110 and 111111. In base64 those sequences have to occur at an even bit shift. If the encoded data is ASCII text then the top bit of every byte is 0, so neither sequence can occur at any shift that puts part of it in the top two bits. The only possibility is that it appears in the bottom 6 bits of a byte, so you get a byte value of the form 0?11111?. There are four of those, and one of them is 0x7f, which isn't printable.

So the answer is: any printable ASCII document which avoids the three characters >?~ will encode to purely alphanumeric base64. And that's not very hard at all – plenty of syntaxes don't happen to use those. The encoded data in this case turned out to be JSON, in which all the strings were either alphanumeric identifiers or other pieces of base64.

My intuition "surely you expect a + or / by chance" was based on mentally modelling base64 as some kind of random transformation. Not a good model, as it turned out!

Os chineses, que levam a sério o seu programa espacial, lançaram no ano passado o Atlas Geológico do Globo Lunar, o mapeamento de mais alta resolução já publicado sobre a Lua, fazendo uso das imagens coletadas pelas missões da própria China e atualizando os mapas anteriores, da época do Projeto Apollo.

O Atlas detalha mais de 12.000 crateras, além de outras informações geológicas, topográficas e tectônicas da superfície lunar, em escala 1:2.500.000.

Mais: https://english.cas.cn/newsroom/cas_media/202404/t20240422_660730.shtml

#Newsletter

I want to defend Wayland here and explain a crucial piece that I think people are missing...

The splitting of protocols in Wayland and compositor reimplementation were to allow for new form factors. It had to sacrifice the guarantee of all desktop app functionality being present to achieve that.

The idea (as I see it) was never to have 500 desktop compositors all trying to reimplement the same thing with slight differences. Iinstead, it was for 500 different interfaces for different platforms that are compatible with the same apps (e.g. desktop, laptop, phone, car screens, AR/VR, watch). Different form factors have totally different ways of dealing with interface, but share enough common features where it makes sense to have 1 base protocol and many other ones for device/form specific features.

Problem is, while in 2008-2016 we had a ton of new experimental UIs coming out on a semi-regular basis (that was the peak of the whole convergent phone/tablet craze, smartwatches started, fancy car UI, touch tables, early AR/VR) things have quieted down. The purpose of Wayland's insane modularity hasn't been visible to most people given it's almost always complained about in a desktop contest vs X11. But X11 was literally only designed for a desktop form factor and has been refined for that 1 purpose for decades!

As an example of different form factors, Wayland lets IVI (in-vehicle infotainment) systems work way better than Xorg could have. Desktop window layouting on that platform would inherently produce massive amounts of unnecessary complexity, and the ability to direct scanout saves on power/expensive compute. Automotive Grade Linux and COVESA maintain reference interfaces for cars so companies can iterate a ton faster. Wayland gives the app compatibility and they can make the system UI work with more flexibility and ease than an X11 window manager.

Take Linux Mobile too, the compositor can reliably enforce window layout and boundaries and composition. While this could technically be done with an X window manager and compositor, doing it with Wayland guarantees reliability as the app simply doesn't have a choice or room for error. Some things like drag and drop of toolbars doesn't make much sense on mobile given how small the screens are.

There's some interfaces where X11 is basically impossible to use. In AR/VR (where i am making a Wayland compositor) the concept of a screen simply does not exist. How is an app supposed to position itself when the very concept of 3D is not part of the protocol? In Wayland I don't have to implement the protocols that don''t work (e.g. layer shell) and therefore any apps that don't need it will be compatible..

Wayland has allowed for insane levels of flexibility, things that no other display server architecture can do reasonably. Total flexibility between app and screen, direct scanout without hacks, AR/VR support, etc.

Here's some fun and useful stuff that's been done with Wayland, stuff that X11 could never reasonably do:

Now, could Wayland devs maybe have distributed features across protocols better? Worked with app toolkit devs to ensure the protocols they made actually fit what the apps and compositors needed? Stopped bikeshedding (though imo many cases of "bikeshedding" are simply accounting for other form factors)? Absolutely!

My point here is simple: there was a reason for making it this modular, for not having a standard implementation. It wasn't just devs trying to impose some ideology, it wasn't some corporate takeover. It's good reasons that people using X11 on their desktop/laptop don't encounter. If we made something that wasn't universal, most apps wouldn't be compatible with it and therefore everything but the desktop form factor would lack apps.

Saving an image to a bird

https://www.tomshardware.com/pc-components/storage/yes-you-can-store-data-on-a-bird-enthusiast-converts-png-to-bird-shaped-waveform-teaches-young-starling-to-recall-file-at-up-to-2mb-s

They converted an image to a waveform, played it to a young starling who imitated it well enough that it could be recorded and the waveform converted back to an image.

The linked video is full of info about bioacoustic monitoring too