What would you like to see changed in Debian?

Posted by Steve on Tue 8 Nov 2005 at 14:23

Tags:

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..)

 

 


Posted by Anonymous (213.164.xx.xx) on Tue 8 Nov 2005 at 15:02
Debian Stable is stable because it is well tested, however bugs do get in.

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 ]

Posted by Steve (82.41.xx.xx) on Tue 8 Nov 2005 at 15:16
[ 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 ]

Posted by Anonymous (213.164.xx.xx) on Tue 8 Nov 2005 at 15:22
/srv/ isn't defined properly in the LSB.

[ Parent | Reply to this comment ]

Posted by pjs (217.70.xx.xx) on Tue 8 Nov 2005 at 23:14
I think the best definition is at the FHS.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Wed 9 Nov 2005 at 08:06
Yeah - *that* definition is great!
"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 ]

Posted by Serge (217.136.xx.xx) on Tue 8 Nov 2005 at 15:57
[ View Serge's Scratchpad | View Weblogs ]
I agree with the point of bug fixes. I have such an issue with rsync, which I investigated some weeks ago (http://www.vanginderachter.be/2005/debian-sarge-rsync-package-upd ated/). Debian Stable should get more than only security updates and solve annoying bugs. I realise this is to some level incompatible with the Stable notion, although this could be solved through a separate update repository, so people have the choice. Of course then there are security updates on packages who got bug fix updates....

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Wed 9 Nov 2005 at 16:53
<blockquote>Web apps should be in /var/www/ to allow proper lockdown, not hidden away in /usr/share. php safe mode should be default</blockquote>
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 ]

Posted by adam (198.133.xx.xx) on Tue 8 Nov 2005 at 15:06
I end up compiling a fair number of packages from source for various reasons, mostly because I need to make small changes on a given site I have that has mail delivered to inbox files in the users' home directories for quota reasons.
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 ]

Posted by Steve (82.41.xx.xx) on Tue 8 Nov 2005 at 15:12
[ 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 ]

Posted by Anonymous (216.99.xx.xx) on Tue 8 Nov 2005 at 15:16
dspam package

[ Parent | Reply to this comment ]

Posted by jeld (24.39.xx.xx) on Tue 8 Nov 2005 at 15:54
Amen brother!

You are off the edge of the map, mate. Here there be monsters!

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 02:38
[ 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 ]

Posted by Anonymous (164.73.xx.xx) on Thu 10 Nov 2005 at 01:15
DSpam 3.6.1 is an amazing tool, work with files with CSS storage, has support for dinamically load storage drivers, LDAP support too, and integrated clamav support. With most mail servers works out of the box as a LMTP filter.
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 ]

Posted by Anonymous (70.244.xx.xx) on Tue 8 Nov 2005 at 15:17
1) Better cross-compile capabilities. yes, I know about dpkg-cross, but I'd like to see something like apt-build adapted to be able to do cross-compiles so that given any cross compiler I could rebuild all of debian from scratch.
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 ]

Posted by Anonymous (82.41.xx.xx) on Tue 8 Nov 2005 at 15:19

Could you explain what you mean by "the Debian list/qmail hypocrisy" ?

[ Parent | Reply to this comment ]

Posted by Anonymous (66.179.xx.xx) on Tue 8 Nov 2005 at 15:43
iirc, debian-user runs on qmail, despite qmail not being in debian due to licensing issues.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Tue 8 Nov 2005 at 15:46
debian-user is on lists.debian.org, which is master.debian.org. master runs exim (or claims to).<br> Maybe I am looking in the wrong place?

[ Parent | Reply to this comment ]

Posted by Anonymous (66.179.xx.xx) on Tue 8 Nov 2005 at 17:30
You're right, I was looking at old discussions - apparently master.debian.org switched from qmail a few years back. The dangers of google :)

[ Parent | Reply to this comment ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:12
this is really irrelevant nowadays since dbj has put qmail into the public domain now - see http://en.wikipedia.org/wiki/Qmail

[ Parent | Reply to this comment ]

Posted by miguel (200.207.xx.xx) on Tue 8 Nov 2005 at 16:48
[ View Weblogs ]
Next release is scheduled for december 2006, take a look at debian newsletter.

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 ]

Posted by Anonymous (83.42.xx.xx) on Wed 9 Nov 2005 at 12:42
I have a friend who wants to install a Unix-like system in an old Macintosh (yes: a motorola 68K driven machine).
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 ]

Posted by Anonymous (65.113.xx.xx) on Tue 4 Mar 2008 at 05:41
A few years late, but what the heck... these are issues still not resolved to my knowledge. I actually own a HP PA-RISC j6750 workstation and installed the 64 bit SMP Debian-hppa release (sarge). Everything seems to work except that there's still no support for the HP FX series graphics cards. Seeing that these (the FXe, FX-5, and FX-10) are most common on these workstations, it would be a real plus to get them working. Not sure if it's HP holding out on the source code, or if Xorg hasn't followed up on it, but it would be nice if someone could investigate this.
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 ]

Posted by grimoire (131.175.xx.xx) on Tue 8 Nov 2005 at 17:03
The main area where I think Debian could benefit is documentation, documentation, documentation. d-a is a great little repository of HOWTOs etc. and there are other sites like TLDP, but it'd be good if there were a Debian project which provides a fairly broad range of things which should be documented, and kept that documentation up to date for each release. Ideally I'd like to be able to download and print off a manual which covers installation, basic administration (adding users and software), basic networking (including integrating with CIFS etc.), web browsing, word processing and so on.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 02:40
[ 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 ]

Posted by Anonymous (210.50.xx.xx) on Wed 9 Nov 2005 at 18:01
"like the excellent "Securing Debian" manual" to bad it's outdated and Debian actually isn't following at all by default. Hell, Ubuntu got the package sig stuff from apt 0.6 before Debian ever used it. Also check out their deroot-patches. And what about GCC w SSP? "We'll wait for GCC 4.1". IOW Stable will have it in 2012.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 18:06
[ 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 ]

Posted by grimoire (81.169.xx.xx) on Wed 9 Nov 2005 at 23:33

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 ]

Posted by Anonymous (80.171.xx.xx) on Tue 8 Nov 2005 at 17:06
Suggestions;
* 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 ]

Posted by simonw (84.45.xx.xx) on Tue 8 Nov 2005 at 18:48
[ View Weblogs ]
"apt-get install linux-image-xxxxx" It updates the GRUB settings for you, and allows you to pick the old kernel in the GRUB boot loader.... How do you find this nerve racking? What is your pain? I've had a fair few kernels not boot (Grrr - Linux 2.6.9 breaks my laptop), but I've never not been able to just select the old kernel in GRUB and backout the update with "apt-get remove" if needed. Did it go badly wrong once, and you are now shying away? I have that feeling with libc upgrades sometimes, although only one ever went wrong and that wasn't even under Debian.

[ Parent | Reply to this comment ]

Posted by toyg (212.248.xx.xx) on Wed 9 Nov 2005 at 11:10
Maybe he was referring to compiling/patching...? I know, that's not so difficult either, but documentation on this mainly relies on Google (again, not the way to go) and it even changed recently.

[ Parent | Reply to this comment ]

Posted by lpenz (200.102.xx.xx) on Wed 9 Nov 2005 at 13:00
There are funny dependencies with udev and friends.

[ Parent | Reply to this comment ]

Posted by grimoire (66.235.xx.xx) on Wed 9 Nov 2005 at 22:59
There are no funny dependencies with udev within the stable branch when upgrading from 2.4 to 2.6 using kernel-image packages. If you're not using the stable branch, then you should know how to deal with funny dependencies.

[ Parent | Reply to this comment ]

Posted by ska (81.225.xx.xx) on Tue 8 Nov 2005 at 18:07
A short list:
* 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 ]

Posted by simonw (84.45.xx.xx) on Tue 8 Nov 2005 at 18:53
[ View Weblogs ]
> (so many -dev packages needed!).

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 ]

