The DNSSEC master key securing DNS is about to change - <AUTHOR> http://www.techworld.com/security/dnssec-master-key-securing-dns-is-about-change-should-we-be-worried-3645538/ <comment><USER2> Nothing about DNSSEC should concern you other than the prospect that it might someday actually be deployed.

[http://sockpuppet.org/blog/2015/01/15/against- dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

<comment><USER3> I wonder why moxie's Convergence [0] didn't take off. To me it sounds near- perfect. It could handle multiple layers of authenticity, including DNS.

The project has been inactive on GitHub for 5 years [1], however the Namecoin project picked it up [2] as "FreeSpeechMe" and added support for IPv6, and .bit, .onion, .b32.i2p domains. Now this, too, has been discontinued "because Mozilla removed the relevant API's as of Firefox 33". They "intend to release a replacement soon". According to Jeremy Rand [3] "A replacement is in the works (and is mostly working already)", but the source doesn't seem to be public or I can't find it.

Are there any downsides of Convergence?

0: [https://www.youtube.com/watch?v=Z7Wl2FW2TcA](https://www.youtube.com/watch?v=Z7Wl2FW2TcA)

1: [https://github.com/moxie0/Convergence/](https://github.com/moxie0/Convergence/)

2: [https://github.com/namecoin/Convergence/](https://github.com/namecoin/Convergence/)

3: [https://twitter.com/biolizard89/status/712525859194798080](https://twitter.com/biolizard89/status/712525859194798080)

<comment><USER4> IIRC, Google didn't want to run it because they'd end up running all the notaries themselves, which they didn't want to do.

<comment><USER3> So according to this and CiPHPerCoder's comment, the only reason it didn't take off is that it didn't take off?

 _Edit_ : found the comment from Adam Langley [0]. They didn't want to add it to Chrome because it wouldn't meet standards for the preferences UI inclusion, practically everyone would just rely on the default notaries, so Google would have to guarantee notary uptime, thus being forced to run them on their own.

He doesn't really point out why they don't include it as an optional alternative without any notaries pre-configured. He does however say that running it as an extension would be fine, but the required APIs weren't available at the time of writing.

0: [https://www.imperialviolet.org/2011/09/07/convergence.html](https://www.imperialviolet.org/2011/09/07/convergence.html)

</comment></comment></comment></comment><comment><USER5> > `Should we be worried`

I don't understand why that's in the headline outside of being clickbait. The article itself mentions that meetings of the DNSSEC key holders are quarterly and regular, and that the hardware involved in the actual key rollover complies to the highest level specified by FIPS-140 (presumably actually FIPS-140-2).

I don't believe there's reason to be worried; the ICANN has historically taken reasonable precautions to ensure the safety of such meetings and exchanges.

<comment><USER6> ...I think they mean 'should we be worried' that DNS will break due to the change. The article didn't really answer that though, instead just outlines the ceremony that takes place.

Does the key change frequently?

<comment><USER7> No, it doesn't change frequently. The article mentions that this is the first time it's changing.

</comment></comment></comment><comment><USER8> "The DNSSEC master key securing DNS is about to change. Should we be worried?"

No. Why should we be worried about anything in a protocol which has a deployment status close to zero on the client side?

<comment><USER7> Exactly. Does anyone know of any standard deployments that actually have the clients verify the DNS key chain?

<comment><USER9> That depends on how you define a client. If you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Recursive resolvers on most Linux distributions have DNSSEC validation by default.

One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date.

<comment><USER10> > One school of thought is to migrate DNSSEC from relying on validating > resolvers sitting within the network provider, and moving it closer to the > edge, in web browsers and so forth. Not much of that has happened to date.

Fedora is actively working to including a system-local DNS resolver by default that will validate DNSSEC-signed zones. The change was originally slated for F24 but was deferred due to lack of resources, but I suspect it should make it in by F26/F27 if all goes well and some of the NAT64 issues that were discovered with Unbound are fixed.

<comment><USER8> What Fedora plans to do is to use a local resolver with a fallback in case DNSSEC doesn't work. By this trick they try to prevent the inevitable deployment problems of DNSSEC. Of course they also make it completely insecure and it doesn't make any sense.

<comment><USER10> The fallback is to be configurable, but breaking the entire UX is not desirable when a full recursive resolver is unable to function. Personally, I would like to see some indication as part of the GNOME Network icon whether the resolver is secure or not, but I have a hard time determining what that would look like and how to implement it without giving users false assurances or worrying them if they don't care.

It's a tricky problem to solve, but Rome wasn't built in a day either. I'll probably disable the insecure fallback myself and only turn it on when I connect to my work VPN, I already don't trust public hotspots so unless I can connect to my OpenVPN server at home I don't use them.

</comment></comment></comment></comment></comment></comment><comment><USER11> What is the security like in these meetings? Is any security agency taking part on these ceremonies? What is preventing a terrorist group to launch an attack against this people considering the importance of all of them? I am probably exaggerating because all this reminds me of the not-so-old movies about hacking a la "Mission: Impossible" film series. Do they say that the meeting is going to take place in one place — like in the article it says El Segundo, CA — but actually meet elsewhere? Do the key holders have security 24/7 in their respective countries to prevent stolen keys?

Again, I am misunderstanding the information here, but the keys are actually useless, even if you get your hands on all of them to attempt an incursion against the building where the KSK is, you would not be able to do anything because the security of that place is probably good enough to counter an attack like that, and supposing the attack takes place the other DNS servers would simply disconnect from the root and serve the information that they have until it gets outdated. So the only scenario that I can picture in my head is one where a terrorist attack goes against the building to disrupt the functionality of the whole system for anarchy reasons.

<comment><USER9> The security is designed to guard against surreptitious access. Interested members of the public are welcome to attend ceremonies (availability on a first-come first-served basis).

There are multiple redundant sites and backups of the keys, so an attack aimed at destroying a site should not alone be a problem. Even if all all sites and backups were destroyed, there is a window where a new key can be constructed (approximately between 3-6 months worth of operational zone-singing keys are prepared in advance for the root zone).

<comment><USER12> One window of vulnerability is the after-party where everyone with a piece of the signing key drinks cocktails together.

<comment><USER9> Ceremony attendees don't leave with part of the signing key.

Despite the folklore around these ceremonies that there are 7 people with "the keys to the Internet", those seven only retain a metal key that is used to access a safety deposit box in the ICANN/IANA facility, each of which contains a smart card of which there is an "m-of-n" configuration to activate HSMs containing the actual key.

<comment><USER12> Thanks for the correction. :)

</comment></comment></comment></comment></comment><comment><USER13> I'm not sure if the author really understands just how irrelevant DNSSEC is as of right now.

<comment><USER14> I don't know why you're being downvoted into oblivion.

This is a legitimate observation. When I saw the submission title, I momentarily thought "Huh? Did DNSSEC finally take off?".

Spoiler: The answer is no. There are more effective ways to deal with security at the higher layers of the OSI model (such as relying on TLS encryption/identity).

<comment><USER7> While this is true, what DNSSec solves is the distribution of trusted identity.

It's one of the lowest layers in the Internet, if you can hijack DNS, then all connections the client is routed to can be used to exploit higher level security features like TLS. Yes, things like pinning of certificates can reduce this, but all a bad actor needs to do is get access to a poorly managed x509 trusted cert.

DNSSec does offer a layer of trust that most people lack today.

<comment><USER2> You trust Verisign? You trust the USG? You trust the UK?

DNSSEC was hijacked --- by old-school Unix people in the IETF who loathe X.509 on aesthetic grounds and by the USG, which attempted to mandate DNSSEC --- to integrate with and replace X.509 CAs.

You write as if DNSSEC could be deployed alongside the X.509 CA hierarchy. No.

On the real-world Internet, browser trust validation has to work for everyone, or it doesn't work at all. Common-sense workarounds, like "we'll do DANE for the people who can do DANE, and then fall back to CA validation" fall apart when confronted with adversaries. Anything you "fall back" to becomes the default for purposes of security, because attackers will launch downgrade attacks to make that happen.

Don't take my word for this:

[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

The net result is: DANE doesn't collapse Internet trust down to a single point; rather, it provides us with a 1036th CA. One that just happens to be run by world governments.

<comment><USER7> If I understand your basic argument, it's that shit is broken, and so fuck it, we'll just not bother with it. At what point do we decide that we should fix it?

New DNS record types not being returned, yes this sucks, it means there are a lot of firewalls and resolvers that need to be fixed. But IPv6 has the same upward battle in terms of router support, finally making a lot of headway. As people start demanding DNSSec, anything that is blocking that will need to be fixed.

RSA 1024 keys should be replaced, but again, we should be working to fix this, should we not?

> it provides us with a 1036th CA. One that just happens to be run by world > governments.

Validating a different set of data though. On top of that, TLD's can start to be ranked based on their reputation.

Just because things don't look good right now, doesn't mean that we can't work to fix them and make them better. Similarly we need to start pushing for BGP to get secured, as attacks on that network are significantly on the rise. I don't think we should just ignore the lower stacks of the network.

<comment><USER2> DNSSEC has no meaningful real-world deployment. Nobody on the entire Internet has ever been protected by a DNSSEC validation. So if we're just going to fix things and make them better, _let 's fix the protocol_, instead of deploying something that is broken and obsolete before anyone even starts using it.

<comment><USER7> Do you have any specific recommendations? Or something to point me to? I'd love to help _fix the protocol_.

<comment><USER2> Sure. DNSSEC was designed in the early-mid 1990s on the premise of "pick two: offline signing, authenticated denial, secret hostnames". They picked offline signing and authenticated denial. They picked wrong: the protocol should be redesigned to assume online signers, taking advantage of cryptography in every transaction.

Obviously, DNSSEC should provide query secrecy. Obviously, every DNSSEC transaction should be encrypted. That's functionality not present in DNSSEC that must be before the protocol can be taken seriously. Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between servers and clients anymore).

Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, _you don 't really even need signatures anymore_: if every link in the resolution chain is encrypted, there's no straightforward place to launch spoofing attacks anymore. DNSSEC advocates will point out that this doesn't make injecting fake DNS records 100% impossible. But it makes it so difficult that it's not worth it to any plausible attacker.

There's nothing you can do about the fact that DNS is a hierarchical PKI controlled by governments. DANE simply can't be made to work: DNS has no business holding TLS certificates.

<comment><USER7> I think I completely agree with you:

> the protocol should be redesigned to assume online signers, taking advantage > of cryptography in every transaction.

When you say online signers, do you mean not actively storing RRSIG records for RR sets at all? Or do you mean dynamically resigning the zone after any update? I think there is a benefit to these records in validating they originate with zone from which they claim to be. The biggest concern I have right now with the protocol is that having multiple nodes being responsible for managing a zone is difficult because each has to be signed by the parent zone, though with the necessary automated support, this shouldn't be hard to overcome (i.e. makes HA harder).

> Resolver-server encrypted transactions also solve the problem of endpoint > signature validation (because there's no weak link between servers and > clients anymore)

Do you have any thoughts on DNS over TLS vs DNSCrypt? I got halfway through implementing DNSCrypt, but I have some concerns about it being easily exploitable for DOS attacks. And am switching to DNS over TLS for now.

> Daniel Bernstein, among others, was smart enough to realize that if you > encrypt the connection between a resolver and a server, you don't really > even need signatures anymore...

Yes, this is true, but the concerns I've had with this are 1) ability to cache data and 2) ability to add nodes to the network. While I completely agree with this, we need to come up with a method that allows new nodes to be added to the graph, which might be cumbersome from a resolver perspective. In terms of zone authorities it should be relatively straightforward though. With the current DNSSec design, it allows for trusted data to be stored on untrusted nodes in the graph, making cached data straightforward.

If you don't mind, I'd love your feedback on a project I've been working on for the last year: [https://github.com/bluejekyll/trust- dns](https://github.com/bluejekyll/trust-dns)

I want to try and deal with many of these aspects of the protocol, from the slant of making it easier to setup and operate. I currently don't have a lot of documentation around operations, as I'm still focused on implementing some things like DNS over TLS. I'd love to bake some of these concepts into the software, so if you have any feedback that would be awesome.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> >The same ceremony will be repeated at the secondary master key facility in early 2017 before being used in anger for the first time at a third get together in Q2.

Is this a typo, or there some reason they're going to be angry?

<comment><USER16> "...used in anger" means used for the purpose it was intended for, not just in testing or rehearsal.

The analogy is to a spear or a gun; when used in anger, it is used to hurt somebody.

</comment></comment><comment><USER17> "This is only the beginning. The same ceremony will be repeated at the secondary master key facility in early 2017 before being used in anger for the first time at a third get together in Q2."

???

</comment><comment><USER18> Interesting but ridiculous approach to hiding content because of ad blocking: set the article's font to "redacted_scriptbold".

<comment><USER19> Particularly when you have no control over the ad blocking.

</comment></comment><comment><USER20> Yet another site that confuses an ad blocker with a privacy guard. Is there some kind of pre-canned explanation or site I can point them at?

</comment><comment><USER21> What type of key is it going to be, RSA or ECC? The article omits that detail. ECC would be a huge step forward...

<comment><USER9> It is going to be 2048-bit RSA, same as the existing. It was considered rolling the key for the first time would be complex enough that tracking the effects of an algorithm change as well probably should wait for a future opportunity.

</comment></comment><comment><USER22> TLDR: No.

</comment><comment><USER23> 'No'</comment>


Chainsaw - Parses a log file and returns lines matching the time period provided - <AUTHOR> https://github.com/blahed/chainsaw#chainsaw-

<comment><USER2> I'm a little puzzled by the naming conventions nowadays. Chainsaw for intelligent log file segmenting? Moustache for templating? On the other hand - we're far gone from readr, twittr, searchr.

<comment><USER3> Nowadays?

Apache Chainsaw[1] dates back at least to 2004[2]...

Speaking of which, I wonder how/why the dev chose the name "Chainsaw"? Did he not take the 5min. to Google his project's name before he named it? What are the odds that the dev formulated the same name for this type of tool? From looking at both sources, it doesn't appear that code was lifted, although it's possible this new version is some sort of port.

Regardless, I'll probably try it out, considering that I could never get the one from Apache to work...

1\. <http://logging.apache.org/chainsaw/>

2\. [https://issues.apache.org/bugzilla/buglist.cgi?component=cha...](https://issues.apache.org/bugzilla/buglist.cgi?component=chainsaw&product=Log4j&query_format=advanced&resolution=---&order=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_based_on=)

</comment></comment><comment><USER4> why not use awk?</comment>


Cinema chain set to allow texting - <AUTHOR> http://www.bbc.com/news/technology-36043996 <comment><USER2> This is exactly why I see movies exclusively at Alamo Drafthouse these days.

I honestly don't understand why you'd shell out ten bucks to half pay attention to a film. Or, as the article suggests, maybe I'm just too old to get it :)</comment>


Ask HN: any good hosting providers offering SSDs? - <AUTHOR>

I am looking for a hosting provider for my startup. We'll be looking for dedicated servers on a monthly plan.<p>The only well-know provider that I've found to offer Intel solid-state drives as an option is SoftLayer. Do you know of others? Do you use them? <comment><USER2> Only seen it done by ordering/colocating your own hardware so far.

SSDs are still bloody expensive for one, and the people who really need them generally already have a decent HW footprint and are more likely to be renting whole racks, though I imagine companies like Rackspace/etc will be adding it to their dedicated offers fairly soon, I'd suggest dropping them an email, you might get lucky.</comment>


The Women's Crusade - <AUTHOR> http://www.nytimes.com/2009/08/23/magazine/23Women-t.html

<comment><AUTHOR> "Perhaps the lesson presented by both Abbas and Saima is the same: In many poor countries, the greatest unexploited resource isn't oil fields or veins of gold; it is the women and girls who aren't educated and never become a major presence in the formal economy. With education and with help starting businesses, impoverished women can earn money and support their countries as well as their families. They represent perhaps the best hope for fighting global poverty."

Indeed. More people with better education working to take care of themselves is the proven path to poverty reduction all over the world.</comment>


Sift migrated petabyte scale HBase from AWS to Bigtable with zero downtime - <AUTHOR> https://engineering.sift.com/gcp-data-mig-1/ <comment><USER2> More information on the database migration here: [https://engineering.sift.com/gcp-data- mig-3/](https://engineering.sift.com/gcp-data-mig-3/)</comment>


Humor: Arc developer wanted - <AUTHOR> http://www.lonsteins.com/archives/2008/02/01/humor-arc-developer-wanted/ <comment><USER2> Some recruiters are still looking for an impossible number of years of experience in a technology. That's one of the reasons the startup revolution is happening.

</comment><comment><USER3> I'm going to start prefacing all my submissions with "Humor:". That way, people will laugh.

</comment><comment><USER4> So, they're trying to hire PG or RTM?

<comment><USER5> Heh! Arc begin in October 2001, as I recall...</comment></comment>


The Writer of the Future - <AUTHOR> https://books.substack.com/p/notebook-the-writer-of-the-future <comment><USER2> The problem is the reader world is bifurcating. It is no longer viable to write "for the middle" of the audience.

The two profitable price-quality points are:

\- Cheap content for the masses (lowest common denominator, ad supported)

\- Deep content for the vested (at a high price point)

"The middle" graces you with:

\- High cost to produce (research, depth, diction)

\- Limited audience

\- Zero willingness to pay

A writer demanding the world take them seriously is the last step on the way down.... performance begets entitlement, not the reverse. There are critical writers in the business world: those who write landing pages, build core content, drive desirable activity. They are often very well paid and - in the event they aren't - are frequently positioned to go out on their own as an independent publisher. It's the ones that write what in retrospect was the filler who tend to complain....

<comment><USER3> Book Post here. Thanks for giving us some thought! Agree, $45 subscription is a lift. Upside: Overhead is low & I don't need a mass readership to make it work. The New York Review of Books and the New Yorker were built on an "aspirational" audience of people not necessarily seriously into books but wanting to keep up with culture in an approachable/manageable way. Would love to have enough readers to charge less. Isn't there something between business reporting and "filler" that is a social good? Like, just because teachers don't have the market leverage to earn millions, doesn't mean we don't want their salaries set at a level that attracts qualified people and makes the profession sustainable...

</comment></comment><comment><USER4> Interesting.

But they want $45 for a one-year subscription to get book reviews. I have a hard time parsing that. Maybe if I were seriously into literary matters. Also, I can't see what forms of payment they accept, unless I provide an email address. Probably not Bitcoin, I'm guessing.

<comment><USER5> > Maybe if I were seriously into literary matters.

Like the subscribers to the _London Review of Books_ ($49 US / year), the _New York Review of Books_ ($89 US / year), or the _LA Review of Books?_ ($100 US / year for a _quarterly_ , if I'm not mistaken).

There are lots of people who are serious enough about books to pay these kinds of prices, and the price they're asking is around market (though maybe a little high for digital only).

My question is this: Are they as good as these other very famous publications?

<comment><USER3> Book post here! I worked at the NY Review of Bks for 30 years. One thing we heard over & over is that the issues pile up and no one has time to read them. Trying to develop a model that fits into modern life, makes people feel plugged in, not guilty. Looking not to compete with the old lions but offer something different.</comment></comment></comment>


What I Learned Building LittleIpsum - k-mcgrady https://medium.com/what-i-learned-building/f03b96aa6533

<comment><AUTHOR> I like small apps like this. They do their job and they don't try to reach outside of their domain.

However, I felt like the article was misrepresented by it's title. No real talking about what was learned, more talking about what the app can and what happened when released.</comment>


Bringing Enhanced Primitive Support to Clojure - <AUTHOR> http://groups.google.com/group/clojure/browse_thread/thread/c8c850595c91cc11

<comment><USER2> Why do I need to login to read that posting?</comment>


Marijuana Investors Lost $23.3B in Penny Stocks Last Year - <AUTHOR> http://motherboard.vice.com/read/marijuana-investors-lost-billions-in-penny-stocks-last-year <comment><USER2> I'm skeptical of the total loss quoted. If a stock drops from 2B to 0.3B market cap, it doesn't necessarily mean that investors lost 1.7B in the pump and dump. For that to happen 100% of the shares would have had to have traded hands. The remaining investors would have been there for the ride up as well as the ride back down.

</comment><comment><USER3> _In 2014, pot companies had the most drastic ups and downs for penny stocks_

A missed opportunity to use the phrase "highs and lows"

<comment><AUTHOR> $23.3B up in smoke?

</comment></comment><comment><USER4> Dot-com era, more like dot-bong era!</comment>


ISO C is increasingly moronic - <AUTHOR> https://www.varnish-cache.org/docs/trunk/phk/thetoolsweworkwith.html C is a very robust language which is hard to ruin, but ISO surely is trying.  The latest draft has a new mandatory one-macro #include file, and new incompatible and useless thread API, but still not compiler support for big-endian/little-endian variables or structure packing to match protocol specifications. <comment><USER3> Doesn't seem like the author really thought some of this through:

FTA: " _The <nostdreturn.h> file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ?_"

It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that don't build in C++). The underscore-followed-by-capital convention happened to have been reserved by ISO C90, so that's what they picked.

But they allow that this is ugly, so there's a new C1X header file you can include in new C1X code that makes the identifiers look like you expect they should. Obviously old code won't include this header and is insulated from the change. (I guess if you wanted to nit here, having a separate header for each new feature seems dumb to me. Why not a single <c1x.h> or the like?)

Compatibility is important, especially for languages like C with _staggeringly large_ bases of mature code. For an example of what happens when you break compatibility in the name of "progress" see Python3, which years on is still not installed by default anywhere, and probably never will be.

<comment><AUTHOR> First of all: You're wrong, the compatibility is the other way around: The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress.

Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers.

Besides: I have yet to see a compiler that didn't have flags to make it compile to a slew of older dialects of C, so if C1X happens to break your old code, you set such an option, or you fix your source code.

There, fixed it for you.

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits.

Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

<comment><USER4> If you don't value backwards compatibility, then perhaps you should not use a 40-year-old language with a standards committee that does value it.

<comment><USER5> I see no reason why he shouldn't express his opinion on the committee's goals re backward computability.

Defending the status quo by saying "well duh, you should know better, take it or leave it" is just a way of rejecting someone's contentions without actually addressing them. In a reasoned debate that's indefensible.

If he's wrong, tell him why rather than telling him to take his ball and go home.

<comment><USER4> This is from the Rationale for an International Standard for C, in the intro where they state their guiding principles from 2003 ([http://www.open- std.org/jtc1/sc22/wg14/www/C99RationaleV5.10...](http://www.open- std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf)):

 _Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee 20 did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator._

Note that this guiding principle was listed first. The author disagrees with one of their fundamental guiding principles. My point is that he then has a _fundamental_ disagreement with the purpose of the standard, and for that reason, perhaps he is using the wrong tool.

If someone has the guiding principle _X_ , and someone else has the guiding principle _!X_ , I contend that difference is irreconcilable.

</comment></comment></comment></comment></comment><comment><USER6> Absolutely wonderful quote from the article:

 _My tool for writing Varnish is the C-language which in many ways is unique amongst all of the computer programming languages for having no ambitions.

The C language was invented as a portable assembler language, it doesn't do objects and garbage-collection, it does numbers and pointers, just like your CPU.

Compared to the high ambitions, then as now, of new programming languages, that was almost ridiculous unambitious. Other people were trying to make their programming languages provably correct, or safe for multiprogramming and quite an effort went into using natural languages as programming languages.

But C was written to write programs, not to research computer science and that's exactly what made it useful and popular._

This is a great thing to meditate on when trying to understand why the language is still used.

</comment><comment><USER7> The Sydney Opera House is a good example, actually.

It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently).

There's just one problem. It's not a very good _opera house_. The structural requirements make it impossible to have an ochestral pit for the musicians, and the shape of the building make it very difficult to have all the usual invisible magic that makes opera work smoothly. It's cramped and oddly shaped.

The SOH is a perfect example of the triumph of style over substance. The New South Welsh who commissioned it are now facing a $1 billion dollar bill for maintenance over the coming decade.

edit: decade, not 5 years.

<comment><AUTHOR> Funny you should say that: I've always wondered how it worked in the inside.

I'm not claiming it is a great opera house, but it is a very good example of using modern building tools.

When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?) were filled into the seam instead, and that has allowed moisture to seep into the construction. I have no idea if this is true or not.

<comment><USER7> Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive.

But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design a semi-practical music hall.

It's not really architecture, in a Vitruvian sense. It's walk-through sculpture.

<comment><USER8> Your remarks are superficially plausible and fit many people's pet theories about architects. The only flaw is that they don't have any relation to the reality of the construction of the actual Sydney Opera House.

The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.

<comment><USER7> > The internals of the building were not built to Utzon's design; they were > redesigned and built after Utzon resigned in 1966.

My understanding is that Utzon's original design was, basically, impossible. The new design was a compromise made during intense negotiations with physical reality after Utzon had quit.

The further point is that those compromises rule out little things such as the ochestral pit or the tower. Things that are sorta kinda really really useful for ochestras.

If it was up to me I'd build the usual mausoleum somewhere else and turn the "opera house" into something else. A museum perhaps.

> Your remarks are superficially plausible and fit many people's pet theories > about architects.

Availability bias. We never hear about the vast majority of architects who stick to designing safe, sensible and non-hideous buildings. We _do_ hear about self-promoting designers of monuments to their own egos, such as Gehry. And naturally this tilts the public view of architecture.

<comment><USER7> On the other hand ...

As a kid I wanted to be an architect. Maybe I'm suffering from armchair expertise. "I use buildings, therefore I'm an architect".

But sometimes mistakes are so visible that end users can point them out. My personal bête noire is the business school building at the University of Western Australia. Just a stunning array of dumb details, but it's visually bold and jaunty. I guess that's what sold.

</comment></comment></comment></comment></comment></comment><comment><USER9> > Now, don't get me wrong: There are lot of ways to improve the C language > that would make sense: Bitmaps, defined structure packing (think: > communication protocol packets), big/little endian variables (data sharing), > sensible handling of linked lists etc.

> As ugly as it is, even the printf()/scanf() format strings could be > improved, by offering a sensible plugin mechanism, which the compiler can > understand and use to issue warnings.

> Heck, even a simple basic object facility would be good addition, now that > C++ have become this huge bloated monster language.

As a C user, I would not want to see _any_ of these things in C.

C++ was originally named "C with Classes," and it didn't start out as a monstrosity. Adding "simple" classes to C because C++ is too complicated makes no sense. C++ got complicated because of all of the things that users end up wanting if you walk that path. There's no reason to think that "simple" classes added to C would stay simple.

Plugins for printf()/scanf()?? Not even remotely the kind of thing that needs to be in the core language libraries.

I don't think defined structure packing would really add much; if the idea is to memcpy() the raw data into your structure, then you're just making the actual data processing part more expensive because the compiler has to store the structure in a sub-optimal way (ie. with non-native endianness). Simple expressions like x.y++ could end up being much more expensive than expected.

<comment><USER10> For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_<star> functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD.

This is so much of a win that I don't understand why everyone doesn't do it:

* Cross-platform counted/allocated/concatenated string semantics that with no annoying nits from one platform to another.

* "Native" support for printing IP addresses (%i), which gets rid of inet_ntoa and ilk, and binary.

* A registration system for adding new format codes, which is like being able to create Object#inspect functions in C code.

All of which is a roundabout way of saying I agree that we don't need to improve printf/scanf; we need to burn them with fire.

I'm going to tend to believe PHK if he thinks explicit structure packing is a win, noting at the same time how unlikely it is that any implementation of it is going to be a performance bottleneck compared with I/O.

<comment><USER9> > I'm going to tend to believe PHK if he thinks explicit structure packing is > a win, noting at the same time how unlikely it is that any implementation of > it is going to be a performance bottleneck compared with I/O.

I've spent a lot of my life writing parsers for various network formats, and one thing that I can say with authority is that at both my current company (Google) and at my previous company (Amazon) the CPU cost of parsing bytes off the network was noticeable enough to spend significant resources optimizing.

I haven't done benchmarks myself about eg. bitvectors, but I'm pretty sure I've heard that the performance of packed bitvectors is noticeably slower than non-packed. I also think the cost would be comparable to 64-bit math on 32-bit processors (ie. an overhead of 3-5 instructions per operation), which is a non-trivial cost.

<comment><USER10> In the sense that your parsing strategy influences your I/O strategy and, in particular, may incur extra copies, I buy this.

The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more.

I've done a fair bit of high performance network code (not for Amazon or Google, but, for instance, for code watching most of the Internet's tier-1 backbone networks on a flow-by-flow basis) and I'm not sure I could have won much by counting the cycles it took me to pull (say) an NBO integer out of a packet.

This stuff always makes me think about:

<http://cr.yp.to/sarcasm/modest-proposal.txt>

<comment><USER9> > The idea that Amazon has cycle-optimized network parsing code, and that they > did it for a significant practical benefit... I have no reason to doubt you, > but I'd like to hear more.

I can speak better to Google, since it's my more recent experience. Google's internal data format is Protocol Buffers (and all the code is open-sourced, as you probably know). The C++ code that is generated to parse Protocol Buffers is fast (on the order of hundreds of MB/s) as a result of a lot of optimization. This has reached a rough ceiling of what I believe is possible with this approach (generated C++). Even so, Protocol Buffer parsing code shows up in company-wide CPU profiles, and certain teams in particular have performance issues where Protocol Buffer parsing is a significant concern for them.

To address these issues, I wrote a Protocol Buffer parser that improves performance in two ways:

\- it is an event-based parser (like SAX) instead of the protobuf generated classes which are a more DOM-like approach (always parsing into a tree of data structures). With my parser you bind fields to callbacks, and you can parse into any data structure (or do pure stream processing).

\- I wrote a JIT compiler that can translate a Protocol Buffer schema directly into x86-64 machine code that parses that schema. Without the intermediate C++ step, I can generate better machine code than the C++ compiler does. In an apples-to-apples test, I beat the generated C++ by 10-40%. If you do more pure stream parsing the win is even greater.

My protobuf work is open source: <https://github.com/haberman/upb>

> I'm not sure I could have won much by counting the cycles it took me to pull > (say) an NBO integer out of a packet.

That's certainly different experience than mine. I don't know much about routers.

<comment><USER10> Bad-ass. I'm happy to be wrong if it solicits comments like this. :)

</comment></comment></comment></comment></comment></comment><comment><USER11> The C standards committee has been broken since C99 introduced long long, thus _silently_ breaking conforming code.

How do you print out a size_t, portably, without losing information? The standard says size_t is an unsigned integer type, but doesn't say way size. However, the C89 spec explicitly stated that there are no integers sizes longer than long- so the conforming way to do this is to explicitly cast the size_t to unsigned long (which, while it may add bits, is guaranteed not to lose them), and print the unsigned long.

In an attempt to save all the broken, non-conforming code that assumed that sizeof(int) == sizeof(long), C99 introduced the long long type. And, among other things, allowed size_t to now be unsigned long long. Which meant the conforming C89 code that wants to print out a size_t is now wrong. Worse yet, it's silently broken- because the type cast is explicit, the compiler has to assume it's correct. They added a new way to print size_t's, granted- but this is no help for the legacy code (or code that needs to continue to support C89-only compilers).

Of course, the punchline here is that I have yet to see code that assumed sizeof(int) == sizeof(long) that didn't also assume sizeof(void *) == sizeof(int). So all that broken non-conforming code they were trying to save? It still needed to get fixed for 64-bit.

<comment><AUTHOR> You overlook the %z printf specifier which attempts, but not quite solves the problem, because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant.

I usually end up doing printf("%j", (intmax_t)foo);

<comment><USER12> Won't "%zu" vs "%zd" do the trick? `z' is a modifier, like `l'.

(That said, I've only ever used %zu myself... don't think I've ever used ssize_t. I'm pretty sure it's non-ISO.)

<comment><USER13> It does (other variants like `%zx` are also fine).

</comment></comment></comment></comment><comment><USER4> I find this author's characterization of the history of C inaccurate. At the time, C _was_ innovative. And its existence _did_ enable computer science research, because with C, operating systems were finally portable. C itself was a worthwhile contribution to computer science research. Kernighan and Ritchie built upon prior languages, but they were able to distil what levels and kinds of abstraction were needed to implement portable systems programs. Many of the concepts in C existed in C's predecessors, but not in the same form we know them as. It's easy to under-estimate how novel that contribution is because so many of us _think_ in C now.

For a history of C from the source, Dennis Ritchie, read this: <http://cm.bell-labs.com/who/dmr/chist.html>

<comment><AUTHOR> You are rationalizing: C was not "novel", it was pretty much BCPL-light. There also were portable operating systems before UNIX, some of them were written in PL/1 and FORTRAN.

<comment><USER4> BCPL had a single data type (the "word") and no structures.

Ritchie's paper above covers the innovations in C quite well. See sections "The Problems of B", "Embryonic C" and "Neonatal C".

<comment><AUTHOR> And that's where C started out (as 'B').

Adding structures or for that matter pointers to a programming language was not "novel" in 1970.

The sheer success of the UNIX and the myth it has built, has many contemporary programmers thinking that everybody else punched cards with flint tools around the bonfire. Even MULTICS, a very innovative and in many ways wonderful OS has gotten a bad rap because of the UNIX-fanboiz cult-building.

Dennis, Ken & Brian broke ground, but very few people can correctly say what new ground they broke. (Hint: namespaces, file structure, what a file contains).

</comment></comment></comment></comment><comment><USER13> As noted elsewhere, the _Noreturn spelling is used precisely _because_ such identifiers have been reserved since the first ISO C standard, so existing conforming code shouldn't use them and hence shouldn't break.

However, rather than introducing <stdnoreturn.h> to create the pretty spelling, it would perhaps have been better if the standard specified that if you define a macro like _C_SOURCE to a suitable value before including any standard headers then you get that define.

That would mean old conforming code would continue to work, and new code would just have to start out with

      #define _C_SOURCE 20110101

(or whatever the actual date specified is) to declare its allegience. This kind of thing would also allow older-standard compilers to detect and reject code that requires the newer standard.

<comment><USER14> Neither approach would allow one to mix the two versions. Consider the following use case: program P uses two third party libraries L and M, so it uses:

      #include "L.h"
      #include "M.h"

Program P gets updated by downloading improved versions of L and M. The new version of L.h does a

      #include <stdnoreturn.h>

or

      #define _C_SOURCE 20110101

Now, program P accidentally gets processed while noreturn is a keyword.

I do not see how to fix this (you could #undef every macro that the new C standard introduces before including M.h, but M.h might have a noreturn macro of its own that is not the ISO C version). It is just as if 'old C' and 'new C' are two different languages that happen to look similar, and that can be compiled by a single compiler.

<comment><USER13> For precisely this reason, third-party libraries should not be including <stdnoreturn.h> in their external headers unless they are specifically intended to work only on C1x.

Under the _C_SOURCE scheme they _certainly_ shouldn't be defining that macro, since the program which is including them has likely already defined it and you cannot have a duplicate macro definition. If they care, they should instead be testing its current value with #if, not changing it - ie, if a library requires C11x then it would use something like:

      #if _C_SOURCE < 20110101
          #error C11x or better required for this library
      #endif

</comment></comment></comment><comment><USER15> Taking bets on when ISO C will acquire a form of templates, or taking it in even more generic direction - parametrized namespaces. Something like this (an illustrative example, don't knock me down for including _val_ into _list_ ):

      namespace(T)
      {
        struct list
        {
           T      val;
           list * next;
           list * prev;
        };

        void append(list * l, list * i)
        {
          ...
        }
      }

Then

      list<int> * foo, * bar;
      ...
      append(foo, bar);

No need for namespace nesting, default arguments and other ++isms. Just something to replace multi-line macro blocks.

<comment><USER16> Why not just use C++ without namespace nesting, default arguments, and other ++isms?

</comment></comment><comment><USER17> Well this sounds very messy, the fact you can't change the stack of the thread is a no go for many purposes, just an example, in Redis this must be done because otherwise lzw encryption will cause a stack overflow.

Also the ISO C guys completely miss how important is to provide a better libc with data structures and so forth, very very very well designed.

About the epic quote of C being a language without ambitions, one of the reasons if D or Go, or other languages are going to hardly replace C is that they are indeed, too ambitious. No one is trying to fixing C with minimal but important changes.

</comment><comment><USER18> Link to the current C1X draft which is mentioned in the article:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>

</comment><comment><USER19> > Concrete has been known since antiquity, but steel-reinforced concrete and > massive numerical calculations of stress-distribution, is the tools that > makes the difference between using concrete as a filler material between > stones, and as gravity-defying curved but perfectly safe load-bearing wall.

Ahem. [http://www.google.ie/imgres?imgurl=http://romanconcrete.com/...](http://www.google.ie/imgres?imgurl=http://romanconcrete.com/graphics/pantheon_dome.jpg&imgrefurl=http://romanconcrete.com/about.htm&h=900&w=600&sz=91&tbnid=XqbRatDd5am7uM:&tbnh=90&tbnw=60&prev=/search%3Fq%3Dpantheon%2Bdome%26tbm%3Disch%26tbo%3Du&zoom=1&q=pantheon+dome&docid=0KpRyueAMS9WzM&sa=X&ei=_4TxTq2nF5SyhAfK-N2zAQ&ved=0CD0Q9QEwAw&dur=2401)

</comment><comment><USER20> Ignoring complaints about the introduction of a new style of _Identifier, the rant about pthreads seems myopic or just plain wrong.

For a start as a vendor-neutral spec (the C standard itself), pthreads would never be adopted as-is. It simply couldn't happen for political reasons (without knowing a thing about the internals of the working group, I'm fairly confident of that). In the meantime it is still useful to define _some_ uniform cross-platform API, even if most organizations continue to use pthreads in legacy code.

Assuming "too dangerous" wasn't a direct quote: stack size is an implementation detail, something they probably intentionally left undefined. There are good reasons for this, not least baking assumptions about the underlying machine into the standard has never been a goal. Secondly, with advances like Go's dynamic stacks and its <5 assembly instruction overhead, why would you go and bake a feature akin to a modern sbrk(2) in when sexy alternatives that might see wider adoption are already seeing deployment.

As for timed sleeps, providing absolute timestamps rather than intervals is important because it prevents drift: given any function manipulating time, or some timeout, calculating some perceptible end time in the function prologue is much more immune to stupid developers introducing drift (via loops), than expecting the average Joe to account for the latency/contention introduced by system calls, the scheduler, power management, etc.

Fears regarding ntpd causing sudden jumps aren't well-founded (ntpd adjusts time very slowly, in sub-second intervals), although the general argument is fair (the sys admin, or other crazy external sources, can cause large time jumps).

<comment><AUTHOR> This comment was filled with fail.

Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own.

"Too dangerous" is a direct quote from a WG14 member.

Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applications. The C1X thread API provides no way you can set it.

With respect to timed sleeps: You can simulate wall-clock sleeps with duration-sleeps, but not the other way around. Just that simple fact should make it clear why the API, if it can only offer one kind of timeout, should offer duration-sleeps.

NTPD will step your clock up to +/- 3599 seconds. I happen to know: I helped write it.

<comment><USER20> With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic).

Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate _anything_ when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?").

The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above.

Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.

<comment><AUTHOR> First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ?

Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks.

Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller).

Fourth: What does malloc(3) have to do with thread stacks ??

<comment><USER20> For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless.

Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning.

It would be like insisting on a frewindtapedrive() library call, because your machine happens to have a tape drive (and aren't files stored on tapes eventually!). Thankfully you weren't on the committee in the 1980s. ;)

Nowhere did I suggest all threads should have the same stack size - <USER2> anything by the Go example, I suggested they might have no specific 'size' at all.

malloc(3) has nothing to do with thread stacks, it was just an example of yet something else that has very implementation-defined behaviour, for which any standardized tuning API would probably come up short.

<comment><AUTHOR> Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ?

Even on 64bit machines you can and will have memory fragmentation when you approach a million threads.

PS: A bad analogy is like a wet screwdriver.

<comment><USER20> 1) <http://gcc.gnu.org/wiki/SplitStacks>

> This is currently implemented for 32-bit and 64-bit x86 targets running > GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using > the gold linker, which you can get by building binutils 2.21 or later with > --enable-gold.

2) You're still conflating heap and stack.

<comment><AUTHOR> Too bad it is not part of the ABI specification on any known platform, so if you call a library function compiled without this magic compiler you're totally screwed.

But an interesting research project, I'll grant you that.

<comment><USER21> There's a section in that link which details how they handle calls to libraries that aren't aware of what's going on. Sounds like it works just fine.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> In case you missed it, this article is part of the 'Poul-Hennings random outbursts' section which is a nice collection of thoughts from a very talented programmer. I have always enjoyed reading these:

<https://www.varnish-cache.org/docs/trunk/phk/index.html>

</comment><comment><USER23> I don't see this as particularly monstrous - it's reasonably succinct, and in this case a macro implementation does the job just as well as a built-in linked list would, and with much more flexibility.

        #define VTAILQ_INSERT_BEFORE(listelm, elm, field) do {              \
            (elm)->field.vtqe_prev = (listelm)->field.vtqe_prev;            \
            VTAILQ_NEXT((elm), field) = (listelm);                          \
            *(listelm)->field.vtqe_prev = (elm);                            \
            (listelm)->field.vtqe_prev = &VTAILQ_NEXT((elm), field);        \
        } while (0)

(I don't understand why it uses VTAILQ_NEXT((elm), field) instead of what it expands to, (elm)->field.vtqe_next - that would make it more obvious what's going on by paralleling the use of vtqe_prev - but that's the fault of the macro implementation.)

<comment><USER24> Can anyone explain why this needs to be a macro? What does this get you over a plain function?

<comment><USER10> The idiomatic way you'd express a generic tailq in C with functions is with void-stars, which cost 4-8 bytes and incur the costs of indirecting through another memory address and, probably, of allocating lots of fiddly little structs at random times.

The macro version expresses the same generalized logic but embeds the link pointers in the structure you're queueing.

<comment><USER24> Thanks! Helpful as always.

</comment></comment></comment></comment><comment><USER25> _As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use to issue warnings._

gcc allows this with the 'format' attribute: [http://gcc.gnu.org/onlinedocs/gcc/Function- Attributes.html#F...](http://gcc.gnu.org/onlinedocs/gcc/Function- Attributes.html#Function-Attributes)

<comment><AUTHOR> Yes, but gcc gives you no way to explain to the compiler that %Q takes a struct foobar* as argument, so either you don't use extensions, and have the seatbelts provided by -Wformat, or you use extensions and have no seatbelts at all.

</comment></comment><comment><USER26> _For instance, neither pthreads nor C1X-threads offer a "assert I'm holding this mutex locked" facility. I will posit that you cannot successfully develop real-world threaded programs and APIs without that, or without wasting a lot of time debugging silly mistakes._

It's funny, Alan Cox thinks the same: [https://plus.google.com/111104121194250082892/posts/jWjJ9897...](https://plus.google.com/111104121194250082892/posts/jWjJ9897skU)

</comment><comment><USER27> Underscore-capital has been a reserved identifier prefix for many, many years. It's rather late to begin complaining about it. The side note about name- mangling on some platforms also using a leading underscore only shows that you can use a tool for years and still not understand it; that issue is completely orthogonal. I assure you, everyone on the committee is perfectly clear on the difference between name mangling and the reserved namespace.

The section on stack size is where it actually goes off the rails. _C does not require that there be a stack._ (Actually, the standard does not even contain the word "stack".) From that perspective, being able to control the "stack size" of a thread is nonsensical.

I'd be the first to agree that there have been some questionable additions to the C language, but this criticism comes off as half-baked at best. If you really care about this stuff, you should get involved with the standards process, or at least provide this feedback directly to the committee members-- they are, for the most part, a very reasonable and thoughtful group of people.

</comment><comment><USER28> The deal with underscores isn't anything new, that was there in C99 for sure. Maybe C89 but I don't know. In any case, I think getting upset about a more than decade old change is a little late and detracts from the main point.

</comment><comment><USER29> I am usually not one to appeal to authority, but I do find it amusing the number of people attempting to argue with somebody like phk over stylings of the C language. Most people on here would be overwhelmed with pride to have written a fraction of the important code he has.

</comment><comment><USER30> I'm not a C expert by any means, but is there a need for another new version? Last time I checked, some compilers hadn't even got round to implementing C99 (e.g. Visual C++ doesn't support variable length arrays). Even gcc hasn't got everything:

<http://gcc.gnu.org/c99status.html>

</comment><comment><USER31> Nothing good ever came from a committee.

<comment><USER32> Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

<comment><AUTHOR> You're probably right about that, ANSI did a couple of good things, but I'm not sure I think they came out in the black in the end.

ISO on the other hand, seems like a total disaster.

<comment><USER33> It's interesting to note the bumpy road that lead to the final standardization of C as ANSI X3.159-1989, as documented on the following post:

[http://groups.google.com/group/comp.lang.c/msg/991b9116ffa83...](http://groups.google.com/group/comp.lang.c/msg/991b9116ffa83c60?hl=en&dmode=source&output=gplain)

Dennis Ritchie spend part of that time fighting against the introduction of several new features he felt were not the proper future of the language. Unfortunately, he had little to no involvement on the C99 standardization process. The final outcome was a butchered language. I'm sticking to C89/C90 on all my C development, no matter what.

"I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99 standard is much bulkier, and though the committee has signaled that much of their time was spent in resisting feature-suggestions, there are still plenty of accepted ones to digest. I certainly don't desire additional ones, and the most obvious reaction is that I wish they had resisted more firmly." --dmr

<comment><USER34> The post you point at just talks at length about two features: const, which Dennis Ritchie liked but wanted changes to, and noalias, which he wanted to kill off. Const works exactly like he suggested; noalias became "restrict", which seems dead outside of a few standard library functions.

That doesn't seem to me like a pervasive sign of problems with C99. Personally, I find the C99 standard incredibly useful and I can hardly stand to write C code that can't rely on C99. I like having designated initializers. I like having a "bool" type. I like having structure literals, for use in arguments or return types. I like having the family of sized integer types, such as uint32_t and uint64_t. And I like having standardized versions of pre- existing features such as "long long", "inline", and variables declared in the middle of code.

Do you really despise all of those features?

</comment></comment></comment></comment></comment><comment><USER35> I wonder if he's looked at golang.

</comment><comment><USER36> phk is one of my personal heroes!

</comment><comment><USER37> """The <nostdreturn.h> file according to the standard shall have exactly this content: #define noreturn _Noreturn"""

Damn, this standard is way past the point of no return!

</comment><comment><USER38> Some of the comments here seem rather harsh and certainly after the fact. There are a lot of knowledgeable, well-intended people on the committee and the standard was ratified by nation states. So it is finished. The time to take issue with it (draft/formal comment period) has passed.</comment>


Why I attend Hackathons - <AUTHOR> http://www.geralds.co/my-life-why-i-attend-hackathons/ <comment><AUTHOR> Anyone feel the same way about these types of hackathons? What are your thoughts of hackathons?</comment>


Google Ventures - <AUTHOR> http://www.google.com/ventures/ <comment><USER2> "If you would like your venture to be considered for funding, email is the best way to reach us. Please limit your presentation to no more than 20 slides or three type-written pages. Unfortunately, due to the large volume of email we receive, we can not promise a response to all inquires."

The ones that we really like, we'll just send to our product team. Those will be the ones with no response.

<comment><USER3> Yeah, Google hasn't stolen your idea yet because they hadn't launched a venture arm to serve as a honeypot for hackers and their brilliant ideas.

<comment><USER4> Agreed. If your strategy to compete with Google is, "They haven't heard our idea yet." you're probably screwed.

</comment></comment></comment><comment><USER5> If this is anything like every other corporate venture arm that has ever existed, this will be a political (interally) and financial mess. This may also mean that the acquire-to-hire era is coming to an end at Google, which would be a negative situation for seed investors such as Y-Combinator. Overall, I'm not seeing the value equation here -- it's not as though Google and its employees didn't already have a birds'-eye-view of the startup scene.

<comment><USER6> It might not be like every other corporate venture arm, though. A lot of the things Google does, they do differently from other corporations. I've met these guys and I'd tend to give them the benefit of the doubt.

<comment><USER7> I agree that it might not be like every other corporate venture arm. Although, if I had to speculate, I think Google is doing this because it needs to diversify its business outside of generating cash through advertising. By investing in ventures, Google should be able to supplement its income nicely, keep its stock price high, and not have in increase operating expenses too much should anything that they invest in takes off.

<comment><USER5> If I were a shareholder, I'd much rather have them pay me a dividend than enter the distracting world of venture capital. These types of moves inevitably risk turning the company into yet another bloated enterprise, even if they are successful in their investments.

Google has always had a significant amount of cash. They used to use that capital to do really interesting, strategically smart things, like buying dark fiber. This was similar to Apple's philosophy - you don't see Apple distracting themselves with some sort of "Apple Ventures" play; instead, they will take advantage of their cash position to do things like cornering the market for miniature hard disks, which leads to a direct benefit to the bottom line.

Methinks there are too many cooks in the kitchen.

<comment><USER4> Wait, are you leaving out that block of time that comprises most of Apple's history where they made bad business decision after bad business decision?

</comment></comment></comment></comment></comment><comment><USER8> To me this looks like another google idea to outsource projects to smart volunteer people, who are not on Google's payrol.

Maybe this is similar to the various Google initiatives: android application competition, Google Summer of Code, Google Code Jam etc.

I think this is pretty smart because even if some project do not work out, but Google decides the people were valuable, Google can recruit them.

</comment><comment><USER3> Is it just me, or does this seem like a bad idea for entrepreneurs? I mean, if Google backed you, wouldn't that make you less desirable to many acquirers who compete with Google?

<comment><USER9> No, it wouldn't. I've been at companies that took money from large company investment arms (in my case, intel and idg) and it didn't really change things either way. Well, a little on the positive side from a connections standpoint and a lot from the fact that they gave us moolah.

<comment><USER9> (not speaking for google, btw) That said, this isn't an april fools joke, it's real. Rich Miner and Bill exist!

</comment></comment></comment><comment><USER10> Maybe this is a way to provide more degrees of freedom to some of the more promissing 20% projects that don't make sense internally?

</comment><comment><USER11> Is this not in direct competition with their "hire-by-acquisition" model? Generally, Google acquires companies early on for a price that is favorable to the founders, but wouldn't be favorable to any institutional VC since it wouldn't "move the needle" enough. If Google Ventures invests, then this means that they'd be hesitant to sell for a founder-friendly price to google itself.

Then again, maybe companies that say no to an early stage acquisition, are prime candidates for investment. Something that was impossible before Google Ventures.

</comment><comment><USER12> Seems to me their 'innovation' machine stopped working long time ago. It was expected though, after all those acquisitions. In reality, I haven't seen anything 'new', but just 'better'. This could be their way to go through the downturn.. As for us, we've applied at YC, but when I weigh it out, it's not the money that we really need, but guidance. Real costs of doing a startup, in the beginning, cant be a lot more than 100€ per month. If they are, you are simply not an entrepreneur...

<comment><USER13> Two things:

First, I'm not sure Google has ever made anything new. They've always just done it better. And that is a kind of innovation. In fact, I would argue it's the only kind of innovation. Making new things exists on a completely different level.

Second, you are right that for start ups the biggest need is guidance. But I balk at your 100/month figure. Cost of living is a cost. Even in the cases when it isn't monetary (say living in your parent's basement), there's an opportunity cost.

<comment><USER12> true. it's incremental innovation. However, they're bad at it too IMHO. Search hasn't changed since they've launched. And even then, they had nothing new..Their new algorithm..blahh. Using microcomputers for search processing. Thats the startup thinking, alright, cut all the costs, do it cheaper, do it better. There is no recipe, but they hit the right time. Thats what they did right, recognize the moment. However, google search sucks, and it sucks badly. Crawlers are as bad as spam. It clogs up. It's inefficient...and Google is too big to do anything about it, it's victim of its own size. There ARE better ways. I miss those days when we pulled hair by trying to save a KB in the mem.. efficiency and efficacy for their own sake.

Regarding the 100/month, my starting point is that you've gotta live anyway, regardless where your efforts are. I understand your view, I am trying to change it in self, and found that I approach my business efforts with much higher perseverance... = I am doing it no matter what, and I will find the cheapest way to do it, it's worth it!

Good Luck!

</comment></comment></comment><comment><USER14> I don't know if I'd want to pitch my idea to Google at such an early stage. They have enough resources to duplicate a lot of entrepreneurs' efforts. Seems like it is still best to start small, think big, and dream even bigger. Pitch the idea to Google once it has tangible promise.

My gut tells me to head to Google for sizeable funding, on the order of 100k and above. Anything less and I'd keep it with places like YC and friends and family (oh and fools too). Just my 2 pesos

</comment><comment><USER15> Is this for real or did Google start with the April jokes early this year?

</comment><comment><USER16> Wow, finally, a real competition to Y-combinator?

<comment><USER6> No; they're planning to operate like a regular VC fund.

<comment><USER17> _The fund will focus primarily on companies seeking seed funding and early stage funding, and Google Ventures will have the ability to make investments ranging from tens of thousands to "several tens of millions" of dollars, Maris said._

[http://www.wired.com/techbiz/media/news/2009/03/reuters_us_g...](http://www.wired.com/techbiz/media/news/2009/03/reuters_us_google_fund)

Sounds like competition to me. But it may also bring new opportunities for YC start-ups to be bought.

<comment><USER6> The small investments are not what makes YC YC.

Existing VCs also have the ability to make investments in the tens of thousands. But they rarely do because that's not what they're designed for.

</comment></comment></comment></comment><comment><USER18> My Angle: I am curious to see how Google structures their fund. How entrepreneur friendly will they be? Will they be a strategic investor (translation: driven by internal priorities) verses financial profit motive?

<http://www.siliconangle.com/ver2/?p=3668>

</comment><comment><USER19> This is probably the best news of the year for startups. I see Google as a great partner for entrepreneurs who will not go for small seed money like what YC, TechStars and other incubator give. A lot of founders I know are people with career not out of college folks. Kudos Google!!

<comment><USER14> Why does this guy get negative points? It's legitimate...

</comment></comment><comment><USER20> aaaand...? The site is cold and impersonal and gives no real details about their strategy or vision. I mean, c'mon...one paragraph + a few one sentence FAQs? It's almost like, yesterday, someone at Google said, "Hey, we should do that too.", and threw up a website for it. At this point, I'd much rather get funded by YC and have a good feel for what I'm really getting out of the deal, rather than just some $ thrown at me.

Also, and this might not be a negative, but Google is only throwing two guys at this venture? I'm just not convinced their heart is in this one yet. It doesn't seem well thought out for a "launch".

</comment><comment><USER21> April Fool's joke?

</comment><comment><USER22> Kudos! The more the merrier, entrepreneurs should be happy there is another source of capital for their startups.

Welcome Google Ventures!

</comment><comment><USER23> Could this be an early April fools?

<comment><USER24> Yes, it would be AWESOME PR for google to laugh in the face of everyone who submits a 3 page pitch tomorrow! HAHAHA suckers. Maybe they should publicly bash every entry that comes in.

Come on.

<comment><USER25> Agreed. Good grief.

Google always launches their April Fools' joke on April, it's always themed to look like a preexisting Google theme, and it's always obviously a joke. This one uses custom font sizes, a custom logo/theme, and it's not funny.

<comment><USER26> The joke tomorrow will be that this announcement was a joke and all the submissions were a total waste.

<comment><USER25> No. That's not how April Fools works. That's not how Google does April Fools. Google's jokes are funny for people who _don't_ spend their lives in front of computers. That's because they're, y'know, actually _funny_ and not _inside jokes_.</comment></comment></comment></comment></comment>


Does cloudflare support http and https both together? - <AUTHOR>

Does cloudflare support http and https both together? I want to implement my site which works both http and https. <comment><USER2> Yes.

<comment><AUTHOR> May I know how to do that? any tutorial?

<comment><USER2> You just need to have the ssl enabled for your site, you can usea self-signed certificate.

And the enabled full ssl on Cloudflare.</comment></comment></comment>


The Informant: learn from your users' mistakes - <AUTHOR> http://www.informantapp.com/

<comment><AUTHOR> Cameron here, designer for The Informant. We've just launched as a Heroku addon and are looking for feedback, insights & whatever you can throw at us.

What it is: The Informant is usability testing in the form of error tracking. It simply watches ActiveRecord validations and tracks when errors are triggered. It's a great way to learn where users are making mistakes, so you can improve the usability of those areas.

For example, maybe you're getting abandonment rates on account creation or checkout. The Informant will tell you if users are simply mistyping their phone number a lot, and the fix might be as simple as a copy edit or more forgiving backend logic.

tl;dr your users make mistakes all the time. Now you can learn where and why, and fix it. :)</comment>


Dr. Martin Luther King, Jr.'s "I Have a Dream" Speech Washington DC, August 1963 - <AUTHOR> https://www.youtube.com/watch?v=fIshI_qxxew <comment><AUTHOR> Detail on the March and the speech setting:

[https://en.wikipedia.org/wiki/I_Have_a_Dream](https://en.wikipedia.org/wiki/I_Have_a_Dream)

Past discussion about the video's copyright status:

[https://news.ycombinator.com/item?id=5079708](https://news.ycombinator.com/item?id=5079708)</comment>


Anatomy of a Facebook-Hosted Phishing Attack - <AUTHOR> https://tech.firstlook.media/anatomy-of-a-facebook-hosted-phishing-attack <comment><AUTHOR> The current frontpage Anatomy of a Scam Pitch Deck [1] post reminded me of this. Though the two are very different kinds of scams, it is nice to see more 'anatomies' being done.

[1] [https://news.ycombinator.com/item?id=22168978](https://news.ycombinator.com/item?id=22168978)</comment>


Congratulations Graduate Also, 9 Reasons Why I Will Never Hire You - <AUTHOR> http://bostinno.com/channels/congratulations-graduate-also-9-reasons-why-i-will-never-hire-you/

<comment><USER2> Points 2, 4, 7 are entirely reasonable.

Point 1 is relatively subjective, one person's "too long" can very easily be another person's "not enough."

Point 3 - I guess YMMV. If I'm hiring someone, a "thank you" indicates some thoughtfulness, I'm not going to be offended that an applicant didn't offer a treatise to her experience at the interview. That said, a more complete "thank you" note would probably put that applicant ahead of another applicant with a shorter note.

Point 5 - somewhat disagree, I think it's just as much a job for an employer to guide an applicant/employee as much as it is for an applicant/employee to sell herself.

Point 6 - in the context of "don't get social media, but thinks you do" I can agree, but the implication here is that an applicant needs a social media presence. The author works for a marketing firm, so perhaps in that industry it's true, but no so much for other industries. I'm an engineer who works a lot for state and federal agencies, and there are pitfalls to social media that one has to be aware of (being perceived to represent "official" policy, accidentally revealing incorrect information, providing material for opposing legal counsel, etc).

Point 8 - completely disagree. Not everyone wants or needs to have a public presence, and some folks may be uncomfortable with providing information to a online service that will almost certainly try to sell that information. I'm fine with that. That said, if you do have a LinkedIn profile, the info better match what's on your resume.

Point 9 - agree, but I also realize that internships/co-ops may not be possible depending on your circumstances. I'll give bonus points for having an internship, but won't necessarily dock you if you don't have one, and your qualifications/references are otherwise stellar.

Point 10 - there's courtesy and there's shyness. As a shy person myself, and recognizing that someone fresh out of college may be overwhelmed at an interview, I'm going to cut you some slack. That said, one thing I will look for is evidence of bias - for example, if I introduce you to a female supervisor and then you spend the next 20 minutes of the interview completely ignoring the female and only addressing her male underling, I'll notice.

TL;DR: job applicants, don't think all 10 of these reasons apply to all jobs everywhere, be mindful of your industry and the company you are applying for.</comment>


A Techie Birth Announcement - <AUTHOR> http://chronicdabbler.blogspot.com/2008/12/techie-birth-announcement.html

<comment><USER2> A CS professor who taught my friend came into class soon after his wife gave birth and lamented his new baby's "poor user interface."

<comment><USER3> Not to mention his "core dumps".

</comment></comment><comment><USER4> Congratulations! Did you buy the domain name yet?

<comment><USER5> Not yet, but that would be one hell of a domain name. :)

</comment></comment><comment><USER6> Congrats - but - don't techies tend towards metric units?

<comment><USER5> For many things, yes, I prefer metric... but I was raised on the imperial system and human body measurements just make more sense to me that way. 3.47kg just doesn't work as well for me as 7lbs 10.6oz. :)</comment></comment>


Microsoft is testing a malware-proof Edge browser - <AUTHOR> http://www.techradar.com/news/microsoft-is-testing-a-malware-proof-edge-browser <comment><USER2> Interesting, this is basically what Bromium does. Kinda cool!</comment>