Search Results: "ana"

19 April 2008

Chris Lawrence: Principals, agents, and Debian

I’ve noted in the past that Debian has deliberately enshrined in its constitution some rather serious principal-agent problems. By and large this isn’t a bad thing, since there isn’t the consensus within the Debian community to support the “benevolent dictator for life” model of decision-making—if you want that, well that’s what Ubuntu and Daddy Warbucks is for. But it does mean that sometimes the caca hits the fan when a Debian project leader does exercise his powers, as our now-former DPL did earlier this week just before the end of his term of office (by my estimate, just over one hour and 27 minutes before). John Adams would be proud. So we have three related issues in my mind:

As a matter of general principle, lame-duck DPLs shouldn’t be making appointments. This issue is ameliorated somewhat because DPL delegations—unlike “midnight judges”—can be revoked at any time, but it strikes me that whatever legitimacy a DPL has from the developers evaporates once a new DPL-elect has been designated. I can only speculate why this happened in this case, so I won’t bother.
Second, while Debian has a very strong tradition of developer sovereignty, with many aspects of the project being self-organized rather than originating with appointments from upon high, it seems to me that certain aspects of core infrastructure can’t be managed in this way.
Third, the appointment does little to relieve the excessive concentration of power in the core of Debian; if anything, Anthony Towns’ apparent resignation in the wake of Jörg’s appointment worsens the situation. Ensuring there is proper vetting of people with access to important infrastructure is important, but at the same time I find it difficult to believe that there are only a half-dozen or so Debian developers who are trustworthy enough to be system administrators, account managers, or archive maintainers (several of them occupying overlapping positions). That, rather than a lack of technical tools, has been a problem of note within Debian since, oh, the days of my youthful vigor within Debian (which are long since past).

In any event, congratulations to all the new Debian developers—and I’ll avoid pondering for too long why one person’s appointment to an unrelated group would suddenly break the logjam of developer application approvals.

Jeff Bailey: Physio, Illness

I started physiotherapy this past week. The first clinic I went to on Wednesday (Mountain View Physical Therapy) turned into an interesting disaster. When we walked into the place, the first impressions were that it was noisy and dirty. There was someone sitting upright in the waiting area asleep. The place is one big room, with the massage tables in the middle of the room and exercise equipment all around the outside. None of the staff looked really happy to be there. I met my therapist who, it turns out, is the director of the clinic. She was truly excellent - good enough that I would've overlooked everything else, except for the fact that she doesn't have 3 days a week free to see me. More weeks, I would've been lucky to get her more than once per week.

So for Friday, we found a different clinic. Orthosport. It was such a difference from the previous place, there's no good comparison. The receptionist was friendly, the therapist very professional, and the place really tidy. Even the assistants were very friendly and checked in on a regular basis.

But in between those two days, I got sick again. I had some sort of stomach flu or drug reaction the previous week, and it seemed to be coming back. After two days of throwing up, I made an appointment with the after-hours clinic today to get more anti-nausea drugs. They've also taken some more blood and want to do some tests next week to make sure that everything's still doing okay.

Another bit of love and affection goes to my new bank, RBC Centura. Not only have they done lovely things for bill payments, and sending money for free between my Canadian and American accounts, they also have a "Bank by Mail" program, where I can just stick cheques in an envelope that's already postage paid, and they deposit them for me. No need to find a machine of the right persuasion to do deposits. We still have a couple tasks to do before we can close out the HSBC account, but we're almost there.

Leif is pushing out new teeth. He'll be up to 9 when he's done.

Enrico Zini: Laptop stolen

Laptop stolen Last thursday I flew from Italy to Manchester as usual, and while walking home from Levenshulme railway station my laptop has been snatched off me by a gang of thieves. I've managed to give the police all the details of the laptop including the serial number. I could also precisely describe to them the dynamics of the incident pointing at places over satellite maps in google maps. And give them the time of the theft with 10 seconds accuracy. And show them pictures of all stolen goods with a few simple internet searches. They were impressed. All sensitive data in the laptop are protected with one or two layers of strong encryption, and I have fresh backups, so the only work that I've lost was the work I did on the train and airplane on my way to the UK. If anyone around Manchester or Stockport happens to see, in a Cash Generator or second hand shop, a suspicious looking white ASUS laptop with a Taiwanese keyboard (US-style keyboard with extra Traditional Chinese and Bopomofo glyphs on it), please quietly walk out of the shop, alert the police and send me an e-mail. The day after the theft I managed to talk with a pub owner in the area, and there I learnt that pubs are networked and alert each other when suspicious people are roaming around. Lesson learned: if I see suspicious people around the street whem I'm walking home with my laptop, it's a good idea to go inside a pub and ask how's the situation. That night, for example, they've been alerting their customers of the danger. I wish the railway station had done the same.

