4 ms·

The classic tragedy of Linux-on-the-Desktop: trying to gain traction by removing perceived "warts", all the while alienating user and developer communities alik

by _pmf_ 9y ago

The classic tragedy of Linux-on-the-Desktop: trying to gain traction by removing perceived "warts", all the while alienating user and developer communities alike. Result: more cluttered landscape that is even less of a target platform for desktop software.

pdkl95 9y ago
> removing perceived "warts" Unfortunately a lot of people look at large projects full of difficult to understand, ugly, inelegant code and see a pile of spaghetti and warts that is hard to maintain. In many cases - especially mature projects that are widely used - the warts and inelegance are bugfixes, the piles of spaghetti are the compromises needed in complex interdependent systems and the workarounds/patches that handle the messy problems of real life. As Joel Spolsky famously explained[1], a lot of those "warts" are the most valuable part of the software. They represent an incredible amount of programmer time and effort. Throwing them out and starting over sounds nice because the clean, elegant replacement is solving a far simpler problem. The replacement is usually missing features and bugfixes. When you finally update the new version to be an actual full-featured, bug tested and fixed replacement, you've probably re-added most of the messy "warts". [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- rubber_duck 9y ago
  A lot of warts in software come from legacy constraints - both I'm terms of backcompat, and HW/design constraints that are laughably irrelevant - throwing out warts and starting simpler is how you got ZFS for eg.
  - pdkl95 9y ago
    > HW I'm only talking about software. > legacy constraints Those "legacy constraints" are often being used. Backwards compatibility is very important, because throwing out decades of development efforts involving millions of man-hours. Supporting legacy interfaces can be annoying and in some situations it gets in the way of newer features, but it's incredibly rare > ZFS Nothing needed to be thrown out to implement ZFS. More than one software interface can exist at the same time. ZFS development didn't use some of the features used by traditional filesystems, but it's "rampant layering violations" didn't require the removal of UFS, RAID, or older volume management drivers. The fact that it's always been possible to mount ZFS and older UFS disks at the same time should make this obvious.

by _pmf_ 9y ago

pdkl95 9y ago

> removing perceived "warts" Unfortunately a lot of people look at large projects full of difficult to understand, ugly, inelegant code and see a pile of spaghetti and warts that is hard to maintain. In many cases - especially mature projects that are widely used - the warts and inelegance are bugfixes, the piles of spaghetti are the compromises needed in complex interdependent systems and the workarounds/patches that handle the messy problems of real life. As Joel Spolsky famously explained[1], a lot of those "warts" are the most valuable part of the software. They represent an incredible amount of programmer time and effort. Throwing them out and starting over sounds nice because the clean, elegant replacement is solving a far simpler problem. The replacement is usually missing features and bugfixes. When you finally update the new version to be an actual full-featured, bug tested and fixed replacement, you've probably re-added most of the messy "warts". [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

rubber_duck 9y ago
A lot of warts in software come from legacy constraints - both I'm terms of backcompat, and HW/design constraints that are laughably irrelevant - throwing out warts and starting simpler is how you got ZFS for eg.
- pdkl95 9y ago
  > HW I'm only talking about software. > legacy constraints Those "legacy constraints" are often being used. Backwards compatibility is very important, because throwing out decades of development efforts involving millions of man-hours. Supporting legacy interfaces can be annoying and in some situations it gets in the way of newer features, but it's incredibly rare > ZFS Nothing needed to be thrown out to implement ZFS. More than one software interface can exist at the same time. ZFS development didn't use some of the features used by traditional filesystems, but it's "rampant layering violations" didn't require the removal of UFS, RAID, or older volume management drivers. The fact that it's always been possible to mount ZFS and older UFS disks at the same time should make this obvious.