Same. I buy Motorola phones because they have 3.5mm headphone jacks, real SIM cards, and microSD cards.

I agree that the article is a bit unfocused about the supporting material. But the primary topic is clear: it's about the memory consumption of the Go map implementation.

This is an article written by a real human person, who's going to meander a bit. I prefer that over an LLM article which is 100% focused, 100% confident, and 100% wrong. Let's give the human person a little bit of slack.

Off topic: Something on that web page causes Firefox on my MBA2020 to use 133% of CPU, 30% of GPU Helper, the fan goes to full speed, and scrolling is slow and janky. I can barely read the article.

When I go to Reader mode, the CPU goes down to less than 20%, scrolling works great, and the fan goes off.

Did they implement scrolling using JavaScript?

I'm not familiar with the Gnome terminologies. Is Overview the one where they removed all the desktop icons, breaking 40 years of GUI conventions going back to the 1970s? (It's impossible to do a search on a product called "Overview".) I blew away Gnome after that, installed Mint MATE (now Cinnamon), and vowed to never touch Gnome again.

Overview is when you press the Super ('Windows') key.

What appears is an unholy amalgamation of a launcher, a workspace strip, a window overview, workspace peeking, and a dock.

Worse yet is that every time you go in or out of this overview, an animation plays, making things fly and animate everywhere constantly, whenever you want to take any action.

Whenever someone points out to Gnome developers that most people only want to open a launcher to type "52*93" or find a contact, that they just want to mouse over a dock to have a lightweight way to see if an application is open (and to switch to it), they get irate and tell you their vision is vastly superior.

Gnome could be pretty great if the developers their attitude to their users wants and the feedback on their issue tracker wasn't extreme snark and "actually we are right". Even if clear UI defects are pointed out, no, in fact they are right.

The Gnome peoples also frustrate any attempt at improving Wayland at a more rapid clip.

There is a reason why Valve went with KDE. KDE has its own set of problems, but at least they are receptive, cooperative and friendly. I genuinely hope Valve puts enough money into KDE that Gnome with its high and mighty attitude gets completely railroaded.

Sounds awful. Luckily we still have other options. I hope I never have to use GNOME again.

We put a beautiful wallpaper on the Desktop. Ahhhh.

Along comes a Luddite and puts icons on it, totally ruining its beauty. For fsck's sake! Just No.

Thankfully, along comes GNOME and it just says No.

I agree.

Shell sort is sooo much faster than Bubble sort for tiny microcontrollers, for only a little bit more flash memory, like 40-100 bytes. If that's too much, then Insertion sort is 6X faster than Bubble sort, for only 10-20 bytes of extra flash.

I read this all the time from other people, but for me, Selection sort is the easiest to remember and implement. My next easiest would be Insertion sort.

Bubble sort doesn't click for me easily. I think it's because the terminating condition seems uglier than Selection sort or Insertion sort. I always have a little voice in the back of my mind, "Is this outer loop guaranteed to terminate?"

Terminating condition in Bubble sort is "did we swap any values during this loop"? Yes -> continue, No -> list is already sorted, exit the loop.

I don't believe that insertion/selection sort is easier to grasp. Can you type it from memory, without looking it up? Here's bubble sort:

    var swapped = true
    while swapped:
      swapped = false
      for i in 0 .. list.len-2:
        if list[i] > list[i+1]:
          swap(list[i], list[i+1])
          swapped = true

Different strokes for different folks I guess.

Selection sort was the first sorting algorithm that I ever created: Find the smallest element for slot #1. Find the next smallest for slot #2. And so on. I've recreated it from scratch many times. The double for-loop means that it is guaranteed to finish, and it is obviously O(N^2).

I did not learn about Bubble sort until my university class, where I thought, this is a terrible algorithm: It's not completely obvious that it will finish, and it's not obvious what the runtime complexity is. For example, if the inner loop used ">=" instead of ">", it would work for test data sets with unique elements, then hang forever with a real data set that contained duplicates.

> Can you type it from memory, without looking it up?

Well, yeah, but that’s not a very useful heuristic for people who are already aware of the algorithms in question. If you ask people to come up with a way from scratch – probably without explicitly asking, in order to get better success, like by watching how they sort cards – I bet they won’t tend to come up with bubble sort. Maybe that says something about the relative intuitiveness of the approaches? Or not.

I recall "inventing" bubble sort during one of my first CS classes when the question was posed of how to sort a list. So, not that outlandish.

Agree. I remember the names of many of these algorithms, but not the logic.

Let's see.

  for i in 1 .. list.len - 1:
    j = i - 1
    while j >= 0 and list[j] > list[j + 1]:
      swap(list[j], list[j + 1])
      j = j - 1

On 8-bit and 32-bit microcontrollers (e.g. 8-bit AVR, 32-bit ESP8266/ESP32), Insertion sort is 6X faster than Bubble Sort on random data. I have tested this up to about N=1000.

Both Insertion sort and Bubble sort are O(N^2). Both are stable sorts. Insertion sort consumes only about 10-20 bytes more flash memory than Bubble sort. It's hard to think of situations where Bubble sort would be preferred over Insertion sort.

