dbrgn

See my reply to the sibling comment: https://news.ycombinator.com/item?id=30665186 I don't know about the current Samsung situation, but there were multiple phones by multiple vendors where whitelisting apps wasn't possible at all, or where it simply didn't work properly.

As DontKillMyApp notes, "the latest feedback suggests even when you remove an app from the restricted list, Samsung may re-add them later after a firmware update or when it thinks it is using too much resources". That is horrible.

This is also about developer frustration, but not only. Over the years, I've used various alarm clock apps. There were some Huawei phones where it was literally impossible to get those alarm clock apps to work, because even if you added it to all whitelists, it would still kill the app in the background. Another issue is if you're using a messenger with VoIP functionality that you don't use every day. When an incoming call is received after not using the app for a while, it simply wouldn't ring.

Stock Android already contains energy saving mechanisms that work reasonably well. By piling potentially broken additional battery saving mechanisms on top of that, you risk breaking the phone for certain use cases. At the very least, as a user of that phone, there should be an easy way to exclude certain apps from energy saving measures. (Let's pick out Huawei again, where even if you added an app to such exclusion lists, after a few days the OS would randomly remove the app from that exclusion list again. Plus, there was some kind of "lock" that you could activate in the app switcher, but that lock wouldn't survive a reboot.)

Because some of the energy saving measures are so extreme, some manufacturers put popular apps on internal exclusion lists. These apps work fine, but apps by smaller developers don't. This is a major source of market distortion.

Huawei used to be the worst offender in this space, but it has gotten a little bit better by now. Nokia also had a phase where they had a horribly broken energy saver, but thankfully they got rid of that. Samsung has gotten worse and worse over the last years.

I rent, but the homeowner doesn't care. We're three parties in the house, one neighbour doesn't care either, and the other neighbour's wife is sad if we cut the flowers :)

I don't have any clover here, but lots of flowers. We usually wait with the first cut in spring until the flowers are mostly gone. They displace grass unfortunately, but look very nice, and insects love them. https://i.imgur.com/sbqhEYt.jpeg

I prefer not to upload all my potentially private documents into a cloud service :)

OCRmyPDF (https://ocrmypdf.readthedocs.io/) actually does a pretty good job! It also handles deskewing and all other stuff that's necessary for good OCR results.

I can relate to the document scanning issue. In my case, I digitize all documents I get on paper. For this, I've written this wrapper around scanimage and ocrmypdf: https://github.com/dbrgn/pydigitize

It does the following steps:

1. Scan a document with any scanner that supports SANE (ADF supported), 2. straightening and cleaning of scanned documents, 3. run OCR on PDF so that it becomes searchable, 4. generate PDF/A file for archival, 5. add keywords to the PDF file

I've probably saved many hours with this script, even when taking into account the time it took me to write it.

Tiny projects don't always save time, but they sure are gratifying when they work as intended!

I think the main reason for the sudden uptick in Pipewire usage is that due to the pandemic a lot more people were doing daily video meetings with screen sharing. And for all people that have migrated to Wayland, this was a major source of pain.

With pipewire, this works quite nicely, including for applications that are sandboxed (e.g. Jitsi in a Flatpak). In my bubble, when people talked about using Pipewire, it was almost exclusively related to screensharing on Wayland.

I've switched from Pulseaudio to Pulseaudio-on-Pipewire last year and haven't looked back. Next step would be trying to set an audio processing pipeline with audio effects (like a multiband equalizer tuned to my headphones), something that I managed to set up with Jack before using Pipewire, but that was always a pain.

From a very quick glance, it seems that Interslavic is to Slovio what Interlingua is to Esperanto.

Esperanto is a language that's simple and easy to learn (at least if you're familiar with romance languages), but not necessarily easy to understand if you're not familiar with it.

On the other hand, if you're familiar with 2 or 3 romance languages, try to read https://ia.wikipedia.org/wiki/Interlingua. Even if you've never heard of Interlingua, you'll probably understand most of it. Interlingua is optimized for easy understanding, which means that it adopts common words from romance languages even if they're not totally consistent with the rest of the language. This means that ease of understanding comes at the cost of language consistency and ease of learning. For people in central Europe, I'd say Esperanto is easier to learn (to speak) and Interlingua is easier to understand.

Once that goal is reached, I'd be happy to try it!

As far as I understand it, Taler is not made for person-to-person payments, but for person-to-service-provider payments. The idea of taxability is that the person sending the money (the customer) is anonymous, while the recipient of the money (the webshop, for example) is not anonymous. This allows taxing the companies, while giving more privacy to the customers than with the current system.

While this is a very different idea than decentralized cryptocurrencies, what it would give us as consumers is a much more privacy-preserving alternative to credit cards, Apple Pay and PayPal when buying things online (or in a store). At the same time, it is controllable enough for governments and banks that they could consider introducing such a system.

Could Taler be used in a smaller scope already? For example, could it be used as an "account system" inside an association (like a hackerspace), where members can charge their accounts with Talers and then use these to pay drinks from the fridge, etc?

Setups like this could be used to test the system in practice.

