berkes (u/berkes) - Readit News

berkes commented on F-Droid build servers can't build modern Android apps due to outdated CPUs · Posted by u/nativeforks

dannyw · 13 days ago

I agree it’s a bit concerning but please keep in mind F-Droid is a volunteer-run community project. Especially with some EU countries moving to open source software, it would be nice to see some public funding for projects like F-Droid.

berkes · 13 days ago

> please keep in mind F-Droid is a volunteer-run community project.

To, me, that's the worrying part.

Not that it's ran by volunteers. But that all there's left between a full-on "tech monopoly" or hegemony, and a free internet, is small bands of underfunded volunteers.

Opposition to market dominance and monopolies by multibillion multinationals shouldn't just come from a few volunteers. If that's the case, just roll over and give up; the cause is lost. (As I've done, hence my defaitism)

Aside from that: it being "a volunteer ran community" shouldn't be put as an excuse for why it's in trouble/has poor UX/is hard to use/is behind/etc. It should be a killer feature. Something that makes it more resilient/better attuned/easier/earlier adopting/etc.

berkes commented on I bought a £16 smartwatch just because it used USB-C shkspr.mobi/blog/2025/08/... · Posted by u/blenderob

oezi · 17 days ago

Apple just put in a more capable processor, wifi and cellular, a brighter display and more sensors. They are just consuming the entire battery over a day because it is not such a big deal for customers.

berkes · 17 days ago

Is it not a big deal? Or do customers lack the choice?

If Apple had two lines of smartwatches, one for city/work crowd with the WiFi, Bright screen, NFC, powerful processor etc. but with tiny battery life. And another for hike/off-grid/travel/festival crowd without wifi, a slower, blander screen, slower hardware, less features but over a week)weeks on one charge.

Would people not buy the second option?

berkes commented on I bought a £16 smartwatch just because it used USB-C shkspr.mobi/blog/2025/08/... · Posted by u/blenderob

ofrzeta · 17 days ago

I have an Amazfit smartwatch that gets charged by a simple USB cable with two pins that magnetically attaches to the back of the watch. When I was on vacation and forgot that cable I was able to make my own by cutting a USB cable and attaching the wires to the contacts of the watch with tape. That simplicity is hard to beat. And this watch is water resistant.

berkes · 17 days ago

Those proprietary cables are terrible.

USB (abc, micro etc) are everywhere. Any house, hotel, office, glove box, has some lying around.

But when I forgot my Fitbit charger, I couldn't get one anywhere. The only option was a large electronics store where I could buy an entire new Fitbit. I didn't shove out €200 just to get hold of a charging cable.

The EU should quickly impose rules on waterproof chargers like they did with USB chargers. It will settle worldwide just as fast as the USB enforced standard.

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

theozero · 21 days ago

In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of your codebase.

berkes · 21 days ago

Yes, that's indeed the right place, IMO: ephemeral tooling that leverages, or simplifies OS features.

Tooling such as xenv, a tiny bash script, a makefile etc. that devs can then replace with their own if they wish (A windows user may need something different from my zsh built-in). That isn't present at all in prod, or when running in k8s or docker compose locally.

A few years ago, I surfaced a security bug in an integrated .env loader that partly leveraged a lib and partly was DIY/NIH code. A dev built something that would traverse up and down file hierarchies to search for .env.* files and merge them runtime and reload the app if it found a new or changed one. Useful for dev. But on prod, uploading a .env.png would end up in in a temp dir that this homebuilt monstrosity would then pick up. Yes, any internet user could inject most configuration into our production app.

Because a developer built a solution to a problem that was long solved, if only he had researched the problem a bit longer.

We "fixed" it by ripping out thousands of LOCs, a dependency (with dependencies) and putting one line back in the READMe: use an env loader like .... Turned out that not only was it a security issue, it was an inotify hogger, memory hog, and io bottleneck on boot. We could downsize some production infra afterwards.

Yes, the dev built bad software. But, again, the problem wasn't that quality, but the fact it was considered to be built in the first place.

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

brulard · 22 days ago

How many apps do you think has properly set user and access rights only to what they need? In production? If even that percentage was high, how about developers machines, people that run some node scripts which might import whoever knows what? It is possible to have it running safely, but I doubt it's a high percentage of people. Feature like this can increase that percentage

berkes · 22 days ago

Wouldn't "simplifying" or even awareness of the existence of such OS features be a much better solution than re-building it in a runtime?

If an existing feature is used too little, then I'm not sure if rebuilding it elsewhere is the proper solution. Unless the existing feature is in a fundamentally wrong place. Which this isn't: the OS is probably the only right place for access permissions.

An obvious solution would be education. Teach people how to use docker mounts right. How to use chroot. How Linux' chmod and chown work. Or provide modern and usable alternatives to those.

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