Shell sort is vastly superior if you can afford an extra 40-100 bytes of flash memory. (It's not too much more complicated than Insertion sort, but sometimes, we don't have 100 extra bytes.) It is O(N^k), where k ≈ 1.3 to 1.5. As soon as N ⪆ 30, Shell sort will start clobbering Insertion sort. For N ≈ 1000, Shell sort is 10X faster than Insertion sort, which in turn is 6X faster than Bubble sort. Unfortunately Shell sort is not stable.

Comb sort has a similar O(N^k) runtime complexity as Shell sort. But it seems slower than Shell sort by a constant factor. Comb sort is also not stable. I cannot think of any reason to use Comb sort over Shell sort.

Quick sort is not much faster than Shell until about N ≈ 300. Above that, the O(N*log(N) of Quick sort wins over the O(N^k) of Shell sort. But Quick sort is not stable.

Merge sort is stable and runs in O(N*log(N)), but it consumes an extra O(N) of RAM, which may be impossible on a microcontroller. You may be forced back to Insertion sort for a stable sort.

There is stable in-place merge sort, it runs in O(n*log(n)^2). It is about 3 times more complex than shell sort. I implemented it here https://github.com/thomasmueller/bau-lang/blob/main/src/test... (most sort algos you mentioned above are in the same direcory btw)

You didn't mention heap sort. A simple implementation, which doesn't do any method calls just like shell sort (also next to the merge sort above) is about twice as complex than shell sort.

Thanks for the reference to in-place merge sort. GitHub is having a lot problems right now, I cannot see your code. I will look at it when I get a chance.

I think I ignored Heap sort because it uses O(N) extra RAM, which is precious on a resource-constrained microcontroller.

Heap sort is in-place (and does not even need recursion, unlike quicksort). But yes, it is not stable, and usually slower than even shell sort (except for very large arrays).

I don't follow the Syncthing ecosystem, so it's difficult to understand what is happening.

[Edit: The GitHub repos are called "syncthing-android". The Android apps are called "Syncthing-Fork" or "Syncthing-Fork Wrapper", which adds to the confusion.]

If I recall, there used to be a syncthing-android app on Google PlayStore. That was discontinued by @imsodin in Oct 2024 (https://forum.syncthing.net/t/discontinuing-syncthing-androi...).

There was a version of sycnthing-android on F-Droid. I don't remember who maintained that. I have version 1.30.0.4 installed. But I cannot find any information about that version anymore.

The current version on F-Droid is 2.0.12.1. That seems to be maintained by a fellow named @researchxxl. Apparently @researchxxl claims to have inherited the source code and signing keys from a person named @Catfriend1 (Not sure who that is, the maintainer of version 1.30.0.4?)

There is another fellow named @nel0x who seems to be maintaining a different version of synchthing-android? (Edit: Here it is, https://github.com/nel0x/syncthing-android, which says that it is a fork of the one maintained by @Catfriend1).

[Passed my edit window, so replying to self]

Looks like the original repo of syncthing-android, (https://github.com/Catfriend1/syncthing-android), which was maintained by @Catfriend1, now redirects to the one maintained by @researchxxl (https://github.com/researchxxl/syncthing-android).

The problem seems to be that no one in the syncthing community knows who @researchxxl is. The account was created only 3 weeks ago. There was no communication about how the transfer took place. Was the transfer actually authorized? Did @Catfriend1 get hacked? People are worried about a backdoor hijack attack similar to the XZ libary.

There's a long discussion at https://forum.syncthing.net/t/does-anyone-know-why-syncthing.... It is too long and complex for me to follow. (I tried to get an LLM to summarize that thread for me, but the output was not helpful.)

It is unclear what sycnthing-android users are supposed to do right now. I am staying at version 1.30.0.4 until things become more clear.

> People are worried about a backdoor hijack attack similar to the XZ libary.

This is a particular concern because the syncthing-fork is coded to require full storage access, iirc for compatibility with certain phones. Idr, went through with Claude and iterrated through a diff of everything that between Catfriend1's changes and the original repo. The broad access really isn't necessary on most phones as I refactored the flag, compiled the app and installed it with no problems. I ultimately decided to go with the official build to make updates easy, now hmmm. Troubling when the trust gets so dilluted.

This is how I've observed it: Catfriend1 has long been the owner of syncthing-fork on android, which was fork of the official client syncthing-android. It had extra features around Android that were lacking in the official client (e.g sync windows to reduce battery usage).

When google locked down on file apis a year or so ago, the official syncthing-android pulled out of google play, but syncthing-fork stuck around in fdroid as the fork was for personal purposes, and they were using fdroid for distribution in the first place.

This change in ownership is new to me, but I'm also not surprised it happened as syncthing-fork was always a personal project.

> I have version 1.30.0.4 installed.

Can confirm same case here. App was installed from f-droid, no longer linked to the store.

Could also be French speakers. They would say "J'utilise le format .avif depuis quelques années." I think the "depuis" throws off the French speakers when they translate that literally as "since some years" instead of "for some years".

Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".

I tried eBay like 4 times. But they were all fake or defective. At least one of them was dead on arrival.

I finally bought one from iFixit.com. Far more expensive than eBay, but the battery actually worked great for about a year. Then about a month after the 1-year warranty expired, it degraded noticeably (maybe to 80%) with only about 100-200 charge cycles. Even iFixIt cannot source a battery as good as the original Apple.

Right now, it's at 65% capacity after 584 charge cycles, after 4.5 years of service. I will probably go back to iFixIt. At least I'll get one year of full capacity from them, instead of the fake or DOA ones from eBay.