On 4/21/24 04:20, Andreas Eder wrote:
> I think the problem is that they grew up in a Windows dominated world,
> not like us greybeards.

I really would like to agree. However we have some 20 year old
developers that have been using Linux their entire life making these
types of questionable decisions.

I think it's more apt to say that they have grown up with frameworks
that abstract things away from them and they have no idea how the
underlying infrastructure works.

It used to be that Unix, and I'll include VMS, system administrators
were full stack LONG before "full stack" was a thing. Now people think
"full stack" is a honor and rarely achieved because they seem to think
that there is too much to learn / know. Yet there are those of us that
have been doing full stack from the SCSI bus all the way up to the
encryption that web traffic runs through and all the equipment in between.

I remember when a 486 could serve up static web pages with the best of
them. Now some developers think you need multiple high end physical
boxes in a cluster to run the stack to serve up a simple web page that
is now dynamically created, half of it rendered client side in JavaScript.

> +1

:-)

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/21/24 13:17, Scott Dorsey wrote:
>> Because Linus owns the trademark and controls what can be called
>> Linux and what cannot be. Linus decides what goes into the kernel,
>> and therefore if he wants there to be one Linux kernal, there is.
>> If he wanted there to be two, he could do that too.
>
>On one hand I agree. But on the other hand I disagree.
>
>Given that the Linux kernel is released as source code, people can
>reconfigure it as they want. People can even add patches to it to add
>additional functionality that's not in the upstream vanilla kernel
>source. OpenZFS and some binary BLOB drives from vendors being perfect
>examples of such things not in the upstream vanilla kernel source.

That's true, but they can't just call it Linux. I run Linux+RT-PREEMPT myself.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 20/04/2024 6:46 am, Dan Cross wrote:

> They can also look at the number of outstanding bugs that
> are not getting fixed.

Quite. I know the people involved, have worked with them, and the
consensus from the industry is that X11 is dead. It gets attention when
a CVE appears, and when things break on XWayland, but X11 is dead.
Wayland is not X11, and the world has moved on. It's impossible to do
ssh forwarding with any reliability, xhost doesn't work as you'd expect,
etc. The entire _model_ is obsolete and the Big Players do only as much
as needed to keep legacy stuff working up until it gets rolled over into
a big k8s thing.

Anyway all I was saying is that maybe instead of hanging on to how
things were done in 2004 it might be more useful to make sure than
things like ssh from Windows Terminal or whatever work without too much
finagling.

--
motk

On 20/04/2024 10:05 am, chrisq wrote:

> As with systemd, Wayland looks like yet another attempt at power grab,
> and even after years, still doesn't work properly, nor is it complete
> compared to X functionality. Who cares if X isn't completely secure,
> just use it accordingly...

Deeply unserious summation. Feel free to keep righting spaghetti bourne
in rc.d, but the actual working world will just leave it behind.

> Chris

--
motk

On 20/04/2024 7:44 am, John Dallman wrote:

> That's an extremely sweeping statement. I'm working for a very large and
> paranoid corporation. I wouldn't try using X11 across the internet, but
> for working with a lot of different Linuxes, macOS and Solaris in a
> secured development lab, it is truly excellent, and nobody is trying to
> stop me.

I'd love that sort of gig myself, but everywhere I've been for the past
twenty years would have conniptions if I asked to open firewall holes
for X, or to add stuff to /etc/skel for xhosts, or to add selinux
policy, etc etc.

> It lets me have editors and terminal windows on lots of different Linuxes
> without needing to deal with their different GUIs and desktop
> environments. As far as I can see, Wayland doesn't offer that unless you
> slap on a remote desktop protocol. I actively don't want remote desktop:
> it is not useful to me, it will suck bandwidth, and it gives me much,
> much more setup to do.

Wayland is not X. It was never designed to do that, and I've personally
berated Keith et al about that decision. RDP pretty much exploded and
all interest in replicated X in that way vanished, but there is yet
hope, ie https://gitlab.freedesktop.org/mstoeckl/waypipe/

