Search Results: "ema"

14 August 2008

Steve McIntyre: Past halfway through Debconf already... :-(

I've had an outstandingly good time, as expected. Much kudos to the local team here in Argentina for organising the conference so well, and it's great to see that the efforts of the video team are making it possible for lots of people to attend the talks virtually as well. Good work, folks! My highlights so far: Unfortunately, the end of the week is quickly approaching. I'll have to head back to England all too soon.

Uwe Hermann: Physical memory attacks via Firewire/DMA - Part 1: Overview and Mitigation

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic: They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs: Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools: Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know. David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394. I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support: 
  $ modprobe ohci1394 phys_dma=0
I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext: 
  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext
Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

13 August 2008

Mark Brown: Paging Doctor Grumpy

Please, folks, when emailing the same question to multiple people or places send a single email with multiple recipients. Don’t send separate mails to each destination - at best you’ll waste people’s time, at worst you’ll irritate them. There are a few exceptions, mostly to do with confidentiality, but they really are pretty rare - especially for free software. Not that this should be in any way news or non-obvious.

Julien Danjou: Save power, aka easy CPU frequency scaling

Recently I came with the idea that my big computer is just useless. I know I was not using its entire CPU power, so I decided to take a look at CPU frequency scaling. Last time I tried, it was a PITA, required something like a daemon, and just did not work. With recent hardware and/or kernels, it's just easy as Debian. etch lenny On my box, the 3 GHz CPUs (Core 2 Duo) are running at 2 GHz (the lower value) at 99.13% of the time. That's almost a bit less power wasted.

Julian Andres Klode: Joined Software in the Public Interest (SPI)


On Monday, I joined Software in the Public Interest (SPI). I’m currently a non-contributing member and have already applied for contributing membership. MJ Ray asked why people do and dont join SPI, and received answers. Not knowing SPI is no good reason, at least if you are participating in Debian’s development, and you should really know SPI if you are a Debian Developer. For me, personally, not joining the SPI would not make any sense. The existance of other organizations is no good reason. Look at me, I am also a Fellow of the Free Software Foundation Europe. There is only one reason which seems to be a bit right: It’s hard to join SPI. The membership information is located at ‘About -> Membership’ in the menu. Maybe this should be made a top-level menu-item and a big link “JOIN!” should be put on the homepage. I see no reasons for anybody to not join SPI. All you need to join is a valid email address and interest in free software.

12 August 2008

MJ Ray: DebConf 8 Video Team Gives Excellent Service

DebConf, the annual Debian Conference, is held this year in Mar del Plata, Argentina. One sometimes-overlooked part of this is the brilliant video streaming service, with each stream supported by an IRC feedback channel including announcement of talks and events as they approach, start and finish. While I was watching Martin F. Krafft’s talk yesterday (which introduced the topgit patch manager to me, which I’ll look at and may suggest to the Koha project), I was blown away by the production quality of the video. It’s even better than last year, which was already good. The shots of the slides with the presenter in a little window on them are a particularly clever idea and much better than the “auto-refreshing slides webpage” method I’ve seen from other conferences. It does look like a little encoder tweaking might be possible to get the slides (which don’t change much) pixel-perfect while compressing the presenter window, but I’d be happy if all conferences were covered this well. Read the debconf announcement for links to the streams and schedules. I was having a few problems watching this afternoon (packets getting lost between telecomplete and bytemark), but switching to a European video server helped it. Mplayer’s hardframedrop also seems to help in bad network conditions, but it takes multiple attempts to get a successful connection from mplayer, for reasons I don’t understand. The conference continues until next weekend, which includes Debian’s 15th anniversary.

Joerg Jaspert: DebConf8 - And time after it

Third day of DebConf8 now - and it has been a pretty nice time since I arrived. The local orga team is doing a marvelous job, making this whole conference a really nice experience for about every attendee. Thanks to that we had a lot of time doing actual Debian work, which meant that we got a nice number of changes in dak either done or planned for the future, including a redesign of our database schema. Which is urgently needed if we want to follow some of the points we discussed. Like throwing away apt-ftparchive and generating the Packages files ourselve. Or various other enhancements. So for dak, the changes are summarised into: But we did not only do work on dak, we also did some work for the conference. In the days down here we (re)wrote the Pentabarf entrance controller, enabling our frontdesk to check people in, keeping track of various details they need to know about them. We wrote entirely new controllers for Pentabarf, one of it being the part that manages this years Assassins game. Other orga team members (hello triple des :) ) wrote a video and a volunteer controller. I guess after DebConf we will have some fun time to merge our changes back to upstream.
Travel in .ar Oh well, as some people know, I stay in Argentina for about 10 days more after DebConf is over (my flight back goes on 27. August, in the evening). Up to now I haven’t decided - or even started planning - what I do here. I should probably look at that soon. Hrm. Anyone out there doing something similar the next days? :) Comments: 0