Posted by ska (81.225.xx.xx) on Tue 8 Nov 2005 at 20:19
Oh, then it's just ignorance :-) I know how to do apt-get source <package>, but I don't know how to get all the dependencies to build it. I'll look it up next time...
Remove that from my list then!
// Simon

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Tue 8 Nov 2005 at 22:51
[ View Weblogs ]
apt-get build-dep package-name

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Tue 8 Nov 2005 at 23:40
[ 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 ]

Posted by fsateler (201.214.xx.xx) on Tue 8 Nov 2005 at 20:20
[ View Weblogs ]
Actually, if the package is well done (and there is no reason to believe it doesn't), an apt-get build-deps evolution (or any other package) should work.
--------
Felipe Sateler

[ Parent | Reply to this comment ]

Posted by Anonymous (86.49.xx.xx) on Tue 8 Nov 2005 at 18:22
SELinux enabled Debian/Sarge would be nice... I mean no get-from-somewhere patches and policies but really complete official Debian/Sarge SELinux support.

[ Parent | Reply to this comment ]

Posted by Anonymous (83.179.xx.xx) on Wed 9 Nov 2005 at 21:01
I think that RSBAC is better.
So i will prefer a RSBAC integration

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Fri 11 Nov 2005 at 12:24
Me too (that and the patent problem affecting selinux ...).

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 ]

Posted by uroboros (86.49.xx.xx) on Sun 2 Apr 2006 at 19:22
[ View Weblogs ]
It looks like that there is more contributors to the SELinux project than to the RSBAC project (only 5 people?)... Though...

--
If you're smart enough to ask this question, you're smart enough to RTFM and find out yourself.

[ Parent | Reply to this comment ]

Posted by Anonymous (200.203.xx.xx) on Tue 8 Nov 2005 at 19:08
- Prettier init scripts output (cosmetic, I know...) - Switch to xinetd - /etc/profile.d

[ Parent | Reply to this comment ]

Posted by pjs (217.70.xx.xx) on Tue 8 Nov 2005 at 23:04
Debian unstable already has /etc/profile.d:

$ dpkg -S /etc/profile.d
lsb-core: /etc/profile.d

[ Parent | Reply to this comment ]

Posted by sytoka (194.254.xx.xx) on Wed 9 Nov 2005 at 08:47
Switch to fcron...
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 ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:27
Yes, better init scripts would be good.

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 ]

Posted by Anonymous (194.63.xx.xx) on Tue 8 Nov 2005 at 19:15
I would like Debian to be faster. Like Slackware and Kanotix. Where the packages are compiled with optimizations (march, mcpu). And a way to download only patches not full packages for updates. See --> http://www.debian-administration.org/articles/239

[ Parent | Reply to this comment ]

Posted by Anonymous (202.164.xx.xx) on Wed 9 Nov 2005 at 22:09
Downloading patches would be nice. I remember needing to upgrade a rather large package--a download of 40Mb, on dialup!--to (hopefully) fix an issue I was having. The changelog cheerfully told me that the single change made was to a typo in the French manpage.
Grrr.
The bugfix came out a week later...

[ Parent | Reply to this comment ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:21
Agreed!

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 ]

Posted by Anonymous (130.243.xx.xx) on Fri 11 Nov 2005 at 17:57
About faster. This is a comment that comes up all to often.
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 ]

Posted by pjs (217.70.xx.xx) on Tue 8 Nov 2005 at 20:16
Porting chkconfig would be nice, I just don't like the sysv-rc-conf / update-rc.d way.

[ Parent | Reply to this comment ]

Posted by Anonymous (203.214.xx.xx) on Fri 11 Nov 2005 at 09:36
I totally agree.

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 ]

Posted by Anonymous (70.128.xx.xx) on Tue 8 Nov 2005 at 20:37
Yes, I know this isn't necessarily Debian's problem... My main problem is when it comes to the desktop. A lot of the applications or frameworks are so buggy, I can't even believe it made it in to Debian stable--such as GStreamer. It's a great idea and all, and newer versions are more stable, or about to get stable so I hear, but the version that ships with Sarge is a joke. It shouldn't even be in there since there is unfortunately no "easy" way to grab the latest GStreamer packages on my Sarge desktop. Same with Firefox. I can't believe people actually like Firefox. The combination of crashes from Firefox and GStreamer have seriously got me scared and confused when the sole reason I switched to 100% Linux back in '96 -- the desktop was actually stable. My Sarge desktops have firefox crashes multiple times a day (with no extra extensions) and Rhythmbox and every other gstreamer application crashed every hour on the hour. My memory is not the problem as this is the case on multiple desktops. The problem is that I *use* the software. The one desktop I upgraded to sid (for testing) is actually almost rock solid. I don't care for a "new gnome" or "new and flashy this and that." I just want something that doesn't crash and interrupt my thought process 10 times a day. I have no clue how Debian can be changed to address this. Please don't tell me to use Ubuntu either. I'd rather just use ancient software that works than bleeding edge flashy wastes of time that for some reason seem to have everyone reinventing the wheel.

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 ]

Posted by Anonymous (85.76.xx.xx) on Wed 9 Nov 2005 at 02:26
You must have something badly wrong in your system. I use Firefox every day on Debian, and I have never seen it to crash. It's wery stable.
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 ]

Posted by Anonymous (70.128.xx.xx) on Wed 9 Nov 2005 at 15:11
Yeah I'd prefer to use Debian packages, but that's the problem with Debian... Some packages are too old (and supposedly stable) for their own good. I don't have any proposals on how to fix this and if it were me in charge of Debian, I'd leave it the way it already is. The fact is that it's the oss community that releases something called "stable" before it's ready. :-/
Oh well it beats spending money on commercial software.

[ Parent | Reply to this comment ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:32
"the problem with Debian... Some packages are too old"

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 ]

Posted by medwayman (212.159.xx.xx) on Tue 8 Nov 2005 at 20:45
[ View Weblogs ]
Better support for brand new users, who want to use Debian for servers, I mean the headless box type server
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 ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 16:50
[ 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 ]

Posted by badiane (216.27.xx.xx) on Tue 8 Nov 2005 at 21:57
I have always wondered with so many great things coming out of the Debian distro why should the installer be the way it is and also follow the same logic of sequence as do most other OS installers. I am quite proficient @ using it in its present form but what I would like to see is a full GUI/CLI interface.
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 ]

Posted by Anonymous (216.191.xx.xx) on Wed 16 Nov 2005 at 04:54
As I understand it, the interface for the installer has to be kept to a minimum due to the massive number of architechtures supported. It's a lowest-common-denominator sort of deal. You'll notice that the live-cd examples you listed are all very limited in the number of architechtures they support.

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 ]

Posted by badiane (68.167.xx.xx) on Wed 16 Nov 2005 at 17:19
I have a feeling that it wouldn't be that difficult to get it done barring memory constraints and the assumption for this is that I believe if there exists the possibility to do a netinst on these platforms then most of the work is already done.

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 ]

Posted by ido50 (85.64.xx.xx) on Tue 8 Nov 2005 at 21:59
[ View Weblogs ]
1. Faster database for apt-get. 2. An easier way to create .deb packages, and I don't mean something like checkinstall. Some kind of graphical wizard could be good. 3. Newer kernels in testing.

[ Parent | Reply to this comment ]

Posted by Anonymous (83.161.xx.xx) on Tue 8 Nov 2005 at 22:35
I like to see two (or more) meta packages, use-desktop-defaults and use-server-defaults. These should conflict with each other. All configuration that is done differently on typical desktop machines than on typical server machines should use these packages for sensible defaults.
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 ]

Posted by Anonymous (213.208.xx.xx) on Tue 8 Nov 2005 at 23:45
Ideally I'd like a new task-sel called Desktop Debian that installs a full desktop suite that has just one desktop environment (Gnome or KDE, but not both), one best of breed app per task, a firewall installed and running by default, an update-checker of the kind Ubuntu has, a really nice-looking theme and icons, webmin installed by default, and sensible defaults right down to user-mountable disks and partitions, etc. Debian is a really wonderful distro but it's harder than it needs to be to make a really nice desktop distro from it, imho. This might also include a separate kernel optimised for desktop use and which includes stuff like bootsplash and access to more wifi drivers and the like.

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 ]

