5 ms·

Linux has turned haphazardry into a strength. This is impressive. I prefer FreeBSD.

by quesera 11mo ago

actionfromafar 11mo ago
I like the haphazardry but I think systemd veered too far into dadaism.
- arthurfirst 11mo ago
  THIS. As bad as launchctl on Macs. Solution looking for a problem so it causes more problems -- like IPv6
  - dralley 11mo ago
    You can't be serious thinking that IPv4 doesn't have problems
    - arthurfirst 11mo ago
      Of course not. But IPv6 is not the solution to Ipv4's issues at all. IPv6 is something completely different justified post-facto with EMOTIONAL arguments ie. You are stealing the last IPv4 address from the children! - Dual stack -- unnecessary and bloated - Performance = 4x worse or more - No NAT or private networks -- not in the same sense. People love to hate on NAT but I do not want my toaster on the internet with a unique hardware serial number. - Hardware tracking built into the protocol -- the mitigations offered are BS. - Addresses are a congintive block - Forces people to use DNS (central) which acts as a censorship choke point. All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc I actually wrote a code project that implements this network as an overlay -- but it's not ready to share yet. Works though. If I were to imagine my self in the room deciding on the IPv6 requirements I expect the key one was 'track every person and every device every where all the time' because if you are just trying to expand the address space then IPv6 is way way way overkill -- it's overkill even for future proofing for the next 1000 years of all that privacy invading.
      - bluGill 11mo ago
        > All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc That is what we have in ipv6. What you write sounds good/easy on paper, but when you look at how networks are really implemented you realize it is impossible to do that. Networks packets have to obey the laws of bits and bytes and there isn't any place to put that extra 0 in ipv4: no matter what you have to create a new ipv6. They did write a standard for how to send ipv4 addresses in ipv6, but anyone who doesn't have ipv6 themselves can't use that and so we must dual stack until everyone transitions.
        deleted 11mo ago
        [deleted]
        arthurfirst 11mo ago
        Actually there is a place to put it... I didn't want to get into this but since you asked: My prototype/thought experiment is called IPv40 a 40bit extension to IPv4. IPv40 addresses are carried over Legacy networks using the IPv4 Options Field (Type 35) Legacy routers ignore Option 35 and route based on the 32-bit destination (effectively forcing traffic to "Space 0". IPv40-aware routers parse Option 35 to switch Universes. This works right now but as a software overlay not in hardware. Just my programming/thought experiment which was pretty fun. When solutions are pushed top down like IPv6 my spider sense tingles -- what problem is it solving? the answers are NOT 'to address address space limitations of IPv4' that is the marketing and if you challenge it you will be met with ad hominen attacks and emotional manipulations.
        bluGill 11mo ago
        You didn't save anything as everyone needs to know the new extension before anyone can use it. Hardware is important - fast routers can't do work in the CPU (and it was even worse in the mid 90's when this started), they need special hardware assistance.
        11mo ago
  - Someone 11mo ago
    > Solution looking for a problem Two clear problems with the init system (https://en.wikipedia.org/wiki/Init https://en.wikipedia.org/wiki/Init) are - it doesn’t handle parallel startup of services (sysadmins can tweak their init scripts to speed up booting, but init doesn’t provide any assistance) - it does not work in a world where devices get attached to and detached from computers all the time (think of USB and Bluetooth devices, WiFi networks). The second problem was evolutionary solved in init systems by having multiple daemons doing, basically, the same thing: listen for device attachments/detachments, and handling them. Unifying that in a single daemon, IMO, is a good thing. If you accept that, making that single daemon the init process makes sense, too, as it will give you a solution for the first problem.
    - actionfromafar 11mo ago
      Yes, ”a solution”. We need a thing. Systemd is a thing. Therefore, we need systemd.
      - hylaride 11mo ago
        Not to get into a flame war, but 99% of my issues with systemd is that they didn't just replace init, but NTP, DHCP, logging (this one is arguably necessary, but they made it complicated, especially if you want to send logs to a centralized remote location or use another utility to view logs), etc. It broke the fundamental historical concept of unix: do one thing very well. To make things worse, the opinionated nature of systemd's founder (Lennart Poettering) has meant many a sysadmin has had to fight with it in real-world usage (eg systemd-timesyncd's SNTP client not handling drift very well or systemd-networkd not handling real world DHCP fields). His responses "Don't use a computer with a clock that drifts" or "we're not supporting a non-standard field that the majority of DHCP servers use" just don't jive in the real world. The result was going to be ugly. It's not surprising that most distros ended up bundling chrony, etc.
        pezezin 11mo ago
        > (this one is arguably necessary, but they made it complicated, especially if you want to send logs to a centralized remote location or use another utility to view logs) It is not complicated at all. Recent enough versions of systemd support journal forwarding, but even without it, configuring rsyslog is extremely easy: 1. Install rsyslog 2. Create a file /etc/rsyslog.d/forwarding.conf $ActionForwardDefaultTemplate RSYSLOG_ForwardFormat *.* @@${your-syslog-server-here}:514 3. Restart rsyslog 4. Profit.
- helterskelter 11mo ago
  C'mon that just rude to Dada.

Linux has turned haphazardry into a strength. This is impressive. I prefer FreeBSD.

by quesera 11mo ago

Linux has turned haphazardry into a strength. This is impressive. I prefer FreeBSD.

actionfromafar 11mo ago

I like the haphazardry but I think systemd veered too far into dadaism.

arthurfirst 11mo ago
THIS. As bad as launchctl on Macs. Solution looking for a problem so it causes more problems -- like IPv6
- dralley 11mo ago
  You can't be serious thinking that IPv4 doesn't have problems
  - arthurfirst 11mo ago
    Of course not. But IPv6 is not the solution to Ipv4's issues at all. IPv6 is something completely different justified post-facto with EMOTIONAL arguments ie. You are stealing the last IPv4 address from the children! - Dual stack -- unnecessary and bloated - Performance = 4x worse or more - No NAT or private networks -- not in the same sense. People love to hate on NAT but I do not want my toaster on the internet with a unique hardware serial number. - Hardware tracking built into the protocol -- the mitigations offered are BS. - Addresses are a congintive block - Forces people to use DNS (central) which acts as a censorship choke point. All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc I actually wrote a code project that implements this network as an overlay -- but it's not ready to share yet. Works though. If I were to imagine my self in the room deciding on the IPv6 requirements I expect the key one was 'track every person and every device every where all the time' because if you are just trying to expand the address space then IPv6 is way way way overkill -- it's overkill even for future proofing for the next 1000 years of all that privacy invading.
    - bluGill 11mo ago
      > All we needed was an extra pre space to set WHICH address space - ie. '0' is the old internet in 0.0.0.0.10 --- backwards compatible, not dual stack, no privacy nightmare, etc That is what we have in ipv6. What you write sounds good/easy on paper, but when you look at how networks are really implemented you realize it is impossible to do that. Networks packets have to obey the laws of bits and bytes and there isn't any place to put that extra 0 in ipv4: no matter what you have to create a new ipv6. They did write a standard for how to send ipv4 addresses in ipv6, but anyone who doesn't have ipv6 themselves can't use that and so we must dual stack until everyone transitions.
      - deleted 11mo ago
        [deleted]
      - arthurfirst 11mo ago
        Actually there is a place to put it... I didn't want to get into this but since you asked: My prototype/thought experiment is called IPv40 a 40bit extension to IPv4. IPv40 addresses are carried over Legacy networks using the IPv4 Options Field (Type 35) Legacy routers ignore Option 35 and route based on the 32-bit destination (effectively forcing traffic to "Space 0". IPv40-aware routers parse Option 35 to switch Universes. This works right now but as a software overlay not in hardware. Just my programming/thought experiment which was pretty fun. When solutions are pushed top down like IPv6 my spider sense tingles -- what problem is it solving? the answers are NOT 'to address address space limitations of IPv4' that is the marketing and if you challenge it you will be met with ad hominen attacks and emotional manipulations.
        bluGill 11mo ago
        You didn't save anything as everyone needs to know the new extension before anyone can use it. Hardware is important - fast routers can't do work in the CPU (and it was even worse in the mid 90's when this started), they need special hardware assistance.
        11mo ago
- Someone 11mo ago
  > Solution looking for a problem Two clear problems with the init system (https://en.wikipedia.org/wiki/Init https://en.wikipedia.org/wiki/Init) are - it doesn’t handle parallel startup of services (sysadmins can tweak their init scripts to speed up booting, but init doesn’t provide any assistance) - it does not work in a world where devices get attached to and detached from computers all the time (think of USB and Bluetooth devices, WiFi networks). The second problem was evolutionary solved in init systems by having multiple daemons doing, basically, the same thing: listen for device attachments/detachments, and handling them. Unifying that in a single daemon, IMO, is a good thing. If you accept that, making that single daemon the init process makes sense, too, as it will give you a solution for the first problem.
  - actionfromafar 11mo ago
    Yes, ”a solution”. We need a thing. Systemd is a thing. Therefore, we need systemd.
    - hylaride 11mo ago
      Not to get into a flame war, but 99% of my issues with systemd is that they didn't just replace init, but NTP, DHCP, logging (this one is arguably necessary, but they made it complicated, especially if you want to send logs to a centralized remote location or use another utility to view logs), etc. It broke the fundamental historical concept of unix: do one thing very well. To make things worse, the opinionated nature of systemd's founder (Lennart Poettering) has meant many a sysadmin has had to fight with it in real-world usage (eg systemd-timesyncd's SNTP client not handling drift very well or systemd-networkd not handling real world DHCP fields). His responses "Don't use a computer with a clock that drifts" or "we're not supporting a non-standard field that the majority of DHCP servers use" just don't jive in the real world. The result was going to be ugly. It's not surprising that most distros ended up bundling chrony, etc.
      - pezezin 11mo ago
        > (this one is arguably necessary, but they made it complicated, especially if you want to send logs to a centralized remote location or use another utility to view logs) It is not complicated at all. Recent enough versions of systemd support journal forwarding, but even without it, configuring rsyslog is extremely easy: 1. Install rsyslog 2. Create a file /etc/rsyslog.d/forwarding.conf $ActionForwardDefaultTemplate RSYSLOG_ForwardFormat *.* @@${your-syslog-server-here}:514 3. Restart rsyslog 4. Profit.
helterskelter 11mo ago
C'mon that just rude to Dada.