Seth Nickell

Graydon’s c#/java post, I think rightfully, mostly concludes that Java and C# are more or less same-ish. Dare’s C# for Java programmers document, which Miguel linked to as a more rigorous technical comparison, says roughly the same thing in its “Conclusion” section. I’d paraphrase it roughly as “Java programmers will probably find that C# has more nice extras available than vice versa. Java and C# are similar enough though that useful code has been, and probably will continue to be continue to be ported back and forth between them.“.

Looking through that (old) list of things C# has that Java doesn’t, most of the major ones are now present in Java 5: varargs, generics, foreach, metadata. Most of the rest of them are things that are arguable back and forth as to whether they’re a good idea (I hope everyone learned from C++ that more features != better) such as having a pre-processor. Delegates and Structs stand out as exceptions to this. Structs can, I think, be argued back and forth. Java is in certain ways more determinedly high level than C#, this would be an example of that (not exposing a distinction between stack adn heap). But, on the whole, there have been enough cases where I really do damn well want to allocate things quickly on the heap that this feature seems to be a win for C#. Delegates are quite a bit cleaner than the equivalent Java idiom and very nice. But neither of these is world changing features. Really.

On the flip-side Java has checked and unchecked exceptions. It was an intentional language decision to not include these in C#, I’m sure (just as, say, not including pre-processor in Java was almost certainely discussed and rejected). Some people hate having to catch all the exceptions. Personally, I think it makes code better. I’d trade structs for Java’s declared exceptions any day (perhaps not for delgates through). Java can also, e.g. dynamically instantiate classes from byte streams. But who really cares?

Probably the most practically important difference doesn’t seem to be mentioned in Dare’s analysis, which is the ease with which Mono code will be able to avail of existing C libraries. I think this is very important, and shame on Sun for making this such a PITA with JNI. Unlike this and that language construct I think this will have significant impact on how the language is actually used.

Java and C# remain the most similar major languages evar (that I know of at least). C# is pretty damn clearly an iteration of Java. Its a good improvement, and in turn Java picked up a number of the best improvements and integrated them into its next release. But the differences are not earth shaking.

My personal suspicion is that Eclipse makes a bigger difference (both in terms of productivity and in terms of how clean the codebase is since it makes all sorts of refactoring so easy) than the language construct differences. But then, I am a known IDE junkie.

Oh, I should add that Miguel is absolutely right that JDK 5 has not been replicated in the free software context, and, IMO, shame on the classpath developers for that being true. It was clear which of the JSR bits would be included in JDK 5 long before it was released. ecj, Eclipse’s built in Java compiler which we’ve now extracted as a standalone thing does support JDK 5 stuff, but the class libraries still need to be genericized and such. So you can already do varargs and stuff like that. The main thing that’s missing from the free java stack right now, wrt to JDK 5, is that the standard libraries don’t come in genericized versions so you can’t do List yet. That’s pretty important obviously, though you can write your own genericized classes already.

As I mentioned, there’s a lot of stuff we’re still working on wrt to blogs.gnome.org.

• One obvious issue is that individual entries, when linked to, don’t show up with the general theme. Also, the blog links to itself in non-”portal” mode by default so it looks like this rather than this.
• There’s no preview button on the “post to blog” page.
• The themes aren’t quite as nice as we’d like them to be and have some annoying bugs (like, try hovering over a link that’s already been clicked on, and it goes bold reflowing the text).
• Image posting from gnome blog. This would be cool.

jrb added blogs.g.o support to gnome blog so I’ll be doing a release of that pretty soon.

Its been a long time coming, but we’re happy to announce a standard site-wide mechanism for hosting your blog on gnome.org. We’re using the excellent NewsBruiser blog software. blogs.gnome.org comes in three delicious flavors, with more to come. You can also design your own template and CSS rather than using one of our stock themes.

Autumn
Black and White
Blue and Green

If you’re currently hosting your blog on gnome.org using software installed in your user account (such as pyblosxom), we would strongly encourage you to move your blog over. Its very easy to import an existing blog, and it will reduce the opportunities for gnome.org to be craxzor3d.