Posted by Anonymous (66.236.xx.xx) on Thu 10 Nov 2005 at 16:37
I definitely agree that tasksel could be more granular. I don't think we necessarily need a GUI installer (though why not?), but some middle ground between tasksel and aptitude would sure be helpful. Something like redhat's installer would be nice, where you can select which desktop you want to install, then drill down to finer shades if you want to.

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 ]

Posted by Anonymous (71.241.xx.xx) on Wed 9 Nov 2005 at 01:44
I would like to see:
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 ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:38
"Why (in all *nixes) are all executables lumped into one directory?"

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 ]

Posted by Anonymous (213.164.xx.xx) on Wed 9 Nov 2005 at 08:10
1. More kernels 2. Ditch desktop support for Debian Stable, make it a server distro.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 09:11
[ 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 ]

Posted by sytoka (194.254.xx.xx) on Wed 9 Nov 2005 at 09:09
FreeNX is really good for IDSN line. I would like to see the freenx server near the xorg server.
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 ]

Posted by Anonymous (82.127.xx.xx) on Wed 9 Nov 2005 at 10:21
Well, I know I'll get flamed for this but please, remove or give a way to _totally_ disable the horrible debconf.

[ Parent | Reply to this comment ]

Posted by k8to (64.142.xx.xx) on Wed 9 Nov 2005 at 16:05
I don't think you actually mean this. Could you spell it out more clearly? I suspect what you actually want is to get rid of is dselect. But maybe I misunderstand.
.
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 ]

Posted by Anonymous (82.127.xx.xx) on Wed 9 Nov 2005 at 22:49
I propose a way to deactivate debconf so that packages can be configured by hand for people who want to. I just hate interactive package installs.

[ Parent | Reply to this comment ]

Posted by k8to (64.142.xx.xx) on Wed 9 Nov 2005 at 22:54
It is already possible to have noninteractive package installs.
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 ]

Posted by k8to (64.142.xx.xx) on Wed 9 Nov 2005 at 22:59

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 ]

Posted by Anonymous (130.243.xx.xx) on Fri 11 Nov 2005 at 18:01
I whould like to see better README.Debian-files for each package.
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 ]

Posted by Anonymous (147.88.xx.xx) on Wed 9 Nov 2005 at 10:25
Release at time :) I think the stable/testing/unstable/experimental release model is too complex and ubuntu like model would be better.
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 ]

Posted by toyg (212.248.xx.xx) on Wed 9 Nov 2005 at 11:34
Some projects are actually paid for, but the budget is limited. I think debian should constantly campaign for donations, I don't see that happening now; I think during the DPL elections someone said they didn't want to rely too much on Software on the Public Domain (the no-profit company looking after debian's finances), because the few people there are already overworked by trying to make sure money goes to the right people and projects. I'm not sure this is still the case, however I think the last few years made clear that there's an organisational "scaling" issue that still needs to be addressed.
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 ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 16:45
[ 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 ]

Posted by shufla (83.22.xx.xx) on Wed 9 Nov 2005 at 10:45
Hello,
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 ]

Posted by Anonymous (66.73.xx.xx) on Wed 9 Nov 2005 at 11:48
Debian's security must be at least as good as other popular distros.

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 ]

Posted by Anonymous (213.164.xx.xx) on Wed 9 Nov 2005 at 15:01
Wow. That's bad. What bug number did you get for this?

[ Parent | Reply to this comment ]

Posted by Serge (213.118.xx.xx) on Thu 10 Nov 2005 at 11:27
[ View Serge's Scratchpad | View Weblogs ]
Well, as of this morning, I get
~$ 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 ]

Posted by Anonymous (196.25.xx.xx) on Thu 10 Nov 2005 at 21:47
Your timing is perfect -- go check the debian frontpage, you might find that the awstats security fix for CVE-2005-1527 is the top of the security updates list!

How's THAT for service ;-)

[ Parent | Reply to this comment ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:41
It's still a month behind! (although to be fair it might be upstream's fault, but who knows?)

[ Parent | Reply to this comment ]

Posted by Anonymous (205.183.xx.xx) on Wed 9 Nov 2005 at 13:55
I would like to see better COM support. We have some older applications which run great under Woody but have problems under sarge. We also have some applications which we ported from Red Hat to Sarge and they too use com ports. In the past, they would run fine but on Debian, they lock out.

[ Parent | Reply to this comment ]

Posted by k8to (64.142.xx.xx) on Wed 9 Nov 2005 at 14:33
Debian package management needs coherent, by-default logging.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Wed 9 Nov 2005 at 15:01
This would be great.

[ Parent | Reply to this comment ]

Posted by Anonymous (68.18.xx.xx) on Wed 9 Nov 2005 at 15:17
I wholeheartedly agree.

[ Parent | Reply to this comment ]

Posted by k8to (64.142.xx.xx) on Wed 9 Nov 2005 at 15:50
And yes I would contribute some money to a good implementation, perhaps 30 dollars personal, although I'm pretty shocked it's not there already.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 16:43
[ View Steve's Scratchpad | View Weblogs ]

aptitude does provide logging, although apt-get and dpkg do not.

Steve
--

[ Parent | Reply to this comment ]

Posted by Utumno (59.120.xx.xx) on Thu 10 Nov 2005 at 07:34
[ View Utumno's Scratchpad | View Weblogs ]
Eh? What about /var/log/dpkg.log then? I can see this on my Etch machine and I didn't manually set this up for sure...

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 09:13
[ View Steve's Scratchpad | View Weblogs ]

Wow, I'm sure that wasn't there the last time I looked.

Steve
--

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Fri 11 Nov 2005 at 17:00
[ View dkg's Scratchpad | View Weblogs ]
Logging was added in dpkg 1.13.2, and turned on by default in dpkg 1.13.5.

In the handful of downgrades i've seen done (etch-to-sarge, and yes, i know it's not officially supported), that's usually the first sticking point. When dpkg is downgraded, it refuses to work at all, with a message like

dpkg: configuration error: unknown option log: Success
sarge's dpkg is basically saying (rather cryptically) that it doesn't understand the log option in its configuration file. This can be fixed by commenting out the line in /etc/dpkg/dpkg.cfg that reads log /var/log/dpkg.log.

[ Parent | Reply to this comment ]

Posted by Anonymous (193.82.xx.xx) on Wed 9 Nov 2005 at 14:45

I'd like to see support for some simple auditing come with each package. There are two potentially useful, yet flawed packages that need some level of distro wide support.

1) logcheck. This is a cron-scheduled job that finds potentially important log entries by using a series of regexps to throw away the one's you don't need to see. This is great, but it's limited by the fact that since the regexps are packaged in a semi-monolithic way there are a log of checks it makes that are irrellevant to the installed software on my system, or even the version I'm running. If the log regexps were versioned and distributed with the packages concerned then this process would be far more efficient.

2. cruft. This lists "cruft" on your system by checking the list of files registered in the dpkg system and checking it against what's actually installed. There's a lot of files on a running system that aren't directly installed by dpkg (especially under /etc and /var) so this package also contains lists of regexps for filenames - and this is sadly way behind now. So it would be nice if packages included a list of files and synlinks that they generate just by running or being installed.

Also, it would be nice if the contrib packages that retrieve and install non-free software via a non-deb format would use the /opt directory rather than installing into /usr.

[ Parent | Reply to this comment ]

Posted by Anonymous (85.99.xx.xx) on Wed 9 Nov 2005 at 14:49
Really tighter and fine grained permissions. I mean, even *ls* must be restricted if the user is not a member of a specific group. For example users of *developers* group could be able to access gcc, python, etc... but an ordinary user must not be allowed to access these tools.

*nobody* user must not be allowed to access anything. And daemons must only access the things they really need to access and nothing else.

Of course this all must be used if a special installation parameter (paranoid-mode-on) is enabled.

If this is too hard to accomplish, at least there must be a concept of "admin users". Actually there already is a concept like this, by the usage of *adm* group but not all packages follow this paradigm. For example exim's logfiles are, by default, not readable by anyone but root. All packages must use the permissions to allow the members of the adm group to at least diagonise the problems.

Oh, by the way, using init-ng and syslog-ng by default would be great.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Wed 9 Nov 2005 at 15:00
I think selinux is a better choice.

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Wed 9 Nov 2005 at 16:48
SELinux is patent encumbred.
Commercials distros such RHEL can handle this by buying a usage licence to Secure Computing, but Debian wouldn't.
See: http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf and http://lwn.net/Articles/6267/

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Tue 10 Apr 2007 at 09:23
Well, Debian has selinux now..

[ Parent | Reply to this comment ]

Posted by sytoka (83.179.xx.xx) on Wed 9 Nov 2005 at 21:04
I think we have to forget SElinux and put the energy on RSBAC. This could be very nice to have it in future Debian Stable.

[ Parent | Reply to this comment ]

Posted by fugit (199.2.xx.xx) on Wed 9 Nov 2005 at 14:57
[ View Weblogs ]
The list is somewhat short for me, mostly just highlighting what others have already said. Some original stuff below... official amd_64 support. Have a switch to not autodetect DHCP on install (maybe I just don't know how). Maybe just unique to my situation but something better then the interfaces file setup. Out of hte box xen support would be awsome. Full blown SALinux would be nice (as in don't have to have it) official volatile support. Some packages seem to depend on exim4 instead of just any mta ( I happen to like postfix). ~ 1yr release cycle would be awsome. Don't change to much of what makes debian great freedom of choice. Thats my short list, I'm sure I'm missing some stuff but that covers most of it for me.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 15:37
[ View Steve's Scratchpad | View Weblogs ]

The installation manual tells you how to disable the DHCP test for new installers - by adding the netcfg/disable_dhcp parameter.

Steve
--

[ Parent | Reply to this comment ]

Posted by rpetre (83.166.xx.xx) on Wed 9 Nov 2005 at 15:21
Nothing much, really. I have come to learn and love "the Debian way" (although a lot of people complain about a lot of pointless things), but it'd be fun if Debian would:
- drop exim in favor of postfix (I know there is no reason why they'd do that, but it would be nicer to easily switch from one to another, or even choose at install)
- cleanup the dependencies. It really sucks that samba depends on cups, for example (and there are some other cases of "everything plus the kitchen sink". And the later policy of using aptitude which by default also installs recommended packages plainly sucks.
- setup in a saner way the hostname, i always get into trouble with postfix/squid/apache when they can't really tell the hostname and the domain (but probably it's my fault, neglecting some obvious stuff)
Uh, that's all. I like /var/www over /srv , and ONE Debian vs. Server/Desktop Debian (yeah, i run stable on the desktop ;) )

[ Parent | Reply to this comment ]

Posted by Anonymous (81.189.xx.xx) on Wed 9 Nov 2005 at 16:42
debootstrap an ARM image from an x86 box and finishing installation with qemu

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Wed 9 Nov 2005 at 16:59
When GCC 4.1 will be the base compiler, I hope we'll compile everything with the now included smashing stack protection (not the propolice patch! I really talking about the fresh new gcc mainstream implementation).


Smashing stack protection, beside being an excellent way to secure the system, would help to catch many memory management bugs early.

[ Parent | Reply to this comment ]

Posted by ska (81.225.xx.xx) on Wed 9 Nov 2005 at 17:45
Another small, small thing which I sometimes miss: (optional) screenshots in the package descriptions.
// Simon

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Wed 9 Nov 2005 at 18:06
[ View Weblogs ]
Whilst I'd be happy to see better stack protection, and SELINUX and such like for my server usage.

I'd really like to see Debian push on the desktop integration front.

Most of it is there, from GNOME (or KDE), but it needs a bit of tidying up to make sure things integrate nicely by default. Even perhaps adding in Googlizer and Spell checking Applets on the default Gnome desktop (people can always remove them).

Little thing like making sure Icons have long descriptions in their POP-UP dialogues etc.

Would I pay for this, well I almost set up a company doing it at one point, so... maybe. But I want it in Debian, not in a derivative.

Meanwhile if "Debian Administration" could sort out its comment formatting...

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 18:46
[ View Steve's Scratchpad | View Weblogs ]
Meanwhile if "Debian Administration" could sort out its comment formatting...

It will all be fixed tomorrow.

I'm now using the HTML::FromText module to format things properly - whilst making sure that the preview is exactly like the submitted content.

I just need to make a couple more tweaks to make sure htings are working correctly and I'll push out the changes.

Steve
--

[ Parent | Reply to this comment ]

Posted by Anonymous (82.152.xx.xx) on Wed 9 Nov 2005 at 19:08
I'd like to see the init.d scripts accept the argument 'status' as Red Hat (and other) systems do. For example:
# /etc/init.d/ntpd status
ntpd dead but pid file exists
# /etc/init.d/crond status
crond (pid 18378 4906 382 7820) is running...
# 
BS

[ Parent | Reply to this comment ]

Posted by markybob (67.163.xx.xx) on Wed 9 Nov 2005 at 19:54
i would like to see an easy way to have it start up processes in parallel upon bootup. maybe a special package that'll make it happen. suse and redhat have started doing this

[ Parent | Reply to this comment ]

Posted by Anonymous (65.96.xx.xx) on Thu 10 Nov 2005 at 02:03
The init-ng group is working on this. List is at http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-de vel -dsr-

[ Parent | Reply to this comment ]

Posted by Anonymous (83.240.xx.xx) on Wed 9 Nov 2005 at 22:05
Full unicode support!

[ Parent | Reply to this comment ]

Posted by Anonymous (194.108.xx.xx) on Sun 13 Nov 2005 at 17:42
+1.

Debian installer will soon default to using utf-8 locales for all languages, which will only uncover problems with dselect, most, nvi, mc and some others.
Hope Debian will deal with this before etch. E.g. for mc patches exist in BTS, but maintainer is unwiling to use them.

[ Parent | Reply to this comment ]

Posted by Anonymous (158.125.xx.xx) on Wed 9 Nov 2005 at 22:28
I've been using Debian for a few years now (Sid, Sarge, Etch mainly). I really love the distribution but I feel it could both adapt to changing times and put itself in an even better position by:

* Developing apt-build so that it has to employ fewer hacks to get its job done (see the documentation for some of them). I would love to be able to get the advantages of apt with added optimisation and control over patches. It would be great to see apt-build become an officially-accepted way of installing stuff.

* I recently installed centericq on my server running Sarge. In the process, libusb was installed. I followed the dependencies and they made sense, but I still think that installing libusb on a server with no active USB ports doesn't make much sense. Could we have a system to cut down on dependencies we know we don't need -- much like Gentoo's useflags system but it would probably make more sense in Debian to implement it as a ``do not use'' system (to ensure package maintainers specify a maximal and correct set of deps). As the software grows, this technique could be used to keep it a reasonble size for most people. Could also be handy for very security-conscious sites or small systems.

* I love the stability of the system, but it might be an idea to implement different release tracks a la BSD -- ones for security-only updates, minor new features or major new features. This way people could install testing and get updates when new point releases of GNOME came out. Perhaps this would need automating because of the burden it could place on maintainers.

* I like to recommend people use aptitude as it clears up after itself but sadly it doesn't warn people as apt-get does when they will uninstall a critically-required package. Would love to see this feature included so I can sleep at night re people's systems keeping reasonably clean :-).

Again, these are minor points compared to the joy I've got from this distribution. I've only ever once thought about leaving for greener pastures since I installed Sid with the help of a friend years ago. I tried said greener pasture and realised that Debian was the distro for me :-).

Also, would like to say ta muchly to the people that run this site -- mainly Steve -- for an excellent contribution to the community that is useful for Debianites and non-believers ( ;-) ) alike.

best regards,


Matthew T. Atkinson

[ Parent | Reply to this comment ]

Posted by Anonymous (81.178.xx.xx) on Wed 9 Nov 2005 at 23:19
I wish debian would release something usable for AMD64 - the current state still requires both sarge and etch or you'll have unmet dependencies, nvidia requires the help of a module assistant, and I get segmentation faults in mozilla and apt-build.

[ Parent | Reply to this comment ]

Posted by rmcgowan (143.127.xx.xx) on Thu 10 Nov 2005 at 00:14

I'd like to see a modification in (or addition to) the hierarchical structure of the package installation as seen in aptitude, something between the 'task' level and the 'system' level (base system...etc.).

I know a little bit about some of the various packages (for example, PostgreSQL and mySQL are both database systems, exim and postfix are mail transfer agents [I think]), but this is not true for everyone. And it doesn't make sense to me that I should have to either know or spend time searching for packages with similar functionality, only one of which I really need to install.

So, something like an 'Editors' category with all editors (line, visual, GUI) listed, 'Command Interpreters' with all shells (bash, ash, csh, tcsh ...), and so forth. I could then pick my favorite(s), remove those I'd never use, or include something I might want to experiment with, with less effort and time than is now required.

Bob

[ Parent | Reply to this comment ]

Posted by Miciah (24.252.xx.xx) on Sun 13 Nov 2005 at 01:45
Already there: the 'Section' field in package descriptions. If you have grep-dctrl, try grep-aptavail -F Section editors or grep-aptavail -F Section shells. If you prefer Aptitude, see View -> New Categorical Browser. Search for 'bash' or 'mysql' to find the section (I find the hierarchy that Aptitude presents difficult to navigate, myself).

[ Parent | Reply to this comment ]

Posted by Miciah (24.252.xx.xx) on Sun 13 Nov 2005 at 01:45
Already there: the 'Section' field in package descriptions. If you have grep-dctrl, try grep-aptavail -F Section editors or grep-aptavail -F Section shells. If you prefer Aptitude, see View -> New Categorical Browser. Search for 'bash' or 'mysql' to find the section (I find the hierarchy that Aptitude presents difficult to navigate, myself).

[ Parent | Reply to this comment ]

Posted by rmcgowan (143.127.xx.xx) on Thu 17 Nov 2005 at 17:28
Miciah, thanks for the info. It will be useful, for sure. But... Looking back over my posting, I see I didn't explain my concern clearly. I was thinking of installation, where you have two choices: the tasks list; or, aptitude. And, as you noted "(I find the hierarchy that Aptitude presents difficult to navigate, myself)".

I recently did an install of 3.1 and, after selection of some basic tasks, used the aptitude selection to try and fine tune the package selections. Though I did not keep precise time involved, I can say I spent at least 2 hours futzing around in the hierarchy, trying to find things I wanted, removing things I didn't, and then trying to fix the broken dependencies, and so on. One reason it took so long, I think, was I don't know the specific names of packages particularly well, but I do know what I want to do. So, a set of 'metapackages', named by the function they provide, containing the packages that provide the particular service or solution, would still be helpful, I think.

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Thu 10 Nov 2005 at 00:22
-----
xinetd instead of inetd (provide many things that help to secure system agains DoS, and to do many usefull custom tasks).
-----
split i386 in two archs: make pre-i686 an arch, and pentium (or more recent) another, to help optimizations.
-----
an mplayer package. it's already done and used for years (in marrillat archive) but would be great to have it in main.
-----
gcc+propolice (or as said previously, gcc 4.1 with the integrated spp protection) used to compile the whole archive.
-----

Have regular enough, predictible (officially stated policy !) releases. Or at least an official position about (or against) this .

Have a schedule (when to update core libs & toolchains, when freeze will come etc.) to help this timing to be honored.

This problem really need to be seriously handled (even if it's to end up with a voted "no ! we'll keep the current process"), rather than having many people softly agree about this being a problem, but no strict dispositions nor commitment to have it done an other way than it was for Sarge!

And for now no one can say if nexts releases will happen, or be tryed to happen 1 year or rather in 3 years, nor if a majority of debian devs are for regular and predictible releases or not, etc etc.

[ Parent | Reply to this comment ]

Posted by Anonymous (158.125.xx.xx) on Thu 10 Nov 2005 at 11:27
I often wondered why xinetd was not included. I looked into it a couple of years ago and found that it is because of their licence. I believe that since then, inetd has come on leaps and bounds, but I don't know what the relative merits of each are now.

Re mplayer, same issue I believe -- the win32 codecs are non-free. I find it inconvenient not to be able to play some stuff on my PowerPC but the x86 Marillat packages should provide what you need (but you'll have to sell your soul ;-)).

The other suggestions you made are interesting -- with apt-build (I mentioned above) you could have packages optimised for your exact system, but currently the process is a little hacky due to the assumptions made by the rest of the system. I'd love to see this integrated into Debian proper.

best regards,


Matthew T. Atkinson

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Thu 10 Nov 2005 at 11:50
I wasn't aware of xinetd licence problems.
For mplayer: the licence is GPL, and win32codecs aren't mandatory. A pb using marillat's is that it's not always up to date with testing and sid, so the package is sometime broken when we're not on debian stable (eg. when a mplayer dependancy is updated on sid).

[ Parent | Reply to this comment ]

Posted by Anonymous (164.73.xx.xx) on Thu 10 Nov 2005 at 01:43
I think scheduled releases is what every debian user dreams. I don't want crazy timelines like six or four months, but one release every 12 or 18 months would be nice.

[ Parent | Reply to this comment ]

Posted by markybob (67.163.xx.xx) on Thu 10 Nov 2005 at 05:47
how about having bind9 install automatically in a chroot, like RHEL 4 does?

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Thu 10 Nov 2005 at 09:15
[ View Steve's Scratchpad | View Weblogs ]

Bind can be chrooted trivially just by adding the correct flags to the command line.

What would be more useful is adding support for all the other daemons to be chrooted - things like MySQL, Apache, etc.

Of course that brings in its own problems. (e.g. if mySQL is chrooted then users have to mess around with the socket - or connect via the loopback interface.)

Steve
--

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Thu 10 Nov 2005 at 11:27
Yes, for who need more precisions:
joe@myhost:~$ cat /etc/default/bind9 
# for a chrooted server: "-u bind -t /var/lib/named" OPTIONS="-u named -t /var/named"
and that's all what's needed !

[ Parent | Reply to this comment ]

Posted by Anonymous (38.117.xx.xx) on Thu 1 Dec 2005 at 09:24
As trivial as it is for an admin or guru to chroot bind, when I tried doing it to add to my web server/ntp server, following a how-to guide online, I ended up with a failure to start error message in the logs. So even though I tried fixing anything I could think of after going through the article several times and de-intalling/re-installing bind, I never got it working. My guess is that I have a permissions problem in a sub-directory somewhere. So as trivial as it is to set up for some, it isn't so trivial for others sometimes due to a trivial configuration error or some other trivial matter. Trivially stated.

[ Parent | Reply to this comment ]

Posted by Utumno (59.120.xx.xx) on Thu 10 Nov 2005 at 07:01
[ View Utumno's Scratchpad | View Weblogs ]
I would like Debian to adopt release schedule that is similar to OpenBSD's - more frequent releases, less ambitious goals for each.
Why not concentrate on *one* major change per release? For example, Debian 3.2 would be basically Sarge but with X.org in place of XFree and some updated packages. Then, 3.3 would foucs on gcc-4.0 & C++ ABI transition. Time between releases ~6 months.

[ Parent | Reply to this comment ]

Posted by Anonymous (158.125.xx.xx) on Thu 10 Nov 2005 at 11:27
I think these are good suggestions. It seems to me that the problem comes when server admins and desktop users clash. If server admins decide to upgrade every other release, maybe the time for security fixes will have run out? Or maybe we could have releases that are supported server/desktop releases and then other releases that are more like ``service packs'' and are not necessarily supported by the security team (e.g. change from XFree to XOrg).

Debian is a *fantastic* server OS but I feel to make inroads onto the desktop (does it really /want/ to emulate Ubuntu or Mandriva?) there would have to be separate release tracks for both purposes (as I mentioned above) -- otherwise both server admins and desktop users would have to compromise.

I'm quite happy at the moment as I am doing work which absolutely relies on a functioning computer, but it would be nice to have more up-to-date desktop software if it doesn't place too much strain on the project as a whole.

best regards,


Matthew T. Atkinson

[ Parent | Reply to this comment ]

Posted by matej (158.193.xx.xx) on Thu 10 Nov 2005 at 15:54
security.CC.debian.org

[ Parent | Reply to this comment ]

Posted by Demitsu (84.176.xx.xx) on Thu 10 Nov 2005 at 16:20
By default, adduser should not only put new 'normal' users (without --system) in their own (primary) group, but also add them into a general (secondary) group, like the historical @users group. This should put nobody at risk due to over-permissive umasks, but allow the admin to e.g. set /etc/security/limits.conf more easily.

Speaking of limits.conf -- default limits for @users would be helpful. If I remember correctly, the current default permits everybody to deplete available file descriptors and other resources, which is never a Good Thing.

On the desktop side, I'm in favour of Ubuntu's modifications to GNOME, particularly the "Nothing on the desktop" paradigm. Accessing volumes through the Places-menu is simply more time-efficient, since everybody has at least one window open, covering most if not all desktop items. And it cuts short the bad habit of storing downloaded files on the desktop, of course "only temporarily" ;)

By the way, does anybody out there know where the "Debian Menu" within the GNOME menu has gone?

[ Parent | Reply to this comment ]

Posted by Anonymous (199.84.xx.xx) on Thu 10 Nov 2005 at 20:23
  • Security is a seller. Keep it better...
  • I don't want to sacrifice stability for planned released. So I suggest to keep that stable releases when "ready", as presently. But for thoses needing more frequent updates, we could have planned freezes/releases on testing. For instance, have a goal to freeze testing every 6 months, instead of automatically accepting from unstable.
  • This idea could be extended to tasks freezes. I'll really like to have a KDE34 or tomcat5 release when all the developpers working of these tasks have a set of packages that they judge "tested stable". Not an official Debian stable, but a task that you could install on a stable server to get an intermediate update for a group of packages.
  • It's dream time, so let ask for better documentation or source of information. Not necessarily more, but organized, versioned if not up to date, nor redundant, indexed. Generaly, there is too much noise on the information available on the Web, either from wrong or obsolete sources.
  • Too many packages. Too much freedom is no more freedom! Choice is good when you can separate the wheat from the tares. Why when I install KDE, should I get 4 PDF viewers, 2 word processors, 3 terminal applications? I like the previous idea of better subcategories in the distribution. Why not use popularity-contest to select the most popular application and install this one only. But let the user change this default choice, in d-i expert mode. I hope the tags will help with this too...
  • Did I talked about security?

[ Parent | Reply to this comment ]

Posted by Anonymous (81.178.xx.xx) on Thu 10 Nov 2005 at 21:28
postfix+cyrus+amavis require some heavy dark magic:
1) Create the /etc/postfix/sasl directory
2) Create the /etc/postfix/sasl/smtpd.conf file with the same crap sasl methods as /etc/imap.conf
3) Modify the saslauthd init.d script to store details in /var/spool/postfix/var/run/saslauthd
4) Add the cyrus service to /etc/postfix/master.cf that should already be there according to a lot of documentation - only then will 'mailbox_transport = cyrus' work in main.cf
5) Add the amavis service to master.cf - again something that should already be there just waiting to be enabled in main.cf

