Search Results: "cas"

10 September 2008

Martin F. Krafft: Republican bickering

I wonder what would have happened if Obama had put lipstick on a pitbull would there be any less of this circus put up by the Republican monkeys? Are we back in Kindergarten? Mom! Mom! He hit me! . Is the next thing we ll see tears on stage? Or some sort of fake emotional outbreak? Anything goes in America, I say Both, Obama and McCain have used the lipstick analogy in the past (see previously linked article, and this AP writeup), so why are the Republican monkeys trying to nail him on sexism? They are (trying to) play the gender card (thanks to Erinn Clark for the link). Sexism surely is a word to grab attention, especially in the Excited States of America. By shifting attention to sexism, the Republican monkeys are not only stealing Obama s show and dragging the short-attention-span media (and populace) away from any Palin-related scandals, they are also covering up that they don t have anything else to say. Finally, sexism is an emotional topic, unlike the other political and policy crap the entertainment-hungry television crowd has to put up with, so hooray for excitement! I am disgusted by this American election circus. And I wish we d get about as much coverage of American news in these times as international news gets airtime on American TV. Even though I hope Obama wins for no other reason than that he s not in the same political camp as George W. International Terrorist and War Criminal Bush, I couldn t really care less and don t have any reason to believe that things will improve when the Democrats move back into the White House. And neither do lobbyists care who s sitting at the top. Idiots exist on every level and all over the globe. The rich will still pull the strings. The capitalist avalanche (euphemistically called the strive for democracy ) doesn t slow down. Other countries political monkeys have tasted totalitarianism and lost their senses, and no US government will get them back on track. And the media, who controls it all anyway, is just cashing in on the whole spectacle, which is why I have to continue to be subjected to it. Which brings us back to the rich I wouldn t be surprised to find the likes of Haliburton in the financial support list of the Republican monkeys. PS: I know and respect many American citizens, and I know most of them think like me. Nevertheless, I feel it necessary to point out that none of the above is an attack on those of you with a clue. I feel sympathy at the same time as I feel the rage expressed in the above, but this rage is solely with the political monkeys, the media, and merciless capitalists. None of those are US-specific, it just happens that you seem to have the most pronounced combinations. NP: Mogwai: Come On Die Young

Lucas Nussbaum: UDD and Buildstat

Ultimate Debian Database (UDD) is a GSoC project (now finished) which aimed at importing all different data sources that we have in Debian in a single SQL database, to make it easy to combine that data. Currently, we import information about source and binary packages, all bugs (both archived and unarchived), lintian, carnivore, popcon, history of uploads, history of migrations to testing, and orphaned packages. The goal is really to have that data, without really thinking of a specific use cases: there will be lots of use cases. Buildstat is a project by Gon ri Le Bouder, that provides a framework for running QA tests (rebuilds and lintian currently, but buildstat is built in a very extensible way) on packages, using both packages in the archive, and packages in the VCS repositories of teams. This is pretty cool: it allows teams to get an overview of the status of their packages, not using the archive as reference, but using their VCS. Buildstat schedules and runs the tests, store the data in an SQL database, and allows to browse the data using a web interface. Buildstat also import some data from other sources (only the BTS currently, using the LDAP dump) to display it on the web interface. Since both projects are using an SQL DB, people have been asking why we don’t simply merge them. The big advantage would be that the data is synchronized: buildstat would display more up-to-date info about the data sources it doesn’t generate locally (like bugs), and UDD would get fresh buildstat data. We have been talking a lot with Gon ri, considering the different possibilities. But I don’t think it’s a good idea. I think that both projects should try to do one thing, but do it very well, instead of trying to fix the world. UDD focuses on importing data that exists elsewhere. Sometimes it means doing some complex processing. But data should be be generated by UDD. Merging the projects would mean having a very big piece of software that does everything (or tries to do everything). Both databases were designed differently, with different goals. UDD tries to stay close to the data it imports. There might be some incoherences in the data sources, but that’s fine: one of the goal of UDD is to make it easy to find them (and fix them), so we need them in the DB. In buildstat, since the goal of importing data is to display it on the web interface, with a strict use case, you can freely “simplify” data if it helps. Another big difference is that UDD is designed to be easy to use (ie write and run queries) by a human user: UDD uses multi-column primary keys, while buildstat uses surrogate keys (integer “id” keys), that ORM tools usually require. There are also more technical concerns: currently UDD makes a compromise, for each data source, on what it imports: it tries to import the data that is useful, not all the data available. Merging buildstat and UDD would mean increasing the DB size significantly, by adding all the “private” data that buildstat needs. Another problem is the stable API problem: if buildstat and UDD are merged, it means that buildstat cannot change its DB schema without making sure that it wouldn’t break what UDD users are doing. So, what should we do, from my POV, instead of merging? - Continue to talk, and get Gon ri into the UDD “team”. He gathered a lot of experience working on buildstat, and he probably would be able to help a lot. - Data that is not generated by buildstat (bugs data) should be imported from UDD. Doing SQL->SQL will probably make things easier there. - A summary of buildstat’s infos should be imported into UDD. There’s also the issue of providing the data through a web interface, to the DDs, which buildstat tries to address partially. The Debian Developer Packages Overview (DDPO)’s main limitations are: - lack of knowledge about VCS (what buildstat solves) - lack of knowledge about complex organizations (you can’t get any list of packages, or list of packages maintained by teams not using a consistant Maintainer/Uploaders scheme, or list of packages from tasks, etc) - poor handling of large amount of packages. In teams with lots of packages, it’s useful to have restricted views, such as “packages outdated compared to upstream”, “packages which have bugs/RC bugs”, “packages which are newer in the VCS than in the archive”. The perl team’s work on PET clearly shows the kind of things that are needed. At this point, I think that DDPO would benefit from a full rewrite (using the existing code as a source of inspiration, and making sure that there are no regressions, of course). Using UDD as the data source, it should be easy to get something done (even if UDD still lacks some of the data DDPO has currently). But it still requires web developer skills, which I don’t have. If you are interested, contact me!

