Welcome to Amsterdam

Posted by Jim Jagielski on Thursday, February 22. 2007 in ASF

Sander and Nick somewhat recently blogged about how we're working on the "next generation" of the Apache web server, code named "amsterdam." My own personal codename for my design concept is "outback" and we'll see why in a bit. To be sure, we are at the very early stages, basically conceptual whiteboarding, if even there, right now. But some things are clear, at least in what major direction Apache will be taking. With 1.2 the big news was HTTP/1.1 compliance; with 1.3 it was Windows compatibility; with 2.0 it was threading; with 2.2 it's proxy, cache and large file improvements. With next-gen, it will be asynchronous, event-based processing... The real advantage of this can best be made clear using an analogy. I like to think of the way Apache works as similar to checking out at a grocery store. As people check out (requests come in), the are handled by a "dedicated" cashier (process or thread). The cashier is busy with that single person, and if more people need to check out, they need to be handled by other cashiers (the store manager, who then calls in extra cashiers, is the Apache parent process). As we all know, the problem occurs when there are more people checking out at the same time, and there aren't enough cashiers around; they queue up or are simply denied. To handle this, the move is more towards a restaurant and waiter-type design format. In this scenario, your "server" doesn't just sit there at your table, dedicated just to you. Instead, they move about, responsible for several diners, taking drink orders here, dessert orders there, delivering food hither and yon. This is much more efficient. Of course, there is a step even further, which some of you may have already guessed upon. There are, after all, times when your waiter is handling a lot of tables, and other waiters are handling almost none; your waiter may not be dedicated to you, but they are dedicated to their "section." The improvement is the way Outback Steakhouse tries to operate, where all waiters kind of do everything, and sometimes a different waiter will take your dinner order as compared to the one who took your drinks, etc. This is the most efficient, but also the trickiest one to pull off in a hybrid (process and thread based) server (the waiter "sections" could be considered process bound, in a way). It's also the source of my design codename: outback. This will be fun, but hard, especially when we want to maintain as much backwards compatibility as possible, as well as allowing the server to be useful on OS's that may lack the network calls (like epoll and kqueue) that make it "straightforward." Add in the current filter design and you can start seeing a lot of work needs to be done. But with serf, we may already have a good foundation to start off with.
More...

Daylight Savings

Posted by Jim Jagielski on Thursday, February 15. 2007 in Programming

Seems that not a day goes by when there isn't at least 1 posting on the user lists wondering if Apache and/or Tomcat are "affected" by the US Daylight Savings Time changes for 2007. As noted, this is really a OS or JVM issue, and not an Apache or Tomcat one. Regarding the JVM/JDK, you are pretty much dependent on that vendor to make sure you have the fix. However, for OS changes (for Apache and others), even if your vendor doesn't provide an official patch, you can still fix the system yourself, as I describe here in my Covalent blog.
More...

Easy to fudge

Posted by Jim Jagielski on Friday, February 9. 2007 in ASF

