Re: [luv-main] ubuntu hang after upgrade natty to oniric
On Oct 27, 2011 7:28 PM, "Jason White" <jason@jasonjgw.net> wrote:
Watch the boot messages, modifying your boot loader's configuration to ensure that they are displayed if this is not the case by default.
With quiet and splash removed, these tell me that local-premount, local-bottom, and init-bottom executed and completed from /scripts directory. Then nothing.
If you have the openvt command then openvt -c 2 bash should work too, and obviously you can substitue any virtual console number for 2 in the above example.
That works. Trouble is everything looks good to me... Apart from the fact nothing is happening. There are some non-kernel processes: init sh -e /proc/self/fd/9 \_ initctl emit startup plymouthd --mode=boot --attach-to-session mountall --daemon The last one seems strange, is this really meant to be a daemon? Seems to be in a select, according to strace. Everything else is either kernel stuff or from console tty2, ie. My debugging console. top says only one process is running, presumably top itself. Any more ideas? Thanks.
Quoting Brian May (brian@microcomaustralia.com.au):
On Oct 27, 2011 7:28 PM, "Jason White" <jason@jasonjgw.net> wrote:
Watch the boot messages, modifying your boot loader's configuration to ensure that they are displayed if this is not the case by default.
With quiet and splash removed, these tell me that local-premount, local-bottom, and init-bottom executed and completed from /scripts directory. Then nothing.
There's a problem with watching boot messages on recent Ubuntu releases: What you expect to be reported, isn't. And that's even when you remove the 'quiet' and 'splash' keywords: http://marc.merlins.org/perso/linux/2010-10.html#Ubuntu-Maverick_-Plymouth-I... Rather odd attitudes seem to be at the root of this. https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/665789 -- Cheers, "Transported to a surreal landscape, a young girl kills the first Rick Moen woman she meets, and then teams up with three complete strangers rick@linuxmafia.com to kill again." -- Rick Polito's That TV Guy column, McQ! (4x80) describing the movie _The Wizard of Oz_
Rick Moen <rick@linuxmafia.com> wrote:
There's a problem with watching boot messages on recent Ubuntu releases: What you expect to be reported, isn't. And that's even when you remove the 'quiet' and 'splash' keywords:
http://marc.merlins.org/perso/linux/2010-10.html#Ubuntu-Maverick_-Plymouth-I...
That article at least mentions an undocumented parameter for the boot loader which should turn this undesirable feature off. Whether that parameter still works is another question entirely, of course.
On 28 October 2011 10:15, Jason White <jason@jasonjgw.net> wrote:
That article at least mentions an undocumented parameter for the boot loader which should turn this undesirable feature off. Whether that parameter still works is another question entirely, of course.
I tried that, it didn't seem to have any affect. It is an old post, suspect it no longer applies to Ubuntu 11.10 -- Brian May <brian@microcomaustralia.com.au>
Quoting Brian May (brian@microcomaustralia.com.au):
I tried that, it didn't seem to have any affect. It is an old post, suspect it no longer applies to Ubuntu 11.10
Notice that when author Marc Merlin[1] filed a bug about several aspects of the problem, the maintainer closed it as 'invalid'. Marc re-opened the bug, as (essentially) the matter had not been addressed at all, and there's been no comment or other activity on the bug since then, about a year ago. [1] FWIW, senior system administrator at Google, Inc. and before that at VA Linux Systems / VA Software / $WHATEVER. (Marc's a friend and occasional co-worker.)
On Thu, 27 Oct 2011, Rick Moen wrote:
Quoting Brian May (brian@microcomaustralia.com.au):
On Oct 27, 2011 7:28 PM, "Jason White" <jason@jasonjgw.net> wrote:
Watch the boot messages, modifying your boot loader's configuration to ensure that they are displayed if this is not the case by default.
With quiet and splash removed, these tell me that local-premount, local-bottom, and init-bottom executed and completed from /scripts directory. Then nothing.
There's a problem with watching boot messages on recent Ubuntu releases: What you expect to be reported, isn't. And that's even when you remove the 'quiet' and 'splash' keywords:
http://marc.merlins.org/perso/linux/2010-10.html#Ubuntu-Maverick_-Plymouth-I...
Rather odd attitudes seem to be at the root of this. https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/665789
I don't get why geeks use Ubuntu. I think the usual argument is "it just works" (somewhat like Apples - I can at least understand that in principle, although it never worked for me, with my brain being wired to focus-follows-mouse-but-not-raise, and with middle click being broken in the opengl X11 apps I was programming, and with package management being useless), but demonstrably, it just doesn't work (so completely unlike, I mean, like Apple then). -- Tim Connors
Quoting Tim Connors (tconnors@rather.puzzling.org):
I don't get why geeks use Ubuntu.
In fact, I told Marc (among other things): 'Debian Test/Unstable remains excellent. Come home. ;-> ' -- Cheers, "Why is the alphabet in that order? Is it because of that song?" Rick Moen -- Steven Wright rick@linuxmafia.com McQ! (4x80)
On Fri, 28 Oct 2011 10:47:06 AM Rick Moen wrote:
In fact, I told Marc (among other things): 'Debian Test/Unstable remains excellent. Come home. ;-> '
I did look at Debian Testing at one point, but it's got old KDE packages though. :-( -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
Quoting Chris Samuel (chris@csamuel.org):
I did look at Debian Testing at one point, but it's got old KDE packages though. :-(
I _did_ say 'Testing/Unstable'. What you do is use package-pinning[1] to make unstable-branch packages (and implicitly requested dependencies) available upon request, e.g., # apt-get -t unstable install kde-core Using package-pinning in /etc/apt/preferences (which you'll probably have to create)... Package: * Pin: release a=unstable Pin-Priority: 50 ...ensures that the -unstable deb lines you add to /etc/apt/sources.list (similar to the -testing ones) are not consulted except when you specifically invoke the otherwise deprecated 'unstable' target. I'm not really a user of KDE or any other 'Desktop Environment', but, FWIW, the unstable=sid packages look like 4.6.5 versions, currently. Is that considered old relative to upstream's 4.7? I honestly wouldn't really know. And, actually, I notice that those 4.6.5 packages have also cleared quarantine into wheezy=testing. [1] Disclaimer: The experts tell me that my usage of pinning to deprecate a target using a pin-priority of 50, where 100 is normal, is bass-ackwards from the normal and expected usage. I can only reply that I arrived at it by expermenting until I found something that works, and then stopping.
On Sat, Oct 29, 2011 at 1:02 PM, Rick Moen <rick@linuxmafia.com> wrote:
I'm not really a user of KDE or any other 'Desktop Environment', but, FWIW, the unstable=sid packages look like 4.6.5 versions, currently. Is that considered old relative to upstream's 4.7? I honestly wouldn't really know.
And, actually, I notice that those 4.6.5 packages have also cleared quarantine into wheezy=testing.
Just noting for comparison I'm currently running KDE 4.7.2 on Ubuntu. If you sat me at a terminal though, I can't say I'd be able to tell the difference between a 4.6.5 install and 4.7.2. Others might. / Brett
Quoting Brett Pemberton (brett.pemberton@gmail.com):
Just noting for comparison I'm currently running KDE 4.7.2 on Ubuntu.
Good to hear. In fact, one of the original reasons for the founding of the Ubuntu Project was timely provision of coherent suites of leading-edge GNOME and KDE packages on (just) i386 and x86_64, without having to wait for Debian's QA to bear fruit on all 13[1] supported CPU platforms and without the sometimes uneven availability of _all_ of KDE or _all_ of GNOME at a certain release level that one has in Debian testing. FWIW, double-checking the Debian packages currently on unstable=sid, I do see some 4.7.1 packages -- along with some 4.7, some 4.6.5, and some 4.4. [1] Number is from memory, and things have changed a bit since then, as two new ports have been introduced as 'technolgy previews' (kfreebsd-i386 and kfreebsd-amd64), some former main platforms such as alpha, m68k, hppa have been relegated to 'unstable ports' so as to not hold up releases any more, and some new 'unstable ports' have been added.
Rick Moen wrote:
Quoting Chris Samuel (chris@csamuel.org):
I did look at Debian Testing at one point, but it's got old KDE packages though. :-(
I _did_ say 'Testing/Unstable'.
What you do is use package-pinning[1] to make unstable-branch packages (and implicitly requested dependencies) available upon request, e.g.,
# apt-get -t unstable install kde-core
Using package-pinning in /etc/apt/preferences (which you'll probably have to create)...
Package: * Pin: release a=unstable Pin-Priority: 50
Where it works, I prefer Default-Release (cf. pinning): $ cat /etc/apt/apt.conf Apt::Default-Release "wheezy"; IME it works for the specific case of testing/unstable, but I don't know if it's the Right Thing. Both approaches also totally failed last time I tried them on Ubuntu, but that was ca. 2007.
On 28 October 2011 10:47, Rick Moen <rick@linuxmafia.com> wrote:
In fact, I told Marc (among other things): 'Debian Test/Unstable remains excellent. Come home. ;-> '
For me the benefit Ubuntu has it that I get daily security updates that rarely break anything (yes I know it does happen) without having to do a daily upgrade to the latest Debian/testing (which ends up taking significant time, especially if you have multiple computers to maintain and/or if things break badly) while at the same time not falling behind as much as Debian/stable. Yes, things can and do do break badly in Ubuntu upgrades, but at least you only need to worry about these once every 6 months, not once every day. Personally the redesigned boot system doesn't bother me, but it would be nice if it was more robust and ways to get better debugging information were better documented. -- Brian May <brian@microcomaustralia.com.au>
Quoting Brian May (brian@microcomaustralia.com.au):
For me the benefit Ubuntu has it that I get daily security updates that rarely break anything (yes I know it does happen) without having to do a daily upgrade to the latest Debian/testing (which ends up taking significant time, especially if you have multiple computers to maintain and/or if things break badly) while at the same time not falling behind as much as Debian/stable.
What you describe resulting from 'doing a daily upgrade to te latest Debian/testing' implies doing something like 'apt-get dist-upgrade', which indeed hogs a lot of time and bandwidth -- especially if you've made the error of doing a kitchen-sink installation -- but is completely unnecessary: The interesting thing about Debian's security updates (as detailed on the debian-security-announce mailing list, http://lists.debian.org/debian-security-announce/) is that, upon examination, you find that 95% are either irrelevant to your installed system for one reason or another (package not installed, threat model applies only to a particular configuration you don't have), or is intended to fix theoretical vulnerabilities so far-fetched that there's no hurry dealing with them. In 2011 so far, there have been 211 postings to that mailing list (whose postings I skim-read). Of those, 42 were package updates that were _potentially_ applicable to my Debian servers, and 42 were _potentially_ applicable to my Debian workstation. However, the actual number of relevant updates has been much smaller than that. Let's consider the 42 workstation packages, and spot/weed out the ones that can be ignored: DSA-2141-2, nss: This addressed the far-fetched TLS man-in-the-middle scenario in January, which I already render irrelevant in other ways. DSA-2142-1, dpkg directory traversal: Far-fetched attack on .deb source-code packages that are in 3.0 quilt format. DSA 2149-1: local DoS against dbus; not much of an attack. Carefully crafted system messages could cause an instance of dbus to segfault, but it'd launch another, so not a big deal. DSA 2151-1 (still January): Set of OO.o bugs whereby malicious RTF documents, XML filters, TGA (Targa) graphics files, MS-Word files could 'potentially execute arbitrary code' as the local user, which means there's no exploit and may never be but you should get around to upgrading on general principle. I didn't bother, but instead just gave OO.o the heave-ho when LibreOffice came out. DSA 2152-1, hplip: irrelevant because I don't use the SNMP discovery code. DSA 2153-1, linux-2.6: Almost entirely bugs in drivers and subsystems I don't use, except some minor information leakage and several local-user DoS bugs, meriting eventually kernel upgrade when convenient but not urgently. DSA 2164-1, shadow: Farfetched, and I don't use NIS. DSA 2176-1, cups: Basically, DoSing the print daemon with malformed files, in which case it segfaults and cupsd forks/execs another copy. DSA 2200-1: iceweasel: Blacklisting several fraudulent SSL certs issued by Comodo, which is nice but I'd already manually removed the Comodo root cert. DSA 2203-1: nss: Same Comodo certs, already dealt with locally. DSA 2213-1: x11-xserver-utils (xrdb utility): So-called remote attack if remote X11 is enabled (who does that?) or there's a 'rogue DHCP server' on the local LAN issuing 'crafted hostnames' that might in some farfetched scenario possibly stack-smash the xrdb utility that might in theory escalate privilege. Farfetched, no hurry. DSA 2217-1, dhcp3: 'Rogue DHCP server' could send DHCP client shell meta-characters that could speculatively maybe some day lead to an explotiable way to execute arbitrary code as the dhclient user. Farfetched, and moreover irrelevant because I have DHCLIENT_SET_HOSTNAME="no". DSA 2240-1, linux-2.6: Various kernel bugs, all of them in drivers and subsystems I don't use, except for one about video support for AGP devices, which is irrelevant because my users aren't in group 'video'. DSA 2264-1, linux-2.6: As above. DSA 2265-1: perl: 'tainted' flag isn't always handled correctly, which is serious but irrelevant because I don't rely on it for anything. DSA 2267-1, perl: Perl's 'safe' module can sometimes be bypassed, which is serious but irrelevant because I don't rely on it for anything. DSA 2275-1, OO.o: Import filter for Lotus Word Pro is subject to theoretical, speculative attack as the local user, but this is irrelevant because I don't use Lotus Word Pro files. DSA-2287-1, libpng. Several bugs, the most serious of which can be used to make libpng grab lots of RAM, maybe fall over, and very speculatively maybe some day accomplish more mischief. Not urgent. DSA 2292-1, dhcp3. DoS: Remote attacker can make your DHCP client program fall over. Bummer. Annoying, but hardly a security emergency. DSA 2299-1, ca-certificates: Blacklisting Diginotar for incompetence as a CA. Irrelevant for the same reasons as the Comodo issues. DSA 2200-1, nss: Same. DSA 2300-2, nss: Diginotar round 2. See above. DSA 2303-1, linux-2.6: Mostly drivers and subsystems I don't use, except two that are minor information leakage (to fix when convenient, not an emergency) and a fascinating bug in TCP sequence number randomisation that merits a kernel upgrade (again) when convenient but not an emergency. (If your secret network transactions are accessible merely by guessing packet sequence numbers, you aren't doing security right.) DSA 2303-2, linux-2.6: Fixes a nasty bug introduced by the prior fix. (See? This is one reason to not be in a hurry except when haste is actually needed.) DSA 2310-1, linux-2.6: Again, almost entirely drivers and subsystems I don't use, excepting a couple of minor information leakage bugs. Merits kernel upgrade when convenient, not an emergency. DSA 2310-1, OO.o: Bugs in the MS-Word importer, which can cause OO.o Writer to fall over but so far probably not much else. Taking out the above 26 irrelevant or not-very-important updates, what does that leave? One fairly serious glibc update, one fairly serious PAM update, five updates each of iceweasel (Firefox) and icedove (Thunderbird), and four updates to freetype: 16 package updates, plus in some cases dependencies. So, _not_ 211 for the current year, but rather _16_. Plus a kernel upgrade or two whenever convenient. Also, because of my usage scenarios for Iceweasel and Icedove (well-tuned NoScript and RequestPolicy for Firefox, simple HTML display in Thunderbird), I actually ignore most upgrades with perfect safety because I've addressed threat vectors at other levels. Anyway, I hope you'll notice, _very_ few package upgrade result, if you bother to read the DSAs and fix only what's worth fixing -- and if you haven't installed the kitchen sink. By the way, if you have numerous Debian machines needing package updates, you do _not_ have them all fetch those in parallel. What you do is have each host's apt subsystem use a shared local Squid cache you establish for that purpose. That way, duplicate downloads are eliminated automatically.
Yes, things can and do do break badly in Ubuntu upgrades, but at least you only need to worry about these once every 6 months, not once every day.
As you see, you were misinformed. One just subscribes to the DSAs (very low traffic announce-only mailing list), skim-reads the occasional postings, ignores 95% as irrelevant, and acts on the remaining dozen-plus packages per year.
On 29.10.11 22:44, Rick Moen wrote:
What you describe resulting from 'doing a daily upgrade to te latest Debian/testing' implies doing something like 'apt-get dist-upgrade',
Apropos upgrading for security, does anyone know whether letting that GUI "Update Manager" run will upset apt's view of the installed package base? (It seems rash to assume that they're necessarily compatible, after all, Network Manager stuffs up a variety of things.) Up to now, I've operated in paranoid mode, and used apt-get on packages listed under the Update Manager's "Important Security Updates" heading. (OK, yeah, mostly paranoid about unhelpful GUI app behaviour. Tardy package updating hasn't observably bitten me yet.) Just letting Update Manager rip would still involve deselecting several hundred non-security packages, each with a mouse-click, I see now. So an apt-get command option selecting only security updates would be the way to go, I figure. ...
By the way, if you have numerous Debian machines needing package updates, you do _not_ have them all fetch those in parallel. What you do is have each host's apt subsystem use a shared local Squid cache you establish for that purpose. That way, duplicate downloads are eliminated automatically.
That does sound easier than doing an "apt-get --download-only", sharing the archive via NFS (or sneakernet), and doing a "dpkg -i", but we often just end up doing what we remember how to do. Erik -- Habit is habit, and not to be flung out of the window by any man, but coaxed down-stairs a step at a time. - Mark Twain, "Pudd'nhead Wilson's Calendar
Quoting Erik Christiansen (dvalin@internode.on.net):
Apropos upgrading for security, does anyone know whether letting that GUI "Update Manager" run will upset apt's view of the installed package base? (It seems rash to assume that they're necessarily compatible, after all, Network Manager stuffs up a variety of things.)
/usr/bin/update-manager (Python utility with dependencies on dconf-gsettings-backend, gir bindings for gtk+3 / VTE, python-dbus, python-gobject, Python gtk+3 aptdaemon widgets) is in fact a front-end for apt, same as synaptic, kpackage, and all the rest (http://en.wikipedia.org/wiki/Advanced_Packaging_Tool#Front-ends). So, no. You can switch back and forth between one of the graphical front-ends such as update-manager and apt-get, without causing problems.
Up to now, I've operated in paranoid mode, and used apt-get on packages listed under the Update Manager's "Important Security Updates" heading.
Sounds reasonable to me. To elaborate on what I was saying about skim-reading DSAs, if I read one that suggested a pretty urgent security update to glibc (package libc6), I would open an xterm and do: su - apt-get update && apt-get install libc6 ctrl-D
That does sound easier than doing an "apt-get --download-only", sharing the archive via NFS (or sneakernet), and doing a "dpkg -i", but we often just end up doing what we remember how to do.
Those are worthy of respect, too, though. For extra win (if you don't mind the bandwidth usage, you could put this in a nightly cronjob: apt-get update && \ apt-get -y --download-only dist-upgrade && \ apt-get autoclean That way, when you wake up, all the available updates for your installed packages are already available locally in /var/cache/apt/archives/ , with no download delays.
On 30/10/2011, Erik Christiansen <dvalin@internode.on.net> wrote:
Just letting Update Manager rip would still involve deselecting several hundred non-security packages, each with a mouse-click, I see now.
If you are lucky :-) on that window the secondary mouse button might bring up a context menu offering "deselect all". I don't use it myself but vaguely recall this from a Fedora list discussion long ago. A small concession to the cautious old school from the "newer is better, just use your unlimited bandwidth to update everything, otherwise click everywhere because you never know where we might hide a menu" devs.
Hello, Erik Christiansen:
That does sound easier than doing an "apt-get --download-only", sharing the archive via NFS (or sneakernet), and doing a "dpkg -i", but we often just end up doing what we remember how to do.
Instead of doing a "dpkg -i", just copy the downloaded .deb files into /var/cache/apt/archives/ on the other machines, then use apt-get as normal. That way you still only download once (other than the index files), but you get all the smarts of apt-get, eg if one of the machines is not quite like the others it'll still do the right thing. That's assuming hard disk space is not a problem, but that's often the case. Jiri -- Jiri Baum <jiri@baum.com.au> http://www.baum.com.au/sabik
Quoting Jiri Baum (jiri@baum.com.au):
Instead of doing a "dpkg -i", just copy the downloaded .deb files into /var/cache/apt/archives/ on the other machines, then use apt-get as normal. That way you still only download once (other than the index files), but you get all the smarts of apt-get, eg if one of the machines is not quite like the others it'll still do the right thing.
Yeah, I was thinking that a nightly rsync cronjob on /var/cache/apt/archives/ was just the thing. -- Cheers, "kill -9 them all. Rick Moen Let init sort it out." rick@linuxmafia.com -- Joe Bednorz <bednorz@mail.net-connect.net> McQ! (4x80)
Quoting "Tim Connors" <tconnors@rather.puzzling.org>:
I don't get why geeks use Ubuntu. I think the usual argument is "it just works" .. but demonstrably, it just doesn't work
It worked for a while. The Unix desktop universe follows Douglas Adams: "There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened." As soon as there was one graphical environment working, it was replaced by something "brand new". Linux-specific, a lot of that trickled back into the Linux kernel and "close relatives", as udev, the DBus to HAL 9000, the DeviceKit and the PoliceKit and whatever in-between. And that's all just to catch three events a day to plug/unplug a USB stick or to speed up a boot process. Regards Peter
On Fri, 28 Oct 2011, Peter Ross wrote:
Quoting "Tim Connors" <tconnors@rather.puzzling.org>:
I don't get why geeks use Ubuntu. I think the usual argument is "it just works" .. but demonstrably, it just doesn't work ... Linux-specific, a lot of that trickled back into the Linux kernel and "close relatives", as udev, the DBus to HAL 9000, the DeviceKit and the PoliceKit and whatever in-between.
I should have suspected that all of the evil in the world came from Ubuntu. -- Tim Connors
Rick Moen wrote:
Quoting Tim Connors (tconnors@rather.puzzling.org):
I should have suspected that all of the evil in the world came from Ubuntu.
Well, except for Celine Dion, anyway.
Canonical support does come out of .ca...
I started using Ubuntu in 2005...Hoary I think.... and disliked Kubuntu. I've preferred Gnome up til 11.04. I'm not a developer or coder... just a user. I just disliked MS and wanted to rebel.hoices were limited Ubuntu, I just liked. I've tried Arch Linux and Debian, had a dip at Sabayon, Mandriva/Mandrake, kept coming back to Ubuntu...now Kubuntu! I don't like Unity. Haven't tried Gnome 3, but understand it's similar to Unity, so I tried Kubuntu and surprised myself by liking it.
From what I've read, Ubuntu/Canonical could have gone with Gnome3 or their own Unity desktop so saying that they went from something that worked and changed to a brand new UI is a little disingenuous. They had little choice. I don't like Unity, but the choices were limited.
All said, I upgraded to 11.10 Kubuntu about 2 days after release and I still like it. Michael On Fri, Oct 28, 2011 at 6:16 PM, Trent W. Buck <trentbuck@gmail.com> wrote:
Rick Moen wrote:
Quoting Tim Connors (tconnors@rather.puzzling.org):
I should have suspected that all of the evil in the world came from Ubuntu.
Well, except for Celine Dion, anyway.
Canonical support does come out of .ca... _______________________________________________ luv-main mailing list luv-main@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Fri, Oct 28, 2011 at 10:55:49AM +1100, Peter Ross wrote:
As soon as there was one graphical environment working, it was replaced by something "brand new".
that's because rewriting from scratch every two or three years is far cooler and more exciting than doing something boring like adding incremental improvements, fixing bugs, or writing documentation. it's what Jamie Zawinski calls The CADT Model http://www.jwz.org/doc/cadt.html IMO it's a pretty accurate observation. craig -- craig sanders <cas@taz.net.au> BOFH excuse #130: new management
Craig Sanders <cas@taz.net.au> wrote:
it's what Jamie Zawinski calls The CADT Model http://www.jwz.org/doc/cadt.html
IMO it's a pretty accurate observation.
I don't like it. I haven't noticed it much, though, for software projects in which the developers use the software heavily. I don't think the free/open-source community is so good at writing software for other people to use (i.e., people who aren't like the authors of the program in important respects). That's fine, since I prefer software which is written by people who are actually users of that class of tool.
Tim Connors wrote:
I don't get why geeks use Ubuntu. I think the usual argument is "it just works" (somewhat like Apples - I can at least understand that in principle, although it never worked for me, with my brain being wired to focus-follows-mouse-but-not-raise, and with middle click being broken in the opengl X11 apps I was programming, and with package management being useless), but demonstrably, it just doesn't work (so completely unlike, I mean, like Apple then).
AFAICT what happens is, Canonical takes Debian and breaks bits, and is then praised by people who haven't used Debian at all / for years because the unmodified Debian bits "just work". A textbook example was back before ubiquity replaced d-i, people would come up to me and say "wow, ubuntu's installer is amazing, it only asked me a couple of questions, much easier than Debian", and you would point them at the contemporary Debian installer which looked EXACTLY THE SAME and asked THE SAME QUESTIONS. Having said that, LWN had (or linked to?) an analysis on security defaults in GCC et al, and Debian was a long way behind Ubuntu, so kudos to Kees Cook et al there. (Yama notwithstanding.)
Quoting Trent W. Buck (trentbuck@gmail.com):
Having said that, LWN had (or linked to?) an analysis on security defaults in GCC et al, and Debian was a long way behind Ubuntu, so kudos to Kees Cook et al there. (Yama notwithstanding.)
Kees Cook does some amazing work. He has a really good page about his and other maintainers' heroic accomplishments with AppArmour and other security improvements. https://wiki.ubuntu.com/Security/Features
On 28/10/11 10:45, Tim Connors wrote:
I don't get why geeks use Ubuntu.
They package the latest KDE releases quicker than anyone. But I guess then I use Kubuntu, not Ubuntu. :-) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Quoting "Chris Samuel" <chris@csamuel.org>:
On 28/10/11 10:45, Tim Connors wrote:
I don't get why geeks use Ubuntu.
They package the latest KDE releases quicker than anyone.
Is that the reason for 200GB .xsession-errors? ;-) Cheers Peter
On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
They package the latest KDE releases quicker than anyone.
Is that the reason for 200GB .xsession-errors? ;-)
Maybe it would be good to have something like plymouth take over the .xsession-errors. Send that data to a pipe which is read by a program that displays the last few megs of data instead of all of it. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting "Russell Coker" <russell@coker.com.au>:
On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
They package the latest KDE releases quicker than anyone.
Is that the reason for 200GB .xsession-errors? ;-)
Maybe it would be good to have something like plymouth take over the .xsession-errors. Send that data to a pipe which is read by a program that displays the last few megs of data instead of all of it.
Good old syslog maybe? "Message repeated x times" is already built-in. Regards Peter
On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
Maybe it would be good to have something like plymouth take over the .xsession-errors. Send that data to a pipe which is read by a program that displays the last few megs of data instead of all of it.
Good old syslog maybe? "Message repeated x times" is already built-in.
That doesn't work for the situation where you have a set of three or more messages repeated or for the situation where you have 1000 variants of the same message (EG the same message repeated for each file in a directory or each memory address of an object that wasn't liked). On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
I just wanted to start working - and deleted it. It did not happen since.
That's a bad idea. When an open file is deleted there is no way (*) to reclaim the disk space except killing every process that has a handle for it - which means logging out at a minimum. "echo -n > file" is the correct thing to do in such situations. (*) Well you could attach a debugger to a process which has an open file handle and make it call ftruncate(2). But for a typical user that's impossible. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting "Russell Coker" <russell@coker.com.au>:
On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
Maybe it would be good to have something like plymouth take over the .xsession-errors. Send that data to a pipe which is read by a program that displays the last few megs of data instead of all of it.
Good old syslog maybe? "Message repeated x times" is already built-in.
That doesn't work for the situation where you have a set of three or more messages repeated or for the situation where you have 1000 variants of the same message (EG the same message repeated for each file in a directory or each memory address of an object that wasn't liked).
Well, you can filter for severity, drop and it only fills up /var/log. I have the habit to give /var/log an extra partition. To the delete - I did a reboot anyway. A modern desktop isn't predictable after a dozen background processes were running into difficulties. Cheers Peter
Peter Ross wrote:
Quoting "Russell Coker" <russell@coker.com.au>:
On Fri, 28 Oct 2011, "Peter Ross" <Peter.Ross@bogen.in-berlin.de> wrote:
They package the latest KDE releases quicker than anyone.
Is that the reason for 200GB .xsession-errors? ;-)
Maybe it would be good to have something like plymouth take over the .xsession-errors. Send that data to a pipe which is read by a program that displays the last few megs of data instead of all of it.
Good old syslog maybe? "Message repeated x times" is already built-in.
FYI, in rsyslog, # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # #$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # Filter duplicated messages $RepeatedMsgReduction off Since I use logcheck w/syslog-summary, which does a better job of it anyway.
On 28/10/11 12:16, Peter Ross wrote:
Quoting "Chris Samuel" <chris@csamuel.org>:
They package the latest KDE releases quicker than anyone.
Is that the reason for 200GB .xsession-errors? ;-)
I don't know, have you added that PPA ? I don't think storing errors in .xsession-errors was invented by *buntu either, I'm pretty sure Mandrake was doing that years ago, and I"m pretty sure Arch Linux does it too. So if anyone is to blame then it's KDE for producing software that creates that many errors - what were they from ? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Quoting "Chris Samuel" <chris@csamuel.org>:
So if anyone is to blame then it's KDE for producing software that creates that many errors - what were they from ?
Valid question. A graphical system with a filled root disk isn't that responsive - and I also don't know how much of it was caused by the full disk. I just wanted to start working - and deleted it. It did not happen since. Regards Peter
On 28 October 2011 14:34, Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote:
A graphical system with a filled root disk isn't that responsive - and I also don't know how much of it was caused by the full disk.
Probably full of "out of disk space errors" :-) I have seen mythtv do just this - when the video partition was full it filled the root partition up with error messages :-(. -- Brian May <brian@microcomaustralia.com.au>
Tim Connors <tconnors@rather.puzzling.org> wrote:
I don't get why geeks use Ubuntu. I think the usual argument is "it just works" (somewhat like Apples - I can at least understand that in principle, although it never worked for me, with my brain being wired to focus-follows-mouse-but-not-raise, and with middle click being broken in the opengl X11 apps I was programming, and with package management being useless), but demonstrably, it just doesn't work (so completely unlike, I mean, like Apple then).
Linux mostly "just works" for me, with one major exception - anything related to X desktop accessibility, where the number of bugs is high relative to everything else that I use. In general, though, if I weren't involved in the community and actively testing and exploring new tools, I could, for the most part, just configure everything as I want it and leave it alone to "just work". Procmail is a good example, I only touch it when I want to add a mailing list or improve the spam filtering. It's still basically the same configuration that I set up in 1994 or 1995 under SunOS. What's even better these days is that, under distributions such as Debian, many packages have reasonable default configurations, and hardware detection by the kernel and by the X Window System is much better than it used to be, reducing still further the required configuration work.
On 28.10.11 10:45, Tim Connors wrote:
I don't get why geeks use Ubuntu.
Well, this one found that Debian wouldn't install on hardware he'd just paid good money for, nearly a decade ago. Ubuntu was the closest which worked OOTB. And to be fair, it has for the most part worked well enough, at least after various gremlins have been whacked on the head after each upgrade. (Not pointing the finger _only_ at NetworkManager, here.)
I think the usual argument is "it just works" (somewhat like Apples - I can at least understand that in principle, although it never worked for me, with my brain being wired to focus-follows-mouse-but-not-raise, and with middle click being broken in the opengl X11 apps I was programming,
One of the first things I tweaked after the first Ubuntu install was focus-follows-mouse-but-not-raise. If you don't mind using the GUI (just once), then System->Preferences->Windows presents that option. Dunno how middle click needs to work for you, but on my 3-button mouse, Left selects, Middle pastes, and ^Right pops up the "VT Fonts" dialogue. For pasting into Vim, middle click is _essential_ for me.
and with package management being useless), but demonstrably, it just doesn't work (so completely unlike, I mean, like Apple then).
I've installed a couple of dozen packages, including a couple of toolchains, without anything but flawlessness. (That I can recall) It has worked so well that my long-term habit of building cross-compiler toolchains and various favourite apps has fallen into disuse. It's NetworkMunger, the "DO NOT EDIT" crap in config files, and the other user-alienating M$-style arrogance which will cause me to flip back to Debian. (I like to upgrade every 3-4 years, if it seems warranted, but Ubuntu may offend fatally before then.) Erik -- Debian is for people who can read man pages. Robert Moonen (on luv-main ML)
On Fri, 28 Oct 2011, Erik Christiansen wrote:
On 28.10.11 10:45, Tim Connors wrote:
I think the usual argument is "it just works" (somewhat like Apples - I can at least understand that in principle, although it never worked for me, with my brain being wired to focus-follows-mouse-but-not-raise, and with middle click being broken in the opengl X11 apps I was programming,
One of the first things I tweaked after the first Ubuntu install was focus-follows-mouse-but-not-raise. If you don't mind using the GUI (just once), then System->Preferences->Windows presents that option.
Dunno how middle click needs to work for you, but on my 3-button mouse, Left selects, Middle pastes, and ^Right pops up the "VT Fonts" dialogue. For pasting into Vim, middle click is _essential_ for me.
OSX sorry (and the X11 therein, at least several years ago. Maybe it and fink have improved since). The OSX gui model is fundamentally not compatibile[1] with focus-follows-mouse-but-not-raise, as the menu bar is in that stupid position off to the top of the left-hand monitor. I note also that OSX doesn't work at all well with multiple monitors. [1] http://steve-yegge.blogspot.com/2008/04/settling-osx-focus-follows-mouse-deb... BLONK! BLONK! BLONK!
and with package management being useless), but demonstrably, it just doesn't work (so completely unlike, I mean, like Apple then).
I've installed a couple of dozen packages, including a couple of toolchains, without anything but flawlessness. (That I can recall) It has worked so well that my long-term habit of building cross-compiler toolchains and various favourite apps has fallen into disuse.
Its repository when I last looked at it was smaller than redhat enterprise and had bugger all in it. Not so good for someone used to debian. Also, at that time, you had to build from source. Ie, it was a poor man's version of gentoo. Er sorry, I'm talking about OSX here, I just realised you might be talking about Ubuntu. That'll teach me for having the hightail ale. And or talking about Apple in the first set of bracketted text.
It's NetworkMunger, the "DO NOT EDIT" crap in config files, and the other user-alienating M$-style arrogance which will cause me to flip back to Debian. (I like to upgrade every 3-4 years, if it seems warranted, but Ubuntu may offend fatally before then.)
Heh. My next install might just be debian+kFreeBSD+zfs because I'm getting so sick of Linux. But I'm not due to buy new computers for another 3 years, unless the now-3 year old computers crap out before then. Come on, crap out before then, dammit. No wait, the hardware is getting worse too. -- Tim Connors
Quoting Erik Christiansen (dvalin@internode.on.net):
Well, this one found that Debian wouldn't install on hardware he'd just paid good money for, nearly a decade ago.
This was often the case _if_ you were unaware of the many extremely good third-party installer images. At any given time, there are a huge number of these, and there were (e.g.) a number of live-CD Debian installers long before the Debian Live Project (live.debian.net) existed. I even got so tired of hearing how _the_ Debian installer image was insufficient that I made a Web page to point people to (and of course, it is now a bit out of date): http://linuxmafia.com/faq/Debian/installers.html My own current favourite way to install Debian is Aptosid (formerly Sidux). Live CD with installer, comes out every quarter.
On 28.10.11 19:11, Rick Moen wrote:
Quoting Erik Christiansen (dvalin@internode.on.net):
Well, this one found that Debian wouldn't install on hardware he'd just paid good money for, nearly a decade ago.
This was often the case _if_ you were unaware of the many extremely good third-party installer images. At any given time, there are a huge number of these, and there were (e.g.) a number of live-CD Debian installers long before the Debian Live Project (live.debian.net) existed.
I was unaware then, and throughout the intervening decade, until I read your post today. One Live CD, and one Install CD, were all that I bumped into. (For some, the focus is on using, not futzing. [1] If the chicken wings aren't in the bain-marie, then they aren't sold.)
I even got so tired of hearing how _the_ Debian installer image was insufficient that I made a Web page to point people to (and of course, it is now a bit out of date):
I can see why it'd be a bit dated. It can't be easy to find the time to review the current status of them all, for an update. You've prompted me to visit debian.org, even though I won't migrate today. After even a ubuntu upgrade there's a week of bumping into missing packages, because one discipline I haven't developed is making a list of what I install. (A before, and after, "dpkg --get-selections" might be a way round that, perhaps.)
My own current favourite way to install Debian is Aptosid (formerly Sidux). Live CD with installer, comes out every quarter.
A quick glance at their site left me with the impression that it is KDE oriented. (kI kan't kstand kKDE, kespecially kthe kommand knames. :-) The Debian Live CD, with Gnome, ..., Xfce sampler is more appealing. I've never had an insoluble problem with Gnome, but the talk of Xfce on this list is almost enough to make me curious. I suppose the signing of the ISOs manages the risk of downloading from BitTorrent. Erik [1] I don't futz with linker scripts, Vim features, and shell scripts; the increase in functionality makes it productivity improvement. -- Unlike plagues of the dark ages or contemporary diseases (which) we do not yet understand, the modern plague of overpopulation is soluble by means we have discovered and with resources we possess. What is lacking is not sufficient knowledge of the solution, but universal consciousness of the gravity of the problem and the education of the billions who are it victims. - Dr. Martin Luther King Jnr.
Quoting Erik Christiansen (dvalin@internode.on.net):
I was unaware then, and throughout the intervening decade, until I read your post today. One Live CD, and one Install CD, were all that I bumped into. (For some, the focus is on using, not futzing. [1] If the chicken wings aren't in the bain-marie, then they aren't sold.)
One becomes a bit motivated to research alternatives upon being handed a new system whose mass-storage HBA isn't supported by the regular installer image. ;-> You'll notice that a number of the third-party images for Debian were evidently prompted by such hardware issues: All it took was for someone to say 'I think I know how this is installer gets built. Let's remaster it with a better kernel and an updated initrd.' [Aptosid installer:]
A quick glance at their site left me with the impression that it is KDE oriented. (kI kan't kstand kKDE, kespecially kthe kommand knames. :-)
Actually, the KDE image is one of _two_ Aptosid editions, the other being Xfce4. (Both images also include the Fluxbox window manager.) When I most recently rebuilt my workstation, I had no interest in either KDE or Xfce, so I installed the Xfce edition of Aptoid and then did: # mv /etc/alternatives/x-session-manager /usr/local/ # apt-get install wmaker I believe that the latter action set Window Maker automatically as the default window manager, but you can always do # update-alternatives --config x-window-manager to check and verify. I can't remember whether I even bothered removing the Xfce packages, or if I just ignored them. There was a bit more to it, e.g., I had to work around the fact that the accursed motherboard used a Broadcom 57xx 'Tigon 3' ethernet chipset requiring a non-free firmware image not included in Aptosid's (or Debian's) installers. Full account is here: http://linuxmafia.com/pipermail/conspire/2011-May/006209.html
Rick Moen wrote:
My own current favourite way to install Debian is Aptosid (formerly Sidux). Live CD with installer, comes out every quarter.
IMO if its package archive master isn't hosted on <foo>.debian.org, it isn't "real" Debian; stuff like aptosid and grml are just as much Debian *derivatives* as Ubuntu (cf. "pure blends") -- they just happen to be less divergent (at least, for now). Whether they're in some way *better* is, of course, a separate issue. (As for me, I usually use syslinux to load the d-i netboot installer via PXE or USB, and then pull everything else (including the udebs) from the local deb mirror over HTTP. Who even HAS an optical drive anymore? Fing o' der parst!)
Quoting Trent W. Buck (trentbuck@gmail.com):
IMO if its package archive master isn't hosted on <foo>.debian.org, it isn't "real" Debian; stuff like aptosid and grml are just as much Debian *derivatives* as Ubuntu (cf. "pure blends") -- they just happen to be less divergent (at least, for now).
Aptosid's primary policy and reason for existence is compatibility with Debian-unstable. The Aptosid repo is an add-on to provide stabilisation packages only, to the best of my understanding: Your system consults the Debian-sid repo for almost everything, the add-on Aptosid repo furnshing only bugfixes for sid packages. All contents of the Aptosid repo (and installer images) must comply with Debian Policy and the Debian Social Contract. Moreover, if you decide after using that Aptosid installer that you don't care to receive Aptosid's bug-fix packages, all you need to do is disable those lines in /etc/apt/sources.list, and your system will converge onto pure Debian sid thereafter. Compare: Ubuntu's repo isn't even _binary-compatible_ with any Debian repo. They've specifically disclaimed since 2005 ever having intended any such compatibility, in fact: http://tectonic.co.za/?p=657 Adding Ubuntu repo lines to a Debian system's /etc/apt/sources.list[.d/*] or vice-versa will _break_ that system. Ubuntu has no commitment to Debian Policy or the Debian Social Contract. You see the two cases as 'just as much' derivatives and merely 'happen to be less divergent (at least for now)'? OK, good luck with that.
(As for me, I usually use syslinux to load the d-i netboot installer via PXE or USB, and then pull everything else (including the udebs) from the local deb mirror over HTTP. Who even HAS an optical drive anymore? Fing o' der parst!)
Indeed, what's an ISO for other than loop-mounting it on one's Web or NFS server? Oh, you forgot that using an ISO doesn't require an optical drive, didn't you? ;->
Rick Moen wrote:
Quoting Trent W. Buck (trentbuck@gmail.com):
IMO if its package archive master isn't hosted on <foo>.debian.org, it isn't "real" Debian; stuff like aptosid and grml are just as much Debian *derivatives* as Ubuntu (cf. "pure blends") -- they just happen to be less divergent (at least, for now).
Aptosid's primary policy and reason for existence is compatibility with Debian-unstable. The Aptosid repo is an add-on to provide stabilisation packages only, to the best of my understanding: Your system consults the Debian-sid repo for almost everything, the add-on Aptosid repo furnshing only bugfixes for sid packages. All contents of the Aptosid repo (and installer images) must comply with Debian Policy and the Debian Social Contract.
OK, clearly I was misinformed.
(As for me, I usually use syslinux to load the d-i netboot installer via PXE or USB, and then pull everything else (including the udebs) from the local deb mirror over HTTP. Who even HAS an optical drive anymore? Fing o' der parst!)
Indeed, what's an ISO for other than loop-mounting it on one's Web or NFS server? Oh, you forgot that using an ISO doesn't require an optical drive, didn't you? ;->
Well, sans optical media, there are better choices than ISO. rsync -r and squashfs spring to mind. But I take your point. And of course there is isohybrid in syslinux 4...
On Thu, Oct 27, 2011 at 03:40:09PM -0700, Rick Moen wrote:
http://marc.merlins.org/perso/linux/2010-10.html#Ubuntu-Maverick_-Plymouth-I...
Rather odd attitudes seem to be at the root of this. https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/665789
WTF is wrong with ubuntu and gnome and kde devs? have they all been infected by microsoft or apple? or are they all just stupid? don't they get that a half-arsed imitation of MS and Apple crap ISN'T going to attract MS or Apple users to linux, it's just going to piss off existing linux users? what is so difficult to understand about the fact that linux desktops aren't (or weren't until recently) user-hating patronising crap is one of the reasons linux users actually use linux. and seeing "See 'man 7 undocumented' for help when manual pages are not available." for every new and amazing piece of crap is really pissing me off. they want to fuck with the way unix systems boot and work and couldn't even be bothered writing the documentation so i, and other victims of their meddling, can figure out WTF they have done? FTFAJ. craig -- craig sanders <cas@taz.net.au> BOFH excuse #307: emissions from GSM-phones
Quoting "Brian May" <brian@microcomaustralia.com.au>:
That works. Trouble is everything looks good to me... Apart from the fact nothing is happening.
There are some non-kernel processes:
init sh -e /proc/self/fd/9 \_ initctl emit startup plymouthd --mode=boot --attach-to-session mountall --daemon
The last one seems strange, is this really meant to be a daemon? Seems to be in a select, according to strace.
The manpage is a stub, it does not explain the options. It states: "This is a temporary tool until init(8) itself gains the necessary flexibility to perform this processing; you should not rely on its behaviour. BUGS Report bugs at <https://launchpad.net/ubuntu/+source/mountall/+bugs>" Maybe worth going through the list. I wonder whether you caught one of the bugs. There are some "xxx causes boot to hang". Maybe due to rudimentary error handling? Regards Peter
On 28 October 2011 09:44, Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote:
There are some "xxx causes boot to hang". Maybe due to rudimentary error handling?
I just noticed mountall --help provides help information. Me things all my problems were caused by this entry in /etc/fstab: cgroup /var/cgroup cgroup defaults 0 0 Previously this was required to get cgroup stuff to work in Ubuntu. However now it seems that mountall wants to do this itself, and it gets upset if the filesystem is already mounted. Later: Typical. Was working through the Ubuntu bugs, but this one was listed last. https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/874989 -- Brian May <brian@microcomaustralia.com.au>
Brian May wrote:
On 28 October 2011 09:44, Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote:
There are some "xxx causes boot to hang". Maybe due to rudimentary error handling?
I just noticed mountall --help provides help information.
Me things all my problems were caused by this entry in /etc/fstab:
cgroup /var/cgroup cgroup defaults 0 0
Previously this was required to get cgroup stuff to work in Ubuntu. However now it seems that mountall wants to do this itself, and it gets upset if the filesystem is already mounted.
I expect that's coming from mountall's personal, non-conffile /lib/init/fstab :-/
participants (14)
-
Brett Pemberton -
Brian May -
Chris Samuel -
Craig Sanders -
David -
Erik Christiansen -
Jason White -
Jiri Baum -
Michael Scott -
Peter Ross -
Rick Moen -
Russell Coker -
Tim Connors -
Trent W. Buck