Yep, well, foolish people say lots of things about other people's work that they don't understand. I recommend people think for themselves and do a little research occasionally. People saying this kind of stuff are talking about issues that are easily two years or more old, and I can assure that someone had a reason for each of those replacements because there's a bit of an obligation to keep up with those packages once they've been adopted and that sort of extra workload piles high and deep very quickly.

You're also talking about these packages as if to imply that none of the Dropline devs are actually checking the things to be sure they're compatible with each other. They are on both counts. This checking has many times in the past revealed bugs in other packages which also need to be fixed which is how Dropline wound up maintaining a ton of packages that otherwise would have never gotten any updates from Pat. Who in their right mind builds X on their own without very good reason I ask? (Ah yes and that's been dropped since at least 2.18 since there's currently no outstanding show-stoppers in the Xorg packages.) Reminder: Pat does not update packages to fix bugs which only affect packages that Pat doesn't ship--so if you're using some package that Pat doesn't ship, and a bug in say, xwd keeps it from working, Pat's never going to release an update for your problem (which is not unreasonable--he can't readily test what he's not running).

As to the "all kinds of third party dependencies" that would be a big, fat no. Dropline ships nothing that depends on anything not provided by Slackware or Dropline itself. People coming to conclusions that differ from that probably have some stuff from Linuxpackages.net installed that's polluting their dependency trees. (use readelf not ldd, people).

As to the end-user having to worry about "hundreds of other packages" that's why Dropline exists, so that all these packages have actually been built against each other and checked by someone so the end user doesn't have to figure out the entire list of everything they need--it's all been provided for them. If they want to cull out packages they're not using, just like with every other Slackware package then it's their responsibility to know what needs what else so they don't break something. (Good example: the short bus riders who decide to remove PAM and then wonder why GDM stops working.)

If the system has brokenness which needs correcting, I'd have thought most people would want those problems fixed instead of taking such a mindlessly dogmatic stance as to actually be keeping bugs around because of some nameless fear of what might happen if something gets a teeny-version upgrade. That sort of insanity leads to nothing ever being upgraded because dear god you might actually come across one new bug as you fix two outstanding ones.

I'm sure you'll enjoy the cries of "IT IS TEH INTRUSIV!@#!@" as much as we do should you dare to release an updated XFCE package to fix the bug it has that causes it to occasionally fail against the new gtk+. ...or to cite another historical example, the bug in pango that causes it to fail to render vertically-oriented text properly. ...or the construction of Firefox that causes an upgrade to require >100Mb of packages to be rebuilt and redownloaded.

NetworkManager, as it stands, requires at least one change to the system to work properly, if at all. Anyone wanting to use NetworkManager without being "intrusive" is just S.O.L. Some folks might opt to take the lazy and unproductive approach of never daring to take that step because it might cause them to have to think for themselves and maybe make a decision or two. Me, personally, I put in the work and the research to figure out what are the least changes necessary and to figure out how to minimize the impact of those changes on the rest of the system. The difference between these two approaches is that one of them is what system administrators and architects are for, and the other is what wild-eyed religious fanatics are best at.

Reading this thread I think we largely agree and are disagreeing on semantics here. I may be doing the same thing but instead I call the repository "upgrades" since I'm upgrading packages included in Slackware, that aren't upgraded upstream until a newer release. The burden to keep them updated is on me from then on and not on Patrick.

I may have put this the wrong way so you misunderstood, but I consider many codecs (faac, faad, xvidcore etc.) to be third party libraries that are needed a.o. for GNOME and KDE applications. You consider them to be part of Dropline GNOME. I don't think either of us is wrong, again discussing semantics.

Linuxpackages must be the most useless "collection" of packages ever created. I have tried them multiple times over the years and in the end I decided to just build my own. It's really something made by amateurs for amateurs without any source scripts available for most of them.

I don't know what kind of script you use for dependency checking to see if all binaries have their dependencies satisfied but for lack of something better I have been using the "--dep" portion of swaret. I hope to create a script for doing this in a better way when I can spare some time.