Russell Coker: SpamAssassin During SMTP

For some time people have been telling me about the benefits of SpamAssassin (SA). I have installed it once for a client (at their demand and against my recommendation) but was not satisfied with the result (managing the spam folder was too complex for their users). The typical configuration of SA has it run after mail has been accepted by the server. Messages that it regards as spam are put into a spam folder. This means that when someone phones you about some important message you didn’t receive then you have to check that folder. Someone who sends mail to a user who has such a SA configuration can not expect that the message will either be received or rejected (thus giving them a bounce message). Even worse it seems to be quite common for technical users to train the Bayesian part of SA on messages from the spam folder - without reviewing them! Submitting a folder of spam that has been carefully reviewed for Bayesian training can increase the accuracy of classification (including taking account for locality and language differences in spam). Submitting a folder which is not reviewed means that when a false-positive gets into that folder (which will eventually happen) it is used as training for spam recognition thus increasing the incidence of false-positives! Spam has been becoming more of a problem for me recently, on a typical day between 20 and 40 spam messages would get past the array of DNSBL services I use and be re-sent to pass the grey-listing. Also I have been receiving complaints from people who want to send email to me about some of the DNSBL and RHSBL services I use (the rfc-ignorant.org service gets a lot of complaints - there are a huge number of ignorant and lazy people running mail servers). So now I have installed spamassassin-milter to have SA run during the SMTP protocol. Then if SA checks indicate that the message is SPAM my mail server can just reject the message with a 55x which will cause the sending mail server to generate a local bounce (if it’s a legitimate message) or to just be discard it in the case of a spam server. Here is how to set it up on Debian/Lenny and CentOS 5: Install the package yum install spamass-milter or apt-get install spamass-milter spamassassin spamc (spamassassin seems to be installed by default on CentOS). On a Debian system the milter will be setup and running. On CentOS you have to run the following commands:
useradd -m -c "Spamassassin Milter" -s /bin/false spamass-milter
mkdir /var/run/spamass-milter
chown spamass-milter /var/run/spamass-milter
chmod 711 /var/run/spamass-milter
echo SOCKET="/var/run/spamass-milter/spamass.sock" >> /etc/sysconfig/spamass-milter On CentOS edit /etc/init.d/spamass-milter and change the daemon start line to ‘runuser - spamass-milter -s /bin/bash -c "/usr/sbin/spamass-milter -p $SOCKET -f $EXTRA_FLAGS"‘ Then add the following lines below it:
chown postfix:postfix /var/run/spamass-milter/spamass.sock
chmod 660 /var/run/spamass-milter/spamass.sock The spamass-milter program talks to the SpamAssassin daemon spamd. On both Debian and CentOS run the command “useradd -c Spamassassin -m -s /bin/false spamassassin” to create an account for SA. The Debian bug #486914 [1] has a request to have SA not run as root by default. On CentOS it seems that SA wants to use a directory under the spamass-milter home directory, the following commands alllow this. It would be good to have it not do that, or maybe it would be better to have the one Unix account used for SA and the milter.
chmod 711 ~spamass-milter
mkdir ~spamassassin/.spamassassin
chown spamassassin ~spamassassin/.spamassassin On Debian edit the file /etc/default/spamassassin and add “-u spamassassin -g spamassassin” to the OPTIONS line. On CentOS edit the file /etc/sysconfig/spamassassin and add “-u spamassassin -g spamassassin” to the SPAMDOPTIONS line. To enable the daemons, on CentOS you need to run “chkconfig spamass-milter on ; chkconfig spamassassin on“, on Debian edit the file /etc/default/spamassassin and set ENABLED=1. Now start the daemons, on CentOS use the command “service spamassassin start ; service spamass-milter start“, on Debian use the command “/etc/init.d/spamassassin start“. Now you have to edit the mail server configuration, for Postfix on CentOS the command “postconf -e smtpd_milters=unix:/var/run/spamass-milter/spamass.sock” will do it, for Postfix on Debian the command “postconf -e smtpd_milters=unix:/var/spool/postfix/spamass/spamass.sock” will do it. Now restart Postfix and it should be working. For correct operation you need to ensure that the score needed for a bounce is specified as the same number in both the spamass-milter and SA configuration. If you have a lower number for the spamass-milter configuration (as is the default in Debian) then bounces can be generated - you should never generate a bounce for a spam. The config file /etc/default/spamass-milter allows you to specify the score for rejecting mail, I am currently using a score of 5. Any changes to the score need matching changes to /etc/mail/spamassassin/local.cf (which has a default required_score of 5 in Debian). You can grep for “spamd..result..Y” in your mail log to see entries for messages that were rejected. One problem that I have with this configuration on Debian (not on CentOS) is that spamd is logging messages such as “spamd: handle_user unable to find user: ‘russell’“. I don’t want it to look for ~russell when processing mail for russell@coker.com.au because I have a virtual domain set up and the delivery mailbox has a different name. Ideally I could configure it to know the mapping between users and mailboxes (maybe by parsing the /etc/postfix/virtual.db file). But having it simply not attempt to access per-user configuration would be good too. Any suggestions would be appreciated. Now that I have SpamAssassin running it seems that I am getting about 5 spams a day, the difference is significant. The next thing I will do is make some of the DNSBL checks that are prone to false-positives become SpamAssassin scores instead. When I started writing this post I was not planning to compare the sys-admin experiences of CentOS and Debian. But it does seem that there is less work involved in the task of installing Debian packages.