Christian Perrier: Samba week

I spent the entire week at the SambaXP conference in G ttingen, Germany. The conference is the annual conference of the community of developers, contributors and users of Samba. I general call it "my annual german pilgrimage" as I attended all seven editions of the conference, the only FLOSS conference I attend on my work time, as my daily work involves quite a lot of uses of samba. This year featured a workshop or training session held by John Terpstra, longstanding FLOSS evangelist and member of the Samba Team for over 10 years, and Karolin Seeger, the brand new release manager of Samba. This has indeed been an incredible opportunity to have discussions with them about the packaging work for Samba. Actually, the work we did in the last 3 years to bring Samba Debian packages in a very good shape (when I don't screw up) is much appreciated. I think these days have been another opportunity to keep that link very closed. I have been impressed by the promising work of Karolin with respect to the preparation of the release and the very serious way she has to do that work....as well as her very friendly, while still discreet approach to technical discussion. Some work was done on Samba package bugs, though less than usually (the remaining ones are harder and harder to tackle!). I mostly work on Debian packages as well as .deb packages prepared by Sernet (the services company that organises the conference and employer of some Samba Team members), as these could some day become the packages provided by the Samba Team. Talks at the conference were pretty interesting, to keep connected with Samba 3.2 and 4.0 development. News from Andrew Tridgell about exchanges with Microsoft (yes, The Evil) and access to MS documentation, are very promising. The collaboration between Samba developers and Microsoft enginneers is now working well again, at the engineers level (as Tridge says: "lawyers are away, now, we can talk at the engineers level and restore the link that existed in the early 90's"). I also could measure the progress of the Openchange project whose ultimate aim is to provide a complete Microsoft Exchange replacement solution. They currently have working MAPI libraries and an Evolution plugin for Exchange is under development, while the bricks to build a server are patiently being put together. Good discussions with Julien Kerihuel, the lead (and French) developer and manager of the project. Jelmer Vernooij and I also settled the final plans to get Samba4 packages in Debian. I proposed to make a first upload to experimental, but quite soon to upload to unstable, the point being a largest as possible exposure of that code, so that upstream developers (Jelmer himself, Andrew Bartlett and a few others...) get as much feedback as possible. That upload will not be targeted for lenny (we'll block it from entering testing). For that reason and also because Samba 3 and 4 will certainly coexist for years, the source package will be named "samba4". Expect more news quite soon. And final conclusion of that week: I've also been delighted to be able to visit Alex and Meike in Hildesheim, as well as Andreas in Wernigerode. It's always a great pleasure to see longstanding Debian friends. At the beginning of the week, I planned to see *two DD and finally, at the end of the week, I can tell I've seen *three* Debian developers, finally!

18 April 2008

Russell Coker: Preparing for a Collapse

Rick Falkvinge (leader of the Swedish Pirate Party) has written his predictions about an economic crash in the US [1]. Predicting that the US economy will crash is no great stretch, it’s gross failures seem obvious. The Pirate Party [2] is a one-issue political party that is based on reform of intellectual property laws. It derived it’s name from the term Software Piracy [3] which originally referred to using software without paying for it, but in recent times has been broadened in scope to cover doing anything that copyright holders don’t like. The term “Piracy” is deprecated in the free software community based on the fact that it’s unreasonable to compare armed robbery and murder on the high seas (which still happens today and costs between $US13,000,000,000 and $US16,000,000,000 per year [4]) with copying some files without permission. But that battle has been conclusively lost, so it seems that the mis-use of the term “Piracy” will continue. The majority of the acts which are considered to be “Piracy” are well accepted by the community, the acts of the music industry in taking legal action against young children have only drawn more public support for the “Pirate” cause. Such support is increasing the changes of the Swedish Pirate Party getting a seat in parliament at the next election, and has caused the major Swedish parties to change their positions on IP legislation. Now Rick’s background related to Intellectual Property issues causes him to analyse the IP aspects of the current US problems. His claim is that the US economy was trashed during the Vietnam war, has been getting worse ever since, and that the US position on IP legislation is either intentionally or accidentally helping to finance the US while it’s production of useful things is steadily decreasing. He also claims that some multi-national financial customs (such as using the US dollar for the international oil trade) is propping up the US currency and effectively allowing the US government (and the US residents) to borrow money from the rest of the world. Dmitry Orlov’s presentation titled “Closing the ‘Collapse Gap’: the USSR was better prepared for collapse than the US” [5] provides some interesting information on what happens during an economic collapse. He also has some specific advice on what can be done (by both governments and individuals) to prepare for an impending collapse. However he doesn’t mention some issues which are important to people like us (although not as important as food, water, and shelter). On my document blog I’ve got a post with some ideas of how to run an Internet Infrastructure after a medium-scale collapse of the economy as we know it [6].

[1] http://www.falkvinge.com/2008/03/why-us-is-collapsing.html

[2] http://en.wikipedia.org/wiki/Pirate_party

[3] http://en.wikipedia.org/wiki/Software_piracy

[4] http://en.wikipedia.org/wiki/Pirate

[5] http://www.energybulletin.net/23259.html

[6] http://doc.coker.com.au/internet/running-net-after-collapse/

Gregor Herrmann: surprise

when I woke up today (after sleeping in for the first time with my new roll-top in front of my bedroom window) I was surprised & confused by a couple of "congratulations!" messages in my irc away-log. it took me a bit of time & coffee (& looking into my mailbox) to begin to realize that my Debian account had indeed been created while I was asleep. — in fact I guess I still haven't completely realized my new status as Debian Developer.

as others I'd like to follow the good tradition of taking the opportunity to thank some of the people who helped me to get there:

first & foremost Tony Mancill, my advocate, permanent sponsor, & long-time co-maintainer; for all his support in preparing & quickly uploading packages, tracking down bugs, encouraging & advocating me but also for our very pleasant "chats" via email. — we have already agreed to continue co-maintaining each other's packages.
the friendly & helpful guys from the Debian Perl Group: Gunnar Wolf, for always encouraging me (to join the group, to apply for the New Maintainer Process, ...); Damyan Ivanov, for teaching me so much (even if he called it "nitpicking"); Gunnar, Damyan, Krzysztof Krzyżaniak, Niko Tyni, Roberto C. Sánchez, Stephen Gran, Frank Lichtenheld, Jaldhar H. Vyas, Russ Allbery, Raphaël Hertzog, & some others for uploading packages I've prepared & helping me when I had questions or problems; Martín Ferrari, for all his help, expertise, & especially for the fun & the good times we share on IRC.
my Application Manager Wouter Verhelst; for guiding me through the New Maintainer process not only fast but also in a very helpful, at the same time demanding & supporting way.
the Debian Women sub-project; for making Debian a better & friendlier place not only for women but in general.
finally: the people who used the time while I was asleep to actually create my account tonight :)