Erich Schubert: A few words on my job and research

As some might know, I've been working at the university for a few weeks now. I'm very happy how it all worked out, because of the people there and the subjects to work on. It's just great to think through some mind-bending index structure to improve reverse-k-nearest-neighbor queries. And the professor (who is very well known for his work on R*-Trees, the X-Tree, and the DBSCAN and OPTICS algorithms) really manages to aggregate excellent people.(rkNN is the problem of finding those points for which a Nearest Neighbor Search [Wikipedia] would return the given point. There are many use cases for example in location based services.)A lot of my work involves a framework which has been published recently on the SSDBM 2008 conference: ELKI - Environment for DeveLoping KDD-Applications Supported by Index-StructuresThe goal of ELKI is to become what WEKA is for machine learning. And it's well on it's way for that.ELKI aims at the data mining researcher, it's not designed to squeeze out the last bit of performance. Instead it allows you to compare different algorithms, try different index structures (including various spatial and metrical trees) and offers all kinds of functionality you can reuse. If you are planning to do some real world applications, it likely is still useful for prototyping.In the last weeks I've already put quite some effort in ELKI, so expect the next version to be released with significant changes and new functionality. In fact some working functionality was just left out of the release because we hadn't cleaned up the code yet.Currently, getting started with ELKI can be a bit tricky. It's not hard to use, but you just need to find out where to start. The next release will therefore include a "dummy algorithm" that mostly serves as being a template for implementing custom algorithms (it can also be used for benchmarking an index structure, though).

8 September 2008

Christoph Haas: mentors.debian.net s flakiness

A lot of users of mentors.debian.net have already mailed, irced and jabbered me. (Fortunately nobody rang at my door.) The service was pretty unreliable in the past weeks. If I’m not mistaken it was due to not enough RAM. Unfortunately it’s a VPS server (sponsored for that purpose by vpslink.com) that has 1 GB RAM but doesn’t allow to set up swap for the rare cases where a 100 MB more RAM would save the world. Took me a while to figure out where the infrequent “MySQL server has gone away” came from. That lead to packages either left in the incoming directory or being thrown away randomly during the import into the repository because not all database error conditions have been properly caught. The better news is that the debexpo project done during this year’s Google Summer of Code is now done. The Pylons-based software was written to suit the need for easy-to-use web-based Debian package repositories like PPAs or debpool. I am currently working on a few subleties of debexpo before it will be used for mentors.debian.net. I intend to announce the beta version of mentors.debian.net in about a week. And I hope for lots of feedback then. And let’s hope I get the RAM situation improved on the server. The mentors backend was the only software using the MySQL database. With debexpo (which uses SQLAlchemy for database interaction) I’m free to use PostgreSQL or even SQLite.

Neil Williams: Gobby - collaborative editing for worksession meetings

A few speakers at DebConf8 used gobby during their talks to collate ideas without breaking the flow of the session.
I've just come back from the Emdebian meeting in Extremadura (of which more later) where we also used Gobby - FAI used it too. Once the network setup was working, it was simply a case of clicking Create Session in gobby on my laptop and everyone else clicking Join Session, entering the IP of my laptop (only accessible locally) and choosing a colour.
Gobby is real-time, currently plain-text only but clearly indicates how sections have been edited and has an integrated IRC box for each session. At the end of the meeting, every gobby user has a copy of every document they opened in every session they joined. updated to the moment they quit the session.
Based on using gobby in events like this, I'd strongly recommend that someone at each worksession-type meeting starts a gobby session and maintains that session for the duration of the meeting.
Gobby even does syntax highlighting - depending on how many people join and the colours they choose, this might become difficult so it can be turned off too.
There are only a few minor issues:
  1. The colour bar warning box isn't particularly intuitive - you need to click on what looks like a dimmed progress bar to select a unique colour for yourself.

  2. I initially thought that Gobby had no authentication - in a local meeting, anyone who can connect to the specified IP address is able to edit the document. Since then, I've noticed it does support password authentication and there is mention of fully encrypted connections so it may be possible to use it over public networks.

  3. According to Wikipedia, there is a gobby server that allows non-GNU/Linux clients to run gobby and join any gobby session - I didn't explore this and the Debian package doesn't mention anything about a server option or mixed-OS support.
    • Update - the server is called Sobby and is in Debian.


  4. The right hand side of the window is a bit wasted - maybe some kind of sidebar would be handy, especially docking the userlist into the window so that edits can be identified more quickly.


7 September 2008

John Goerzen: Can You Feel The History?

A few years ago, Terah and I got to visit the beautifully-restored Kansas City Union Station. What a sight. A train station designed to hold 200,000 people, and saw over 200 trains pass through in its heyday. So many people had stories of traveling through Union Station, of arranging to meet someone under the station's iconic giant clock. Maybe they were meeting a husband or wife back from a long trip or fighting in a war, or maybe they were meeting a relative they hadn't seen for years. Walking through Union Station one quiet evening, you can almost hear all the activity still there. Taking the train there, walking in through Amtrak's small boarding area, then stepping out into the dazzling expanse of the station is quite the experience too. It wasn't just a static relic; it was a true piece of history that we can feel.

