kaliszad

The author is a great guy and indeed quite smart and meticulous in areas he cares about deeply. He is a published author with a reasonably popular book considering the market size: https://www.melvil.cz/kniha-jak-sbalit-zenu-20/ he has edited probably more books than he would like to admit as well. It's not surprising he is able to write a good article.

However good writing is a skill you can get good at with enough practice. Read a lot, write a lot of garbage, consult more experienced writers and eventually you will write readable articles soon. Do 10-100x more of that and you will be pretty great. The rest is some kind skill and experience in many other fields than writing which will inform how to write even better. Some of it is intelligence, luck, great mentors and perhaps something we call talent even. As with most things you can get far just by working diligently a lot.

Czech does as well, milion, miliarda, bilion, biliarda...

Perhaps we don't need to transport electrical current in the form of electricity but rather some kind of media, perhaps sodium metal could be a good choice. We could pump liquid sodium through pipelines or just transport it by ships.

Salt (NaCl) is abundant in oceans. If you react sodium with water in a fuel cell you get NaOH, which you can again electrolytically split into sodium metal, oxygen, and hydrogen. There are ways how to extract sodium metal more efficiently than using the 130 year old basic Castner process though and there are better approaches to the fuel cell than what Lockheed imagined originally in the 1970s.

The java.net.Inet4Address and Inet6Address could be more lightweight.

For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.

For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.

Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. What am I missing here? Can or should this be streamlined?

Here is an archive of the article:

https://web.archive.org/web/20250512120733/https://www.bloom...

This seems like a case of insufficient leverage and negotiation. This is of course easy to say after the problem is described. Freelancers and small companies need to be really good at negotiation or accept that they will have a higher risk of losing a lot of money, time and energy on somewhat unnecessary fuck-ups.

Most of the moving I have personally done was with people that someone knew and it worked out reasonably well. We have done most of the packing and these guys have mostly just done the loading/ unloading. The only other thing was taking apart and putting together the bed, table etc. This worked well enough even between Zurich and Prague and cost slightly over $1,000.

Yes and no. Statically typed languages only know that data stored in some piece of memory was conforming to some kind of shape/ interface when it was first stored there. That's why tricks like SIMD Within A Register (SWAR) work at all. E.g. when you need to parse temperatures from string input very fast like in the 1BRC: https://questdb.com/blog/billion-row-challenge-step-by-step/ How does your type system help there?

With static typing, you are doing specification and optimization at the same time, which is maybe necessary because compilers and languages are not sufficiently smart but also because of this mix it complicates reasoning about correctness and performance. Also static typing introduces a whole universe of problems with itself. That's why we have reflection or stuff like memory inefficient IP address objects in Java:

For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.

For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.

Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. Is this just bad design or excessive faith in static typing combined with OOP?

The two things I ever enjoyed that is some kind of programming was building a pipeline in shell to process data and for the last almost 5 years writing Clojure and ClojureScript. We are now 4 guys writing Clojure with 30+ years of Clojure experience added together. I participated as a co-founder in a front-end heavy project in Clojure/ ClojureScript and more than a year ago started a Clojure-preferring consultancy in Prague, Czechia. For stuff like Inter-dealer broker trading system it's a no-brainer. For many other things as well. Even for distributed systems/ higher level infrastructure stuff it might be a good choice to get going at least.

I wonder does anybody use GnuCash for s.r.o. (LLC/ Ltd.) business in Czechia? How is your experience with it, e.g. do you also do DPH (VAT)?

The ZFS ARC cache tries to keep a balance between most frequently and least recently used data. Also, by default, ZFS ARC only fills out to a maximum of about half the available RAM. You can change that at runtime (by writing the size in bytes to

  /sys/module/zfs/parameters/zfs_arc_max

or setting the module e.g. in

  /etc/modporbe.d/zfs.conf

to something like this

  options zfs zfs_arc_max=<size in bytes>

). But be careful, as the ZFS ARC does not play that nice with the OOM killer.

That's what SLOG is for if the writes are synchronous or if you have many small files/ want to optimize the metadata speed look at the metadata special device, which can also store small files of configurable size.

