| alkisg | http://tech.slashdot.org/story/12/09/03/0318246/ubuntu-gnome-remix-1210-arrives-for-testing | 03:54 |
|---|---|---|
| stgraber | alkisg: yep, that's jbicha's work | 03:55 |
| alkisg | Yup, I like the direction it's going in :) | 03:55 |
| alkisg | stgraber: any ideas about edubuntu/ltsp/thin client future, now that we won't have unity-2d and gnome-fallback? llvmpipe over the network really sucks, maybe switch to xfce/lxde? | 03:56 |
| alkisg | Or try to run the WM locally? | 03:57 |
| stgraber | alkisg: I sent an e-mail regarding that to the desktop team, we'll see what happens | 03:57 |
| stgraber | alkisg: short answer is, ltsp is in main and supported by Canonical, so I have to release with Unity support | 03:57 |
| alkisg | Cool, /me searches for the archives... | 03:57 |
| stgraber | now it's up to the unity team to fix it so that it works | 03:57 |
| jbicha | stgraber: edubuntu 12.10 won't have gnome fallback? | 03:58 |
| stgraber | jbicha: Edubuntu 12.10 will still let our users use gnome fallback. I'm talking about LTSP here | 03:58 |
| alkisg | Hmmm... warren mentioned that up to some point, maybe 2008/2009, 3d, compiz etc over the network worked quite well... unfortunately I've never been able to reproduce this | 03:58 |
| stgraber | alkisg: it does work fine if the software you're running supports indirect rendering | 03:59 |
| stgraber | which is the case for compiz, but not for compiz+unity... | 03:59 |
| alkisg | stgraber: with intel server + client, I'm still getting software rendering with llvmpipe | 03:59 |
| alkisg | (which is unusuably slow) | 03:59 |
| stgraber | also, compiz blows up in 16bit mode (well, so does llvmpipe, which is why I had to revert to 24bit in quantal for now...) | 03:59 |
| stgraber | alkisg: that's weird. And LIBGL_ALWAYS_INDIRECT=1 is set in the environment? | 04:00 |
| alkisg | Yeah.. I'll test again to make sure today | 04:00 |
| stgraber | I certainly was playing openarena full screen on 12.04 with my atom netbook just a few weeks ago ;) | 04:00 |
| alkisg | As a thin client??! | 04:00 |
| stgraber | yep | 04:00 |
| alkisg | Ty, I'll look into it | 04:00 |
| stgraber | it was using 30-40Mbps of bandwidth, so not something you'd want all your network to do, but it was still working | 04:00 |
| alkisg | We'll have problems with all the older hardware that doesn't support 3d, but at least modern hardware will work in this case | 04:01 |
| alkisg | (although usually ancient hardware => thins, modern => fats...) | 04:01 |
| stgraber | yeah, I expect people deploying on older hardware to go with gnome-session-fallback or switch to lxde/xfce | 04:01 |
| alkisg | We need to select one of them and debug it a bit to ensure a smoother experience | 04:01 |
| alkisg | I think vagrantc is using lxde, so it should work ok with ltsp | 04:02 |
| stgraber | yeah, will happily let that work to someone who actually cares ;) for now I'm just trying to get something that works fine on 2-3 years old Intel, that's already hard enough as it's... | 04:02 |
| alkisg | Edubuntu will stay with unity, right? | 04:03 |
| stgraber | yep | 04:03 |
| stgraber | though as jbicha mentioned, we offer gnome-session-fallback as an option in the installer | 04:03 |
| stgraber | choosing that option will change the default session of both the server and thin clients | 04:03 |
| alkisg | I don't think that'll still be alive for the next LTS though... they're killing it upstream | 04:03 |
| stgraber | (both unity and gnome-session-fallback are installed in all cases) | 04:04 |
| stgraber | yeah, that part kind of sucks as I really don't want to bring a whole different desktop environment in Edubuntu just to support older hardware... | 04:04 |
| stgraber | the fallback session was really good for these cases... | 04:04 |
| stgraber | (and for the nostalgics ;)) | 04:05 |
| jbicha | alkisg: I don't think gnome-session-fallback is dead yet | 04:05 |
| alkisg | And I heard some apps like totem won't work with fallback, I don't know when that started though | 04:05 |
| alkisg | jbicha: I'm reading this: https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode | 04:05 |
| jbicha | alkisg: no, totem won't work now without 3D, it still works in GNOME Classic | 04:05 |
| alkisg | ...and the relevant bug reports suggest they're removing support upstream currently | 04:05 |
| stgraber | alkisg: I believe the totem issues are linked to clutter which doesn't like 2D environments, so yeah, these will likely stop working on thin clients, whatever the desktop environment you're using | 04:06 |
| jbicha | "won't work with fallback" is a bit misleading | 04:06 |
| stgraber | unless they work with indirect rendering, then they should at least work on intel | 04:06 |
| alkisg | "several apps now require clutter and can't work in fallback mode (totem, audio/video UI in empathy, cheese, etc.) " ==> the way they say it, they should have problems with unity-3d too | 04:07 |
| jbicha | it depends on what the meaning of "fallback" is | 04:07 |
| jbicha | in the pure, ideal GNOME world, you'd only be using fallback if you don't have working 3D so in that case, the clutter apps won't work | 04:08 |
| stgraber | alkisg: anyway, it's indeed a pretty bad time for LTSP at the moment when gnome-shell, unity and kde all kind of suck on thin clients (where suck ranges from segfault to being so slow it's unusable). I'm expecting to recommend people to stick to 12.04 for now while we see how things evolve... | 04:08 |
| alkisg | Their solution there is software emulation, llvmpipe | 04:08 |
| alkisg | stgraber: +1 | 04:09 |
| stgraber | alkisg: my guess is that soon enough we might have to start doing fat clients by default and let the thin client stuff to people who know what will work with it and what desktop environment they want... | 04:10 |
| stgraber | I'm really not looking forward to that day though... it kind of defeats the original purpose of LTSP... | 04:10 |
| alkisg | It depends... the most valuable thing in LTSP for me is it's "whole lab in a server" feature, not just the "reuse ancient hardware" feature... | 04:11 |
| stgraber | sure, but we used to have both ;) | 04:12 |
| alkisg | Yeah :( | 04:12 |
| alkisg | We might be able to run the WM locally though... | 04:13 |
| stgraber | indeed, we'd likely have to fix dbus to work properly first though then check that dconf and similar stuff don't blow up | 04:13 |
| stgraber | and that wouldn't save us from totem and other stuff using clutter, though I suppose we could run these locally too (probably a good idea in any case) | 04:14 |
| stgraber | I think the idea would really to reverse the concept between local and remote apps and make sure we can seamlessly integrate "remote" apps on a fat client system | 04:15 |
| stgraber | then build a list of stuff that should be running on the server (libreoffice, ...) | 04:15 |
| * alkisg expects 14.04 to be a bit chaotic for LTSP, and the next LTS after that to use wayland and be even more chaotic :D | 04:15 | |
| stgraber | I'm kinda hoping someone will eventually notice that our new shiny desktops don't have any working remote desktop protocol and will fix that somehow... as remote X11, VNC, RDP, NX, ... all suck with the new shiny desktop environments... | 04:16 |
| stgraber | gets me wondering why we even ship vino... | 04:16 |
| jbicha | alkisg: wayland was considered for 12.10, I expect they'll try again for 13.04 | 04:16 |
| alkisg | I think that part will be very good for ltsp... either fats, or the wayland remote desktop solution | 04:16 |
| alkisg | jbicha: so we might have it as the default for 14.04 without the need for x-wayland? Dunno, it sounds to me the apps aren't ready yet... | 04:17 |
| jbicha | oh, it's still x on wayland | 04:17 |
| alkisg | That will still give us the same problems with ltsp though :-/ | 04:18 |
| stgraber | so far my upstream plans are to do the switch to lightdm during this year's hackfest (next month), nag Scotty to get libnss-ssh and libpam-ssh in shape, get that released, then fix/update stuff as things get better/worse | 04:19 |
| stgraber | they landed lightdm with rdp support last week (or the week before?) in quantal, so my plan is to just re-use that API to implement an X11/LTSP backend | 04:20 |
| stgraber | that should be trivial and should let us get rid of ldm | 04:20 |
| alkisg | Cool, that's a very good plan | 04:20 |
| stgraber | then again, it's an LTSP hackfest, so we'll see how much of that will actually happen ;) | 04:20 |
| alkisg | Eat some lobster for me too :D | 04:21 |
| stgraber | highvoltage: speaking of the hackfest, Marc and you are going, right? (otherwise I'll need to figure out how to get down there and pretty quick...) | 04:21 |
| vmlintu | stgraber: is lightdm going to be the only supported dm? I remember there being talk about supporting kdm/gdm/xdm/lightdm with libnss-ssh/libpam-sshauth. | 12:14 |
| alkisg | Ideally we would support any pam-capable DM | 12:16 |
| alkisg | But I don't know if we'll be able to support everything, like e.g. the rdp plugin | 12:17 |
| alkisg | We can create different sessions in /usr/share/xsessions to be selected from any DM upon login | 12:17 |
| alkisg | E.g. "Local session (fat client)", "Gnome, on server (thin client)" etc | 12:17 |
| alkisg | And authentication is fine with pam as well | 12:17 |
| vmlintu | does the rdp stuff require something special? | 12:18 |
| alkisg | But "login as guest", "rdp session"... I don't know if we'll be able to support all the options that are available in ldm | 12:18 |
| alkisg | The rdp session actually isn't a session at all, since the user doesn't exist locally | 12:18 |
| alkisg | *not in any ssh-capable server | 12:19 |
| alkisg | Anyways, most of these questions will be answered in BTS... although the implementation will need months | 12:19 |
| vmlintu | now that schools have started, I'll have time to work on the lightdm stuff again | 12:22 |
| alkisg | Cool... it would be nice if you could attend the BTS as well, to give feedback to Scotty, even remotely... | 12:23 |
| vmlintu | until now we've been doing to work with any dm, but the lightdm specific backend stuff would change this | 12:23 |
| alkisg | I think the plan is to support any DM, and just polish lightdm a bit more | 12:24 |
| alkisg | Since it has supports for plugins etc | 12:25 |
| vmlintu | I won't be able to attend bts physically | 12:25 |
| vmlintu | when is it going to be? | 12:25 |
| * alkisg neither... in a couple of months, not sure exactly | 12:25 | |
| alkisg | The certain part is that we'll need to change LTSP a bit as well | 12:26 |
| alkisg | E.g. if we only have 1 DM menu for selecting the thin client session, how will clustering or load balancing be done? | 12:26 |
| alkisg | So maybe "Gnome on server with less CPU load (thin)", "LXDE on server1 (thin)" etc, multiple menus | 12:27 |
| alkisg | And we'll need the DM to notify pamssh about the selected session, _before_ the authentication... | 12:27 |
| vmlintu | so far we have disabled all ldm menus anyway | 12:27 |
| alkisg | That's ok for testing, but it can't be committed upstream like this, people that use load balancing will complain | 12:28 |
| * alkisg only uses a single linux server so doesn't care much about all that | 12:28 | |
| vmlintu | automatic load balancing should be no problem as the login script checks the servers before logging in | 12:29 |
| alkisg | Also pulse will need to be started as part of the session... ldm/rc.d will need to find a new location | 12:29 |
| vmlintu | load balancing cannot be left to the user anyway | 12:29 |
| alkisg | There are cases where the user needs a certain server because it has a specific app | 12:30 |
| alkisg | Or cases where someone wants to try a local login (fat), or an rdp login, or an ssh login (console)... too many cases to support | 12:30 |
| vmlintu | hmm.. I've never actually tried if ldm has support for selecting the server | 12:30 |
| alkisg | Now we only have /usr/share/xsessions/*.desktop files to go with | 12:31 |
| alkisg | (if we want to support all DMs) | 12:31 |
| alkisg | And we won't be able to display different languages per server | 12:31 |
| alkisg | We'll just have to sum up all of them and display them all at once | 12:32 |
| vmlintu | different languages? | 12:32 |
| alkisg | Login language | 12:32 |
| alkisg | E.g. a server might support en, fr, and another en, el | 12:32 |
| alkisg | Ideally when server1 was selected, the language combo box of the DM would only show en + fr | 12:33 |
| vmlintu | Does LDM have currently something like that? | 12:33 |
| alkisg | No, it only supports a single server :) | 12:33 |
| alkisg | (I think) | 12:33 |
| vmlintu | ok.. I started thinking that I have missed something big | 12:34 |
| vmlintu | one option would of course be to have a separate dialog appearing after *dm login | 12:35 |
| vmlintu | That could ask everything that is needed - specific server, language, what ever.. | 12:36 |
| alkisg | One for selecting the server before, and one for selecting specific options afterwards | 12:36 |
| alkisg | But displaying dialogs is intrusive, they'd need to be optionally selected from DM menus | 12:37 |
| vmlintu | I want the *DM to be without a single selection anyway | 12:37 |
| vmlintu | Do you know what kind of apps people are using that are installed only on specific servers? | 12:38 |
| alkisg | I've heard some people at #ltsp mentioning specific use cases, but I don't remember any of them | 12:39 |
| vmlintu | I think I'll do some testing with the xsession .desktop files to see how lightdm behaves.. | 12:41 |
| vmlintu | Are there other load balancing solutions besides ltsp-cluster around? | 12:41 |
| vmlintu | That kind of load balancing doesn't require UI | 12:41 |
| alkisg | LDM_SERVER="server1 server2 server3" | 12:43 |
| alkisg | I think we support automatic load balancing when the user defines multiple servers | 12:44 |
| alkisg | (if not, I once wrote a script for that...) | 12:44 |
| vmlintu | that queries ldminfod? | 12:44 |
| alkisg | I think ldminfod is queried for all LDM_SERVERs | 12:45 |
| alkisg | ...but since we're only using 1 server always, I haven't really dug into all that | 12:46 |
| vmlintu | yep.. we've been using lately a load balancer that asks sinfod for server loads | 12:47 |
| vmlintu | it mimics partly ltsp-cluster so it works with normal chroots | 12:48 |
| vmlintu | I've been wondering if something like that should be built-in in ldminfod. Every server would broadcast its status and all other servers would always know the status for all servers. | 12:49 |
| vmlintu | ldm/lightdm/*dm would need to query only one server to know where to connect | 12:49 |
| alkisg | At some point in the future I want to propose a new configuration system for ltsp, a settings daemon on the server that provides info for the server itself and for each client/boot phase | 12:49 |
| alkisg | If that's well implemented, it might replace ldminfod... | 12:50 |
| vmlintu | would ldminfod replacement need to be compatible with it? | 12:50 |
| highvoltage | stgraber: it's highly unlikely that Marc will be going at this point | 12:51 |
| highvoltage | stgraber: I want to go, so we'll see | 12:51 |
| alkisg | vmlintu: it depends... it might have a compatibility layer there, it's not hard to do that, although I'm not sure if it's worth it | 12:51 |
| vmlintu | highvoltage: going to uds? | 12:55 |
| vmlintu | alkisg: what about the lts.conf stuff? Is there need for tftp based method? | 12:56 |
| alkisg | vmlintu: I don't see a need there, except for compatibility | 12:57 |
| alkisg | The initramfs can access the web (wget) or any other port (nc), no need for the additional tftp client we're installing in the initramfs... | 12:57 |
| alkisg | And since we already have an ldminfod, it's not like we need another settings server. 1 is enough | 12:58 |
| highvoltage | vmlintu: I'm not sure, at this point it doesn't seem so | 12:59 |
| vmlintu | highvoltage: ok | 12:59 |
| highvoltage | vmlintu: but I admittedly don't have much of a reason to go, I have enough work for the next 6 months edubuntu-wise already | 12:59 |
| vmlintu | highvoltage: what kind of things are you working on now? | 13:02 |
| vmlintu | alkisg: if there was a way to load the kernel with http, I'd be happy.. | 13:04 |
| alkisg | vmlintu: other than ipxe / ipxelinux.0 ? | 13:05 |
| vmlintu | alkisg: I always keep forgetting that.. it should be the default | 13:09 |
| vmlintu | and now I remember again that ipxe doesn't work with all the hw I have in hand.. | 13:24 |
| alkisg | ipxelinux.0 is supposed to reuse the pxe stack | 13:24 |
| alkisg | So it should work for all cards | 13:25 |
| vmlintu | maybe I have tried it with some other method | 13:26 |
| vmlintu | hmm.. I think it was the chainloader that I tried earlier | 13:29 |
| highvoltage | vmlintu: not much, that's the problem | 13:30 |
| highvoltage | vmlintu: we don't have that much technical commitments atm, but we have a *lot* of project stuff to sort out, growing the community, contuing the work we set out to do on the website, interviews and news on the site, sponsorship process and more | 13:31 |
| highvoltage | vmlintu: not necessarilly big or scary things (actually quite the opposite), but I'm interested in too many things that could each be full-time things on their own. at least I've been making progress with time-managing all of these recently. | 13:32 |
| vmlintu | alkisg: is ipxelinux.0 available somewhere? | 13:40 |
| alkisg | vmlintu: I haven't used that, I'm not even sure it's named like that | 13:40 |
| alkisg | It might be called undi something | 13:40 |
| vmlintu | undionly.kpxe? | 13:41 |
| alkisg | Yup, that one, but still not sure about it | 13:41 |
| alkisg | And not sure from what version on it supports http either | 13:41 |
| alkisg | Try the syslinux wiki or irc | 13:41 |
| vmlintu | that has been giving be problems earlier | 13:41 |
| alkisg | http support should be quite new, so you might have hit bugs that were fixed in the meantime | 13:42 |
| vmlintu | I'll do some testing | 13:42 |
| vmlintu | thanks | 13:42 |
| alkisg | People at #syslinux are friendly, do ask them about any problems | 13:42 |
| vmlintu | highvoltage: that does sound like a lot | 13:45 |
| bencer | stgraber: did u see my reply on #1043654? | 14:34 |
| highvoltage | stgraber: these would be fine for weblive, right? http://www.hetzner.de/hosting/produkte_rootserver/ex4 | 16:45 |
| highvoltage | hey there bencer | 16:45 |
| bencer | hey highvoltage | 16:45 |
| bencer | im blocked waiting for the -release team to approve the ffe | 16:46 |
| bencer | migration is going to be difficult from precise | 16:46 |
| bencer | as explained in the ticket | 16:46 |
| bencer | https://bugs.launchpad.net/ubuntu/+source/zentyal-samba/+bug/1043654 | 16:46 |
| ubottu | Launchpad bug 1043654 in zentyal-samba (Ubuntu) "[FFe] New version of zentyal-samba" [Undecided,New] | 16:46 |
| stgraber | highvoltage: yep | 16:48 |
| highvoltage | stgraber: ok, I sent PLC an email request cc'ing ben and serge and also sent ben an update on the sponsoring process that we're working on | 16:54 |
| highvoltage | stgraber: now to get the TB while I'm at it :) | 16:54 |
| stgraber | highvoltage: ok :) | 16:54 |
| bencer | stgraber: highvoltage any opinion on the zentyal-samba? | 16:57 |
| highvoltage | bencer: imho it looks reasonable | 17:20 |
| bencer | highvoltage: if you can comment something on the ticket, would be great | 17:20 |
| highvoltage | bencer: ok, but I have pretty much 0 say in it :) | 17:22 |
| bencer | highvoltage: maybe helps to get the ok from the -release guys | 17:23 |
| highvoltage | bencer: ok, posted | 17:26 |
| bencer | highvoltage: cool, thanks! | 17:26 |
| bencer | highvoltage: ups and ltsp modules ffe are still there, no updates :-/ | 17:26 |
| highvoltage | bencer: yeah you might want to ask in #ubuntu-release about that | 17:27 |
| === yofel_ is now known as yofel | ||
| highvoltage | bencer: not sure if you follow #ubuntu-release... | 19:39 |
| highvoltage | 15:36 < iulian> highvoltage: zentyal: I'd appreciate it if you could provide something more useful than that, preferably some logs that show that it is indeed a low-risk update. | 19:39 |
| bencer | highvoltage: https://launchpad.net/~bencer/+archive/zentyal-2.3-p/+packages | 20:10 |
| highvoltage | bencer: ok, see #ubuntu-release and paste that link to iulian too please | 20:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!