KDE on multiuser/multicomputer systems?

On my schools computer lab we have lots of desktop computers all with gnome, kde and various other wm’s installed, with the home folder shared across all computers. Lately I’ve become more and more conscious of the various bugs setups like this bring in KDE. Even though most of the computers in question run the same (k)ubuntu, there’s many times more glitches than a similar single-user system. Things like “do you want to forget these audio devices” popping up on every login, plasmoids randomly failing to load when changing computers, wallpapers also randomly going blank, having to resize the panels when changing to/from a widescreen computer, plasmoid positions jumping around, etc etc, they all make me wonder how much the changing environment case has been taken into account designing the KDE desktop.

Are there tricks to get working setups for my case? Would the best bet perhaps to be to only use a least common denominator type of setup, only introducing new stuff when I know they work everywhere? Or am I crazy to even expect the desktop to work similarly on a (seen from KDE configuration POV) constantly changing environment?

11 Responses to “KDE on multiuser/multicomputer systems?”

  1. FACORAT Fabrice Says:

    Same issues for me ( /home on NFS ), and thus even if most of the time, people don’t change computer.

    – phonon with pulseaudio devices issues
    – firefox sqlite bork after crash or unexpected closing ( or hard reboot )
    – panel sizing issue ( IMHO when checking thre max size panel option, it should always take the maximum width of the screen )
    – digikam not willing to put it’s database on NFS
    – I guess that Akonadi will have the same issue …

    If you look closely, more and more application ( notably the ones using a database ) no longer really support a /home on NFS setup … this is sad

  2. g Says:

    Unfortunately I am not able to help you. But I want to say that your are NOT crazy for expecting this. In the future we may have situations in which people will have their whole $HOME directory on a USB stick or smartphone and move from computer to computer (instead of dragging a laptop or a netbook with them). Therefore it is necessary that the transition from computer to computer is smooth with no intervention from the user. Furthermore configurations or features that are not available on a certain computer should smoothly degrade. Setups like yours in which you have several computers with the same software and which are maintained centrally (i.e. one configuration for all) are quite common and should work out of the box without any tricks. Also when a user buys a new screen (with a different size), he shouldn’t be forced to relocate all plasmoids on his desktop to a decent place or resize panels or change the background … So the fact that setups like yours fail so miserably is a bug in my opinion and you should file the bug in the KDE bug tracker.

  3. Andre Says:

    Fabrice:
    #1 is afaik a Pulseaudio / gdbm problem. But we have phonon so you can simply try a different backend.
    #2 and #4 are SQLite problems (it needs file locking for the database which is broken on some NFS implementations). Updating the NFS packages might help. Otherwise you can compile digikam with –enable-nfs-hack.
    Akonadi will not have this issues.

    OP: often the problem is that new versions can convert old configurations, but of course not the other way around. i agree there should be a desktop-wide way to deal with this automatically, but afaik there is no such thing.

  4. Jonas M. Gastal Says:

    I don’t know wether or not this is relevant, but I can explain some of these issues you are having. The explanation might help come up with workarounds.

    *Audio devices issue: Phonon is storing the configuration of the devices inside the users $HOME folder and since(presumably) not all computers have the same hardware came the error messages. Maybe you can look into relocating the Phonon configuration file.
    *Wallpapers desappearing: The wallpapers are not being stored in the $HOME folder which means that it exists only in the computer you downloaded it. Maybe you can move the default wallpaper folder inside the user $HOME folder.
    *Plasmoid issues: these is more complicated since changing the config files outside the $HOME folder(would resolve size/placement) issues would also mean having to configure them in each computer.

    I absolutely agree that these issues should be handled by kde(and firefox), but while they aren’t maybe the above explanations will help.

  5. Yiannis Belias Says:

    [In the future we may have situations in which people will have their whole $HOME directory on a USB stick…]

    WOW! I live in the future :)))
    Well, OK… Actually I got a USB HD cause *fast* && > 10GB flash memory is still too expensive.
    Currently I’m using symbolic links for config files that should be different between the 2 hosts (My desktop and netbook).
    To automate this task, I have a script on the ext. HD that is run by udev and makes the necessary mounts and links. So I just turn on the pc, plug in the drive, and wait for KDM login. I could blog about it if someone’s interested, but it is in “beta” state – although it works for me :P

    The only *real* solution to this kind of problem would be a different configuration system for all apps writing on $HOME. Something like elektra: http://elektra.g4ii.com/Main_Page ,
    but with an extra (optional) hostname field for each key/value pair.
    Of course, this should not be KDE/Gnome/whatever specific (elektra isn’t).

  6. s.h. Says:

    I used to have a problem which is a part of your problem:
    I used vnc to login to X/kde on my big machine remotely with my netbook. Obviously my screen settings where different between the big machine (22″) and my netbook (10.1″) which screw up screen configuration every time. After bringing this up on kde brainstorm as an idea for a new feature (making config of kde resolution dependant) and getting “shot down” with “nobody needing that feature”, I tried a dirty hack by kdm linking config on log in. But this was not really usable so I solved it by giving up since nobody else seemed to be interested…

  7. martinsandsmark Says:

    We have a patch for fixing the path of the phonon configuration, should be fixed any day now. :-)

  8. Chani Says:

    if the panel is max. size, it should Just Work. sounds like a bug to me.
    the rest of it is harder to deal with… although I think I saw a patch for phonon recently

  9. Dotan Cohen Says:

    The best thing that you can do is to file bugs with detailed reproduction instructions. Not many devs have access to the configurations that you are using, so of course your configurations are the least tested. File bugs and help make KDE that much better!

  10. Aaron Seigo Says:

    “if the panel is max. size, it should Just Work.”

    depending on how new the KDE is; there were bugs in this right up into the 4.3.x releases, with some fixes backported.

    if there are still breakages with 4.4, some debugging would be welcome.

    as for “widgets jumping around”, nobody has worked yet on a heuristic for dynamically adjusting widget geometry in different screen resolutions beyond “keep them in the current screen geometry” which we have right now. it’s not a trivial problem, though probably not rocket science either. patches welcome.

    as for “widgets not loading because of changing computers” … well, do you want/expect plasma to carry all the widgets it has currently running around with its configuration? (exercise left to the reader to determine why that would be a pretty crazy idea).

    as for wallpapers .. are the wallpapers available on the other machine? the only possible solution there is to copy the currently used wallpaper into the user’s home directory if it doesn’t already exist there. this would a waste for most people using plasma-desktop, but it would be a way to make “i moved my home directory to a different computer and now there’s no wallpaper” work still. would require some changes to the image based wallpaper plugins to use that as a fallback, of course.

    in any case, i do know that your blog is really not the most productive place to work on these things. put together detailed sets of issues, create a page on techbase.kde.org/Projects/Plasma/ for it then come to plasma-devel@kde.org and a dialog can be started on the issues.

    • Harald Says:

      For the widgets not loading, these were standard widgets which should have been installed on the other computer as well, but for some random reason they still did not load. I will look into it.

      For the wallpapers, they were downloaded using GetHotNewStuff as a normal user (of course), and this is the reason I expected it to appear on the other computer as well because the wallpaper should be placed in some folder relative to the homefolder and just work.

      As for the last comment, I really did not mean to focus on the various bugs I listed (although I see that I perhaps listed to many for just stating a point), what I really was interested in was what earlier design decisions were taken for these kind of setups (as well what the current guidelines are now). Things like, are there use cases defined for kde configurations actively switching betweens computers/versions?
      …crap, reading the post once more now I realize that point drowned completely in the things-aren’t-working-rant…

      For getting the issues fixed bug-reporting is of course the way to go.

Comments are closed.


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: