Re: dselect survey
On Wed, 8 Dec 2004 19:32:35 -0800, Brian Nelson <[EMAIL PROTECTED]> wrote: > On Wed, Dec 08, 2004 at 10:23:16PM -0500, Mason Loring Bliss wrote: > > Maybe I'm still waiting for my first real problem to show up, but I > > generally find dselect to be a real pleasure to use. > > > > Could you present an example of a problem you had with dselect? Honestly, > > I wouldn't be using Debian today if not for dselect, which I see as being > > a really nice selling point. > > If you really want to find out, go ask on debian-user. You'll find > plenty of people more than willing to piss all over dselect. Hi, I'm mostly a user, and just lurking on the lists to get a feel for whether I want to become a developer or not, but on this topic I will observe that the dselect interface is very cumbersome and non-intuitive until you get used to it. Having "enter" exit the selection process (rather than simply selecting the entry) is perennially surprising, and if I ake the tragic mistake of hitting enter twice based on the muscle memory of some other application, I find I may have already taken actions I wasn't quite ready to take. Selecting packages, and their dependencies, can be confusing. In general, for safety and for confidence, I prefer to apt-get exactly the package and its dependencies that I have researched through the web interface. I have done something terrible to one system: which was a stable distribution. For a project, I needed to obtain a package versioned in the unstable distribution. I foolishly thought I could simply change the settings for dselect to grab that one package, but now dselect thinks it needs to change the package version of just about every package on my system, and I am reasonably sure letting it make that change will irreparably damage the system. So, until I deprecate that machine and rebuild it from scratch, I don't use debian tools on it at all any more. I presume there is a better way to grab a single package (and its dependencies) if one needs a different version than is available in "stable". I am sure there are other ways to damage a system using dselect, but my main gripes are interface: having to scroll or search through thousands of rather garbagy ackages to find what I want is just useless, the moreso if I don't know the exact package name. The web interface to finding packages is a zillion times better, and apt-get is simple and safe. (If I can apt-get a package versioned outside my overall distribution, that would be perfect.) -bluejack -- -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Re: dselect survey
On Fri, 10 Dec 2004 12:13:29 +0100, Florent Rougon <[EMAIL PROTECTED]> wrote: > I'm just trying to understand > people who bash dselect on the first occasion. If you don't like dselect > and don't fall in one of the cases I have mentioned, then we have a > problem. Simply preferring aptitude is *not* a valid reason to say > dselect is ugly, difficult to use, here>. Question: does awkward, non-intuitive user interface for a text-based utility constitute a "problem"? I don't care for dselect primarily because, for whatever reason, the user interface constantly rubs me the wrong way. Although I have read the documentation, I almost always remember it wrongly, hit the wrong keys, etc. etc. After working with it for half an hour or so, I regain my proficiency... but after 6 months of not using it all that minutia is lost to my active memory, and -- once again -- my intuition about how a text-based application SHOULD work fails me. Do I consider this a problem? Not particularly. It is my problem, as much as anyone's. This is a sophisticated sysadmin tool, and I am only an occasional sysadmin, by no means sophisticated. > > (f) bash dselect 'cause someone else said it was crap > However, if you believe that user interface is important, it might behoove you to listen to your users: people don't usually grow to "hate" a system administration utility simply because it's the hip thing to do. Of course there may be some unreasonable, or even plain-stupid users: but if you believe that user interface is important, you even have to think about how to make *them* happy. An owner, interested in user interface, might take it upon him- or herself to start a thread asking for interface suggestions, in a place where users congregate. Ask questions like: "What text-based applications do you consider to be examples of good design?" Focus on the distinction between navigation and data-altering events. Consider on-screen cheatsheets that advanced users can disable. Ensure that there are sufficient and obvious undo paths with multiple roll-back points. I am a software developer too -- I know the temptation to mock users who just don't get it when "it" is perfectly obvious. (I recently rolled out some web software in which a table interface had graphical links: up and down arrows at the top of each column, right below the column label. The number one complaint was: "This is useless. There's no way to sort!" Are my users dumb as dirt? Apparently they are. Is it their problem? No, it's mine.) Anyway, something to think about. -bluejack -- -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Looking for an NPTL porting project
Ahoy! Any developers on this list interested in some help porting an application from LinuxThreads to NPTL? As part of a research project, I need to work through these details, and figure I might as well make myself useful on a real app rather than mock up some braindead multithreaded hello world for the occasion. In particular, I'm looking for something that attempts to handle signals or work with PIDs under LinuxThreads, and which will break under NPTL unless proper conversion is done. Something non-graphical is preferable, but not necessary. Any takers? Pointers to other lists / development projects equally appreciated. -Blunt Jackson -- -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Thu, 17 Feb 2005 12:16:24 -0500, Greg Folkert <[EMAIL PROTECTED]> wrote: > > Debian is unpopular Many places where Debian has changed the "globbed" > config. Many people HATE little bitty files to make things work. Me, > best thing since Sliced Bread. Except I'd rather see --keepcomments as > default and changed to --removecomments. My only gripe, pretty minimal. > As a general note, I find it annoying, frustrating, and confusing whenever ANY debian package has a substantially different installation or configuratin mechanism than the mechanism documented by the software publisher. Taking Exim as an *example* of this, when I installed Exim, and ran into some problems configuring it the way I wanted, comparing the application documentation on the Exim website with what apt-get installed I found it utterly different. The Exim website gracefully acknowledged the Debian configuration mechanism as "elegant" and then advised that if I needed help with it, I should contact the debian distribution owners. Maybe I missed some great documentation out there, but using Google, I found no such documentation. Exim is by no means the only package to do non-standard things, it seems like a debian package maintainer's sole objective in life is to take a perfectly reasonable ./configure ./make ./make install and do utterly wacked out things to it. The upside *may* be having a debian system that does things the "debian" way, which way is more "elegant" (or more secure, a perfectly laudable goal) -- but the downside is clearly that the installation, and often configuration support from the original software team is largely useless. I am perfectly open to understanding why my frustrations with debian packages are (A) due to some ignorance of debian documentation, or (B) inherently unreasonable. Currently, I feel they are (C) the cost of working with an otherwise excellent, reliable, and philosophically congenial distribution. Packages I expect to work closely with (ie., more than just run-it-out-of-the-box) I usually bypass the debian package system and get the manufacturer's distribution. Sincerely, -bluejack -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Thu, 17 Feb 2005 19:31:20 +, Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Blunt Jackson <[EMAIL PROTECTED]> > > > As a general note, I find it annoying, frustrating, and confusing > > whenever ANY debian package has a substantially different > > installation or configuratin mechanism than the mechanism documented > > by the software publisher. > > Perhaps Debian is not the distribution for you, then. We have always > prioritized constistency across the entire Debian OS over adherence to > what upstream authors somehow chose to do. Obviously there's a balance. I wasn't looking for flames. I believe I did explain *why* debian was my distribution of choice even so. > I maintain one package whose upstream author apparently thought that > $PATH would be a good place to look for a system-wide configuration > file. I changed that to look in /etc instead, which makes the > configuration mechanism in Debian substantially different from > upstream's. You may find this annoying, frustrating and confusing, but > it's how Debian operates. And clearly, *this* is a scenario in which the upstream author was way outside the *unix* standard way of doing things. I'm not saying there's any clear-cut answer, other than to hope that both upstream developers and debian package maintainers use common sense. One distinction is in applications that the majority of users just want to work out of the box, and forget about. If I had to tweak the configuration of every application on my servers, I would be a frothing maniac. But there are some biggies, some very well known applications, that, when installed for any practical purpose, generally require somewhat sophisticated user oversight. Exim is one, Apache is another. Mysql is a third. I put in the time to figure out the debian way of doing Exim (and I'm still not sure I understand it, but at for now I have it working). There was a substantial amount of hair pulling and cursing due to the disparity between what I saw on my hard drive and what I saw in the online documentation. After that experience, when I installed apache and mysql, and saw they were doing their own thing as well, I decided I didn't want to learn go through the same frustration with applications I already knew pretty well. I removed the debian packages, and compiled my own from the upstream developers. Note that removing the debian packages did not remove all their config files and so forth, there was a fair bit of manual cleanup afterwards -- but I'm not using the stable distribution, so I don't expect perfection. As for you, Florian's snide comment: > Just because the configuration file is called /etc/exim4/exim4.conf > instead of /usr/exim/configure? Oh dear. No, it was the stuff like this that made me pull out my hair: domainlist local_domains = DEBCONFlocal_domainsDEBCONF How do I figure out where that DEBCONF stuff is coming from? What it means? Of course, it didn't help that during the install I didn't quite know what I was doing, so based on the advice of the install program I chose the big-file-install, which *was* what I wanted, but I forgot that I had done that, so when I went to look at the exim config and found, as the exim website told me I would find (because I was on debian), a gazillion little bitty config files, I got started figuring them out, editing them, and not realizing why it made no difference. Suggestion to exim package people: if someone chooses the big config file, don't even install the little ones. Anyway, the point was not to complain about exim... it sounds like other people are doing that somewhere else. The point was that *whenever* debian package maintainers re-implement a well-known distribution/config system, I *hope* that when users have to work with it they will discover, as I am sure anyone using Henning's package will, that the changes are clearly necessary -- an indisputable improvement. Now... my apologies for that interlude. I'll go back to lurking now. I promise I won't respond to any further condescending comments. -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Thu, 17 Feb 2005 17:08:41 -0600, John Hasler <[EMAIL PROTECTED]> wrote: > > Why were you not referring to the Debian documentation? It has been (or > should have been) edited to reflect the "Debian way". > Well... I guess I'm the typical dumb user in this case. I didn't know the documentation was there! I use a command line interface only, as I build out servers -- I don't install any gui at all. Typically I use my laptop (not linux) to go online to find documentation on applications, or work off the README's and INSTALL's and other documentation that come in a tarball of source. It didn't occur to me that apt-get was putting all that documentation on my hard drive for me. Never even looked in this /usr/share/doc place. So... I guess I have a lot more resources than I thought! I'll just go hide under a rock now. (But I still think there is some benefit from approximating the upstream developer's installation conventions where reasonable and appropriate.) BTW: I have never found any of that documentation through the debian web site. It would be fantastic if there were an easy way to reference it through the web. Except, I suppose there is, I was just too dumb to find it. Gulp. -b -- -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NPTL and static linking
I discovered with some surprise that the 2.6 kernel does not come with an archive version of the NPTL pthreads library (ie., no libpthread.a). So, while dynamically linked applications will link against NPTL by default, building a statically linked application will not only link to LinuxThreads by default... that's your only option! Does anyone know if this is an intentional decision on the part of the glibc/nptl crew to refuse to support static linking of the pthreads library (perhaps due to ongoing development)? If it is a debian decision, apparently we're in good company. Some research turned up the fact that only the Gentoo distribution comes with a static version of NPTL. I considered getting my own glibc source, and compiling it to obtain the archive I desire, but on looking through the glibc documentation, and having only a sketchy grasp of the way that glibc is tied to the kernel itself, I decided against that course of action. -bluejack -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Tue, 08 Mar 2005 23:55:15 +0200, Lars Wirzenius <[EMAIL PROTECTED]> wrote: > ti, 2005-03-08 kello 13:00 -0800, Blunt Jackson kirjoitti: > > Does anyone know if this is an intentional decision on the part of the > > glibc/nptl crew to refuse to support static linking of the pthreads > > library (perhaps due to ongoing development)? > > The glibc upstream maintainers have been against static linking for > some years now, for reasons that seem valid, but which I forget now. I > think there are problems with at least nss (name service switch), which > requires dynamic linking. They don't really guarantee that static > linking works for anything, even if doesn't use threads at all. I am familiar with the nss issue, although that's not really relevant to this question. The nss issue, and the related question in the FAQ is that when statically linking to libc, there are still dynamic loads required -- but libc handles this for the application. (Presumably by dlopen.) I don't actually see anything in this FAQ, or in the mailing list archives (although I haven't read every possible email) to indicate that the glibc maintainers are against static linking in principle. If in statically linking, glibc handled the dynamic loading of the desired pthread library that would be an acceptable solution, but that's not what happens here. In our distribution there *is no way* to link to NPTL in a statically built application. It seems like a problem. Maybe I should take this to the debian glibc maintainers. I think there's a list for that... -bluejack -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Wed, 9 Mar 2005 05:00:52 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: > > Yes, dlopen, but the problem is version skew. With a dynamic libc6, > libc and the NSS modules will always be compatible. With a static > libc6, NSS functions (gethostbyname, getpwuid, etc.) will only work if > the target system has a very similar version of libc to the one the app > was linked with. Or they'll be ABI-incompatible and your program will > crash. Kind of defeats the purpose of static linking. Ah. I understand. That makes sense. > I know this is not directly related your question, but you displayed > what seemed to be a misunderstanding of the static + NSS problem, so. I appreciate the clarification. What is desirable, then, is for the developer to be able to statically link his or her own libraries, and third party libraries, but to dynamically pick up "system" libraries, of which I would number libpthread. That would be adequate for my needs. I expect this is possible, as *everything* is possible, somehow. Perhaps it is something as trivial as a compiler or linker flag that I have missed? -Blunt -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Wed, 9 Mar 2005 19:57:00 + (UTC), Jason Lunz <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] said: > > I just figured out a way to do this for the ssh binary. Maybe this would > work for you? > > Here's what I did: > > $ apt-get source ssh > $ cd openssh-3.8.1p1 > $ debian/rules build I appreciate the thought, but actually building glibc (and the nptl add-on) is a dangerous and daunting task. I looked into it for about half an hour, but glibc is a different order of beast from ssh entirely: it requires considerable configuration which is not for the casual developer, and installing it is a *very* touchy business. Of course, I would really only need to install the libpthread.a archive, but even so, building the whole glibc package is an involved and intensive undertaking and moreover... > Is there anything wrong with doing this? I have by doubts that this is > completely foolproof. Any libc macros or inlines will come from the > build system's libc, for example. I don't know if that can cause > problems when a different glibc version is dynamically linked at > runtime. Exactly. So I decided against this course of action entirely. For just about any application or library *other* than glibc, this would be the right approach for my needs. -Blunt -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Wed, 09 Mar 2005 21:35:56 +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit : > > I appreciate the clarification. What is desirable, then, is for the > > developer > > to be able to statically link his or her own libraries, and third > > party libraries, > > but to dynamically pick up "system" libraries, of which I would number > > libpthread. That would be adequate for my needs. I expect this is possible, > > as *everything* is possible, somehow. Perhaps it is something as trivial > > as a compiler or linker flag that I have missed? > > Yup, just enclose the libraries you want to link statically against > between -Wl,-Bstatic and -Wl,-Bdynamic: > > gcc -o something foo.o bar.o -lsystemlib -Wl,-Bstatic -lownlib > -lthirdpartylib -Wl,-Bdynamic -lpthread This, of course, is the right workaround. Thank you! -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