Share This

11 August 2008

Benjamin Mako Hill: Making Wiki Images More Wiki

One thing that has always annoyed me about most wiki is the way they handle images. MediaWiki, like most wikis, allows users to upload images and embed pictures. However, if you want to change an image, you need to download the file, open it up in GIMP, Inkscape, or Photoshop, edit it, save it, and re-upload it. Somewhere in this long process, the ease of editing that makes wikis so wonderful gets lost. Basically, I'm annoyed because images in wikis aren't very "wiki." I had a talk with Brianna Laugher at Wikimania about ways to make it easier to folks to edit pictures from within the browser -- even if it is only simple stuff. Yesterday I took the afternoon to write a new MediaWiki extension which gives a working example of in-browser image editing. It provides the ability to crop images using David Spurr's wonderful Javascript cropping user interface and uses ImageMagick to do the actual image manipulation. It is in the form of an extension to Mediawiki I've called EditImage. It's an afternoon hack from an under-qualified PHP hacker so it's nothing special. You can read it about on its page in the Mediawiki wiki and you can try it out on my personal wiki where I have it installed. I'm certainly not the first person to think about doing this. In fact, some old pages in the MediaWiki wiki imply that I'm not even the first person to play around with the idea of using Spurr's code to do image cropping for MediaWiki. Hopefully though, my code can act as a nice first step and a framework for folks wanting to add additional image manipulation features. For example, I think it would be quick to add the ability to do in-browser brightness and contrast manipulation and I would love to see this in a future version of the extension.

Eric Dorland: Sentiment Sharing

Biella, I am from there and I do agree. If I was still living there I would try to form a team and make a bid. Simon even made noises about organizing a bid at DebConfs past. I wish he would :)

But a DebConf in New York would be almost as good.

Biella Coleman: Oh Montreal

Rumor has it that NYC may be proposed for Debconf 10. While that would mean I would most likely go, since I do live there, now that I visiting Montreal, I can't think of a better place for Debconf.... Wonder if anyone else, especially from there, shares my sentiments :-)

10 August 2008

Alexander Reichle-Schmehl: Bits from the DPN editors

