rnd

rnd , 3 months ago

Cinny is the closest to Discord in terms of UI, it even has a feature where you can show subspaces within a space as if they're categories of a Discord server.

rnd , 3 months ago

What you're describing sounds like an issue with either A-GPS (a mechanism by which sat navs can receive initial data over a cellphone connection, without which the initial location search can last up to 10 minutes, but afterwards it will be as smooth as always) or approximate location (a mechanism in which Google uses a huge database of cell tower and Wi-Fi data to quickly get your approximate position).

I would suggest checking the permissions on the OSMAnd app -- maybe it's lacking something that Google Maps has?

rnd , 4 months ago

For comparison, I wonder how vulnerable Flathub (flatpak's primary repo) is to these kinds of manipulations... Seems like every app manifest there is publicly available and is compiled on their servers, presumably making it easier to spot shady apps and updates, and the submission process requires manual approval.

rnd , 4 months ago

Okay, the responses here are kinda disappointing because folks here seem to be unaware that (1) Mozilla has already added "AI" info Firefox a few versions ago (to provide machine translations of pages), and (2) the way they did it is very responsible (the whole thing is 100% local, no info is sent to other servers).

I understand that we're all tired of this whole trend of language models being put where they don't belong, but from what I see, Mozilla is actually the company I'd trust the most to do it right. (AFAIK, one area where the FOSS world is severely lacking and where Mozilla works to solve it is speech recognition with the Common Voice project, and if they start working on an LLM-based program to do that, I'd welcome it.)

rnd , 4 months ago

Sounds cool, though I'm a bit confused as to why that is such a big priority given that ReactOS currently aims to replicate Windows NT 5.2 (XP x64 / Server 2003), which did not provide graphical set-up*...

* Technically all Windows versions up until, IIRC, Vista had their install process in two stages: a text-based stage where you'd input the most basic info (what filesystem to install onto, what Windows directory to use, etc.) and a graphical stage once the basic files are installed (where you'd be asked what devices the computer has, whether it's networked, date/time, etc.). From Vista to the present day, the first stage is graphical as well. ReactOS' latest release uses the pre-Vista model, but the latest blog posts indicate a move to the more modern one.

rnd , 5 months ago

So, hexadecimal uses 16 characters. Each character stores 4 bits of data (2⁴ = 16).

If you use the 10 digits and 26 letters of the Latin alphabet, the resulting encoding is called Base36.

It is a rather impractical format for storing data, though, because for purposes of simple conversion, the number of possibilities should be a power of 2 -- that way a program can do (quick) bit shifts instead of (difficult, especially on big numbers) division to determine which character to use. That's why it's mostly used to encode numbers, and not large sequences of data.

Base32 is a slightly-smaller variant that can fit 5 bits of data into one character. (2⁵ = 32)

If you add up digits, uppercase and lowercase characters together (differentiating between upper and lower case), you get 62. This is also an impractical number for computer purposes. But add two extra characters and you get 64, which is another nice power of two (2⁶ = 64), letting one character store 6 bits. And Base64 is a common encoding scheme for data.

---

And when you know how many bits a character can fit, you can calculate how "efficient" the encoding will be and how many characters will be needed to store data. A Base32 encoding will need 20% fewer characters than hexadecimal, and Base64 needs 33.3% fewer.

rnd , 5 months ago

If you're using Linux (or macOS or MinGW or CygWin or MSYS), you can do something like this in the terminal:

xxd -r -ps | base64

The first command will read the standard input and decode hex strings back into raw data, and the second one will do base64 to the output.

If I pass the hex string mentioned in your original post through this command, I get:

Z3nFNDK4ut8Em7nYkkpXhd2IckM=