Decades ago, one of the busiest airports in the country was in Wichita, Kansas. At its peak, the Wichita Municipal Airport saw a flight land or take off every 90 seconds. Its beautiful art deco terminal saw off many an excited traveler. From the Wichita Municipal Airport, you could see buildings owned by Boeing, could drive a minute or two and see Cessna, and other major aircraft manufacturers were also in Wichita. The airport saw many cutting-edge flights, perhaps thanks in part to this. Movie stars were known to fly through Wichita frequently. And Wichita was part of one of the first cross-country air travel routes, New York to Los Angeles, which then took "only" 48 hours. Due to lack of radios and lighted runways, people would fly during the day and ride onboard a train at night to minimize travel time.

Due to an incredible fluke of history, the Wichita Municipal Airport terminal building and control tower still stand. I've never been in an airport that still feels like the 1940s. Other great airports of the era have continued to expand, grow, and generally be replaced as demands for jet service rendered them obsolete and unusable for air service.

You can walk into the building and stand on the main floor lobby (see photos) where people once waited to catch their flight. You can walk down the single departure gate to the tarmac. Obviously we were witnessing a different era -- one in which planes carried only a few passengers each, not the hundreds that they carry today. Three to five planes would line up, and you would simply walk to yours and walk on up and into it. The control tower, a new addition in 1941, still has the high-powered red and green lights that were used to signal airplanes in the days before radio contact was common. The outside of the building has been beautifully restored, but the interior needs a lot of help (and funding) yet. You can still see some areas where the original decorative paintings and tile work survive, but all too many areas have been stripped to the concrete. Outdoors, you can find everything from one of the few surviving B-29s, to some of the earliest small airplanes, to a FedEx jet transport and other quite large planes.

Up in the control tower, they have a radio tuned to air traffic control frequencies. You can hear aircraft being routed to various Wichita airports. On the counter sit several photo albums. As you look down on the ground where historic airplanes sit, you see photos of airplanes lined up, ready to receive passengers. In this building, too, you can really feel the history.

Volunteers were all over. They were all eager to share about the building, the planes, everything they knew. One of the people working on the restoration of the B-29 saw us approaching, and excitedly asked, "Would you like a tour?" Of course!

Though you don't really see 1940s airports anymore, this situation was unique. In 1951, the United States Air Force announced plans to seize the airport and use it to establish an air force base in Wichita. They intended to do so within three weeks. Due to much legal wrangling, including a landmark court case in which the Air Force was forced to honor a contract it had signed with the City of Wichita, the Air Force couldn't quite kick everyone out until 1954, when a new airport in Wichita was completed.

Between 1954 and 1984, the building was an office used by the Air Force. It was abandoned between 1984 and 1991, when the City of Wichita purchased it for use as a museum.

Despite years of neglect, it still stands as a grand old airport. Standing in the airport today, you can see the sign for the Boeing Co. off in the distance, the runways in the other direction, and excited people scurrying about. In a way, it's the same scene that you would have seen 60 years ago -- though nobody was wearing a suit.

6 September 2008

Wouter Verhelst: Bughunting is fun

Two reasons:
  1. 'foo FTBFS on m68k' is not RC. 'foo FTBFS on m68k because it segfaults during the build since it does bar and baz, which just happens to result in a segfault on m68k at startup but might randomly result in a segfault on every architecture, really' in most cases is.
  2. It, well, is just fun to debug someone else's code. On m68k, it's easy to do that, too, if you know a bit of assembly language.
Today's (and last week's) bug: #497262. Xemacs21 segfaults at startup on m68k (and FTBFSes because of that), which is RC for m68k. Reason: confusion between a pointer and its value. In other words: the sanity check might succeed, or it might not, depending on your luck. In fact, the first time the code flows through this buggy path, it does not bomb. Once we do get through this bit, it's also very likely that regular error handling will catch it—the only reason why xemacs segfaults here is because we're still in initialization, and the error object in the lisp stuff hasn't been initialized yet, so we get a nice null pointer dereference... That alone isn't enough to make it RC everywhere, but it's good enough to make it important and fixable for the maintainer. Like I said, fun. Sorry for those of you who want to release Lenny ASAP, but I think I'll be making your life a bit harder :-> Next week's bug: a similar issue in emacs, or the build failure of ghc6 on m68k, depending on time and complexity.

5 September 2008

Gunnar Wolf: Awesome!

