Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable
Michael Nottebrock wrote: It's never too late to correct unfortunate decisions. :-) Such as putting packages in /usr/local/lib/ ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable
Michael Nottebrock wrote: Such as putting packages in /usr/local/lib/ ? I don't get it. Me neither -- the practice of putting entire packages in /usr/local/lib from the ports, such as Mozilla, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable
Joe Marcus Clarke wrote: On Sat, 2003-10-11 at 11:23, Michael Sierchio wrote: Michael Nottebrock wrote: Such as putting packages in /usr/local/lib/ ? I don't get it. Me neither -- the practice of putting entire packages in /usr/local/lib from the ports, such as Mozilla, etc. Mozilla doesn't go into /usr/local/lib. It installs into /usr/X11R6/lib/mozilla. Not on my planet. linux-mozilla (the native version hasn't been very compatible with java or other plugins) gets put in /usr/local/lib But /usr/X11R6/lib is just as busted -- thanks for making my point for me! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable
Joe Marcus Clarke wrote: What point? Okay, new rule: if you're going to complain about something, include some supporting details, and a suggestion on how to make things better. Point (I'll sharpen it) -- ../lib is for *what*? Libraries? Putting entire packages and executables in lib directories is a horrible kludge, at least as far as my *NIX experience goes (only back to 1979). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Encrypted filesystems
Peter B wrote: I have searched for encrypted filesystems for un*x. Is there any better encrypted filesystems than the ones I have found for *bsd (+freebsd)..? For per-file encryption, cryptfs/FiST is a good place to start. I'm looking for something convinient to enrypt cdrom's. Which will also suit dvd-r media. It should preferable be portable and not require specific kernel hacks. To ensure feature stability availability. Stackable virtual filesystems seem to be your friend. Which operating systems manage to effectivly to use encrypted swap..? That's quite a different problem -- Poul-Henning Kamp's done work in GEOM based disk encryption which is directly applicable to encrypting swap. Key management is always interesting. -- Well, Brahma said, even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred. - The Mahabharata ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi
Poul-Henning Kamp wrote: Yes, I can attest to this an I belive it is actually the case on both -current and -releng4 that disabling newreno improves TCP performance. I belive running an X11 application or scp(1) over a wavelan is a very good test-bed for this issue. Wireless breaks a lot of optimizations, doesn't it? Congestion control assumes that packet loss is due to congestion, and less than 1% of loss is due to damage -- quite the opposite of 802.11(b) in an urban environment -- cordless phones, microwaves, etc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brian T.Schellenberger wrote: The existance of this thread merely demonstrates that people don't make use the resources that are already out there. No, the existence of this thread demonstrates that the historical explanation is less than satisfying as an excuse for the broken nomenclature -- and that's why it keeps coming up. I realize that it's SOP some places to fix bugs by documenting them, but was hoping for something better here ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brooks Davis wrote: I'm sure you folks hashed this all over before, but really...calling a branch -stable when it really isn't is not good semantic practice IMNSHO. DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed over more times then are worth counting on various mailing lists which are fully archived. If you really care go read the flamewars there, don't start them on the list. The signal to noise ratio is bad enough without this junk. That's right, let's not make any mention of the pink hippo in the living room. The nomenclature is fup duck. It should be changed. Just because there's a historical explanation for abusing the language doesn't mean it should be perpetuated. Bad semantics could definitely be considered noise. -STABLE is unstable (or potentially so). -SECURITY (which isn't really a tag) is what most people think of when they lex the term stable. Squelching the insightful newcomer is the sign of disease. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