It's more or less four months since I proposed to resurrect our newsletter. We already released eight issues of the Debian Project News and work for the ninth issue has already started. So I guess it's time for a small "state of the DPN" speech, but since I'm not attending DebConf, you will have to read this mail instead ;) After having a rough start (and in fact missing some self-set deadlines and completely underestimating how much work is involved in such a kind of newsletter) we finally developed a - more or less - working flow of work (Which is by the way documented here). Speaking of the current state sadly means to confess, that our hopes to draw a lot of help from the community by using a system for drafting the news with a low entry barrier were not fulfilled. We actually had a good start, with good participation, but due to (I assume) the aforementioned initial difficulties participation in the creation of the DPN dropped considerably. Currently the workload of creating our bi-weekly newsletter is shared by only two people (that being Meike Reichle and myself), which is barely enough :( While we at least get a hint from time to time, what we should mention in the next issue, it rarely happens, that someone contributes by drafting a text -- which is the real work. (At this point a BIG "Thank You" to those who did! (See list bellow.) It's much appreciated!) We suffer especially, since although we are a two people team, we have in fact no redundancy, since real live issues affecting one of us will most likely affect the other one, too. Therefore we mostly concentrated our work on creating the next issues and getting them out in time, and didn't have time to answer all mails considering suggestions for changes and improvements (yet?). We are sorry, but at least we tried to read them briefly and keep them in mind when drafting the next issue. As a result of this we re-added the list of DSAs, WNPP and new and noteworthy packages due to popular demand. There are still a lot of unanswered mails not dealing with content, but with workflow issues / proposals (including changing from wiki.debian.org to a special ikiwiki instance). We are sorry, that we couldn't yet act on them and take appropriate measures, but be assured, they are not forgotten. Other issues the DPN currently have are "unwritten guidelines" regarding editorial choices of DSAs to be published and which packages to list in the "new and noteworthy package" section. Both is more or less done by our gut feeling. Speaking of problems the DPN are facing, we also need to mention translations of the DPN. The current workflow makes it difficult for translators of the DPN, since we often fail to get the final draft of the DPN ready in time to give translators a "head start" so the translated DPNs can be released together with (or at least with a as small as possible delay to) the English DPN. So here is a big call for help! We really need your help writing the DPN. (Monitoring lists and newstickers we don't monitor ourselves would be nice, too, but only add more work to us if you only give us pointers.) We will both be very busy with our real live the upcoming month, and are not sure how much time we can dedicate to the DPN. So please help us! The current draft for the next issue of the DPN is always available here . There should already be a todo list with pointers to interesting topics, which need to be written out. Some guidelines about style and content are available here. Last but not least, we would like to thank the following people who have contributed to the DPN so far: (Unfortunately we can't list those people, who contributed by translating the DPN, nor do we have a complete list of the native English speakers, who helped by proofreading. But we thank them nonetheless!)

9 August 2008

Wouter Verhelst: Mail "migration"

I never thought I'd have to use my 'cluebat' section in my blog for myself, but apparently I do. Since I moved out, a while back, mail to wouter@grep.be (and w@uter.be) was still being delivered on my Thecus N2100 that serves as server and internet gateway at my parents' place. This made sense when I set it up, because I don't usually read mail anywhere but home. Since I now don't live with my parents anymore, however, I don't usually read mail anywhere near that server anymore. So, I'd been preparing to move the mail endpoint from goa (the Thecus) to samba (which has been my primary MX for quite a while, and which also has sufficient disk space to do so). Yesterday I made the switch, but forgot the important thing of checking up on whether the mail was actually arriving. I'll spare the details, but suffice to say that I did make an error, and that over the last 12 hours, not a single mail that was sent by a server not known to me could send email to any of the grep.be or uter.be domains, amongst others. It wasn't blackholed (only 5xx'ed), but that's bad enough; I've now probably been kicked off every mailinglist in the universe. Go me! Anyhow; if you sent me an email and you expect me to read it, you may want to send it back. Off trying to resubscribe myself to some mailinglists now...

8 August 2008

Tollef Fog Heen: eweouz 0.1 released

I just released the first version of eweouz, the interface between emacs and evolution-data-server. Sources are available, no packages yet. It is now possible to both add contacts from within gnus and search for contacts. Patches and feedback is of course welcome.

MJ Ray: Is Yahoo Now Even Worse On Spam?

When working on mailservers, I’ve noticed that Yahoo’s mailservers seem to “punish” others by sending code 421 (service not available) for a few minutes for a first report of spam that originated from there, longer for a second report and so on. Yahoo’s help pages suggest they do this if you don’t “comply with our guidelines (described below)” (which aren’t actually described below). That system seems to completely screw everyone on a server if a user forwards their own email to Yahoo and then flags some as spam, or if a website user who registered with a Yahoo mail address then closes their Yahoo account without updating their registration details. In the worst cases, a server’s mail queue can become clogged with stuff that it can’t forward to Yahoo. I’ve suggested that server owners ban forwarding to Yahoo, but not all have done that yet. Yahoo’s server-punishing tactics are particularly unfair because of the amount of spam we receive from Yahoo - when I tried rejecting that, the server tested seemed to get more 421 punishment for that. I now usually direct it to a blackhole, which feels a bit dangerous. Now I’ve just seen this from Indymedia which makes it sound like Yahoo’s getting even worse recently:-
“Yahoo doesn’t make it so easy for us. They do (unintendedly) transport a remarkable amount of spam, often sent by robots which automatically (and wide scale) crack Yahoos’ new account signup CAPTCHAS (those images with the cats + dogs + digits + letters in them) just to relay their spam through Yahoo. So it’s not easy to determine who sends legitimate email through Yahoo and who does not.”
I wrote about some alternative service providers back in 2006, including ippimail, which Yahoo users might like to change to. I’d be interested in comments about any new arrivals in this field. BT internet customers are probably using Yahoo-hosted email too. I recommend changing to The Phone Co-op, but my company is an agent for them, so I would say that, wouldn’t I?

7 August 2008

Sandro Tosi: Another info source for Debian

It seems that #debian-devel@OFTC channel topic is used to inform for some particular situations, even grave ones (like HP Fort Collins outage of today).

But what to do if you'd like to be alerted for such situation and you can't check IRC, or you prefer different communication medium (like mails or feeds)?

There is a nice page on wiki.d.o that's been updated every time that #debian-devel@OFTC topic is changed. So, go there and simply subscribe to it (and you'll receive emails every time the page is changed). There should be a way to get an RSS feed from a MoinMoin page, but can't find a way: suggestions?

