Date: Mon, 18 Feb 2002 03:42:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: FreeBSD Questions <freebsd-questions@FreeBSD.ORG> Subject: Re: in-kernel HTTP Server for FreeBSD? Message-ID: <3C70E8B2.168D9F56@mindspring.com> References: <20020217143343.41758.qmail@web21104.mail.yahoo.com> <xzp4rkgf7n7.fsf@flood.ping.uio.no> <20020217163045.GB90303@voi.aagh.net> <3C703089.AD03554B@mindspring.com> <018501c1b816$2a9cb970$0a00000a@atkielski.com> <3C705564.E1EA2FDA@mindspring.com> <001c01c1b859$6ee18c80$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski wrote: > Terry writes: > > The obvious rejoinder to your claim is that on > > a resource starved system that is using HTTP > > based system management, once you hit resource > > starvation, your management of the system which > > would enable you to recover from the failure > > situation is impossible, unless that management > > is immune from said stavation (e.g. by being in > > the kernel). > > HTTP-based system management is an unnecessary gadget. This is your unbacked opinion, and it runs contrary to market opinion. > A simple terminal session is more efficient and reliable. This is also your opinion. Effeciency is not measured soley in number of keystrokes -- though being efficient will not necessarily mean that the number of keystrokes increase. Effciency is a product of the learning curve vs. training requirements vs. critical task performance vs. "the warm fuzzies". If something has a sharp learning curve (and command line interfaces have this), then dropping someone in raw tends to not get the best results for a while. Yes, we all like to believe that we are members of some elite above average intelligentsia for having managed to learn something that other people do not know, but in fact, that's just human ego. Training requirements are also an issue. It is not some cosmic coincidence that employers ask for experience with Microsoft products. This is because the average training cost per seat for computer using jobs for common business roles, according to IDC, is US$2,500. Existing familiarity with applications written to conform to the "Windows Style Guide" means that you are familiar with the operating principles, if not the details, of any new application which also conforms. Businesses want to be able to plug in a replacement from a temporary agency, and businesses want to pay for the value of knowledge, rather than paying some premium based on its scarcity. By far, the most important issue is the ability to start from scratch and perform the critical tasks necessary to get minimum value out of a product. There is no magical serendipity involved in the little pictures on the document feeder for photo copiers showing which side is up, or the fact that the default when you press the green button is to make one single-sided copy (the most common operation, and an operation which can be substituted for all others, if need be by turning one two sided sheet into two one sided sheets, etc.). And "the warm fuzzies", though tangible only in survey of the confidence of the user after performing the task, before committing the results, are nearly as important as the ability to hit the ground running with the product. I really think that what you need is to visit the usability lab of a large company to see HCI testing over a period of several iterations, so you can understand. > I've never cared for anything that must be managed via > HTTP. That's your taste, which is atypical, given that you are an atypical user. Most devices that can be managed via a Web UI can also be managed through at least one more method. The last product I worked on for a commercial vendor had four methods, and the product before that had six. Your response here is a bit unsupportable, since it was your implication of "must". > That's one reason why I don't like IIS. Again, your taste, and your implication. I know of at least two other ways to manage IIS, and I could easily implement other on top of the available, documented framework. > > Finally, yes, it makes sense for a dedicated > > web server to do this; so what? It also make > > sense for any web server where performance is > > an issue, dedicated or not. > > No. If the machine is not dedicated to HTTP, putting such > functions in the kernel unnecessarily complicates and > destabilizes the kernel. More code does not necessarily equal instant instability, particularly in the BSD camps. It takes as much code as it takes, to implement any design. The complication is in your imagination; Julian has already posted that JMB has already used the ng_socket interface to build a proprietary in-kernel HTTP server for a commercial application. Any such module would be compartmentalized, and thus incredibly low risk, particularly if it was written as a result of an engineering process. > In fact, it defeats the whole purpose of an operating system. > The OS is supposed to handle essential functions common to all > users and affecting the entire system; user processes are > supposed to handle applications specific to a user or users. > When OS designers work to improve stability or security, they > tend to move more and more code out into userland; when they > work to get the highest possible score on a benchmark in order > to please the marketroids, they move code into the kernel. I think you are reading from the GNU HURD Bible here, or at least from the microkernel Bible. If you read the introduction to the MACH documentation, you'll notice that they explicitly state that the "micro" in "microkernel" refers to the number of services offered, and not to the amount of code that it takes to implement them. Frankly, if this is your ruler, you are in the wrong place, since FreeBSD is, and always has been, an example of the monolithic kernel paradigm. While it's true that there are a lot of drivers and other subsystems today in kernel modules, modularity does not affect whether or not the resulting system is monolithic or micro. I never expected to get away from the monolithic kernel design, and I'm the author of the original module services in FreeBSD, NetBSD, and OpenBSD. > > PS: People use FreeBSD for dedicated web servers; > > therefore, even if your limitation argument were > > valid, which I don't grant, it makes sense for > > FreeBSD to at least have this facility available. > > People use FreeBSD for dedicated routers, too; so by your > logic, presumably all network and routing daemons should be > moved into the kernel as well. Most of the routing code *is* in the kernel. For routing daemons themselves, that would mean eliminating a significant latency in response, which would subsequently result in a reduction of pool retention time for routing packets under stress loads. Further, routing is a system level service. So yeah, with gigabit interfaces becoming common, if you are routing at all -- and this include NAT and PPP and PPPOE and other more and more common connection facilities that require routing between a local network and the rest of the Internent -- then you're quite correct that the code belongs in the kernel, if that function is performance sensitve. Just like the HTTP server belongs in the kernel when serving static pages, if that function is performance sensitive, or if it must operate within a browser tiemout independent of system load, as it must do, if that is the system management interface. Guess what? MPD -- the Multilink PPP daemon -- and the PPPOE implementation *ARE* in the kernel. Guess what else? So is the ARP code. > If a user needs a dedicated web server, he should consider > something other than a general-purpose operating system. For example? What are the top two dedicated web servers running on something other than a general-purpose OS which you would suggest using, in this circumstance? > Additionally, needing a dedicated server for anything often > is an indication of skimping on hardware, and on that path > lies danger, no matter what OS is used. The "danger" is, once again, only in your opinion. By that same argument, use of free software as your computing platform is an indication of "skimping on software", if you want to point to skimping as something bad. If you're in for a penny, then you're in for a pound: you can't call "skimping on hardware" bad, unless you tar use of FreeBSD with that same brush. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C70E8B2.168D9F56>