Getting the kernel, Xorg (DRI), OpenOffice.org and Java running on MIPS and SPARC is taking too much of my time right now to get this sorted out.

I am not criticizing Dropline, I only installed it once when I learnt Slackware (and therefore UNIX) in 2003. I remember it borking my system and that was the last time I ever installed it. Things may have improved in the meantime but I can't tell.

This type of users is the worst and that's why we need some kind of dependency checking if only to prevent them from unnecessarily taking too much of our time with such basic issues. I'm not arguing in favour of RPM or DEB (I think they both suck) but more like what aptitude does, installing dependencies when they are needed for the system to function properly and still not hinder the basic pkgtools.

Again no bad word from me about this need to upgrade packages to enable certain extra functionality. But from then on you have to take responsibility for any further security and functionality upgrades for these packages instead of relying on Slackware to do that for you.

I have to admit that I've never used GNOME much longer than a few weeks at a time since it just doesn't seem to fit my needs. That may be why I've never experienced these bugs myself, though I've been finding out that building Firefox with GNOME support leads to various kinds of weird and buggy behaviour, so I've disabled that.

I haven't even had the time to try this out since previously I used Wifi Radar to get wireless up and running. This is the first time that I've compiled Networkmanager and I don't have the luxury of previous experience that tells me what is and what isn't needed for it to function correctly.

I hope you aren't pointing to me, because if that accurately described my view I would never have even started building a Slackware derivative using (C)LFS to get the software running on different architectures. I would have stuck to Debian, OpenSUSE or Fedora.

Sometimes it's a hell of a ride to perfect some build script and get sets of packages to build in a cohesive way. I don't go out of my way to upgrade packages if necessary but I also take full responsibility to maintain them. Also users of my (up to now nameless) distribution should bother me and not Patrick if anything is wrong since he can't possibly fix anything he didn't include or test himself.

I think Dropline should do the same thing and not call it Dropline GNOME but instead something like Dropline Linux. This would communicate in a better way what you are actually providing, i.e. a complete distribution based on Slackware, but also replacing packages when you think that's necessary. Patrick already considers Dropline a fork, so what's stopping you from formalizing this?

Not a bad idea. While Dropline Gnome isn't a "complete distibution" by any means, it still makes enough changes that your no longer running vanilla Slack. When I build Gnome on Slack, I don't replace Slackware packages to fix bugs. That's not building gnome, it's taking over maintainership of Slackware. gnome 2.20 only requires glib2, pango and gtk2 upgrades on Slack 12 to run. That's it. shared-mime-info needs upgraded for totem's plugins and a source built fireox is "needed" for a few things. atk, desktop-file-utils, libgsf, libxml2, libxslt and many others are replacements purely for bug fix or enhancement reasons only and not actually "required" for the build.

It really just depends on how far the developer is willing to go to provide the most complete gnome and how far the users are willing to go to install said gnome.

Ofcourse. But fixes on Slackware packages need to originate from Slackware. I think therin lies the bulk of replaced packages on DLG. The rest are "enhancements" like added security that PAM provides. fixes and enhancements really have nothing to do with Gnome. It's strictly the developer making a decesion that he or she WANTS to replace those packages. Not that they NEED replaced.

If that be true, then that's where I stop what I'm doing and scrap the project. Early in this thread people were argueing against NM for the reason that it goes against "Slackware philosophy" as far as the functions that it provides. A lame excuse. If it turns out that NM goes against the "Slackware philosophy" because you have to bastardize your system just to get it to work.... Then yes. I'll whole heartedly agree. Network Manager has NO place on Slackware.

NM is very much redhat based. Atleast the dhcp dbus bindings are Redhat. So, it really wouldn't suprise me if you do have to jump thru hoops to get it to work on another distro besides FC or RHEL... When someone builds software specifically designed for a certain platform then you'll have centric related things.

I don't think anyone stated that it's 100% possible to get it working on Slackware without being intrusive. No one will be eating any words. People like myself just won't be using NetworkManager, that's all...

Hi all,

Just a quick note to say that I have (K)NetworkManager working on my Slack12 laptop,
and that it is a thing of great beauty!

To find and connect to any wireless network in KDE is now a single mouse-click event.
(no terminal or .rc editing required at all).

My system has not suffered any speed degradation, nor has it become unreliable or unstable so I am very happy with the results.

I also have the option of choosing between (K)NetworkManager or standard slackware networking by chmod'ing a single rc.
Both networking systems work independently of each other, so I'm happy about that as well.

I haven't yet gotten dial-up connections automated through (K)NetworkManager, although I must admit that at this stage, this is of lesser importance to me than Wireless.

I am currently experimenting with WPA and WEP networking to windows systems, but so far, things are looking good.

I'll play around with it some more in the near future (time permitting),
and when I can, I'll also post a How-To and package list.

Cheers

Orbit


.

It's great to hear your success story. It would be much appreciated if you could send us (psychicist and jong357) the source code patches and scripts that you used to get this working.

Cheers,
psychicist

...or how much FUD and nonsense people are willing to use to try to make an argument. Offering package replacements that fix bugs isn't "taking over maintainership of Slackware". It's fixing things that Pat can not be expected to fix. Being a system administrator means making decisions about what is going to work and what isn't, and if you're distributing packages to people, that onus is doubled. Sitting around saying you're not going to make any decisions about these things makes you a user and this is not a useful hat to be wearing if you're going to try to make binary packages for other people because you're really just dumping all that responsibility into their laps. I'm not about to start telling people "well you need to go do x, y, and z, manually if you want this to work" when I release something. I'm going to fix the freaking problem and if they ask why they didn't have to go do those things, I'll tell them "oh yeah, that's been fixed. Enjoy."

To address the latter point, psychicist has at least admitted that he hasn't actually seen Dropline in four years, and I suspect you're no different. So what kind of special knowledge does this give either of you to say whether or not Dropline is or isn't anything?