some final thoughts about the NM process from my point of view:

it took me some time to actually apply for NM; what deterred me was not that I knew it would take some time but that I didn't know how long the time would be; & that I knew that the bigger part of the overall time would consist of waiting.
I applied on 2007-04-03, my account was created on 2008-04-18; 380 days is not bad altogether in my opinion; the actual work with my AM was from 2007-08-12 until 2007-11-28 (i.e. 108 days, or 28% of the whole duration).
I did enjoy the actual checks; I had to read & think a lot, & I learned a lot in that period.
Front Desk (i.e. Christoph Berg) was very quick on all necessary steps.
I was never demotivated about my Debian work because of all the people supporting me & taking the burden of uploading packages I had prepared. but I have to admit that I got a little bored in the last months of waiting after the report had been submitted by my Application Manager.

& now it's time first to celebrate & then to try to fully grasp my new rights & responsibilities.

Martín Ferrari: I am finally a DD!

*Ahem*... I'm soooo excited! After 884 days, I just became a DD. It was almost two years and a half of much work, learning, patience, struggling to keep the morale up, and more work. In fact, Debian is already taking almost all my free time since months ago, something I don't regret at all. I was able to do most of the things I wanted to do, even without an account, including: DebConf organisation, team-maintaining packages (sorry pkg-perl folks, dc8 didn't leave me much time lately), some QA work, coding tools, etc. But this small feat has a huge symbolic importance to me, now the project as a whole is recognising me as a full member; many people already did individually, but sometimes you need the "official" stuff. So thanks to all the people that helped me during the way (sorry for the omissions!): maxy, for introducing me to Debian, marga for encouraging me to apply to NM —and all the moral support—, des for the help and the sarcasm, damog for being my first AM, even if we had our problems, ana for being my second AM and being so supportive, the Perl-lings for being such a nice bunch of people to work with and to learn from. Thanks also to all the nice people I've met along the way (dudes!), you make Debian a nicer place. Update: There was another paragraph that I butchered after noticing that the actual process in the last 24 hours was different than what I thought. But anyway, my thanks to Sam, Myon and Ganneff for their respective help in this process. Also, I don't want to forget to thank Ganneff for the trust he'd put on me during this time. Tags: Planet Lugfi, Planet Debian, Debian

Clint Adams: The bouncer knows all

Jaldhar, you are dressed too nicely to be in the club.

MJ Ray: Explaining web site improvements: what's important to you?

[Photo of Some Traffic]
Is this traffic or congestion? This is one of those Friday Afternoon Projects - it's been put off all through a busy week because it's unpaid, I'm not completely sure how to approach it and now my arms hurt like hell from travel jabs which are making it hard to concentrate! So I'm going to float it on here... I've been asked to brief a meeting next week about that group's current web site and its problems. I'm not linking it yet to avoid insulting/embarrassing them. The site looks OK, but doesn't rank well on search engines and doesn't allow much member participation. I need to explain why that's a bad thing and how the site's technical choices have led to that. I'm not directly pitching for TTLLP to get any work (because I'm a member of that group, it might be a conflict of interest and we're pretty busy anyway - even our own site needs work on some of the points I'm going to mention), but I don't want to be unhappy if we're asked to implement my recommendations. I've got a usual outline that I follow, but my presentation's time is limited, so I'd like to ask you: what about this is important and what isn't? If you give me useful feedback, I'll put you in the Acknowledgements with a backlink and I hope the briefing will be shared pretty widely over the next few months. The current plan is to start with a basic explanation of how search engines rank pages, as far as we can tell, referring to PageRank Explained Correctly with Examples, by Ian Rogers as well as the shorter official summaries from the dominant search sites at Yahoo, Microsoft and Google. Then I go through a quick evaluation of the site against the basics of validation, accessibility and robot-friendliness, followed by a couple of SEO-style checks of its current rankings and inbound links. Next is a bit different because I have access to some of their web access stats: I summarise what we know and suggest some other stats they've probably not considered and why they're useful, along the lines of Dave Briggs's measures of blog success. Finally, I suggest ways to improve the site. The top tip will be to take control of the site hosting and stop using the cheap and cheerful donated server that makes all links except the front page point to another domain. I'll probably suggest a mix of free and open source software tools to power it. If they don't want to move it all yet, I'll suggest running a second site for member participation, using tools like Wordpress, NoseRub and so on. What do you think? Plan for success, am I missing some tricks, or am I setting myself up for a lynching? Let me know with a comment or email, please.

Robert McQueen: Lazyweb request: gadgets I would like to have

Last night I thought of a few gadgets which I’d like to have, and although I’m pretty sure you should be able to get hold of them, I had trouble finding anything that looked quite right:

Alarm clock which makes coffee: I can’t be the only one who finds it hard to bootstrap my days because I have to get out of bed and make the first coffee of the day before I’ve had any coffee. My parents had a machine which was an alarm clock which made tea (very noisily) at the appropriate time in the morning. Surely there should be a similar device which can display the time and make (at least passable) coffee instead? Be it an alarm clock with a sideline in making coffee, or a coffee machine with a built in timer. I’ve noticed some of Gaggia’s bean-to-cup machines claim to have 24-hour clocks, but does that mean they have a timer function? We just don’t know.
Decent watch with USB storage: I found some watches online last night which had USB storage built in, some with a little USB connector that folded out, some with a mini/micro USB connector on the side, with the idea I could store (maybe parts of) my GPG and SSH keys on it, and maybe a bootable Debian installer/rescue system. The thing is, I have a reasonably nice Timex Expedition watch at the moment which I quite like: it has an electro-luminescent analog display for the middle of the night, and a digital bit for the date, alarms and multiple time-zones. The USB-enabled watches I saw didn’t look that great as watches, but I might be wrong. Does anyone have a watch that features USB storage that doesn’t compromise too much on the watch functionality? Maybe I should just give up on this one and go for the rugged USB stick on the keyring approach.
Video output over USB: I have a reasonably new HP 2510P laptop which I also use as my main machine at work with a docking station, TFT, keyboard, mouse, etc. However, as a machine for watching DVDs or other videos on at home, it’s a bit on the small side. I have an olde-worlde big flatscreen TV at home (which is not as good as Christian’s flat-screen blueray surround sound movie set-up, but I think I retain the moral high ground on taste in films), but my laptop doesn’t have any video out. Is there a USB 2.0 widget which produces composite or S-Video output which I can feed to my TV, that will work with Linux, or should I just get a scan converter of some sort so I can use the VGA output?

So, answers on a postcard…

Adeodato Sim : Les invasions barbares

Yesterday I watched Les invasions barbares, a film by Canadian director Denys Arcand. I came to find it because one of my favourite cinemas in this oh-so-small city was premiering L’ ge des t n bres, the third part of a trilogy started by Le d clin de l’empire am ricain, and continued by Les invasions barbares above. I loved Les invasions barbares. I think it’s a very honest film, but for me not only it portrayed a reality and set of characters that I found credible, I also felt empowered by watching attitudes towards life so compatible, if not similar, to my own. Reminds me a bit of some of the feelings I had when watching Juno. It is also one film more to add to my (smallish) collection of films I’ve watched in French (with subtitles), though I’m intending to fix that: I really enjoy French, as well as enjoyed all Canadian or French I’ve watched in the past. We’ll see how it goes.

Julien Blache: Analysis of NagVis 1.2.x

NagVis is a visualization add-on for Nagios, offering a somewhat better summary view compared to Nagios. As we are faced with abysmal performance on a “large” setup here, I conducted a quick analysis. Given what I found pretty early on during this analysis, I’ve given up trying to salvage NagVis. We’re looking at alternatives and considering writing our own tool to cover our needs.

Lucas Nussbaum: 19 new Debian Developers! \o/

I am very happy that 19 contributors who were waiting for their accounts, sometimes for a very long time, became Debian Developers today. This is great news for them, and for the project as a whole. Many thanks to all people involved for making this possible, including Joerg Jaspert, Steve McIntyre and James Troup. And congratulations to (using their account names) kibi, plessy, gregoa, goneri, tincho, akumar, filipe, miriam and the others I haven’t had the chance to work with yet. It also seems that the various pending issues (updating keys that expired, etc.) have been resolved, which is great news for several of our current DDs. But this doesn’t solve the DAM problem on a permanent basis. Something interesting about today’s events is that the account manager asked the system administrators to create the accounts, which is a nice way to offload part of the process. But the keyring maintainance is still a SPOF. A tool has been developed to allow multiple people to collaboratively edit the same keyring (and it’s used to maintain the Debian Maintainers keyring), but I’ve heard that some people weren’t satisfied with it, unfortunately. Let’s hope that this is solved soon, so the next ones to go through NM won’t have to wait that long!

17 April 2008

Mike O'Connor: im in ur keyring, uploading ur packages

YAY! I'm now a Debian Developer. I started celebrating by uploading an NMU for the oldest patch of a RC bug I had sitting in the BTS. Thanks to Ari for advocating my membership, to Ari, Clint, Free, Piotr for sponsoring my uploads, and TomV. for managing my application. Also a special thanks to sam for making the last minute DAM appointments, which probably sped up my account creation, thus, finally 'making debian sexier' :).

Matthew Garrett

This week I'm in Mountain View for the X Developers' Conference, where I gave a presentation on things graphics drivers have to care about in order to make suspend/resume work reliably. Various people suggested that I write up an explanation of the current situation, along with some best practices for manufacturers.

One of the major differences between the ACPI specification and the older APM specification is that saving and restoring hardware state is generally left up to the operating system, with the firmware playing a much more passive role. Linux is now able to handle this state restoration for the majority of hardware, but we still have issues with graphics. Modern graphics hardware can be hugely complicated, which to a large extent we've been able to ignore because the platform will initialise it on boot. Many X drivers know how to switch a card from text mode to graphics mode (and vice-versa), but that's not adequate.

What can make this situation even more awkward is that the ACPI specification makes no guarantees about what state the hardware comes up in. It may still be in PCI D3. It may be powered up, but the registers may all be zeroed. It's even valid for the hardware to come up in text mode. A driver has to be able to deal with all of these situations.

So far, we've mostly tried to deal with this situation by running chunks of the video BIOS with applications like vbetool. This is hacky and often works badly - in some cases, it won't work at all (nvidia rewrite the entry point to their video BIOS after boot, in order to prevent situations where someone attempts to POST the card and it tries to jump to bits of the system BIOS that no longer exist). The only long-term option is for the kernel to handle the graphics suspend/resume. There's several levels at which this can be supported:

Able to restore text mode. This is basically adequate right now, since the kernel enforces a virtual terminal switch around suspend/resume.
Able to restore arbitrary video mode. In the kernel modesetting world, we want to be able to go straight into the mode that we're running X in, in order to reduce screen flicker. This would probably still be surrounded with a VT switch out of and into X.
Able to jump straight into X. Right now, on x86 the process freezer will prevent X from running until after all of the devices have been resumed. As we move to a model where we remove the freezer and expect drivers to be able to block userspace tasks, we hit a pretty obvious problem with X - right now it hits the graphics hardware directly, rather than going via the kernel. With nothing to block it, it'll hit the hardware while it's still in an undefined state and then become very unhappy. This can't really be fixed until X does all its hardware access through the kernel. For now, we can inhibit X by leaving the VT switching in place.

Since 2.6.25, i915 and later Intel hardware can manage basic mode reprogramming without requiring any external assistance. The radeon kernel modesetting code is also heading in this direction, and we ought to be able to manage something there before too long. The nouveau developers are heading towards the stage of being able to do native mode programming, so there's some hope of progress there as well.

It's not all plain sailing, though. Vendors can wire up hardware in different ways. AMD and Nvidia hardware provides scripts in the ROM that, in theory, abstract this away. The downside to this is that we'll have to put the interpreters for these scripts in kernel space, though this is probably needed for kernel modesetting work anyway. Even then, it's possible that we'll need workarounds for specific pieces of hardware that don't quite behave as we expect them to.

As far as making graphics work over suspend/resume, we have a pretty good idea where we are now (failing on anything other than modern Intel hardware), where we need to be in the future (triumph, huge success, cake) and how to get there (?). However, hardware manufacturers can still help.
Chipset vendors:Tell us how to reinitialise your hardware. If that involves parsing BIOS tables, then please let us know how to do that. Expecting us to jump into your ROM and execute x86 code is ok if that's genuinely the only way to do it, but for any modern hardware that's clearly not the case.
System vendors:Try not to alter your system behaviour too wildly. Requiring magic register writes in order to light up the VGA output does not classify as value add. Please don't have your firmware program text mode directly - we're trying to get away from that. And do not attempt to detect that you're running on Linux and alter your system behaviour. If it's possible for you to tell that you're not running on Windows, that's a bug in Linux. If you rely on that bug, you will break. I'm not joking here in the slightest. The closest thing to a "standard" interface between an OS and the hardware is whatever Windows does, and we're basically aiming for bug-for-bug compatibility there.

MJ Ray: 21 today! MJR around the web...

Not done one of these round-ups for a while and I'm really pushed for time today, so here are some sites that I've written on:

16 April 2008

Matthew Palmer: When you think you're good...

It's stories like the following that make you realise just how puny your talents are... (Reposted from a place not to be named, by the legendary Al Viro)

Give them what I got yesterday. As in, box that got
        a) Linux kernel running.
        b) init and bash running.
        c) serial and floppy - built as modules. And not loaded.
        d) no sash.
        e) no ethernet.
        f) bloody large number-crunching that Should Not Be Aborted(tm).
        g) libc and ld-linux.so - unlinked (self-LART by owner).