> I produce closed-source commercial shared libraries that have to work on
> as many Linuxes as possible. The list of ones I have running in the lab
> isn't ludicrous, but nor is it short:
>
> x86-64: CentOS 7.9, RHEL 8.9, Rocky 8.9, Alma 8.9, Alma 9.3, SLES12sp5,
> SLES15sp5, Ubuntu LTS 20.04 and 22.04. I need to add Ubuntu LTS 24.04
> soon, of course, and I'm getting extended support on the CentOS 7.9s so
> that products released on them can serve out their maintenance lives.
>
> Aarch64: Ubuntu 20.04, Amazon Linux 2, and RHEL 8.9. I need to add Amazon
> Linux 2023, Ubuntu LTS 22.04 and 24.04.
>
> Would you want to set up desktops for all those different Linuxes?

I'd probably just use RDP to be honest. Easy enough to set up on most
thing, and the corp environment would be already glued together to allow
it. I've used NoMachine when maintaining a farm of windows/osx/linux
desktop/servers before.

> John

--
motk

On 20/04/2024 10:37 am, Lawrence D'Oliveiro wrote:

> I wonder who you think is “grabbing” this “power”. Both systemd and
> Wayland are open-source projects, created by people who see a problem and
> are trying to fix it. Those in the community who see value in these
> efforts adopt their solutions, others don’t. There is no Monopolistic™
> BigCorp® forcing any of these things down our throats. If you don’t want
> to use them, don’t use them.

If you've ever spend two days awake chasing races in shell scripts
across pacemaker/corosync you'd do anything for systemd or something
similar, like the solaris stuff.

This is what I'm saying here, it's possible to neckbeard yourself into
irrelevance and then you end up looking like some dude complaining
that's no such thing as rock and roll anymore. It's just cringe.

--
motk

On 21/04/2024 1:08 am, chrisq wrote:

> systemd originally came from redhat. I rest my case.

uh

> A suffocating carbunkle on  what was an elegant os that really didn't
> need it...

uh

--
motk

On 21/04/2024 8:27 am, Lawrence D'Oliveiro wrote:

> Linux is able to offer a great deal of variety with minimal fragmentation,
> while the BSDs have more fragmentation and less variety.

All the BSD's are great! I'm especially fond of FreeBSD, but even they
have issue with service (rather than process) management.

--
motk

On 22/04/2024 8:36 am, motk wrote:

> Deeply unserious summation. Feel free to keep righting spaghetti bourne
> in rc.d, but the actual working world will just leave it behind.

Argh, 'writing'

--
motk

On 21/04/2024 1:00 am, chrisq wrote:

> Perhaps a poor choice of words, but are there any desktop / GUI systems,
> other than windows, that do not depend on X11 ?. The point was that it
> is a standard, and not optional. Can't remember if the old Motif based
> CDE used X11 libs or not, but that's long gone anyway. VWS, ditto...

Literally ... all of them? GNOME, KDE, none of them require X11 for
anything, and they all work perfectly fine. Xwayalnd exists and is
actively maintained so you can still use X11 and not notice anything.
You will get the occasional wrinkle (copy/paste finagling) but it's my
daily drive now. The people who actually do the coding, xfree86/xorg
people, are now making enormous strides in a post-x11 world. People are
even writing entire desktop environments in rust now, which is exciting.

If you're looking for standards, it's now wayland/xdg-portal/dbus.

It really is worth doing the research here and seeing what modern best
practice is. Ignore phoronix commenters of course.

--
motk

On Sun, 21 Apr 2024 11:41:06 +0200, Andreas Eder wrote:

> But .INI format is not a classic unix file format and not as easy to
> parse as the real, classic unix file formats. I think of it as an
> abomination.

It’s very easy to deal with, and very popular among open-source
developers. It’s so popular, there’s even a module in the standard Python
library for parsing it. That’s why systemd adopted it.

I think it is Windows programmers who were conditioned to hate it, by
Microsoft marketing.

>> Not so easy to selectively add/remove, enable/disable or start/stop
>> individual services.
>
> In fact it is easy to do all that if you know how to edit text filesm
> either by hand or with tools like awk or sed.

Not really the best idea, when you can separate out the definitions into
individual files. Less chance of accidentally altering something you
didn’t mean to.

On 21/04/2024 1:37 am, Arne Vajhøj wrote:

> I don't think macOS use X either (for native macOS
> applications - can run X applications).

