Stuart Herbert | Gentoo

For some reason that currently eludes me, since an emerge -u world earlier in the week, my local exim MTA is bouncing all incoming email. Apologies to everyone who’s tried to reach me in the last few days, and to anyone who tries to reach me until I track down the cause and fix it.

Linux 2.6.17 kernels won’t boot from the onboard SATA controllers on VIA SP13000 boards (and, reportedly, SP8000 boards too, but I don’t own one of those to verify the problem on there). This email contains instructions on two patches that need reverting to fix the problem.

Here are some screenshots of goman - the Gentoo Overlays Manager tool that I’m currently building in PHP.

Any feedback, questions, or feature requests, please drop by in #gentoo-overlays on irc.freenode.net

It’s official. overlays.gentoo.org is no longer under wraps, and folks are now free to blog about it as much as they’d like. We’ve put out a press release, and hopefully over the next few days we’ll be getting some more PR for our new service out the door too.

Folks who deserve a big thanks are Lance from Infra, Stefan from Overlays and Sunrise, Gunnar for creating layman, and Christel from User Relations. You guys made all this possible, and you made it better than it would have been originally. A big thank you too to everyone who has already signed up for the service. I hope you’ll be the first of many many people to do so.

The big thing about o.g.o isn’t that it provides hosting for overlays on Gentoo infrastructure. That’s nice, don’t get me wrong, but it’s not the point of the project. o.g.o is the place where Gentoo developers (folks w/ the nice shiny @gentoo.org email address) and Gentoo users (folks w/out the nice shiny @gentoo.org email address) can directly collaborate together on creating packages and documentation for Gentoo. Instead of having to wait for ages for patches to make their way from Bugzilla into the Portage tree, folks instead can ask for commit access to the relevant overlay, and under the mentoring of experienced Gentoo devs, can commit their changes directly into the overlay. This has a profound effect on users who get involved, because for the first time they really are involved in creating packages for Gentoo. The difference has to be seen to be believed, and if you’re a Gentoo developer struggling to recruit folks to help you with a herd of packages, you should strongly consider going down the overlays route to help you reach out to the Gentoo user community.

We’re calling these overlays social workspaces, because they bring folks from the wider Gentoo community together to work together.

It’s an exciting project, and we won’t be stopping here. We have a few little tidy-ups to do with the homepage and RSS feeds, and then it’s on to providing a choice of version control systems, and with providing a web-based control panel for folks to directly admin their own overlays.

The arch teams have been busy, marking baselayout 1.12 as stable. Unfortunately, I can’t point you at the release announcement, or an upgrade guide, as neither has been published

This release is not 100% backwards compatible. It’s expected to work for most folks, but there has been the odd problem here and there. Before upgrading, please check this tracker bug first to see the current state of things. If you come across any new problems, please add them to that bug.

And it goes without saying that, if you run Gentoo in a production environment, you should first test any upgrade (especially one like this!) on a test box first.

I’m working on a web-based control panel for Gentoo Overlays, so that users can do things like change their passwords, and overlay owners can do things like manage who can do what to their overlay. It’ll stop my Overlays admin team being a bottleneck for run-of-the-mill stuff, which should help us provide a high-quality and responsive service.

Step 1 is to get a PHP5 app working that manages data about users and overlays in an SQLite3 database. That’s coming along nicely, and should be complete during the coming week.

stuart@belal /var/www/localhost/htdocs/goman $ wc -l `find . -name '*.php'`
   25 ./index.php
   36 ./logout.php
   76 ./createOverlay.php
   75 ./changePassword.php
   55 ./yourPanel.php
   71 ./changeEmail.php
   63 ./login.php
  114 ./createUser.php
   68 ./classes/FormMessages.class.php
   97 ./classes/UserCookie.class.php
   43 ./classes/OverlayRole.class.php
   47 ./classes/UserTypeBehaviour.class.php
   61 ./classes/UserRecord.class.php
   27 ./classes/OverlayUrlBehaviour.class.php
   44 ./classes/OverlayRecord.class.php
   56 ./common.php
   14 ./snippets/userCreated.page.php
   42 ./snippets/createOverlay.form.php
   30 ./snippets/login.form.php
   29 ./snippets/changeEmail.form.php
   57 ./snippets/createUser.form.php
   14 ./snippets/emailChanged.page.php
   14 ./snippets/passwordChanged.page.php
   31 ./snippets/changePassword.form.php
   64 ./snippets/controlPanel.page.php
 1253 total

