100% correct. People here are stupid for not seeing that progression.
By which you mean "people here aren't a Clever Little Boy like me for being skeptical that it's an inevitable progression". Free clue: a slippery-slope argument is often no more than a cheap trick.
I have been saying for years that eventually only "authenticated" devices will be allowed on the Internet.
And presumably there's a point in time after which, if it doesn't happen, you can be treated as having been proven wrong, correct? If not, then the use of "eventually" is another cheap trick.
I don't think you're reading that right. To me, that first part reads like throwaway text that has nothing to do with what follows, even though they're trying to pretend it does. Like this:
So by "I don't think you're reading that right" you mean "you're not reading into it what I'm reading into it".
However, large parts of the public remain apprehensive about data collection and consider that more transparency is needed. Online platforms must respond to these concerns by more effectively informing users what personal data is collected and how it is shared and used, in line with the EU data protection framework.[36] More generally, this issue includes the ways in which users identify themselves in order to access online platforms and services. It is recognised that a multitude of username and password combinations is both inconvenient and a security risk. However, the frequent practice of using one’s platform profile to access a range of websites and services often involves non-transparent exchanges and cross-linkages of personal data between various online platforms and websites. As a remedy, in order to keep identification simple and secure, consumers should be able to choose the credentials by which they want to identify or authenticate themselves. In particular, online platforms should accept credentials issued or recognised by national public authorities, such as electronic or mobile IDs, national identity cards, or bank cards.
which sounds like it would, at most, require "online platforms" to allow the use of national ID cards as credentials, but says nothing about requiring users to use them as credentials.
If you mean implementations of those protocols, a very important implementation was done at Berkeley.
Time to get schooled:
Nope, no schooling involved; I already knew about CYCLADES.
However, the Internet Protocol and the Transmission Control Protocol, in particular - which are, respectively, one of the network layers and transport layers of the stack to which the person who started this thread was referring - were developed as part of a DARPA project; the original poster wasn't referring to the entire concept of packet switching, but was referring to the protocols on the Internet. That doesn't mean that every single idea involved with them was a US invention, but it does mean that the development IPv4 and TCP in particular was paid for by the US Department of Defense.
Windows has never been for techies. We took one look at it in the 80's with no memory protection, 8.3 filenames, no multi-tasking, inability to address more than a 640K without horrible hacks, and said, "Uh... no thanks."
And decided that was sufficient to continue to reject it even after NT (standard multiple-address-space OS, long file names, multi-tasking, standard 32-bit address space) came out, presumably.
So many technical errors in this it should be deleted.
CDMA also didn't win any race, except for being patent encumbered that is. CDMA is seeing sunset well before GSM will be switched off.
By "CDMA" do you mean the concept of "code-division multiple access" or do you mean the cdmaONE/CDMA2000 mobile phone technologies from Qualcomm, both of which use code-division multiple access, but aren't the only mobile phone technologies that do so, either.
Apparently they're using it for items tagged "digital", because it has the word "digital" in it (the "D" in "DEC" being "Digital"), and if DRM stuff is tagged "digital" it's presumably because the "D" in "DRM" also stands for "digital".
Not that this means it makes sense. I suppose a better icon might be something with 1's and 0's in it, but maybe they decided that wasn't an obvious icon, so they used the logo of a computer company because it had the word "digital" in it.
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.
One thing that all of the non-Linux UN*X systems you mention have is the notion that if you run some process under nohup, it'll continue running after you log out. (Tested on OS X 10.11.4 and Solaris 11.)
What some people are complaining about with this configuration change to systemd-logind is that, with that change, if you run some process under nohup, it won't continue to run after you log out, so there's one thing that Solaris, OS X, etc. have that you don't have.
Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).
Harrumph El Capitan, d00d.
(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.
So perhaps screen, tmux, and nohup need to be modified to, on systems with systemd, do whatever the appropriate magic is necessary, just as is done on OS X.
Can we please get an architecture document from the Linux core developers LIMITING the scope of SystemD?
SystemD is supposed to be the Init / Service Management Daemon,
Can we, instead, get a project rename from the systemd developers, so that there's a name for the suite of programs they maintain that's not the same as the name of the process-1 daemon in that suite? That might keep people from making "that doesn't belong in the init daemon!" arguments about "systemd" when the "that" in question is being done by another daemon in the suite.
The offending behavior appears to be behavior of the systemd-logind daemon, which is the daemon that...
and it should have no responsibilities related to managing user sessions.
...is "a system service that manages user logins".
That's Getty's Job, or SSHD's Job, for example, which is unrelated to what SystemD needs to be doing.
Actually, getty, on many UN*Xes, is 1) run by the init daemon and 2) execs the login shell without forking, so that it doesn't stay around for the duration of the session, which means that the job of terminating the session when it's finished belongs to, err, umm, the init daemon.
Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).
Shouldn't that read: "Disclaimer: verified using hacked OS image in an unsupported environment, your mileage may vary."?
No, it shouldn't, because it is a standard El Capitan running on VMware Fusion, not a Hackintoshed version of El Capitan running on some hypervisor to which Apple haven't given permission to run standard OS X.
(Sorry about the name mixup; I've been jokingly calling it "El Camino" for a while, but I meant "El Capitan", not "El Camino".)
Ordinarily, a user's processes SHOULD all be killed on logout. They're no longer logged on; they're no longer using or entitled to use the machine.
For better or worse, that hasn't been the way UNIX worked since at least the 1975-vintage V6 - you could use nohup, redirect the standard input/output/error, and run in the background to make a process be a job that survives logging out.
However, there will be cases where something long-term needs to go on. How hard is it to add daemons or background services in an administrator or batch context? That's where the long-term stuff should go. Olde days with VM/CMS: CMSBATCH was available to ordinary users if some job would run too long to be practical in foreground in the user account. Submit; it runs when scheduled (by the user or the system, depending on load) and returns results to the user account.
Perhaps UNIX should have had such a mechanism since the beginning, rather than later, for example, getting the at/batch command. For what it's worth, it didn't, only getting it later.
The issue is the violation of POLA (principle of least astonishment) given that Unix has allowed processes to run after user exit through nohup(1), which dates back to at least 1986:
If you still have the screen up, you didn't log out. By default, all Unices have had it default that a logout causes termination of your scripts. Unless you're root or have something that keeps your session active (eg. the screen command if your admin allows it).
Or you nohupped whatever you ran.
If systemd is using anything other than SIGHUP to kill the jobs, it's not allowing nohupped jobs to continue to run, and may also break other programs as well.
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely.
The Unix Time-Sharing System has allowed that since Day One.
The question then is whether we should start treating that as a deficiency to be fixed, and in what ways it should be fixed, e.g. "should even nohupped jobs be killed?"
Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).
(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.
The Unix tradition has always been "you want your backgrounded processes to survive a logout, nohup them" - traditionally, when the tty driver saw that carrier dropped, it'd deliver SIGHUP, although I'm not sure all UN*Xes pseudo-terminal drivers deliver SIGHUP when the master side closes, that being the closest moral equivalent to carrier dropping; I think I've seen that not happen on OS X, but didn't dig through the pseudo-tty code in XNU enough to see why that wasn't happening or to determine whether that was intentional.)
The best part was when that vapid bitch got in front of a microphone to state quite plainly that they "didn't buy Oracle" just to file the suit against Google.
She is a lawyer, not a programmer. What she is saying is nonsense
Maybe she shouldn't be talking about something of which she is ignorant. Then again, she's an attorney and from what I've been able to observe, attorneys frequently talk out of their collective asses about things which they know nothing about, especially in technical or scientific fields.
A company I worked at a while ago was planning to threaten another company with a claim that "you couldn't possibly have implemented that without stealing our stuff"; I remember the threat letter repeatedly claiming it was "inconceivable" that they could have done that.
Maybe hyperbole is Standard Operating Procedure for lawyers in many situations - perhaps the belief is that if you can get the people to whom the hyperbole is addressed to believe it, you win.
Slashdot Mirror
100% correct. People here are stupid for not seeing that progression.
By which you mean "people here aren't a Clever Little Boy like me for being skeptical that it's an inevitable progression". Free clue: a slippery-slope argument is often no more than a cheap trick.
I have been saying for years that eventually only "authenticated" devices will be allowed on the Internet.
And presumably there's a point in time after which, if it doesn't happen, you can be treated as having been proven wrong, correct? If not, then the use of "eventually" is another cheap trick.
Clever people see it coming...
Some "clever" people see things that aren't there.
I don't think you're reading that right. To me, that first part reads like throwaway text that has nothing to do with what follows, even though they're trying to pretend it does. Like this:
So by "I don't think you're reading that right" you mean "you're not reading into it what I'm reading into it".
The Fine Document says:
which sounds like it would, at most, require "online platforms" to allow the use of national ID cards as credentials, but says nothing about requiring users to use them as credentials.
ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),
If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".
If you mean implementations of those protocols, a very important implementation was done at Berkeley.
Time to get schooled:
Nope, no schooling involved; I already knew about CYCLADES.
However, the Internet Protocol and the Transmission Control Protocol, in particular - which are, respectively, one of the network layers and transport layers of the stack to which the person who started this thread was referring - were developed as part of a DARPA project; the original poster wasn't referring to the entire concept of packet switching, but was referring to the protocols on the Internet. That doesn't mean that every single idea involved with them was a US invention, but it does mean that the development IPv4 and TCP in particular was paid for by the US Department of Defense.
(And as for networking and governments, well, said Pouzin (misspelled "Pouzim" in the paper) was working for the Institut de Recherche d'lnformatique et d'Automatique, and IRIA was, err, umm, a French government organization, so that's even more gummint involvement.)
ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),
If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".
If you mean implementations of those protocols, a very important implementation was done at Berkeley.
Or maybe they're hoping there's intelligent life somewhere up in space because there's bugger all down here on earth.
For those curious about the machine, here's the manual.
Windows has never been for techies. We took one look at it in the 80's with no memory protection, 8.3 filenames, no multi-tasking, inability to address more than a 640K without horrible hacks, and said, "Uh... no thanks."
And decided that was sufficient to continue to reject it even after NT (standard multiple-address-space OS, long file names, multi-tasking, standard 32-bit address space) came out, presumably.
And has he gotten a job with this consulting company?
But did he ever proactively leverage his synergies?
So many technical errors in this it should be deleted.
CDMA also didn't win any race, except for being patent encumbered that is. CDMA is seeing sunset well before GSM will be switched off.
By "CDMA" do you mean the concept of "code-division multiple access" or do you mean the cdmaONE/CDMA2000 mobile phone technologies from Qualcomm, both of which use code-division multiple access, but aren't the only mobile phone technologies that do so, either.
1. Quit using the DEC logo for DRM stuff.
Apparently they're using it for items tagged "digital", because it has the word "digital" in it (the "D" in "DEC" being "Digital"), and if DRM stuff is tagged "digital" it's presumably because the "D" in "DRM" also stands for "digital".
Not that this means it makes sense. I suppose a better icon might be something with 1's and 0's in it, but maybe they decided that wasn't an obvious icon, so they used the logo of a computer company because it had the word "digital" in it.
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.
One thing that all of the non-Linux UN*X systems you mention have is the notion that if you run some process under nohup, it'll continue running after you log out. (Tested on OS X 10.11.4 and Solaris 11.)
What some people are complaining about with this configuration change to systemd-logind is that, with that change, if you run some process under nohup, it won't continue to run after you log out, so there's one thing that Solaris, OS X, etc. have that you don't have.
Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).
Harrumph El Capitan, d00d.
(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.
To be fair, the OS X nohup, as well as, apparently, the OS X screen has been modified to call _vprocmgr_detach_from_console() , and that document is part of a version of tmux ported to OS X.
So perhaps screen, tmux, and nohup need to be modified to, on systems with systemd, do whatever the appropriate magic is necessary, just as is done on OS X.
Can we please get an architecture document from the Linux core developers LIMITING the scope of SystemD?
SystemD is supposed to be the Init / Service Management Daemon,
Can we, instead, get a project rename from the systemd developers, so that there's a name for the suite of programs they maintain that's not the same as the name of the process-1 daemon in that suite? That might keep people from making "that doesn't belong in the init daemon!" arguments about "systemd" when the "that" in question is being done by another daemon in the suite.
The offending behavior appears to be behavior of the systemd-logind daemon, which is the daemon that...
and it should have no responsibilities related to managing user sessions.
...is "a system service that manages user logins".
That's Getty's Job, or SSHD's Job, for example, which is unrelated to what SystemD needs to be doing.
Actually, getty, on many UN*Xes, is 1) run by the init daemon and 2) execs the login shell without forking, so that it doesn't stay around for the duration of the session, which means that the job of terminating the session when it's finished belongs to, err, umm, the init daemon.
Log out = no more of your processes. Normal. Having "nohang" processes, for a regular user != root, is the exception.
If by "nohang" you mean "nohup", then, yes, it is an exception, in the sense that you have to run the command with nohup.
However, with the configuration change being discussed here, nohupping a process apparently isn't sufficient to allow it survive a logout.
Shouldn't that read: "Disclaimer: verified using hacked OS image in an unsupported environment, your mileage may vary."?
No, it shouldn't, because it is a standard El Capitan running on VMware Fusion, not a Hackintoshed version of El Capitan running on some hypervisor to which Apple haven't given permission to run standard OS X.
(Sorry about the name mixup; I've been jokingly calling it "El Camino" for a while, but I meant "El Capitan", not "El Camino".)
Ordinarily, a user's processes SHOULD all be killed on logout. They're no longer logged on; they're no longer using or entitled to use the machine.
For better or worse, that hasn't been the way UNIX worked since at least the 1975-vintage V6 - you could use nohup, redirect the standard input/output/error, and run in the background to make a process be a job that survives logging out.
However, there will be cases where something long-term needs to go on. How hard is it to add daemons or background services in an administrator or batch context? That's where the long-term stuff should go. Olde days with VM/CMS: CMSBATCH was available to ordinary users if some job would run too long to be practical in foreground in the user account. Submit; it runs when scheduled (by the user or the system, depending on load) and returns results to the user account.
Perhaps UNIX should have had such a mechanism since the beginning, rather than later, for example, getting the at/batch command. For what it's worth, it didn't, only getting it later.
The issue is the violation of POLA (principle of least astonishment) given that Unix has allowed processes to run after user exit through nohup(1), which dates back to at least 1986:
More like "at least 1975" - nohup dates at least back to V6.
If you still have the screen up, you didn't log out. By default, all Unices have had it default that a logout causes termination of your scripts. Unless you're root or have something that keeps your session active (eg. the screen command if your admin allows it).
Or you nohupped whatever you ran.
If systemd is using anything other than SIGHUP to kill the jobs, it's not allowing nohupped jobs to continue to run, and may also break other programs as well.
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely.
The Unix Time-Sharing System has allowed that since Day One.
The question then is whether we should start treating that as a deficiency to be fixed, and in what ways it should be fixed, e.g. "should even nohupped jobs be killed?"
You morons all sound like a bunch of Mac users.
Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).
(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.
The Unix tradition has always been "you want your backgrounded processes to survive a logout, nohup them" - traditionally, when the tty driver saw that carrier dropped, it'd deliver SIGHUP, although I'm not sure all UN*Xes pseudo-terminal drivers deliver SIGHUP when the master side closes, that being the closest moral equivalent to carrier dropping; I think I've seen that not happen on OS X, but didn't dig through the pseudo-tty code in XNU enough to see why that wasn't happening or to determine whether that was intentional.)
The best part was when that vapid bitch got in front of a microphone to state quite plainly that they "didn't buy Oracle" just to file the suit against Google.
Presumably you're referring to the Oracle co-CEO saying they didn't buy Sun just to file the lawsuit?
She is a lawyer, not a programmer. What she is saying is nonsense
Maybe she shouldn't be talking about something of which she is ignorant. Then again, she's an attorney and from what I've been able to observe, attorneys frequently talk out of their collective asses about things which they know nothing about, especially in technical or scientific fields.
A company I worked at a while ago was planning to threaten another company with a claim that "you couldn't possibly have implemented that without stealing our stuff"; I remember the threat letter repeatedly claiming it was "inconceivable" that they could have done that.
"The Princess Bride" came to mind.
Maybe hyperbole is Standard Operating Procedure for lawyers in many situations - perhaps the belief is that if you can get the people to whom the hyperbole is addressed to believe it, you win.