Gnu/Linux Considered Harmful

[borjam]

It seems like most of the heat in this rant is properly directed at the distribution vendors, not at Linux (the kernel) or (most of) gnu utilities.

That's actually the root of all that evil. There is no such thing as a kernel without an OS. An operating system is a tightly coupled and trusted set of components which you can usually divide into kernel and userland tools, you can split userland tools into administration, development and user commands, and so on.

The mere concept of Linux not existing as a proper OS but just "a kernel" is stupid.  It was acceptable when Linux was the toy of its author but it stopped being being funny long ago.

Who is the architect? Linus Thorvalds? He just maintains a kernel. The distribution packagers who probably don't have much clue on OS architecture?

I have met plenty of Linux "users" who couldn't actually use their computer for anything meaningful. It was a sort of bonsai in which they were constantly updating packages and marveling at the fact that it worked. But to browse the web they went Windows

And that constant bonsai pruning is one of the consequences of that of proper, architect oversight.

Sorry about the rants, I could go for hours.

(Stupid typos edited)

[digsys]

I find this thread to be one of the most informative, objective and considerate that I've read for a while ... considering the subject .... almost as if I've strayed
into another universe :-)

[bd139]

LOL that's even worse. Three words: Network Location Awareness.

[KE5FX]

I am sure most Linux users will not fully understand the relevance of this example and they will dismiss it as the complaints of a fastidious BSD idiot fanboy.

The idea that a user should have to dig into the intricacies of Ethernet duplex connectivity in order to use their system is deeply pathological.  Say what you will about Windows, but when I want to set up a system, I just plug the Cat5 cable into the jack in the back of the PC, and it just works. 

Of course, Microsoft is working day and night to 'fix' that state of affairs, I'm sure.

[borjam]

I am sure most Linux users will not fully understand the relevance of this example and they will dismiss it as the complaints of a fastidious BSD idiot fanboy.

Meanwhile, in Windows, I just plug the Cat5 cable into the jack in the back of the PC, and it just works. 

Yeah. Which was the first version that didn't require a reboot because you changed the IP address?

[KE5FX]

I am sure most Linux users will not fully understand the relevance of this example and they will dismiss it as the complaints of a fastidious BSD idiot fanboy.

Meanwhile, in Windows, I just plug the Cat5 cable into the jack in the back of the PC, and it just works. 

Yeah. Which was the first version that didn't require a reboot because you changed the IP address?

No version of Windows I have ever used, starting with Windows 95, has ever required that.

There were a lot of third-party Winsock providers in those days, but I was always able to use the components that shipped with the OS. 

And rebooting is a heck of a lot easier to deal with than... whatever all that other stuff you were talking about was.

[borjam]

The idea that a user should have to dig into the intricacies of Ethernet duplex connectivity in order to use their system is deeply pathological.  Say what you will about Windows, but when I want to set up a system, I just plug the Cat5 cable into the jack in the back of the PC, and it just works. 

Yes. Of course. Tell me that when in the 90's I spent a weekend replacing the network of a whole hospital. Peecees running Windows, most not negotiating properly.

In that case it wasn't Microsoft's fault per se. Networking manufacturers made a whole mess. Even big names like Cisco and 3Com.

So, faced with a real and present problem you can:

- Ignore it (Microsoft or the early Linux camp before ethtool)

- Implement a bad and incomplete solution (Linux)

- Do it properly (FreeBSD).

At a time I had a really surreal situation with Cisco hardware. Not talking about Linksys but a Cisco 7200 VXR router and Cisco Catalyst switch. The router connected to the switch, it negotiated 100 Mbps full duplex properly only to have the process responsible for CDP (Cisco Discovery Protocol) decide that the interface had to be reconfigured in half duplex because of some stupid crap.

Shit happens, face it. The best designs help you sort it out properly. And the best designs reflect their state in a meaningful and accurate way.

[borjam]

No version of Windows I have ever used, starting with Windows 95, has ever required that.

I haven't worked on Windows, but I recall an astonished customer when I was changing the IP addresses of a large factory and I just configured two IP addresses on the network interface of my laptop (running FreeBSD). He was scared of the change because he pictured like 30 reboots of it.

Now, seems they fixed that stupid issue in 2000.

