What are the Implications of Kubuntu with Wayland and Ubuntu with Mir

[SteveRiley]

I just read that Phoronix article. Take a long, hard look at the following paragraph:

Canonical will now need to carry the XMir support out-of-tree from the xf86-video-intel driver. Canonical is also carrying patched versions of Mesa, xf86-video-ati, and xf86-video-nouveau for being able to support Mir/XMir in Ubuntu 13.10. The binary AMD and NVIDIA graphics drivers also remain incompatible with Mir.

At what point will Ubuntu no longer be Linux?

[SteveRiley]

So it is now up to Canonical to develop a driver in house for the Ubuntu 13.10 release -- yet more new software to integrate, verify and validate in a short space of time. Best of luck to our SABDFL.

Oh wow. Let me tell you a little something about this. Microsoft collects an astounding amount of useful telemetry from PCs whose owners have opted into this service. One aspect of this is data that leads to root cause analysis of blue screens. Well over 50% of crashes come from third-party drivers (and if I remember my numbers correctly, malware is the next 45%, and bugs in the OS make up only the remaining 5%). If the companies that make video hardware for a living have trouble maintaining high-quality driver code, the future of Mir on Intel seems grim indeed.

[NoWorries]

Intel Supporting Wayland

I am still on holidays and will not be returning to OZ for about a week, but I am still able to keep tabs on developments. This one particularly interested me as it has an impact on Ubuntu developing Mir and positive support for Wayland. In this Phoronix article Intel initially supported driver development for XMir and this has now been remove. The approach that they are now taking is best discribed in this quote from the article

Intel, which is a company heavily invested in Wayland and has many full-time employees working on the competing display server (including Kristian Høgsberg, the Wayland founder), now doesn't want any XMir support in their mainline driver. It's interesting to see Intel management force the XMir removal from the Intel driver just days after it was committed and to publicly state a neutral stance on Canonical's controversial display server.

So it is now up to Canonical to develop a driver in house for the Ubuntu 13.10 release -- yet more new software to integrate, verify and validate in a short space of time. Best of luck to our SABDFL.

[Rog132]

Sddm

Earlier:

http://www.kubuntuforums.net/showthr...l=1#post329737


Ubuntu wish:

https://bugs.launchpad.net/ubuntu/+bug/1157742


Kubuntu & Saucy

https://trello.com/kubuntu -> 13-10 Postponed


Other/Fedora

https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM

[SteveRiley]

Derp. Thanks for the correction!

[kubicle]

Claydoh mentioned a while back that KDE will likely switch to SLiM at some point.

You mean SDDM (a QML display manager), not SLiM.

[SteveRiley]

Claydoh mentioned a while back that KDE will likely switch to SLiM SDDM at some point.

[texaswriter]

So, here's a good question regarding LightDM... Why doesn't KDE/Kubuntu fork LightDM for their own purposes. I know that may seem pathetic at first thought, but if this is going to be problematic for developers or for KDE-related organizations in the future, it should be a no-brainer, no??

Apologies if this has been posted somewhere already.

[kubicle]

hope that answers your question

Indeed it does, thanks

[shadeslayer]

It's been a while since I've had neon, but sounds that it'll likely be the best way to eventually test KDE5.

I know neon's kde settings were sandboxed by a different $KDEHOME, but what about $XDGDIRS (~/.local/share, ~/.config, ~/.cache), I'm mainly thinking akonadi here, are these sandboxed as well...or is it safer to use a separate user for neon? (something I used to do previously)

From /opt/project-neon/share/project-neon/environment.rc

## XDG
## put these seperate, needed for e.g. akonadi
## refer to http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
mkdir -p $KDEHOME/local/share
export XDG_DATA_HOME=$KDEHOME/local/share
mkdir -p $KDEHOME/config
export XDG_CONFIG_HOME=$KDEHOME/config
mkdir -p $KDEHOME/cache
export XDG_CACHE_HOME=$KDEHOME/cache
export XDG_DATA_DIRS=$KDEDIR/share:/usr/local/share:/usr/share

hope that answers your question

[kubicle]

it's a complete sandboxed solution to run KDE from git.

It's been a while since I've had neon, but sounds that it'll likely be the best way to eventually test KDE5.

I know neon's kde settings were sandboxed by a different $KDEHOME, but what about $XDGDIRS (~/.local/share, ~/.config, ~/.cache), I'm mainly thinking akonadi here, are these sandboxed as well...or is it safer to use a separate user for neon? (something I used to do previously)

[shadeslayer]

Breakage? What kind of breakage? It's installed separately, the configs are stored separately, it's a complete sandboxed solution to run KDE from git. So even if latest git breaks for you, you can always login into your regular KDE and enjoy a breakage free system

[NoWorries]

Have you been running on Project Neon? I've considered it, but worry that there might be too much breakage.

Not yet, but I may consider it after I replace Kubuntu 13.04 by Kubuntu 13.10 on my Laptop. I currently have 13.10 on a USB 3.0 memory stick connected to my Laptop for testing and when all the problems with this are resolved, I will install 13.10 on my Laptop. I will then add the neon repositories to the system on the USB 3.0 stick to test as, if this system breaks, it will not damage my main system.

[SteveRiley]

Have you been running on Project Neon? I've considered it, but worry that there might be too much breakage.

[NoWorries]

Thanks very much for this news. I found it interesting that throughout the report, the term Kubuntu was always used. I was also encouraged that allowance was made to people like myself

At the same time, the brave among us will be able to test early versions of Plasma Workspaces 2, which are being constantly updated through Project Neon, a sort of rolling testing releases.

So great times ahead