The cloth is woven, so the tailors are busy collecting measurements. If you've ordered a kilt or whatever, and have not yet sent in your dimensions & money you need to do that within about 24 hours if you're hoping to get something in time for DebConf.We seem to have got about 20 yards more than we ordered (weaving's more of an art than a science) so if you've only just realised that you want a kilt, skirt, whatever, in glorious Debian Tartan, I suggest you get in touch promptly, as even if you don't want it in time for DebConf, I imagine the rest will get snapped up as soon as people see what they've been missing in New York.I'm getting some Ties made -- they'll cost about 25.00 GBP each. If you fancy one, tell me, and add yourself to this table on the wiki. There's more background on that page.
Bug-Squashing-Party in Munich
We are organizing
another BSP in Munich on the weekend of 17th/18th July.
Like the last BSP, it will
take place in the LiMux office in the
city center. See the coordination page for further information and directions and in order
to sign up for it.
Food and drinks for the event are partly sponsored by the
City
of Munich and this amount (100 ) has been again matched by
credativ GmbH.
Contributions by non-DDs are welcome as always; the BSP will
be attended by several Debian Developers who will be able to
upload fixes. Attending BSPs is a great way to get involved
in the Debian community!
We cannot guarantee crash space to people from
outside Munich at this point, so if you want to attend
please contact the Munich list (area-muc@teams.debian.net)
beforehand or arrange your own accomodation.
We probably start the BSP at some point after 6PM on
Friday evening already, but the main action will be on
Saturday and Sunday. As usual,
people should bring their notebooks and possibly an ethernet
cable. Wireless will be present as well, but a certain
bandwidth cannot be guaranteed.
Bug-Squashing Introduction
I also plan to give an introduction to bug-squashing at this
month's Garching Debian Stammtisch, which will take place
next Wednesday, July 14th in the campus-cneipe (or its
beergarden) as usual (the monthly Stammtisch is always on
the second Wednesday of the month). If you study/work in
Garching and would like to attend the BSP, come to the
Stammtisch for a tutorial (and beer)!
Debian Packaging Tutorial
Some time ago, I gave a tutorial on Debian packaging in the
TechTalk series of the Open-Source-
School. The audience seemed to be pleased with the talk,
and as more people requested to attend than there were seats
in the room, we decided to reprise the event on September
7th. Attendence is free, but you have to register (see the
event
page). There are still some places left at this point.
Currently I own and use an iPhone 3G. I bought it almost two years ago, when the local phone provider LMT started offering the iPhone legally. I had a pretty good experience with it most of the time, but now it is showing its age:
Hello,
Last weekend (2010-07-02 2010-07-04) nine people met at the FAI developer workshop at Linuxhotel in Essen/Germany. If you can t remember: FAI is a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large-scale infrastructures and clusters.
The participants of the FAI meeting:
second row from left to right: Michael Goetze, Michael Prokop, Andreas Schuldei
Between the hack sessions and discussions the attending people presented their FAI usage and approaches. Some notes from the presentations:
A demo video is available at blip.tv. Currently Stephan is searching for a nice name for his FAI management tool please send suggestions either to him or to the linux-fai-devel mailinglist.
Grml / Michael Prokop
Grml is a Debian based Linux live system specially made for system administrators. Grml uses grml-live for building the ISOs, whereas grml-live itself uses FAI s dirinstall feature to build the live system. This provides the Grml team with a nice way to autobuild 18 ISOs per day, known as daily.grml.org. Mika also presented Grml s netscript bootoption and the ethdevice bootoption of live-initramfs which is useful for booting Grml/FAI via PXE.
Host Europe / Michael Goetze
Host Europe uses FAI for installing Debian and Ubuntu (32+64 bit) in the support center. They have ~20 FAI classes and use a Debian lenny NFSROOT as base for all deployed systems. Their main problems with FAI aren t related to FAI itself, but instead e.g. broadcom NICs with lack of support for it in Lenny s kernel. They are not using softupdate (yet) and currently use Kickstart for deploying CentOS but are working on deploying CentOS with FAI as well.
LIS AG / Sebastian Hetze
Linux Information Systems AG (LIS AG) are using FAI 3.2.17 and provide a luma and PyQt based GUI to their customers. They use DHCP, LDAP and DDNS for inventory, configuration and deployment.
Mathematical Institute of the University of Bonn / Manuel Hachtkemper
The Mathematical Institute of the University of Bonn uses FAI 3.1.8 and 3.3.5 for managing ~150 systems. They are automatically running softupdates every day, reporting how many hosts actually did run the softupdate and how many didn t run. The involved failogwatch tool supports two regex files, one for excluding specific hosts and the other one for grepping for known problems in the logs.
Spotify / Andreas Schuldei + Mattias Jansson
Spotify is a peer-to-peer music streaming service and the operating people at Spotify use FAI for deploying the systems. Currently they are using FAI 3.3.3 to deploy ~400 bare metal machines and ~150 virtualised machines. They have their class names in DNS using the txt/Text record entry. They are using a self written prepend_class script to manage dependencies between classes.
University K ln / Thomas Lange
Thomas uses FAI s trunk version (of course
My project.
This post assumes that the reader has read my last post.
I m posting this weekly report earlier this week because there are too many things to tell already. I ve found the reason behind the segfault I m looking for so much time. The last problem, which is the only I know exactly when was fixed, because the programs started working, was related to allocating two times in the same region of memory. This happened because in each major GC the list of free line groups is generated again, but my old code was still allocating in the same line group of the last generation. So the last part of the line group, which was not yet used, would be a part of a line group in generated in the new collection, and it will be used for allocation two times: one in the allocation of the current line group, and another when this new line group starts being allocated.
The implementation of the allocation of memory in lines is not very complicated, but it has some details that should be paid attention, and that were the cause of most trouble last weeks, and still need improvement. Initially I was allocating one object per line, just to see if it would work. As it didn t, I kept on improving the approach until I could find the problem. The next attempt was by setting ws->todo_free and ws->todo_lim in alloc_for_copy() in rts/sm/Evac.c. I think this is not ideal, because I didn t want the code to become too inconsistent with the way memory was allocated using these pointers before my changes. So I created new variables, line_free and line_lim, at first in the gen_workspace ws, the same place that todo_free and todo_lim are, but because of the last problem I described in the previous paragraph I changed it to generation. I m still not sure about where to place these pointers, this is something that can be improved.
Another problem that I took a long time to understand is that the object need to be scavenged after being allocated. When it was allocated in todo_free, it was being scavenged by scavenge_block() in rts/sm/Scav.c, because the block in which it s in, todo_bd, is scavenged by this function. As I didn t wanted to the whole block where the free line group is to get scavenged again, I didn t want to send it to this function. So I thought about creating a way to scavenge only part of a block, that is, the space in the free line group that was allocated. This is still a valid idea, but I noticed that it was easier to use the mark stack. So I mark the object that is allocated in the line and push it in the mark stack. The main problem with this approach it s only possible to allocate in lines during major GCs, since only in this kind of GCs the mark stack is active. This is certainly the place where I can make more improvement.
The patch of these changes and another one for the sanity checking explained in the last post.
I m now benchmarking these changes with nofib, to see how much it affects the performance.
I m a Debian developer since 1998 and have been fostering cooperation between Debian and Ubuntu since its inception with various levels of success.
I recently decided to go one step further and join Ubuntu as an official member. I wanted to be able to vote and to promote best cooperation practices from the Ubuntu side as well (and not only in Debian). Joining as a Debian developer should be relatively easy, it is well known in the Debian community that Mark Shuttleworth once said:
Every Debian developer is also an Ubuntu developer, because one way to contribute to Ubuntu is to contribute to Debian.So I sought to verify that too! Here s the result. I prepared my application page collecting 2 testimonials from Lucas Nussbaum and Colin Watson, I registered for the next EMEA membership meeting (which happened yesterday, irc logs here), and I attended. (I just followed the instructions on the wiki) During the meeting, when it was my turn, I pasted my short introduction and got immediately +1 votes from several board members, they didn t even want to hear from me, they were already convinced.
The laptop features an Intel Core i5 430 M processor with integrated graphics, 4 GiB of RAM, 320 GB hard disk storage, matte screen, and of course a TrackPoint. The machine comes pre-installed with Windows 7 Professional which is not very nice (and Lenovo does not take Windows licenses back). I booted Ubuntu 10.04 from an USB disk which worked a few times, but not always, so I upgraded the BIOS to make USB booting reliable (as Lenovo published multiple BIOS updates already, one fixing this USB booting issue).
The first step was booting Ubuntu 10.04 from an USB hard disk to check the Linux support. Using Ubuntu, everything worked out of the box, including stuff like HDMI audio support or output switching. An exception may be the DVD drive, which only works if you set the SATA mode to compatibility. Non-DVD media also works in AHCI mode, but only if you start with a disc inserted in the drive. Playing DVDs requires setting a region code using setregion(8) [otherwise they do not work at all] and SATA compatibility mode [otherwise they only work partially].
Another issue is the HDMI output, as the TV is not correctly detected and some parts at the top and the bottom of the image are missing (that is, the GNOME panels) (but that happens with different screens and ATI cards as well). Oh, and closing the lid with a screen attached and the internal screen disabled works only as long as you do not open it again, because that causes the GPU to stop.
On the input side, we have one keyboard, one TrackPoint, and a touch pad. All of them work out of the box, but they have a few problems on the hardware side: The cursor keys on the keyboard are incredibly small and the touchpad is very large. The keyboard is different from the one in the HP Compaq: First of all, there is space between the keys (like Apple keyboards); and secondly, you need to apply more pressure in order to use the keys.
The device feels more solid than the HP Compaq 6720s, especially touching the screen does not change the colors on the screen. I don t know how long the keyboard will last, but I hope that I will still have symbols on them in 5 months (which was not the case for the HP Compaq 6720s keyboard).
Power consumption is another interesting point. When the device is idle and the screen is disabled, the device seems to consume about 10W. With screen enabled, consumption varies between 13W (idle) 35W (building source code); if the values received via ACPI are correct. The device ships with a 48 Wh battery which after some time was displayed as 53 Wh in gnome-power-statistics (only the when loaded state, capacity is displayed as 47.5Wh). According to Lenovo, the laptop lasts 4.5 hours on battery, meaning consumption of 47.5 Wh / 4.5 h = 10.5 Wh which is a bit overly optimistic if you want to work on the device.
After checking everything, I took over my Debian sid installation from my old laptop (which I installed in 2008). It runs happely now, although I still need to get accustomed to the new keyboard and the large touch pad.
All in all, the price of 765 I paid for the device seems to be OK. Now I only need to remove the Windows 7 sticker and hope that the device lasts long enough until I want to buy a new one (probably 2013, if the aliens don t invade us 2012).
During the last three months and since my last blog-post about gimp-plugin-registry a lot happened: Mainly a large number of new plugins was added, but also various enhancements and bugfixes went into the package, together with updates for various already included plugins.
For those who don't know gimp-plugin-registry yet, it is a collection of scripts and plugins for The GIMP. The name is based on the webpage GIMP Plugin Registry, where most (new) plugins and scripts are listed. So far the package ships with 170 scripts/plugins. Most of the scripts are written in TinyScheme, but there are also several plugins in C or Python. Probably most noticeable is the inclusion of the GIMP FX Foundry, which is an awesome collection of 124 scripts.
Below follows a list of all scripts and plugins as shown in the long description of the Debian package. New plugins are marked with a bold fontface.
to start with the good news: christine has joined
the RCBW
initiative yeah! let's see who joins next ...
The X Strike Force needs you! (redux)
This time, the focus is on the
xserver-xorg-video-intel
driver. KMS and UMS are going to be used heavily below, one may
want to check the
mode-setting wikipedia article
and the
modesetting page on X.org.
Intel follows a 3-month cycle for its video driver releases. Some
comments on the last ones:
2.9: What we ve had in Debian for some time already. Works mostly
fine, supports both KMS and UMS. What we ve planned to release
with for some time already.2.10: First version with ripped-off UMS support. Not a
significant improvement.2.11: Apparently (still) having a bunch of regressions from 2.9,
which is why we didn t switch to it.2.12: Many regressions are supposed to be fixed, meaning it could
compete with 2.9, which is why we need you.2.12 from experimental and see
how it goes from here. If regressions are found, we should be able to
try hard(er) to get them fixed, so that we can move 2.12 to
unstable and release with it. If there are too many of them, and if
they re not going to be fixed on time, we might stick with 2.9.
Pulling the driver from experimental should be quite easy: libdrm*
packages are going to be upgraded, but that s mostly it (meaning the
server itself will stay the same, and rolling back should be as easy
as downgrading the driver and the libdrm* packages).
A note on KMS and UMS: a benefit of sticking with 2.9 was being
able to switch back to UMS in case KMS wasn t usable for some
cards. Unfortunately, popular/well-spread cards like i8xx aren t
well supported yet, that s why Chris Wilson (upstream) is considering
introducing UMS support again for that kind of blacklisted
cards. This way, it should be possible to move to 2.12 (including
Chris work) without leaving some users behind.
Feedback appreciated as follows:
2.9 used to work and if 2.12 doesn t: please
file a bug upstream.2.12 works while 2.9 didn t, reportbug -k or debian-x@.I like to read business books, but many of them contain a nugget of valuable information, and lots of fluff, because you can't sell a 10 page book. Some of them are pure fluff! Occasionally, one of them has profound implications.
I created this site several years ago in order to have a place to summarize a series of books I'd read, with the aim of creating a community interested in summarizing and, most of all, discussing business books. To be honest, that community hasn't really materialized, although there are a number of registered users (585 at last count). Most other business book summary sites are for-pay - you pay $X dollars a month and receive Y summaries. I wanted to create an open site, in order to foster discussion and communication between people reading summaries.
In any case, one baby later and in a different country, my heart isn't really in it any more, so I've decided to put the site up for sale. I still think the idea is a good one, and that in the right hands, the site could take off.
It was a fun site to work on, and really do think that in the right hands, it, or something derived from it, could be successful. I could conceivably hang on to it and keep trying different things with it, but I've decided I really need to impose this limitation of "make something to sell directly" on myself in order to avoid wandering off into "cool, but no idea how to make money" projects.
Edit:
One thing that I'd like to state explicitly and publicly is that I'm not giving up on open source, just that I think I need to draw a really clear line between "I hope to make some money with this" and "this is a cool project I want to share with the world". In other words, I think I'd rather avoid the middle ground where stuff is sort of openish, and go either for projects that pay directly, or stuff that's pure open source under an Apache or BSD license. Hopefully, if I ever hit on a project that takes off, I'll be able to dedicate some time/resources to open sourcing some of the infrastructure, as I think that's currently one of the better models for producing open source software.
I love this game.
Love that it's so abstract and beautiful and meditative.
Love how it plays with fractal scale. Am I a planet or a unicelled organism?
Love that this basic game idea could have been written at any point since
Spacewar (1961), and could be said to be recycling ideas from everything
from that to Pac Man ... but instead seems entirely new, pure, and fresh.
Love that I can be playing it and it makes me think about things right out
of a Greg Egan novel. Like about how it's most efficient for conciousness
to be slow and not care about the passage of time. So you don't have to
waste much mass on delta-v. Until carnivorous life enters the picture.
Then you have to be bold, and fast.
Love that it has a linux port.
Love that it's hard.
A screenshot can't do it justice -- the video on its
site gives a better idea.
Next.