Guild Wars certainly gives you the adrenaline rush a FPS game, although it is closer to a MMORPG than to a FPS. And no, you don't need to accumulate stuff, you just create a PvP char, unlock skills and you're ready to jump into action...
Errr. I bought a USB 2.0 disk yesterday, and to my disppointment, FreeBSD doesn't support USB 2.0 very well. man ehci(the USB 2.0 controller driver) says that the driver is currently buggy and does not build by default.
I tried everything, even turning off debugging and SMP and recompiled the kernel. It helps a bit, but it still feels sluggish. I will wait until -RELEASE comes out, and if the proformance is still not whre it should be then I'll start seriously looking at the alternatives...
My experiences with USB on FreeBSD is very positive. I tried three different digital cameras and two external disks, mouse etc. and everything was autodetected, although I never tried a USB 2.0 mass storage device. The best thing to do is try out it yourself.
Am I the only one that feels that FreeBSD 5.X has gone in the wrong direction?
I run FreeBSD 5.X on my desktop since I don't feel it's ready to replace the production servers running happily with 4.X; and 5.X and the desktop feels very sluggish and slow in many areas compared to 4.X.
Maybe 5.X is faster on SMP, but on uniprocessor I think it's definitely a set-back compared to 4.X.
I feel FreeBSD 5.x is not yet ready, even it's almost 2 years late based on the original predictions(5.X-STABLE at least).
I don't want to start a flamewar, it's just that I cannot get rid of this bad aftertaste that 5.X left me with.
I really really hope FreeBSD improves over time - it was a fine OS. Meantime DragonFlyBSD is something to keep an eye on... it sounds promising, although only time will tell...
Studying Computer Science without the knowledge of programming is like studying Physics wihout the knowledge of math.
How are you supposed to know the machine if you don't know how it works? People that know how to use few specific applications or know how to write HTML or XML don't deserve a PHD.
It's like being a mechanic who knows how to drive a car, but doesn't know how to fix the engine...
Yes, I found that after carefully inspecting fatal(), but I still don't see why this generated so much hype. If there is an exploit out there, I bet it's not in this piece of the code so ssh remains vulnerable...
The buffer->alloc field is not accessed in xrealloc() or in fatal() so I don't see how this patch fixes anything? Either this is not the correct fix or the bug is vapour. I still have to find evidence of an exploit or at least some reference to where the affected code could be... or maybe I'm just missing something - can somebody with more low-level ssh knowledge enlighten me?
The buffer->alloc field is not accessed in xrealloc() or in fatal() so I don't see how this patch fixes anything? Either this is not the correct fix or the bug is vapour. I still have to find evidence of an exploit or at least some reference to where the affected code could be... or maybe I'm just missing something - can somebody with more low-level ssh knowledge enlighten me?
Well, ssh is not multi-threaded and there is no way another process can write to that region(that would be classified as a kernel bug in any case) unless the buffer is in a shared memory, which is not. fatal() runs few cleanup handlers(which do not touch that buffer in any way) and exits with exit code 255, so fatal() is pretty much fatal.
I still have to find evidence of the exploit besides few mails with absolutely no technical detals. More and more I think this is some kind of hoax... and I can understand why everybody is so jumpy, afterall ssh is a crucial part of a "secure" box.
I don't see how this fixes any problem... The code is practically identical, or am I missing something? What's the big deal in calculating the new size in a separate variable? Maybe this is sime kind of DOS attack, not a remote exploit....
Slashdot Mirror
Guild Wars certainly gives you the adrenaline rush a FPS game, although it is closer to a MMORPG than to a FPS. And no, you don't need to accumulate stuff, you just create a PvP char, unlock skills and you're ready to jump into action...
Errr. I bought a USB 2.0 disk yesterday, and to my disppointment, FreeBSD doesn't support USB 2.0 very well. man ehci(the USB 2.0 controller driver) says that the driver is currently buggy and does not build by default.
Well, actually it's X + KDE.
Yes, that's the first thing I tried.
I tried disabling both debugging and SMP, and it helped, but still seems FBSD 4.X is still MUCH faster on the desktop and UP system.
Also note, that these is just the "feel" of the desktop. I did not perform any serious benchmarks and other things, so it is 100% subjective.
I was not talking about SMP, I was specifically referring to uniprocessor performance. I also clearly stated that I do not know about SMP performance.
I tried everything, even turning off debugging and SMP and recompiled the kernel. It helps a bit, but it still feels sluggish. I will wait until -RELEASE comes out, and if the proformance is still not whre it should be then I'll start seriously looking at the alternatives ...
My experiences with USB on FreeBSD is very positive. I tried three different digital cameras and two external disks, mouse etc. and everything was autodetected, although I never tried a USB 2.0 mass storage device. The best thing to do is try out it yourself.
Yes, this is going to be -STABLE. Work on 6.X has already begun on the -CURRENT branch.
Am I the only one that feels that FreeBSD 5.X has gone in the wrong direction?
... it sounds promising, although only time will tell...
I run FreeBSD 5.X on my desktop since I don't feel it's ready to replace the production servers running happily with 4.X; and 5.X and the desktop feels very sluggish and slow in many areas compared to 4.X.
Maybe 5.X is faster on SMP, but on uniprocessor I think it's definitely a set-back compared to 4.X.
I feel FreeBSD 5.x is not yet ready, even it's almost 2 years late based on the original predictions(5.X-STABLE at least).
I don't want to start a flamewar, it's just that I cannot get rid of this bad aftertaste that 5.X left me with.
I really really hope FreeBSD improves over time - it was a fine OS. Meantime DragonFlyBSD is something to keep an eye on
Studying Computer Science without the knowledge of programming is like studying Physics wihout the knowledge of math.
...
How are you supposed to know the machine if you don't know how it works? People that know how to use few specific applications or know how to write HTML or XML don't deserve a PHD.
It's like being a mechanic who knows how to drive a car, but doesn't know how to fix the engine
Yes, ...
I found that after carefully inspecting fatal(), but I still don't see why this generated so much hype. If there is an exploit out there, I bet it's not in this piece of the code so ssh remains vulnerable
AFAIK ssh is not multi-threaded. If this was the case, the structure should be at least mutexed.
The buffer->alloc field is not accessed in xrealloc() or in fatal() so I don't see how this patch fixes anything? Either this is not the correct fix or the bug is vapour. I still have to find evidence of an exploit or at least some reference to where the affected code could be... or maybe I'm just missing something - can somebody with more low-level ssh knowledge enlighten me?
The buffer->alloc field is not accessed in xrealloc() or in fatal() so I don't see how this patch fixes anything? Either this is not the correct fix or the bug is vapour. I still have to find evidence of an exploit or at least some reference to where the affected code could be... or maybe I'm just missing something - can somebody with more low-level ssh knowledge enlighten me?
Well, ssh is not multi-threaded and there is no way another process can write to that region(that would be classified as a kernel bug in any case) unless the buffer is in a shared memory, which is not. fatal() runs few cleanup handlers(which do not touch that buffer in any way) and exits with exit code 255, so fatal() is pretty much fatal.
I still have to find evidence of the exploit besides few mails with absolutely no technical detals. More and more I think this is some kind of hoax... and I can understand why everybody is so jumpy, afterall ssh is a crucial part of a "secure" box.
http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/o penssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h
... The code is practically identical, or am I missing something? What's the big deal in calculating the new size in a separate variable? Maybe this is sime kind of DOS attack, not a remote exploit....
I don't see how this fixes any problem