Re: SCO vs. Novell; Novell wins.
On 03/31/2010 11:37 PM, Jeffry Smith wrote: Well, Red Hat sued them, so they can't make that go away, and the main thing left in the IBM case is the IBM counterclaims. Whether they're liabilities or not (and they're major liabilities), the decision to stop them doesn't reside with TSCOG any more. I don't think either Red Hat or IBM are interested in settling. IBM could have bought TSCOG (which is probably what they wanted to begin with). I know that Red Hat did sue TSCOG, but right now, it is up to the bankruptcy court. Not sure what would happen to these suits if TSCOG were to go chapter 7. But, the IBM case is not just counterclaims, it is still the contract issue, and that has not been adjudicated. Now since the copyright issue has been resolved as well as the Novell royalty claims, IBM and or Red Hat could petition for a lifting of the stay. But there could be more interesting stuff. Remember that when Darth tried to sell TSCOG to to his buddies in the York Galaxy, the litigation would have been pursued by the buyer. And basically, the court has not ruled on the 3 derivatives that IBM contributed to Linux. IBM must prove that either the derivative clause itself does not apply or that it does not apply to SMP, NUMA, and JFS. In any case, we've essentially eliminated the SCO vs. Novell from the mix (unless by some idiocy, TSCOG decides to appeal). I think TSCOG should sue Kevin and Darl McBride :-) -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: SCO vs. Novell; Novell wins.
On Thu, Apr 1, 2010 at 4:11 PM, Jerry Feldman g...@blu.org wrote: On 03/31/2010 11:37 PM, Jeffry Smith wrote: Well, Red Hat sued them, so they can't make that go away, and the main thing left in the IBM case is the IBM counterclaims. Whether they're liabilities or not (and they're major liabilities), the decision to stop them doesn't reside with TSCOG any more. I don't think either Red Hat or IBM are interested in settling. IBM could have bought TSCOG (which is probably what they wanted to begin with). I know that Red Hat did sue TSCOG, but right now, it is up to the bankruptcy court. Not sure what would happen to these suits if TSCOG were to go chapter 7. But, the IBM case is not just counterclaims, it is still the contract issue, and that has not been adjudicated. Now since the copyright issue has been resolved as well as the Novell royalty claims, IBM and or Red Hat could petition for a lifting of the stay. But there could be more interesting stuff. Remember that when Darth tried to sell TSCOG to to his buddies in the York Galaxy, the litigation would have been pursued by the buyer. And basically, the court has not ruled on the 3 derivatives that IBM contributed to Linux. IBM must prove that either the derivative clause itself does not apply or that it does not apply to SMP, NUMA, and JFS. In any case, we've essentially eliminated the SCO vs. Novell from the mix (unless by some idiocy, TSCOG decides to appeal). I think TSCOG should sue Kevin and Darl McBride :-) I'll check Groklaw, but I don't see any sort of case now on those issues. All three are owned outright by IBM as the developer, USL/Novell explicitly denied thier rights over derivitive code, Novell (who owns the code according to this ruling), in accordance with the APA, explicitly waived prosecution of IBM,. Quick check - SCO is still claiming unfair competition, interference in contracts, and interference in business relationships, based on their last report on the case to the judge, after Judge Kimball ruled for Novell (which it looks like this is the jury trial confirming) - ref: http://groklaw.net/pdf/IBM-1079.pdf Of course, they have to prove those claims. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: SCO vs. Novell; Novell wins.
On 04/01/2010 09:08 AM, Jeffry Smith wrote: On Thu, Apr 1, 2010 at 4:11 PM, Jerry Feldman g...@blu.org wrote: On 03/31/2010 11:37 PM, Jeffry Smith wrote: Well, Red Hat sued them, so they can't make that go away, and the main thing left in the IBM case is the IBM counterclaims. Whether they're liabilities or not (and they're major liabilities), the decision to stop them doesn't reside with TSCOG any more. I don't think either Red Hat or IBM are interested in settling. IBM could have bought TSCOG (which is probably what they wanted to begin with). I know that Red Hat did sue TSCOG, but right now, it is up to the bankruptcy court. Not sure what would happen to these suits if TSCOG were to go chapter 7. But, the IBM case is not just counterclaims, it is still the contract issue, and that has not been adjudicated. Now since the copyright issue has been resolved as well as the Novell royalty claims, IBM and or Red Hat could petition for a lifting of the stay. But there could be more interesting stuff. Remember that when Darth tried to sell TSCOG to to his buddies in the York Galaxy, the litigation would have been pursued by the buyer. And basically, the court has not ruled on the 3 derivatives that IBM contributed to Linux. IBM must prove that either the derivative clause itself does not apply or that it does not apply to SMP, NUMA, and JFS. In any case, we've essentially eliminated the SCO vs. Novell from the mix (unless by some idiocy, TSCOG decides to appeal). I think TSCOG should sue Kevin and Darl McBride :-) Please reply to the listserv not me. I'll check Groklaw, but I don't see any sort of case now on those issues. All three are owned outright by IBM as the developer, USL/Novell explicitly denied thier rights over derivitive code, Novell (who owns the code according to this ruling), in accordance with the APA, explicitly waived prosecution of IBM,. Not entirely true. Novell waived the copyrights. TSOG still holds the contractual rights. While SMP, NUMA, and JFS were developed by IBM (and Sequent) under the strict terms of the original ATT contract these are considered derivative works. IBM needs to prove in court that the derivative clause does not apply. They signed their perpetual contract with ATT before ATT sold USL to Novell. This has not yet been adjudicated which is why I am including JFS which (IBM claims) was not part of AIX. Basically, while Novell owwns the copyrights to the Unix source code, TSCOG has the right to manage and sell licenses. This is what Santa Cruz bought from Novell. Quick check - SCO is still claiming unfair competition, interference in contracts, and interference in business relationships, based on their last report on the case to the judge, after Judge Kimball ruled for Novell (which it looks like this is the jury trial confirming) - ref: http://groklaw.net/pdf/IBM-1079.pdf Of course, they have to prove those claims. In any case, there are still some rulings left in the SCO vs. Novell case that are before Judge Stewart. -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: SCO vs. Novell; Novell wins.
Not entirely true. Novell waived the copyrights. TSOG still holds the contractual rights. While SMP, NUMA, and JFS were developed by IBM (and Sequent) under the strict terms of the original ATT contract these are considered derivative works. IBM needs to prove in court that the derivative clause does not apply. They signed their perpetual contract with ATT before ATT sold USL to Novell. This has not yet been adjudicated which is why I am including JFS which (IBM claims) was not part of AIX. Basically, while Novell owwns the copyrights to the Unix source code, TSCOG has the right to manage and sell licenses. This is what Santa Cruz bought from Novell. Actually, Novell has the right to waive those claims, not just the copyright. TSCOG is agent for Novell, not owner of the contract (that's why the contract says 100% to Novell, who remits a 5% fee to SCO) - TSCOG has ownership of code developed after the sale. Not the overall rights. Quick check - SCO is still claiming unfair competition, interference in contracts, and interference in business relationships, based on their last report on the case to the judge, after Judge Kimball ruled for Novell (which it looks like this is the jury trial confirming) - ref: http://groklaw.net/pdf/IBM-1079.pdf Of course, they have to prove those claims. In any case, there are still some rulings left in the SCO vs. Novell case that are before Judge Stewart. Agreed - we'll see how it goes. Of course, Darl's admission on the stand that they didn't need the copyrights to conduct Unix business should be pretty devastating to their case. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: SCO vs. Novell; Novell wins.
While SMP, NUMA, and JFS were developed by IBM (and Sequent) under the strict terms of the original ATT contract these are considered derivative works. IBM needs to prove in court that the derivative clause does not apply. They signed their perpetual contract with ATT before ATT sold USL to Novell. This has not yet been adjudicated which is why I am including JFS which (IBM claims) was not part of AIX. Basically, while Novell owwns the copyrights to the Unix source code, TSCOG has the right to manage and sell licenses. This is what Santa Cruz bought from Novell. 1. Only NUMA may not have the derivative clause - IBM DID have it, and the others are theirs. 2. IBM developed the linux JFS from theiir OS/2 JFS, which was a clean-room implementation of JFS. Despite what TSCOG claims, copyright does NOT cover methods and concepts. jeff ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
[GNHLUG] [DLSLUG-Announce] TONIGHT: An Open-Source Involvement Engine - DLSLUG Monthly Meeting - 2010-04-01
[no dinner rsvp's, so skipping it this month] *** Dartmouth-Lake Sunapee Linux User Group http://dlslug.org/ a chapter of GNHLUG - http://gnhlug.org *** The next regular monthly meeting of DLSLUG will be held: Thursday, April 1st, 7-9PM at: Dartmouth College, Haldeman 041 23 North Main Street, Hanover, NH All are welcome, free of charge. Agenda 7:00 Sign-in, networking 7:15 Introductory remarks 7:20 OpenHatch.org: An Open-Source Involvement Engine presented by Parker Phinney Parker Phinney (Dartmouth '12) has just returned to campus after spending the Winter working for the Philadelphia-based startup company OpenHatch.org. OpenHatch is an open source involvement engine--a community website that aims to make open source software development more approachable, friendly, and fun! Parker will talk about some specific areas where participating in open source seems less fun or less exciting, and the things that OpenHatch is doing to remedy them. He wants to hear YOUR feedback about what you think that open source is missing and what sorts of features you would like to see from a site like OpenHatch.org. Also, time permitting, Parker may talk about Pair Programming and the other Extreme Programming techniques that he learned about while working at OpenHatch. 8:50 New York Minute By popular request: bring your ideas, questions, advertisements, job offers/searches, etc., we'll go 'round the horn and make introductions and announcements. - Driving Directions Please see the website for links to driving directions. Refreshments We currently lack a refreshment sponsor. If you or your company would like to provide or sponsor refreshments, please get in touch. RSVP RSVP by replying to this e-mail so we can give any refreshment sponsor a count. Mailing Lists There are two primary mailman lists set up for DLSLUG, an Announce list and a Discuss list. Please sign up for the Announce list (moderated, low-volume) to stay apprised of the group's activities and the Discuss list (unmoderated) for group discussion. Links to the mailing lists are on the webpage. Tell Your Friends Please pass this announcement along to anyone else who may be interested. -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle ___ DLSLUG-Announce mailing list dlslug-annou...@dlslug.org http://dlslug.org/mailman/listinfo/dlslug-announce ___ gnhlug-announce mailing list gnhlug-annou...@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
April fools
We interrupt your regularly scheduled off-topic discussions to bring you this message: http://xkcd.com/ is awesome today. I have found several Easter eggs so far (without cheating). -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: April fools
On Thu, Apr 1, 2010 at 12:39 PM, Benjamin Scott dragonh...@gmail.com wrote: We interrupt your regularly scheduled off-topic discussions to bring you this message: http://xkcd.com/ is awesome today. I have found several Easter eggs so far (without cheating). I'm afraid to look. XKCD doesn't normally post on Thursdays. If I look is the joke on me? ;-) -- Tyson D Sawyer A strong conviction that something must be done is the parent of many bad measures. - Daniel Webster ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: April fools
On Thu, Apr 1, 2010 at 12:54 PM, Tyson Sawyer ty...@j3.org wrote: On Thu, Apr 1, 2010 at 12:39 PM, Benjamin Scott dragonh...@gmail.com wrote: We interrupt your regularly scheduled off-topic discussions to bring you this message: http://xkcd.com/ is awesome today. I have found several Easter eggs so far (without cheating). I'm afraid to look. XKCD doesn't normally post on Thursdays. If I look is the joke on me? ;-) OK. I looked. Its real. :-) -- Tyson D Sawyer A strong conviction that something must be done is the parent of many bad measures. - Daniel Webster ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: SCO vs. Novell; Novell wins.
On 04/01/2010 11:25 AM, Jeffry Smith wrote: Only NUMA may not have the derivative clause - IBM DID have it, and the others are theirs. 2. IBM developed the linux JFS from theiir OS/2 JFS, which was a clean-room implementation of JFS. Despite what TSCOG claims, copyright does NOT cover methods and concepts. While these facts might be true (and from what I have read are quite true), the lawsuit covers all 3. Essentially, the SCO vs. IBM case has not been adjudicated, regardless what IBM claims, it is up to the court. IBM has been claiming from day 1 that the derivative clause itself was waived by ATT. It comes down to contract law. And, while Novell currently owns the copyrights, TSOG retains the contract rights. This is why Microsoft and Sun went to TSOG, not to Novell. That was the other issue in Utah regarding the royalties that was resolved and not appealed. TSCOG issues and maintains the licenses, and must pay some of the royalties to Novell. -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
[GNHLUG] Vim - how to learn more - CentraLUG, April 5th
The April meeting of the Central New Hampshire Linux User Group, CentraLUG, will be on Monday, April 5th, at the New Hampshire Technical Institute's Library, Room 146, starting at 7 PM. Directions and details always available at http://www.centralug.org Ted will talk about Vim the text editor. Developed by Bram Moolenaar and originally released for the Amiga (on Fred Fish 591!)[1], Vim was based on the vi editor by Bill Joy (and he, in turn was inspired by ex, etcetera...). No expert, Ted will talk about what he's learned and where he learned it, resources that are out there to learn or enhance the basic functionality, and a demonstration of what he's learned so far and how far he has to go. We'll talk about resources you can use - websites, cheatsheets, videocasts, books - online and paper version, a really cool one-liner, add-ons and plugins and more! Beginners interested in learning about Vim are welcome. Experienced practitioners and experts are welcome to share their insights and suggestions on how to learn more. Emacs users are welcome to make constructive comments. As always. we will have a question and answer session, announcements, job openings, folks looking for jobs, and general camaraderie. Hope to see you there. [1] http://en.wikipedia.org/wiki/Vim_(text_editor) http://en.wikipedia.org/wiki/Vim_%28text_editor%29 -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ gnhlug-announce mailing list gnhlug-annou...@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
NFS stops responding
I've run out of clues (EBRAINTOOSMALL) trying to solve an NFS puzzle and could use some help getting unstuck. Analysis is awkward because the customers in question are trying to make what use they can of the machines even as these problems are ocurring around them, so reboots and other dramatic acts have to be scheduled well in advance. Symptoms: after approx 1 hour of apparently normal behavior, operations like 'df -k' or 'ls -l' hang for minutes at a time and then fail with I/O errors on any of the three machines when such operations refer to NFS mounted directories. At that point, doing this on all 3 machines: umount -f -l -a -t nfs ...followed by this: mount -a -t nfs ...on all 3 gets things unstuck for another hour. (?!?!) The 3 machines have NFS relationships thus: A mounts approx 6 directories from B (A-B) B mounts approx 6 directories from A (B-A) C mounts approx 6 directories from A (C-A) (same dirs as in B-A) C mounts approx 6 directories from B (C-B) (same dirs as in A-B) All systems are running x86_64 CentOS5.4 on HP xw8600 workstations connected via a Dell 2608 PowerConnect switch that's believed to be functioning properly. No jumbo packets. All MTUs are the standard 1500. I've tried specifying both UDP and TCP in the fstab lines. I've disabled selinux. The output of 'iptables -L' is: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination These commands: service nfs status ; service portmap status ...indicate nominal conditions (all expected daemons reported running) when things are working but also when things are b0rken. There wasn't anything very informative in /var/log/messages with the default debug levels but messages are now accumulating there at firehose rates because I enabled debug for everything, thus: for m in rpc nfs nfsd nlm; do rpcdebug -m $m -s all; done After machine A exhibited the problem I *think* I see evidence in /var/log/messages that the NFS client code has decided it never got a response from the server (B) to some NFS request, so it retransmits the request and (I think) it then concludes that the retransmitted request also went unanswered so the operation is errored out. I gathered some Enet traffic for Wireshark anlysis on both machines thus: dumpcap -i eth0 -w /tmp/`hostname`.pcap ...and viewed the client traffic with Wireshark, which (apparently) confirms that the client did indeed wait a while and then (apparently) retransmitted the NFS request. The weird thing is that Wireshark analysis of corresponding traffic on the server shows the first request coming in and being turned around immediately, then we later see the retransmitted request arrive and it, too, is promptly processed and the response goes out immediately. So, if I'm reading these tea leaves properly it's as if that lost the ability to recognize the reply to that request. [?!] But, then, how could it be that all 3 machines seem to get into this state at more or less the same time? and why would unmounting and remounting all NFS filesystems then fix it? Aaaiii!!! [ Unfortunately, this problem is only occuring at the one customer site and can't be reproduced in-house, so unless I can find a way to first sanitize the logs I may not be permitted to publish them here... -/ ] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: NFS stops responding
Oops. I wrote: So, if I'm reading these tea leaves properly it's as if that lost the ability to recognize the reply to that request. [?!] ...but meant to say, [...]it's as if that client lost the ability[...] But, then, how could it be that all 3 machines seem to get into this state at more or less the same time? and why would unmounting and remounting all NFS filesystems then fix it? Aaaiii!!! ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: NFS stops responding
Michael ODonnell michael.odonn...@comcast.net writes: Oops. I wrote: So, if I'm reading these tea leaves properly it's as if that lost the ability to recognize the reply to that request. [?!] ...but meant to say, [...]it's as if that client lost the ability[...] But, then, how could it be that all 3 machines seem to get into this state at more or less the same time? and why would unmounting and remounting all NFS filesystems then fix it? Aaaiii!!! I don't suppose things are breaking at about the same time all of the machines renew their DHCP leases, are they? -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
NFS stops responding
After machine A exhibited the problem I *think* I see evidence in /var/log/messages that the NFS client code has decided it never got a response from the server (B) to some NFS request, so it retransmits the request and (I think) it then concludes that the retransmitted request also went unanswered so the operation is errored out. So, you have a path client - switch - server (request) - file system - server (reply) - switch - client. And that's a simple setup. Add automount and NIS maps and then you'll have real fun. I gathered some Enet traffic for Wireshark anlysis on both machines thus: dumpcap -i eth0 -w /tmp/`hostname`.pcap ...and viewed the client traffic with Wireshark, which (apparently) confirms that the client did indeed wait a while and then (apparently) retransmitted the NFS request. The weird thing is that Wireshark analysis of corresponding traffic on the server shows the first request coming in and being turned around immediately, then we later see the retransmitted request arrive and it, too, is promptly processed and the response goes out immediately. So, if I'm reading these tea leaves properly it's as if that lost the ability to recognize the reply to that request. [?!] Sounds that way. I learned to hate network switches when I was doing GbE performance work with NFS. I also got a phone call at 2230 one Friday night before a blizzard about a customer with inscrutable NFS problem, ultimately traced to their new router they didn't think of telling me about. (And a panic in code that choked on malformed NFS packets which was actually helpful in fingering the router as the corrupter.) Oh, this problem. So you're seeing the replies leave the server. That's good, it means you're talking about a networking problem, not hung file systems or such stuff. It also means your subject line isn't quite right. That's okay, happens all the time, but do note the server _is_ responding. The packets are getting lost. The client isn't seeing the replies? Blame the router, blame the router! Except - take a closer look at those replies. In the IP protocol is the destination address the client? Look at the Ethernet protocol, is the destination address the router? If both are true, then the router must be seeing the replies, but isn't sending them on to the client. Where are they going? Check statistics in the router (if you can, another reason to hate routers). Check the ARP table in the router (if ... hate ...). My guess, and I'm getting really rusty on this, is perhaps some other system is using the clients IP address (fail - all 3 clients get lost? that's unlikely. Check routing tables if you can (... hate ...). Simplify, simplify, simplify. One challenging thing about chasing NFS problems with NFS is that oftentimes the problem is not NFS. However, NFS is often the dominant traffic source and people are surprised to see that telnet/ftp/ssh don't work either. You can't get much simpler than ping - start a ping from client - server. If you stop getting ping replies the same time you stop getting NFS replies, then don't worry about NFS. Fix ping. Routing tables. ARP tables. But, then, how could it be that all 3 machines seem to get into this state at more or less the same time? and why would unmounting and remounting all NFS filesystems then fix it? Aaaiii!!! If it is related to something like IP address reuse, it may be that by doing unmounts you stop the NFS traffic long enough for the clients to send out an ARP message stating they have the IP address and hence reclaim it. I'm skeptical that's the problem, but it might be related. Oh, it's still up - check out http://h30097.www3.hp.com/tipnfs.html I wrote that ages ago to keep people from pestering me with NFS problems that were not specific to NFS. Oh - another thing that can do you in. Verify that the IP messages and NFS messages are lengths that the recipient can understand. If one system uses jumbo frames and the other doesn't, things work just fine for small files and small directories and then something wedges because a message is too long. Same for NFS messages - I saw one case where the client said it wanted 64KB I/O, the server reported it could offer 64KB I/O, but the caching NFS system in the middle only handled up to 32 KB NFS messages. Bring bubble wrap to pop as needed. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