A few people have expressed... well... "concern" is *way* too strong a word, but maybe "curiosity" is better, regarding the latest Netcraft survey in which Apache has seen a dip and IIS has seen a jump. Make no mistake: chipping away at Apache's lead is something that MS really, really wants to do, even if it's just for the numbers game and the PR aspects. That's why they are throwing money around to several hosting centers "encouraging" them to move their parked domains to IIS. It's also why they try as many tricks as possible to drive the numbers in their direction (hint: when you own a "community" service, it's trivially easy to quickly create thousands of "new sites" that show up on these surveys). Meanwhile, the ASF does *none* of these things. People depend on Apache because they are smart and they know better, not because we're "convincing" them to do so, or doing things to fudge the numbers. Just remember, unless you are running Windows, you *aren't* running IIS. And even then, a lot of really smart people are running Apache on Windows environments as well. So "misleading" numbers also serve another goal: "proving" that Linux/Solaris/BSD/whatever aren't really as popular as people say they are: after all, if a site is IIS, it must be Windows. Of course, this smacks down right in the face of what everyone sees and admits: open source is more popular than ever, and people are either migrating to it or starting off with it. And if someone is using Linux/Solaris/BSD/whatever, then they aren't going to be using IIS; maybe not Apache, but certainly not IIS. What's more interesting to me, in addition to the fact that Apache still has a commanding "lead" (whatever that means), is the fact that people who know, people whose business depend on the web, far and away rely on Apache over IIS. Apache handles much more traffic, by far, than IIS, and the traffic of high-end, "important" sites... Apache is popular because of what it *is* , not because of anything we do to "push it." Update: counter-point
More...

Telaen steadily improving

Posted by Jim Jagielski on Thursday, February 8. 2007 in Programming

We just released the 1st release candidate for Telaen 1.1.3. Now that Uebimiau is completely dead (and its replacement has gone "commercial and proprietary"), we've been seeing quite an uptake in interest and usage in this simple yet powerful little webmail app. I'm working on a plugin implementation for Telaen which shares a lot with Apache's hook mechanism. But that won't likely be done until version 2.0.0.
More...

Business Friendly Apache License

Posted by Jim Jagielski on Monday, February 5. 2007 in Open Source

While following the current SOA Flamewar going on, I also found my way to a somewhat recent ServerSide thread regarding Terracotta's licensing, and whether it was "real" Open Source or not. This, of course, degraded to, in many postings, a Apache License vs. (L)GPL license discussion, and which was "better." In my opinion, you pick a license depending on your ultimate goals for the redistribution and usage of the software. In some cases, an AL-type license is the best choice; in others, something (L)GPL-like makes more sense. There is no one license to rule them all. Yet this distinction seems to be lost on too many people, including people who really should know better. The idea that, no matter what, one should *always* choose (L)GPL is crazy (and I use (L)GPL in this example because, almost without exception, that is the exact claim made). I like the AL, and it is my preferred license, simply because of the fewest restrictions it places on the code, the developers and the end-users. If one defines "free" as "having fewest restrictions or limitations" then an Apache-type license is "freer" than others. Look at it from another perspective, and imagine that one's license defines freedom of movement. The AL says that one can go forward and reverse, left and right and diagonal. Basically, the moves of the Queen in chess. Other licenses place restrictions on the software; limitations that affect distributors, developers, or users. They take away some freedom of movement: you can no longer go diagonally, for example. Also, I like the fact that the AL is business friendly; that it encourages the *usage* of the code by commercial entities with almost no strings attached. It's been said that the AL license is the most "business friendly" open source license around, which I would agree with. But others believe just the reverse. And by following the ServerSide thread, I was reminded of (and pointed to) Fluery's "Business Friendliness" blog entry of 2004 which makes that claim. Personally, I don't see how that could possibly be the case. Fluery claims that his example shows that AL is bad, creating forks, and (L)GPL is good because it prevents (or, at least, discourages) them. Well, IMO, the ability to create forks is a foundation of Open Source, but we'll let that slide. What is ironic is that he bashes the AL for allowing what he specifically did for Axis: taking the code and using it as he wished. He also states that he had "no professional interest in giving this code back to our competitors." But since it's under the (L)GPL, isn't it "available" anyway? And certainly wouldn't that be a valid excuse for other commercial entities to not even look at a (L)GPL implementation in the first place? And isn't it just slightly hypocritical to claim the superiority of a license that forces others to do what you specifically decided *not* to do ("give" your code to your competitors)? The AL allowed him to do exactly what he wanted with the code in his particular circumstance: use it as a basis for their implementation and then not provide any patches back to the original community; the (L)GPL would not have. It certainly would not have allowed him to relicense under the AL. If you can go from the AL to the (L)GPL, but not the reverse, I'd say that one has more degrees of freedom, wouldn't you? And recall that this was a *business* decision. Seems you have more options on which decisions are available to you with the AL, dontcha think? And look what happened: a commercial entity grew and prospered and the Open Source community did as well (Axis got better, additional Open Source projects took foot, etc...). What we see with many, many, many AL projects is that the threat of "proprietary" forking does not happen. Those commercial entities give back to the community not because they *have* to, but because they *want* to. The trust and altruism inherent in the AL is reciprocated. Sure, there are times when that doesn't happen. In which case, the hope and intent is that, by using an AL project to base your implementation on, you have no compelling need to waste resources on implementing "features" which defeat open standards. In other words, yes, you fork the code, but not the open standards and protocols that they implement... which sounds like a good deal to me. Good enough, at least.
More...

Page 1 of 1, totaling 5 entries

Quicksearch

Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!