Ubuntu desktop team teases 'proof of concept' systemd on Windows Subsystem for Linux

Canonical may be working on introducing systemd to Ubuntu on Windows Subsystem for Linux (WSL), according to a post by Ubuntu Desktop Team Technical Leader Didier Roche. Roche's remarks were posted on the Ubuntu Desktop Team Updates two days ago. "PoC of systemd on WSL at startup of an instance," he said, raising hopes (or …

[Anonymous Coward]

WSL is a joke, and so is WSL2. Neither will let me work on the kind of projects I do; I tried. With WSL1, you couldn't even build a package for distribution because you couldn't do a chroot.

Nope. VMs for me. Started with Microsoft's limited VMs, and now I'm on VMWare Workstation 16. THAT is how you do Linux on Windblows. :)

[DrXym]

Personally I find it very useful being able just type bash and have a lightweight Linux environment at my command. It's extremely useful for development when your code runs in Windows and Linux, or just to use Linux like a shell, or even desktop apps.

<p>

Perhaps it's not as full blown virtualized machine but as you say, you can always fire up a VM for that. The downside of a VM is the performance and integration into Windows is far worse.

[mpi]

That's why I do it the other way 'round:

Run Linux and spin up Windows in a VM when I have to ;-)

[teknopaul]

Systemd for Windows will probably be a shim, except systemd has no spec it just does whatever pottering wants this week. It will never be a viable solution.

It will be like the /proc system work systemd team have crowbared into lxc. Systemd won't work in containers because systemd is broken by design, but instead of accepting that, they try to hack at other projects to compensate bad initial design.

It's a mess: if wsl is poisoned it matters little, its just more fuel to the fire.

[NoneSuch]

Amen brother, testify.

"Canonical is not Microsoft" and we thank the gods daily for that.

[keithpeter]

"Canonical is not Microsoft [...]"

at this time...

[oiseau]

"Canonical is not Microsoft [...]"

at this time as far as we know.

O.

[a pressbutton]

for me, Cygwin is enough.

... i know it isnt true linux but it provide what I need

[bombastic bob]

Why not JUST install Linux???

(in a VM if your host system MUST be Windows!)

I am (right now) running Win-10-nic in a VM and updating it. It's been a year... and I just recently updated this FreeBSD box with the newest ports, kernel, userland. Might as well update the VMs too, right?

So maybe I'll play with WSL too, but that would be kinda pointless, I think.

(I like Cygwin anyway and use that on Windows 7 pretty frequently - rsync for backups really rocks!)

(strangely the icon dd not work without disabling scripts completely)

[jake]

"2 users though have frequently requested systemd support"

That many, eh? Roughly twice as many as I expected.

More seriously, if Windows users want the systemd-cancer, they can have it. Hopefully they'll manage to make it completely incompatible with Linux along the way.

[Anonymous Coward]

@jake - Re: "2 users though have frequently requested systemd support"

Watch what you're wishing for!

Something tells me this is exactly Microsoft's plan. They'll make it incompatible, and as soon as Linux runs well within WSL, Microsoft will start shutting down any other distribution that doesn't run on Windows. This is where SecureBoot comes in handy, nobody will be able to run Linux unless they login to Windows with a Microsoft account. It took a while but they will soon have total control over every PC.

[jake]

Re: @jake - "2 users though have frequently requested systemd support"

"Microsoft will start shutting down any other distribution that doesn't run on Windows."

What, pray tell, would be the proposed mechanism for this fantasy?

[Doctor Syntax]

Re: @jake - "2 users though have frequently requested systemd support"

They have the signing keys for secure boot. So long as you can turn that off it's not an immediate problem but in essence it's a dangerous monopoly. If systems are sold with BIOSs that don't provide for that they have control of what can be booted on a PC. Strange things seem to be happening in the world of BIOS - my current laptop has a very strange one without the many parameters you could tweak on AMI and the like.

[Anonymous Coward]

Re: @jake - "2 users though have frequently requested systemd support"

Well, I'm pleased to report that my Gigabyte Aorus has more options than I can shake a stick at compared to the BIOS on an 8086 based PC. :)

[Anonymous Coward]

Re: @jake - "2 users though have frequently requested systemd support"

Very few manufacturers ship systems with BIOS these days. They almost all use UEFI now.

[dajames]

Re: @jake - "2 users though have frequently requested systemd support"

Very few manufacturers ship systems with BIOS these days. They almost all use UEFI now.

What is UEFI if not a Basic Input Output System?

OK, it's not nearly as Basic as it should be, but it's still a BIOS ... just not a BIOS that is compatible with the one in the original IBM PC.

Way back in the day I built a Z80-based computer that ran CP/M. There was a 2Kbyte EEPROM that held the BIOS ... and that wasn't compatible with the one IBM later wrote (or had written for them) either.

[cyberdemon]

Re: @jake - "2 users though have frequently requested systemd support"

> What is UEFI if not a Basic Input Output System?

It's a rather complicated, convoluted and contrived system for a lot more than input and output.

[mpi]

Re: @jake - "2 users though have frequently requested systemd support"

>If systems are sold with BIOSs that don't provide for that

...then I don't buy them, simple as that.

[bombastic bob]

Re: @jake - "2 users though have frequently requested systemd support"

agreed. last 2 motherboards I purchased boot just fine with FreeBSD, no key required.

Both support Ryzen so they are pretty new designs.

[phuzz]

Re: @jake - "2 users though have frequently requested systemd support"

Microsoft have a signing key, which is included by default in every* UEFI. Distros that support Secure Boot use their own key, which has been signed by Microsoft, so theoretically Microsoft could update their key to invalidate the distro keys they've signed, although this wouldn't affect most existing devices, only new ones going forward.

Most of them allow you to enrol your own keys, so there's nothing stopping you from compiling your own kernel and signing it yourself.

Given that Microsoft got sued just for making their own web browser the default on first install, I don't think it's likely they'd ever go that far though, no profit in it.

* I assume every device includes the Microsoft key, but it's purely at the discretion of the manufacturer.

[bombastic bob]

