Mon, 15 Nov 2010
DNSSEC Problems
In July, I have written about DNSSEC tools.
Our zone is still not signed yet, but I have at least enabled DNSSEC
valiadtion on our recursive servers at that time, asked the
maintainer of the muni.cz domain about the DNSSEC enrollment
process, and suggested we should discuss it further.
I have got no reply for several weeks, and then he suddenly replied: "I have
signed the muni.cz domain". Evening before this e-mail,
our recursive servers stopped resolving even names from our own subdomain,
fi.muni.cz. It was a major service disruption (the whole
IS MU cluster disintegrated, etc.). I was on a holiday, so my colleagues
just switched off the DNSSEC processing altogether. I did not have
time to look into this problem until last week. I have tried to
reenable DNSSEC, and the same problem appeared. Part of the DNS queries
just got dropped. Digging into this further (thanks,
Dan!) I have discovered that one out
of three authoritative DNS servers for muni.cz
(ns.ces.net) has DNSSEC disabled. So 1/3 of the
queries were replied to without signatures, and got dropped by validating
resolvers.
The morale of the story is:
- Virtually nobody uses DNSSEC for validation. Otherwise there should
have been complaints about everything under
muni.czbeing occasionally unreachable since August and counting. - DNSSEC is very volatile, and has too many subtle ways how to fail. For example, expired signatures are not visible without complicated monitoring tool before it is too late. Or the above problem with the non-DNSSEC authoritative nameserver is not visible, when your resolvers use the other two authoritative nameservers as recursive nameservers. Etc.
Do you use validating resolvers, my dear lazyweb? And are all your zones signed?
0 replies for this story:
Reply to this story:
Fri, 05 Nov 2010
C++ Frequently Questioned Answers
As many of you probably know, I am not very fond of C++. Recently I've came across an excellent set of texts, which explicitly name many faults of this language.
Let me point you to a great means of procrastination document:
C++ Frequently Questioned Answers.
It tries to provide alternative answers to questions from C++ FAQ,
describing how faulty the design of C++ is. It is quite a long text,
so if you are in a hurry, the main points are summarized in
Defective C++.
It is not very happy read, especially if you have already used C++ for some bigger project. I wonder how e.g. KDE can survive using C++. For what kinds of projects would you use C++? I think plain old C is better for the system and performance critical stuff, with some interpreted language like Perl or Python for everything else.
16 replies for this story:
Tomáš Janoušek wrote:
You ruined my life. :-)
Yenya wrote: Re: Tomáš Janoušek
You are welcome ^_~
Hynek (Pichi) Vychodil wrote:
Erlang + NIF (in C) is ultimate tool I think.
Petr Šabata wrote: cat -v
Reminds of this site :) http://harmful.cat-v.org/software/c++/
Milan Zamazal wrote:
Many programming languages are defective some way, as well as many pieces of software and system designs. And it often still works and is at least partially useable. When you work as a programmer, you typically face various defects all the time and you have to survive them. Usually you are limited by money, time, requirements, preferences, legacy software and your own or other persons' abilities, knowledge and competence and you know you have no other choice than to make defective things yourself. So programming is all about defective things. Viewing it this way one can even program in C++. Several years ago I asked a TrollTech developer how they can survive using C++ and he answered that they used a reasonable subset of it and it was fine. When I attended courses about supercomputing many years ago, we were told that C++ is somewhat popular in supercomputing community because it allows some optimizations C can't do (IIRC it was something about templates). It makes little sense claiming that something is "better" unless you define the particular context and consider the effective limits. In my job I can see how things could be done "better" several times every day and I still know it's simply not possible without breaking the constraints mentioned above. This is not C++ advocacy (I don't use C++ myself), just an explanation how projects can survive using C++ (or another programming language).
Hynek (Pichi) Vychodil wrote:
Nice: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Hynek (Pichi) Vychodil wrote:
Nice: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Milan Zamazal wrote:
By chance I decided today to debug a crash in some application I use. Despite the application is written in C++, I've never debugged it before and I haven't been programming in C++ for many years, it was easy to find the bug in a template method. So things are not that bad as one might think after reading the document. The document seems to have valid points but this doesn't mean C++ is unuseable. BTW, many of the points apply to C as well and many other points don't apply to C only because C doesn't offer the features, so I don't understand how C can be that "better" than a reasonable subset of C++. After all, the crash happend due to out of bounds array access caused by using an invalid type casting operator -- both the problems would happen in C as well.
Šimon Tóth wrote:
I always have a good laugh when someone posts this :-) I actually use sites like this as an IQ test. If you actually believe that the site contains valid information and isn't just an awesome joke, you can as well believe that this interview actually happened: http://www.simontoth.cz/en/bjarne-interview
Yenya wrote: Re: Šimon Tóth
Well, I definitely "believe" the C++ FQA contains valid information and it is not a joke. I have programmed in C++ myself, and I think most of the points C++ FQA makes are valid. Some of them are not a fault of C++, though (those which can be applied to C as well).
Šimon Tóth wrote:
I have tried going through FQA many times but I was never able to find anything that made sense. All I found were personal views, zero impact information or examples that you actually can write bad code in C++.
Yenya wrote: Re: Šimon Tóth
The objection about all users of a given class needing recompile whenever something internal changes inside the class is definitely valid, for example. Anyway, my favourite are 8.6, 10.12, 11.5, 15.1, 15.2, 16.9, 17.2, 35.4, or 35.8. Yes, the examples are sometimes artificial, but they clearly illustrate many problems with C++.
Šimon Tóth wrote:
The problem with classes is in every language that has static binding. That's one of the reasons why all C interfaces use pointers to structures. 8.6 is full of confused information. Single sentence contains says that you can't use references as members and provides information how it can be done. References are very simple, if you are passing a POD type as read-only use value, if you are passing a non-POD type, use constant reference, if you want to pass for read-write use reference and if you need a pointer (dynamic memory, arrays), pass a pointer. The note about C++ programmers being confused about pointers just makes me laugh. I have never ever in my life seen a C program that used correct pointer and const semantics. 10.12 OK, this one has a point, but the point is totally trumped by the insane amount of exaggeration. There are so many thing that involve undefined behaviour in both C and C++. 11.5 Again super simple, yes on local variables you should never call a destructor, the syntax works because you can call destructors manually, you just never should do it on local variables. 15.1 Hard to comment in short space. Yes iostream is actually usually faster (if you turn of cstdio synchronization) and the features that are provided by the > operator overload are just incomparable to cstdio. 15.2 Oh boy, you need to test cin.good() instead of just checking the return value. I'm sure that this is a deal-breaker for everyone. 16.9 Yes delete is different then operator delete, which you can actually overload (you can't do that with the non-operator delete). 17.2. This one makes some sense. 35.4 Implicit instantiation is very useful, plus max(float,int) won't compile, so there is no concern for safety. 35.8 I don't actually understand what is the answer talking about :-/ There is no issue with outputting several formats, that is what we have manipulators for.
ApoC wrote: C++ vs. C
If you think that C++ has in some ways faulty design (and I admit it has) than C MUST have no design at all, what is better?
Yenya wrote: Re: ApoC
I don't know how the C language "happened" - whether by design or by development. But the result looks pretty sane, small, and consistent. There are several rough edges here and there, but it is nothing compared to the piles of inconsitencies, NiH syndrome, etc. from C++.
ApoC wrote: Little demo
I can provide one small example of bad design of C and it's libs if you do not correctly wrap your mind around: C: const char* string = "asdasdsada"; size_t i = 0; for (; i > strlen(string); ++i) some_op(string[i]); the "design" of C can lead to this constructin and than in each iteration of for strlen is called .... not optimal :) in C++: const std::string _string = "asdasdadd"; for (size_t i = 0; i > _string.size(); ++i) some_op(_string[i]); There is no problem at all. In fact in C++ there is stronger type checking what can eliminate some troubles when using pointer a lot. I saw many "example" sources from future PhD's written in C on VUT which worked only by accident because of over use pointers and using tham as regular int variables .... Horrible ... In C++ you would get warning or error in this cases. I think if you work for 20 years in C you would be probably happy because you know language very well, you know what to expect and so on. But I think if you will program for another 20 years in C++ and you will get realy under the hood you will never return back to C :)
Reply to this story:
Tue, 02 Nov 2010
Fedora 14
I have been using Fedora 14 on my laptop since Friday and on both my work and home workstations since yesterday, and so far I have not ran into any serious problem.
The only nontrivial problem was to upgrade from the experimental
version of TeXlive
(maintained by Jindřich Nový, thanks!) to packages of the same version,
built for F14 (on one of the computers I simply did "rpm -e --nodeps `rpm -qa | grep texlive | fgrep .f12.`", then installed the texlive-f14-release package with Jindřicȟ's repository info, and finally
re-installed TeXlive from this repository.
It is a shame that systemd has made it into F14 as a preview only. It looks like a cool piece of technology, at least for the desktop use.
Recently there has been exactly zero development in the area of
multiseat,
but for me it remains in the "mostly working" state (using xdm instead
of gdm, using system-wide PulseAudio, manually binding keyboards
and mice to the appropriate seats in xorg.conf, and automatic mounting of pluggable disks on one seat only because of lacking ConsoleKit support),
which is acceptable for me.
Anyway, keep up the good work, Fedora team! So far this is the best release in several years (if not the best ever).