You code in Java
... that's your source of problems right there.
2854 posts • joined 6 Sep 2007
... what will that bomber do when a bunch of critical processes get evicted due to too much disk space taken up by logs. And the logs immediately deleted, as the pods are being destroyed. Don't get me wrong, Kubernetes is very useful for lots of different cases, but critical software that can result in people dying when gone wrong is probably not one of them.
It probably already is.
Not yet. I quite like 20.04 server edition, but right after installation I run a small script which starts like so:
apt-get purge -y fwupd packagekit dconf-service dconf-gsettings-backend bolt unattended-upgrades open-iscsi multipath-tools sg3-utils tpm-udev glib-networking glib-networking-common glib-networking-services snapd landscape-common
apt-get install -y zsh bc kpartx zip unzip wget curl tmux htop vim
apt-get autoremove --purge -y
The machines work just fine without snapd. It's a good luck that I have no desire to use LXD because then I would have to install it with snap.
C++ has threads since version C++11 . Rather than create threads ad-hoc, the more efficient way is to manage a thread pool, fixed to the number of available cores. The problem with efficiency remains because of synchronization overhead, see also Amdahl's law (not to mention whole new category of bugs). Although of course there are better alternatives to explicit synchronization, e.g. message passing (for C++ example see seastar library - it looks ugly, but is also very efficient). Message passing is one of the reasons to try Go because channels are quite a good abstraction.
The smart thing would be for UK to "support" this. When US corporations (esp. Silicon Valley) wake up to the fact that everyone is considering their tech a liability rather than asset, lure them to this side of the pond with more liberal regulation, and let US slide to Amish level of tech.
I disagree. Java GC is one or two orders of magnitude slower than that provided by modern Go runtime, not to mention both memory and CPU overhead of all the other 3rd party Java libraries which you will end up using in your program, for convenience or because Java defaults are not useful. It's just not very good for microservices, unless your memory and cores come for free. Although admittedly, Oracle is making an effort to bring Java to more modern age, with GraalVM.
"The implication is that while Go may be great for developing APIs and web services, it is not so good at the lowest level, perhaps a price paid for developer-friendly features like garbage collection."
I concur. Garbage collection is not great if your program works with many low-level resources (other than memory) because you have to maintain their lifetime by hand. I use both C++ and Go and while I would prefer to write higher level code in Go only, anything low-level has a better chance of good performance and consistent low resource utilization if it is written in good, idiomatic C++
It's an old chip and I am not surprised that it is being retired. Perhaps they waited for a worthy successor - there are few on the horizon as of now, but it will be little longer before the new hardware can be installed in the datacentres. They also won't be cheap, which makes them hard sell for bare-metal. In the meantime, the old bare-metal instances are turning out to be pain for the users and maintenance staff which is not surprising.
You are comparing apples to oranges; Intel's TDP applies to base frequency only and will be exceeded, by quite a large but unspecified degree, as soon as turbo frequencies kick in (which, for some workloads, could be "all the time"). AMD TDP on the other hand is focused on a removal of waste heat which is perhaps more accurate as it indirectly points to max power, but is also unnecessarily coupled to things like thermal capacity of a cooler. Example discussion here.
Biting the hand that feeds IT © 1998–2020