mmazur.7thguard.net

Aw, shucks, we're blushing.

PLD will have an additional CVS repository layout that looks more or less like portage. The 'less' part is about not using gentoo's package categories (sys-devel, sys-db, etc.), however it's most likely perfectly doable, at least for the majority of our packages, to automatically fetch that metadata from gentoo, and place it somewhere. Either in a file (like 'packages/glibc/gentoo-category') or make an additional module that looks 100% like gentoo's portage tree (perfectly doable server side; we'd have 'packages' with a flat structure, that is 'packages/packagename' and, say 'portage' with portage-like structure, meaning 'portage/packagecategory/packagename'). The question is -- why? What does it give us? (Except for the coolness factor :)

One crazy idea -- create that portage tree in our cvs repo, hack the original gentoo's portage to be able to use rpmbuild instead of those ebuilds (quick dirty hack would do) and try to actually set up a pld system using gentoo's installers. Sounds cool, not that it's in any way usefull however :) Other then getting us a mention on slashdot for pulling this off probably.

Oh, and for the record -- no, it's not, and will not be possible to have, like in gentoo, more then one package of the same name, but under different categories. Both rpm internally and the way our repo is organized prevent this.

Hmm. It would however be possible to have aliases based on gentoo's group/name pairs. What would you say if poldek -i git-core was equal to poldek -i dev-util/git (-i stands for install). And same for the builder script? Considering poldek already provides a virtual filesystem, we could just expand it, so it would look something like this:

[root@klapek ~]# poldek
(...)
poldek:/all-avail> cd dev-util
poldek:/all-avail/dev-util> ls
(...)
git-1.5.0.3-2 (git-core-1.5.0.3-2)
git-1.5.1.2-1 (git-core-1.5.1.2-1)
(...)
517 packages
poldek:/all-avail>

Now that sounds both cool and potentially usefull. What'd ya think? Any other ideas?

Per Patrys' suggestion, I've generated SQL data from builder activity and he promised to generate some graphs from them. I've uploaded it -- full version since end of 2005 and a short version with data for the last two months only. I was mainly interested in the amount of time the builders are actually active and it would appear that they still have lots of processing time left and we're not bogging them down that much.

If someone's curious and willing to spend a little time on it, it's perfectly possible to retrieve some interesting stats from the data (and generate pretty graphs; maybe using Swivel). Like who's the most active sender (arekm, the release manager; sends allmost as much requests as the rest of the developers combined) by month, how many requests were sent by month, etc, etc. I haven't added any info on whether the builds were successfull and whether they resulted in a (failed) upgrade, though that's doable and I'll most likely do it some time in the future (to get some broader idea about which architectures are the most problematic, which desync most often, etc, etc.). Also would be interesting to figure out builder downtimes (shouldn't be to hard to figure out an algo; let's say no builds for more then a day or two) and also plot that.

For people wanting to actually play with the data -- builder 'th-ftp' is just a script which mails ppl when it finds there's something wrong with a package and if you want to count unique requests actually sent by people, look at 'th-src' (however by comparison with the number of requests actually processed by the binary builders, it can be clearly seen that something like 28% of sent requests fail a the source builder). And one more thing -- the i486 lacks data for the past few months. That's because it stopped sending mails for some reason and nobody bothered to fix it.

Oh and here's the "script" I've generated it with. And yes, that's shell generating python, which in turns generates sql :)

Interesting. It seems that there's some kind of an "edit war" going on over at the English Wikipedia regarding the Netlog entry. Netlog, as some people might now, is the social site known as Facebox, after having experienced some heavy rebranding a few weeks ago.

At the moment of writing, the disputed section reads as follows:

In early 2007 when registering to Facebox one was asked to provide the GMail login and password. Then Facebox downloaded the address book of the newly registered user and used it without any warning to send out invitations to all GMail's contacts, including mailing lists, and resending the invitation once a week until the victim reacted to it[3].

