 | You are viewing ![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} np237's journalLog in Create a LiveJournal Account Learn more | Explore LJ: Life Entertainment Music Culture News & Politics Technology |
Maybe this will make the anti-Mono religious zealots shut their mouth.
Summary: there won’t be any patent claims filed against implementations of ECMA 334 (C# language specification) and ECMA 335 (CLI specification) from Microsoft. Now, the whole movie-plot scenario boycottnovell imagined collapses like a house of cards.
So many wrong statements were made in the insane troll about Mono, I feel that somehow I need to write some explanations about the current situation. So far the closest post to the reality was made by Tolimar but there are still some inaccuracies in it.
Q: Will Debian squeeze include Mono and Tomboy in the default install?
A: Short answer: yes. Long answer: in the current state of affairs, the GNOME installation media (which, remember, are far from being the only ones) will install tomboy if it is available. This might change depending on the feedback of the installer team and the CD team, but currently there isn’t a compelling reason to change this.
Q: Wasn’t it excluded from lenny because of problems with Mono?
A: There were two reasons to exclude Tomboy from lenny: the size, and the lack of support for some of our architectures. It has nothing to do with anything specific to Mono.
Q: What has changed since lenny that makes this situation evolve?
A: First, the size of Mono packages and of Tomboy itself was considerably reduced, thanks to awesome work from the Debian CLI team. Second, the availability of GNote means that architectures without Mono support can have a stripped down version (although this makes the situation far from ideal for these architectures, see next question).
Q: Why not ship GNote instead by default?
A: GNote was written for bad reasons, without even respecting the GPL copyright requirements. But more importantly, its maintenance model is going to make it only follow behind the Tomboy lead, as any code changes in Tomboy will need to be translated to C++. It also supports less languages and less features. Furthermore, it was introduced in Debian for political reasons, by a maintainer who doesn’t use it and isn’t involved in GNOME maintenance.
Q: Isn’t GNote much smaller?
A: Not really. C++ bindings are larger than CLI bindings, so the only real differences are the size of the Mono interpreter, and the size of translations. In the end, Tomboy with all its dependencies is only 10 MiB larger; that includes 3 times as many translations, and some important functionality.
Q: I disagree with this decision. What can I do to change this?
A: Get yourself seriously involved in either of Tomboy development, GNOME development, Debian GNOME packaging, or the Debian installer. Then, maybe your opinion will mean more than a troll on your pet free software news site.
Q: Tomboy should use Python / Vala / Java / Parrot / Lisp / (insert here your favorite pet language).
A: The developers prefer C#. While I’d personally appreciate if they could switch to a less controversial language like Vala (mainly because it would avoid trolls), I have no right to tell them to do so.
Q: Why is there a difference of treatment between Mono and Java?
A: Because there are about 30 applications using Gtk# in Debian, several of which are among the most popular in their category, while there is exactly 0 useful application using java-gnome.
Q: Is Mono free software?
A: Yes, it is 100% free software. Just as everything in Debian, it was scrutinized by FTP masters who found it is free. Most of the code is under the GPL, LGPL or MIT licenses.
Q: Are there patent issues with Mono?
A: Just like any other software, Mono certainly infringes on thousands of stupid software patents. However the Debian policy with patents is to put them in a trash and pee on them, unless they are actively enforced with reasonable chances to win. The situation of Mono is much more comfortable than (for example) that of MP3 decoders, for which patents are actively enforced; it’s just that they are so lame that we choose to ignore them.
Q: Are there specific dangers coming from Microsoft regarding Mono?
A: Microsoft has claimed to possess patents on some Mono compatibility layers with non-standard Microsoft APIs. Not only this is completely irrelevant to GNOME, since nothing in Gtk# and related stuff uses these compatibility layers, but if you know how things work in the patent world, you already understand this is merely FUD. Microsoft has nothing, but claims to have something in order to scare consumers away from Mono. Actually, not enforcing the patents, while knowing they are violated, would make their case very weak in a patent suit. What their behavior shows is that they are very afraid of Mono. It is stealing customers from their best and most advanced product, their lead development framework. There is absolutely zero chance that they are sustaining Mono from behind, since its very existence is going to make them lose a large amount of money.
Q: Would it make Debian uncomfortable if these patents were starting to be enforced?
A: In the very unlikely situation where Mono would be found to infringe on valid Microsoft patents, we would simply have to remove it from the Debian archive. We are not short from alternatives, and it wouldn’t be long before we had drop-in replacements in Vala or Python.
Q: What is the agenda of Roy Schestowitz, Sam Varghese, Robert Millan and their friends?
A: What they are doing is giving credit to the Microsoft FUD in order to also scare consumers and developers away from Mono. They want to scare them away to other free software environments, but what they achieve is scaring people away to buy Microsoft products instead. It is tempting to conclude, because of the result, that they are employed by Microsoft underhand, but applying Hanlon’s razor, I think they are just incredibly incompetent, to the point where they are dangerous. These people are toxic to the community, and we really need them to shut up. If they ever reach their goal and destroy a great piece of free software like Mono, they will go on and find something else to destroy. Remember, their goal is to SDD: scare, disrupt and destroy. You cannot build anything useful or interesting with such goals.
Q: But Richard Stallman says they are right!
A: RMS is also the guy who wants us to ship non-free documentation. I don’t think RMS has enough connection left to the real world for his opinion to be considered relevant.
Ever noticed how the dependency fields of development library packages are tedious to maintain? They are often:
In order to improve the situation a bit, I have written a debhelper script to handle development libraries and generate automatically these dependencies in a ${dev:Depends} variable, using the pkg-config information. I have requested its inclusion in debhelper, but in the meantime, I’d appreciate if people could test it against various library packages so that its potential bugs can be fixed; this could surely convince Joey to accept it faster.
Here you go: dh_devlibs.
The next step in this direction is to do some automatic validation of build-dependencies. The first approach I thought of requires some improvements in pkg-config, but given how this package is maintained, I’m afraid it will require some time. There are other possibilities involving diversions, so it is still possible that something good comes out of this.
If forums did not exist, happily we would have blog comments for entertainment.
From Jo Shields’ insightful explanations:
“Mono is a cancer that attaches itself in an intellectual property sense to everything it touches.”
“Mono serves no useful purpose to anyone other than Microsoft.”
“Fuck mono, parrot will probably end up replacing that piece of shit.”
From LHB’s link to the previous post:
“It shouldn't be a surprise to find out this crappy little blog was de Icaza's.”
“Mono is dead”
From Robert Millan’s uninformed accusations:
“It is sick and a slap in the face to the good people in Debian to tolerate such a psycho.”
“When also Miguel de lcaza stops getting checks from M$, even he will stop pushing Mono and get a life.”
“How much did Microsoft pay Joss for this? We know de Icaza is getting paid “bonuses” fro his work, so what was Joss’ paycheck?”
“I think Mono is an abomination”
“If this happen i will switch distro to slackware.”
From my previous blog entry:
“Hey whats your salery for this -Hey we all love Mono- Posting? Did Novell or Microsoft paid you?”
“Have you noticed that you are arguing from the same position as Microsoft is with Internet Explorer ?”
“An email client is not part of a Desktop.”
“These are *APPLICATIONS* and forcing me to install them is, to my mind, antithetical to the open source ideal.”
“The majority of the Debian userbase has no use for patent-encumbered microsoft-wannabe software.”
“Will somebody kick Joss a** already? Thank you.”
“ notice that you didn't contradict me, so we are in agreement that Tomboy, Fspot, and GnomeDo aren't cool.”
“I sincerely hope you drop any kind of linux and/or debian development ASAP.”
“honestly all those mono files horribly ending with .exe on Linux sucks”
“Evolution serves no useful purpose in today's world”
“As an aside, I still write programs for Messy Doss.”
“Hey, before you start packaging up software where you have no idea whatsoever why people have an issue with it […]”
“That last bit about you watching anime instead of working on that project because some journalist hurt your feelings is a concern for me. I wasn't aware children had leadership roles in Debian's future...”
“You don't know nor belong the free software movement. You should go and ask for a job at Microsoft! (lame botas de Microsoft!)”
From OSnews’ surprisingly neutral explanations about what is happening in Debian:
“And gnuplot is neither GNU nor OpenSource.”
“GNote is not a Tomboy ripoff.”
“I swear people like you are just sitting in a call center in india getting paid by microsoft to post lame anti-anti-mono crap. ”
“Or are you just copying and pasting rebuttals from a spreadsheet put together by MS's marketing/psychology department?”
“You can't just remove mono and the associated apps as this will cause problems when doing updates due to a meta package being missing.”
And of course, Boycott Novell’s troll of the day is a recommended reading for anyone wanting to get a share of fun.
And there are now some in this very blog entry! We’re going into a loop!
“After this, I do really hope they kick you out of Debian.”
“have you guys kicked out Kurt Roeckx for crippling OpenSSL? I heard he got a nice job offer from the NSA over that.”
UPDATE: we made Slashdot!
“It's just like Wine and DOSEmu: a gateway to viruses that originated on Microsoft platforms.”
“I see Microsoft having a field day with this...”
“But it's not just Microsoft's products that bloat Debian.”
“Why are this guys, which I believe have their best of interests, trying to shove up our asses a lame excuse of a programming language that basically doesn't bring anything new but license agreements, EULAs, patents to a perfectly, usable environment?”
“I can code a Tomboy like app in Python in three days...”
“Because nobody fucking wants Mono on their system!”
“Get in bed with Microsoft and you have to be careful that you don't end up with a knife in your back and act accordingly.”
“He's just a pushy immature unmannered jerk who managed to slip something in early in the development cycle.”
Let me add to this a disclaimer: if the people who want me out of the Project – for re-adding a dependency into a metapackage – volunteer to contribute to Debian, and manage during 6 months to contribute together the same amount of work I am contributing currently in GNOME packaging, I’ll happily leave the project.
EDIT: added new quotes, last addition: 16 june, 08:13 UTC.
Unlike what you are suggesting, I’m not the one who decides what goes into the default Squeeze installation. There is most likely going to be a small discussion with the debian-installer team, like the one we went through for Lenny and which turned out very constructive. Saying that I “decided that Mono must be part of the default desktop install” is so freakingly untrue that it leaves me somehow speechless.
Of course, the real discussion around including Mono by default is not about Tomboy. If they don’t want of it, the debian-installer team just has to include GNote in the gnome-desktop task to get it by default instead of Tomboy; note that this is possible since I added an or dependency, precisely as you suggested. No, the applications that are going to make a difference are things like GNOME Do and F-Spot. If we want to include these cool applications that have no real alternative (even proprietary), this will include the Mono stack as well. And there are no stripped down C++ versions of those.
Let’s get back to Tomboy. The reason why it is now a dependency of the gnome metapackage is the same reason why upstream GNOME included it in their default desktop release. It is not to bow before Microsoft or Novell, as you and your paranoid friends seem to think; it is because professional-grade note-taking is a vital application to an important share of our users.
Everyone working in a corporate environment, with many projects to manage with several clients, meetings every other day, and random thoughts to write somewhere, needs to manage notes. Some use random pieces of paper scattered on their desk. Some use notebooks. Some use Emacs. Some write formal proceedings for each of their actions. It turns out that none of these methods are comparable to Tomboy in terms of efficiency.
As such, I’m wondering whether you are actually using the software you packaged. Your writings suggest that you don’t need an application such as GNote. Which means that, consistently with your other actions in the project, you only packaged it to push your pointless political agenda, not to do something useful for our users. That also explains why you proved to be so clueless while packaging it.
And I am sorry to inform you that the Project does not give a shit of your political agenda. The reason why Tomboy was not included in the default Lenny installation is not because of stupid software patents. If we gave a shit of inapplicable software patents, we wouldn’t be shipping MP3 decoding software by default. If we gave a shit, we wouldn’t ship Mono in main, regardless of what is in the default installation. We don’t give a shit of where is Mono coming from, as long as it is free software. As Jo explained, we don’t even give a shit of what Mono is, it just happens to be a dependency for Tomboy. No, the reason why Tomboy was not here by default is simply because its dependency stack was too big for some installation media. Now, the Debian Mono team managed to reduce a bit the installation size, and the availability of GNote as an alternative is giving a last-resort choice that will be much smaller.
Oh, and just a side note: I was going to work on the remaining bits of GNOME 2.26 in Debian this week-end. You just convinced me to watch anime on my home cinema instead. With new seasons of Higurashi and Haruhi Suzumiya coming around, this is perfect timing.
Here are a few hints if you want your reports to be treated more promptly.
If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the “I upgraded foo, then bar broke” category.
Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug.
“This is related to printing in a GNOME program, so I report this against libgnomeprint.”
Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you’re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages).
“After upgrading libfoo, bar starts crashing, so I’m reporting it against libfoo.”
Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program’s maintainer will reassign if needed, and will hit the library’s maintainer with a hammer if needed.
“The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don’t know what libfrob is about, but I have some problems that look frobniz-related.”
Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don’t forget to explain what bug lead you on investigating.
“I’m trying to do that with your package and it looks extremely complicated/doesn’t work as expected/fails miserably. Your package is clearly broken!”
If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve.
In these situations, always include in your report what you are trying to do and why you want to do it.
Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output.
For the specific cases that require strace for debugging, these traces are welcome but if you’re not sure, don’t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is gdb.
There is a good reason why some packages include bug control files and scripts. Use a reporting tool that takes them into account. Unless you are requesting an enhancement, always use reportbug. Please avoid reportbug-ng since it only provides parts of the required information.
Seen on Slashdot: a large discussion forum site hacked through its backups.
I had seen this coming. And it’s just the beginning, you can expect this to be a major attack vector in the next years. Until people understand it’s not possible to secure data without securing the network.
Due to the repeated tendency of our friends of the MPAA beloved government to create laws that turn computer and Internet users into criminals, I’m considering to shutdown any kind of non-encrypted communications that I initiate from France.
Therefore, I’m looking for cheap dedicated hosting in an Internet-friendly country, in a way similar to what we have here with OVH or Iliad. My requirements are:
Suggestions are welcome. I’m currently considering hosting solutions in the Netherlands, but I’d appreciate some advice.
Up to lenny, our GNOME desktop lacks a bit branding. We used to have the splash screen but it doesn’t show up anymore, so that only leaves the background. It has several times been requested to put a bit of branding in the menu, as most distributions do, and this has been in my mind for a while.
I have uploaded a first attempt to unstable. Since I didn’t want the branding to be too intrusive, I used the “swirl foot“ logo of the pkg-gnome page. So far, the reactions haven’t been very enthusiastic, that’s why I’m writing here. Any change generates an amount of grumpiness, and it’s hard to distinguish what’s caused by the mere fact that something broke people’s habits, and what’s really changed for the bad.
This is why I have set up a little poll where users are welcome to voice their opinion. What should we set as the main menu icon?
The good old GNOME foot icon
The Debian swirl icon
The “swirl foot“ iconI also welcome proposals for some other icon that would be better for this place. Actually, that would be my favorite option if I had something to propose, as I’m not enthusiastic about any of the available ones. Time to be creative!
So now is the time to express your preferences. If you have comments, please put them in the blog entry, not in the poll page.
EDIT : I found that some opacity settings in the SVG I used for the “swirl foot” icon were completely wrong. Here is a new version, taking account what has been proposed in the comments:
The gnome-power-manager developers like clean code. Actually, more than clean code: code that will not generate a single nitpicking warning. The package builds with the following C compiler flags:
-Werror -Wcast-align -Wno-uninitialized -Wall -Wformat-security
On the SPARC architecture, -Wcast-align really starts to mean something. Unlike most other architectures, any alignment error on here will leave you gather your teeth spread on the floor after you’ve been hit by a SIGBUS. It tries to catch at build time alignment errors resulting from a cast between pointers to different types.
Together with -Werror, it triggered a first FTBFS bug. The error occured on the following code:
if (XRRGetOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight,
0, 4, False, False, None,
&actual_type, &actual_format,
&nitems, &bytes_after, &prop) != Success) {
egg_debug ("failed to get property");
return FALSE;
}
if (actual_type == XA_INTEGER && nitems == 1 && actual_format == 32) {
*cur = *((int *) prop);
ret = TRUE;
}
XFree (prop);
return ret;
More precisely, the error occurs when casting prop (which is an array of pointers) into an int *.
The compiler is clearly right. The alignment requirements are different for a pointer and an integer; therefore, casting a pointer to a pointer into a pointer to an integer will always work, but dereferencing the pointer later will possibly cause a crash. Turning this expression into a memcpy leads to code that should always work.
Lesson learned: do not design APIs where an array of pointers can actually store integers. Have you ever heard of opaque structures?
This was not enough and a second FTBFS bug showed up. Here, the error happens in the following code:
static inline GstBuffer *
gst_buffer_ref (GstBuffer * buf)
{
/* not using a macro here because gcc-4.1 will complain
* if the return value isn't used (because of the cast) */
return (GstBuffer *) gst_mini_object_ref (GST_MINI_OBJECT_CAST (buf));
}
GstBuffer is a structure which contains a GstMiniObject at the beginning. Therefore, you conduct operations on the GstMiniObject through a mere cast. The first cast (GstBuffer → GstMiniObject) is fine, but in the second cast (GstMiniObject → GstBuffer), the compiler suspects a problem, since the alignment requirements on GstBuffer are stronger than those on GstMiniObject.
The compiler is wrong because it didn’t read the API documentation; otherwise, it would have known that gst_mini_object_ref can only return NULL or its argument, which means there can’t be any loss of alignment. Since there are no function attributes to express such complex things, we are still forced to rely on the developer having correctly read the documentation. Way to go, compiler.
Lesson learned: there are good reasons why some warnings are not part of -Wall. Especially, it is dubious to use them with -Werror. Does anyone know whether it is possible to apply -Werror only to some of the warnings and not to all of them? It would sound like a useful improvement.
For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I’ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless.
Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol – I won’t explain why here, you will find tons of better explanations on the intarweb.
The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable – that’s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code.
When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let’s bring the session preferences:
The UI of this dialog hasn’t changed since 2.22. However, I do not resist the urge to show you the code behind the “Remember Currently Running Applications” button:
static void
on_save_session_clicked (GtkWidget *widget,
GsmPropertiesDialog *dialog)
{
g_debug ("Session saving is not implemented yet!");
}If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what’s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager!
The surprises don’t stop here. I also noticed that logout was much faster – instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it’s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn’t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn’t need them to register for saving the session, it also saves the time to ask them to close cleanly.
The result is that you will see a lot of such dialogs:
It’s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let’s be realistic, it’s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.)
Wait… aren’t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:
It’s good to see such improvements on the session manager coming, and I’m really thankful to the gnome-session developers to work on it. What I wonder is:
This is a very good example of a lack of “big picture” thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user’s point of view – the kind of regressions that make people fly away.
If there’s one thing that I’ve learned from working in IT, it’s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.
during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:
Pretty please. What you mean is “Go fuck yourself”, but the way you are saying it is no more friendly and actually much more rude. If you meant “Go fuck yourself”, why not just say it?
As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is “I hope you were on crack while writing that” ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.
There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system.
Let’s put aside the fact such tools are useful on Windows and MacOS which don’t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can’t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We’re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth.
Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:
Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers.
However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules.
As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier – and they are really willing to fix it – and several more general issues, setuptools developers forgot to look at the existing solutions:
Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.
While a few developers have the chance to be paid for their job on Debian, most of us are doing it on our spare time, for fun. Yes, we are making the best operating system out there, for fun. Yet a large number of developers are taking this project way too seriously. To say it in other words, they have a carrot up the ass. I happen to prefer the French expression though, since it conveys better the rigidity of their attitude: they have a broomstick up the ass.
Recently, when I launched the idea of the Bug Sprint, someone wrote to me to propose, instead of rewarding people with cookies, to send them money. This is the best example of broomstick behavior: taking the fun out of people by bringing back rampantly the very idea that almost split the project in two the last time it was introduced. The very same person, when faced with a sarcastic email sent to an announcement mailing list, immediately rushed in to send a ban request to list masters (a totally useless one, since I don’t have the habit to make the same joke twice). That person happens to be the project leader. So it seems the only thing the DPL has to do, at a time when we’d rather need people to fix RC bugs, is to protect the project from seditious members who don’t share their love for broomsticks.
When someone makes a bad-taste joke, you are not forced to laugh. But you are not forced to impose your rigid and moralist views either. And on top of that, throwing random accusations of sexism without any kind of justification does not improve the mood. This is even very close to defamation, but since I don’t have a broomstick in the ass myself, I prefer to just laugh at them with the help of some fellow developers.
I will go on shocking these people. And they won’t like it more than in the past. Every time one of them climbs on her high horse to take a pathetic and patronizing stance while totally missing the point, it will bring a bit of fun.
Edited to add (22 dec) : when I said “I will go on shocking these people”, I didn’t mean “I will purposely shock these people”. They shouldn’t expect to obtain enough of my attention for that to happen.
Bonus #1: as for the promised statistics, we are, at the time of writing, at 493 599 unique IPs who clicked on the trap. Quite a good investment for someone who’d want to make money from smelly geeks.
Bonus #2: here is a sexist picture.
Hey Romain,
you’d be impressed by the number of upstreams whose knowledge of security measures is similarly close to the absolute zero. Since “bad guys” are always digging through commits for suspicious things, hiding the relevant commits is the best thing you can do to help them. Given things like this exist, It’s likely that they have even automated tools to do this search for them. This way, distributors and security engineers have to do the same job, hoping to never miss a change that was actually a security fix.
Unfortunately, two small scale projects that we happen to use have exactly the policy Romain described regarding security updates. I’m amazed by the fantastic job the distributions’ security teams manage to achieve in these conditions.
The Debian bug sprint has started!
27 players registered in the hope to win cookies. The list of players and their assignments can be viewed at the usual place.
Good luck to everyone.
NB: for those who wonder, the assigned bugs were chosen as the 27 oldest RC bugs without a patch and randomized with shuf.