https://www.itprotoday.com/windows-78/when-does-windows-2000-need-rebooting

In Windows 2000 they still required a reboot if you changed the IP address of the DNS server, turns out.

In 1990 I didn't need to reboot a Unix system because of any of those. Not even Linux when it arrived.

[bd139]

Sometimes it's quite usual to have to bounce a windows box after network changes because NLA fecks up.

Typically we've seen private networks suddenly go public if a teaming config fails at which point the firewall clams up and you have to hit the ILO interface to fix the box.

NLA = network mr clippy. "it looks like you're doing something useful. I have dropped all routes for you!" 

[Marco]

Just make. All you need is make. And a clue stick.

And a tiny bit of time to edit it when you want to compile it on a system which evolved over time and which you aren't allowed to beat into shape with your clue stick. Unless you suggest replacing autoconf with ad-hoc scripts called from the makefile which does the same kind of autoconfiguration. When it works ./configure make make install is very nice, when the build process fails on a large project with a page full of dependencies with a large range of supported versions you're up shit creek regardless.

These large projects need to optimize for the common case where you can automate/hide the complexity of configuration of the build process, they need something like autoconf. If it makes life harder when it does fail, well sucks to be you.

[vtwin@cox.net]

Now I recall another unfunny anecdote. Setting a fixed IP address on a Raspberry Pi running Raspbian. Someone decided it should run DHCP always and to use a config file name with such an intuitive name as d-h-c-p-c-d.conf. Wow. As it happened I was setting up a couple of Raspberries shortly after this came out and doing a Google search for the right way to do it was so fun.

Oh man, this hits close to home.

Generally I like working with Linux. I've been using Linux since about 96 w/ Redhat version 4 or 5. Before that I did a lot of AIX work. I ran an SCO XENIX UUCP Usenet site for years for people to access -- late 80's -- (I can remember paying something like $1500 for 4MB of RAM for a memory upgrade for the machine! OUCH!) Then on to SCO UNIX. I ran a SCO software repository for a while, and authored articles for SCO World Magazine. I lost touch w/ SCO around OpenServer 5, I had moved on to Linux as a more cost-effective solution for customers. Today, I manage a Rocks-based HPCC all built on Linux at work. I have a linux-based NUC at my house I use as my internet router. And so on.

But I definitely can relate to your rant. For instance, on CentOS 7, why do my /etc/sysconfig/network-script/ifcfg-* files get OVERWRITTEN by dracut with a stock configuration that disables my static IP and forces a DHCP connection, unless I go in to /etc/dracut.conf.d/ and tell it not to.

I stuck a Pi  w/ raspian inside my Generac generator so I could run "genmon". Raspian's a linux distro, right, so how hard can it be to figure out (I'm principally a Centos/RHEL/Fedora guy). All I want to do is assign the Pi a freakin static IP address. I spent HOURS attempting to figure out how to do this. I'm like WTF. Finally I just gave up and reconfigured my DHCP server so I could create a reservation for it. Okay, admittedly I do not do not work with Pis and raspbian, so maybe to the hard-core user it is easy... but still...

My biggest bitch about Windows for years was software designers deciding for me how things should work, rather than letting me configure things the way I need to them. Sure, defaults are fine... but under no circumstances, ever, should you override a user-defined setting. That's just shitty software design. Now I see this type of behavior in Linux distros, which really annoys the piss out of me.

#endrant

[borjam]

I stuck a Pi  w/ raspian inside my Generac generator so I could run "genmon". Raspian's a linux distro, right, so how hard can it be to figure out (I'm principally a Centos/RHEL/Fedora guy). All I want to do is assign the Pi a freakin static IP address. I spent HOURS attempting to figure out how to do this. I'm like WTF. Finally I just gave up and reconfigured my DHCP server so I could create a reservation for it. Okay, admittedly I do not d

Yeah, and when someone asked on a mailing list the answers were like "Why do you want to do that if you can use DHCP?" Instead of answering the bloody question 

[sokoloff]

To be fair, 99.5+% of RPi users do almost certainly want to use DHCP.

The problem is that you (and I) might be that less than 1 in 200 case.

