Improving recovery (Re: support for merged /usr in Debian)
Simon McVittie debian.org> writes: > I personally think those factors undermine the "/ as recovery" use-case > so far that the advantages of a merged /usr far outweigh it. User side note: If people would like to help the recovery use case, grml-rescueboot is already packaged which adds grub integration. So the only thing missing to get better recovery with no other effort than installing a package is a grml-iso (or similar) package that depends on gmrl-rescueboot and either contains the latest grml ISO or downloads it to /boot/grml. Or perhaps integrate this directly into grml-rescueboot. Ole
Re: Proposal: switch default desktop to xfce
Steve McIntyre steve at einval.com writes: Pros: * CD#1 will work again without size worries * Smaller, simpler desktop * Works well/better on all supported kernels (?) * Does not depend on replacing init Cons: * please fill in here IMHO you forgot the crucial part here - why is there a default at all: so that people who don't have the information to make a choice don't have to. The arguments that come up here are from people who *have* made a choice. But if you have made a choice, you're not in the target group for the default. Right? As I see it, when you install Debian you're either an archetypical Debian hacker running some weirdo^Wperfect setup you've refined over the years (or soon-to-be version of the same), or you just don't care. For people who just don't care, are you doing them a favour by installing xfce rather than GNOME? I don't think so. Most of the things people hate about GNOME are things that GNOME is doing to specifically target people who just don't care. Are you doing the archetypical (perhaps still wannabe) Debian hacker a favour by choosing xfce? Possibly - but I think it's wrong to confound these two populations. Catering for the hackers is the same as saying that Debian is for Debian hackers, don't-cares go home. IMHO. Of course you can change the installer UI, etc., but when we're talking about the default, that's the message. Another side of the coin is momentum. Both GNOME and KDE have a lot of momentum. They are drivers for the Linux application landscape. E.g. they both are actively being ported to Wayland. IMHO a don't-care is in a much better long-term position with GNOME or KDE on his computer than one of the smaller environments. Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20131025t104930-...@post.gmane.org
Re: Proposal: switch default desktop to xfce
Thorsten Glaser tg at mirbsd.de writes: • Your primary use case appears to be “the desktop”, whereas Debian, as opposed to some of its downstreams and Pure Blends, is a Universal OS, which means it’s got much more servers in use, which don’t benefit from systemd either at all or at least not that much. I humbly disagree. I'm mainly interested in the perspectives of systemd on servers. For instance: I have in the past had downtime on servers I maintain because Debian out of the box doesn't babysit processes. Apache or MySQL hit by a random once-in-a-year irreproducible crash? Boom. The day of better systemd integration in Debian, where I can uninstall monit, or at least relegate it to application level testing (does this page return 200 OK), I'm a happy camper. If you take a look at the systemd feature set, much of it is aimed towards servers, not desktops. Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20131025t140418-...@post.gmane.org
Re: using upstart in Debian [was, Re: Debian systemd survey]
Steve Langasek vorlon at debian.org writes: Sorry you ran into trouble with upstart. Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic of Upstart, I have some technical comments on why, surprisingly, I think it may not be mature enough yet. A couple of years ago I was doing emergency consultancy work for a company using Red Hat and upstart. The dev dude there was really on top of new tech and had made Upstart scripts for starting his Python web apps (which I thought was a great idea, this was back when Upstart looked like THE alternative to sysvinit). However, when debugging it, we had some weird lock-ups from Upstart, basically you'd ask Upstart for the status of the job and it would lock up really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t immediately obvious why Upstart would be the culprit, I found this (at the time) old bug: https://bugs.launchpad.net/upstart/+bug/406397 Upstart couldn't track the forks going on inside a started process reliably. As one commenter notes: “I’m wondering why this bug has a importance of “low”, as it renders using upstart for many daemons (including apache, postfix and others) as impossible.” This bug doesn't appear to be fixed yet. So unfortunately, I don't think Upstart is ready for handling a server boot with native job files. I had a look at the apache2 packages for Ubuntu raring, and there’s a sysvinit file, but no Upstart job. I'm telling you the whole story here to explain that this isn't just a minor problem for packages shipped with the distribution, it's also a potentially big problem for ISVs. Also on technical merits although more philosophically, with Upstart you're expressing yourself in an event-based DSL rather than writing configuration files. It's pretty generic. But unfortunately, that means it's also not entirely straightforward, and, I believe, easier to get wrong. Scott had some explaining blog posts before he left Canonical that I still find confusing (from the POV of just getting a job file done): http://netsplit.com/2010/12/20/events-are-like-methods/ http://netsplit.com/2010/12/03/event-matching-in-upstart/ Lennart Poettering wrote in his initial blog posts on systemd about why he thought this fundamental model of Upstart wasn't entirely spot on, and while I thought this might have been NIH BS at the time I've later come to the conclusion that he's probably right. Taking as much confusing logic as possible out of the job files does seem like a win. Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130523t110151-...@post.gmane.org
Re: using upstart in Debian [was, Re: Debian systemd survey]
Dmitrijs Ledkovs xnox at debian.org writes: Also on technical merits although more philosophically, with Upstart you're expressing yourself in an event-based DSL rather than writing configuration files. It's pretty generic. But unfortunately, that means it's also not entirely straightforward, and, I believe, easier to get wrong. Scott had some explaining blog posts before he left Canonical that I still find confusing (from the POV of just getting a job file done): http://netsplit.com/2010/12/20/events-are-like-methods/ http://netsplit.com/2010/12/03/event-matching-in-upstart/ Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. I think you misunderstood me. I was not questioning the documentation here, I was questioning some of the fundamental design choices that Scott's blog posts exposed. While the Upstart team has obviously done good work on documentation, I guess fixing mistakes in the architecture after the fact is going to be hard, if it's even on the radar. Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130524t181806-...@post.gmane.org