And thats just to name a few things.

Out of box, cyrus+postfix just error out everywhere. It took me 4 days googling and reading documentation to get anything out of this common recommendation under Debian - all of this is painless on other distributions including Slackware.

[ Parent | Reply to this comment ]

Posted by Anonymous (71.241.xx.xx) on Fri 11 Nov 2005 at 00:43
On small memory systems Debian Sarge runs just fine.
But when using Dselect or Aptitude, the full 15,000+ package database
simply brings these small systems to a halt. I.E. less than 20 MB.
This makes setting up a 386 very discouraging, although useable
some administration tasks are slow due to swapping out the apt data.
Maybe some kind of linked data which only loads package names
and pulls descriptions from disk when someone looks at one would be faster.

Oh yes a 386 today is very obsolete, but what happened to using Linux
to keep these machines useful with current updates and not having to
be running ten year old software. Some things still barely load a 386 server.
And wasn't *nix supposed to use many tiny programs to do big things?

[ Parent | Reply to this comment ]

Posted by Anonymous (84.151.xx.xx) on Fri 11 Nov 2005 at 12:26
- adding support for software raid in the installer. The current implementation in di is broken.

- adding crypto support in the installer (aes encrypted root filesystem) - hey, its 2005, mandriva got this 3 years ago or so

