No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
Of course. Keeping track of running services is out of scope for a service management system. Genius.
It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.
Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.
Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.
Also note that I'm talking about the init system, and not about individual services doing their own logging.
While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)
No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.
There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.
Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.
Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)
I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.
Also, you might want to actually read about UNIX before you make these kinds of accusations.
I speak from personal experience
Reading taoup is a good place to start.
Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.
It does next to nothing. All the real functionality is in distribution specific scripts, which means you need to research and write a script for each distribution you want to support, each with its own particular features and idiosyncracies.
Each script is a bunch of boilerplate that has to reimplement the same stuff. Often badly, especially when an init script has to be improvised.
The functionality is inconsistent between services. Some can be restarted, some not. Some have a status command, some not.
To check whether a service is running, it uses pid files. Pid files are horribly unreliable and prone to failing if a pid file happens to be left around, and something else happens to use the same pid.
If you want start on demand, eg, something like xinetd, that's an entirely different system that's managed differently and separately.
If you want a service to get automatically restarted, that's also done with an entirely different system like monit.
It doesn't have useful logging. Processes can vanish into the ether without useful information in the logs because stderr may not be captured in some cases, and because init doesn't log service crashes.
Service providing services are tricky. You may know the daemon has started, but you don't know it's now accepting requests. Yay for "sleep" hacks.
Breaks horribly the moment something goes wrong. Network cable not plugged in? Well, if you boot like that nothing network related works, so you've got to log in and fix it by hand.
Because modern solar panels are just 20% efficient, which means you still get 80% of the heat. And the parts not covered by panels keep performing just like in any other car, so you can expect this thing to be what, 10% cooler in the best case?
It could run the AC, but then I suspect it'd get much less charging done.
It seems to still require an external pump, and liquid cooling didn't seem to take off yet except among hardcore overclocking enthusiasts. It's complicated, messy, and can fail in ways that are much worse than air cooling.
And what happens if those tiny channels erode or get clogged?
Or perhaps this is supposed to be paired with an OEM system intended to be maintenance free to solve such problems?
The article unfortunately is short on useful information.
What's the point of that? It's large, ugly as sin, and the concept only works assuming low use anyway. It's also not going to work as intended if you park it in a garage, inside parking spot, or in the shade.
I wonder if it's even practical in ideal conditions, because a car parked in the sun gets hot as hell, and batteries don't like that much.
It's much better to put those panels on your roof instead. That way you can go with cheaper and less efficient panels because there's less need to squeeze all the possible power in the small amount of room available, they'll be unobstructed as much as possible, collecting power at all times when there's any to collect, and it can be used for things besides the car.
You are ignoring how other countries have benefitted from our pollution. China's economy would still be shit with 2 billion starving people instead of 1 billion.
And the glazier benefits from broken windows. That your actions had an effect that was positive for somebody doesn't mean you get out of paying damages. See the broken window fallacy.
What's marxist about it? You break somebody's window, you have to pay them for the repairs. You poison somebody else's garden, you pay for having it replanted. This is pure capitalism and the very model libertarians propose.
Hah, I knew it. You have no ability to hold a technical discussion.
If there's somebody not needed here, it's people who are ignorant and proud of it. If you actually want to contribute something useful, start coding. You discredit your own cause by posting this nonsense.
Where else do you get to see somebody professing their love of the True Unix with Unix Philosophy, while repeatedly demonstrating ignorance of the very system they claim to love so much?
Allow me to impart a bit of education: some things have more than one manpage. For instance there's a manpage for both cron, and crontab, and Perl has a whole bunch of them. Any competent admin would know this and wouldn't be mystified by systemd having separate manpages for commandline tools and descriptions of unit files.
In sysv land, this is the difference between letting a service fork by itself and using start-stop-daemon. If you take the later approach, start-stop-daemon will perform the daemonization task on behalf of the service. In such a case if it ever prints on stderr, it will be lost in the void, since it's no longer connected to any terminal. systemd actually will ensure it goes into the log.
Actually no, it hasn't. sysv init has long been a pile of hacks on top of a pile of hacks. Ever tried to write a sysv service? It's really wonderful when a service refuses to come up because the pid file was left around for whatever reason, and some other program happens to be running under that pid.
For instance, the stderr thing this guy is complaining about was long a "feature" of sysv systems, where stderr could actually disappear into the void. Systemd actually makes things much better by ensuring stderr always gets saved.
As to why change logging, under systemd you can trivially ask for the messages for a particular service, or the messages from last boot, without having to figure out what to grep for, or having to setup syslogd beforehand to sort out your messages into separate files.
That's a stupid attitude to have in a field that moves as fast as computing. The internet didn't exist in anything resembling the current shape 30 years ago, just to give an example. You don't get to excuse ignorance of networking just because of that. I don't see how it's viable remaining a sysadmin without dealing with the fact that the hardware, software, and needs of the organization are constantly changing.
Nevertheless, all it takes is "ForwardToSyslog=yes" in journald.conf.
No, it is not. The string "forking" isn't anywhere in the man page for systemd on Red Hat. Considering Poettering works for Red Hat, that is a pretty big omission if you're right that it is the solution, and it isn't considering I have that in the unit file.
That's because the systemd manpage is about the main application. You want the systemd.service manpage.
Not so much propaganda as well known psychological phenomena. Some people switch to diet drinks and decide that since they consume less calories now, they can have an extra piece of ice cream. Often that turns out to more than offset the gains.
Sounds like he's badly confusing something. I think he's badly misunderstanding how a rectifier works. Some waste of course happens, but not nearly that much.
And that 230k is less than a drop in a very, very, large bucket.
For the company itself, sure. For that particular department, it's probably a serious amount of cash, and is likely to get whoever gets blamed for it in trouble.
This assumes customers will always pay whatever is asked for them. If TW could charge more, they already would.
Also, a tax deduction doesn't mean it's free for them. All it means they get to substract $229,500 from their taxable income. They still have to pay $229,500 out of their pocket.
And then what? Slashdot needs money on a regular basis.
Slashdot would need a way of getting enough people to pay to sustain itself, and that seems tricky. The audience is tech savvy with adblock and other places like reddit offer more value and still have trouble earning money.
What I thought from the description is that a neural network was taught how to play Magic and somehow generated new cards by trying to play with them. Think for instance of a program that tries to come up with a new chess piece by coming up with a movement pattern, playing games with that piece and trying to figure out whether it'd be useful or interesting to play with.
This on the other hand looks like something like a markov chain generator. Amusing nonsense that can give humans fun ideas.
I think it comes from the tax paid by the company, actually.
At any rate, I have no problem with part of my tax money being used to ensure people aren't screwed over. Of all the things tax money goes into, this one seems very reasonable to me.
Slashdot Mirror
Since systemd was mentioned I figured that sysv init + rc scripts was implied, otherwise it's not a really fair comparison.
Of course. Keeping track of running services is out of scope for a service management system. Genius.
It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.
Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.
Also note that I'm talking about the init system, and not about individual services doing their own logging.
No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.
Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.
I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.
I speak from personal experience
Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.
Okay, sure.
Because modern solar panels are just 20% efficient, which means you still get 80% of the heat. And the parts not covered by panels keep performing just like in any other car, so you can expect this thing to be what, 10% cooler in the best case?
It could run the AC, but then I suspect it'd get much less charging done.
It seems to still require an external pump, and liquid cooling didn't seem to take off yet except among hardcore overclocking enthusiasts. It's complicated, messy, and can fail in ways that are much worse than air cooling.
And what happens if those tiny channels erode or get clogged?
Or perhaps this is supposed to be paired with an OEM system intended to be maintenance free to solve such problems?
The article unfortunately is short on useful information.
That's just 18 days worth of video at 30 fps. You'd think that they could have done something more interesting with that than a counter.
What's the point of that? It's large, ugly as sin, and the concept only works assuming low use anyway. It's also not going to work as intended if you park it in a garage, inside parking spot, or in the shade.
I wonder if it's even practical in ideal conditions, because a car parked in the sun gets hot as hell, and batteries don't like that much.
It's much better to put those panels on your roof instead. That way you can go with cheaper and less efficient panels because there's less need to squeeze all the possible power in the small amount of room available, they'll be unobstructed as much as possible, collecting power at all times when there's any to collect, and it can be used for things besides the car.
Quartz is the technically superior solution. Gears may have a nostalgic appeal but are less accurate.
And the glazier benefits from broken windows. That your actions had an effect that was positive for somebody doesn't mean you get out of paying damages. See the broken window fallacy.
What's marxist about it? You break somebody's window, you have to pay them for the repairs. You poison somebody else's garden, you pay for having it replanted. This is pure capitalism and the very model libertarians propose.
Hah, I knew it. You have no ability to hold a technical discussion.
If there's somebody not needed here, it's people who are ignorant and proud of it. If you actually want to contribute something useful, start coding. You discredit your own cause by posting this nonsense.
You systemd haters are really hilarious.
Where else do you get to see somebody professing their love of the True Unix with Unix Philosophy, while repeatedly demonstrating ignorance of the very system they claim to love so much?
Allow me to impart a bit of education: some things have more than one manpage. For instance there's a manpage for both cron, and crontab, and Perl has a whole bunch of them. Any competent admin would know this and wouldn't be mystified by systemd having separate manpages for commandline tools and descriptions of unit files.
Actually it is a step forward.
In sysv land, this is the difference between letting a service fork by itself and using start-stop-daemon. If you take the later approach, start-stop-daemon will perform the daemonization task on behalf of the service. In such a case if it ever prints on stderr, it will be lost in the void, since it's no longer connected to any terminal. systemd actually will ensure it goes into the log.
Actually no, it hasn't. sysv init has long been a pile of hacks on top of a pile of hacks. Ever tried to write a sysv service? It's really wonderful when a service refuses to come up because the pid file was left around for whatever reason, and some other program happens to be running under that pid.
For instance, the stderr thing this guy is complaining about was long a "feature" of sysv systems, where stderr could actually disappear into the void. Systemd actually makes things much better by ensuring stderr always gets saved.
As to why change logging, under systemd you can trivially ask for the messages for a particular service, or the messages from last boot, without having to figure out what to grep for, or having to setup syslogd beforehand to sort out your messages into separate files.
That's a stupid attitude to have in a field that moves as fast as computing. The internet didn't exist in anything resembling the current shape 30 years ago, just to give an example. You don't get to excuse ignorance of networking just because of that. I don't see how it's viable remaining a sysadmin without dealing with the fact that the hardware, software, and needs of the organization are constantly changing.
Nevertheless, all it takes is "ForwardToSyslog=yes" in journald.conf.
That's because the systemd manpage is about the main application. You want the systemd.service manpage.
What are you on about?
There's your stdout and stderr.
Not so much propaganda as well known psychological phenomena. Some people switch to diet drinks and decide that since they consume less calories now, they can have an extra piece of ice cream. Often that turns out to more than offset the gains.
Sounds like he's badly confusing something. I think he's badly misunderstanding how a rectifier works. Some waste of course happens, but not nearly that much.
For the company itself, sure. For that particular department, it's probably a serious amount of cash, and is likely to get whoever gets blamed for it in trouble.
This assumes customers will always pay whatever is asked for them. If TW could charge more, they already would.
Also, a tax deduction doesn't mean it's free for them. All it means they get to substract $229,500 from their taxable income. They still have to pay $229,500 out of their pocket.
And then what? Slashdot needs money on a regular basis.
Slashdot would need a way of getting enough people to pay to sustain itself, and that seems tricky. The audience is tech savvy with adblock and other places like reddit offer more value and still have trouble earning money.
What I thought from the description is that a neural network was taught how to play Magic and somehow generated new cards by trying to play with them. Think for instance of a program that tries to come up with a new chess piece by coming up with a movement pattern, playing games with that piece and trying to figure out whether it'd be useful or interesting to play with.
This on the other hand looks like something like a markov chain generator. Amusing nonsense that can give humans fun ideas.
I think it comes from the tax paid by the company, actually.
At any rate, I have no problem with part of my tax money being used to ensure people aren't screwed over. Of all the things tax money goes into, this one seems very reasonable to me.
No, they don't lose. France isn't the US. The AGS guarantees the employees will get paid.