It clearly isn't, as Windows and MacOS X - in fact, every commercial OS ever made - did not require the central repository scheme.
Yes, they did it's just at the root of the repository was a large proprietary binary blob that couldn't be changed. And, yes I can see how that makes the incomplete solution easier... but given that I can get complete solutions for less, I'll pass on your "next best thing".
Again, we know that and as we just said the fact that autopackage doesn't allow seperate privilages between the package and the package installer is a _bug_ not a _feature_.
You can run autopackages as user and install to ~/.local
Yes, well done... in a few cases I might like to do that. However 99% of the time I'll want them outside my home dir. And that still doesn't excuse you from not seperating the package installer from the package. Again with a font/background/sound/text package there should be zero security concerns, the package installer will be trusted to put things in the correct place (in my home dir. if I wish) and the package itself can't do anything. Not so with your shar reimplementation.
And with SELinux it should be possible to limit the pacakge and the package installer even further, again this isn't possible with your broken installation methodology. You are incouraging people who don't know any better to run bash scripts from the 'net, if you think people aren't going to call you on such a stupid idea, you need to think again.
If a random guy from the street tells me my house is a fire accident waiting to happen, I might be curious and ask for reasons or just say "I don't think so" and ignore him. If a guy trying to sell me fire proofing comes up to me and says that I'm going to be very suspicious, and likely not believe him no matter my opinion. If the local fire marshal says it... I'm likely going to believe him.
Thinking for yourself is all well and good, but when someone who knows what they are talking about says X then "I don't think so" is not a good response. In the same way when you say I need autopackage, given only a cursary assessment of said code... I'm going to take my pinch of salt with that, and I don't need to think very hard to do so.
The problem is that, unless you make a distinction between system and desktop, the user will be presented with a huge list with thousands of packages. If my dad wants to upgrade mune he really isn't interested in seeing glibc and qt in that list. It's more a user interface problem.
And you still have to solve this problem when I distribute an epoll using application to a system using a glibc that doesn't have the epoll symbol. And this is such an obvious UI issue, I dearly hope you have a better example than this for why you screwed the pooch.
If X requires Y, you can't just pretend otherwise and say "not our problem we just do desktop apps".
The plugins should be upgradable too. But what prevents you from doing that?
It's the same problem, you have X provided by you and Y provided by the distribution... you can either: 1) hope version of Y is compatible. 2) upgrade Y when required. 3) always provide your own version of Y.
Only option 2 works, and autopackage seems to think that not doing option 2 but a mixture of 1 and 3 is a feature. Back in the real world bugs aren't features.
They don't like us because they want to centralize software packaging.
Nobody wants that, but it's basically required. You can't solve the "I need to install mod_foobar, which requires Apache-httpd-2.2.0" problem without understanding what Apache-httpd is and what version you have, and how you get from here to there... which requires a single way to query all software. This doesn't mean it can't be distributed, like DNS, just that you can't pretend you can have two roots and everything will be fine (or even blame those nasty root server operators for telling you otherwise when you try).
Untrusted source? Is the upstream developer an untrusted source? If he cannot be trusted, then why would one trust third party Gentoo packages?
Say you're installing a GNOME theme, it's basically just XML+pngs... then assuming the installer is secure, there is no reason you can't just install this "package" from anywhere and try it out. The same is true with installing backgrounds, or documentation etc. (think CIA. world factbook).
With aribtrary binary applications this is somewhat muddier, but there is still a deliniation between trusting the package and trusting the package installer (the later of which likely needs more privilages).
For instance "conary" is one of the newer package management ideas, and to them packages are basically just collections of files which are tagged (Ie. doc/bin/shared-library). Installing/removing a package has basically zero security concerns.
The biggest problem IMO is that their claim that "the Autopackage team believes that managing system and desktop software together is a mistake", this is just obviously wrong. Every Linux distro. is essentially component based, it's just not possible to say ok "here" is the line in the sand.
I'm just as likely to want to upgrade postgresql, as get "muine"... and if I upgrade muine, what about my installed plugins?... what about if I have a distro. muine installed and want a plugin that requires a newer version of muine?
Also AFAICS their security errata story is basically non-existant atm.... which is the final nail in the coffin.
Would you then say that http should support e.g. video straming?
It does... or at least you can abuse chunked encoding in HTTP/1.1 to do a constant stream of data without any changes to a normal HTTP server/client.
I can imagine that there might be better specific protocols, for quality control etc. although those can probably be hacked in using extra extension headers.
Are you asking if I think it's the best protcol to start from... hard to say, if you had no other constraints then I'd probably go for using a seperate protocol. But I can imagine there are cases where you'd want to go with something over HTTP.
Huh? Is it not just a question of knowing the commands for either?
I was trying to think of why you would be preferrring FTP over HTTP, HTTP is simpler on a basic level... and works at least as well as FTP. About the only advantage of FTP is that it has a defined way to get directory listings. But this doesn't help when you want to download one big file (and can be a disadvantage, no common FTP server lets you drop 3 files into one directory, giving URLs to different people without everyone being able to see all files).
The point is there are various protocols designed especially for transferring files
And HTTP is one of them, my web server currently _only_ transfers files. I can somewhat agree with "use the right protocol for the job" but when you are talking about transfering a static block of data HTTP _is_ the right tool, or at least the first one I'd try given no other constraints.
http which seems to be pretty much a general-purpose protocol these days.
I can sympathize, HTTP has been made to do a lot of things... but I think this is somewhat inevitable. Designing a protocol is hard, testing/debugging more so... if you can get that for free that's a big saving.
DNS can't support LFS tyep sizes, you would actually need to change the protocol. HTTP on the other hand has worked fine with LFS for a _long_ time, just not if you are using apache-httpd.
And as another webserver author, I can give you a couple of reasons for using HTTP over FTP:
Caching proxies, esp. helpful at large organisations where many people will be requesting the same data
proxies... often it's the _only_ way out of the network (well you can somtimes do FTP over HTTP).
at a protocol level, HTTP is at least as efficient/suitable as FTP for transfering files of any size... indeed you could easily do the HTTP by hand, this is _much_ harder with FTP
You still get the other benifits of HTTP, like content negotiation (like getting avi/mpeg or zip/gz/bzip2 depending on which you'd prefer) and caching (Ie. ETag)
If anything is more "suitable" for large transfers it'd probably be bittorrent, not FTP... but even then bittorrent has one plus but fails most of the above
Open Source authors tend to be rather bad about listening to their user base- the snotty answer is "if YOU want it to do X, then code it yourself", and many times reported bugs that are annoying current users are put off or ignored, often because the development version is almost ready to go stable, and fixing the bug would be "a pain".
Open Source is not a religion, Open Source is not a social way of life and Open Source is not a development methodology... all it signifies is that you can see and alter the source to some degree Many companies provide services for Open Source projects, and I can guarantee that if you goto Sun, Novel or Red Hat with a large pile of money and say "I want X" they will be happy to provide that service for you. If you only want to spend a small amount of money, then expect similar treatment from any proprietary software company... of course with the later you have no other options if they refuse.
Oh... you meant you wanted it for zero cost, like maybe you imagine this slave state of Open Source people where we all jump to do your bidding? That's certainly an interesting perspective, and I can see how you get disappointed.
And, yes, if you ask nicely for a feature that can be implemented well in an Open Source project you'll often get it for relativly zero cost (just the price of asking nicely and waiting)... however this isn't the same as paying for a service, or expecting a slave state to do your bidding.
I always re-compile Gnome without assertions, and the speedup is noticable.
You mean you disable all the g_assert()/etc. stuff?... do you have any numbers for this as I know when I asked GNOME people at redhat they were convinced that it wasn't noticable.
First of all, it doesn't perform better than apache. It uses less memory than apache to serve many static files. Apache performs very well if configured correctly [... snip...]
Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face.
My reaction was mainly based on the fact that it gets old fast when people start saying "My HTTPD is super fast, see this perf. comparison against Apache-httpd"... it's basically the exact same stuff from at least the 1999 paper (I'm sure there were referneces before, but 6 years old is enough for/.) "Performance Issues in WWW Servers".
As, I believe, I said before though multiple apache-httpd developers have said that speed/scalability/etc. isn't a driving force... so it not being good isn't really a failure.
Second, yes [it's probably insecure] but [you could work around it with defense in depth] and [it's about as good as apache].
I don't disagree with any of that... but the above implies that having defense in depth means you get a free pass to have one of the layers be bad. That's like saying because A-random-webserver is behind a firewall that understands HTTP and rejects bad requests it's now OK that it's a security nightmare. But we might just be agreeing vemenantly here.
Third, does your webserver support any of the stuff lighttpd does, or is it just like thttpd (not terribly useful)?
Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later:).
To possibly answer your question, And-httpd doesn't support CGIs or FastCGI yet... so you might well think of it as "not terribly useful".
And finally, where is this buffer overflow exactly?
One of the lighttpd developers emailed me within a few hours of posting, so it's fixed in the latest CVS anyway.
Saying that web server performance is better than Apache-httpd is like saying fish can swim better than dogs, it's true... but pretty meaningless. Apache-httpd developers have publicly stated that they don't consider performance a design goal, and their email server is actually Apache-httpd in disguise.
As for lighttpd being "secure" it had a problem this year where you could bypass checks by using the NIL byte encoded. As a web server author I can only say "Like, Duh!"... and after taking a 10 minute grep[1] of 1.4.7 I can see a buffer overflow already, I'm not sure how easy it is for a normal user to do (and it's only a couple of bytes) but I don't care too much either. The obvious DOS is there for the Range header, and the symlink "protection" is smoke and mirrors (stat check followed by a non-checked open()).
It also doesn't seem to support Accept/Accept-Language negotiation, which I thought was pretty weird (feel free to disagree).
Obviously I'm somewhat biased, given that I've writen my own, but then I do have a "security guarantee" with it.
[1] For anyone who does care do a strncpy grep in http_auth.c (I looked at version 1.4.7)
Don't blindly try for ~100% coverage (you'll never get it anyway)
Neer, neeer... *cough*, sorry about that. Of course, I also have a monetary reward for remote holes in my webserver... so I'm probably not that normal:)).
Typical distros that support pervasive no-reboot updating (like Debian) don't exactly replace a "running" libc (or any other library), they simply update the on-disk copy. ...
Usually this works very well
Actually... not so much. nss is the biggest problem, but a bunch of glibc interfaces aren't guaranteed to work across updates like this, including anything using iconv and locales. Pretty much all distros. that "support" large updates without a reboot just ignore this problem in the general case (debian has hacks that help, if all the stars align).
But then a similar problem is the real ABI of glibc changing, and programs going from working to not working because of it (this is against the theoretical ABI that "is compatible")... all of the distros. also ignore this problem.
You don't think we need MX records? Hell I think you'd have a _HUGE_ problem getting rid of CNAMEs. I can sort of understand wanting SRV records for everything, but that's been around for a while too and hasn't exactly been taken up in droves.
Also it has a problem that the choice is too simplistic, for instance there's only a place for one _webcache._tcp.and.org where most applications allow different caches for http, https and ftp... plus exceptions. Well there's also the problem that basically zero clients do anything with it.
IPV6's also has a big problem due to lack of available testing, for instance my webserver refuses to do IPV6 because I don't have access to an IPV6 network to make sure it actually works (even though I'm pretty sure it's a simple change).
Bar none, if you want to write something portable, Java is the language to use. It has the incredibly complete and mature libraries, performance is excellent, tool support with IDE's and app servers and source repositories is fabulous, and it is designed to be cross platform!
I've seen a bunch of quotes like this, and all I can think is that there must be a lot of people writting crap. For instance, you can't even write a correct version of rm... Java just doesn't support the APIs you need to call to do it well. Yes, you can do a crap version that has security problems and that'll be buggy everywhere... Most people have been able to write code that doesn't work everywhere in C for a long time.
Small businesses go out of business all the time. The average lifespan is far less than 10 years. It's a very convienent excuse for them to tell people that "WalMart forced them out of business". Sounds a lot better than "I misjudged the market, mismanaged the shop, and totally fucked up".
True, but then you have economists that don't agree with you. I think it's a lot easier to be dead when Walmart moves into the neighbourhood.
On the other side of the fence, I can't really bring myself to care too much... they are just doing everything possible to compete on price, and the other businesses either aren't offering anything else to compensate (for instance, decent organic foods or well crafted furniture isn't loseing to Walmart) or just aren't as good at competing on price (this is also known as stupidity).
See the link I posted, AIUI you can't use a trigger if you might ever need to put a value in manually... whereas this "just works" in PostgreSQL (and AIUI in MySQL), by when you insert without a seq you get a new one and when you insert with a seq it uses that.
What database requires this? Every database I've ever used has an efficient, documented method of getting the automatically generated ID.
Yeh, I was pretty surprised when I read a blog entry recently about this "feature" of
Oracle. From what I could see it's basically identical to the PostgreSQL behaviour... but you can't link to seq.next directly to the column and then select on seq.last_value.
I can emerge several different vi derivatives and they all answer to 'vi'.
It's not the only thing too that's annoyingly different in linux:
* most distros complain that nslookup 'depreciated' and should use dig - nslookup is still the standard on other UNIXes.
* head and tail complain that should be using the -n argument instead of the normal "head -#" like UNIX has had for decades. Why???
Both of these points tell me that gentoo is crap, and that you don't seem to understand why "paying money for Solaris" and "not paying money for Linux" are giving you a different expereicne. It's like the people installing debian stable and then complaining that desktop Linux is horrible, sorry I have no pity for you... in the words of Radiohead "You do it to yourself, you do, and that's what really hurts".
I have to say that I cringe every time I see a MySQL story on slashdot these days, because it just seems like there is a legion of PostgreSQL zealots just waiting for any chance to denigrate MySQL. It's the same littany every time - PostgreSQL is so much better, have they fixed the "Gotchas" yet, etc etc. Even when MySQL AB adds a feature or does fix some perceived failing, then the detractors simply ignore this and move on to some other apparent showstopper. For example, it's not enough that MySQL has transactional capabilities - no, now they simply moan that it's not the default (MyISAM still is).
The problem is popularity, a lot of people are using MySQL... and are learning to view the world in a very different way than if they'd used a real RDBMS. Think of it like Basic on win32... sure people who knew what they were doing could write things well in it, and you can even argue that it was the right tool for the job. But with them a huge amount of people started writing programs in Basic, that are now unmaintainable nightmares.
The same is true if you look at DB based apps. most of the ones that support MySQL use very simple queries (and usually _lots_ of them, instead of a single query with a JOIN or three)... no VIEWs, no FORIEN keys, no transactions and likely no NOT NULL constraints etc. etc.
Sure, they may "work"... but there's no way I'd want to have to maintain that crap. And while this isn't all MySQL's fault, they are certainly reaping the rewards from doing this... so I don't feel bad about giving them the downsides by mentally associating [using MySQL DB] == [retards].
A good start to our current security problem would be to stop writing internet based software in languages that allow buffer overflows to occur (e.g. C, C++). [...] Writing computer programs in these types of languages and patching the errors as they are found is simply not a scalable solution. It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains
This is a huge over reaction, although tends to be happening anyway... for other reasons (mainly because it's cheaper). I'll repeat what I've said before writing with a real string type in C, is not hard... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers).
Of course I'm also backing up my retoric with a $500 security guarantee, on my webserver that's written using only a real string type... in C. Also AFAIK the only software in the OSS community that have offered such guarantees have all been written in C (and all with real string types).
90% of security exploits are caused by buffer overflows. I've seen a figure like this in research papers, but it should be obvious to anyone from reading patch descriptions and current security alters
This may have been true but is now false, and has been for years. Even if you take into account integer overflows etc. that can be mitigated by real string types, it maxes out around 60%. I do have some stats. I did myself, from 2003... and I've seen other more recent ones which say the same thing (I don't own them though, and I'm not sure they are public).
This all seems to be a rehash of the "worse is better" meme... that those damn software programers/companies aren't doing what we want. The only problem is, it's all crack. Almost no customers, even now, are willing to pay more for "quality".
Yes, I think all other things being equal, people will go towards quality/security... but it just isn't high on anyones list. Cheap, features, usable... and maybe quality comes in fourth, maybe.
And, yes, there are exceptions... NASA JPL obviously spend huge amounts of money to get quality at the expense of everything else, and I say this having written my own webserver because apache-httpd had too many bugs (which comes with a security guarantee against remote attacks)... but I'm not expecting people to migrate in droves from apache-httpd, it's got more features. The 90%+ market share have spoken, consistently, and they just don't care about the same things Bruce and I do.
I have a lot of respect for Bruce, but the companies really are just producing what most people want... so stop blaming them.
They give a valid reason for not caching all the links. Your UID is low enough that I expect you know about the FAQ. Did you know that they address this?
Last Modified: 6/14/00
Five years old, and only a year after rfc2616 was released (and when bittorrent didn't exist at all). Ok, I could grant that as a plausible answer at the time... but now? We've had ETag's and Cache-Control for a _significant_ amount of time (and Expires for longer).
If the site doesn't send Cache-control it can resonably be assumed that they don't mind you caching the data, sure most sites still don't give ETag data, but then Last-Modified should still be good enough.
Hell even if they only did it for sites that send out ETag's it'd at least mean there was a simple way out when you had a site on DSL with 50kbits upload on the front page, as it stands now you are basically screwed.
I sure hope you don't work for NASA or a nuclear power plant or anyplace else where software correctness is important
There is a big difference between "important", which is what I'd describe the status of quality of a significant amount of software as, and "kills people if you fail". The later is often developed very differently, and with much more expense than any other typ0e of software... NASA's JPL does lots of things that's just not affordable to do elsewhere.
A bug that you can't easily detect is still a bug, and under the right conditions it can bite people
I agree, but a memory leak if it is there at all usually happens slowly... so if you see it, it's not hard to fix... and if you don't (because, say, the application doesn't get run for long enough for it to matter) who cares.
The problem is that not every C/C++ programmer is as conscientious as you are. (neither is every Java programmer; but then, they don't need to be)
They don't need to care "some" of the time, often when you need to release resources you need to do other things... if you've layed out your code well, doing both isn't hard... if not then doing either can be hard. Yes, having destructors/dispose helps some... but even then it can't save them if they don't unlink the objects from the heap properly (and sometimes doesn't save them anyway, when using a limited number of resources, like DB connections).
Basically writting code well, is always the best defence:). I just don't see leak protection helping "the others" much... although, I'd probably agree that memory protection can help everyone quite a bit, and helps "the others" a lot. But even then, I see those problems only very rarley even in C.
Slashdot Mirror
Yes, they did it's just at the root of the repository was a large proprietary binary blob that couldn't be changed. And, yes I can see how that makes the incomplete solution easier ... but given that I can get complete solutions for less, I'll pass on your "next best thing".
Again, we know that and as we just said the fact that autopackage doesn't allow seperate privilages between the package and the package installer is a _bug_ not a _feature_.
Yes, well done ... in a few cases I might like to do that. However 99% of the time I'll want them outside my home dir. And that still doesn't excuse you from not seperating the package installer from the package. Again with a font/background/sound/text package there should be zero security concerns, the package installer will be trusted to put things in the correct place (in my home dir. if I wish) and the package itself can't do anything. Not so with your shar reimplementation.
And with SELinux it should be possible to limit the pacakge and the package installer even further, again this isn't possible with your broken installation methodology. You are incouraging people who don't know any better to run bash scripts from the 'net, if you think people aren't going to call you on such a stupid idea, you need to think again.
If a random guy from the street tells me my house is a fire accident waiting to happen, I might be curious and ask for reasons or just say "I don't think so" and ignore him. If a guy trying to sell me fire proofing comes up to me and says that I'm going to be very suspicious, and likely not believe him no matter my opinion. If the local fire marshal says it ... I'm likely going to believe him.
Thinking for yourself is all well and good, but when someone who knows what they are talking about says X then "I don't think so" is not a good response. In the same way when you say I need autopackage, given only a cursary assessment of said code ... I'm going to take my pinch of salt with that, and I don't need to think very hard to do so.
And you still have to solve this problem when I distribute an epoll using application to a system using a glibc that doesn't have the epoll symbol. And this is such an obvious UI issue, I dearly hope you have a better example than this for why you screwed the pooch.
If X requires Y, you can't just pretend otherwise and say "not our problem we just do desktop apps".
It's the same problem, you have X provided by you and Y provided by the distribution ... you can either: 1) hope version of Y is compatible. 2) upgrade Y when required. 3) always provide your own version of Y.
Only option 2 works, and autopackage seems to think that not doing option 2 but a mixture of 1 and 3 is a feature. Back in the real world bugs aren't features.
Nobody wants that, but it's basically required. You can't solve the "I need to install mod_foobar, which requires Apache-httpd-2.2.0" problem without understanding what Apache-httpd is and what version you have, and how you get from here to there ... which requires a single way to query all software. This doesn't mean it can't be distributed, like DNS, just that you can't pretend you can have two roots and everything will be fine (or even blame those nasty root server operators for telling you otherwise when you try).
Say you're installing a GNOME theme, it's basically just XML+pngs ... then assuming the installer is secure, there is no reason you can't just install this "package" from anywhere and try it out. The same is true with installing backgrounds, or documentation etc. (think CIA. world factbook).
With aribtrary binary applications this is somewhat muddier, but there is still a deliniation between trusting the package and trusting the package installer (the later of which likely needs more privilages).
For instance "conary" is one of the newer package management ideas, and to them packages are basically just collections of files which are tagged (Ie. doc/bin/shared-library). Installing/removing a package has basically zero security concerns.
The biggest problem IMO is that their claim that "the Autopackage team believes that managing system and desktop software together is a mistake", this is just obviously wrong. Every Linux distro. is essentially component based, it's just not possible to say ok "here" is the line in the sand.
I'm just as likely to want to upgrade postgresql, as get "muine" ... and if I upgrade muine, what about my installed plugins? ... what about if I have a distro. muine installed and want a plugin that requires a newer version of muine?
Also AFAICS their security errata story is basically non-existant atm. ... which is the final nail in the coffin.
It does ... or at least you can abuse chunked encoding in HTTP/1.1 to do a constant stream of data without any changes to a normal HTTP server/client.
I can imagine that there might be better specific protocols, for quality control etc. although those can probably be hacked in using extra extension headers.
Are you asking if I think it's the best protcol to start from ... hard to say, if you had no other constraints then I'd probably go for using a seperate protocol. But I can imagine there are cases where you'd want to go with something over HTTP.
I was trying to think of why you would be preferrring FTP over HTTP, HTTP is simpler on a basic level ... and works at least as well as FTP. About the only advantage of FTP is that it has a defined way to get directory listings. But this doesn't help when you want to download one big file (and can be a disadvantage, no common FTP server lets you drop 3 files into one directory, giving URLs to different people without everyone being able to see all files).
And HTTP is one of them, my web server currently _only_ transfers files. I can somewhat agree with "use the right protocol for the job" but when you are talking about transfering a static block of data HTTP _is_ the right tool, or at least the first one I'd try given no other constraints.
I can sympathize, HTTP has been made to do a lot of things ... but I think this is somewhat inevitable. Designing a protocol is hard, testing/debugging more so ... if you can get that for free that's a big saving.
DNS can't support LFS tyep sizes, you would actually need to change the protocol. HTTP on the other hand has worked fine with LFS for a _long_ time, just not if you are using apache-httpd.
And as another webserver author, I can give you a couple of reasons for using HTTP over FTP:
Open Source is not a religion, Open Source is not a social way of life and Open Source is not a development methodology ... all it signifies is that you can see and alter the source to some degree Many companies provide services for Open Source projects, and I can guarantee that if you goto Sun, Novel or Red Hat with a large pile of money and say "I want X" they will be happy to provide that service for you. If you only want to spend a small amount of money, then expect similar treatment from any proprietary software company ... of course with the later you have no other options if they refuse.
Oh ... you meant you wanted it for zero cost, like maybe you imagine this slave state of Open Source people where we all jump to do your bidding? That's certainly an interesting perspective, and I can see how you get disappointed.
And, yes, if you ask nicely for a feature that can be implemented well in an Open Source project you'll often get it for relativly zero cost (just the price of asking nicely and waiting) ... however this isn't the same as paying for a service, or expecting a slave state to do your bidding.
You mean you disable all the g_assert()/etc. stuff? ... do you have any numbers for this as I know when I asked GNOME people at redhat they were convinced that it wasn't noticable.
Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection ... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face.
My reaction was mainly based on the fact that it gets old fast when people start saying "My HTTPD is super fast, see this perf. comparison against Apache-httpd" ... it's basically the exact same stuff from at least the 1999 paper (I'm sure there were referneces before, but 6 years old is enough for /.) "Performance Issues in WWW Servers".
As, I believe, I said before though multiple apache-httpd developers have said that speed/scalability/etc. isn't a driving force ... so it not being good isn't really a failure.
I don't disagree with any of that ... but the above implies that having defense in depth means you get a free pass to have one of the layers be bad. That's like saying because A-random-webserver is behind a firewall that understands HTTP and rejects bad requests it's now OK that it's a security nightmare. But we might just be agreeing vemenantly here.
Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides ... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later :).
To possibly answer your question, And-httpd doesn't support CGIs or FastCGI yet ... so you might well think of it as "not terribly useful".
One of the lighttpd developers emailed me within a few hours of posting, so it's fixed in the latest CVS anyway.
Saying that web server performance is better than Apache-httpd is like saying fish can swim better than dogs, it's true ... but pretty meaningless. Apache-httpd developers have publicly stated that they don't consider performance a design goal, and their email server is actually Apache-httpd in disguise.
As for lighttpd being "secure" it had a problem this year where you could bypass checks by using the NIL byte encoded. As a web server author I can only say "Like, Duh!" ... and after taking a 10 minute grep[1] of 1.4.7 I can see a buffer overflow already, I'm not sure how easy it is for a normal user to do (and it's only a couple of bytes) but I don't care too much either. The obvious DOS is there for the Range header, and the symlink "protection" is smoke and mirrors (stat check followed by a non-checked open()).
It also doesn't seem to support Accept/Accept-Language negotiation, which I thought was pretty weird (feel free to disagree).
Obviously I'm somewhat biased, given that I've writen my own, but then I do have a "security guarantee" with it.
[1] For anyone who does care do a strncpy grep in http_auth.c (I looked at version 1.4.7)
Neer, neeer ... *cough*, sorry about that. Of course, I also have a monetary reward for remote holes in my webserver ... so I'm probably not that normal :)).
Actually ... not so much. nss is the biggest problem, but a bunch of glibc interfaces aren't guaranteed to work across updates like this, including anything using iconv and locales. Pretty much all distros. that "support" large updates without a reboot just ignore this problem in the general case (debian has hacks that help, if all the stars align).
But then a similar problem is the real ABI of glibc changing, and programs going from working to not working because of it (this is against the theoretical ABI that "is compatible") ... all of the distros. also ignore this problem.
You don't think we need MX records? Hell I think you'd have a _HUGE_ problem getting rid of CNAMEs. I can sort of understand wanting SRV records for everything, but that's been around for a while too and hasn't exactly been taken up in droves.
Also it has a problem that the choice is too simplistic, for instance there's only a place for one _webcache._tcp.and.org where most applications allow different caches for http, https and ftp ... plus exceptions. Well there's also the problem that basically zero clients do anything with it.
IPV6's also has a big problem due to lack of available testing, for instance my webserver refuses to do IPV6 because I don't have access to an IPV6 network to make sure it actually works (even though I'm pretty sure it's a simple change).
I've seen a bunch of quotes like this, and all I can think is that there must be a lot of people writting crap. For instance, you can't even write a correct version of rm ... Java just doesn't support the APIs you need to call to do it well. Yes, you can do a crap version that has security problems and that'll be buggy everywhere ... Most people have been able to write code that doesn't work everywhere in C for a long time.
True, but then you have economists that don't agree with you. I think it's a lot easier to be dead when Walmart moves into the neighbourhood.
On the other side of the fence, I can't really bring myself to care too much ... they are just doing everything possible to compete on price, and the other businesses either aren't offering anything else to compensate (for instance, decent organic foods or well crafted furniture isn't loseing to Walmart) or just aren't as good at competing on price (this is also known as stupidity).
See the link I posted, AIUI you can't use a trigger if you might ever need to put a value in manually ... whereas this "just works" in PostgreSQL (and AIUI in MySQL), by when you insert without a seq you get a new one and when you insert with a seq it uses that.
Yeh, I was pretty surprised when I read a blog entry recently about this "feature" of Oracle. From what I could see it's basically identical to the PostgreSQL behaviour ... but you can't link to seq.next directly to the column and then select on seq.last_value.
Both of these points tell me that gentoo is crap, and that you don't seem to understand why "paying money for Solaris" and "not paying money for Linux" are giving you a different expereicne. It's like the people installing debian stable and then complaining that desktop Linux is horrible, sorry I have no pity for you ... in the words of Radiohead "You do it to yourself, you do, and that's what really hurts".
The problem is popularity, a lot of people are using MySQL ... and are learning to view the world in a very different way than if they'd used a real RDBMS. Think of it like Basic on win32 ... sure people who knew what they were doing could write things well in it, and you can even argue that it was the right tool for the job. But with them a huge amount of people started writing programs in Basic, that are now unmaintainable nightmares.
The same is true if you look at DB based apps. most of the ones that support MySQL use very simple queries (and usually _lots_ of them, instead of a single query with a JOIN or three) ... no VIEWs, no FORIEN keys, no transactions and likely no NOT NULL constraints etc. etc.
Sure, they may "work" ... but there's no way I'd want to have to maintain that crap. And while this isn't all MySQL's fault, they are certainly reaping the rewards from doing this ... so I don't feel bad about giving them the downsides by mentally associating [using MySQL DB] == [retards].
This is a huge over reaction, although tends to be happening anyway ... for other reasons (mainly because it's cheaper). I'll repeat what I've said before writing with a real string type in C, is not hard ... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers).
Of course I'm also backing up my retoric with a $500 security guarantee, on my webserver that's written using only a real string type ... in C. Also AFAIK the only software in the OSS community that have offered such guarantees have all been written in C (and all with real string types).
This may have been true but is now false, and has been for years. Even if you take into account integer overflows etc. that can be mitigated by real string types, it maxes out around 60%. I do have some stats. I did myself, from 2003 ... and I've seen other more recent ones which say the same thing (I don't own them though, and I'm not sure they are public).
This all seems to be a rehash of the "worse is better" meme ... that those damn software programers/companies aren't doing what we want. The only problem is, it's all crack. Almost no customers, even now, are willing to pay more for "quality".
Yes, I think all other things being equal, people will go towards quality/security ... but it just isn't high on anyones list. Cheap, features, usable ... and maybe quality comes in fourth, maybe.
And, yes, there are exceptions ... NASA JPL obviously spend huge amounts of money to get quality at the expense of everything else, and I say this having written my own webserver because apache-httpd had too many bugs (which comes with a security guarantee against remote attacks) ... but I'm not expecting people to migrate in droves from apache-httpd, it's got more features. The 90%+ market share have spoken, consistently, and they just don't care about the same things Bruce and I do.
I have a lot of respect for Bruce, but the companies really are just producing what most people want ... so stop blaming them.
Five years old, and only a year after rfc2616 was released (and when bittorrent didn't exist at all). Ok, I could grant that as a plausible answer at the time ... but now? We've had ETag's and Cache-Control for a _significant_ amount of time (and Expires for longer).
If the site doesn't send Cache-control it can resonably be assumed that they don't mind you caching the data, sure most sites still don't give ETag data, but then Last-Modified should still be good enough.
Hell even if they only did it for sites that send out ETag's it'd at least mean there was a simple way out when you had a site on DSL with 50kbits upload on the front page, as it stands now you are basically screwed.
There is a big difference between "important", which is what I'd describe the status of quality of a significant amount of software as, and "kills people if you fail". The later is often developed very differently, and with much more expense than any other typ0e of software ... NASA's JPL does lots of things that's just not affordable to do elsewhere.
I agree, but a memory leak if it is there at all usually happens slowly ... so if you see it, it's not hard to fix ... and if you don't (because, say, the application doesn't get run for long enough for it to matter) who cares.
They don't need to care "some" of the time, often when you need to release resources you need to do other things ... if you've layed out your code well, doing both isn't hard ... if not then doing either can be hard. Yes, having destructors/dispose helps some ... but even then it can't save them if they don't unlink the objects from the heap properly (and sometimes doesn't save them anyway, when using a limited number of resources, like DB connections).
Basically writting code well, is always the best defence :). I just don't see leak protection helping "the others" much ... although, I'd probably agree that memory protection can help everyone quite a bit, and helps "the others" a lot. But even then, I see those problems only very rarley even in C.