Debian Wiki, Wheezy,GNOME 3, Gaming and stuff
This post attempts at some explorations I did in the Debian world and some surprising results.
First up, while exploring the Debian world I was kinda saddened that there didn’t seem to be an IRC log of the discussions which happen between Debian Developers. For those who do not know or came in late IRC stands for Internet Relay Chat. Its like GMail Chat or any other chat with the exception that its like a room or channel where there is a specific topic. I had seen something in Launchpad (the Ubuntu service) and was kinda missing that. Then I came to know about the amazing service Meetbot which keeps a track of things. I was actually looking at it as I am/was mildly curious about a Debian games meeting which happened around 2 weeks back. As no developer or a packager but just an interested party and lo and behold Meetbot gave me the shortlog as well as the link to complete meeting log. While the tool is pretty cool and really great what I’m not so happy about is the wiki that Debian has got. The wiki somehow feels incomplete, dunno the reason but it just isn’t there. A good one perhaps which I am/was curious to know is what they are planning for Debian Wheezy and instead of wading through the debian-devel mailing list (as not really a developer but an interested party) I came to this to this to one random goal. What was interesting for me was that I had no idea what were the goals for Debian Squeeze and when I saw them they are the same exact goals as they were during the Squeeze cycle. I saw atleast two if not more issues in the whole communication scenario :-
a. For many of the things/bugs etc. there is no tracking bug. For instance if you look at the Boot performance wiki page one of the options there talks of Correcting the remaining init.d dependencies. For somebody like me who is seeing this from above, I do not know/get it if there has/had been any improvements during the Debian Squeeze cycle. What would really be good is to have a meta-tracking bug which would track which of the bugs have yet to be worked upon, which are done, which are re-opened that sorta thing with some kind of progress bar. I know this is hard as :-
a. The goal post would always keep on moving.
b. There is/maybe no perceptible increase in bug-triaging and bug squashing. For hardcore guys it would be just bling.
The problems which I have faced with the wiki are numerous. From not getting the right page to not getting any info. about the authors who wrote a page or some part of the page. For instance, let’s take that Boot Performance Page again. The page is immutable (which means cannot be changed), look at in the centre above you can see that. While its ok to have the page immutable not being able to see history of that page or was it something that was done in one shot is not known. Then looking at the wiki page a bit deeper came to know that somebody named Petter Rein Holdtsen made that wiki page (party or fully not known) . A look for his wiki page turned up empty. Little bit of digging in one of the bugs turns up that he seems to be a Debian Developer.
The whole point to the above is the amount of digging to be done and whether you are just an interested person/s or a developer time spent in digging/searching can be better applied somewhere else better.I do not know how but they need to somehow get a better job done. As of now it takes quite sometime to really find what’s going on, what’s happening and where things are going. For instance one of the beautiful tools meetbot needs to be somehow better integrated into the wiki and it would really make the system a bit more responsive. One another issue I see is that the Wiki doesn’t still have an https:// (secure) login page.
One blooper/mistake or what I wasn’t aware of in the last post was the reason behind Debian unstable also being frozen when Debian Testing is frozen. While I did put it up on a mailing list and got no response I was able to get some idea on a thread going in Debian-devel about time-based freezes. For those who came in late or might not be aware unlike Ubuntu which does time-based releases every 6 months (meaning every 6~7 months there would be release) Debian does one when it perceives the release has been baked enough, when the developers are happy and there are no show-stoppers. A Debian Stable release as of now is roughly something like a 2 year thing. Anyways what they are trying to with a time-based freeze is to have as small a window for freezing stable, be strict about it and then out of the door. The reason they want to do it (out of many) is because of the freeze period (which can be 6 months or even more) both testing and unstable lose sync and quickly get stale. The reason became clear in one of the posts on the debian-devel mailing list.
Packages that are present in unstable the day we freeze will be automatically allowed into testing, that is, the freeze date … does not mean your package should be in testing by then, but only in unstable.
- Release team, Debian Squeeze
Now at last, I know the reason.While it doesn’t change things in any way at least one knows why the things are the way they are.
Frankly, when I wanted to put up this post I was going to abuse about the state of GNOME 3 in Debian but thankfully I saw Raphael’s post on the same subject. What was interesting was that he linked to one page in particular. This I found pretty fascinating and is kinda the thing I was thinking about when I was whining about not having info. about say BootPerformance page.
Now if you look at the page and this page, the differences are obvious, this is more GUI friendly and the coloring and labelling makes it so easy to figure out where the team needs to go to get the whole of GNOME 3 (first in experimental) and then baking it into unstable.
Needless to say I’m one of those cherry-pick kinda guys so I’m ok with the little brokeness I am having. I have shifted some of the non-essentials (like Epiphany browser,GTK) and some other things to GNOME 3 while the core is still at GNOME 2. There are still couple of bugs in the Epiphany browser libraries so it’s not completely there, yet.
$ apt-cache madison epiphany-browser
epiphany-browser | 3.0.0-1 | http://ftp.debian.org/debian/ experimental/main amd64 Packages
epiphany-browser | 2.30.6-2 | http://ftp.debian.org/debian/ unstable/main amd64 Packages
epiphany-browser | 2.30.6-1 | http://ftp.us.debian.org/debian/ squeeze/main amd64 Packages
epiphany-browser | 2.30.6-1 | http://ftp.debian.org/debian/ squeeze/main Sources
$ dpkg -l epiphany-browser for instance.
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
ii epiphany-brows 3.0.0-1 Intuitive GNOME web browser
Changing the panel and all would probably happen when things are a bit more clearer.
One of the more interesting things which I saw and came to know about is the flourish conference and specifically an hour talk by icculus .
While the talk was interesting to say the least, I was let down by the fact that he focussed too much on FPS (maybe because that the lowest common denominator) . I have never been an FPS guy and in fact like to be more in exploring, simulation, role-play kinda games with one big caveat no time management. One of the things perhaps was perhaps when I was growing I spent a lot of time with a game called SIMS .
One of the ones I look forward to play some day is FAR Colony. The game itself is on an interesting premise/idea that how would we colonize Mars, what experiments we would do and how technology would evolve there. I haven’t played the game because the game says at the beginning that you have one year (365 days in gametime) to colonize Mars. Realistically speaking, it would take years even if we get there . Look at the Mars Rovers Spirit and Opportunity, from their one year mission to still being there today and ‘Opportunity’ still doing work. If I think about it, it could be interesting as lot of things could be dynamically generated, right from how many things are safely transferred between the planets and how much things are damaged to dynamic climate stuff. There is a lot that the AI can play here making for some interesting gameplay but I’m going to hold on till it gets some kind of casual game option (no time barriers) as the first few times it is just going to take time to explore.
I also came to know about 2 Windows games which are into casual sim (with japanese manga art sorta look ) but nothing in the remotest horizon in FOSS games. While there are promising RPG’s (like dungeonhack , now called ‘Godhead’) and dawn-rpg but they are few and far between. I mostly look at fantasy and medieval time-frames when looking at these kinda games.
One of the other things which I had been wondering about is why hadn’t KDE 4.6 made it to Debian Experimental in quite some time. A little bit of searching/digging and came upon a third-party semi-official Debian repository . While I’m not really a KDE user, the only thing I really use from side is ‘Palapeli’ and sometimes ‘Kate’ an editor otherwise nothing much to see/use (speaking strictly for self). Couple of lines added to /etc/apt/sources.list and I was good to go.
Added the public keys and freshened the index. One thing with using this repo was I had to explicitly say the package along with version as the flag ‘ -t unstable’ or ‘-t experimental’ didn’t work . While apt-cache or aptitude versions gave me what new versions of the packages are available I had to explicitly use those to install the same.
The new Palapeli was a downer because I had been expecting some sort of bulk tool where I could give something like say 200 CC-BY-SA pictures downloaded and asking Palapeli to make jigsaws from them either randomly or in some set pre-defined way but didn’t see anything like that. Maybe need to talk with the developer.
Anyways, suffice to say there are lots going both in the Debian world as well as some in the FOSS gaming world. It would be interesting to see what the days and weeks ahead bring for us.