Today's Debian technical committee resignation: Ian Jackson [LWN.net]

A request

Posted Nov 19, 2014 13:36 UTC (Wed) by corbet (editor, #1) [Link] (13 responses)

Regardless of how you might feel about Ian's recent activities in Debian, it would be good to allow him to have a rest now. Actually, we could all use a rest. So could I please ask that any comments posted here be respectful and not rehash the same old arguments about related topics?

Thank you.

A request

Posted Nov 19, 2014 13:50 UTC (Wed) by nix (subscriber, #2304) [Link]

I note that we've already had a GNU adns release, with working IPv6 support!

Goodbye bickering, hello software development!

A request

Posted Nov 19, 2014 14:25 UTC (Wed) by niner (subscriber, #26151) [Link]

Regardless of how one might feel about Ian's recent activities in Debian, one has to admit, that he stepped down with grace.

Thanks Ian and have much fun coding :)

Here's to sunnier days

Posted Nov 19, 2014 15:55 UTC (Wed) by martin.langhoff (subscriber, #61417) [Link] (1 responses)

Thanks Ian and everyone. My hope is that this divisive topic is put behind, systemd improved (and perhaps eventually replaced/refactored) for the betterment of the platform.

And perhaps all the parties involved come back to the TC or other leadership positions strong but... more patient :-)

We will need them; systemd won't be the last controversial moment in Linux...

Here's to sunnier days

Posted Nov 19, 2014 17:23 UTC (Wed) by donbarry (guest, #10485) [Link]

I'd just like to thank Tollef Fog Heen, Russ Allbery, Colin Watson, and Ian Jackson, and Joey Hess for their tireless effort, even in those cases where I disagreed with their decisions. I have never met any of them but I greatly respect their efforts to provide guidance for the improvement of the Universal Operating System's architecture. Debian is generally the better for their struggles to do the right thing, and that will particularly be seen in the long run.

I also am quite happy with the improved functionality of Jessie, especially the rapid boot time. I agree with the Technical Committee that systemd was the best choice in a difficult field and acknowledge their valid concerns about both a certain arrogance of upstream and the porting issues.

That said, systemd is free software. It does not have the problematic license assignments of upstart, and is more technically mature. It is one of Debian's great successes in the past that they have built tools to split unwieldy master codebases into modular packages -- with some cleverness on Debian's part and a willingness to collaborate on the part of the systemd team, I hope that great things can happen.

Sorry, but no.

Posted Nov 19, 2014 18:27 UTC (Wed) by HelloWorld (guest, #56129) [Link] (7 responses)

People need to deal with the consequences of their actions. Ian has been spreading all kinds of lies and trolling against systemd, he engaged in tactical voting and added fuel to a fire that was bad enough already and ultimately led to the resignation of several project members.

I'm all for respect, but there's nothing wrong with calling a spade a spade. I'm sure Ian did terrific work in the past, but that doesn't give him the right to behave like this.

Sorry, but no.

Posted Nov 19, 2014 19:23 UTC (Wed) by Zack (guest, #37335) [Link] (1 responses)

> there's nothing wrong with calling a spade a spade

Oh, how I wish I could right now, but corbet asked me not to.

Sorry, but no.

Posted Nov 19, 2014 19:29 UTC (Wed) by martin.langhoff (subscriber, #61417) [Link]

And thank you :-)

Sorry, but no.

Posted Nov 19, 2014 20:45 UTC (Wed) by tomegun (guest, #56697) [Link] (4 responses)

Whatever we may think of recent events. Jackson did a great deal of work over many years, and now he has resigned. There is no point in rehashing whatever disagreements there may have been, let's be respectful and acknowledge his achievements instead. Water under the bridge and all that...

Sorry, but no.

Posted Nov 20, 2014 10:41 UTC (Thu) by drago01 (subscriber, #50715) [Link] (3 responses)

People get judged by their recent actions. To illustrate it with an extreme example imagine someone that people know as being a nice person goes and kills people. The latest action will surely overshadow what he did in the past.

So while Ian's recent actions are surly not comparable to "killing people" they did harm the debian project. So not really surprising that people forget about his past achievements and focus on that.

Sorry, but no.

Posted Nov 20, 2014 12:42 UTC (Thu) by Zack (guest, #37335) [Link] (1 responses)

No, because his actions "harming the project" is debatable. Now you could say that isn't so and have *that* debate, but:

-the votes are in
-Ian resigned from the TC

so it would be perpetuating the debate to perpetuate the debate, since it would involve the same amount of strife, but with nothing at stake.

Sorry, but no.

Posted Nov 20, 2014 14:00 UTC (Thu) by drago01 (subscriber, #50715) [Link]

Oh I am not asking to rehash the debate actually its good that this whole thing is finally ending. Just tried to explain why some people don't simply go "ok doesn't matter he did great work in the past" ... things simply don't work that way.

No imagination required

Posted Nov 20, 2014 19:00 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

To illustrate it with an extreme example imagine someone that people know as being a nice person goes and kills people. The latest action will surely overshadow what he did in the past.

It doesn't take much imagination, given that one prominent Linux developer was convicted of killing his wife. A fair number of people were willing to defend him when there was still a serious question of his guilt, but he quickly became an unperson once he confessed.

A request

Posted Nov 19, 2014 21:12 UTC (Wed) by flussence (guest, #85566) [Link]

Amen to that.

This has all gotten ridiculously out of hand, and I feel like I've added to the problem despite trying not to side with either "camp". So I offer this open apology, whatever it's worth, for ever getting involved in those kind of threads at all.

All that time spent telling others they're wrong would be better spent coding.

Thanks

Posted Nov 19, 2014 13:50 UTC (Wed) by ncm (guest, #165) [Link] (53 responses)

Thank you, Ian, for your long and distinguished service to all users of Debian and its downstream projects. It was would be a sad thing for it to end on this note.

Technological progress is like a series of small strokes. Those of us involved it for long are always in rehab, learning again to do what we used to do easily. Sometimes the effort to retrain is too great, and we bow out.

Thanks

Posted Nov 19, 2014 14:39 UTC (Wed) by gb (subscriber, #58328) [Link] (52 responses)

Well, world have changed. Let's see that would be result - anyway now we all must go and use systemd in our work.

Thanks

Posted Nov 19, 2014 15:39 UTC (Wed) by tjc (guest, #137) [Link] (51 responses)

> anyway now we all must go and use systemd in our work.

Not necessarily; there are still alternatives for those who don't care for systemd: Slackware, Gentoo, Crux -- perhaps others that I don't know about. And one can always switch to FreeBSD, PC-BSD, NetBSD, etc. without too much trouble. systemd is dominant, but not exclusive.

Thanks

Posted Nov 19, 2014 16:19 UTC (Wed) by moltonel (guest, #45207) [Link] (1 responses)

Dare I mention that those distributions have plenty of other things going for them than just not being tied to systemd ? :)

Gentoo user here. Go have a look, the small compile time pain is largely worth the gain (no, this is not about performance). And you can use whichever init system you prefer.

Thanks

Posted Nov 20, 2014 11:01 UTC (Thu) by deepfire (guest, #26138) [Link]

Gentoo is passe, NixOS is the declaratively-defined new hotness nowadays : -)

A noticeable chunk of the haskell community is behind NixOS -- to the point that next-gen haskell.org infrastructure is being built on it..

Thanks

Posted Nov 19, 2014 16:33 UTC (Wed) by seyman (subscriber, #1172) [Link] (14 responses)

> there are still alternatives for those who don't care for systemd

There's also the possibility of forking an existing init system (or creating one from scratch) and making it better than systemd. It's a lot of work but it can be done.

Thanks

Posted Nov 21, 2014 15:29 UTC (Fri) by tjc (guest, #137) [Link] (13 responses)

I guess if it comes to a fork, Upstart would be the most viable candidate. Canonical has a copyright on the name, so that would have to be changed, but the code is under the GPLv2. That might be better than starting over yet again, unless, of course, someone is just itching to write an init system. I'm all in favor of writing code for the sake of writing code; I have no delusions of world dominion. :)

Thanks

Posted Nov 21, 2014 15:59 UTC (Fri) by anselm (subscriber, #2796) [Link] (12 responses)

That might be better than starting over yet again, unless, of course, someone is just itching to write an init system.

The problem with Upstart is that it has severe shortcomings that – at least according to its original lead developer – would require a major redesign to overcome. So it seems that you would in effect have to be “itching to write an init system” in order to make Upstart a viable long-term proposition.

This would be especially ludicrous given that systemd is basically such a redesign already, and has both a fairly vibrant developer community and widespread buy-in from mainstream distributions, so is likely to stick around unless something radically better comes along, which at this point is unlikely. Given this, it would probably make much more sense to fork systemd rather than Upstart.

Thanks

Posted Nov 21, 2014 18:48 UTC (Fri) by tjc (guest, #137) [Link] (10 responses)

> The problem with Upstart is that it has severe shortcomings that – at least according to its original lead developer – would require a major redesign to overcome.

What are the shortcomings? I've been using Upstart for several years without incident, but I don't require much of an init system (other than to "init").

Thanks

Posted Nov 21, 2014 19:31 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (6 responses)

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/4... is an example.

Thanks

Posted Nov 22, 2014 16:10 UTC (Sat) by smurf (subscriber, #17840) [Link] (5 responses)

To summarize: While an event-based init system seemed like a good idea at the time, upstart quickly ran into a whole lot of corner cases which are basically unsolvable without adding job state as separate concepts. Upstart has tried working around this by adding even more events (like "starting to start" and "finished starting") but they don't help in general.

Given this fact, a dependency-based system which uses events just to change the units' state simplifies the whole system and affords easier debugging, as it's statically introspectable – meaning you don't need an event history to figure out what's wrong, just the current job states and the dependency graph.

Thanks

Posted Nov 22, 2014 21:14 UTC (Sat) by mgb (guest, #3226) [Link] (4 responses)

Forgy invented http://en.wikipedia.org/wiki/Rete_algorithm in the 70's and it was widely adopted in the early 80's.

Sad to see the wheel painfully being reinvented again.

Thanks

Posted Nov 22, 2014 21:46 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Dependency resolution in an init system doesn't need anything remotely this elaborate. We don't even need alternates (what for?).

Thanks

Posted Nov 22, 2014 22:08 UTC (Sat) by mgb (guest, #3226) [Link]

> Dependency resolution in an init system doesn't need anything remotely this elaborate.

Rete is not elaborate. It is a clean elegant modular algorithm.

> We don't even need alternates (what for?).

Alternate networks. Sometimes alternate data stores. Alternate entropy sources - you want sshd ASAP but maybe not until you have some entropy. "If I can't get any entropy bring up sshd only on the private LAN and if that doesn't work fall back to telnetd on the private LAN."

As the "new" init systems try to invade serious servers they will keep on running into problems and adding more keywords and reliving the 70's until they eventually relearn the lessons of the early 80's.

Thanks

Posted Nov 22, 2014 23:33 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

How would you apply this to an event-based init system?

Thanks

Posted Nov 23, 2014 0:15 UTC (Sun) by mgb (guest, #3226) [Link]

> How would you apply this to an event-based init system?

Your own http://lwn.net/Articles/622742/ answers that.

If you want functionality beyond inittab, an event-based init system is even worse than an ad-hoc dependency-based init system that has to keep adding keywords like RequiresMountsFor.

Thanks

Posted Nov 21, 2014 20:14 UTC (Fri) by Felix (guest, #36445) [Link] (2 responses)

jspaleta also compiled an impressive list https://lwn.net/Articles/582585/

Thanks

Posted Nov 21, 2014 21:02 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (1 responses)

One request...

If someone does fork upstart and fix all the deep deep design problems. Please rename it as a new project. What you end up building will be a very different animal.

I have a couple of humble name suggestions:
upyours, upset, upchuck

-jef

Thanks

Posted Nov 22, 2014 15:23 UTC (Sat) by zuki (subscriber, #41808) [Link]

Funny... but not quite funny enough. Please give it a rest.

Thanks

Posted Nov 21, 2014 22:31 UTC (Fri) by seyman (subscriber, #1172) [Link]

> Given this, it would probably make much more sense to fork systemd rather than Upstart.

I don't see how this will win over the people who are complaining (assuming anything can, at this point). OpenRC always seemed the better choice, imho.

Thanks

Posted Nov 19, 2014 17:42 UTC (Wed) by gb (subscriber, #58328) [Link] (1 responses)

> Not necessarily; there are still alternatives for those who don't care for systemd: Slackware, Gentoo, Crux -- perhaps others that I don't know about. And one can always switch to FreeBSD, PC-BSD, NetBSD, etc. without too much trouble. systemd is dominant, but not exclusive.

I am tied to Linux not just as a hobby, but also at work. Debian at home, Red Hat at work. Every day I develop software for Linux on Linux, deploy software, packaging software, parsing logs, etc. This all soon be changed by systemd, wayland. New Linux. I hope it wouldn't like Gnome 3.

Thanks

Posted Nov 22, 2014 10:44 UTC (Sat) by Wol (subscriber, #4433) [Link]

Well, the systemd guys seem to view backwards compatibility as important. If you want to use systemd pid1 just to fire off your old SysVInit scripts and not use their new config files, that's a design goal. If it doesn't work, file a bug report.

And Wayland is being developed by the X guys. In effect it's X13 (seeing as the moniker X12 is already taken). So again, any failure in compatibility is a good candidate for a bug report.

Cheers,
Wol

Thanks

Posted Nov 19, 2014 18:08 UTC (Wed) by jonnor (guest, #76768) [Link] (31 responses)

I also think there is a pretty good chance that Debian will work ok without systemd for the forseeable future for a lot of usecases, now that the discussions are (hopefully) over and people can spend their energy on solving technical problems.

Thanks

Posted Nov 19, 2014 23:12 UTC (Wed) by andreashappe (subscriber, #4810) [Link] (30 responses)

I believe it will work until socket/service-activated services will get used more (if ever) -- otherwise it should be possible to create those init-scripts from systemd's configuration.

Thanks

Posted Nov 20, 2014 1:42 UTC (Thu) by JdGordy (subscriber, #70103) [Link] (29 responses)

At which time someone will make another shim so they work or everyone will wonder why the heck the community had such an ugly argument over this.

Thanks

Posted Nov 22, 2014 15:31 UTC (Sat) by zuki (subscriber, #41808) [Link] (28 responses)

> At which time someone will make another shim
One could argue that inetd/xinetd already do this, although not with the systemd protocol.

More recent systemd-activate from the systemd tree implements most of socket activation protocol including Accept=yes/no and multiple sockets (not all socket types, e.g. netlink is missing but that could be fixed). It is not tied to systemd as PID 1, so it could be used a shim easily.

Thanks

Posted Nov 22, 2014 20:19 UTC (Sat) by rodgerd (guest, #58896) [Link] (27 responses)

It's a reasonable argument.

(It would also be interesting to know how many "traditional Unix is the ONLY WAY" actually run ssh or their web servers out of inetd.)

Thanks

Posted Nov 23, 2014 1:29 UTC (Sun) by zuki (subscriber, #41808) [Link] (26 responses)

I think socket-activated sshd makes a lot of sense... Not the extreme of running a separate instance for each connection (Accept=yes in systemd parlance), but a single instance with delayed activation. For many notebooks, workstations, and dedicated servers sshd is used never or rarely, so not starting it unconditionally is a nice optimization. For this to really work nicely, sshd should learn to exit-on-idle. Then you get the best of both worlds.

Thanks

Posted Nov 23, 2014 3:05 UTC (Sun) by mgb (guest, #3226) [Link] (20 responses)

You save a few bytes of swap space and increase the likelihood of having to drive to the data center at zero dark thirty.

Not for me, thanks.

Thanks

Posted Nov 23, 2014 7:31 UTC (Sun) by smurf (subscriber, #17840) [Link] (19 responses)

How does socket-activating sshd increase any likelihood of problems?

I'd assume that this would decrease it, since this way you do not risk starting it too early (/var/log not yet mounted, or whatever else might cause sshd to fail to start), nor too late (i.e. not at all, if something earlier in the boot sequence fails)

Thanks

Posted Nov 23, 2014 7:42 UTC (Sun) by mchapman (subscriber, #66589) [Link] (18 responses)

> How does socket-activating sshd increase any likelihood of problems?

If the system is close to being out of memory, then I would expect a socket-activated SSH to be less likely to get you to a shell than a non-socket-activated SSH.

If your only remote access to the system is with SSH, and remotely rebooting it is infeasible or impractical, then this could be a concern.

Thanks

Posted Nov 23, 2014 9:01 UTC (Sun) by mgb (guest, #3226) [Link] (12 responses)

Also for handling upgrade problems.

Once your sshd process exists you don't want it to disappear unexpectedly.

Thanks

Posted Nov 23, 2014 9:29 UTC (Sun) by mchapman (subscriber, #66589) [Link]

No, I don't think socket-activation changes anything there. When you upgrade SSH, the package's post-installation scripts should cause it to be restarted if it's running as a non-socket-activated service.

Thanks

Posted Nov 23, 2014 16:37 UTC (Sun) by flussence (guest, #85566) [Link] (8 responses)

Reliably upgrading sshd doesn't have much in common with socket activation. You can still do the normal "restart daemon, log in on new sshd to verify it works, log out of old sshd when it's safe" routine, though that of course renders this micro-optimization pointless.

On the other hand, a system using cgroups to indiscriminately purge entire process ancestries will create exactly the problem you're describing... by design!

Thanks

Posted Nov 23, 2014 16:57 UTC (Sun) by mgb (guest, #3226) [Link] (5 responses)

> On the other hand, a system using cgroups to indiscriminately purge entire process ancestries will create exactly the problem you're describing... by design!

Exactly.

A hypothetical modular portable dependency-based init could have been a useful tool but systemd is the opposite of a tool - it is a restrictive imposition. Systemd's short-sighted design is extraordinarily counter-productive and this becomes glaringly obvious as systemd attempts to move from its desktop niche to the critical server and embedded spaces.

Thanks

Posted Nov 23, 2014 17:53 UTC (Sun) by zuki (subscriber, #41808) [Link] (4 responses)

>> Reliably upgrading sshd doesn't have much in common with socket
>> activation. You can still do the normal "restart daemon, log in on new
>> sshd to verify it works, log out of old sshd when it's safe" routine,
>> though that of course renders this micro-optimization pointless.
Not if exit-on-idle is implemented. If it is, you can do a test login after upgrade, and still have the process go away after while.

I agree that for a server this is pointless, but let's say that you are running containers or lightweight VMs, in multiple instances. Then avoiding starting the process can be a nice optimization.

>> On the other hand, a system using cgroups to indiscriminately purge
>> entire process ancestries will create exactly the problem you're
>> describing... by design!
> Exactly.
I don't grok. When an SSH session is started, the ssh instance and user process forked off it are moved to a separate scope unit, which of course also means a different subtree in the cgroup hierarchy. So individual sessions are completely independent of the ssh service. As for the sshd service itself, yes, all processes in it are stopped during restart. That pretty much describes the basic functionality of systemd achieved with cgroups. If you think something is wrong with "purging" all processes of a service when it is stopped, please explain.

[snip the rant]

Thanks

Posted Nov 23, 2014 18:06 UTC (Sun) by mgb (guest, #3226) [Link] (3 responses)

> If you think something is wrong with "purging" all processes of a service when it is stopped, please explain.

You should try pre-systemd Debian Stable which doesn't kill existing sshd connections during upgrades. It's great.

Thanks

Posted Nov 23, 2014 18:15 UTC (Sun) by zuki (subscriber, #41808) [Link] (2 responses)

>> If you think something is wrong with "purging" all processes of a
>> service when it is stopped, please explain.
> You should try pre-systemd Debian Stable which doesn't kill existing sshd
> connections during upgrades. It's great.

Once again: existing sshd connections *are* *not* *part* of sshd.service.
After they are established they are independent and are not touched when sshd.service is stopped or restarted.

(It is possible that there's a bug in your Debian package or setup or whatever... I can only say that it works for me and apparently for most people, and of course is *designed* to work this way. If it doesn't work for you, please provide the details and we'll work on a fix. Probably best to do this on the distribution bugtracker rather than here though.)

Thanks

Posted Nov 23, 2014 18:43 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

Asking mgb for details about specific failures of systemd-based systems is a waste of electrons; they have explicitly stated on this site a refusal to use systemd or help debug systemd.

Thanks

Posted Nov 25, 2014 16:31 UTC (Tue) by nix (subscriber, #2304) [Link]

It's also clear from this subthread that mgb doesn't bother to actually read posts to which it responds: rather, it scans them for things that can be attacked, and ignores everything else, including inconvenient facts that might contradict its rants.

Thanks

Posted Nov 23, 2014 23:28 UTC (Sun) by mchapman (subscriber, #66589) [Link] (1 responses)

> On the other hand, a system using cgroups to indiscriminately purge entire process ancestries will create exactly the problem you're describing... by design!

Except it doesn't. There are two reasons for this.

First, pam_systemd will move the SSH child process into a different cgroup.

Second, even if it didn't do this, the sshd.service contains KillMode=process, which means only the main process is killed upon stop or restart. Other processes in the sshd.service cgroup are unaffected.

Thanks

Posted Nov 24, 2014 20:16 UTC (Mon) by smurf (subscriber, #17840) [Link]

This did happen, once upon a time. It was a bug. It was fixed rather quickly, for obvious reasons.

Too bad (from the point of view of the anti-systemd crowd, that is).

Thanks

Posted Nov 24, 2014 20:18 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

It won't. Socket-activated processes don't get killed because they're idle. systemd ignores the socket while the process is running, so how could it know?

Thanks

Posted Nov 24, 2014 20:48 UTC (Mon) by mgb (guest, #3226) [Link]

> Socket-activated processes don't get killed because they're idle.

The subthread to which you are responding is concerned with zuki's suggestion http://lwn.net/Articles/622790/ that sshd should exit on idle.

Thanks

Posted Nov 24, 2014 13:02 UTC (Mon) by james (subscriber, #1325) [Link] (1 responses)

I'd expect a socket-activated sshd that is activated from init to be more likely to work (perhaps after a minute or two), simply because init won't be killed by the OOM killer.

Thanks

Posted Nov 25, 2014 16:32 UTC (Tue) by nix (subscriber, #2304) [Link]

sshd also takes precautions against being OOM-killed -- but for most other daemons your point is valid.

Thanks

Posted Nov 24, 2014 18:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

It's quite likely for OOM killer to kill your sshd, especially if it's inactive. Sure, you can play with OOM killer settings to make sure that your sshd (which is usually dropbear ssh) is not killed.

But of course, it's easier to do with systemd and socket-activation is useful because it will restart your daemon in case of failures...

Thanks

Posted Nov 24, 2014 19:27 UTC (Mon) by rodgerd (guest, #58896) [Link] (1 responses)

Of course, systemd makes it trivial to mark OOM settings on a per-service basis, too.

Thanks

Posted Nov 24, 2014 20:00 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm actually thinking that combining socket activation and adjusting OOM killer score to make it _more_ likely to kill sshd is an even better strategy. This way, sshd will be killed first and will free up RAM that is likely wasted.

There's a slight possibility of a livelock when sshd is killed immediately after it's restarted by systemd. Perhaps the "OOMAdjustDelay" setting can be added to systemd?

Thanks

Posted Nov 23, 2014 9:32 UTC (Sun) by rodgerd (guest, #58896) [Link] (4 responses)

For some cases. Of course, OpenSSH isn't very traditional Unix. It's one project that replaces telnet, rlogin, rsh, rcp, and FTP. Why have a big monolithic blob? Shouldn't it be run as a set of loosely-coupled projects with seperate repositories?

The proper Unix way would be to have all those traditional services spawn out of inetd and use tools like tcpwrappers for access control; if you really need security you should be using something like stunnel rather than building it all into the basic tool. All that code living together is obviously a much bigger attack service.

And have you seen the attitude of the maintainer? He rejects portability patches and keeps saying rude things about other platforms!

All of this is against traditional Unix principles and will be a disaster for Unix, mark my words.

Thanks

Posted Nov 23, 2014 18:35 UTC (Sun) by dlang (guest, #313) [Link] (3 responses)

actually, the fact that ssh is telnet + ftp + vpn is an ongoing problem for security people who would like to allow some of this capability without allowing it all.

Thanks

Posted Nov 24, 2014 20:22 UTC (Mon) by smurf (subscriber, #17840) [Link] (2 responses)

It is, like, _so_ difficult to turn the unwanted features off in sshd_config, no?

Thanks

Posted Nov 25, 2014 2:22 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

yes, it's extremely hard to turn features off for some users while allowing it for others.

Thanks

Posted Nov 25, 2014 16:33 UTC (Tue) by nix (subscriber, #2304) [Link]

The keyword you're looking for is 'Match'. You can PermitTunnel on a group-by-group, IP-by-IP, user-by-user, or even local-port-by-port (?!) basis.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 14:23 UTC (Wed) by marduk (subscriber, #3831) [Link]

As the swirl turns...

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 14:34 UTC (Wed) by Zack (guest, #37335) [Link] (4 responses)

Thanks for making sure this GR happened and seeing it through to the end. Where before I was told I was just part of a very small minority and I should just roll over or go away, the results tell me Debian, as a project, still cares about the fate of alternative inits.

I feel like my concerns have been listened to, and my reservations expressed. The actual outcome means nothing concrete has been changed, but at least systemd has not been unanimously voted "King of Debian." The DDs have spoken, and as far as democracy goes, I'm pretty happy with the results.

Sure I'm still in the minority, but now that it's been quantified it's sizable enough for me to feel comfortable with and stay with Debian: something I wouldn't have known without the GR.

Majorities are for squares anyway.

Thanks again for the hard work of representing an unpopular and controversial opinion, and dealing with all the ad-hominem unpleasantness that goes with that.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:26 UTC (Wed) by emunson (subscriber, #44357) [Link] (3 responses)

While I didn't/don't agree with Ian, this was an important outcome of the GR.

Ian managed to maintain a pretty level head in the otherwise nasty init debate, but more importantly Ian did great work for Debian. Hopefully he will remain engaged with the community.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 18:15 UTC (Wed) by HelloWorld (guest, #56129) [Link] (2 responses)

> Ian managed to maintain a pretty level head in the otherwise nasty init debate
Yeah... right...
https://lists.debian.org/debian-ctte/2014/02/msg00342.html
https://lists.debian.org/debian-ctte/2014/02/msg00344.html
https://lists.debian.org/debian-ctte/2014/02/msg00359.html

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 18:57 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Yeah, there were moments in this debate in which Ian went nonlinear.

But there were also moments in which he was level-headed. For obvious reasons, these tend to not be as visible.

People are not perfect. We cannot divide people into Incorruptible Pure Pureness and Complete Monster buckets.

We should cherish the good Ian has done, and leave behind any bad he has done. One day, we will all look back to this and say, "how silly have we been!"

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 19:37 UTC (Wed) by Rehdon (guest, #45440) [Link]

+ 1.

Rehdon

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:01 UTC (Wed) by ctun (guest, #99860) [Link] (36 responses)

As Ian Jackson's crusade against the new seat of power controlling all of GNU/Linux, systemd, bites the dust and is rejected by the masses, he runs away to avoid the wrath of the new establishment.

The aspiring ruler of GNU/Linux, Lennart Poettering, is now unopposed and has finally completed his campaign, solidifying his ultimate control over all GNU/Linux systems.

Assimilation is completed and as work to establish systemd everywhere is about to be finished, we welcome a new era enlightened by the unwavering guidance of our new magnificent overlord, Lennart Poettering the Infallible, the supreme dictator of all GNU/Linux systems.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:11 UTC (Wed) by corbet (editor, #1) [Link] (35 responses)

This is exactly the sort of comment I asked people not to post. Please, folks, let's not rehash this thing again...?

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:33 UTC (Wed) by seyman (subscriber, #1172) [Link] (19 responses)

In unrelated news, the comment filters work perfectly.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:43 UTC (Wed) by SEJeff (guest, #51588) [Link] (4 responses)

Thanks for reminding me. I'd literally forgotten that was a feature of a lwn subscription. filtered_accounts++

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 15:57 UTC (Wed) by niner (subscriber, #26151) [Link] (1 responses)

Oh I didn't even know that lwn does have this feature. Nice!

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 23:35 UTC (Wed) by philh (subscriber, #14797) [Link]

Ah, that's better -- thanks. :-)

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 16:46 UTC (Wed) by The_Barbarian (guest, #48152) [Link]

oh, that is handy. I didn't know it was there!

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 20, 2014 10:09 UTC (Thu) by gebi (guest, #59940) [Link]

oh didn't know that too!
THX, much better now!

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 16:41 UTC (Wed) by a9db0 (subscriber, #2181) [Link] (3 responses)

Oooh yes! Thank you for the reminder.

For those wondering / needing a refresher, go to My Account (link at the top of the left hand menu bar), enable filtering, and add the offending user to be filtered.

Works like a charm.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 17:41 UTC (Wed) by andreashappe (subscriber, #4810) [Link] (1 responses)

ah thank you for that reminder!

Is there a way of temporarily filtering out all guest accounts? I know there are insightful contributions coming from guests but as soon as there's a flame-y topic the greater internet dickwad theory seems to be proved.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 19:51 UTC (Wed) by halla (subscriber, #14185) [Link]

I would _love_ that feature...

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 23:28 UTC (Wed) by antitezo (guest, #99387) [Link]

Thank you! I was looking for it at the wrong place :)

No, comment filters don't work perfectly

Posted Nov 19, 2014 21:45 UTC (Wed) by louie (guest, #3285) [Link] (9 responses)

LWN's comment section, in the language of Jeff Atwood, is Jon's house (or in my earlier framing, it is Jon's party). To further quote Jeff:

[M]ute and ignore, while arguably unavoidable for large worldwide communities, are actively dangerous for smaller communities.

This is your house, with your rules, and your community. If someone can't behave themselves to the point that they are consistently rude and obnoxious and unkind to others, you don't ask the other people in the house to please ignore it – you ask them to leave your house.

I'm very sad that LWN has come to the point where Jon can't just leave the door open and let anyone into his house. But it is clear that it has come to this point. Jon, how can we help you fix this? Because as-is it is poisoning all the good work you've done here over the years :/

No, comment filters don't work perfectly

Posted Nov 19, 2014 22:26 UTC (Wed) by corbet (editor, #1) [Link] (8 responses)

Don't know. We really don't want to be in the business of comment moderation, and, if we do have to do that, it will show elsewhere. There's no spare time for it.

Suggestions more than welcome.

I'm really hoping that things will get better if and when this whole systemd thing runs its course. As it is, we're all kind of exhausted.

No, comment filters don't work perfectly

Posted Nov 19, 2014 23:19 UTC (Wed) by sjj (guest, #2020) [Link] (1 responses)

Maybe you don't / shouldn't need to think of building your own moderation. Have you looked at Discourse (discourse.org)? I don't have experience with it, but their heart seems to be in the right place... ("Civilized discussion. On the Internet.")

No, comment filters don't work perfectly

Posted Nov 20, 2014 7:39 UTC (Thu) by joib (subscriber, #8541) [Link]

Presumably, as there's even a recent LWN article about it: https://lwn.net/Articles/609720/

No, comment filters don't work perfectly

Posted Nov 19, 2014 23:20 UTC (Wed) by andreashappe (subscriber, #4810) [Link] (4 responses)

Would it be possible to add an easy way filtering (or collapsing) guest comments? Not long-term or in a permanent way in the database but rather like a ``view filter'' (for lack of better words)?

When a article seems to be collecting flames then I tend to mostly ignore guest posts (due to lack of time) -- my theory is that subscribers don't sh*t where they eat and move their asbestos/flame-related needs to reddit (:

but anyway, thank you for your work!

No, comment filters don't work perfectly

Posted Nov 19, 2014 23:27 UTC (Wed) by corbet (editor, #1) [Link] (3 responses)

Filtering guest comments would be a useful feature. I'll look into what it would take to add that, it might not be that hard.

No, comment filters don't work perfectly

Posted Nov 20, 2014 7:07 UTC (Thu) by peterhoeg (guest, #4944) [Link] (2 responses)

Have you considered opening up the source for the site?

Considering your primary audience, I think you would not have problems finding readers who would submit patches.

No, comment filters don't work perfectly

Posted Nov 20, 2014 7:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>>Is the LWN site code open source?
>Not yet. We do intend to release our code once it gets a bit more "ready," has had one more security audit, and when we are in a position to support it as an open source project.
>Unfortunately, we spend most of our time creating the content that makes up LWN, and trying to bring in enough money to keep food on the table (servers running, etc.), so it has not, yet, gotten anywhere near the top of the priority list. When LWN reaches a level that is truly self-sustaining, we certainly will spend some time to get that done. Thanks for your patience.

Right here in the: https://lwn.net/op/FAQ.lwn

No, comment filters don't work perfectly

Posted Nov 20, 2014 13:49 UTC (Thu) by fb (guest, #53265) [Link]

I always found the instance of not opening up LWN source a little silly.

I mean:
- sure the code likely looks like crap. It is not as if we all don't write crap code.
- yes, there are likely exploitable bugs there.

Given the popularity of this site, it would surely get reviewed and cleaned fast, AND I would be more likely to get fancier features at LWN.

Hey Jon, please consider placing a git repository somewhere and announcing only for subscribers. Within a month, the code would likely get cleaned AND you would have enough material to write a few major articles out of the experience.

No, comment filters don't work perfectly

Posted Nov 19, 2014 23:27 UTC (Wed) by louie (guest, #3285) [Link]

The exhaustion doesn't surprise at all, but nevertheless I'm very sorry to hear it.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 16:30 UTC (Wed) by jch (guest, #51929) [Link] (2 responses)

> This is exactly the sort of comment I asked people not to post.

I actually found ctun's comment rather funny, and neither disrespectful nor a rehash of previous arguments.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 19:21 UTC (Wed) by fest3er (guest, #60379) [Link]

Hyperbolic satire; it's so over-the-top, it has to be funny. And it clearly isn't true because systemd will never be in my GNU/Linux distro. :)

Probably as long as I use GNU/Linux on my desktop, it'll be Debian. If I change, it'll be back to Haiku (BeOS).

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 21, 2014 10:11 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> I actually found ctun's comment rather funny, and neither disrespectful nor a rehash of previous arguments.

...and it was an obvious troll. Consider it a good thing or a bad thing as you wish. (I consider it a bad thing.)

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 19:57 UTC (Wed) by timtas (guest, #2815) [Link] (11 responses)

True, but funny that you didn't mind HelloWorld's disrespectful comments.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:03 UTC (Wed) by corbet (editor, #1) [Link]

Oh I minded them all right. But it's Wednesday and I only have so much time to nag people. Especially people I've had to nag several times in the past.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:25 UTC (Wed) by HelloWorld (guest, #56129) [Link] (9 responses)

My comments were not disrespectful but an accurate depiction of what happened. And you know what? I actually find Jon's behaviour inappropriate. Trolls like mgb get to spread their hatespeech all over the place while people who'd like to criticise one of the primarly culprits of all this mudslinging are muzzled (and let's face it, he clearly was, otherwise there'd be no need for Jon's request in the first place!). Because that's how you encourage the right kind of behaviour.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:36 UTC (Wed) by corbet (editor, #1) [Link] (3 responses)

FWIW I have asked mgb to tone it down before as well.

The thing that you miss is that there's a time and a place for things. This particular occasion is neither. It doesn't seem all that hard to figure that out, but I guess some people need help.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:47 UTC (Wed) by SEJeff (guest, #51588) [Link]

And Jon, we thank you for your gentler style, which results in (overall) LWN from not devulging into another HN or /.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:57 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> The thing that you miss is that there's a time and a place for things.
I didn't miss that, I'm just afraid we disagree on what this is the time for. The week that several accomplished project members resigned in due to his actions is most certainly *not* the week we should thank him for his work on dpkg.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 21:22 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Then don't thank him. Noone has requested that you thank him. Be silent.
Just let him go quietly. Please just let him go. If it irks you that other people are thanking him...just grit your teeth and let it happen and just let him go.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 23:19 UTC (Wed) by timtas (guest, #2815) [Link] (4 responses)

Well, I have learnt early in school to stop kicking when somebody lies on the floor. Ian Jackson has been with Debian for 16 years, was project leader, wrote dpkg and has therefore the right of a decent leaving of Debian. To now dig deep and pull out the most ranting emails he has written clearly is totally disrespectful to him.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 21, 2014 21:55 UTC (Fri) by HelloWorld (guest, #56129) [Link] (3 responses)

Well, I have learnt something at school too: to take responsibility for my actions. I thus stand by my opinion: when you behave like a dick, you have to be prepared to take the blame for it. The people whom you should be sorry for are Russ, Colin, Joey and Tollef who couldn't take it any more, and while Ian certainly isn't the only one to blame for that, he certainly was part of the problem. In a situation like this it should be made clear that this behaviour is intolerable. Instead Jon asks us for leniency for Ian, and when Lennart dares to actually complain about the abuse he suffered, Jon writes an article ("on the sickness of our community") that basically denies the problem and blames the victim, perhaps to avoid fouling his own nest. I'm sorry, but that just doesn't seem right to me.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 22, 2014 1:55 UTC (Sat) by itvirta (guest, #49997) [Link]

There are some things I learned at school, most of them technical in nature.

There are also things I've learned, that were not taught at school.
Things I had to learn outside of it, in the real world, with real people.

One of those was to learn at least some ways to take other people's
feelings into account; and, especially, when to recognise that saying
something will not do any good, and it would be better to just keep my
mouth shut.

I would recommend everyone to at least try to take these things into
account.

For what it's worth (probably not much), I think our valued editor has
done his best to ask for leniency towards _all_, not just any single
person or persons. I can't say I agree with him on every single
occasion, but I cannot do anything but hold that principle in high regard.

--

I'm sorry to say this, but I do not think the editor is the only party
around here to say something that does not seem right.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 22, 2014 15:44 UTC (Sat) by Zack (guest, #37335) [Link] (1 responses)

"To take responsibility for my actions," he wrote on the Internet, anonymously. He tried to fan the dying embers. Soon the cold would return, and with it the dampness. It was lonely at the waterfront, but at least it provided shelter.

flaming poetry

Posted Nov 29, 2014 13:40 UTC (Sat) by DonDiego (guest, #24141) [Link]

You know what? That was a strikingly beautiful piece of lyrical prose. You just made my day. I think I'll stick a modified version of this on my wall somewhere. Thank you.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 17:35 UTC (Wed) by josh (subscriber, #17465) [Link]

> I now hope to spend more of my free software time doing programming. dgit is at the top of my Debian queue, but some of my GNU and SGO projects could do with attention too.

I've been quite impressed with Ian's technical contributions to Debian, particularly dgit, and I'm glad to hear that he plans to continue that work. I would have been quite sad if this had been a resignation from the project rather than the TC.

If you haven't seen dgit, take a look at it; it's an impressive bit of wizardry that lets you pretend the entire Debian repository all lives in git.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 18:09 UTC (Wed) by mgb (guest, #3226) [Link]

Successful volunteer projects aspire to quality standards. Others are playgrounds. Sad to see Debian flip but nobody could have worked harder than Ian trying to protect the magnificent body of work that Debian had built over the years.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 18:33 UTC (Wed) by amacater (subscriber, #790) [Link]

Whatever you may think of the GR, the results, or how people have behaved - and leaving aside the trolls from outside the Debian Project - it has to be said that Colin Watson and Ian Jackson have both been magnanimous and behaved well as they have each chosen to step down from the Technical Committee for similar reasons.

I had the pleasure of attending the mini-Debconf with them in Cambridge recently: neither of them is a devil incarnate, both of them are helpful.

Now can we have a couple of months of relative peace and quiet so that a planned Jesssie release can actually take place - please?

Andy - speaking for himself in his own right as a Debian user in this instance and NOT as a Debian developer or for anyone else in the wider Debian Project.

[Disclaimer: I _am_ a Debian developer - my LWN subscription has been sponsored for many years as a side benefit of being a DD.]

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 19:02 UTC (Wed) by jb.1234abcd (guest, #95827) [Link]

Mr. Jackson,

I would like to thank you for representing the "minority" view in this
important decision process at Debian project.
You did well and deserve some peace now :-)

I, and many others, regardless of our favorite distro affiliation, were
and still are supporting the same cause on various discussion venues because it is important to us as well.

Things may change in this matter as the time progresses.

jb

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 19, 2014 20:04 UTC (Wed) by yohahn (guest, #4107) [Link] (1 responses)

I wondered if the resolution was too broad but would have more merit in a restricted manner. I did wonder if this is really about defaults and not about packages in general.

If we looked at default install packages like monopolies, i.e. they can exist, but because they wield certain powers they should be regulated a bit more strictly, would we have had as much controversy?

If a package didn't want more regulation it could opt not to be the default.

Just a random thought. I'm still not sure what I think of the whole thing myself. I need to start wrestling with the new debian with systemd before I'll really know.

That said.. I'm just a random sysadmin, not a dev.

Hopefully closure comes.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 20, 2014 6:09 UTC (Thu) by pabs (subscriber, #43278) [Link]

If you are interested in understanding how systemd works etc, I would recommend going through Lennart's blog posts about it starting at the beginning with the initial post about his review of existing init systems. His "systemd For Administrators" blog series is also very interesting.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 20, 2014 13:42 UTC (Thu) by deepfire (guest, #26138) [Link] (3 responses)

I am grateful for Ian's insistence on hedging against the uncertainties that systemd adoption brings to us.

Let's be honest -- it's not a debate about an init system. Systemd is much more, and aspires for still more.

Systemd seeks a profound change to how Linux systems are composed.

God help us.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 21, 2014 17:26 UTC (Fri) by Kamilion (subscriber, #42576) [Link] (2 responses)

Uh? According to the last graphs of market share I saw, "Linux Systems" are far and above anything else out there due to Android's usage of the Linux kernel.

http://cdn-static.zdnet.com/i/r/story/70/00/008699/meeker...

So, unless the BSD-license proponents at Google go away, I seriously doubt systemd will be able to effect a profound change to how Linux systems are composed.

However, what I actually suspect you meant was GNU/Linux, linux with the GPL3 GNU userspace running glibc and a standard unix-style structure based against the POSIX and FSH specifications.

In reality, these systems are extremely rare when we have supercomputers that have 4096 CPU packages running Single System Image linux, and counted as one computer just the same as the dualcore galaxy S3 in my pocket.

In my *personal* opinion, I am not personally thrilled with 'sticking with POSIX' and feel that there is still 'nothing else' out there that really tries to do their own thing besides maybe Gobo Linux or QubesOS.

I am quite quite thrilled at the benefits that hardware virtualization has brought to the table, as it means I can nest a nonstandard system within a standard system or a standard posix system on top of something else.

Xen on ARM64 blows people's minds when you pull what looks to be an oversized USB stick from your pocket and explain it's fully capable of running nine distributions of GNU/Linux at the same time.

Let's help ourselves and leave God to deal with his own business.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 21, 2014 23:47 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> when we have supercomputers that have 4096 CPU packages running Single System Image linux, and counted as one computer just the same as the dualcore galaxy S3 in my pocket.

supercomputers are not running a single system image, so they would count as hundreds or thousands of computers.

unfortunately for the stats, they only cound people who bother reporting that they are running linux, so if the supercomputer operator doesn't go out of their way to report the thousands of machines, they won't be visible to the stats.

The same thing goes for all the machines that Google runs in their datacenter. There are a lot of them and Google won't tell you how many, but the fact that they are missing from the stats makes a noticeable difference. The same thing applies to msot corporate datacenters and cloud systems, you don't know how many instances of Linux are running, and have no way of knowing.

Today's Debian technical committee resignation: Ian Jackson

Posted Nov 23, 2014 23:40 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link]

Just to comment, as I'm someone who's been working in HPC for a while.

You are both right - there are indeed distributed memory systems out there as dlang mentions (the now "traditional" 20 year old Beowulf clusters) and also large Single-System-Image systems that bind lots of NUMA nodes together into a single machine that Kamilion mentions (think SGI's UltraViolet and earlier Altix systems for example).

Of course building a really massive Single-System-Image is very challenging as I believe the Linux kernel is limited to just 64TB of RAM so you can only get larger than that with distributed memory systems. :-(

All the best,
Chris

From:		Ian Jackson <ijackson-AT-chiark.greenend.org.uk>
To:		debian-ctte-AT-lists.debian.org
Subject:		Resignation
Date:		Wed, 19 Nov 2014 13:08:29 +0000
Message-ID:		<21612.38477.245453.248600@chiark.greenend.org.uk>
Archive‑link:		Article