4 ms·

As a long time user of utils-linux, I can say this: purge! We need a big, big, huge purge of this ancient decrepit nonsense. We don't need blkid, lsblk, fdisk

As a long time user of utils-linux, I can say this: purge! We need a big, big, huge purge of this ancient decrepit nonsense. We don't need blkid, lsblk, fdisk, wipefs, parted, df and a bunch of other lopsided semi-functional horrors to ask questions about storage. Just one program that works. We need integration of MD, DM, LVM and possibly stuff like Btrfs volumes. ZFS was close to it. And commands associated with these utilities need to make sense in the way they are named and associated with each other. The way it needs to work is something like: $ storage volume-manager physical-volumes list (This doesn't mean you have to type it out in full, useful abbreviations would still apply, but there must be a way to spell it out so that non-initiated may understand the purpose and the reason of the "spell") Instead of guessing whether you should run pvdisplay or btrfs subvolume list Networking seemed like it went in this direction sometime ago with iproute2, but it's still not enough. Stuff like nmcli or all kinds of nslookup, ss and so on need to be brought under one roof, generic enough to allow extensions and implementations by different concrete programs. Today, just in order to find the configuration of one's network interfaces one must scout different places on their filesystem and try to figure out what utility is reading those and whether it's able to understand the config, and whether there's any other config in some other place that overrides the one they are looking at.

eternityforest 4y ago
The more time goes on the more I start thinking a clean wipe of the entire thing might be in order. Linux is great and all, but it's so full of old crap. It's getting better, but all the old crap still just sticks around fragmenting everything, and there's still no container system that can match APKs, because there's no API level to build to, every system is different, and everyone tries to support 50 different configurations. Nmcli would be part of the OS itself if this were android or windows, and there wouldn't be ConMan and others unless you fork the whole OS or use some plugin API.
- sseagull 4y ago
  But developing the new stuff doesn’t make the old stuff go away; there’s a huge userbase with trillions of lines of scripts and stuff to support. It’s thinking like this that led to the fragmentation in the first place.
  - dsr_ 4y ago
    Right. A new project can: - get changes into the kernel, and all newly installed systems after some point maybe three years from now will have them, probably - get changes into the core requirements of a distro, and get newly installed and upgraded systems to have the feature in a couple of years, but only that distro. If the changes are too obnoxious, some organizations won't upgrade and some will leave for another distro - make an implementation so attractive that lots of distros will include it either by default or as an option. Nothing will get the project traction on systems that are not upgraded, regardless of the reason being can't or won't. And as long as people have a high expectation of working on those systems, the replacement will be another thing people have to remember.
    - eternityforest 4y ago
      Windows has lots of old systems, but they just continue to run the old systems for a few years, and then 20 more years after support ends. It's a lot easier to maintain old versions when there are fewer of them and they are all corporate backed. One team can keep a version going. But with Linux there are thousands of versions, arguably millions because it encourages customization even beyond just choosing a distro. With Windows, Android, and just about any other commercial style thing, there are versions that come out once per year or so, with either no forks, or forks that promptly get ignored and forgotten, or very minor customizations that don't really add or remove anything beyond the wallpaper and launcher. And they generally preserve backwards compatibility better than Linux, because the stack can just be application+bundled libraries -> OS stuff fully controlled by OS vendor. There's no systems made of small pieces meant to be interchanged by the installer, any one of which could stop working on a new system, all by different teams, you know your GUI toolkit works on the new OS version because it ships with the new OS version. There are no other distros, because even when they are possible, like with AOSP, there's no culture of tinkering, people just take what they get, which both prevents fragmentation, and on the other side, gives the developers a reason not to make migration too hard, because they are trying to make one distro for all, not just a distro for their 10% of users. Ubuntu does a good job of trying to be "The standard Linux", but things still change and break between versions far more than on Android.
  - 4y ago
ilyt 4y ago
The problem is that it would need to be near perfect or else you're ending up with another kludged-in mess like networkmanager. I'll take my one-tool-does-one-thing-well over that anytime
- crabbone 4y ago
  The problem is that currently Unix (well, Linux) doesn't have tools that do one thing right. They are too small and too overwhelmed by the problems they need to solve. And this gets worse the more generic a tool you want to make, because, inevitably, you will have to account for the lower-level tools that your tool has to use. Let's, again, take storage as an example. So, you want to write a program that shows users what block devices are currently available to them. Seems conceptually simple and potentially very useful. And, right off the bet you hit complexity: do loop devices count? Do separate partitions count, and if so, what to do about special partitions that keep data necessary for hardware RAIDs to function, that, in general, shouldn't be exposed to users)? How do you go about RAID devices, do you acknowledge that RAIDs exist and display them as separate entities, or do you pretend they don't and only display their constituents? How about physical and logical volumes? Do you think that you need to support ZFS volumes? What if some FUSE filesystem decides to expose some information as a device file, does that count as a block device? What about iSCSI (potentially with multipathing)? Encrypted devices? And there are more... there's archaic NBD alongside with the blazing hot NVMe over IP and so on. And you don't really have any unifying interfaces. You can look into /sys/block, but depending on how you answered the questions above, you'll either find too little or too much info there. And there's not a single tool that can really, in all circumstances, give you a correct answer to the question "what block devices are currently available". Unix started with a bunch of simplified assumptions and sloppy (if any) planning. It's OK for computers with predictable and not very diverse hardware configuration. But, because Linux is free (as in beer) enterprise sector decided to capitalize on this freedom. They no longer needed to develop the platform to run their stuff on. They took a tool that was supposed to enable individual users and small businesses to take ownership of their hardware and turned it into a money printing machine. And they keep using it w/o major investments as long as they can make profits. It means that it sucks to be a system / infra guy (not financially, but in terms of what you have to work with), because your stuff is broken and will never get better, since the business decided that they'd rather run their stuff on a toy but free (as in beer) system than invest into developing a more grown-up one.