- newer kernels (and with rfmon patches applied)

[ Parent | Reply to this comment ]

Posted by Anonymous (195.135.xx.xx) on Sun 13 Nov 2005 at 10:17
- adding support for software raid in the installer. The current implementation in di is broken.
In what matter? I recently installed on sw-raid using di and it worked perfectly.

Regards,
Christian Joergensen

[ Parent | Reply to this comment ]

Posted by Anonymous (85.84.xx.xx) on Wed 23 Nov 2005 at 21:54
I have a SRCS14L Intel RAID card, and the Debian installer of sarge with kernel 2.4.27 worked perfectly, but he 2.6 kernel freezed the install. So I installed with 2.4 and manually installed 2.6.x kernel.

RAID cards are very common these days... they should tune the kernel well.

[ Parent | Reply to this comment ]

Posted by Anonymous (212.43.xx.xx) on Fri 11 Nov 2005 at 15:45
Traduced (internationalized) packages descriptions would be a great improvment.

Now, all packages descrs (both the one-liner short and the longer one) are in english. Package management tools lastly became newbie-friendly (synaptic, gnome-pm, ...) but can only deal with pkg descr as provided by the archive. That imho an important showstopper for non english speaking newcommers

Think a minute about someone not easy with technical english but still wanting to install an office suite / word processor: how could he succeed with descriptions like " WYSIWYG word processor based on GTK2" ? (if you're native english speaker, imagine how lost you'd be if you've the equivalent in french "traitement de texte CQTVECQTA basé sur GTK2" )

I know this imply a modification in the archive Packages.gz file content and handling, and on package management tools. But it's a requirement for a wider debian adoption, in particular for linux newcommers: facing simultaneously the difficulties of adopting a new system (with softwares that have different names), in a foreign language, and a higher level of technicity ("gkt2 , hu ?"). Since the technical details (like gtk2, etc.) are pertinent and useful for many, and since there no point in renaming applications (like "evolution" becoming "outlook" ;) it'd be really better not to push an other difficulty there.

This requirement is specially important for debian, since we don't provide a default install with a full desktop (all common tasks covered: playing music, movies, mail, web, games, ...), then we should help newcommers to get in, and to install their own environment by themself, even if they come from a minority language. I'm sad to hear over and over that "debian is hard for beginers" only because of such a small detail. It's only about 15 000 short -< 80 char-s lines to traduce for contrib+main in Sarge, but of course the real work would be to handle this (archive formats, apt* tools modifs etc.).

Appart from that, internationalisation is now in a pretty good shape (large DE like gnome or kde are nicely internationalized, debian.org most importants docs are traduced, the installer handle foreign languages very well etc.), great collective effort !


I would really love to ear other people opinion on this. What would be the greater improvment, according to you, for people without enough instruction ? and for people without an enough good english skill ? How would you handle this ? do you think packages description internationalization is a good solution ? or know an alternate way to do this ? or do you think it's not an important problem ?

[ Parent | Reply to this comment ]

Posted by Anonymous (212.43.xx.xx) on Fri 11 Nov 2005 at 15:52
Sorry, I've reported a bad number about the lines to traduce:
egrep -v '(^$|^ .$|^Package|^Priority|^Section|^Installed|^Architecture|^Version| ^Depends|^Filename|^Size|^MD5sum)' /var/lib/apt/lists/ftp.crihan.fr_debian_dists_sarge_main_binary-i 386_Packages | wc -l
149704

(plus 2263 for contrib)

[ Parent | Reply to this comment ]

Posted by Anonymous (194.108.xx.xx) on Sun 13 Nov 2005 at 17:37
This problem can be divided into two parts:

1. Infrastructure in the archive (iirc something is in devel branch of apt)
2. Infrastructure for translators

I guess helping with (2) is the highest priority right now, because translation can be easily done before actual deployment. If Debian allows (1) into archive e.g. month before etch, it will be useless, because there will be no translations to use.

I saw some not very clear mails about this on debian-i18n a while ago, but no result.

[ Parent | Reply to this comment ]

Posted by mcortese (213.70.xx.xx) on Fri 2 Dec 2005 at 20:41
[ View Weblogs ]
There existed a project meant to address exactly the issue you're mentioning. Its name was DDTP (Debian Descriptions Translation Project).

It was ruled by Debian developer Michael "Grisu" Bramer. He managed to put in place a complex system based on a central server feeding (via mail) english descriptions to a farm of translators, and getting the translations from them.

Just adding a line to your sources.list, you could read all the descriptions in your native langiage in dselect/aptitude/...

After debian.org was compromised in 2004 (or was it in 2003?), the server never came up again, and nobody seems to know where Grisu is now.

M.

[ Parent | Reply to this comment ]

Posted by Anonymous (82.253.xx.xx) on Fri 11 Nov 2005 at 21:04
Hello from Philippe Orléans France
I used the Debian3.1 since 2 month after I had tried several other Linux Dsitributions ( Mandrake from 8 to 10.1), Keops first in 1997, Suse 9.0 and previous item, Slackware 9 and 10.
I also use Aurox 10.1 based on Fedora.
I consider than now I am ready using Linux because I haven't only single problems during installation ( about screen resolution). Previously I got problems with the SATA hard disk on which I wanted Linux installed.
As I'm using my pc only for private activities ( open office, planner ...), multimedia, internet and games associated with scanner, printer, lcd, camera and dvd readers, cd as audio and data with burner.

I should like to get improvements about
1 Installing linux with access to internet in texte mode to get informations in order to success installation. Otherwise : get possibility to read documentation on the cdrom during installation. We should think that some computers have no windows system.
2 I'm always suprised by the list of links on the "menu démarrer". very often, the title of each link does not say what for is it ( in KDE ! ). So, for the newbie on linux who are not usefull of computer, it is the ocean. So I suggest that configuration make simplier this list. Also that groups of application was systematicaly made. French Gnome in Debian 3.1 starts this but go to see in :
\Applications\Menu Debian\Applications\petits outils : 41 links
and in
\Applications\Menu Debian\Applications\outils systeme: 62 links

for example : groups for : video ( for reading DVD, photographes), internet ( sub : connections, navigator, mailer, ftp), at work, game, sound ( for listening audio, adjust volume, extract files ...), drawing ( gimp, inskape, dao ...),
scanner, burning room ( cd dvd ...), printer and system utilities where we find : savings records and system, every software to maintain computer and data, installing soft and hard ...
just notice : Aurox is starting that but in gnome desk we have difficulties to get the links to manage the pc.
3 The less quantity of softwares but the most able to compete with microsoft. Anybody could go from windows to linux without difficulty
4 Last suggest : make simplier the Linux world distributions in order to offer to customer an alternative at monopolistic system.
5 Practical case : my Totem do not read DVD : why put it in the main list of software?
Thanks a lot

[ Parent | Reply to this comment ]

Posted by Anonymous (165.21.xx.xx) on Sun 13 Nov 2005 at 11:22
Ubuntu's update-manager (have to agree, it's a much more easier, HIGfied GUI frontend to APT than synaptic)/notification-daemon are waiting in NEW queue (see https://debian.polito.it/downloads/d-i_gtk_snapshots/ Interface sure can do with some sprucing up though i.e. something that conforms more to GNOME's HIG would be nice.

What I do really want to see in Etch is the default version for python upgraded to 2.4, 2.4 kernels ditched, a firewall installed by default e.g. arno-iptables-firewall (currently available from mentors.debian.net) or firehol as someone has suggested and perhaps YAST fully ported. I understand that Jaldhar anc friends are working on it (see http://gnomefiles.org/app.php?soft_id=1004) too if YAST's port can't be finished in time. ;-)

Predictable time-based release wise, I suppose 1 release per year should not be overly disruptive to those administrating server and yet not too long a wait for desktop users. A compromise no doubt but better than present situation me think.

[ Parent | Reply to this comment ]

Posted by Anonymous (165.21.xx.xx) on Sun 13 Nov 2005 at 11:25
Oh some other stuff I hope will make it includes clamtk - gtk frontend to clamav gtkorphan - graphical tool to find and remove orphaned libraries and BUM - GUI runlevel configuration editor for Debian-based systems too if YAST's port can't be finished in time. ;-)

[ Parent | Reply to this comment ]

Posted by Anonymous (218.18.xx.xx) on Wed 16 Nov 2005 at 06:10
Debian is great and I wouldn't want any suggestion to seem like a complaint.

I am not an end-user I can sympathise with those who have get a little technophobic. I feel some small changes would make Debian friendlier.
1. One is have it write partitions to fstab automatically on installation as Knoppix does.
2. Also, the OS installation process could use more explanations along the way.
3. Another is making easier the installation of java programmes. "I have not been successful in installing "cryptoheaven".)
4. Enable midi for all sound cards.

Hope this is a help. Thanks for a listening ear.

[ Parent | Reply to this comment ]

Posted by lloyd (206.173.xx.xx) on Wed 16 Nov 2005 at 07:09
Two things come to mind:

1) I recently installed the new Sarge release from CD. Very efficient. But it left me with a console boot. When I went on to configure X and peer-to-peer Samba print/file functionality I was totally at sea. Problem with X was lack of printer driver. Problem with Samba was ???? I've spent days working through the Samba issue, consulting books, websites, help forums. Recipes and advice very contradictory across sources. I know that this isn't, strictly, a Debian problem. But even a few hints on the installer or better help on the Debian site would help a relative newbie like myself make faster progress. Perhaps better Samba installation/diagnostic tools are needed. Debian could lead the way here. If I were a C programmer I'd think deeply about this.