Now, I could tell the guy to piss off, but... WTF? He had decent beer and
was properly scared. Oh, well... So we have no exec() for anything
dynamically
linked. And we have no chance to access any external stuff - insmod is
linked
dynamically, so no insmod floppy for you. Shutting the system down was not
an
option due to (f) (aside of dealing with fsck later - umount(8) is
dynamically
linked too). Now, I knew that both /lib/libc.so-2.1.2 and
/lib/ld-linux.so-2.1.2 were still alive - mmaped by init, for one. And
/proc/1/maps would even contain their inumbers. So the plan of attack was
to create a file in root and then cannibalize the entry (change inumber in
the directory). Alas - not enough. In-core inode got zero i_nlink and
if I would just create a link by hands it would not become positive. I.e.
still remove-upon-close. But. But if we will manage to call link() on the
hand-made link we will get i_nlink raised to 1 - iget() will find the same
in-core inode, so we are OK. We'll have to revert the phony link to avoid
PO'd fsck, but that's not a problem...
        So there we go: assuming that we got static ln
echo >foo
ln foo bar
flip inumber in foo entry to point to libc
ln foo /lib/libc.so-2.1.2
flip inumber.......................... bar
repeat for ld-linux.so
rm foo bar
begin recovering other damage (self-LART was a bit larger).
        But... we don't have this flip stuff and we don't have (aaarrgh)
