Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:From a security perspective... (Score 1) 924

You're an idiot. The name of the command is part of its functionality. If systemd were to insert itself in front of the bash interpreter and swap around 'rm -rf' and 'ls -lh', while preserving the 'functionlity' of one under the name of the other, who would need to be jerking you off under the table for you to claim that nothing has changed, and 'it's not a big deal, IMHO'?

Do you really think your made up, incoherent hyperbolic stories counts as technical arguments?

It is scary to think that you probably are old enough to shave yet behave like a retarded 10 year old. You mother must really have hated you since you ended up in such a sad state. I am sorry for you, I really am.

Comment Re:From a security perspective... (Score -1, Redundant) 924

*For a concrete example, all of your scripts that automatically ssh into a server, start a process with screen, and log out, now break. To name just one thing that I have done on numerous occasions.

Just edit your scripts. You had to edit them too when ssh replaced rsh back in day. Or just set "KillUserProcesses" to "no" and live with the same old problems. Hardly a big deal.

Comment Re:To be quite honest... (Score 1) 924

In Unix and its derivatives, frequently used commands are terse If there's something new for me to learn, it ought to be a half-dozen keystrokes.

No, I am not going to learn to use a new command that has over 40 extra keys to type

I think it is rather a question of who first "stole" the nice short commands, leading to permanent hogging of the namespace. Who is really using ar these days.

Anyway, those "terse" commands and their "terse" switches are really hard to remember, especially when they only have the vaguest mnemonic resembles to what they perform. And "-t" can mean anything depending on what program it is used with.

The solution was to use proper mnemonic commands and have tab completion of everything, including switches, and always have "long option" switches so a simple "--*tab*" would reveal the options. This combined with using the command stack is highly efficient, not only when it comes to typing, but also when it comes to remember what stuff do.
Programs like git and systemd is designed around this concept. I like it.

  to support a misfeature that has no benefits to me.

I think we can safely assume here that do don't really have any experience with systemd-run, nor have actually read its man-page. So you must have psychic powers in order to know that it offers no benefits to you.

Comment Re:WTF (Score -1, Troll) 924

Seriously? "Jump through extra hoops and it'll work like it always did?" If you have to jump through such stupid extra hoops then it fucking doesn't work like it always did!

The way you run the programs may have changed, but not the functionality. Screen works just like expected when started by systemd-run once it is running. So no functionality is lost.

Being able to run stuff in the background has been around for decades

This isn't about running stuff in the background (though systemd-run can do that too), but about keeping processes alive after logout.

With systemd-run the programs get their own scope that you can manipulate with standard systemd tools and use many of the standard systemd resource management features like limiting IO etc. In short, you can trivially constrain your long running processes so they don't DoS the system, even if some process went rogue.
Another major benefit is the ability to safely purge the user session in a clean way, so that only explicitly allowed processes survive the logout.

Anyway, it is trivially easy for those who want it to revert to the old (rather hackish) way of doing things. man logind.conf will show you how.

Comment Re:WTF (Score 1) 924

SSH came with a provable security benefit and didn't silently fail,

Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.

But some people just have severe trouble adapting to new tech and new work flows and start to cling to old outdated procedures and programs.

this change is merely an opinion of best practice and forces a poorly documented change on an unsuspecting public

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Comment Re:To be quite honest... (Score 0) 924

No it does not work as before. Before you just typed "screen", and it worked on any system.

Life is too short to spend time committing all that extra crap to memory or else having to configure every system you touch with custom shortcuts.

If you think that having to remember to type "systemd-run --user --scope-screen" in front of a frequently used utility (and having the system silently clobber your work if you forget) is reasonable, you're deluded.

Just recall the command line from the stack. No need to type when eg. "Ctrl-r" works so well.

Really such changes occur all the time in tech; we no longer use telnet, rlogin, uucp and similar old and insecure stuff anymore either. It must be hard to work in tech when unable to learn new commands and new ways of doing things.

Comment Re:I assumed this was already a default (Score 2) 924

Yes. The issue isn't that it can't be done. The issue is that longstanding default behavior has changed. Since it appears that there's no good, solid reason for the change, people are objecting to it. Change for change's sake is bad.

Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?

Comment Re:I assumed this was already a default (Score 0) 924

What about when I have a long running process I need to run and I don't want it to be stopped if I get disconnected from wifi? Or maybe I know it'll still be running when I have to go home?

The way it is now, if I just disconnect from ssh, they get killed. If i go out of my way to ensure they won't (e.g. start them in a screen session) then they aren't. How is the old way a problem?

That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.

Comment Re:From a security perspective... (Score 0) 924

But please.
WHY. THE. FUCK. break decades of well-established Unix conventions? Why the actual fuck?
I hate the arrogance of the systemd folks who think they are doing everything better. Even Darwin respects Unix conventions more than systemd. And yes, they scrapped sysvinit too. And yes, I still prefer sysvinit.

Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text? Unix was chock full of insecure way of doing things and an unfortunately a lot of this have carried over to Linux with the end result that multi-user Linux security seems to rely on users being nice guys as a basic security measure.

With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally.

Comment Re:From a security perspective... (Score 0) 924

It's not a bloody small change in syntax. It's a fundamental design change on the way linux processes and logins work. This breaks a lot of stuff and should have a massive red warning on it. It should be a major release and not an incremental change (if it were even a good idea, which it's not).

There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have changed.

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.

Comment Re:WTF (Score -1) 924

"screen" will work exactly as it always have, even with the new defaults.

Except that the way you describe is not the way that screen has always worked. Instead of the straightforward invocation screen on the command line, now it has to be prefixed with all kinds of systemd-specific stuff that wasn't there before.

Its functionality is the same. Really, just use an alias if typing is hard for you to do. Or even better. Start screen automatically at boot by running it as a .service. See the Arch wiki for how.

Comment Re:To be quite honest... (Score -1) 924

Fear not, people of Slashdot, because there is an option to maintain background processes, even after user disconnection.

But this option is not "on" by default. So, yeah, screen and tmux all of a sudden become useless, unless you fiddle with the knobs.

You are of course wrong. Probably because you never read the technical documentation on this but just relied on wrong hearsay.

Here is the relevant man-page:
https://www.freedesktop.org/so...

As you can see, even with the new defaults, it is trivial to make GNU screen or tmux keep running, even after logout, even with the new defaults settings. You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).

Comment Re:I assumed this was already a default (Score -1, Flamebait) 924

A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely

Crippling the service is not a good way to protect the server.

There are other ways to protect system from users to consume all the resources. Admin can and should setup the server the way it is protected from incompetent/malicious users.

If you make this protection by killing processes after logout, you are actually removing functionality from it. And for me, it's a step backward.

A good thing that you are misunderstanding what is happening then; Even with the new settings, no user process will be killed on exit/logout if the user have told the system not to.
Instead of starting the program with with "nohup" you start it with "systemd-run" instead.
This is how you start "screen" so it will survive logout: "systemd-run --user --scope".

Slashdot Top Deals

PLUG IT IN!!!

Working...