I don't think that's the idea; it's more that when you're not beholden to an employer, you can focus on (and take pride in) whichever aspects of the work you want to focus on. When I'm working on my own projects, most of the pride I take in my code is based on what it does -- not on how clean it is, and certainly not on how well organised is the repository it lives in.
Yes, sometimes that makes things harder in the long run, but on the other hand there may not be a long run for this project if I try to force myself to do all the tedious bits 'correctly'. (And 99% of the time what bites me is my sloppy coding practices; it's very rare for much to hinge on the quality of my commit messages.)
Ha! I practice good commit hygiene---even when no one's paying me---because it's useful to my future self, but I don't think pride in one's work (especially through importing workplace best practices) is a great reason, especially not a normative one. I think this is like the proverbial carpenter finishing the back of a drawer though no one will see it. It's done for the carpenter's sake, out of principle or mundane Calvinism, and I wouldn't begrudge a carpenter who didn't. And the latter might sell more furniture.
But yeah, if someone made a cabinet with fancy Japanese joinery that turns out to be inkjet AI-generated veneers over glue and nails... I would not buy it.
If anything it's the opposite, except maybe at the very low end: AI boosts implementation skill (at least by increasing speed), but not {research, coding, writing} taste. Hence slop of all sorts.
XFS doesn't support whole-volume snapshots, which is the main reason I want CoW filesystems. And it also stands out as being basically the only filesystem that you can't arbitrarily shrink without needing to wipe and reformat.
You can shrink XFS, but only the realtime volume. All you need is xfs_db and a steady hand. I once had to pull this off for a shortened test program for a new server platform at Meta. Works great except some of those filesystems did somehow get this weird corruption around used space tracking that xfs_repair couldn't detect... It was mostly fine.
I am not sure what you mean by "whole-volume" snapshots, but I have not noticed any restrictions in the use of the XFS snapshots. As expected, they store a snapshot of the entire file system, which can be restored later.
In many decades of managing computers with all kinds of operating systems and file systems, on a variety of servers and personal computers, I have never had the need to shrink a file system. I cannot imagine how such a need can arise, except perhaps as a consequence of bad planning. There are also many decades since I have deprecated the use of multiple partitions on a storage device, with the exception of bootable devices, which must have a dedicated partition for booting, conforming to the BIOS or UEFI expectations. For anything that was done in the ancient times with multiple partitions there are better alternatives now. With the exception of bootable USB sticks with live Linux or FreeBSD partitions, I use XFS on whole SSDs or HDDs (i.e. unpartitioned), regardless if they are internal or external, so there is never any need for changing the size of the file system.
Even so, copying a file system to an external device, reformatting the device and copying the file system back is not likely to be significantly slower than shrinking in place. In fact sometimes it can be faster and it has the additional benefit that the new copy of the file system will be defragmented.
Much more significant than the lack of shrinking ability, which may slow down a little something that occurs very seldom, is that both EXT4 and XFS are much faster for most applications than the other file systems available for Linux, so they are fast for the frequent operations. You may choose another file system for other reasons, but choosing it for making faster a very rare operation like shrinking is a very weak reason.
I definitely met several cases where support for shrinking would be beneficial - usually something about migrations and things like that, but yet I agree it's quite rare operation. Benefits come with lower amount of downtime window and/or expenses in time and duplicating systems.
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.
I do not see the connection between shrinking and migrations.
In migrations you normally copy the file system elsewhere, to the cloud or to different computers, you do not shrink it in place, which is what XFS cannot do. Unlike with Windows, copying Linux file systems, including XFS, during migrations to different hardware is trivial and fast. The same is true for multiplicating a file system to a big set of computers.
Shrinking in place is normally needed only when you share a physical device between 2 different operating systems, which use incompatible file systems, e.g. Windows and Linux, and you discover that you did not partition well the physical device and you want to shrink the partition allocated for one of the operating systems, in order to be able to expand the partition allocated for the other operating system.
Sharing physical devices between Windows and any other operating systems comes with a lot of risks and disadvantages, so I strongly recommend against it. I have stopped sharing Windows disks decades ago. Now, if I want to use the same computer in Windows and in another operating system, e.g. Linux or FreeBSD, I install Windows on the internal SSD, and, when desired, I boot Linux or FreeBSD from an external SSD. Thus the problem of reallocating a shared SSD/HDD by shrinking a partition never arises.
> Now, if I want to use the same computer in Windows and in another operating system, e.g. Linux or FreeBSD, I install Windows on the internal SSD
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.
There are advantages to having the filesystem do the snapshots itself. For example, if you have a really big file that you keep deleting and restoring from a snapshot, you'll only pay the cost of the space once with Btrfs, but will pay it every time over with LVM.
On some of my zfs servers, the number of snapshots (mostly periodic, rotated — hour, day, month, updates, data maintenance work) is 10-12 thousand.
LVM can't do that.
Thanks--you just saved me an hour or two of debugging. I thought, CONFIG_DEVTMPFS_MOUNT=y, what more do I need to do? I should've just RTFM though: even an unpatched kernel mentions this in the help for that config option.
Right, they should just post the 0days on their blog.