For about eight years, I was a very happy WindowMaker user. It was very lightweight, aesthetically pleasing, and I had interiorized its behaviour and keybindings so much, I didn't feel I'd ever switch away. I periodically tried (forced myself even!) to use any of the other, more en vogue environments... Experimented using Gnome for a week, KDE for a week, XFCE for a week (so I would have enough time to learn their ways)... And always came back to my good, well-known wmaker.
In 2006, when we held DebConf6 in Mexico, I saw how other people worked with ion3. I fell immediately in love with it. Not because it is prettier, snappier or has nicer widgets than other window managers - but because it is enormously more usable. Quoting Tuomo Valkonen, the ion3 author,
Ion is not perfect and certainly not for everyone, but neither is any user interface. Usability is subjective.
Using a keyboard-oriented, tiling window manager represented -for the first time in 20 years (I had my first contact with a Macintosh in 1986)- a radical user interface change. For my way of working, I just don't need a desktop, I don't need having a background space or overlapping windows. What I need is a way to functionally organize the windows I have open at any given time, quickly switch between them (and not depending on the mouse, please!), maximizing screen space and all that. ion3 was godsent.
Now, in 2007 there was (yet another) huge flamefest. Valkonen basically does not want distributors distributing any version of ion3 that's not the latest, and introducing changes not approved by him - He basically demands ion to be non-free. So, it was moved to the non-free section of Debian where only Womble decided to keep giving it support. And, of course, by September 2007 Julien Danjou announced he had written another window manager: Awesome.
My main motivation for switching away from ion3 is that... I don't want to use non-free software. But I was very comfortable with ion3. It was only after I saw many other people using Awesome at DebConf8 I decided to bite the bullet and switch. It looked at least as comfortable as ion3.
But... Well, I cannot come up with better phrasing than what Joey said when he switched to Awesome, almost exactly a month ago. When changing between the mainstream window managers, the differences are mostly cosmetic. But with these really different window managers... I cannot but reproduce Joey's words:
I wish I had a good analogy to explain to my nontechnical readers what changing to a new window manager is about.
One way to think about it is that it's like driving a car down the road, and suddenly swapping the steering wheel and brakes out for a tiller and gear shifter. And having to downshift for braking until you learn that the brakes moved to the turn indicator lever. By trial and error.
But that's really only part of it. Another way to look at it is adopting a new philosophy. Or, in some cases a cult. (In some cases, with crazy cult leaders.) Whether they use Windows or a Mac, or Linux, most computer users are members of a big established religion, with some implicit assumptions, like "thy windows shall be overlapping, like papers on the desktop, and thou shalt move them with thy mouse".
So, changing to a new window manager is a process of being dumped into a different environment, where nothing works like you've come to expect, and trying to construct a mental model that you can use to make sense of it. But it's also a process of modifying that environment to behave the way you like.
And when done whole-heartedly, this doesn't just mean trying to make it like the environment you were used to before. It means trying to absorb the underlying philosopy of the window manager, and think up new ways of doing things, inspired by that philosopy, and modify the environment to allow doing those things.
So ideally, "I switched to a new window manager" doesn't mean "my screen has some different widgets on it now". It means "I'm looking at the screen with new eyes."
So, what's so different?
Besides learning some new keybindings (expected, of course), Awesome has several suggested layouts to help you organize your workflow, usually (although not always) consisting of a main area and a side area, tiled side by side (or one above the other, or several stranger ways). This sounds rigid, but it is incredibly comfortable - and I've only been an Awesome user for three days!
But what sets Awesome apart from basically anything else is the concept of tags. Whey you see an Awesome session, you recognize something similar to the very well known workspaces concept we have had in any Unix-like environment for many years, right? Well, but they are not workspaces. They are tags. What is the difference?
When I work with workspace, each of my windows can be in a different workspace. So in one, I'll have my mail-related stuff. In another one, I might be browsing. In another one, I have my development things, and I might be following some logfiles in yet another one.
Awesome allows you to use tags for categorization in much a more flexible way.
For example: I am mostly a web-oriented developer. I usually need four things when developing a system: A browser, Emacs, the log for my development server, and a console where I can peek and poke at my objects and interactions. Of course, cramming them all into the same screen makes no sense - It would be better to follow the good ol' desktop metaphore, and just switch the focus and raise the window, right?
In Awesome, I can have them all set to the maximum screen size - _and_ use the most common combinations as well. Each of the windows can be tagged to more than one workspace (and yes, this is immensely more flexible than the always visible hint on traditional WMs).
To begin with, I'll give each major process a tag to itself, to work full-screen. Emacs is on tag 1, my browser on tag 2. The log and the console share a terminal (i.e. via screen or terminator).
This console by itself is not too useful, so I'll set it to tag 4, and we will go back to it later.
So if I'm building a view or following online documentation, I will add tag 3 to both Emacs and the browser.
I'm also setting tag 4 to the browser - That allows me to use it next to my terminal, following the results of my website-clicking.
And, of course, tag 5 will be set to Emacs and to the console, so I can quickly check any quick API-related question that does not need the documentation or look at a newly written method.
By the way, have you noticed CapsLock is the most stupid key invented, ever? Ok, I gave a good use to it: It's called Mod4. Imagine it is just an extra Ctrl, Alt or Meta key.
So, Mod4-1 gives me Emacs. Mod4-2 gives me the browser. Mod4-3 gives Emacs+browser, Mod4-4 gives browser+console, and Mod4-5 gives Emacs+console. And, of course, the handy Mod4-0 gives me all of my open windows tiled side by side.
Even this is a pattern of being a newbie, I know - I could keep 4 and 5 free, and just tag several simultaneous tags to be active. How? Switch to tag 1 exclusively (Mod4-1), and activate tag2 as well (Ctrl-Mod4-2). There, I have Emacs and browser side by side. Want to get the console instead of the browser? Simple. Ctrl-Mod4-2 (toggle off tag 2), Ctrl-Mod4-3 (toggle on tag 3).
Anyway - As you can see, I am excited at finding a very new and nice tool to help me work better. Today I was playing a bit with the Awesome widgets, but that's something to be talked about later.
In Debian, we are at a crossing point: Awesome is just reaching ion3's popularity. And I'm adding my two main machines' votes to Awesome.
This is Awesome. Quoting (yes, one last quote) the official Awesome site, This gonna be LEGEN... wait for it... DARY!.

Joachim Breitner: vm.overcommit_memory = 2, vm.overcommit_ratio = 0