static
ln. Oh, shit... OK, but all we really need is a couple of syscalls, right?
There we go:
        eax=__NR_link;
        ebx=s1;
        ecx=s2;
        int 0x80;
        eax=__NR_exit;
        ebx=0;
        int 0x80;
s1:     "foo"
s2:     "bar"
The next step was getting the syscall numbers. grep? We don't need no
stinkin'
grep.
# while read i; do case $i in *__NR_link*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_link 9
# while read i; do case $i in *__NR_exit*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_exit 1
#define __NR__exit __NR_exit
Now, scratching the head and recalling intel code...
start:  b8 09 00 00 00
        bb (address of s1)
        b9 (address of s2)
        cd 80
        b8 01 00 00 00
        bb 00 00 00 00
        cd 80
s1:     66 6f 6f 00
s2:     62 61 72 00
Fine, but... a.out support is compiled... you guessed it, as module and not
currently loaded. So we are in for crufting up an ELF binary. OK, we don't
actually need 100%-correct ELF, just something that will pass for the
exec(). Now, we don't have shell scripts, but . will work. So the next
step was rolling more(1) in shell and reading through the relevant code
(surprisingly small - binfmt_elf.c and two headers). After much swearing
the following abortion was created:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 start______ 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 base_______
base_______ size_______ size_______ 05 00 00 00
00 10 00 00
start:
b8 09 00 00 00 bb start+1d___ b9 start+21___ cd
80 b8 01 00 00 00 bb 00 00 00 00 cd 80 66 6f 6f
00 62 61 72 00
OK, set base to something page-aligned, start=base+54, size=79. There we go:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 54 00 00 80 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 80
00 00 00 80 79 00 00 00 79 00 00 00 05 00 00 00
00 10 00 00 b8 09 00 00 00 bb 71 00 00 80 b9 75
00 00 80 cd 80 b8 01 00 00 00 bb 00 00 00 00 cd
80 66 6f 6f 00 62 61 72 00
well, while read l; do for i in  echo $l ; do echo -ne "\\$i"; done; done
made for oct2bin, overwriting /usr/bin/emacs with the output of that gave
us static equivalent of ln foo bar. And it worked. The rest was essentially
the same - the only tricky part was to find the location of directory entry.
Which was done with (lseek, read byte, exit(said_byte)) and shell wrapper
around that. So we had a way to read a block and dump it on the console.
The rest was obvious - start from relevant block in inode table and walk
through the references... Once we got that, it was an easy ride - trick
with inumber flipping brought libc and dynamic linker back and after that
we had 99% of system back into the working state. Amazing how little you
actually need to bring the system back to life...

