31–40 of 81 posts
Previously : https://news.ycombinator.com/item?id=18741529 https://news.ycombinator.com/item?id=13618378 https://news.ycombinator.com/item?id=13622301
Earlier quoted context omitted.
It's far more generic but also practically useless for an end-user. Really, its only use seems to be for someone who is a remote sysadmin of some sort. You have to stop pretty much everything on the computer, and still go through a reboot. The only difference thing it buys you is being able to stay SSH'd at the cost of wasting so much more time and going through so much more risk and inconvenience. On Windows you'd j…
>It's far more generic but also practically useless for an end-user. Do end-users really mess with partitioning usually (outside of formatting brand new disks I suppose)? I'm not asking rhetorically, I suppose there must be a use case if MS implemented this (tricky) feature but I can't really imagine any of my non-techies friends and relative decide to shrink a partition (actually most of them probably aren't aware o…
More generally, I was trying to approximate "the set of users who aren't solely sysadmins of remote systems". Substitute for it whatever word you see fit.
Earlier quoted context omitted.
I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.
And this is how to shrink a mounted filesystem in Linux when you use btrfs: btrfs filesystem resize 4g / It's just not supported for ext4. You can grow an ext4 file system, even when it is your currently mounted root, just not shrink it. While it's great that NTFS does (now) support it few other file systems do because it's a relatively uncommon and quite risky. I certainly wouldn't shrink mounted filesystems even on…
P.S. I realize an existence proof makes us mathematically happy, but it's a little disingenuous to suggest file system experience on Linux and Windows is comparable merely because of the existence of some uncommon file system with similar capabilities. The reality is most Linux users are on ext4 rather than on btrfs or zfs, and most Windows users are on NTFS rather than ReFS or FAT32, so their experience with shrinking file systems is not going to be remotely comparable.
Earlier quoted context omitted.
And this is how to shrink a mounted filesystem in Linux when you use btrfs: btrfs filesystem resize 4g / It's just not supported for ext4. You can grow an ext4 file system, even when it is your currently mounted root, just not shrink it. While it's great that NTFS does (now) support it few other file systems do because it's a relatively uncommon and quite risky. I certainly wouldn't shrink mounted filesystems even on…
Does that also shrink the partition? Otherwise you're not comparing equivalent things... P.S. I realize an existence proof makes us mathematically happy, but it's a little disingenuous to suggest file system experience on Linux and Windows is comparable merely because of the existence of some uncommon file system with similar capabilities. The reality is most Linux users are on ext4 rather than on btrfs or zfs, and m…
yes, it does.
btfs is already the default in SUSE derivatives. It remains to be seen how the other distributions will handle it within the next ~3 yrs.
its only just become stable enough to be usable in production.
The Stack Overflow answer linked is horrifyingly delightful: https://unix.stackexchange.com/questions/226872/how-to-shrin...
I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.
But about Windows, last year I had to resize the partitions on my work desktop, there are enough restrictions around changing things on the disk that Windows is installed that it became a week long research task for our IT support people.
Earlier quoted context omitted.
I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.
I love that this line sounds like an old sea shanty: for i in dev proc sys run; do mount --move /oldroot/$i /$i; done
Earlier quoted context omitted.
I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.
The "good" Linux answer would be to do the equivalent to your script on parted. I have no idea why an explanation of how to remotely install Linux on a machine while running Linux become the accepted answer. But about Windows, last year I had to resize the partitions on my work desktop, there are enough restrictions around changing things on the disk that Windows is installed that it became a week long research task…
You're suggesting the research phase for partition management is somehow easier on Linux than on Windows?
Earlier quoted context omitted.
>It's far more generic but also practically useless for an end-user. Do end-users really mess with partitioning usually (outside of formatting brand new disks I suppose)? I'm not asking rhetorically, I suppose there must be a use case if MS implemented this (tricky) feature but I can't really imagine any of my non-techies friends and relative decide to shrink a partition (actually most of them probably aren't aware o…
"End-user" is not a synonym for "layman". Are you a developer? Do you work on your laptop? Great, you're an end-user. More generally, I was trying to approximate "the set of users who aren't solely sysadmins of remote systems". Substitute for it whatever word you see fit.
Earlier quoted context omitted.
"End-user" is not a synonym for "layman". Are you a developer? Do you work on your laptop? Great, you're an end-user. More generally, I was trying to approximate "the set of users who aren't solely sysadmins of remote systems". Substitute for it whatever word you see fit.
I fully expect a developer to be able to follow the instructions given in the post then. It's not more complicated than your average framework or build system.
And I never suggested a developer would be incapable of following these. Seems like you got so sidetracked in arguing that you forgot what the discussion was actually about. See my original comment: https://news.ycombinator.com/item?id=19357672
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!