fillest

How is client logic support for different languages designed in your project? Some time ago I found Kafka clients for several languages are pretty much unusable due to bugs and/or performance non-debuggability. The reason, I think, was that the client logic is quite complex and each client project had to re-implement it from scratch (or use some C FFI monstrosity - which was pretty much a dead end too).

Services should be decoupled from OS distro dependencies as much as possible, otherwise you will be bitten at an unexpected moment (e.g. upgrading your distro packages) by some problem like this https://wiki.postgresql.org/wiki/Locale_data_changes

This can be solved by building statically (or using something like Nix) or by at least using containers.

Be careful if you use streaming replication - secondary replica leaks memory on 17.0 (16.4 is fine)

A personal warning about 17.0 if you use streaming replication: secondary replica leaks memory quite actively. 16.4 is OK.

Got an order of magnitude saving, mainly due to absurd AWS network traffic costs.

Why is watchdog needed at all? There is systemd or any other pid1, stdout/stderr should go to journal without any middleware.

I fail to see how being on that list implies anything. Imagine for example if you are a person with some status which implies that you are socially/politically active, and some rich folk calls you and invites you to have a talk at a dinner, would you instantly decline it? For example even if you dislike this class of people, don't you at least feel curious how will this meeting pass? Isn't it an interesting, even useful experience even if you know that you are going to decline any offer he will propose there anyway?

The font rendering is poor, blurry on edges of the letters, even if I increase the font size (which works poorly anyway because the thin column container doesn't scale, keeps its width)

I wouldn't call it noodly.. If her composition was a bit more complex, it would be close to Debussy level probably. She's maybe like minimalist Debussy :) Check her "Ballad of the Spirits" and "The Song of the Sea".

Nah, check Fostex TH-900 (25 ohm), for example

This is fake indeed. And it is strange and bitter for me to see it unflagged on HN

On mobile it is indeed at least not blurry but still harder to read..

The font is unreadable, very thin

I think, the problem is: the production of languages (and libraries especially) is way too much market-driven, there is too little cooperation, too little time spent to polish and to model at least some major use cases. Also the quality of education is too poor, too focused on time-to-market - it makes harder for non-seniors to understand e.g. complex type systems (which are required for more usable languages anyway).

A language is released too prematurely -> some companies start to use it -> design problems become clear, but the language is in a compatibility trap at this stage -> e.g. it becomes a swamp or it slowly becomes a monstrosity of design afterthoughts and crutches.

It probably even wouldn't require much more spending from corporations, only some initiative. They anyway already invest considerably in language&toolchain development, but often with wasteful goals.

If by "large" you mean e.g. "under relatively high load" then you can simulate this load and learn to deal with it. Populate your databases with a lot of generated data. Use load testing tools. Add latency and faults to different parts of the system (you can even inject errors into storage system (e.g. device-mapper)). At some point you even can rent some big servers (e.g. cloud) to test you problems and ideas - the cost of learning can be very effective. Make some checklists and iterate over all the components:

  - what happens if this stuff fails (and how to test it, how to analyze it)
  - what attack surface that stuff has
  - how to scale if it receives x10 requests or becomes x10 bigger
  - how can you explain to a new coworker how it works, how all the decisions were made

It will rapidly give you the real understanding and practice. System design is about dealing with problems, making compromises. It is very hard to make an effective book (probably even impossible - it should probably be an interactive course at least) that will walk you through this process, not just throw a bunch of "patterns" at you (which is not useful and can infect you with the shallow cargo-culting that our whole industry is so full of).

While the "cloud" can look easier (and is indeed easier to start), there is quite big its own complexity around it - learning, tooling, specific problems, performance limits, costs and so on. Also most of this knowledge is not quite reusable.

But if you use the cloud carefully, selectively and avoid vendor lock-in as much as possible, you will be OK and it will be not hard to move to Hetzner (dedicated) incrementally later.

I was tempted to write "you always need to put a many-years-battle-tested specialized server in front, if you mean protection from attacks", but nowadays even these servers get so many new features and rewrites so often, that it's pretty valid to doubt their maturity.. And being written in C is always a time bomb.

But probably it's still a good idea to use them.

Test for Demodex mites infestation too

Hetzner has its network hiccups sometimes, but AWS quality may be a joke if you really care about latency tails and even median under any significant load. I didn't analyze the networking itself, but - you run in a VM and share host machine with other clients VMs - you just can't get stable latencies this way. It's night and day when you migrate to baremetal Hetzner and observe how latencies change. (Again - it's about dedicated baremetal - I know nothing about Hetzner's cloud)

The problem with Kafka is not Java nor ZooKeeper - it is that non-native (non-Java) clients are buggy as hell (last time I touched them), because everybody have to re-implement all the complex logic for each language (often multiple times). Do you have any plans for Redpanda-native protocol/client library?

It is OK to call whatever one needs actually - just minimize the usage of Bash language features (Python provides most of them). It is not complicated and requires no dependencies, here's a self-contained helper: https://gist.github.com/fillest/8d64f8fa0cdb1745bfc9c683cf39...

Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.

I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.

Probably, it's more fun to play with syscall filtering in containers or with fuzzers than to review side-channels or educating coworkers. Therefore, security theater.

The thing about compression is wrong. "HDR photography" compresess for the eyes (let's simplify and leave the brain out), it has nothing to do with displays. If a part of a photo is too dark, the details will be clipped out for your eyes, no matter how much bits they will be encoded with - it will be just too dark.

In reality eyes can adjust the "exposure" on the fly because they recieve all the needed information always. But in a displayed digital image this information is already lost - eyes don't recieve all these bits, the display doesn't send them.

In the editor you can adjust the "exposure" for the RAW files too - they have the needed information - but! - it is not a static image, because you are adjusting it, you are sending continuously different information to the eyes.

Exactly. Or even stricter. I've finally made a self-contained helper for that: https://gist.github.com/fillest/8d64f8fa0cdb1745bfc9c683cf39... Pure Bash is really not needed since we have Python 3.

Some software doesn't support that - building that way can randomly fail with very confusing errors.

Any reasearch/evidence on size vs strength, please? From what I've skimmed through, size vs strength looks like a myth (popular one though). It seemed to me that one can't get bigger without getting stronger (== handling heavier load) and vice versa. (Without pharma)

telegraf supports some summarization https://github.com/influxdata/telegraf#aggregator-plugins

>the application incurring OOM is statistically unlikely to be the one that should be killed on multi-application servers Could you please explain this?

Looks like they have tested a newer kernel too:

https://github.com/fastos/fastsocket#nginx

>on Linux 2.6.32 achieves 470K connection per second and 83% efficiency up to 24 cores, while performance of base 2.6.32 kernel increases non-linearly up to 12 cores and drops dramatically to 159K with 24 cores. The latest 3.13 kernel doubles the throughput to 283K when using 24 cores compared with 2.6.32. However, it has not completely solve the scalability bottlenecks, preventing performance from growing when more than 12 cores are used.