2) Wouldn't it be great to have a totally barebones Debian system, with apt, packaged as a deb package that includes an installer that produces a liveCD or USB flash boot system! Then, given the liveCD or flash I could use apt to load whatever packages I wanted to create more capable liveCDs or boot flash systems exactly tailored to meet my diverse needs.

Would I be willing to pay for these things? Within my means yes; certainly make a contribution toward them provided there was a trustworthy system set up get the work done.

All the best,

Lloyd

[ Parent | Reply to this comment ]

Posted by Anonymous (38.117.xx.xx) on Thu 1 Dec 2005 at 09:31
I'd like to be able to see what's going on with my hard disks and raid array without having to reboot and check the raid array in the bios. Have an adaptec 2400 card with raid 5 and hot spare, and when the system is running (uptimes averaging 6 months), I have no idea the status of the raid array or disks. There is supposedly some ability to see this by patching in something having to do with i2o, but I have tried following the directions and can't get it working. Last time the system went down due to a power problem, I discovered a bad disk with the hot spare having taken over. Now running raid 5 without a hot spare while my hard drive is replaced under warranty. It'd be nice to know whether I lose another drive in the meantime, so I can run out and replace the second drive before I lose the array...

[ Parent | Reply to this comment ]

Posted by Anonymous (38.117.xx.xx) on Thu 1 Dec 2005 at 09:39
I know there is a YAST for Debian effort underway, but I'd like to see YAST with the same full functionality/capabilities as it has under SUSE. I'd especially like to see Debian/YAST be able to set up OpenLDAP as easy as I've been able to set up NIS and NIS+ on SUSE 8.0/8.1/8.2 And I'd like to be able to set up other configurations or hardware as easily on Debian as I was able to with SUSE by using YAST.

Yes, its a gui frontend. So the argument goes you don't learn how to do things because it hides the text configuration file. Except I never used YAST that way. I always saved a virgin copy of the config file before using YAST, then used YAST to config what I needed, then compared the virgin file to the altered text file to see what changes YAST made to the underlying config file so I could learn from that. I even mentioned to SUSE for them to make it possible to see the command line changes being made to the config file while using YAST, instead of a twirling icon or timer or progress bar.