I think it dropped X support a decade ago. The could probably do a
headless thing but nobody needs it. There are third party apps of course.

--
motk

On Sun, 21 Apr 2024 11:20:03 +0200, Andreas Eder wrote:

> I think the problem is that they grew up in a Windows dominated world,
> not like us greybeards.

If only Windows had Linux-style service management, don’t you think?
Imagine being able to add/remove, enable/disable and start/stop individual
services without having to reboot the entire system!

On Sun, 21 Apr 2024 11:16:07 +0200, Andreas Eder wrote:

> On So 21 Apr 2024 at 02:08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Why is it the Linux distros are able to maintain a common kernel, but
>> the BSDs are not? Aren’t the BSD kernels flexible enough for such
>> different uses? Which aren’t even that different, compared to how
>> distinct the various Linux distros can be?
>
> Because they do not want to! They have different objectives and they are
> really different projects. Not at all comparable to Linux distributions.

And yet the range of variety they are able to offer, with their fragmented
kernels, is only a small fraction of what Linux distros have achieved,
with their unified kernel base.

The fact that the BSDs needed to make incompatible kernel changes to
support their userland variants is simply an admission that that kernel
wasn’t all that flexible to begin with.

On 4/19/2024 5:44 PM, John Dallman wrote:
> I produce closed-source commercial shared libraries that have to work on
> as many Linuxes as possible. The list of ones I have running in the lab
> isn't ludicrous, but nor is it short:
>
> x86-64: CentOS 7.9, RHEL 8.9, Rocky 8.9, Alma 8.9, Alma 9.3, SLES12sp5,
> SLES15sp5, Ubuntu LTS 20.04 and 22.04. I need to add Ubuntu LTS 24.04
> soon, of course, and I'm getting extended support on the CentOS 7.9s so
> that products released on them can serve out their maintenance lives.

And related to the other topic about RHEL significance then that is:
RHEL + 3 RHEL clones + SLES + Ubuntu

> Aarch64: Ubuntu 20.04, Amazon Linux 2, and RHEL 8.9. I need to add Amazon
> Linux 2023, Ubuntu LTS 22.04 and 24.04.

And RHEL + 1 RHEL clone + Ubuntu.

Arne

On Mon, 22 Apr 2024 08:48:13 +1000, motk wrote:

> All the BSD's are great! I'm especially fond of FreeBSD, but even they
> have issue with service (rather than process) management.

A client of mine has office routers running pfSense, which is based on
FreeBSD. I find some oddities, compared to Linux. For example, the “route”
command (for maintaining the routing table) has no option to list the
contents of the routing table: instead, you have to use an entirely
different command, “netstat -r”, for that.

There was a time when the BSDs had a much superior network stack to Linux.
Those days are gone.

And by the way, the BSD world is working on its own systemd-lookalike,
too. It’s called “InitWare”.

On 4/21/2024 7:07 PM, Lawrence D'Oliveiro wrote:
> On Sun, 21 Apr 2024 11:20:03 +0200, Andreas Eder wrote:
>> I think the problem is that they grew up in a Windows dominated world,
>> not like us greybeards.
>
> If only Windows had Linux-style service management, don’t you think?
> Imagine being able to add/remove, enable/disable and start/stop individual
> services without having to reboot the entire system!

They don't need to imagine. They have been doing that for decades.

Arne

On Mon, 22 Apr 2024 08:45:09 +1000, motk wrote:

> This is what I'm saying here, it's possible to neckbeard yourself into
> irrelevance and then you end up looking like some dude complaining
> that's no such thing as rock and roll anymore. It's just cringe.

I see that around me all the time. systemd is one obvious trigger for
them, but there are others (e.g. Wayland, iproute2). Some of these people
may be physically no older than me (I’m guessing), but mentally it seems
they already have one foot in the grave.

On 21/04/2024 8:58 am, Arne Vajhøj wrote:

> It probably didn't hurt that the product they intended to
> displace was also using Electron (Atom).

It'll probably move on to react/fluent/webview2, like teams did.

Using a display engine used in anger on billions on devices is probably
a good call, there's a lot more react coders in the world that qt or
similar.

> Arne

--
motk

