Re: Replacing GNU grep revisited
On Wed, Jun 25, 2003, Sean Farley wrote: On Wed, 25 Jun 2003, Christopher Weimann wrote: There is at least one aspect of freegrep that doesn't even come close to GNU grep, fgrep. I just added fgrep handling. It better be slower. :) At least it will now try a faster method on the patterns before hitting the regex library. It is still slow. I ran both of these more than once so it is not a fluke. After looking at it further it seems that freegrep does not use the Aho-Corasick algorithim for fgrep but just uses brute force. Yes, it uses brute force. I am considering either Aho-Corasick, Commentz-Walter (used in GNU fgrep) or the Boyer-Moore variation used in Glimpse and an older agrep. The last algorithm is supposedly the fastest, but I do not know if these algorithms are patent-free or not. Cool! I didn't realize you were so into this... The only good string matching algorithm I actually understand is KMP, but really smart people tell me Boyer-Moore is the fastest in the average case. It *can* be worse than KMP, depending on the input, but for nearly all inputs it supposedly works quite well. There shouldn't be any patent issues associated with it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Page Coloring Defines in vm_page.h
On Wed, Jun 25, 2003, David Gilbert wrote: Matthew == Matthew Dillon [EMAIL PROTECTED] writes: Matthew The primes are designed such that the page allocation Matthew code covers *ALL* the free lists in the array, so it will Matthew still be able to find any available free pages if its first Matthew choice(s) are empty. Matthew For example, prime number 3 an array size 8 will scan the Matthew array in the following order N = (N + PRIME) Matthew (ARRAY_SIZE_MASK). N = (N + 3) 7: Matthew 0 3 6 1 4 7 2 5 ... 0 Matthew As you can see, all the array entries are covered before Matthew the sequence repeats. So if we want a free page in array Matthew slot 0 but the only free pages available happen to be in Matthew array slot 5, the above algorithm is guarenteed to find it. Matthew Only certain prime number / power-of-2-array size Matthew combinations have this effect, but it is very easy to write a Matthew little program to test combinations and find the numbers best Matthew suited to your goals. For the mathematically inclined, 3 would be a 'generator' of the group. That's the part I already know. I want to know why 4 MB and 2 MB caches use primes less than 32, 1 MB caches use primes less than 16, 512K caches use a non-prime, and 256K caches use primes smaller than 8. The code refers to PQ_HASH_SIZE, which has never existed as far as I can tell... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
On Mon, 23 Jun 2003, Robert Watson wrote:
RW Can nodev also be added to all above + /usr?
RW
RW nodev prevents opening specfs character devices, but doesn't prevent
RW opening fifos or UNIX domain sockets, so is generally fine for all file
RW systems except /dev. The common exceptions I bump into are:
RW
RW (1) If you have per-user chroots, make sure wherever their custom /dev is
RW isn't nodev.
Maybe my experience would be useful for the community:
I've successfully use mfs under 4.x for chroot/jailed environment, created via
JDEV=/ar/J/j224/dev
mount_mfs -s 256 -i 768 -o nosuid /dev/ad0s1b ${JDEV} /dev/null 21
cd ${JDEV}
sh /dev/MAKEDEV std pty0
rm mem kmem pci io klog console
ln -sf null mem
ln -sf null kmem
ln -sf null console
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Virus Alert
The mail message (file: your_details.zip) you sent to [EMAIL PROTECTED] contains a virus. (on mailhub-3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Encrypted filesystems
I have searched for encrypted filesystems for un*x. Is there any better encrypted filesystems than the ones I have found for *bsd (+freebsd)..? Note that some comments are based on what others have said. I think it's important to keep in mind the different approches used, per-file vs disc-block aswell. 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. The encrypted filesystems arena looks like a collection of software rather than a unified solution across platforms. Which operating systems manage to effectivly to use encrypted swap..? Openbsd seems to handle it nativly, while freebsd could possible use vncrypt in conjuction with swapon, or cfsd with swapon-file. Netbsd might use cgd? Interesting encrypted filesystem projects The following is directly usable on freebsd: cfs 2 GB limit (nfsv2), easy portable vncrypt Unstable? (and needs kernel module) geom(4) Modular disk I/O request transformation framework The following seems usable althought might require some work: loop-aesOnly ported to linux so far http://sourceforge.net/projects/loop-aes/ cryptfs Port for freebsd available (btw, check out FiST!) http://www1.cs.columbia.edu/~ezk/research/cryptfs/index.html http://ftp.vit.edu.tw/pc/programming/hacktic/disk/ BestCrypt Source avail, 30day trial period. http://www.jetico.com/ Available, BUT not directly applicable: PPDDLinux specific, needs 100MHz+ pentium pgpdisk M$/win+Mac binary only http://mail.lab.net/lists/archive/cryptography-exploder/2003-February.txt PGPdisk + Linux ..? Janis Jagars, handle Disastry tcfsAlias cfs? (available for Linux,Netbsd,Openbsd) http://www.tcfs.it/ ncryptfs Follow up from cryptfs, not publicly released yet. http://www1.cs.columbia.edu/~ezk/research/ncryptfs/ncryptfs.html#sec:eval-feature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_create broken?
Julian Elischer wrote: Alternatively, the man page hints that a 'srcdir' would stop a following 'cwd' from having effect in the create phase. Just wanted to mention that order is extremely important with package creation. If you have @cwd /foo/bar; @srcdir /bar/foo your files will be picked up from /bar/foo. If you have @srcdir /bar/foo; @cwd /foo/bar your files will be picked up from /foo/bar. @cwd changes the directory pointer for both creation and extraction, and so if you have @cwd AFTER @srcdir the @srcdir command effectively gets over-written. An experiment using just @srcdir and @dstdir might be worthwhile... Cheers, DMK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_create broken?
Arrgh. Forget what I just wrote about a @dstdir option. My brain shortcircuited and I believed it actually existed. Cheers, DMK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_create broken?
On Thu, 26 Jun 2003, Dwayne MacKinnon wrote: Julian Elischer wrote: Alternatively, the man page hints that a 'srcdir' would stop a following 'cwd' from having effect in the create phase. Just wanted to mention that order is extremely important with package creation. If you have @cwd /foo/bar; @srcdir /bar/foo your files will be picked up from /bar/foo. If you have @srcdir /bar/foo; @cwd /foo/bar your files will be picked up from /foo/bar. @cwd changes the directory pointer for both creation and extraction, and so if you have @cwd AFTER @srcdir the @srcdir command effectively gets over-written. yes but if you have a @cwd followed by an @srcdir then tar gets told to chdir to both places and it quits with an error if the first one doesn't exist, even if it need not exist. An experiment using just @srcdir and @dstdir might be worthwhile... Cheers, DMK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: move cardbus container to pci devclass
First, CardBus is not PCI. It is a derivative of PCI that has its own, weird rules for configuring cards. Our current implementation doesn't follow all the weird rules, since most cardbus hardware is the same silicon as pci hardware. However, for attachment and such there likely needs to be a distinction. In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : I have made a patch for -CURRENT and 5.1-RELEASE that hopefully : improves the support for Cardbus devices by changing the cardbus : driver to implement the pci devclass rather than the cardbus : devclass, and to make their unit numbers correspond with the : PCI secondary bus numbers that their bridges are assigned. I both like and dislike this patch. It has advantages and disadvantages :-) : This has a number of advantages: : : - User mode tools that interface with the /dev/pci interface :such as pciconf and lspci (from ports) are now able to access :Cardbus devices without modifications. This is cool. There are other ways that this could be done. : - PCI drivers no longer need an additional driver declaration :in order to support cardbus, e.g., in : : ./pci/if_xl.c:DRIVER_MODULE(xl, cardbus, xl_driver, xl_devclass, 0, 0); : ./pci/if_xl.c:DRIVER_MODULE(xl, pci, xl_driver, xl_devclass, 0, 0); : :only the second line is required. (The first is harmless though.) I'm not sure this is a good idea. Cardbus is supposed to be configured in a different way than pci. The fact that we're able to get away with just looking at the vendor/subvendor fields means we're lucky. That violates the spec. Also, I've added the cardbus line whenever I've verified that the hardware exists in cardbus form and when I have some modest reason to expect it to work. : - Because the unit numbers in the pci devclass now represent :the PCI bus numbers in use in the system, we now have a good :way of assigning bus numbers to the Cardbus bridges in lieu :of the PCI BIOS doing so, which is not something we can expect :all BIOSes to do. (The old code incremented a static counter :starting from 2 by 3 every time this condition occurred, :which wasn't correct because there could already be a pci2 :in the system, and the counter would eventually recycle.) This is also cool. The current kludge we have is ugly, and has the problems you describe. : And a couple of potential drawbacks: : : - Drivers that need to behave differently for Cardbus devices :can't do so by declaring another driver_t specifically for :cardbus. (No driver that I'm aware of does this, however; :they all use the same driver_t.) None currently do, but some might need to in the future. While this could be supported with kobj returning errors in the raw pci case and no errors in the cardbus case, I think that would make for some icky attachment code. I'm torn on this issue a little. : - Users that are accustomed to newbus nameunits containing :descriptive information about devices may prefer to see, :for example, cardbus0 rather than pci2. This is a very useful distinction. It makes it a lot easier to say 'do this when a cardbus card attaches, but do that when a non-cardbus card attaches'. devd exposes this to the user now, and i'd prefer to keep this distinction. i don't mind if it is called cardbus2 rather than cardbus0 when the cardbus has a bus number of 2. I have a laptop that has a rl0 on pci0 and a rl1 on cardbus0. I'd like to continue to have devd able to do different thing to each one based on their location, not on the rl number. :Note that :using newbus in this way defeats a good deal of its :potential for object-oriented design. I don't understand this comment at all. : The patches are at : : http://users.erols.com/eaja/cardbus51.diff : http://users.erols.com/eaja/cardbuscurrent.diff : : Any comments? I think that these are patches that I can work with. However, it assumes that the bus number and the pci unit number are the same. This may be true on some machines, but definitely isn't true on all machines. We also need to reserve, like windows does, at least one additional bus per slot to deal with cards that have bridges on them (there are a few, including nasty things like cardbus to pci bridges so you can have 5 pci slots on your laptop). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA8235 + AD1980
Oleg Well done on working out a working fix for this problem and apologies for not answering the email you sent earlier. It was one of several lost in the inbox overflow whilst the recipient was busy elsewhere. I'm also going to be offline until until July 7th and won't be able to provide any further input for a little while. There are some comments inline below that may help. - Orion Oleg Sharoiko writes: | | There is a small problem with this patch: AC97_MIXEXT_SURROUND has | seprate mute bits for right and left channels and I don't see how | can they be implemented in FreeBSD. The gain setting method would need to check for whether the register was the AC97_MIXEXT_SURROUND and have a specific piece of code to deal with this case. | I'd like to get to the roots of this problem and this is where I | need some help. If I understood everything correctly than it happens | so that the sound somehow goes to surround dac. The question that I | cannot answer: why it goes to surround dac? Unfortunately I don't | have via8235 spec. Myabe data are being put into wrong timeslots? The driver was written from the VT8233 spec under NDA. The driver sets the AC97 slots for the multichannel register set - these are set with the macros SLOT3 and SLOT4. There are no documented registers for assigning the regular stereo playback channels to different slots. The behaviour you are describing would be partially explained if channel spreading were enabled in the codec (2 channels spread to 6). This can be manually and automatically enabled (AD1980 rev 0 specs pages 25 and 27). Since the AD1980 is an ac97 2.3 codec and these codecs do jack sense detection, it's probably worth checking out the ac97 2.3 spec and writing some code to find out what the jack sense registers report as attached. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replacing GNU grep revisited
On Wed 06/25/2003-11:43:50PM -0700, David Schultz wrote: The only good string matching algorithm I actually understand is KMP, but really smart people tell me Boyer-Moore is the fastest in the average case. It *can* be worse than KMP, depending on the input, but for nearly all inputs it supposedly works quite well. There shouldn't be any patent issues associated with it. Aho-Corasick and Commentz-Walter specifically deal with searching for multiple keywords which is really a different problem than searching for a single keyword like KMP or Boyer-Moore. Here is a neat applet that shows how AC works. http://www-sr.informatik.uni-tuebingen.de/~buehler/AC/AC.html -- Christopher Weimann http://www.k12usa.com K12USA.com Cool Tools for Schools! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Page Coloring Defines in vm_page.h
David Schultz wrote: On Wed, Jun 25, 2003, David Gilbert wrote: Matthew == Matthew Dillon [EMAIL PROTECTED] writes: Matthew The primes are designed such that the page allocation Matthew code covers *ALL* the free lists in the array, so it will Matthew still be able to find any available free pages if its first Matthew choice(s) are empty. Matthew For example, prime number 3 an array size 8 will scan the Matthew array in the following order N = (N + PRIME) Matthew (ARRAY_SIZE_MASK). N = (N + 3) 7: Matthew 0 3 6 1 4 7 2 5 ... 0 Matthew As you can see, all the array entries are covered before Matthew the sequence repeats. So if we want a free page in array Matthew slot 0 but the only free pages available happen to be in Matthew array slot 5, the above algorithm is guarenteed to find it. Matthew Only certain prime number / power-of-2-array size Matthew combinations have this effect, but it is very easy to write a Matthew little program to test combinations and find the numbers best Matthew suited to your goals. For the mathematically inclined, 3 would be a 'generator' of the group. That's the part I already know. I want to know why 4 MB and 2 MB caches use primes less than 32, 1 MB caches use primes less than 16, 512K caches use a non-prime, and 256K caches use primes smaller than 8. The code refers to PQ_HASH_SIZE, which has never existed as far as I can tell... Substitute PQ_L2_SIZE for PQ_HASH_SIZE in those comments. Going a step further, globally substituting PQ_COLORS for PQ_L2_SIZE would make sense. PQ_L2_SIZE is a misleading name. (Please consider this encouragement to commit such a change. :-)) Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
replacing sendmail with qmail
Hi guys, As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: replacing sendmail with qmail
At 09:47 25/06/2003 +0300, Alin-Adrian Anton wrote: As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). This topic has arisen many times in the past. Basically, it comes down to this: Every MTA has its supporters and detractors; FreeBSD needs to have an MTA; FreeBSD currently has Sendmail. It's simply not worth changing at the moment. If you want to use qmail, go ahead and install it from the ports tree. At some time in the distant future, when FreeBSD is fully packagized, it's quite likely that Sendmail will be just one of many installable options; but that time hasn't come yet. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: replacing sendmail with qmail
Alin-Adrian Anton writes: Hi guys, As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). Please look for this topic in the archives. It has been discussed VERY many times. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: replacing sendmail with qmail
It ends up as a religious war. There is no perfection in this world. Perhaps the next world. We use Qmail. But we use it because of vpopmail and our free email service at cybertouch.org. We used to use Sendmaail. It was great but at the time we could not find a solution to not having system accounts. Lanny Colin Percival said: At 09:47 25/06/2003 +0300, Alin-Adrian Anton wrote: As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). This topic has arisen many times in the past. Basically, it comes down to this: Every MTA has its supporters and detractors; FreeBSD needs to have an MTA; FreeBSD currently has Sendmail. It's simply not worth changing at the moment. If you want to use qmail, go ahead and install it from the ports tree. At some time in the distant future, when FreeBSD is fully packagized, it's quite likely that Sendmail will be just one of many installable options; but that time hasn't come yet. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~ Lanny Baron Proud to be 100% FreeBSD FreeBSD Systems, Inc / Freedom Technologies Corp. http://www.FreeBSDsystems.COM 1.877.963.1900 +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~ ___ [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]
