581 karma · joined February 26, 2022
I personally run my proxy there and overall I'd take some > 10000 port for such kind of stuff
I consider my point as still valid with UV, what you wanted to express?
On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.
That's kind of very optimistic evaluation - literally anything beyond "import json" will likely lead you into the abyss of virtual envs. Running something created with say Python 3.13.x on Ubuntu 22.04 or even 24.04 (LTSs) / Rocky 9 and the whole can of worms opened.
things like virtual envs + containers (docker like)/version managers become a must quickly.
Indeed, container live migration is limited and a bit unclear on "network devices" - bridged interface is network device or not?
Bit ironic, that even with using CRUI, which AFAIK was created by the same Virtuozzo guys which provided OpenVZ back then, and that VEs could live migrate, was personally testing it in 2007-2008. Granted, there we no systemd by that days, if this complicates things. And of course required their patched kernel.
> Live migration for containers For containers, there is limited support for live migration using CRIU. However, because of extensive kernel dependencies, only very basic containers (non-systemd containers without a network device) can be migrated reliably. In most real-world scenarios, you should stop the container, move it over and then start it again.
P.S. Microcloud tries to achieve this AFAIR, but it's from Canonical, so on LXD.
To some extent, of course things like vSphere/Virtuozzo and even LXD/Incus, and even simple Qemu/Virsh systems can do live migration of VMs, so you may care less on preparing things inside VMs to be fault taulerant, but to some extent.
I.e. if your team do run PostgreSQL, your run it in cluster with Patroni and VIPs and all that lovely industry standard magic and tell dev teams to use that VIP as entry point (in reality things bit more complicated with Haproxy/Pgbouncer on top, but enough to express the idea).
For others, why it may be useful in regular sysadmin job:
* say doing Ansible scripting against LOCAL network is hell amount of time faster than against 300+ ms remote machines
* note that because you can use VE snapshots, it's very easy to ensure your playbook works fine without guessing what have you modified when testing things - just do rollback to "clean" state and start over
* multiple distros available - need to debug Haproxy from say Rocky 8 linux? Check!
The full system, means, all your standard stuff works in expected way - crons, systemd units, sshd, multiple users, your regular backup solutions and so on. As well, that "system" can be dumped/exported/backuped/snapshotted as a whole - very much similar like you do with your vSphere/Qemu or whatever you use in your datacenters as hypervisor.
Foreseeing the question - yep, you can run Docker inside LXD/Incus VEs. In practical terms, that makes much simple when you need to give some dev team (who are of course not anywhere known to do sane things) access to environment with Docker access (which in 99% cases means that host's root level access is exposed).
I'm not sure I've ever seen any server which had dualboot of this sort - meaning production systems, not tests/homelabs of course. Usually it's either Linux either Windows, and never FreeBSD (it's dead basically, over last 15 years at least).
That sounds more like desktop/laptop usage case, where experimenting can happen and planning is out of equation, cuz it's well, experimenting.
> I do not see the connection between shrinking and migrations.
You may think on "changes" as more wider term in addition to migrations - be it changing underlying drives under DB partition or need to free some space on in VG and LV to be able to use LVM snapshots (a looooooot of systems I see allocate all the space in VG at once and then cannot use snapshots because there is literally no space available) or some webhosting like cPanel/Plesk managed need more/less space for /var/{mail,you_name_it} and so on.
Again, there could be more reallife stories with XFS, but well it was not an option in many cases in the past. Nowdays, at least in my bubble, it's usually something clustered and you can do migration/changes on node-by-node basis and downtime window is avoided on another level, not by FS means.
I.e. back in ~ 2013-2014 while moving some baremetal Windows server into VMware, srhinking and then optimizing MFT helped to save AFAIR 2 hours of downtime window.
> except perhaps as a consequence of bad planning
Assuming people go to Clouds instead of physical servers because they may need to add 100 more nodes "suddenly" - selling point of Clouds is "avoid planning" - one may expect cases of need of shrinking are rising, now lowing. It may be mitigated by different approaches of course - i.e. often it's easier to resetup VM, but yet.
From my personal experience and some opinions by others, even here on HN, WSL is the mix which provides best of two worlds for a lot of cases.
Mind sharing a bit of info here - what do you mean and what Apple specifically did?
> everyone that only cares about UNIX/POSIX without religious attachment
I've personally helped to start with WSL for several persons, though I cannot say do they care on POSIX and UNIX as a concepts at all.
yaw, didn't know Linux influence is so high on FreeBSD.
though, it may be a good sign - as it sorta base system becoming split in packages, may be on day LTS version FreeBSD will be born and it'll become usable
TIL: "as with broken ABI the drm-kmod related kernel modules just panic and reboot each such system instantly … and this problem persists for whole 3 months...I have spoken about that problem for years"
Indeed, stable and solid system, I wouldn't be part of CorpIT team who needs to support such setups.
> As you’ll read below, this saves us millions of dollars a year and allows us to scale out our ClickHouse Cloud service without having to be concerned about observability costs, or make compromises on the log data we retain.
https://clickhouse.com/blog/building-a-logging-platform-with...
For my team needs, I see benefits of using self-contained tool which doesn't require any extra modules to be installed and venv-like activated (this is a great barrier when ensuring others can use it too). Not even mention it will run fast.
Testing headers is particularly nice, so can test configuration of webservers and LBs/CDNs.
Assuming you know what systemd as init system able to do, I'm not sure what extra information you need for getting list of advantages.
If you going with examples is better for you, i'll mention couple of mine - note that I likely forget some other good samples as it's so natural so I'm may be not realizing it's systemd's feature, just "how things work"
* hardening - syscall filtering, privilege limiting, read/write path filtering, per-unit tmp files. As nice example, I have great peace of mind when I put php-fpm into network isolated to localhost only for IP level
* resource management and resource information at all - observing resource usage by multiple units when needed with a quick way saves my time, in addition to being able to collect such metrics into monitoring. Setting the lowest IO priority for backup scripts and even MB/sec per block device - godsend. Limits on CPU usage or RAM usage where needed ensures smooth operations of the fleet without nasty surprises
* things like quick overview with systemctl --failed, user-level units instead of flacky @reboot in crontab (yeah, we still remember it from eggdrop/psybnc days)
* clear and uniform way to work with services across the team, no hacky bash scripts with saving PIDs
so on.
Probably you do system administration for your servers in some other way that all that goodies are not noticeable for you and your team.
I'd say as someone who started with shell/bash in ~ 2000 to cater Linux systems, it's quote usual syntax and I believe that's true for many sysadmins.
No way I'd like to deal with opaque .Net or even Go stuff - incapable of doing "bash -x script.sh" while debugging production systems at 3AM. And non production as well - just loosing my time (and team time) on unusual syntax, getting familiar with nuget and ensuring internet access for that repos and pinging ITSec guys to open access to that repos.
> let a junior developer tweak something in a script and expect it to go well
let developers do their job, writing bash scripts is something extraordinary for dev team to do, just because - where they expected to apply it? I can imagine "lonely dev startups" situations only, where it may be reasonably needed
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest