Search Results: "ag"

8 January 2012

Russ Allbery: Debian and popularity

In the course of a discussion on debian-project, statistics about how many computers run Debian came up. This is a metric that always bothers me a little, and this time I tried to say something about why. It feels like a comment that should have an independent existence outside of that thread, so I'll post it here as well. One of the delightful things about Debian is that the project consists of a group of people who are working together to create something that, primarily, we all want to use. Making it usable for everyone else as well is, of course, a wonderful goal and something that many of us care a lot about. But I think it's important not to lose sight of the fact that world-wide adoption on the order of Windows is not a requirement for the Debian project to be a success. Debian is successful every time I boot a system and it's running Debian, every time Debian solves my problems, every time I can fix something I ran into because it's Debian and I can help make it better. It's fun if I can get more people to use Debian, and it's important to have an influx of new blood and new ideas to keep Debian fresh and responsive, but that's about keeping Debian successful, not about making Debian successful. If we have enough developers to maintain and improve Debian even at the rate that we're maintaining and improving Debian today, to me that's a success, and I don't really care whether the percentage of Debian users in the broader computing context ever moves off of 0.02%. One of the great things about free software is that we're not a business: we don't live or die by market share, we aren't going to get bought out by someone else if we don't become a big enough fish, and we don't have to grow 10% a year or implode. It would certainly be nice to attract more people and more users and improve even faster, and I certainly wouldn't want to stand in the way of that, but it's not part of my metric of success.

7 January 2012

Petter Reinholdtsen: Second beta version of Debian Edu / Skolelinux based on Squeeze

I am happy to announce that today we managed to wrap up and publish the second beta version of Debian Edu / Skolelinux. If you want to test a LDAP backed Kerberos server with out of the box PXE configuration for running diskless machines and installing new machines, check it out. If you need a software solution for your school, check it out too. The full announcement is available on the project announcement list.

Bartosz Feński: I m even cooler

Evgeni Golov you re not the coolest fanboy. I ve got thispenguin And it s made by my girlfriend as a christmas gift. Also hand-made. Judge this ;)

Bartosz Feński: calcurse 2.9.2

Finally found some spare time to refresh my packages. Here are first results, new version of calcurse. Repackaged, using Guilt as a source format, DEP-5 for copyrights, bumped policy
standards, new *working* watchfile and new debhelper. Fixes two bugreports.

Mark Brown: ASoC updates in 3.2

Linux 3.2 was released yesterday. It s been a fairly busy release for ASoC in terms of the subsystem, including the first piece of work at moving the register I/O code over to regmap to eliminate the duplication there, but a pretty quiet one on the drivers front.

Stefano Zacchiroli: debian donations-fu

