A pthread in unix shares the virtual address space with the other threads spawned by the same process. Which appears to be how you defined a "team." So I am left to assume from your post that normal BeOS threads do not share address spaces with other threads in the same process. UNIX also has this facility. They are called "processes." If you mean something else, please elaborate.
This is one of those examples where the GPL really helps Linux. It allows SGI to port the OS without having to deal with Be, Inc. Much more importantly, since I'm sure Be would be delighted to have SGI port Be, is that SGI needs to keep control over their platform's OS. With Linux, they can always just fork the tree if Linus does something detrimental to their product.
Personally, I'd rather see a firm real time system be integrated. If you're doing something that requires hard real-time, patching a kernel isn't a problem, however many "desktop" apps could benefit from universal firm realtime. Perhaps.5 to 1 ms scheduling with about 250 ps of latency.
You don't understand DRI. It lets your app talk directly to the hardware, the X server is not directly involved. The main overhead with DRI is the memory usage of the X server (which is not nearly as bad as people seem to think. Keep in mind that the server is mmapping the WHOLE video memory into its address space, so if you have a 16 meg TNT, it makes X look HUGE, when it is in fact merely large). As for D3D, at least when I was writing apps with it, the overhead was horrible, because of those damn execute buffers. Then John Carmack saved the gaming world from the abomination that is D3D by using OpenGL in Quake, forcing 3D card makers to support it. It really is a vastly superior standard.
Unfortunatly, I don't think C++B for Linux is very likely. Borland said that the new JBuilder would the first JBuilder that is 100% pure, which means of course that it'll run on Linux. They keep talking about their special Linux and Solaris "Ports" but I think that really just means the installer. I hope I am wrong, but I just don't see C++B/Linux coming anytime soon. =(
They are one and the same, at least with audio. To do very low latency audio, you have to have a very small output buffer. To do this, you need to schedule events with very short intervals, for example, an event every 1 millisecond. You also need that event to go off as close to possible to the scheduled time. To pull this off you need an operating system with at least basic real-time capabilities. Of course, no mainstream OS supports this, which disappoints me. Firm real time support in BeOS would make it much much more useful for my realtime audio effects. For now I stick with linux with KURT.
Its pretty obvious from the data in the registers after the crash that it works. Just in case you know nothing about the x86 line, I'll enlighten you. the fact that ECX and EIP (EIP is the instruction pointer, use your imagination) are filled with 0x41414141 (0x41 is the letter 'A', which is what their overflowing buffer was filled with). So obviously, the instruction pointer is overwritten, allowing the attacker to point EIP back into the buffer, executing their code. Not theoretical at all. The reason sites aren't going down left and right is that the security outfit that found this didn't give out their own test exploit, and people who know how to write one don't give them to script kiddies. An exploit has usually been known about by professionals for a while before it shows up on rootshell.com. The only reason script-kiddie attacks are so sucessful is that admins don't patch to fix holes that have been known about for years.
I have to take offense with this comment. "one of BeOS's strongest points is very low software latency for streaming media." BeOS is NOT a real-time OS, and as such, cannot provide the sub 1 ms latency required for real time audio effects processing. Linux with the KURT patches is quite good at this task. I won't argue with BeOS's great architecture for offline video and audio editing and effects, and I think it could quite possibly be the next toaster, but marketing BeOS as real-time is irresponsible.
The main reason that Micros~1 had such an easy time subverting Java is that it was mainly a consumer product, so Micros~1 controlled the ONE VM that the vast majority of users would be using. Most users with IE didn't know a VM from a toaster, and didn't really care, as long as the pretty little animations work OK. With PERL, Micros~1 is trying to compete with web servers running various flavors of UNIX, and people using PERL are usually knowledgable enough to get a standard PERL for NT if they don't want the extensions. So bending PERL to their omnipotent will is much more difficult.
Actually, you don't really want AA in this case, you only want AA to make 10+ pt fonts look better. With your microfonted web page, instead of looking like a bunch of dots, it would look like a smear. Quite an improvement I'm sure.
Just my preliminary/timerefresh immediatly after starting the first board (yeah yeah, lame I know): 800x600 with all visual options on: 27FPS.
keep in mind, it is VERY unoptimized, the two worst offender is that all rendering happening in the Xserver's context, which means all that data has to be pumped through a pipe! No AGP texturing doesn't help either. Now for a 100% unscientific "test" morph3d screensaver looks about 4 times faster under linux with this driver than under windows with nvidia's detonator drivers (no textures to stuff through the pipe). I can hardly wait till Precision Insight works their magic.
All in all, a very solid alpha driver, works great (except for q3test) and speed will only improve with time.
This is great for any linux user who has a 3D card. 3dfx released binary only drivers, Matrox witholds information for programming the triangle setup engine (WARP). The consumer 3D market is so competitive, now that Nvidia has done it, the others will be forced to follow suit, so they are not percieved as having inferior linux support. Its good to see that the linux "market" has grown to the point that companies are writing drivers themselves. Here's to a open sourced linux driver on every hardware vendor's web page!
It doesn't seem to run quake3 for me yet, but quake2 runs and looks great (still a little slow, hopefully Precision Insight will come through for us soon). The kicker? you HAVE to see sproingies at 1600x1200 flying by! Running quake2 and sproingies both in a window and getting good framerate out of both is cool too.
read it again. The only port that should be open to anyone should be 80. Leave 22 open to the IPs of the machines you admin from. Ideally, you are on the same LAN with the webserver, so you can block internal IPs from coming from anywhere except your network.
I'll address the Linux part first, because I know the most about that.
First off, do the obvious things like removing EVERYTHING you don't absolutely need from/etc/inetd.conf and your rc scripts. Shadowed passwords, not allowing root login remotely (use su) and only having ssh for remote access spring to mind. Now, if thats still not enough, look into the firewall support. deny ICMP, and access to ssh from anything but your machine. The only port that anyone can connect to should be 80. Finally, if you're getting hammered by the kiddies, you might want to look into things like Solar Designer's non-executable stack patch(its called secure-linux, and I think its at: www.false.com). Its not perfect, but its a great extra layer to stop the formulaic attacks. Also, things like StackGuard (a hacked GCC that generates code to try to avoid buffer overruns) may be helpful. If all this isn't enough, its time to break out the heavy iron.
Which brings us to OpenBSD. Most of the stuff I said above applys, except for instead of secure-linux, you just use StackGuard. And firewalling uses ipfilter. No matter what you use, you want tripwire, and be sure to keep the database and the statically linked executable, and a safe kernel, on write-protected floppies.
CGI security i'll leave to someone more qualified than I, especially since there are many great resources on secure CGI programming techniques, and a few on secure apache CGI configuration. Nothing will make a box 100% secure, but every little thing you do could prevent another attack, and eventually, the cost of attacking your server exceeds whatever gain the attacker would get.
If you were working in game programming around the time that Direct3D came out, you would been yelled at by Alex St. John about how much better Direct3D's brain dead "Execute Buffer" scheme was than OpenGL. If it wasn't for Chris Hecker at M$ and John Carmack, OpenGL wouldn't be nearly as well supported as it is today, despite being superior in EVERY way to Direct3D. Funny side note: In D3D v5, they ditched execute buffers for a OpenGL style interface, but they couldn't admit ogl was better and start using that, they had to clone it (poorly) and use that. Microsoft set the 3D gaming world back by at least a year.
SCO MERGE has been around much longer than vmware, and proves that virtualization is possible on x86. Of course, some idiot is going to point out that MERGE only runs win95, but you still have to virtualize 386 protected mode for that. My guess is that SCO didn't think anyone would want to run windows NT on unix. Not that bad an assumption, I think.
For what its worth, I found netscape crashes much less if you "downgrade" to the libc5 version, no matter what your system uses. On my redhat6 box, Netscape 4.08 libc5 version crashes exceptionally rarely, if at all. The libc6 4.51 that came with RH6 crashed on my daily. I hope this helps.
The drug of choice when I was in high school was always weed. Have you ever seen someone stoned? They're sure as hell not killing anyone. Most likely they're struggling with whether or not they're too lazy to go get some munchies. LSD? possible but really really unlikely, since it only lasts 12 hours, and this episode took MUCH longer to plan. As far as scapegoats go, its not drugs either. Keep trying.
wow, so some mac-addict requested those two web pages in netcraft until they reached the top. The other top picks make perfect sense, the first two don't.
According to id, for Quake III, you want a TNT, or a TNT2 when they come out. nvidia has released a full GL driver for win32, and its pretty well optimized. Now they just need to see the light about everything other than win32.
I use a dual 450 box and it has always run perfectly, once the initial bugs from the pre 2.0.35 SMP were worked out. With 2.2 it screams. It blows slightly warm air out the back, but is no worse than my P90. I find that most PIIs run cooler than many versions of the classic pentium, due to 5.5v vs 2.2 and other such details.
I dunno about the others, but on my OpenBSD box, also a P90, ftping a file from it cause X to simply STOP until the file is done. A simple ping flood will cause the mouse cursor to jerk around and make it hard to move windows around. Maybe some BSD advocate will tell me what I'm doing wrong, but this is not the searing network performance that I was told to expect from the BSDs.
Slashdot Mirror
A pthread in unix shares the virtual address space with the other threads spawned by the same process. Which appears to be how you defined a "team." So I am left to assume from your post that normal BeOS threads do not share address spaces with other threads in the same process. UNIX also has this facility. They are called "processes." If you mean something else, please elaborate.
This is one of those examples where the GPL really helps Linux. It allows SGI to port the OS without having to deal with Be, Inc. Much more importantly, since I'm sure Be would be delighted to have SGI port Be, is that SGI needs to keep control over their platform's OS. With Linux, they can always just fork the tree if Linus does something detrimental to their product.
Personally, I'd rather see a firm real time system be integrated. If you're doing something that requires hard real-time, patching a kernel isn't a problem, however many "desktop" apps could benefit from universal firm realtime. Perhaps .5 to 1 ms scheduling with about 250 ps of latency.
You don't understand DRI. It lets your app talk directly to the hardware, the X server is not directly involved. The main overhead with DRI is the memory usage of the X server (which is not nearly as bad as people seem to think. Keep in mind that the server is mmapping the WHOLE video memory into its address space, so if you have a 16 meg TNT, it makes X look HUGE, when it is in fact merely large). As for D3D, at least when I was writing apps with it, the overhead was horrible, because of those damn execute buffers. Then John Carmack saved the gaming world from the abomination that is D3D by using OpenGL in Quake, forcing 3D card makers to support it. It really is a vastly superior standard.
Unfortunatly, I don't think C++B for Linux is very likely. Borland said that the new JBuilder would the first JBuilder that is 100% pure, which means of course that it'll run on Linux. They keep talking about their special Linux and Solaris "Ports" but I think that really just means the installer. I hope I am wrong, but I just don't see C++B/Linux coming anytime soon. =(
A unified buffer cache is great for the whole range of linux systems.
They are one and the same, at least with audio. To do very low latency audio, you have to have a very small output buffer. To do this, you need to schedule events with very short intervals, for example, an event every 1 millisecond. You also need that event to go off as close to possible to the scheduled time. To pull this off you need an operating system with at least basic real-time capabilities. Of course, no mainstream OS supports this, which disappoints me. Firm real time support in BeOS would make it much much more useful for my realtime audio effects. For now I stick with linux with KURT.
Its pretty obvious from the data in the registers after the crash that it works. Just in case you know nothing about the x86 line, I'll enlighten you. the fact that ECX and EIP (EIP is the instruction pointer, use your imagination) are filled with 0x41414141 (0x41 is the letter 'A', which is what their overflowing buffer was filled with). So obviously, the instruction pointer is overwritten, allowing the attacker to point EIP back into the buffer, executing their code. Not theoretical at all. The reason sites aren't going down left and right is that the security outfit that found this didn't give out their own test exploit, and people who know how to write one don't give them to script kiddies. An exploit has usually been known about by professionals for a while before it shows up on rootshell.com. The only reason script-kiddie attacks are so sucessful is that admins don't patch to fix holes that have been known about for years.
I have to take offense with this comment. "one of BeOS's strongest points is very low software latency for streaming media." BeOS is NOT a real-time OS, and as such, cannot provide the sub 1 ms latency required for real time audio effects processing. Linux with the KURT patches is quite good at this task. I won't argue with BeOS's great architecture for offline video and audio editing and effects, and I think it could quite possibly be the next toaster, but marketing BeOS as real-time is irresponsible.
if you have the server do all the important game events, like quake does, compromised clients can't do as much damage.
The main reason that Micros~1 had such an easy time subverting Java is that it was mainly a consumer product, so Micros~1 controlled the ONE VM that the vast majority of users would be using. Most users with IE didn't know a VM from a toaster, and didn't really care, as long as the pretty little animations work OK. With PERL, Micros~1 is trying to compete with web servers running various flavors of UNIX, and people using PERL are usually knowledgable enough to get a standard PERL for NT if they don't want the extensions. So bending PERL to their omnipotent will is much more difficult.
Actually, you don't really want AA in this case, you only want AA to make 10+ pt fonts look better. With your microfonted web page, instead of looking like a bunch of dots, it would look like a smear. Quite an improvement I'm sure.
Just my preliminary /timerefresh immediatly after starting the first board (yeah yeah, lame I know):
800x600 with all visual options on: 27FPS.
keep in mind, it is VERY unoptimized, the two worst offender is that all rendering happening in the Xserver's context, which means all that data has to be pumped through a pipe! No AGP texturing doesn't help either. Now for a 100% unscientific "test" morph3d screensaver looks about 4 times faster under linux with this driver than under windows with nvidia's detonator drivers (no textures to stuff through the pipe). I can hardly wait till Precision Insight works their magic.
All in all, a very solid alpha driver, works great (except for q3test) and speed will only improve with time.
This is great for any linux user who has a 3D card. 3dfx released binary only drivers, Matrox witholds information for programming the triangle setup engine (WARP). The consumer 3D market is so competitive, now that Nvidia has done it, the others will be forced to follow suit, so they are not percieved as having inferior linux support.
Its good to see that the linux "market" has grown to the point that companies are writing drivers themselves. Here's to a open sourced linux driver on every hardware vendor's web page!
It doesn't seem to run quake3 for me yet, but quake2 runs and looks great (still a little slow, hopefully Precision Insight will come through for us soon). The kicker? you HAVE to see sproingies at 1600x1200 flying by! Running quake2 and sproingies both in a window and getting good framerate out of both is cool too.
read it again. The only port that should be open to anyone should be 80. Leave 22 open to the IPs of the machines you admin from. Ideally, you are on the same LAN with the webserver, so you can block internal IPs from coming from anywhere except your network.
I'll address the Linux part first, because I know the most about that.
/etc/inetd.conf and your rc scripts. Shadowed passwords, not allowing root login remotely (use su) and only having ssh for remote access spring to mind.
First off, do the obvious things like removing EVERYTHING you don't absolutely need from
Now, if thats still not enough, look into the firewall support. deny ICMP, and access to ssh from anything but your machine. The only port that anyone can connect to should be 80.
Finally, if you're getting hammered by the kiddies, you might want to look into things like Solar Designer's non-executable stack patch(its called secure-linux, and I think its at: www.false.com). Its not perfect, but its a great extra layer to stop the formulaic attacks. Also, things like StackGuard (a hacked GCC that generates code to try to avoid buffer overruns) may be helpful. If all this isn't enough, its time to break out the heavy iron.
Which brings us to OpenBSD. Most of the stuff I said above applys, except for instead of secure-linux, you just use StackGuard. And firewalling uses ipfilter.
No matter what you use, you want tripwire, and be sure to keep the database and the statically linked executable, and a safe kernel, on write-protected floppies.
CGI security i'll leave to someone more qualified than I, especially since there are many great resources on secure CGI programming techniques, and a few on secure apache CGI configuration.
Nothing will make a box 100% secure, but every little thing you do could prevent another attack, and eventually, the cost of attacking your server exceeds whatever gain the attacker would get.
I managed to fix almost all of my NS crashing problems by switching to communicator 4.08 libc5 version. This is remarkably stable for me.
If you were working in game programming around the time that Direct3D came out, you would been yelled at by Alex St. John about how much better Direct3D's brain dead "Execute Buffer" scheme was than OpenGL. If it wasn't for Chris Hecker at M$ and John Carmack, OpenGL wouldn't be nearly as well supported as it is today, despite being superior in EVERY way to Direct3D. Funny side note: In D3D v5, they ditched execute buffers for a OpenGL style interface, but they couldn't admit ogl was better and start using that, they had to clone it (poorly) and use that. Microsoft set the 3D gaming world back by at least a year.
SCO MERGE has been around much longer than vmware, and proves that virtualization is possible on x86. Of course, some idiot is going to point out that MERGE only runs win95, but you still have to virtualize 386 protected mode for that. My guess is that SCO didn't think anyone would want to run windows NT on unix. Not that bad an assumption, I think.
For what its worth, I found netscape crashes much less if you "downgrade" to the libc5 version, no matter what your system uses. On my redhat6 box, Netscape 4.08 libc5 version crashes exceptionally rarely, if at all. The libc6 4.51 that came with RH6 crashed on my daily. I hope this helps.
The drug of choice when I was in high school was always weed. Have you ever seen someone stoned? They're sure as hell not killing anyone. Most likely they're struggling with whether or not they're too lazy to go get some munchies. LSD? possible but really really unlikely, since it only lasts 12 hours, and this episode took MUCH longer to plan. As far as scapegoats go, its not drugs either. Keep trying.
wow, so some mac-addict requested those two web pages in netcraft until they reached the top. The other top picks make perfect sense, the first two don't.
According to id, for Quake III, you want a TNT, or a TNT2 when they come out. nvidia has released a full GL driver for win32, and its pretty well optimized. Now they just need to see the light about everything other than win32.
I use a dual 450 box and it has always run perfectly, once the initial bugs from the pre 2.0.35 SMP were worked out. With 2.2 it screams. It blows slightly warm air out the back, but is no worse than my P90. I find that most PIIs run cooler than many versions of the classic pentium, due to 5.5v vs 2.2 and other such details.
I dunno about the others, but on my OpenBSD box, also a P90, ftping a file from it cause X to simply STOP until the file is done. A simple ping flood will cause the mouse cursor to jerk around and make it hard to move windows around. Maybe some BSD advocate will tell me what I'm doing wrong, but this is not the searing network performance that I was told to expect from the BSDs.