Then maybe I could get OpenLDAP working, maybe a working printer, or some other tasks made easier.

[ Parent | Reply to this comment ]

Posted by Kellen (85.178.xx.xx) on Sat 3 Dec 2005 at 13:40
[ View Weblogs ]
An option in dpkg to resolve difference between the maintainer's config and the local config w/ vimdiff.

Right now you get:
* install the package maintainer's version (bad if you have local changes)
* keep local version (bad if there are substantial updates to the default upstream that you have no idea about)
* show the differences (fine, I know they're different)
* background it to examine the situation (ehh not that useful)

Being able to edit your local config to a satisfactory point at install time would decrease downtime for packages (say... dovecot) which seem to have config changes every time (unstable, yeah).

[ Parent | Reply to this comment ]

Posted by Anonymous (62.254.xx.xx) on Tue 28 Feb 2006 at 16:49
What I would really like is function management, rather than package management. For example, I'd like to be able to say I want:

* A web server
* A mail server
* Kerberos
* LDAP
* Firewall
* DHCP
* Desktop PIM
* Encrypted network connections
* Encrypted on-disk storage and swap

And then have APT work out what packages I need to fulfill those dependencies. Now, tasksel and debtags and such already kind of do this, but I'd love it to really work "intelligently", so that the best firewall for dealing with LDAP and Kerberos is installed, and the best mail server that integrates with LDAP is installed, etc., and I'd like dist-upgrade to automatically remove one mail server and install another with compatible storage (perhaps by depending on a runtime-created "mailbox-format-data" package, or something), when a newly available mail server can fulfill the goals better.

Yeah, it's a bit of a dream, but Debian is already a dream, and I'm just taking it to it's logical conclusion ;)

Failing that, I'd love it to support client-server single sign-on and other organisational security/management infrastructure, like Active Directory or eDirectory does, or (I guess) Redhat/Fedora Enterprise editions do.

[ Parent | Reply to this comment ]

Posted by Anonymous (66.92.xx.xx) on Thu 9 Mar 2006 at 02:57
It would be really nice if you didn't have to build a custom kernel in order to get Debian Stable to recognize all of your memory. Is it that rare for servers (or workstations, for that matter) to have more than 1GB of RAM?

[ Parent | Reply to this comment ]

Posted by Anonymous (60.234.xx.xx) on Sun 26 Mar 2006 at 23:48
removal of Exim as a default mail package, becomes annoying with apt-get if you have a source install of another MTA (qmail etc). Perhaps the default could become a more widely known/secure MTA like Postfix etc. And a Qmail deb package, maybe this would kill the idea of security behind Qmail?

[ Parent | Reply to this comment ]

Posted by Anonymous (212.20.xx.xx) on Mon 27 Mar 2006 at 08:23

A real qmail package isn't going to happen until DJB changes his broken license.

[ Parent | Reply to this comment ]

Posted by ramnet (63.20.xx.xx) on Mon 7 Jul 2008 at 20:48
He has! See comment 157 for more.

[ Parent | Reply to this comment ]

Posted by Anonymous (81.178.xx.xx) on Thu 13 Apr 2006 at 14:40
I would like debian base-config and installer to use the release "code name" (e.g. sarge) instead of "stable" in /etc/apt/sources.lst.
Today, doing "debootstrap woody" + base-config will upgrade to sarge by default and I think that is wrong (i know that there is work-around by cancelling package installation, editing the sources.lst by hand, then re-sarting apt process).

Vlad

[ Parent | Reply to this comment ]

Posted by Anonymous (69.181.xx.xx) on Sat 15 Apr 2006 at 01:12
I am a not too technically advanced Debian user who only uses it for a basic desktop, I would like to see a debian package that doesnt have every application that exists but has a multimedia, a word processor, and a web browser. Something like the netinst package, but with enough applications to use the system as a desktop

[ Parent | Reply to this comment ]

Posted by Anonymous (200.55.xx.xx) on Sat 6 May 2006 at 16:47
I want complete support for UTF-8 (like ubuntu, mandriva, redhat, suse an anothers) in all packages.

TIA

[ Parent | Reply to this comment ]

Posted by Anonymous (131.130.xx.xx) on Wed 10 May 2006 at 16:18
I think it would help to change the default runlevel setup and runlevel management. For example: Default runlevel in Debian is 2. I consider it usefull if there are different multiuser runlevels with different options - like with or without network and networkservices - as default.

Some kind of centralized runlevel management would also be nice. Like chkconfig in Fedora or rc-update in Gentoo.

[ Parent | Reply to this comment ]

Posted by Anonymous (145.117.xx.xx) on Fri 26 May 2006 at 15:01
The PROMPT_COMMAND variable should be unset again in /etc/bashrc. It is extremely annoying when you have xterms with shells on a couple of dozen shells, and as soon as you connect to a Debian or Redhat system, your xterm title bar gets changed to some obnoxious prompt. I think having my prompt on the command line is sufficient, leave the xterm title bar alone. I don't mind if the definition would be hashed out in bashrc so those who wish to have their titlebar mutilated can opt for that, but it should be off by default

[ Parent | Reply to this comment ]

Posted by Plymouth (80.235.xx.xx) on Sun 23 Jul 2006 at 22:06
The partitioner could be made a hell of lot more intuitive. I'm sure there's a whole load of guru types muttering about the current partitioner being perfectly adequate if you know what you're doing.

Obviously you can't "dumb down" everything, but unless the install process is made as simple as possible, all too many people will be deterred from installing Debian, and experiencing the rich learning environment it provides.

The maintainers really should take a leaf out of Mandriva's book - now there is a partitioner that's truly intuitive!

[ Parent | Reply to this comment ]

Posted by Anonymous (132.236.xx.xx) on Thu 3 Aug 2006 at 19:16
Honesty: either remove the sourceless binary-only stuff, or admit in the "Social Contract" that it's included. I don't care which.

[ Parent | Reply to this comment ]

Posted by Anonymous (60.52.xx.xx) on Sun 10 Jun 2007 at 18:38
A reasonably good device driver for Broadcom Wireless cards which is already available in Ubuntu but doesn't work properly on Debian.
Thank you.

[ Parent | Reply to this comment ]

Posted by brittdun (70.61.xx.xx) on Tue 5 Feb 2008 at 17:09
[ View Weblogs ]
I very much agree. That was the biggest issue for me as I had an old Dell 1350 wifi pcmcia card that never worked until I found Mepis 7. Kubuntu, Ubuntu, Debian, all would not support that card even though i used ndiswrapper or madwifi. BUT, I finally went out and bought a netgear card and I now have wifi out of box.

I probably would have stayed with Debian as I loved it soo much, but seeing as I had no internet access, I had to keep looking.

I do love the way debian-systems run and are typically easy to use for a new linux convert.

I would like to see gtk and all required packages available via apt-get/synaptic.

Actually, I don't know how feasible this is, but I would love to see an intuitive shell. Say you are compiling a program and it needs a dependency. I would love for it to automatically know - hey I need this to work - and it downloads and installs it if it's available. (Me being new to linux, I have no clue if that is feasible.)

Thanks!

Brittany Dunlap

SimplyMepis 7, KDE 3.5.8, Evolution, Firefox
2.6.22-1-mepis-smp

[ Parent | Reply to this comment ]

Posted by Anonymous (212.123.xx.xx) on Mon 16 Feb 2009 at 08:07
remove the logo,

it might not seem important but i was actually thinking about using the official font from the official debian logo in some graphics and was wondering where to get that font....guess what.... it has a restrictive license and can be purchased for USD 95,-

now...blobs and blubbers in the kernel i can handle and personaly i have no hard feelings toward "non-free" software, altough i do like the seperation.
but to have a "NON-FREE DEBIAN LOGO" kind of makes it hard to explain the debian philosophy.

[ Parent | Reply to this comment ]

Posted by Anonymous (95.208.xx.xx) on Wed 14 Apr 2010 at 21:17
What about maintainers answering more timely and being more patient towards those reporting bugs? That would be great.

cb

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 825 votes ~ 10 comments )