The OpenStates / GASP hackathon here at PyCon is going killer. We ve got a bunch of brandy-new contributors hacking away, and sending in pull requests. We re squashing bugs like crazy, and it s going super well.
Shout-out to all the new contributors!
One of the most popular backup solution under Linux is Bacula, but it s quite complicated to setup. The same for Amanda.
Since we ve got this software in Debian installing it on unstable is as simple as apt-get install burp .backup ~ # burp -a b 2012-02-22 17:53:03: burp[30584] Listing configured paths: 2012-02-22 17:53:03: burp[30584] include: /home 2012-02-22 17:53:03: burp[30584] Listing starting paths: 2012-02-22 17:53:03: burp[30584] /home 2012-02-22 17:53:03: burp[30584] before client 2012-02-22 17:53:03: burp[30584] begin client 2012-02-22 17:53:03: burp[30584] auth ok 2012-02-22 17:53:03: burp[30584] Compression level: 9 2012-02-22 17:53:03: burp[30584] do backup client 2012-02-22 17:53:03: burp[30584] Phase 1 begin (file system scan) ddwdffffddffdfdfdddfffffdddfffffffdfffdfdfffffdfdfdffdddddfffddff 64 [...a lot of output...] 2012-02-22 17:53:03: burp[30584] Phase 1 end (file system scan) 2012-02-22 17:53:03: burp[30584] Phase 2 begin (send file data) ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 64 [...a lot of output...] -------------------------------------------------------------------------------- Start time: 2012-02-22 17:53:03 End time: 2012-02-22 17:53:07 Time taken: 00:04 New Changed Unchanged Total Scanned -------------------------------------------------- Files: 100 0 - 100 100 Directories: - - - - 76 Soft links: - - - - 1 Grand total: 100 0 - 100 177 -------------------------------------------------- Warnings: 1 Bytes estimated: 17628946 (16.81 MB) Bytes in backup: 17628946 (16.81 MB) Bytes received: 0 Bytes sent: 17628946 (16.81 MB) -------------------------------------------------------------------------------- 2012-02-22 17:53:07: burp[30584] Phase 2 end (send file data) 2012-02-22 17:53:07: burp[30584] backup finished ok 2012-02-22 17:53:07: burp[30584] after client backup ~ #
disk=/dev/foo
smartctl -a $disk
smartctl -t long $disk
badblocks -swo $vendor_$model_$serial_$timestamp.badblocks.swo $disk
smartctl -a $disk
master:/srv/leader/news/bits-from-the-DPL.*
Hacker s demo shows how easily credit cards can be read through clothes and wallets.
So, in 2002 I attended my first SPUG meeting. Also in attendance were Randal, Tim, J.P. (I think) and quite a few of the other usual suspects. The guest speaker was the inestimable Dr. Damian Conway. This night might be the single most important event in my career as a builder of the internets. I was already set in my ways regarding my operating system, and I knew enough perl to get by, but I wasn t in touch with any users groups until then.
The crown jewel of the night was Damian s recital in full of his poem, I Am The Very Model of A Poster To CLPM (sung to the tune of that song from Pirates of Penzance). I must admit that I d never heard of CLPM and that it all sounded like gobble-de-gook at the time. If I recall correctly, this happened just after he took about 10 minutes to teach us all to pronounce the name of then-Pumpking, Jarkko Hietaniemi. This was the same year that the following video was made
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/XkU_GQVOCqo" width="420"></iframe>
With that in mind, there s one more thing I need to share with you before disclosing the lyrics. This piece was developed during a time when it was common for members of the perl community to flame one another on news feeds, take their anger and frustration out on newbies and generally be the bane of most of the internet. I like to think that it helped to shape me into a kinder, gentler perl programmer, debian user and general netizen over the years. I would also like to think that it will do the same for future members of our communities.
And so, without further ado, Damian Conway s
master during this
merge window. Which is
what happened,
a few days before Christmas.
The other components involved in XI2.2 (aka. multitouch ) were
packaged in experimental while the server side was getting prepared:
Given we reached the
1.12 RC1
stage, it s a good idea to start building drivers against the new
server to make it possible for users to perform some tests. And as
usual, a new server means bumped input and video ABI, meaning a
rebuild for the drivers to pick new dependencies. Some of them also
needed a few fixes to make them build against the new server. Nothing
that can t be fixed with a few merges from upstream master branches.
The usual set of major drivers was uploaded to experimental:
xserver-xorg-input-evdevxserver-xorg-input-keyboardxserver-xorg-input-mousexserver-xorg-input-synapticsxserver-xorg-input-voidxserver-xorg-video-atixserver-xorg-video-dummyxserver-xorg-video-nouveauxserver-xorg-video-fbdevxserver-xorg-video-intelxserver-xorg-video-vesamaster branch was created, and packaged
with SNA support enabled. SandyBridge's
New Acceleration has apparently reached a point where it can be
published to the masses, so here we go. Some details about it can be
found in the
initial commit.
Also, for those wondering about the xorg-server FTBFS on some
architectures,
fixes are pending.
Happy new year.
Do you believe that there will come a major inflation in the next months or years? If not, you can stop reading this article. Otherwise lets think what would be the right thing to do now. 
Back in 2007, Harpers Magazine published The Ecstasy of
Influence: a beautiful article by Jonathan Lethem on reuse in art
and literature. Like Lewis Hyde in The Gift (quite like
Hyde, as readers discover) Lethem blurs the line between plagiarism,
remix, and influence and points to his subject at the center of
artistic production. Lethem's gimmick, which most readers only
discover at the end, is that the article is constructed entirely out
of "reused" (i.e., plagiarized) quotations and paraphrases.
A couple months ago, I suggested to my friend Andr s
Monroy-Hern ndez a very similar project: a literature review on
academic work on remixing and remixing communities constructed
entirely of text lifted from existing research.
After some searching around, Andr s pointed out that Lethem had
essentially beaten us to the punch and linked me to his article. Only
after I visited the link did I remember that I had read Lethem's
article when it was published and loved the idea then. Over time, I'd
forgotten I read ever it.
Without knowing it, I had read, loved, forgotten, and then --
influenced, if unconsciously -- copied and reproduced the idea myself
in slightly modified form.
And I suppose that was the point.
master:/srv/leader/news/bits-from-the-DPL.*
Handy command line arguments for gpg:
gpg --list-options show-photos --fingerprint 0xdc6dc026This is nice to examine someone s PGP photo. You can also include it in
--verify-options, depending on how/when you want to see the photo (for example, when doing key signings).
If gpg doesn t pick the right photo viewer, you can override it with --photo-viewer 'eog %I' or similar.
2011, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Happy.
This is how I feel after I ran the "Le Puy-Firminy" night race last
Sunday. 70 kilometers (mixed roads and trails), 1500 meters positive
slope, close to my birth town, St-Etienne (the track on Garmin Connect
unfortunately has bugs for the profile, sorry for this....this is
apparently a bug in Garmin Connect as pyTrainer shows the
track very well.
And running this by night, starting at midnight and arriving
at....09:16 the next day. A full night running.
Such "ultra" experience is completely different from marathon running.
In marathons, you mostly try keeping a constant pace all along the
race, running very close to your limits all along the race.
Very long distances involve managing much more than keeping a constant
pace. Being able to run (and walk) for many hours requires being very
careful at the start of the race, controlling the pace and save energy
for the last part of the race. Climbing is most of the time done by
walking (except for the very first runners) and going down for
kilometers is very hard for legs, even at slow paces.
Night running is also making things a lot different. Particularly in a
quite small race like this one, it means running alone most of the
time. And, by alone, I really mean alone. You and your head lamp,
that's all.
I am very happy about the way I managed this race. I reached the 32km
mark, where an important food/drink point was organised, in a little
bit more than 3 hours 15 minutes, where I stopped about 7-8 minutes.
That was followed by about 5 kilometers downhill, at 6%, on a paved
road, which is really killing legs.
The marathon distance was reached in about 5h05, more or less what I
planned, but that race is known to be harder in its second half. And
completing a marathon, *then* knowing that you still have 2/3 of a
marathon to run is kinda challenging..:-)
Another important moment of the race was the 55 kilometer mark. This,
because this was the longest distance I ever ran in a single race (in
March, for the Paris Ecotrail race). Of course, the longer you run,
the harder are legs and what was expected happened to me: I had cramps
in both legs, at the worst moment, around km 64, when the track
brutally goes down for 150 meters in a small canyon, then goes up for
about 200 meters. Indeed, I completed kilometer 66 in....22 minutes (I
see my marathon runners friends laughing here).
This is indeed where you know if you're strong and motivated enough :
not abandoning, continue despite cramps, waiting for them to
disappear...and finally complete the race.
It was really worth it anyway : running by night is really magic. I
still remember the though moments at 5am, in the moonlight, alone on a
road...and so happy to be there..:-)
That race was the last one for me this year. I followed my plans (the
only regret being not beating my record at Berlin marathon).
Next year plans include two marathons: probably Caen ("Les Routes de
la Libert " along the D-Day beaches in Normandy) in June and another
one during Fall. I'll also push my limits a bit further with the 80km
race of Ecotrail, arriving at Eiffel Tower first floor after running
through forests in the SW area of Paris....and probably again that
70km race in November. Once you've tried ultra races, you don't want
to stop..:-)
Until the end of the year....recovery...and training. After all,
Ecotrail is only in 4 months..:-)
It s general election time again in New Zealand this year, with the added twist of an additional referendum on whether to keep MMP as our electoral system. If you re not interested in New Zealand politics, then you should definitely skip the rest of this post.
I ve never understood why some people consider their voting choices a matter of national security, so when via Andrew McMillan, I saw a good rationale for why you should share your opinion I found my excuse to write this post.
Party Vote
This blog post isn t only directed to ThinkPad owners as most notebook Linux users with Intel Core Duo 1/2 and i3/i5/i7 processors have been affected by this bug if not all. And yes, this problem is present on latest Debian Unstable and Ubuntu 11.10.
Prelude
I m owner of Thinkpad X300, great machine except the fact that just recently I replaced its 3rd cooling fan! Yea, I do a lot of compiling and it s on all the time, but still this kind of things shouldn t happen. I first linked this problem to the fact that Thinkpad fan on Linux (as of 2.6.22) always works at what s its basically maximum RPM, thus the reason there are numerous fan control scripts. My favorite one is Thinkfan, but controlling fan doesn t really help if you have a overheating problem. For matter of a fact it working on its maximum speed might only help, with its own toll.
As of kernel 2.6.38 up until 3.1 (still present) there has been a problem of power regression but besides this I had slight problem with overheating. Regarding overheating in beginning I tried reporting bugs, tried different Thinkfan configurations, blamed proprietary software such as Adobe Flash for spiking up CPU temperature, however this problem was somewhat solved. After numerous battery calibrations and as these didn t work in the end for battery life getting poorer with each day, I just blamed the factor that notebook was getting pretty old (~3 years).
Then the consumer woke up inside of me and I thought it was time to get new notebook. I laid my eyes upon ThinkPad X1 thing of beauty except one mayor drawback, its price. I did some reading on X1 and interesting enough, X300 comes with Core Duo 2 L7100 but overheating + power regression was still present even on latest Intel Core I* series. Reading this killed the consumer and woke up the hacker side.
Solution
Initial workaround to the problems of power regression is to add pcie_aspm=force besides existing GRUB boot arguments, this did help to some point but what really helped in both cases was also adding i915.i915_enable_rc6=1 or at least I thought so since this line only applies to Sandy Bridge (i3/i5/i7) and latter. In the end my /etc/default/grub looks like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force i915.i915_enable_rc6=1"and make sure you run update-grub after making these changes. Besides the arguments I used there are other ones you can use and for more info please head to Tweaks To Extend The Battery Life Of Intel Linux Notebooks . Results I ended up with such simple tweak are more then satisfactory as I got some ~45 extra minutes of battery life besides the fact that it lowered temperature by some ~10 C. Guess this also gives me extra time until I get a chance to lay my hands on X1
P.S:
After I posted this some argued that this is a workaround rather then a fix and folks at [Phoronix] just posted what they call a proper solution to this problem. Also please note although Sandy Bridge users that enable this might sometimes get a video corruption bug, i915_enable_rc6 is still supposed to get enabled by default in 3.2. So logical conclusion you can come up with is unless you re troubled by this problem, you might not want to use this work around/fix at this point. And hope it ll be fixed in future releases of your favorite Linux distribution.
One of the things I liked about Gnome 2 was the ability to run a background 'slideshow' defined in an XML file with a list of background files to give me a change of scenery from time to time.
Switching to XFCE4 I can't seem to find a simple way to do that, but the ingredients are all there:
#!/bin/sh # PANELPID=" /usr/bin/pgrep -U $ LOGNAME xfce4-panel " stealEnvironment() tr '\000' '\012' < /proc/$PANELPID/environ grep -a "^$1=" cut -f2- -d= export DISPLAY=" stealEnvironment DISPLAY " export XAUTHORITY=" stealEnvironment XAUTHORITY " /usr/bin/xfdesktop --reloadSo now I have my background image switching among my favourite photos again, and my Desktop is effectively back as it was a week ago.
Ubuntu has had an explicit goal for several cycles now to achieve
flicker-free booting: smooth graphical boot all the way through from
bootloader to the desktop, with no messy modeswitches or cuts between
text and graphics mode on the console. This is no small task, to be
sure; even getting flicker-free transitions between plymouth and X for
the KMS-capable video cards was a handful for 10.04 LTS.
So I was suitably impressed when in the course of testing for the
upcoming Ubuntu 11.10 release I
found that on a laptop with the nouveau driver, we had achieved 100%
flicker-free boot all the way from grub to X. And then I was astonished
to find the grub-kernel transition was flicker-free when using the
binary nvidia driver too!
This is in large part thanks to Colin Watson's work upstream
implementing VBE support in GRUB2, and Andy Whitcroft's adding proper
support for a vesafb fallback when no KMS video driver is found. The
architecture of how this all hangs together is now documented in the
Ubuntu wiki.
The irony is that, while nouveau gives a perfect flicker-free boot, and
the nvidia binary drivers give a boot with just one modeswitch, both of my
Intel systems show two modeswitches on boot - one between grub and the
kernel, another between the kernel and X. Something to work on cleaning up
next month, I think...
Fixing the Sandbrige MacBook Air display initialization
We left our hero with Debian installed on the MacBook Air, but with
the display getting scrambled as soon as the i915 driver loaded.
As was reported to Matthew, the problem is as simple as a lack of
the right mode for the eDP panel in the machine. This mode is supposed
to come from the panel EDID data, but for some reason the driver
wasn t able to query the EDID data, and so it decided to try some
random panel timings it dug out of the VBT tables, which are generally
supposed to be used by LVDS panels. Apple helpfully stuck valid data
there, but for some other panel one that is 1280x800 pixels instead
of the 1366x768 pixel panel in the MacBook Air.
I heard rumors that some machines would get a black screen when the
i915 driver loaded. I was fortunate my machine simply displayed a
1366x768 subset of the programmed 1280x800 mode. A bit of garbage on
the right side, and a few scanlines missing at the bottom. Quite
workable, especially after I ran fbset -yres 768 to keep the console
in the visible portion of the screen.
DDC failure
Looking through the kernel logs, the Intel driver tries to access the
EDID data and times out, as if DDC is just completely broken. This is
rather unexpected; the eDP spec says that the panel is required to
support DDC and provide EDID. Now, we ve seen a lot of panels which
don t quite live up to the rigorous eDP specifications, but it s a bit
surprising from Apple, who generally do VESA stuff pretty well.
We ve heard reports about panels reporting invalid EDID data, or EDID
data which didn t actually match the panel (causing us to prefer the
VBT data on LVDS machines). But I ve not heard of an eDP panel which
didn t have anything hanging off of the DDC channel.
But X works fine?
During early debugging, I happened to start X up. Much to my surprise,
X came up at the native 1366x768 mode. Digging through the kernel logs
after that, I discovered that EDID was successfully fetched from the
eDP panel while X started up.
At this point, I knew it was all downhill the EDID data was
present, it just wasn t getting picked up during the early part of the
driver initialization when the console mode is initialized.
eDP power management
The CPU is given complete control over the power management of the eDP
panel; sequencing through various power states and waiting appropriate
amounts of time when things change. Given the goal of keeping power
usage as low as possible, this makes a huge amount of sense.
The eDP spec is quite clear though, without power, the panel will not
respond to anything over the aux channel, and that includes EDID
data. The eDP panel power hardware in the Sandybridge chip has a special
mode for dealing with this requirement. If the panel is not displaying
data, you can supply power for the aux channel stuff by setting a
magic bit in the panel power registers.
When initializing the frame buffer, the kernel driver turns off the
panel completely so that it has all of the hardware in a known state
(yeah, this is not optimal, but that s another bug). When X started,
the panel was already running with the console mode.
Given the difference between these two states EDID querying with
the panel off failed, while EDID querying with the panel on worked, it
seemed pretty clear that the panel power wasn t getting managed
correctly. So, it seemed pretty clear that the magic power the panel
bit wasn t getting turned on at the right times.
Getting the power turned on.
I stuck a check inside all of the aux channel communication functions
to see where things were broken. This pointed out several places
missing the panel power calls. This wasn t quite sufficient to get
EDID data flowing. The remaining problem was that the code wasn t
waiting long enough after turning the panel power on before starting
the aux channel communication. A few msleep calls and huzzah! EDID at
boot time and the console had the right mode.
Making it faster
However, it turns out that the driver does this a lot, and the msleeps
required were fairly long the eDP panel wants a 500ms delay from
turning the panel power off before you can turn it back on.
I fix this by simply delaying the panel power off until things were
idle for a long time. Now mode setting goes zipping through, and a
few seconds later, the bit to force panel power on gets turned off.
Getting these bits for yourself
I ve pushed out the code to my (temporary) kernel repository
git://people.freedesktop.org/~keithp/linux
in the fix-edp-vdd-power branch. I d love to hear if you ve tried this
on either a MacBook Air or any other eDP machine from Ironlake onwards.
Next.