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

Just to add some more pennies to the thread, I'd like to add my recent experiences with fedora 8 and slack 12.

Fedora 7 had network-manager and it worked well. However, in fedora 8 it is badly broken and for me it doesn't work with any encryption methods. I resorted to using wicd instead, a simpler python program that works fine.

Upon installing slackware again as a dual boot, I was at first worried about connecting to my house WEP network, so I tried installing wicd, but the gui doesn't want to work. So, I investigated the config files, edited one, ran an rc script and within 2 seconds saw the message "your ip address is ...". I didn't believe it could actually have worked so quickly and simmply. but it did.

Now all I've got to do is get WPA-Enterprise working too...

wicd
 

Try wicd
It's a network manager for Slackware
See:
http://slackbuilds.org/result/?searc...anager&sv=12.1

Since getting a wireless network card (and getting into wireless networks) I've used wpa_supplicant on Slackware and after the initial configuration using it has been pretty much painless. Configuring wpa_supplicant wasn't exactly difficult, but did take some time at first with a Broadcom card and ndiswrapper (before the native kernel module and fwcutter). However I think those who choose Slackware instead of, say, Fedora are already geared towards making some configuration changes themselves (directly into the configuration files) rather than always using point-and-click along with graphical-only tools. I don't carry my Slackware-loaded computer around, so I don't need to worry about wireless hotspots, but from what I've read wpa_supplicant should be capable of doing that sort of roaming too..so there you go, automation :)

On the other hand I use Ubuntu too, which means I'm using the NetworkManager (through nm-applet) with wireless networks. Works like a charm, and this new 0.7 version fixed an issue I had with older versions, so in short I like it very much -- eases up life. It needs to be configured (fill in passwords, perhaps keyring password, ...) at first just like wpa_supplicant, and after that you can pretty much forget it. But since it's so easy to use (partly because of that, at least) I have absolutely no idea how, or if it's even possible, to configure it if I don't happen to have X running, which is bad. I can't rely on having X at hand always, and sometimes I don't even want to run it -- but still need to get connected. I assume it can be configured/used even without X, but have no idea how to do it; that means it would take time to study the thing, which is exactly the opposite of what it was supposed to be (a thing so easy that you don't need to learn to configure). On the other hand wpa_supplicant is fairly straightforward to configure and once it's done, can be used directly, trough scripts, in command line or by clicking a nice icon on a graphical desktop ("icon" => script, launcher, link, ...)

So even though I absolutely agree that it's good to have options and that things shouldn't be so darn hard for a beginner, I think wpa_supplicant fits into Slackware way better than NetworkManager (even before we start to talk about dependencies, installation etc.) If you cared to take the time and install Slackware, configure the system and still used it, how come you woulnd't take the time to configure wpa_supplicant (or just install one of the fancy graphical KDE apps for that matter, if you liked KDE)?

Hello Everybody,

I want to point out that developing a package for NetworkManager is in fact very Slackware-like.

Slackware's approach has no problem with using GUIs or other methods to accomplish tasks without reverting to the command-line. From my experience with using Slackware, it is not as much interested in creating a specific operating system as is it in creating a structured base in which open source projects can be be used.

That is actually part of the beauty of Slackware. It completely understands its place in the Linux community as a distribution of open source projects and does not try to become yet another convoluted and bloated operating system, with buggy GUIs and non-standard overbearing packaging and directory structures, as some other Linux flavors turned into.

Accordingly, Slackware will not go out of its way to create GUIs and other niceties if they don't exist already in the Linux community. However, if a GUI is developed for network management or other applications (phpmyadmin, for example), there is nothing philosophically wrong with implementing it into Slackware.

Murdock