1. Who can get one? Anyone with a GNOME cvs account can request a blog.
2. Why does blogs.gnome.org redirect to planet.gnome.org? Individual’s blogs can be found at http://blogs.gnome.org/username . We decided not to provide an aggregator for blogs.gnome.org blogs since its pretty much an arbitrary set (unlike planet gnome which in theory aggregates the most interesting gnome related blogs).
3. _______ doesn’t work Please e-mail seth@gnome.org and jrb@redhat.com or talk to us on IRC.
4. Why’d you use NewsBruiser?

   NewsBruiser is a bit of a dark horse, but it matched our needs most closely:

   • Supports multi-user site installs
   • Is straightforward and focused on letting people write and read blog entries
   • Makes it very easy to import entries from an existing blog (it has a few different types of importer, including a bloxsom importer, but we’ve found the RSS importer works best and should work with the most blogs)
   • Has a reasonable web-based per user setting system
   • Can be arbitrarily themed / templated by users, but also allows for stock site-wide themes
   • Has a web form for posting entries
   • Supports MetaWeblog for posting entries using tools like gnome blog
   • Is written in a language we can reasonably extend and maintain ourselves, if necessary (Python)
   • Has a helpful and responsive maintainer
   • Did not require per-user SQL accounts (NB doesn’t use SQL at all)
   • Stores blogs in a simple format so we aren’t necessarily tied to the software, say, 4 years down the road (NB also allows users to download all their entries as a tarball w/o sysadmin intervention, a nice bonus)

   Actually, if you look through this list its not a particularly exotic list of features, and its really a shame that given how much blog software has been written NewsBruiser is the only one (we could find) that supports these features.

Getting a blogs.gnome.org account

1. In the next week or so, just pester either jrb or I on IRC (or by e-mail, though I personally prefer IRC). We’ll need your gnome.org username. Long term, people can email accounts@gnome.org instead. Anyone with a CVS account can request a blog.
2. Visit http://blogs.gnome.org/yourusername and login using the password we provide to you.
3. Click import to import from an existing blog (if you have one). We’ve found the RSS importer to work best.
4. Click configure (should be one of the links replacing the login box after you’ve logged in).
5. Setup your blog information on the first page. We recommend you use your name for the “Notebook Title” so that its easy for people to tell who’s blog they’re reading. Click the submit button at the bottom of the page when you’re done.
6. You can change the theme (or define your own theme/template using the “no theme” option) from the “Look and Feel” configuration page.

Post

Its rough, its dirty, its still pretty cool. Diana and I originally put together a mockup for the RH blog aggregator, to replace the existing monstrosity:

It sounds like the RH blog aggregator will be moving to Planet soon anyway, so I thought I’d get an early start on the template/CSS munging. And since I was already doing it for Planet, I figured, why not take a whirl at the Planet I know and love?

Here’s Planet Gnome with the new template/css. Obviously I’m not running the planet.py updater periodically, so its fixed where I left it last night. Lots of little cleanups left to do, like using day names instead of dates, hardcoding the little image sizes to improve render speed, making it work at narrower sizes, make titles link, etc. There’s also a couple visual details off relative to the mockup (some of the spacing, the blog entry titles should be darker which looks better and is easier to read). I chose the colors 10 seconds ago, so they suck

This design isn’t just purty, its designed to improve reading too.

• The primary contextual information used for orienting the conent of a blog entry is “who”. I think most regular readers are picking up the “who” from photos, so those are visually distinct off to the left.
• The name and face are also grouped closely together, which should help people build the association.
• Your eye can skim down the un-noisy left hand side (also note that we break days using a color band with the day name, so the lightly coloured bar at the left is basically the orientation/skimming bar) to find entries
• Once you’ve located the start of an entry (this isn’t just for “searching” through the page, its a frequent orientation procedure while you read), your eye shifts over to the text in a familiar left-to-right reading direction (compare with the existing layout where people’s eyes tend to try and scan on the right which is mixed with noisy text, then once they are oriented/context loaded as to the person, have to scan left and find the start of the text line to read… the little bits of extra work add up :-).
• Most of the white on the page is inside the actual blog entry content boxes (in the word balloons). Restricting white like this draws your eye into the boxes. This reduces some of the visual overload problems in the existing pgo (its even worse in the RH blog aggregator right now). In other words, the layout draws your eye into the text, which is what the blog is really about, and also keeps the amount of text from seeming overwhelming (which is what “wandering eye with no strong visual reference” tends to do to people). The existing pgo has a strong wandering eye effect, which seriously discourages people from actually reading, whereas if the text seems more managable people are more likely to dive in.
• I think the titles of blog entries are usually useless, so I almost dropped them altogether, but didn’t, as you can tell.
• We avoided strong visual lines and dividers to make it easier to pleasantly “read through” the whole page. Lines get in the way of your eye, so they should only be used when you actually want to disrupt or control the eye’s flow.
• As far as high level design goals, I think the “word balloon” increases the feeling of attribution. Its suggestive that there’s a real person saying these things. I think its less of an issue for pgo, but for Red Hat that both improves the humanness of the blogs (the main reason companies are starting to have them, I think), and it makes it clear that the statements are individual opinions. Its subtle, but I think it has impact on how people interpret the information.
• The width of text is restricted. Its easier to read relatively narrow text columns.

