Ask HN: How do I convince my coworkers to use HTTP well? Or am I being a pedant? - <AUTHOR>

Throwaway account here.
I work on a team that is developing a mobile app with an HTTP-based backend. Except for me, everyone is attempting to reinvent the wheel. They are:
1. HTTP 200 everything, unless it's a 500 internal error, or the route requested doesn't have a handler (404).
2. POSTing everything.
In cases where, say, a route exists but the resource requested does not, they return a 200 with a JSON payload that identifies some internal error code (the list of which is not currently well documented).
In cases where a client requests a resource, the request is sent as a POST with either a querystring or JSON body. Same for updating, same for deleting.
My question:
How would you convince them to use HTTP as God (Mr. Fielding) intended? Things to note:
1. It's a small, new team. I believe they can be swayed, but I want to make it an easy argument.
2. The API is (currently) completely private. Only internal developers use it, so until we have external folks accessing it, it's kind of a matter of taste. I reason that we shouldn't assume it will never have external consumers. Still, I'm not sure: am I being too pedantic?
If my argument is worth pursuing, can you help me build it to be short and strong? Anything other than the whole W3C spec and a dissertation that might sound convincing to them? Or should I just keep quiet and work on? <comment><USER2> If your app does become super popular, it would be very hard to implement http-level caching when using only POST. By using GET you can do caching at client (or CDN/reverse proxy) layer.

<comment><AUTHOR> Thank you, yes. This is exactly the sort of short and sweet bullet points that I'm building up.

</comment></comment><comment><USER3> Either they don't know how HTTP can be utilized more effectively or they don't care.

The former is relatively easy to fix. Still searching for the answer for the second one...

<comment><USER4> Same here for #2

</comment></comment><comment><USER5> You're going to have a harder time making this argument if the API is really completely internal. You could point out that it will be difficult to inter- operate with other programs or libraries though. I think your best bet is to show them that the spec already exists, there is already code that implements those specs, and they will have a lot less work to do (now and in the future) if they stick to the standard.

</comment><comment><USER6> > Only internal developers use it, so until we have external folks accessing > it, it's kind of a matter of taste.

No, it's not a matter of taste. What will you do when there are external users? Rewrite your whole internal ecosystem to use the external one? Maintain two APIs? Throw a complicated, not semantic API out there and sacrifice goats hoping that someone will use it?

</comment><comment><USER7> Programming is API's all the way down. Point to an API in the programming language in your shop, and be like, "how productive is it really to start overloading methods in this API to have effects other than they intended?" Because what they're doing is effectively the same.

The verb is the method, the post content and query string are the arguments.

Not only would it be incredibly confusing for newcomers to the system (and there invariably will be), why add to the cognitive load when you can simplify things instead?

</comment><comment><USER8> Even if it is internal, you're just making things harder on yourself if you go against convention for no reason.

Most client networking libraries have abstractions built upon those conventions. Like jquerys $.ajax: it returns a promise that will invoke the failure callback for a response other than a 200 level code.

</comment><comment> T-R Talk about the practical benefits you can get, and decide based off of those:

\- GET requests are supposed to be idempotent so they can be transparently cached by caching proxies. Even if you won't be taking advantage of caching proxies, it makes it easier if you can use the same data and mechanisms (i.e., HTTP headers) for server-side caching (and makes it easier to pull it out onto a separate server later). This is important if it gets a bunch of traffic or requests are resource intensive.

\- Thinking about endpoints as "resources" instead of as function calls discourages you having parameters with a large or infinite set of possible inhabitants, which would dilute your cache utilization. "mysite.com/multiplicationTable.html" is nicely cacheable; You can cache "mysite.com/mult?a=5&b=10" if you want to, but how likely is someone to request that same URL again before it falls out of cache? Any information that changes the response is technically a parameter, too (since it invalidates your cache) - that especially means things like session state and side effects. That doesn't necessarily mean "never have side-effecty/RPC endpoints", but you should minimize them if you want to be scalable, since every request to one pretty much _has_ to put load on your server.

\- PUT/DELETE requests are supposed to be idempotent so they can be re-issued in case of failure. I also find it encourages design with immutable/replace semantics, rather than partial update semantics, which puts you in a better position when you want to move toward distributed/eventual consistency systems (or even just for debugging), since the data's all there in the request, and likely easier to make it commutative with other requests. Some of these things might matter to you more than others, depending on what you're building.

\- Using headers properly gets you nice features like content negotiation, and provides what's needed for caching to work (e.g., 'vary' header). Using the built-in stuff means you can probably use someone else's library instead of hacking out something buggy yourself.

\- HATEOAS gets you fully dynamic API discoverability. Describing your links well enough to accomplish this is pretty involved, and I'm personally not really sure it's worth the benefits, at least for anything that isn't an API having arbitrary clients built for it, or otherwise being directly navigated by some unknown end user. Maybe if there were more standardization around hypertext formats.

\- Proper error codes can be nice for debugging, and theoretically can let certain situations be handled automatically (e.g., 401s could direct a user to authenticate, 302s generally redirect transparently) They also communicate some intent to e.g., search engines ("pass on my SEO link juice to this new URL"). They're a bit of a harder sell for internal APIs, since they're not really as descriptive as they should be. Probably the best practical benefit would be the ability to use client- and server-side libraries with them, or to be able to categorize your errors easily to simplify your handling, without having to dig into the response body. Also nice that you can look them up on Wikipedia - you don't have to maintain documentation for your own error format.

TL;DR: sticking to HTTP as intended helps to save you from rolling your own cache invalidation and coming up with your own new names for things, which are well known to be the two hard things in Computer Science.</comment>


RFC 7049 - Concise Binary Object Representation (CBOR) - <AUTHOR> http://tools.ietf.org/html/rfc7049 <comment><USER2> RFCs don't amount to much without adoption. The RFC database is full of protocols with grand designs and seemingly broad applicability. Look at the "Extensible Provisioning Protocol", EPP - [http://tools.ietf.org/html/rfc5730](http://tools.ietf.org/html/rfc5730) \- a protocol "for the provisioning and management of objects stored in a shared central repository." \- it reads as a marvelously generic protocol for client- managed key-value data storage - maybe it's suited for caching systems, or cloud BLOB storage, or as an abstraction of dropbox... but in reality it's just the protocol used by internet domain registrars to manage domain name registrations on a registry server - the nichiest of niche applications, yet the subject of a dozen RFCs. It's not going to be picked up and supported by Hadoop or Dropbox or anybody else who needs client managed obect storage, they're going to stick to HTTP REST.

This CBOR format is being proposed by the VPN Consortium - presumably there's some specific VPN interoperability application they have in mind for this. In the meantime, everybody else will continue to use compressed JSON, or protocol buffers, or whatever other standards have good library support and interoperability and - crucially - _adoption_ in their domain.

<comment><USER3> I agree with all the points you've made, and I haven't read this RFC beyond a quick skim, but consider:

-a lot of the time, a dearth of implementations of a new Thing is not because the new Thing is bad, but simply because people are change-averse and lazy, even in the face of an objectively better Thing, and

-I still consider this a quality submission; even if CBOR doesn't get adopted it's still neat to read. It's like watching one's government draft new legislation, except more relevant.

</comment></comment><comment><USER4> There is one significant problem I see:

the length field for compound types (arrays and maps) specify the length in "the number of items", not in bytes. This means while processing, If I need to skip a compound type, I actually need to process it in its entirety. Not very "small device" friendly.

In practice, I have found far more utility in knowing the byte-length of a compound field in advance than the number of items it contains. If I am interested in the field, I am anyway going to find out the number of items cause I am going to process it. If I am not interested in the field, the number of items are useless to me, but the byte-length would have come in handy.

<comment><USER5> I think the thinking here is that the sender may not be able to compute the byte size of the object a priori. Think HTTP chunked encoding.

<comment><USER4> I understand that is a concern in many situations. The problem here though is that you don't get the "streaming" benefits in any case: you still have to include the length-in-number-of-items of the compound type and the lengths of each individual member item in any case.

</comment></comment></comment><comment><USER6> Avoiding the need for protocol version negotiation might be a useful feature in some systems, but it seems to me that the things you lose makes it really not worth it. Particularly, a protocol without atoms invariably ends up like most JSON APIs -- very 'stringly typed', somewhat poorly defined, and verbose on the wire.