hk1337 · 22 days ago

> The "proper" place to solve this, is in the OS.

This is my thought on using dotenv libraries. The app shouldn’t have to load environment variables, only read them. Using a dotenv function/plugin like in omz is far more preferable.

berkes · 22 days ago

Entirely.

The argument often heard though is 'but windows'. Though if windows lacks env (or Cron, or chroot, etc) the solution would be to either move to an env that does support it, or introduce some tooling only for the windows users.

Not build a complex, hierarchical directory scanner that finds and merges all sorts of .env .env.local and whatnots.

On dev I often do use .ENV files, but use zenv or a loadenv tool or script outside of the projects codebase to then load these files into the env.

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

batmansmk · 22 days ago

For years, I heard it's better to use cron, because the problem was already solved the right way(tm). My experience with cron has been about a dozen difficult fixes in production of cron not running / not with the right permission / errors lost without being logged / ... Changing / upgrading OSes became a problem. I since switched to a small node script with a basic scheduler in it, I had ZERO issues in 7 years. My devs happily add entries in the scheduler without bothering me. We even added consistency checks, asserts, scheduled one time execution tasks, ... and now multi server scheduling.

Deployments that need to configure OSes in a particular way are difficult (the existence of docker, kubernetes, snap are symptoms of this difficulty). It requires a high level of privilege to do so. Upgrades and rollbacks are challenging, if ever done. OSes sometimes don't provide solution when we go beyond one hardware.

If "npm start" can restrain the permissions to what it should be for the given version of the code, I will use it and I'll be happy.

berkes · 22 days ago

If cron is broken for you, than the logic solution would be to replace it with something that does work for you. But do so at the right place and abstraction. That's hardly ever the runtime or in the app.

Do One Thing (and do it well).

A special domain specific scheduler microservice? One of the many Cron replacements? One of the many "SaaS cron"? Systemd?

This problem has been solved. Corner cases ironed out. Free to use.

Same for ENV var as configurations (as opposed to inventing yet another config solution), file permissions, monitoring, networking, sandboxing, chrooting etc. the amount of broken, insecure or just inefficient DIY versions of stuff handled in an OS I've had to work around is mind boggling. Causing a trice a loss: the time taken to build it. That time not spent on the business domain, and the time to them maintain and debug it for the next fifteen years.

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

tkzed49 · 22 days ago

I think the widely-implemented terminal escape sequences are well-known at this point, but I don't see why I'd want to copy this into every project.

Also, I'm guessing if I pipe your logs to a file you'll still write escapes into it? Why not just make life easier?

berkes · 22 days ago

Arguably, using a library is also "copy it into every project".

berkes commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

simonw · 22 days ago

Whoa, I didn't know about this:

  # Run with restricted file system access
  node --experimental-permission \
    --allow-fs-read=./data --allow-fs-write=./logs app.js
  
  # Network restrictions
  node --experimental-permission \
    --allow-net=api.example.com app.js

Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

berkes · 22 days ago

I very much dislike such features in a runtime or app.

The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already.

Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

berkes commented on Figma will IPO on July 31 figma.com/blog/ipo-pricin... · Posted by u/nevir

lazyasciiart · a month ago

Sure, but I’ve seen plenty of senior co-workers deliver a pile of dynamite in Java and get a bonus for it, abandoning it to some other poor sod who will have to fix and maintain it. Managers who reward that behavior will probably be the ones who try to AI Everything, and it’ll probably work for just long enough to make all the devs redundant.

berkes · a month ago

Yea. To be clear. With "senior" I did not mean "developers with over 16 months of experience" but developers that have failed spectacularly, several times, learned from that, and now strive to avoid these, and related mistakes.

A junior can never be that, due to lack of the experience. But too many long-term developers haven't failed, or haven't learned from these mistakes.

For example, about five years ago, I worked a few months with a 40+ years-of-experience software developer, who worked almost his entire life on one single product (in C++ and Java) in one company, solo. I was asked to assess if/how it was possible to get new people for this project because he was retiring. Part of the code was marvelous and a true beauty. Other parts were horrors or inintelligable mess. He truly did not like Java (at first) so a giant part of the java codebase was there to make it look-and-feel somewhat like his (also non-standard) C++.

Ironically, the nice parts were those that were hardly touched or changed - infrastructure, boilerplate, etc. But the worst parts were those that needed frequent changes due to business demands or the ever changing outside world. He honestly never realized that there were patterns and systems (by now), to keep software manageable under real-world-demands and changes. That turned also to be the saving of this project: he loved "DDD" and "Design Patterns" (both he heard about, but never dove into), and implemented some core ideas in this project before handing it over: anti-corruption-layers, ports-adapters, dependency-injection, testing.