Zak

The load-bearing word in my original comment is could.

An experienced developer will often have a good intuition about what might deserve attention in the future but isn't worth the effort now.

It's also useful for social reasons. Maybe the CTO wrote the original code and a junior developer working on the optimization thinks they know a better way but isn't sure about questioning the CTO's choice of algorithm. A comment saying it was arbitrary gives them permission.

> wouldn't you include all three with the benchmark tests

Maybe. If I know that the performance of this particular code path is going to be critical to the project's future success, sure. It's more common for something like that to be premature optimization though and the extra code is dead weight. I am not convinced by the idea that LLMs make that kind of dead weight much less undesirable.

> Don't build anything of any significance in dynamic languages!

Posted on a significant website built in a dynamic language.

I tend to disagree. Static typing can catch some bugs, but most serious errors are not type errors, and the common situation where the type system disallows just enough invalid states for developers to get complacent is the worst of both worlds.

Your car's ABS is probably programmed in something more error-prone than Python, like C or the assembly language of whatever microcontroller runs it.

This gets more terrifying if you've ever experienced spurious ABS activation. It's the third scariest thing that's happened to me in a vehicle.

I hadn't thought about Rust that way before, but I think you might be on to something here. Rust and Java both lean heavily into keeping developers from doing anything dangerous with expressiveness and power being pretty far down the list of concerns.

If something could be important and a decision about it was arbitrary, it's valuable to capture that. "There are three viable algorithms here and I don't know which will perform best with our live data so I picked the one that's mathematically beautiful for now" tells whoever is optimizing that system a couple years later that they should try the other two.

Wireless charging, on the other hand generates heat, which is bad for the battery.

Slow, wired charging is the best combination for battery service life. A basic 5-10W power supply when the phone is going to be plugged in overnight is a universal method to achieve that; AccA on a rooted Android device with suitable hardware allows fine-grained control in software.

Even more important is to avoid charging the battery to full. The higher the voltage, the quicker it wears out.

There are standardized sizes for cylindrical Li-ion cells, and that's often what's inside battery packs. The majority of current mirrorless cameras, for example use battery packs that have two 18500 cells inside, but no two brands have compatible batteries. There are only bad reasons for the lack of compatibility.

I'd be happy if everything sized for it took standardized cylindrical Li-ion cells with protection circuits stuck on the ends. That's common for flashlights and rare for everything else.

It breaks the zero one infinity rule by supporting an arbitrarily limited number of themes: exactly two.

https://en.wikipedia.org/wiki/Zero_one_infinity_rule

In software architecture, we talk about essential complexity and incidental complexity.

Essential complexity is inherent to the problem being solved; it can't be eliminated through better tools, process, or design. Incidental complexity is anything added by poor choices or flawed tools. Every line in a "hello world" program that isn't something pretty close to `print("hello world")` is incidental complexity.

To change the battery in electric vehicles that follow typical present-day design patterns, it's essential to have a way to get some clearance under the vehicles like a lift, ramps, or a pit, and it's essential to have a lift or jack to support the weight of the battery. Everything else is basic hand tools.

It is not essential to use any proprietary tools or software that isn't onboard the car or battery. Requiring anything like that is incidental, and a regulation could forbid it in the name of right to repair, reducing waste, or maintaining a healthy used car market.

I suppose it depends on what you want out of a flashlight. It's kind of cool that you can flash the firmware over USB, but the rest of it is middling, and there are quite a few flashlights today running open source firmwares with exposed flashing pads.

Regulated, open source, flashable, USB-charging, and a standardized battery describes most lights from https://www.firefly-outdoor.com/

I moderate /r/flashlight. Something I've seen a substantial increase in over the past few years is people who are surprised to learn that it's possible to have a built-in charger in combination with a field-replaceable battery. It doesn't take much explaining; it just hadn't occurred to them because the devices they're used to don't work that way.

People don't change batteries in their phones now because they'd need a heat gun and a soldering iron and they'd have even chances of starting a fire, breaking the phone, or succeeding in changing the battery without prior experience using those tools. A shop could do it reliably, but the shop will charge 100€ because it's time-consuming and error-prone. A 3-5 year old phone is often not worth 100€.

When a battery change costs 25€ and takes 5 minutes, people will do it all the time even if they don't know that today.

Pegasus tries to get root on your phone. If it succeeds, it could theoretically read message content or decryption keys right out of RAM and Signal doesn't have many options to defend itself.

If it doesn't, it tries to get additional permissions by other means, including asking the user for them. If it gets permission to read notifications and Signal is set to show message content in notifications, then it can exfiltrate your Signal messages. Your messages might be safe otherwise.

> Does Pegasus help governments read messages from Telegram? Signal?

Yes. It attempts privilege escalation and exfiltrates whatever message contents it can from multiple apps. Signal has some potential resistance to that since messages are encrypted in transit and at rest. The easiest weak link would be displaying message content in notifications, which is optional in Signal.

