Free DNS management service - <AUTHOR> https://entrydns.net/ <comment><USER2> I'm not sure I'd trust something as mission-critical as DNS to a business which doesn't appear to have a viable business plan.

I noticed you're suggesting the freemium route - any details on how that's planning to work? Buying more record slots? Restrict certain types of records? Free GApps/Heroku/AWS configuration, custom configurations cost?

<comment><USER3> I agree. I use pointhq.com because they have a free version, but they also have a paid version if you plan to use it on more then 10 domains. I think this is the better route to go.

<comment><USER4> I went with Rackspace DNS, which is free and has no limits. There are many, many other options. I think Linode has a similar offering?

<comment><USER5> My favorite thus far has been <http://dns.he.net>. Hurricane Electric runs many free services and when the time comes, I will be paying for their paid services as well. TunnelBroker alone is fantastic and has saved me many hours.

On topic, I checked out EntryDNS when they first announced it on HN. Glad to see many improvements, such as including HTTPS support, AAAA records, etc. Great job!

Edit: as a suggestion, let me view DNS zones directly. That would be very helpful to some, and also eliminate the need to learn how to translate between different providers' UI's.

<comment><USER6> You have no idea how awesome this is.

I've been looking for a good, reliable, and fully-featured managed DNS literally for the last 2 weeks straight (I'm tired of the default managed offerings from Rackspace, they are pretty bare-bones). None (free or paid) I've found have impressed me.

I've taken Hurricane Electric's IPv6 certification courses, used their Tunnel broker services, and I implicitly trust their tech. They really know what they're doing and their services are complete, well-managed, and work great. I will also gladly pay for their offerings if they move in that direction.

For those of you who haven't been introduced to Hurricane, please visit the site above and explore it. I highly recommend the IPv6 certification as a way to introduce yourself to IPv6 concepts, and the tunnel broker service as a way to set your own sites and clients up to use it before you have available infrastructure from your ISP or host.

Thank you very much, this is great news indeed.

<comment><USER5> Yes, HE's only limit is something like 50 zones, which for my projects is plenty. Their interface is solid and simple to use, and they support reverse DNS as well. Also, their support for these free products rocks. I haven't had support that great for any SaaS/PaaS out there, ever. They respond very quickly and actually know what they are talking about.

So far I've found only two issues: (1) no support for DNSSEC and (2) their use of HTTPS is somewhat spotty, so you must pay attention to it yourself.

Glad you found what you were looking for, and thanks for plugging TunnelBroker. The more people use services like these, the more IPv6 we'll be seeing.

Edit: I take it back. Looks like they always use HTTPS. It's tunnelbroker.net and tunnelbroker.com that don't.

</comment></comment></comment></comment></comment></comment><comment><USER7> I don't get it, they say they're filling a niche, yet pretty much every registrar offers DNS tools for free anyway (after all, you bought a domain from them) and there are a number of free dynamic DNS services out there too.

Unless I'm overlooking some killer feature, this is a typical case of a startup not reviewing their market before hand.

</comment><comment><USER8> A cautionary tale: I had good luck with ZoneEdit when they launched. It was/is kind of in the same space as this. Their new UI is okay, but yours looks a bit better. They started out with freemium, but eventually had to re-structure how their premium service worked, and in the process crippled how the free service worked. It got bad enough that I abandoned them.

Be very careful how you structure your premium offerings. People don't like when the free version starts losing features or capacity.

</comment><comment><USER9> Well the SSL certificate isn't valid so that's not a good start! I also use PointHQ.com and have been for about 2 and a half years now. Brilliant service. Built by the guys at aTech Media who make Codebase - <http://codebasehq.com> and a few more useful apps =]

<comment><USER10> _Well the SSL certificate isn't valid so that's not a good start!_

I think the certificate's valid, they're just not sending out a required intermediate certificate. Doesn't exactly inspire confidence though.

<comment><USER11> <https://www.ssllabs.com/ssltest/analyze.html?d=entrydns.net>

</comment></comment></comment><comment><USER12> Route 53 is not really expensive, if you have just a few important domain I would use a service with a 100% up record. DNS is just too important.

<comment><USER13> Agreed. We use it and it has been rock-solid, has a handy API, and a nice usable console that doesn't get in the way of someone who knows what they're doing.

The one bummer with Route53 is <http://aws.amazon.com/route53/faqs/#DNSSEC>.

</comment></comment><comment><USER14> Well, <http://zoneedit.com/> has been around for quite long now, that does this, and has a business model that seems to work?

<comment> amar-c Or <http://dns.he.net>

Works OK for me..

<comment><USER15> For smaller deployments (they have a 50 domain limit on the free accounts), Hurricane Electric DNS has been great. The business case is straightforward and they have top notch IPv6 support.

</comment></comment></comment><comment><USER16> You need to state how many servers you have and where they are geographically.

Site is friendly but devoid of a technical FAQ

(it's also slightly confusing in that it's not just DNS management you are offering but actual authoritative DNS service)

These are your competitors, at least the commercial ones:

[http://socialcompare.com/en/comparison/hosted- authoritative-...](http://socialcompare.com/en/comparison/hosted- authoritative-dns-providers-r5oyhz1)

</comment><comment><USER17> These guys have been around for a long time: <http://freedns.afraid.org/>

</comment><comment><USER18> It's "made by geeks" but doesn't support IPv6. I don't buy that :-).

<comment><USER5> It does. You have to create a zone, then edit it and it lets you add all the records. Startled me at first too, as IPv6 is my current #1 requirement for a DNS provider.

</comment></comment><comment><USER19> Many round-robin DNS failover providers can afford to offer free DNS, though API access is a differentiator:

<http://www.cloudflare.com/plans>

<http://www.dnshat.com/free-dns.html>

etc.

</comment><comment><USER20> namecheap does offer free dns, but an API controlled free DNS seems nice. The people who will likely need it are probably willing to pay $0.50 a month to amazon though.

</comment><comment><USER21> Apart from hosting DNS myself (which I gave up on - not worth the effort), I have been using DNSMadeEasy - $30.00 for 10 domains is pretty good and they are rock solid.

</comment><comment><USER22> While an interesting concept, I don't think I'd be willing to trust my internet lifeblood to a group that has yet to make a name for themselves.

I'll just continue to host my own DNS.

</comment><comment><USER11> dnsmadeeasy.com - $30/year - anycast - Google for their uptime record.

or if your site isn't worth the $30 just use your registrar's free dns.

</comment><comment><USER23> aTech Media has had Point free for a while. AFAIK it supports about the same features.

</comment><comment><USER24> "Create an Account Now

It's free, sign up in 60 seconds"

Here's a free grammar correction for that comma splice:

"Create an Account Now

It's free. Sign up in 60 seconds"

</comment><comment><USER25> i think DNSPOD.com is the best dns solution. and if you have 1k+ domains , dnspod.com is your only reasonable chioce.

<comment><USER26> Not sure how you can claim that when their non-free plans are listed as "Coming soon".</comment></comment>


Ask HN: What are the best sites to find Beta users for my App? - <AUTHOR>

if you too like to check the app you can surely go to www.getplix.com :) <comment><USER2> Go to where your potential users hang out and ask around. This could be a forum site that they frequent.

Also depends how public you want to make it, places such reddit might work.

<comment><AUTHOR> Thanks for the reply :)</comment></comment>


The History of the URL: Domain, Protocol, and Port - <AUTHOR> https://eager.io/blog/the-history-of-the-url-domain-and-protocol/ <comment><USER2> This is a good article. A few nits:

It was _the_ ARPANET (or _the_ arpanet since most systems were case- insensitive in those days - Multics, and later Unix, were exceptions, not the rule) as in area's network, that used arpanet protocols like NCP. You do use "the" the first time in your article but seem to have dropped it after that.

CHAOSNET was just a LAN protocol like "ethernet" or pup -- also used what we call 10base2 "thicknet" coax. It was developed at MIT's AI Lab and was pretty much used only there and at a few institutions close to MIT like Symbolics and LMI.

In the NCP days routing was handled by IMPs (Interface Message Processors) which were not PDPD-11s, and when '11s were used they were smaller than the 11/70s which you used to illustrate the article (11/70s were the largest PDP-11s made -- still 16 bit unlike the 36-bit PDP-10s which were the mainstay of academic computer science in those days).

> In this era before 'mail servers', if my computer was off you weren't > sending me an email.

In that era few people had what you would consider a personal computer and more likely you logged into a timesharing system that had your mail along with everything else. So your statement is true, yet an anachronism. Even if you did have your own host, the upstream host (one earlier in the ! path) would have your message so you could consider it literally your mail server.

</comment><comment><USER3> DNS was never ASCII only, and I've never seen DNS software make that assumption--that "every piece of internet hardware from the last fourty years, including the Cisco and Juniper routers used to deliver this page to you [assumes ASCII]".

The essay links to RFC 1035 to support its claim of ASCII only, but RFC 1035 actually says is

"However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided."

and

"Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. "

Indeed, some country TLD servers were (and maybe still are) supporting non- punycoded UTF-8 directly.

Lookups are supposed to be case-insensitive, but it's always been verboten to actually modify the case of names in a DNS packet. A query reply is supposed to include the identical question name in an 8-bit clean manner. Indeed, some DNS clients will arbitrarily randomize the case of names to add an element of randomness to thwart DNS spoofing attacks. (If the answer isn't the same 8-bit name, you ignore it just as if it came from a different IP address then you sent it to.) Unfortunately there exist enough broken DNS proxies out that software like Firefox or Chrome can't do this without headaches, but I've never encountered such broken software myself (at least, not that I knew about). At worst I've seen query responses which lack the question portion altogether, and this can cause timeouts (rather than immediate failures) for software which enables anti-spoofing measures. But I've also seen responses which lack the same QID, too. There's always broken software; the threshold for when you can ignore it is highly context dependent.