You, yourself, just listed a whole slew of packages with known bugs, and then decided that it was okay for those bugs to remain in place. The argument you make above that these bugs should not be fixed is complete and utter crap. That's suitable behavior for a religious debate, but as far as technology is concerned, it's insanity itself. (In fact, many of those packages you're citing as "enhancements" are explicitly itemized for GNOME releases, and not using them means you're not shipping GNOME, you're shipping a "bastardized" GNOME. Period.)

This is the core of the problem. You, and a whole lot of other people out there, seem to think it's okay to have bugs lying around untended. The reasons everyone seems to keep citing for saying this returns to not replacing packages to avoid creating bugs because they don't want bugs. These two approaches are diametrically opposed to one another.

To put it bluntly, you don't get to have "nice things" like NetworkManager in Slackware without doing one of two things:

1. Maintaining some packages that Patrick basically isn't.
2. Sitting and staring at a long list of known problems and having users wonder why they're not being fixed.

...and there's multiple problems with this as well.

There's a few interpretations of this "Slackware packages need to originate from Slackware." statement, and the one most people seem to be falling into is just plain dogma. Patrick does not upgrade packages to fix bugs unless they affect Slackware packages. Period. With this approach you can not run anything that Slackware doesn't ship without keeping any bugs relating to it caused by old versions of it's dependencies indefinitely.

Well, if you really believe this, NetworkManager actually has no place in Slackware because you will be tampering with the dhcp package, or NetworkManager can not work. Somehow I think you're going to react just like everyone else does by quickly changing your tune as if you didn't actually say those short-sighted things (i.e., changing your criteria to suit the situation), or you might actually declare NetworkManager unsuitable for use with Slackware, which would simply be dogma.

RedHat's people are where NetworkManager originated, but it is very much not RedHat-centric. The issue is that since Pat doesn't modify the way packages are put together, this frequently leaves no avenue for anything outside of Slackware to usefully utilize those facilities.

Saying the "dbus bindings are Redhat" is simply incorrect. They are not. The thing uses dbus, period. Slackware now ships dbus. Debian and Ubuntu ship dbus. Mandriva ships dbus. SuSE ships dbus. Heck, Slackware was pretty much the last distro to come out of the woods and ship dbus. There is nothing Redhat-centric or anything like it in the way that NetworkManager uses dbus.

The show-stopping "hoop" is strictly because there is no safe way to hook into dhclient's exit scripts with the way Patrick has constructed the DHCP package without trodding on local-administrator space and risking blowing away say, someone's ddnsclient installation. Dhclient's exit script functionality was designed from the outset to be used by other programs, and without ISC breaking their own vanilla installs, there's no way for them to change what they've got. Patrick won't change what he's shipping because of the policies he's following when he makes packages, and those changes are exactly the sort of minor things the ISC guys expect actual system administrators to handle on their own.

At least what I've got simply requires someone using a ddnsclient that's tied into dhclient to move their hook into a directory where it can actually play nicely with other things that use the dhclient exit hook functionality. Functionality is increased, things are just as transparent of operation as they were before, and everyone (except the people living in caves) goes home happy.

I've been saying flat out, it's not possible to do this using the pointlessly dogmatic approach you guys are calling for. It's going to continue to be a problem for you and a lot of other people pretty much forever until you man up and make some judgement calls instead of behaving like a walking shell script. I suggest you break out the silverware.

According to what I've seen at their site, the next release of NetworkManager won't require the dhcdbd (dhclient dbus bindings), so assuming there aren't any other dependencies introduced, it should be pretty straightforward to get the new version (when it releases) going on Slackware. The netlink library is small and easy to build, and from memory, that's the only thing NetworkManager will need that isn't already part of Slackware.

Yeah, that would be an issue of semantics, alright. Dropline releases the packages GNOME needs and wants, and Dropline maintains them from there on out, except when Dropline does it, people don't call it "upgrades" they call it "intrusive". I call that a double standard.

In the past Dropline shipped those because basically, multimedia functionality is something just about all the users seem to want. Slackware isn't shipping them, and GNOME has a number of packages that make extensive use of them. It only seems sane to go ahead and just fix the problem. Now that some more time has been spent to iron out some of the finer details, there's a number of those which will no longer be shipped by Dropline because some jerk will probably eventually start suing people, so some parts of gstreamer are going to get shipped with missing dependencies that will break the plugins that depend on things that can't be shipped safely. ...but at least if someone goes and solves those dependencies themselves, the plugins will have been compiled and should immediately work.

Well, at least we agree on that much, although disclosure would require me to say I'm still a little irked with them over their kvetching that I bzip my man pages instead of gzipping them. Of all the ludicrous things to call foul on...

When was the last time you saw something compile without it's dependencies being present? At any rate, I don't use a script for this. I've stared at the stuff for so long I can pretty much recite them in my sleep. Knowing what dependencies something needs is right in there with core Slackware values and there's too many other problems for me to solve right now to worry about that one.

Dropline's been doing that.

Two reasons:

1. Dropline isn't providing a complete distribution. Dropline provides GNOME and things GNOME desperately needs, and some applications that people who install GNOME are almost invariably using.
2. Because this would entail increasing the workload to the level where Dropline would wind up getting much less done. Dropline already has to pretty much cut off support for older releases rather quickly due to manpower issues. Patrick seems perfectly capable of handling all the OS underbelly issues so why borrow trouble?

If you want a fork, find me some home cloning technology.

This whole problem with NetworkManager is symptomatic of how people are creating unreasonable and contradictory criteria for what they consider "stable" and then just picking and choosing which guidelines they're going to actually adhere to at any given moment.

Bingo. The average linux user has NO CLUE how much time, effort, and headache is involved in maintaining (or even attempting to maintain) a complete linux distribution. Dagmar does (regardless of whether he's ever done so) - listen to him :-)

Seriously, if you want to have just a small idea of how much work it is, pick a few non-trivial applications and start maintaining packages and build scripts for them. Be sure to respond to *all* (or at least most) user support requests in a timely matter (you will support your packages, right?). You'll need to subscribe to mailing lists for all of them and keep track of issues people in other distributions face with them. Once you've done that for a while, now consider doing that for hundreds of libraries, applications, and other software, the vast majority of which you don't even use (or perhaps know how to use). When you've been there and done that, you'll be much more appreciative of what Pat does (and how well he does it). The same can be said for Dropline, for that matter - while I'm not a fan of GNOME at all (and that's no secret), I still have a lot of respect for the time and effort the DLG guys put into it (and for the quality of the resulting product).

First of all Dagmar, calm down. No one is criticizing anyone and their work. There is no need to take offense or get huffy. What I'm saying is that I use Slackware for a reason. I like the way it's contructed and opperates and any additional tinkering I do isn't viewed as necessary. I can use it as is and be perfectly happy.

I'm opposed to replacing Slackware packages for many reasons. To be precise, I have no problem doing it on my own system but I will not force it on anyone else. It's not my place to start screwing with peoples systems and replacing packages here and there. I build gnome for myself and no one else and I only replace what is necessary to get it to build.

We'll see glib2, pango, gtk2 and other upgrades in Current eventually and when that happens I'll stop using my own packages. I already have my own OS built from scratch to maintain. I have no desire to start doing it on Slackware. That's Pat's job, plain and simple.

I use and make available scripts only so the user can decide what is best for their system. I am not "administrator" of anyones system except for my own. By building from source, the user has complete control over what happens with their system and it takes me out of the equation. "If you don't like it, then fix it". To me, that's what Slackware is about.

Your the one who came in touting that NM works with DL and you've never seen a complaint that it didn't. We were trying to talk about NM, but once again we get sidetracked. Just because one or two people mentioned in passing that they had problems with NM on DL in the past doesn't mean you should come in a high jack the thread.

I never said they shouldn't be fixed. I said it's not my job to fix problems in Slackware Linux. It's Pat's and the Slackware team. What should be happening is that you should email Pat and send him patches that fix these bugs so they can be included in Slackware proper. To argue that Pat has no reason to fix them is utter crap. When you side step proper chanels and decide to fix something without pushing it upstream you do nothing but hurt OSS development. Period. If they have already been identified upstream and fixed in SVN, then we will see a fix when the new version gets added to Current.

bastardized implies extreme re-orginazation. Try minimalized. If those packages were only used by gnome then they wouldn't be included with Slackware, would they? They are GTK based apps, not gnome based apps.

Absurd. Where do you get this stuff?

The rest is rubbish as well. I don't have time to argue with you. Indeed, there is nothing to argue about. The fact that there are many gnome offerings provided indicates that people inherently like to do things different. What's wrong with that? If you feel the need to argue about it, then just don't. It's a waste of breath.

That may be true for the average user, but then I'm not. I now have about 1500 packages installed (inflated by modular Xorg and KDE/KOffice translations) on both x86 and MIPS and SPARC is going that route as well. It will only grow bigger over time and maybe rival Debian for the number of packages in a few years' time but for now I'm focused on fewer high-quality ones.

I know very well how difficult it is to maintain a distribution, as that's what I've been doing for more than two years now, albeit I borrow the underpinnings from Slackware. Ubuntu does the same thing with Debian Unstable, but I prefer stable releases. Not to mention figuring out why some packages build fine on x86, while for some stupid (e.g. intertwined x86 assembly) or obscure reason they don't on the other architectures.

I'm not actually all that excited. I'm acting in the usual role I seem to get stuck with as the Bearer of Bad News. People are wanting NetworkManager on Slackware, which IMHO is a completely worthwhile thing. I was on the fence about it at first, but after putting together some packages and testing them at a local coffee house, I was completely won over. For open and WEP networks, it's more reliable and easier to deal with than even the stack Windows uses.

...but what simply not going to be able to happen is for Slackware users to use NetworkManager without a certain level of "teh intrusiv" going on. You guys seemed to be under the impression that this is a doable thing, and I can tell you for certain that without at least seriously bending some of the commonly accepted guidelines that it's simply not going to be possible. People are just going to have to make those adminly decisions if they want this functionality.

I'm just going to settle for quoting a particular movie for this one:

"It builds! SHIP IT!"

It's not enough to get a script together that results in binaries. For some strange reason, quite frequently people expect these binaries to actually work correctly.

I feel the same way, hence, no "Dropline Linux".

DLG packages ship with their "DNA" so the users have the scripts if they want to figure out the build engine and make that go. Most of them just hit the wall of realizing that things are a lot more complex than they first thought, and tend to grind to a halt and just complain later.

Acutally, I was pointing out that it works with DLG because we were willing to stick our necks out and make the necessary changes. No one complained before (well, no one in their right minds anyway) that we were replacing the dhclient-bearing package, in part because Pat's package hadn't actually worked in years. I still have no idea why they didn't put the patch I sent them to fix this into the latest release--I'll hammer on them about that again later--maybe I'll get somewhere if I just email Ted Lemon directly.

If you're wanting this package to work without touching anything in the official Slackware packages, you are just S.O.L. at the moment.

No, it's not crap. The sad truth--and this is nothing against Pat--is that he really does not update packages if they don't have bugs that affect packages he has released. We've been through this with him before about a number of packages. It's also completely reasonable that he does not update these things, since if the affected package isn't one he's building or shipping, he doesn't have any reasonable way to test the updates without allowing scope creep to eat up all his time.

If you're going to be saying that Slackware with Dropline isn't really Slackware anymore, then by the same token, GNOME without the requisite packages and versions GNOME ships isn't GNOME anymore either. Parity.

Yeah, and now Slackware has several packages that are definitely in "GNOME-space" and they got into Slackware because other smaller projects like XFCE started using that technology. Would it be appropriate to let a smaller, less used project screw up the functionality of larger, more useful ones? Definitely not. Are we checking those smaller things to see if the changes are breaking them? Definitely. This XFCE thing is so edge-case that I've only seen it manifest once (and I'm not even sure that's why XFCE stopped) a week after I was told about the GTK+ issue (I was using XFCE while building 2.20) and basically, that's the only time I've seen one of these tiny-release changes break anything.

I get it from hours upon hours of banging on packages, breaking them on purpose, monitoring IRC channels to watch for common failure scenarios, building different iterations of packages and comparing them, examining source code and sanity-checking patches, talking to developers, reading documentation, and monitoring web forums looking for reported problems.

The short of it again comes down to this, there is no way to make NetworkManager work without doing multiple things that are against the "Slackware philosophy" that people are following blindly--mindlessly even. This is not productive and is going to require people to change their mode of thinking and stop this ludicrously dogmatic approach to never touching anything in a system that, like all distributions, is not without it's flaws and shortcomings.

I'll even go so far as to the issues endemic to NetworkManager on Slackware and list them now, and I might actually leave one out because I'm not at the moment looking at the spiral notebook I scribble my notes in as I work on stuff.

1. dhcdbd expects that the dhclient package has been patched to support the -x option which allows dhclient to hand down vendor extentions used by the dhcp server. The patch to dhcp for this is a bit too cryptic for me to be 100% certain is not doing something unsafe, so I ditched it with 2.18/2.20, and dug around in dhcdbd until I found the hook the dhcdbd authors had put in there to allow it to be disabled (because basically, very few people are going to be needing that functionality, and those that are are hopefully going to be skilled enough to figure out where things are falling down, and rebuild both packages). You'll have to either a) patch and replace the dhcp package to make dhclient understand -x, or b) patch dhcdbd to make it not pass the rather optional -x flag because the hook they have doesn't appear to work. In the case of a) you get to be intrusive and replace a Slackware package, and in the case of b) you get to be intrusive and patch a vanilla source package (which is something Patrick is very strongly committed to not doing).

2. NetworkManager involves access to hardware, which means elevated privs are basically required, which means some extra level of access control is required. This is where dbus comes into the picture, because that's basically it's function. NetworkManager is using dhclient to get leases because reinventing the wheel and coming up with their own feature-complete DHCP client is not really a sane option for them at this stage (I'm not sure it's ever going to be a sane option, personally, but I have hope.) For it to do this, HAL needs to be able to communicate to NetworkManager to let it know when the signal gets lost (among other things) and NetworkManager needs to be able to inform the user of this as well as get information from the user about how and where to connect. For these things to happen, NetworkManager needs to hook into dhclient's exit script functionality because NetworkManager needs to be able to operate asynchronously from dhclient, which means stuff has to go into /etc/dhclient-exit-hooks (which is technically site-local scoped) or /sbin/dhclient-script above that (which is what was being done before). This brings us to more rather unlovely options: a) You get to break the site-local installations that make use of /etc/dhclient-exit-hooks, which can't be done cleanly without blowing away whatever the site-local admin has been doing with it (e.g. ddnsclient or VPN hackery), or b) you have to tamper with a file not "owned" by the NetworkManager package when you do the install, or c) you can pussyfoot around and attempt to check for existing files before deploying either of these changes, and get a package that completely breaks upon installation on a system where /etc/dhclient-exit-hooks has been used, etc etc.

I was fairly heavy-handed before with changing the dhcp package simply because (I'll remind) the Slackware one did not work at all, but just before 12.0 I managed to demonstrate to Patrick where and why it was breaking (the how of it's breaking was not something I expected so I had to really get aggressive to find it. Check the dhcp.SlackBuild script for exactly what that change was.) so that with 12.0 dhcp actually worked. I opted for patching dhcdbd to eliminate the use of -x and then calling a newer function added to the library of things DLG can stick into doinst.sh scripts to backup any existing /etc/dhclient-exit-hooks and replace it with one that calls all the scripts in /etc/dhclient-exit-hooks.d, which lets people have their cake and eat it, too.

WARNING: While copying the existing dhclient-exit-hooks script into the new .d directory, even using a quick md5sum invocation to examine it first may seem like a good idea, this has proven itself to be a fragile proposition and in this case could result in someone's deletion of a simple comment from the original file creating an endless loop which would be full of lose. (Yes, that's lolcatspeak.)

These are the types of adminly decisions one must necessarily make on a regular basis, and for it, you will get to see people who have no idea what's really going on call these things "intrusive" and that is just lame. This particular problem sucked up about 8 hours of development time in order for me to be comfortable with the solutions, and that's just on the latest release. I therefore am quite understandably short when it comes to people casually throwing around the word "intrusive" while simultaneously ignoring that they're about to be doing those very things they were calling other people's work "intrusive" for. Multiply that time by the number of places where the "pure vanilla" aspect of Slackware conflicts with a "plays well with others" approach (thank god for rc.sysvinit) that a few simple modifications could achieve, and you very quickly wind up heavily oversubscribed for your time. Don't fall in with the "intrusive" crowd without being very certain of what all the issues really are.