As a result of that policy the google search for the keyword facebox resulted in more than numerous links warning users against registering in the service[4]. It has been suggested in the blogosphere[5] that this situation was the direct reason for the rebranding on the service: Facebox became Netlog.com on April 25th, 2007.

First, for some facts. It is true, that Facebox abused the email accounts of some people subscribed to it. In early April I have suddenly received a couple of invitations from a friend of mine. Each was sent to a different email address (all of which were mine). Scratching my head for a second, I've IRCed about it only to find out, that most of the people I know got varying amounts of those invitations (the president of the Polish Linux User Group bragged about receiving as much as six invitations from a single person). Additionally, from a series of blog posts and email messages, I've learned that more people got affected by this. (One post (in English) from this guy, another from this guy, yet another from this guy, and last one from this guy.)

So, concerning the wikipedia entry in it's current form -- it should be noted, that the only reports thus far were from Poles (a limited test gone awry?). Additionally, if you want to know my opinion, the "has been suggested in the blogosphere" implication is too far fetched and should be removed. I don't think one person's entry (as cited), written in a language unknown to most readers of that wikipedia article, and without even a hint of having any insiders knowledge about the decision to rebrand, should be enough to warrant such a mention.

Other then that, the mention of the incident itself is appropriate, simply because it did happen and can probably be considered a major screwup on Facebox/Netlog's part. And if somebody's motivated enough, it'd be quite easy to collect at least half a dozen very credible reports of this, both from people that got spammed, and those in whose names the spamming was being done.

(And I'll bet Netlog's just dying for a major tech blog or news site to pick this story up and investigate a bit. I'm sure they'd start getting tons of new subscribers afterwards. :)

(You can be my valentine if you write something like this :)

Some fire... make that konqueror (I rarely use firefox) plugin that indexes (the same way google does) all of the sites I visit and allows me to do google-like searches for specific keywords, phrases and such. I'll bet the chronic bloggers would die for something like this. I would too. With the amount of material I'm reading online every day it's impossible for me to be able to find a piece I might need for whatever reason (something as simple as a quote or a link to the full article). And it's really irritating.

Dunno if current computers have enough cpu power to make this feasible without actually resorting to google. I really hope so, since the last thing I'm willing to do is give google full logs of where I've been, what I've read and how easy it is to blackmail me with those furry sites. YMMV though.

Quite recently I've stumbled across another one of the many smaller rpm based distros out there. It's not the first time I got interested in such a project and probably won't be the last, because to me they all are potential candidates for using PLD as their base. And I really think having a bunch of such projects (not PLD per se, but using our packages and at least parts of our infrastructure) would be really beneficial to both PLD and the external projects involved. Let me tell you why.

I could say that there are two main reasons for PLD being a very good base distro, one technical and the other organizational, but in reality they are really interconnected, so I'll try to cover both of them in one pass.

First thing to keep in mind is that PLD is really a lot more about technology then about providing a product. Sure, we do have something that could more or less be called a linux distribution, but on a day to day basis, most developers just view it as a place for keeping the software they use in one place and not something one treats as a whole. I assume at least some people would object, but let's face it -- our track record with regards to doing actual releases is probably worth a thousand words. PLD, being nine years, has one official release which has been abandoned ages ago, one in permanent freeze mode (we could probably advertise it as a remedy for global warming) and one in active development. Yes, we've always looked up to Debian.

Let's face it -- we're just not that good at getting our acts together and agreeing on something that could be put in a box.

This has its upsides however -- it means that the project has developed internal policies that are mostly meant to stay out of developers' ways. Otherwise, with actual releases clearly lagging, the project would collapse under it's own weight a long time ago (we did get close to that while releasing PLD 1.0, but that's a long story).

So what are those policies? Well, for the most part, there simply aren't any. There are a lot of technical things to keep in mind, best practices, kosher ways to do things 'n stuff (PLD is one of those projects that really push what rpm's capable of). But other then that, people are generally free to do whatever they want and need. Sure, there are some rules with regards to how our cvs repository is organized, but that too is rather straightforward and thought up in such a way, that the most popular types of changes aren't a pain in the ass for the developers performing them.

So how would a new project fit in? First, it'd be best for someone to talk to one of our more experienced developers (I'd be more then happy, so feel free to ping me) in order to discuss expectations and possibilities. After that it's just a matter of that developer writing a short email with a request for new developer accounts, having two other developers sign off on it (that's never a problem) and voila -- the new guys are free to start playing.

