All I'm trying to say is that Debian's distributions should be named to reflect the actual usage patterns. I apologize if you think I can't and shouldn't use Testing as my desktop distribution, but I _do_, as do others. Currency is dangerous -- but it's nice to have the choice.
I may not have explained well, having "current" packages brings it's own problems... but most people who would care know how that goes (even comming from the win32 world). The problem is that, for example, the cvs security errata earlier this year took a few more days to come out for unstable as it did for stable... but it took over 3 months IIRC to get into testing. Therefore recommending "normal" people use testing is not going to help debian, IMO. Obviously you, and your friends, can use it... I presume you know what you are doing... it just isn't a general solution like "fedora", mandrake, etc. etc.
Pardon me if I sound a little harsh in my rebuttal, but you have done an excellent job of summarizing the most common arguments of the anti-Debian camp.
So if I point out a flaw in debian then I'm "anti-debian", I guess then all the people pointing out flaws in the US just attacking whoever it feals like really are "anti-american".
It just so happens that the "current" distro is called "Testing."
No, there isn't (at least not how you are implying). There is a testing distro called "testing". It doesn't provide security updates, and things have to be "tested" before they get there. You cannot and should not use it is a regular distro. like mandrake/fedora etc. It is much like FreeBSD cusrrent, but I assume you meant it more like saying "fedora has current packages"... which also isn't true enough at times, it's just much closer to the truth.
You can have stable, or you can have bleeding-edge. Debian gives you both options (three, actually).
That's not true. If you have a server OS, then you can use "stable" and it is likely to be what you want (assumnig you don't need a feature from this millenium). As far as "unstable" and "testing" go... neither provide security errata. and are thus useless for normal people. Unstable can be ok for the very experienced Linux user who is watching bugtraq.
Your comment also implies that 1) all applications are created equally and 2) debian "stable" means that the apps. are guaranteed to work.
Where it seems obvious to me that I might want MozillaFirebird (comming soon in 2006 to a debian stable near you), but not want to move from apache httpd-1.3.x... everyone gets this wrong IMO, it's just debian's choices make it the most painful. Also "stable" doesn't mean working, it means not changing... so if you have a bug with something in stable (something I've experienced), then it just won't get fixed "by design" because it's unchanging and any change might break something for someone else (this is ignoring times when debian gave up, like the bind9 security upgrade).
Why do you use stable? I mean, really?
You can just go with testing, it's a lot more stable and consistent than your typical distrib
Because all snae people want security updates. stable provides them, unstable doesn't but you are "likely" to have new packages "soonish". Testing doesn't and sometimes it takes months before a new package gets in there.
I think an important Perens quote from the article is:
"UserLinux would only depart from Debian for software that is not open source"
so, UserLinux will be Debian + proprietary software. A dissapointing step back in my opinion.
A step back from what? Right now most US companies running a supported Linux in the enterprise are running Red Hat Enterprise Linux, and it comes with (or with support for) all the products they need, Ie. Java, Oracle, PowerPath, etc. etc. etc.
This is the same "argument" that RMS uses, Ie. It's better to have nothing than something. Life doesn't work like that, people always go for the path of least resistance. Hell even debian wasn't stupid enough to not have "netscape" available when that proprietry and the only real browser. Saying "It's not free" doesn't solve the problem of "I need, now" (and "need" is relative, some people "need" to be able to play proprietry games, etc.).
And many technical solutions being proposed are no better - certificate based SMTP is a perfect example. You too can pay Verisign a grand a year for the privilege of having other mail servers talk to yours. Oh, and of course, they'll *never* let spamhauses get certs, either!
You don't need a central auth. And it doesn't need to cost that much. All that's needed is something to auto-pgp everyone's email. Then when I can put email from everyone I know where it belongs, unsigned stuff somewhere I'll look at every now and again and signed stuff can be decided if it's really someone who wants to speak to me or a spammer (this can be helped with web of trust type schemes).
Obviuosly as/if people implement it only the spam will be unsigned, which will make email (as we know it today) obsolete... as it'll need to be signed for anyone to read it.
Even for fairly large traffic mailing lists like lkml you will only need a few hundred keys for 99% of the traffic.
I will agree that a lot of crappy stuff has been done in Flash. There's also a lot of crappy books/webpages/slashdot posts that have been written,
The difference is the level of control, esp. on Linux. Java, EMCAScript and Flash or have very poor control facilities (EMCAScript is getting somewhat better, but I'd still turn it off). Flash can be nice (homesteader comes to mind -- but this is more a comment on the quality of video players than anything), but it's use for banner adds or for frontpages is very annoying.
Something like technial illustrations on a website would be a perfect example
So you don't think it would be better as a dia/visio file?
For most usage SVG should nicly replace it, for the portable vector video we're probably stuck with it for a while:(.
Try getting funding from a bank. Tell them the core applications you're working with come with no warranty and no support. See how much they increase your line of credit!
So how many people have sued Microsoft for costing them millions due to SoBig etc.?... so how many banks will give funding if you say "Well our core software doesn't work, but hey it's from MS so they are acountable"? Replacing MS with some random other firm will not inspire anymore confidence, I think. Banks/VCs are much more likely to give funding if you can say "we have access to the source for all our core software" than if you can't.
Legal acountability for comercial software vendors is a fiction. However if you wish to play "lets pretend", then you can get this same fiction from Red Hat, Novell etc. You sign a piece of paper, it says "you will pay X" and "we will be acountable in X ways".
But this isn't anything to do with accountability, it's to do with service agreements... accountability is how often you need them. Or at the extreme, you can say "this works". However, very few pieces of software come with that kind of accountability.
So, the worms are not the worm writers' faults, but actually Microsoft
I know you're just trolling, but unfortunately a lot of people really believe this. It's like blaming homeowners for burglary.
But it's more like if I take all my valuable goods, stick it in a box, put it in the middle of Central Park and then go home. Sure, in a perfect world, I could count on it being there when I get back tomorrow... however in reality no sane person would.
Really putting thirteen year olds in prison for longer than they've been alive isn't going to solve anything.
Uh, ours does. In fact, we test every piece of code that goes to a customer on a dozen different hardware pieces, we have a unit of each model of printer that we've okayed for use (some 30 or 40 units) and for big releases we deal with several large beta customers before release.
And our company only employs 20 people. Every minute spent testing is a minute we could be making a new product...but supporting the old stuff is what makes us so popular with the customers we have, and it's why they pay support costs every year and buy our new stuff when it comes out.
In fact, now that I think about it, every company I've worked with since I started my professional career had a very serious and very adept quality team on our side. Most of the time they were structured in such a way that QA was working actively AGAINST the release of any software...playing a sort of programmatic Spy vs. Spy with the developers. The result is stronger software faster, which contributes to the bottom line.
Oh, my. Where do you work? Far to many places I've worked at companies the QA has been something that people assume the programer does (mostly for internal code)... or they have a QA team, but it is "controlled" by the engineering managers. One very large company I worked for had a seperate QA dept. however if they found any bugs that they thought should hold up a release (and they had 3 days to do it in) then they had to ask the development dept. to stop the code from shipping. No matter what the bug, they were powerless to do anything. Of course the same dept. had no unit tests and used "RCS" for version control.
I *LIKE* open source, but the existing mechanisms for testing are really terrible, even if the bug repair response can be great. And since there's no accountability, there's little enforcement for responsibility
This isn't true, my goddamn name is in the authors file and the web site etc. Not some nameless corporation. I am completely accountable, which is why Vstr has over 98% code coverage and the test suite is almost half the size of the code. This is very unlike when I work on code inside a company, where often can we deploy it is the only question asked and time just isn't allocated to do it to the same level of quality. It would probably be more fair to say that OSS is often more concentrated in it's accountability.
Congratulations, that was one of the most brilliant pieces of flamebait I've ever seen or read. It had everything
It wasn't bad, I'm not sure whether it was a troll or stupidity. However, assuming it was a troll, as with all good trolls there were grains of truth in it...
I don't know of a single open-source / free software project that doesn't use version control.
Really? Well, I don't use anything more than diff and tarballs of releases. Linus didn't have a public one for a long time, and I know other "well known" contributors who also just use the diff and tarball method. Also I'd be willing to bet that most OSS projects don't use version control, CVS just happens to be how the code is stored in sf.net. Also you could argue that CVS is a pretty bad source control mechanism, esp. given the use case for OSS programers. Arch. looks like it could be good soon. However the comercial market has bitkeeper, perforce and Clearcase... which are all usable and used right now.
Coding Standards?
There is a difference between large and small projects. For instance most smaller projects that only have one main contributor shouldn't have a coding standard, because it should all look the same and common best practice would dictate that patches be in the same format. And if they aren't then it's a relatively small problem to reformat them by the main contributor.
However the larger the project is, the more an official coding std. is needed as it's much harder for a single person to keep an eye on everything. Indeed some of the larger code infrastructure in Linux like the kernel, gcc and glibc are very anal about Coding Stds.
Quality Control?... "all bugs are shallow, given enough eyeballs?"
Again, in a smaller project, the Quality Control will basically be a function of what the main contributor does (as there are very few extra eyeballs). Some projects have very good "traditional" QA measures.
It's also worth pointing out that even though the larger projects will tend to get a lot more bug reports/fixes, for the normal code paths, it doesn't necessarily hold that all code paths will have been tested. For instance see wu-ftpd or sendmail, here you really do need good code and some real QA (see vsftpd and qmail/exim). However the comercial offerings tend to fair just as badly, or even worse.
Support?... Modifing code?
The point is not that A company can provide support, or alter the code. It's that anybody with sufficient knowledge can.
FWIW, the server name is transmitted in a standard HTTP/1.1 response so it's trivial to work out what kind of server something is running. As a simple test, run 'telnet [host] 80' and type 'GET / HTTP/1.1' and hit enter a few times. You'll get a response (usually an error saying invalid HTTP/1.1 request) which includes a server version.
To be pedantic, that should really be... "A server name is trans... what kind of server something says it's running."
Re:Does adding every ingredient make it better?
on
C# 2.0 Spec Released
·
· Score: 1
No, you don't understand what I'm saying. I am saying that some legal C++ programs (ie, those that use template metaprogramming) cannot be compiled (they instruct the compiler to loop forever) and that it is not possible for a compiler to distinguish those programs from the programs that can be compiled successfully.
Those aren't legal C++ programs, the C++ std. places a limit on how much recursion you can use in a template. Anything over that limit is, by definition, not a legal std. compliant C++ program. The C std. places limits on the number of nested blocks allowed in a function, and the number of times a macro expansion can recurse. Lisp dialects place limits, either implicitly or otherwise, on recusion level of functions.
Or maybe you're saying that the error message is't helpful when this happens? But that's also true if you forget to close a macro call in C or forget to close a string constant, in C or lisp.
If you think perl is nice, well, perhaps there is no hope...
You just said, "I don't program in it, so I don't have any specific examples". If someone said lisp is just python with too many brackets, that would be just as bad... and there are a lot more perl programers and code out there.
perl's idea of TIMTOWTDI does lead to a very free syntax compared to say scheme, however I have written a lot of nice readable code in perl... and I've also read a lot of nice perl code. Sure I've also seen my share of unreadable crap in perl, but probably more so in plain C (which is only free in the use of whitespace, but some people don't even need that).
C written in perl can be especially bad, more so than even lisp written in perl. But then C written in scheme isn't pretty either.
Re:Does adding every ingredient make it better?
on
C# 2.0 Spec Released
·
· Score: 1
Some examples of why C++ is broken:
Compilation is an impossible task.
There is exactly 1 standard-compliant implementation of C++
Well personally, I detest C++. And it is fair to be annoyed that it's only been had a standard for 4 years... and almost noone has caught up with it fully yet, however most modern implementations are very close. As far as I know there are no legal programs that don't compile (there are ambiguities in the syntax, but they were known about and documented by the std. -- and so not legall IMO). And even if you considered something like "foo<bar<X>>" a legal program, that still doesn't make it impossible to compile (it's even possible someone could work out how to make a C++ compiler work out what to do with it).
Why Perl is broken:
Compilation is impossible, as above.
There exists one implementation, which defines the language.
However I use perl quite a lot, it is a nice languages that does what it aims to do well, very well. It is different in that it has a better defined goal than most languages, which nodoubt why it reaches a goal (certainly lisps goal of solve the same problems as everyone else, but in a different way and use lots of brackets doesn't impess as many people). As you say there is no std. and only one viable implementation, but as a difference to the C++ problem everyone uses that implementation. However the "compilation is impossible" statement makes no sense to me, I'm not sure if you are trying to complain about the syntax of the lanuage (which is the whole point of the language) or that the only implementation is mainly a bytecode interpreter.
So, did his Hello World support multibyte character sets, or, in fact, any sort of internationalization?
Without being nice about it, dietlibc is a piece of shit. If you just want a syscall list and the obvious functions (memcpy() etc.) use klibc. If you need more then dietlibc is almost certainly broken IMO, everytime I've looked at something "big" in it the implementation was worthless. In fact the printf() like function is unique only in how terrible the implementation is, and that's probably the most widley used function in libc.
As for multibyte, that's no problem because Felix is using a broken string library, which is one of the few things that tries to forgo the use of printf() making i18n almost impossible.
OTOH, the results are of concern and should be verified by someone less obviously biased. I haven't noticed them in practice on moderately loaded servers though (but I'm biased in the opposite direction).
The poll() code in libowfat (broken reimplementation of DJB code) is a very poor implementation, having 3 extra O(n) loops. Also some of the benchmarks looked wrong, for instance the socket() benchmark has FreeBSD suddenly getting much lower latency after it's created almost 4000 fds... it's possible this is some weird hack in FreeBSD, but if so almost certainly means the micro benchmark is worthless.
One machine I have has almost no IPs on that network.
One machine I have is recursive, but has about 6 zones which need to be "overridden" with special private data... which is done by setting bind up as authoritative for those zones. It's possible that there is some "special" way of setting up djbdns to do this by using a seperate server just to pretend to be authoritative for those zones and telling the recursive serverr to just talk to that for those zones (which seems like a much bigger hack, to me).
The right thing to do is to run two services one for DNS cache, the other as your authoritative nameserver.
Where I presaume you are just believing whatever DJB's seperation page says? And his (only three) arguments are... Compromise of your cache is a compromise of your authoratitive data, DOS attacks on your authoratitive server can also DOS your caches, and doing seperation allows you to change software easily.
The first doesn't affect anyone small enough to do this, IMO. The second is laughable (it's much easier to just DOS the network). And the third is crack... fixing your damn software would allow people to easily replace both their auth. and cache DNS software. And you'd only need to do it once.
Even BIND idiots recommend to run BIND this way.
Yes, it can be useful. But it shouldn't be required. In the same way that I'd recommend to any and all real ISPs that they should have seperate machines (possibly with seperate software) for smarthosts, MX servers and MX relays... but I sure as hell don't need that for my email server which can do all three (even if I do get an above average amount).
there is more than one good alternative, including, but not limited to, djbdns.
Ok, so I want a authorative and recursive DNS server. It needs to be able to be distributed via. rpms, and patchable etc. I really want it to be my vendor of choice who packages and distributes it, but I that's more of a social thing.
So... what do I use?
nsd is written with just as little regard for security as bind... and isn't a recursive server
djbdns has all the legal djb problems and can't be a recursive and authoritive server
maradns has already had security problems and fairly major DNS bugs, uses a threaded design and has piles of needed things in the "unimplemented" section of the man page. The string ADT looks suspicious to say the least.
dnrd is recursive only
dents unmaintained, and never worked well AIUI
dnsmasq just does recursive queries
dnsproxy is just recursive
ens (yaku-ns) is said to be "experimental" by the author
pdnsd proxy only, has lots of bugs and uses a threaded design.
So I'll use bind 9... and when there's a security problem I hope it's the last. However this issue doesn't count, this is a minor configuration problem that is All verisigns fault.
Not surprising, as BIND is as shown again and again a poorly designed and coded product. The fact that authors of this crap can't come up quickly with a working patch is laughable.
Well I certainly generally dislike ISC and BIND, due to their lack of security about strings and IO. However, in this case all the blame lies with Verisign, the root and.com registrars went from trusted sources to untrusted atackers overnight. From a DNS server point of view the changes to the design of the software can't be exagerated. djbdns, bind and others all tried to get out quick patches to "fix" DNS, however bind also did extra patches to try and preemptivley combat other things that these now untrusted sources could do. And if you enabled those, you would trigger on some registrars who are still providing trusted information but trigger as a possible attacker.
Actually, if you read the GPL (I understand that's a rare occurrence among both it's promoters and detractors), you will find that learning from the source code is perfectly valid thing to do with GPL code.
Where does it say that explicitly? ("l?earn" isn't found). In fact that's a pretty stupid thing to do as it's much more likely that what you produce would be classed as a dirivative work of the GPL'd work.
While you can learn from it, that isn't a "get out of copyright free" card. Indeed this is a major reason that the samba developers don't look at MS CIFS code, because then they are much more likely to write tainted samba code.
err... no. The sender puts the source address in an IP packet, the destination sends replies to that address. If the source doesn't care about the replies, it can just lie about the source address. There is no magic "caller ID' for telling the source address.
SMTP is only available over TCP in most places, so you need to complete a three way handshake to talk SMTP with a host. To do this you basically need to have access to the return IP packets. So you need to be somewhere between who you are talking to and the rest of the world.
Some spam software forges source address and just sends packets at the right time so that some make it through the protocol.
Doubtfull. The only time this might be of use is if you were on something like a university network, where you could log into one machine and pretend to be another. This just doesn't work in the real world.
Here is a question for those who are familiar with SMTP.....Can someone take the source code to an SMTP server like Java Mail Server and alter then send a message with spoofed an IP address in the header?
The IP addresses are put in by the recieving sites server, so if server A sends something to server B then server B will always record it as comming from server a (no matter what you've done to server A).
One thing you can do is pretend that you (as server A) got it from someone else, when in fact you didn't.
Actually, you're wrong. The exception is "checked" for each operation that can generate the exception. Once an exception is thrown, control immediately passes to the catch(){} block. So in order for the second op to run, the first needs to succeed.
No, the second op is only run if the first fails and it's run outside of the try, as is the close(). And according to Sun's documentation both calls are allowed to throw exceptions. This was hard to read due to/. eating all the formatting. I've put it here so you can easily see it.
Slashdot Mirror
I may not have explained well, having "current" packages brings it's own problems ... but most people who would care know how that goes (even comming from the win32 world). The problem is that, for example, the cvs security errata earlier this year took a few more days to come out for unstable as it did for stable ... but it took over 3 months IIRC to get into testing. Therefore recommending "normal" people use testing is not going to help debian, IMO. Obviously you, and your friends, can use it ... I presume you know what you are doing ... it just isn't a general solution like "fedora", mandrake, etc. etc.
So if I point out a flaw in debian then I'm "anti-debian", I guess then all the people pointing out flaws in the US just attacking whoever it feals like really are "anti-american".
No, there isn't (at least not how you are implying). There is a testing distro called "testing". It doesn't provide security updates, and things have to be "tested" before they get there. You cannot and should not use it is a regular distro. like mandrake/fedora etc. It is much like FreeBSD cusrrent, but I assume you meant it more like saying "fedora has current packages" ... which also isn't true enough at times, it's just much closer to the truth.
That's not true. If you have a server OS, then you can use "stable" and it is likely to be what you want (assumnig you don't need a feature from this millenium). As far as "unstable" and "testing" go ... neither provide security errata. and are thus useless for normal people. Unstable can be ok for the very experienced Linux user who is watching bugtraq.
Your comment also implies that 1) all applications are created equally and 2) debian "stable" means that the apps. are guaranteed to work.
Where it seems obvious to me that I might want MozillaFirebird (comming soon in 2006 to a debian stable near you), but not want to move from apache httpd-1.3.x ... everyone gets this wrong IMO, it's just debian's choices make it the most painful. Also "stable" doesn't mean working, it means not changing ... so if you have a bug with something in stable (something I've experienced), then it just won't get fixed "by design" because it's unchanging and any change might break something for someone else (this is ignoring times when debian gave up, like the bind9 security upgrade).
Because all snae people want security updates. stable provides them, unstable doesn't but you are "likely" to have new packages "soonish". Testing doesn't and sometimes it takes months before a new package gets in there.
A step back from what? Right now most US companies running a supported Linux in the enterprise are running Red Hat Enterprise Linux, and it comes with (or with support for) all the products they need, Ie. Java, Oracle, PowerPath, etc. etc. etc.
This is the same "argument" that RMS uses, Ie. It's better to have nothing than something. Life doesn't work like that, people always go for the path of least resistance. Hell even debian wasn't stupid enough to not have "netscape" available when that proprietry and the only real browser. Saying "It's not free" doesn't solve the problem of "I need, now" (and "need" is relative, some people "need" to be able to play proprietry games, etc.).
You don't need a central auth. And it doesn't need to cost that much. All that's needed is something to auto-pgp everyone's email. Then when I can put email from everyone I know where it belongs, unsigned stuff somewhere I'll look at every now and again and signed stuff can be decided if it's really someone who wants to speak to me or a spammer (this can be helped with web of trust type schemes).
Obviuosly as/if people implement it only the spam will be unsigned, which will make email (as we know it today) obsolete ... as it'll need to be signed for anyone to read it.
Even for fairly large traffic mailing lists like lkml you will only need a few hundred keys for 99% of the traffic.
The difference is the level of control, esp. on Linux. Java, EMCAScript and Flash or have very poor control facilities (EMCAScript is getting somewhat better, but I'd still turn it off). Flash can be nice (homesteader comes to mind -- but this is more a comment on the quality of video players than anything), but it's use for banner adds or for frontpages is very annoying.
So you don't think it would be better as a dia/visio file?
For most usage SVG should nicly replace it, for the portable vector video we're probably stuck with it for a while :(.
So how many people have sued Microsoft for costing them millions due to SoBig etc.? ... so how many banks will give funding if you say "Well our core software doesn't work, but hey it's from MS so they are acountable"? Replacing MS with some random other firm will not inspire anymore confidence, I think. Banks/VCs are much more likely to give funding if you can say "we have access to the source for all our core software" than if you can't.
Legal acountability for comercial software vendors is a fiction. However if you wish to play "lets pretend", then you can get this same fiction from Red Hat, Novell etc. You sign a piece of paper, it says "you will pay X" and "we will be acountable in X ways".
But this isn't anything to do with accountability, it's to do with service agreements ... accountability is how often you need them. Or at the extreme, you can say "this works". However, very few pieces of software come with that kind of accountability.
But it's more like if I take all my valuable goods, stick it in a box, put it in the middle of Central Park and then go home. Sure, in a perfect world, I could count on it being there when I get back tomorrow ... however in reality no sane person would.
Really putting thirteen year olds in prison for longer than they've been alive isn't going to solve anything.
Oh, my. Where do you work? Far to many places I've worked at companies the QA has been something that people assume the programer does (mostly for internal code) ... or they have a QA team, but it is "controlled" by the engineering managers. One very large company I worked for had a seperate QA dept. however if they found any bugs that they thought should hold up a release (and they had 3 days to do it in) then they had to ask the development dept. to stop the code from shipping. No matter what the bug, they were powerless to do anything. Of course the same dept. had no unit tests and used "RCS" for version control.
This isn't true, my goddamn name is in the authors file and the web site etc. Not some nameless corporation. I am completely accountable, which is why Vstr has over 98% code coverage and the test suite is almost half the size of the code. This is very unlike when I work on code inside a company, where often can we deploy it is the only question asked and time just isn't allocated to do it to the same level of quality. It would probably be more fair to say that OSS is often more concentrated in it's accountability.
It wasn't bad, I'm not sure whether it was a troll or stupidity. However, assuming it was a troll, as with all good trolls there were grains of truth in it...
Really? Well, I don't use anything more than diff and tarballs of releases. Linus didn't have a public one for a long time, and I know other "well known" contributors who also just use the diff and tarball method. Also I'd be willing to bet that most OSS projects don't use version control, CVS just happens to be how the code is stored in sf.net. Also you could argue that CVS is a pretty bad source control mechanism, esp. given the use case for OSS programers. Arch. looks like it could be good soon. However the comercial market has bitkeeper, perforce and Clearcase ... which are all usable and used right now.
There is a difference between large and small projects. For instance most smaller projects that only have one main contributor shouldn't have a coding standard, because it should all look the same and common best practice would dictate that patches be in the same format. And if they aren't then it's a relatively small problem to reformat them by the main contributor.
However the larger the project is, the more an official coding std. is needed as it's much harder for a single person to keep an eye on everything. Indeed some of the larger code infrastructure in Linux like the kernel, gcc and glibc are very anal about Coding Stds.
Again, in a smaller project, the Quality Control will basically be a function of what the main contributor does (as there are very few extra eyeballs). Some projects have very good "traditional" QA measures.
It's also worth pointing out that even though the larger projects will tend to get a lot more bug reports/fixes, for the normal code paths, it doesn't necessarily hold that all code paths will have been tested. For instance see wu-ftpd or sendmail, here you really do need good code and some real QA (see vsftpd and qmail/exim). However the comercial offerings tend to fair just as badly, or even worse.
The point is not that A company can provide support, or alter the code. It's that anybody with sufficient knowledge can.
To be pedantic, that should really be... "A server name is trans ... what kind of server something says it's running."
Those aren't legal C++ programs, the C++ std. places a limit on how much recursion you can use in a template. Anything over that limit is, by definition, not a legal std. compliant C++ program. The C std. places limits on the number of nested blocks allowed in a function, and the number of times a macro expansion can recurse. Lisp dialects place limits, either implicitly or otherwise, on recusion level of functions.
Or maybe you're saying that the error message is't helpful when this happens? But that's also true if you forget to close a macro call in C or forget to close a string constant, in C or lisp.
You just said, "I don't program in it, so I don't have any specific examples". If someone said lisp is just python with too many brackets, that would be just as bad ... and there are a lot more perl programers and code out there.
perl's idea of TIMTOWTDI does lead to a very free syntax compared to say scheme, however I have written a lot of nice readable code in perl ... and I've also read a lot of nice perl code. Sure I've also seen my share of unreadable crap in perl, but probably more so in plain C (which is only free in the use of whitespace, but some people don't even need that).
C written in perl can be especially bad, more so than even lisp written in perl. But then C written in scheme isn't pretty either.
Well personally, I detest C++. And it is fair to be annoyed that it's only been had a standard for 4 years ... and almost noone has caught up with it fully yet, however most modern implementations are very close. As far as I know there are no legal programs that don't compile (there are ambiguities in the syntax, but they were known about and documented by the std. -- and so not legall IMO). And even if you considered something like "foo<bar<X>>" a legal program, that still doesn't make it impossible to compile (it's even possible someone could work out how to make a C++ compiler work out what to do with it).
However I use perl quite a lot, it is a nice languages that does what it aims to do well, very well. It is different in that it has a better defined goal than most languages, which nodoubt why it reaches a goal (certainly lisps goal of solve the same problems as everyone else, but in a different way and use lots of brackets doesn't impess as many people). As you say there is no std. and only one viable implementation, but as a difference to the C++ problem everyone uses that implementation. However the "compilation is impossible" statement makes no sense to me, I'm not sure if you are trying to complain about the syntax of the lanuage (which is the whole point of the language) or that the only implementation is mainly a bytecode interpreter.
Without being nice about it, dietlibc is a piece of shit. If you just want a syscall list and the obvious functions (memcpy() etc.) use klibc. If you need more then dietlibc is almost certainly broken IMO, everytime I've looked at something "big" in it the implementation was worthless. In fact the printf() like function is unique only in how terrible the implementation is, and that's probably the most widley used function in libc.
As for multibyte, that's no problem because Felix is using a broken string library, which is one of the few things that tries to forgo the use of printf() making i18n almost impossible.
The poll() code in libowfat (broken reimplementation of DJB code) is a very poor implementation, having 3 extra O(n) loops. Also some of the benchmarks looked wrong, for instance the socket() benchmark has FreeBSD suddenly getting much lower latency after it's created almost 4000 fds ... it's possible this is some weird hack in FreeBSD, but if so almost certainly means the micro benchmark is worthless.
Why do I need to put them on seperate IPs/machines? See this message before commenting
One machine I have has almost no IPs on that network.
One machine I have is recursive, but has about 6 zones which need to be "overridden" with special private data ... which is done by setting bind up as authoritative for those zones. It's possible that there is some "special" way of setting up djbdns to do this by using a seperate server just to pretend to be authoritative for those zones and telling the recursive serverr to just talk to that for those zones (which seems like a much bigger hack, to me).
Where I presaume you are just believing whatever DJB's seperation page says? And his (only three) arguments are... Compromise of your cache is a compromise of your authoratitive data, DOS attacks on your authoratitive server can also DOS your caches, and doing seperation allows you to change software easily.
The first doesn't affect anyone small enough to do this, IMO. The second is laughable (it's much easier to just DOS the network). And the third is crack ... fixing your damn software would allow people to easily replace both their auth. and cache DNS software. And you'd only need to do it once.
Yes, it can be useful. But it shouldn't be required. In the same way that I'd recommend to any and all real ISPs that they should have seperate machines (possibly with seperate software) for smarthosts, MX servers and MX relays ... but I sure as hell don't need that for my email server which can do all three (even if I do get an above average amount).
Ok, so I want a authorative and recursive DNS server. It needs to be able to be distributed via. rpms, and patchable etc. I really want it to be my vendor of choice who packages and distributes it, but I that's more of a social thing.
So ... what do I use?
So I'll use bind 9 ... and when there's a security problem I hope it's the last. However this issue doesn't count, this is a minor configuration problem that is All verisigns fault.
Link should have been... http://www.and.org/vstr/security.html
Well I certainly generally dislike ISC and BIND, due to their lack of security about strings and IO. However, in this case all the blame lies with Verisign, the root and .com registrars went from trusted sources to untrusted atackers overnight. From a DNS server point of view the changes to the design of the software can't be exagerated. djbdns, bind and others all tried to get out quick patches to "fix" DNS, however bind also did extra patches to try and preemptivley combat other things that these now untrusted sources could do. And if you enabled those, you would trigger on some registrars who are still providing trusted information but trigger as a possible attacker.
Where does it say that explicitly? ("l?earn" isn't found). In fact that's a pretty stupid thing to do as it's much more likely that what you produce would be classed as a dirivative work of the GPL'd work.
While you can learn from it, that isn't a "get out of copyright free" card. Indeed this is a major reason that the samba developers don't look at MS CIFS code, because then they are much more likely to write tainted samba code.
SMTP is only available over TCP in most places, so you need to complete a three way handshake to talk SMTP with a host. To do this you basically need to have access to the return IP packets. So you need to be somewhere between who you are talking to and the rest of the world.
Doubtfull. The only time this might be of use is if you were on something like a university network, where you could log into one machine and pretend to be another. This just doesn't work in the real world.
The IP addresses are put in by the recieving sites server, so if server A sends something to server B then server B will always record it as comming from server a (no matter what you've done to server A).
One thing you can do is pretend that you (as server A) got it from someone else, when in fact you didn't.
No, the second op is only run if the first fails and it's run outside of the try, as is the close(). And according to Sun's documentation both calls are allowed to throw exceptions. This was hard to read due to /. eating all the formatting. I've put it here so you can easily see it.