Better yet user better, more convenient string APIs in the first place. One of them is in libowfat.
As you pointed out strn* doesn't protect you from buffer overflows. There are a mighty fine number of good programmers who you'd call braindead. People make mistakes, and if an API helps in that regard then that API is better than the stdio garbage. That's why OpenBSD uses strl* functions instead of strn*.
Nobody's going to bother unless they're forced to do so. The reason, and most seem to miss the point, is the migration path from v4 to v6 is not automated. If it were automated, with the sysadmins essentially doing very basic or zero configuration, we'd all be running v6 already.
At any rate, clockspeed is another weird DJBism that doesn't support the standard everyone else uses (UTC), and instead implements something fairly similar and arguably better (TAI) that no one else wants. Since TAI doesn't do leap seconds, neither does clockspeed so it's not really relevant to the subject at hand.
So it's a matter of aversion. You have a DJB aversion. You also seem to speak for everybody. Try and prove that no one else uses TAI or clockspeed. I think someone tried that with qmail already.... Unfortunately for those unaware people and due to people like you that spread FUD, UTC is a broken standard, and TAI actually handles leap seconds instead of jumping around.
Would be nice to see bulk.fefe.de type benchmarks for webserving on that hardware as well, to see how the OSes scale in web serving. I wouldn't be surprised to see either Linux or FreeBSD come out at the top.
Also take a look at the excellent stralloc which is also part of libowfat.
Better yet user better, more convenient string APIs in the first place. One of them is in libowfat. As you pointed out strn* doesn't protect you from buffer overflows. There are a mighty fine number of good programmers who you'd call braindead. People make mistakes, and if an API helps in that regard then that API is better than the stdio garbage. That's why OpenBSD uses strl* functions instead of strn*.
Nobody's going to bother unless they're forced to do so. The reason, and most seem to miss the point, is the migration path from v4 to v6 is not automated. If it were automated, with the sysadmins essentially doing very basic or zero configuration, we'd all be running v6 already.
At any rate, clockspeed is another weird DJBism that doesn't support the standard everyone else uses (UTC), and instead implements something fairly similar and arguably better (TAI) that no one else wants. Since TAI doesn't do leap seconds, neither does clockspeed so it's not really relevant to the subject at hand.
So it's a matter of aversion. You have a DJB aversion. You also seem to speak for everybody. Try and prove that no one else uses TAI or clockspeed. I think someone tried that with qmail already.... Unfortunately for those unaware people and due to people like you that spread FUD, UTC is a broken standard, and TAI actually handles leap seconds instead of jumping around.
IMHO clockspeed can. It synchronizes with the precision up to attoseconds and has leapsec support.
You can with clockspeed/taiclock. http://cr.yp.to/clockspeed.html
IIRC clockspeed/taiclock are good at handling leap seconds vs. NTPD: http://cr.yp.to/prot/utctai.html
See here under 'What's the problem?'
Would be nice to see bulk.fefe.de type benchmarks for webserving on that hardware as well, to see how the OSes scale in web serving. I wouldn't be surprised to see either Linux or FreeBSD come out at the top.