Re: @jake - "2 users though have frequently requested systemd support"

yes but NOW we know their EVIL PLAN. Heh heh heh!

[Anonymous Coward]

Re: "2 users though have frequently requested systemd support"

Poettering has a friend?

[Anonymous Coward]

Re: "2 users though have frequently requested systemd support"

Poettering has a sockpuppet. The two are in a committed, if non-traditional, relationship. Who are we to judge.

[G40]

Re: "2 users though have frequently requested systemd support"

@AC, sock puppet has coffee on iPad. Plz have a beverage =>

[katrinab]

Re: "2 users though have frequently requested systemd support"

Whoever's in charge of the Gnome Project, I believe?

[Anonymous Coward]

Re: "2 users though have frequently requested systemd support"

"Poettering has a friend?"

No, it's his Mom.

[CrazyOldCatMan]

Re: "2 users though have frequently requested systemd support"

if Windows users want the systemd-cancer, they can have it

It'll be a marriage made in hell..

[simonb_london]

Re: "2 users though have frequently requested systemd support"

....and the systemd cancer will spread to the Windows kernel itself....taking over all the services, logs and even user directories.....making Windows incompatible with itself!

[bombastic bob]

Re: "2 users though have frequently requested systemd support"

Roughly twice as many as I expected.

The other must be a sock-puppet

[DS999]

WSL 2 users have frequently requested ...

Probably they aren't really WSL 2 users - they are users of proper Linux who figure if they have to suffer so should WSL 2 users!

[karlkarl]

As a BSD user, systemd hasn't really affected me but it has been interesting to watch from the sidelines.

One observation I have is that for too long Linux (and the rest of us) has been riding on the ancient UNIX/POSIX design that has proven to be fairly successful. Perhaps it is time for it to go its own way and prove to the world that it is Linux that is great, rather than the old crusty UNIX design. I see Systemd as the first step in doing so.

I'm certainly not saying that all Linux distros should do this. If anything Devuan, Alpine, void, etc can act as the "control" group so if systemd crumbles, we can blame it on that broken design rather than Linux in general.

After all, "GNU Is Not UNIX". It is possibly time for it to prove its worth and perhaps even surpass it? Who knows? GNU favours bigger, entangled software (Emacs, GTK, systemd). I personally am not convinced by this but time will tell.

As for Microsoft embracing it. This is a gimmick. A mere distraction whilst they slowly become irrelevant.

[Anonymous Coward]

@karlkarl - I don't think so!

No chance for Microsoft to become irrelevant, they have too much control.

[jake]

Re: @karlkarl - I don't think so!

"No chance for Microsoft to become irrelevant, they have too much control."

Don't you believe it, not even for a minute.

By it's very nature, FOSS will be around as close to forever as makes no nevermind. Corporate closed source software, on the other hand, is just as ephemeral as the company in question. IBM is doomed to die, eventually. So are Amazon, Goophabet, Metaface, Apple and yes, even Microsoft.

Before you poo-poo this, think about it. Where are Burroughs, Sperry, Allied Signal, Philco, Amdahl, Remington Rand, DEC and ROLM? We won't mention the likes of HP, the poor mewling thing, so senile it doesn't know it's dead yet. And that's just for a start.

[W.S.Gosset]

Re: @karlkarl - I don't think so!

> We won't mention the likes of HP, the poor mewling thing, so senile it doesn't know it's dead yet.

Ah-hhh, HP. The first major casualty of open sauce competition.

[cyberdemon]

Re: @karlkarl - I don't think so!

And I think that's why Microsoft bought GitHub. ;)

What happened to the Bill Gates Satan Icon?

[John Brown (no body)]

Re: @karlkarl - I don't think so!

"What happened to the Bill Gates Satan Icon?"

It's retired and gone off to do "good works" in the care home for ex-CEOs of defunct tech companies.

[Lorribot]

Re: @karlkarl - I don't think so!

Where are Talbot, NSU, Alvis, Bristol, Austin, Cord, Morris, Saab etc. Any industry has its once big names that fell by the wayside, were absorbed by other companies sold, went bankrupt, reborn only to die again.

Microsoft has re-invented itself as a Datacentre owner and make the vast majority of its profits from that not Windows, in fact Azure itself runs more Linux servers than Windows.

IBM may or may not survive, as Wang has not, or become an irrelevant subsidiary of some other corporation like Xerox, i know not the future for certain.

Microsoft have less control than Facebook or Google, more devices in the world run Android (a Linux fork) than Windows, more devices run Chrome as a browser than all other browsers put together and most of those are basically reskinned versions of Chrome with built in Google services, and more people search the web with Google than any other search engine.

The great unwashed public like a dominant player as they like the illusion of safety.

It really is time people woke up to the world that is, not the one that was 20-30 years ago and now only exists in their heads.

Make your choices based on what you need to do and don't blame MS, FB, GG, Apple for theirs, they are just making as much money as possible, that is what companies do. If you don't like just use something else.

If there is no choice or Hobson's choice (eg phone OS) then complain to your government representative.

[Ian Johnston]

Re: @karlkarl - I don't think so!

Remember 386 processors? Linux dropped them at Kernel 3.8. And here's a list of all the other processors proposed for deletion soon: https://www.phoronix.com/scan.php?page=news_item&px=2021-Linux-Drop-Old-CPUs

Sure, you can use an ancient kernel to get a 386 running or even compile your own, but there's nothing stopping you from doing that on a VAX 11/780 either ...

[Adrian 4]

Re: @karlkarl - I don't think so!

Like IBM ? Or Rome ?

Their relics are everywhere but the power is long gone.

[MyffyW]

Re: @karlkarl - I don't think so!

Far-called, our navies melt away;

On dune and headland sinks the fire:

Lo, all our pomp of yesterday

Is one with Nineveh and Tyre!

[W.S.Gosset]

Re: @karlkarl - I don't think so!

> Like IBM ? Or Rome ?

RomulOS and RemOS, those were the days.

[oiseau]

I see Systemd as the first step in doing so.

Seriously?

Are you sure it was sugar you sprinkled on your tea?

