Love how well you articulate these notions. They are truly valid for most of us. It also means you're doing it right. The point then is to stay with the practice until you can stop fighting the notion of boredom and instead be "friends" with it. Just be fine with the boredom. Learn to relax in it. Hope you'll try it again.
While I like Proxmox and have used it in a startup, I wouldn't recommend it for enterprise simply due to how flaky the Terraform integration was the last time I checked. Probably a year or two ago. Regardless, the Terraform integration was done in the typical open source fashion of a single developer, where I'd question the amount of resources put into getting the software past 80% completion. The company behind Proxmox does not seem to prioritize the enterprise market segment.
We ended up using the REST API for automated provision management and there are certainly warts. It's a far cry from being a turn-key solution, which I'd argue is preferred by a large enterprise.
It's great for click-ops if that's your use case, but that also wouldn't qualify as an enterprise use case.
It's quite annoying to not be able to use common tools for DNS queries like `dig`, when using `systemd-resolved` for DNS. I think you might have to sometimes flush the caching feature of `systemd-resolved` as well.
It's fine, I guess. But it did take a while to learn the new ways.
I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.
I did have a look at numpy and on my machine the tests did not bloat it as much as you made me believe. The `core/tests/` modules are 3MB and the `__pycache__` doubled it to 6MB. What do you refer to as "test case artifacts"? The modules, pycache, or both?
Also, wrt you statement on pandas; is it the debug symbols that account for the bloat, or the libs themselves?
Wrt to 1), how often do you reckon a beginner is faced with:
> By default, `args` is a set of derivation names denoting derivations in the active Nix expression. These are realised, and the resulting output paths are installed.
?? - I think the author really hits the nail on the head with this point.
From what I've heard from experienced carpenters and wood millers, growing conditions are a huge factor, as you want slow growing trees that have compact tree-rings. Also if you can get a wood piece with the core wood running through the entire length, you'll have a stronger work piece.
Whenever I see a GIS application, I'm always curious to see how they solve the gdal problem.
The best is always no GDAL, but that gets pretty hard to do quite quickly as GDAL contains some really great algorithms for dealing with non-trivial raster processing.
This is sorely missed in the GIS world: A well written and simple tool that isn't over engineered trying to cover all sorts of fringe use cases. Very clean code and good design at first glance.
I get why rasterio is preferred, its API is less annoying, but I'm not sure putting a leaking abstraction over gdal helps much. It just creates an aluring veneer over gdal, without really solving the main problems of gdal, being its monolithic monstrosity of hardly portable yet highly necessary GIS tool functionality.
Doesn't matter too much with gdal's warts, as this server should be deployed with ansible or in a container anyways, so portability is handled in a somewhat sane manner.
I really like dgraph. Even amidst some rapid development for graphql integration, dev team has been quick to respond to issues. Was happy to see the continued Jepsen testing.
Now that the frontend devs have gotten their attention, I hope dgraph plans to give the python community some love as well by improving the client API and asyncio support and even full integration with networkx.
Hackers in standard CSGO games are rampant from what I understand.
Serious players pay extra to queue up in a dedicated service for high tickrate servers and anti-cheats which I believe are rootkits as well.. not sure about any of this though.