The end of the year is a period of time during which many people sit down and decide to donate some money to initiatives that pursue the public good. I have that habit myself. At the end of 2011 I've decided to donate to Wikipedia, as I consider Wikipedia to be one of the greatest achievements of humanity and I see a lot of value in keeping it running on a purely non-profit basis. (Not to mention that it's already quite annoying to see Jimbo's banners one month per year, go figure what would happen if those banners would suddenly turn into permanent advertisement banners!) You may wonder why I haven't donated to Debian, given my involvement in the project. In fact, that involvement is precisely why I didn't donate to Debian: there is some sort of sanity in keeping a distinction between causes to which I donate my spare time (the case of Debian) and those to which I donate money (the case of Wikipedia), and I like to keep that distinction. As DPL, I've the luxury of being cc:-ed on Debian donation notifications that flow through SPI, and I can also check the flow of donations to other Debian trusted organizations. This year, I've been particularly impressed by the high flow of Debian donations during the end of the year. Thank you, donors, it is thanks to your generosity that we keep many Debian activities going. Using the money people like you regularly donate to Debian we: On a more political note, I'm happy to observe that Debian incomes come almost entirely from private citizens. We do have big corporate sponsors, but their contributions tend to be concentrated as specifically earmarked donations for our annual conference. This is good for them, because they get the fancy banners on the DebConf website and at the conference. But it is also good for Debian, because a donation-based economy (as Debian's, with DebConf exception) is less likely to be influenced by the whims of a few big donors. But with (great) donations comes (great) responsibility. In particular, it comes the need of budget transparency. You can't go out soliciting donations and simply say "thanks, your contribution is appreciated". You need to show donors how their money are used, so that they can judge whether they made the right choice in donating to you or not. Whether they will donate again in the future or not granting long term sustainability to your project usually depends on that. So, if you have donated to Debian or are considering doing so in the future, here are a few of places where you can check what we have been doing with donated money: Albeit quite detailed, the above is not enough: we should do better on the transparency of Debian budget. For one thing, the above is too scattered: budget transparency should not depend on (potential) donors mixing and matching too many sources of information. Further more, the above is not even complete: SPI is not the only Debian trusted organization, and the accessibility of information about Debian budgets hosted at other organizations varies quite a bit. We've been working on improving this for the past year or so: we're not there yet, but I'm positive we can have detailed and comprehensive budgets encompassing all Debian trusted organizations published in the coming months . Why has it taken so long and what could possibly be so difficult about it? I think the cause of the delay is twofold:
  1. The disperse nature of Debian adds some difficulties to regular accounting challenges. Contrary to other FOSS projects I'm aware of, we've many different trusted organizations, each one with its own different way of reporting things. The advantage of such a setup is that we can often avoid the costs of money transfers around the world, costs in which we'd incur had we a single organization holding our assets, say, in the US. Still, having too many organizations is counterproductive. This is why for the past 1.5 years I've been working on consolidating our money assets into as few budgets as possible (avoiding, for instance, to use more than one organization per currency).
  2. We tend to be good at recruiting packaging geeks, but not so good at recruiting other kinds of geeks: budget geeks, artwork geeks, journalist geeks, management geeks, etc. But it is upon those other kinds of "geekness" that many activities of "standard" Debian geeks depend. For example: if you want to have a steady flow of new project members, you need to communicate effectively Debian values and make some buzz around them, so that you could hope they get to the right ears. If you want to organize sprints for maintainers to work together you need money donations, and to solicit donations you need a transparent budget. Etc. In the specific case of accounting, we're now lucky enough to have found "standard" Debian geeks who also have a passion for accounting and auditing; but that appaears to be, essentially, a coincidence. If we don't fix the more general problem, I believe our difficulties in recruiting "non-standard" Debian geeks might hurt us quite a bit in the long run.

Steve Kemp: Review of the Panasonic Lumix FS-16 camera

Recently I've been wanting to replace my old point and shoot camera, a Canon PowerShot A620. I've got a pair of DLSR cameras and I do frequently carry one of them out with me, but there are undoubtedly occasions where I'd rather not bother, or where I find myself wanting to take a picture without having one to hand. Unfortunately the PowerShot is pretty large itself, although significantly less so than the DSLRS I possess. (I cannot remember the last time I used the PowerShot outside my flat, that is how rarely it goes outdoors). The PowerShot has been a good camera to me for many years and the three features I liked the most: Picking a replacement camera, even with the help of fine comparison websites like snapsort.com is hard. Cameras have moved on and "improved" a lot over the last few years - to the extent that finding one with a built-in viewfinder is hard. Finding one with a built-in viewfinder and running on easily replaceable batteries was virtually impossible. Eventually I settled on the Panasonic Lumix FS16, which omits both: The way that you use the LCD or viewfinder differs pretty significantly, but the LCD wasn't as bad as I'd feared:
ViewFinder
You hold the camera to your eye, and press the appropriate buttons.
LCD
You typically hold the camera at arms length, which means you're prone to shaking your hands/arms and getting blurry shots. Because you're holding the camera relatively far away from your eyes if you have the sun at your back you're liable to need to squint.
The LCD on the Lumix FS-16 isn't amazing, but neither is it horrific and it is better than expected in dark locations. So after a week what do I think? On the whole it is a fine camera, better than the PowerShot in many ways, and while it has draw-backs none are deal-breakers:
Size
The best camera is one you have with you; on that basis this camera is a clear win being smaller, lighter, and more compact than the Canon. I've taken this camera with me, randomly, to several places and returned with useful and interesting images.
Low Light
Low light performance is pretty poor. With only one manual control you see noise if you're shooting in gloomy pubs, and outdoors. With the flash you can get acceptable pictures if you're careful - but its a tricky thing to get right. (To update this a little: Outdoors at night? No. In a pub with poor lighting you'll be alright.)
Manual Controls
The camera features precisely two manual controls:
  • "Flash on" vs. "Flash off".
  • ISO can be changed from: Auto, 100, 200, 400, 800, 1200 and 1600.
There is no notion of shutter speed, nor is there any ability to change the aperture size. (Though both these values are displayed on the screen as you take a picture I wonder why? As you can't change anything you can't use the information in any useful fashion, and presumably a non-camera-person wouldn't understand what these numbers represent.) The lack of these two controls is a little galling, but pretty common for the low-end P&S cameras.
Video Recording
There is no external MIC so sounds aren't great, but they're not horrible either. Video recordings are limited to the smaller of 8 minutes or 2Gb. So no long films, but short ones look fine. Just be aware that once you start recording focus won't change, nor will zooming work. Compared to the canon the quality is improved; but the Canon allowed you to (optically) zoom whilst recording. Here you can only zoom with your feet.
Recharging Time
When I received the camera it took about an hour to charge. The battery life seems reasonable - the level is 2/3 a week later and I've been shooting, reviewing, and deleting regularly. (Note: I never use USB to transfer pictures, I always remove the card and plug it into my PC. Whether this makes a difference to battery life I don't know.)
Controls
Physical controls are reasonable. There is a mechanical slide-switch to turn on/off. I like that, as it is less prone to being knocked by keys, change, etc. There is also a physical slide-switch to change from "shoot" to "review current images/videos". (Same as my Canon) I think this is a mistake, and don't see why it can't be a soft-button.
Full Auto
There are several modes available in the camera (remember the caveat about lack of aperture/shutter speed) I've been using both full-auto and manual modes, and both are good. Full auto would suit most people - it has clever face-tracking.
Focusing Speed
As expected this is not stellar. Walking to the corner shop the other lunchtime I found a cat in the road, I talked to her and she rubbed herself against my ankles. Could I focus fast enough to catch her looking up at me? No. For static scenes, and candid shots of people it'll suffice. For fast action and moving children probably not a chance.
On balance, the upgrade was worthwhile. ObQuote: "I don't mean to lecture and I don't mean to preach. And I know I'm not your father..." - Spider-Man

Christian Perrier: [life] [running] 2011 summary

That time of the year comes where I summarize my running activities. It's now 4.5 years that I resumed running, after nearly 10 years without active sports. Apparently, things continue to improve, though I'm logically reaching my limits in some way. I finally missed the 2500km mark by 14 kilometers, mostly because of a cold I had during the last 2 days of the year. The grand total is thus 2486 kilometers run, in 237 hours (9 days 21hours), at about 10.5km/h. The climbed height difference is 27700 meters, so about three times the altitude of Mount Sagarmatha..:-) This was achieved in 294 "activities". That seems to be a lot (nearly 1 activity per day): indeed, there are days where I have up to 4 activities, when I run to/back work, which means two runs in the morning (3+4km) and two in the evening. If I count the number of days where I had at least one running activity, this lowers to 181. In short, I ran about every 2 days. Indeed, along the year, the biggest timeframe between two runs has been 7 days. In short, I ran at least once every week during this year. The most active month was July with 272km and the less active was September with 163.5. When counted by distance, this summarizes to: When it comes at results, I ran 8 official races during the year : two "ultra" races (70km Le Puy-Firminy in November, by night and 55km Paris Ecotrail), two marathons (Paris, two weeks after Ecotrail, and Berlin in September), one 35km trail race (Trail des Cerfs in May), two half-marathons and one 12km cross-country race in my hometown. The seasons "peaks" were clearly the Ecotrail+Paris Marathon succession in March/April, the Berlin marathon in September and my longest race ever in November. Most were as successful as I expected, except maybe Berlin marathon, were I was secretly hoping to break my record (indeed, I can still be proud of running in the same race than Patrick Makau breaking the world record in 2h03'38"). An injured ankle unfortunately prevented me to prepare it as serously as I was hoping. This year was indeed the first year where I was trying to go beyond the marathon distance as another challenge. And, believe me, ultra distances are really fun (yes, running 9 hours by night *is* fun!). Indeed, I only regret not breaking one of my best times (either half-marathon or marathon). I'll try to do that in 2012. How about next^W this year? Well, my goals are currently being secured: Busy program....I cross fingers for no injury to come and disturb all this.

Jon Dowland: Flow My Tears, the Policeman Said

The Philip K. Dick Collection The Philip K. Dick Collection
I've just finished reading "Flow My Tears, the Policeman Said" by Philip K Dick, one of 13 novels collected in the Library of America's wonderful "The Philip K. Dick Collection" boxed set. This story has never jumped out at me as one to read with any particular urgency, despite the title being a reference to a composition by my namesake. I was reminded about it whilst listening to one of BBC Radio 4's "Great Lives" broadcasts, where Michael Sheen read a passage from the book. As an aside, the "Great Lives" series is a really interesting listen: I particularly enjoyed their episode on Ludwig Wittgenstein. You can get the whole series in podcast form. Back to the book. It features Dick's trademark theme of fractured realities, perhaps more so than in many of his more well-known works such as Ubik or A Scanner Darkly. It also has much better characterisation than I expect from his writing. His female characters remain as always sinister, threatening, mischevious, but they are at least fleshed out. There is a lot more of an exploration of the human condition than usual. Dick wrote that the novel begun as an attempt to explore different varieties of love. I enjoyed the mystery of the weird goings-on whilst they were mysterious, but I felt mildly let down when the explanation was eventually proffered.

Christian Perrier: Towards 100% in wheezy for debconf translations

This article could become one of my recurring "let's make noise about translators work" articles. You've been warned. In Squeeze, a few languages reached full completion of debconf strings, those "questions" that are asked during packages installation or upgrades. This can be followed here (for unstable: we don't have an online status page for testing).. Many of you, particularly those who aren't bored at reading me, know that I like pushing this friendly "competition" as a good way to encourage progress in localization of that part of Debian. As of now, we have really good and active teams that are able to maintain a great completion in this. Several of them are likely to reach full 100% completion for wheezy. Let's look at the current status: I hope this maybe gave you the idea of joining these efforts. Please pop up on one of the i18n mailing lists if you're interested, and if you don't know where to start, then debian-i18n< is what you're looking for. See you soon!

Craig Small: rpath bites me again

Debian OpenLogo

Image via Wikipedia

It s funny, in bad way, when certain sorts of bugs come back to bite you. People may remember the fun debian had with rpath issues around in the late 90s where some binaries wanted to set the path of where their libraries were located. After much contraversy the consensus was at least in Debian (with some specific exceptions) RPATH is bad and don t use it. I lived through that fun and remember hacking libtool or autoconf or some such file. The horror of those times came back to haunt me today while working on procps 3.3.2 packages. lintian was suddenly complaining that binary-or-shlib-defines-rpath for all my binaries. I ve not seen rpath set for many years and as I m also part of the upstream and never saw it set there it took me a while to work out what was going on. Certainly, my binaries were setting the RPATH, it wasn t lintian getting the wrong idea. You can see this with objdump myfile grep RPATH. If you get a hit, you got RPATH set, an empty result means no RPATH. libtool was definitely setting the rpath, with 
cc -Iproc -g -O2 -o \$progdir/\$file pmap.o  ./proc/.libs/libprocps.so \
 -Wl,-rpath -Wl,/home/csmall/debian/procps/procps/proc/.libs \
 -Wl,-rpath -Wl,//usr/lib/x86_64-linux-gnu
That s not one rpath setting but two, for double insult. Configure flags such as disable-rpath wouldn t work. I flicked back to a pure upstream archive and there was no rpath there in either the compile flags or objdump. There was obviously some sort of side-effect going on. The problem, after much testing, was in the debian/rules file: 
        ./configure \
          --build=$(DEB_BUILD_GNU_TYPE) \
          --enable-watch8bit --enable-w-from \
          --prefix=/ \
          --mandir=\$$ prefix /usr/share/man  \
          --libdir=\$$ prefix /usr/lib/$(DEB_HOST_MULTIARCH)
The problem is above, and all it was was a / . libtool does some checking to see if the library directory exists and if it doesn t silently turns on rpath. It s not smart enough to know that //usr/lib/x86_64-linux-gnu is the same as /usr/lib/x86_64-linux-gnu and so it enables rpath. Removing the slash before the usr fixed the problem. I d say this is bad behavour on libtools part. It should know that / is // or all the other alternative ways of specifying paths. Hopefully this post will stop someone else wasting their time like I did.

Paul Wise: apt-get purge defoma

Debian is finally transitioning from the unmaintained and Debian-specific font manager called defoma. The replacement is called fontconfig and it is maintained upstream and in Debian (by upstream) and is cross-distribution with wide support from our upstreams and other distributions. With the upload of libwmf 0.2.8.4-9 (thanks Lo c!) the last package in Debian sid declaring a strict dependency on defoma has removed this dependency. There is still more to do, some more bugs to file and some lenny->squeeze->wheezy upgrade testing to do. Thanks go to Christian PERRIER for slogging through and providing encouragement, bug reports and NMUs. The transition is unfortunately not without loss of functionality; TeX uses a different directory for fonts to the rest of the system. Fonts used by TeX cannot be used by the rest of the system and vice versa. This issue has always existed in Debian and other distributions and is unrelated to the removal of defoma. If your software doesn't use one of the text renderers (such as Pango, Qt or QuesoGLC) that find fonts on their own and fall back on other fonts where needed (due to missing fonts or glyphs), please switch text rendering systems. If you are unable to switch, please use fontconfig to search for font filenames rather than hard-coding them at build time. This message brought to you by the Debian Fonts Task Force. We welcome people who want to help us maintain font packages or improve support and quality assurance for fonts and font related software.

Craig Sanders: fstrim and XFS

Does anyone use fstrim on an XFS formatted SSD partition? I ve got two systems with XFS root partitions that fstrim seems to do (almost) nothing on, but it seems to work correctly on another system with formatted with ext4.

Details follow: System 1 is an AMD 1090T with a Patriot Torqx 2 128GB SSD. System 2 is also an AMD 1090T with a Patriot Pyro 120GB SSD. I ve been running both for several months without any TRIM support because I (incorrectly) assumed that XFS support for TRIM was automatically enabled. I ve recently discovered that it s not, and also that it s better performance-wise to run fstrim regularly from cron for batch-mode TRIM operations. Anyway, System 1 takes over 7 minutes to run fstrim, and claims to have trimmed about 16GB .but if i run it again it still takes over 7 minutes and claims to have trimmed about the same amount of data (slightly less). 
# time fstrim -v /
/: 16777764864 bytes were trimmed
real 7m31.089s user 0m0.004s sys 0m9.705s
# time fstrim -v /
/: 16772276224 bytes were trimmed
real 7m8.973s user 0m0.000s sys 0m9.165s
System 2 takes over 28 minutes to run fstrim and claims to trim about 51GB of data (it s had an SSD for a lot longer than System 1. It also has /home on /, whereas System 1 has /home on a separate disk). Similarly, running it again immediately afterwards also takes about the same amount of time and claims to trim about the same amount of data. 
# time fstrim -v /
/: 51594948608 bytes were trimmed
real 28m19.832s user 0m0.000s sys 0m6.264s
# time fstrim -v /
/: 51499814912 bytes were trimmed
real 28m29.230s user 0m0.000s sys 0m6.328s
(interestingly, the Pyro is a *much* faster SSD than the Torqx2. it s SATA3 and is capable of about 500-550MB/s. The Torqx 2 is SATA 2 and is capable of about 230MB/s seems as if TRIM speed is roughly the
same for both drives, proportional to the amount of data to be trimmed. almost certainly limited by the flash speed with the internal controller differences being negligible for this task) OK, so it seems as if fstrim claims X bytes were trimmed, but it doesn t actually happen. On a third system, I have / on an SSD formatted with ext4. System 3 is an Intel Xeon E5607, and the SSD is an OCZ AGILITY3 120GB. 
# time fstrim -v /
/: 14267424768 bytes were trimmed
real 2m25.222s user 0m0.000s sys 0m0.636s
# time fstrim -v /
/: 0 bytes were trimmed
real 0m0.001s user 0m0.000s sys 0m0.000s
on ext4 fstrim seems to work as expected. The OCZ SSD is also a LOT faster than the Patriot SSDs (roughly 14GB trimmed in 2.5 minutes). anyone seen this before? is it a bug in XFS SSD handling? or am i just misinterpreting the results? my google-fu can t find anyone with similar problems, just mailing list articles and an XFS wiki page saying that it works, and that running fstrim regularly is recommended over using the discard mount time option. fstrim and XFS is a post from: Errata

6 January 2012

Mark Brown: regmap updates in 3.2

Version 3.1 of the Linux kernel was the first release to include regmap support and only included a bare minimum of features in order to ease review so version 3.2 has been a pretty big one for regmap development with some pretty major features being built on top of the core code.

Steve Kemp: Tonight I've mostly been using Sinatra

This evening I've mostly been using Sinatra to build a little file storage service which uses a REST API. That means I can upload a file: 
skx@birthday:~/hg/sinatra$ curl -X PUT -F file=@/etc/fstab http://localhost:4567/
 "id":"dbd1bdc11b5a1a8e80588a135648b4c2edffb49a","path":"/"
Download that same file: 
skx@birthday:~/hg/sinatra$ curl -X GET -F id=dbd1bdc11b5a1a8e80588a135648b4c2edffb49a  \
   http://localhost:4567/
# /etc/fstab: static file system information.
..
/dev/cdrom        /media/cdrom0   udf,iso9660 user,noauto     0       0
Get an index of files: 
skx@birthday:~/hg/sinatra$ curl http://localhost:4567/
[ "id":"dbd1bdc11b5a1a8e80588a135648b4c2edffb49a","type":"file" ]
And finally we can delete a file: 
skx@birthday:~/hg/sinatra$ curl -X DELETE -F "id=dbd1bdc11b5a1a8e80588a135648b4c2edffb49a" \
  http://localhost:4567/
Removed
We can also upload to different paths so we can replicate a file-system if we wanted to. (I added in "type" to hold either "file" or "directory", though I guess if we were to code up a FUSE client we'd want to store things like ctime, UID, GID, etc. THe list operation will show both files and sub-directories) The code was trivial once I got the hang of Sinatra, and I'm pretty pleased with it so far. I don't yet need to use it for anything, but I'm thinking of unifying the way that I store images on a couple of sites - and fetching them via JSON and Javascript might be an option this was an experiment in that direction. (Though I'd probably want to hook in rsync so we replicated the eventual upload location for safety.) In other news I've been all organized and upgraded the kernel on my guest: 
steve@steve:~$ uptime
 22:00:28 up  4:18,  1 user,  load average: 0.14, 0.05, 0.05
steve@steve:~$ uname -r
3.2.0-kvm-hosting.org-i386-20120106
So for once I'm up to date with a cutting edge kernel. Happy times. ObQuote: "How you expect to run with the wolves come night when you spend all day sparring with the puppies? " - The Wire (Omar)

Matthew Garrett: Firmware bugs considered enraging

Part of our work to make it possible to use UEFI Secure Boot on Linux has been to improve our EFI variable support code. Right now this has a hardcoded assumption that variables are 1024 bytes or smaller, which was true in pre-1.0 versions of the EFI spec. Modern implementations allow the maximum variable size to be determined by the hardware, and with implementations using large key sizes and hashes 1024 bytes isn't really going to cut it. My first attempt at this was a little ugly but also fell foul of the fact that sysfs only allows writes of up to the size of a page - so 4KB on most of the platforms we're caring about. So I've now reimplemented it as a filesystem[1], which is trickier but avoids this problem nicely.

Things were almost working fine - I could read variables of arbitrary sizes, and I could write to existing variables. I was just finishing hooking up new variable creation, but in the process accidentally set the contents of the Boot0002 variable to 0xffffffff 0xffffffff 0x00000000. Boot* variables provide the UEFI firmware with the different configured boot devices on the system - they can point either at a raw device or at a bootloader on a device, and they can do so using various different namespaces. They have a defined format, as documented in chapter 9 of the UEFI spec. At boot time the boot manager reads the variables and attempts to boot from them in a configured order as found in the BootOrder variable.

Now, obviously, 0xffffffff 0x00000000 is unlikely to conform to the specification. And when I rebooted the machine, it gave me a flashing cursor and did nothing. Fair enough - I should be able to choose another boot path from the boot manager. Except the boot manager behaves identically, and I get a flashing cursor and nothing else.

I reported this to the EDK2 development list, and Andrew Fish (who invented EFI back in the 90s) pointed me at the code that's probably responsible. It's in the BDS (Boot Device Selection) library that's part of the UEFI reference implementation from Intel, and you can find it here. The relevant function is BdsLibVariableToOption, which is as follows (with irrelevant bits elided):
BdsLibVariableToOption (
  IN OUT LIST_ENTRY                   *BdsCommonOptionList,
  IN  CHAR16                          *VariableName
  )
 
  UINT16                    FilePathSize;
  UINT8                     *Variable;
  UINT8                     *TempPtr;
  UINTN                     VariableSize;
  VOID                      *LoadOptions;
  UINT32                    LoadOptionsSize;
  CHAR16                    *Description;
  //
  // Read the variable. We will never free this data.
  //
  Variable = BdsLibGetVariableAndSize (
              VariableName,
              &gEfiGlobalVariableGuid,
              &VariableSize
              );
  if (Variable == NULL)  
    return NULL;
So so far so good - we read the variable from flash and put it in Variable, Variable is now 0xffffffff 0xffffffff 0x00000000. If it hadn't existed we'd have skipped over and continued. VariableSize is 12.
  //
  // Get the option attribute
  //
  TempPtr   =  Variable;
  Attribute =  *(UINT32 *) Variable;
  TempPtr   += sizeof (UINT32);
Attribute is now 0xffffffff and TempPtr points to Variable + 4.
  //
  // Get the option's device path size
  //
  FilePathSize =  *(UINT16 *) TempPtr;
  TempPtr      += sizeof (UINT16);
FilePathSize is 0xffff, TempPtr points to Variable + 6.
  //
  // Get the option's description string size
  //
  TempPtr     += StrSize ((CHAR16 *) TempPtr);
TempPtr points to 0xffff 0x0000, so StrSize (which is basically strlen) will be 4. TempPtr now points to Variable + 10.
  //
  // Get the option's device path
  //
  DevicePath =  (EFI_DEVICE_PATH_PROTOCOL *) TempPtr;
  TempPtr    += FilePathSize;
TempPtr now points to Variable + 65545 (FilePathSize is 0xffff).
  LoadOptions     = TempPtr;
  LoadOptionsSize = (UINT32) (VariableSize - (UINTN) (TempPtr - Variable));
LoadOptionsSize is now 12 - (Variable + 65545 - Variable), or 12 - 65545, or -65533. But it's cast to an unsigned 32 bit integer, so it's actually 4294901763.
  Option->LoadOptions = AllocateZeroPool (LoadOptionsSize);
  ASSERT(Option->LoadOptions != NULL);
We attempt to allocate just under 4GB of RAM. This probably fails - if it does the boot manager exits. This probably means game over. But if it somehow succeeds:
CopyMem (Option->LoadOptions, LoadOptions, LoadOptionsSize);
we then proceed to read almost 4GB of content from uninitialised addresses, and since Variable was probably allocated below 4GB that almost certainly includes all of your PCI space (which is typically still below 4GB) and bits of your hardware probably generate very unhappy signals on the bus and you lose anyway.

So now I have a machine that won't boot, and the clear CMOS jumper doesn't clear the flash contents so I have no idea how to recover from it. And because this code is present in the Intel reference implementation, doing the same thing on most other UEFI machines would probably have the same outcome. Thankfully, it's not something people are likely to do by accident - using any of the standard interfaces will always generate a valid entry, so you could only trigger this when modifying variables by hand. But now I need to set up another test machine.

[1] All code in Linux will evolve until the point where it's implemented as a filesystem.

comment count unavailable comments

Mirco Bauer: Smuxi 0.8.9 "One Giant Leap" Release

Smuxi - IRC Client Smuxi 0.8.9 "One Giant Leap" Release
Just in time for 2012 I am very pleased to announce Smuxi 0.8.9 codenamed "One Giant Leap". During the development 56 bug reports and 33 feature requests in 593 commits were worked on making this release a major milestone of the Smuxi project. At the Chaos Communication Congress (28C3) in Berlin I was doing the final development sprint to get 0.8.9 done, which was a very intensive and refreshing experience. Here are the highlights of this release: Development Builds / Rolling Releases After the 0.8 release it became clear that a continious and short development -> test cycle is important to keep the project going quickly. At some point I have received requests if the project is dead while it was more active than ever. The lack of new releases (for about 15 months) lead to this wrong impression. Thus Smuxi can be obtained from development builds now. This includes daily builds for Debian (Squeeze, Wheezy, Sid), Ubuntu (Lucid, Maverick, Natty, Oneiric, Precise) and Windows. Thanks goes to Hannes Tismer for providing the Windows autobuilder and to Canonical for the PPA autobuilder. We invite everyone to use these daily builds to keep track of the latest development of Smuxi. Issues and regressions are fixed in a very short period (usually the same day). Thanks to our users who ran development builds and reported issues which led to many bug fixes prior to this release. On the other hand one of my New Year's resolutions are to "release early, release often" So there should be no nerd left behind... Screenshot of Smuxi 0.8.9 on Mac OS X Mac OS X support With the help of Steven McGrath (Steve[cug]) who created the initial Mac OS X installer for Smuxi we now have official support for Mac OS X. The download page contains the instructions how to obtain and install Smuxi on Mac OS X. This makes the 4th platform where Smuxi can be used on besides Windows, Linux and *BSD. For now Smuxi 0.8.9 doesn't feel as native as it could as it relies on the GTK+ port. We are looking into enhancing the experience though, just stay tuned. Chat History on Disk (Beta) The most exciting feature in this release I think are the "persistent message buffers". With this feature I could solve one of the biggest drawbacks IRC ever had: IRC does not retain any messages you have sent or received. All messages are only relayed to all users. The issue is that if you close your IRC client or even just leave a channel, all your received messages are gone. One workaround in most clients was to create text log files which then contains the chat history, but it is annoying and not user-friendly to open some text file somewhere from your disk to read the history outside of your IRC client. Now with Smuxi 0.8.9 you no longer have this issue, all chat history gets automatically written and read to a message database when you start Smuxi, join channels or open queries! As this feature is not fully stable yet it is not enabled by default. If you want to try it go to: File -> Preferences -> Interface and change "Persistency Type" from "Volatile" to "Persistent", hit OK and restart Smuxi. Now all messages are saved into the database and will automatically be shown. Click here for a screencast of this feature Jabber / XMPP Support (Beta) You probably have friends not on IRC and Twitter, say on Jabber, gTalk or Facebook? This is where the new XMPP engine of Smuxi comes into play. You can send and receive messages to/from them now! The implementation is far from complete, though. It has no buddy list for example and needs only to be treated as a technical preview of what will be coming in future Smuxi releases. Click here for a screencast of this feature Screenshot of Smuxi's Text Interface Text Interface (Alpha) This is the first release that contains a text frontend based on the STFL library. STFL is a library that uses ncurses to draw text based user interface using a markup language (like Glade for GTK+). This frontend is in early alpha state and lacks a lot of interface features and likes to crash. It is still included to attract potential developers who want to enhance this frontend. The frontend can be enabled by passing --enable-frontend-stfl to the configure script and then by executing smuxi-frontend-stfl. NetworkManager Support Everyone with a laptop knows how annoying it can be to suspend and resume when network based applications suddenly go crazy because they have lost the connection and either spew errors or take forever to get back in shape. Smuxi will now detect the network state right away with the help of the new Network Manager support. It automatically reconnects when needed right away for you. Next Generation Internet Support You can now connect to IRC servers using the IPv6 protocol Enhanced Find Group Chat Support Users had real issues to find out how to search for channels, thus Bianca Mix added a neat feature. The /list command will now simply open the Find Group Chat dialog for you. This way everyone used to IRC will find it in no time. Searching for channels on freenode wasn't working correctly, this is now fixed. Smuxi also supports the SAFELIST feature of the IRC protocol now which allows to retrieve a full channel list and do client side search which makes consecutive searches much faster. Enhanced Windows Experience For a long time you could not use Smuxi with the latest GTK# version of 2.12.10 on Windows. The issue was that Smuxi relied on SVG support which 2.12.10 no longer had. Smuxi is no longer using SVG instead it uses pre-scaled PNG images thus it works just fine with GTK# 2.12.10 on Windows now. At the same time the issue that the maximized state of the main window was left when restoring from task bar is fixed with GTK# 2.12.10. Screenshot of Fixed-Sys vs Consolas font Smuxi used by default the FixedSys font on Windows to give it the typical IRC look most people are used to. Since Windows Vista there is a better console-like font available called Consolas. Smuxi will now use the Consolas font instead on Windows Vista or later. Another important enhancement is that Smuxi no longer has issues with multiple GTK+ installs on the same computer, which was getting more common with more popular ported GTK+ applications such as GIMP or Pidgin. SSL for IRC fixed IRC with SSL was only working with the default port of 6697. Thanks to Jo Shields now any port can be used with SSL. Crash Related Issues Desktop notifications could crash Smuxi in case of errors related to the notification system or an absent notification daemon. There was a chance that the crash dialog simply disappeared which made reporting bugs more difficult no longer happens. Rapid use of ctrl+w, /window close (Jimmie Elvenmark) and opening the Find Group Chat dialog on the Smuxi tab do no longer crash. Also number-only network names, /network switch freenode and GTK+ install without SVG support no longer lead into a crash. Enhanced Notice Handling Notices will no longer open query tabs for you instead it will show them on tabs you share with the person who sent it with the server tab as fallback. This also avoids ChanServ, NickServ and spammy IRCop tabs. Twitter fixes Twitter made some changes to their API which broke the Twitter support of Smuxi 0.8. This was taken care of and also a few other issues were solved allowing Smuxi 0.8.9 to work smoothly with Twitter again. Extended Keybindings Smuxi allows now to use the ctrl+tab / ctrl+shift+tab and ctrl+n / ctrl+p keys to switch tabs. The keybindings still work even with a hidden menu bar now. Smuxi Server specific highlights More interactive and much faster synchronization When connecting to a smuxi-server you had to wait till Smuxi finished the synchronization before you could use the interface. Also you could not tell how far the synchronization was and just had to wait till it was completed. With Smuxi 0.8.9 the connect just takes a few seconds and all chats are synchronized in the background with a progress bar so you can use the interface from the first moment on and know how far it is. The speed how much it takes to synchronize all chats also reduced drastictly by 400%! Click here for a screencast of this feature More background communication When using a smuxi-server the interface sometimes had load times like when opening the preferences or when using the nickname completion (Andrew Kannan). These operations are done in the background and no longer blocks the interface. Also when the communication is lost to the smuxi-server the frontend will now automatically reconnect to it in the background. Low Bandwidth Mode When it comes to mobile internet connectivity such as UMTS/HSDPA, Edge and GRPS it can be a real pain to connect to the smuxi-server as it has to transfer all the messages over that. If you just want to ask someone you know then you don't need any old messages to do that. With the "Low Bandwidth Mode" you can now connect to the smuxi-server without loading old messages which makes the connect very quick. You find this option in the engine connect dialog. Stable Protocol Initially I didn't plan to make the protocol of Smuxi stable before the 0.9 release, but as it turned out the 0.8 protocol was good enough to still use it and for that reason Smuxi 0.8.9 is still compatible with 0.8. The 0.8 protocol will see no breakages, instead the next protocol will be on-top or opt-in of the current one. This means future Smuxi versions stay compatible with it. Shutdown Command You can now shutdown the smuxi-server if you like using the /shutdown command. It it safe to use the command, it will do a clean shutdown sequence for you. For example it makes sure all messages are written to disk in the case of enabled persistent message buffers. If you have your smuxi-server daemon monitored (e.g. with runit) it can also automatically be restarted and upgraded this way. Built-in SSH Keyfile Support It is no longer needed to fiddle with the .ssh/config file or pagent to get SSH key authorization working. You can now simply tell Smuxi which SSH keyfile you want to use to connect to your smuxi-server. Updated Translations
  • Catalan (Siegfried-Angel Gevatter Pujals)
  • Danish (Joe Hansen)
  • Finnish (Kalle Kaitala)
  • French (Cl ment Bourgeois)
  • German (Bianca Mix)
  • Italian (Vincenzo Campanella)
  • Portuguese (Americo Monteiro)
  • Spanish (Castilian) (Ricardo A. Hermosilla Carrillo)
New Translations
  • Chinese Simp (Dean Lee)
  • Slovak (Tom Vadina)
  • Swedish (Jimmie Elvenmark)
  • partially Russian (Aleksandr P)
  • partially Turkish (Umut Albayrak)
  • partially Urdu (makki)
Contributors Contributors to this release are the following people:
  • Mirco Bauer (497 commits)
  • Tuukka Hastrup (10 commits)
  • Bianca Mix (10 commits, translations)
  • Cl ment Bourgeois (8 commits, translations)
  • Andrius Bentkus (5 commits)
  • Carlos Mart n Nieto (3 commits)
  • Jimmie Elvenmark (3 commits, translations)
  • Hannes Tismer (1 commit)
  • Jonathan Pryor (1 commit)
  • Jo Shields (1 commit)
  • Siegfried-Angel Gevatter Pujals (translations)
  • Dean Lee (translations)
  • Aleksandr P (translations)
  • Americo Monteiro (translations)
  • Andrew Kannan (translations)
  • Joe Hansen (translations)
  • Kalle Kaitala (translations)
  • makki (translations)
  • Ricardo A. Hermosilla Carrillo (translations)
  • Tom Vadina (translations)
  • Umut Albayrak (translations)
  • Vincenzo Campanella (translations)
Thank you very much for your contributions to Smuxi! After reading this whole pile of text, head over here and grab this smexy stuff!
Posted Sun Jan 1 22:58:29 2012
Copyright 2004-2009 Mirco 'meebey' Bauer

Vincent Fourmond: Graphical connection to a Mac from Linux

For my lab work, I have developed an (almost) cross-platform program based on Qt4 that help us analyze our data. One of the motivations to use Qt was the ability to port the program to other platforms, and in particular MacOSX (half of my team uses them). After installing the required development tools using MacPorts (mind you, the MacOS version of the development tools, not the X11 one), I was able to compile and run the program without a single code change on my bosses' Mac. But here come problems: several things do not work the same way in Mac and in Linux (whereas it should, I think), so additional tweaking and debugging will be necessary.This is where the problem comes in: I don't own a Mac and don't intend to, so I need to connect to my bosses' Mac in order to perform testing. How can I connect to a Mac display ? X11 connection won't work, since my application is a Mac application and not a X11 one. I had him turn on screen sharing (the most basic tick box), which sets up a VNC server on the Mac. Unfortunately, when I connect using the command-line VNC clients available for debian, ie vncviewer (from the packages xvnc4viewer or xtightvncviewer), I get the following problems:

~ vncviewer chrismac
VNC Viewer Free Edition 4.1.1 for X - built Mar 10 2010 22:31:05
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Wed Dec  7 10:40:41 2011
 CConn:       connected to host chrismac port 5900
 CConnection: Server supports RFB protocol version 3.889
 CConnection: Using RFB protocol version 3.8
 CConnection: No matching security types
 main:        No matching security types

The good news is that remmina is able to connect graphically, although for me it required that I set the display depth to 24 bits (else it seems to connect, but the connection dies immediately). Great, I'll be able to debug, then...
Edit: after a while, I found out that remmina had some drawbacks when connecting to a Mac, such as, at least in my case, a weird problem with Shift: once I hit Shift, I'm never able again to type in lowercase characters, which is quite painful. I tried also Vinagre, who handled that better (but had some quite painful freezing moment), so I must say that I finally found a client I'm happy with: gtkvncviewer.

Bartosz Fe&#324;ski: Update your packages

I thought it s going to be an easy task. lintian told me it s not so easy I have to review all my packages, bump their stadards policy, comply with DEP-5, use new quilt format and so on That s not an easy task with more than twenty packages. Yeah I know it s not requirenment, but still want to do that.

Alexander Reichle-Schmehl: Release Critical Bug report for Week 01

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
In Total:1614
Affecting Wheezy:945
Wheezy only:148
Remaining to be fixed in Wheezy:797
Of these 797 bugs, the following tags are set:
Pending in Wheezy:47
Patched in Wheezy:135
Duplicates in Wheezy:45
Can be fixed in a security Update:28
Contrib or non-free in Wheezy:10
Claimed in Wheezy:0
Delayed in Wheezy:6
Otherwise fixed in Wheezy:50
Ignoring all the above (multiple tags possible) 532 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 845 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Next.

Previous.