Quote:
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.) Quote:
Quote:
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. |
Quote:
Quote:
Quote:
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. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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? |
Quote:
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. Quote:
Quote:
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 . |
Quote:
Cheers, psychicist |
Quote:
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. Quote:
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. Quote:
Quote:
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. Quote:
|
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.
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
Quote:
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. Quote:
Quote:
Quote:
Quote:
Quote:
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. |
Quote:
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. |
Quote:
...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. Quote:
"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. Quote:
Quote:
Quote:
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. Quote:
Quote:
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. Quote:
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
|
All times are GMT -5. The time now is 11:15 AM. |