I’ve been keeping a close eye on your posts lately and felt I had to say something, just so you know that it’s not like no one cares, like these morbid thoughts you have fall completely unto deaf ears. There’s little I (or anyone, as you said yourself) can do about them as long as no lives are directly at risk, but what’s always kept me from going forward with such ideas is I imagine it’d feed horribly anticlimactic once you cross that line. Nothing, especially the internal craving won’t have changed, you’ll see that the wheel of the world still keeps on whirling. It’ll just now go on without you (once the karma of your actions hits you), and no matter how much damage you do, you are still bound for oblivion just like everyone else.
Is there anything you include in these thoughts about what you’d want it to look like, how you’d want people to react, a message of some kind? Is it the ”I’m smarter than you” or is that just a bonus?
My Xorg log is flooded with lines about reusing xkmfile:
jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | tail
[ 99.477] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.480] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.484] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.487] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.491] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.494] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.498] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.502] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.505] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
[ 99.509] (II) XKB: reuse xkmfile /var/lib/xkb/server-5CBD5B10CEC815928ACEFB86BAB14051BA0C83FF.xkm
jani@saegusa:~$ grep ”XKB: reuse xkmfile /var/lib/xkb/server-” /var/log/Xorg.0.log | wc -l
1507
Is this normal, caused by something in local configuration, or should I file a bug?
I’ve just had a GPU lockup with 3.3.0-030300rc4-generic. Would this be yet another issue (i.e. not this bug nor bug #938894)? If so, where (if anywhere) should I file it? I’m pasting below here what was in syslog about it.
Feb 26 19:53:38 saegusa kernel: [ 8031.040107] radeon 0000:01:05.0: GPU lockup CP stall for more than 419884msec
Feb 26 19:53:38 saegusa kernel: [ 8031.040113] GPU lockup (waiting for 0x00103023 last fence id 0x00103022)
Feb 26 19:53:38 saegusa kernel: [ 8031.040125] [drm] Disabling audio support
Feb 26 19:53:38 saegusa kernel: [ 8031.041548] radeon 0000:01:05.0: GPU softreset
Feb 26 19:53:38 saegusa kernel: [ 8031.041550] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030
Feb 26 19:53:38 saegusa kernel: [ 8031.041551] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003
Feb 26 19:53:38 saegusa kernel: [ 8031.041553] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20000040
Feb 26 19:53:38 saegusa kernel: [ 8031.041559] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
Feb 26 19:53:38 saegusa kernel: [ 8031.056444] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00000001
Feb 26 19:53:38 saegusa kernel: [ 8031.072335] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030
Feb 26 19:53:38 saegusa kernel: [ 8031.072337] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003
Feb 26 19:53:38 saegusa kernel: [ 8031.072339] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20008040
Feb 26 19:53:38 saegusa kernel: [ 8031.073333] radeon 0000:01:05.0: GPU reset succeed
Feb 26 19:53:38 saegusa kernel: [ 8031.094096] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
Feb 26 19:53:38 saegusa kernel: [ 8031.094153] radeon 0000:01:05.0: WB enabled
Feb 26 19:53:38 saegusa kernel: [ 8031.094156] [drm] fence driver on ring 0 use gpu addr 0xa0000c00 and cpu addr 0xffff88020f609c00
Feb 26 19:53:38 saegusa kernel: [ 8031.127631] [drm] ring test on 0 succeeded in 1 usecs
Feb 26 19:53:38 saegusa kernel: [ 8031.127656] [drm] ib test on ring 0 succeeded in 1 usecs
Feb 26 19:53:38 saegusa kernel: [ 8031.127659] [drm] Enabling audio support
(For the ”launcher getting stuck despite autohide being set” part, see bug #940590.)
I can confirm this is an issue, though I can’t reproduce it with Nicholas’ recipe. Not sure what double-clicking should do, here it works just as single-clicking does (bringing the group of windows to front in the order I left them). Thus I have no recipe to reproduce the issue, here it seems to happen seemingly at random. It is quite frequent though, happens multiple times a day and after it’s triggered nothing short of killall unity-2d-shell fixes it.
I believe this started with the recentmost big Unity updates, 5.4 I think. It wasn’t present in prior versions.
Confirming the issue of not being able to get rid of indicator-messages apart from uninstalling it system-wide, but not agreeing with stuffing the menu with another item just for solving this. IMHO Indicator-messages should be de-/selectable in Startup Applications preferences (like indicator-multiload for instance is).
According to an answer on Ask Ubuntu [1], blacklisting all message-providers should hide indicator-messages altogether, but this doesn’t seem to work in 12.04, apparently because status-providers (which are different from message-providers) are still using the menu. (U1 Control Panel also seems to still occupy it despite being blacklisted.)
I’ve even tried overriding indicator-messages’ dbus service file with a hackish solution [2], but the envelope still insists on appearing (though without the associated menu).
* [1] http://askubuntu.com/a/15616/34756
* [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544483#42
There are many windows that would benefit from having the maximize button available but don’t. I produced snapshots of the history window, the ’Downloading Package Information’ window and the ’Mark additional required changes’ window. IIRC, the downloading packages and installing packages windows are also affected, though I couldn’t produce snapshots of those right now without installing sh… numerous packages I don’t want. Software sources is also affected, I guess that should be marked separately.
All these windows tend to have huge listings in them, and scrolling through those listings in cramped space is difficult. They’re already resizable (as they should be), so why not allow easy maximizing as well?
Seems to happen every time I update package listings now, right after all downloads have finished. It doesn’t prevent upgrading however, because if I restart Synaptic after the crash, all the listing updates have been applied and downloading the upgraded packages doesn’t crash Synaptic.
I just had the brightest idea. Two actually:
1. Make the launcher fill itself automatically with the most frequently used apps.
2. Make the launcher infinite in size so that you could (theoretically, should you want to) scroll down to every app you’ve ever launched that the infrastructure knows of.
==Severity==
I’ll elaborate on the justification below based on my use case. Depending on whether it’s a common or a less common one, this report is to be read as severity ’wishlist’ for a system default or an optional feature (an add-on or whatever they’re called in Unity-land).
==Justification==
The way I currently seem to be intuitively using the launcher, manually, is to stack it with apps I use most, with the most used one on top and less used ones descending according to use-frequency down from there.
This is at least an implicit, sometimes explicit [1] use case for the launcher, and something at which computers are by nature better than humans. So why not make the launcher do this automatically?
* [1] https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes#Ubuntu_Netbook_Edition
==Requirements==
Sometime in the past (see Bug #893214), the dash seems to have had a ’most frequently used apps’ category, apparently based on Zeitgeist. So the basic infrastructure for this should already exist.
==Affected==
I’m filing this against unity-2d-shell, since that’s what I’m using, but I suppose this applies to 3D as well. Ayatana might be the abstract-level target.
@Derkman96 No, looks like we’ve discovered this hidden gem of movie history independently. :)