I seem to recall doing it without a ton of aggravation a few years ago when setting up an isolated Asterisk/FreePBX test environment.
https://raspberrypi.stackexchange.com/questions/37920/how-do-i-set-up-networking-wifi-static-ip-address/74428#74428 seems similar to what I did, but I can't be 100% sure as, in my "production" home network, I do in fact use DHCP reservations to assign unchanging IP addresses to fixed infrastructure.

[borjam]

To be fair, 99.5+% of RPi users do almost certainly want to use DHCP.

The problem is that you (and I) might be that less than 1 in 200 case.

Yes, but still pure idiocy. There are many valid for disabling a DHCP client and using static addresses instead. Why make it harder? There is no reason. No benefit. Ah yes, someone answered a "why???" question with a "there are countless opportunities there". For blunder I would add.

I understand changes when there is a good reason. But, gratuitous? Like all that systemd crap and their stellar response to potential security issues.

https://github.com/systemd/systemd/issues/6237

[djacobow]

To be fair, 99.5+% of RPi users do almost certainly want to use DHCP.

The problem is that you (and I) might be that less than 1 in 200 case.

Yes, but still pure idiocy. There are many valid for disabling a DHCP client and using static addresses instead. Why make it harder? There is no reason. No benefit. Ah yes, someone answered a "why???" question with a "there are countless opportunities there". For blunder I would add.

I understand changes when there is a good reason. But, gratuitous? Like all that systemd crap and their stellar response to potential security issues.

https://github.com/systemd/systemd/issues/6237

I built a cluster of RPi's awhile back to use for a demo for schoolchildren. I remember noodling with IP addresses and DHCP. In the end, I found it easier to leave the cluster units' DHCP clients running and run a DHCP server on a multi-homed gateway unit, following an IP assignment policy that I could control in one place. So, I get fixed IP addresses but the cluster units don't know they're getting fixed IP addresses. Even better would be if I could netboot the slave pi's from the master, but I didn't need to get that for for the demo.

Not sure why I told that anecdote, exactly.

[rhb]

Holy Cow!!!!  ROFL

This has become a complete hoot!  I *really* do have a bunch of work I need to get done today, so I'll wait until tonight to read through the thread and comment.

[tooki]

If you do not recognize the allusion in the subject line or know what an allusion is, *please* just skip this.  I don't really have the patience to deal with the rampant ignorance of millenials.  I fully realize that it is not your fault.  You have been conned by an educational system that is only interested in serving the interests of the faculty and staff.  But it is a major impediment to communication.

I fundamentally agree with your post, other than the cheap jab at millennials. Remember that:
a) “Millennials” is a synonym for people who are, as of right now, “adults under age 40”. They’re not kids, and most aren’t even 20-somethings.
b) Most of the ills attributed to Millennials aren’t even true, and the ones that are, are the folly of youth, not any real changes in fundamental perspectives. Boomers forget how uninformed they were when they were the same age!

If you’re surrounded by dumb, ignorant Millennials, that’s an artifact of the specific environment you’re in, not because of any trait of an entire generation.

[grizewald]

Haha. This is typical experience yes. And when Linux is broken, getting it fixed is nigh on impossible even if you pay DeadRat lots of money. And that doesn't even cover the crap you have to deal with on top of it with sytemd-networkd or even worse NetworkManager.

Amen to that. NetworkManager gets more and more broken with each damn release! Not to mention adding dnsmasq and everything else to the mix in an attempt between systemd and NetworkManager to make your network configuration so impenetrably complicated that even someone like me who's been doing various UNIXes and Linuxes for decades has trouble sometimes understanding why the hell I can't do a DNS lookup after coming home from work and connecting to my network at home!

Personally, I think systemd is complication for the sake of it. There was nothing wrong with the Sys V init system and it was simple and transparent.

[djacobow]

Boomers forget how uninformed they were when they were the same age!

"Were?"

[Monkeh]

To be fair, 99.5+% of RPi users do almost certainly want to use DHCP.

The problem is that you (and I) might be that less than 1 in 200 case.

Yes, but still pure idiocy. There are many valid for disabling a DHCP client and using static addresses instead. Why make it harder? There is no reason. No benefit. Ah yes, someone answered a "why???" question with a "there are countless opportunities there". For blunder I would add.