Final note: Yeah, WPA didn't work with NM for 2.18 (and probably 2.16 as well) because when I initially did the testing on it, I went the "Full Monty" and built every little thing it asked for. In testing, with the WPA dependencies populated it actually worked for both WPA and WEP. Since most of the WPA stuff had a lot of "dot-oh" things in it which make me very nervous (and oh look, those "third party dependencies" again) I just took a pass on doing them up for the formal release. I also don't have a simple way of testing the WPA stuff (I had to basically lock my Nintendo DS out of the home network for awhile to do it) which poses another problem of it's own. Hopefully this incredibly long post will fill just about anyone in on what they're going to have to be aware of if they're going to try to build NetworkManager for Slackware.

well i liked network manager because it was a good package . for some reason it wont compile on a stock slackware install. thats ok thanks to /etc/rc.d/rc.local i just added the commands i wanted to start up the wireless in there so i didnt have to .

Actually...what you are complaining about, I never have an issue with.

I drive a truck for a living in all lower 48 states. I run into all kinds of networks and hotspots everywhere, and have never had an issue connecting.

Why should I complicate a working setup? When I first install my wireless card/chip, I modify the config files, and never touch them again.

IT JUST WORKS.

I am always flying everywhere for vacation and business and what i found that works best is the wlassistant. very painless to use, the only problems i have had with it are that sometimes it doesn't connect on the first shot but always makes it on the second. Although you do have to use the sudo command to use it,but sudo can show some weird results while using it regarding the editing of the files needed and the iwlist, etc. However i would recommend it to anyone looking for a wifi connection app that has root access or Sudo access