ZFS of course has its limits too. But in my experience I feel much more confident (re)configuring it. You can tune the real world performance well enough especially if you can utilize some of the advanced features of ZFS like snapshots/ bookmarks + zfs-send/recv for backups. Because with LVM/ XFS you can certainly hack something together which will work pretty reliably too but with ZFS it's all integrated and well tested (because it is a common use case).

Now the common code base of upstream OpenZFS is the FreeBSD/ Linux code. Things have changed a lot with OpenZFS 2.0 AFAIK.

Yeah, server vendors are a bit crazy with small jet engine fans. A 4U chassis could easily house 80, 92 or even 120 mm fans which could spin much slower with a much higher air flow. That would of course also be much more efficient.

Rather build a L2ARC or metadata special device hybrid setup using ZFS or skip ZFS and go for lvmcache/ mdadm style RAID with XFS or something.

I wouldn't recommend combining those two. It's only begging for problems.

You can also have a special metadata only/ small files dedicated special VDEV. ZFS can pull of many tricks if you configure it well. Of course, the L2ARC is better, if you don't trust the caching device that much (e.g. only have a single SSD).

You clearly haven't read the full article as Jim Salter writes about the mechanical stuff at the end of the article.

Also, you want to reduce vibrations because of this: https://www.youtube.com/watch?v=tDacjrSCeq4 (Shouting in the datacenter)

Btw. there is a new video from the Heart of Clojure Hallway track: https://www.youtube.com/watch?v=GEqzw6V31tk I think it really captures the great atmosphere in the community and some community leaders.

Missed your reply but we've met anyway... so all is good. Thank you for attending and sponsoring.

Hard to say, I was always contacted directly by the team/ had other role and later it turned out I can do a fair bit of programming too ;-)

Yes, in fact there is also a good number of conferences, for instance in less than two days https://2024.heartofclojure.eu/ starts in Belgium for instance (meet me there ;-) ).

We are writing a trading system for a small broker company in Clojure/ ClojureScript with a Datomic centered backend. The previous company some of us on the team worked at had the code-base also in Clojure/ ClojureScript.

See the quotes...

At that time I wrote this excerpt:

  > I observed the /dev/sda disk that comes with our VM is supposed to be 80 GB big.
  > If this was to a decimal base, it would be exactly 80 000 000 000 bytes big, but
  > it is actually 81923145728 bytes big. That is 80.003072 GB if you define a GB as
  > 10^6 \* 1024 bytes and add 3 KiB (3072 bytes). This is quite non-standard, because
  > you basically mix bases without any sort of transparency.
  >
  > We also have a volume mounted. /dev/sdb is currently 70 GB big where you seem to
  > define a GB as IEC GiB or 2^30 bytes.

It seems they have upgraded the specs on the block storage volumes, I have a support e-mail from December 22nd 2022 saying "You can expect a throughput of 250MB/s on average, and up to 2500 IOPS for the cloud blockstorage volumes." and that it's constant with size (which still seems to be the case). They write "It is not possible to RAID them, they are already in a RAID on the volume host." which is a mystery to me what it means exactly.

I guess they could write, if you must assume the volumes are served by the same cluster or not - e.g. for the case where you need more performance or storage space as one big filesystem/ file (and want to do a software RAID/ use ZFS/ btrfs/ bcachefs etc. to achieve that).

There is no note about the performance/ limits of the NVMe storage that the instance resides on - they generally seem to be much faster.

Also in 2021, I got a clarification by Markus Schade that:

"Instance disks are included in every server type and defined in the same way as physical drives (80 GB = 80000 MiB) rounded to the nearest 4MB. As we are offering dedicated as well as virtual servers, we use GB on all our pages for included drive sizes to reflect this. Volumes are different because it is a pay as you product. As such they are sized and invoiced on a per GiB basis."

Volumes seem to be base 2.

Unfortunately, Hetzner also have no log about internal migrations of VMs or relevant adjustments to the underlying host that would be visible to the user. What seems to be some kind of infrastructure adjust seems to have had a negative influence on Java GC at least once. It would be easier to debug these things if you didn't have to ask support first and make yourself look like a fool at times.

If you have proper dental hygiene there should be no smell from your mouth besides after spicy foods/ onions/ garlic etc. until you brush of the plaque. Or if you are sick (that goes mostly from the bacterial disbalance, the stomach etc.)

Of course, the minty freshness is nice to have but that is just a bonus. Most people rely on this to cover up bad hygiene but a proper dental hygienist will of course see the problems either way.