This is my first project working with SQLite3, and my feelings about it are mixed. On the positive side, it’s well suited to the size of data that we’re going to be managing, and to the amount of use that Goman is going to get. Infra don’t like requests for MySQL databases, so SQLite3 fits well with them too.

On the downside, SQLite3’s ALTER TABLE statement can’t be used to change the design of a table. You can work around it by creating a new SQLite3 database with the new schema, and then writing a single script to migrate the data from the old database to the new one, but it quickly becomes tiresome during development, when you’re constantly evolving the schema.

The other negative for me is that PHP’s SQLite3 driver is a PDO driver. I recently investigated a PDO segfault, which led me to raise concerns about how PDO is currently implemented under the bonnet. It should be safe on o.g.o, if for no other reason that we regularly restart Apache on there anyway to force Trac to pick up configuration changes.

Tomorrow’s job is to test the existing forms with the Nokia N770 tablet, and make sure they work with it too. I’ll try and find the time later this week to post my first impressions of the Nokia N770; it’s an interesting toy to be sure.

Chris, you’re completely missing the point about objects and PHP.

Classes and inheritence are not new to PHP 5; PHP has had these for many many years now. PHP 5 brings with it new features, such as interfaces, class constants, and access controls (although it’s still got a ways to go to catch up with both Python and Ruby). It also changes the semantics of objects; in PHP 4, objects are passed by copy, but in PHP 5, objects are passed by handle.

You can - and plenty of folks do - write object-oriented code in PHP 4 just fine.

PHP’s runtime behaviour - that each page starts afresh - is one of PHP’s killer features. You’ve obviously got no idea about just what a difference it makes. Every time your script runs, you’re guaranteed to start with a clean slate. The only state you have to worry about is the state you’ve stored for yourself. This simplicity makes it almost trivial to create deterministic code, without which you cannot produce high-quality code.

Managing state between pages is very straight forward in PHP. If the state matters only for the user’s current visit, put it in the session. If you need state to persist between visits, or it is information that other visitors need, put it in a persistent datastore (such as a database). Use a local cache (files on disk, memcached) to reduce the amount of time you have to get state from the persistent datastore. That’s the PHP way.

Folks who follow design patterns religiously are missing the point. They’re not hard and fast rules (that way lies Java, and its hideous and pointless complexity); they’re guidelines, meant to make you think about the natural structures that arise in your code. They’re not meant to be a cult. Anyone tells you different, they haven’t read enough Suzuki. When all you have is a hammer (or a set of design patterns), everything starts to look like a nail.

And that’s the beauty of PHP over many of the other tools that you have. If you want to write a system that’s entirely object-oriented, you can. But you don’t have to. You can create and use objects where they make sense, and you can continue to use global functions where they make sense. PHP’s neutral philosophy gives you the freedom to just get on with it, and do what’s right for your needs, your skills, and your tastes.

Donnie, what’s stopping you having both X.org 7.0 and X.org 7.1 stable at the same time on x86? Is it possible to craft the ebuilds so that, if you choose the opensource drivers, Portage will let you have X.org 7.1, but if you choose the binary drivers, Portage will block any attempts to go beyond X.org 7.0? That’ll allow us to support both types of driver for now.

Instead of the current black and white approach, maybe it’s time for a two-speed approach instead?

I can’t speak for anyone else, but whilst I’ve found the opensource ATI driver fine for your run-of-the-mill 2D GNOME desktop (provided you don’t mind the lack of power management support!), the lack of 3D support limits my use of Linux. This is with a Radeon 9600 M10 card - an obsolete graphics cards from several years ago. I’d love to see ATI and nVidia open their drivers, but until they do, I’ll be a user of the binary drivers as long as they offer features that I need, and that I can’t get from the opensource drivers.

So, c’mon Greg, stop fucking about beating up distros, and go after ATI and nVidia directly. In the Windows world, users are already well-trained in downloading binary drivers from ATI and nVidia. There’s no reason to believe that the same behaviour won’t become the norm in the Linux world (if it hasn’t already). The only way you’re going to put a stop to it is to get ATI and nVidia to honour the GPL by releasing their code. Stopping binary drivers being included in distros won’t win the battle. Folks’ll just download the easy-to-install binary drivers directly from ATI and nVidia instead, and it’ll be in ATI and nVidia’s interest to make them easy to install.

If you’re right in your assertion that binary drivers are illegal, put ATI and nVidia directly in the dock. Enforce the GPL against the source of your problem - the folks making the binary drivers.