Re: [vox-tech] Upgrading Perl in Debian
On Mon, Mar 01, 2004 at 08:07:43PM -0800, Richard S. Crawford wrote: > My Debian installation has Perl version 5.6; I'd like to upgrade to > 5.8. Is there a super-easy way to do that (apt-get doesn't seem to be > doing it)? Or a less than thoroughly painful way, at least? It depends on what your /etc/apt/sources.list says... you are probably using "stable" or "woody". At this point Debian testing is being frozen for the next stable release... most major changes are over with (X11 4.3 is still expected to land in testing before the final changes). So at this point I think it's getting safe for most people to switch to testing. If you want to do this, edit the sources.list change all "stable" or "woody" words to "testing"... comment out security... you should get a file that looks something like the following: === # deb file:///usr/src/apt/ ./ # deb http://security.debian.org/debian/ testing main contrib non-free deb http://http.us.debian.org/debian/ testing main contrib non-free deb http://non-us.debian.org/non-US/ testing/non-US main contrib non-free # deb-src http://http.us.debian.org/debian/ testing main contrib # non-free # deb-src http://non-us.debian.org/non-US/ testing/non-US main contrib # non-free === then run "apt-get update", "apt-get dist-upgrade". This process is medium-risk, you will get the new perl, but new everything else too. There are ways to just get the new perl and things it depends on from testing, or compile the perl in testing against the stable system... they are just more complex to explain and lower risk. If you don't feel upto using testing... as for one of these. Keep in mind if you mess up perl, there are quite alot of other things that will break. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
On Mon, Mar 01, 2004 at 11:33:03AM -0800, Robert G. Scofield wrote: > On Monday 01 March 2004 06:28, Peter Jay Salzman wrote: > > the fact of the matter is, nobody was really happy with xfree86 before > > this happened. they were extremely slow, secretive, and seemingly > > rejected patches in a passive-aggresive way (the cygwin xfree86 issue). > > it's just that they haven't been viewed as "evil" up until now. many > > forks have been started, and they've all stalled. > > I don't understand the big picture. How can the XFree project get away with > upsetting so many people? If Red Hat, Debian, Mandrake, SuSe, OpenBSD, etc. > get upset and start looking for alternatives, where does that leave the XFree > project? Why is it not the case the XFree project needs to depend on making > everyone happy? On Mon, Mar 01, 2004 at 12:05:12PM -0800, Bill Kendrick wrote: > But, noone's stopping them from living in their 'own little world,' > while everyone else moves on with a forked version. On Mon, Mar 01, 2004 at 07:30:03PM -0800, Mark K. Kim wrote: > 1. There are too many X-based programs to simply "switch over" to another >GUI platform. Mark, As Bill pointed out, the upset people just have to take the 4.4.0rc2 source base (which was the last one with the old license), and make a fork... pickup from that point is very simple compared to coming up with a new graphic infrastructure standard. Bob, I am a little confused about what was in the minds of whoever decided to do this... it seems like there wasn't much public discussion. They also do not seem to be backing off very quickly. It seems the X11 client libraries are exempted from this license change, but it's unclear if this includes everything that could be a problem. Pete, I hope a fork of X would do wonders, like EGCS fork did for gcc... but with that said the old X11 has made some pretty impressive changes in the last 3 years. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Upgrading Perl in Debian
My Debian installation has Perl version 5.6; I'd like to upgrade to 5.8. Is there a super-easy way to do that (apt-get doesn't seem to be doing it)? Or a less than thoroughly painful way, at least? -- Slainte, Richard S. Crawford AIM: Buffalo2K / Y!: rscrawford http://www.mossroot.com http://www.stonegoose.com "It is only with our heart that we can see clearly. What is essential is invisible to the eye." --Antoine de Saint Exupery ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
On Mon, 1 Mar 2004, Robert G. Scofield wrote: > I don't understand the big picture. How can the XFree project get away with > upsetting so many people? If Red Hat, Debian, Mandrake, SuSe, OpenBSD, etc. > get upset and start looking for alternatives, where does that leave the XFree > project? Why is it not the case the XFree project needs to depend on making > everyone happy? Hence the reason everyone is so upset. > Also, it seems like SuSE (Novell) and its friend IBM, and GNOME's friends like > Sun and HP have a whole lot of resources. Can't they come up with a an > alternative? 1. There are too many X-based programs to simply "switch over" to another GUI platform. 2. Even giants like IBM, Sun, and HP take time to create something new. 3. There *are* alternatives already, like Freedesktop.org, but it'll take time to take root to become the next standard. I expect the XFree86 group to change their new license again to something more palatable within a few months. If not, I expect another XFree86-compatible project (Freedesktop.org, most likely) to take over its place. But I'd think the former is more likely to happen than the latter. -Mark -- Mark K. Kim AIM: markus kimius Homepage: http://www.cbreak.org/ Xanga: http://www.xanga.com/vindaci Friendster: http://www.friendster.com/user.jsp?id=13046 PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE PGP key available on the homepage ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] (no subject)
A discussion on vox just made me realize that my ATI Rage 128 Pro card has 3D acceleration that is supported on Linux (I never was able to make it work without crashing). I tried out TuxRacer, but the screen is all garbled (the menu is unreadable), and it spits out a lot of r128UploadTexImages: upload texture failure on local texture heaps, sz=349568 r128UploadTexImages: upload texture failure on local texture heaps, sz=349568 r128UploadTexImages: upload texture failure on local texture heaps, sz=174816 errors into my xterm. (enough of these to fill my 1500 line scrollback buffer within seconds) Does anyone have any idea what's wrong? -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. My key was last signed 10/14/2003. If you use GPG *please* see me about signing the key. * My computer can't give you viruses by email. *** ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
On Mon, Mar 01, 2004 at 11:33:03AM -0800, Robert G. Scofield wrote: > I don't understand the big picture. How can the XFree project get away with > upsetting so many people? I don't think there's any TECHNICAL reason why they can't. ;^) Based on what little I know and have read about it (mostly here), it really does seem like a foolish move, though. But, noone's stopping them from living in their 'own little world,' while everyone else moves on with a forked version. > Also, it seems like SuSE (Novell) and its friend IBM, and GNOME's friends > like Sun and HP have a whole lot of resources. Can't they come up with a > an alternative? Sure! It will be interesting to see what they say about this situation, if anything... -bill! (addicted to Debian and KDE 3.2) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
On Monday 01 March 2004 06:28, Peter Jay Salzman wrote: > > > > the fact of the matter is, nobody was really happy with xfree86 before > this happened. they were extremely slow, secretive, and seemingly > rejected patches in a passive-aggresive way (the cygwin xfree86 issue). > it's just that they haven't been viewed as "evil" up until now. many > forks have been started, and they've all stalled. I don't understand the big picture. How can the XFree project get away with upsetting so many people? If Red Hat, Debian, Mandrake, SuSe, OpenBSD, etc. get upset and start looking for alternatives, where does that leave the XFree project? Why is it not the case the XFree project needs to depend on making everyone happy? Also, it seems like SuSE (Novell) and its friend IBM, and GNOME's friends like Sun and HP have a whole lot of resources. Can't they come up with a an alternative? Bob ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Very slow TCP transfer over loopback
On Sun, Feb 29, 2004 at 11:43:31PM -0800, Matt Roper wrote: > On Sun, Feb 29, 2004 at 08:56:42PM -0500, Mike Simons wrote: > > pps: if you move the RCVBUF setting to change the "accept_sock" > > instead of the "file", then the problem goes away regardless > > of what size. > > Hmm, I didn't think it was possible to change the RCVBUF and SNDBUF > settings after you had already accepted the connection. I just checked > the tcp(7) manpage, and it contains the following: > > "On individual connections, the socket buffer size must be set prior > to the listen() or connect() calls in order to have it take > effect." [...] > So I think you want to move the RCVBUF setting up to where you set the > REUSEADDR option. Yes, thanks for pointing that out, older man pages do not have that phrase. I agree that it should be done once before accept instead of after every single accept. Unfortunately the new man page is wrong. Changing the buffer size with SO_RCVBUF or SO_SNDBUF does have "an effect" after a socket is accepted. > Unfortunately I'm not sure why this would cause the > delays you're experiencing; that sounds almost like something to do with > the Nagle Algorithm (although that's a sending issue, not a receiving > issue). Err nope, Nagle should not be causing this sort of behavior. Nagle basicly says ... if you can't send a full TCP frame and you have any outstanding sends that have not yet been ACK'd, then wait until the ACK arrives. Both of those conditions fail in this case, there are many full frames worth of data available to send... and there is no outstanding data to ack. === RFC1122 TRANSPORT LAYER -- TCP October 1989 Internet Engineering Task Force[Page 98] DISCUSSION: The Nagle algorithm is generally as follows: If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the sending TCP buffers all user data (regardless of the PSH bit), until the outstanding data has been acknowledged or until the TCP can send a full-sized segment (Eff.snd.MSS bytes; see Section 4.2.2.6). === Right around the paste above in rfc1122 they describe a "senders Silly Window Syndrome avoidance algorithm"... this looks like it could be the reason. The Max(SND.WND) was 16k... right at the beginning of the connection. The D is big 64k or more... (as seen in netstat) lots to send. The U is small 1.5k (in the trace provided), but depends on what RCVBUF was reduced to. I don't know what Fs is in linux, but it appears to be 1/3rd (based on observation). I don't know what Timeout is, but it appears to be .2 seconds. === 4.2.3.4 When to Send Data A TCP MUST include a SWS avoidance algorithm in the sender. [...] IMPLEMENTATION: The sender's SWS avoidance algorithm is more difficult than the receivers's, because the sender does not know (directly) the receiver's total buffer space RCV.BUFF. An approach which has been found to work well is for the sender to calculate Max(SND.WND), the maximum send window it has seen so far on the connection, and to use this value as an estimate of RCV.BUFF. Unfortunately, this can only be an estimate; the receiver may at any time reduce the size of RCV.BUFF. To avoid a resulting deadlock, it is necessary to have a timeout to force transmission of data, overriding the SWS avoidance algorithm. In practice, this timeout should seldom occur. [...] Send data [only if]: [...] (3) or if at least a fraction Fs of the maximum window can be sent, i.e., if: [SND.NXT = SND.UNA and] min(D.U) >= Fs * Max(SND.WND); (4) or if data is PUSHed and the override timeout occurs. Here Fs is a fraction whose recommended value is 1/2. The override timeout should be in the range 0.1 - 1.0 seconds. It may be convenient to combine this timer with the timer used to probe zero windows (Section 4.2.2.17). Finally, note that the SWS avoidance algorithm just specified is to be used instead of the sender-side algorithm contained in [TCP:5]. === It appears to be a combination of the Really Big loopback MTU (16k), The application lowering RCVBUF after accept instead of before, and this senders side SWS which are leading to the problem. ___ vox-tech mailing list [E
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
Quoting Peter Jay Salzman ([EMAIL PROTECTED]): [very cogent and valuable explanation of problems resulting from the new XFree86 1.1 licence] > the good news (i think) is that only the client xfree86 libraries have > the new 1.1 license change. the server does not. _So far._ It's not very reassuring that the licensing change happened suddenly and without them consulting with anyone. I think most people's concern is that the camel's nose is in the tent. -- Cheers, Everything is gone; Rick Moen Your life's work has been destroyed. [EMAIL PROTECTED] Squeeze trigger (yes/no)? -- David Carlson (winner, haiku error message contest) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] XFree86 4.4.0 non-GPL compatible
On Mon 01 Mar 04, 12:19 AM, Mike Simons <[EMAIL PROTECTED]> said: > On Sun, Feb 29, 2004 at 07:35:23PM -0800, Ken Bloom wrote: > > On 2004.02.29 18:32, Mike Simons wrote: > > >On Fri, Feb 27, 2004 at 07:18:38PM -0800, Jim Lowman wrote: > > >Xfree86 4.4.0 does have support for the Radeon 9800 video card... > > >however it seems that XFree86 recently (Jan 29) decided to change the > > >license on the X server to be GPL incompatible. Depending on how > > >the various distributions deal with with this it may take a while for > > >that card to work in most distros. > > > > > >http://xfree86.org/legal/licenses.html > > >=== > > >What about GPL-compatibility? > > > > > >The 1.1 license is not GPL-compatible. To avoid new issues with > > >application programs that may be licensed under the GPL, the 1.1 licence > > >is not being applied to client side libraries. > > >=== > > > > How exactly does GPL incompatibility cause a problem for the distros? > > Well the old license was GPL compatible. > > If there are any parts of the distribution that the non-GPL X server portions > run time link with GPL'd code then distributions would not be able to continue > shipping both the new X server and that GPL'd thing. ken, mike was in a hurry, and that sentence didn't parse well. :-) the problem is when code (forget about GNOME and KDE. we're talking about anything that puts a window on your screen) links to xfree86 libraries shipped under the 1.1 license. the problem is that when your GPL code statically links with something, it produces a "derived work". under the terms of the GPL, that derivative work must be GPL. however, when you statically link to the new X libraries under the 1.1 license, there's an advertising clause that is GPL incompatible. therefore, when you link against X 4.4 libraries, the resulting work MUST be GPL because of the terms of the GPL. but it CAN'T be GPL because of the terms of the X library. that's the problem. furthermore, the FSF has ruled that dynamically linking to a library also produces a derivative work, so the problem exists whether you statically link or dynamically link. this is really, really bad. a project the size and complexity of the X server and libraries is not something you want to fork. unless a good chunk of the developers move to the fork, this will be crippling for awhile. the fact of the matter is, nobody was really happy with xfree86 before this happened. they were extremely slow, secretive, and seemingly rejected patches in a passive-aggresive way (the cygwin xfree86 issue). it's just that they haven't been viewed as "evil" up until now. many forks have been started, and they've all stalled. people have started to talk about new projects like freedesktop.org. i believe it will be a long while until we see something useful and new out of them. this ain't exactly like hacking a new openGL infrastructure for doom... unfortunately, X 4.4 looks really good. i've read that it autodetects so much that in some cases, you don't even need an XF86Config file. suh-weet! the good news (i think) is that only the client xfree86 libraries have the new 1.1 license change. the server does not. most distros have the X libraries as a different package than the xserver. i *believe* that all will be good, at least in the short run, if they update the server to 4.4, but leave the libraries at 4.3. of course we don't want to have different versioning on the server and libraries forever, but until the forks get a chance to rally and start pumping out stuff we can use, it might be a good short term fix. unfortunately, i read that brandon robinson (sp?) refuses to put 4.4 anything into debian. i believe the 4.4 server should be fine, but perhaps there are issues i'm not aware of. at least, i'm fairly sure the server doesn't have the new license. maybe i'm wrong... pete > There's also some recent evidence that GPL compatibility is important > from one project that's tried to go from GPL-compatible to > GPL-incompatible: XFree86. The XFree86 project has historically led > development of a popular X server, and traditionally the vast majority > of its code used the simple "MIT/X" open source license that is > GPL-compatible. The XFree86 president, David Dawes, decided to change > the XFree86 license to one that isn't GPL-compatible, primarily to give > developers more credit. This proposed license change caused a serious > uproar. Jim Gettys, a well-respected developer, strongly opposed this > change to the XFree86 license, even though he's not a strong advocate of > the GPL. Richard Stallman asked that something be worked out. An article > at Linux Today and a discussion at Freedesktop.org show that Red Hat, > Debian, SuSE, Gentoo, Mandrake, and OpenBSD plan to drop XFree86 if they > switch to this new license. [...] > At this point it's not clear what will happen, but I think it's very > likely that the license will change (again) or the project will be for