Which is strange for a thing calling itself 'concise'.

<comment><USER7> It does seem an odd trade off. Having key value pairs is great for prototyping and the keys make it easier for people to interpret the messages and to write code to use them. On the other hand repeatedly sending readable key values seems a huge waste. I guess when streaming you could send a header with a map in it, but it then makes things complicated....

<comment><USER8> Could something like GZIP mask a lot of that repetition?

<comment><USER7> Definitely, but at the cost of requiring more memory and processing power. If its goal is to be compact and lightweight I think it would be helpful to have something in protocol itself.

Looking at the spec though, it does allow numeric keys in maps so you could use id's and provide the definitions elsewhere.

</comment></comment></comment></comment><comment><USER9> Serialization formats are like indentation styles. Dead easy to pick or invent one, nearly impossible to convince others to switch to it.

<comment><USER10> Yes! For that reason, I also have my own: [https://github.com/albertz/binstruct](https://github.com/albertz/binstruct)

</comment></comment><comment><USER11> Anyone care to comment on where we might use such a thing? Is it already in use? And does it compare favourably with BSON?

<comment><USER12> It looks closer to msgpack if anything, but with actual strings and bytes.

<comment><USER13> It is inspired by msgpack. If you read the RFC then you will see that the authors like msgpack but have some different requirements.

</comment></comment></comment><comment><USER14> This gets a surprising number of things right. I've worked on a couple of these. In particular I'm delighted to see both the definite and indefinite streams of things.

I'm a little bit tired (well, more than a little tired) of standards that aren't couched in terms that are directly executable. English descriptions and psuedo-code are fine, but in the end I want to have some working code that implements an API for the stuff. Doesn't have to be an official API, but something usable shows me that (a) it is indeed usable, and (b) will go a long way towards heading off other people's mistakes.

We don't do crypto without test vectors. I don't know why we think we can do other complex standards without test vectors, either. (I worked on NBS / NIST in the 70s on some verification suites. Have we lost that practice?)

I think that much of what is busted on the modern web can be traced back to loose english and lack of reference code (even stuff with placeholders). CSS, HTML, etc., I'm looking at you... :-/

<comment><USER15> > In particular I'm delighted to see both the definite and indefinite streams > of things.

Why? I can see the advantages of either one, but I don't see what having both gets you.

In my experience the implementation advantages of having length-prefixed lists disappear if you have to support indefinite lengths anyway.

<comment><USER14> I want to use the same data structures for

\- Passing small messages around

\- Doing streaming of large content (occasionally)

I'm probably doing these over different pipes, but the data shares a lot of the same characteristics and I don't want to use two totally different APIs to get the job done.

"Large" can be "I need to transfer something on the order of megabytes using a 4K intermediate buffer."

</comment></comment></comment><comment><USER16> They should do the world a favor and include a datetime type.

<comment><USER17> Whats terribly wrong with [http://tools.ietf.org/html/rfc7049#section-2.4.1](http://tools.ietf.org/html/rfc7049#section-2.4.1)?

<comment><USER18> The minor issues are missing timezone and precision information.

But, most importantly, use of integers for datetime values hides type-level semantics. It's just integers and you, the end user, and not the deserializer, is responsible for handling the types.

I think it's quite inconvenient to do tons of `data["since"] = parse_datetime(data["since"])` all the time, for every model out there.

<comment><USER17> But they also allow strings with time zone information:

 _" Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287]."_

RFC4287: _" A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset."_

</comment></comment></comment></comment><comment><USER7> Looks a good spec, great as a way of sending data to 'Internet Of Things' style devices where processing power and possibly bandwidth are issues.

</comment><comment><USER19> Can anyone enlighten me on why number equivalency is a good idea? The spec says that even if you're expecting an integer like 0, encoders can decide to use floating point, and things should just work. One of the first statements is that "7" should be able to be represented in multiple ways. That doesn't seem concise.

<comment><USER20> Hmm, that's not the impression I got. I don't think they're arguing you _should_ use multiple encodings willy nilly. Rather, they're avoiding the limit of exactly 1 encoding for every input (maximum flexibility in the spec).

 _Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains at least one pair whose key is 0xab01"._

7 is 7 whether it's uint_8 or uint_32, right?

<comment><USER20> Also, there's actually a much more relevant section later on in the spec (just got to p18):

       For constrained
       applications, where there is a choice between representing a specific
       number as an integer and as a decimal fraction or bigfloat (such as
       when the exponent is small and non-negative), there is a quality-of-
       implementation expectation that the integer representation is used
       directly.

</comment></comment></comment><comment><USER21> I would really love to see a convergence of such binary formats, I hate that choosing between Google's Protocol Buffers, Apache (Facebook) Thrift etc. forces you down a very specific path of non-interoperable libraries.

I would like to see how this compares to other formats with respect to serialised size...

</comment><comment><USER22> Any JSON object encoding format would greatly benefit from compression. It does not have to be complicated: even something as simple as using a dictionary array of "symbols" whose indices can be used instead of repeating string values.

</comment><comment><USER23> This looks like a fairly well-designed format. My main concern is that this seems to have suddenly appeared out of nowhere and gone directly to RFC. (Presumably there was an Internet-Draft, but I have never seen anything about this before.)

<comment><USER24> These kind of binary formats always have vulnerabilities. eg [http://technet.microsoft.com/en- us/security/bulletin/ms04-00...](http://technet.microsoft.com/en- us/security/bulletin/ms04-007)

<comment><USER25> It would be up to the parser to implement the standard without a vulnerability, but a protocol is a language and a language can be designed to be self-referential, hypocritical, inconstant etc, making a conforming parser impossible. A lot of these so called "living standards" are probably not "evolving" so much as partially classified.

</comment></comment></comment><comment><USER26> In the examples, 0x3bffffffffffffffff decodes to -18446744073709551616, which doesn't fit into int64_t. Why didn't they switch to bignums after INT64_MIN (-9223372036854775808) instead? Seems a bit asymmetric.

</comment><comment><USER27> I was really starting to like capnproto.com

</comment><comment><USER28> At least it doesn't copy the JSON's braindead idea to rule out NaNs and Infs...

<comment><USER29> Wait, what? I hadn't heard about that. Whatfuck?

<comment><USER28> See: [http://stackoverflow.com/questions/1423081/json-left-out- inf...](http://stackoverflow.com/questions/1423081/json-left-out-infinity-and- nan-json-status-in-ecmascript)

In short, this is because JS does not treat NaN and Infinity as numerical constants but as pre-defined, mutable variables; this way backward-compatible parsing of hypothetical sane JSON with eval would be vulnerable to injection. Nevertheless, many JSON codecs have their own idea what to do with it, so this stuff can get really nasty.

</comment></comment></comment><comment><USER30> I like it. Fighting the urge to write a parser for it in my language of choice.

<comment><USER31> I couldn't fight it off [https://github.com/michaelmior/pycobr](https://github.com/michaelmior/pycobr)

Just got the encoder so far (without major type 6, i.e. tagging) and the code is pretty messy and possibly not 100% correct, but it's true that the amount of code required is pretty minimal.

<comment><USER31> Update: Fixed a bunch of bugs in the encoder and have a working decoder as well. Still no tagging, but you can encode/decode pretty much anything you could with a naive JSON implementation.</comment></comment></comment>


Bay Area home sales tank 10 percent in August – slowest pace in 7 years - <AUTHOR> https://www.cnbc.com/2018/09/27/bay-area-home-sales-tank-10-percent-in-august-to-slowest-pace-in-7-years.html <comment><USER2> The headline is written as though the market is tanking, but "the median price for all Bay Area homes sold in August was $830,000, up 12.4 percent annually" \-- fewer homes are selling because they're so expensive, but it isn't causing prices to decrease. They're still going up.

</comment><comment><USER3> Sales volumes are down. Prices aren't. Sellers are largely waiting things out because why sell now when prices will be even higher in a year. And likewise most buyers have fled the market because the low inventory and price appreciation have made housing options increasingly unappealing.

</comment><comment><USER4> Maybe buyers are buying elsewhere, like out of state.

</comment><comment><USER5> I wonder how much of this is due to recent fires and abysmal air quality... it's bad enough here that if I were still seriously considering moving out of area , I might have made the leap.

AQ is so bad I simply don't exercise outdoors as much... and it's not clear when it's going to get better.

<comment><USER6> What stopped you from moving out?

<comment><USER5> Massive change for kids, aging parents nearby and friends... not to mention one of us will have to find work wherever the other one goes.

It's a big change if you've put down roots.</comment></comment></comment>


The 2015 Global Startup Ecosystem Ranking Is Live - <AUTHOR> http://blog.startupcompass.co/the-2015-global-startup-ecosystem-ranking-is-live

<comment><USER2> Wow, look at Berlin's growth. I wonder what is driving this - can't only be Wunderlist and Rocket Internet ;-) Interesting insights into gender equality as well with 30% female founders in Chicago

</comment><comment><USER3> Wonder how cost of living will factor into growth in future years...SV, NYC, London, etc. are often just too expensive for early-stage and bootstrapped startups</comment>


Show HN: CSS UI Elements Only Marketplace (Not Full Themes) - <AUTHOR> https://www.uibuytes.com

<comment><AUTHOR> Have any thoughts/comments/feedback, I am here listening :)</comment>


Show HN: CloudMapper, open-source tool for visualizing AWS environments - <AUTHOR> https://github.com/duo-labs/cloudmapper <comment><USER2> VisualOps.io is a relatively full featured SaaS, for designing AWS environments, generating CloudFormation, and converging environments, plus more ops tools.

It can also import to visualize:

 _"Want to visualize your current AWS deployment? No a problem, Import the existing resources and generate the relative diagram automatically."_

[http://www.visualops.io/feature/](http://www.visualops.io/feature/)

[https://github.com/MadeiraCloud](https://github.com/MadeiraCloud)

</comment><comment><USER3> Looks like a great tool. The lovely folks at Hava.io are going to be unhappy about this!

<comment><USER4> The guy paying 1999/month is not going to switch to free & open source

<comment><USER3> I don't think that's accurate. We stopped paying because we couldn't justify the expense. Great product, great support, but we didn't have the necessary uptake with users. We would totally use an alternative like this.

</comment></comment></comment><comment><USER5> Nice! my account came out pretty ugly :( and took nearly 5min to generate. But this could be a handy addition to deployment pipelines/PRs when following Infrastructure as Code (as well as being on AWS).

Will keep my eyes on this.

Also +1 to duo 2fa ssh

</comment><comment><USER6> I like it, but I am not sure all the neighbors/children are helpful in a large deployment. We're running about 100 instances but have 1800 connections.

</comment><comment><USER7> Now if something like this could be built on top of Terraform provider- independent...

</comment><comment><USER8> The demo totally locks up Brave</comment>


Co1 – A directory for companies of one to find each other - <AUTHOR> https://co1.io <comment><USER2> Love seeing that folks are using the nomenclature from my book and creating new things from it!</comment>


Speech and Consequences - <AUTHOR> http://www.popehat.com/2013/09/10/speech-and-consequences/

<comment><USER2> I have found no reason to believe that the PD thing is/was anything more than a satire of the TechCrutch Disrupt demographic. It's just too silly.

<comment><AUTHOR> Don't worry, this post got flagged off the front page too. No need for HN to discuss it.

<comment><USER3> Pity though, it's a well-reasoned essay on why freedom of speech doesn't mean freedom from consequences, almost independent of PD's actions.</comment></comment></comment>


Pep8 is dead, long live pycodestyle - <AUTHOR> https://twitter.com/gvanrossum/status/737438918799282178 <comment><USER2> As per HN Guidelines[1], "please submit the original source", in this case:

[https://pypi.python.org/pypi/pycodestyle/1.8.0.dev0](https://pypi.python.org/pypi/pycodestyle/1.8.0.dev0)

(which more clearly explains that "pycodestyle" is a renaming of "pep8").

[1] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment><comment><USER3> I use Google's YAPF [0].

[0]: [https://github.com/google/yapf](https://github.com/google/yapf)</comment>


That Lost 4G Phone - <AUTHOR> http://www.dilbert.com/blog/entry/thatlost4gphone/

<comment><USER2> More interesting than the comics (which came off a bit forced to me) is the following:

>I worried that the story would become stale before my comics would work through the pipeline. I think the soonest I can get something published is in about a month, perhaps a bit sooner, but I've never tested it.

A month to go from the final draft of a black-and-white, three-panel, line- drawn comic to publication in a daily newspaper. A _month_!

And people wonder why newspapers are gradually becoming irrelevant.

<comment><USER3> I think what he was trying to say is that he has a 1 month worth of comics done that are waiting to be published, and if he would sent a new one it would get it's turn in one month ...

<comment><USER4> No, he had it right.

"I think the soonest I can get something published is in about a month ... it wasn't worth the extra friction to push them to the front of the line"

So if he had made a big push, he could have gotten them published in a month. He goes on to say when it would be published if he submitted it at the end of his queue.

"And it would be June 18th before they ran in their normal position, which seemed too far in the future."

</comment></comment></comment><comment><USER5> "That's a coincidence because _I sell other people's belongings_ "

Well put.

<comment><USER6> IIRC, the guy tried several times to return it to Apple, and they kept ignoring him. And he waited three weeks before selling it, giving them ample time to get in touch with him if it was really theirs. Since Apple remotely bricked it, he had no way of getting in touch with Gray or any of his friends/colleagues directly.

So it really seems like the guy's options were to sell it to Gizmodo, or let it sit in a drawer forever. If the account above is accurate, then I don't think it's fair to imply the guy was acting in bad faith.

<comment><USER7> Or to send it to Apple in a simple padded mailer. Or to bring it to the police. Seriously, his "only option" was to tell it to a gossip blog for thousands of dollars?

<comment><USER8> So Apple loses this thing that's worth a lot to them. Critical "trade secrets". He tries to return it, they don't say anything. He could give the super-valuable thing he recovered back to him for free, but why should he? What obligation does he have to work for Apple for free?

Instead, he decided to cash in. Seems reasonable to me.

<comment><USER9> > _"He could give the super-valuable thing he recovered back to him for free, > but why should he?"_

Because it's illegal to keep it - if he knows who it belongs to he is _legally compelled_ to return it to its owner.

Them pesky laws, always getting in the way of profit.

<comment><USER8> Arguably, Apple didn't want the phone, since he tried to return it and they didn't care. So, he eBayed it. (Or the moral equivalent thereof.)

<comment><USER10> It's fundamentally the same as the classic "found wallet". If it isn't claimed, it reverts to "finders keepers". So I have no idea why people are voting you down.

<comment><USER11> Not from a legal perspective.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So while the #2 link at the moment is HN 3 years ago and we say hey, those links were interesting back then.

And over here at #1, we have 88 votes for a comic strip. With the top comment saying 'well put'

I like Dilbert as much as anyone else. But ask yourself: did you learn anything? Long lasting interest doesn't come cheap. Some may say, 'hey, lighten up', but I'd say, 'hey, we already have reddit'.

<comment><USER8> Someday, you will learn that life is long enough to both learn _and_ have fun.

<comment><USER12> _sigh_ yes. By stating something that no one's going to dispute--myself included (I mean, who doesn't want to learn and have fun at the same time?), it diminishes what I was getting at.

In the case of dilbert comics, it was fun, but didn't learn much. That's what I'm against. Sure, there are other things that are also learning and fun, which is great.

If fun is sugar and learning is fiber in cereal, all I'm saying is beware eating sugar-only cereal. If you want sugar-only, we've got reddit. Important thing is to have the fiber, regardless of sugar or not.

</comment></comment></comment><comment><USER13> Am I the only one who doesn't find it funny? Not because I don't think jokes should be made about the situation, but rather because I think those particular jokes aren't very good.

<comment><USER14> It guess it just came off as strange to me because it's a stretch in terms of scope. For the comic's history, the jokes have generally implied that Dilbert's unnamed employer produces some kind of sprawling enterprise software, maybe with a consumer version, and to suddenly have them building next-gen smartphones is jarring enough to distract from the gag.

There _is_ something cool about seeing a never-to-be-printed Dilbert strip, though.

<comment><USER4> I was always under the impression that Dilbert's company was some sort of sprawling conglomerate like G.E. that produces all sorts of products. Dilbert and his coworkers seem to bounce pretty freely between hardware and software products.

Also, I don't think continuity is one of Scott's goals at all. In fact, I suddenly realized how absurd it was to be discussing what is and isn't Dilbert Canon.

<comment><USER15> There's no Dilbert canon at all. Adams even draws Dilbert's mouth now and then.

</comment></comment></comment></comment><comment><USER16> _Take a moment to marvel at the fact that I didn't need to add anything to the story as it has been told in the media. All it really needed was Wally._

That's all a lot of things need... Half his genius seems to be simply applying Wally to the right circumstances.

</comment><comment><USER17> I liked the following idea (from a commenter on the site) better than the originals:

> _Alternatively, it could be funny if Wally became a hero at work when he > suddenly delivers an amazing 4G phone that finally makes the company > successful - right up until the time it's discovered that he didn't actually > develop it, but found it on the counter at the coffee shop._

</comment><comment><USER18> Kinda ruined it when he has to explain it.

Way too literal in the first place, should have made some kind of parallel.

<comment><USER19> His stuff is often very literal, you just never worked for the company he was writing about (former Pacific Bell/SBC/AT&T employee here).

</comment></comment><comment><USER8> Excellent. The facial expressions and choice of characters are just perfect.

</comment><comment><USER20> I love Dilbert - this cartoons from the post are brilliant =)

</comment><comment><USER21> Funniest Dilbert episodes I've read in a while.</comment>


Show HN: Best Hired help you finding the top-notch developer - <AUTHOR> http://www.besthired.com

<comment><USER2> You need to proofread your copy dramatically, as it's honestly difficult to comprehend and breaks many grammatical rules.

Also, don't use sockpuppet accounts to comment on your Show HN thread.

<comment><AUTHOR> Thanks for the feedback. We will correct them. What you mean sockpuppet account?

</comment></comment><comment><USER3> Got an amazing work? Best developers on town. lol

</comment><comment><USER4> Hiring made easy- Awesome UI.Great</comment>


Schema Creator - <AUTHOR> http://schema-creator.org/

<comment><USER2> Is this the Second Coming of the semantic web?

<comment><USER3> I wouldn't characterize it as "semantic". It is definitely the Microdata spec from HTML5. But it's barely semantic.

</comment></comment><comment><USER4> Is this what happened to microformats?

</comment><comment><USER5> Ok, this is awesome.</comment>


Citus and pg_partman: Creating a scalable time series database on Postgres - <AUTHOR> https://www.citusdata.com/blog/2018/01/24/citus-and-pg-partman-creating-a-scalable-time-series-database-on-PostgreSQL/ <comment><USER2> I wouldn't call this a time series database at all. To me, tsdb implies analytics over a time dimension such as weather sensors or stock market data.

This is just patitioning a log on time so you can query the most recent and delete the old stuff.

I doesn't even really seem to me you necessarily want to partition on time since your load distribution is going to be terrible.

Edit: too add a little. There is a thing called a temporal database that is a little more general in usage i feel in that it is more about facts at specific points in time (such as your address last year) that i think this is more about.

There is even a bitemporal database that has two time dimensions (what do we think your last year's address is right now and what did we think your last year's address was yesterday - and in those you don't ever delete data that is wrong, you just update your belief about that point in time) and they are really interesting to work with. Those would seem much more similar to this.

<comment><USER3> Thanks for mentioning bitemporal databases, I hadn't heard of anything like that before. Time-based mutable facts are so hard to represent well.

I think their definition of time-series database fits the common usage I've seen everywhere: the data has a time dimension and is append-only/immutable (well, ok, you can mutate the data in a postgresql table, but nobody's forcing you to).

Given the choice between selecting a specialized time-series only database or using a time-series pattern in your existing postgresql database, postgresql is often (usually?) the more pragmatic choice. That's what we do at mixrank with time-series tables approaching the 100 billions of rows.

<comment> sahil-kang I also feel that using the bitemporal pattern on a Postgres DB is the most pragmatic choice. What are some advantages to using a specialized timeseries DB? I can't really think of any.

<comment><USER3> For one, you can avoid double-writing to disk by only having the log instead of the WAL/log + table. You can save space by using a more compact binary representation. Basically all performance/efficiency related.

<comment><USER4> How about a merkle tree structure for storing data (like Git does)? This would make it easy to find out what the snapshot at any given point of time was. Q is, whether it is powerful enough to support typical data-oriented applications?

</comment></comment></comment></comment></comment><comment><USER5> There was a post about timescale DB recently. Can you combine citusdb and timescale somehow to get super fast timeseries data and citus flexibility?

<comment><USER6> Craig from Citus here. From our cursory looks it does look like they could work together, though personally we've not tried it and I'm not aware of users that have (though it's entirely plausible some have already). What you'd have to do is setup timescale on each of your distributed nodes and tables. You'd still talk to Citus as the primary point and it would re-write and push the queries down to the nodes which could then leverage timescale.

</comment></comment><comment><USER7> Big shout-out to Keith Fiske for developing and maintaining pg_partman. It makes Postgres 10's native partitioning really easy to use.

</comment><comment><USER8> How well it performs compared to TimescaleDB ?

<comment><USER7> In general I'd expect native partitioning to have similar performance characteristics as TimescaleDB. On the insert side lot of the benefit comes from partitions having small indexes, on the delete side from the ability to drop partitions quickly, and on the select side from skipping partitions based on filters.

Postgres 10 partitioning does have a few limitations and inefficiencies that will be resolved in Postgres 11. Partitioning is the most actively developed area of postgres.

Note that Citus shards across multiple nodes, and can then partition on disk using native partitioning, which is automated by pg_partman. TimescaleDB so far only works on a single node.

Citus can also run parallel, distributed SQL queries, perform distributed transactions, and build rollups tables in parallel, and is used in Postgres clusters with up to a petabyte of data.

</comment></comment><comment><USER9> To me, this seems like the ideal solution to so many multitenant applications...

</comment><comment><USER10> The problem with Citus and TimescaleDB is that users can not install extensions on AWS RDS PostgreSQL.

<comment><USER11> That's a problem with AWS RDS PostgreSQL, not with Citus and TimescaleDB.</comment></comment>


Is there a blogging threshold for your startup? - <AUTHOR>

I read somewhere that 20 blog posts a month is about right, if you pursue blogging as a traffic acquisition strategy. Is there science to it or would you just write as much as you can (And perhaps give it way as guest posts for other blogs?) <comment><USER2> IMHO, blogging for driving traffic is really hit-and-miss. One article may become huge and generate tens of thousands of visitors in a short time span while hundreds other barely get any eyeballs on them. If traffic is your primary goal, fewer articles while making sure they are as "link-baity" as possible is optimal. Top ten lists, inflammatory titles and easily digestible content. Also get the link to the article out in as many places as possible to maximize the odds of it going viral.

<comment><AUTHOR> Perhaps more than traffic, conversion should be the measure. Good content converts, while link baits could get traffic. Seems like common sense, but would love to see some stats or experiences if anyone has.

</comment></comment><comment><USER3> One trick from some major media sites (such as CNN). They keep changing the title of the same article to make it look like it's a new one a few times a day.

You may learn what style of title may give the highest click rate, given the same article.

<comment><AUTHOR> That's interesting. I guess it would be mildly irritating though for readers who check in more than once, in a day!

</comment></comment><comment><USER4> It depends on the market and product. Its rarely 20, though. Usually around 10.</comment>


Private vs Public Beta - <AUTHOR>

My partner and I are ready to launch a beta version of our startup.  The thing is, this has taken a lot longer than expected, and we want to get this out there as soon as possible.<p>My question is, what are the pro's and con's of a private or public beta?  Why do people advise against public betas? <comment><USER2> Private betas can be great when you have lots of existing customers, and you'd like to limit the quantity of feedback on a new product or feature.

If this would be the first exposure the app is getting, and you don't have a treasure trove of users that might be lined up to get into the beta, I'd vote for a public beta.

In fact, I'd go further and not focus so much on the nature of the beta, but just launch the product, noting that this is the initial release, and you'd love to get feedback as you continually improve the product.

The three most important things for a startup to do are: Ship it, ship it and ship it. Location matters much less these days ;)</comment>


Ask HN: Is Posterous dying? - <AUTHOR>

Looks like Twitter is not giving them engineering resources. <comment><USER2> Are parts of it not working for you? I have not seen problems, and I use it almost every day.

Or are you asking whether they have ceased innovating? That could well be.</comment>


Show HN: ShelfJoy (making buzzfeed for books) - <AUTHOR> http://shelfjoy.com/discover <comment><USER2> This is quite interesting! (Former book editor here.) I will totally use this to discover and buy books.

I might suggest your "buzzfeed for books" comparison doesn't do it justice. Perhaps "Pinterest for books" or "Reddit for books"?

As feedback, a few thoughts off the cuff: \- I'm hesitant to auth Twitter, because you ask for permission to post but don't do the thing where you promise never to post on my behalf without advance warning. \- I think the "shelves" model is interesting. I'm definitely interested in what David Bowie found interesting. Maybe not so much Art Garfunkel (though IIRC he is an obsessive reader so who knows) \- It would be interesting if there was some cut where, for a given book on a given shelf, you could see other popular/relevant shelves it was on. Sort of the way Twitter surfaces tweets in your timeline that were liked by a friend. \- Maybe a view of just books, not shelves. \- I want to see what others had to say about these books, not just whose shelves they're on. Maybe that comes later, when you have more activity? \- Looks like you can add a book to your reading list, "heart" it, or "heart" a whole shelf. This is a slightly confusing information architecture, vs. something like on Airbnb which has a clear architecture of saving properties you like to a list. Might want to refine that a bit.

<comment><AUTHOR> Hey Greg,

Thanks a lot for your feedback. Reddit for books would definitely be more relatable to people on HN :)

You've suggested some serious interesting things.

Like giving the link to other shelves on which a book is. I currently don't have a book view because the site itself is very new and I want to validate if people really like the proposition as such. But this information can be integrated in the current shelf model too. I'm thinking something at the bottom of a shelf where the reader gets to see the other shelves that contain the same books.

Hearting of a shelf and the share on the right is indeed confusing people. Will do something about it sooner than later.

Thank you again for taking out the time to write your feedback :)

<comment><USER2> My pleasure and definitely agree some of the things I suggested go well beyond MVP. It is the blessing and the curse of getting product feedback that the second you do something interesting, people want a million more features ;-).

Good luck with it!

</comment></comment></comment><comment><USER3> Looks pretty interesting. I like the curation a lot better than some others I've seen. Although this may be a function of user base and audience at present. My comparison would be Goodreads, which is so overwhelmed with historical romance, fluff, young-adult sci-fi, and New-Agey self-help that I've yet to see anything on their newsletters that looks remotely appealing to me. People love that stuff, but it's not what I'm looking for.

I'd be curious (at some later date) to know what kind of a return you're getting on Amazon affiliate fees. At this point, that's the most reliable advertising income stream on my side-projects. It seems to be the best deal going, considering it's a pretty minimally invasive kind of advertising, and they actually pay a decent cut on referred sales. And that's on a piddly little blog that has some reviews, some code tutorials, and a page where I list some favorite books, as opposed to something like this which is really designed to get people to convert.

<comment><AUTHOR> Thanks for the warm words :)

Affiliate is just working enough for me to pay the server bills (less than 100 USD). So here's the thing I'm noticing about Affiliate commissions - currently, the only way to get decent commissions is to have a lot of shelves that are popular. Its just 3 months of launch and due to lack of aggressive marketing of any kind, most of the shelves are just sitting there.

The ones that get popular are converting well. I still need to figure out if this can be made mainstream by chance.

</comment></comment><comment><AUTHOR> Hello HN,

I've been working on ShelfJoy for quite sometime now. I've thought of ShelfJoy to be like buzzfeed for books where people can discover curated books on deep niche topics.

Curation is guided by algorithms in a few cases but finalised by an editor.

Wanted to know your feedback on this. If you think it works for you or not and what can I do to improve it.

Thanks in advance.</comment>


The Invention of Jaywalking - <AUTHOR> https://www.citylab.com/transportation/2012/04/invention-jaywalking/1837/ <comment><USER2> Kind of impressive how many "cultural" views and traditions are the result of clever and pervasive marketing.

Offhand, examples like putting a diamond in a wedding ring that costs a few month's salary or dressing boys in blue and girls in pink come to mind in that these views are so pervasive because they generate sales.</comment>


Populism takes a wrong turn - <AUTHOR> https://www.janus.com/insights/bill-gross-investment-outlook <comment><USER2> > [Trump's] tenure will be a short four years but is likely to be a damaging > one for jobless and low-wage American voters.

The second part of that sentence - probably. The first part - not so sure.</comment>


Teacher builds $50M a year business with learning materials - <AUTHOR> http://www.ocregister.com/2017/08/23/orange-county-teacher-builds-50-million-a-year-business-with-learning-materials/ <comment><USER2> I'm sure there's a lot more to this business than we can know from this fairly sunny writeup, but always good to hear about businesses that succeed outside of tech on HN. A couple business lessons I took away from this account:

1) Know your market - she was a teacher and deeply understood the pain of finding ways to engage students in a hands-on way.

