Live data from Hacker News

Shall we fork Debian?

debianfork.org

101–110 of 284 posts

Re: Shall we fork Debian?

#101
post #51

Earlier quoted context omitted.

I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR...

The next step in troubleshooting that one is to run strace and find out what's happening. I agree it's frustrating but if no one debugs these things, problems won't get solved. (and yes, scorching the earth and installing a different distro is a valid solution to the problem at hand)

I'm not sure how to make strace pid 1 :-) And I'm not quite ready to abandon Debian yet. I've created a virt-install script which reproduces the problem reliably (honestly all it does is install jessie, then lxc-docker). Hopefully my workload eases and I can put this trivially reproducible thing into a bug report somewhere (debian? systemd? docker) for somebody to see what's going on.

FWIW systemctl start docker works fine after the system has booted. It's configured to require network.target, and even though I can see network target scroll by during boot, it's still not being noticed.

The work-around is to make multiuser want docker, then I've got docker starting at bootup.

Re: Shall we fork Debian?

#102
post #8

Go ahead and fork. Just leave me alone while I enjoy using systemd. I think some people are taking this way too personal and overreact. Forking is probably the best way to stop all the whining.

A fork would also mean that Debian (systemd edition) would not have to keep legacy init script support. You could have a 'clean' systemd in around Jessie+1 I imagine.

Debian already supports non-Linux kernels on which systemd won't function. So the legacy init support (or a compatible alternative) will still be required.

Re: Shall we fork Debian?

#103
What a joke.

They can't even spell things correctly. It's System V instead of SystemV and systemd instead of SystemD

> only few of us have the time and patience to interact with Debian on a voluntary basis.

But a fork is less work I guess?

> Pure Debian by Veteran Unix Admins

Pretty funny thing to say as GNU and Linux are pretty un-unixy to begin with.

They link to mobile wikipedia

Re: Shall we fork Debian?

#104
Don't threaten a fork. Just do it when the time comes. It sounds like you don't have a single Debian committer on board and no real influence there so you are going to have to prove yourselves, just like every other vanity distribution.

Re: Shall we fork Debian?

#105
post #96
post #61

Earlier quoted context omitted.

https://www.youtube.com/watch?v=ZTdUmlGxVo0 This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD. The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc. Yes, it’s not the nicest way to interrupt a talk, b…

The way Lennart interacted with the speaker during that talk was extremely inappropriate. If he had corrections to make he could have arranged a short talk afterwards or a written blog post. It is very poor form to be so disruptive to a speaker, no matter how much you disagree with them.

No it isn't.. being on a soap box doesn't give you some special permission to just spread false information without being interrupted. I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community. What's up with that?

If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of. If you take the opportunity to talk in front of a lot of people, you should also take the responsibility to be properly prepared, and be ready to face the consequence of not performing adequately.

Re: Shall we fork Debian?

#106
post #51
post #28

Or just shut up and put your efforts into maintaining https://packages.debian.org/jessie/systemd-shim Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script? Also relevant: http://www.itwire.com/business-it-news/open-source/65684-deb...

I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR...

Does the official package not work for you? https://packages.debian.org/jessie/docker.io

Even the docker page tells you to use the docker package for Jessie: https://docs.docker.com/installation/debian/

Re: Shall we fork Debian?

#107

Earlier quoted context omitted.

Have you ever used it?

I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.

I've installed systemd on Debian testing months ago and have not had a single problem. https://wiki.debian.org/systemd has some hints. I think it's likely when Jessie is released you'll most likely find that stuff still works.

Re: Shall we fork Debian?

#108

Earlier quoted context omitted.

A fork would also mean that Debian (systemd edition) would not have to keep legacy init script support. You could have a 'clean' systemd in around Jessie+1 I imagine.

Debian already supports non-Linux kernels on which systemd won't function. So the legacy init support (or a compatible alternative) will still be required.

The fork could maintain these.

Re: Shall we fork Debian?

#109
A few points:

* These folks seem clueless. The cite Eric Raymond. Enough said.

* I like classic init. I'm actually not a big fan of systemd, but I clearly recognize something needs to be replaced. The system needs to handle parallelism and dependencies. It's essentially the same problem in a hundred different domains (from luigi, to things like make/ant/paver/rake, to things like supervisord). Each systems seems to solve it worse than the one before it.

Personally, I'd actually go with forking make, since it's the one everyone knows and the most Unix-y, modify it to:

* Handle long-running task and task restarts

* Handle parallelism

* Clean up some of the issues around modularity

Re: Shall we fork Debian?

#110
post #39

Earlier quoted context omitted.

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. And don't get me started on binary log files. As was said before, buster, your attitude is the problem. It's the same as the systemd developers and those within the community. SysVInit has served me thus far with no issues.

Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?

xl2tpd, still doesn't work.

I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.

took me some time to figure out it was systemd.

the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections"

My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.

Post reply on HN