On 4/21/2024 7:06 PM, Lawrence D'Oliveiro wrote:
> On Sun, 21 Apr 2024 11:41:06 +0200, Andreas Eder wrote:
>> But .INI format is not a classic unix file format and not as easy to
>> parse as the real, classic unix file formats. I think of it as an
>> abomination.
>
> It’s very easy to deal with, and very popular among open-source
> developers. It’s so popular, there’s even a module in the standard Python
> library for parsing it. That’s why systemd adopted it.

People may have different opinions on what is "very popular".

The 3 most widely formats for config files today are XML, JSON
and YAML.

But INI and Java properties may be the next 2 in usage.

Arne

On 22/04/2024 9:12 am, Lawrence D'Oliveiro wrote:

> A client of mine has office routers running pfSense, which is based on
> FreeBSD. I find some oddities, compared to Linux. For example, the “route”
> command (for maintaining the routing table) has no option to list the
> contents of the routing table: instead, you have to use an entirely
> different command, “netstat -r”, for that.

Muscle memory is like that.

> There was a time when the BSDs had a much superior network stack to Linux.
> Those days are gone.

They're working on it all the time at least, it's still performant and
the BSD/Linux network guys have an amicable rivalry.

> And by the way, the BSD world is working on its own systemd-lookalike,
> too. It’s called “InitWare”.

Of course. Once you realise that you're not just doing the
fork-child-daemonise thing for a single binary (which had all sorts of
exciting edge cases), you have to start thinking is services. What are
you expecting to be up? What state should it be in? What should a
running target look like?

Further: modern IT optimises for cattle, not pets.

People forget that sysvinit and crontab and stuff were just itches
scratched. People made a lot of money with proprietary service managers,
batch managers, etc, for the legacy unixes. Now you have systemd which
just works and now you can go home and drink beer. Bonus: don't have to
deal with sweaty-palmed salespeople at trade shows.

--
motk

On 21/04/2024 10:32 am, Grant Taylor wrote:

> At least Solaris stopped SMF at managing services and didn't try to take
> over DNS, NTP, and many other things.

Those are entirely optional, but very handy for embedded/cloud image/iot
stuff, where you don't want to pull in an entire distros worth of stuff.

This is all a bit sad in 2024.

--
motk

On 21/04/2024 10:46 am, Arne Vajhøj wrote:

> But my impression is that it missed on the main criteria: keeping
> things simple.

I can assure you it's much more simple than dealing with shell scripts
in init.d, rc.d, /opt/foo/product/bin/etc/local/init.d/rc.d etc etc. Let
alone stuff glommed into inittab that called stuff that did god knows
what. This script calls a binary, that writes out a shell script with a
BASE64 encoded portion that extracts itself and execs it and writes out
a pid somewhere and what the hell.

Someone said "bugger this" and wrote something much neater and with
clearly defined configuration. It was a godsend.

> To illustrate the point and somewhat move back to VMS let me confess
> something: I really like SYS$MANAGER:SYSTARTUP_VMS.COM to manage
> what get started on VMS.
>
> VMS start the stuff that has to run and one put in what one
> want to start in SYS$MANAGER:SYSTARTUP_VMS.COM usually in the
> form of @SYS$STARTUP:something$STARTUP.COM.
>
> A simple text file that after a little cleanup typical
> will be only 20-50 lines. Easy to understand. Easy to edit.

Sure, you can still do that, but you now have the problem of knowing
what the state of the system is, being able to interrogate that in a
machine readable way, and being able to be managed as a fleet.

--
motk

On 21/04/2024 7:20 pm, Andreas Eder wrote:

> I think the problem is that they grew up in a Windows dominated world,
> not like us greybeards.

My beard is as grey as anybody! I refuse to wear suspenders, or socks
with sandals. Have to draw a line.

--
motk

In article <v0465s$gqf3$6@dont-email.me>, motk <meh@meh.meh> wrote:
>On 21/04/2024 1:37 am, Arne Vajhøj wrote:
>
>> I don't think macOS use X either (for native macOS
>> applications - can run X applications).
>
>I think it dropped X support a decade ago. The could probably do a
>headless thing but nobody needs it. There are third party apps of course.

XQuartz is supplied by Apple and provides X under MacOS which works pretty
reliably, although slower than native MacOS graphics. It's used by a lot of
applications from Matlab to the various open-source ports to MacOS.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."