Since he caught a glimpse of Kristian’s wobbly windows, Bryan has stalked Red Hat’s dark and hallowed halls, breathing fire, demanding his chance in the directorial seat. So it is that we bring you Monkey Hoot productions first, uh, production. Since a lot of people have asked, these videos show Luminocity running on two different laptops, both with fairly slow/old video cards (Intel i830 and ATI Radeon 7500 mobility) and open source drivers.

Luminocity

Theora | MPEG4

Kristian showing off his spring-modeled “wobbly windows” effect in Luminocity,Owen’s crack-tastic OpenGL based window/compositing manager. This is the only effect that requires GL hardware acceleration in Luminocity (and not even much at that, Kristian’s development machine uses an embedded Intel video card). Notice that menus and tooltips are also animated as they pop on and off the screen. The animation effects on window impulses are implementable in a modular manner, allowing anyone to write new effects. Monkey Hoot productions would like to thank “The Blair Witch Project” for its inspirational camera work and lighting, and apologize to our viewers.

Physics Models for Window Moving

Theora | MPEG4 | MJPEG

The wobbly window effect is mildly addictive. Kristian hasn’t gotten much work done since he wrote it. He (and now I) spends all day moving windows around and watching them settle. This video shows off the motion a little better. It also demonstrates Luminocity’s live workspace switcher (aka pager) which updates in synch with the screen. We were surprised by how much more tangible windows felt when they gave a little (i.e. less than in this video) as you moved them (like a real world object). Of course, we turned the effect on “high” for this demo so it’d be very visible.

Live Updating Workspace Switcher

Theora | MPEG4 | MJPEG

The workspace switcher in luminocity is updated in-synch with the window contents. Also notice that the workspace switcher renders each window rather than just “capturing” what each workspace looks like (this can be seen in the absence of a background in the pager), allowing us to do nice UI tricks in the future. Since its just re-using the existing window textures, applying them to a new (smaller) surface, the workspace switcher has basically no performance overhead when using hardware accel (other than a few new surfaces for your graphics card to render, no biggie for the card).
Its a little hard to see in this video, but Luminocity also has a nifty workspace switching animation. It zooms out as it pans down to the next workspace and then zooms back in. Of course, since its also the compositing manager, any on screen action doesn’t freeze as you switch workplaces. Watch for this as we switch into the 3rd workspace containing an animated circle-o-icons, the icons keep spinning as you switch.

Movies Still Play as the Window is Warped

Theora | MJPEG

A GStreamer movie pipeline rendering into Luminocity. Notice that its warping the movie as it plays without slowdown (and of course, updating the workspace switcher live, which is just re-using the same GL texture rendered onto a smaller surface).

OpenGL Accelerated Alpha Compositing

Theora | MPEG4 | MJPEG
> 

> 

JPEG

Luminocity uses GL for hardware accelerated alpha compositing. It works well with software GL implementations too. Of course, since Luminocity is a technology testbed, we use it for “unfocused windows” here, probably not a very good long term use ;-). In one of his earlier demos Owen hijacked the mouse scroll wheel to control window transperancy. Bad Owen! This video also has another nice demonstration of wobbly menus. They feel really nice, though they’ll probably need to be faster in a “real world” version. The screenshot shows fdclock rendering in Luminocity. fdclock, unlike the video, actually uses a 32-bit ARGB visual to specify where (and how much) transparency it wants. No videos because our camera man is tired (you can run it yourself with “fdclock -ts”).