From my point of view, after far too many years of work with M$ OSs, the one thing I can say is that systemd behaves just like M$'s infamous registry and that is no coincidence.

To quote another comentard on systemd, here at ElReg:

---

" ... takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host."

---

ie: just like a malignant tumour.

In a nutshell: systemd is nothing but a developer endorsed registry-class© virus set up inside Linux distributions, just like the registry in MS OSs from W95 onwards.

I don't want that sort of crap inside my Linux distribution.

That's why I run Devuan.

O.

[mpi]

>I can say is that systemd behaves just like M$'s infamous registry and that is no coincidence.

How so?

The admin still has complete control over it, the entire config is done in plain text files, it doesn't have a tendency to get frekked up by installed and deleted programs as the system ages, and applications don't use it as a weird mix of runtime-storage+config. I also don't have to use features like systemd-nspawned or homed if I don't want to, even though they are there.

And while it is in commonly used distroy these days; nothing prevents people from using other init systems if they prefer to. There are more distros not using systemd than I care to count, and on top of that, one is free to build his favorite linux variant from scratch. In fact "LinuxFromScratch" has recipes for both building with or wo. systemd.

But most people do use it. And here is my guess why that is: systemd, for all the criticism it receives, is just too damn useful. Its performant, it does its job, and it takes over functionality that SHOULD be centralized into a monolith, and not spread out over dozens of sub-systems glued together by some shellscripts.

I have had to work with my fair share of servers where "services" were partially implemented in whatever initd was present, and partially as weird mixes of "init-scripts" and "watchdog-cronjobs". No thanks.

[Zolko]

systemd, for all the criticism it receives, is just too damn useful.

what for ? I've been using Linux for 24 years, and I still don't understand what systemd does better – or at all – that was not done before. udev was the game-changer, it was done way before systemd, even though it is in systemd now.

it takes over functionality that SHOULD be centralized into a monolith.

well, pretty much the exact opposite of what Unix ever was

[mpi]

I'll give you my top 3:

1) Easy to configure. If I want to change how an init-script controlled service behaves, I sometimes can do that by changing a 12 line init script. And at other times, I have to wade through hundreds of lines of uncommented shellcode. I prefer a unified way, where the same syntax is concise, and applied to every service in the same way.

2) Easy, event-driven way to know when devices are ready. udev is nice, but only tells me if the kernel knows about the device, that doesn't garantuee that it's rdy. So, what to do? Many init scripts "solved" this by looping over dev operations until they succeeded...and every service requiring that device hat to do that for itself.

3) Unified handling of service dependencies. Doing that in shellcode runs into the same problem as described in 2) ...just because a service executable runs (many services never bothered with a PID-file, so theres more fun to be had by calling ps | grep over and over) doesn't mean its ready.

>well, pretty much the exact opposite of what Unix ever was

The Linux kernel is a monolith as well, and the reasons why are pretty much the same as with systemd: Spreading things out that could be centralized redundant computations and harder optimization. Sure, one buggy driver can bring down the whole system. But the solution to that is "let's fix the bugs" not "let's go microkernel"

[Paul Hovnanian]

"1) Easy to configure."

If it's something that Puttering saw fit to build into his binary. Otherwise, NOTABUG, WONTFIX. If Lenny doesn't need to do it on his laptop, you are out of luck.

That's not entirely accurate. One can still write a shell script, launch it from systemd and even interact with DBUS within it. If you can put up with the screeching from the anti-script crowd. Even when they aren't going to be running your non-standard daemon anyway. I expect a change to systemd at some point where it will refuse to allow bash to execute.

[Ian Johnston]

If it's something that Puttering saw fit to build into his binary. Otherwise, NOTABUG, WONTFIX. If Lenny doesn't need to do it on his laptop, you are out of luck.

It's open source, so you are free to modify it to suit your needs. Or at least, that's the answer to feature requests on every other bit of free software, so why not for systemd as well?

[Doctor Syntax]

1) Easy to configure. If I want to change how an init-script controlled service behaves, I sometimes can do that by changing a 12 line init script. And at other times, I have to wade through hundreds of lines of uncommented shellcode. I prefer a unified way, where the same syntax is concise, and applied to every service in the same way.

If I want to change an init-script I can see exactly what it does. The workings are exposed, however many lines there might be. I can run the code from the command line and step through it if need be. If I change a config file I'm just relying on a black box to do something, hope it's right and submit a bug to be marked WONTFIX is it isn't.

2 & 3) See 1 above.

[mpi]

>if I want to change an init-script I can see exactly what it does.

If I want to change a service-file I know exactly what it does, because `$ man systemd.unit` explains in great detail what each stanza in the file does and why.

The difference is: These rules are _the same for every single service_.

Whereas with init-scripts, the rules are whatever the author of that script came up with.

>The workings are exposed

https://github.com/systemd/systemd

[Paul Hovnanian]

"many services never bothered with a PID-file, so theres more fun to be had by calling ps | grep over and over"

man pidof

[sebacoustic]

Seems ill-informed to compare the Windows registry to systemd, one is a configuration database and one an init system. Also what's with the cancer metaphor? Load of nonsense.

Have been using systemd for a few years now as it comes with fedora. Confusing at first, just like anything new and unfamiliar, but after a while beginning to appreciate the useful features.

Resource-hogging? I don't think so. Currently, my systemd at pid 1 has 178kB ram and roughtly 0% cpu.

[Steve Graham]

"Currently, my systemd at pid 1 has 178kB ram and roughtly 0% cpu."

Why is your init system still running after startup? Is it buggy?

[Peter Gathercole]

Re: "Currently, my systemd at pid 1 has 178kB ram and roughtly 0% cpu." @Steve

Um. Do you understand how SysV Init works and what it does?

It sits around all the time (PID 1), waiting for monitored processes defined in inittab (or sometimes getty or ttys and some other files) to change their state so that it can take appropriate action. This is pretty much of a muchness in all historic systems not running systemd or upstart.

