I read an [old] article on habrahabr.ru about how Windows 7 worked after a bug in BIOS that sent the guy’s system 14.000 years forward. That got me interested — how would my favourite system [Linux] work in such a case? So I opened clock configuration tool in GNOME and started adding years.

1. Max possible date turned out to be 258337. Looks like that’s when the world ends.
2. Gnome Shell clock stopped working (showing up on the panel) after the first 10K years leap. Anyone cares to report?
3. Linux thinks that once in 20K years you still should change your password. After each time leap I had to ‘sudo passwd’ for the user, otherwise the GUI for changing date/time in GNOME couldn’t get superuser privilegies.
4. Of course, everything related to HTTPS stopped working, because all certificates expired.
5. LibreOffice Calc couldn’t calculate the current date, outputting “Error: 511” instead of the value in a cell. And after the first 10K years jump it couldn’t really load the user’s profile.
6. Google Chrome simply refused opening my Gmail account because of the expired certificate and didn’t even suggest to “Continue anyway” . Epiphany, however, worked just fine in both 10.000 and 260.000 years and only warned about insecure connection in the address bar. Google Chrome also failed to load the user’s profile (history, bookmarks etc.) in 200.000 years.
7. VirtualBox freezed when starting a virtual machine and in general started very slowly. Which is why I couldn’t figure out what Windows would really do in the future.
8. GNOME’s screenshot utility suggested “Screenshot-(null)” name instead of the usual “Screenshot-$DateTime”.
9. The rest of the system worked surprisingly fine (which is more than what could be said about Windows 7 from the habrahabr.ru article). Nautilus, Pidgin, Epiphany, console tools: all of them managed to display and use six figure dates.
10. Google promised 10^308 Mbyte free space for GMail.

To sum it up: Linux is ready fo the future apart from LibreOffice, some proprietary tools and the Gnome Shell clock.

After going back to the present the system experienced a kernel panic. It’s the first time I ever saw how all four CPU cores went out one by one on Linux, btw, and the disc activity stopped only after the last one. After that I rebooted from a flash drive, ran fsck, booted the system. So far it works just fine.

Somewhere between last and this week LGW was actually started (the official announcement was made in early August 2009). The existing disproportion between amount of news and tutorials is quite annoying, so there will be more tutorials and reviews and probably less news covering minor software releases. I’m also hoping to be done with new design in the coming month, because honestly, things that are made as temporary always do their best to stick forever, and no matter how hard you scrub…

Why, and I’m absolutely serious about this, why do you want that? Why do you care if it’s male or female brain that excellent ideas come from?

You write: “Individual projects have found ways to make women welcome…”. What the heck? No, really! Show me a single FLOSS project that blatantly refused to welcome women. Or the one that pointedly ignored their contributions. I’m really curious.

You write later: “The report from the summer of 2009 layed out some U.S. educational figures: in 2006 only 20% of computer science students were women going for their bachelor’s degree”. Well, I feel sorry for you. If you come to visit Moscow State Technical University you’ll see that about half of students there are women. YMMV.

At my previous job practically all girls in cluster/data centre department were either studying at MSTU or Moscow State University of Aerospace Technologies or Moscow Engineering Physics Institute or have had graduated from either of them. YMMV.

We’ve already been through discussions about stupid people and their “show me your boobs” requests. We don’t have issues about women not being welcome. We have an issue of having dicks in the community who do not respect other people.

I’ve been to many forums for designers and even though offensive jokes towards women are so rare there that people would queue up to read them for novelty sake, women usually don’t make above 15% of presence there. While in fact making 1/2 of designers community (at least where I live). And I daresay most interior designers here are women. Again, lots of women in photographers communities while at the same time really few of them when it comes to discussing some bloody 1:1 crops with different interpolation methods.

Somehow a lot of women just don’t feel like joining techie communities or discussing techie things. So why do you want them to do it? Because you want it? And will you drag them kicking and screaming into the bright new Century of Women in FLOSS if they refuse?

So if you make women a special case in FLOSS, here is an idea. We need more dwarfs in FLOSS. And trolls. And while at that, why not get more werewolves? There really are so few of them. Since you care

It’s really amazing how some people cannot twist their heads around a very simple idea that equal rights does not actually mean equal interests.

I hope you’ll excuse the fact that I’ve been working as IT journalist for seven years only (and as editor in an offline IT magazin with >100K copies run per issue several years ago). Not that much, but still a nice experience.

There are several simple rules in journalism.

1. Make sure the issue really exists.

If you are a good journalist, you don’t play with people’s minds and you don’t make up problems. You investigate, analyze and tell.

Nathan: “Twice in recent weeks open source projects have surprised me with their lack of openness. In both cases, developers acted or spoke out in such a way as to intentionally push other developers away from their work.”