2) Hustle: "she hand-wrote tens of thousands of letters to teachers. She followed up by driving to 60 teacher supply stores."

3) Capitalize on your hits - their first really popular product was a book on health and nutrition called "My Body" that sold more copies than there are teachers in the United States and still sells today.

4) Evolve the business: as technology became more popular, they started making materials geared around tech and their 2nd big product was "Technology for Terrified Teachers"

<comment><USER3> hustling like Ray Kroc

<comment><USER4> Although she seems to be much less caustic than Ray.

</comment></comment></comment><comment><USER5> I'm one of those lucky software engineers in the Bay Area that happens to be married to a teacher and I can 100% confirm that they are real hustlers at what they do. Every time I get home after a hard day of work and listen to what her day was like it humbles me and makes me really appreciate the awesome job that teachers do in our society. She is always super tired but super happy and satisfied at the same time.

</comment><comment><USER6> Teacher here. Good teaching materials are incredibly valuable.

One would think that some big company like Pearson would have cornered the market on teaching materials. Turns out, most teaching materials out there are just complete garbage.

Most materials made by a company are easy multiple choice and fill in the blank worksheets rather than engaging activities.

Most materials made by teachers are better, but usually have some kind of glaring flaw (like just too short or not modified for students with accommodations) because a teacher created it out of desperation with little time available and never went back to fix it up.