But what exactly would they be free to do?

Well, alter packages obviously. Let's say you want to build a desktop oriented distribution for home users. First thing -- they don't need stuff like openldap, mysql or postgres linked everywhere. No problem, just define appropriate global bconds (build conditionals; think USE flag from gentoo's emerge) on your build machine and build the required packages. You'll probably have to add bconds (or fix support for them) in a package or two, but generally that should be a quickie.

Ok, now for something more ambitious. PLD by default produces a shitload of subpackages for every app. Just to show you what I mean.

poldek:/ac> ls kde
Display all 716 possibilities? (y or n)

You probably don't want that in a desktop distro, since it'll just confuse users. So is there a way to somehow change this while still keeping your changes mergable with PLD? Yup. One solution -- you can create metapackages that just have a lot of Reqs on the subpackages you want. Or a more elegant approach -- using a bcond, depending on which rpmbuild will produce either a big package for, let's say, kdelibs or a multitude of subpackages (and I did test that's it's in fact possible, although I haven't seen anyone actually using this yet; see comment on pushing rpm :).

And now for something even bigger. Below is a typical way of how PLD splits libraries by default.

poldek:/th> ls libogg-*
libogg-1.1.3-2
libogg-debuginfo-1.1.3-2
libogg-devel-1.1.3-2
libogg-static-1.1.3-2

Libogg is the main stuff, debuginfo is something for gdb to munch on, devel are mostly C headers and static are static versions of a given lib (think .so vs. .a files). Confusing for our desktop users? You betcha. The same bcond rule applies here, however going through

[mmazur@klapek SPECS]$ ls|grep spec$|wc -l
11325

spec files and adding a bcond into each and every one of them probably isn't the way to go. The preferred solution here would most likely be altering rpm and it's default macros in a way that would allow for a global bcond that would work on all (well, most, some would probably need fixes of various sorts) our spec files out of the box.

And that's just a taste of the technological freedom offered in PLD. Rule of thumb is -- as long as your changes don't actually break anything for other developers, aren't ugly as hell and are in compliance with our technical policies -- you have a green light.

(And if you want to do something really weird, there's always the possibility to branch it, however I would advice against doing that too often -- we're using CVS which is not all that great with branches, even considering we have a healthy amount of scripts helping us with various tasks. YMMV however.)

There is more of course. I won't go into details, but we do have things like a builder infrastructure (python scripts for automatic package building and uploading) and an ftp infrastructure (ditto for tossing those packages around an ftp site) plus you're quite likely to be able to get someone to host your builder or two. And if you're worried about those systems not satisfying your needs -- PLD 2.0 has 8 basic distinct targets for which packages get built (that's five distinct architectures), meaning a lot of builders and a lot of files to keep track off on our ftp server. And it's all being run by a single guy. With a sex life. Involving another person. Not over the internet. And not the phone, either.

Sure, there's still a lot to be done there, but I do believe those scripts should constitute a really reasonable basis for most people.

Oh, and if you're worried about us being too Polish oriented, there's no need to. All cvs commits are in English, our website is in English, and though the Polish devel maillists are seeing more traffic then the English ones, that's just because people are lazy. Threads started on the English lists get the same amount of attention.

And if you don't believe me, we have two non-Polish developers, one from .us and the other from .ee (no, I won't tell you what obscure country that is, go look it up), that will be more then happy to confirm my story. And their willingness has absolutely nothing to do with us having their relatives held hostage.

Really.

For the record -- a couple of days ago Arcadius Meeshkyevich announced that he has taken over the position of Release Manager for PLD 3.0. Most developers agree that this should speed up the release of said PLD Th by at least a decade or two.