Search Results: "will"

26 January 2008

Andrew Stribblehill: ls color considered harmful

This is a rant I have made many times in person: far too many to count. Since I can't possibly warn everybody who might be affected by this, face to face, I'm hoping you will all spread the word. The problem To begin with, I should say that ls --color is useful. It can show you which items in your directory listing are directories, symlinks, broken symlinks, device nodes, named pipes, whatever. I am glad that it exists. However, let’s consider the basic action of ls. It is, of course, to display which files and directories exist in a directory. This is really quick and easy in Unix. Simply use the libc function opendir() then just readdir() till it returns NULL and errno is 0. In terms of syscalls, this is an open(), one or two read()s and a close(). When you turn on the color option, every directory item incurs the weight of an extra stat() call to see what it is. Worse still, if it’s a symlink, ls will obligingly bound across to the thing linked to, to check it exists. If this causes your automounter to wake up and mount something remote, that’s quite an overhead. If your mount hangs because the remote filesystem is unavailable, you can say goodbye to that process; it'll be stuck blocking on a syscall that will never return. A partial solution To fix the symlink problem, here’s what you do. ls was written to avoid chasing symlinks if configured not to. Check your environment variables for the LS_COLORS variable with: $ env grep ^LS_COLORS If it exists, you have a config file for colour ls: you should edit /etc/DIR_COLORS* or copy it to $HOME/.dircolors and edit it there. Otherwise, type: $ dircolors --print-database > $HOME/.dircolors The edit you need to do is to remove or comment out the ORPHAN line from the file. Unless you were able to edit the file in /etc, you now need to make sure that this new $HOME/.dircolors file is used. In your shell login script (.bash_login for bash and .login for (t)csh, put the line: eval dircolors $HOME/.dircolors (Note that these are backticks, not apostrophes.) Next time you log in, you'll be able to use colourful ls without fear of a remote filesystem freezing your directory listings. In conclusion Use ls --color when you need it, but as with all powerful tools, use it with care. Corrections: James pointed out that to dump the default config it is –print-database not –print-directory.

Biella Coleman: Spa Audaciousness

New York is a pretty crazy city but who knew there was the room for this type of roomy spa crazinesss?. All I gotta say is check out the different, (some very high-tech), sauna rooms. I gotta check it out. Soon. Update: A small crew went and it is, I think, the best 30 bucks one can spend in the greater New York area. The saunas, baths, and wrist watch tech-keys were nothing short of great, as was eating Korean food after a series of saunas. I can’t wait to go back during the week when I am sure it will be a little more calm.

Martin F. Krafft: Thai massage lesson learnt

Here s an important lesson I learnt today: if you are in Thailand and still feel the effects of a not-so-recent knee and wrist injury, you should, before the massage, learn how to say in Thai: please, go easy on my knee and my wrist. The rest of my body likes brutal Thai massages (well, learnt to like them), but when the knee is bent and twisted and my face inadvertedly morphes in agony, the typical massagist will apologise furiously and take it easier from now on not what I want, at all. Three Thai hanging out on the street, asked individually, could not translate I like it rough but my knee does not. Instead, they just giggled and wanted to know where I was from and where I was going and whether I wanted a massage or attend porn shows or buy drugs or well, that about lists it all. No blame for the average Thai s broken English, it s still better than my command of their language.

Julien Danjou: Moving old projects to git

I finally did it. Most of my small and personal projects (telak, sysrqd and mod_defensible) were maintained in my home-svn-repository. This had the side effect that I did not have a good overview of the current status of the project, and that I never though about tagging releases. I used git-svnimport to move this stuff to git, with great success. Now, I see that only one release on three is tagged correctly, bad me. They are now on my git server. But with a better tool like git I'm sure I will be more precise when I will work on that source code, so it was time to switch. And now my source code is public, which is far better than before.

25 January 2008

Meike Reichle: Look Ma I'm on Podcast!

I recently had my first podcast experience, when I was approached by Mario Heide of the German podcast pofacs.de ("Podcast für alternative Computer Systeme") who asked me for an interview. To be true, I first had to read up a bit on podcasts, but after a little research I was very happy to accept his invitation. We did the interview via Sykpe, which wasn't exactly optimal sound-wise but still very nice. We talked mostly about Debian, primarily from a first time user point of view. The (German) interview is online now and will, as I just heard, also be included on the next LinuxUser magazine CD. If you do understand German also have a look at the other podcasts there and thanks again to Mario for giving me the opportunity to brag a bit about Debian.

Dann Frazier: Etch and a half

