Dear Daniel,
It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious.
Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.
NOT.
Also see #363516.
Genius.
Now regenerating every single SSH key, SSL certificate and whatever else I can identify that’s been produced by one of the Valgrind-clean openssl. Also expiring and changing every single password I’ve ever typed in a vulnerable SSH session (be it at login or in the session).
Updating the packages on the machines was fun already.
Worst Debian day ever since the 2003 compromise. And that was a BAD one.
I guess we need a new openssl maintainer, we obviously cannot trust the current one(s).
The SANE project is working on improving SANE, extending the API and ABI in a backward-compatible manner and bumping the version from 1.0.x to 1.1.x to celebrate that.
The timetable has been posted, and calls for a release of SANE 1.1.0 on July, 30th.
This will be too late for the Lenny freeze by a few weeks, which means Lenny is set to be released with SANE 1.0.19.
SANE 1.0.19 is a good, solid release, which is good news. I’m not sure 1.1.0 will be as solid as 1.0.19 is, so I won’t try to rush 1.1.0 into Lenny at the last minute.
Until the Lenny freeze, I’m going to augment the current SANE 1.0.19 with code from the SANE CVS, concentrating mostly on bugfixes and self-contained new hardware support and features.
Hence, if there is something in the SANE CVS that you would like to see in Lenny: test it, then tell me about it. You have until the end of June to do so.
Currently on my TODO list:
Currently in experimental, sane-backends 1.0.19-7:
Comments and feedback welcome.
Trying to upgrade a craptastic server that’s proving problematic under 2.6.18 to the Etch 1/2 kernel, not only is the machine extremely sloooooow to boot, but it turns out that it’s partly due to bnx2 now requesting a firmware file, whereas the firmware is built-in in the 2.6.18 Etch kernel.
Of course, the machine has no working network access due to this, and, to make things even worse, the firmware file is nowhere to be found. No firmware-nonfree in etch-proposed-updates and it’s not in the firmware-nonfree package in unstable.
You’d better hide your kittens, for Etch 1/2 makes me want to kill a large number of kittens.
Put down the crack pipe. Really. Wow.
Dear Jaldhar,
I wrote the post you’re referring to knowing that only one person had been stupid enough to title his post “Is Debian dying?”, so before you go on writing I’m insulting a group of people (at least I’m reading your post this way), please do your research.
Lucas’ post is about the worst PR we can imagine. There’s nothing more stupid to do than what he did. That’s the PR equivalent of committing suicide, mostly. It’s seriously hindering the work some of us are doing, publicizing Debian, going to trade shows, etc. It’s not only stupid, it’s hurting people who do this work.
What’s worse, the post comes with comments from random nobodies, who have nothing to do with Debian, don’t have the first clue about how the Project works internally, yet they can tell that Debian is dying and grinding to a halt. Not to mention it’s been publicized yet again by some “journalist”.
I’ve known Lucas for a long time now. I know where I stand. And I maintain my previous post in full, like it or not.
Kthxbye.
NagVis is a visualization add-on for Nagios, offering a somewhat better summary view compared to Nagios.
As we are faced with abysmal performance on a “large” setup here, I conducted a quick analysis.
Given what I found pretty early on during this analysis, I’ve given up trying to salvage NagVis. We’re looking at alternatives and considering writing our own tool to cover our needs.
New developer accounts have been created moments ago, “finally”.
Congratulations to all new DDs, with a special note for Aurélien GÉRÔME (ag) and Cyril BRULEBOIS (KiBi).
All of this made possible by Sam, our best DPL to date.
Also, don’t listen to the fucktards going around telling “OMG DEBIAN IS DYING!!11!1!”. They’re just that, fucktards.
I’ve just released pommed v1.17, which is a pure maintenance release to accomodate changes in Linux 2.6.25.
The path for the led interface exposed by applesmc for the keyboard backlight has changed, so if you lost the keyboard backlight when switching to 2.6.25 or a pre-release, now you know why ;)
No new features this time around :-)
There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already.
This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
This matter is undecided as of yet, but extensions to SANE1 are planned, being discussed or in the making for some of them.
During the discussions, a fork of SANE has been announced, dubbed “SANE Evolution”. No idea where that is going, but it’ll probably end up being merged back into SANE in the end.
So, in a nutshell, things are moving again (albeit slowly), which is good news considering the project was mostly asleep in recent times.
To celebrate that (and because I now have total control over my free time again), I’ve been working on the network side of SANE again. In 2 weeks (3 week-ends, roughly):
Turning saned into a regular daemon made it possible to clean up a good chunk of the code duplication that was introduced by my previous AF-indep/IPv6 work; the startup code is readable again.
The Avahi support is (I hope) a very nice thing as, when enabled, configuration of the net backend on the client side is no longer needed. This is an experimental feature still and as such it’s disabled by default at build time. I have a couple of ideas to improve that feature, but this means saned will have to evolve even more so it’ll take some time.
The WireShark dissector is a tool for working on enhancing the network protocol. It proved useful already with the information leak I spotted with it (though it’s minor). It’ll be a long work to extend the network protocol and implement that into saned and the net backend in a backward-compatible manner.