6 ms·

I find it really arrogant to claim "this software does everything I need, so it should never change", while in reality you are but an infinitesimally small part

by nialv7 6y ago

I find it really arrogant to claim "this software does everything I need, so it should never change", while in reality you are but an infinitesimally small part of the user base said software has to support. Sure, all the software can stay where they are if all the developers had to serve is you. But that is just not the reality.

1_player 6y ago
Especially in the Linux world where not asking too much of their own PC is seen as a virtue, so people are running tiling WMs from the nineties, spend their time in Emacs and say everything is fine. Meanwhile I want my Linux system to run VR, multiple 4K displays, very demanding games and bluetooth headphones. And Linux is the worst for it, because everything feels laggy and half polished there and on the proprietary OS my setup feels MUCH faster. Sure, it's not Linux's fault, but let's stop saying everything is fine and dandy because Emacs is still running.
- wegs 6y ago
  No one is saying everything is fine. It's not. What we're arguing is why everything is not fine. SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for. My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt. I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.
  - anthk 6y ago
    > think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware They did, modular kernels date back as 2.2 at least. And USB was born in that era.
    - wegs 6y ago
      If this was anticipated by the architecture: * My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac. * My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too. * I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in. * The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable. .. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back. Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
      - sergeykish 6y ago
        You've described need for UUID but then discard it for disks, why? $ ls /dev/disk/by-uuid/ 266c945c-1c6d-40e7-b770-73864a5541fa $ cat /etc/fstab UUID=266c945c-1c6d-40e7-b770-73864a5541fa /
        wegs 6y ago
        Mostly, because as of 2020, most things don't use UUIDs. See e.g. 1) https://www.raspberrypi.org/documentation/installation/installing-images/linux.md https://www.raspberrypi.org/documentation/installation/insta... 2) man fdisk 3) man mkfs And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical. It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.
wegs 6y ago
There isn't a magical different userbase Linux has to serve which has somehow bizarre needs not served by thoughtfully-designed older software, but which newer, poorly-designed software somehow meets. Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline. Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI. At the end of the day: 1) Everything is slow, requiring literally more than 100x the resources it once did. 2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below." 3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too. Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer. As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.
- sergeykish 6y ago
  Maybe you should fine community that shares your views. I don't use pulseaudio, networkmanager, desktop environment, works perfectly in Arch Linux [1]. Arch has great wiki, it is correct. System is quite transparent. I am fine with systemd but, for example, Void Linux [2] uses runit, Alpine Linux [3] uses OpenRC and is compiled statically. Arch Linux pacman serves my needs perfectly, it is quick, it shows only relevant information. AUR provides ready made PKGBUILDs. Lots of Linux distributions is its strength. It allows people with niche requirements find its home. We are far better members of societies when supporting our system than grunting. [1] https://www.archlinux.org/ https://www.archlinux.org/ [2] https://voidlinux.org/ https://voidlinux.org/ [3] https://alpinelinux.org/ https://alpinelinux.org/

by nialv7 6y ago

1_player 6y ago

Especially in the Linux world where not asking too much of their own PC is seen as a virtue, so people are running tiling WMs from the nineties, spend their time in Emacs and say everything is fine. Meanwhile I want my Linux system to run VR, multiple 4K displays, very demanding games and bluetooth headphones. And Linux is the worst for it, because everything feels laggy and half polished there and on the proprietary OS my setup feels MUCH faster. Sure, it's not Linux's fault, but let's stop saying everything is fine and dandy because Emacs is still running.

wegs 6y ago
No one is saying everything is fine. It's not. What we're arguing is why everything is not fine. SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for. My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt. I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.
- anthk 6y ago
  > think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware They did, modular kernels date back as 2.2 at least. And USB was born in that era.
  - wegs 6y ago
    If this was anticipated by the architecture: * My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac. * My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too. * I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in. * The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable. .. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back. Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
    - sergeykish 6y ago
      You've described need for UUID but then discard it for disks, why? $ ls /dev/disk/by-uuid/ 266c945c-1c6d-40e7-b770-73864a5541fa $ cat /etc/fstab UUID=266c945c-1c6d-40e7-b770-73864a5541fa /
      - wegs 6y ago
        Mostly, because as of 2020, most things don't use UUIDs. See e.g. 1) https://www.raspberrypi.org/documentation/installation/installing-images/linux.md https://www.raspberrypi.org/documentation/installation/insta... 2) man fdisk 3) man mkfs And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical. It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.

wegs 6y ago

There isn't a magical different userbase Linux has to serve which has somehow bizarre needs not served by thoughtfully-designed older software, but which newer, poorly-designed software somehow meets. Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline. Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI. At the end of the day: 1) Everything is slow, requiring literally more than 100x the resources it once did. 2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below." 3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too. Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer. As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.

sergeykish 6y ago
Maybe you should fine community that shares your views. I don't use pulseaudio, networkmanager, desktop environment, works perfectly in Arch Linux [1]. Arch has great wiki, it is correct. System is quite transparent. I am fine with systemd but, for example, Void Linux [2] uses runit, Alpine Linux [3] uses OpenRC and is compiled statically. Arch Linux pacman serves my needs perfectly, it is quick, it shows only relevant information. AUR provides ready made PKGBUILDs. Lots of Linux distributions is its strength. It allows people with niche requirements find its home. We are far better members of societies when supporting our system than grunting. [1] https://www.archlinux.org/ https://www.archlinux.org/ [2] https://voidlinux.org/ https://voidlinux.org/ [3] https://alpinelinux.org/ https://alpinelinux.org/