For those unfamiliar with the project, etch-and-a-half has the goal of making the existing etch release work on more hardware, but with minimal risk to existing etch users. This will be done by *adding* new kernel packages to the existing release. Kernel selection isn't final yet - the kernel team would like to use 2.6.24 if it proves itself stable in time; 2.6.22 is the backup choice. etch-and-a-half isn't restricted to kernel updates by-definition; new X drivers, or proven-safe X driver updates are reasonable candidates as well (though at this point, no changes have been proposed). An oft-asked question is around updating desktop packages, e.g. new versions of GNOME/KDE. This is beyond the scope of etch-and-a-half because it introduces a great deal more change than just additional hardware support, its wouldn't be a transparent upgrade to existing etch users, and we cannot say with a high level of confidence that it wouldn't introduce regressions for existing users. That said - a localized change to a package that adds support for new hardware and clearly doesn't break existing hardware is a valid candidate for any stable release. Such requests should be submitted to the SRM team like any other stable update request. The current plan for etch and a half is to release as part of a point release. 4.0r4 is the planned point release, since 4.0r3 is planned to have a quick turnaround to fix issues with 4.0r2. This means that pre-release bits will be made available via proposed-updates - testers are greatly appreciated. There is no plan to add support for etch-and-a-half to the etch branch of d-i. Rather, support will likely be added in a beta of the lenny installer. A wiki page exists here, and a coordination list has been setup on teams.debian.net.

Neil Williams: New uploads and embedded issues in Debian