Do you know this experience: A program, in my case subversion, has a bug and starts to eat memory. You can not interact with your system any more, only watch the memory and swap run full (if you have a display for that). Then it takes a while, while the kernel kills the (hopefully right) program. Things start to move again, until they are fully recovered from the swap and you can continue your work. Or the kernel does somehow not kill the right program, and you are screwed.During regular work, though, your swap is hardy ever needed. Only after a while, a few megabytes of never-used RAM is swapped out, to make space for using the RAM as a file cache.I d like to see the kernel not give out more memory to processes than there is physical memory, because that s plenty for normal work, and if there is more requested, then that s most likely wrong. But I still want the kernel to use the rest of the memory for caching files, and also move some unused RAM pages to the swap file.Unfortunately, there does not seem to be a settings that achieves this directly. But if you happen to have the swap about the same size as your RAM, then these settings, when written to /etc/sysctl.d/vm.conf, will do the job:
vm.overcommit_memory = 2
vm.overcommit_ratio = 0
The first one is to make sure the kernel does not hand out more memory than you tell it to, and the second is to make sure that it only hands out (swap size + 0 * RAM size) to processes.Beware that things go wrong if you happen to have no swap any more for some reason, beause then the kernel will hand out zero memory! Therefore, you need to make sure that these settings are applied after swap was enabled. On a Debian machine, rename /etc/rcS.d/S30procps to /etc/rcS.d/S37procps. This would not be possible if you could also specify the ration of swap memory to be used. Then I could set that to zero and the RAM ratio to 100.If anyone knows better ways to achieve this, I m interested to hear them.Update: For my qemu based armel package builder, this is not enough it seems. I m now running it with overcommit_ratio = 50.

Matthew Garrett: Power management and graphics

