You haven't solved A and E. Which shows how hard it is. An OS has to deal with programs crashing. It doesn't matter whether you think they should or shouldn't what matters is they do.
I don't know what you mean by.done and... I think you are responding to someone else.
I guess my first question is have you done mainframe? If I say something like central Kentucky horse region looks like England that only makes sense if you know rural England. Anyway columar isn't particularly mainframe. OTOH map/reduce is. The core idea of MR is to able to process records individually and the consolidate aggregates, unlike relational's table at a time. That's exactly what mainframes databases do. Or for example you can think of Kafka as a bank of tapes. Etc...
There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix
Disagreeing with the Unix way of doing things and not understanding the Unix way of doing things are not the same thing.
As for the mainframe.... no some of us have used systems that have had to handle contention well for decades.
What do you mean no batch in a modern world? Most of the world is still batch. For example the whole big data push is essentially cutting hardware costs and thus allowing for larger batch systems, going back to tape paradigms on hard drives using generic hardware. Obviously there isn't much one can do that's too intellegent other than avoid fragging with resource contention on real time.
As for a slow FTP taking 12 hours and wanting to suspend, I agree stupid use case. But I was saying that if such a thing were important than systemd should be extended to manage and schedule it.
Saving and restoring of state is something the process manager handles. Once the process manager knows what's needed it can decide how best to handle the problem.
Those aren't steps BTW they are options as indicated.
The computer works for me, not the other way around. If I explicitly tell the computer I want a process to continue running, it should do so.
If you are the admin and understand the issue, change the defaults. The people being discussed either
a) don't understand the behavior they want b) don't own the system.
What exactly is this assumption based on?
Standard procedures in use for generations.
Why shouldn't a user of a system be able to run a process that takes several days to complete?
In general they shouldn't because it is a shared resource and that's consuming too much of it. Once they start using a shared resource that heavily the activity should be scheduled or they should be using a dedicated or partially dedicated resource.
The system admin can easily control the users access to the system resources so that they're shared appropriately. What if it's the only user on the system?
Yes they can. And if they are doing that they systemd's defaults don't apply.
I think it is pretty obvious the systemd developers are neither lazy nor ignorant. They may disagree with you but those sorts of accusations don't deserve a response.
I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.
I think security is probably too strong. I'd say avoids annoyance and operational hassles is probably more fair. So you asking me to defend a position stronger than the one I'm advocating for.
Sure tons of enterprise apps. For example you have an app (A) tied to a database (B) tied to a virtual slave (C) copying information to kafka (D) which is being picked up by Hadoop process (E1) which then does batch transformation (F1) which then at the same time D is picked up by Spark (E2) which creates RDDs (F2) which then creates windows (G2) both F1 and G2 feed Elastic (H).
Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?
As for stopping process that what iOS does for most to conserve energy. Only those systems entitled to run in the background are allowed to run anything and even there the system makes the choice not the application.
Correct. systemd is part of a broader system that is replacing POSIX. No one is arguing that POSIX never existed. Nor is anyone arguing that systems that don't adopt won't be left behind. As for Solaris and AIX they both had process managers. Not getting terminated on logout was up to the process manager not the end user.
1) FTP command line registers with systemd that's its going to be doing a download over the next 12 hours from a slow server. 2) You run FTP from inside systemd telling the process manager this FTP is going to take 12 hours 3) After you start the FTP process you notify systemd
Runtime dependencies: Process A depends on B which depends on C which depends on D which depends on E. C crashes. You restart C. What do you do with A, B, D and E?
Of course there is good reason. Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.
Slashdot Mirror
You haven't solved A and E. Which shows how hard it is. An OS has to deal with programs crashing. It doesn't matter whether you think they should or shouldn't what matters is they do.
I don't know what you mean by .done and ... I think you are responding to someone else.
I guess my first question is have you done mainframe? If I say something like central Kentucky horse region looks like England that only makes sense if you know rural England. Anyway columar isn't particularly mainframe. OTOH map/reduce is. The core idea of MR is to able to process records individually and the consolidate aggregates, unlike relational's table at a time. That's exactly what mainframes databases do. Or for example you can think of Kafka as a bank of tapes. Etc...
Are you sure the change originated with systemd I had heard the opposite.
Done really? C's lost information about D. B has lost information about the new state of C. They weren't notified in your solution. How is that done?
There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix
Disagreeing with the Unix way of doing things and not understanding the Unix way of doing things are not the same thing.
As for the mainframe.... no some of us have used systems that have had to handle contention well for decades.
winning = increasing market share.
Checkpointing is an application function. Other than notifying the application or dumping all of memory how is a process manager going to checkpoint?
What do you mean no batch in a modern world? Most of the world is still batch. For example the whole big data push is essentially cutting hardware costs and thus allowing for larger batch systems, going back to tape paradigms on hard drives using generic hardware. Obviously there isn't much one can do that's too intellegent other than avoid fragging with resource contention on real time.
As for a slow FTP taking 12 hours and wanting to suspend, I agree stupid use case. But I was saying that if such a thing were important than systemd should be extended to manage and schedule it.
https://developer.apple.com/li...
Why not? Why should Unix be forever unable to handle scheduling and resource contention in intelligent ways?
Saving and restoring of state is something the process manager handles. Once the process manager knows what's needed it can decide how best to handle the problem.
Those aren't steps BTW they are options as indicated.
The computer works for me, not the other way around. If I explicitly tell the computer I want a process to continue running, it should do so.
If you are the admin and understand the issue, change the defaults. The people being discussed either
a) don't understand the behavior they want
b) don't own the system.
What exactly is this assumption based on?
Standard procedures in use for generations.
Why shouldn't a user of a system be able to run a process that takes several days to complete?
In general they shouldn't because it is a shared resource and that's consuming too much of it. Once they start using a shared resource that heavily the activity should be scheduled or they should be using a dedicated or partially dedicated resource.
The system admin can easily control the users access to the system resources so that they're shared appropriately. What if it's the only user on the system?
Yes they can. And if they are doing that they systemd's defaults don't apply.
I think it is pretty obvious the systemd developers are neither lazy nor ignorant. They may disagree with you but those sorts of accusations don't deserve a response.
I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.
Well I'll tell you about one. The longest running popular operating system on the planet: https://en.wikipedia.org/wiki/...
I think security is probably too strong. I'd say avoids annoyance and operational hassles is probably more fair. So you asking me to defend a position stronger than the one I'm advocating for.
I understand what saving state is. Reread the answer.
Sure tons of enterprise apps. For example you have an app (A) tied to a database (B) tied to a virtual slave (C) copying information to kafka (D) which is being picked up by Hadoop process (E1) which then does batch transformation (F1) which then at the same time D is picked up by Spark (E2) which creates RDDs (F2) which then creates windows (G2) both F1 and G2 feed Elastic (H).
C crashes who needs to be notified and how?
Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?
Pretty much yes they were. In theory there might have been hundreds of choices. In practice there were just a handful.
systemd allow you to have processes not tied to a session. That hasn't changed. You just have to tell the system and have permissions to do it.
You likely don't log out of your cell phone.
As for stopping process that what iOS does for most to conserve energy. Only those systems entitled to run in the background are allowed to run anything and even there the system makes the choice not the application.
Correct. systemd is part of a broader system that is replacing POSIX. No one is arguing that POSIX never existed. Nor is anyone arguing that systems that don't adopt won't be left behind. As for Solaris and AIX they both had process managers. Not getting terminated on logout was up to the process manager not the end user.
You have heard. Process management.
New system options
1) FTP command line registers with systemd that's its going to be doing a download over the next 12 hours from a slow server.
2) You run FTP from inside systemd telling the process manager this FTP is going to take 12 hours
3) After you start the FTP process you notify systemd
etc...
Runtime dependencies:
Process A depends on B which depends on C which depends on D which depends on E.
C crashes. You restart C. What do you do with A, B, D and E?
Of course there is good reason. Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.