Border/Contents Resize Synchronization

When you resize a window inside Luminocity it doesn’t redraw the borders until the application is done redrawing the window contexnts. This means that they feel like “one piece” instead of the staggered redraw you see on traditional window managers (where the border gets ahead of the contents, and then they catch up). The effect on the perceived “reality” of windows on the screen is excellent, i.e. windows feel more like solid real objects (the same sort of improvement as double-buffering of widgets gave). It also, ironically, makes window resizing feel smoother (though each redraw is slightly slower and not progressive).

Cairo

While not as sexy as the Luminocity videos, here (finally) are screenshots of GTK+ themes rendering with Cairo enhancements. Cairo both increases the rendering quality of GTK+ widgets, and allows for widgets that scale beautifully to different sizes (of course, we also have a Cairo driven SVG renderer, knock yourself out). When you get your 600 dpi monitor, we’ll be there

Dynamic Themes - each widget unique

In my last X rendering post I discussed dynamic theme rendering, where every time a widget is rendered it looks slightly different. By writing algorithmic renders rather than fixed pixbuf based widgets, we can increase how dramatic the visual effects are without driving people nuts. For example, the tiger stripe buttons have proved very reasonable for long term use. However, any single rendering of a tiger stripe button would get old very quickly when repeated all over the screen ad nauseum. Currently visual designers are extremely restricted in what they can do without a theme being unusable. That’s largely the reason all themes look basically the same. We hope dynamic themes will allow visual designers to increase the variety of their palette without producing themes that wear quickly. Of course, its still easy to go overboard, *grin*. By providing higher level drawing primitives, Cairo makes it much easier to implement dynamic themes.

Resolution Independent Rendering

A large checkbox rendered with Cairo. This would look fantastic as a checkbox “normal size” on a next-gen 600dpi display.

Cairo makes it easy to draw well rendered custom-widgets. Here’s an example of how the GTK+ color picker looked before and after Cairo integration.

Getting Luminocity

It took me about half an hour of work (and some compiling time) to get Luminocity running using jhbuild. Eventually we’ll add a jhbuild target for compiling Luminocity. Luminocity is not intended to turn into a real world window/compositing manager. Instead, its a technology test bed. We’re trying stuff out in Luminocity and will be rolling them into Metacity (and hence stock GNOME) as they mature. Don’t expect Luminocity to have the frills and smarts you’d expect from a normal window manager. You’ll need hardware GL acceleration enabled to have wobbly windows work, though you can try the other bits of luminocity without it. Emebedded Intel video cards (which have open source DRI drivers) will work just fine. ATI and NVidia cards, of course, work even better.

This section has been superceded by the Luminocity wiki page which has simpler more up to date build instructions

1. If you have not used jhbuild, get jhbuild from Gnome CVS module ‘jhbuild’. Then run jhbuild bootstrap to compile basic tools such as autoconf and automake (just agree with its defaults).
2. Run jhbuild build xserver Xcomposite Xdamage Xrender Xext Xcursor X11 Xtst. This will build the freedesktop.org xserver, including the damage and composite extensions, and the Xephyr/Xfake nested X servers.
3. Apply a small patch that evilly hacks around some issues with DAMAGE in the X server
4. Checkout module “luminocity” from Gnome CVS.
5. With the jhbuild buildroot at the start of your PATH (so you get autoconf, automake, etc from the buildroot): from the luminocity directory run ./autogen.sh –prefix=PATH_TO_JHBUILD_TREE, then make and finally make install. Alternatively, see README.jhbuild for instructions on adding a “luminocity” target to jhbuild (eventually we should just include this in jhbuild).
6. Now to get things running. Luminocity grabs windows from an existing X server and renders them in its own GL context. This technique is not intended to be particularly efficient, but it works surprisingly well for a development testbed. We will use “Xfake” as the X server. Xfake doesn’t display windows sent to it, so they only get rendered on screen once (by luminocity). Xfake is included in the “xserver” module built by jhbuild above. If you are running at 1024×768, run jhbuild run Xfake -ac -screen 1024×3072x32 :1 to start Xfake on display :1. Basically, use XRESULTIONx(4*YRESOLUTION)x32. This is because Luminocity starts with 4 workspaces by default.
7. Now lets display something on the Xfake display. From a new window, set DISPLAY to “:1″ (e.g. export DISPLAY=:1). Then run any program you want to use, e.g. gnome-terminal. Of course, you won’t see a window since its displaying to the fake X server.
8. Start Luminocity with luminocity -f :1 PATH_TO_BACKGROUND_IMAGE. Including a background image is important since a bug in the wobbly windows rendering code causes major performance problems when the background is missing. Luminocity should now be running fullscreen, display whatever application you launched earlier (in this example, gnome-terminal). Another bug in wobbly windows increases the animation timeout every time you open a new window. This means that for every window you open, wobbly windows get jerkier and jerkier. Oops! Don’t worry, this is a silly bug and not a sign that we’re overloading your card or something.
9. Sometimes windows start with their titlebars off screen. To move them onto the screen, you’ll need to drag them while holding down the super key (if you have a Windows key on your keyboard, try this). You may have to remap your super key to make this work, esp. if you have no Windows key, e.g. xmodmap -e ‘keycode 95=Super_L’, which will then allow you to move windows by dragging them while holding down the F11 key.

