3 ms·

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 t

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.

ilyt 4y ago
> 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? I think PowerShell had right idea here, even if it maybe went too hard into "object oriented". If tools had option to pass structured representation between eachother the above problem could be solved by tool that returns everything + set of generic tools to filter information, like say lsblk | f(type=disk,bus=nvme,name != nvme0n1) # all physical nvme devices except nvme0n1 lsblk | f(type=lvm_lv,vg=data,mountpoint =~ {^/data} ) # any LVM LV that is in data VG and mounted under /data I wonder if it would be possible to retrofit into existing design. Like, have additional filedescriptors and some way of signalling so shell can connect "structured out" with "structured in" of the next app in the pipe. > 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". I'd be interested in which case lsblk is not showing block devices, so far it has been pretty bulletproof for me, even in extremely weird setups
- crabbone 4y ago
  Microsoft isn't at the place yet where they may possibly have this problem. They aren't making an operating system that's extendable by others, that needs to incorporate interests of others. Where anyone may come and take any part of the system and repurpose it to their need. They have the luxury of not having to coordinate with others. This takes away from the usefulness of their product (eg. I see no value for myself in using such an operating system), but it makes it easier in engineering terms to make one. So, PowerShell doesn't solve the problem. It didn't have one from the start. But, it also has nothing to offer to the Linux world as a consequence. The problem we have in the Linux world is more of a people problem before it's an engineering problem. We need an authoritative body that can mediate the interests of many parties using the system, incorporate their wishes and workflows, and then design a generic and extensible way of using the system. Right now it's chaos and anarchy which hinder or prevent the creation of useful programs. PowerShell would only increase the entropy of the system. > I'd be interested in which case lsblk is not showing block devices What about device files in a FUSE system randomly mounted somewhere? Also, I don't know of any way of showing loop devices with lsblk. Also, lsblk doesn't show RAIDs as individual devices, it shows them piece-wise. Also, I'm not sure about how it integrates (if at all) with ZFS block devices (I think it does on FreeBSD though). From what I understand, lsblk will only show a (large) subset of what may be found in sysfs. If it's not there, it's not a block device from its standpoint.

ilyt 4y ago

> 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? I think PowerShell had right idea here, even if it maybe went too hard into "object oriented". If tools had option to pass structured representation between eachother the above problem could be solved by tool that returns everything + set of generic tools to filter information, like say lsblk | f(type=disk,bus=nvme,name != nvme0n1) # all physical nvme devices except nvme0n1 lsblk | f(type=lvm_lv,vg=data,mountpoint =~ {^/data} ) # any LVM LV that is in data VG and mounted under /data I wonder if it would be possible to retrofit into existing design. Like, have additional filedescriptors and some way of signalling so shell can connect "structured out" with "structured in" of the next app in the pipe. > 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". I'd be interested in which case lsblk is not showing block devices, so far it has been pretty bulletproof for me, even in extremely weird setups

crabbone 4y ago
Microsoft isn't at the place yet where they may possibly have this problem. They aren't making an operating system that's extendable by others, that needs to incorporate interests of others. Where anyone may come and take any part of the system and repurpose it to their need. They have the luxury of not having to coordinate with others. This takes away from the usefulness of their product (eg. I see no value for myself in using such an operating system), but it makes it easier in engineering terms to make one. So, PowerShell doesn't solve the problem. It didn't have one from the start. But, it also has nothing to offer to the Linux world as a consequence. The problem we have in the Linux world is more of a people problem before it's an engineering problem. We need an authoritative body that can mediate the interests of many parties using the system, incorporate their wishes and workflows, and then design a generic and extensible way of using the system. Right now it's chaos and anarchy which hinder or prevent the creation of useful programs. PowerShell would only increase the entropy of the system. > I'd be interested in which case lsblk is not showing block devices What about device files in a FUSE system randomly mounted somewhere? Also, I don't know of any way of showing loop devices with lsblk. Also, lsblk doesn't show RAIDs as individual devices, it shows them piece-wise. Also, I'm not sure about how it integrates (if at all) with ZFS block devices (I think it does on FreeBSD though). From what I understand, lsblk will only show a (large) subset of what may be found in sysfs. If it's not there, it's not a block device from its standpoint.