Proving [ ] that a team was the best way to maintain large package sets changed the way people work on Debian.

Our huge bug backlog will never be dealt with.

1. General lack of configurability
2. Strange design decisions
3. Red Hat centric development
4. Hardware requirements
5. Change resistance

On the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.

In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.

3 years [of support] is really not enough for corporate users.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .

8 comments Liked this article? Click here. My blog is Flattr-enabled.

    PROC *new;
 
    if (!(new = malloc(sizeof(PROC))))  
        perror("malloc");
        exit(1);
     
    strcpy(new->comm, comm);

#6  new_proc (comm=0x6111b0 " console-kit-dae ", pid=1571, uid=0)
  at pstree.c:267

Related articles

• Detecting security problems using static analysis to catch them early and less expensively (blogs.windriver.com)
• A Textbook Buffer Overflow: A Look at the FreeBSD telnetd Code (thexploit.com)
• Exploit the buffer Buffer Overflow Attack (alitarhini.wordpress.com)
• Aurelien Jarno: Performances of open-source Radeon driver (aurel32.net)

E:  3,4:Foo.foo: An attribute affected in foo line 12 hide this method

class Foo:
    def foo(self):
        return True
    def foo_override(self):
        return False
    def __init__(self, override=False):
        if override:
            self.foo = self.foo_override

foo = Foo()
moo = Foo(override=True)
print "expect True  : %s" % foo.foo()
print "expect False : %s" % moo.foo()
print "expect True  : %s" % Foo.foo(foo)
print "expect False : %s" % Foo.foo(moo)

$ python ./foo.py 
expect True  : True
expect False : False
expect True  : True
expect False : True

... the special thing about methods is that the object is passed as the first argument of the function. In our example, the call x.f() is exactly equivalent to MyClass.f(x). In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method s object before the first argument. [Official Python Tutorial]

>>> print moo.__dict__
 'foo': <bound method Foo.foo_override of <__main__.Foo instance at 0xb72838ac>> 

1. The generated symbols file was HUGE. Hundreds of lines. This is a marked difference from the typical C symbols file, which is of quite manageable size. Some of that is that the library provides a lot of different classes, but some of it is that C++ just generates a lot of exported symbols. There's no way that I could do what I would do with a C library and understand those symbols, why they're there, and whether they are likely to have changed between revisions.
2. Generating a reasonable symbols file was a pain. Generating an unreasonable symbols file that just contains all of the mangled symbols is largely mechanical and uninteresting, but that symbols file doesn't seem to me to convey useful information. So I did some scripting to translate the symbols back with c++filt, and add (c++) tags, and then try to understand what I was looking at and figure out whether I should sort the symbols list because the default sort is by mangled name, which is meaningless. This is a rather unappealing process. It's not particularly difficult, but it's very awkward and feels like it's missing vital tools.
3. The resulting symbols file is incomprehensible to someone without strong knowledge of C++. It's full of opaque entries that don't make sense to the non-C++ programmer, which I suspect is a substantial number of people who package C++ libraries for Debian. I know enough C++ from school that I can evaluate security fixes, make simple patches, and review upstream changes, and I think that's all that should be needed to package things for Debian. But I'm deeply uncomfortable producing a symbols file on my own that contains entries for things that I know nothing about and cannot evaluate when they've last changed, like "non-virtual thunk to FooClass::~FooClass@Base".
4. Once I had a symbols file that resulted in a successful build and that I could have uploaded, I started thinking about how I was going to maintain it. With a C program, I would change the symbols file versions when the underlying function implementation changes in a way that may not offer eqiuvalence, similar to bumping shlibs. I realized that I was going to have no idea when that happened, and the only way that I would maintain the symbols file would be to either trust upstream to maintain ABI equivalence and therefore only change the symbols file when upstream changes the SONAME, or not trust upstream to maintain ABI equivalence and therefore change all the versions with each new upstream release. That gives me exactly the same semantics as a shlibs file, so what's the point in having a symbols file?
5. The exported symbols of the library contained many symbols that obviously weren't really from that library, but instead were artifacts of the C++ compilation process, things like instantiations of std::vector. Do those go into the symbols file? Do they change from architecture to architecture? If they disappear again, is that actually an ABI break? How do I know? It's all very mysterious, and while shlibs provides the same semantics as just ignoring this, at least I'm not then including in the package data, generated by me, things that I'm just blindly ignoring.

