They're at least one-upping Google. Samsung makes you pay for it, stuffs it full of ads anyway. They're even stuffing ads into older devices you already paid full price for fair and square.
And to complete the idiocy, they can't figure out why sales are down.
None of those options have a single thing to do with saving state. You show no sign of understanding what we were talking about. Please Google "saving program state" and "checkpointing".
C runs under a restarter and the database re-connects on ENOTCONN. Done.
The restarter can be as simple as while true; do run; done. You'll probably want to echo something to a log in the restarter just so you can see how often it happens.
Can you name a case where that condition is more than theoretical? Preferably one where the correct answer isn't one script starts them all in order?
The closest thing I have seen of that nature is something depending on the database. If it gets a connection error on a query, it tries to reconnect. If it can't, it serves an error message.
Incorrect. Solaris worked much like non-systemd Linux works. Dettach from the controlling tty if you want to keep running. Either in the program itself or use screen or nohup to do it for you.
All systemd is doing is adding an incompatible behavior.
Funny, I've not seen this difficulty in development. All systemd "contributes" is yet another variation that has to be accounted for.
For example, the subject of TFA. Until systemd came along, there were a couple good ways to not get terminated on logout. They worked across *BSD, Solaris, Aix, Unicos, and the many flavors of Linux (perhaps Mac as well). Now, not so much.
That doesn't even begin to make sense. There is nothing more or less manual about systemd and it's not going to do anything for security (but potentially introduce new holes).
You may be a bit confused. What daemon? I'm talking about good old ftp on the command line. I connect and start a download that I expect to take 12 hours or so (huge file or slow server, doesn't matter why). How is the system going to save state such that when restored it's still connected and downloading?
For a service, there is no periodic wakeup. It just needs to block on accept. When a connection comes in, the accept call returns.
apt-get install sysvinit-core presents far fewer problems and future surprises. Why swat flies all day when I can just close the screen door?
Google "principle of least astonishment".
Beyond that, the question was "So other than again pointlessly changing the well known and understood API, what's the point of systemd again?", not "How can I turn/burn that particular wart off?
They've already resorted to unhiding updates that the user hid. What makes you think they won't undo other actions the user takes to explicitly reject an update?
Absolutely not. The job is running on the behalf of the user and should one go sideways, I need to know who to email about it. There is often more than one running at a time. Furthermore, they set up the data beforehand so it is owned by them and they will be the ones performing the post-analysis, so they need to own the output files.
Some run the jobs under screen, others prefer nohup.
In a larger group, there would be disk quotas to consider as well.
So other than again pointlessly changing the well known and understood API, what's the point of systemd again? How about just leave things the way they were?
That is, when the tty disconnects, it sends SIGHUP to the processes it controls. It's up to those apps to determine what is the right thing to do upon recieving SIGHUP.
Slashdot Mirror
You won't get much of a bargain on that considering how much of that 60 inches will be consumed by commercials.
They're at least one-upping Google. Samsung makes you pay for it, stuffs it full of ads anyway. They're even stuffing ads into older devices you already paid full price for fair and square.
And to complete the idiocy, they can't figure out why sales are down.
None of those options have a single thing to do with saving state. You show no sign of understanding what we were talking about. Please Google "saving program state" and "checkpointing".
Then why in your steps is there no save or restore of state?
C runs under a restarter and the database re-connects on ENOTCONN. Done.
The restarter can be as simple as while true; do run; done. You'll probably want to echo something to a log in the restarter just so you can see how often it happens.
Can you name a case where that condition is more than theoretical? Preferably one where the correct answer isn't one script starts them all in order?
The closest thing I have seen of that nature is something depending on the database. If it gets a connection error on a query, it tries to reconnect. If it can't, it serves an error message.
Since it would have been easier to name one, I conclude you have no idea.
Incorrect. Solaris worked much like non-systemd Linux works. Dettach from the controlling tty if you want to keep running. Either in the program itself or use screen or nohup to do it for you.
All systemd is doing is adding an incompatible behavior.
You're going to have to be more specific because I have process management now without systemd.
Go back up and figure out what we're talking about. The sub-topic here is saving state.
So name one.
Funny, I've not seen this difficulty in development. All systemd "contributes" is yet another variation that has to be accounted for.
For example, the subject of TFA. Until systemd came along, there were a couple good ways to not get terminated on logout. They worked across *BSD, Solaris, Aix, Unicos, and the many flavors of Linux (perhaps Mac as well). Now, not so much.
Linux long ago replaced all of those in most applications. I have yet to hear of anything systemd can do that wasn't already being done.
I just prefer well designed systems. Init may not be the best, but systemd is a step backwards.
That doesn't even begin to make sense. There is nothing more or less manual about systemd and it's not going to do anything for security (but potentially introduce new holes).
You may be a bit confused. What daemon? I'm talking about good old ftp on the command line. I connect and start a download that I expect to take 12 hours or so (huge file or slow server, doesn't matter why). How is the system going to save state such that when restored it's still connected and downloading?
For a service, there is no periodic wakeup. It just needs to block on accept. When a connection comes in, the accept call returns.
How will you keep TCP connections from timing out?
I have many linux systems. No systemd in sight. Never will be.
Consider it my vote of no confidence.
It's clear you have no idea how the principle of least astonishment works.
apt-get install sysvinit-core presents far fewer problems and future surprises. Why swat flies all day when I can just close the screen door?
Google "principle of least astonishment".
Beyond that, the question was "So other than again pointlessly changing the well known and understood API, what's the point of systemd again?", not "How can I turn/burn that particular wart off?
Apt-get install sysvinit-core seems to fix it...
How about the systemd kiddiez go get their own sandbox to play in?
Or at least quit proselytizing for a giant hairball that's hard to rip out.
They've already resorted to unhiding updates that the user hid. What makes you think they won't undo other actions the user takes to explicitly reject an update?
You mean other than forking off Devuan, for example?
Note that apparently nohup doesn't work when systemd is killing processes on logoff. That's because nohup follows POSIX standards but systemd doesn't.
Screen has worked just fine for many years, and still does unless someone screws up the system with systemd.
Absolutely not. The job is running on the behalf of the user and should one go sideways, I need to know who to email about it. There is often more than one running at a time. Furthermore, they set up the data beforehand so it is owned by them and they will be the ones performing the post-analysis, so they need to own the output files.
Some run the jobs under screen, others prefer nohup.
In a larger group, there would be disk quotas to consider as well.
So other than again pointlessly changing the well known and understood API, what's the point of systemd again? How about just leave things the way they were?
That is, when the tty disconnects, it sends SIGHUP to the processes it controls. It's up to those apps to determine what is the right thing to do upon recieving SIGHUP.