<comment><USER4> > some DNS clients will arbitrarily randomize the case of names to add an > element of randomness to thwart DNS spoofing attacks.

I believe this is undefined behavior. It shouldn't be something you count on. The only reference I found in the spec that implies this is:

 _The question section of the response matches the question section of the query_

From rfc 1034. Which isn't very specific, but could be interpreted by some in the way you mean.

If you want to secure the request, it's best to randomize the QID and outbound port. If a server responds with the wrong QID, I'd ignore it.

<comment><USER3> From RFC 1034 S. 3.1: "[D]omain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed."

First, we can't speak of it being undefined in the same manner as we do undefined in the C standard. The DNS standards weren't this rigorous, and didn't use consistent terminology like MUST and SHOULD universal in today's RFCs.

Second, they were explicit that while the existing services (e.g. IN class and A record type) were ASCII-based and case-insensitive, the binary protocol was meant to be 8-bit clean, that some labels might be 8-bit in the future, and it was expected and mandated that this capability be preserved. So strictly speaking, the RFC allowed a server to, e.g., modify the case of an A record label on the wire, but not of some unknown label. In practice it's easier to simply treat all labels in an 8-bit clean manner, and that's in fact what major implementations do. You literally have to go out of your way to do otherwise while still obeying the standard.

Caching name servers like BIND and unbound will reply with the identical question label. For example, notice in the following how the TTL is decremented (and thus being pulled from cache) but the query case is preserved:

      % dig -t A google.com
      ; <<>> DiG 9.8.3-P1 <<>> -t A google.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20838
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

      ;; QUESTION SECTION:
      ;google.com.			IN	A

      ;; ANSWER SECTION:
      google.com.		105	IN	A	220.127.116.11

      ;; Query time: 0 msec
      ;; SERVER: 192.168.2.1#53(192.168.2.1)
      ;; WHEN: Sat Jul  9 00:45:57 2016
      ;; MSG SIZE  rcvd: 44

      $ dig -t A GoOgLe.com
      ; <<>> DiG 9.8.3-P1 <<>> -t A GoOgLe.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7947
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

      ;; QUESTION SECTION:
      ;GoOgLe.com.			IN	A

      ;; ANSWER SECTION:
      GoOgLe.com.		95	IN	A	184.108.40.206

      ;; Query time: 0 msec
      ;; SERVER: 192.168.2.1#53(192.168.2.1)
      ;; WHEN: Sat Jul  9 00:46:07 2016
      ;; MSG SIZE  rcvd: 44

In reality, the core DNS infrastructure was perfectly capable of fully supporting raw UTF-8 labels (Though a DJB page suggests that some older versions of Unix gethostbyname stripped 8-bit labels.) Unlike other infrastructure, the implementations were fairly homogenous (until a few years ago BIND absolutely dominated), so ad hoc (and broken) implementations were few and far between. And unlike other infrastructure, there was very little incentive to violate 8-bit cleanliness. The biggest problems were not that some ad hoc implementations modified case, per se, but that some ad hoc caching proxies would reply with the case of a cached record. That's out of sheer laziness, or because they didn't read the standard closely enough. It's telling that BIND, unbound, and other major caching proxies are careful to preserve case in the reply even though that's not necessarily the easiest solution.

The real problem was edge software, like browsers, e-mail clients, etc, that baked in way more assumptions than warranted. Arguably IDNA and punycode took more effort to roll out than would have alternatives based on raw UTF-8. The core infrastructure software wasn't a real barrier, and the IDNA solution required more code at the edges. While the major browsers were facing lots of work regardless, most ad hoc software would have been fine just fixing 8-bit cleaniness problems and then punting on things like glyph security issues, especially if they weren't directly user facing. The vast majority of edge software would have just required some slight refactoring, not huge rewrites with library dependencies for the new compression scheme, etc.

</comment></comment></comment><comment><USER5> > The first 32 identified the remote host, similar to how an IP address works > today. The last eight were known as the AEN (it stood for "Another Eight-bit > Number"), and were used by the remote machine in the way we use a port > number

Gold.

Great read, it hits home for me with the right mix of nostalgia, history from before my time, and funny little things I never knew.

</comment><comment><USER6> Another nitpick: on iOS Safari, that pizza-poo-domain name actually does show up in the address bar. So there has to be another mechanism that prevents the Amazon-with-Cyrillic-"a"-trick which I guess involves normalization.

</comment><comment><USER7> Great read! "Thanks" for all the Wikipedia links - I ended up wasting a few hours reading more details

</comment><comment><USER8> For http:com/example/foo/bar/baz how would you determine what the host is?