Neither of parties tried to “intentionally push other developers away from their work”. In the first case we have a designer and a spokesperson who express disagreement with people not having respect for their (or, rather, Oxygen designers) work. In the second case amount of decision makers is intentionally limited to maximize signal/noise ratio, while amount of contributors is not limited at all.

Is it really worth a rant, not even speaking about an article?

2. Research, don’t guess

Nathan: “Through the Internet Archive’s Wayback Machine, you can examine the Oxygen project’s site all the way back to 2005. Ever since the beginning, two things have remained unchanged: the only images available are “previews” licensed under Creative Commons Attribution-NonCommercial-NoDerivs, and the team does not invite outside participation.”

OK, I look at the archive and I see that the website hasn’t changed. How does it related to openness of the project?

Instead let’s go straight to Contact page of Oxygen project:

“To get involved you can join the KDE Artists mailing list where everyone is encouraged to contribute, share ideas and offer help. You can also discuss Oxygen on IRC (freenode.net #kde-artists).”

Does it sound like the team is not inviting outside participation? Clearly it doesn’t. Every conclusion you make should be backed by facts. If you intend to prove that Oxygen team doesn’t welcome contributors, use facts: tell readers about people who actually studied principles of Oxygen’s approach to design, tried to contribute, but were rejected from participation. If such people ever existed.

Nathan: “But that absence of an open invitation to contribute is topped by direct rejection.”

Is it the same Nathan Willis who earlier wrote “When I researched the GIMP UI brainstorm in October…”? Research is the wrong verb here. Looking through is the right one. You wanna proofs? Here you are.

a) We can see Sven saying: “The process is completely open and you have obviously misunderstood quite a few things about it. … Can we please not distract ourselves right now with a discussion that is based on nothing but fear, doubt and misunderstandings? Thanks.”

b) “Participate in the UI brainstorm” is listed among “Ways in which you can help” at GIMP’s website.

The term direct rejection is a clear case of no good research at all. For every conclusion you needs solid facts. To get solid facts you have to research.

3. When writing about a conflict situation, talk to both parties.

This is not even an option like buying or not buying ice-cream in a supermarket. This is golden rule. If you don’t follow it, go blogging elsewhere.

• Did Nathan contact the creator of “Oxygen Refit” icon package to ask him if he was really abused? Since this is not mentioned, I’d say, no — the guy wasn’t contacted. You say you disagree? Then prove me wrong. Use facts.

• Was Oxygen team contacted to provide comments? Not mentioned in the article, therefore not contacted.

• Was Esteban contacted to have him say he was abused by GIMP UI design team rules? Looks like he wasn’t as well. Too bad, because after initial misunderstanding, how the UI design project works, he keeps contributing. To the “closed” project

• Was GIMP UI design team contacted to provide explanations? All the same.

Googling and quoting isn’t enough. Go blogging, if you think it is.

4. Tell, but don’t teach.

Nathan: “The secondary complaint — that it is wrong to release the icons before the project declares them “ready” — is entirely incompatible with the “release early, release often” philosophy. Artwork is no different from executable code in either regard.”

A journalist is not supposed to teach (unless he writes tutorials), especially in an agressive manner. Never. Ever. Primary function of a journalist is to tell people what is going on. If you try to be both journalist and evangelist, you will fail at both. This is simple.

Anyone mad about the way Oxygen project works? Buy a punching ball and contribute to it.

Just for the record, I’m not affiliated with Oxygen project. I’m a tiniest bit affiliated with Tango project and I did feel angry about this silly Tango vs. Oxygen opposition. They are good friends.

5. Learn what you are writing about.

A good journalist can write about just anything at all. Sure, noone would expect a great SAN related article from someone who has been writing about agriculture for last 30 years. But if you are an IT journalist, you have no excuse for not knowing basics.

Very few users use most of functions in an aplication like GIMP. Therefore they can contribute with ideas how to improve a small part of the application, but they can’t be great UI architects, because they don’t see the big picture. As simple as it is. Basics, as I said before.

Now think about reasons, why decision making is limited to Sikking’s team. And think about the way OpenUsability project works (and it wasn’t even mentioned in the article — another sign of no proper research).

That’s it. Five rules is enough for now.

Oh yeah, and because this blog posting is about teaching, you are free to consider it a rant

So go grab bright and shiny 2.2.1 release with lots of improvements and talk to your elder relatives before you lose your latest chance to find out in details, where your roots are.

Spent a great week in St. Petersburg (for the first time in my life, which amused most of my friends) walking, meeting with friends and shooting pictures — unusually much street photography that I never felt I was good at.

Now onto work

I’ll be offline next two weeks due to long anticipated vacation. Have fun