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.
(I'm one of the founders of Latacora and reviewed the post.) If any of you are at Heart of Clojure, I'll be there both wearing my Latacora hat and my Clojurists Together hat :)
I would love for my next job to be in Common Lisp.
I do have a concern though. I see that at lots of companies the job is not a Go job or a Python job or a Javascript job, but a Go-at-Foocorp job or a Python-at-Bazco job or a Javascript-at-International-Clowns-Inc. job. What I mean is that the team have built so many leaky abstractions atop the core language, and added so many third-party tools, that the learning curve is steep and the skills non-transferable. On the one hand, who cares? We’re human, we can learn. But on the other it means that it can take significantly longer to ramp up and start delivering value than one would prefer.
What’s this have to do with Lisp? Well, while a well-written Lisp system will be faster to pick up and get started on that one in a less-powerful language (i.e., almost all of them), a poorly-written mess will be much, much slower. My concern is that I might leave a pretty good situation for what ends up being a dumpster fire — and then have to find a new job too quickly.
I'd say that market exists, but is kinda invisible.
I've been looking around for a junior with a passion for Common Lisp, but I have _no_ idea where to find one, especially in Germany (job's remote, but I'm currently not able to hire FTEs outside the country).
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.
> 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.
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.
There are a string of these posts going back to 2009. Not "updated every 3 years", but it looks to me like we get an update when important advice has changed at least. I may have missed some, but from my bookmarks I have:
So not every 3 years, but if you read through you'll notice a _lot_ of each update pretty much says "use the same advice as last time."
It's not clear who wrote the most recent Latacora post, but it's Thomas Ptacek's company, and the original 2009 post was by Colin Percival. If you've been around here for a while you'll probably recognise those names, they's #1 and #60 here: https://news.ycombinator.com/leaders At least in my head, both have serious credibility over many years in this subject space.
The 2018 Latacora post says:
"This content has been developed and updated by different people over a decade. We’ve kept what Colin Percival originally said in 2009, Thomas Ptacek said in 2015, and what we’re saying in 2018 for comparison. If you’re designing something today, just use the 2018 Latacora recommendation."
I started Latacora with Erin and Jeremy in 2016, and wrote the last "Right Answers" post with their name on it, but Erin and I haven't worked there since 2020.
"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.
This is true but the kernel gets more scrutiny and has better priorities. Only CrowdStrike audits and hardens the CS kernel driver, so things like proactive improvements are competing in a single Jira board against marketing’s request for new features (want to bet that was all AI until Friday?) whereas the kernel eBPF implementation might be improved by people at other security vendors, distributions like Red Hat or Ubuntu or a major cloud provider (all of whom fund serious security audits and have engineers who care a lot about robustness), or academic researchers.
“Many eyes” is a bit dubious in general but the Linux kernel is pretty much the best case for it being true.
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.
That sodium battery sounds great for grid scale storage and maybe aviation. The major problem with lithium there is weight per kWh. Wouldn’t use it in anything consumer because liquid sodium loves to party.
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.
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.
But what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for people like you
This is still a good practical reference I like to point out, when people ask: https://www.youtube.com/watch?v=mWqe8_5SUvk Richard A. Steenbergen has also other good talks, e.g. on traceroute. There are multiple versions of these talks that include more or less the same stuff with occasionally more information here and 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.
reply