LargoLasskhyfv 4y ago
Ahem. AIX: mk*, ch*, rm*, cp*, ln* almost anything. The BSDs: ifconfig anything. Any Linux? NIH everthing!

eternityforest 4y ago

The more time goes on the more I start thinking a clean wipe of the entire thing might be in order. Linux is great and all, but it's so full of old crap. It's getting better, but all the old crap still just sticks around fragmenting everything, and there's still no container system that can match APKs, because there's no API level to build to, every system is different, and everyone tries to support 50 different configurations. Nmcli would be part of the OS itself if this were android or windows, and there wouldn't be ConMan and others unless you fork the whole OS or use some plugin API.

sseagull 4y ago
But developing the new stuff doesn’t make the old stuff go away; there’s a huge userbase with trillions of lines of scripts and stuff to support. It’s thinking like this that led to the fragmentation in the first place.
- dsr_ 4y ago
  Right. A new project can: - get changes into the kernel, and all newly installed systems after some point maybe three years from now will have them, probably - get changes into the core requirements of a distro, and get newly installed and upgraded systems to have the feature in a couple of years, but only that distro. If the changes are too obnoxious, some organizations won't upgrade and some will leave for another distro - make an implementation so attractive that lots of distros will include it either by default or as an option. Nothing will get the project traction on systems that are not upgraded, regardless of the reason being can't or won't. And as long as people have a high expectation of working on those systems, the replacement will be another thing people have to remember.
  - eternityforest 4y ago
    Windows has lots of old systems, but they just continue to run the old systems for a few years, and then 20 more years after support ends. It's a lot easier to maintain old versions when there are fewer of them and they are all corporate backed. One team can keep a version going. But with Linux there are thousands of versions, arguably millions because it encourages customization even beyond just choosing a distro. With Windows, Android, and just about any other commercial style thing, there are versions that come out once per year or so, with either no forks, or forks that promptly get ignored and forgotten, or very minor customizations that don't really add or remove anything beyond the wallpaper and launcher. And they generally preserve backwards compatibility better than Linux, because the stack can just be application+bundled libraries -> OS stuff fully controlled by OS vendor. There's no systems made of small pieces meant to be interchanged by the installer, any one of which could stop working on a new system, all by different teams, you know your GUI toolkit works on the new OS version because it ships with the new OS version. There are no other distros, because even when they are possible, like with AOSP, there's no culture of tinkering, people just take what they get, which both prevents fragmentation, and on the other side, gives the developers a reason not to make migration too hard, because they are trying to make one distro for all, not just a distro for their 10% of users. Ubuntu does a good job of trying to be "The standard Linux", but things still change and break between versions far more than on Android.
- 4y ago

ilyt 4y ago

The problem is that it would need to be near perfect or else you're ending up with another kludged-in mess like networkmanager. I'll take my one-tool-does-one-thing-well over that anytime

crabbone 4y ago
The problem is that currently Unix (well, Linux) doesn't have tools that do one thing right. They are too small and too overwhelmed by the problems they need to solve. And this gets worse the more generic a tool you want to make, because, inevitably, you will have to account for the lower-level tools that your tool has to use. Let's, again, take storage as an example. So, you want to write a program that shows users what block devices are currently available to them. Seems conceptually simple and potentially very useful. And, right off the bet you hit complexity: do loop devices count? Do separate partitions count, and if so, what to do about special partitions that keep data necessary for hardware RAIDs to function, that, in general, shouldn't be exposed to users)? How do you go about RAID devices, do you acknowledge that RAIDs exist and display them as separate entities, or do you pretend they don't and only display their constituents? How about physical and logical volumes? Do you think that you need to support ZFS volumes? What if some FUSE filesystem decides to expose some information as a device file, does that count as a block device? What about iSCSI (potentially with multipathing)? Encrypted devices? And there are more... there's archaic NBD alongside with the blazing hot NVMe over IP and so on. And you don't really have any unifying interfaces. You can look into /sys/block, but depending on how you answered the questions above, you'll either find too little or too much info there. And there's not a single tool that can really, in all circumstances, give you a correct answer to the question "what block devices are currently available". Unix started with a bunch of simplified assumptions and sloppy (if any) planning. It's OK for computers with predictable and not very diverse hardware configuration. But, because Linux is free (as in beer) enterprise sector decided to capitalize on this freedom. They no longer needed to develop the platform to run their stuff on. They took a tool that was supposed to enable individual users and small businesses to take ownership of their hardware and turned it into a money printing machine. And they keep using it w/o major investments as long as they can make profits. It means that it sucks to be a system / infra guy (not financially, but in terms of what you have to work with), because your stuff is broken and will never get better, since the business decided that they'd rather run their stuff on a toy but free (as in beer) system than invest into developing a more grown-up one.

LargoLasskhyfv 4y ago

Ahem. AIX: mk*, ch*, rm*, cp*, ln* almost anything. The BSDs: ifconfig anything. Any Linux? NIH everthing!