Don't buy phones from Samsung. They're the worst. They've been #1 on https://dontkillmyapp.com/ for a while now.

I have a Pixel 3a and it has been working flawlessly. Best phone I've owned so far.

I've heard a lot of complains from Pixel 4a and 6 owners though, about bugs in the OS and drivers... Not sure if these issues are widespread or not.

This will probably break many other use cases as well (e.g. services that allow pasting formatted text and will convert it to unformatted text, or pages like GitHub where you can paste an image into the edit area).

Enforcing requires court cases and time. That's how law works, unfortunately.

Fortunately organizations like NOYB (with Max Schrems) are doing exactly this: https://noyb.eu/en/noyb-files-422-formal-gdpr-complaints-ner... Once there are a few high-profile cases with high fines to set a precedent, this hopefully changes the way companies handle cookie banners.

> Can we cut through the clickbait and see what's wrong here. If my website askes users for their permission to use GA and they click yes then is that still illegal here? I see this as yes it's still illegal.

From what I can tell: If you ask your users for permisssion ("informed consent"), then no, it is not illegal. The way I understood the court case in Austria, the disputed point was whether or not the use of GA falls under the GDPR. If it does fall under it, then you are obliged to ask your users for consent ("opt-in"). If it does not, you can use it freely without consent.

Because analytics data isn't worth that much if you collect only part of the data, most collectors of data do not want to ask users for their consent, because most users would reject this.

But IANAL. In any case, please stop using Google Analytics, and self-host your analytics using Matomo, Plausible, or something similar. Matomo can also be configured to use server-side analytics, in which case your analytics become both less invasive (no client-side JS needed) and more complete (can't be blocked by ad-blockers).

There's also Pixelfed, which is like "Instagram on the Fediverse".

Ah, from Reddit (https://www.reddit.com/r/ErgoMechKeyboards/comments/scj65b/g...):

> Unfortunately Hot-swap sockets are not really compatible with curved FR4 PCBs, without extensive hand soldering.

That makes sense.

I agree about hot-swap, but I'm not sure if hot-swap exists on the market for low-profile switches.

A non-low-profile keyboard would need to be designed differently, to avoid the keys colliding (due to the curving). It's probably not feasible as an option, that would be an entirely new design.

Unfortunately TypeScript's enums have various shortcomings compared to powerful sum types in languages like Rust:

- https://stackoverflow.com/questions/40275832/typescript-has-...

- https://github.com/microsoft/TypeScript/issues/32690

In a TS codebase I'm currently working on, we have the policy of never using "plain" TS enums. Instead, we have a tool that generates our own enum objects using a schema and a generator script for the cases where we want "rich" enums. For other use cases, we use string unions a lot (in combination with a helper function that allows exhaustive matching).

Developing UI components based on ContentEditable is trial and error, with a lot of code held together by cross-browser integration tests where you always have to pray that a browser upgrade doesn't brake something new in a subtle and surprising way...

1/5, would not recommend. (But sometimes there's no way around it.)

Hmm, putting them in a subcrate / separate compilation unit is pretty smart. I can imagine that quite a chunk of the compilation time goes into the proc macros :)

I like Docopt for quick scripts, used it both in Python and Rust projects. It is quite unflexible though.

The Rust Docopt implementation¹ was deprecated this year, which is probably good because clap v3² is so awesome. In a project of mine (tealdeer), I noticed that docopt.rs was responsible for the huge majority of CPU instructions when running the binary: https://github.com/dbrgn/tealdeer/issues/106#issuecomment-59... I then switched³ to clap and shaved off almost a megabyte from the release binary⁴. Performance improved as well, time required for rendering a tldr page went down from ~15.9 ms to ~12.4 ms⁵. With the migration, we also managed to reduce a lot of custom validation logic and move this logic into the derive macro attributes.

¹ https://github.com/docopt/docopt.rs

² https://github.com/clap-rs/clap

³ https://github.com/dbrgn/tealdeer/pull/108

⁴ https://github.com/dbrgn/tealdeer/pull/108#issuecomment-9448...

⁵ https://github.com/dbrgn/tealdeer/pull/108#issuecomment-9448...

Looks nice!

Did you try fuzzing your implementation (e.g. with AFL++ or libfuzzer)? Codecs and especially decoders written in C that handle untrusted binary data are quite worthwhile targets for fuzzing.

How is that related to serde?

> If we mean to say this tractor is all-electric, keep in mind most small farms arent equipped to charge anything more advanced than a cordless drill or flashlight.

Are you sure? In Switzerland, most farms I know have at least one dusty three-phase power outlet somewhere in a shed. Sometimes just 16A, but that should be sufficient for many use cases.

Yep, the core concepts did not change. It's still relevant.

Note: If someone wants to learn Rust by implementing linked lists, then https://rust-unofficial.github.io/too-many-lists/ is a must-read :)

Just start a small project and figure out how things work on-the-go :) My first one was a small PCB to control a RGB LED strip using three potentiometers.

Instead of discussing the ideas presented, the _person_ behind the ideas is discussed. In my book, that's pretty close to an ad-hominem, even if the accusations are only implied.