Filed under: English Phpmyadmin 0 comments Flattr this!

• Timeline of incidents in Geekfeminism. Note that while it seems we see more as time passes, I am almost sure it's because we are more aware of the problem, not because it occurs more often. I hope I'm not mistaken.
• Debconf ftp-masters talk. Myself a Debian person, my first contact with this problematic was being at the DebConf3 ftp-masters talk And the discussion and action that followed. This led to the creation of the Debian Women group, one of the most (socially, not technically) influent parts of Debian. Great thanks and admiration to their members, as well as to the (male and female alike) people who have worked to form it and make it heard.
  I think Debian Women sparked other similar projects such as GnomeWomen (and there is a list with further projects in there), but I cannot authoritatively say who was there first.
• Planet Fedora up-skirting photo (the original post is still available) showed the communit does no longer tolerate this behaviour. Good!
• The Open Source Boob Project. One of the most childlike attempts at humor that surely alienated many would-be female geeks.
• Another conference season, another dumb sexist, a post by Piers Cawley addressing this issue after attending the CouchDB + Ruby: Perform like a Pr0n star talk. Quoting him, Apparently, the difference between 80s truck salesmen and Matt s audience is that at least 80s salesmen had the grace to look embarrassed.
• Liz Keogh: "I am not a pr0n star: Avoiding unavoidable associations", a hacker woman that clearly felt offense by the CouchDB Pr0n Star joke, and did a thorough and interesting analysis, extending the effects to your work environment.
• Just Say You're Sorry Already (regarding the same incident on CouchDB+Ruby)
• Richard Stallman's EMACS virgins joke incident. It's sad how it's impossible to get Stallman to acknowledge he can also make mistakes and make feel people insulted.
• [update] And of course, MadameZou mentions the very important 2002 HOWTO: HOWTO encourage women in Linux?

• on mailing lists (debian-user@lists.debian.org for the English-speaking one);
• on IRC (channel #debian on irc.debian.org);
• on questions & answers websites like ask.debian.net;
• on web forums like forums.debian.net;
• on every other places where Debian users hang out together (on a booth during a conference, during an install party of a Linux User Group, etc.).

If you want to start contributing to Debian, click here to subscribe to my newsletter and get future updates for new contributors. You can also follow me on Identi.ca, Google+, Twitter and Facebook.

5 comments Liked this article? Click here. My blog is Flattr-enabled.

Dear Pvt. Adams-Collier: Thank you for contacting me about the Stop Online Piracy Act (SOPA) and the Protect IP Act (PIPA). I wanted to update you on my views on this important issue. I am opposed to SOPA and PIPA in their current forms. I believe that these bills create unacceptable threats to free speech and free access to the internet. I have heard from many of you in Northwest Washington who are deeply concerned about the potential impacts of SOPA and PIPA. Online piracy is a serious problem that costs U.S. businesses billions of dollars. Government agencies must be empowered to stop and prosecute intellectual property thieves. But in doing so we cannot undermine freedom of speech or jeopardize the free flow of information on the internet. I will work with my colleagues to see that any final anti-online piracy legislation protects the internet and does not encroach on free speech rights. Please be assured that I will keep your thoughts in mind should I have the opportunity to vote on any legislation that would impact online piracy and internet freedom on the House floor. Again, thank you for contacting me. I encourage you to contact me in the future about this or any other issue of importance to you. Sincerely, Rick Larsen
United States Representative
Washington State, 2nd District

• https://file.example.com/sha1/509c2fe2eba509e93987c3024a74d74583c274bd

 <a href="/foo" rel="sha1:xxxxx md5sum:xxxx">
  <img src="foo.jpg" alt="img name">
 </a>

1. Finish the translation of the Debian Administrator s Handbook The target is to have the book available in April. It would be nice to complete the liberation fund until then so that the book is immediately made available under a DFSG-free license.
2. Update the Debian Administrator s Handbook for Wheezy
Translating the book in English is only the start of the journey. The real challenge is to keep the book up-to-date with each subsequent release of Debian. And Wheezy should hopefully be released in 2012 since the freeze is in June.
3. Design and implement the Debian Package Maintenance Hub It s an ambitious project that aims to merge and replace the PTS, the DDPO and their respective mail variants. It should also standardize the flow of information directed towards package maintainers. I m going to use the DEP process to drive this project. This could easily take most of the year, but hopefully I ll motivate other people to chime in and help.
4. Implement dpkg --check-db and dpkg --repair-db While dpkg is fairly reliable, it s not exempt of bugs and more annoyingly, harddrives/filesystems are not 100% reliable either, thus it happens that some internal database files get corrupted. Given that most files are text based, advanced users can manually fix them but many less skilled users are just left with a broken system that they tend to reinstall. To avoid this, we could provide a command that would try to automatically bring back the internal database to a sane state by looking for a working backup to restore (while at the same time marking some packages as requiring re-installation since we have some indications that they were present).
5. Implement storage of dpkg s internal files in Git This would be an extension of the former idea. Installing a package dpkg-db-history (any idea for a better name?) would setup dpkg hooks that would record every database change in a git repository. This repository could then be used to restore the last working version of the database.

1. Write useful articles for Debian users and Debian contributors. They should complete the pages Mastering Debian, Contributing to Debian 101, Debian Packaging Tutorials, and help me increase the audience of this blog.
2. Write at least one Debian-related ebook (different from the Debian Admin Handbook) and sell it. It could be an ebook targetting testing users since I believe that many more users could benefit from it if they had some better knowledge of the limitations and of the way to mitigate the problems that arise from time to time. Or maybe it could be an ebook for people who want to start contributing to Debian, it could even be bundled with a few hours of mentoring.
3. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products. This means doing 3,5 times better than in 2011. It should be doable given that the sales of the Debian Administrator s Handbook will contribute to this goal (once the translation is over).

11 comments Liked this article? Click here. My blog is Flattr-enabled.

Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill). This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed. At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.