I understand changes when there is a good reason. But, gratuitous? Like all that systemd crap and their stellar response to potential security issues.

https://github.com/systemd/systemd/issues/6237

I built a cluster of RPi's awhile back to use for a demo for schoolchildren. I remember noodling with IP addresses and DHCP. In the end, I found it easier to leave the cluster units' DHCP clients running and run a DHCP server on a multi-homed gateway unit, following an IP assignment policy that I could control in one place. So, I get fixed IP addresses but the cluster units don't know they're getting fixed IP addresses. Even better would be if I could netboot the slave pi's from the master, but I didn't need to get that for for the demo.

Not sure why I told that anecdote, exactly.

Perhaps you're tired of the grumpy old attitude of 'everything must be static, DHCP is the work of the devil'?

It, like many other new tools, is very powerful, but you do have to stop and learn how to utilise it.

Yes, I know it's not that new, but to a grizzled unix veteran set in his ways it is

[madires]

Please don't blame linux! Blame specific linux distributions! Some think they have to move to the latest and greatest fancy stuff. But you don't have to. I'm running the same non-fancy window manager for ages.

[SiliconWizard]

Where can I start to describe what's wrong with Linux?

Nowhere. Everything goes smooth as long as you use a stable & well tested distribution in a PC with hardware which is supported by Linux (the latter is much less of an issue nowadays) and do a training so you know what you are doing. (...)

True enough.

The basic issue discussed here IMO is about "fragmentation".

Obviously the only way you can avoid software fragmentation is having ONE big company controlling the whole development process and strategy. MS was actually pretty good at doing this, and I mean was. Looks like they're on a slippery slope at the moment, although you can still run most decently-written apps from 15 years ago on their last OS. But even well established companies controlling everything can't completely avoid fragmentation. Besides, I'm not sure this would be a good thing for GNU/Linux in the long run. This can't be.

A second but related point is that open source software and binary distribution don't get together well by nature. Open source is about software itself much more so than about fitness for any particular use or even ease of use. Now if you need support, you can buy it and use Red Hat for instance, which has been one of the most popular distributions for commercial companies selling Linux software.

Obviously the GNU/Linux world is pretty fragmented but that's also what makes it fruitful and independent. Now I admit it makes software distribution very tough if you target Linux, that's why most companies targetting Linux only target a very limited and well selected number of distributions as nctnico suggested.

You also have to define what you consider acceptable and unacceptable incompatibilities.
Having to make your own software evolve every few years to accomodate for external evolutions doesn't seem that abnormal or infuriating to me. If it were every few months, it may be. But again, you can select very stable and slow-evolving Linux distributions to mitigate that. (Just think that some distributions still run on kernel 2.6  )

One means of insuring a lot less fragmentation would be to require strict conformance to well known standards. Problem with this is 1/ software standards are not that many and don't cover everything, 2/ there is no way you can "require" anything from open source software teams, and 3/ that would probably hinder the "productivity" of open source software development big time and add considerable hidden costs, only leaving the big players alive, which as I hinted above would probably mean the end of open source as we know it.

The short-term solution is again either targetting only one or two very stable Linux distributions or devising your own, that you can update as you see fit.

[rhodges]

I am new to this forum, but I already know I'm going to like it here. Am a FreeBSD fan, myself. Did a couple device drivers, network  code, used the ATM (HARP) stack.

I noticed a new term above, where "CHUM" was used in context of comanies' business. Okay, fun international crowd here!

Oh, it is my browser font and tight kerning. The word is "CHURN"... Around here, "CHUM" is rotting meat used as fish bait. Wait, maybe it was "CHUM"...

[bd139]

Welcome. You will fit right in

[Marco]

The problem with Raspbian DHCP is that no one is paying the dhcpcd creator to be compatible with /etc/network/interfaces and it doesn't have his interest because he wants to have a minimal program, if you use it it's take it or leave it and Raspbian took it. Meanwhile the other big dhcp client is being created by Redhat, who have no interesting in allowing easy transition to non systemd systems because it's their baby and gives them competitive advantage ... so they will have their own configuration too.

For the near future there will be a slow grind of changes in Linux administration practices until systemd reigns supreme over all, Redhat is funding so much of Linux at this point it's unavoidable.