Hot damn that's some deep hackery...

Simon McVittie: Implementing D-Bus services with telepathy-glib

16:46 < epmf> tp-glib is made of magic
—#telepathy, 2008-04-15

Rob pointed out today that I'd been promising to blog about telepathy-glib for several months and still haven't done so. I think there's too much to cover in one blog post, so I'll start with the oldest part - implementing a service (typically a Telepathy connection manager).

While telepathy-glib is (obviously) intended for Telepathy implementors, I think the ideas we've been implementing are likely to be useful for any D-Bus API, particularly flexible/complex APIs where an object implements many interfaces.

Introduction to telepathy-glib telepathy-glib started out as a collection of code extracted from our XMPP connection manager, telepathy-gabble, but at some point it grew beyond that into a wrapper around/partial replacement for dbus-glib. We've been quite pleased with it, really :-) My first major round of work on telepathy-glib, during the first half of 2007, was to split it out from telepathy-gabble (versions up to 0.5.9 were released as part of Gabble 0.5.x tarballs, in fact), leading to the release of the 0.6.x stable branch in late September. This was very helpful for implementing connection managers - Salut, Idle and telepathy-sofiasip (our connection managers for link-local XMPP, IRC and SIP) all started off by forking/cargo-culting from Gabble, and achieved huge code reductions by porting to telepathy-glib. Also, Will Thompson used it in his Summer of Code project, telepathy-haze, to go from nothing to a working and useful Telepathy implementation based on libpurple in a matter of a few months. The second major round of work, which I'll discuss in a later article, added client code to telepathy-glib, obsoleting the older/worse libtelepathy and allowing client programs like Empathy and telepathy-stream-engine to be written using telepathy-glib. In the process, I accidentally reinvented DBusGProxy :-) More details to come later!