I agree that for SysV init, the stuff in rc.d only gets run once on system startup, and once at each runlevel change, but that is just part of the function of init. If you look, there is a script, often called /etc/rc (or sometimes one script per run level, it's not actually that standard, although the concepts are always similar) that is listed in inittab, which actually traverses the rc.d directory hierarchy, running the correct start and/or stop scripts for the appropriate runlevel.

I wonder how many people realize that init becomes the ancestor of last resort, such that it re-parents any process whose real parent actually terminates before it does. As such, it has a vital function to perform a wait() to clean up the process table entries up (ever understood what zombie processes are, read up about what wait() actually does).

This is all historical, but relatively well understood. Once these things change, you start asking whether a system is still Unix-like.

[Ian Johnston]

So why do so many distros use it? Are the maintainers less clever than you are, have they been bribed or have they been forced into it?

[Anonymous Coward]

lazy, stupid or both

combined with red twat trying to monopolise

[mpi]

Or maybe, just maybe, its because systemd _solves real world problems_ with service initialization in a way that is uniform, reliable and doesn't require who-knows-how-many hours poured into maintaining a bunch of shellscripts?

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/

[Peter Gathercole]

@mpi

I am a professional UNIX system integrator and administrator of 40 years experience, and have looked after UNIX systems in the education, IT, commercial, utility, supercomputer and government spaces.

I have never had to spend significant amount of time maintaining shell scripts in the init system. Where I've had to spend time, it's been straight forward and easy to do.

I have actually spent much more time just in the last year trying to fix/implement things in Systemd than I've had to spend on System V Init scripts in the last 20 years!

I'm sure that there is an element of what you know vs. what you don't, but i believe that Systemd introduces more problems than it solves, and has failed to achieve it's stated design goals.

[jake]

Re: @mpi

"i believe that Systemd introduces more problems than it solves"

Concur.

"and has failed to achieve it's stated design goals."

That's OK, it adds new design goals all the time.

[Peter Gathercole]

@Ian

Systemd was supposed to address a perceived problem in Cloud/Containerized Linux implementations, and on personal Linux laptops.

Because the System V init system is mainly linear in the way it starts services, it does not employ much in the way of parallelization, it was seen as a bottleneck when spinning up new instances of Linux VMs and containers, and by people who want their laptop's to boot instantly.

For traditional UNIX workloads, running mainly on large pieces of hardware, this has never been a problem. The long uptime and good resilience for these systems, measured in months or sometimes even years, meant that an extra few 10's of seconds was largely irrelevant. Especially if it meant that if for some reason it failed to boot, you could easily diagnose the problem because it was so simple.

But if you wanted to spin up 100 Linux VMs in the Cloud to cope with a spike in demand, this time could be important. And some people are just impatient on their laptops and workstations.

Systemd was supposed to be a statefull init system that allowed you to define dependencies between various subsystems, so that you could start up many things in parallel, and have the co-ordination managed by Systemd to get a system up as quick as possible.

But in my (somewhat limited) experience, it failed to achieve this. My personal Linux systems with Systemd do *NOT* boot faster than they did when using more traditional init systems. And things fail to start up sometimes, and sometimes dependencies cause things to hang, leading to long boot times, and sometimes the systems not shutting down properly because of circular dependencies . And in every case, trying to debug the system is a nightmare, with binary log files needing tools to read them, and arcane knowledge, not easily acquired, needed to understand what caused the problem. It's got better as time has gone by, but I still have problems. And I have problems configuring it.

And the solution to this appears to be to widen the remit for Systemd so that it encompasses everything in the system. This is why it has been called an OS in an OS, and also a cancer. And this is what rub's UNIX Greybeards like myself up the wrong way·

[bazza]

Might As Well Use Windows

Thing is, if one writes off Unix/Posix as a defunct outdated "style", really what other "styles" are there? Windows? MacOS?

SystemD is effectively threatening to overturn everything, eg you no longer program to the Posix API, but to the SystemD API (eg how name resolution is now done; SystemD would have you do that via a Dbus req to itself rather than established Posix API calls for host lookup).

The problem with this is that it is hell bent on nothing less than major revolutionary change when, at most, only minor tweaks to Posix are needed to fix whatever inadequacies are perceived to exist in current implementations like glibc.

This is nuts, because it creates a third ecosystem for the sake of having a third ecosystem, not because there's anything technically and irrevocably deficient about the existing ecosystems. Windows does work. UNIX/Posix does work. MacOS occasionally works (and can be fairly Posixish when squinted at). These things are already pretty heavily optimised (yes, even the Windows kernel plus API is pretty good).There's nothing really to be gained by porting one's code to do things the SystemD way. You lose a ton of portability as well.

[jake]

Re: Might As Well Use Windows

UNIX and Posix are not the same thing. Stop conflating them, it makes you look silly.

"you no longer program to the Posix API, but to the SystemD API"

Speak for yourself, Kemosabe.

[Anonymous Coward]

Re: Might As Well Use Windows

Ahem. I was in the industry when POSIX was implemented by every single *nix vendor there was, as I started with BSD 4.2 on a VAX back in University. POSIX literally implies "portable Unix"; the name is INTENDED to do so.

So yes, POSIX *is* Unix; it is the core of what makes Unix programs portable between distributions and vendors.

[jake]

Re: Might As Well Use Windows

Since argumentum ab auctoritate seems to work in your world, I've been using UNIX since Septemberish 1974, with UNIX Version 5 at Berkeley, just before ken got there. I helped write the pile of code & patches that became 1BSD, and carried on contributing to BSD through 4.3-Reno, which brought BSD close to POSIX compliance. Note that POSIX did not even exist until 1988. So I think I can quite comfortably state that no, UNIX and POSIX are not the same thing.

And get this ... POSIX isn't even tied to UNIX. It is a series of standards designed to allow software portability between operating systems. Including Windows. Ever use Cygwin?

_{Yes, Peter, I know ... Linux isn't UNIX. Nor does it try to be. Neither does BSD anymore.}

[bazza]

Re: Might As Well Use Windows

Well, the Wikipedia page for the Single UNIX Specification lists Posix as being at the core of the Single Unix Specification. For example, 2001's SUS v3 is also called Posix:2001. The IEEE names the standards Posix, the Austin Group names the same things as Single Unix Specification.

So, in any way that matters, Unix is Posix. If it is tested as being Posix Compliant, that's exactly the same as saying it's compliant with the Single UNIX Specification, which means it *is* Unix by the formally accepted standard of today (i.e. you can't use the trademark Unix without compliance testing).

The fact that there is nowadays no actual OS called Unix (the last use of the name for an actual implementation was Unix v10 in the very late 1980s) reinforces that. Only Aix if formally compliant with Unix v7 so far as I can tell. Which means that, presently, absolutely everything else is merely Unix-like, or old-unix at best.

The time in history when one could say Unix isn't POSIX was before 1995, prior to the emission of v1 of the single unix specification, 26 years ago in the last millenium.

[Anonymous Coward]

Re: Might As Well Use Windows

"> And get this ... POSIX isn't even tied to UNIX. It is a series of standards designed to allow software portability between operating systems. Including Windows. Ever use Cygwin?"

You're right. I remember Digital Equipment boosting their POSIX compliancy for VAX/VMS... They had Ultrix besides of course, so they knew what had to be done... :)

[Peter Gathercole]

Re: Might As Well Use Windows @jake

Linux is not UNIX. I know it, you know it, but it seems like too many people around here don't.

I'm sorry I keep rubbing it in, but if I don't, who will!

I actually do have a slight fondness for various BSD derived systems, having had exposure to early PDP11 releases, as we've discussed before, although most of my working life has been with System V derived systems. Even most of my SunOS experience started after version 4.

I've recently put a pfSense firewall on my network, and have various releases of UNIX and BSD on my PiDP11, and it's interesting to see how much has changed, and yet how much has stayed similar to Edition 7, which is where BSD forked. It's all very nostalgic.

The original version of Posix was basically the System V Release 3 (SVR3) Interface Definition (SVID), as published by AT&T, with some minor changes (in fact, looking at them side-by-side, everything including much of the wording is the same). In later releases, additions and deletions have been made, so Posix has now a life of it's own. It's like it's own fork of UNIX, without the source code.

So Posix was a fork of the UNIX interfaces that then started to drive new features into UNIX (and other operating systems). Things like Portable (or is that Posix) Streams. Unfortunately, that stagnated, so although there are recent Posix revisions (it looks like 2018 was the latest) it's all tweaking around the edges rather than major changes to keep up with other OSs.

Linux came along, and decided to go it's own way, (mainly because moving the Posix standard was so hard) albeit in a consistent way to the UNIX philosophy, at least until Systemd.

[Down not across]

Re: Might As Well Use Windows

So yes, POSIX *is* Unix; it is the core of what makes Unix programs portable between distributions and vendors.

No its not UNIX. But you are getting closer.. key is in the name

MPE/iX is definitely not UNIX, however because it was POSIX compliant you could port lot of things from UNIX to it relatively easily.

[bazza]

Re: Might As Well Use Windows

The name Unix can be applied to anything that passes the compliance testing for the Single Unix Specification aka Posix. The whole point is that if you have something that comes with "Unix" stamped on it software can't tell the difference between that and anything else with Unix stamped on it (unless it calls uname)

Eg if MS put sufficient work into a native Windows Posix implementation and submitted it for compliance testing and passed that, Windows could be legitimately labelled "Unix".

What you can't do anymore is take the actual OS that was called Unix and claim that it is a Unix-complaint OS (by todays standards). Dev under that name stopped back in the 1980s and standards have moved on. It had the name Unix, but it is not today's Unix.

Linux is often dubbed "Unix like", but in fact one Linux distro (Euler OS, a Redhat offshoot) was submitted for compliance testing and passed. That was then labelled as Unix (though according to the Wiki page it's not been put up against the very latest iteration of the SUS).

[Peter Gathercole]

Re: Might As Well Use Windows @bazza

You are right, as far as it goes.

But as you point out, all Linux distros. are not Posix complient, and even if they were, there are enough differences between the latest Posix and Single Unix Standards to prevent Linux being called UNIX.

But even the last "UNIX" platforms have not been keeping up with the latest SUS, and this is mainly because it does not matter any more. UNIX and Linux have diverged, and in many cases what is in Linux is now much more important than UNIX.

But this poses a problem. What is GNU/Linux? Well, it's not one thing. The Linux part (the Kernel) is controlled by a single influential individual, with a small group of trusted lieutenants, and a lot of contributors. So it is kept in line. But the GNU part is controlled my many individual maintainers of the various packages, none of which are mandated for a distro. Distro's may have wildly varying versions of each package, and may end up applying their own patches.

What GNU/Linux is missing is a standard (yes, I know about the Linux Standards Base, but who bothers with that any more). There is not, and never will be (IMHO) a GNU/Linux standard. It just can't be done, because it's against the very openness of Linux. Don't like something? Fork it, publish it, and let the users and distro maintainers decide.

What there are is dominant distro's. We have Redhat and Debian (and to a certain extent SuSE), but they are controlled by companies, not by an independent organization. And thus we have Systemd and Wayland, because one of the dominant distro's thought they were a good idea, and managed to convince the other majors.

I've ranted too long here. Time to do some work.

[BOFH in Training]

Re: Might As Well Use Windows

I do run some Linux stuff occasionally, when needed.

With that said, I never really got into the systemd or init way of doing things. I just do whatever is needed on whatever is available.

With that said, isn't it the opensource way to create whatever you think you want / think is better / just feel like it? It's up to the others to use or don't use it. So, let him create his 3rd ecosystem. Maybe someone else will create the 4th or 5th ecosystem, etc.

It's up to the end users which they want to use.

[Peter Gathercole]

Re: Might As Well Use Windows @bazza

You will actually find me arguing both sides here.

It would, IMHO, be possible to have a Posix compliant system with Systemd. Systemd does not (as far as I understand it) change the areas that Posix standardizes, the system call layer, the general libraries or the command set that people use to interact with the system.

If you look at the Posix (and the UnixXX standards maintained by The Open Group), I don't think you'll find the init system documented, although you may find some referenced to inittab and maybe an interface to change the run level. In fact, if you read the "Base Definitions" of the standard, "System configuration and resource availability" is explicitly listed as being outside of that specified by Posix.

And services like name resolution and DNS, filesystem mounting, and many of the other things that Systemd is taking over are also not covered by Posix beyond the library API that systemd does not touch. There are acknowledged ways of doing things, inherited from System V, BSD, and as cross pollination from proprietary UNIXes, but these are defacto standards, not by defined standard.

But that's largely irrelevant, as Linux is not a fully Posix compliant operating system, and apart from a brief flurry of interest a couple of decades ago, never was (I believe there was a minor distro that claimed to be able to pass the Posix verification suite, but I can't remember it's name.)

Probably as much was changed with the inclusion of the sys and proc pseudo filesystems, and udev. Each of these moved away from tradditional Posix and UNIX, but they did it in a good and useful way (and you may say that /proc and /sys actually are in keeping with the UNIX "everything as a file" tenet).

Many of what are still classed as UNIX^tm systems like the one I know best, IBM's AIX added things on top of basic Posix, things like the ODM configuration database, the device configuration manager, the System Management tool SMIT, the jfs and jfs2 filesystems, and none of these broke Posix compliance.

But Systemd just goes too far in my opinion, does not follow many of the UNIX ways of doing things like "do one thing and do it well", and is just too opaque to be considered helpful. Although there is complexity in UNIX and Linux, most of it can be worked out by investigation and with the available documentation. I do not feel the same is true in the confusing morass of documentation of different versions, how-tos, and FAQs that spread across the Internet for Systemd, and even what is there is mainly how to configure it rather than how it works. And it is constantly evolving as maintainers spread it's area of control, making it difficult to follow.

[jake]

First of all, the systemd-cancer is nothing more than an init. A huge, grossly bloated, inefficient, unsecure, hideous, spaghetti-coded blob of an init, but just an init nonetheless. There are many inits.

Second, the systemd-cancer has absolutely nothing to do with Linux (the kernel). This isn't going to change any time soon, as the kernel maintainer has decreed it so.

Third of all, most of the other little bits & bobs that make up a running system aren't even aware that the systemd-cancer exists, much less require it in order to do their jobs.

Thus, it is easy to put together a very usable system based on the Linux kernel without requiring even a sniff of the stinking mess known as the systemd-cancer.

This is not going to change any time soon.

Also note, the systemd-cancer is not part of the GNU toolkit ... and most of that toolkit consists of small tools, each of which does one thing very well. The bloated monstrosities like EMACS (sorry, rms!) are the exception, not the rule.

[Adrian 4]

Emacs bloated ?

It might be 'eight megs and constantly swapping' but have you see VS Code ?

[jake]

Note that the "eight megs" was the amount of RAM in the machine, not the size of the code.

Yes, VS is bloated. That doesn't preclude other code from also being bloated ... and remember that bloated is a relative term.

[Anonymous Coward]

You must remember that when Emacs was first written, it could only run on something like a VAX or equivalent. There were no PCs with that much memory; the physical limits of even an 8086 (a "high end" machine; a programmer's "workstation") precluded anything more than 4MB on them. There was a keyboard-compatible variation called micro Emacs around for such machines that ran quite well (it was my favourite editor for a few years, as the enhancements vim brought to vi didn't exist yet.)

[Peter Gathercole]

Ahem.

I might point out that vi needed a VAX to run as well. I tried to get it to run on a PDP11/34 with 2MB of memory, and because of the 16 bit process address space limitation, vi was too big.

I'm sure that Jake will say that it ran on separate I&D PDP11s like the 11/7x, 11/44. and 11/8x systems, but I would still expect that it was a memory hog on those systems.

[jake]

The first versions of Joy's vi weren't called vi (we called it "ex in visual mode" or "Bill's ex") until version 2, when it became vi ... These all ran fine on smaller PDP11s, at least until until version 3 (2.13 was the same thing as version 3, but without the enhancements[0] that were the cause of the major number change). The 3.0 release was big enough that it required overlay code (a version of paging) to run on the 16 bit machines. If you didn't have the overlay software (available from Version 7 with the 2BSD patches), or your machine was otherwise under powered, you happily ran 2.13. I still run a somewhat modified 2.13 on a couple of the older machines in my collection.

[0] This included debugging (trace?), the VAX/unix vfork system call, lisp hacks, ability to edit encrypted files, and a couple other bits & bobs that have slipped my mind. Seems to me that enabling debugging made it too large for any PDP11.

[Peter Gathercole]

I did try to build it with the overlay loader, but never got it working. But then, I didn't really try that hard, as my system mainly ran RSX-11M. But playing with that, I realized that the techniques could be applied to other systems, and I wrote a simple overlay system for the BBC Micro that allowed programs to be much larger than the available memory.

During the day, RSX prevailed except when there were classes that needed UNIX (the prime reason for putting UNIX on it in the first place was to teach Relational Database using Ingres). Although I could do some things during those classes, Ingres was heavy on a system of this size so I could not do too much.

During the days of the week, I had a two hour maintenance window, which if I hurried the backups allowed me to boot UNIX for an hour (exchangeable disk packs were so useful!) I also had UNIX running one evening a week (during term time) when I had other things that kept me there.

The vacations gave me the best time to play, but again I had other things to do during that time.

[Doctor Syntax]

AFAIK the Gnome crowd are trying to make systemd essential to their stuff. As far as I'm concerned they're welcome to each other but if too much other stuff just assumes systemd and its tentacles are there to be used then it could become worrying time to move to BSD.

[Anonymous Coward]

I stopped using Gnome quite some time ago. I install Ubuntu Mate instead. You can't remote a Gnome session, so I don't want it taking over the console.

Gnome stopped being useful when they migrated to Wayland.

[Doctor Syntax]

As recently as that?

[DrXym]

How is it bloated, inefficient or insecure? Systemd has lots of small executables running on the principle of least privilege. It doesn't run something unless it needs to and when it does, that thing has a very specific task which it is configured to do. It is actually the opposite of what you assert.

[Adair]

It's not 'bloated' in a monolithic sense, it's bloated as in more and more aspects of the user space are depending (optionally or not) on yet another little systemd package that has inserted itself between user space and the kernel.

Systemd is becoming a complete inescapable layer calling the shots between what I want to do and the kernel (and other lower level packages).

Potentially there isn't anything wrong with that, if it was needed and if there was no compulsion, given that there are plenty of other existing tools serving the various calls.

But, it seems we aren't being given that option. As time goes on app writers are tying their code into systemd packages, increasingly leaving other tools out in the cold.

It's not good. Rather like ringing my GP and facing the Reception Dragon who seems to be under the impression they have a medical degree and are entitled to decide whether or not I require the doctor's services. Well the dragon needs to wind their neck in, make a booking, or pass me over to someone qualified to make a sensible decision. The dragon is not the system.

In fact 'the dragon' shouldn't be a dragon at all, and should be replaced with someone who knows their place and behaves appropriately.

[mpi]

>a complete inescapable layer

https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd

BSD

https://www.linuxfromscratch.org/lfs/view/

[Anonymous Coward]

You're arguing with hysterical and paranoid old men in braces.

[DrXym]

There's definitely a touch of Amish about it - some kind of line the sand over which progress should not pass without some people losing their shit. Never mind that systemd is demonstrably capable, proven and offers a slew of benefits.

[anonymous boring coward]

The monster Emacs is tiny by today's standards. Can't fire up hardly anything in Windows that's smaller... But, yes, I remember using Jove instead. Nice editor.

[Doctor Syntax]

"for too long Linux (and the rest of us) has been riding on the ancient UNIX/POSIX design"

The reason I use Linux is that it implements that design.

[DrXym]

Replacing init.d with something better has always been an itch to scratch and systemd wasn't the first attempt to move away from it. Dists were using upstart before that and people weren't bitching and whining about upstart and seem to have conveniently forgotten that it existed. It's just fashionable to rag on systemd.

[Doctor Syntax]

"Dists were using upstart"

Another source of problems I have a bad memory of.

However as it didn't take over so many distros it was easier to ignore it than complain.

[bombastic bob]

I too am a BSD user, and prefer FreeBSD over Linux for a lot of things... but for certain benefits (like official support of RPi for example) Linux is often the better choice for production systems.

Still that means I have to *DEAL* *WITH* that 'S' word abomination (the init that shall not be named).

Yet if something is SO SUCCESSFUL then WHY TRY TO RE-INVENT IT ??

"Time for it to go its own way" - WHY ???

Others have commented that SystemD is a lot LIKE the way MS crammed everything into the registry. At first it was interesting until EVERYTHING DUMPED THEIR POLLUTION into it. I suppose SystemD will eventually grow in size (theme from The Blob playing in my head, the one by Burt Bacharach) until it becomes just as monolithic and "my god its full of CRAP" like the windows registry...

just how bad and icky do things have to get before people yell "STOP " loud enough for these JUNIOR engineers to HEAR IT? Let alone, LISTEN??

[Grumpy Rob]

What I don't get..

..is why you'd run Linux in a Windows subsystem??? If you want to run Linux (i.e. need the stability and security, don't need all the bloat and a bazillion services adding to your "user experience" barff), then just run it. If you need Windows to run a favourite program then run Windows in a VM, where it can't do too much damage.

[Anonymous Coward]

Re: What I don't get..

... why you'd run Linux in a Windows subsystem?

Why?

No idea.

But there's a myriad of deadbrain idiots who have drunk the it is so convenient KoolAid.

And then there's the "Look, Ma ... I'm running Windows on Linux!!!!" crowd.

But they don't know better.

The worst of all are the ones who actually push this crap, the ones with a hidden corporate agenda.

[Anonymous Coward]

Re: What I don't get..

VS Code and containers would be my answer for the question "why run WSL". I *love* having nice, clean, truly OS-independent development environments. And the performance seems to be fine with the WSL 2 backend. I'm willing to waste some CPU cycles to avoid the headaches of Windows always being the odd duck, and things breaking in strange ways when you just wanted to do some small changes on your work-issued laptop. Meanwhile, running development environment VMs is just far more clunky.

As a bonus, can avoid Docker Desktop with the help of WSL Probably would be even simpler to set it up with systemd available, to avoid having to launch dockerd manually (I have not checked in a few months)

[captain veg]

Re: What I don't get..

VS Code is available on Linux. No Windows required.

-A.

[Duncan Macdonald]

Re: What I don't get..

Running Linux from an emulated CD (or DVD) in a VM is one way to handle dangerous websites.

Start the VM, access the bad website(s) from the VM then shut the VM down - any crap that the website(s) download to the VM disappear when the VM is shutdown (assuming that there is no persistent storage allocated to the VM).

This might seem overkill but there are not many methods to allow a bad website to function without risking a PC if it is running Windows. (NoScript et al can stop bad website code from executing on a PC but often break websites that depend on Javascript etc.)

[JamesTGrant]

It’s actually all fine

systemd stuff is fine - suffers from a common name where really it should have lots of different names ‘systemd-init’ ‘systemd-time’ ‘systemd-networkd’ etc etc. The thing is, it’s ALL optional, none of it is preventing good work on other projects and some of it (systemd vs initv) is actually good and handy for many people. So, chill out - no one is making you use it - a default is only a default you like if you like the default.

Folk spouting off about systemd is so boring, it’s like complaining about the colour of your neighbour’s car.

Retreating in 5,4,3…

[Anonymous Coward]

Re: It’s actually all fine

Right, and your "poke the bear and run test" will get the usual response. Systemd is problematic for a long list of well documented reasons, and the ongoing vitriol is still here because the problem is still getting worse not better. Systemd is metastasizing into home folders next. Some people are noping off to BSD, and others at picking sides in the Linux or Lenux bun fight.

I think ideally it's fine if WSL gives people the option to run more than one Init, but expect howls if M$ migrates to systemd and the little d-heads start using is as another excuse to claim they are the "one true" pid 1 or leaning on other distros.

[Skiron]

Re: It’s actually all fine

Slackware, my friend. Clean, fast and just works.

[Mozzie]

Re: It’s actually all fine

You say 'ALL optional' like systemd can be swapped out at a click by the average user. It takes a lot of (hundreds/thousands of) hours by the MX and Devuan crew to eliminate the dependencies on systemd within their respective distros. That is not ALL optional by any distros standards.

Or do you mean optional as in you can pick a completely different non-mainstream distro to avoid systemd?

On the basis of your ALL optional theory I'd like an up to date edition of Ubuntu running on OpenRC where everything in the repos and PPA's will run without issue.

[wolfetone]

Re: It’s actually all fine

BURN THE HERETIC!!!!

[Anonymous Coward]

Re: It’s actually all fine

"Folk spouting off about systemd is so boring, it’s like complaining about the colour of your neighbour’s car."

No, more like car manufacturers all being convinced by a fuckwit that the accelerator should be the on the passengers side and then deciding that the brakes are a button on the back seat, then moving the steering wheel to the trunk and just for laughs seal the doors and make everyone use the sunroof to get in and out.

Just fucking crazy shit, for no reason.

[wolfetone]

Jeez, I feel sorry for Windows. For years it tried to extinguish Linux and Steve Ballmer called it a cancer. Now Windows is going to willfully inject the systemd cancer in to itself. It'd be funny if it wasn't so cruel.

Also, this is a joke surely?

"Systemd is an optional Linux component for managing services and other system software"

Bollocks is it optional. It comes installed and there's feck all you can do to remove it. Sure the guys at Devuan have done an amazing job of removing it as much as they can, but there are instances where you are forced to use it because a particular piece of software or library requires it.

[jake]

"Bollocks is it optional. It comes installed"

Slackware does not now, and currently has no plans to ever run the systemd-cancer. Seeing as Slackware is the oldest continuously maintained, and (arguably) the best Linux distribution available, your premise is clearly wrong.

"but there are instances where you are forced to use it"

"Forced"? Does that word mean what you think it means?

"because a particular piece of software or library requires it."

You might come close to convincing me if you can make a business case for one piece of software that requires it.

[wolfetone]

The last few times I've attempted to install PHP 7.4 FPM on Devuan, Normally you'd use Sury mirrors but they no longer offer it without systemd. Meaning you have to go through the process of compiling the code from source elsewhere in order to get it to run. I don't mind this on a hobby machine, but that's a different kettle of fish if it's on a work machine. The workload and potential complexity increase because of the inane requirement for systemd.

However, no matter how old Slackware is, it's not Linux as a whole. The vast majority of distributions elect to use systemd, with the exception of Devuan and a handful of others. So, as far I'm concerned and others who are in this position, systemd is forced upon you.

Genuinely, if systemd was so brilliant, so game changing, it'd be an option to select. A lot like how Wayland is an option or you can use X.org. I know it's unfair to compare the two like this, but the abstract idea is relevant.

[Tim99]

OK

You know how we all hate a smartarse who says "I told you so"?:-

Link 1 a conspiracy by Canonical (2015); Link 2 Canonical to distribute a "premium" commercial product (like Red Hat) that will tend to limit user and developer choice (2015); Link 3 How can we make money? (2018 - Satire?).

Well, I told you so.

[georgezilla]

Re: OK

Please.

Go ahead and say it.

They need to be reminded that you did.

[lvm]

Good job!

Let's make windows even more windowsy by offloading linux junk there.

[chuBb.]

We are all doomed

Why would anyone think this is a good idea just wait someone will take it upon them selves to get wsl systemd editing the host registry, this is the oppositite of a feature.

On other hand would make wsl more n00b friendly can follow any how do I tutorials for Ubuntu then, which could be useful I guess if you want to faff with hosts file and give wsl it's own host name (local db, dev machines use a local host alias for db), but really run a vm or containerise your dev environment in this day and age

[FIA]

Microsoft continued with its own init presumably for reasons related to the integration between WSL and the rest of Windows.

Yeah, that's the reason..... :)*

Although weirdly as systemd does try and make Linux more Windows like maybe it is the apropriate place for it?

_{* are we 100% sure it's not because after years and years of traumatic exposure to the Win32 API asking a dev to look at systemd is now considered a serious HR incident at MS?}

[Rich 2]

SSH

“… As far as some are concerned, this is a bug in WSL 2, in this case because an attempt to start the SSH daemon gave the error "System has not been booted with systemd as init system (PID 1). ”

Why do you need systemd to run sshd? I’ve never experienced this.

[Anonymous Coward]

Provided one can figure out the security sandboxing, and perhaps a few issues with control of hardware, this is something I would provisionally be very excited to see.

User experience is of course king with this type of problem. Wine, VM's are options for some, but when you are talking application space usability can become a bit of a blocker.

I am sure some sadist will want to create a bastard child of systemd talking to active directory at some point.

Bastardised hybrid uglyness aside; having things that help routes to WinExit along should generally be percieved as a good thing. With a workable linux desktop (inc. business applications) in hand, overhead of awful legacy APIs, registry, AD etc become motivating factors to move applications to linux native.

[sabroni]

WSL 2 users though have frequently requested systemd support.

You're holding it wrong.

[Pirate Dave]

Sad

"WSL 2 users though have frequently requested systemd support."

Those poor, ignorant bastards. They have no idea of the fresh hell they're asking for. They're probably just trying to follow recipes from StackOverflow or ServerFault, so they'll never know the feeling of a fresh breeze upon the cheek, or the warmth of the sun on their backs. Just mindless minions, working in the darkest mines of Redmond, looking for some faint glimmer of hope. I pity them.

(oh, I almost forgot -- fuck systemd! )

[georgezilla]

Re: Sad

" ... (oh, I almost forgot -- fuck systemd! ) ... "

Yea.

What you said.

[Allan George Dyer]

What we need...

is systemd integrated with the Windows Registry. Imagine the joy and convenience of systemd configuration held entirely in registry keys, so you can reconfigure the WSL using familiar Windows tools, and use systemd tools for updating arbitrary registry keys.

What could possibly go wrong?