Joey Hess, Developer Of 18 Years With Debian Departs – Second Edition

This is a duplicate of the article below so that comments can work again. Some comments may be lost

The strife in the Debian community has had another casualty, Joey Hess.“If I have one regret from my 18 years in Debian, it’s that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It’s clear to me now that it’s a toxic document, that has slowly but surely led Debian in very unhealthy directions.” He’s been there working hard since nearly the beginning but he’s fed up with the bickering/second-guessing/friction involved in the process these days. In messages on the debian-devel list, he describes his frustration with arguing about systemd for nearly two years and now, just weeks before the freeze of Jessie, users are up in arms.

I can see his point, but users are not developers and don’t read debian-devel. I don’t usually. It’s not surprising that users vent the same frustrations about systemd that developers did. There are a lot more users than developers, thousands of times more, and they need to be considered in making radical change to their operating system, something near and dear… Still everyone’s life goes through stages and it may well have been time for Joey Hess to move on for other reasons as well. I expect Debian will survive and it may survive by taking some of Joey Hess’ advice. Probably the worst thing that could happen is more developers leaving, followed closely by some kind of fork and revolution in the splinter group.

Perhaps it’s time that Debian reform it’s social contract/internal procedures to deal with dissent by better means than personal attacks on the lists or departures of key people. Democracy/fairness works but sometimes gets off the rails when conflicting groups try to have their way at the expense of others. It’s not enough just to have a mechanism to break deadlocks. It’s important to respect minorities of users as it is to respect the majority of developers. One only needs to see the USAian government to see how extremism and disrespect can go way overboard. We don’t want Debian to go that way.

See so long and thanks for all the fish.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , . Bookmark the permalink.