If you need help, or you’re interested in contributing to Luminocity etc, you can probably find some knowledgable people on #fedora-desktop on irc.gnome.org (naturally, you don’t have to be running fedora Eventually we’ll probably have a channel for this. People to look out for are: “owen”, “ssp” (Soeren Sandmann), “krh” (Kristian Ho/gsberg) and “seth” (Though I’m just a user, *grin*).

Update: I wrote a little more explaining how Luminocity relates to xcompmgr/metacity/Xgl in another blog entry

Update: People have been asking what sort of hardware this was done on. Videos were shot on a mix of an IBM thinkpad X30 (with a paltry Intel i830 video card using open source drivers) and an IBM thinkpad T41 (with a slightly beefier but still pretty old Radeon Mobility 7500, also using open source drivers). Everything we’re doing so far is light on hardware requirements. FYI, a locking bug was introduced in Luminocity that causes wobbly windows to get increasingly jerky as more windows are opened (or if there’s no background image present, go figure!). This is not related to its CPU or graphics card use, and should be easy to fix without major codebase changes.

Update: If you’re having build problems, I’ve updated the “jhbuild” line to include more luminocity dependencies than just xserver. Also added a note about “jhbuild bootstrap” for building the initial dev environment (auto*, etc).

Update: Build section now superceded by the Luminocity Wiki page

Just created a wiki page for Luminocity with improved build instructions. Should be a lot easier now, esp. thanks to all the people who have reported problems and found solutions on #fedora-desktop. Its basically “jhbuild build xserver luminocity” at this point, except that a patch has to be applied to xserver first.

Relation to Metacity

When it has proved itself, Luminocity’s compositing manager will probably be moved into Metacity (along with any effects / extra features we consider good and stable). We originally considered doing the work in Metacity itself, but didn’t want to destabilize it until various approaches were tested. Luminocity is, effectively, a testbed for Metacity. It provides a smaller/simpler codebase to test interesting rendering code with, and means we don’t have to worry about fucking up Metacity in the process. Soeren’s computer is (as of tonight, at least, that’s the first I saw of it) running a version of Metacity that’s apparently using the compositing manager code from Luminocity to render to a GL context.

Relation to xcompmgr

Luminocity has an internal compositing manager that performs the same function as xcompmgr. The compositing manager / window manager integration allows Luminocity to do things that an individual compositing manager or window manager couldn’t. Of course, Luminocity composites using OpenGL, unlike xcompmgr. This apparently can be an upside and a downside, but I don’t know anything about it so I’ll shut my trap.

Relation to Xgl

This is the complicated one :-). I’m loathe to stick my toes in these waters because I’m the wrong person to do it, but I’m also afraid that we’re going to end up with two rendering infrastructures down the road and no clarity for application developers as to which (if either) they can use. I don’t know if that’s where we’re headed, I hope not, but I have this vague (probably, hopefully unfounded) fear… The effect will be slow adoption and general suck. I should premise this by saying that I have no direct knowledge of the Xgl codebase. I have knowledgable sources, and I know what Xgl generally is, but I haven’t personally used Xgl, let alone looked at its codebase (I’ve barely looked at the Luminocity codebase either, for that matter).