<comment><USER7> There is [https://www.teacherspayteachers.com/](https://www.teacherspayteachers.com/). The teachers are incentivized to fix up their one-off material and sell it for profit.

</comment></comment><comment><USER8> Wow, what a small world. I went to high school with the daughters in the '90s. Both of them were nice and I'm happy for their family's success.

<comment><USER9> as someone who grew up in the HB/FV area, i can definitely tell you're from the area too based on your username ;)

<comment><USER8> Ha, yes. Huntington Beach pride! Great to see another OC native on here. Sometimes I'll check the Who is Hiring thread to see which OC companies are using HN for recruitment

</comment></comment></comment><comment><USER10> I'm sure most qualified teachers will tell you they are in desperate need of quality classroom materials. What this article doesn't address (and a quick search reveals no answers) is that these materials _need_ to fit into a research-based curriculum. It's one thing to make engaging lessons, it's another to conclusively prove they teach the material.</comment>


The Hacker's Diet - <AUTHOR> https://www.fourmilab.ch/hackdiet/ <comment><USER2> its fascinating that people keep writing about this even though everyone knows exactly how to lose weight.</comment>


A look at some (Linux) RSS readers [LWN.net article] - <AUTHOR> http://lwn.net/Articles/421348/

<comment><AUTHOR> Could someone please come up with a better (and learning) RSS reader? I mean:

\- never show me duplicate articles (duplicate is: points to the (almost - yeah, clever) same link)

\- I can rate the items (if I want to), than it sorts based on that rating

\- then allows filtering of items based on everything (especially rating)...

I'd donate...

<comment><USER2> I don't understand your rating request. What's the use case?

If you rate the item after reading it, you won't want to see it in your incoming stream of new items, so I don't see how you can sort based on ratings.

If you rate the item before reading it, what are you rating it on?

As I said, I don't understand what your use case is.

(But filtering --- yes, I understand completely.)

<comment><AUTHOR> Sorry about not explaining correctly. I meant: read the article, give it a spam/ham status (or 1 to 5 start rating or ...). Then on the next article(s) (in the near future) based on the words in the already classified article's words (which can be links to specific domains too (e.g. subscribed to some link aggregator, but it sometimes sends spams)) the unread article should be classified as probably ham/spam. And I don't want to see spam below a threshold... In short: Bayesian like learning...

And yeah I can use something like rss2mail and a MUA with spam filter... But I'd prefer a dedicated application (which lives on the desktop but syncs with the cloud, and multiplatform).

Is that too much? ;-)</comment></comment></comment>