I've got an upload of gpe-tetris pending - see 462306 - to provide a smaller version of the popular falling blocks game for embedded devices. One or two things crop up from this package:

  1. popcon - a lot of maintainers put a lot of store by popcon results but the popularity-contest package is perl and perl is not available in Emdebian (it is thrown out along with "Essential: yes" for space reasons). Writing a replacement for popcon may not be particularly sensible either because embedded devices, although often left running for long periods in a "low power" mode, often have rare and intermittent access to any form of internet connection. This could easily result in maintainers thinking that because a package has few (or even zero) popcon figures, it is not used. On the contrary, the package could simply be used on devices that either do not support perl (Emdebian) or which do not have the ability to file popcon reports despite being able to support perl. (With the probability that GPEPhone will be added to the GPE support already in Debian, users may not wish to have popcon "phoning home" because it would likely cost real money to do so - even if a C version of popcon was written.) So I'm posting this here so that I can refer back to this post if queries arise later on.

  2. GPE apps on Debian - gpe-tetris is inherently designed for small devices with small screens and relatively slow processors, just like the majority of GPE. gpe-tetris is also designed to be usable on a handheld device where the lack of a normal keyboard can make game play awkward. As a result, playing gpe-tetris on an average Debian box is likely to appear trivially easy and the "progression" between levels would appear very slow in comparison with the tetris available in GNOME or KDE. This is deliberate and is expressly intended to allow the game to be playable on embedded hardware that has fiddly little keys. (I'll be adding this to the manpage and a brief summary of this to debian/control.) This does give the opportunity for a little sleight-of-hand such that a device could be provided with a highscore file created on a much more powerful device and so preventing any new highscores being set, but please don't do that - play nicely!

  3. small apps != bad code - Yes, lots of GPE packages are very small, some were clearly written originally as "demos" or during the process of learning how to write larger packages. This does not necessarily mean the packages contain bad code. I will feed back sensible patches to upstream to resolve flaws in the code but please do not think ill of the packages merely because the source code looks "trivial" compared to a GNOME package.

  4. dpkg-shlibdeps - one issue that I must begin to track after Fosdem will be to aggregate the "foo should not be linked against" messages from dpkg-shlibdeps in GPE packages and try to build a complete picture, in case there is a real possibility of completely dropping some packages that always seem to appear in that list due to the pkg-config --libs gtk+-2.0 listing. If so, I'll begin discussions with upstream about manually specifying the GTK_LIBS variable whilst retaining the PKG_CHECK_MODULES macro that ensures that the -dev package is available in the cross-building environment. This is likely to be some form of database-query mechanism - feeding data in from grepping the build logs, building a query from the list of packages to be used for a specific Emdebian root filesystem (machine/variant specific) and then spitting out whether particular package sets can have particular targets removed. If anyone fancies working on that already, the Debian version of the information is already available via the buildd network and the Emdebian cross-build results will not differ greatly from those at this stage.

Other uploads include updates of libgpeschedule, gpe-calendar and gpe-clock if gpe-announce makes it through NEW as expected. Updates for emdebian-tools and apt-cross and likely new releases for QOF, gpe-expenses and pilot-qof.
debcheckout compliance
In other developments, I've worked out how to specify Vcs-Cvs correctly such that debcheckout can find the repository data correctly. Sadly, vim syntax highlighting does not help with the CVS version but the CVS syntax is:

Vcs-Browser: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-view/?cvsroot=dpkg-view
Vcs-Cvs: :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/dpkg-view dpkg-view

Note the colon prefix to pserver and the space between the repository login location and the module name. Remember to omit the "-d" - debcheckout will add that for you (and won't check to see if you have already specified it).

Neil Williams: collaborative maintenance, source packages, patches and other disagreements

Firstly, I haven't been following debian-devel as closely as in recent months and some things have passed me by. Secondly, I am rather pre-occupied with my own small world of Embedded Debian. One result of this is that I wasn't really paying attention to arguments over the source package format and took longer than I expected to respond to a request to take a look at tslib - a touchscreen library for embedded devices. When I did start work on it I managed to upset Joey Hess by implementing dpatch support which he had recently decried as unhelpful. I also added some extra fuel by getting myself in a two-and-eight over svn-buildpackage and it's broken bias towards native packages.
I happen to disagree with the idea that maintainers should alter upstream files directly, merely relying on the .diff.gz or some weird $RCS runes. Instead, I seek to ensure that the .diff.gz contains no changes outside the debian/ directory. I'm not happy keeping the entire upstream source in yet another RCS (for any reason) and would much rather make updates to my Debian packages by simply copying the debian/ contents into an unpacked pristine upstream source (preferably via uscan). I find it really useful to simply check out the latest CVS/SVN/$RCS, dump debian/ into place and call 'debuild' when testing various upstream development issues. Maybe this is because I have relatively few Debian packages that need debian/patches/* and certainly few that need more than a couple of patch files. It certainly has a lot to do with my embedded work where I need to make changes to the contents of debian/ to make an Emdebian package whilst retaining the same upstream code as is used in existing embedded projects like Open Embedded and Familiar. I don't want to be chasing changes through the upstream source - I want all the changes in a single place so that I can create Emdebian patches against the Debian source. (I'd rather not have patches in the Debian source at all but this is only realistic for either my own packages or those released as part of GPE for various embedded-native compatibility reasons.) I certainly do not want any Debian $RCS to be lumbered with yet another set of upstream sources that will always be out of date compared to the real upstream sources.
I am also a great fan of CDBS - much to the horror of some in Debian - primarily for one very simple reason, it cross builds so easily. Considering my workload, it should not be a surprise that the ability to support cross building without requiring any changes to the Debian package is incredibly persuasive when selecting a build system for a package of my own. debhelper really is woeful at cross building - each package needs customised cross building support painstakingly devised and tested, making script-based mass bug filing impossible. CDBS shows that with a little wrapping, debhelper can support cross building in a clean and completely non-intrusive manner.
This means I can concentrate on those changes that are actually important - the changes that provide the benefits of cross-building and justify the effort of actually cross building the entire dependency chain: the ability to fully control Debian-specifics like "Essential: yes" and to disable, modify or adapt components of any package such that the installed system has a fraction of the dependencies of the Debian version of precisely the same package. TDeb support is good too but that can be implemented against any build, it doesn't need to be a cross build.
Sadly, the end result of all this for tslib is that it will be removed from collab-maint very soon, Joey does not wish to be associated with the new version because although it includes some features which he is happy to see implemented, my use of dpatch and the hacks I had to devise to workaround svn-buildpackage do not fit with his workload patterns. Once tslib is removed from collab-maint, these hacks become redundant and I can use my normal packaging methods. Equally, his methods (in particular the lack of debian/patches/*) do not fit with my workload patterns and although I do not have as many packages as Joey, I have enough (when the 200 Emdebian source packages are also considered) to make the issue into a blocker. The new version of tslib uses the upstream SONAME and adds a -dbg package so it will spend some time in NEW. I am also likely to migrate it to CDBS once removed from collab-maint.
I suspect these issues will be revisited during discussions at Fosdem 2008 where I'll be presenting two talks - one in the Debian developer room and one in the Embedded developer room. Feel free to harangue me if you feel strongly that there is a sane way of cross building that does a better job than CDBS. :-)

MJ Ray: Links for 2008-01-25

Nick Leeson: The financial storm is not over yet
Surreal to see his byline on an article the same day as a rogue trader comes to light... "Cutting interest rates has stemmed the flow for now, but 2008 will see higher energy costs, higher food costs and higher importing costs which will damage consumer confidence. Right now we can only look to Davos and hope that the global economic leaders can keep positive and stop the markets from spiralling further downwards"
SFinfo TV Schedule for Sunday
SFinfo is carrying some of the Davos meeting live again (where corporations tell governments how to direct their populations). Only interesting thing left in my opinion is the Climate Change forum on Sunday morning. Watch and see where our glorious overlords will be taking us.
How to block all Facebook application and message spam
Practical freedom from Matt Lee's Exploring Freedom.
Valuing Users by Allowing Comments : David Lee King
It makes sense - you know it does.
Internet Psychology: Podcasting? That's old-fashioned - video is the online future by Graham Jones, Internet Psychologist
Maybe I just forgot the obvious, or maybe we haven't really seen what people can do with podcasting yet.
Gaba en San Pancho Blog Archive what things to check when buying an used car
Worst used car I ever saw had a split hose leaking petrol from the carb feed onto the engine block - switching that one off when I asked was the fastest I ever saw a car salesman move!
Modern Communicator: Imarco Activ-Media have been acquired
Personally, I find one of the benefits of working in cooperatives is that it's very difficult for us to be acquired and good collaboration is much more common than merging.
sab39 ... O noes, somebody I don't like did something I agree with!
I feel the point about the bozo bit is well-made. Is one of the few features of my weak memory a low probability that I keep the bozo bit set in the long term?
How You Can Fine-Tune Your Blogger Personality Perception
How do you repair a broken perception? Can you repair it, or is it time to delete the blog and start again at a new address? Can you start again, or does web.archive mean past mistakes will hurt you forever?
robmyers - My Ogg Player
I never succeeded in accessing anything besides basic file upload/removal on my YP-U2 and Samsung Support broke promises they made to me.
another blog is possible Give cyclists a break
"Those of you drive should read this article and change your behavior towards cyclists. You may not like cyclists in the road, but they have every right to be there."

Steve Kemp: Painted wings and giant rings make way for other toys.

This week has mostly involved me getting my live mail filtering site up and running with a guineapig or two. This uses a custom user interface to allow users to manage the filtering settings for an entire domain: In terms of implementation this is an SMTP proxy which is built upon the qpsmtpd framework. I've got both the user interface and a collection of plugins reading all data from an MySQL database. The practical upshot is that if you use the service you'll get less spam, and anything that has been rejected will appear in an online browsable quarantine for a period of times allowing you to view mistakes/rejected mails. Any mail you didn't want, providing you've got the spam-filtering plugin enabled for your domain, you may send back to be trained as spam. It scales nicely, doesn't appear to have lost any mail ever in real-world testing, and could be useful.

Stefano Zacchiroli: bts followup

New bts command: followup In Debian I'm pretty sure we have many perfectionists. Sadly, I'm one of them: I can't help loosing lots of time fixing silly things totally useless with respect to a more important task which is waiting to be completed. An example? Following up on BTS bugs. If I have the original bug report in my mailbox that's easy, I just hit r on mutt and reply as usual (ok, I will still loose some time getting rid of unneeded quoted text, but that's not too much). If I don't have it ... tragedy! I then have to open the bug log in the browser and compose from scratch a new mail including several information which I have to manually grab from the bug log web page: (Yeah, I know, it looks like I'm hopeless, but I'm confident some of the people reading do actually share this and similar dramas.) Missing (or maybe overlooking) a tool helping me out on this, I've patched devscripts's bts to automate the above steps. Now I can do:
bts followup 430986

to end up in a mutt mail composing session with proper (according to the definition of "proper" above) recipients, headers, and quoted text:
From: Stefano Zacchiroli <zack@debian.org>
To: 430986@bugs.debian.org, 430986-submitter@bugs.debian.org
Cc: 
Bcc: 
Subject: Re: when reporting bugs by maintainer, please include Uploaders
Reply-To: 
In-Reply-To: <20070628174236.13848.57178.reportbug@aquarium.takhisis.invalid>
On Thu, 28 Jun 2007 19:42:36 +0200, Stefano Zacchiroli wrote:
> Package: bugs.debian.org
> Severity: wishlist
> 
> Browsing bugs by maintainer (and with this I mean something like
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=zack@debian.org, or
> it shorter form http://bugs.debian.org/zack@debian.org) used to be
> terribly useful as a TODO list. Using that I used to have a simple entry
> point for knowing what I have to do "for Debian" regarding my packages.
> 
> This usefulness has diminished a lot with the spreading of team
> maintenance. To know all bugs that apply to me indeed I know have to
> repeat browse by maintainer for each team I'm a member of.
> 
> It would be terribly useful to include bugs which apply to packages in
> which I'm mentioned as an Uploader in the report by maintainer pages.
<snip>

Now I just need to actually perform the original task, the problem now being that in the meantime I've forgotten what was it about ...
Try it out: Comments?
Anyone else find this useful? If so I can just go ahead and commit it to devscripts mainline ...
Update: some changes to the code, thanks to Adam Barrat for the feedback.
Changelog:

Wouter Verhelst: Samba v2

samba.grep.be. This machine has been my trusty publically-accessible server for about four years now. It runs my website, including this blog, is my primary MX, contains my subversion repositories, and my gallery. For slightly less than the first year of Planet Grep, it was the only machine running that site (it has now been migrated to two machines running in two different data centers, to cope with the ever-increasing bandwidth usage of that site). It runs the bacula-director for our backup system, and it contains the modem behind our fax number, allowing us both to receive faxes and to log in using PPP to our local network. Most importantly, I've been using it as an SSH jumphost and IRC box to allow me to connect to other machines whenever I'm behind an overly paranoid firewall. But now it's time to retire the machine. The high number of services combined with the, to today's standards, low number of available system resources, is beginning to be a problem. A few times now, already, I've had to reboot the machine because a load spike was making it unresponsive. So it has to go. Many people will be shocked to find out that the machine powering samba up to now was an IBM SurePos 500. No, really. The reasons are long and complex, but suffice to say that there was a point in time where I wanted to set up a server for myself, and I had an idle, never-to-be-used-anymore, 2000+ priced, machine standing by. So there I went, usurped this machine as server, and have given it near-100% uptime. If you want to know just how near-100% that is:
  9 Power_On_Hours          0x0032   058   058   000    Old_age   Always       -       31170
[...]
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       99
Or, in plain English: according to SMART, the hard disk has seen just 99 power cycles in four years. This machine was never designed to do that. Side note: yes, that is a touch screen on top of that box. The new machine is much, much better. We're going from this:
model name	: Intel(R) Celeron(TM) CPU                1200MHz
to this:
model name	: Dual-Core AMD Opteron(tm) Processor 1210
which is much, much better. The box actually containing this processor is also much, much better. However, there was one problem: the old processor was a PentiumIV-class processor, requiring Debian's i386 port, whereas the new one (obviously) contains a processor that will allow me to run the amd64 port; and I did intend to do this. Additionally, I wanted to migrate from a simple "root-on-partitions" system to a "root-on-LVM" system, with Xen somewhere in between. As such, simply rsync'ing the entire hard disk on the old system over to the new system (my usual way to migrate a non-critical server) wasn't going to work. Luckily Debian isn't too hard to migrate from one machine to the other, however. Or, well, that was the idea. Because I forgot about one silly detail: if I wanted to make everything work out correctly, I would have had to keep UID numbers in synch. Unfortunately, I forgot about that; and as a result, a number of files were created with the wrong owner. This made all kinds of things fail horribly; and rather than stop and think about it, which would have made me copy the old passwd file over from the old installation, add some extra lines for users that were on the old server but were not yet created on the new one, and then finally leave it at that, everything would've been fixed. Instead, I started to change ownership of files all over the filesystem, creating a mess of things. Silly me. But, well, in the end I did get everything to work correctly; even if it took me longer than expected. No worries.

Roger So: Input Method API Now (nearly) Standardised on Linux

With no standard ways of plugging input methods into Linux desktops, trying to develop one used to be difficult. No more — now there is an actual standard to address this small but important part of Linux, especially for East Asian users. Last week, I was in Beijing to chair the Input Method Sub-Working Group meeting for the 13th time over the past three years. The IMSWG is part of the larger Northeast Asia OSS Promotion Forum (NEAOSS), formed by the Chinese, Japanese and Korean governments for pushing open source software.
CESI
Over the past few years, every detail of how input methods should work were discussed and debated among participants from the three countries. All had strong opinions on the architecture of the system, and at times it seemed impossible for them to agree on the specification. We solved that by getting them to write software code instead — being programmers, we found they understood each other better in computer languages than in English. :)
SWG1 at work
Now, not only do we have an agreed specification, but we are also developing a reference implementation, IMBus, thanks to the hard work of all involved, which includes James Su of SCIM fame, and Hideki Hiura, the designer of XIM and IIIMF. James gave a nice talk about IMBus at last year’s LF Desktop Architects Meeting. I said “nearly” because the overhead of being a semi-government entity means the specification won’t be published until later this year. But all technical issues have been dealt with. With hope, this specification will work its way up to ISO and published as an ISO standard in future. ISO being ISO, this won’t happen anytime soon — I’ll talk more about that later. Update: this post now also up on the Outblaze blog.

24 January 2008

Adam Rosi-Kessel: Best Reason to Have More Than One Child

…so that you will eventually know the indescribable joy of finding all of them sound asleep at a reasonably early point in the evening.

Neil Williams: Separating debug symbols with dh_strip

See #462456 and particularly #462007.
I have come across (what is to me) a non-obvious problem in the use of -dbg packages using dh_strip --dbg-package=libfoo-dbg. If a .install file exists for the -dbg package, dh_install copies the unstripped object into the -dbg build directory. When dh_strip --dbg-package=libfoo-dbg is then called, it silently omits the file from the call to objcopy --only-keep-debug (to prevent an objcopy error), resulting in an unstripped object file being retained in the -dbg package that has a complete (and fully functional) copy of the library embedded inside - as shown by the presence of a full Dynamic Section under objdump -p. Without the .install file, dh_strip takes care of copying the debug symbols into place directly - no .install file is actually needed.
The solution is to simply remove the debian/libfoo-dbg.install file. (Doh!)
However, the error goes undetected because dh_strip outputs no warnings, lintian does not check for it (yet) and there is no particular sign of a problem except the larger size of the files in the -dbg package. With a new library package (or the addition of a new -dbg package to an existing library source), this could easily be missed because all debugging operations using the -dbg package are unaffected (sponsors take note).

With the .install file present:

$ ls -l /usr/lib/debug/usr/lib/libqof*.so.*.*
-rw-r--r-- 1 root root 155585 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof-backend-qsf.so.0.0.7
-rw-r--r-- 1 root root 78554 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof-backend-sqlite.so.0.0.2
-rw-r--r-- 1 root root 1029686 2007-12-19 21:49 /usr/lib/debug/usr/lib/libqof.so.1.0.9

With the .install file removed:

$ debc tail
-rw-r--r-- root/root 103217 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof-backend-qsf.so.0.0.7
-rw-r--r-- root/root 47930 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof-backend-sqlite.so.0.0.2
-rw-r--r-- root/root 728646 2008-01-24 22:53 ./usr/lib/debug/usr/lib/libqof.so.1.0.9

(results have been sorted to keep the same sequence)

The error is possible in any debhelper package, despite being found in a CDBS package. Not sure what made me think that a libfoo-dbg.install file was necessary but there you go.

Martin-&#201;ric Racine: Re: xf86-video-amd: patched xserver-xorg-core available

I previously wrote that:
The next step is to produce patches against the X server 1.4 in Debian/Sid and Ubuntu/Hardy, and then get the fix merged into the upstream X.org tree before X server 1.5 is released.
Good news: Bryce Harrington produced patched X server 1.4 packages for Ubuntu/Hardy! The LTSP and OLPC communities are hereby invited to test this ASAP. If nothing major is reported, this will be become the standard X server 1.4 for the Ubuntu/Hardy LTS release, following which the patch will also be merged into Debian/Sid.

Biella Coleman: Spread the beef

Anyone who knows me, even remotely, knows that I have a huge beef with the American health insurance industry, which was greatly magnified after my own unpleasant run-ins with them over the course of the last two years. But of course while the insurance industry is certainly a ruthless predator and thus deserving much of the blame, they are not the sole culprit in sustaining what is a lousy health care system for Americans. A key player, I think, are American doctors, and I would now like to spread that beef patty of disgust to them, especially since they are now the one’s giving me problems dealing with the final portion of BCBS bill. The story is indicative of lager issues and problems that center on the problematic silence “spoken” by doctors. To make a long story short, BCBS of NJ was not ponying up some serious cash (at least for me) for 2 mole surgeries because they were claiming it was pre-existing condition. After having the public relations director email me (thanks to that post) and a lot of research and letters etc, it was more or less resolved. Soon after they overturned the pre-existing “bs” (and I am not talking blue shield here), they promptly started to pay all sorts of bills (and I even got money back from doctors I had paid). But there is one pesky $1600 bill that lingers like a bad smell and the question is why? I am not entirely sure but my interactions with my ex-dermatologists, Affilated Dermatology in NJ, I think reveal some important lessons as to why and how the medical establishment are complicit. Basically, BCBS is telling me that it looks like they have been double billed because the cost is exactly the same for two procedures that are also exactly the same. I explained that I had did indeed have two surgeries on my scalp (they were really close to each other) and they let me know that the provider needs to call back and send information that clearly shows there were two surgeries. This actually seems somewhat legitimate and potential mistake (and it is not like medical billing is known for their lack of mistakes and integrity either). So I call Affiliated Dermatology and while I would say they have been patient, in so far as patiently waiting for my money, they have been completely unhelpful in any meaningful sense to help me getting this resolved. Now, given how difficult it is to deal with the health insurance industry, I understand they can’t provide fine-tuned, fine-grained personal attention. The health insurance industry engages in some real hefty politics of foot dragging and well, there are so many foot soldiers at doctor’s offices to keep up with the web of knots that the health insurance constantly entangles us in. With that caveat in place, they can however do two things: 1. Inform you that you can contact the Department of Housing and Insurance and start some sort of formal complain process. 2. Give you some small clue as to whether the doctor has sent any of the additional requested information (they are usually mum, or enigmatic, or totally confusing with regards to that) so you know what the heck is going on. So a few days ago when I was speaking with health insurance person at the dermatology office, she claimed there was nothing else she could do about this last bill. Every time she calls BCBS, she claims that they claim it is a problem with being a pre-existing condition, and I was like “how can that be when that has been cleared and every other bill, and there were many, has been paid?” And then she also said that there has never been this confusion before where 2 surgeries look like one, blah blah and blah (and in retrospect, I forgot to tell her that my double surgery, according to the doc, was in fact highly unusual, because they would usually do them on two separate days because they were so close to each other. They made an exception because I was literally on my way to Canada and begged them to do so but anyway). Ok, so there I was bickering with this woman and feeling stuck between a rock and a hard place. Finally I let her know, point blank, that they have been remarkably patient with the billing but totally unhelpful in, well, helping me out. I let her know that they should let people like me know, for example, that they can file a formal complaint against the health insurance company and this would at least get the ball rolling. I then let her know that I had no other option but to file another complaint with the Dept of Banking and Insurance and they would just have to wait for that, at which point, she all of a sudden became more helpful. She suggested that we can do a three way call to resolve this. Well there you go. Why did it take a heated 15 minute conversation topped with a threat to get what I think actually makes perfect sense? Get the 3 parties involved on the phone with each other so as to all get on the same damn page about what needs to be done (not sure if BCBS will agree to this… at which point I will pester the public relations director again and in the end, I think this was resolved because he was sick of my emails). Now, why why why why why why are doctors and their staff so unhelpful? I think that main answer is they are overwhelmed and don’t have the staff to deal with the enormous amount of foot dragging and coy tactics deployed by the health insurance. That said, there are 2 things worth mentioning that I think don’t paint a very flattering picture of many American doctors. If you pay attention to your medical bills (and you always should), it is immediately evident that the doctors and hospitals get paid LESS, sometimes a lot less, if the health insurance company foots the bill because of the pre-arranged negotiated rate. So there is an actual incentive on that side of things to get paid via the consumer as opposed to the health insurance company. Now. I am sure that there are health care economic studies and reports justifying this strangeness but that does not make it right either. There is a clear incentive in place to get your green dollars, as opposed to those of the insurance company. Second and this is a much bigger issue, is that I think that for any meaningful change to happen, we need the active support of a large percentage of the medical community, especially doctors. If they are mum, or actively opposed to health care reform (as was the case when the AMA helped derail the Clinton effort at instituting universal health care in the 1990s), well then it becomes all that much harder for the general populace and the politicians to initiate real change. Doctors are the ones, after all, with the moral weight and capacity to make claims that can STICK. If they are saying this system negatively impacts how we care for the ill, it is a system that is is immoral, well, one should listen to them as they are the ones, after all, who dedicated their LIFE to healing the ill, right? Yes? No? Maybe? So their silence is nothing short of grave. The good news is that it seems like more doctors are on board than ever before clamoring for change in the right direction, but we need a lot more to come aboard… A number of years ago, I wanted to write a controversial and critical article that claimed hackers are more ethical than doctors. I thought it would be fun to claim that those who are usually seen as ethical (doctors) are less so than those that are usually portrayed as bad-as* unethical tricksters. Some people were offended by this because doctors deal with the great burden of life, death, sickness, and thus suffering while geeks and hackers are “just” geeking out on their computers. True. But at least a cadre of hackers have sustained a social realm and a real ethics–free software–in order to guarantee their own autonomy and also create the conditions for what is right for software. Doctors, on the other hand, do not carry the torch of ethics as they should. While individually I am sure they deal with a oodles of difficult ethical choices and decisions, it is about time they they turn as a collective to the larger structural conditions that seriously cause a lot of harm to millions of Americans, especially the droves of uninsured. They have the moral weight to do something about it and it is about time they carry their weight in this battle and take some burden of suffering off others.

23 January 2008

Joey Hess: a problem with tools

We have a problem with our tools in Debian, and it's this: Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package. Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem. The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because
  1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
  2. getting the project to standardise on a tool is hard
  3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with
So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument. Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on. Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them. At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it? One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.
For now, I have no interest in being on a team that requires I use any of the following things: This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.
PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different. PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)

Russell Coker: How I Partition Disks

Having had a number of hard drives fail over the years I use RAID whenever possible to reduce the probability of data loss caused by hardware failure. It’s unfortunate that some machines make it impractically difficult to install a second hard drive (my laptop and some small form factor desktop machines I have given to relatives). But when it’s possible I have two hard drives running software RAID-1. I use two partitions, one for /boot and one as a LVM physical volume (PV). When using RAID I make both /boot and the PV be software RAID-1 devices (the vast majority of machines that I install don’t have budget available for hardware RAID). /boot is a small partition, approximately 100M. For a machine with only one disk I make the second partition take all the available space as there is no benefit in doing otherwise (LVM allows me to create an arbitrary number of block devices out of the space at run-time). When using software RAID I often make the PV take less than the full capacity of the disks. When the disks are 40G or more I usually use less than half the capacity. For most machines that I install or run the full capacity of the disks is not required. One deficiency of Linux software RAID is that on a power failure the entire RAID device must be checked to ensure that all disks have matching data. Reading the entire contents of a pair of disks can take a large amount of time if the disks are large, and as the size of disks is increasing at a greater rate than the speed of disks this problem is getting worse. See my ZCAV benchmark results page for graphs of the contiguous IO performance of some disks I’ve owned [1]. It seems that with a 10G disk you may expect to be able to read it all in less than 1000 seconds, for a 46G disk it’ll be something greater than 1,500 seconds, and for 300G disks you are looking at something well in excess of 5,000 seconds. Almost all disks (and all IDE and SATA disks for which I’ve seen benchmark results) have the lower block numbers mapped to the outside tracks which are longer and give a higher contiguous IO speed. So by using the first half of the disk the RAID synchronisation time is reduced to less than half what it might be (in the absence of motherboard bottlenecks). When there is no need for more than about 10G of storage space there’s no benefit in making a large RAID device and wasting recovery time. While the system can operate while the RAID is synchronising the performance will be significantly lower than normal. If the usage pattern of the machine changes such that it needs more space it’s easy to create new partitions, make a new software RAID, and then add it to the LVM volume group (I’ve done this before). So the down-side to this is minimal. When creating LVM logical volumes (LVs) I create volumes for the root filesystem and swap space when doing the install. This should result in the swap space being near enough to the start of the disk to get reasonable performance (but I haven’t verified this). I make the root filesystem reasonably large (EG 6G) as disk space is plentiful and cheap nowadays and the root filesystem is the only one that you can’t easily extend when running LVM (trying to do so deadlocks the disk IO). After the base install is done I create other LVs.

Russell Coker: Storing a GPG key

Chris Lamb has suggested storing a GPG key on a RAID-5 device [1]. The idea is that it can be stored on several physical block devices such that losing just one will not give the key to an attacker. A default GPG secret key will be about 1.2K in size (3 sectors of a hard drive). A minimal key (with 1024 bit DSA keypair) will be 0.9K (2 sectors). I expect that very few people have secret keys greater than 4K in size. To create a software RAID-5 device under Linux the tool mdadm is used. The default chunk size is 64K, so a 1.2K file will probably be on a single device. If you use the -c option of mdadm to specify a smaller chunk size then the smallest that is accepted is 4K which still permits a default GPG secret key to be on a single device. The Ext2 and Ext3 filesystems will always align such file data to a 4K boundary unless the device is smaller than a certain size (or a special mkfs option is used) to give a 1K block size for the filesystem. If an Ext2 or Ext3 filesystem is used with 1K blocks then you might get a 1.2K file split across multiple 4K RAID chunks. So storing a GPG key on RAID-5 won’t prevent an attacker who steals one part from getting all the most valuable data. It will make it more inconvenient for them (if you are lucky it will prevent them getting all the data) and it will also make it difficult for the owner of the GPG key to determine which of the devices actually contains the secret data (probably all of them will end up having copies if you edit the secret key). Now if RAID-5 did allow chunk sizes that were smaller than the secret key or if you have Ext2/3 with 1K blocks and get lucky with file fragmentation then the problem still isn’t solved. The reason is that you don’t require N-1 of the N disks to get some useful data out of a RAID-5 array (run strings on one element of a RAID-5 array to verify this). A single disk on it’s own will have some data that can be used, as file(1) can recognise GPG secret keys so you could just copy 1K chunks of data into separate files and use file to determine which (if any) has the data in question. The really exciting question is, what do you get if you have the first 1K of a 1.2K GPG secret key? If it could be proved that the first 1K does not give an attacker any advantage then this might provide some benefit. But I think that this is a very dubious assumption, when dealing with such things it’s best to assume the worst. Assume that an attacker who has 1K out of 1.2K of secret data has the ability to reconstruct the rest. In that case the Linux kernel RAID-5 provides no benefit for storing a GPG secret key. Just try not to get your devices that contain secret data stolen. Maybe a watch with a built-in USB device is a good idea. Thieves seem to be targetting mobile phones instead of watches nowadays and something that’s strapped to your wrist is difficult to lose.

Next.

Previous.