Xgl is an X server implementation that, rather than directly accessing chip specific hardware drivers, does its low-level drawing using OpenGL calls. That means Xgl is functionally equivalent to a traditional X server, it just uses a different rendering path. Put another way, Xgl is to X11 as Glitz is to Cairo: it provides the same APIs rendered in a much smarter way.

Luminocity, on the other hand, is a compositing manager / window manager fusion that composites using OpenGL. Compositing and Window managing are all about what you do with client-rendered windows. Luminocity doesn’t know what’s inside windows, and it doesn’t care. Xgl, on the other hand, I would characterize as primarily being about how the contents of windows are drawn (in this case: quickly and with less CPU load, *grin*). Xgl can do some other non-inside-window things like drop shadows, but I’m going to argue later those are mostly expedient demos of cool technology and Xgl is probably not the place we want to be doing those things long term. From the perspective that Luminocity is mostly about rendering windows and Xgl is mostly about rendering window contents, they are theoretically complimentary. At the moment, they can not be used in conjuction with one another (since they both want to directly drive the GL hardware), but they’re goals are at least compatible.

Neither Xgl nor Luminocity are complete on their own. Xgl provides an X server and requires a window manager (and a compositing manager?) (and an X server for doing GL calls into, but see below, that will hopefully cease to be an issue eventually). Luminocity provides a window manager and a compositing manager but requires an X server (currently using Xfake or Xephyr, though supposedly there’s some plan for modifying the core fd.o X server so Luminocity will work using only the host X server?). With some hand waving (in particular there’s no way to hand OpenGL textures residing in the video card between processes), perhaps we could get Xgl to render windows into textures on the video card, and then use Luminocity to figure out what do with those textures. All graphics computations are done by the card, and data flows only once to the card. Perfect! Other than those niggly make-or-break technical details

As far as I know (and I’m pretty sure of this), there is no systematic way (besides GLX inside a running XFree86 / fdo.o X server) to access the “hardware accelerated OpenGL drivers”. That means that Xgl and Luminocity are currently forced to have a traditional host X server, open a fullscreen window on the host server and draw into it using OpenGL. Both Luminocity and Xgl are premised on OpenGL as the standard API through which vendors can provide graphics hardware acceleration (as opposed to, say, RENDER).

Update: Soeren, one of our X hackers, thinks that Xgl actually includes no cross-window stuff but just uses an existing compositing manager (and of course, accelerates its rendering). In that case, the next couple paragraphs are totally unnecessary. Like I said above, I don’t know anything about the Xgl codebase.

I would not take something I say here as authoritative! My knowledge of this stuff only scratches the surface. But many people have been saying even less informed things, so I wanted to get slightly more accurate info out there (esp. on online forum comments). Enjoy

The three immediate design stakeholders in the ‘enterprise desktop’ are: end users, help desk staff, and desktop system administrators. Most design work for GNOME has gone into improving the end user experience, which is really the dominant stakeholder of those three. Some improvements aimed at end-users, like promoting preferences instead of settings you can get wrong, have also made life a little easier for help desk staff (as people are that much less likely to hose things). Recently Mark’s work on Vino has added a very large improvement for help desk staff: the ability to remotely view and operate user’s desktops (there is nothing more frustrating than blindly stepping people through computer operations over the phone).

So what about sysadmins? Sabayon is GNOME’s first major design targeted at improving the user experience for people who administer GNOME systems, and hopefully the start of an initiative toward designing for this important group of users. I’m jazzed about Sabayon as the first step toward a historic goal: GNOME as the definitive desktop management experience for sysadmins. We have a long way to go, but if there’s a hundred possible improvements to make over Windows and MacOS/X toward the end-user experience, there’s a thousand for admins. But big things start with small steps, right? I see promise for Sabayon as the ground floor of the revolution! <seth takes a deep breath and returns back to earth> In any case, whatever the future holds, this is fertile territory because the status quo is so much worse than it needs to be.

