And since nobody would use it because of the incompatibility issues, it would be REALLY secure. He could then afford to offer a $1000 bounty to anyone able to 'sploit it. 8-)
qmail is the second most common SMTP server on the internet, so it's hardly fair to say that nobody uses it. He can afford to offer guarantees because there are no security holes.
I agree that those screen shots look blurry, but if you get used to the anti aliasing on Windows 2000, which only does larger fonts, it is definitely an improvement. I have friends with laptops (LCD's) and XP, and they absolutely love ClearType. So I think it's a combination of getting used to it (it won't look good immediately, since you are used to sharp, jagged edges) and getting a decent font renderer (which Linux may or may not have). Give yourself a few days of it and see if it looks better to you. You might end up wishing you'd done that a long time ago.
Now color me crazy, but since when has attaining similar aesthetic content to Windows been considered a good thing? It hurts my eyes just to look at it. I long for the good old days without those fancy anti-aliased fonts, although Mac OS X is quite pleasurable to use.
I didn't like the anti aliasing ("smooth edges of screen fonts") in Windows 2000 and didn't use it for a long time. Then it somehow got turned on, and when I noticed I decided to give it a chance. After a few days, I got used to it, and everything really does look better now. I stopped using Linux as a desktop, fonts being a big reason, so I don't know how well X does fonts with this (imho the screenshots are horrible on the eyes), but I suggest giving it a try for a few days and see if you end up liking it better.
I guess the name is ClosedBSD, because it closes the doors/ports for bad guys such as hackers... what a firewall is supposed to do. The name is basically an allusion to security...
I have it on good word that the name is a poke at the OpenBSD guys.
My guess is that AOL has a bug up their butt about Oscar because it has security holes. The Trillian fiasco is a bit like creating a client for Slashdot that accesses the MySQL database directly, having the Slashdot guys close it down for you, and then you crying foul. There's a public interface and a private interface, and AOL lets whoever wants to write a client to the public interface go for it... but Trillian insists upon using that internal interface.
TOC lacks many features features. It works for their web client that is usable if you want to log on from somewhere and send someone a quick message, but it's not good enough for a full client. One very important feature it lacks is the ability to check away messages without sending the user a message. People who use IM all the time keep information in their away message, and not being able to check it really takes away from the IM "experience".
"$0.65 for those who buy everday; $1.65 otherwise,"
Last I knew, they had this, have always had this, and will continue to have this. Since when do you pay news stand price to have the paper or a magazine delivered to your door every day / week / month?
You can't go on forever throwing things in landfill, your country will fill up.
I'm sure there is an obvious answer for this, but how can a country fill up due to landfills? The law of conservation says you have to be getting it from somewhere, this stuff isn't just being made out of nothing. So why not put it back where it came from originally?
strncpy() won't null terminate the string if the destination is not long enough, which can cause many other problems later (such as calling strlen() on it).
Umm, Microsoft gives away it's SDK and compilers and provides the developer libs as a free download. You don't need to pay MS a thin dime to develop on Windows (except for the base OS, but if you are tricky you could compile for Windows on Linux or BSD).
Microsoft has a free compiler for Windows now? I guess I got duped into buying VC++ then. And how am I supposed to test my apps on Windows if I don't have it?
I run bnetd on one of the spare servers at work for our bi-weekly Starcraft games. It's a fantastic piece of software and it allows us (in IT) to have an IPX free network whilst still allowing for gaming (after hours of course ; ).
The latest patch to Starcraft that came out within the last month adds UDP LAN support, so you don't need IPX anymore. Does anyone know how to route it over the internet, so you don't need battle.net? Sure, I could use an IPX to TCP converter like Kali or Khan, but I want something that doesn't cost as much as the game itself.
Then use zeus for static pages, and Apache (an APPLICATION SERVER which happens to talk HTTP and feed static content, conveniently) for dynamic content. Zeus doesn't DO dynamic stuff...
Zeus most certainly does handle dynamic content, and it handles it very well. Zeus supports CGI, FastCGI, NSAPI and ISAPI (basically everything that's not proprietary, like Apache).
I doubt that any mod_perl based site is set up in such a way. At a bare miniumum, mod_perl sites have two apache binaries serving pages: one for the static pages, one for the dynamic pages. The static binary is obviously as lightweight as possible. If you're really interested in mod_perl tuning check out the mod_perl guide at perl.apache.org.
Why should you go through all that extra hassle to make up for a design flaw in the web server? Wouldn't it make more sense to use a non blocking web server with a single process per CPU, and have the Perl FastCGI handling the Perl code?
If serving huge amounts (>1 GB/hour)of static content from a single-CPU computer is what your server does, Apache is not for you.
A well designed non blocking server can run in multiple processes, to take advantage of multiple CPU's. Zeus does this.
But if you would stop to think for a while, you would see that no one does that. Nowdays, it's all about dynamic content. And in that case the overhead of using multiple threads is tiny compared to the added benefits of scalability and stability.
That's wrong. As I said, most of your requests will be static content. Take Slashdot, for example. This comment posting page is one perl page, and six images. Do you really need six extra processes for those images? Especially large Apache processes that have mod_perl and who knows what else compiled into them. Sure, the code pages should be shared, but it's still poor design.
It is actually possible to use a kernel-based server like Tux for static content and let Apache take care of the dynamic bits.
Sure you can do that, but wouldn't it be better to use a well designed server in first place, and not have to kludge around design flaws in the web server? Your web server should not be your application server. Your web server should be serving web pages. Your application server should be running applications. The Apache model of "build everything conceivable into the web server process" is a bad idea, and is not consistent with the unix philosophy of doing one thing, and doing it well.
Everyone knows CGI's are bad for performance because it causes forking a separate CGI process for each request. Turning the CGI's into Apache modules solves this problem, but not in an optimal way. Applications do not belong in the web server. A model such as FastCGI is a much better approach. It is similar to CGI, especially in the sense that it is easy to program for. But instead of running the process and using stdin/stdout as with a CGI, it connects to the FastCGI via a socket. Thus the application stays running, and there is no process creation overhead. It keeps any necessary load balancing on the application end where it belongs, and out of the web server.
Additionally, the application doesn't even need to be on the same box. You can have one or several application servers, and a single web server. A web server only needs to handle data. A single box should be able to fill your outbound pipe, or at least around 100mbits of it. If an application is slowing it down, then you need another application server, not another web server. It is unfortunate that the two are not seen as the separate entities that they should be.
I've been using Apache 2 on Linux and FreeBSD for about 2 months now (...), and IMHO it is really going to rock the server world.
This isn't meant to be a flame, but a genuine complaint of the Apache web server that I haven't seen adequately addressed anywhere. How can Apache claim to be a modern web server if it continues to use an outdated request model? Having a separate process or thread for each request is completely unnecessary. Even for a site with dynamic content, the majority of the requests will be for static content (images). So why use up system resources when not necessary?
A request for static content is essentially just moving data from one file descriptor to a socket, something that sendfile(2) can be used for on operating systems that implement it. If a single system call combined with a select(2) loop can handle the majority of the requests, then why is each request tying up a process or a thread? When reading the Apache mailing lists, you get answers such as "it's too difficult for other programmers to extend the server", "processes or threads don't have to be expensive depending on how the operating system implements them", "everyone is happy with how it works now", and "Apache is meant to be correct first and fast second". None of these address the issue that Apache's request model is flawed, and it will never be high performance until it is corrected.
Additionally, the Zeus Web Server is well implemented and doesn't suffer from any of the problems that seem to keep Apache from being implemented correctly. It's also better than Apache in every way, ranging from performance to configuration (with the exception of not being open source). Zeus did everything right and built a great web server. Years later, Apache is just now getting their next version into beta, and it seems to be just as fundamentally flawed as the first version. If there is ever an open source web server as high quality as Zeus, then it more than likely won't be Apache.
Well, generally, when I see something like sleep(3), it means that a thread is waiting for an event to finish.
That notation tells which manual section the name is in, not what parameters if any the function may be called with (many times the name is not a function). In this case, the "sleep" function is in manual section 3. i.e. you run "man 3 sleep".
The brain can not recall every stimulus it has ever encountered. It uses some very lossy compression. People don't often remember an event perfectly.
No, but people with photographic memories can remember everything they've ever seen. And hypnotism can be used to recall events that people cannot remember or have blocked out. Ever wonder why you have a dream about someone or something that you haven't seen or thought about in years? It's all in there, somewhere. The brain is very amazing, and we are nowhere near duplicating it or even understanding it. Don't underestimate it's potential.
It would presumably be impractical and unnecessary for an AI being to retain EVERY shred of information it ever collected. The assumptions about computers becoming superior to human brains are all very well, but even a day's worth of human sensory stimulii would take up an unimaginable amount of storage space.
Very true, it would take up a lot of space. But your brain somehow manages to store it all. You just have trouble retreiving it, unless you are on of the lucky few with a "photographic memory". This is likely the direction that storage will take in the future.
Short answer: it is a LOT more work up front. But later it is sweet. You let your graphic stud come up with a new layout in HTML (dreameweaver or whatever) and you write an XSL to translate into that. Maybe have him export a netscape compatible one (browser sniffing dishes out a different transform) and you have a plain text one as well (section 508 compliance becomes very easy. That's what is driving the current conversion).
We use HTML templates for everything, where you basically have HTML with variables in it, that get replaced by the code. It gets complicated when you tables and such, or when you do anything that changes the ordering of the templates. That's what I haven't been able to find a good way of doing: specifying a template order separate from the code, while using templates that are displayed by code (such as displaying all rows in a table). Though you don't change the entire layout too often, and when you do, it's not that much code to change. I can see the advantage to using XML and XSL for everything, but it seems that it might be easier to just change the little bit of code necessary when changing layouts.
What's that? Some PHB wants a new "look and feel"? I just write a new XSL stylesheet, replace it on the server, and I'm done.
Do you have any references for doing this type of thing? I've seen many things and people such as yourself claiming it's easy, but whenever you get to actually doing it, you end up with lots of hacks if you have a complicated design.
The 57Mb is only a small test set of the entire data set. As it notes on the page, the tarball includes links to where to download the entire set, which will fill the five CD's.
Slashdot Mirror
And since nobody would use it because of the incompatibility issues, it would be REALLY secure. He could then afford to offer a $1000 bounty to anyone able to 'sploit it. 8-)
qmail is the second most common SMTP server on the internet, so it's hardly fair to say that nobody uses it. He can afford to offer guarantees because there are no security holes.
I agree that those screen shots look blurry, but if you get used to the anti aliasing on Windows 2000, which only does larger fonts, it is definitely an improvement. I have friends with laptops (LCD's) and XP, and they absolutely love ClearType. So I think it's a combination of getting used to it (it won't look good immediately, since you are used to sharp, jagged edges) and getting a decent font renderer (which Linux may or may not have). Give yourself a few days of it and see if it looks better to you. You might end up wishing you'd done that a long time ago.
Now color me crazy, but since when has attaining similar aesthetic content to Windows been considered a good thing? It hurts my eyes just to look at it. I long for the good old days without those fancy anti-aliased fonts, although Mac OS X is quite pleasurable to use.
I didn't like the anti aliasing ("smooth edges of screen fonts") in Windows 2000 and didn't use it for a long time. Then it somehow got turned on, and when I noticed I decided to give it a chance. After a few days, I got used to it, and everything really does look better now. I stopped using Linux as a desktop, fonts being a big reason, so I don't know how well X does fonts with this (imho the screenshots are horrible on the eyes), but I suggest giving it a try for a few days and see if you end up liking it better.I guess the name is ClosedBSD, because it closes the doors/ports for bad guys such as hackers ... what a firewall is supposed to do. The name is basically an allusion to security ...
I have it on good word that the name is a poke at the OpenBSD guys.Is there a way to patch the major distro versions (i.e. rh, suse, mandrake ...) from there default versions to the secure version?
# apt-get update
# apt-get upgrade
:-)
My guess is that AOL has a bug up their butt about Oscar because it has security holes. The Trillian fiasco is a bit like creating a client for Slashdot that accesses the MySQL database directly, having the Slashdot guys close it down for you, and then you crying foul. There's a public interface and a private interface, and AOL lets whoever wants to write a client to the public interface go for it... but Trillian insists upon using that internal interface.
TOC lacks many features features. It works for their web client that is usable if you want to log on from somewhere and send someone a quick message, but it's not good enough for a full client. One very important feature it lacks is the ability to check away messages without sending the user a message. People who use IM all the time keep information in their away message, and not being able to check it really takes away from the IM "experience"."$0.65 for those who buy everday; $1.65 otherwise,"
Last I knew, they had this, have always had this, and will continue to have this. Since when do you pay news stand price to have the paper or a magazine delivered to your door every day / week / month?You can't go on forever throwing things in landfill, your country will fill up.
I'm sure there is an obvious answer for this, but how can a country fill up due to landfills? The law of conservation says you have to be getting it from somewhere, this stuff isn't just being made out of nothing. So why not put it back where it came from originally?I always thought NFS meant "No File Security"
DJB calls it Network Failure System.
strncpy() won't null terminate the string if the destination is not long enough, which can cause many other problems later (such as calling strlen() on it).
Umm, Microsoft gives away it's SDK and compilers and provides the developer libs as a free download. You don't need to pay MS a thin dime to develop on Windows (except for the base OS, but if you are tricky you could compile for Windows on Linux or BSD).
Microsoft has a free compiler for Windows now? I guess I got duped into buying VC++ then. And how am I supposed to test my apps on Windows if I don't have it?I run bnetd on one of the spare servers at work for our bi-weekly Starcraft games. It's a fantastic piece of software and it allows us (in IT) to have an IPX free network whilst still allowing for gaming (after hours of course ; ).
The latest patch to Starcraft that came out within the last month adds UDP LAN support, so you don't need IPX anymore. Does anyone know how to route it over the internet, so you don't need battle.net? Sure, I could use an IPX to TCP converter like Kali or Khan, but I want something that doesn't cost as much as the game itself.Then use zeus for static pages, and Apache (an APPLICATION SERVER which happens to talk HTTP and feed static content, conveniently) for dynamic content. Zeus doesn't DO dynamic stuff...
Zeus most certainly does handle dynamic content, and it handles it very well. Zeus supports CGI, FastCGI, NSAPI and ISAPI (basically everything that's not proprietary, like Apache).I doubt that any mod_perl based site is set up in such a way. At a bare miniumum, mod_perl sites have two apache binaries serving pages: one for the static pages, one for the dynamic pages. The static binary is obviously as lightweight as possible. If you're really interested in mod_perl tuning check out the mod_perl guide at perl.apache.org.
Why should you go through all that extra hassle to make up for a design flaw in the web server? Wouldn't it make more sense to use a non blocking web server with a single process per CPU, and have the Perl FastCGI handling the Perl code?
If serving huge amounts (>1 GB/hour)of static content from a single-CPU computer is what your server does, Apache is not for you.
A well designed non blocking server can run in multiple processes, to take advantage of multiple CPU's. Zeus does this.
But if you would stop to think for a while, you would see that no one does that. Nowdays, it's all about dynamic content. And in that case the overhead of using multiple threads is tiny compared to the added benefits of scalability and stability.
That's wrong. As I said, most of your requests will be static content. Take Slashdot, for example. This comment posting page is one perl page, and six images. Do you really need six extra processes for those images? Especially large Apache processes that have mod_perl and who knows what else compiled into them. Sure, the code pages should be shared, but it's still poor design.
It is actually possible to use a kernel-based server like Tux for static content and let Apache take care of the dynamic bits.
Sure you can do that, but wouldn't it be better to use a well designed server in first place, and not have to kludge around design flaws in the web server? Your web server should not be your application server. Your web server should be serving web pages. Your application server should be running applications. The Apache model of "build everything conceivable into the web server process" is a bad idea, and is not consistent with the unix philosophy of doing one thing, and doing it well.
Everyone knows CGI's are bad for performance because it causes forking a separate CGI process for each request. Turning the CGI's into Apache modules solves this problem, but not in an optimal way. Applications do not belong in the web server. A model such as FastCGI is a much better approach. It is similar to CGI, especially in the sense that it is easy to program for. But instead of running the process and using stdin/stdout as with a CGI, it connects to the FastCGI via a socket. Thus the application stays running, and there is no process creation overhead. It keeps any necessary load balancing on the application end where it belongs, and out of the web server.
Additionally, the application doesn't even need to be on the same box. You can have one or several application servers, and a single web server. A web server only needs to handle data. A single box should be able to fill your outbound pipe, or at least around 100mbits of it. If an application is slowing it down, then you need another application server, not another web server. It is unfortunate that the two are not seen as the separate entities that they should be.
I've been using Apache 2 on Linux and FreeBSD for about 2 months now (...), and IMHO it is really going to rock the server world.
This isn't meant to be a flame, but a genuine complaint of the Apache web server that I haven't seen adequately addressed anywhere. How can Apache claim to be a modern web server if it continues to use an outdated request model? Having a separate process or thread for each request is completely unnecessary. Even for a site with dynamic content, the majority of the requests will be for static content (images). So why use up system resources when not necessary?
A request for static content is essentially just moving data from one file descriptor to a socket, something that sendfile(2) can be used for on operating systems that implement it. If a single system call combined with a select(2) loop can handle the majority of the requests, then why is each request tying up a process or a thread? When reading the Apache mailing lists, you get answers such as "it's too difficult for other programmers to extend the server", "processes or threads don't have to be expensive depending on how the operating system implements them", "everyone is happy with how it works now", and "Apache is meant to be correct first and fast second". None of these address the issue that Apache's request model is flawed, and it will never be high performance until it is corrected.
Additionally, the Zeus Web Server is well implemented and doesn't suffer from any of the problems that seem to keep Apache from being implemented correctly. It's also better than Apache in every way, ranging from performance to configuration (with the exception of not being open source). Zeus did everything right and built a great web server. Years later, Apache is just now getting their next version into beta, and it seems to be just as fundamentally flawed as the first version. If there is ever an open source web server as high quality as Zeus, then it more than likely won't be Apache.
Well, generally, when I see something like sleep(3), it means that a thread is waiting for an event to finish.
That notation tells which manual section the name is in, not what parameters if any the function may be called with (many times the name is not a function). In this case, the "sleep" function is in manual section 3. i.e. you run "man 3 sleep".The brain can not recall every stimulus it has ever encountered. It uses some very lossy compression. People don't often remember an event perfectly.
No, but people with photographic memories can remember everything they've ever seen. And hypnotism can be used to recall events that people cannot remember or have blocked out. Ever wonder why you have a dream about someone or something that you haven't seen or thought about in years? It's all in there, somewhere. The brain is very amazing, and we are nowhere near duplicating it or even understanding it. Don't underestimate it's potential.It would presumably be impractical and unnecessary for an AI being to retain EVERY shred of information it ever collected. The assumptions about computers becoming superior to human brains are all very well, but even a day's worth of human sensory stimulii would take up an unimaginable amount of storage space.
Very true, it would take up a lot of space. But your brain somehow manages to store it all. You just have trouble retreiving it, unless you are on of the lucky few with a "photographic memory". This is likely the direction that storage will take in the future.Short answer: it is a LOT more work up front. But later it is sweet. You let your graphic stud come up with a new layout in HTML (dreameweaver or whatever) and you write an XSL to translate into that. Maybe have him export a netscape compatible one (browser sniffing dishes out a different transform) and you have a plain text one as well (section 508 compliance becomes very easy. That's what is driving the current conversion).
Thanks for the info. The correct url is http://www.zvon.org/xxl/XSLTreference/Output/index .html. Unfortunately, it sounds exactly like what I thought. Just another way of doing something, not necessarily better :(
We use HTML templates for everything, where you basically have HTML with variables in it, that get replaced by the code. It gets complicated when you tables and such, or when you do anything that changes the ordering of the templates. That's what I haven't been able to find a good way of doing: specifying a template order separate from the code, while using templates that are displayed by code (such as displaying all rows in a table). Though you don't change the entire layout too often, and when you do, it's not that much code to change. I can see the advantage to using XML and XSL for everything, but it seems that it might be easier to just change the little bit of code necessary when changing layouts.
What's that? Some PHB wants a new "look and feel"? I just write a new XSL stylesheet, replace it on the server, and I'm done.
Do you have any references for doing this type of thing? I've seen many things and people such as yourself claiming it's easy, but whenever you get to actually doing it, you end up with lots of hacks if you have a complicated design.I agree that with the current system, it is a social problem. But a new standard like Internet Mail 2000 would be immune to spam.
Ahh. I thought you meant they earned billions, and lost (spent) all but a couple million.
So if they aren't losing a couple million, isn't that a profit?
The 57Mb is only a small test set of the entire data set. As it notes on the page, the tarball includes links to where to download the entire set, which will fill the five CD's.