less GNU
Since version 340 less has been released under a gnu license. Shouldn't less, lessecho, and lesskey be under src/gnu/usr.bin instead of where it is now (src/usr.bin)? --Peter pgpNHEERnqVb9.pgp Description: PGP signature
Re: less GNU
On Sun, Oct 08, 2006 at 07:29:42AM -0700, Peter Avalos wrote: Since version 340 less has been released under a gnu license. Shouldn't less, lessecho, and lesskey be under src/gnu/usr.bin instead of where it is now (src/usr.bin)? --Peter Guess it helps if you actually read the files...It can be distributed under either license, so nevermind the noise. Thanks Joerg! --Peter pgpcYY4LLtQBY.pgp Description: PGP signature
Re: KDE and SSL still not working
Petr Janda wrote: Ive just recompiled kdelibs3 after a couple of months but find out that SSL in KDE is still broken. Is it moving anywhere closer to be fixed? Petr I have already said that, but by chance do you have OpenOffice installed, and with it something like ssl-devel? Because for me this was the cause for SSL not working in KDE under FreeBSD. Remove this ssl-devel, this makes no difference for OpenOffice, and KDE suddenly works OK. -- Michel Talon
Re: Network Slowdowns?
Might add that we've been using 3com 905b on all our servers with good results. This is a reliable card + the bsd drivers have had a great support for this particular card. On 10/8/06, Freddie Cash [EMAIL PROTECTED] wrote: On Sat, October 7, 2006 3:19 am, Bill Hacker wrote: Jamie wrote: *SNIP* (all details already posted) (I use 3Com on all machines) Without digressing into decades of *why*, I can just about guarantee that replacing the offending card with almost-anything-else, from el-cheapo Realtek to Gig-E Intel, probable exception of anything-SiS, will cure the problem without further ado. [snip] We *always* replace 3Com on general principal when encountered, and at our own (not client) expense. Not about right or wrong, its about what works *always* and what doesn't always work. The time saved the past dozen years has been more than worth the very modest cost of replacement NIC's. Life is too short etc. Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) For Windows, Linux, and FreeBSD, the only NICs that we found to work well are 3Com 3C905B and 3C905C series NICs. D-Link, NetGEAR, RealTek, even a lot of Intel chipsets have given us grief in the past. Since standardising on 3Com, we haven't had any problems. Now we just need to find a good, solid, GigE chipset. Freddie Cash, LPCI-2 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Network Slowdowns?
On Sun, October 8, 2006 1:39 pm, Jonas Trollvik wrote: We *always* replace 3Com on general principal when encountered, and at our own (not client) expense. Not about right or wrong, its about what works *always* and what doesn't always work. Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) At a prior job I had, we'd buy large quantities of (mostly PCI) network cards and hand them out with cable modem installation, at probably the rate of 20-30 a week. We started with 3Com cards, and then switched to RealTek, because they were a third of the price, and (totally counter to my expectations) had half the Dead-On-Arrival rate of the 3Coms. The biggest Realtek issue was Windows driver quality.
Re: Network Slowdowns?
Freddie Cash wrote: Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) No doubt in an all-3Com environment it should do .. For Windows, Linux, and FreeBSD, the only NICs that we found to work well are 3Com 3C905B and 3C905C series NICs. That could be a major differentiator - Windows, how it drives and configures NIC's, and what that requires of other players. After a score of years 'in the barrel' we are down to just 4 legacy WinBoxen + one W2K 'server', and those only on their own internal LAN (Dell with onboard Intel NIC's). Everything else is now *BSD, OS/2-eCS, or OS X. D-Link, NetGEAR, RealTek, even a lot of Intel chipsets have given us grief in the past. Since standardising on 3Com, we haven't had any problems. Now we just need to find a good, solid, GigE chipset. Have had mixed results over time with Intel, scrapping-out 2 different generations of them - but current Gig-E are rock-solid for us. Unless, of course one has a 3Com+Win environment to adapt to? - in which case, 3Com, of course... ;-) But I still maintain that the problem in the original post is addressed best and cheapest by a NIC swapout - and to a different 'race', 'coz that means a device driver change as well. IF THEN: - the problem persists = experimentation by others is warranted (could be a MB bus timing problem, for instance) - the problem goes away = driver-coders may be interested, but it is *probably* not a kernel issue. Could *still* be a system-board/bus hardware/timing issue. Best, Bill..
Re: Network Slowdowns?
Justin C. Sherrill wrote: On Sun, October 8, 2006 1:39 pm, Jonas Trollvik wrote: We *always* replace 3Com on general principal when encountered, and at our own (not client) expense. Not about right or wrong, its about what works *always* and what doesn't always work. Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) At a prior job I had, we'd buy large quantities of (mostly PCI) network cards and hand them out with cable modem installation, at probably the rate of 20-30 a week. We started with 3Com cards, and then switched to RealTek, because they were a third of the price, and (totally counter to my expectations) had half the Dead-On-Arrival rate of the 3Coms. The biggest Realtek issue was Windows driver quality. The RealTek are a bit like the old 'Timex' watches. The design was so crude they had no *right* to work at all! But they were cheap and cheerful (chipset cost reputedly one Hong Kong dollar, i.e under 13 cents US) - so - some very determined folks wrote drivers for them that worked around the problems quite well, and NIC's dropped from US$200+ to HK$ 100, then less. My watchmakers told me, BTW, that the reason the Timex could 'take a licking and keep on ticking' was that the mainspring used to power them more properly belonged in a wall-clock, and was powerful enough to drive sandy gears and corroded bearings that would have stopped a Rolex cols. So, too the original RealTek when backed-up by a powerful CPU and fast RAM. The Intel 3Com NICs of similar vintage, OTOH, were capable of being fully functional, doing low-level handshaking, and looking for / providing netboot even if the CPU was 'hors de combat'. Bill