GConf, with its support for mandatory settings and system defaults, was supposed to be a big improvement for system administrators, but it ended up being something of a boondogle because the features were hard for sysadmins to use. In most cases it actually made things harder as sysadmins struggled through the giant XML files for defaults (most probably tried to edit schemas instead, which isn’t even the right thing, but its not their fault because we didn’t publicize this well). Even apart from the XML files being long and verbose, remember that most sysadmins in the world (think Windows), esp. desktop sysadmins, are not uber-leet Unix haxors who adore vi and the command-line.

Speaking of leetness, two super-leet Red Hat desktop hackers with funny accents are kicking off work on Sabayon: Mark McLoughlin (panel maintainer, etc) and Daniel Veillard (libxml & gamin maintainer). There was a tuffle over the name, but the French (what with their centuries of cultural sophistication and all) beat out the elves. As Mark explains it, DV probably just wanted to be able to say, “Hello I’m Daniel Veillard and I pronounce Sabayon ‘Sa-ba-yon’”. Our Irish hackers really are like little elves that write code. You go to bed and when you wake up in morning a bunch of code has magically appeared. In retaliation, I was assigned the mythical character of a “Troll” by DV, but this does not hinder my speaking the truth. I may be a troll, but I am a truthful troll. The only thing that serves to dampen Mark’s elf-nature is when he lights up like a chimney stack, strangles me with scarves, whacks me with bats, drives through red lights and otherwise engages in behavior liable to result in death. But back to Sabayon.

Humble Beginnings, What Sabayon Does Today

First and foremost, Sabayon provides a sane way to edit GConf defaults and GConf mandatory keys: the same way you edit your desktop. Sabayon launches profiles in an Xnest window. Any changes you make in the Xnest window are saved back to the profile file, which can then be applied to user’s accounts. Want to add a new applet to the panel? Right click on the panel and add one just like you usually would. Of course, you’re also free to use gconf-editor to change keys at a lower level, or download any GNOME setting tweaking program from the internet and use that. Sabayon also uses gamin to watch changes you make to the filesystem. So if you want to change the font for your users, you can drag a TTF to ~/.fonts, change it in “Font Preferences”, and voila. When you’re done making changes, you can save the profile. A change log will automatically be generated so an organization with a number of sysadmins can track down what changed when. Hopefully in the future we’ll also have revision support for desktop profiles.

Right now Sabayon has support for tracking: GConf settings, panel applet addition/removal, general files and special Firefox profile support.

The Illustrated Tour of Sabayon HEAD

1. First we launch Sabayon (if a non-root user it uses console helper to get root).
   
2. Lets create a new profile for panty-waist designers. We base it off our existing Office Desktop profile.
   
   
   
3. Sabayon starts an instance of that profile in an Xnest, including the sabayon monitor window.
   
   
4. Designers need to be coddled, we create a welcoming text file for them and save it to the desktop.
   
5. In response to saving the new text file, two new entries appear in the sabayon monitor. We don’t actually want to change the recently used list, so we tell sabayon to ignore that setting.
   
6. We drag a new Gimp launcher to the panel. Gimp is like crack for designers.
   
   
7. In response to the new launcher, sabayon monitor shows some new entries (and I have a continuity error in taking screenshots, there should still be the two items for creating the text file because we haven’t yet saved, oops). Notice that Sabayon records a “Panel object added” change rather than a dozen GConf keys being added. Sabayon can be taught to aggregate standard groups of changes together to make it clearer to admins what’s going on when they read through the change log.
   
8. Designers like pretty things, lets change the background. (As a total aside… the background capplet rewrites its GConf keys constantly a couple times a second whether they have changed or not, which makes the sabayon monitor flash a bunch in the background. The monitor has been interesting in revealing a lot of apps that are setting keys / saving settings files at weird times, which would be sucky in a networked environment)

   
   
   

9. And, as expected, the Sabayon monitor shows a bunch of GConf keys being changed. We’ve also gone ahead and checked the keys for adding the Gimp launcher to be “mandatory”. That means users that have this profile applied will be unable to remove the Gimp launcher. Unexpectedly, there’s a bunch of “.fonts.cache” files in the list too. Sabayon has a list of files and directories to ignore, but its not complete yet. For now, some operations will generate a bunch of file change noise.

   

10. If we just quit now, the all-in-one Desktop Designer.zip profile in /etc/desktop-profiles would not have been updated. If we’re happy with the changes, we can save them back to the profile.
    