Some background: service-side code generation

The secret Collabora code-generation process

(credit: daf)

Supporting D-Bus in the GObject world has always involved quite a lot of code generation. The core API of dbus-glib is heavily reliant on varargs functions, which aren't type-safe and are easy to get wrong. dbus-glib contains a program called dbus-binding-tool, which is meant to generate reasonably sane GObject APIs for D-Bus objects. Unfortunately, it seems to be intended to generate a whole GObject at a time. Early versions of telepathy-gabble used dbus-binding-tool plus a script called gengobject.py to generate API stubs for the exported objects; developers then filled in the blanks, and hey presto, we had a GObject on D-Bus. This was fine up to a point, but had a couple of major drawbacks. Whenever we changed the D-Bus API (quite common during the early development of Telepathy), there was a very laborious and error-prone merging process. We ended up with the following process:

copy the D-Bus introspection XML from the telepathy-spec repository into a directory xml/pristine (actually, the canonical form for the spec was Python for a while, and we had a script that exported a contrived object onto D-Bus and introspected itself to get the XML - but that's another story!)
preprocess the introspection XML to add the dbus-glib CFunctionName annotation, resulting in a directory xml/modified
run dbus-binding-tool and a Python script gengobject.py to generate C source in xml/src
three-way-diff the old version of xml/src, the new version of xml/src, and the real C code in src to create a new version of src
pray that the diff process hadn't randomly exchanged functions' implementations
update the resulting code in src so it worked
check the whole mess back into darcs
hope that nobody else had made changes that would result in darcs conflicts

If you haven't yet gathered, this was a bit of a nightmare. Also, it was very easy to return the wrong thing from a method without noticing - because all the APIs were varargs, the compiler didn't notice, and the first we'd know about it was a mysterious segfault under certain circumstances.

How telepathy-glib fixes code generation telepathy-glib improves on this by taking advantage of this innocuous-looking feature in dbus-glib:

commit 355ef78d98d6fc65715845d56232199162cab12a
Author: Steve Frécinaux <steve istique net>
Date:   Thu Aug 17 11:48:20 2006 +0200
    Interface support for bindings.

Instead of running dbus-binding-tool or creating GObjects with D-Bus interfaces, we put the entire Telepathy spec through glib-ginterface-gen.py, a distant descendant of Gabble's gengobject.py. For each interface in the spec, we generate a GInterface that mirrors the D-Bus interface. Any GObject that implements the GInterface automatically gets the D-Bus interface if it's exported onto D-Bus. There are a few non-obvious refinements, though:

The signature of the method implementation is always in the mode that dbus-glib calls "asynchronous", where the method implementation can either send a reply message before or after it returns. For "slow" methods, this is the only thing you can do. For instance, many Telepathy D-Bus methods can't return anything until some TCP round-trips to the server have happened. This is also the only thing you can do if you want to extract extra information, like the sender's unique name, from the method-call message (dbus-glib's "synchronous" API doesn't allow this to be done). For "fast" methods, sending a reply message before returning is just as easy as using the "synchronous" API (it's just a difference of syntax), and has an API consistent with that of the "slow" methods, making it easier for service authors.
The layout of the GInterface vtable is private, and (auto-generated) accessor functions are used to fill in implementations. This means our ABI doesn't change just because we re-ordered functions in the spec.
If no implementation is provided for a method, we just raise an appropriate error (org.freedesktop.Telepathy.Errors.NotImplemented), rather than suffering an assertion failure. This means we can safely add methods to an interface.
While we're generating code anyway, we generate some static inline wrapper functions which wrap dbus_g_method_return(), to have type-safe method returns. You can easily check that a method replies with correct types, by checking that the implementation of Foo() replies by calling tp_svc_some_interface_return_from_foo().
Similarly, we generate wrapper functions to emit signals, to get type-safe signal emission.

Not all interfaces are stable enough to be included in telepathy-glib's stable API and ABI, so some of our other projects include a copy of the telepathy-glib code-generation tools, and generate their own "mini-telepathy-glib" (traditionally in a /extensions/ directory) for their implementation-specific (drafts of) interfaces. This isn't yet as polished as it ought to be (mainly because we don't want to freeze the augmented-introspection-XML format that we write the Telepathy spec in, because it's rather ad-hoc and hackish in places) but it works quite well in practice. To see what this looks like in practice, have a look at the examples in telepathy-glib, or at a Telepathy connection manager like telepathy-gabble.

Mixins and base classes Another feature of telepathy-glib which makes life easier for connection manager authors is that it provides "mixins" and base classes which implement some of the GInterfaces. There's absolutely nothing magic about the base classes - they don't have any access to private implementation details of the GInterfaces, they just implement them like everyone else does. The "mixins" are only slightly more magical - they store some extra state inside the structures representing GObjects and their classes, and use it to provide default implementations of some or all of the methods on a particular interface (or two interfaces, in the case of the new TpMessageMixin). I'll leave it up to Rob to explain those in greater detail, since I seem to remember that he invented them :-P The examples and regression tests in telepathy-glib are quite good examples of how these work in practice.

Clint Adams: Saciar esta locura

I shall sleep the sleep of the damned, swathed in sateen and the silken locks of angels. I will dream of Faberg eggs resting atop a plateau of gabardine. Blessed are those who walk the path betwixt linen and twill, watching the chain links cross the sky, breathlessly seeking Heaven. I hope that J.K. Rowling does not sue me for mentioning MayoKetchup .

Patrick Winnertz: Demotivaton of new prospective Developers

I'm writing this blog entry as a reaction of Lucas Nussbaums one. More or less one year ago I also was a New Maintainer who completed the process after 3 months (Started in February and ended in May). My Intention was to become as fast as possible a Developer and I was very motivated. (I helped Lucas with filling the build twice in a row bugs in this time). The FD approves me quite fast... (I'll guess I was only waiting for two weeks?) but the next to steps (Approval of DAM and creation of the account) took very long. After waiting for 3 months I was quite demotivated and doing only necessary things in order to update my packages... it was very frustrating. But now I'm finally a DD, since 6 months. For those who doesn't want to calculate: I was waiting for DAM about 4 months. When I saw that I was again highly motivated and started again to work on Debian a bit more, because I thought that the account creation can't took long...this was an error: I was approved by DAM in the middle of October... and got my account in Dezember... again waiting for a simple action. I can really understand New Maintainer who are directly MIA after being a DD. Waiting a half year for account creation is much too long. In my eyes there is only one possible solution for this issue: Since DAM and the Account Manager have also many other tasks which consumes there time, I would suggest to give them assistants...every manager needs at least one assistant ;-). This would speed up the process and people who are doing actually a great job doesn't get frustrated by waiting, but can actively work on Debian. I hope that the new DPL will find a solution for this really big issue during his time.

Next.

Previous.