Re: [Cooker] kernel 2.4.21-0.13 has no APM?
On Tuesday 15 July 2003 22:00, Ben Reser wrote: On Tue, Jul 15, 2003 at 01:22:01PM -0400, Gary Lawrence Murphy wrote: IBM reports that they find two orders of magnitude more bugs in an OS release within 30 days of a public release than in the /entire/ development QA period. That observation doesn't really fit your snapshot/beta/pre model. I'm gonna make the safe bet that IBM's data is based upon closed source operating systems where nobody except the few people IBM allows to beta test has access to the binaries let alone the source code to the OS. Cooker is a very different animal. There will of course always be bugs after a release but to suggest that twice as many bugs are found after the release as during the development process is just not accurate in this case. Not twice. two orders which i guess means 100 times more.
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
I'm hoping I missed something, but the apm-tools (apmd) tell me the 9.1 distro kernel does not include APM support -- is this correct? no. If so, does it mean I _must_ build a custom kernel for a laptop? it depends. For a start you may try to boot with acpi=off. -andrey
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Lawrence Murphy wrote: I'm hoping I missed something, but the apm-tools (apmd) tell me the 9.1 distro kernel Of course, this is the wrong list for this question ... - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/E8sFrJK6UGDSBKcRAuikAKC94sir21cQwd/MtbOtukLqF35I5QCgiu4Q oABImTKxi0bJCFP7AZUjmy0= =dmuZ -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Lawrence Murphy wrote: B == Buchan Milne [EMAIL PROTECTED] writes: B Gary Lawrence Murphy wrote: I'm hoping I missed something, but the apm-tools (apmd) tell me the 9.1 distro kernel B Of course, this is the wrong list for this question ... Even if we're building cooker with options incompatible with laptops? Well, asking on a list where more people run the affected kernel (2.4.21.0.13mdk or 2.4.21.0.18mdk) may help ensure the validity of your claim. FYI, my Thinkpad 600X runs either acpi or apm just fine on 2.4.21.0.13mdk (sorry, can't give definitive answers for other kernels, as I have so many installed on it now for other reasons). Maybe I'm mistaken. I thought the purpose of cooker was to ensure a consistent and robust distribution through massively parallel debugging under wide user circumstances -- unless there's good reason to believe this subsystem has changed, aren't the lessons of installing the just-prior release in unusual circumstance suitable topics for discussion? For example, does the cooker list not care if the pcmcia_cs *.conf files mistakenly assign prism2 wireless cards to hermes chipsets or that the prism2_cs module, according to Google search results on mandrake prism2_cs has _never_ been successfully configured? If you ask me, we'll never get a distro 'perfect', but it still makes us look bad if we include dysfunctional parts Of course it is all valid, but the points you are missing out are: 1)What relevance is a bug in the previous ditro to the next one if it's already fixed in cooker? 2)Cooker can't support people running a mix of a stable release and cooker So, if you are running full cooker, and you have problems, file a bug. If you are running 9.1, check first with another list (expert, a.o.l.m etc), and then file a bug for 9.1 (there is no official procedure for this though ... I think the current method is to abuse mandrakeexpert for this). If you are absolutely sure (ie it's a config file, and you have checked Mandrake's latest package in cvs) it's still applicable in cooker, then file a bug in bugzilla. For the kernel, and only the kernel, it may be valid to run the current cooker kernel (kernel-2.4.21.3mdk-1-1mdk) on 9.1, but you better be sure of your stuff if you do things this way. If it's any other package, rebuild it on your stable release, send any changes required to the maintainer, and hope he's interested in having the packages build on older releases (it is quite a bit of work). Sorry, but it's just too difficult to debug cross-release stuff, for instance there was someone who complained that libsmbclient packages were wrong (since it wanted him to install samba-common-2.2.7a-8mdk and uninstall libsmbclient0). But 2.2.7a-8mdk *is* only in 9.1, and in 9.1 there *is* no libsmbclient package. Having to track this down only to find what the user has done is simply a waste of time ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/FCGRrJK6UGDSBKcRAvp0AKCQxG/ptyvOiD7mKGpLPKohBZaoDQCgsnk1 wt5fA0XXNkB1QgkF2rwFzAA= =yCAj -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
B == Buchan Milne [EMAIL PROTECTED] writes: B Gary Lawrence Murphy wrote: I'm hoping I missed something, but the apm-tools (apmd) tell me the 9.1 distro kernel B Of course, this is the wrong list for this question ... Even if we're building cooker with options incompatible with laptops? Maybe I'm mistaken. I thought the purpose of cooker was to ensure a consistent and robust distribution through massively parallel debugging under wide user circumstances -- unless there's good reason to believe this subsystem has changed, aren't the lessons of installing the just-prior release in unusual circumstance suitable topics for discussion? For example, does the cooker list not care if the pcmcia_cs *.conf files mistakenly assign prism2 wireless cards to hermes chipsets or that the prism2_cs module, according to Google search results on mandrake prism2_cs has _never_ been successfully configured? If you ask me, we'll never get a distro 'perfect', but it still makes us look bad if we include dysfunctional parts Maybe no one can do anything about it (esp the prism2 issue), but if it's mentioned in the cooker, then at least the next random user who slams into the bug and asks Google, maybe they will find the cooker alert and realize it's an 'issue' -- 99% of the issues we see here every day never make it into the official 'errata' ;) Is it inappropriate to the future release to ensure we distribute packages compatible with the kernel we're including? In my case here, if APM _is_ disabled in the kernel, that's ok, but then the apmd kit being shipped with the cooker should be dropped because it's incompatible: If people can recompile their own kernel to gain APM support, you can be pretty certain they know how to download the apmd software; if APM _is_ included in the kernel, then maybe this issue points to an essential incompatibility with the kernel settings. The thing is, unless someone reports it, how will we know? Just my opinion of course ;) -- Gary Lawrence Murphy [EMAIL PROTECTED]: office voice/fax: 01 519 4222723 Business Advantage through Community Software - http://teledyn.com what I need is a job that doesn't interfere with my work -gary murphy
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
B == Buchan Milne [EMAIL PROTECTED] writes: B FYI, my Thinkpad 600X runs either acpi or apm just fine on B 2.4.21.0.13mdk (sorry, can't give definitive answers for other B kernels, as I have so many installed on it now for other B reasons). Good -- that's what I needed to know ;) B Of course it is all valid, but the points you are missing out B are: 1)What relevance is a bug in the previous ditro to the B next one if it's already fixed in cooker? ah, yes, but, that assumes it _is_ 'fixed' in the cooker. If we only depend on cooker-members to test the cooker, we're doomed, we've reduced our quality control to the same inadequate model used by proprietary software and we will fail to find most bugs. This gets back to Warly's comments about the bug-reports --- even if it's a bug being reported on 6.0 ... if we've been overlooking it for a dozen releases, that doesn't mean we shouldn't fix it, it means that someone finally found it. B 2)Cooker can't support people running a mix of a stable release B and cooker True; my question was if an option was off (which it could because it's an old technology) and you confirmed by your experience that it is not. _Now_ it becomes an installation issue ;) B ... If you are absolutely sure (ie it's a config file, and you B have checked Mandrake's latest package in cvs) it's still B applicable in cooker, then file a bug in bugzilla. I disagree; that model always leads to such bug-bloat, no one ever goes in because they have to wade through so much garbage. If someone reports an issue, our first responsibility is to ensure it's not a design problem with the cooker we'd just released as stable; if someone can confirm that it's not a flaw, then it becomes an install issue, an issue of educating the customer in how to properly configure an otherwise essentially correct distribution component. If these (volunteer) customer service reps cannot resolve the issue _then_ it's a bug and needs to be logged so it's not forgotten. if you reverse that process, dump everything in the bug-jar by default, the bug-jar becomes so muddied, you might as well be working on Mozilla ;) B Sorry, but it's just too difficult to debug cross-release B stuff, for instance there was someone who complained that B libsmbclient packages were wrong (since it wanted him to B install samba-common-2.2.7a-8mdk and uninstall B libsmbclient0). But 2.2.7a-8mdk *is* only in 9.1, and in 9.1 B there *is* no libsmbclient package. Having to track this down B only to find what the user has done is simply a waste of time Disagree with you there -- in this case, the proper customer education is not to throw their report away, but to have told them when they downloaded cooker RPMs that there may be problems; it is extremely useful for many people to have the option to pick from the cooker, I have clients who only use Mandrake because the cooker saved their skin _but_ as you point out, _our_ response to missing packages is so cryptic, it confuses those who have not been following the discussions. What the pre-install scripts of the samba-common needed to do was to _tell_ them what it wanted (fyi, Dykstra would fail anyone who used anthropomorphisms about computers such as feeding a computer data) The error was not with the user, but with the package, so his reporting the glitch to the cooker is a Good Thing -- you're under no obligation to help him, but as you illustrate above, the /story/ of the situation is generally instructive and belongs in the archives. -- Gary Lawrence Murphy [EMAIL PROTECTED]: office voice/fax: 01 519 4222723 Business Advantage through Community Software - http://teledyn.com what I need is a job that doesn't interfere with my work -gary murphy
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
On Tue, 2003-07-15 at 16:25, Gary Lawrence Murphy wrote: B == Buchan Milne [EMAIL PROTECTED] writes: B Gary Lawrence Murphy wrote: I'm hoping I missed something, but the apm-tools (apmd) tell me the 9.1 distro kernel B Of course, this is the wrong list for this question ... Even if we're building cooker with options incompatible with laptops? Maybe I'm mistaken. I thought the purpose of cooker was to ensure a consistent and robust distribution through massively parallel debugging under wide user circumstances -- unless there's good reason to believe this subsystem has changed, aren't the lessons of installing the just-prior release in unusual circumstance suitable topics for discussion? For example, does the cooker list not care if the pcmcia_cs *.conf files mistakenly assign prism2 wireless cards to hermes chipsets or that the prism2_cs module, according to Google search results on mandrake prism2_cs has _never_ been successfully configured? If you ask me, we'll never get a distro 'perfect', but it still makes us look bad if we include dysfunctional parts To add an on-list reply to the off-list replies I've sent Gary: using orinoco_cs by default is, IMHO, correct. It *does* support prism2 cards (it works with mine) and it's compliant with the kernel wireless specification, which wlan-ng isn't. It's quite simple to use wlan-ng, I've done it to compare with orinoco_cs. You just need to be sure to have the prism2-tools package installed. Is it inappropriate to the future release to ensure we distribute packages compatible with the kernel we're including? In my case here, if APM _is_ disabled in the kernel, that's ok, but then the apmd kit being shipped with the cooker should be dropped because it's incompatible: If people can recompile their own kernel to gain APM support, you can be pretty certain they know how to download the apmd software; if APM _is_ included in the kernel, then maybe this issue points to an essential incompatibility with the kernel settings. The thing is, unless someone reports it, how will we know? Well, you've reported two essentially invalid bugs, which isn't helping anyone much :). APM isn't disabled except when you enable ACPI, and this isn't just Mandrake, it's standard kernel behaviour. Plus the default on installation is for ACPI to be disabled (and thus for APM to be enabled). You can switch between the two either by adding and removing acpi=off to lilo.conf or, I believe, through one of the drak* tools. Associating prism2 cards with orinoco_cs by default is correct behaviour given the qualities of orinoco_cs vs. wlan-ng, and besides, merely comes from the stock pcmcia-cs config file. -- adamw
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Lawrence Murphy wrote: B Of course it is all valid, but the points you are missing out B are: 1)What relevance is a bug in the previous ditro to the B next one if it's already fixed in cooker? ah, yes, but, that assumes it _is_ 'fixed' in the cooker. If we only depend on cooker-members to test the cooker, we're doomed, That's why we have snapshots, betas, and pre-releases. we've reduced our quality control to the same inadequate model used by proprietary software and we will fail to find most bugs. This gets back to Warly's comments about the bug-reports --- even if it's a bug being reported on 6.0 ... if we've been overlooking it for a dozen releases, that doesn't mean we shouldn't fix it, it means that someone finally found it. But it could also mean it was fixed upstream before 6.1 was released, and it may take too much effort for someone else to replicate the problem, only to discover it is fixed. Instead, the reporting user could confirm it is still an issue on cooker/snapshot/beta/pre with much less effort. B 2)Cooker can't support people running a mix of a stable release B and cooker True; my question was if an option was off (which it could because it's an old technology) and you confirmed by your experience that it is not. _Now_ it becomes an installation issue ;) No, by default (ie, unless the user chose to use acpi by checking the box in the bootloader setup) it will use apm, by passing 'acpi=off' via lilo. There is an issue with drakboot automatically setting ACPI on *after* installation, if the user doesn't watch closely. I am not sure if this is fixed in cooker .. B ... If you are absolutely sure (ie it's a config file, and you B have checked Mandrake's latest package in cvs) it's still B applicable in cooker, then file a bug in bugzilla. I disagree; that model always leads to such bug-bloat, no one ever goes in because they have to wade through so much garbage. If someone reports an issue, our first responsibility is to ensure it's not a design problem with the cooker we'd just released as stable; if someone can confirm that it's not a flaw, then it becomes an install issue, an issue of educating the customer in how to properly configure an otherwise essentially correct distribution component. If these (volunteer) customer service reps cannot resolve the issue _then_ it's a bug and needs to be logged so it's not forgotten. And the current determination is that it was not a bug. Most people have problems *enabling* acpi! If acpi were enabled by default, we would have seen many more bug reports on 9.1 installation (from machines that would not boot with acpi enabled). B Sorry, but it's just too difficult to debug cross-release B stuff, for instance there was someone who complained that B libsmbclient packages were wrong (since it wanted him to B install samba-common-2.2.7a-8mdk and uninstall B libsmbclient0). But 2.2.7a-8mdk *is* only in 9.1, and in 9.1 B there *is* no libsmbclient package. Having to track this down B only to find what the user has done is simply a waste of time Disagree with you there -- in this case, the proper customer education is not to throw their report away, but to have told them when they downloaded cooker RPMs that there may be problems; No, the correct answer is don't use binary rpms from cooker on a stable release. Doing so is asking for trouble. It may work just after a stable release, but if it doesn't work, please don't waste the maintainers time filing a bug report, until you have either rebuilt the source package, or tried full cooker. it is extremely useful for many people to have the option to pick from the cooker And how much effort is it to rebuild the package? It yields better results in most cases. , I have clients who only use Mandrake because the cooker saved their skin _but_ as you point out, _our_ response to missing packages is so cryptic, it confuses those who have not been following the discussions. What the pre-install scripts of the samba-common needed to do was to _tell_ them what it wanted (fyi, Dykstra would fail anyone who used anthropomorphisms about computers such as feeding a computer data) The problem was that he wanted libsmbclient0-devel. There was never such a package in 9.1. So, he installed the cooker one, but it required libsmbclient.so.0, which in 9.1 was provided by samba-common. So, since he had a 9.1 source, and a cooker package, urpmi was wanting to install samba-common-2.2.7a-8mdk and libsmbclient0-2.2.8a-5mdk, which will not work (dependencies not met). The error was not with the user, but with the package, so his reporting the glitch to the cooker is a Good Thing -- you're under no obligation to help him, but as you illustrate above, the /story/ of the situation is generally instructive and belongs in the archives. There's
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
A == Adam Williamson [EMAIL PROTECTED] writes: A Well, you've reported two essentially invalid bugs, which isn't A helping anyone much :) You'd be surprised -- I get technical questions solved all the time by finding false positives. Diskspace for archives is cheap, especially compared to the alternative (long OT discussions like this ;) Second to not a bug answers, the next-best good sign of a non-bug is question is posted, but never answered which implies only one person found the trouble, thus likely a cruft conflict solveable by a re-install or delete of something. A Associating prism2 cards with orinoco_cs by default is correct A behaviour given the qualities of orinoco_cs vs. wlan-ng, and A besides, merely comes from the stock pcmcia-cs config file. -- Which, again, is good to have in the archives for future reference. Mailing lists like cooker are not transient things, they accummulate a searchable knowledge base, so it's to our advantage to have every possible variation of every question asked to trap the queries that come through the search engine. My opinion of course, but having been here in the cooker for 500+ messages a day since Mdk 6.0, in all that volume, I've never once seen a stupid question that shouldn't have been asked. -- Gary Lawrence Murphy [EMAIL PROTECTED]: office voice/fax: 01 519 4222723 Business Advantage through Community Software - http://teledyn.com what I need is a job that doesn't interfere with my work -gary murphy
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
B == Buchan Milne [EMAIL PROTECTED] writes: B That's why we have snapshots, betas, and pre-releases. So you're saying once it's cut, it's perfect? That's a bit much to believe. Let's just agree to disagree: I want Mandrake's distros to be maximally consistent and bug-free, and that means addressing overlooked bugs just as much as the one's a few dozen people might find. IBM reports that they find two orders of magnitude more bugs in an OS release within 30 days of a public release than in the /entire/ development QA period. That observation doesn't really fit your snapshot/beta/pre model. B But it could also mean it was fixed upstream before 6.1 was B released, and it may take too much effort for someone else to B replicate the problem, only to discover it is fixed. No one says it has to be checked. If only one person reports it, the maintainer might keep an eye on the situation, if two people report it, it's almost certainly at least a documentation bug. Every bug report is an opportunity, but we're volunteers here, we are under no obligation to open the door -- but I don't think we should shoo them away. B There is an issue with drakboot automatically setting ACPI on B *after* installation, if the user doesn't watch closely. I am B not sure if this is fixed in cooker .. Ah ... so it _is_ a cooker question after all :) B And the current determination is that it was not a bug. Didn't you contradict that determination one paragraph back when you asked me to file a bug report if the problem known to be in the cooker is still there? B No, the correct answer is don't use binary rpms from cooker on B a stable release. Doing so is asking for trouble. Don't agree. If I agreed, I'd use RH -- cooker is /transparent/ technology, it just has to be repeated (and has been repeated) that if you mix your versions, you take your chances But it's still good testing -- we've caught many RPMs where the dependency message was to the exact lib instead of the actual package, so when people come in asking for the lib by name, we know the RPM had a bug. B It may work just after a stable release, but if it doesn't B work, please don't waste the maintainers time filing a bug B report, until you have either rebuilt the source package, or B tried full cooker. You you don't want anyone but experienced developers debugging the distro? Ok ... -- Gary Lawrence Murphy [EMAIL PROTECTED]: office voice/fax: 01 519 4222723 Business Advantage through Community Software - http://teledyn.com what I need is a job that doesn't interfere with my work -gary murphy
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
On Tue, 2003-07-15 at 18:11, Gary Lawrence Murphy wrote: A == Adam Williamson [EMAIL PROTECTED] writes: A Well, you've reported two essentially invalid bugs, which isn't A helping anyone much :) You'd be surprised -- I get technical questions solved all the time by finding false positives. Diskspace for archives is cheap, especially compared to the alternative (long OT discussions like this ;) Second to not a bug answers, the next-best good sign of a non-bug is question is posted, but never answered which implies only one person found the trouble, thus likely a cruft conflict solveable by a re-install or delete of something. A Associating prism2 cards with orinoco_cs by default is correct A behaviour given the qualities of orinoco_cs vs. wlan-ng, and A besides, merely comes from the stock pcmcia-cs config file. -- Which, again, is good to have in the archives for future reference. Mailing lists like cooker are not transient things, they accummulate a searchable knowledge base, so it's to our advantage to have every possible variation of every question asked to trap the queries that come through the search engine. Well, you're rather shooting yourself in the foot there, as most of the information I'm writing is from the original Cooker ML discussion on the subject, which happened when someone pushed for wlan-ng to be properly implemented (we'd been packaging the modules without the necessary tools for them to actually *work* for quite a long time). An archive search should find the relevant stuff... -- adamw
Re: dealing with bug reports from stable releases (was Re: [Cooker]kernel 2.4.21-0.13 has no APM?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Lawrence Murphy wrote: B == Buchan Milne [EMAIL PROTECTED] writes: B Maybe now I can go back to spending my limited time fixing B *real* bugs in samba? I suppose -- people /still/ use Windows? Amazing ;) samba3 is a critical piece of software that will allow people to migrate from Window NT infrastructure to linux-based infrastructure, probably with about the same effort as migrating to AD, losing some features of AD at present, but with significant licensing savings. This (linux on the servers) will make it easier to migrate desktops to linux (since you can have a real NFS server for free). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/FFC9rJK6UGDSBKcRAt5iAJ4xTgGClPvHZ18mfAexdGTl8YdVRACeKnZM cbjmo/ASCUnppfxO3RbXQ4M= =MAiw -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
On Tue, Jul 15, 2003 at 01:22:01PM -0400, Gary Lawrence Murphy wrote: IBM reports that they find two orders of magnitude more bugs in an OS release within 30 days of a public release than in the /entire/ development QA period. That observation doesn't really fit your snapshot/beta/pre model. I'm gonna make the safe bet that IBM's data is based upon closed source operating systems where nobody except the few people IBM allows to beta test has access to the binaries let alone the source code to the OS. Cooker is a very different animal. There will of course always be bugs after a release but to suggest that twice as many bugs are found after the release as during the development process is just not accurate in this case. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What upsets me is not that you lied to me, but that from now on I can no longer believe you. -- Nietzsche
Re: dealing with bug reports from stable releases (was Re: [Cooker] kernel 2.4.21-0.13 has no APM?)
B == Buchan Milne [EMAIL PROTECTED] writes: B Maybe now I can go back to spending my limited time fixing B *real* bugs in samba? I suppose -- people /still/ use Windows? Amazing ;) -- Gary Lawrence Murphy [EMAIL PROTECTED]: office voice/fax: 01 519 4222723 Business Advantage through Community Software - http://teledyn.com what I need is a job that doesn't interfere with my work -gary murphy
Re: dealing with bug reports from stable releases (was Re: [Cooker] kernel 2.4.21-0.13 has no APM?)
On Tuesday 15 July 2003 12:02, Gary Lawrence Murphy wrote: I suppose -- people /still/ use Windows? Amazing ;) I'm sure Buchan will explain why samba is going to be necessary for Windows to finally die--but even after that happens, samba may well survive. SMB/CIFS, when done right, is a good filesharing system. The only real problem with it is that all of Microsoft's implementations so far stink--but samba 3 does not stink. Samba is not only useful for transitioning LANs from Windows to linux, it's also useful for all kinds of multi-platform LANs. I can't think of another filesharing system that runs on so many *nix platforms that doesn't block in the kernel on network reads, handles user-level shares easily (with nice GUIs, even), allows hierarchical networks, can use LDAP or various other techniques for authentication, etc. And that works on every version of Windows, and Mac OS X, and (with cheap add-on software) MacOS 9.
Re: dealing with bug reports from stable releases (was Re: [Cooker]kernel 2.4.21-0.13 has no APM?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Payn wrote: On Tuesday 15 July 2003 12:02, Gary Lawrence Murphy wrote: I suppose -- people /still/ use Windows? Amazing ;) I'm sure Buchan will explain why samba is going to be necessary for Windows to finally die-- # net rpc vampire ;-) (with some preparation). but even after that happens, samba may well survive. SMB/CIFS, when done right, is a good filesharing system. The only real problem with it is that all of Microsoft's implementations so far stink--but samba 3 does not stink. But, to be able to claim this, we would need the cifs filesystem driver in-kernel (which would give us symlinks and named pipes and potentially working chown/chmod etc across cifs mounts). Would also give us 2GB file support on cifs mounts. Samba is not only useful for transitioning LANs from Windows to linux, it's also useful for all kinds of multi-platform LANs. I can't think of another filesharing system that runs on so many *nix platforms that doesn't block in the kernel on network reads, handles user-level shares easily (with nice GUIs, even), allows hierarchical networks, can use LDAP or various other techniques for authentication, etc. And that works on every version of Windows, and Mac OS X, and (with cheap add-on software) MacOS 9. The fact that samba is a great implementation, and that MS OS's are ubiquitous has nothing to do with SMB/CIFS being a good protocol ;-). NFSv4 or OpenAFS etc may be better solutions. BTW, we hardly use user shares anymore, since we implemented a really reliable (currently Mandrake 9.0/samba-2.2.8a with ldap) file server, and migrated all data there, and made provision for automatically creating/cleaning directories for people to temporarily share data. Very few users now have rights to create shares, and files are easier to locate, and all backed up (amanda) and all accessible to us linux users without having to resort to smbfs (nfs). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/FGWlrJK6UGDSBKcRApCgAKCJqwoXqjp79+fQY4pe92JO0ODJmQCgikGz jTnqIKMqfzuxRNrECSWuRhE= =mKx1 -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] kernel 2.4.21-0.13 has no APM?
B It may work just after a stable release, but if it doesn't B work, please don't waste the maintainers time filing a bug B report, until you have either rebuilt the source package, or B tried full cooker. You you don't want anyone but experienced developers debugging the distro? Ok ... Well, someone not skilled will be able to help, of course, as all FS project ( translation, and so on ), but, really, most of the time a beginner cannot really help with coding. and debugging a distro is about coding. if this si simple , people use bot, or add features to rpmlint. mdk tried to accept bug report from everybody before, and they losed too much time with useless bug report. son now, bugzilla requires a login, which seems to stop simple useless bug report ( 'kde don't work' ). for 1 begginner able to help , you have 10 making developers lose time. sorry, this is not worth. -- Mickaël Scherer
