Host ID: 156
Chase Douglas is a software developer at Canonical working primarily on multitouch user interface support. For the past year, Chase has been involved with developing gesture support through Canonical’s uTouch framework and multitouch support through the X.org window system. Prior to working on multitouch, Chase spent three years performing Linux kernel and plumbing layer development and maintenance at Canonical and IBM.
Alison's questions: 3:49 - Alison asks "Chase, back up for a moment, can you talk a little bit about what X input is and how X in general works in Linux."
6:13 - Alison asks "Do you have any particular target hardware that you are thinking about during its development?"
11:57 - Alison asks "Do we expect the mouse and keyboard to be with us in the long term? Are you really thinking of all these touches used in concert with the mouse and keyboard or that we may be evolving away from that?"
17:45 - Alison basically asks "Is there talk about an agreed upon gesture language?"
20:56 - Alison asks "What is the state of device driver support for capacitive screens that will support multitouch in Linux?"
26:34 - Alison asks "Speaking of software coupling, are you looking at Wayland already or is that still over the horizon?"
28:43 - Alison says "The automotive case seems like a fascinating one. As far as touch and gesture goes and Ubuntu has an IDI and recently Cadillac has a multitouch screen that has haptic feedback and some gesture support. This looks like a very exciting area for development. Actual shipping products in 2012. I don't know if you're familiar with that at all."
32:11 - Alison asks "Do you anticipate contributing the multitouch work to GNOME and Debian as well?
35:0 - Alin asks "What new features can we anticipate that will be user visible for precision in the area of multitouch and gestures?"
43:56 - Alison says "I think I'm happy although I must mention I was pained to hear that it was 24 years ago that you were an infant because I was at M.I.T when they started the X project. heh heh. you young whippersnappers. ... that was very fascinating. I had no idea there was that much activity going on. I'm really excited to see what's coming out and what new features are being added."
Martin Peres works on the nouveau driver for X.org.
Nouveau project site - http://nouveau.freedesktop.org
Nouveau mailing list - http://lists.freedesktop.org/mailman/listinfo/nouveau
Nouveau irc - irc.freenode.net #nouveau
The program that reads information from your Nvidia card that Martin talks about is called nvacounter.
It can be found at: https://github.com/pathscale/envytools/tree/
Ian Romanick works on Mesa at Intel. Mesa is an open-source implementation of the OpenGL specification - a system for rendering interactive 3D graphics.
Mesa project site - http://www.mesa3d.org/
Mesa mailing list - http://www.mesa3d.org/lists.html
Mesa irc - irc.freenode.net #dri-devel
Peter Hutterer works on X.org, specifically the input system, at Red Hat.
Xorg project site (input is one of several parts to X) - http://x.org/wiki
Xorg mailing list - http://lists.x.org/archives/xorg-devel/
Xorg irc - irc.freenode.net #xorg-devel
Peter's blog - http://who-t.blogspot.com
Jamey Sharp was placed on Ritalin, briefly, in fifth grade. His interests and activities have been varied ever since. Today his day job involves a computer test for attention deficit disorder, but his biggest projects have been the Portland State Aerospace Society, a student rocketry club at Portland State University; XCB, a new low-level binding to the X protocol, in the process of replacing Xlib; and Serialist, because his other projects didn’t leave him enough time to read his favorite webcomics without tool support.
Jamey’s interests span computer science fields including cryptography, combinatorial search, compilers, and computational complexity; systems-level programming, such as file format and network protocol implementations, Linux kernel development, and boot-loader hacking; computer architecture and its impact on software design; and functional programming, preferably in Haskell.
This interview focuses on Jamey's work on X.org, specifically the XCB project. The X protocol C-language Binding (XCB) is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility.
XCB project site - http://xcb.freedesktop.org/
XCB mailing list - http://lists.freedesktop.org/mailman/listinfo/xcb
XCB irc - irc.freenode.net #xcb
rpm, rpm5, deb/dpkg, ebuild, compressed files (archlinux), pisi, .tgz (tar.gz file) slackware/vector linux, .tlz (Vector Linux)
Program Distro(s) website notes
conary Foresight Liux/rPath company handles distributed repositories, commit/rollback
entropy Sabayon consists of Equo client (textual), Sulfur client (graphical)
kpackagekit kubuntu uses policykit (any problems if booted computer from a live cd and mounted and chroot'd?)
opkg openmoko lightweight; based on ipkg
pirut fedora it calls yum so it's just a gui wrapper? not sure how widely used...?
pisi pardus (Turkish distro) was based on gentoo. as far as I can tell it now uses its own pkg format
poldek Fedora RPM
portage gentoo ebuilds,
slapt slackware tgz
slapt vectorlinux tlz;
smart UnityLinux RPM5
synaptic ubuntu DEB; graphical frontend to apt
urpmi mandriva RPM
yum redhat/fedora RPM
zypper opensuse RPM
Other useful links:
apt - http://wiki.debian.org/Apt
conary - http://wiki.rpath.com/wiki/Conary
entropy - http://wiki.sabayon.org/index.php?title=En:Entropy
kpackagekit - http://en.wikipedia.org/wiki/KPackageKit, http://www.packagekit.org
opkg - http://code.google.com/p/opkg/
pacman - http://www.archlinux.org/pacman/
pirut - http://fedoraproject.org/wiki/F8_User_Guide_-_Managing_Software_with_Pirut
pisi - http://en.pardus-wiki.org/Making_Pisi_Packages
poldek - http://poldek.pld-linux.org/
portage - http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1
slapt - http://vectorlinux.osuosl.org/docs/vl58/manuals/vl5_slaptget_en.html
smart - http://niemeyer.net/smart
synaptic - http://www.nongnu.org/synaptic/
urpmi - http://wiki.mandriva.com/en/Tools/urpmi
yum - http://yum.baseurl.org/
zypper - http://en.opensuse.org/Portal:Zypper
1) package burn out - will it get to the point where only either large distros or commercial distros have large repos due to the effort involved?
2) I've lost track of the number of times i've heard from people 'our distro doesn't have enough manpower to package ...'
wouldn't it be helpful to not have to use our limited manpower in building redundant packages?
3) in 10 (or less) years when non-technical people take over at Redhat/Ubuntu/other large distro, will they use the package system as a club to beat the other distros with? I'm not sure how, but where money is involved, you can feel assured it _will_ happen.
4) current state of packaging systems in linux is like sound systems were 10 yrs ago.
remember esd vs arts vs vs ...? each desktop environment had its own system. sound in linux was painful and a complete joke. it still has a ways to go but it's _SO_ much better now that it was. does anyone want to go back to that?
pulseaudio isn't perfect but it's so much better than what we had before. and it's ONE system!
can you image if printing and authentication were like the packaging systems? image if everyone had their own printing system instead of CUPs? imagine if there was no pam.d?
5) I believe packaging systems are NOT about choice. the exact opposite. it's about vendor lockin and NIH.
(we'll do it OUR way because we can do it better or the 'proper' way. "so-and-so does blah, which is
choice is being able to write a script in php,perl,python,bash,csh,... on the SAME system.
because I can CHOOSE. If I have a debian box I can't choose to use RPM or ebuilds, same for those other systems.
of the systems I've used: deb, rpm, rpm5, portage, (and tarballs if you count linuxfromscratch)
and the managers I've used: yum, urpmi, smart, kpackagekit, synaptic, apt-get, emerge
each system has little features the others don't. but there is nothing that one system has that couldn't be added to the others.
The Xorg project, http://www.x.org, wants students to participate in Google Summer of Code.
Details for Xorg's projects can be found at: http://www.x.org/wiki/SummerOfCodeIdeas
More information on GSoC in general: http://www.google-melange.com/