What would you like to see changed in Debian?
Posted by Steve on Tue 8 Nov 2005 at 14:23
As Debian users what do you think you'd like to see changed in the Debian's future releases? Are there any small changes you'd particularly like to see made?
I'm thinking in terms of both the available packages, and new installations. Now don't go crazy suggesting unrealistic things such as:
- Hardware support for all new devices
- This is mostly a kernel issue anyway.
- Automatic hardware detection
- This is coming along nicely and will continue to improve.
It is the little things I'm curious about. Are there simple changes which would make your lives easier?
- I know I'd be pleased if there were fewer "essential" packages, so I could minimise new installations.
- Although I've fairly guilty of writing things in Perl which should probably be shell scripts.
But what would you like to see changed? And would you be prepared to pay people to work on them? (I find the AJ market a fascinating idea..)
For example, bind9 has an annoying bug when not used with a forwarder. A four second delay is present if the server is on an ipv4 only network. Judging by past bug reports, this bug will be closed without a fix. RHEL on the other hand tends to fix these kind of things (in fact they did) AS WELL as providing security updates, which is what Debian tends to do.
Debian needs a time-based release schedule to enable businesses to plan. The current "Use Debian" rule falls flat on its face as soon as you mix Stable and testing/whatever repos. A time-based release schedule would help to reduce this. "Test on testing, release when the platform is declared stable".
Apt updates need to be signed, but this is being addressed.
Secure by default would be good too. The default permissions on /root/ are ridiculous, as are /home/* (yes this can be configured, but only for adduser not useradd).
Hostnames shouldn't be intertwined with config files. $(hostname) should either change /etc/hostname and /etc/motd, etc, or these files should be generated at boot.
Web apps should be in /var/www/ to allow proper lockdown, not hidden away in /usr/share. php safe mode should be default.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Sure some bugs are always going to be present, and it would be nice to see them fixed. However the Debian guidelines don't really allow that even for point-releases unless there are severe breakages, or security issues.
I think that time based releases would be a nice thing to have, but I couldn't say how likely that is to happen. I know that nobody wants to wait so long for releases as we did for Sarge, but hopefully this can be addressed even if time-based releases aren't implemented.
As for permissions on install. Yes some changes can be made, but it is worth remembering that different people have different ideas of how things should be setup - and that a small amount of post-install configuration is to be expected in any installation, especially for servers. The Securing Debian manual has excellent advice.
Your hostname suggestion is unlikely to ever be implemented since it would involve changing lots of packages, and that isn't the place of Debian to do - it would just result in software not working as expected in mixed Debian/Redhat environments.
PHP safe mode is a whole can of worms I'm not sure many people want to get into .. it isn't a panacea, and whilst useful it is unwise to trust it significantly.
As part of the LSB work I imagine /var/www will eventually migrate to /srv/ (I think that was the location?) in most Linux distributions ..
Steve
--
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
"The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done."
versus the current Debian-way of /var/www/
[ Parent | Reply to this comment ]
[ Send Message | View Serge's Scratchpad | View Weblogs ]
[ Parent | Reply to this comment ]
By the way, open_basedir should be fixed by default too (and then yes, restricting to only one dir is the way to go, for openbasedir also).
[ Parent | Reply to this comment ]
Thus, what I would really like is a little more uniformity about how packages are built. Each individual package seems to be easy to build, but with five different packages you'll get five different methods, and you mostly have to search the net to find them. I want to see a concerted effort to make sure the README.Debians actually get you from source to .deb without having to resort to Google.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
That would be very nice to see, I agree.
I remember the discussion starting a few months ago when somebody asked for some consolidation in unpacking source - many packages (such as Apache) ship with tarballs, so actually just extracting the source is tricky.
There is no standard rule for doing the unpacking. It would be nice to see something like:
make -f debian/rules unpack
But failing that a README.Source, or README.Debian describing how to work with non-standard packages would be fantastic.
Steve
--
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
You are off the edge of the map, mate. Here there be monsters!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I actually considered packaging this myself, until I started working with crm114 and discovered it worked beautifully upon my server.
Is there a compelling advantage to using dspam?
Just glancing over the most recent version I see that it has changed a lot since I looked at it last and the setup looks .. intricate. (With the Exim4 integration and the requirement for a database, unless I misread things.)
Steve
--
[ Parent | Reply to this comment ]
And for CRM114 users, DSpam has Markovian Discrimination (the same algorithm from CRM114), even CSS is from CRM114 ... CRM Sparse Spectra.
From my point of view, there is some advantages over CRM144, LDAP and Clam A/V integration and running as daemon. About acurracy both of them are excelent tools, in my own home made test. and after 4 weeks of using both, i got 3 errors in aprox. 5000 messages.
[ Parent | Reply to this comment ]
2) python policy needs to get fixed - it's insane to have to do parallel installs of software if you really just want the latest python.
3) the jabber packaging needs to suck less. It's old and the gateways are all busted and the configuration for the whole mess is a pain.
4) Debian should allow installation of a gentoo-like dependency-based init.d system - it's all about choice, right?
5) The debian list/qmail hypocrisy should be resolved.
Another random idea I had was that a way to solve the chronic shortfall of cpu time for packagebuilding would be to allow debian users to contribute spare cycles foo@home style - it's as worth a cause to me as things like GIMPS or whatever.
[ Parent | Reply to this comment ]
Could you explain what you mean by "the Debian list/qmail hypocrisy" ?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I want for the next release:
- Easy way to install Xen.
- The Volatille project as official part of the stable release.
- DHCP test in installer go away.
- No more 2.4 kernels.
- DO NOT split the packages as main and contrib, and keeping main small, like ubuntu, with that universe, multi-verse shit. What makes Debian f*cking great and unique is that ALL packages need to follow the quality policy (more then 15000 today).
- x86_64 and PPC64 official archs.
- Does any one reading this use motorola 68k or hppa? What is the relevance of this archs in december 2006?
- Why not mplayer? We got now ALL libs but libdvdcss, why not player?
- Kill gtk1 aplications and libs. libwxgtk is now using gtk2 on unstable.
- No openoffice 1.
- Some project or task force to do clean up and remove packages with dead upstream, or really outdated and based on debpopcon, drop this packages.
- Lastest Firebird, mysql and postgres.
- I really don't know if the best place of web aplications should be /usr/share, it works good for now, but this really should be studied.
- I really dont want one more directory in my /. I always remove /mnt, /opt, /srv looks useless, /usr/srv for web applications looks fine, this includes make a better policy for web applications.
- Really try to keep up to date with linux kernel releases, for one reason: drivers!
Man there is a lot more!
[ Parent | Reply to this comment ]
He was looking for OSes supporting this architecture and he only found Debian, NetBSD and OpenBSD.
This means that Debian seems to be the only chance to install Linux in this type of machines.
[ Parent | Reply to this comment ]
There seems to be a lot of these machines showing up in the second-hand market, and HPUX 11i minimum technical install leaves a lot to be desired. These workstations make dandy fileservers and webservers and such and even as a desktop box, the HP graphics cards have great capabilities if they can be accessed. ;-)
Other packages/features that I'd like to see integrated:
- webmin
- or CipUX
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
The hard part here is finding qualified people with the time to write it.
I'd love to see more documentation, especially on performing common jobs - perhaps taking some of the articles from here and making them longer?
But all is not too bad. The various Debian manuals (like the excellent "Securing Debian" manual) are doing a good job, and do get better over time.
Steve
--
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Too many people complaining, not enough helping. If the manual is outdated then please suggest changes.
As for apt you must realise that the reason that Ubuntu has it and we don't is because Sarge was frozen for a long time.
When Ubuntu goes into its longer-cycled stable freeze you'll have exactly the same issue. Suddenly they won't have the latest and greatest packages - I wonder how many people will jump ship when that happens?
SSP is available for Sarge from outside people (me) and can be used to compile anything you wish - you just need to fix all the breakages (like I've been doing). Having it available for Sarge would have been good and I wanted it, but I can see that it wasn't ready. Not by a long way.
Steve
--
[ Parent | Reply to this comment ]
I've had a lot of talks with various people about how best to achieve this, and I think it's going to take some momentum within the Debian Project for it to happen - I could work on my own unofficial Debian documentation project, but I don't have the resources to make it easy to contribute to, or to give it sufficient publicity that people would contribute to it. And by "people" I mostly mean Debian Developers, since they should know the best practice for doing things.
There's also been talk of the Debian wiki, but I don't think that's sufficient - really, we need a Documentation Manager who'll handle revising documentation for each Debian release, possibly by freezing documentation for an upcoming stable release along with its packages, and by maintaining a "testing" documentation branch (I don't think trying to document unstable is a worthwhile goal). That way issues such as translations can be handled more neatly. The DM also needs to identify a target audience and make sure that the documentation is appropriate for them, and excise information which is no longer useful.
[ Parent | Reply to this comment ]
* A novist friendly way for debian users to update/upgrade the Linux Kernel. Sure I'm a new users, but I find that trying to upgrade from the 2.4 to 2.6 very nerve racking.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
* More task-style packages (e.g., task-emacs, task-latex which installs the main packages plus a set of extras)
* Better support for rebuilding packages (like someone else said). I recently tried to hack some changes in evolution, and gave up after failing to compile the package (so many -dev packages needed!).
* Pre-built cross-compiler packages would be nice. The best thing would be if there was a "gcc-multiarch", although I know that this is a problem on the GCC-side.
Also, I for one like the fact that debian is available for many architectures. Personally, I use ARM packages for a Psion 5MXPro, but I would guess other people have similar "pet architectures".
// Simon
[ Parent | Reply to this comment ]
But that is a necessary prerequisite for building complex systems.
It only needs one command to install all the dependencies for rebuilding a source package.
So what is your specific pain?
[ Parent | Reply to this comment ]
Remove that from my list then!
// Simon
[ Parent | Reply to this comment ]
apt-get build-dep package-name
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
As suggested apt-get build-dep ... will do the job. This was briefly covered in the rebuilding packages from source article.
Steve
--
[ Parent | Reply to this comment ]
--------
Felipe Sateler
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
So i will prefer a RSBAC integration
[ Parent | Reply to this comment ]
Gentoo users did a good synthetic Access Control Comparison Table for those who don't know about the various ACL solutions on Linux:
http://gentoo-wiki.com/Access_Control_Comparison_Table
On a related note, I would love to see some (or many) of the intrusions prevensions techniques mentioned here:
http://cvs.openbsd.org/papers/ven05-deraadt/
[ Parent | Reply to this comment ]
--
If you're smart enough to ask this question, you're smart enough to RTFM and find out yourself.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
$ dpkg -S /etc/profile.d
lsb-core: /etc/profile.d
[ Parent | Reply to this comment ]
Like inetd, it is not really possible to change the cron system. You can install fcron or ancron but it's not possible to purge cron. Same for inetd !
So xinetd and fcron/ancron are not really alternatives.
[ Parent | Reply to this comment ]
Speaking of that, how about having the init scripts actually indicate if everything went okay. I know it goes against the standard unix tradition of silence == good, but it really should be done - especially since some init scripts will fail silently, and unless you check the process list, you'd never know. Right now some scripts do return "done", but that indicates success nor failure, which makes it essentially useless.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Grrr.
The bugfix came out a week later...
[ Parent | Reply to this comment ]
Not only would this benefit dialup users, but everyone - the security.debian.org server load would drop way off if their were deb files for security patches - save the monster downloads for when the release of debian increments! It means more downloading later, but overall would save huge amounts of time, and would actually allow people to get the security fixes faster!
This would actually be trivial to do - when a package is updated, the update contains only files that have changed - the files from the original full package wouldn't be touched (which is fine).
is anyone from d.o listening? steve?
[ Parent | Reply to this comment ]
You prob. only get a small fraction faster whith packages compiled optimized against a version of CPU. Where it can make a difference is in make a optimized kernel, which is already there.
But then again. You can automaticly rebuild all packages with your own set up. Look at apt-build for this.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I think this would be easier if all the init scripts had their ordering and/or dependency information in the header block as they do on Red Hat, but it would still be possible to do by storing the existing order when removing or deactivating a service and using a default value otherwise.
Still, there are plans to replace the System V-style ordered configuration with a NetBSD-style dependency configuration. http://alioth.debian.org/projects/initscripts-ng/
[ Parent | Reply to this comment ]
For the server-side of things, a firewall installed by default would be nice, even if its disabled, something to let the user not suffer through finding a decent firewall package. I think FireHOL is very easy to setup and use.
Some defaults I prefer also:
Exim -> Postfix UW-IMAP -> *ANYTHING* else (I actually use Cyrus)
[ Parent | Reply to this comment ]
But maybe it's because I did not install Firefox from Debian packages. I downloaded it directly from mozilla page. I have a feeling that Firefox in Sarge is not the latest version (atleast version number looks like that) and it's not an good idea to use old version because there has been some security holes in Firefox too.
[ Parent | Reply to this comment ]
Oh well it beats spending money on commercial software.
[ Parent | Reply to this comment ]
That's what backports.org is for! It's even "official" now. Get the latest version of certain packages for debian stable this way, and (paranoid alert) downgrade back or uninstall when a new major release comes out.
[ Parent | Reply to this comment ]
I say this as a small business owner who merely uses Debian in a business that has nothing to do with IT, and thinking of thousands of other small businesses who should use Debian, but will probably stray to Windows servers in the mistaken belief that familiarity is going to help.
2 years down the line I can now happily look after my servers from the command line, but that's after a lot of RTFM. When I started as an absolute noob, I couldn't even find the FM, let alone read it!
There is plenty of documentation, and it's extensive, but what often seems to be missing is the "Quick Start Guide", which lays out the bare essentials.
Maybe each instance of "apt-get install" should end by displaying a README, divided into:-
Must Should Could Would
sections?
And a default Debian install should replace MOTD with a link to this site?
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
There are Debian manuals out there, and every package contains something beneath /usr/share/doc - it is just a matter of people finding it.
Short of pointing this out at install time I'm not sure how you'd help people find it. I guess that most people who need to run a server are assumed to read the documentation on the website and have some experience.
Putting a link here would be utterly inappropriate for desktop users, or people who weren't running server farms. Far better to point people at the existing documentation at http://www.debian.org/doc.
Steve
--
[ Parent | Reply to this comment ]
Here's what I was thinking; we should have an installer based on a livecd. If we can have something like DSL (Damn Small Linux) around 50MB couldn't we remove all of the apps and the desk top stuff and use that as an installer. Imagine booting up in a livecd that recognizes all or most of your hardware and can configure your network interface and give you access to your network or the Net while allowing you to configure the underlying system to your hearts pleasure; imagine having access to multiple terms and tools; wouldn't this be the most ass kicking installer around. It could have curses, html or any gui one wanted; graphical partitioning (for those who need it). All that and we still would have more than 600MB of a cd left for packages if one needed them as such. If one can boot and install a mepis, (k)ubuntu, knoppix, etc cd and configure their system and install it why couldn't our installer have been based on that and still be under 50MB for a basic netinst and more for other configurations? The install cd could @ the same time offer forensic tools, antivirus and all sorts of things but that would be extra. I remember when installing storm linux I would play pacman while it installed (I did this mostly to impress the windows users standing around).
I would love to have the full system flexibility with an install disk. There are tons of lightweight GUI's which have run well on old 486 systems which could be used.
I don't see why we have to follow the same thing that has been done by everybody else when we don't have to. Nearly all of the OS installs I have done have been almost all linear and very limited (yes I can access consoles in linux while installing but more can be done so why not do it).
I would also like to see Debian's default security be tighter than all; it should have the ability, if one needed it, to recompile all the packages akin to a gentoo system.
Web apps should be under /var/www or maybe /var/local ( I keep my djbdns under there with its service dir in /var/lib/svscan/ ) but not new directory @ the / please.
Badiane
[ Parent | Reply to this comment ]
There is an effort to develop a graphical installer. The new Sarge installer is supposedly built around an engine/interface model where graphical interfaces are easy to attach to the installer engine while maintaining a text-based interface for the architechtures that require it. Personally, I have not seen a graphical front-end for the D-I yet, but it supposedly in the works.
As for a live-cd installer, I don't think that sort of thing would be appropriate for Debian due to the mentioned compatability issues. I agree that it's /neat/ to have access to a functional desktop while your system is being installed, but waiting 45 minutes for the install to complete isn't going to kill you.
[ Parent | Reply to this comment ]
The locus of my idea resides at the level of the user interaction. The same way a user chooses [linux, expert26] they can also choose for example [linuX, eXpert26] and the underlying structure would remain the same and all that would be used would be the presently available GNU/Debian tools such as the frame buffer if possible or any mechanism which would allow for tightvncserver to run for example. If the requirments to run vnc (X server might bee too heavy) are not present the installation would default to the curses install. The reason I mentioned vncserver is for the same reason D-I now allows the installtion to be performed remotely; but I would want it to happen from the beginning. That way I could walk into the server room pop in the cd and boot the machine which after contacting dhcp would be accessible remotely and log in and start my install. In the spirit of your mention, I believe that all of this should be based on the lowest graphical common denominator. I could even be thought of as a framework. A graphical interface is needed, whatever provides a graphical interface on any of these platform and has been available for eons from that distro should be used and it should allow for a remote connection; the window manager which runs in the least amount of memory space; the smalest practical browser that allows the greatest amount of flexibility in the smallest of space.
I have often ecountered obstacles while installing Debian which required me to go online and search for solutions to the problem. Now I could do the searches while I'm installing, actually I could even share the install with someone (imagine the didactic use in a classroom), I could leave it and pick it up later like screen.
In reference to your assumption about my motivations, it is not that I cannot "wait" to have a desktop (the last desktop I installed was on my laptop 2+ years ago), I just want a bigger and better toolbelt.
I just don't believe in making excuses for something not to happen when all of the elements required exist and have just not been arrange in a certain manner.
Once the elements were available it became possible to have a livecd; the only reason it hadn't been done after that point is because there needed to be someone who didn't see things the same way as the others and didn't accept what was considered to be "the normal way". That's what you find and is should be bred in the community.
The reason I mentioned DSL is to show that within 50MB of space so much functionality has been squeezed and if most of that functionality were to be redirected towards installation tools instead of a desktop, Debian might be perceived as less intimidating. Also you may have also noticed that many things start within a branch of the Debian world and if possible is ported to the others. At this stage it's more a matter of feasibility. If it can't be done on certain platforms then it's just not included and the intallation happens.
I'm not a programmer, I do some average system administration; the best thing I could contribute to such a project are ideas and I believe that if it could only be started it would be a great think for Debian.
I firmly believe that there is no need for installers (wheter graphical) in general to be so inflexible in terms of being able to manage the process and interacting with the machine.
I would love a constructive exchange of ideas since it would afford me the opportunity to clear my thoughts on the matter.
Openmind, Opensource; Closedmind, Closedsource.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
For example, on a server, a cdrom device should not be user mount-able. On a desktop, the cdrom device should be readable by the user (for cd-ripping) and mount-able. Same for your usb- camera/storage/cardreader.
On a server, ulimit should be set, quota enabled etc. On a desktop, everything should be pretty free, and users should be in most groups as audio and cdrom by default.
Plenty more examples to think of. But it would make Debian much nicer as a desktop distribution, without any comprises to the server quality.
Olivier Sessink
[ Parent | Reply to this comment ]
Otherwise, hmmn, I've always found Postfix easier than Exim and there is a lot more help for it out on the net. And the point some other folks have made about aiming for timed releases is quite persuasive.
[ Parent | Reply to this comment ]
I find that when I install things with tasksel (particularly the desktop option), I end up with lots of packages I don't want or need, which means more wasted bandwidth upgrading them all the time or else wasted time removing them. On the other hand, if I just go for the bare-bones install and do everything via apt, I find myself hitting up apt-get every time I use the computer for the next 3 months because something basic wasn't installed.
[ Parent | Reply to this comment ]
Smaller memory footprint.
Less manditory packages. Make UUID optional not manditory. Fsck currently will not even install without it, I just 'tune2fs -U clear' every boot. Other packages have similar problems.
Why (in all *nixes) are all executables lumped into one directory? Example: /usr/bin, Why not say /usr/X/bin and /usr/X/bin/screensavers etc etc, a little sub category goes pretty far when all one uses is 'ls'.
What ever happened to kerneld? Now I have to manually unload all those unused or un-needed kernel modules.
Otherwise Debian is just the best for me,(from -Potato to Sarge+)
[ Parent | Reply to this comment ]
Do not tempt the unix overlords!
Seriously though, debian does this to remain compatible with all the other *nixes out there - *nix incompatability should (and i think must) be reduced, not expanded. Lot's of things would break if this were done anyway (although a forest of symlinks might work, but then you have another mess altogether)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
That just isn't going to happen - remember Debian is the Universal operating system ...
Steve
--
[ Parent | Reply to this comment ]
I would like to a thin debian TX client like LTSP with NX support (and XDM support). This TX client could be install on a hard disk but also could be boot by TFTP.
My thin TX are old PC without hard disk actually. So this support could be only for i486 i think at the beginning.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
.
If you get rid of debconf, then you cannot configure packages in a way that can be tracked. Do you propose a replacement along different lines, or that everything be configured 'by hand'?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Here are some methods:
- You can select that you would like the defaults applied in all cases. You can later use debconf to change the defaults interactively or in a command-driven fashion.
- You can cause debconf to derive its answers from one of the automated methods, such as out of an ldap system, or you can create your own custom method for the these settings to be selected.
Personally I have my system configured to only ask me important questions, and thus do not have to make interactive choices except in cases where things probably cannot be cleanly handled automatically.
[ Parent | Reply to this comment ]
Speaking of which, what I'd really like to see is this sort of stuff be made more obvious to end users in the documentation. Just figuring out what documentation text might contain your answers can be an ordeal.
It's not an easy problem, and I respect that. I think the wiki is a step in the right direction. Hopefully there can be some wiki-to-documentation information flow.
[ Parent | Reply to this comment ]
Some basic configuration examples would realy be nice.
Now some are without ANY information about the package, or pointers where to find more information. For me it's a real problem.
[ Parent | Reply to this comment ]
Since debian benefits from the rapid ubuntu development (eg xorg) they should try to better cooperate with canonical.
They should finally switch from apt-get to aptitude and aptitude should be completed For example u cannot do something like aptitude search kde AND gnome, wo using strange regex.
Another thing is that there is not good commercial support for debian (compared to redhat), which just sucks.
A big problem here is also that debian does not pay developers which is especially problematic for some positions like security (Martin Schulze seems to be the only person who cares about deb security, even if he's not paid for that..)
[ Parent | Reply to this comment ]
For "commercial support" I take you mean "certificated support" (as you can already find commercial support by many companies: Progeny, Canonical, etc). This is somehow linked to the previous issue, as it might end up being a nice way to make money, but again there are scale issues. Doesn't matter how old and mighty it can seem, Debian is quite small in terms of people working full-time on it, the proof is that it didn't take much for Canonical to hire many key developers. (btw, too many words have been spent on Canonical already, better not going there :-) leave this stuff to DPL and friends...)
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
There is certainly more than one person who cares about Security in Debian.
Whilst I can see why people might suggest paying developers that just opens two immediate problems:
- What do you do when people who aren't getting paid feel like second-class developers - and quit?
- Where does the money come from?
Steve
--
[ Parent | Reply to this comment ]
Transition to libelektra[1] by default - it could be used internally by debconf, before packages would be ready for it. Using of initng[2] or something similar. More consistency in configration.
Adapt something like Launchpad.net from Ubuntu. Make it easier to help Debian by ordinary and less IT-oriented users.
Best regards, Luke
[1]http://www.libelektra.org/ [2]http://initng.thinktux.net/index.php/Main_Page
[ Parent | Reply to this comment ]
Here's just one example of how Debian's security is falling behind compared to other distros.
awstats-6.4-1.1 fixed CAN-2005-1527 (security bug) on 4-Sep-2005 and is NOT YET AVAILABLE in Debian stable as of 9-Nov-2005 for no apparent reason.
That is 2+ months too long for a server-oriented distro that is supposed to be secure without having to do apt-pinning with testing or unstable.
Please prove me wrong: Try 'apt-get update && apt-get install awstats' using pure stable branch, and see for yourself. You will get 6.4-1 (26-Mar-2005). You will not get 6.4-1.1 (4-Sep-2005) or 6.4-2 (19-Sep-2005).
Other distros can get all the available security updates using a single command. There is no reason Debian stable should not get all the CAN-xxxx-xxxx security fixes by doing 'apt-get update && apt-get upgrade'!
References:
CAN-2005-1527
http://www.idefense.com/application/poi/display?id=290&type=vulne rabilities
Changelog for awstats in Debian stable branch (last change 26-Mar-2005)
http://packages.debian.org/changelogs/pool/main/a/awstats/awstats _6.4-1/changelog
Changelog for awstats in Debian testing branch (last change 19-Sep-2005)
http://packages.debian.org/changelogs/pool/main/a/awstats/awstats _6.4-2/changelog
Developer info for awstats (no mention of CAN-2005-1527 fix being held up)
http://packages.qa.debian.org/a/awstats.html
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Serge's Scratchpad | View Weblogs ]
~$ apt-show-versions -u awstats/stable upgradeable from 6.4-1 to 6.4-1sarge1
That still is to late of course.
BTW, you expect to get 6.4.2, but you should now that Debian sticks to the same 'stable' version and backports security fixes. I suppose that's what happened in 6.4-1sarge1.
--
Serge van Ginderachter
[ Parent | Reply to this comment ]
How's THAT for service ;-)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]