It's the X Development Summit in Edinburgh this week, so I've been hanging out with the graphics crowd. There hasn't been a huge amount of work done in the field of power management in graphics so far - Intel have framebuffer compression and there's the lvds reclocking patch I wrote (I've cleaned this up somewhat since then, but it probably wants some refactoring to avoid increasing CPU usage based on its use of damage for update notifications). That still leaves us with some fun things to look at, though.

The most obvious issue is the gpu clock. Intel's chipset implements clock gating, where unused sections of chip automatically unclock themselves. This is pleasingly transparent to the OS, and we get power savings without any complexity we have to care about. However, there's no way to control the core clock of the GPU - it's part of the northbridge and fiddling with the clocking of that would be likely to upset things. Nvidia and Radeon hardware is more interesting in this respect, since we can control the gpu clock independently of anything else. The problem is trying to do so in a reasonable way.

In an ideal universe, we can change these clock frequencies quickly and without any visual artifacts. That way it's possible to leave it in the lowest state and clock it up as load develops. There's a couple of problems with this - non ideal hardware, and the software in the first place. Jerome's been testing a little on Radeon and discovered that changing the memory clock through Atom results in visual corruption. It's conceivable that this is due to some memory transaction cycles getting corrupted as the clock gets changed. If we could ensure that the reclock happens during the vertical blank interval, that's something that could potentially be avoided (of course, then we have the entertainment of working out when the vertical blank interval actually is when you have a dual head output...). The other problem is that 3D software tends to consume as many resources as are available. Games will produce as many frames per second as possible. Demand-based clocking will simply ramp the gpu to full speed in that situation, which isn't necessarily what you want in the battery case (as the number of frames per second goes up, so does the cpu usage - even more power draw) but is probably pretty reasonable in the powered case.

Handwavy testing suggests that this can save a pretty significant amount of power, so it's something that I'm planning on working on. Further optimisations include things like making sure that we're not running any PLLs that aren't being used at the time (oscillators chew power), not powering up output ports when you're not outputting to them and enabling any hardware-level features that we're currently ignoring. And, ideally, doing all of this without causing the machine to hang on a regular basis.

Nico Golde: Google chrome code reuse nightmare

While some people think that Googles new open source webbrowser Chrome is a great example of code reuse I think the opposite is true. He found at least 25 open source libraries used by the browser. So far this is not a problem but what is a problem is that it embeds all of them in the upstream source tarball instead of depending on the system-wide copies. I know that it might be problematic if people have to install 25 libraries on their own (they could provide static builds though) but for distributors this is just a nightmare if security issues pop-up in one of the used libraries (famous libraries who had issues in the past: webkit, libpng, libjpeg, libxml, ...).

In this case the distributors can't just fix the security issue in the shared library and all applications using it are fixed, no they also have to fix all the copies in software like Chrome. Same if you installed Chrome from source, if a security issue pops out in one of the embedded libs you have to go and install a new Chrome version. Google also needs to additionally maintain upstream and security fixes in their embedded code copies but I guess they have enough manpower to do so.

I didn't yet look at the Chrome source code but I hope it has at least a way to link against the system-wide copies without patching the makefiles.

4 September 2008

Raphael Geissert: Top 20: the packages with most dependencies

Some time ago I wrote a small shell script that counted the number of dependencies of each package. It used to take lots of time to perform such a simple operation, so today I decided to rewrite it from scratch in perl and even made it able to sort the packages according to the number of pre-/dependencies.

So, here are 20 packages from sid, which are in the top 20 of most number of pre-/dependencies:

texlive-full:103
libjifty-perl:82
brdesktop-gnome:74
rhythmbox:72
evolution:66
xorg-dev:65
epiphany-gecko:58
gnome-control-center:55
epiphany-webkit:55
iceweasel-l10n-all:55
anjuta:53
gnucash:52
gnome-core-devel:52
brdesktop-common:52
gnome-desktop-environment:51
mplayer:51
beagle:50
dtc-common:49
totem-gstreamer:49
gnome-power-manager:49

Note that ORed dependencies are, correctly, counted once only.

Here's a usertagged list of bugs I filed when I computed the values with the shell version of the script to see what was the reaction of the maintainers. Here's the list of the 20 packages with the more dependencies on sid as of ~2008-05-02.

103 texlive-full
79 brdesktop-gnome
68 rhythmbox
65 xorg-dev
60 evolution
57 epiphany-gecko
54 gnome-control-center
53 epiphany-webkit
51 screenkast
51 iceweasel-l10n-all
51 beagle
50 vlc-nox
50 python-gnome2-extras
50 brdesktop-common
50 anjuta
49 dtc-common
48 totem-gstreamer
47 python-gnome2-desktop
47 awn-applets-c-core
46 gnome-main-menu

So, it looks like we are only going up but not down :(

Russell Coker: Random Opinions, Expert Opinions, and Facts about AppArmor

My previous post titled AppArmor is Dead [1] has inspired a number of reactions. Some of them have been unsubstantiated opinions, well everyone has an opinion so this doesn’t mean much. I believe that opinions of experts matter more, Crispin responded to my post and made some reasonable points [2] (although I believe that he is overstating the ease of use case). I take Crispin’s response a lot more seriously than most of the responses because of his significant experience in commercial computer security work. The opinion of someone who has relevant experience in the field in question matters a lot more than the opinion of random computer users! Finally there is the issue of facts. Of the people who don’t agree with me, Crispin seems to be the first to acknowledge that Novell laying off AppArmor developers and adding SE Linux support are both bad signs for AppArmor. The fact that Red Hat and Tresys have been assigning more people to SE Linux development in the same time period that SUSE has been laying people off AppArmor development seems to be a clear indication of the way that things are goind. One thing that Crispin and I understand is the amount of work involved in maintaining a security system. You can’t just develop something and throw it to the distributions. There is ongoing work required in tracking kernel code changes, and when there is application support there is also a need to track changes to application code (and replacements of system programs). Also there is a need to add new features. Currently the most significant new feature development in SE Linux is related to X access controls - this is something that every security system for Linux needs to do (currently none of them do it). It’s a huge amount of work, but the end result will be that compromising one X client that is running on your desktop will not automatically grant access to all the other windows. The CNET article about Novell laying off the AppArmor developers [3] says ‘“An open-source AppArmor community has developed. We’ll continue to partner with this community,” though the company will continue to develop aspects of AppArmor‘ and attributes that to Novell spokesman Bruce Lowry. Currently there doesn’t seem to be an AppArmor community, the Freshmeat page for AppArmor still lists Crispin as the owner and has not been updated since 2006 [4], it also links to hosting on Novell’s site. The Wikipedia page for AppArmor also lists no upstream site other than Novell [4]. The AppArmor development list hosted by SUSE is getting less than 10 posts per month recently [6]. The AppArmor general list had a good month in January with a total of 23 messages (including SPAM) [7], but generally gets only a few messages a month. The fact that Crispin is still listed as the project leader [8] says a lot about how the project is managed at Novell! So the question is, how can AppArmor’s prospects be improved? A post on linsec.ca notes that Mandriva is using AppArmor, getting more distribution support would be good [9], but the most important thing in that regard will be contributing patches back and dedicating people to do upstream work (Red Hat does a huge amount of upstream development for SE Linux and a significant portion of my Debian work goes upstream). It seems to me that the most important thing is to have an active community. Have a primary web site (maybe hosted by Novell, maybe SourceForge or something else) that is accurate and current. Have people giving talks about AppArmor at conferences to promote it to developers. Then try to do something to get some buzz about the technology, my SE Linux Play Machines inspired a lot of interest in the SE Linux technology [10]. If something similar was done with AppArmor then it would get some interest. I’m not interested in killing AppArmor (I suspect that Crispin’s insinuations were aimed at others). If my posts on this topic inspire more work on AppArmor and Linux security in general then I’m happy. As Crispin notes the real enemy is his employer (he doesn’t quite say that - but it’s my interpretation of his post).

3 September 2008

Jaldhar Vyas: Was the Python Trivia Properly Vetted?

I don't know what it says about Debian but while the political content of my last post was ignored, I have received a steady stream of email today saying Michael Palin was in fact the lumberjack in "And Now For Something Completely Different" Obviously I am unfit to be a heartbeat away from the DPL. obTheOtherPalin: Today is Ganesh Chaturthi so I have been to busy praying to watch it. I presume it will be on youtube or something by tomorrow. In any case as long as she didn't embarass herself, my view that she will be a plus for the McCain campaign still stands.

Martin-Éric Racine: another Tux bites the dust

At the dayjob, we've been evaluating various OS options for a customer project. Without going into details, it involves installing embedded software on a ThinCan for a special usage case. The basic needs are simple: graphic environment to run a custom application (OS neutral), plus a few drivers for hardware attached to the ThinCan. That's it. Nothing to excited about. Comparing various team members' proposals to implement the OS base was the real shocker: no matter how optimized the software base and compiler options, no matter which build environment was used (Thin Station, Open Embedded, Gentoo, etc.), we couldn't get a performance that was remotely usable: Then came the proposal from our team's lone Windows guy: XP Embedded. Booted in less than 10 seconds, has a graphical environment that is usable out of the box and integrating the customer's application was a breeze. Heck, the demo is practically a finished product already and took just a couple of hours to assemble! To make matters worse, the total we'd be paying in licensing fees, for all the Windows components we choose, would amount to far less than what it would cost to polish either of the Free Software -based proposals. Before anyone goes and puts on their asbestos suit, I'm already aware that the point of Free Software is to keep people employed and to make the community at large benefit from everyone's code improvements by contributing patches to upstream. Please keep in mind that, in contrast, business requirements are to get results at a reasonable cost, reasonably fast and to produce a well-polished product. The Free Software community has finally conquered the challenges of the desktop and was already on the server ages ago, but we ain't quite there yet on embedded devices, I'm afraid. While I personally refuse to run anything else than Ubuntu on my laptop, let's face it, in the above case, the savings in time=money were obvious and the resulting product quality, even at demo stage, spoke for itself. Thus, another Tux bit the dust.

2 September 2008

Runa Sandvik: I heart London

While sitting on a bench in Hyde Park, watching the leaves fall from the trees, thinking that fall is just around the corner, I started to write on the back of an old receipt. One that says 108,- for a Banana Passion Split and a bottle of Coca Cola. It’s just something I do when I’m nervous, excited, lonely, happy or all of the above. Sometimes I spend so long thinking about how to express myself, that I forget what I was going to write. I spend too long trying to find the right adjectives. And I wish I could find the right words to describe some of the best moments. My trip to London was more than just Big Ben, The London Eye, Madame Tussauds and Oxford Street. A lot more. Another receipt says 590,- for a haircut. It’s from July 15th, 2008. My ramblings on the back, blue ink, some words crossed out, some misspelled; at least 1 of the 268 Underground stations has a staircase with 78 steps, a shop on Oxford Street sells salt from the Dead Sea, and some very big soap bubbles were seen in Camden Town. There are some keywords at the bottom of the second receipt. Just to remember all the other things that happened. Like the time we almost got lost on the Underground, the elevator with no buttons, the Kanye West sunglasses in white and pink, and the lack of a proper breakfast - even though I don’t mind white bread and strawberry jam. There was just one small thing I wasn’t too happy about; you can’t write on receipts from Tesco. They have THANK YOU FOR SHOPPING WITH US printed all over it. And it took me a while to find that piece of paper in my bag. This time I saw fall in London, and a white pigeon. I will make sure I have my notebook with me next time.

Michal Čihař: Number of records in phone database

I was today just too lazy to do much actual work, but I spend time on playing with something new - this time it was Google Chart API or better Python Google Chart module. I wanted to have some visualisation of growth of data in Gammu phone database for a long time and this module seemed to be good way to achieve good charts. After a bit of playing I got following chart: Chart showing history of phone database. What we can see from it? Number of garbage grows very fast. Mostly it is caused by Wammu, which asks user for feedback after some time of active usage and this sometimes leads to duplicate records (but it also brings information which phones are really being used). The bad thing which is visible here is that mostly half of reports is about unsupported phones! I think we should do something about this as the reality is not really that bad and from my POV, most of failure reports are caused by wrong configuration being used. I know it is sometimes tricky to find working one especially when you use Nokia phone with cable, where exists simply too much possibilities. It's time to tweak up autodetection so that it can handle most of such cases (and recent HAL features to export capabilities of modem devices might also help in this area).

Martin F. Krafft: Does silence kill kids?

When Graham Bell invented the telephone in 1876, he probably didn t expect the rise of the cellphones we ve been seeing over the last 20 years. At first, there were C-net phone too huge to carry, but mobile still, as they communicated wireless. Then, devices became smaller, networks faster and ubiquitous, and today, the number of cellphones sold worldwide has exceeded the population. Much like everything else, it used to be better back then . When phone calls were still ridiculously expensive, people were able to enjoy their peace and life progressed slow for everyone to think enough, not do or say without engaging their brains. Then, when the first cellphones stuffed people s pockets, they did their job pretty much from the start: you could make phone calls. Some genius discovered SMS as a splendid tool to rip off customers, so phones grew pager abilities, but other than that, they just worked; I remember my first phone, which didn t break in years. Obviously, if you re a phone manufacturer, you don t like that, because once you sell a phone that works, the customer won t come back to give more monies in ten years. Clever as you are, you devised two schemes to ensure your cash flow: make phones more brittle and crap, so that they break within a year, at most two; and drag ever younger people into the debt trap. For the truly stupid, sites and services offer ring tones and games and what not, and the lesser challenged you keep close by the continuous addition of new features that noone needs. So these days, almost every phone can play music files, which is mighty convenient to spice up your work commute with some tunes, but our youngsters are overburdened by that, it seems. I almost soiled myself laughing at a group of five Italians at Ezeiza Airport in Buenos Aires, who were sitting around waiting for a bus, every one of them ear plugged and grooving to the beats (you know how dorky it looks when people silently sing along rap songs?). That s not the funny part. The funny part is that every minute, one of them would say something, which would cause the others to unplug one ear, and form their lips to bleat what (making sure to add just a little bit extra of the tone of general disinterest, which is cool ). This elicited one of two responses: either the original speaker would say oh, nothing and everyone nodded, or he d repeat his wisdom, causing everyone to laugh and nod before in both cases they replugged and returned to luff themselves. I wonder how they made it to the airport themselves, and why they travel as a group. Worse than that, however, is that cellphone manufacturers remembered that their phones had speakers (for fancy ringtones) and consequently added the ability to blast tunes through them. As a result, groups of kiddies walk around or sit in trains, with one (or more) of those cellphones blaring into the environment. Apart from being generally inconsiderate, what I don t understand is how they put up with the sound quality. It s mostly hip-hop music you know that genre that makes some homies out there install 5000 watt subwoofers into their cars so make sure the windows rattle with the base but these phones have a frequency spectrum comparable in width to that of your grandfather s, way further up the scale (meaning they just don t do base). Playing hip-hop through those is like putting a flute concerto on a subwoofer, just worse, because high-pitch tones are harder to filter by those who don t want to hear them. And yet, I see it all over the place, kiddies listening to music through cellphone speakers. Is it because silence would kill them? NP: 65daysofstatic: The Fall of Math

1 September 2008

Daniel Baumann: Debian not complying to licenses

First of all, I don't want to blame individual persons. This is just a note of how disappointed I'm about some parts of Debian that are not complying to licenses when it comes to distributing software. debian-cd embedds copy of syslinux without source A couple of years ago, I took over the maintenance of the syslinux package since its previous maintainer was MIA. The takeover was motivated by to the fact, that having started to take care about live systems, I also started to use syslinux on a daily basis and that the syslinux package in Debian was horribly outdated. At that time, I found out that debian-cd, the toolkit to build the official Debian Installer images, doesn't take syslinux out of the archive at build-time of the image, but rather embedds a copy of the required binaries inside the package itself. So I asked Steve to update the binary what he did. Before the etch release, I needed to ask the debian-cd team to sync again their embedded syslinux copy to match the one I had uploaded to the archive, as it was again outdated. On the other hand, live-helper, the toolkit to build the official Debian Live images, was always using the package out of the archive and did never had that problem. After we have released the Debian Lenny Live Beta 1 images last week, we got reports from people trying them on Apple MacBooks and failed because syslinux, taken out of the archive (version 3.71), is broken on that hardware. Some people stated that Debian Installer images do work. That is because debian-cd has an embedded copy of syslinux (version 3.63) which doesn't have that regressions. Since syslinux version 3.71 is present in testing/lenny as well as unstable/sid, and stable/etch has version 3.31, that means... if debian-cd is embedding a syslinux binary with a different version, it must contain the sources for it (it also needs to contain the sources for it anyway, even if it would embedd binaries of the current version, however, it would be a tiny bit less arguable if its sources would be at least present in the Debian archive). So I checked debian-cd, and surprise, it doesn't contain syslinux sources. Syslinux is licensed under the GNU General Public License, version 2 or later. That means, that if you distribute the binaries and sources together, you can remove both at the same time if you decide to no longer distribute the binary (that is what Debian uses to do). This let me to bug #497270. The option to distribute the binary with a note on how to get the sources, valid for three years, could theoretically be done, but isn't used so far (since it has pretty bad practical implications of keeping sources arround even after having stopped to distribute the binaries). Debian sarge release has incomplete source images Checking fo the consequences for embedding bootloader binaries in debian-cd, I just saw that the Debian sarge release does ship syslinux version 2.04 in its images, but is shipping syslinux 2.11 in its source images. This is another violation of the GPL and I've filled this as bug #497471. ...and syslinux is just one bootloader, only used for i386 and amd64. Someone still needs to check for all the other bootloaders for the other architectures we support (and those also for the etch release). cdimage.debian.org distributes images without sources While browsing arround on cdimage.debian.org, I also found the kde4beta livecds made by the Debian KDE team back in November 2007. Although these images are nice, there is no source available for them at all. They use packages that are not available anymore in Debian since a long time. This time, this doesn't only violate the GPL as in the previous two cases, but almost any copyleft license under which we distribute software in main and that is included on these images. I've filled this as bug #497462. Again, this is not about blaming individual persons. But I'm pretty disappointed by these things. In Debian, we spend a big chunk of time checking licenses of packages before we start distributing them. We have our beloved NEW queue where, after the Debian Developer who has initial uploaded a package and has checked the sources, also ftp-masters are re-checking each and every package to ensure that our archive is kept legal. The NEW queue is a mesurement that consumes a big deal of our time, making uploading packages new packages slow, but this is the prize we pay for ensuring our freedom. And we do also make a big fuss about cluebating upstreams that don't respect licenses (be it intentionally or by accident). However, it appears that as good as our package checks are, we spend little to no time to check our resulting products made from these packages. Update: kde4beta livecds have been removed now from cdimage.debian.org, see #497462. Update 2: debimg does the same crap.

MJ Ray: The Phone Co-op: interview, phorm, challenges

Among other things, my webmaster cooperative is an agent for the Phone Co-op. Particularly with Free Software, cost-efficient ways of downloading data is a good companion service to have and the Phone Co-op has given a good ADSL and calls service to my own home and office for a few years now. When there are problems, they’ve worked pretty well to fix them. Just last week, I had a phone call to tell me when routing problems in LINX were fixed… which was a great help. I don’t remember an ISP doing that for me for years. I think the last one was my university’s dial-up service, 10 or more years ago. Another unusual thing for a UK ISP is the excellent public position on the Phorm ad-snooper that I mentioned previously: We strongly oppose these practices, especially the loss of privacy [...] Phorm is not operating on our users’ lines and we have required and received assurances from our suppliers that this will remain the case. Our Chief Executive Vivian Woodell gave an interview to the FT (accept the first two cookies, then block the rest, else you only get two paragraphs) which has a pretty good explanation of how the business side of the cooperative works. We’re recruiting for Line Rental (PSTN and ISDN) until the end of the year, including special offers like residential Unlimited Anytime Calls for 7.95 a month (normally 9.99) at the moment, as well as the great climate-neutral and ethical policies - if your landline contract renewal comes up, give it a look. The Phone Co-op was ten years old in June, but there are still big challenges: I’d love to see a cooperative pay-as-you-go mobile phone service and the mobile contract offers still look a bit expensive to me (no bundled data on phones, 25 per month for a 3G data card). I’d also love to see support for some daring innovative solutions like customers owning their own tails (tails are the last link to their house, where most of the UK has a choice of one provider: BT), using that as a way to upgrade small towns and villages to fibre-optic, or offer resident-owned wifi. Update: As if by magic, Ofcom has started a social web consultation about mobile phone services. Go comment.

Next.

Previous.