33 Responses to Joey Hess, Developer Of 18 Years With Debian Departs – Second Edition

  1. DrLoser says:

    Having said that, Robert, I’d fight back if I were you.

    Apache dependent on nothing?

  2. DrLoser says:

    We’re to take it that oiaohm is actually more competent than Robert to navigate around the relatively simple ways of systemd configuration?

    OK.

    I can buy that.

  3. oiaohm says:

    The reason why it worked for me is my apache is not starting as part of sysinit.target Yes apache is disabled in my rcx.d directories.

    I have a new target called services that has apache and other services in it that is Dependant on nothing.

    systemctl |grep LSB if this did not include xdm or kdm because these were real unit files you most likely could push the complete sysinit.target to be after graphical start.

    sysvinit mixed with systemd equals cat fight.

    Everything LSB: comes out of the systemd-sysv-generator as in memory service files.
    /run/systemd/generator
    /run/systemd/generator.late
    is where you find generated.

    I bet your /etc/rcx.d directory still contains apache starting. So then it has to obey the conditions of the sysvinit start of being before basic.

  4. DrLoser says:

    The old-fashioned scripts weren’t doing that. Systemd is doing its own thing.

    To quote the Church Lady, “isn’t that surprising?

    Briefly, system is a different (and better imho) dependency chain. They’ve gone to considerable lengths to make it backward compatible. But at some point you are going to have to deal with the “unit” files.

    Which, in all honesty, are basically just cleaned up versions of rc.d files.

    I was given to understand that the beauty of FLOSS is that you were empowered.

    Apparently, with this single tiny little lurch into the third millennium, you’re actually enfeebled, Robert.

    Never mind. There will be more competent Prophets after you have passed on.

  5. DrLoser says:

    Without intending to I’ve disabled apache and can start it my own way. This is progress, but systemd sure gets in my way for a default.

    So then. What we can assume is that the standard release of whichever Debian it is will basically start up everything with no problem. (I am stipulating here that Debian has a reasonable QA system and doesn’t just throw things at the wall and watch them go splat!)

    We can further assume, I think, that Apache is one of the more important bits of Debian.

    We can therefore deduce that you are doing it wrong, Robert.

    Either that, or the tens of millions of other Debian users out there are somehow failing to notice this minor little issue.

  6. oiaohm wrote, “my last option when dealing with dependency chain hell it tell systemd disable the services I want to latter.”

    I don’t even see how/why apache2 starts. There’s no apache2.service file for it. So, how do I start it later? This is not working for me. Whatever reasonable edit I make to the files is rejected. The thing starts basic.target and multiuser.target and neither mentions apache2.

    Wait! Look at this!
    cat apache2.service.d/apache2.conf
    [Unit]
    After=xdm.service graphical.target
    beast:/etc/systemd/system# dmesg|grep apach
    [ 6.467574] systemd[1]: Breaking ordering cycle by deleting job apache2.service/start
    [ 6.467578] systemd[1]: Job apache2.service/start deleted to break ordering cycle starting with graphical.target/start

    Without intending to I’ve disabled apache and can start it my own way. This is progress, but systemd sure gets in my way for a default.

    graphical.target, of course, does not mention apache, so how does apache start?
    [Unit]
    Description=Graphical Interface
    Documentation=man:systemd.special(7)
    Requires=multi-user.target
    After=multi-user.target
    Conflicts=rescue.target
    Wants=display-manager.service
    AllowIsolate=yes

    Neither does multi-user.target:
    [Unit]
    Description=Multi-User System
    Documentation=man:systemd.special(7)
    Requires=basic.target
    Conflicts=rescue.service rescue.target
    After=basic.target rescue.service rescue.target
    AllowIsolate=yes

    And neither does basic.target:
    [Unit]
    Description=Basic System
    Documentation=man:systemd.special(7)
    Requires=sysinit.target
    Wants=sockets.target timers.target paths.target slices.target
    After=sysinit.target sockets.target timers.target paths.target slices.target

    There are so many layers of BS in systemd. I hate it.

  7. oiaohm says:

    Robert Pogson my last option when dealing with dependency chain hell it tell systemd disable the services I want to latter. Then use timer latter on to wake up a service Dependant on them all so bring all those services I want to life latter..

    Sometimes systemd is a bugger and remember dependency chains and does not want to change them.

  8. oiaohm says:

    luvr the default they don’t have any dependency on each under systemd. Cpu resources are limited. Result of random start order is apache and other things starting before xdm/kdm.

    Setting sysinit number higher than xdm/kdm on apache2 also created dependency that xdm/kdm get run fist. Failure of something before you in a sysvinit setup can still result in your service not starting.

    Yes there was a reason why I bound to the target not the xdm.service. If everything in a target fails it still gets a completed status.

    http://www.freedesktop.org/software/systemd/man/systemd.timer.html
    Another option is use timer files to delay services start to a particular boot second. Of course for reduced pain it can pay to setup a delay.service for this job and make all the services needing to be delayed dependent on it. Yes counting too many timers become cpu costly.

    It is also possible to combined conditional path checks with a timer. So service starts when conditional paths are met or when timer triggers what ever one happens first under systemd.

    luvr there are other options as well. Basically there are ways under systemd to skin the cat and get the same result as sysvinit was doing. The problem is you need to skin the cat a different way.

  9. wrote too soon. Systemd finds a loop and disables the tweak.
    “[ 6.378370] systemd[1]: Found ordering cycle on apache2.service/start
    [ 6.378379] systemd[1]: Job x-display-manager.target/start deleted to break ordering cycle starting with apache2.service/star”

    x-display-manager.target depends on xdm.service which depends on apache2.service…. Do I have to manually override every dependency in the chain? I guess so. Then there are the databases and udev pauses for 30s to wait for devices… Sigh.

  10. oiaohm wrote, “Place a file in directory ending in .conf containing
    [Unit]
    After=x-display-manager.target”

    Weird, but it works… Thanks. On my system there isn’t a apache2.service file so I could not tweak it. It’s dynamic… So this looks like tweaking a non-existent configuration. Weird.

  11. luvr says:

    “Now you want apache2 to start after graphical login right.”

    Actually, I don’t think that’s what Robert was after. As I understand him, he wants to start Apache and the Display Manager without any dependency between them. Neither has to be running for the other to start.

  12. oiaohm says:

    Robert Pogson
    That’s false. Should your PC fail to allow you to login because some server out on the web is down?
    When a dependency fails that is not a hard dependency systemd still start the following services.

    It really depends what that missing service is. Winbind for example to allow logins using Windows servers. Or maybe something like vpn that should be up to allow a company network login.

    It’s just wrong to require every service to be up for login. That’s true even if the service is local.
    My KDM login screen appears half way through the boot process and I can login while the remaining services are still coming up. Basically its not required it how systemd is calculating it out with the information it currently has on your system.

    Apache on my system starts after KDM.

    Robert Pogson I will give you getting around how to order things on systemd so they start where you want them is a little tricky. Kinda kills new systemd users because they do completely the wrong thing. (yes I did as well)

    https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Startup_Process_-_Systemd

    Nice is write up but like all them they miss something so critical its not funny.

    Now you want apache2 to start after graphical login right.

    Make directory /etc/systemd/system/apache2.service.d
    Place a file in directory ending in .conf containing
    [Unit]
    After=x-display-manager.target

    Simple right. Guess what this tweak is not crushed by updates or anything else.

    Temptation is straight up edit the unit files that brings hell. Systemd supports the .d standard for adding to unit files customization.

    A user of systemd should be able to choose.
    Yes a user of systemd is able to choose it is just different. Add a few .d directories order the services you want to run after the login is running to be Dependant on after.

    Nice part of systemd unit files is the fact they allow many after and before declares. So the addon .conf option has not overridden any defined already in the unit file so limiting how badly you can screw it up. Yes everything depending on apache2 in my example would be pushed to starting after xdm.service as well.

    I find systemd a lot cleaner to know what I have messed with. Coming from sysvinit you are looking for numbers not create a new directory and then create a file in to tell the system do something different.

    Systemd you leave your distrobution installed files alone.

    systemctl list-dependencies xdm.service
    This here lists exactly what systemd thinks it needs to get started before starting xdm. You will find apache2 is not listed and of course the following
    systemctl list-dependencies apache2.service
    List apache2 list

    Default systemd starts service as soon as dependencies list is met. So apache2 out box starts before xdm. Fix add a dependency.

    What ever you do don’t follow any instructions suggesting messing with files in /lib/systemd/system as these will be updated with packages.

    Everything about systemd start order comes down to too many or too few dependencies for it to be starting it where you want it to.

    There is a before command as well.

  13. oiaohm wrote, “Allow you to login while services that you may need uses are not ready not a highly good idea.”

    That’s false. Should your PC fail to allow you to login because some server out on the web is down? Say, LibreOffice.org. If they were down, I might not be able to visit that site, but there’s probably a mirror somewhere, or a Google cache entry or a different site with useful information. It’s just wrong to require every service to be up for login. That’s true even if the service is local. There are some services locally that are highly desirable for a logged in user but not essential. A user of systemd should be able to choose. I’ve tried. I haven’t been able to do it in several tries. I have managed to make my system unbootable but to get Debian to be bootable I have to start and have everything local up before systemd will allow me to log in. That’s just silly. I can stop apache without having to log out. Why should I have to have it up to login? That’s stupid and dangerous if I really need to do something and can’t because of such a rule. This is an inflexibility in systemd that’s really annoying. Under sysvinit, apache and xdm could start together or I could manually start apache afterward. I guess I can still do that and put some commands in apps to be started in the GUI. How is systemd making my life better? It’s not. It’s adding complexity/inflexibility. That’s not why I chose Debian GNU/Linux.

  14. oiaohm says:

    Robert Pogson
    From where I stand, its purpose seems to be slowing down booting on Beast by starting and finishing everything before xdm starts. That’s wrong, dangerous and stupid. The old-fashioned scripts weren’t doing that. Systemd is doing its own thing. Now I have to try to undo what’s in the Debian packages without having my handiwork undone on the next update…
    This is the pain of a change of init system.

    Robert Pogson what the old init system was doing was truly dangerous and stupid. Allow you to login while services that you may need uses are not ready not a highly good idea.

    Lot of cases slow start up trace to lost files with systemd trace to handling old files.
    systemctl and you will most likely see that xdm has a LSB: yep its old script. Systemd not 100 percent sure of it dependencies and LSB init scripts over state dependency. LSB script states that X services requires Y other services started but does not state if X service can be started safely before Y services are running. The old sysvinit of debian was presuming it was safe to start X before Y other services were started.

    Robert Pogson so it a case of fixed a bug and caused a bug. As debian gets more proper unit files with better description of dependency these issues will reduce.

    KDM on my system starts way earlier with systemd than what xdm does because it does not list the huge stack of dependencies xdm does. Yet both under the old init system would start at the same time. I would have not know the difference myself if I had not dig into what is going on problem.

    Robert Pogson systemd is about having a fast and safe boot. Debian multi process sysvinit variant really did not check if what it was doing was safe. Unsafe equals faster boot.

  15. DrLoser wrote, “The whole point of systemd is that eventually this nominalist crap will completely disappear.”

    I’m not so sure. From where I stand, its purpose seems to be slowing down booting on Beast by starting and finishing everything before xdm starts. That’s wrong, dangerous and stupid. The old-fashioned scripts weren’t doing that. Systemd is doing its own thing. Now I have to try to undo what’s in the Debian packages without having my handiwork undone on the next update…

  16. DrLoser says:

    Were you not aware that the LSB has changed over time I guess not DrLoser so you did not bother checking what version the page quotes were refering to then also did not check that pages history on the wikipedia.

    Constantly referring to the often monumentally long history of various uninteresting Wikipedia pages is not an activity that is suited to anybody, like (say) everybody else on this site, oiaohm.

    Still, I suppose it saves you on subscriptions to Playboy and the like.

  17. DrLoser says:

    Switch from init 1 to init 5 is found in LSB application install scripts that are 3.2 conform-ant or before.

    Who cares?

    The whole point of systemd is that eventually this nominalist crap will completely disappear.

    First of all, practically any script whatsoever is going to be conformant. That’s the whole stupid principle behind scripts. And it’s wrong and it’s dangerous and it’s stupid.

    And secondly, even if you have truffled up some important script-wizard discovery (you haven’t, btw), there’s no reason not to adjust that script to jump into init 2, 3 or 4.

    Depending upon what system facilities are available in init 2, 3 or 4.

    Which is precisely the point.

  18. oiaohm says:

    DrLoser you claim to be master of everything Linux that is Myth so you should know every single wikipedia bug without having me point it out.

    Switch from init 1 to init 5 is found in LSB application install scripts that are 3.2 conform-ant or before.

    As I said debian has two run-level patterns. Debians and LSB as configuration options.

    Init level 5 has historical always been the X11 init.

    Next LSB conforming applications it is valid to look at run level and decide if they will attempt graphical or not.
    I did not say what version. Older versions of that wikipedia page also had it correct for older versions of LSB. Sorry DrLoser only 1 cite was required if you researched the cite. The wikipedia is dynamic the evil thing does from time to time lose a key detail or two that is use to have.

    Were you not aware that the LSB has changed over time I guess not DrLoser so you did not bother checking what version the page quotes were refering to then also did not check that pages history on the wikipedia.

  19. DrLoser says:

    In other words (and in theory), system is designed to eliminate side-effects (via the use of a declarative model) whilst booting up a Linux system.

    Naturally it would be quite helpful if Pid Eins or Lennart Poettering bothered to point this out.

    Side effects are bad things.

  20. DrLoser says:

    If I can proceed from the minor irritation of helping oiaohm out with his historical inaccuracies and obvious inability to parse a fairly straight-forward Wikipedia article, Robert, I’d like to agree with you on the general topic of understanding how systemd works.

    See, to understand the architectural principle, you have to make a fairly massive perceptual shift. With Sysvinit you are dealing essentially with a bunch of disparate procedural bits of booting up. With systemd, you are dealing with a declarative model.

    And this is a source of confusion and irritation to both of us. (Believe me, Robert. I have spent several weeks working with a similar declarative model, ie the WiX installer on M$. I suspect the two experiences are comparable.)

    From a million-mile high perspective, the declarative model is clearly superior. You want to get from A (nothing) to Z (everything nicely booted up). You don’t actually care how you get there.

    Except that there are Bs and Qs and occasionally a misplaced J in the way. No problem! Define a dependency relationship between them, and the model is still declarative.

    Now, with Sysvinit, it’s anything but. When you write a procedural script, complete with if-exprs and waits and what not, it’s intuitive to assume that your script starts at the top, ends at the bottom, and all is well with the world.

    Except when it isn’t. And we’ve all been there. And we’ve all tweaked our rcn.d scripts to account for edge cases and stuff.

    Is systemd the answer? Personally, I claim it is. But mostly I claim that because I can’t stand faffing around with stupid bash scripts just to get my computer up and running in a coherent state.

    YMMV.

  21. DrLoser says:

    Basically applications are no longer from LSB 4.0.0 on are meant to depend on runlevel information at all.

    Did I say that this was ever a requirement? No, I didn’t. But it’s what you clearly implied, oiaohm.

    DrLoser remember how the Wikipedia is not 100 percent correct.

    Well, it was the only source you cited, oiaohm. As a matter of fact, it’s still the only source you’ve cited.

    I am therefore predisposed to the assumption that you are basing your information on that source, and then adding your usual soupcon of imaginary nonsense pulled out of thin air. To quote your original claim:

    Next LSB conforming applications it is valid to look at run level and decide if they will attempt graphical or not.

    You have now completely reversed your opinion and (correctly) claim that this is arrant nonsense.

    One of us needs a “history lesson” on *nix runlevels (and Linux runlevels in this specific case), but it ain’t me, oiaohm.

    Briefly, the only genuinely “standard” ones are 0, 1 and 6. If you like, you can split 1 into “pure 1” and “S,” although in any given case I would have to deep-dive documentation to remember precisely what the difference between “1” and “S” is.

    Run-levels 2-5 have had various historical significance at various times and on various platforms. In Linux, the only really important thing about them is which run-level is defined by /etc/inittab as the default run-level. For tolerably obvious reasons, everything else is up for grabs as far as a Distro is concerned.

    Enough “history” for you?

    Oh, and there’s no evidence whatsoever that systemd breaks any of this in any way at all. The two links provided by Robert are, respectively, to a “bug” that cannot be reproduced (and is a seriously weird choice of action inside a systemd environment in any case) and a reporting bug that apparently misinforms the user as to which rcn.d is presently being processed.

    I fail to see how either of those is going to bring the boot process (or anything else) crashing down to the ground.

    Which, barring babbling claims about historical knowledge, and barring confused ramblings about the LSB, is pretty much what we were talking about before you butted in, oiaohm.

  22. oiaohm says:

    DrLoser remember how the Wikipedia is not 100 percent correct. The LSB does not state that runlevel layout is optional in all versions of LSB. LSB 4.0.0 and later does but this also includes something else. But you might have an older LSB application where is not stated as optional.

    I did not say what version LSB. From LSB 1.0 to 3.2 it was not stated as optional on Runlevels. LSB 4.0 and newer applications are not meant to look at runlevel at all.

    Applications may not depend on specific run-level numbers.
    Basically applications are no longer from LSB 4.0.0 on are meant to depend on runlevel information at all. Remember applications include servers. So anything breaking under systemd handling of runlevels is not LSB 4.0.0 or latter conforming. It could be LSB 3.2 or older conforming. Application support is application support. LSB define of applications include services.

    DrLoser standards evolve. Items like LSB standards are snapshot in time. Yes running a LSB 1.0 application on the latest Linux distribution is possible. Full conformance with LSB requires the means to meet particular requirements this includes the correct runlevel values.

    The wikipedia quote is only based off LSB 4.1.0 or post 4.0.0 information. Lack means to set runlevels as per LSB lack support for applications before LSB 4.0.0.

    Also the wikipedia fails to quote that no application should depend on Runlevel values as of LSB 4.0.0 or latter. So from LSB 4.0.0 and latter what they are define as should be completely not important and LSB 4.0.0 on only has run-level values as a guide to Distribution makers to make system administration simpler.

    DrLoser basically information in the wikipedia is badly abridged. Debian has been LSB conforming back to LSB 1.0. Not all distributions are that conforming. Yes the runlevel 5 thing is about being in conformance to every version of LSB. There are not many LSB 3.2 and before applications that have not been updated or replaced.

    When checking conformance you do what appears stupid things and then complains about them.

  23. DrLoser says:

    Next LSB conforming applications it is valid to look at run level and decide if they will attempt graphical or not.

    From your own cite, oiaohm:

    Systems conforming to the Linux Standard Base (LSB) need not provide the exact run levels given here or give them the meanings described here, and may map any level described here to a different level which provides the equivalent functionality.

    Your point was, Keeper of the LSB Historical Flame?

  24. oiaohm says:

    DrLoser really sometimes you need to learn some history.

    http://en.wikipedia.org/wiki/Runlevel#Standard_runlevels

    Debian with or without LSB. Yes debian runlevels can be either debian own or LSB conforming. Next LSB conforming applications it is valid to look at run level and decide if they will attempt graphical or not. Init 5 for cross distrobution applications means graphical not Init 5 most likely not graphical.

  25. DrLoser says:

    Amusingly enough, you’ve managed to justify that awful and completely unwarranted Wikipedia attitude to your otherwise sane and rational and perfectly to the point articles and revisions, Robert.

    How many links to your own site did you include?

    Quite a lot?

  26. DrLoser says:

    Ah, I’ve just figured out this “moderation” stuff, Robert. It’s all about too many URLs in a single post, isn’t it?

    Well, there goes the collective wisdom of Dougie. Sad, but hard choices have to be made.

    Here’s a question about commutable operations that might be relevant, Robert:

    What’s the difference between 2 x 3 and 3 x 2?

  27. DrLoser says:

    However, Robert, I have downloaded the source code for systemd. I am one of the Fallen: I just grabbed a tgz. You are one of the Chosen: you can pick a DEB — perfection! — or a RPM — diseased, but at least GPL!
    Download the stuff. Utilize your Four Freedoms!
    I’d absolutely love to explain to you what I’ve found out, by analysing the code, concerning systemd and runlevels …

    But I don’t really want to anchor your opinions on the subject.

    Go analyse the C code, Robert!

  28. DrLoser says:

    Debian is normally in runlevel 2 but systemd uses 5 like RedHat…

    Now, I am too lazy to set up a VM with Debian in it, Robert, but luckily you can help me here.

    Does Beast have files with absolute paths like /etc/rc2.d, /etc/rc3.d, /etc/rc4.d and /etc/rc5.d?

    It does? Then your version of Debian is effectively running, concurrently, at runlevels 2, 3, 4 and 5.

    These are all multi-user “runlevels.” Runlevels 0 (PROM), 1/S, and 6 are basically reserved. And runlevel 5 means something in, say, Solaris, but nothing much at all in any flavour of Linux you care to mention.

    I can help you with this not very confusing stuff, you know. First of all, one of your cites boils down to:

    It looks like systemd changes the runlevel only after having finished a
    target and not when entering/executing a target.

    Actually, no, it does not. It “looks like” systemd bothers to report the runlevel only after having “finished” a target … whatever “finishing” might mean.

    End of bug. No effect on your system, other than logging.

    Secondly:

    Inserting the root password and then just typing “init 5” will result in a very odd situation:
    – Blank screen … etc

    This bug is filed as “unreproducible.”

    It should really be filed as “User Is A Moron.”

    I fail to imagine any good reason at all why a user should log in to runlevel 1 (hey! me gets a terminal and all!) and then, for some completely unknown reason, randomly chooses init 5.

    What, precisely, would be the point of that?

  29. DrLoser says:

    I hope you’ll forgive me, Robert, but I chose to move my answer to this systemd issue here, where it’s a little more relevant. To recap your comment (readers can use the previously cited link to get context):

    DrLoser wrote, “Actually, Robert, there’s only one “Grave functionality bug.”
    And one “Important bugs; Confirmed.”
    And three “Important bugs; More information needed.”
    And one “Normal bugs: Confirmed.””

    I don’t know where you’re looking but the list is much longer…

    I’m looking at the same cite you are, Robert. Four “Important,” of which one is confirmed and three need more information. And one “Normal, confirmed.”

    Let’s get one thing out of the way first. A bug report is not a bug. Otherwise Debian bug 727708 would be a bug. Which, admirable though its sentiment might be, it is not.

    Now, you’ll remember that I asked you for an instance of system causing you a personal issue (on Beast, I would assume). Take as much time as you want to, before formulating that issue.

    Meanwhile, you cite two bug reports:

    This one’s about runlevels.

    So’s this one.

    Hey ho.

  30. DrLoser says:

    It does look slick in some ways but it’s definitely not sliding into Debian easily. There’s a huge number of bug-reports.

    Actually, Robert, there’s only one “Grave functionality bug.”
    And one “Important bugs; Confirmed.”
    And three “Important bugs; More information needed.”
    And one “Normal bugs: Confirmed.”
    There’s a whole bunch of “wishlist,” but those are “desired features,” not “bugs.”

    TBH I don’t see that as particularly earth-shattering.

    Several of them are similar to the mess I have.

    You could, of course, submit pertinent comments on that “mess” to the Debian Bugzilla list. But let’s be a little more creative!

    Pick a single important bug that you see on your system, Robert, and we’ll all try to do the Community thing and resolve it for you!

    There, now. That can’t be too difficult, can it?

  31. DrLoser wrote, “I’m eliding the possibility of heaps of bugs out there, and also false dependencies buried in various packages.”

    It does look slick in some ways but it’s definitely not sliding into Debian easily. There’s a huge number of bug-reports. Several of them are similar to the mess I have. Anything that does not fit the mould breaks it. I know testing is for testing but I never would have installed it on a bunch of systems if I knew there would be this many surprises. I suppose it’s all fixable but just not by me… I’ve read the docs. How smooth it is but the things in the docs do nothing for my Beast. I’m going to take a break from symlinks and hope things improve on their own. In the meantime, I just won’t reboot. 🙂

  32. DrLoser says:

    That’s not what I want. I want apache and the databases to start but I don’t need them running until X is up.

    First, I’m going to confess complete ignorance on the subject.

    However, I would suggest looking at the systemd log files, which are apparently quite handy for this sort of thing, and scooting through them to identify the unit files that apply to your X config; I’m guessing just system.service. (Actually you could probably brute-force find these.)

    Unless I’m mistaken, you should be able to tweak the “wants/requires/before/after” and possibly the “conflicts” declarations to get X up and running either in parallel with or even before apached and postgresd.

    (Finalzone may already have made this recommendation, in which case I apologise for duplication.)

    TBH what little I’ve seen of systemd looks like a nicely declarative and consistent “little language” that really isn’t rocket science to learn. Of course, I’m eliding the possibility of heaps of bugs out there, and also false dependencies buried in various packages.

    But I don’t see why there should be a heap of these, and they should definitely diminish greatly with time. I mean, Red Hat has committed to the thing, so it’s getting a pretty good thrash-testing by large scale users.

  33. Don’t know what went wrong with the comments. Carrying on …

    I’ve got systemd running on Beast but it is really slow to get to the GUI. Finalzone was helpful. There’s lots of cruft that systemd has dug out of sysvinit, long lost services and the like. udev waits a full 30s before letting things run and X doesn’t start until everything is running… That’s not what I want. I want apache and the databases to start but I don’t need them running until X is up. I am the number one process in my world. I just need the browser and the network to have fun with X. I tried adding my own mygraphical.target but it’s not being recognized/used.

Leave a Reply