It'd be really nice if we could team up with the people working on container technology so that we were able to run a full GNOME session within a container. Even if it was privilleged.
We could serve GNOME Continuous images as docker or lxc images with the latest stuff built in so that people can hack instead of waiting forever to build the same thing we're all building and just run it from within the container tree. Containers in general are a lot softer on hardware requirements than full fledged virtualization so we wouldn't be imposing a lot of requirements on hackers, on top of that they have the extra flexibility of us being able to step into the filesystem easily from the host so you can use your development environment instead of having to replicate it inside the VM. This would also alleviate all the dbus problems when nesting. I have tried running gnome-shell inside a docker/lxc image but had issues at several fronts what were less practical to address for me rather than switching to libvirt/kvm (this is something I needed for Fleet Commander). If we could crack those issues with a privileged container of some sort I think we could come up with a really handy workflow for ostree Relying on jhbuild from my point of view is a waste of everybody's time, we've got all these developers building the same version of the same module in the same architecture again and again and again, to reach more or less the same state, all the people who give up on writing a patch or testing master everytime a module breaks (like the latest libgit2-glib issues for example) is a precious resource we're wasting for not having the right infrastructure. Up to the point of glib or gtk+ is kinda handy but beyond that is almost impractical. 2015-07-21 1:16 GMT+01:00 Owen Taylor <otay...@redhat.com>: > On Mon, 2015-07-20 at 16:35 -0700, Jasper St. Pierre wrote: > > I've hacked on things all the from 1-5. Everything has a different > > development process, as usual, and I don't think there's any sense in > > trying to unify them. Writing documentation and getting people > > started quicker is always great, but everybody's going to have their > > own little things. > > We obviously can't make all developers work the same way, and we don't > want to. But there should be a way that we can recommend that actually > *does* work :-) > > > As for shell hacking, it's got increasingly more difficult to hack on > > things in a state like this, even under X11: launching a shell from a > > terminal loses things like search providers or some applications. > > There's issues with pkexec and other friends. Automounting USB keys > > never works when using jhbuild run. It feels strangely unclean and > > frustrating to work with. I just don't run a full shell as an X11 > > compositor through jhbuild anymore. I do what I need to, then reboot > > to get back to a clean state. > > Yeah. This type of thing is especially hard on newcomers, or simply > people who don't continually work on the shell, because only through > constant practice do you know *what* weirdness is due to a restarted > shell. > > > You can run gnome-shell in a nested mode, but gnome-shell's forceful > > grabbing of DBus names mean that the nested gnome-shell gets > > notifications, screen lock goes to it, etc. I tend to only use mutter > > in nested mode for Wayland hacking. > > > > Having scripts or a better setup to keep my jhbuild builds mostly > > in-line with the system ones would be great. > > > > Full KMS-style Wayland hacking, for me, is mostly a separate machine > > ssh'd into my main computer, there to debug and keep a session going > > at all costs. I have issues, though, sometimes the keyring acts up > > and eprompts for my ssh key on the terminal. Other times, I tend to > > "lose session-ness" and basically restart at that point to get things > > working again. > > If we could get nested working reliably, it certainly would be handy. > Not everybody has access to a second computer. (Saying that as someone > who is working as a nomad with a laptop for a couple of weeks.) > > The basic equation here is that nested == multi-seat; making nested > work properly is draining the swamp of multi-seat issues. > > As far as I understand it, there's a strong push on the part of the > systemd team to move from a session bus to a user bus; this probably > means that a single user logging into multiple seats - into a nested > session - is impractical. A single bus with components running from > multiple versions of GNOME seems like an endless source of debugging > headaches, even if we did all the work to move away from bus-global > names. > > So nested == cross-user nested. > > But it probably is better to concentrate on getting VT switching to > work well first, since a nested session is only an approximation of the > real thing. > > > What would really help is making VT switching work better. On my > > systems with external monitors (like the ones I hack on at work), a > > single VT switch takes 2-3 seconds from fbcon and back to X. I don't > > know if this is Xorg or fbcon or just the VT layer in general, but it > > is noticeable, and it is frustrating. I don't know if systemd > > -consoled / logind / "the VT replacement API" would help here at all. > > Yep. > > > Figuring out what "session-ness" means and how to gain it when simply > > ssh'd in would also be great, but I have a feeling it's simply twenty > > different environment variables I have to port over one by one. > > As you know, there are multiple scripts floating around for this, all > pretty hacky. An official solution would be great. > > - Owen > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Cheers, Alberto Ruiz
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