While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content. Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site. Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content. Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.

• Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
• Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
• Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
• and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

• Music files. They're currently stored on a plug computer at home and served over DAAP, but DAAP seems to become less and less of a priority for music players (I'll keep the music players suck rant for another post), and it has its inconveniences too. Ideally, the files should be integrated in the filesystem of my work computer, the one that serves as a media player in the living-room, the one I use for playing the backing tracks when I'm practising the drums, and the laptop I use when on the road too.
• Backups. My BackupPC currently runs on the plug computer at home, so backups of my remote servers are in a geographically distinct location; but backups of my home computers are not, and I'd like to change that without having to copy files around by hand. Backups do contain confidential data, so this adds a constraint on the filesystem.
• Bazaar repositories. I do have a script that pushes and pulls stuff across computers for the many repositories I use, but it's still awkward that I need to do that.
• Parts of my home directory, such as my browser preferences and bookmarks, or the database of the Hamster time tracking tool, or the working directories of stuff I do for clients, and so on. Again, each of those can be done with specific means (bookmarks synced to a server, CouchDB-like database, DVCS and regular commits, etc.), but wouldn't it be much simpler if there only was one file to begin with?

• Availability means redundancy: some of the storage nodes will be on dedicated servers in datacenters, others at home; I can imagine setting up the firewall so that the home computers are reachable from outside, but sometimes network links go down, and the home computers are far from being on 100% of the time.
• Availability/redundancy also means automated replication and rebalancing: if a node is added to the grid (or switched on), it should automatically get its share of the files so as to contribute to availability if another node goes down at a later time.
• Confidentiality: at the very least, network communications must be encrypted and authenticated; ideally, individual storage nodes wouldn't need to be able to access the stored data. If I store bits of my backups on a friend's server, I don't want to have to trust them not to look at the data; also, my friend may actually want to be unable to look at my data (to provide for deniability in case someone else wants to look at it).
• Performance: native disk performance may not be realistically reachable, but the system must be smart enough (or configurable enough) to store files on both sides of the ADSL link, for instance, so not all accesses need to go through the bottleneck.
• Integration with the system: I want a filesystem, not a storage system. All applications know how to navigate a mounted filesystem; very few will interface with an specific application designed to store and fetch chunks of data.
• Scalability would be nice, although my personal needs are still well below the terabyte range and I can't see myself using more than a dozen nodes or so.

