The state of Ubuntu on Windows
-
-
@RaceProUK
Sure, let's look at the thread again more closely:@RaceProUK If we're talking about proper services, then there's only one place you need to look, and that's the Service Manager; other background tasks can be seen on the Start-up tab in Task Manager (on Win10; can't remember if older Windows have that same tab).
@Captain You do understand that he's saying that "proper services" and "background tasks" are not so different, and that Windows forces users to look in multiple places to figure out what is configured to run in the background, right?
@RaceProUK said in The state of Ubuntu on Windows:
@Captain And I pointed out that there's a single list that contains the lot. Your point?
@Captain said in The state of Ubuntu on Windows:
THAT THERE ISN"T A SINGLE LIST, AND YOU SAID SO.
-
@Captain I'm not sure if it's more amusing or pitiful that you really believe you have a point
-
@Captain
The Chrome background task won't be there when you aren't logged on. Even more, if multiple users are logged on simultaneously multiple Chrome background tasks could exist.
-
@RaceProUK The point is that you misunderstood somebody else's point and pointlessly disagreed with him while literally agreeing with him. The point is that you're a moron. Yes, it is pitiful.
-
@Captain said in The state of Ubuntu on Windows:
support of his position,
I think @flabdablet refers to you both. And he's right.
-
FWIW you're both arguing over stupid shit.
-
@loopback0 Isn't that the norm around here? ;)
-
@RaceProUK
Are you claiming we shouldn't?
-
-
@Luhmann I have to admit, I've totally lost track of what this is all about
I did try to flag for Jeffing, but the flag feature didn't want to do anything, so… @mods, can you do the needful? :cute-eyes:
-
@RaceProUK said in The state of Ubuntu on Windows:
I've totally lost track of what this is all about
That's my default state.
-
@RaceProUK said in The state of Ubuntu on Windows:
can you do the needful?
I didn't realize you where Indian?
"Please do the needful and revert" is my favorite indianism. It seems so pointless to do what is needed, and then undo it.
-
@MHolt said in The state of Ubuntu on Windows:
I didn't realize you where Indian?
I'm not; I'm British :P
No idea where I picked up that phrase tbh
-
@RaceProUK I figured as much.
I worked with some Indians at a client.They said it all the time.
Ever worked with Indians?
-
@MHolt I haven't actually, and I don't think I know anyone who has
-
@MHolt said in The state of Ubuntu on Windows:
They said it all the time.
Definitely wish I could be in a position to say "I have absolutely non idea what 'do the needful' means, please try again using English this time".Unfortunately I'd probably get myself fired...
-
@RaceProUK said in The state of Ubuntu on Windows:
Which makes it all the more amazing you claimed Chrome is a service
Who the fuck CARES what it technically is as long as it looks like a service, quacks like a service, and walks like a service?
I'm starting to think that working on the Microsoft ecosystem too much kills some very vital neurons, not unlike prolonged exposure to BASIC of any sort. You just find yourself attempting to rationalize this quackery of ad-hoc patching being thrown on because the old pants no longer fit the growing arse. In BASIC, I have seen people arguing that explicit line numbering was actually a good idea because they have never seen a decent text editor before, for chrissake!
Now you keep defending these petty differences between background processes and services that were invented because Microsoft had to somehow fit the pants of a single-user desktop system onto a multi-user server system that sometimes might have a desktop session, or a bunch of them.
Now when you happen to actively develop and test those services, you might find how easy and handy it is to break the assumptions of the wankers from the ivory towers of systems architecture, and how damn useful it is to have 1) services that start and stop with the whole system, 2) services that start and stop per user session no matter how many times said user is logged in to that particular system, 3) services that are launched per desktop session of the user, UI or not. Also, you find it useful to have the same fucking binary being able to launch both in foreground (so you can debug it) and in background. Something that Windows intentionally makes hard, because a program is one thing, an application is another, a program that has a console is still another, and a service is a totally different beast, thank gods for cygrunsrv.exe, though. What if I want a normally-GUI program that I can run in batch mode, feeding its data from STDIN? I guess I'm gonna be told to fuck off.
(And that's why things like this even happen; they're not heard about much in Unix land, but on Windows, all the time.)
But you know what? That's exactly how bugs happen. You have different code paths depending on how you run the program, because that's how you roll: your application must be aware of all the ways you want to run it. This is how you get the reports about "working ok as a user program and acting funny as a service," or vice versa.
Unix was like that for very long time. Daemons were not your usual happy programs, and had to do the complicated double-fork() dance to go into background properly, do setuid() and stuff. For many old greyball diehards, this is the Way Things Are, not to be changed.
Mac OS X got it right first: you don't do this stuff for launchd, its init system, as it does the "run in the background with proper sandboxing" stuff for you and you just make sure your program does its job, listens on sockets, implements protocols, makes your hair soft and silky, you name it.
Linux and *BSD have a bunch of different process managers that did the same (with process monitoring as a bonus), like supervisor and monit, but generally daemons, at least until now, were written to be able to go into background by themselves. Until recently, because systemd simplified things quite a lot. I still hear diehards bickering about it, but fuck them, really.
The rules are simple: your program runs in foreground, it responds to SIGTERM if it needs to be stopped, it responds to SIGHUP when we want it to reload the configuration. It's that simple. No mucking around with custom entry points. You can launch the same program from a console, attach a tracer to it, do whatever. No distinction. Why should anyone even care how I run my stuff? On system startup, in a user session, on a remote host, you name it, it's the user's business in the end.
-
@wft That's a very long-winded way of saying 'some programs are written badly'
-
@RaceProUK There was also a message about you having Stockholm syndrome.
-
@wft All I saw was "Windows is bad because services need to run under machine accounts" and "Linux is good because services need to run under machine accounts"
-
@RaceProUK Maybe re-attend those reading comprehension classes...
-
@wft Are you saying there's a difference between Linux having user and machine accounts and Windows having machine and user accounts?
-
@RaceProUK Nope.
Where do I even say the words "machine accounts"?
-
@wft Maybe it would help if you didn't take a thousand words to say 'some programs are written badly' and 'Linux is better even though it has the same distinctions as Windows'
-
@RaceProUK It fucking doesn't have the distinctions, or at least doesn't force them on you.
-
@wft Nor does Windows; there's literally nothing stopping you running a normal program under a machine account, or a service under a user account. How do I know this? Easy: I've run a service under a user account while I was debugging it.
-
@RaceProUK oh, so I can now write a, say, NodeJS program that just does
var sleep = require('sleep'); while (true) { console.log('RaceProUK is a liar'); sleep(10); }call
net start C:\Users\wft\src\raceproukisaliar.jsand watch the truth popping in the Event log every 10 seconds?
-
@wft No, because the Event Log isn't a console
-
@RaceProUK Why is there a difference? If I run my program as a service, the output pretty damn sure must go somewhere unless I explicitly silence it.
Talk about Linux having teh distinctions much, eh?
Anyway. That was the second part of what I said. I can assume the first part about net start works, right?
-
@wft said in The state of Ubuntu on Windows:
Why is there a difference?
For the same reason a printer is different to a monitor; they serve different purposes.
@wft said in The state of Ubuntu on Windows:
If I run my program as a service, the output pretty damn sure must go somewhere
And it goes to where you write it. If you write to the console, it goes to the console; if you write to the Event Log, it goes to the Event Log. Which, by the way, all programs can write to, not just services. The only thing 'special' about Windows services is they respond to signals from the Service Manager. That's literally it.
@wft said in The state of Ubuntu on Windows:
I can assume the first part about net start works, right?
The bit where you try to run a Node script without invoking Node? Good luck getting that to work.
-
-
@wft That'll run the script under whatever account
net startuses by default, but it'll still be writing to the console, not the Event Log. Unless the console is being redirected to the Event Log, but then that's not part of what makes a service a service.
-
@RaceProUK said in The state of Ubuntu on Windows:
And it goes to where you write it. If you write to the console, it goes to the console
How do I retrieve it after it went there? My program doesn't know if STDOUT is a console, after all.
-
@wft said in The state of Ubuntu on Windows:
How do I retrieve it after it went there?
Not my problem :P
@wft said in The state of Ubuntu on Windows:
My program doesn't know if STDOUT is a console, after all.
True. It could be a file, a serial port, a USB device, or anything really; depends where STDOUT is being directed.
-
@RaceProUK Oops, I'm getting the error
Error 1053: The service did not respond to the start or control request in a timely fashion.when I try the net start command. Guess I cannot turn my humble NodeJS program into a service this easy.
Also, I happen to know that for services, Windows redirects stdio handles to NUL with no means of redirection whatsoever. Because of this, a program has to be aware how it is launched: as a service, or from console, and choose its logging depending on this (in addition to a metric fuckton of other factors, like command line and configuration). Complexity goes up for no reason at all.
Also, Windows services that happen to do logging to files must implement any log rotation themselves.
Now, read again what I said about amount of boilerplate that must be implemented and maintained, in addition to whatever the actual purpose of that server, and you telling me it's actually a good thing. I call it the Stockholm syndrome of the Microsoft ecosystem programmers.
-
@wft said in The state of Ubuntu on Windows:
Because of this, a program has to be aware how it is launched: as a service, or from console, and choose its logging depending on this
I can see why you're so frustrated; I too find it annoying to decide between the Event Log, the Event Log, the Event Log, and the Event Log.
@wft said in The state of Ubuntu on Windows:
Now, read again what I said about amount of boilerplate that must be implemented and maintained
At most, a dozen lines; a miniscule fraction of the codebase of anything even remotely useful. And if you're smart about it, you can do it in under ten lines that will never need to be altered.
@wft said in The state of Ubuntu on Windows:
you telling me it's actually a good thing
One centralised location that manages all services via an easy-to-use GUI? Yeah, I'd say that's a good thing; beats arcane commands and folders full of scripts any day.
-
@wft said in The state of Ubuntu on Windows:
boilerplate that must be implemented and maintained
It's less than the crap that needs to go into an MSI package I'll bet. As for why? Well, you can take advantage of centrally managed, standard ecosystem that can take advantage of the fact that there's a set defined way of doing things.
Compared to Unix where you can have any variety of scripts and configurations and whatever that you need to maintain and configure and implement for each different service management overlord your distro uses.
-
@Tsaukpaetra I just find it amusing that I'm supposedly the one with Stockholm Syndrome, yet he's the one defending the more arcane, esoteric, and unintuitive system
-
Who really cares?
I can start a service on Ubuntu like this:
service apache2 startI can start a service on Windows like this:
net start "Apache"
-
@wft said in The state of Ubuntu on Windows:
I still hear diehards bickering about it, but fuck them, really.
Most people who bitch about systemd are idiots. The only valid criticism (IMO) is that it forces stuff like journald on us without offering an easy way to replace it with something else. (According to their wiki, the binary file format with all its problems is the only stable API.) Also, the fact that it only supports glibc sucks for some distros. Other than that, it's a huge step in the right direction.
-
@Tsaukpaetra said in The state of Ubuntu on Windows:
Compared to Unix where you can have any variety of scripts and configurations and whatever that you need to maintain and configure and implement for each different service management overlord your distro uses.
Or you could just provide a systemd unit file and let the anti-systemd idiots figure out how to start your service themselves.
-
@asdf journald and syslog can interoperate. Also, the "binary format" is actually a kind of "digital seal" appearing every so often in the files, and they are still human-readable even when not viewed with journalctl.
Which is not much of a problem, as journalctl allows viewing log files scooped from elsewhere, and is present on pretty much every mainstream distro these days.
-
@wft I don't know much about journald except from how to use journalctl, I only read that it can corrupt the log. Apparently, they chose to implement a lightweight DB themselves instead of using an existing, more robust solution:
https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd
https://bugs.freedesktop.org/show_bug.cgi?id=64116The point made in that blog post is a good one IMO: systemd is modular, but that's useless without loose coupling and stable APIs so that some of the components can be replaced with superior tools, if necessary.
-
@wft said in The state of Ubuntu on Windows:
In BASIC, I have seen people arguing that explicit line numbering was actually a good idea because they have never seen a decent text editor before, for chrissake!
I remember looking at code that didn't use line numbers and not understanding how you'd keep track of anything. It seemed like a jumble of chaos! Granted, I think I was 10 years old at the time.
-
@wft it's slightly more complicated than that, but yes, you can do pretty much exactly that.
there are programs out there that let you install any random executable as a service (what they basically do is register themselves as a service and register some registry entries to look up based on what service they are registered as to fork your process)
instsrv was one, part of the resource kit for windows NT/2000, and still worked as of XP (the last time i used it) I assume it still works today, and that if it doesn't someone has made a new one that does the same thing.
so yes, random exe as service is doable.
now you just have to find a way to wrap that nodejs program in an exe and you're done. I assume there's some utility out there that can do that too.
-
@boomzilla said in The state of Ubuntu on Windows:
I remember looking at code that didn't use line numbers and not understanding how you'd keep track of anything. It seemed like a jumble of chaos! Granted, I think I was 10 years old at the time.
Well, code was pretty hard to maintain when your editor was a hammer, chisel and stone tablets.
-
X scribo "Salve, mundum" XX ut X
-
@asdf said in The state of Ubuntu on Windows:
The only valid criticism (IMO) is that it forces stuff like journald on us without offering an easy way to replace it with something else.
That, and the fact that it does too much complicated work inside Pid 1.
I am quite sympathetic to the view that says given that the kernel assigns Pid 1 as the foster parent for processes that have lost their real parents by whatever accidental means, and is therefore the only process that can clean up the resulting messes, Pid 1 must not die. It should also be possible to replace every component of a running system without rebooting it; but you can't actually replace a running Pid 1 without losing its blessed process ID. The best way to achieve both these ends is to make Pid 1 so trivial and so demonstrably bug-free that it never needs to change: its job should be to do fuck-all but kick off the rest of the userland and then hang about reaping orphaned processes. Every other thing that Pid 1 currently does should be hived off to Pid Something Else.
-
@boomzilla said in The state of Ubuntu on Windows:
It seemed like a jumble of chaos!
First language I ever used that didn't have line numbers was FORTRAN IV, and I can assure you that a dropped punchcard deck actually is a jumble of chaos.
