karteum

> Usually, what you want is either the byte or the grapheme cluster.

Exactly ! That's what I understood after reading this great post https://tonsky.me/blog/unicode/

"Even in the widest encoding, UTF-32, [some grapheme] will still take three 4-byte units to encode. And it still needs to be treated as a single character. If the analogy helps, we can think of the Unicode itself (without any encodings) as being variable-length."

I tend to think it's the biggest design decision in Unicode (but maybe I just don't fully see the need and use-cases beyond emojis. Of course I read the section saying it's used in actual languages, but the few examples described could have been made with a dedicated 32 bits codepoint...)

UCB-C headphones use the same USB-C connector as the charging one (there are no smartphone with 2 usb-C connectors), therefore increasing the wear every time you plug/unplug. When using USB headphones you cannot charge at the same time, and when using USB-to-{usb+jack} the behavior is sometimes strange (e.g. does not detect and switch to internal audio when unplugging the jack). Besides, in many situations (especially when walking/moving), a USB-C connector tends to unplug itself so easily while a jack connector will just stay in place. Nothing really replaces an internal jack port ! (+ in some cases, the jack connector would also provide a debug UART :).

In comparison, Moto G84 has LineageOS/Calyx support, headphone jack, 2 SIM (or 1 SIM + SD-card), 12G RAM, and 7/10 repairability score in France (although I lack the details - I hope at least it's relatively easy to replace the battery and USB-C slot) + it weight 160g => even though I'd like to support Fairphone, I won't buy again a phone without jack port !

I totally agree with previous comments which highlight that we used to have removable jack + batteries + SD + root easily 10 years ago (and we also had more options for tiny phones, such as Galaxy S4 Mini).

I also love Typst and use it regularly. But just to note it : there is also https://weasyprint.org that takes HTML as input

FWIW, I used gmvault a long time ago (N.B. I typically deactivated individual .eml.gz compression in favor of a more global compression with a squashfs archive of the gmvault backup). Since I found not very practical to search through that archive, I developed https://github.com/karteum/gmvaultdb in order to convert it to a local sqlite DB (I made it for personal use and chose to keep the schema simple to have simple queries for my case. If the DB was to grow bigger I'd probably use a different schema e.g. to place the contacts/from/to/cc in separate tables... I also chose to extract attachments directly on the filesystem rather than put them in the DB - which enable direct access and deduplication)

(N.B. it can also process the mbox produced by https://takeout.google.com/ with the caveat that in some case Takeout permanently losses some information because of a bug with older encodings so I'd always prefer a backup using gmvault or imap)

It's 12 years old now, but I am still extremely impressed by this 64k intro https://geidav.wordpress.com/2013/04/14/making-of-turtles-al... and also by this 4k intro https://www.youtube.com/watch?v=_YWMGuh15nE :)

And overall this website is extremely interesting with tutorials and code and great explanations https://iquilezles.org/

Google Pixels are the few devices that enable not only to unlock the bootloader but also the ability to flash your own keys and still have secure boot together with full kernel sources availability (which is why Grapheneos only support them as far as I know).

As far as I know Mediatek (and vendors that use those chips) are usually not good with regards to GPL Compliance, which means no Lineageos if kernel sources are not available...

I discovered JSON Binpack recently, which works either schemaless (like msgpack) or - supposedly more efficiently - with a schema. I haven't tried the codebase yet but it looks interesting.

https://jsonbinpack.sourcemeta.com/

Beware when relying on Google Takeout for e-mail backup if you have old e-mails in other encodings than utf-8 : it permanently breaks some characters, which are replaced by 0xEFBFBD (that issue does not occur when doing backup with IMAP or GMVault)

> Also, given that this is the author's work laptop, what's the economic justification for not investing in the primary tool you use for work?

The author explains that there are motivations not related to money (we live on a finite earth, the manufacturing of a laptop encompass a considerable amount of energy and raw materials for mining, etc).

Python may not be the best example, but some other languages also exist and are both less "weird" than https://github.com/denysdovhan/wtfjs and fast (e.g. see http://luajit.org/ which is far less complex than V8).

If you want vertical tabs, built-in adblocker, and more generally are looking for a lightweight and free (as in free speech and as in free beer) browser, you may look at https://www.falkon.org/ (made with QTwebengine i.e. Blink)

I was also thinking about extracting the MPQ on-disk e.g. "foo.mpq" -> ".foo.mpq.extracted/..." (which - to my understanding - would lead to a lot of deduplication even just with jdupes). N.B. depending on the requirements with regards to read performance, you could design a FUSE filesystem that would transparently reconstruct the MPQ on-the-fly.

Of course, I guess all of this would be much slower than being able to use inherent btrfs features as the author of the post wishes, but at least it would be independent from btrfs :)

> But for a curious hacker getting at the internals of how something works, the first instinct is to turn it up. That's their learning path. It's natural curiosity. More must be better. Louder must be better.

If you increase the TXpower way beyond the P1dB of your PA, you will introduce distorsion and therefore harmonics beyond your operating band (i.e. you can end up disturbing RF services other than wi-fi, possibly safety-critical services). https://www.everythingrf.com/community/what-is-p1db

=> Don't do that !

> the only real limit is until you start interfering with other people to the point they notice and complain. it's not like the FCC has vans roving the streets looking for unlicensed TV usage like the BBC but for wifi

In the area of radio, you must be extremely careful with this mindset. Keep in mind that interference may affect important / safety-critical infrastructure (and you may not even realize). For example, I am frequency facing issues from wifi (with deactivated or nonfunctional DFS) towards a weather radar in the same band (which indeed is the primary user, and weather forecasts are critical to aeronautical and maritime safety ! This is a nightmare to troubleshoot).

If you want to tinker with radio, I would suggest to pass your HAM radio license (which will give you the minimum background with regards to radio, propagation, regulations, etc.).

Because an increasing number of people do not care anymore about any regulations, I see many administrations worldwide are increasingly pushing for locked firmwares and bootloaders (i.e. no more openwrt), more import control, etc. If you want to still be able to tinker with hardware and radio in the future, you should always ensure peaceful coexistence with others i.e. know what you are doing and work within the boundaries of regulations (be it txpower, duty-cycle, listen-before-talk, etc. Those limits are there for a good reason !).

I am happily experimenting with Typst right now (https://typst.app/ ), which compiles much faster than LaTeX and with a syntax very similar to md, together with nice support for math, figures and advanced settings.

> Amiga was a lot like DOS/Classic Mac OS, single user, unprotected memory

AmigaOS was actually implementing real preemptive multitasking and was much more "modern" than MacOS and Windows from the same era, and a lot of things were actually unix-alike ! Comparing it to DOS is like an insult :) But yes, memory was unprotected because mot Amiga CPUs didn't have an MMU (but if you did, you could use this https://www.nightvzn.net/portfolio/web/amiga_monitor/archive... ).

There are aspects I didn't fully understand, maybe someone can explain : on one hand I understand that Object arrays were very slow and raised issues, that PyArrow strings solved the issue (how ?) at the expense of a huge dependency, and that the approach here also solves the issue in a lighter way, but it seems to be somewhat the same way as Object arrays : "So, the actual array buffer doesn’t contain any string data—it contains pointers to the actual string data. This is similar to how object arrays work, except instead of pointers to Python objects, they’re pointers to strings" => OK so... if they are stored in a similar way, how is that more performant or better than regular Object arrays ?

There are aspects I didn't fully understand, maybe someone can explain : on one hand I understand that Object arrays were very slow and raised issues, that PyArrow strings solved the issue (how ?) at the expense of a huge dependency, and that the approach here also solves the issue in a lighter way, but it seems to be somewhat the same way as Object arrays : "So, the actual array buffer doesn’t contain any string data—it contains pointers to the actual string data. This is similar to how object arrays work, except instead of pointers to Python objects, they’re pointers to strings" => OK so... if they are stored in a similar way, how is that more performant or better than regular Object arrays ?

If you only care about music (not videos) then you might also have a look at https://webamp.org/ You don't even need to "compile" or do anything fancy to "integrate" it : just include it (of course you might generate the playlist in your app) ! e.g.

    <!DOCTYPE html>
    <html><head><meta charset="UTF-8"><title>Music</title></head>
    <body>
    <div id="app"></div>
    <script src="https://unpkg.com/webamp"></script>
    <script>
    const webamp = new Webamp();
    webamp.setTracksToPlay([ 
        {url: "http://example.com/The%20Gathering%20-%20Travel.mp3", defaultName: "The Gathering - Travel", duration: 1.0, metaData: {title: "The Gathering - Travel", artist: " "}, },
        {url: "http://example.com/Muse%20-%20Plug%20In%20Baby.mp3", defaultName: "Muse - Plug In Baby", duration: 1.0, metaData: {title: "Muse - Plug In Baby", artist: " "}, }, ]);
    webamp.renderWhenReady(document.getElementById("app"));
    </script>
    </body></html>

Reminds me of Razer project Linda (https://www.youtube.com/watch?v=5gKu-T13vXs )

See also https://github.com/vnmakarov/mir

I guess it's without the pictures then ? Because if I compare with the zim file format (which is optimized for this use-case) https://kiwix.org/en/what-is-the-size-of-wikipedia/ I read "As of October 2022, the Full English Wikipedia (ca. 6.5 million articles), with images will use up 91GB of storage space (German and French, the second-largest: 36 GB). (...) If you can do without the images (what we call the nopic version), then you are down to 46 GB."

Thanks ! One question though : why do you say "as it's pretty obvious that the domains in which EROFS and DwarFS are being used have extremely little overlap. DwarFS will likely never be able to run on embedded devices" ? (I mean : as far as I know EroFS was mostly used in smartphones, which are actually powerful devices !)

I would love to see a comparison with EroFS (https://en.m.wikipedia.org/wiki/EROFS )

Last time I tried to install Rocky/Alma Linux on my mum's laptop (Core 2 Duo T5600) it miserably failed because the OS required x86_64_v2 (I didn't even know this existed: I thought all x86_84 linux OS would boot on that machine...). It's a pity since the long-term support of that distro would make it a perfect match for that use-case where I want the computer to "just work" without any bleeding-edge stuff... Anyway, it's just to say that it's not only Microsoft who is dropping support for older machines !

Some people might be interested in https://weasyprint.org/

> The only block of countries reducing it are the EU (making our life miserable), the USA at most is maintaining it, and China, India, all of Africa and mostly all others, are pumping out more and more of it

US is a large country with considerable amounts of coal (and oil to a lesser extent). China also owns a considerable amount of coal on their territory. Several African countries are significant oil producers. (overall even if it's oversimplifying: it makes sense that large countries with low density of population have larger amounts of natural resources per capita...)

Since EU imports > 95% of the fossil fuels it uses and since the volume of oil extracted from earth will soon peak and then decline (in a context where the countries who extract it will keep more and more for themselves, therefore even less to be available on the market), it is indeed wise that EU learns to organise with less fossil fuels (independently from any climate/environmental concerns, which are another good reason). If EU doesn't then it will anyway have to face such a decline, without being properly organised...

fdupes is really nice and fast, but (as far as I remember) it was lacking two features that I needed for my use case, which were 1°/ list duplicate dirs (without listing all of the duplicate sub-contents), and 2°/ being able to identify that all the contents in one dir would be included in another part of the FS (regardless of files/dir structures), which is particularly useful when you have a bigmess/ directory that you progressively sort-out in a clean/ directory. Said differently : fdupes helps to regain space but was not able to help me much to reorganize a messy drive...

This is why I wrote https://github.com/karteum/kindfs (which indexes the fs into an sqlite DB and then enables various ways to process it).

"for windows" only ? then it's a no-go for me...

therefore for consistency I assume you expect the same behavior for "taiwan" ?