• Availability/redundancy 1: all three candidates work on the net, and they all provide for data replication. XtreemFS seems to operate on a fall-back mode while the other two are more distributed (meaning there's no canonical node hosting any particular file). Tahoe uses erasure codes (files can be split across N shares, k of which are enough to reconstruct the whole file; the N/k ratio controls the amount of redundancy); it seems to require the introducer node to be always up, which introduces a single point of failure, but this node can be replaced with no loss of data if it fails (this just requires reconfiguring the storage nodes, which can probably be automated). Ceph can work with any number of meta-data servers, so redundancy is assured there (data itself can be replicated in a configurable way too).
• Availability/redundancy 2: either I'm a fool and I didn't find out about that, or none of the three candidates provides for automated rebalancing. Apparently Tahoe provides a way to repair files without enough redundancy, but that needs to be run manually on each file, rather than being systematic, and it's a kind of add-on to the system rather than being properly integrated. Ceph only does rebalancing of meta-data. XtreemFS seems to work a bit like RAID1 with spare disks, but details are scarce.
• Confidentiality: Tahoe wins, hands down. Neither network sniffers nor storage nodes can see the contents of the stored files. They can't even find out about their name or the directory structure. XtreemFS encrypts the data on the network (but it is still stored in cleartext on the nodes). Ceph doesn't even try.
• Performance: Ceph wins (or loses less, at any rate): it seems possible to configure a topology for the storage nodes, and to drive the storage location policy according to this topology; so I could define sets of nodes ( my servers in datacenters , my plug computer at home , my desktop and laptop computers , my friends' computers ) and decide that each file should be stored at least once on each set of nodes. Tahoe stores shares of files on a number of storage nodes chosed in kind of a round-robin way; read access uses the same round-robin system, which means that you will probably end up fetching a file at least partially over your slow link even when you could fetch it entirely from the local network. The XtreemFS website doesn't seem to acknowledge the possibility of the network being slow.
• Integration: Ceph and XtreemFS win: they're native filesystems. Tahoe is in the storage and retrieval system category; the FUSE layer is marked as experimental and not recommended, and the SFTP layer (which can be mounted as a filesystem with sshfs) has many documented drawbacks. Maybe a WebDAV frontend, combined with fusedav, would provide a working alternative, but it's not implemented yet.
• Scalability: all three candidates boast about scalability (in data size and in number of nodes). Ceph seems to require some configuration every time a new storage node is added. Tahoe seems much more dynamic: new nodes (storage or clients) just need to be told where the introducer node is, and then they merge into the grid seamlessly by being told about other nodes (a bit like Bittorrent, where clients learn about each other by asking the tracker).

• A configurable dispatch policy, so that administrators could define their own behaviour. The current Tahoe parts already turn files into a number of blobs that only need to be stored on various nodes, and the function that chooses which nodes seems to be reasonably self-contained, so it could maybe even be made pluggable, and an administrator could implement a storage policy that matches the constraints and the network topology. Ditto for the function that picks which nodes the data is read from (which, as far as I can tell, is the same; splitting could bring some benefits here).
• A working FUSE implementation, either on top of SFTP if the drawbacks can be fixed, on top of WebDAV if that gets implemented, or native to Tahoe if that can be done.
• Automatic rebalancing of data when new nodes are added or turned on, or when an intermittent network link comes up. The current script seems to be an afterthought; if it can be made more automated and more reliable, I'll be happy with that.

• eCryptfs on top of Ceph. The file contents are still only accessible to those in possession of the adequate key, and replication/distribution is handled by Ceph. That could probably work; the main drawbacks I can see come from Ceph's administrative overhead and manual configuration.
• LUKS and a standard filesystem, on top of the part of Ceph that manages block devices (RADOS). I'm not sure this could be mounted simultaneously by several nodes, though.
• LUKS on top of Ceph's RADOS, and Lustre or GlusterFS on top of that? Am I even making sense?
• A kind of union filesystem with local caching, on top of Tahoe-LAFS. Say we take unionfs-fuse, and add local caching: if the requested file is already in cache, performance is near native; if not, we still get the advantages of Tahoe. I'm not sure how caching works with WebDAV, but once Tahoe gets a WebDAV frontend it might be a simple matter of adding a Squid cache between that and davfs.
• I even thought of building a filesystem on top of the Bittorrent protocol; redundancy would be obtained by ensuring that there are at least N distributed copies of a file among the peers. I gave up even before reaching the details phase, though, but maybe a variant of the idea could be workable.

vi was written for a world that doesn't exist anymore

I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. 9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think.

unless you decide to get a satellite phone and use it to connect to the Net at 2400 baud, in which case you'll realize that the Net is not usable at 2400 baud.