Dude it is time for you to accept init lost. The principle of least astonishment is following systemd policies. The reason you are being astonished is because you are expecting things to work like they did in the days of init.
Everyone would have been happier if one of the other solutions had panned out. The Linux community isn't used to someone just winning. They are much more used to choice. But openrc and upstart both failed. Someone won, and now we have a new standard.
There are many distributions that don't use systemd but they are more niche. Try something like puppy if you hate systemd.
POSIX is decades old. POSIX was designed to solve the problem of competing big box unix solutions and the difficulty of writing software for all of them. We don't have that problem anymore Linux bankrupted most of them and the rest are being shutdown slowly. big box Unix is dead and Linux now has to deal with their customers.
It is still difficult to write software for the various Linux distributions but POSIX doesn't help that. LSB is likely the new POSIX. And LSB is actively supporting systemd as an option.
This is Linux. Software competes. Upstream gets to decide what mainstream distributions do. At this point the alternative approaches get a sandbox and they have to convince people they have a viable approach. (excluding on embedded where non-systemd distributions are doing fine for now).
RedHat is a corporation fighting for licensing fees in enterprise and cloud. They are supportive of the Linux base but not enough to endanger the people who pay them.
The point of systemd is process management. To give to Linux what Solaris, Digital Unix, AIX... have for big box. To give Linux what mainframes have (or at least some fraction of it) since Linux is replacing those use cases. And on the desktop to give Linux what Windows and OSX have.
How does an admin allow you as a user to run arbitrary code that consumes arbitrary resources and protect everyone else? He can have an operations staff or maybe a scheduler but that's precisely what systemd is laying the groundwork for and making possible on Linux.
How many "multi user" systems are left anymore anyway?
Many billions. There are now many dozenss of exabyte datacenters. Those aren't filled with single user machines. AT&T sells over 1/2 their cellular bandwidth to embedded systems.
The single user computer is still important but it is not the norm.
This is standard on OSX and has been part of Unix for many years.
If there is a just a slow FTP then everything is fine. Slow is not the same as off. If it goes off, then the daemon (if configured) wakes periodically and checks if it can resume. The system process monitor decides though when the right time to run these "it can wait' daemons.
As for distros that is what's happening. There are systemd distros and non systemd distros and they are forking further and further apart.
Process management is exactly what this article is about. There are no more serial terminals. The current state looks nothing like a bunch of physically wired terminals in a computer room and getty shouldn't exist. It should simply be replaced with something that fits the current paradigms.
As for sshd: sshd should be registering activities that need to survive outside a session with systemd. It has no way of knowing anything about global resources pools and can't make any intelligent decisions about how to handle scheduling. Its hard to think of a worse place.
That's standard behavior in OSX and iOS. Its easy to do once you start pushing through the idea that the OS's process manager decides what is going to be running.
The problem is the process shouldn't get to decide if they live forever that's the process manager's job. And ultimately on a shared system you as an unprivileged user likely shouldn't have the ability to run jobs consuming resources for days or weeks directly but rather through operations. That's not to say that there may not be reasons but some set of behaviors has to be the default and it seems sensible for me for operations / administration to default as regulating huge tasks rather than individual users and the software they run.
The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.
What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.
That's an excellent link. But you are forgetting the absolutely key point. What is the scope of the "program" to which the claim is being made? With static linking it is often the linked version, with dynamic the unlinked.
The binary is almost always considered a derived work. If you statically link and then distribute that's very different, you are making a copy. If you distribute source and the recipients statically link then that's likely the same thing but may not be.
As for the lawyers, the lawyers may not understand this area of law is rather specialized and very technical. The existing case law is the best source.
Then in that case they are making money as the point of sale, distributor, some of the print shop money (organizing), often the artist, recording company.... The fact that they are also the artist is incidental. They are just cutting out most of the other players and doing the work themselves.
Its not really apples to apples, those other parts still exist.
Using something doesn't invoke copyright, I have to copy it. For example if I buy a book and the license holder doesn't get to decide if I use it for kindling, stop a door jam with it or read it. The question with a derived library is whether an act of copying took place. No copying, no copyright violation. What constitutes copying as contrasted with referencing is the legal issue.
What is a derivative work is a question of judgement. There are criteria but it is not so clear cut.
If program X can dynamically link to A or B where A and B have different license holders than X is very unlikely to be considered a derived work. The same way that raw HTML code is not considered a derived work of internet explorer.
I not sure I agree with the premise of the question. But assuming it were true both parts openly have and have had a cloud migration strategy for their customers. The corporate managed services and government services parts (which in your premise would be the non database) are the most enthusiastic.
Oracle has a pretty good cloud service. They sell their database to other services especially Verizon. There is no bag they have been openly talking about moving towards administering the database and away from just selling licensing.
GPL never claimed it could go further than "derived work". Static linking is worse than dynamic linking. Intermixing source code worse than just static linking and everyone agrees this almost invariable creates a derived work. LGPL doesn't allow for linking explicitly. This ruling allows for reimplementing APIs which is even less than dynamic linking.
Families consume less resources per person than singles. For example when I used to take my child to Disney regularly I'd spend 2 hrs sitting on a bench giving her a nap. You think I ever did something like that when I took a date or a friend to an amusement park as a single?
Slashdot Mirror
Dude it is time for you to accept init lost. The principle of least astonishment is following systemd policies. The reason you are being astonished is because you are expecting things to work like they did in the days of init.
Everyone would have been happier if one of the other solutions had panned out. The Linux community isn't used to someone just winning. They are much more used to choice. But openrc and upstart both failed. Someone won, and now we have a new standard.
There are many distributions that don't use systemd but they are more niche. Try something like puppy if you hate systemd.
POSIX is decades old. POSIX was designed to solve the problem of competing big box unix solutions and the difficulty of writing software for all of them. We don't have that problem anymore Linux bankrupted most of them and the rest are being shutdown slowly. big box Unix is dead and Linux now has to deal with their customers.
It is still difficult to write software for the various Linux distributions but POSIX doesn't help that. LSB is likely the new POSIX. And LSB is actively supporting systemd as an option.
This is Linux. Software competes. Upstream gets to decide what mainstream distributions do. At this point the alternative approaches get a sandbox and they have to convince people they have a viable approach. (excluding on embedded where non-systemd distributions are doing fine for now).
RedHat is a corporation fighting for licensing fees in enterprise and cloud. They are supportive of the Linux base but not enough to endanger the people who pay them.
The point of systemd is process management. To give to Linux what Solaris, Digital Unix, AIX... have for big box. To give Linux what mainframes have (or at least some fraction of it) since Linux is replacing those use cases. And on the desktop to give Linux what Windows and OSX have.
How does an admin allow you as a user to run arbitrary code that consumes arbitrary resources and protect everyone else? He can have an operations staff or maybe a scheduler but that's precisely what systemd is laying the groundwork for and making possible on Linux.
How many "multi user" systems are left anymore anyway?
Many billions. There are now many dozenss of exabyte datacenters. Those aren't filled with single user machines. AT&T sells over 1/2 their cellular bandwidth to embedded systems.
The single user computer is still important but it is not the norm.
And tell your system you want that. You can change default config on Unix.
This is standard on OSX and has been part of Unix for many years.
If there is a just a slow FTP then everything is fine. Slow is not the same as off. If it goes off, then the daemon (if configured) wakes periodically and checks if it can resume. The system process monitor decides though when the right time to run these "it can wait' daemons.
As for distros that is what's happening. There are systemd distros and non systemd distros and they are forking further and further apart.
Process management is exactly what this article is about. There are no more serial terminals. The current state looks nothing like a bunch of physically wired terminals in a computer room and getty shouldn't exist. It should simply be replaced with something that fits the current paradigms.
As for sshd: sshd should be registering activities that need to survive outside a session with systemd. It has no way of knowing anything about global resources pools and can't make any intelligent decisions about how to handle scheduling. Its hard to think of a worse place.
That's standard behavior in OSX and iOS. Its easy to do once you start pushing through the idea that the OS's process manager decides what is going to be running.
The problem is the process shouldn't get to decide if they live forever that's the process manager's job. And ultimately on a shared system you as an unprivileged user likely shouldn't have the ability to run jobs consuming resources for days or weeks directly but rather through operations. That's not to say that there may not be reasons but some set of behaviors has to be the default and it seems sensible for me for operations / administration to default as regulating huge tasks rather than individual users and the software they run.
The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.
What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.
That's an excellent link. But you are forgetting the absolutely key point. What is the scope of the "program" to which the claim is being made? With static linking it is often the linked version, with dynamic the unlinked.
The binary is almost always considered a derived work. If you statically link and then distribute that's very different, you are making a copy. If you distribute source and the recipients statically link then that's likely the same thing but may not be.
As for the lawyers, the lawyers may not understand this area of law is rather specialized and very technical. The existing case law is the best source.
Then in that case they are making money as the point of sale, distributor, some of the print shop money (organizing), often the artist, recording company.... The fact that they are also the artist is incidental. They are just cutting out most of the other players and doing the work themselves.
Its not really apples to apples, those other parts still exist.
Good answer across. Yes you understood my intent here and in your other responses.
Using something doesn't invoke copyright, I have to copy it. For example if I buy a book and the license holder doesn't get to decide if I use it for kindling, stop a door jam with it or read it. The question with a derived library is whether an act of copying took place. No copying, no copyright violation. What constitutes copying as contrasted with referencing is the legal issue.
What is a derivative work is a question of judgement. There are criteria but it is not so clear cut.
If program X can dynamically link to A or B where A and B have different license holders than X is very unlikely to be considered a derived work. The same way that raw HTML code is not considered a derived work of internet explorer.
I not sure I agree with the premise of the question. But assuming it were true both parts openly have and have had a cloud migration strategy for their customers. The corporate managed services and government services parts (which in your premise would be the non database) are the most enthusiastic.
Oracle has a pretty good cloud service. They sell their database to other services especially Verizon. There is no bag they have been openly talking about moving towards administering the database and away from just selling licensing.
GPL never claimed it could go further than "derived work". Static linking is worse than dynamic linking. Intermixing source code worse than just static linking and everyone agrees this almost invariable creates a derived work. LGPL doesn't allow for linking explicitly. This ruling allows for reimplementing APIs which is even less than dynamic linking.
Families consume less resources per person than singles. For example when I used to take my child to Disney regularly I'd spend 2 hrs sitting on a bench giving her a nap. You think I ever did something like that when I took a date or a friend to an amusement park as a single?
I doubt very much the artist is getting $8-14 on a $10-15 CD. Between the wholesaler and the seller the record company isn't getting nearly that much.