6 August 2008

Kartik Mistry: I AM DD now!


* I think it will take time to have updated status on my NM status page but I can’t resist myself because, - kartik@debian.org works - I updated db.debian.org - Added uid in my GPG key and synchronized it with Debian Keyserver - Updated Developers location So, in short, all these things means: I AM DD NOW! Many thanks to My family (Koki, Mom, Papa, brother Rinit and Little Kavin for supporting and encouraging me during this long journey), Jaldhar Vyas for advocating my application, my AM Mohammed Adn ne Trojette (adn), all kind and helpful sponsors of my n number of packages (jaldhar, mones, adn, daniel (special thanks for number of uploads), pabs, joeyh for Festival upload, rkrishnan, acid, tolimar, twerner, bubulle, nijel, bernat, marillat, akumar, hertzog and finally gwolf). Special mention and thanks to bubulle and sam - for coming down and having nice meet at BLR during foss.in/2007, that gave my power back to continue my work when I was frustrated with certain situations. Another special thanks to dear friends - nirav, pradeepto, tuxmaniac and atul chitnis for always encouraging me for my Debian work. In short, you all people rocks! Now, what next? I will keep continue doing my packging work as it is, I have plan to get involve more in near future, but as of now - I first need give time and focus RC bugs for Lenny :P

Christian Perrier: Holidays report

