Bobulate
Home [ade] cookies
Long-term Management
February 3rd, 2011
My friend Armijn sent me this, and asked if I would pass it on. He adds as a word of warning “this is a post that can easily ruin your mood“. I’m posting it here as well as on my new blog, as its theme is the future.
Almost all free software developers I have met are always very enthusiastic about their programs and what to add and improve in the future. Very few of them think what happens afterwards. With this I don’t mean what happens after those additions and improvements (your answer would probably be “more additions and improvements”), but I mean when there is no future. When you’re no longer coding. When your uplink is permanently disconnected. When you’re dead.
Planning for the inevitable is not something we want to think about (thinking about your own mortality is not many people do for fun), but it is something we need to do, all of us. I was remembered about this by two recent events. One was when at gpl-violations.org we got a report about a violation in the Apple AppStore. Since I had already dealt with the same developer in the past (it was resolved very amicably) I decided to connect the reporter directly with the developer. The reporter got an unexpected surprise in the form of an e-mail from the developer’s father who said that his son had died half a year ago and he could not get himself to pull the app from the App Store, as a tribute to his son. Eventually we got sources when one of the developer’s friends (another engineer) was involved to lift the sources from the deceased developer’s laptop.
Another example was when a webmaster of a website that my dad regularly contributed to, died in a fire in his house. The website contained many years of research, at least 10 years, but possibly many more. Many people had contributed to this research, but the data was only available through the website. The database itself was hosted on baseportal.com which allows people to have a free database. How to get the data back, especially someone else’s data is completely unclear. At the moment people are trying to reach the heirs of the webmaster so they can salvage the data and make sure the webpage continues as a tribute to the original webmaster.
The common theme is that these people were very passionate about what they did. They truly loved their work and it work was appreciated by many. But when fate struck it turned out that they had not taken care of what would happen after they would pass away. I am very sure that they didn’t expect this to happen so soon, or never realized that this could be an issue. But in the digital world, with lapsing domain name registrations, databases and webspace being deleted because of unpaid bills, offline development trees and uninformed heirs this is becoming more and more of a risk.
So, what can you do prevent this from happening with your code and data? First, move your development as much online as possible. The KDE project has great infrastructure for this. Second, think about assigning your copyright to KDE e.V. with the FLA. If you don’t want to do this, make sure that your heirs know what you have been doing with free software and what they can and cannot do with the code. Show them that you care a lot about this.
Don’t let this story scare you too much. Keep coding, with passion, knowing that if you have taken the right measures your code will live on and will (hopefully) be used, reused and adapted by many people, even after you are no longer here.
— Armijn
(As a closing note, the FLA that KDE e.V. uses was developed by the FSFE.)
Blog moving
February 2nd, 2011
I’m moving my blog from the Fellowship of FSFE setup to my own hosting, over at http://euroquis.nl/bobulate/. This is the penultimate post on this particular incarnation of bobulate (a name that travels from blog installation to blog installation, for five years now).
Newer OSOL packages
January 10th, 2011
KDE 4.5.4 (why wasn’t that codenamed "pound" or such?) was released some time ago, so there’s updated OpenIndiana packages available. You can find them at the KDE 4.5 package repository. The naming is now deceptive: it’s KDE 4.5.4 in the 4.5.3 repo. Use specific FMRIs if you want to stick to the previous version. Only KDE packages were updated, so all the dependencies stay the same.
We have decided to drop OpenSolaris build 134 as a target. You can use these packages on OpenIndiana build 147 or later or Oracle Solaris Express build 151a. Maintaining compatibility with the older OSOL was increasing the complexity of building packages, putting our resources under strain. So we dropped it. We’re also still on the fence regarding Solaris 10 — no one seems to want it, which means that it may be swept under the rug sometime as well.
Change of direction
January 9th, 2011
I see it’s been about six weeks since I last wrote something – anything – on my blog. Since then we’ve had Sinterklaas, Christmas, New Year’s, I’ve baked a variety of things that might have spiced up various tech articles, there have been interesting patent issues, etc. etc. My mind hasn’t really been on writing about that kind of stuff. My brother was over from Ethiopia, so I now have a fine assortment of spices and an Amharic cheat-sheet. Good holiday-season topics, but not something to bother Planet KDE (or other aggregations) with.
Allen kept reminding me of some sysadmin-ish things I needed to do with the EBN, so that finally was fixed, and now it has some useful DNS aliases as well. There was some occasional KDE e.V. work. didn’t get as much done there as I might have wanted — there’s the Sprints web-app and Sprints wiki pages update to go as well as the KDE e.V. website to clean up.
Anyway, time to wake up. December 1st I started a new job in a non-KDE programming position; I hack Python and documentation now. It’s for a non-profit association and development is Open-Source-ish — association members have SVN access, for instance. There’s some new sysadminning things to learn (like runnning Edgewall’s Trac) and I have many reasons to be thankful for today’s KDE 4.5.4 on Windows release. So far I’ve been using VMWare Player to avoid a good deal of pain — suffice to say that KMail on the desktop kicks Outlook squarely in the nadgers (a range of mountains near the Hub).
I’ve gotten used to the commute, reading the papers on the way out and using my n900 to catch up on KDE news on the way home in the evenings. What I do miss is a good WordPress blogging client on the phone (e.g. Blogilo). A nice Trac client would be a bonus, too. Maybe I will get into mobile apps development with Qt.
Asking for Hardware
November 29th, 2010
Last week I tried to ask for hardware — 1GB ECC PC-2700 DIMMs, to be exact — and got no response, while Aaron didn’t call for hardware and got a bunch of offers to buy monitors and such.
Now, Aaron has since explained that the problem holding back the resolution of the bug that triggered his "donation drive" isn’t a lack of hardware, but a lack of a specific setup and workflow. And it looks like the resolution of the bug has been attempted. Pretty cool stuff — but it’s not the bug resolution that I’d like to write about here.
First off, a "hardware pool" for KDE developers has been tried before. Several years ago (I tihnk it was) Scott Wheeler tried to set one up. The idea would be that spare hardware would get passed around or sent to KDE developers who needed something extra. The idea never took off, and eventually the plan shut down. There were three reasons for this, basically:
- Sending hardware around is really darn expensive. By the time you’ve covered postage and insurance, it can be nearly as expensive as just buying something locally. So it’s expensive to send stuff.
- Customs are a nightmare. Switserland doubly so. I remember long ago someone sent me a spare Palm Vx from the US. It was a used device, and the Vx at that point was already no longer on the market here. Dutch customs assessed me around 50 EUR in import duty. So it’s expensive to receive stuff.
- There are remarkably few hardware requests. Apparently KDE developers work within the constraints of what they have, rather than what they would like. A few times I’ve blogged about left-over hardware that I would give away (in spite of points 1 and 2) and got no response. Maybe my leftover hardware (usually around 3 years old) is just too crappy even to give away.
There are a few exceptions to #3. There was a donation drive to get Krita developers some specific hardware. Maemo devices have been distributed to the KDE community at various events in order to drive enthusiasm and interest for the devices. Those are unusual cases, though.
Now, there is an organization that can help with hardware needs. It’s KDE e.V. The association’s mandate is to support the community. That includes providing hardware if needed. Let’s look at this from two sides:
For the potential hardware donor, KDE e.V. accepts donations in cash (tax-deductible in Germany) and in special cases could receive hardware, too. There are two ways to help KDE e.V. You could donate directly to KDE e.V. and add a note describing what the donation is for. (For legal and tax reasons there is no guarantee that the donation will be used as requested) You could also join the game and systematically support KDE e.V. in its work. Resources that KDE e.V. gathers (e.g. money) are put to work supporting the community. That is usually in the form of travel and lodging for events and workshops, but could cover other forms of support as well.
For the potential hardware recipient there are standard procedures for requesting support. There are forms on the KDE e.V. website. If you need something special (e.g. a second video card and a monitor) then you can ask the board beforehand if that falls within the mandate and if so, request reimbursement afterwards. As a general rule, I think that peculiar or special hardware has a better chance of being supported than general upgrades and hardware requests with a strong and specific KDE purpose are more likely to go through, too. Ask first.
So yeah, if you need a bi-polar defrobnicator to bobulate your Plasma widgets, then by all means do two things: ask if KDE e.V. will help you out there, then blog that you need such a thing and encourage people to donate to KDE e.V. for one. Then wait, buy the stuff yourself, and do cool things.
As far as my desire for more memory for my SPARC workstation for KDE package builds on that platform, well, I think the board of KDE e.V. (myself included!) would answer "too niche, too expensive for the projected benefit of all two KDE4-on-SPARC users."
Bun in the oven
November 26th, 2010
It’s nearly December, which means that Sinterklaas is on his way in the Netherlands. During the recent board meeting it took quite some time to explain to Celeste how Sint works. One good resource is the Sinterklaasjournaal. It’s basically the evening news — produced by the same crew and hosted by Dieuwertje Blok, who was the national news anchor in the lates ’80s — related to Sinterklaas.
Anyway, the kids are big into Sinterklaas, and dutifully set out their shoes when the time comes. Here’s the kids (six and seven years old) after setting out their shoes, complete with a drawing for Sint and Piet and a carrot for the horse. The next morning they had both received a letter of their name in bread; see here Amiel’s initial. You will notice the bite out of the upper right — that’s because this year there is a Baby Piet who is taking bites out of all the candy being made in the candy factory in Harderwijk.
Yes, this is madness, but it’s the best kind of madness. No worse than late-friday-afternoon wrestling with the KDE e.V. website or policy documents.
The bun in the oven is a whole-wheat-and-sesame loaf, actually.
KDE 4.6.0-beta1 packages available for OpenSolaris, OpenIndiana
November 25th, 2010
The first beta of KDE 4.6.0 has rolled around, pretty much on schedule. In the KDE4-OpenSolaris community we’ve been following closely, building trunk as much as possible and upstreaming those patches that make sense. So we’re happy to announce that for the first time there are 0-day packages available for OpenSolaris-type systems using Sun Studio (I’ve got to add that last proviso because the Belenix guys do a good job of producing packages with gcc).
The packages can be had from the 4.6.0 package repository and include Plasma Desktop Workspace, KDE sdk, Konversation and Amarok along with a bunch of other things. There’s no KDE PIM, edu or KOffice because of various compilation problems that we have not yet been able to solve or functionality issues (e.g. KMail crashes in all of its GPG handling in a way that makes me suspect a compiler bug, but I haven’t been able to track it down well enough yet). The specfiles repository from which these packages are built is available too.
Supported Platforms: the packages are currently available for x86 only. In a poll we did some time ago there was little enthusiasm for specific 64-bit packages, so we have not been building them. Anyway, the Solaris kernel can mix-and-match 32- and 64-bit applications and libraries, so there’s not much lost. There’s no SPARC packages, in spite of some recent success in getting things to build. Here’s the list of supported platforms:
- OpenSolaris build 134, x86 Edit: while the repo should build on 134, these packages will not install there because dependency names have changed.
- OpenIndiana build 147, x86
Just those two, hunh. Later builds of either should work, but have not been tested. Oracle Solaris Express 2010.11 should work (it names itself build 151) but has not been tested. Solaris 10 is not supported, as it uses a different packaging system and needs lots of other updated software.
How to get it: set your kdeips-dev publisher to the new repository URL, refresh and install. Something like this should do:
pfexec pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.6.0/ kdeips-dev
pfexec pkg refresh
pfexec pkg install KDEbase-apps
PS. I’d like to welcome Onno Molenkamp to the fold. He’s been doing 64-bit builds for us and tackling some long-standing annoyances (in Virtuoso and Qt) that make the build less pleasant than it might. The #kde4-solaris channel now has random bits of Dutch on it, too.
PPS. KDE4-OpenSolaris acts as an "upstream" for OpenIndiana. We’re "downstream" from the work done by the KDE community, and massage the code a little and send it off again. There is plenty of scope for cooperation, and we’ve seen recent conversations about having various parties interested in stuff to work together more effectively. (Here "stuff" is Qt and KDE frameworks as well as KDE applications and Plasma workspaces).
PPPS. Solaris 10 isn’t dead as far as we are concerned, just very much unsupported and uninteresting as a target (even if it has a decent installed base of corporate use). Some people try building our specs every now and then and we do try to avoid actively breaking stuff for S10.
PPPPS. We know not all of our patches are acceptable for upstreaming. Some actively break stuff for other systems. Those are the kind that don’t go anywhere else. Sometimes we massage things until they are acceptable. It’s a bit of a trade-off. A shout-out to the author of Sentinella, Carlos Olmedo Escobar, for contacting me about the Solaris packaging we’ve tried to do and the patches that required. I hope to have Sentinella running on OpenSolaris pretty soon.
Futile? Yes, but not pointless (Qt 4.7.1 on SPARC)
November 22nd, 2010
I feel so conflicted. Just look at that screenshot.
Qt 4.7.1 demo browser running in GNOME, on Oracle Solaris, on SPARCv9
I was considering starting this blog post in a mad-scientist fashion, “mad, was I? they said I was mad to try! haha! and now I shall unleash my creation upon the world and show them all! hahaha!” but I’ve probably done that before. So what you see there in the screenie is probably the first WebKit browser running on Solaris on SPARCv9 hardware. It is the demo browser from Qt 4.7.1. Compiling Qt took just under six hours, I think, but I went shopping in the meantime.
So this is ultimately futile: SPARC hardware just doesn’t get used for the desktop, does it. However, the KDE4-OpenSolaris has had requests from various folks about Qt on SPARC, built with our optimizations and with the Sun Studio compiler. So now it’s here. That is to say, it compiles and some bits run. We still need to figure out how to merge packages so that the IPS repository will spit out a suitable Qt package (either x86 or SPARC). The pkg(5) and pkg.depotd(5) programs know how to handle multiple architectures, I just don’t know how to move the files around to achieve that.
But this exercise isn’t pointless. It shows up how portable Qt is (within the X11 world, anyway). It shows that the packaging setup that the KDE4-OpenSolaris group has set up actually targets the things we said we wanted to hit (which, even after revising away Solaris 10, still includes SPARC). It might help a teensy bit with code quality to consider the warnings a different compiler throws out — although stuff like "textedit.cpp", line 154: Warning: tb hides TextEdit::tb. isn’t useful in my book.
Another thing this experiment shows is that there is more work to be done in catching CStd-based firefox plugins. The Qt demo browser cheerfully tries to load the flash plugin and then falls over because of bad library initialization (when mixing different STLs, see this post of mine for some details) if there’s any interesting media on the page. In the screenshot, we see www.kde.org, which doesn’t do anything fancy.
So there you go. One more platform Konquered (er .. it’ll take another week to get through to KDEbase).
An exercise in futility (nv151 on Ultra 45 with XVR-2500)
November 21st, 2010
Oracle has released Solaris Express 11. That’s a binary-only preview of Solaris 11, which picks up somewhere after OpenSolaris was killed. The kernel identifies itself as snv_151a. As an exercise in futility, I decided to install this on my Sun Ultra 45 workstation — a SPARC machine. Of course I’ll be doing so only to evaluate the software I am creating (or packaging) for the Operating System, not putting the machine into production use — which is what the onerous license agreement (it’s even difficult to find the URL to link to!) demands.
I have a SPARC-based workstation under my desk, from the time that we in the KDE4-Solaris project actively targeted SPARC; that’s some time ago. The machine is still there and I like the architecture, so I try to use it every now and then. With OSOL this was always problematic. Solaris 11 seems to change that a little.
Solaris 11 comes with a text-based installer for SPARC, which is good enough. It doesn’t seem to come with a graphics driver for the XVR-2500 card that’s in the workstation, though, as the boot process tells me that the pciegfx domain will not be used.
For me it was a little confusing that some GNOME packages were installed — like gnome-audio — but no X server or display manager. Text logins are fine, but in order to test my software at some point I’m going to have to actually run X on it. Given the speed at which this machine compiles (random hardware begging: anyone have 2x1GB DDR PC2700 ECC DIMMs left over? Or four of them, for that matter? How about an UltraSPARC IIIi CPU @1.6GHz?) I’ll be happy to get through to Qt sometime in the next seven days. And let’s face it, Qt 4.7 keeps trying to outsmart the KDE4-OpenSolaris team by saying that it’s partly incompatible with Sun compilers — but in the case of Sun Studio 12 on SPARC it might be right 🙂
Turning the SPARC machine into a usable GNOME box took steps like these:
pkg install xorg evince gnome-terminal gdm
pkg install xorg-video kfb xorg-kfb fbconfig-kfb
pkg uninstall xorg-video xorg-video-wsfb
That last uninstall was to get rid of the wsfb driver which crashes Xorg. After mucking about a bit I got some advice on IRC, from the indomitable Alan Coopersmith in particular. You can find some of his work (newer Xorg) on the OpenSolaris forums. So two essential things: "fbconfig -dev kfb0 -defaults" and "pkg install slim_install", then reboot. So thanks, Alan.
The machine will come back but still be in text mode. SSH is enabled by default, so you can SSH in from another machine on the network and start the gdm service to get a login prompt. with “svcadm enable svc:/application/graphical-login/gdm:default“. If you watch the console, after about 15 seconds you get a gdm login screen. On the one hand, it’s tastefully done with some transparency applied around the session and language selectors; on the other hand there’s this giant Oracle logo on there like “abandon all hope ye who enter here.” And a kind of icky hex grid background and default wallpaper, as if drone-like creatures are going to lay their proprietary eggs in your brain and cause you to surrender your will. Ugh.
Why does the Oracle logo look so out of place on a GNOME desktop where the OpenSolaris one didn’t? Seems strange to me.
Anyway, it seems that Oracle have delivered a technically sufficient OS release for SPARC workstations. I can start compiling stuff on it now (some setup scripts will surely be added to the -460 repo as I carry on with that). Making a SPARC machine a usable development workstation takes another whole bunch of packages, just some of which are the Mercurial and the C++ compiler (you could choose gcc instead, but that’s not the mandate of the KDE4-OpenSolaris project). The Sun compiler is not available from the Solaris 11 package repository right now, so get it from the older OSOL repo:
pkg install mercurial
pkg set-publisher --non-sticky \
-g http://pkg.opensolaris.org/release/ opensolaris.org
pkg install sunstudio12u1
Fight the wall of text!
November 19th, 2010
Dion Moult has just called for people to help out with fighting the wall of text that is www.kde.org. I just started with ev.kde.org for somewhat the same reasons. The KDE e.V. website explains what the e.V. does. You can find blog items about KDE e.V. here and there — for instance, from Sebas regarding the recent board meeting or the previous meeting in may, or from myself on the november meeting or regarding the -vorstand list or mentioning it in passing around Akademy. And our president, Cornelius Schumacher, wrote a nice what-is-KDE entry in October of this year. Frank and Celeste don’t tend to write about KDE e.V. business as far as I know, but I’m tired of searching right now.
So every now and then we try to explain what KDE e.V. is, what it does, how it’s run and what the KDE community can expect from it and how the KDE e.V. membership can contribute to the success of the association. I often liken KDE e.V. to a city’s amateur soccer association. You can play soccer without being a member, but if you want to support soccer in the city in a general fashion — for instance lobbying to make sure that the city keeps playing fields accessible — then being part of the association becomes important.
Anyway, that kind of stuff needs to be on the KDE e.V. website without being a wall of text.
The KDE e.V. website has an additional challenge right now: it switched its look from the older KDE 4.0 look to the latest "Chihuahua" technology produced by the KDE web-team. It looks much nicer now — even if it is width-limited to 800px. However, navigation has suffered because the e.V. site has a bunch of specific documents that are most useful, together with a deeper tree of stuff.
I have started by adding a "quick links" box to the front page, pointing to specific contact information, members and the most interesting forms and events things. Note that we don’t have a really good setup for the forms and events right now, that’s something to be partly automated and generally improved in the next weeks.
What I’m looking for is people who will go over the e.V. site checking links, double-checking texts, pointing out ambiguities and missing information, suggesting navigation improvements etc. etc. Throw stuff in the comments on this blog or send them to kde-ev-board (in the domain of KDE). Most important though is probably getting some nice graphics for various bits and pieces. I’d like the quick links box to have some cutesy icons (Eugene, this means you!). Some identifying graphics elsewhere as we run into identified needs. Perhaps a little CSS spice here and there.
The KDE www team lives in #kde-www on Freenode, and the KDE e.V. website lives in /home/kde/trunk/www/sites/kde-ev on KDE’s SVN server.