If you search my comments, I have written about dental hygiene at length. Source: my fiance is a DH, see neighbouring threads.

That assumes you use a suitable electric toothbrush and technique. If you search my comments I have written about dental hygiene before at length.

I use Philips Sonicare, heard good things about Oral-B iO from a dental hygienist who has patients using both.

Of course, flossing using a super floss (OralB makes those) and interdental brushes by Curaprox/ TP of correct sizes is important to also clean the space between your teeth and significantly lower the likelihood of gingivitis and almost eliminates the progression to periodontitis.

And the interdental brushes hopefully more often. Or, of course, you floss in that case you have a harder and more time consuming way of staying on top dental hygiene.

(Source: My fiance is a dental hygienist in Prague, Czechia specializing in periodontology and treatment of advanced periodontitis.)

Thank you for the update. This is really useful. It would be really great, if you could commit to an update a few years down the road at the latest. E.g. "I will release an update no later than August 15th 2027". 3 years in the fast-changing world shouldn't be such a burden and it would help to settle many discussions somewhat reasonably with appeal to authority :-D No seriously, having something that can be considered current advice would be great.

"These security agents will then be safe and unable to cause a Windows kernel crash."

Unless of course there is a bug in eBPF (https://access.redhat.com/solutions/7068083) @brendangregg and the kernel panics/ BSoDs anyway which you mention later in the article of course.

No, I really meant less investment - you don't have to push seamless pipes 10+ km underground for the sodium fuel cell to work. It can literally be built in a garage.

Liquid sodium is totally fine unless you pour water over it. You have problems with other substances too and it depends what use case and limits you have whether you are willing to go with sodium. For example, filling a big tank with normal gasoline is dangerous without protective atmosphere and other precautions like good grounding because it tends to produce flammable vapors that catch fire easily. Not a problem with sodium. Also, if you happen to spill sodium into water, it neutralizes quickly doing damage only for a short period of time. That cannot be said about any kind of mineral oil, gasoline that has a tendency to destroy ecosystems etc. Last but not least, you can produce sodium metal without begging mostly totalitarian/ authoritarian regimes for natural resources which is the case with the majority of fossil fuels today.

Because of electronics and fine machines we learned a lot about how to make stuff water tight. Sodium is in my opinion mostly much easier to handle than hydrogen, which leaks even through steel, which you have to keep under high pressure to have any kind of decent volumetric energy density or cool to very low temperatures if liquid.

If you used sodium for grid scale storage than you would more or less solve the electricity storage problem and most likely quite cheaply. The great thing about it is, you can store and transport sodium metal easily. Storing power for the winter becomes practical. For stationary stuff in homes or businesses you could probably use sodium too. You could replace old central furnaces with it and instead use the fuel cell and a heat pump perhaps with a small battery and PV to smooth out the peaks. That way you probably wouldn't need to upgrade the last mile of the grid in many places. You could power boats with it. For aviation it doesn't seem that great as you would still have to handle the resulting sodium hydroxide.

There are so many energy projects that need probably orders of magnitude less investment than even the geothermal You propose, e.g. like the sodium fuel cell I have been writing about from time to time.

For instance sodium can be used in its metal form directly to produce electricity in a fuel cell e.g. as described in US3730776A (https://patents.google.com/patent/US3730776A/en). The fuel cell does not require any special materials, however it still is a challenge to construct from the engineering point of view. Also, the proposed design can be greatly improved with additional knowledge about the reactions occurring. The resulting sodium hydroxide solution can be recycled using the well known Castner process, the "waste" hydrogen resulting from both reactions can be used as fuel or for other industrial processes.

Btw. the energy density of sodium metal is 3694 Wh/kg and 3555 Wh/litre - so an order of magnitude more than a typical Li-Ion battery. Also, the advantage of decoupling capacity from power is dramatic. Of course, you can also split the process of storing and releasing of energy which can be an advantage. Last but not least, sodium in its metal form is not hard to store or to transport. At ~100°C it becomes liquid and therefore even easier to transfer using regular steel pipes.

If you are defending against a nation state, you should be worried about your staff being bribed, otherwise coerced or worse just being foreign agents. In properly run networks, BGP hijacks shouldn't have a noticeable impact.