<comment><USER9> It doesn't actually matter: in a world which used that sort of addressing, one could imagine saying to com 'give me HTTP info for your example/foo/bar/baz,' to com/example 'give me HTTP info for your foo/bar/baz' and so forth; in that case, com would just say, 'hey, go talk to 266.328.0.1 (that's what I call example)' and 266.328.0.1 would cheerfully return the information stored at the filesystem path /foo/bar/baz, or it could say, 'hey, I call foo 463.622.42.17' and your browser would keep resolving.

Me, I kinda wish we wrote URLs as [http://com.example.host.invalid/path/to/resource](http://com.example.host.invalid/path/to/resource).

<comment><USER2> > Me, I kinda wish we wrote URLs as > [http://com.example.host.invalid/path/to/resource](http://com.example.host.invalid/path/to/resource).

The UK's predecessor to the DNS worked this way (a "big endian" hierarchy). Sorry I can't remember the network name; if I remember it was rooted in gb.

<comment><USER10> I am old enough to remember the final year of JANET with the backwards addresses.

At the time I was at Plymouth Marine Laboratory with a university email address of the type email@example.com - i.e. backwards. However, in those days there were many different things about networks, you could have several connector types in a room so anything beyond email was a bit like the difference between travelling across state borders in the U.S. and travelling across the Iron Curtain. I can't remember how one got from one's VT terminal to the wider internet on VAX/VMS but that was possible. FTP and some Telnet was how it worked, none of this www stuff.

The change of address structure to normal internet style was not that big of a change, you would think it would have been as traumatic as changing what side of the road to drive on or the Millennium Bug, but, the change happened with no huge amount of work needed or resultant disruption.

<comment><USER11> I am old enough to have been a JANET site administrator.

The JANET when I used it ran over a private X.25 network with a few gateways to BT's public X.25 network. There was a gateway to the internet at University of London Computer Centre but it only provided an FTP client.

</comment></comment></comment></comment></comment><comment><USER12> very good info thanks

</comment><comment><USER13> > This restriction on HTML was ultimately removed in 2007 and that same year > Unicode became the most popular encoding on the web.

Nitpick: Unicode is a character set, UTF-8 is an encoding.

<comment><AUTHOR> Should be fixed shortly, thanks!

</comment></comment><comment><USER4> Nit pick: the modern internet is built on IP, not TCP/IP, but it would be fair to say most protocols use TCP today, but definitely not all.

</comment><comment><USER14> Great article. Another nitpick:

> _It's important to dispel any illusion that these decisions were made with > precence for the future the domain name would have._

I don't think _precence_ is a word, and I'm not sure what would make sense as its replacement.

<comment><USER15> Prescience (knowledge of things before they happen)

<comment><USER16> Now I wonder if "foreknowledge" could have come into English as a calque of Latin "praescientia".</comment></comment></comment>


Only An Idiot Would Rob a Bank: How Inflation Deflated the Stick-Up - <AUTHOR> http://thebillfold.com/2012/05/only-an-idiot-would-rob-bank-inflation/

<comment><USER2> _"Assuming, for simplicity's sake, that each bill weighs a gram and we average the denominations out to all twenties."_

Doesn't this assumption negate the point about the weight of the currency? Inflation means that larger notes are now more common - to assume Dillinger had the same portion of twenties as the Lufthansa heist is silly.

In the US this has been less the case, but to take Australia for example I remember my grandmother withdrawing cash in $2 and $5 notes. Now (25 years on) the ATMs only dispense $20s and $50s, and the $2 bill hasn't existed since 1988.

<comment><USER3> _In the US this has been less the case [...]_

No kidding. When I was a kid in the 80s, ATMs only seemed to dispense 20s. Now a large percentage of them also dispense 10s.

A decade or so ago, I was receiving my paycheck via a Maestro card, which at that time could be used as an ATM card in the US, but not at a POS terminal. This meant that even for larger payments, I had to withdraw a large amount or go to several different ATMs, leading to an embarrassing and stressful situation when I tried to withdraw $1000 from an ATM, which was fine as far as the software was concerned, but jammed the dispensing mechanism. These days I'm not sure any ATM will let you withdraw more than a few hundred.

On the other hand, I suppose that most of what people carry cash for is food, and food prices haven't risen in the same fashion that housing and fuel prices have, so the amounts of cash people carry hasn't had to rise that much.

<comment><USER4> If you're in a really bad area of town, they also dispense 5s. With a $1-2 processing ATM fee.

</comment></comment></comment><comment><USER5> It's also a different world than the depression. You can't rent a nice apartment, buy a house, or buy a (new) car with cash.

If you commit a crime, moving out of town isn't going to help you avoid the police. If you're wanted, you can't safely drive, or have a credit card, or a bank account, or have a home with utilities, or have a job with a reputable employer. That's a hard list of things to give up.

<comment><USER6> You can actually do all of those things with cash.

It's not conventional, but people do make all of those purchases with cash.

<comment><USER5> You'll notice all the qualifiers in my post- "nice" apartment, "new" car. Any vaguely reputable rental company is going to want a bunch of financial data, that proves you can afford it over the lifetime of the lease. You can't do that with 100 grand in a suitcase.

Any new car is going to be over 10k, which means you need to either report the transaction or get a loan from a bank... who is going to want proof you can pay it off.

Housing is the same thing. So yes, you can use cash- but you're going to have a hell of a time using cash that doesn't have an obvious, legal source.

</comment></comment></comment><comment><USER7> "For wage earners this isn't so much of a problem as long as wages inflate as well (which, well, they haven't)"

This, I think is a bit of an overstatement. Although wages may not have inflated too much, compared to, say gold, they have certainly inflated in terms of quality of life. Prices of personal possessions are extremely low, compared to 50 or 100 years ago, mostly due to "technical progress". 100 years ago a watch was a great luxury - passed down from generation to generation. But today "everybody" owns a smartphone, a computer, a wardrobe full of clothes. Everyone can afford high-caloric food (at least in the "developed world"). Not very much like 100 years ago.

<comment><USER8> It is probably referring to the fact that income for the bottom 50% of US earners has remained largely stagnant since the 1970s (after accounting for inflation)

[http://www.washingtonpost.com/blogs/wonkblog/wp/2012/07/31/w...](http://www.washingtonpost.com/blogs/wonkblog/wp/2012/07/31/wages- arent-stagnating-theyre-plummeting/)

[http://www.newyorker.com/online/blogs/johncassidy/2011/09/po...](http://www.newyorker.com/online/blogs/johncassidy/2011/09/poverty- figures.html)

<comment><USER9> Only because new people entered the country and dragged the median down.

[http://www.chrisstucchio.com/blog/2011/immigrants_simpsons_p...](http://www.chrisstucchio.com/blog/2011/immigrants_simpsons_paradox_great_stagnation.html)

Consider a nation with Steve (income $50) Bill (income $50) and George (income $100). The median is $50. Now suppose Steve's income remains the same, Bill's goes up to $60, and George's income goes up to $150. The median has gone up to $60, right?

However, suppose during this time, Jose (income $30) and Hector (income $40) immigrated. The median is back down to $50 even though _every single person_ saw their income go up.

The longitudinal data I link to demonstrates that this is exactly what happened (albeit with different numbers).

(Note: this is an argument against drawing conclusions from Simpson's paradox, not an argument against immigration.)

</comment></comment></comment><comment><USER10> I was thinking about this the other day from the opposite direction. Seeing the Salvation Army people outside grocery stores with the bells is a little sad now--because of inflation, the value of loose change just keeps going down and down. At the same time, debit/credit cards are obsoleting cash and making the now-less-valuable change even more scarce.

At least here in the bay area, I imagine they'd do much better with square readers than a bell and a bucket for change.

<comment><USER11> Teenagers tell me panhandling is still very lucrative, just throw on some ratty clothes and you still make 2x minimum wage.

<comment><USER12> People are especially generous to homeless youth. You have to watch out for very caring individuals that try to take you to get food or a shelter.

</comment></comment></comment><comment><USER13> Interest rates are set by central banks, central banks are doing a form of central planning of the price of new money in other words controlling the interest rate. As we know from history of the past central planning works pretty badly for optimal resource allocation.

The American Federal reserve is a private institution, founded by members travelling on a secret journey from a train station in New Jersey to a private club on Jekyll Island. There the key elements of the Federal Reserve act was created.

On board the train was senator Aldrich, the senators daughter was married to Rockefeller. There was also representatives from Rockefeller and Warburg / Rothschild banking dynasty family.

The whole system, seem to be constructed to create as much debt as possible, which channels money upwards in the economic pyramid.

See Edward Griffins book the creature from Jekyll island <http://www.bigeye.com/griffin.htm>

\- The system is flawed

<comment><USER14> Nice conspiracy theories, but have you noticed that every other country also has a central bank even though they didn't have Rockerfellers and Rothschilds? And when you look at the big picture our economy is extremely successful, the envy of the world.

<comment><USER15> There is an important difference between the Federal Reserve and other central banks which is that the Federal Reserve is privately owned by the banks, whereas in other countries it's owned by the people. Ultimately then, the Federal Reserve is more incentivized to maintain the system than in other countries. One day this may be important.

<comment><USER16> The public vs. private aspects of the Federal Reserve seem to be quite a muddle, per articles in Wikipedia:

Federal Reserve System: "The Federal Reserve System's structure is composed of the presidentially appointed Board of Governors (or Federal Reserve Board), the Federal Open Market Committee (FOMC), twelve regional Federal Reserve Banks located in major cities throughout the nation, numerous privately owned U.S. member banks and various advisory councils."

Federal Reserve Bank: "The Federal Reserve Banks have an intermediate legal status, with some features of private corporations and some features of public federal agencies. The United States has an interest in the Federal Reserve Banks as tax-exempt federally created instrumentalities whose profits belong to the federal government, but this interest is not proprietary. In Lewis v. United States, the United States Court of Appeals for the Ninth Circuit stated that: 'The Reserve Banks are not federal instrumentalities for purposes of the FTCA [the Federal Tort Claims Act], but are independent, privately owned and locally controlled corporations.' The opinion went on to say, however, that: 'The Reserve Banks have properly been held to be federal instrumentalities for some purposes.' Another relevant decision is Scott v. Federal Reserve Bank of Kansas City, in which the distinction is made between Federal Reserve Banks, which are federally created instrumentalities, and the Board of Governors, which is a federal agency."

</comment></comment></comment></comment><comment><USER17> Isn't this more of a consequence of the US not changing their money for a very long time.

I remember as a kid in Italy that the smallest bill wash 1000 ITL (about 50 eurocents) and now the smallest bill is 5 euros, and that is less than the inflation over the 12 years we've had the euro.

So by that logic, bank robberies have become more profitable here as of late.

</comment><comment><USER18> this was one of the more entertaining and enlightening articles I've read in a while.

It reminds me of the scene in The Dark Knight when the Joker is sitting on a literal mountain of cash.

When visualized that way, it's very true that bank robberies no longer make sense.

</comment><comment><USER14> Interestingly, the US Treasury has resisted calls for larger denominated notes precisely because of criminal concerns. Cops don't want criminal organizations to be able to carry more than a million or two in a suitcase.

<comment><USER19> Turns out this is something people want to do in Switzerland. I got a 1000CHF note before at the post office when cashing a check, I was very nervous! I think even the Euro has a 500 note.

I really wish I had that in China. Sometimes when paying the landlord, I would need a bag full of 20K RMB, at 100 RMB a note, which is 200 notes. When my landlord wanted bi-yearly rent, it was easier to go to the bank and just do a transfer (electronic banking isn't done in English, unfortunately).

<comment><USER20> The 1000 CHF bills are pretty ridiculous (1 CHF =~ 1.1 USD). But they're also in common enough use that you can pay for a relatively small purchase in a supermarket with one, and the cashier won't bat an eye. It'll just be a quick check under a UV light at most.

<comment><USER21> Meanwhile, in the UK, most people rarely if ever handle the 50 pound notes that are in circulation - I've only seen perhaps a handful of them in the 12 years I've lived in London.

<comment><USER22> That's mostly because they're harder to get rid of than Scottish currency. Only the major supermarkets seem to accept them.

</comment></comment></comment></comment></comment><comment><USER23> Another reason that the Fed is creating so many new USD is to drive down the value of the USD versus other countries; ie, to make US exports cheaper.</comment>


Police Raided Uber's Paris HQ - <AUTHOR> http://gizmodo.com/police-have-raided-ubers-parisian-hq-1692102556

<comment><USER2> Taxi police just what we need

Whats next ThoughtCrime? Err operator delete that.

I was never here!</comment>


Ajit Pai is making lots of enemies on the road to 5G - <AUTHOR> https://www.politico.com/news/2020/07/08/ajit-pai-enemies-5g-351803 <comment><USER2> Sounds like this is mostly about industries that have to give up their grandfathered monopolies on slices of spectrum so that it can go unlicensed and be used by everyone?</comment>


Digital Currency: ten years before Bitcoin, Neal Stephenson's Cryptonomicon - <AUTHOR> http://www.laurelzuckerman.com/2013/03/digital-currency-ten-years-before-bitcoin-neal-stephensons-cryptonomicon-.html <comment><USER2> Very different concept: the digital currency in Cryptonomicon was centralized, to be issued by a bank or bank-like institution that owned massive gold reserves and could thus be trusted. The anonymity could be guaranteed because the bank would operate in national state that guaranteed anonymity by law (a so-called data haven).

<comment><USER3> That was one bit of Cryptonomicon that bothered me - the Sultan simply decided one day to guarantee anonymity, but he was an absolute monarch so he could just as easily decide one day to remove anonymity.

[Mind you, that is a minor niggle - Cryptonomicon is one of my favourite novels]

<comment><USER2> I agree it is totally unrealistic; no small country could resist the international pressure that would generate

</comment></comment></comment><comment><USER4> anarky - your comment is showing up as dead, which is a shame since it was interesting

> And 5 years before Cryptonomicon there was Tim May's Cyphernomicon (which > obviously inspired the title and theme of Stephenson's book).

> In 1995 there was Stephenson's short story in Wired about digital cash - > "The Great Simoleon Caper".

> Of course, the protagonists of Atlas Shrugged had renounced paper money and > started using privately minted gold coins from Midas Mulligan's Bank way > back in 1957.

</comment><comment><USER5> Honestly, Cryptonomicon is probably my favourite novel. A bit hard going the first read through, but it's immensely re-readable.

<comment><USER6> Anathem makes Cryptonomicon look easy. I'm literally working my way through it right now. Stephenson is one of my favorites, so it's worth it.

<comment><USER7> Try The Baroque Cycle. I rarely use the word epic, but it is a fitting descriptor for that series.

</comment></comment></comment><comment><USER8> And 5 years before Cryptonomicon there was Tim May's Cyphernomicon (which obviously inspired the title and theme of Stephenson's book).

In 1995 there was Stephenson's short story in Wired about digital cash - "The Great Simoleon Caper".

Of course, the protagonists of Atlas Shrugged had renounced paper money and started using privately minted gold coins from Midas Mulligan's Bank way back in 1957.

<comment><USER9> > _And 5 years before Cryptonomicon there was Tim May's Cyphernomicon (which > obviously inspired the title and theme of Stephenson's book)._

Actually, no, according to Stephenson. From the appendix of my copy of _Cryptonomicon_ :

"It has been pointed out that the word "Cryptonomicon" bears obvious similarities to "Cyphernomicon," which is the title of a Cyperpunk FAQ document by Tim May. This leads to the question: am I committing some form of plagiarism, or rendering homage, or what? The answer, strangely enough, is niether. I was completely unaware of the existence of Tim May's Cyphernomicon at the time I came up with "Cryptonomicon."

<comment><USER8> I read that too, and I don't want to doubt Stephenson's word, but it's very hard to believe that he hadn't run across Cyphernomicon or the Cypherpunks (hell, they were on the cover of Wired Issue #1.02) in researching crypto for Cryptonomicon. Maybe he forgot he did but the term stuck in his subconscious. Or maybe he really didn't do even basic research before coming up with the name?

PS. Yes, I am the commenter previously known as anarky. No idea why that account got banned after a single comment.

</comment></comment></comment><comment><USER10> I basically only use digital currency right now, and it's just your normal Euros. I get paid by the company through internet banking and it gets deposited to my bank account. I pretty much only check my bank information online. When I pay (99% of the time) with my debit card, the card reader at the store connects through 3G to the banks server to verify the transaction. I'll go weeks without even touching paper money / coins. I can't imagine how to make it more digital than that and this is what basically everyone in Finland has done for 5+ years

<comment><USER11> The difference here is that the Euros you're working with can't be held digitally as actual stored value. You can't carry them with you, and they must at all times be tied to an identity. With true digital currency, you're not tied to someone else's server for transactions. You can make the exchange in person, no trusted third party required. Your Euros require a trusted bank to hold your Euros, and a trusted country issuing them.

<comment><USER12> Just a small clarification, you can't carry bitcoins with you either.

Bitcoins are not little pieces of information you can hold on a thumb drive, but an agreement by the network that a certain balance belongs to some address.

You are absolutely tied to a server for transactions, and there is a trusted third party required. That third party is the bitcoin network itself. It is impossible to make a bitcoin transaction while offline because making a transaction means updating the state of the network, not merely giving somebody information.

</comment></comment></comment><comment><USER13> Ten years before bitcoin, we had e-gold. And it was good. And now the government owns it anyway.

</comment><comment><USER14> Though in Cryptonomicon the currency was backed by hidden Japanese and Nazi gold.

<comment><USER15> Pecunia non olet, meus amicus.

<comment><USER14> Well I didn't mean it in that sense.

</comment></comment></comment><comment><USER16> Twenty years before Bitcoin, David Chaum was showing us how to make provably secure digital cash protocols.</comment>


Let's Write an LLVM Specializer for Python - <AUTHOR> http://dev.stephendiehl.com/numpile/ <comment><USER2> Interesting. I currently use Python's AST to convert some nested logical query expression (in a syntax unique to my application) into bytecode executed by a specialized VM (I originally tried using V8 and LuaJit for this but performance wise that was unsuccessful; the project replaced some old Boost::Python C++ code). This article should make it easy to get started attempting an LLVM replacement.

<comment><USER3> Yes, LLVM is a great approach for doing code-gen from arbitrary specialized VMs. And the Python interface to it makes it easy to experiment. We no longer use llvmpy for Numba (we use a simpler interface llvmlite) and so llvmpy could use a maintainer.

</comment></comment><comment><USER4> An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.

<comment><USER5> there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?

<comment><USER6> Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible.

To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip, enumerate, etc are generators, instead of returning lists. This makes it feasible to write things like

        (process(line) for line in map(str.upper, open('giantfile.txt')) if line.lstrip()[0] != '#')

Some of the above can also be done with itertools package in Python 2, but not everything.

Python 3.4 changelog is here, it contains e.g. asynchronous io facilities (asyncio module): [https://www.python.org/downloads/release/python-342/](https://www.python.org/downloads/release/python-342/)

edit: added enumerate() in the example above, for line in open(filename) returns a generator in Python 2.x too.

edit2: enumerate is lazy in python2, I replaced it with map(str.upper)

<comment><USER7> The example you gave works perfectly in Python 2.7 (would also be a generator, and you're not using map filter or else); but I agree: those should've been generators from day 1, especially zip and enumerate since they make more elegant code but often come with a performance overhead in Python 2.7

<comment><USER8> Python 2 enumerate returns an 'enumerate' object that is more or less a light weight wrapper of the sequence that was passed in.

Generators provide a convenient syntax to implement that sort of object.

<comment><USER6> D'oh. I put in a map(), that returns a list.

</comment></comment></comment></comment></comment></comment><comment><USER3> This is a great tutorial about first-generation Numba. The author learned a lot about LLVM and llvmpy while working with several of our devs. If you are interested in the "Further work" in his article, come join the Numba project.

<comment><USER9> What is second generation numba? And any plans to branch numba out of pure numeric application s?

</comment></comment><comment><USER10> I really appreciate the length and detail in this blog post. It's comprehensive, not just showing off.

<comment><USER11> Stephen Diehl continues to blow my mind on a regular basis. His latest work in progress "Wrote You a Haskell"[0] is also worth keeping an eye on. I've worked through the first couple of chapters and it's fantastic.

[0] [http://dev.stephendiehl.com/fun/](http://dev.stephendiehl.com/fun/)

</comment></comment><comment><USER12> Very nice article! :)

Storing types via traces could be another step for gathering types. As well as using the more advanced static type checking code that is around for python.

Now I have something to work through on the weekend. Looking forward to part 2!

<comment><USER3> The numba code-base implements quite a bit of this. We actually moved away from the AST approach and went back to the byte-code approach because the AST approach quickly becomes unwieldy as the number of Visitors that you apply grows. Compile times are also slower.

The author is definitely helping people learn about LLVM and how it can be used with Python --- which is great, because this is exactly what Numba is: [http://numba.pydata.org](http://numba.pydata.org). But, please don't start another "Numba". Just come help us improve the current one.

</comment></comment><comment><USER13> I did something similar in Ruby but using GCC as a "JIT" compiler for image processing (software [1], thesis [2]). I can really recommend JIT compilation for doing array processing.

[1] [http://www.wedesoft.de/hornetseye- api/](http://www.wedesoft.de/hornetseye-api/) [2] [http://www.wedesoft.de/downloads/thesis_wedekind.pdf](http://www.wedesoft.de/downloads/thesis_wedekind.pdf)

EDIT: In my approach I didn't go through the Ruby AST though. Rather I used the approach of injecting "GCCVariables" which emit C code instead of doing the actual computation.

<comment><USER14> You should submit your thesis to the Ruby Bibliography [http://rubybib.org](http://rubybib.org)

<comment><USER13> Ok, will do. Cheers :)

</comment></comment></comment><comment><USER15> I love Python but when I use a statically typed language like C, Rust, Go, etc I really feel that it is missing from Python.

I'd love to see a new language exactly like Python but compiled and statically typed. Something similar to Cython, but rather than generating a bunch of C code it would target LLVM. Additionally it would be able to generate pure Python code simply by removing any typing syntax.

</comment><comment><USER16> Could this be used to ahead-of-time compile Python code ? I'm more interested in getting to a native executable or library.</comment>


Go 1.1 RC1 is out - <AUTHOR> https://groups.google.com/forum/#!msg/golang-nuts/9hEw6max1hU/SZIRA3YPyGsJ <comment><USER2> I'm glad that escape analysis now allows for more natural if/then control flow.

But I'm still unhappy that using named return values _still_ requires you to put a superfluous "return;" at the end of such a function.

The whole reason I use named return values is to cut down on the boilerplate code that carries the return value around -- so why not cut out the final boilerplate 'return'? It doesn't solve any problem or add any information!

Otherwise, there are some nice improvements here. Other than the things mentioned so far, I'm glad to see reflection filling out -- the day a Go REPL will be possible is approaching.

<comment><USER3> > Other than the things mentioned so far, I'm glad to see reflection filling > out -- the day a Go REPL will be possible is approaching.

Very close indeed! Struct, array and function types still can't be constructed at run time, but as of Go 1.1, function _values_ can be as well as slice, map and channel types. I exploit some of this in my `ty` package. [1,2]

[1] - <http://godoc.org/github.com/BurntSushi/ty>

[2] - <http://blog.burntsushi.net/type-parametric-functions-golang>

<comment><USER2> This is pretty cool!

I tried to convince rsc at some point about the enormous value of REPLs for rapid development.. imagine connecting to an embedded REPL on a server to do live debugging. I don't think I quite convinced him to drop everything and do it himself, though.

Do you have plans to experiment with a transpiler to smooth away all the remaining type noise?

Maybe a first step would be to explore how one could add pluggable 'dialect translators' to the go tool so that anyone could write simple extensions for the language while preserving the existing toolchain.

<comment><USER3> > Do you have plans to experiment with a transpiler to smooth away all the > remaining type noise?

I don't have any particular plans; the `ty` package was a night of hacking plus several days of polishing/writing. :-)

One of the major bummers about moving into the reflection world is _performance_. My blog article talks about it a little bit, but it's also worth looking more closely at the things I didn't talk about in the benchmarks. (For instance, it seems that function calls in the reflection world pay a very steep price.)

Re transpiler: do you mean a {Language}-to-Go source translation? If so, it seems like you'd want to avoid `reflect` completely in that case. But maybe I am misunderstanding.

> I tried to convince rsc at some point about the enormous value of REPLs for > rapid development ... I don't think I quite convinced him to drop everything > and do it himself, though.

A REPL would be very nice, but a REPL using `reflect` would definitely be a lot of work. You'd need to make extensive use of the sub-packages in `go` to convert the `Read` portion of the `REPL` into appropriate reflection types. You could do it now, but you wouldn't be able to define new functions, structs or interfaces. And `reflect` cannot spawn goroutines either, which is a bummer.

</comment></comment></comment></comment><comment><USER4> The race detector sounds interesting:

<http://tip.golang.org/doc/go1.1#race>

<comment><USER5> I'll paraphrase something Andrew Gerrand said about this at a golang meetup last night:

Because race conditions are so hard to detect, the race detector is obviously prone to false negatives. Just because the tester doesn't find any race conditions doesn't necessarily mean that there _aren't_ any. But the race detector never finds false positives. If it finds a race condition, that condition is very real.

You could just run your app with the race detector on all the time, but there is a performance cost to using the race detector.

One way to get around this in cloud/clustered environments is to deploy your app on a few machines with the race detector on and the rest with the race detector off. That way you're running your app with a production load and you're more likely to find race conditions, but you'll mitigate the performance costs associated with the race detector.

<comment><USER4> It makes sense to me that it can't possibly detect all race conditions but I had never really thought about the ability to detect _any_ race conditions programmatically.

Running the detector on just a few nodes sounds like a great way to offset the performance penalty a bit. The docs on the race detector say that "memory usage may increase by 5-10x and execution time by 2-20x" which could be quite significant.

I also wonder about the effectiveness of randomly fuzzing your app with the race detector on as a form of testing.

<comment><USER6> I'll take a bet that detecting ALL race conditions is equivalent to the halting problem.

Certainly for an entire program it is... not sure if you limit it to the just the code paths executed.

<comment><USER7> It will always be inexact. All dynamic analyses of this type are, because they only observe what the program does as it executes and do not enforce any restrictions.

If you want a more guaranteed form of race freedom, you need to constrain what programs can do, either with dynamic restrictions on mutable state sharing (like Erlang or the parallel extensions to JavaScript do) or with a type system strong enough to reason about sharing of data (like Haskell or Rust).

</comment></comment></comment></comment></comment><comment><USER8> If we're talking about wishlist items, I'd like a tool, any tool, for detecting memory leaks. I understand they can't use Valgrind itself[1], but as it stands, detecting where leaks exist can be very difficult.

[1] <http://code.google.com/p/go/issues/detail?id=782>

<comment><USER9> Outside of using cgo or working on the Go runtime (written in C), how are you leaking memory in a garbage collected language? Your code either has a reference to something, or it doesn't. If your code has a reference to something, how is a tool going to know you don't mean too have that reference?

Outside of the "dangling reference" issue above "leaking" in a GCd language is non-trivial. Here is a related Java discussion: [http://stackoverflow.com/questions/6470651/creating-a- memory...](http://stackoverflow.com/questions/6470651/creating-a-memory-leak- with-java) . Also note Go doesn't have ClassLoader or class static fields.

<comment><USER10> You can leak memory by leaking goroutines. If a goroutine is waiting on a channel that nobody else has access to, it lives forever, as does the memory it references.

So, you can pretty easily leak memory without messing with unsafe things.

<comment><USER9> That is a pretty serious bug, that is not at all as easy to miss as something like a memory leak is in C/C++.

It is also pretty easy to detect by this (or something better), which might be handy in a big program: <http://play.golang.org/p/XmKfgQ4TmS>

<comment><USER10> I somewhat disagree. Even if you don't use channels as iterators/generators (which many folks do), it's not hard to end up with a goroutine blocked on a channel that'll never be closed/written to, and this situation (like memory leaks) can result from changes elsewhere in the program or branches not normally taken. A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program. The runtime could probably detect if there are goroutines blocked on channels that no other goroutine has access to, and that'd be quite helpful for debugging, but as of now it doesn't. Even if it did, it couldn't catch all goroutine leaks.

<comment><USER9> >>A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program.

Sure it is, if you are leaking goroutines you will see an every increasing count, even when your app is idle if the count doesn't return to the proper baseline then you know you have a problem.

If you start a goroutine should should have a plan for terminating it. If you don't have a natural way like the life cycle of handling a request then you need to use channels (defer/close are your friends), waitgroups, condition vars etc. I work on some fairly large Go applications and this hasn't been a pain point.

</comment></comment></comment></comment></comment></comment><comment><USER11> They finally fix:

      func hello() int {
          if true {
              return 0
          } else {
              return 1
          }
      }

      >go run func.go
      ./func.go:3: function ends without a return statement

<comment><USER12> I've been taught by some pretty experienced engineers that in terms of readability, multiple return statements are a bad idea. Instead, you should conditionally set a return variable, and return it once at the end of the function. But I'm not sold.... what is HN's thought on this matter?

<comment><USER13> > I've been taught by some pretty experienced engineers that in terms of > readability, multiple return statements are a bad idea

They were wrong and probably not as experienced as they/you thought. Guard clauses make code simpler and more understandable.

<comment><USER14> Guard clauses and single return statements are not mutually exclusive.

<comment><USER15> The whole idea of guard clauses in algol-derived languages (not functional ones) is to bail out immediately with an early return...

[http://martinfowler.com/refactoring/catalog/replaceNestedCon...](http://martinfowler.com/refactoring/catalog/replaceNestedConditionalWithGuardClauses.html)

<comment><USER14> I understand that but you can have a macro wrapping a goto statement to a predefined label which will do that for you (and potentially set some errors). It's debatable whether this really gives you anything but I kind of like this style since you can replace the whole if statement with a single line something like check_memory(pointer);. The goto's become particularly useful if you want to have some cleanup done at the end of the function even if something during the function fails.

<comment><USER15> Now your assuming the language has goto. Which definitely is not the case these days.

<comment><USER14> Well the discussion is about go and go does have gotos. <http://golang.org/ref/spec#Goto_statements>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> OT: I had not seen that there was a GCC compiler frontend for Go. Does anyone have any experience with that? Do you lose lots of Go specific tooling?

<comment><USER17> > Do you lose lots of Go specific tooling?

No, gccgo has been developed as a first-class compiler; the intent has always been to separate Go-the-language from Go-the-implementation, to prevent a single implementation from becoming the _de facto_ standard over the language specification - a problem which we've seen happen in many other languages.

You can essentially use gccgo as a drop-in replacement for gc; it's only an extra command-line flag you add to the compilation to specify the compiler.

gccgo is actually likelier to be _faster_ than gc for most computationally bound code, since it piggybacks off of the optimizations that gcc has incorporated over the last couple of decades. However, gc may be preferred if you're relying heavily on goroutines (ie, in the hundreds/thousands), since gc is better optimized for that.

</comment></comment><comment><USER18> Interesting comment in that thread:

"It's worth mentioning the function representation change, since it means closures no longer require runtime code generation (which among other things allows the heap to be marked non-executable on supported systems)."

Anyone know what that means?

<comment><USER19> Marking the heap's region of memory as non-executable improves security. <http://en.wikipedia.org/wiki/Executable_space_protection>

<comment><USER18> Sorry, I wasn't clearer, but I have heard of NX. The part I was wondering about was how the function representation changed.

</comment></comment></comment><comment><USER20> Right now it's hard to do numerical analysis on large problems using Go. To fix that, I'd be really excited to see bindings for MPI or something like it. In particular, go doesn't have a concept of an Allreduce or an AllToAll communication. I know that one can do that by calling the C MPI bindings from go, but it would be cool if there were a natural way to do it using go's parallelism and concurrency patterns.

It would also be nice to have a first-class array object - from what I understand, current support for multidimensional arrays is very C-like in that you're really dealing with pointer arrays.

<comment><USER2> Why not write your own, better, MPI with Go? That's exactly the kind of thing it is designed for.

I agree about the numerics. I'm tempted to write an very bare-bones implementation of Mathematica's kernel in Go, but I'll probably wait until people have done more numerics work in Go.

</comment></comment><comment><USER21> I haven't made the jump to using any of the 1.1 betas or this RC but the reported 30-40% performance bumps look nice. I'm really still waiting for an easy way to get gccgo working on os x though.

And I'm glad that they're bumping up the heap size to system-dependent values on 64bit systems. The fixed heap size of 16 GB was a really unfortunate constraint (even if it could be changed with a little hacking around).

<comment><USER22> Gccgo doesn't work on OS X (or any other non-ELF) platform, and it's useless on anything but Linux anyway as segmented stacks are supported only with the gold linker, which is not ported to non-Linux platforms.

</comment></comment><comment><USER23> __Go noob here __

Can actual products (Web apps in my case) be built with Go?

<comment><USER24> Sure. Go doesn't yet have any mature web frameworks like django for python but quite a bit of what is needed to build web apps is already part of Golang. (Packages net/http, html/template etc.)

If I remember correctly Google switched their download service to using Go and there was a post here not long ago claiming they went from a lot of servers to merely 2 by switching to Golang.

See <http://golang.org/doc/articles/wiki/> for an example.

<comment><USER23> Is Go really that efficient? I heard similar claims from somewhere else, and this has been a motivation for me to learn and then build something in Go.

And what might be the reason for that? Speed? Parallel processing?

<comment><USER24> While I don't have any first hand experience with Go's performance - it is not that hard to believe it will be fast enough - it is a compiled language, so no interpreter / JIT overhead like Ruby / NodeJS. Plus they try to be closer to C where it makes sense (it has pointers but no pointer math for e.g.).

The synthetic language benchmarks also put it very close to gcc -O2 C performance. About the only things that need to be improved further (so I've heard) in Go are the GC, coroutine/thread scheduler and crypto performance. They are already better in 1.1 release but Crypto is still not close to OpenSSL performance.

<comment><USER25> Crypto performance improvements, briefly benched and blogged by jgc: [http://blog.jgc.org/2013/04/update-on-go-11-crypto- performan...](http://blog.jgc.org/2013/04/update-on-go-11-crypto- performance.html)

</comment></comment></comment></comment></comment><comment><USER26> What about the 8 remaining issues <http://swtch.com/~rsc/go11.html> will they be part of the Go 1.1 final?

<comment><USER27> gccgo issues: maybe, since gccgo is not included in the Go package

other issues: probably not, since these are new issues that are being worked on

</comment></comment><comment><USER28> I guess this website is going to have to change soon: <http://isgo1point1outyet.com/>

<comment><USER29> Why is that a website? I just can't believe someone bought that. And why didn't he buy

1outyet.com and make a subdomain, so it could be

isgo1.1outyet.com ?

<comment><USER13> > Why is that a website? I just can't believe someone bought that.

It was a demo in a talk by @enneff at Railsberry 2013: <https://github.com/nf/go11>

The site should update automatically once the repository is tagged.

<comment><USER30> Slides here:

<http://talks.godoc.org/github.com/nf/go11/talk.slide#1>

</comment></comment></comment></comment><comment><USER31> Solaris support would be nice...

<comment><USER32> I believe gccgo already works on Solaris. <http://golang.org/doc/install/gccgo></comment></comment>


Where the hell are great senior developers and hands-on engineering directors? - <AUTHOR> https://medium.com/@obie/where-the-hell-are-all-the-great-senior-software-developers-and-hands-on-engineering-directors-b88b0d15fbdf <comment><USER2> Your problem is:

1\. Great senior devs are actually rare, so yeah, you won't just have them flowing into your applicant queue no matter who you are.

2\. You're not just looking for great senior devs, you're looking for great senior devs who hold certain ideological positions, which is going to narrow your pool much further.

Lots and lots of senior devs have been through the OO design stuff and come out the other side. Like a lot of people, I read and used a ton of design patterns stuff back when I was working in Java around the turn of the century, and nowadays think of OO design as an antipattern to be avoided, with a strong preference toward functionally-oriented code.

Same thing with the XP/agile stuff. Been there, done that, kept what worked and abandoned what didn't. I wouldn't want to apply for a place that had an ideological commitment to strong XP principles and thought of people with other opinions as being in need of "training up."

And maybe you don't want people like me working for you; that's fine, you've got your vision of your OO/XP workplace and you don't want people who don't buy in fully. But don't be surprised when you can't find people who combine strong ability, a lot of experience, and a particular type of tech ideology.

<comment><AUTHOR> This is a great example of the feedback I'm looking for since it gives me clues on how to adjust my messaging for the future...

OO: Totally understand where you're coming from and share your viewpoint. (Former OO Java guy, Rubyist, now primarily dong Node for last 2 years)

XP/Agile: I have 8-9 teams under me and their processes vary and are continually evolving via weekly retrospectives and a commitment to perpetual learning and improvement. My ideological commitment is to ruthlessly, earnestly be excellent in what we do. The vibrant cynicism around Agile has been extremely eye-opening.

</comment></comment><comment><USER3> Looking at the company's careers page, I get the impression of old school enterprise meets academia. Entry level administrative positions [clerks] require a bachelor's degree. Senior administrative positions want a CPA or a JD. An employment office position prefers a Master Degree.

What about software engineers you might ask? Software engineer positions include "Senior", "IV" "III" "II" etc. I'd say this is poor signaling. If Roman numerals ever suggested an engineering culture, it's one that was well over by 476 CE [when Odacer became King of Italy rather than Emperor of Rome and an important milestone for Gibbon].

What does that structure optimize for? The Techonolgist II at some college or government who wants to be a III and the IV who wants to become a Senior. These are people who are fine as part of formalized bureaucracies. Who else? People taking a shot bullshitting through an interview structured around categorizing a software engineer as a II or III or IV or a Senior.

My intuition is that the problem of attracting the right sort of engineering talent is cultural fit. As Salvor Hardin quipped "an atom-blaster is a good weapon, but it can point both ways."

Good luck.

<comment><AUTHOR> Thanks for the critical feedback. We hadn't considered bad signaling with the leveling. It's fairly new and replaces senior designations that had their own problems.

<comment><USER3> Since I am on a roll, toss out "engineer" and go with "developer" or "programmer". In the world of real-honest -to-Uncle-Bob-engineers, a senior engineer has a license and is often legally responsible for the work done under their supervision to the point of direct personal liability. That's why in a Civil Engineering context "I,II,III" make sense, there's a progression of credentials and responsibility.

Choosing "engineer" also says something about culture. Combined with a no formal credential job description, there's a cultural tension.

Incidentally, I gave up on a meaningufl use of "architect" years ago.

</comment></comment></comment><comment><USER4> "Competitive pay" is not a number. Most companies just don't want to pay for the talent they claim to want so bad.

Also, a lot of people are tired of the Agile stuff. Senior people in the range this person is looking for are likely to be among those who saw Agile come around and slowly turn into the weird joke that it is today. Places that are so dogmatic about it that they require TDD and pair programming experience are a red flag imo. Just some thoughts from a dev with 12 years experience.

<comment><AUTHOR> Made some adjustments to the article. Our minimum base pay for senior engineers is $125k, more than that for directors + sizable equity grants in a public company. Result is above market pay (in our opinion) although still less than what Google can pay.

I am realizing that Agile might be much more tainted out there than I originally thought. We do Pivotal Labs/Thoughtbot style Agile, which means very strong emphasis on pair programming, TDD and CI -- but with directors given wide latitude on how to evolve process matters on their team. i've written extensively about it in my modern agile collection on medium

[https://medium.com/modern-agile](https://medium.com/modern-agile)

<comment><USER5> There's your problem. Your minimum base pay for senior engineers is far under market. Add about $40-$50K and you might get some interest.

<comment><USER6> Definitely.

It's hard to imagine a salary of $125k/yr being competitive for senior developers _or_ directors in NYC, whether we're talking about a startup or a billion-dollar company.

Moreover, people capable of working remotely can participate in job markets (and benefit from their corresponding pay rates) not only in NYC but also places like San Francisco and Boston.

From a personal perspective, when job postings mention 'competitive' pay but won't establish a baseline expectation involving concrete numbers, I generally feel safe making the assumption that the salary on offer is on the low end of average; otherwise, mentioning it explicitly would be a great differentiator.

<comment><AUTHOR> I purposely said $125k minimum since that is the lower bound of our Engineer IV salary band. What we pay for director-level is entirely based on experience (e.g. a master craftsman might make more base than I do as an SVP)

That said, it is possible that we still need to pay more.

<comment><USER6> > That said, it is possible that we still need to pay more.

It can't hurt!

One might also consider referencing a concrete salary band in the job posting. IMO, the cons from the hopeful employer's perspective (relinquishing some negotiating power) are far outweighed by the pros (setting correct baseline expectations as to both required skill level and average compensation for same).

</comment></comment></comment></comment></comment></comment><comment><USER7> Read as "where are all the senior developers that think exactly like me. I have some limited exposure doing xyz at my last job and I think it's the only way to do things. Come work for me were you can be my minion and if you exercise an ounce of your own thinking I'll "can" your ass faster than you can say "but your way could work too""

<comment><AUTHOR> Geez, cynical much? I have a small but solid reputation in the field, written multiple successful books, launched/sold Hashrocket, ex-Thoughtworks, and been doing Kent Beck-style XP since 2000

<comment><USER7> I apologize, my comments were a little over the top. They weren't necessarily directed at you. I've just worked too many places where "group think" and arrogant senior devs/architects pass judgement on the masses.

</comment></comment></comment><comment> manuel-vidaurre Obie. Great to read you. As you know we have a nearshore company specialized in ecommerce and fintech. We have found the importance of intrinsic motivation with balance of extrinsic motivation. What you have setup, if I reading right, it's more appealing for extrinsic motivation, the only point that you cover for intrinsic motivation is the need for growing our mastery. Your extrinsic motivation drivers are very conventional and no very good for attract good talent, as a good friend once told, joking about why she still single: "husbands are like parking spaces, the good ones are already in use". Usually talent developers have a lot of working options, usually the work that is more aligned with your view and believes is more likely and option. My recommendation work more in intrinsic motivation factors: autonomy, propose, meaning, mastery, etc. Maybe you should also see the international talent, here in Mexico there are lot of talent, there the challenge is cultural fit and remote working. I wish the best for you, if I can help you in any way please let me know. All the best --- Manuel

</comment><comment><USER8> Maybe because Agile is not what it should be. Managers love it Devs hate it. And every place I worked in, no one could do it right. It's not helping at all. It helps the manager to have more tools at his disposal to annoy the team, but it doesn't help the common folk. Also I'm tired to see people referring to seniors as old guys who worked as Devs for XX amount of years. Most of these people are stuck in a loop and know nothing about the new technologies and the younger generation has to teach them in the end. Also most of the senior Devs will move up in to manager positions and won't look back. None of my workplaces knew anything about SOLID principles, Design Patterns and all that fancy unicorn stuff because it looks lovely on paper but in the end it slows development down, so people avoid it. Most of the development work is done like we were monkeys with typewriters. But this is only my opinion. Take it with a pinch of salt.

<comment><USER9> Avoiding all that "fancy unicorn stuff" might not slow you down but it will slow down the next person who picks up your code but who cares that's their problem.

You must come from the same school as "who needs tests they're a waste of time".

<comment><USER8> By calling it "fancy unicorn stuff" I mean, it is really hard to come by in real life. Because generally people avoid it and when they don't, they usually use it in a completely wrong way. I saw a Singleton pattern which made me carve my eyes out. And that came from a guy, who was a Senior Developer. And most of the times being a developer is about working with legacy code and trying to fix loads of problems, which wont be fixed in the end because there is not enough time, money and energy and so on and so on and... This makes loads of experienced people move in to management, or creating their own business, because they had enough of the trench work. That's why you won't see talented people on the market. Because they know...

Oh and no, I'm not from that school. But having tests doesn't mean the tests are any good. You can have loads of methodologies, patterns, principles. If you can't tell when to use a Factory Pattern, or how to implement SOLID, then it doesn't matter how much you like, or want them.

<comment><USER9> Ok I retract my tests comment!

Design patterns can definitely be abused and pragmatism is important when deciding whether or not to use them. I would say though that implementing SOLID is certainly achievable if writing from scratch but harder when refactoring code that breaks those principles (usually badly with no tests or poor tests).

</comment></comment></comment></comment><comment><USER10> As silly as it sounds, if you are a senior developer/eng director that is in high demand these days, the product that you'd be working on matters tremendously. Having people motivated by the whole of the product they are working on is huge, while individual complex problems are also fun, staying power lasts in people who want to use what they are building every day.

I think the sentiment of this article is more around finding senior developers who are also interested in the product you are building. Which is a huge problem because the intersection there is even more sparse than finding a senior developer that just wants to solve generic, complex problems.

</comment><comment><USER11> Obie! I'm dealing with it too. I think many of us who are hiring are. I've got a good team, but besides myself and one other, none are senior. Despite having open positions at a thriving company with great pay and benefits, I have zero senior folks in my pipeline of candidates. We've attracted great talent in every other area of the business from marketing to finance, but development is left with a pool of junior applicants. I know for myself, I don't look for a new opportunity outside of my existing network of friends and colleagues. I am where I am now because I have history with two other people at the company and I want to work with them. Pay and benefits at a cool startup aren't enough because there are lots of those opportunities. As much as I like mentoring, I want to work with other talented developers. There is the catch I suppose. Senior developers want to work with other senior developers so that they can keep upping their own game, and if you don't have any, it's hard to attract others.

<comment><USER9> So is your problem that senior developers just do not apply or that the ones that do apply (from a smaller pool of applicants) get screened out at some point in the process?

<comment><AUTHOR> They don't apply and my recruiters are not finding them.

</comment></comment></comment><comment><USER12> I've written a response to this article. It echoes much of what's been said, but also adds some new things. Enjoy!

In response to Obie's where the hell are all the good senior software engineers and hands-on engineering directors

[https://medium.com/@bradurani/in-response-to-obie-s-where- th...](https://medium.com/@bradurani/in-response-to-obie-s-where-the-hell-are- the-great-senior-software-developers-21632f3182b6#.v3w4goxlm)

</comment><comment><USER13> There are very few companies that do pair programming. It will really close down your funnel if you make pair programming experience a requirement. I would wager less than 1% of programming jobs do any significant amount of pairing

</comment><comment><USER14> Without your medium post I would have dismissed your job adverts completely. They're awfully 'grey' and samey.

On one hand medium uses the positive accomplishments eg "...Empowered cross- functional teams doing disciplined TDD ... pair programming, and continuous integration/deployment ..."

On the job advert reads like you want someone to come and get the team to do those things.

If anything I'd sum up the medium post as "We do good things, come join us" and your jobs adverts "We're slightly above average, can someone please make us better"

</comment><comment><USER15> Good article. I think there's a shortage, and I also think technology overload and the ever-increasing rate of innovation and change prevents many junior programmers from really learning agile fundamentals well. There's just too much other stuff to learn that changes too fast, as well as general societal information overload, to get into the deep philosophical fundamentals of agile and OO. I spent hours reading the TDD Usenet list when I started. Who has time to do that now?

</comment><comment><USER16> I had not previously heard of "2U", and I may be atypical in this, but working for a for-profit education outfit is not in line with my personal ethics.

<comment><AUTHOR> We are white-label service provider for two dozen of the most prestigious universities in the world. maybe check your assumptions -- we are in no way U. of Phoenix

<comment><USER16> I realized that, and my point stands. There's too much money flowing out of universities and into private hands for my comfort, and I won't be part of it. (I make an exception here for things like "hardware and equipment" and "research software").

<comment><AUTHOR> Most (if not all) of our partners are private universities. Also, we generate more revenue for them, not less. So I don't get your point.

</comment></comment></comment></comment><comment><USER9> "Tons of interesting and potentially great people that have never paired or don't know really know how to TDD".

I am slightly surprised at this because these are not new things.

</comment><comment><USER17> Great read! Thank you!</comment>


Compact TLS 1.3 - <AUTHOR> https://tools.ietf.org/html/draft-rescorla-tls-ctls-02 <comment><USER3> This is unlikely to get adopted as a standard, because it only exists in response to OSCORE[1] and EDHOC[2]. The draft is an effort to prove that the TLS working group, which almost exclusively deals with large-scale devices such as laptops, phones, and servers, will listen to and address the needs of the embedded devices (IoT) community. The challenge is that the draft didn't exist until a working group formed to create a light-weight protocol, thereby proving that the TLS working group actually won't address embedded. Whether cTLS or EDHOC become RFCs remains to be seen, but my money is on EDHOC.

[1] [https://datatracker.ietf.org/doc/rfc8613/](https://datatracker.ietf.org/doc/rfc8613/)

[2] [https://datatracker.ietf.org/doc/draft-selander-ace-cose- ecd...](https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/)

<comment><USER4> It's slated as Informational not Standards Track.

You say that "The draft is an effort to prove that the TLS working group, which almost exclusively deals with large-scale devices such as laptops, phones, and servers, will listen to and address the needs of the embedded devices (IoT) community" but you don't present any evidence for that whatsoever. Rescorla's presentation of this at the IETF just gone didn't sound to me like he was trying to "prove" anything to the IoT community, whether to the extent that's represented by core (the working group that produced RFC 8613) or in a broader sense, it would surely make sense for anyone trying to do that to present _to_ that community and not to the TLS Working Group.

cTLS is just smaller TLS, it doesn't even say "This is for embedded" anywhere. The reason TLS itself isn't smaller is purely for interop reasons, if you don't have interop concerns (e.g. there aren't middleboxes in your network) then cTLS in principle gives you all the same benefits for less bits on the wire.

<comment><USER3> Middleboxes are a great example of why cTLS isn't the right direction. cTLS is a smaller TLS, but like TLS, doesn't deal with being proxied. This is by design, of course, because MITM is bad and proxies are MITM. However, there are no deployed wide-area low-power IoT networks I know of that do not use application-layer proxies. Even the cellular offerings I've seen are depending on data collection services as a middle man. OSCORE/EDHOC has been designed to accommodate proxies and provide a secure transport through the proxy, while still allowing the proxy to do its part. Even HTTPS CONNECT doesn't do this. And EDHOC by itself can be used in more exotic key exchange schemes, which it turns out does pop up all the time in IoT design.

So yeah, cTLS is a smaller TLS. Which like TLS doesn't meet the needs of today's IoT designers.

<comment><USER5> If an app isn't _aware_ it's being proxied, how do you keep TLS secure but allow proxying anyway? There are already solutions for proxying apps/clients _when they can be made proxy-aware_. One option is to add your corporate CA to the trusted roots list (and transparently proxy through something that auto- generates certs). Another is to have the app explicitly connect to a corporate proxy.company.com site running a forward proxy (non-transparent proxying). What other solutions are necessary?

It seems like cTLS is not addressing proxy ability because there's no need to address it. cTLS is addressing power/complexity requirements _only_ , right?

For consumer IoT devices, this is all begging the question of whether IoT devices should be directly connecting to _anything_ external. Something like Mozilla's WebThings gateway[1] needs to catch on and become standardized. Even for IoT devices that are capable of supporting TLS to arbitrary internet endpoints, having such devices all talking to arbitrary external sites is a _disaster_.

[1] [https://www.google.com/search?q=ycombinator+mozilla+webthing...](https://www.google.com/search?q=ycombinator+mozilla+webthings)

<comment><USER6> I agree. I'm interested in hearing more about why proxies/MITMs need to be supported as first-class actors.

<comment><USER3> Sure. The kinds of IoT devices I work with aren't consumer IoT. We operate networks of devices where a sensor may be attached to a network interface and the application driving that sensor is somewhere out on the Internet (perhaps on a VPN).

The application wants to connect to the sensor (perhaps for configuration) and to do that needs access to the network on which that device is operating. The network won't be exposed to the public Internet, and is protected via access rules enforced at a proxy, and traffic management may be done at a proxy as well. The application vendor may not trust the network operator with payloads, so wants to keep their payloads secret. So the result is a need for proxies where the payload is secret, but the destination is not, and a secure end-to- end envelope (from the application to the sensor) can be formed. TLS can't address this. Nor can VPNs.

<comment><USER6> The way I'd build this, if I had to, is to a) terminate TLS at the proxy, b) use some an interior protocol (possibly TLS) between the client and the sensor, with the client telling the sensor a digest of (or perhaps the whole) EE certificate presented by the proxy.

This might look like a CONNECT if the proxy will permit it, though using HTTPS to talk to the proxy, not HTTP, naturally. Or it might look like a full-duplex POST to the sensor through the proxy, with TLS being spoken over that POST. If neither CONNECT nor full-duplex POST are options, I might try Websockets, and as a last resort, I'd split up the protocol into multiple POSTs, one for each round trip.

EDIT: At any rate, this sounds exactly like what CONNECT is for, and this covers your needs:

      - The client trusts the proxy if it can authenticate it.

        The proxy is an explicit client-side proxy, though
        it's actually on the server-side, which might seem strange.

      - The client trusts the device if it can authenticate it.

        The proxy cares only to decide whether to route the
        request.

      - The proxy may need the client to authenticate to the
        proxy -- there exist headers for this, and the client
        could also use a user certificate in the TLS
        connection to the proxy.

      - The client may need to authenticate to the device,
        which it can do in the TLS connection to the device
        that runs over the outer CONNECT, with all existing
        choices for authentication available.

The only strange thing is that historically client-side proxies are accessed w/o TLS, but you really need to use TLS here because the "client-side proxy" is actually far away, across the big bad Internet. That client-side proxies are usually talked to w/o TLS is really a bug.

EDIT: If you find that getting your client to use TLS to talk to the proxy is difficult, just think how much more difficult it is to implement a new protocol from scratch.

<comment><USER3> You missed the requirement for the payloads to be secret from the proxy. If the proxy is terminating TLS, then the payload isn't secret from the proxy (and the sensor can't authenticate the source except as from the proxy, either.)

It's worth adding that in my case there is no TCP or HTTP, so the home stretch over the LPWAN is UDP and CoAP.

<comment><USER6> I did not miss that. The client runs the TLS connection end-to-end (to the device) over the CONNECT. _That_ connection will be secure relative to the proxy.

That there's no TCP/HTTP doesn't alter any of this. You can use UDP and DTLS this way, except you'll have to create the proxy protocol, and you'll need the proxy to maintain some "connection" state, and you'll need to expose inner connection close to the proxy so it can cleanup that "connection state".

<comment><USER3> This is kind of a lot of work when there could be a protocol that I can use instead. Like OSCORE with EDHOC. Sure I can go gluing things together but that's more work for me and my people. We have other things to do like build kick ass network management tools etc.

<comment><USER6> Having had to maintain proxies, yes, it's a lot of work. But!

Building a _new_ protocol, and implementations for it, and applications for it, has got to be strictly _more_ work than building a nested TLS protocol and implementation. More work for you, and for the rest of us who would have been happy not to have to deal with it but are forced to by new realities on the ground created by people who thought a new protocol would be less work. More chances to get the crypto wrong. I'm not keen on this. I'm all-in on TLS 1.3, not because it's great but because it's the only way to reduce the pressure to create new legacy. Legacy is fantastically expensive, so I'd rather not create more of it if we don't have to.

To be fair, I'm told that even TLS 1.3 might not fit the power profile of IoTs, however, that's ameliorated by time, and it would also be ameliorated by cTLS, so I'm not sure that's enough to justify a new protocol.

<comment><USER3> Well, we have legacy anyway, because I can't economically use TLS or DTLS this way, so I already have a proprietary protocol. Presumably other designers are in the same position I am. And I'm not the only one looking hard at EDHOC and OSCORE, there are some pretty significant hitters in the IoT scene right now that are also looking at this and for the same reasons we are - <USER2> approaches in an industry sorely needing both standards and functional solutions that work on real networks.

But yeah, building protocols is hard. I should know, since I've been building a dead-end protocol for over 10 years, including HSM support, massive scale, proxy scenarios, HA support, and blistering pen tests, that I am very ready to give up for OSCORE/EDHOC.

TLS is not going to be "ameliorated by time"; RF isn't getting cleaner, radios are already very efficient, power management has gotten decent and there's not a lot left to squeeze. Putting bits in the air will continue to cost money. Embedded IoT will continue to chase the tiniest scrappiest cheapest hardware. Where do you think this "amelioration" is going to come from? TLS is going to get worse for IoT over time, not better. There will be ever more code points in TLS. The WG is going to continue to focus on big-box issues, privacy issues, server deployment issues, ever finer controls on timing attacks, extensions for SNI and other CDN issues. IoT problems will be solved elsewhere, with a different protocol, and that's fine.

<comment><USER6> I'm curious what all we could throw out in a cTLS or uTLS to serve the power/RF constrained environments of IoTs.

If we must have a new protocol, I'm keen on making it as similar as possible to TLS 1.3 that the costs of designing, reviewing, implementing, and maintaining it, are much lower than that of a brand new protocol.

<comment><USER3> There are SO MANY changes to be made for constrained devices. Just a couple quickies, certificate order is all backwards. Eliminate basically all use of DER, preferring CBOR instead. Define larger coarse protocol presets instead of dozens of optional extension points. Also TLS has no certificate caching, which for some radios is nearly fatal and will be a major issue with embedded and PQC. Etc..

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Without commenting on the merits of this RFC, I saw

"[[OPEN ISSUE: Should we just re-encode this directly in CBOR?. That might be easier for people, but I ran out of time.]]"

IMO, yes, please. The last thing the world needs is Yet Another Custom Binary format and CBOR is a very good choice (happens to be one of my favorite encodings).

<comment><USER8> My life would be so much more pleasant if the asn1 stuff in x509 et al was in cbor.

<comment><USER4> Mmm. You obviously wouldn't build anything like X.509 today (not least because the X.500 directory system never ended up building that global directory) but over time I appreciate more and more things that I once thought were mistakes in X.509 and ASN.1.

The Distinguished Encoding for example. So easy to build a format that says well you can do X or Y and then you get nasty surprises because which is it?

Or OIDs. Sure today you figure we'll let IANA track things in a registry, or we'll do everything with URLs which are inherently namespaced, but OIDs are in many ways a nicer option than either.

<comment><USER6> I would replace OIDs with URNs. Textual identifiers are much nicer than OIDs in any APIs and in any UIs (if they must leak there, which often happens). This goes for things like GSS-API as well.

I do NOT like definite-length encoding. It's nice to have the full length of a PDU up front, but inside the PDU you want to use indefinite length encoding for everything as this greatly simplifies encoding.

Tag-length-value (TLV) is an anti-optimization that was only ever a crutch. By the time the ITU-T worked on PER this was well understood. I feel that the use of TLV encoding rules held back [open source] compiler creation for ASN.1.

Compare to XDR and rpcgen. XDR is a lot like a subset of ASN.1 with PER-/OER- like encoding that uses 4-octet alignment. XDR was long easier to use than ASN.1, but why? Mostly because a) it has C-like syntax and is fairly easy to build parsers for, and b) the encoding rules are very straightforward.

Protocol buffers makes some of the same mistakes as DER...

It's really difficult to reinvent wheels well. It really helps to not throw the baby out with the bathwater. Specifically, here, there's a lot functionality in ASN.1 the _syntax_ that would be very good to keep. As for encoding rules, XDR is dead simple, so I'd use that for almost anything.

It's also good to know what's really missing. For my money, the most commonly missing feature is control over emitted types for the host language, and, specifically, lack of a way to emit private fields that are not to be encoded or decoded but which make it easy to keep state near relevant data.

XDR is so simple that as long as you have a decent buffer abstraction and support routines for encoding/decoding scalar types, it's easy enough to do without a compiler.

The most promising newish thing here is flatbuffers.

<comment><USER9> What's wrong with TLV? It helps getting rid of end-of terminators, no?

<comment><USER6> For one, the tags aren't necessary -- you know what belongs at any point, and for OPTIONAL/DEFAULT elements all you need to know is whether they are present or absent (that's one bit, or a byte if you're not aiming to be more space efficient).

Definite-lengths greatly complicate encoding. The easiest way to encode DER is "backwards", starting the end of a SEQUENCE and working your way backwards. That's a bit of a pain.

Definite-lengths add lots of mostly-unnecessary redundancy.

For constrained-range integers, the best thing to do is to encode them as whatever number of octets are needed to encode the constrained range. For structures (SEQUENCE) and arrays (SEQUENCE/SET OF) indefinite length encoding is much easier to encode. Decoding is easy because you just decode the fields -- a terminator shouldn't be needed (though I know BER uses terminators, but that's a design flaw in the BER family of encoding rules, not a complete necessity.

Definite-length encodings or terminator encodings are mostly only needed for strings and extensibility holes (OCTET STRINGs, extensibility markers), but they can be the exception rather than the rule, and thus simplify things.</comment></comment></comment></comment></comment></comment>


Ask HN: Collaborative Tools for Building an Island Community? - <AUTHOR> I'm working on developing an eco-village / hackerspace / visionary art museum / retreat center on an Island in Panama.
I'd like to have an open design process where people can submit ideas for design, materials, governance, events, etc.
I was considering putting something on GitHub.
What tool stack should I consider using?
How would you approach it?
The island is Majagual.org and we have the entire space to create. <comment><USER2> Based on the images on the web site, that seems like a lot of development for such as small site. I would suggest starting with a cap on occupant capacity and working forward from there. A small site can't be all things to all people. But it can do one thing really well. Taco truck not power center. Good luck.

<comment><AUTHOR> It's about 100 acres.

I'd like to cap around 150 people.

Thanks for the insight!

<comment><USER2> @3000sf of development per occupant (direct usable area, services, walkways, docks, gardens, etc) that's about 10 acres. That would be a substantial fraction of the high ground on the main island.

<comment><AUTHOR> I'll clarify. I'd like to only have a max of 150 people there a few weeks a year - mostly beach glamping for a festival.

Otherwise, I imagine perhaps smaller events for 20-30 people.

<comment><USER2> Maximum occupancy will determine the extent of development. Events also dictate capacity must handle a surge. While a stable occupancy might be served by "two boats per day", an event might require handling "two boats per hour."</comment></comment></comment></comment></comment>


Work remotely, building a CoffeeScript/Backbone mobile application - <AUTHOR> http://pathable.com/hiring-javascript-coffeescript-developer/

<comment><AUTHOR> This is shameless self promotion (at least of an open position) but we really are doing great and fun stuff with Backbone, CoffeeScript and for mobile. Plus we support remote working.</comment>