Wired has an interesting article about the possible death of the web:
http://The problem with today’s web is that the underlying code for web pages has become a mutant monster.www. wired. com/ business/ 2014/ 01/ death- pc- also- mean- end- web/
Back in 1994, one could make a compelling web page with just <h1>, <h2>, <b>, <i>, <p>, a couple of <a href=whereever.html>s, possibly even an <img src=whatever.gif>. Then the dot-com party started and it quickly became much more complicated: Plugins, CSS (with a completely different syntax than HTML), using <table> for layout, proprietary HTML tags, Java applets (which started slowly dying because of the browser wars), SSL, Javascript (unrelated to Java), Flash (which is finally slowly dying), IE6 hacks, HTML5, web fonts, and so on.
Somewhere along the way, the web became far too complicated for anything less than a multi-million dollar company to make something to render it (as observed by Opera throwing in the towel and no longer making their own web rendering engine), much less something possible to implement by a hobbyist programmers in their spare time (try browsing the modern web in Dillo).
It has also gotten worse for webmasters: Back in the early oughts, it took me at most a week to design my then-webpage. In the mid-oughts, it took me a couple of weeks to design the webpage I had, the lion’s share of the work being getting the page to look decent in Internet Explorer 6. The current design took about two months of work to make (over nearly two years, off an on), the lion’s share of the work “under the hood” (getting it to look decent in various Internet Explorer versions out there, working around other various browser bugs, editing its webfont in Fontforge so it would render decently with multiple font rendering technologies, having it be readable on small screen mobile devices—which required redoing some of the Internet Explorer hacks, etc.)
There is a lot of appeal with not having to target the web. An app only has to run on iThings and Android devices (with possibly a Windows and Mac port if the app is a runaway success), cutting down on development expense. I can see why many developers want to avoid putting something on the web.
Posted Jan 14 2014
The only warning clang emits when compiling MaraDNS is a bunch of warnings where the code does a comparison like this:
if(some_unsigned_var > max || some_unsigned_var < 0)
I don't see the point in removing all those sanity checks (I would rather have a sanity check like that with an unsigned variable than not have the sanity check with a signed variable)
Posted Jan 12 2014
==MaraDNS/Deadwood and Cppcheck==
I just learned about Cppcheck, which, like Valgrind, is a useful tool for finding errors in C programs. I ran Cppcheck against Deadwood and MaraDNS and have made a few updates:
http://maradns. samiam. org/ download/ 2. 0/ snap/
http://MaraDNS came out remarkably clean; while there were a couple of memory leaks in Deadwood, none of the leaks are a security concern (the issues are along the lines of “memory leak if malloc() fails here”, “null pointer dereference if malloc() fails”, or even one case of “memory leak if a string over 16 megabytes in size is requested”).maradns. samiam. org/ deadwood/ snap/
The Cppcheck updates for authoritative MaraDNS will be part of the 2.0.08 release later this month, and the Cppcheck updates for Deadwood will be part of Deadwood 3.2.05 released near the end of this year (barring a CVE-worthy security hole).
Posted Jan 09 2014
I have archived the microblogs posted between mid-2013 and January 8, 2014:
http://samiam. org/ blog/ 2014- 01- 08. html
To post a comment about this blog entry, go to the forum (self-signed https). New accounts may post once I approve the account.