Sure, that sounds fairly formal to send a report for holidays, doesn't it? Anyway, as I have a few (often Debian/FLOSS related) friends around the world who are reading my blog entries, this might interest them so that's indeed a report..:-)...and I have time for it, so... I'm currently going back from Cahors to Maurepas (home), on my way to Debconf. We spent 10 days in Cahors with Elizabeth and the girls, finally joined by Jean-Baptiste on Sunday. We had great time over there, enjoying the richness of Quercy: So, I'm now heading back home, assemble stuff and will take off for Debconf on Thursday 7th (Paris Orly to Madrid, then Buenos Aires via Air Europa: IIRC nobody from Debconf is in the same flight). "Assemble stuff" here also means collecting cheese for the now famous Debconf Cheese&Wine party. That one will be tricky to achieve as most of us are coming from quite far away and...there are only 6 French citizens who attend DC8..:-)). Anyway, I already know that my fellow Nicolas Fran ois (namely nominated as Assistance CheeseMaster recently) will bring some good stuff. I haven't decided yet what to bring. I might be influenced by my holidays, so cheeses from South-West France are highly probable. Cahors wine will be the choice (prepare yourself: that is strong stuff). At Debconf itself, we'll have a quite busy schedule. I intend to mostly work along with Felipe, Nicolas, Grisu and others on i18n.debian.net. I'll have to animate the i18n sessions for which I want to prepare some schedule instead of just "lat's gather and talk" which didn't work so well last year, IMHO. And I have that bloody keynote lecture which, BTW, could be rescheduled if I properly read debconf-discuss as, finally 9am for keynotes seems to be considered too early for the late birds at DC8...:-)... We'll see: I will certainly have something that's not very well cooked and prepared. Expect some improvisation: this year I didn't want to stress myself with a talk, slides and blahblah. Elizabeth will come back from Cahors on Saturday with the kids. She'll have a holiday week at her father's place whil ethe kids will....do their stuff at Maurepas (this is what happens when kids are grown up). We'll gather together again on Aug 18th and I go back to work on 19th. Crazy, I know but I have a very busy and full work schedule for the upcoming next 2 months. September will be a hard time to go through: Jean-Baptiste will start his "Licence Profesionnelle" in Automated and Embarked Systems. He'll do it in shared time: half-time at university for classes and half-time working in a company (which turns out to be Essilor, the world leader for progressive glasses....and the company which Elizabeth is working for). He'll stay at my sister-in-law place during the week (30km away from our place but closer from university and work). Sophie, our 18-year old daughter, will spend the year in Toulouse, to prepare the admission in a Social Workers school. She'll have her own apartment, in the very center of the city, 20 meters away from Place du Capitole. Annoying, isn't it ? :-) So, we'll mostly stay with our "little" Magali, our 16 y.o. who will be attending High School, on her way to Baccalaur at. Tell us about shrinking families.... Now time to work on some slides for the Debconf keynote. Damn.

5 August 2008

Eric Warmenhoven: Expensive toys, expensive repairs

This past weekend, I took my Canon EF 24-105mm f/4L lens to take some indoor pictures. I had been using it previously to take outdoor pictures, and had used my polarizer, and left it on the lens when I was done. So this weekend, I tried taking it off, and couldn’t. That’s the first time this had happened to me. I wasn’t sure what to do. Fortunately for me, before I did anything too extreme, Adam suggested I get a filter wrench. So I headed over to Wolf Camera to get one. Wolf didn’t have one, so I asked where I could get one, and they suggested someone else who also didn’t have one, but they suggested Keeble & Shuchat Photography, who I had been to before. They did have wrenches, but not in the size that I needed. They suggested I just bring the lens to their repair department, which I did. Fifteen minutes later, the filter still wasn’t off the lens, and they had given up. My lens is now on its way to Canon USA for a repair, and hopefully I’ll get both parts back, separated, and in usable condition. They estimated the cost would be somewhere between two and three hundred dollars. I guess that’s what happens when a lens that costs $1000 and a filter that costs $100 decide to misbehave in tandem. And I was hoping the repair would be a simple $5 filter wrench!

William Pitcock: LSB 4 doesn t fix things any better than LSB 1, 2 or 3 did.

As mentioned elsewhere, LSB 4 is due out soon, and won’t really make a lick of difference when it comes to improving compatibility with non RPM/redhat-like systems. With software appliances and software as a service becoming more relevant, and appliance-oriented non-RPM distributions like rPath, Ubuntu JeOS and Defusion coming around that offer equal (or arguably better) value to customized Fedora/RHEL/CentOS and improved administrative ability due to using tools not stuck in the 1990s (RPM, I am looking at you here), one would think that the LSB working group might actually want to make LSB not suck. Right now, Debian derivitives like Ubuntu JeOS and Defusion can compete by using alien, and rPath has the RPMPackageRecipe for conary, but these are kludges and carry their own share of problems. So, why does the LSB require a specific format? There’s no reason for them to. Really, LSB compliance is a redhat-only club. Not just an RPM-only club… last time I checked, SuSE is in the same boat as everyone else and they use RPMs. A lot of the LSB needs to simply be ripped out in order to do any good. Until the LSB working group is willing to drop a lot of the RedHat-isms they have had, non-RedHat distros will always have problems complying. What about source-based distros like Gentoo for example? There is really no easy way they can comply by default (on the other hand, do they care to?). To put things simply, the LSB sucks. Here’s why: Ideally, the LSB spec would define a config format capable of describing how the system worked, and all of that, but it doesn’t. Until it does, then the LSB spec is worthless, because it can’t handle all distributions (even the common ones).

Next.

Previous.