11. The profile can then be distributed to computer(s) and applied to the relevant user’s homedirs. We haven’t started working on the mechanisms for this yet, Sabayon is the first piece in a bigger framework. For example, once we get the Netscape directory server code released and have a robust free ldap server, we can potentially host e.g. the GConf settings there and push to the server instead of applying bits to actual hard drives (or NFS shares).

    In the interim, the SabayonProfile class already knows how to apply profiles onto a directory. Actually, every time you edit a profile, a new temp directory is created first, and the profile is then applied to it. Consequently, it should be pretty easy for sysadmins to cook up their own python scripts using the SabayonProfile class that work on their custom systems today.

To Infinity, And Beyond!

Sabayon is just the first step in improving the manageability of GNOME. We (well, I) wanted to get something concrete landed that will help us focus on sysadmins as users, rather than designing a bunch of abstract features. It also exposes manageability features GNOME has theoretically had, but never exposed in a way people could easily exploit, which is good. I’m rambling now, again, but here are some random things markmc, dv and jdennis might be working on in the future:

• Making sabayon solid. Its still a very young project (its one month birthday is tomorrow), and is rather rough around the edges. Things are falling into place pretty quickly now, but there’s a lot of work still to go just in making the current feature set work better. Some simple improvements like expanding the “ignore changes to these directories” list will make things a lot better. We also have a number of UI features that aren’t in the current codebase.
• Supporting revision history on profiles
• Figure out how Stateless Linux (in a nutshell, where the root partition is mounted read-only and synched transparently with a central source, giving the central-state advantages of thin client with the low hardware and network infrastructure costs of cheap-intel-box thick client) and Sabayon work together. Stateless Linux makes it easier for one admin to support many machines. Sabayon (particularly sabayon of the future) will make it easier for one admin to support many users. The intersection of these two is a very nice place to be!
• We might try to figuring out a short term solution to distributing profiles to user home-directories (whether those be on an NFS share or spread across a couple dozen computer hard drives).
• A real icon and a logo, because self-respecting GNOME projects these days need kewl logos from day one. By showing the world the icon I barfed up (), Diana will be forced to make us a new icon, pronto. Designers can’t stand ugly graphics.
• Backing GConf with some sort of network store, perhaps LDAP. If we could get a drop in and run GConf server using the better-be-freed-soon netscape directory code, that would be awesome.
• Reducing the pain of panel management and upgrading by moving to a new layout/storing model where applets are either “on” or “off”. Panel cursors allow control over where applets go. This means adding/removing/changing applets in upgrades becomes possible. Currently it breaks everything, which is a management nightmare for distros, let alone the lone sysadmin
• Figuring out how to improve managebility of the Frankendesktop (word thanks to Luis). OO.o and Firefox mean that GConf support alone isn’t enough for now. But if we’re tied into supporting all these systems, we may never have the ability to do something as nice and universal as Windows group policy. So one project is to figure out if we can back OO.o and Firefox preferences using GConf. Then we can support GConf with all our heart, soul and mind in the tools and on the server.
• Extend GConf to support features that allow small numbers of admins to support hundreds or thousands of users (such as group policy). We don’t just want to copy giant technical architectures blindly, and we haven’t started looking into this design yet, so its very vague for now.

Getting Sabayon

Sabayon is a little buggy atm, but its pretty easy to get running :-). Python source is available from the sabayon module in GNOME cvs. The major dependencies are pygtk and the gamin python bindings (these are available in fedora core HEAD, but gamin-python is not in FC3, I think). I think the GConf parts will still work even if you don’t have the gamin python bindings, but YMMV. You’ll also have to paste in two one-line text files in /etc/gconf/2 as per the README, but its pretty easy.

And now for a less sexy blog post. I just sent this message to desktop-devel, but as per the message, I know many GNOME hackers no longer read lists completely, soooo….:

Revitalizing the Urban Center of GNOME

We need to get desktop-devel back to the useful hacker exchange it once was (probably only in the soft glow of memory, but hey). That means not only do GNOME enthusiasts need to be more restrained, but we (the core hacking community) need to get back on the list, start using shared channels like #gnome-hackers (even for hacker-to-hacker social purposes) again, etc.