https://en.wikipedia.org/wiki/Pegasus_(spyware)

The OS ought to let you deny internet access to an app entirely, but DNS-based adblocking might solve your problem: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls

Photoshop does that voluntarily; it's not required to by law. GIMP doesn't do it.

This is akin to trying to require all image editors to detect currency and refuse to process images of it. Making open source image processing software would probably have to be illegal because end users could trivially modify it to illegally process currency, or having general-purpose computers that can run software the government hasn't approved would need to be banned.

I don't like this. The Right Thing is for camera apps to not add location metadata by default.

If you go in and turn location on (which should have a warning on it), then you're the sort of person who changes defaults, a more sophisticated user than the majority of the population who is able to take responsibility for the consequences. Yes, I can imagine a scenario where someone ends up with this setting turned on through no fault of their own, but it shouldn't be the role of an OS vendor to prevent every possible mistake.

It looks like you can't revoke the internet permission, but you can use the firewall via ADB. Settings are lost on reboot, but you can use an automation with Tasker or similar to set them on boot:

https://www.reddit.com/r/tasker/comments/1mxjnvs/how_to_bloc...

It's theoretically possible to just keep an app running in the background all the time and periodically poll a server.

That's unreliable though since some OEM Android builds will kill it for that even if the user disables battery optimizations. Those OEMs sort of have a point; if lots of apps did that it would drain the battery fast.

It doesn't. The API for displaying a notification is purely local.

Receiving a ping from Firebase Cloud Messaging triggers the app to whatever it does in order to display its notification. In the case of Signal, that probably means something like fetching the user's latest messages from the server, then deciding what to show in the notification based on the user's settings, metadata, and message content.

Here's example code for using FCM to show a notification. In this case, the notification content also passes through FCM, but Signal does not do that. https://www.geeksforgeeks.org/android/how-to-push-notificati...

This assumes a high level of technical skill and effort on the part of the stalkerware author, and ignores the unlocked bootloader scare screen most devices display.

If someone brought me a device they suspected was compromised and it had an unlocked bootloader and they didn't know what an unlocked bootloader, custom ROM, or root was, I'd assume a high probability the OS is malicious.

A computer that can run arbitrary programs can necessarily run malicious ones. Useful operations are often dangerous, and a completely safe computer isn't very useful.

Some sandboxing and a little friction to reduce mistakes is usually wise, but a general-purpose computer that can't be broken through sufficiently determined misuse by its owner is broken as designed.

Open source helps, but if you didn't build it yourself, you'll need to trust whoever did. F-Droid reproducible builds help in that you only need to trust either F-Droid or the developer, not both.

The browser tends to be safer because it has a stronger sandbox than native apps on a mobile OS. It's meant to be able to run potentially malicious code with a very limited blast radius.

That, but with a little more ceremony. It gets treated as a separate app by mobile OS app switchers and doesn't show the browser's chrome or other open tabs.

https://en.wikipedia.org/wiki/Progressive_web_app

I imagine usage patterns vary greatly. For me, most of the time, I have it set to only allow messages from contacts, and I usually handle those immediately.

Android modes provide control over notification display.

Modes control which people and apps can trigger a sound/vibration, but also offer the option to hide the silenced notifications from the status bar, pull-down shade, and dots on app icons. I hide them from the status bar, but not the pull-down shade so that I can manually check if I want to, but don't see them at a glance.

I'm not a heavy user of this feature though; I mostly don't install apps that have spammy notifications.

Pointers are famously difficult to learn and reason about even though the basic principles are simple. Programming in a style that requires direct manipulation of pointers when it's not actually necessary is usually regarded as unwise because it's so hard to get right.

Phones are perfectly capable of accessing websites. I think a lot of the shift here has to do with companies aggressively pushing apps because apps are more profitable, which in turn trains users to expect apps.

I leaned on Claude Code quite a bit resurrecting Clojure on Android[0] and got good results with it. Using the Clojure REPL MCP works especially well for about the same reasons I find developing with a REPL myself important: it can query the running program to see how things work, and test implementations with rapid turnaround.

I wasn't sure if I should expect great results relative to more popular languages with more code for the LLM to train on, but it looks like that's either not a big issue, or Clojure is over the popularity threshold for good results. I also previously expected languages with a lot of static guarantees like Rust to lead to consistently better results with LLM coding agents than languages like Clojure which have few, but that's untrue to the point that "bad AI rewrite in Rust" is a meme.

[0] https://github.com/clj-android

This comment assumes both that Reddit is harmful and the outcomes were predictable. The former is debatable, but I am sure the latter is not true; the founders of Reddit didn't know what they were building.

They thought it was a social bookmarking thing for people to find and share blog posts. It didn't even have comments for the first half year. For two more years, self-posts only existed as a hack where the poster had to predict the post's ID to make it link to itself. User-created subreddits didn't show up until about 2.5 years after the site launched.