Benchmark: NetBSD 2.0 beats FreeBSD 5.3
Fellow FreeBSD developers, I hate to say I told you but it was inevitable. Check this out: http://www.feyrer.de/NetBSD/gmcgarry/ As I predicted more than a year ago FreeBSD 5.3 has finally lost its only advantage: performance. NetBSD 2.0 shows that when you write code the right way and end up with SOLUTIONS AND NOT HACKS you have a system that works, and works well on all platforms. This is the consequence of a series of mistakes made by the FreeBSD developers, the most important being too arrogant and selfish to listen to Matt Dillon, the man that warned you all about this. What did he get in return? An expulsion from your gentlemen club. Poul-Henning Kamp has been using FreeBSD to push his personal agenda, with completely useless features such as GEOM and devfs, instead of concentrating on the real problem. The fact that your heavily mutexed system doesn't work and never will. Jeff Roberson's ULE is still broken but don't worry, Matt Dillon will be hacking a much better scheduler for DragonFly that you can later borrow. Mike Smith warned you about committee-designed code years ago, why don't you listen? Why do you insist on this arrogant pose and on treating potential contributors like pariahs? Why do you tolerate assholes like Dag-Erling and Poul-Henning? I hope you can learn something from the NetBSD people before it's too late for FreeBSD. They managed to do much more with less resources. You should feel ashamed of yourselves. Sincerely, Robert PS: if I've offended anyone (yeah, I singled a few out) , prove me wrong, but spare me your insultedness. It's become a pathetic hobby in -core. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
Please don't treat this seriously. Benchmarks are just benchmarks. But the benchmarks and comparison, widespreaded through sites like slashdot or osnews, sometimes affect the interest and view point of some new and potential users. May be we should do some full benchmarks as an answer and to review the true status of our 5.x, 4.x and others? On Thu, 6 Jan 2005, Martin P. Hellwig wrote: cut troll PS: if I've offended anyone (yeah, I singled a few out) , prove me wrong, but spare me your insultedness. It's become a pathetic hobby in -core. Benchmark are made to be put into perspective, although everybody has a right to say what he wants to say, this doesn't mean that you have to say it. It seems to me that FreeBSD is focusing it performance onto MP 64bit processors. As we can see in the benchmark it has in comparison to other projects a negative impact on UP system. But just put it in the perspective of processor developments, AMD (followed by Intel) is heading towards a multi-core 64 bit systems, what probably becomes mainstream at the end of next year. With this technology the FreeBSD model could have winner on there hands. Doing the same job but not having the same philosophy on it, is always inefficient, but in the real world it leads to the Darwin effect. What means that the best solution gets there chance of survival against the test of time. Luckily these are all BSD's, good solution will spread, just take a look at PF. OpenBSD has a good user base but not compatible to the sum of user base of the other BSD's. Still PF has spread there wings beyond the user base of OpenBSD. FreeBSD is just a name for an OS, if any other OS can give me more bang for the buck and provides a full solution, I will use it. Be it DragonFly/Free/Open/Net, MacOsX, GNU+Linux, Windows or any of the other hundreds of OS'es out there. I like the BSD license so I will tend to stick to gratis BSD OS'es. All of the disagreements in development is a healthy process to make sure the sort BSD an not the specie *BSD will survive. Sure I have my disappointments about some decision, but hey so is live, this ain't a fan club for next biggest boy band (he he BSD-Boyz), where using an OS to provide solution for our technologic problems, you favor your solution but don't blind yourself. And when you don't blind yourself you re-evaluate your situation and move forward with the best solution for your problem. Sure it is a pain to migrate my boxes to another OS (well that is the fun part) and do some massive rewriting of my documentation, but thats my job and I tend to like it. Just standing still and not progress has its attractiveness when you had a very rough ride, but it gets dull very soon and then you find yourself back on the dirty tracks. But these are my opinion only, however I like to share them ;-) Martin P. Hellwig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] - With best regards, |The Power to Serve Nguyen Tam Chinh| http://www.FreeBSD.org Loc: sp.cs.msu.ru | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Changes to /usr/src/sbin/md5.c
Hello list. I made some changes to md5(1) wich adds a new feature for comparing inputfiles e.g: [EMAIL PROTECTED] md5]$ ./md5 -c md5 md5.o md5.c md5 MD5 (md5) = 9d99179604174013a053b67a5c6fb3cd [TEST CASE] MD5 (md5.o) = e8458dfaa035ea49a3704384ca044a73 [DID NOT MATCH] MD5 (md5.c) = 3ebe0b8646640b14d7af1a92fe6b7607 [DID NOT MATCH] MD5 (md5) = 9d99179604174013a053b67a5c6fb3cd [MATCH] Attaced is diff ( created with diff -crN, as is show in the diff(1) man page, if this is not the desired format please advies) Any comments, commits or something or other ? -- Thordur I. [EMAIL PROTECTED] FreeBSD - Unix the way *I* like it. A man can do as he will, but not will as he will. Þessi póstur var sendur með vefpósti mi, http://www.mi.is md5.c.diff Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
write retry on filesystem
Hi,
I have a pseudo disk driver that does a copy on write to a log device.
I want to disable further retries to write if the disk space on the log
device is full. I have inserted the following code into the strategy routine
For this I have set the error code and also set the resid to zero,
thinking that the filesystem above will not retry the operation because it
assumes that there are no more bytes to be written (since I set resid to
0). However, control keeps coming back to this code, suggesting that the
FS (buffer cache) is constantly retrying the operation. Is there any other
way to do this (maybe I should try a different error code. I tried ENOSPC
too).
The reason I want to disable retry is to allow the user to manually
select and delete logs to reclaim space and then do the file operation
again if he chooses to. The problem arising is because the buffer cache is
asynchronously flushed to disk (which could be much after a vfs file write
operation). So the application has no way of knowing that a write to disk
failed because COW failed due to log device space shortage. So the syncer
periodically keeps trying to flush the buffer cache to disk because every
time the strategy routine (in my driver which is between the buffer cache
and the disk) cannot complete the operation.
Any suggestions on how I can accomplish this? Any suggested hack in
vfs_bio?
Thanks,
Sid.
strategy ()
{
.
if (failed 0) /* no more free space on log device */
{
printf (No more space on disk! Copy on write failed\n);
bp-b_error = EACCES;
bp-b_flags |= B_ERROR;
bp-b_resid = 0;
devstat_end_transaction_buf(ss-device_stats, bp);
biodone(bp);
return;
}
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
cut troll PS: if I've offended anyone (yeah, I singled a few out) , prove me wrong, but spare me your insultedness. It's become a pathetic hobby in -core. Benchmark are made to be put into perspective, although everybody has a right to say what he wants to say, this doesn't mean that you have to say it. It seems to me that FreeBSD is focusing it performance onto MP 64bit processors. As we can see in the benchmark it has in comparison to other projects a negative impact on UP system. But just put it in the perspective of processor developments, AMD (followed by Intel) is heading towards a multi-core 64 bit systems, what probably becomes mainstream at the end of next year. With this technology the FreeBSD model could have winner on there hands. Doing the same job but not having the same philosophy on it, is always inefficient, but in the real world it leads to the Darwin effect. What means that the best solution gets there chance of survival against the test of time. Luckily these are all BSD's, good solution will spread, just take a look at PF. OpenBSD has a good user base but not compatible to the sum of user base of the other BSD's. Still PF has spread there wings beyond the user base of OpenBSD. FreeBSD is just a name for an OS, if any other OS can give me more bang for the buck and provides a full solution, I will use it. Be it DragonFly/Free/Open/Net, MacOsX, GNU+Linux, Windows or any of the other hundreds of OS'es out there. I like the BSD license so I will tend to stick to gratis BSD OS'es. All of the disagreements in development is a healthy process to make sure the sort BSD an not the specie *BSD will survive. Sure I have my disappointments about some decision, but hey so is live, this ain't a fan club for next biggest boy band (he he BSD-Boyz), where using an OS to provide solution for our technologic problems, you favor your solution but don't blind yourself. And when you don't blind yourself you re-evaluate your situation and move forward with the best solution for your problem. Sure it is a pain to migrate my boxes to another OS (well that is the fun part) and do some massive rewriting of my documentation, but thats my job and I tend to like it. Just standing still and not progress has its attractiveness when you had a very rough ride, but it gets dull very soon and then you find yourself back on the dirty tracks. But these are my opinion only, however I like to share them ;-) Martin P. Hellwig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
Nguyen Tam Chinh wrote: Please don't treat this seriously. Benchmarks are just benchmarks. But the benchmarks and comparison, widespreaded through sites like slashdot or osnews, sometimes affect the interest and view point of some new and potential users. May be we should do some full benchmarks as an answer and to review the true status of our 5.x, 4.x and others? cut True, I don't take it very seriously but it does say something, like all things you measure it shoul be put into perspective. I have already contacted the author of the benchmark, in short I've asked him if he could do the test with latest stable DragonFly too. I don't see the logic in testing FBSD4 as this is a Legacy branch, just as stated on www.FreeBSD.org But perhaps the test should be redone on multiple popular role based hardware configuration, including OpenBSD, DragonFly and any other OS you wish to test. Roles based in the meaning of benchmarking typical firewall, webserver, database, file and print servers roles. But there other things that must be benchmarked too if you want a near objective view, like stability, hardware support, security and design. Personally I don't give a * about performance as long as it doesn't hold me back, but what I do find irritating is that when there is a security issue in a port I should have to rebuild all my ports because of some libthreading issue. Now when talking about a few home boxes this is not a problem, but in a productivity environment with dozen machines having all its specific adaption on configuration and ports, thing get to start ugly. Of course this problem is not a real challenge it is just an inconvenience if you did not expected it. Just like installing a MS patch on the server and finding out that all shared HP printer don't work anymore ;-) Aah well keeps me off the street and out of trouble. -- mph ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freeze when using atapicam
On Wed, Jan 05, 2005 at 09:26:00PM +0100, Olivier Certner wrote: + Hello all, + + Would someone have the time to look at my previous post dated January 4th, + 15:43 GMT on the freebsd-questions mailing list? (I haven't read you post on questions@, but...) I've a hang on boot when I use atapicam with my DVD-RW. With CD-ROM everything is ok. I'm able to boot and work without any problems on my DVD-RW only with atapi DMA turned off in /boot/loader.conf: hw.ata.atapi_dma=0 -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpioiOgvunDB.pgp Description: PGP signature
GNUstep and libkvm
For the last couple of days i have been looking into why the gnustep-gui-port actually Needs procfs mounted in order to successfully build and i managed to track the problem down to being inside libkvm. I am however no kernel hacker and my gdb-skills have left me hanging at a point where i simply can't manage to actually debug the libkvm code itself. (NSProcessInfo is compiled using libkvm instead of the procfs code) If somebody could have a closer look at this for me ... or provide me some more details on how i can go about actually getting gdb to let me debug Inside libkvm so i can gather some additional details that would be highly appreciated. The actual nature of the problem turns out to be the following however: GNUstep apparently uses a gcc-extension to load certain code before the program actually reaches its main() function ... it uses this to allow GNUstep's NSProcessInfo class to gather a program's environment and commandline arguments before its main() routine gets a chance at potentially clobering this information. The function that does this +[NSProcessInfo load] is in itself straight C, so you shouldn't need any actual Objective-C knowledge. (+[NSProcessInfo load] means the class-method load (indicated by the +) of class NSProcessInfo) The following URL is a link to the relevant revision in gnustep's cvs-tree of the NSProcessInfo class [ http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSProcessInfo.m?rev=1.101content-type=text/vnd.viewcvs-markup ] The function-call inside the load-method that actually triggers the /proc groveling seems to be kvm_getargv (at line 406). According to the kvm_getprocs, kvm_getargv and kvm_getenvv only kvm_getenvv depends on a working /proc ... however from my own observations both kvm_getenvv and kvm_argvv return the result of kvm_doargv() ... which under certain conditions seems to call kvm_uread() which in turn is responsible for the observed /proc groveling. What i have been able to establish for any GNUstep-application so far is that the second the size of its command + length of its argument list (not including the whitespace between command and start of argument list) exceeds 242 bytes ... the /proc groveling occurs ... which most likely means the conditional under which kvm_uread is invoked is met. As long as the size of command + argumentlist remains below (or equals) this 242 byte threshold .. everything works as expected. The reason the gnustep-gui port triggers this error is because it tries to build documentation on default (it gets REINPLACEd from no to yes) ... and since the commandline required to perform this action Obviously exceeds this 242 character threshold .. experiences the problem described above. I guess to sum it all up it all boils down to the following question. Is it intended that kvm_getargv() apparently has a conditional under which it depends on the existince of a working /proc .. even though the manpage states this condition is only present for kvm_getenvv ? And if kvm_getargv should not depend on /proc ... how can we go about to fixing this as this is apprently only the case for short commandlines in our current implementation. With Kind Regards, Pascal Hofstee P.S.: This is as experienced on a recent 6.0-CURRENT system .. though the problem is Known to exist on 5.x as well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
On Thu, Jan 06, 2005 at 11:57:26AM +, Robert Ryan wrote: I hate to say I told you but it was inevitable. I think so Brain, but I don't think Netcraft has confirmed it yet? -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GNUstep and libkvm
On Fri, 7 Jan 2005 05:19:52 +, Christian S.J. Peron [EMAIL PROTECTED] wrote: iirc, kvm_getargv() can (and does first) use a sysctl to retrieve it's data. kvm_getenvv() requires procfs because /proc/pid/mem is currently the more simpler to read a virtual memory address in the context of the process. We are looking at implementing a similar mechanism to the argv ps_strings for process environment to get rid of the procfs requirement. pjd has some work done on this but it has not been committed yet. Hope this answers your question. Well .. i noticed that kvm_getargv indeed only seems to use /proc in case that apparently the commandline argument list grows beyond a certain size, as i have been able to establish by trial and error. I guess my question is .. is kvm_getargv INTENDED to use the /proc aproach in cases the command + argument list grows beyond a certain size. Because if that IS the case .. the manpage doesn't reflect this. -- With kind regards, Pascal Hofstee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