Learn Security Engineering - <AUTHOR> https://github.com/veeral-patel/learn-security-engineering <comment><USER2> Author here; let me know if you have any questions.

This repo is a work in progress. I think it has enough content to be useful to others, so I thought I'd share it. But I hope to continue to study security engineering throughout my lifetime, so it hopefully be a work in progress forever :)

Anyways, this means I would very much appreciate any pull requests or issues with links to new books and papers to check out on this topic!</comment>


Vodka from Chernobyl Is Perfectly Safe, Say the Scientists Who Made It - <AUTHOR> https://www.nytimes.com/2019/08/09/world/europe/chernobyl-vodka-atomik.html <comment><USER2> NYT won't let me read the article, but other sources say any amount of alcohol is bad for you:

[https://time.com/5376552/how-much-alcohol-to-drink- study/](https://time.com/5376552/how-much-alcohol-to-drink-study/) [https://time.com/4172600/uk-government-alcohol- guidelines/](https://time.com/4172600/uk-government-alcohol-guidelines/)

</comment><comment><USER3> Can I get a geiger counter before I try it?</comment>


Plastic bags were finally being banned. Then came the pandemic - <AUTHOR> https://www.vox.com/the-goods/2020/5/20/21254630/plastic-bags-single-use-cups-coronavirus-covid-19-delivery-recycling <comment><USER2> Banning plastic bags is a great idea. I love using inconvenient paper bags or buying reusable bags which I have to lug around and inevitably forget to bring with me. And now I get to buy plastic bags to line my trashcans instead of reusing the free ones. What a treat!!</comment>


Go vs. Elixir: A concurrency comparison [slides] - <AUTHOR> https://codesync.global/media/go-vs-elixir-a-concurrency-comparison/ <comment><USER2> I hope this gets to the front page, I'm very interested to read a HN discussion on this. I've only worked with Go and only for 6 months. Concurrency was a new topic for me at the time, I haven't considered different ways of handling it.

</comment><comment><USER3> Youtube link: [https://www.youtube.com/watch?v=SbRvX1CQ9ic](https://www.youtube.com/watch?v=SbRvX1CQ9ic)

Interesting in the conversation with these two langs. Looking into Elixir for a new web app.</comment>


Lenovo Twist Review (Windows 8 Convertable) - <AUTHOR> http://www.sharms.org/blog/2012/10/lenovo-twist-review/

<comment><USER2> Reading this review, what I would really like is a Twist hackintosh, with a hack to the iPad simulator to run it full-screen...

<comment><USER3> As a user of an x41 'twist', I'm definitely curious about this new wave of tablets. I wonder how they'll compare to something like an x220t though? Will the price point be convincing enough to accept the reduced performance?</comment></comment>


Ask HN: Built an app but don't know how to take it to the next phase - <AUTHOR>

I just spent the last year and a half building an iOS app, an idea that I have a lot of passion for. It's a social app, so the next step is quite the obstacle for me, I don't really know how to go about pushing it to the market. Its content requires a decent size user base so I've been considering trying to get some funding for help.
I haven't released it to the app store yet.
I've made a video demo of the app and have thought about sending it to....
questions:
-what direction should I go from here with these presented circumstances?
-would it be risky to send someone the video who has a lot of money and resources?
-should I fly out to san fran and start knocking on doors?
-should I scrap my entire plan and just try to do it myself?
Any advice would be greatly appreciated <comment><USER2> Without knowing exactly what your app does I'd say before taking funding or flying to SF you should start to get some kind of traction or a beta going with a user base to learn from. Also sounds like you are unsure how to market your app. If you need a certain size user/content base before your app is interesting you have an engagement wall problem. It might be a good idea to push installs by buying ads (twitter, facebook, etc.) on top of influencer marketing.

<comment><AUTHOR> Interesting, thanks for the advice. I guess that engagement wall is somewhat a giant one in my case.

Sorry for being so vague with what I have.</comment></comment>


Pointless Terminal Tricks - <AUTHOR> https://lunduke.com/posts/2020-02-18/ <comment><USER2> "Give the terminal an attitude" Where has this been my whole life- I can now have my terminal be snarky with me.</comment>


Why IBM doesn't agree with Google's Open Usage Commons for the Istio project - <AUTHOR> https://developer.ibm.com/components/istio/blogs/istio-google-open-usage-commons/ <comment> tedk-42 It sounds like Google want to continue maintaining the Istio project under the guise of something called the Open Usage Commons.

The other two projects under that are Angular and Gerrit, two other Google products.

IBM's disappointment stems from the fact that they feel Istio is also their baby and that it was suppose to goto the CNCF one day, not Googles own umbrella foundation.

I think the same. Google for the most part want their names associated with these products rather than being something community driven.

<comment><USER2> While I generally believe in Google's altruism in their open source contributions, that good faith does not carry forward to any of their open source initiatives when it comes to Google Cloud.

Maybe I'm cynical, but it seems pretty obvious to me that Google embraces OSS with Istio, Kubernetes, etc only out of necessity and being a distant 3rd in the Cloud race, and this is their attempt at some sort of differentiator.

<comment><USER3> I suspect Google felt they got burned with Kubernetes - doing a lot of the initial development, donating it to the CNCF and then not profiting much from it (e.g. still being distant 3rd in cloud).

<comment><USER4> Google did profit massively from kubernetes, moreso than any other big company (Hello Red Hat lol)

It was (for better and for worse) the #1 reason to adopt GCP for our main cloud platform, and we're not alone.

It's has seen immense adoption that it wouldn't have had if it hadn't been in a neutral foundation. The work was definitely not done by Google alone (~30%).

IS GCP "still" #3 ? Yes. Is it because they didn't get a tighter grip on k8s and try to use it as a competitive advantage ? absolutely not. Nobody would have touched k8s with a 10 foot pole in that situation.

The strength of k8s is in its eco-system and that wouldn't have happened without the CNCF.

And I'm saying this as an early adopter of k8s, it's insane for the Google brass to see anything other than an immense success in the handling of k8s, at least from the perspective of how much money it made Google (indirectly)

It's not because of K8S strategy that GCP is #3. It's just because MS & AWS are better. PERIOD. Better at service, better at marketing, better at some product design sometimes, better at abusing their current dominant position (hehe it sucks doesn't Goog ? heh? Doesn't it ?)

<comment><USER5> > better at abusing their current dominant position (hehe it sucks doesn't > Goog ? heh? Doesn't it ?)

Just wanted to say this one weirdly petty/obnoxious concluding line tainted an otherwise solid comment. Seems unnecessary.

<comment><USER6> I don't see why. It's funny, based on facts and doesn't imply a clear bias (very different from something like "and btw Google are assholes").

</comment></comment></comment></comment></comment></comment><comment><USER7> Disclaimer: i work for Google Cloud and use istio daily.

I don't think this matters to practitioners, it's a solution to fix trademark issues.

Open Source Licenses (like Apache under which istio is released) doesn't solve the trademark (TM) issue, they are vague around this topic, so the use of the name/logo/mascot to release any sort of managed or supported solution based on an OSS tool becomes a hurdle, a lot of money is at stacks here (imagine if k8s was still under the control of Google, AWS or Azure will never be able to launch something called Kubernetes engine because there is a risk Google will sue them).

The problem with CNCF and why istio was not transferred to that org is that CNCF acts as a mediator, so any decision around trademark takes soo much time and effort because CNCF has to get the blessing of everyone or build something neutral (like the k8s certification), and it's in their best interest that things are complicated as they can make money out of that.

The OUC was created to solve the TM issue and allow decisions to move fast, the usage guidelines haven't changed and will likely not change.

I do have to admit that myself i don't understand why no one from IBM is in the initial board of OUC

<comment><USER8> > acts as a mediator, so any decision around trademark takes soo much time and > effort because CNCF has to get the blessing of everyone or build something > neutral (like the k8s certification)

Sorry, but that's the nature of standardisation, and the price you pay if you want to show you're really vendor-neutral. For me, actions like these make Istio go from the almost de-facto default choice for a service mesh, to suddenly wanting to consider other stuff.

> and it's in their best interest that things are complicated as they can make > money out of that.

I don't really see how money would be an issue here? CNCF is a non-profit, Google is not.

<comment><USER7> > Sorry, but that's the nature of standardisation, and the price you pay if > you want to show you're really vendor-neutral. For me, actions like these > make Istio go from the almost de-facto default choice for a service mesh, to > suddenly wanting to consider other stuff.

That's not what the Cloud industry is about, it's about speed and time to market.

> and it's in their best interest that things are complicated as they can make > money out of that.

Valid point, i have no evidence to support this, i just feel like CNCF looks for any opportunity to monetise itself for reasons i don't understand (Certifications, Conferences...). For a non profit that doesn't hire the core developers of the tools they support (most are hire by tech companies) i don't see why kubecon should cost 1k$+

<comment><USER8> > That's not what the Cloud industry is about, it's about speed and time to > market.

Not sure how that's even an argument? Istio already was the de-facto standard, it is already in the market right now. Nothing prevented them from submitting to the CNCF - even if the acceptance would have taken a while. This wouldn't have suddenly stopped adoption or development in any way? It would only have enforced the view that the project was committed to stay vendor-neutral. Now, at least in my eyes, they've shown exactly the opposite.

> For a non profit that doesn't hire the core developers

Not sure why an organization formed to allow multiple vendors to work together on the same tools and play neutral party there would need developers. That would make them a stakeholder, something you want to avoid. They do have staff though[1], which also costs a lot of money, and organizing events isn't free.

[1] [https://www.cncf.io/people/staff/](https://www.cncf.io/people/staff/)

</comment></comment></comment></comment><comment><USER9> Relevant post from Istio blog: [https://istio.io/latest/blog/2020/open- usage/](https://istio.io/latest/blog/2020/open-usage/)

"As one of the founders of the project, Google is the current owner of the Istio trademark. While anyone who is using the software in accordance with the license can use the trademarks, the historic ownership has caused some confusion and uncertainty about who can use the name and how, and at times this confusion has been a barrier to community growth. So today, as part of Istio's continued commitment to openness, Google is announcing that the Istio trademarks will be transferred to a new organization, the Open Usage Commons, to provide neutral, independent oversight of the marks. [...]"

</comment><comment><USER10> It seems a bit that the big players also realize that making money off their technology investments would be nice.

Here we have the interest of IBM/Redhat that as a services company benefits from an as open as possible model, whereas Google as a product company notices that their hugely successful k8s play does not turn into business for their cloud product as intended.

<comment><USER11> Could you please elaborate on what this has to do with this dispute about how to open source the trademark?

<comment><USER12> My understanding is that there is a faction in Google that believes that making Kubernetes freely available as it did was a massive strategic mistake on the part of Google[1], tantamount to giving away the crown jewels. With this in mind, my impression is that there is a strong suspicion that Google is trying to find a way to continue to control the direction and ability to monetize Istio (and future projects if this works out) which obviously makes IBM irate since it now throws into doubt a slew of potential business opportunities on their end.

[1] [https://twitter.com/ThatMightBePaul/status/12798801693443358...](https://twitter.com/ThatMightBePaul/status/1279880169344335874)

<comment><USER13> That's interesting because there's also a vocal contingent who believes Google giving away Kubernetes was a punji trap that the rest of the tech world has falling into.

Is k8s an amazing force multiplier or an unmanageable white elephant? Can it be both?

<comment><USER14> K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non- enormous IT systems operator will eventually realize they can be a pure-play no-fixed-costs service provider. The only challenge is of course that good ops is not the same thing depending on scale, so hype is essential to bring the plebs into accepting maximal complexity of highest-scale ops.

<comment><USER15> Depends pretty much on the stack.

With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS.

Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...

<comment><USER16> I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications.

The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models.

Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.

<comment><USER15> I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries.

The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.

<comment><USER16> My biggest practical issues are around a few libraries with really restrictive licensing without good floss alternatives. At least short of the effort to hire and create appropriate ML models in house, which isn't a proficiency we currently have.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> It looks like the Open Usage Commons organization handles trademarking, so roughly speaking (I'm not a lawyer) they set and enforce rules under which other entities may use their hosted project names and brand identities.

When GCP's container engine launched[1] in 2014 it was initially referred to by the anagram 'GKE' yet corresponded to the name 'Google Container Engine'.

After achieving CNCF certification in Nov 2017[2], GCP began using the term 'Kubernetes' within the product name, rebranding it as 'Google Kubernetes Engine'.

At least as far back as Oct 2017, members of the CNCF did not have to pay any fees[3] to participate in the conformance program.

Is it possible that executives within Google were unhappy about the marketshare gains of GKE and attribute this partially to the time it took their product to achieve certification?

If so, could that have led them to push other open source initiatives within the company to retain their trademarks under tighter control, even if that required creating an organization with less experience handling international trademark registration?

As per the post, IBM's stated standpoint is: "IBM continues to believe that the best way to manage key open source projects such as Istio is with true open governance, under the auspices of a reputable organization with a level playing field for all contributors, transparency for users, and vendor-neutral management of the license and trademarks."

[1] - [https://www.infoq.com/news/2014/11/google-cloud-container- en...](https://www.infoq.com/news/2014/11/google-cloud-container-engine/)

[2] - [https://cloud.google.com/blog/products/gcp/introducing- certi...](https://cloud.google.com/blog/products/gcp/introducing-certified- kubernetes-and-google-kubernetes-engine)

[3] - [https://github.com/cncf/k8s-conformance/commit/34683a3316473...](https://github.com/cncf/k8s-conformance/commit/34683a331647377585f30df47a1bce27b731cac9#diff-1131adf39164dafb81de955efadf6029R39)

<comment><USER18> > After achieving CNCF certification in Nov 2017[2], GCP began using the term > 'Kubernetes' within the product name, rebranding it as 'Google Kubernetes > Engine'.

After _creating_ the certification program: it was driven by GKE PM (and upcoming book author[1]) William Denniss. [https://kubernetes.io/blog/2017/10/software-conformance- cert...](https://kubernetes.io/blog/2017/10/software-conformance- certification/)

(At the time of GKE's launch, 'containers' were more well known than 'Kubernetes'. Google also owned the trademark, so it could have been called Kubernets Engine from the beginning.)

[1] [https://www.manning.com/books/getting-started-with- kubernete...](https://www.manning.com/books/getting-started-with-kubernetes)

<comment><USER17> Thanks for the explanation; that all makes sense and certainly makes the naming of GKE seem like less of a driving factor.

PS: For anyone curious about the adoption of the word 'Kubernetes', Google Trends provides a good summary: [https://trends.google.com/trends/explore?date=all&q=kubernet...](https://trends.google.com/trends/explore?date=all&q=kubernetes) (2014 was definitely very early days)

</comment></comment></comment><comment><USER9> Do I understand correctly that this is a way to make sure the trademarks for the projects can be used in similar open fashion as the code itself?

My understanding: Typically the trademarks are not covered by the open source license. If the software is licensed under Apache license, I can use the software to power my cloud business, but I might not be entitled to use the project's trademark in my marketing.

</comment><comment><USER19> This is entirely about the use of the trademarks/names.

If enough people are upset about it, they can fork the project and take it in their own direction under their own governance.

To me, this is a non-issue. The people doing the work on the project are setting the projects goals and rules, and if _you_ want to do work on the project, nothing stops you, either under their governance/name, or your own.

<comment><USER12> If you look at the CNCF, they now offer Kubernetes certifications. This is worth _a lot_ of money. This is probably one part of what is driving this.

<comment><USER20> As someone who helps run CNCF, there's about 100 certified distributions and thousands of people who have been certified as kubernetes administrators (CKAs), as a small non profit with about 25 employees that pales in comparison to a trillion dollar cloud provider

</comment></comment></comment><comment><USER11> Can someone explain why this matters? I still don't get it after reading the blog post or fh973's comment.

<comment><USER21> "Google launches the Open Usage Commons, a new organization for managing open- source trademarks"

[https://techcrunch.com/2020/07/08/google-launches-the- open-u...](https://techcrunch.com/2020/07/08/google-launches-the-open-usage- commons-a-new-organization-for-managing-open-source-trademarks/)

And their FAQ: [https://openusage.org/faq/#what-is-the-open-usage- commons](https://openusage.org/faq/#what-is-the-open-usage-commons)

<comment><USER11> It doesn't seem like this is a huge deal then, unless there's something happening away from the public view... IBM would have just preferred that another organization had been used.

<comment><USER22> CNCF is where most people and companies doing anything with Kubernetes (who don't work at Google) would expect Istio to reside.

</comment></comment></comment></comment><comment><USER23> In my (worthless) opinion, I'm 90% sure that Google wants to drive istio in the direction of supporting AnthOS and that's why they're vying for control of the project. It seems increasingly clear to me that their entire cloud strategy seems to be to use AnthOS to try and perform an end-run around AWS

</comment><comment><USER24> _At the project's inception, there was an agreement that the project would be contributed to the CNCF when it was mature._

If this is true, the authors could be sued for breach of contract (what the damages would be, I'm not sure). However, I suspect that this agreement was verbal or implicit and wasn't actually written anywhere.

As they say, a verbal agreement is worth the paper it's printed on.

Get your promises in writing, folks.

</comment><comment><USER25> For the uninformed, IBM is mostly in the business of selling expensive old- school consultancy solutions by marketing snake oil and packaging open source in proprietary label. Need evidence? Watch this cringeworthy video, for example: [https://youtu.be/iNVM8vGCZjQ](https://youtu.be/iNVM8vGCZjQ)

<comment><USER26> IBM contributes to the Linux Foundation (Node.js, webpack, jquery, etc.), Apache, and by owning RedHat, also major parts of Linux development, among other things.

<comment><USER27> Also recently the OpenPOWER foundation got moved under the Linux Foundation</comment></comment></comment>


Google Home and Chromecast DOWN - <AUTHOR> https://www.thesun.co.uk/tech/6640574/google-home-chrome-cast-down-not-working-offline-why-fix/ <comment><USER2> I had this issue while trying to watch a World Cup match in bed. I tried to troubleshoot it myself - restarting, rebooting, resetting every connection possible.

I didn't know Chromecast could go down on a large-scale like this because I would imagine it would just be something functional within my own network. Now I know.

<comment><USER3> Same here. I really thought my phone broke because my wife's phone could connect with one app, but YouTube was also down.

I really thought there Chromecast has a small server to listen for broadcast then it would start streaming from whatever content source.

I guess that privacy issue is bigger than I thought.</comment></comment>


Ask HN: What are interesting technology problems in neonatology? - <AUTHOR> My wife recently gave birth to our first child whom had to subsequently spend a month in the Neonatal Intensive Care Unit. I am now in awe of the whole world that exists to help babies transition from the womb to the real world. Are there any interesting computational or technolog-related problems in the neonatology space? I would love to donate my time to this specific cause. <comment><USER2> While this is a noble thought, don't forget to give thought to your wife and baby. Informed spousal support is crucial to warding off postpartum depression, and keeping the marriage healthy requires a lot more work when there's a rugrat in the house.

Ultrasound technology definitely has room for improvement.

There's a bit of quackery going around ultrasound departments where they will miscalculate your fetus' conception date by a week or two, measure the fetus' femur length, and then scare you into ordering an extremely expensive blood test, not covered by health insurance, to rule out Down syndrome.

This is based on some old research that correlates a femur length ratio very weakly to an increased risk, when certain ethnicities frequently occupy that ratio without any increased risk, and miscalculating the number of weeks can also throw normal kids into the danger region due to the necessary precision of the measurements involved.

We were guilted, heavily, into ordering one of these tests by our local and otherwise reputable hospital complex. While we weren't dumb (or wealthy) enough to order the test, it did cause substantial stress for mom, and I wonder how that impacted the baby. Even if we had proof positive that our kid had Down (he doesn't), knowing wouldn't have changed anything, since abortion at such a late term for what may be a minor issue is a nonstarter, and I suspect it would be for most expecting parents.

Just a thinly-veiled way for ultrasound practices to scare you into paying them hundreds of dollars in commissions, at the expense of your mental health and that of your baby. Disgusting and amazing that it hasn't made the news, because from what I found on the internet, it's extremely common.

If you want to help, maybe find a way to cut out this depraved practice.</comment>


Show HN: Kf – Sass keyframe animation library - <AUTHOR> http://kf-sass.com/?HN <comment><AUTHOR> Hi HN - have been working on this small Sass library which helps you create keyframe-based animations. It's finally at a point where I think it could be useful to others.

Basically the idea is you model your animations as Sass maps and then you can use a few mixin to compose the pieces of your animation together.

Any feedback is appreciated.

Github is: [http://github.com/mil/kf-sass](http://github.com/mil/kf-sass)</comment>


Haters gonna HATEOAS (Hypertext As The Engine Of Application State) - <AUTHOR> http://timelessrepo.com/haters-gonna-hateoas

<comment><USER2> The reason nobody does HATEOAS in APIs is because the libraries used by clients don't encourage or even enable it. Chicken and egg.

Why should you care? The real potential is that you don't need a separate API site, you just add links to your existing HTML representations, and optionally provide JSON representations for bots so they don't have to download puny human HTML.

There's a rare of example of this in action in the wild: Canonical's Launchpad. Paper: [http://www.crummy.com/writing/speaking/2010-WS- REST/Develope...](http://www.crummy.com/writing/speaking/2010-WS- REST/Developers%20Like%20Hypermedia.pdf)</comment>


Terrafugia 'Flying Cars' May Go On Sale in 2011 - <AUTHOR> http://www.cbsnews.com/8301-501465_162-20015865-501465.html <comment><AUTHOR> I probably should have just linked to this article:

[http://news.cnet.com/8301-11386_3-20015841-76.html?tag=conte...](http://news.cnet.com/8301-11386_3-20015841-76.html?tag=contentMain;contentBody)

</comment><comment><USER2> Isn't this just a small plane?

<comment><AUTHOR> Mostly, but it does convert into something you can drive on the roads.

</comment></comment><comment><USER3> I still want my hoverboard!</comment>


Chromium Notes: Moonlight vs IcedTea - <AUTHOR> http://neugierig.org/software/chromium/notes/2011/01/plugin-conflict.html <comment><USER2> What a fascinating entry. I absolutely would not want to debug over IRC, and definitely not using gdb. That is some mad skills.

Up one level, BTW, is a discussion about his 20% project at Google working with (or against) clang. Also insightful reading.

</comment><comment><USER3> For RockMelt (Chromium based), plugins account for 38% of our crashes under Windows and 24% under Mac OS X. Looks like Firefox is similarly afflicted:

<https://crash-stats.mozilla.com/products/Firefox>

</comment><comment><USER4> Somewhat unrelated questions: Anyone know when Moonlight will support Netflix (if ever)?

<comment><USER5> I don't have any insider info, but just from having followed Miguel's blog for awhile, my impression is that the Netflix stuff is more related to DRM than anything about Moonlight/Silverlight. I believe it boils down to there not being a PlaysForSure (or whatever their DRM is called, hard to keep them all straight they are so similar) implementation available to them, particularly on non-Windows platforms.

<comment><USER2> While I don't have any intelligent thing to say about Moonlight and Netflix, I did want to point out that Netflix streams to a ton of disparate hardware (and OSes, including "normal" ones such as OSX). Thus, I get the impression this is a legal problem more than a technical one.

<comment><USER6> FWIW, Microsoft provides a Silverlight runtime for OSX[1]; for embedded streaming I assume they hand out crypto certificates on a case-by-case basis. So yeah, pretty sure it's a legal thing.

[1] although being located outside the US, I can only _assume_ that this is what is used.</comment></comment></comment></comment>