Marc 'HE' Brockschmidt: Why THEY don't want me to collect all left socks
Yoe seems to believe I see a cabal in Debian. Let me assure you: I don't - and if there would be a cabal, I would be part of it. I've seen most of Debian, played around with NM, the release team, have seen how our buildd network works (or, in the specific case of today: mostly works) and have close contact to people in all other core teams of the project. I still haven't seen a sign of a Cabal.I believe that there are "clusters" of people who work better with each other, simply because they have known each other for years and developed trust, but that's nothing I would actually mark as problem. I do the same. Many of our core people have too much work to do, mostly because getting a job well done is usually reason to give you more tasks until your performance becomes abysmal. That doesn't mean that they are bad people or do bad things intentionally, but often, they don't allow people to help them - the usual reasoning is "new people need training, training needs time, time is what I don't have => no new people". Obviously, that argumentation is flawed in the long run.
Anyway, on to the more technical details:
- The real reason for not adding new architectures is that not one of the people able to do so cares enough to do it. That doesn't sound as nice as "I don't really know why we don't do it", does it?
- I haven't asked the security team to support backports, and I won't. volatile isn't under the supervision of the security team and works just fine.
- Most porting machines aren't "down", they are "locked down". See the list of Debian machines (which is, BTW, seriously out of date). Hardware failure is something completely different (though we might want to think about using Debian funds to replace broken machines, if needed), but restricting access is a sign of an overloaded team of system administrators.
- Dictating how a team should be changed is usually not a good way to do things - but there isn't another. A few of our core teams have failed to solve their problems on their own. Debian's job now isn't to stand by, watching and saying "He, that's bad. Maybe they'll fix the team in the next decade". Also, there are people experienced with the tasks of these core teams who are not part of them - you might want to use their experiences.
- With my release team and unofficial buildd network hat on I will tell you that adding one buildd maintainer for those architectures that only have one at the moment would improve the situation a lot. Please don't assume that I only talk about stuff I have no idea of. Sometimes I actually know about things!
- I don't think that we need to change our position regarding the GFDL, but I do believe that we should work on our relation to the FSF. Debian is the biggest free-as-in-free-as-in-free-speech distribution on the market, so the FSF should actually be interested in working together with us. Still, that doesn't happen, so we should perhaps start by having a discussion what the problems of each of these organisations is in the eyes of the other.
And, FWIW: I do hate conspiracy theories too. They come to life because people usually want to see the "bigger picture" - even if there is none and all of the weirdness in their environment can be explained by chance, human error and unknown social problems. And as I said - I don't believe there is a group of people making decisions that seem bad for Debian. I just believe a lot of people try to do their best for Debian - but they fail on a regular basis.
I have a theory. There are two kinds of people in the world: those
who see conspiracies everywhere, and those who don't. Personally, I'm
part of the latter group; and it annoys me endlessly when people in
the former group use conspiracy theories to explain what they don't
understand—much in the same way that I don't really understand
people who use religion to explain what they don't understand.
An example of what I mean:
Marc 'HE' Brockschmidt
The talks I proposed for
A short program I wrote has
Once again there is a discussion whether uClibc based systems should get their own architecture, or whether it would be more like Ubuntu -- they, too, have a different C library (with stack-protector support; this simplifies the gcc bootstrap sequence a bit).
Thinking further, why not have generic support for keeping different configurations for various derived distributions in a single source tree, so the same source package could be used on Debian, Ubuntu, emdebian and all the others which all build different binaries?
The gcc package does this, to some extent, but it looks at the build system to find out which configuration to use -- a standard mechanism, for example a DEB_BUILD_VARIANT environment variable would be nice.
This week-end, i decided to copy a collection of CD-R back to my hard drive, to make new copies. Everyone knows, that a CD-R only live for 10 years. After this date, the data on it are more difficult to read. So it's the time to know what brand of CD-R has the greatest lifetime.
I begin to write CD-R sometimes around 1997. From this date, i keep using the same scheme to do this task: use high-end CD recorder (Plextor), good quality disc, always write at the minimum speed (ranging from 4x to 16x for the latest CD-R -- because sometime you cannot go under a defined speed), keep data on a separate partition to prevent buffer underun (10 years ago this was mandatory). The way i do this has almost not changed, expect maybe for the buffer underun, which doesn't happen anymore on modern hardware.
They have been in the same place at the same date. They have always been kept out of direct sunlight exposure, in 18-25 C environment (i.e. near my computer). I didn't often use them. None have "scratches" on theirs surface. I have written the name of the CD with a permanent marker (Stabilo).
For reading back the data I use a DVD-Recorder (Plextor PX-716UF) that can lower its speed if there are too many errors during the read.
The result is somehow what you should think:
Original post can be found
If, like me, you’ve been following development of Joey’s nifty new
Note: red underlined links are clickable