HTTP/2: The Long-Awaited Sequel - <AUTHOR> http://blogs.msdn.com/b/ie/archive/2014/10/08/http-2-the-long-awaited-sequel.aspx <comment><USER2> Check out the IETF draft[1], and this awesome book[2] for more details on HTTP/2.

Some of the coolest stuff I saw was streams and server push. Streams allow multiplexing multiple logical streams of data onto one TCP connection. So unlike the graphs you typically see in chrome network inspector where one resource request ends and another begins, frames (the unit of data) from multiple streams are sent in parallel. So this means only one connection (connects are persistent by default) is needed between server and client, and there are ways to prioritize streams and control flow so it gives devs more opportunities for performance gains.

Also headers are only sent in deltas now. Client/server maintain header tables with previous values of headers (which persist for the connection), so only updates need to be sent after the first request. I think this will be a consistent 40-50 byte saved per request for most connections where headers rarely change.

[1] [http://tools.ietf.org/html/draft-ietf-httpbis- http2-14](http://tools.ietf.org/html/draft-ietf-httpbis-http2-14)

[2] [http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...](http://chimera.labs.oreilly.com/books/1230000000545/ch12.html)

<comment><USER3> I don't get this.

TCP has steams. TCP has connection mux. TCP has flow and congestion control. HTTP has keepalive. Why build another stack on OSI layer 7?

Also now we have to keep state to work out what the diffs are. State is evil.

Whilst I'm sure this will have some minor performance advancements, I'm not sure that it justifies the new protocol stack.

Not sending 2Mb of JavaScript and crappy HTML down the connection to display the front page probably has higher gains.

<comment><USER4> You'll need to call a meeting of all the internet's firewall administrators who block TCP ports by default but allow 80 and 443 through. If you can get them to agree to stop breaking the internet then we can use TCP. Until then we will need to build a new internet on top of HTTP, inside encryption so they can't meddle with it.

<comment><USER3> I don't understand your point.

80 and 443 are "well known ports"[1] which is fine.

What does this have to do with ports? TCP is connection based so a client can create as many connections as it likes to a port on a host.

If someone does indeed build a new "internet" built on top of HTTP which is tunnelled through well known ports with different services with the intention of circumventing the firewall then they will not be allowed through my firewall at all.

[1] [https://www.ietf.org/rfc/rfc1700.txt](https://www.ietf.org/rfc/rfc1700.txt)

<comment><USER5> The problem is that opening new connections is horribly inefficient. The 2-3 round trips (TCP + SSL) required to set up a new connection and the ensuing slow start phase significantly delay the request, and thus the response. It is _much_ more performant to use a single, well-utilized connection in congestion avoidance. The only way to avoid the ugliness of repeated flow control is to build on top of UDP (see QUIC), but there are practical issues with network connectivity and firewalls there.

EDIT: why do you want to block HTTP/2 by the way? You know that HTTP/1.1 can be used to tunnel other protocols too, right?

<comment><USER3> That's not horribly inefficient. That's the cost of doing business with HTTP.

In fact you're going to have to go to the same effort to establish a TCP connection that your HTTP/2 is going to run over, then still have to do a key exchange. That channel then has the same advantages of a persistent HTTP/1.1 channel plus the ability to provide multiple streams.

The multiple streams can be resolved simply by making more than one connection to the server defensively. Perhaps a mechanism to schedule that client-side would work. Oh wait, we already have one (connection limits and keep-alive).

Then again, all of this is moot as once you've loaded the static resources (images/css/js etc) via HTTP, you should only be seeing one request periodically when an operation takes place or at an interval if polling or kept alive for server-push so maximum two connections from a client to a server.

If you need to do anything more than that, you're probably using the wrong technology both on the server and client.

HTTP/1.1 tunnelling I understand. In fact I use it most of the day (RDP over terminal services gateway) which is RPC over HTTP.

The rationale I have is that effectively managing HTTP/2.0 at the firewall requires packet and protocol inspection rather than merely understanding what connections have been made and where from and where to. This has a significant complexity and tooling cost and effort. Plus there is a significant opportunity to mask illegitimate traffic as legitimate traffic. For those of us who deal with end user network security, this is a major problem.

</comment></comment></comment></comment></comment></comment><comment><USER6> HTTP/2 is certainly not a clean separation of concerns like HTTP/1.x was, but it's something of a pragmatic approach to protocol design.

HTTP/1.x was neatly layered on TCP with an easy-to-parse text format. This in turn ran neatly on IP4/6, which ran on top of Ethernet and other myriad things. This separation of concerns gave us the benefit of being very easy to understand and implement, while also allowing people to subvert the system, adding things like half-baked transparent proxies to networks that would munge streams and couldn't agree where HTTP headers started. We ended up having to design WebSockets to XOR packets just to fix other people's broken deployments.

HTTP/1.x also became so pervasive that it became the overwhelmingly most popular protocol on top of TCP, even to the point where a system administrator could block everything but ports 80 and 443 and probably not hear anything back from their userbase. This is the reason we ended up with earlier monstrosities like SOAP and XML-RPC: by that point HTTP had become the most prevalent transport that it was assumed incorrectly in many cases that it was the _only_ transport.

Perhaps the IETF should be pushing a parallel version of HTTP that pushes many of these concerns into SCTP. The problem here is that it'll take forever to get that rolled out and we need something to improve things now. Look at how long it's taking to roll out IPv6: something we _actually need_ to fix now.

<comment><USER7> >We ended up having to design WebSockets to XOR packets just to fix other people's broken deployments.

I was unaware of this and became intrigued. If anyone else is curious, this is the explanation from the RFC: [http://tools.ietf.org/html/rfc6455#section-10.3](http://tools.ietf.org/html/rfc6455#section-10.3)

Basically it's to prevent an attacker from cache poisoning an HTTP proxy (like one on a corporate network) that doesn't properly support WebSockets. WebSockets look a lot like HTTP over the wire, so without masking the wire data in some way a proxy could be tricked into believing a faked "HTTP"-looking request and response are real, and thus cache whatever an attacker supplies.

This would technically be a bug in the proxies, but it's nice to see IETF accounted for this and put in countermeasures before it inevitably became a DEFCON talk.

</comment></comment><comment><USER8> > Why is Internet Explorer leading with HTTP/2 implementation?

 _Leading?_ Firefox and Chrome already support HTTP/2 already (and SPDY, the basis for HTTP/2, for a long time now), just not enabled by default.

<comment><USER9> You are right and given that its a tech preview, this is Microsoft catching up.

Their real problem of course is IIS. We'll probably have to wait for IIS9 which I cannot see happening for another two years. IIS8.5 appeared 12 months ago in Windows Server 2012 R2.

</comment></comment><comment><USER10> Also, Chrome has experimental support for HTTP/2 in Canary[1] as well as Firefox since version 34 (if I'm reading [2] correctly).

It seems unusual for Microsoft to disable SPDY support entirely, at least until support for HTTP/2 is more widely deployed...

[1]: [http://www.chromium.org/spdy/http2](http://www.chromium.org/spdy/http2)

[2]: [https://wiki.mozilla.org/Networking/http2](https://wiki.mozilla.org/Networking/http2)

<comment><USER11> HTTP/2 is based on SPDY: [http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_dif...](http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY)

So if they leave SPDY in place along with HTTP 2.0, they could wind up with strange incompatibilities occurring or site operators feeling like they need to support both SPDY and the HTTP 2.0 standard (rather than just the HTTP 2.0 standard).

Looking at it, it actually seems more progressive to dump SPDY and move to the SPDY-based HTTP 2.0 at this stage. Then ten years down the road hopefully SPDY will be dead and there will just be HTTP/1.1 and HTTP/2.0.

</comment></comment><comment><USER12> You can probably get a comparable, if not greater, improvement in performance by using ad and tracker blocking. Most of those extra TCP streams opened when displaying a web page are for ads and trackers. Those are the ones opening a TCP connection to send their one-pixel GIF.

<comment><USER7> A modern web browser will not block page loading when making a request for an image, though. I don't think blocking ads will necessarily improve perceptible page load time, though obviously it will reduce network traffic.

This does not apply for ad code that's implemented as <script src="..."></script>, which will indeed block page loading.

<comment><USER13> Try it, the change can be dramatic. Ads have a lot of JS these days.

<comment><USER7> >Ads have a lot of JS these days.

A lot of the ad JS I see is in the form of inline script tags, which generally should not block anything (the JS usually asynchronously constructs another script tag, which shouldn't impact performance).

>Try it, the change can be dramatic.

I've been using AdBlock Plus, and now uBlock, for at least 8 years. So I'm definitely not arguing against it.

It's just that in _theory_ , an ad tracker (like a 1 pixel image) does not necessarily have to impact performance. Also note that some ad blockers add performance overhead themselves.

<comment><USER14> >A lot of the ad JS I see is in the form of inline script tags, which generally should not block anything (the JS usually asynchronously constructs another script tag, which shouldn't impact performance).

Well, it does impact performance, even if it's async. The pipe is only a finite width (especially on mobile).

</comment></comment></comment></comment></comment><comment><USER15> [https://github.com/netty/netty/tree/master/example/src/main/...](https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http2)

[https://wiki.mozilla.org/Networking/http2](https://wiki.mozilla.org/Networking/http2)

</comment><comment><USER16> Will this affect the way we do AJAX requests? Or the speed of them? Or has this no impact on websites talking back to the server? My knowledge of networking at the HTTP level is limited and I am trying to find some context.

<comment><USER17> From source:

"What does this mean for developers?

HTTP/2 was designed from the beginning to be backwards-compatible with HTTP/1.1. That means developers of HTTP libraries don't have to change APIs, and the developers who use those libraries won't have to change their application code. This is a huge advantage: developers can move forward without spending months bringing previous efforts up to date."

</comment></comment><comment><USER18> Why is it limited to operating system version? Shouldn't it be a browser feature?

<comment><USER19> (Disclaimer: I don't work for MS, so this may not be entirely accurate anymore.)

It's probably because IE is really just a UI wrapper around system libraries[0]. The changes for HTTP/2 would be made not in IExplorer.exe, but instead in WinInet.dll (and possibly URLMon.dll).

This is because IE isn't the only application that will use these new features.

EDIT: I should add that you don't just go changing system libraries in a patch Tuesday, you'd wait and throw them in a new version, hence the 10 preview.

[0] [http://msdn.microsoft.com/en- us/library/aa741312.aspx](http://msdn.microsoft.com/en- us/library/aa741312.aspx)

</comment></comment><comment><USER20> DDOS future blackmailers are happy: a new leverage for amplification :)

I want that so bad. Coding is hard, DDoSing is so easy.

Thank you architects for making black hats life so easy. HTTPS by default? YEESS even more leverage.

I love progress.

Next great idea: implementing ICMP, UDP, routing on top of an OSI layer 7 protocol, because everybody knows religion forbid to open firewall for protocols that do the jobs, or we could even create new protocols that are not HTTP. But HTTP for sure is the only true protocol since devs don't know how to make 3 lines of code for networking and sysadmins don't know how to do their jobs.

And HTTP is still stateless \o/ wonderful, we still have this wonderful hack living, cookies, oauth and all these shitty stuff. Central certificate are now totally discredited, but let's advocate broken stuff even more.

Why not implement a database agnostic layer on top?

When are we gonna stop this cowardly headless rush of stacking poor solutions and begin solving the root problems?

We are stacking the old problems of GUI (asynch+maintainability+costs) with the new problem of doing it all other HTTP.

I have a good solution that now seems viable: let's all code in vanilla Tk/Tcl: it has GUI, it can do HTTP and all, and it works on all environment, and it is easy to deploy.

Seriously, Tk/Tcl now seems sexy.

</comment><comment><USER21> It looks to interesting to see Microsoft adopting standards as earliest player in the field

</comment><comment><USER22> Could somebody elaborate how server push relates to web sockets (if at all)? Are they completely independent and will both be supported or does one build on the other?

Given that the web is becoming more and more real-time this seems pretty interesting.

<comment><USER23> server push just means that when a server sees a request for index.html, it can serve index.html and also index.js and index.css without those being requested, and when your browser parses the html and discovers it needs the js and css, they are already in cache and are fresh enough to use, which saves the round trip latency and might enable a mobile radio to go to sleep earlier.

<comment><USER24> What if the browser already has those in the client cache? Will it have to abort the pushes, and will it even be able to do so in time on a high bandwidth high latency network like 3g/4g?

Is there a risk that cellular data usage will increase from this?

<comment><USER5> Yes there is. Knowing when a client has a resource cached already is an important part of server push. There is indeed a risk of over pushing.

</comment></comment></comment></comment><comment><USER25> Is there a http/2 test page out there that shows if you are connecting with it?

Found this project but nothing live

[https://github.com/molnarg/http2-testpage](https://github.com/molnarg/http2-testpage)

</comment><comment><USER26> So this terrible NIHy Rube Goldberg contraption does actually get to see the light of day.

I'm saddened. The days of good internet protocols are clearly behind us.

<comment><USER5> What in particular is bad about HTTP/2? Complexity can arise in protocols for multiple reasons. In this case, security and correctness are more culpable than anything else. That is, if you want to design something similarly performant, you are going to run into a lot of the same issues (flow control and priorities for fairness, issues with gzip compression, and so on).

<comment><USER26> _What in particular is bad about HTTP /2?_

At the risk of sounding too blunt: Everything? All of it? Its mere existence?

It fucks up responsibilities by addresses network-layering issues at the application layer. It takes a simple & stateless text-mode protocol and converts it into a binary & state-full mess.

It has weird micro-optimizations decided to ensure that Google's front-page and any Google-request with its army of 20000 privacy-invading tracking cookies should fit within one TCP-packet using American ISPs MTU packet-size, to ensure people are not inconvenienced when their privacy is being eaten away at. Which I'm sure is useful to Google, but pretty much nobody else.

The list goes on.

It does a lot of things which is not needed nor asked for by the majority of the internet, and yet the rest of the internet is asked to pay the cost of it through a mindboggling increase in complexity, and I'm sure a source of a million future vulnerabilities.

I'm not aware of a single thing in there which I want, and if I'm wrong and find one, I'm unwilling to accept that this is the cost I have to pay for that feature.

Any web-browser I will use in the future will be one where HTTP/2 can be disabled.

<comment><USER27> > _It has weird micro-optimizations decided to ensure that Google 's front- > page and any Google-request with its army of 20000 privacy-invading tracking > cookies should fit within one TCP-packet using American ISPs MTU packet- > size, to ensure people are not inconvenienced when their privacy is being > eaten away at. Which I'm sure is useful to Google, but pretty much nobody > else._

Could you elaborate on this, please?

<comment><USER28> I assume josteink is decrying the fact that header compression is used, which is a pretty ridiculous complaint.

</comment></comment></comment></comment></comment><comment><USER29> Its way more complicated. But I guess it has to happen.

<comment><USER30> No, it really doesn't _have_ to happen. Some people are just pushing it through because ~reasons~.

<comment><USER5> Reasons being increased performance and security.

<comment><USER30> Security? You mean, like the trusted proxy stuff? Or the increased performance, which doesn't benefit you so much if you include lots of random shit from other domains (like most people do anyways)? C'mon.

</comment></comment></comment></comment><comment><USER31> Do not want</comment>


How to Flunk Philosophy: or Here we go Again - <AUTHOR> http://www.partiallyexaminedlife.com/2013/08/10/how-to-flunk-philosophy-or-here-we-go-again/

<comment><USER2> Still arguing about philosophy? Who hasn't heard that philosophy was replaced by science over 100 years ago?

And ... how would anyone decide that a particular person had flunked philosophy? It has no fixed, testable content, so there are no right answers, so no wrong ones.

Philosophers talk the talk. Scientists walk the walk.</comment>


Ask YC: Textile vs Markdown - <AUTHOR>

I'm sick of writing html tags. It is a bore, even when using my favorite editors (vim, textmate).
I've been considering the pros and cons of the 2 most popular lightweight markup languages, but can't seem to pull the trigger one way or the other.
I realize that ultimately it comes down to personal taste, like vim vs emacs, but I'd still like some external input. What do you prefer and why? <comment><USER2> Don't forget the costs of using a "lightweight" markup:

You have to learn some new system of quoting and escaping. I don't know textile or markdown, but I just went over to <http://textism.com/tools/textile/index.php> and tried to put a  close tag inside the sample code. It's got problems.

You get approximately one chance at a correct conversion to a richer format: converting to html. Nearly any other conversion, such as from the wrong lightweight markup to another lightweight markup, is lossy.

These markups aren't very extensible. They can't store metadata (e.g. microformats), or if they do, it tends to be by allowing html tags mixed into the markup, which means we're back into quoting/escaping issues.

There tend not to be any WYSIWYG editors, neither for you if you one day want one, nor for a less technical user who you'll someday want to edit your document.

So given almost zero knowledge about your problem, I'd recommend a WYSIWYG html editor. Whichever one you choose, it'll occasionally screw up and corrupt your formatting. Or maybe there will be subtle differences between the preview layout and a final browser layout. If you think those kind of issues will be a problem, then you REALLY don't want a lightweight markup language.

<comment><USER3> Right, it's interesting that you wind up seeing these formats extended with additional complexity, basically reimplementing HTML in their custom syntax, for dealing with the publishing/processing pipeline.

I suggest an editor like vim or Emacs with HTML modes that give you auto- indenting and tag completion key bindings. It's really not that much more work to author straight HTML, and if it's what you're targeting anyway, you'll be happier in the long run when you have to maintain it.

<comment><USER4> No matter what your editor does, editing in HTML is simply slower than writing a Markdown document. You may be overstating the complexity of things like Markdown and Textile.

</comment></comment></comment><comment><USER5> I prefer Textile because I find the linking syntax to be much more intuitive (I can never remember what's in parens and what's in brackets in Markdown).

<comment><USER6> That's interesting, because I've heard that link syntax is one main reason people prefer Markdown to Textile. One issue with Textile-style links is that something like

      "Foo Bar":http://foo.com/bar.

is ambiguous, and the result depends on the parser. It could end up as

      Foo Bar.

or it could end up as

      Foo Bar

The former is probably what you mean most of the time, but then there's no way to link to the (valid!) URL "<http://foo.com/bar>.".

<comment><USER7> So it allows quoted strings on one side of the colon but not the other? Sounds like a bug to me!

</comment></comment></comment><comment><USER8> Since they are so similar, I think it helps to answer a few simple questions:

1\. Do you need something that one has that the other doesn't?

2\. Who's your target audience? Are they going to be writing a lot of markup? If so, considering the syntax differences is more important than say for blog comments where the only likely uses are bold, italic, and link.

3\. How is the library support in your chosen language; are there any quirks? I remember at one point a bug surfaced in py-textile that had something to do with unicode chars so if you were using a lot of unicode chars it was better to go with Markdown.

If I had to pick one I generally like more it would probably be textile, but it's so dependent on the situation that I have no generalized evidence to support one being superior as a rule. If you only want to deal with one, period, I would probably go with Markdown just because, as mentioned, it is more widely used and therefor (slightly) more well-known (also highly dependent on audience) and likely to be better supported lib-wise.

</comment><comment><USER9> For general use, neither, but for personal use, Markdown. Unlike Textile, with its specific syntax, Markdown adapts to various implementations of email syntax (numbered lists actually use numbers, bulleted lists use hyphens or asterisks). Write it like it would look in an email, and it should format nicely.

</comment><comment><USER10> Use Markdown. It works extremely well with TextMate, because all of TextMate's heaviest users and bundle contributors use Markdown. Once you start using it, you certainly won't want to write any non-trivial text document in HTML ever again.

</comment><comment><USER4> Different design goals.

Textile is more expressive. It has more features and does more stuff.

Markdown is more transparent. It's designed to capture the features of a text email message and render them in HTML.

</comment><comment><USER11> Both of them will make you long for the days when you could have just typed in some simple HTML tags.

<comment><USER12> Umm, you can type regular HTML tags in a Markdown document. It parses just fine.

</comment></comment><comment><USER13> I think Markdown is more widely used, but I personally like Textile because it supports one thing that Markdown does not: footnotes. Otherwise, they are basically equivalent to me.

<comment><USER14> Most up-to-date Markdown implementations support footnotes (specifically the Python one does for certain, but the syntax has been around for a while).

The syntax is pretty easy. [^1]

[^1]: And really adds some jazz to blog entries.

</comment></comment><comment><USER15> I've put together a little survey to see what people prefer for markup. Check it out: [http://luciddesign.co.nz/2009/2/9/textile-vs-markdown-vs- tin...](http://luciddesign.co.nz/2009/2/9/textile-vs-markdown-vs-tinymce-etc)

</comment><comment><USER6> I'm a fan of the default syntax offered by [RedCloth](<http://whytheluckystiff.net/ruby/redcloth/>). It's Textile, but with bits of Markdown thrown in, such as link syntax. It's only available for Ruby, though.

</comment><comment><USER16> I think it's fairer to compare Markdown + Smartypants to Textile.

That said, I still prefer Textile, I just like the syntax better.

</comment><comment><USER17> If you use RTL languages like Farsi, Hebrew, ... both of them are kinda useless.</comment>


Rosetta probe disoriented by comet dust - <AUTHOR> http://spaceflightnow.com/2015/04/05/rosetta-probe-disoriented-by-comet-dust/

<comment><AUTHOR> Another article on this topic: Scary times for Europe's comet-chaser Rosetta

[http://phys.org/news/2015-04-scary-europe-comet-chaser- roset...](http://phys.org/news/2015-04-scary-europe-comet-chaser-rosetta.html)

Sounds like they might have to stop flying the spacecraft through the comet's dust tail.</comment>


Bitcoin: The Living Room Revolution - <AUTHOR> https://hackernoon.com/bitcoin-the-living-room-revolution-9acdf521295e <comment><USER2> Can we filter posts like this please...

This is bordering on religious propaganda...</comment>


Domain-Oriented Microservice Architecture - <AUTHOR> https://eng.uber.com/microservice-architecture/ <comment><USER3> > In other words, organizations adopt microservices for an operational benefit > at the expense of performance.

...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths.

Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. Microservices are a way to release that organizational/logistical friction, at great technical cost.

With that said, the domain-oriented bounded context is indeed the right way to think about service delineation.

<comment><USER4> The last company I worked for was very much an "API first" company. We were a B2B company and our APIs were used by our relatively lightly used website. But they were also used for sporadic and large ETL jobs when files from customers came in and most importantly we sold access to our APIs that were used for our customer's mobile apps and heavily trafficked website.

We went microservices for the canonical reason you should - to be able to release and scale independently.

<comment><USER3> That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.

<comment><USER4> How is it a "presumed" benefit when we actually did sell access to our APIs to clients? Some of our APIs initially had very low usage during the day until a batch job came in, others saw a spike in usage by over 100% when we bright a new client in.

We were used by health care networks. Can you imagine the increased use post- Covid?

We even had some that were both hosted on Fargate (Serverless Docker) with lower latency, more expensive but slower scaling for online use and hosted on Lambda for internal batch use - higher latency, faster scaling, less expensive for batch use. The CI/CD pipeline deployed to both.

<comment><USER3> My point is that you don't need to rearchitect your application in an entirely different style to be able to scale in response to load.

<comment><USER4> If only part of your "application" has more load than others what do you suggest?

That instead of being able to granular take part of the application that had a larger load, and run it on a Firecracker micro VM (the underlying VM for lambda and Fargate) with 256MB RAM and 1 core, we add enough VMs to scale a monolithic app - even the parts that don't need it on a full scale VM with 8GB RAM and four cores?

We did actually have to do something similar for a legacy Windows app. We scaled the entire process up based on the number of messages in the queue. It was extremely wasteful. It required at least a 4GB/2 CPU VM compared.

<comment><USER3> Scale the whole thing. The cost of doing that is usually orders of magnitude less than the true CapEx and OpEx of microservices.

edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.

<comment><USER4> We are talking about a 16x difference in resources. Would you also suggest scaling a database that was more read heavy than write heavy instead of splitting reads and writes when you can deal with eventual consistency and just autoscale the read replicas?

<comment><USER3> The comparison is not equivalent.

<comment><USER5> Agreed, I think the comparison is not equivalent,

because a read replica actually is the same database application (same "monolith") just started with different parameters, to behave as a replica

<comment><USER4> The database is the same but you have to then separate your code into reader and writer services with different connection strings, you have to make sure that anything that can't be eventually consistent uses the writer connection string, etc.

It's not just a matter of spinning up a database.

Also, since many enterprise apps live stores procedures and putting business logic in the database, that's another ball of wax you have to untangle.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well.

I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take to building services. All the material I've read seems to point in the direction of services being ideally coupled to domain boundaries.

It seems to me that Uber's services proliferated beyond the framing of bounded contexts, and DOMA is their attempt to reign it back in again. I think it's an excellent strategy, and arguably a very good approach for other companies who find themselves in this position.

I don't think DOMA is a good place to _stay at_. The network should only be tolerated as long as it provides benefits that outweigh the costs. "Monolith" is not synonymous with "poor design". Seeing that these enclaves of services sitting within a domain depend on eachother in the way the OP describes, it really makes me think that they'd find further benefits by expelling the network from each domain.

<comment><USER7> > The network should only be tolerated as long as it provides benefits that > outweigh the costs.

I agree. There should be no need to use network calls to enforce interface boundaries if you have a cohesive bounded context.

Or to be snarky about it, welcome to 2004 Uber! Eric Evans sends his regards!

<comment><USER8> Unfortunately, picking and enforcing bounded contexts is hard work in a big organization, even with strong code review processes.

There will always be people who don't want to respect where the boundaries are drawn (not in a constructive, "it could be better" kind of way, but in a "but this works, too" kind of way). If a group of such people get together, microservices compartmentalizes their capacity to drag down the ship, so to speak. I think this risk compartmentalization is a benefit that must be weighed against the costs (in terms of latency, maintenance of shared libs, opentracing, etc). These days the costs are vanishing, as tools are quite good and becoming easier to manage.

All that said, if you're a small team of senior engineers working with a shared mental model, a single binary with internally-bounded contexts works really well and I agree with you, having seen it done well.

<comment><USER7> I was lucky enough to be in the right place, at the right time, to lead a group that scaled this approach across half a dozen different development teams.

Fortunately everyone bought into the architecture, and respected the boundaries. Not everyone was senior, and not all the code was great, but we adopted the viewpoint that so long as the bad code is in the right spot (and not talking to things it shouldn't) everything would be ok in the end. And it was.

Half a dozen teams working in one codebase was definitely pushing it though, and the need to scale much beyond that would have definitely required some service-level compartmentalization to keep the ship from sinking, as you said.

Even then, it would still be a far cry from the "microservices should be small enough to re-write in 2 weeks" approach.

</comment></comment></comment></comment><comment><USER9> I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths.

I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go?

Side note, I can't wait to hear my boss use "DOMA" in a meeting in the coming months. FML.

<comment><USER10> Sun RPC marketing message, "The network is the computer".

So yeah, we keep going at this, and then people discover that monoliths written in a correct modular way, with libraries, happen to be easier to debug and reason about without a network in the middle.

Main problem seems to be that not many developers bother to read about modular programming, large scale development (like Lakos books) and what features their language of choice offers for such endeavours.

<comment><USER11> Are you sure that was just a marketing line for "RPC"? I thought the scope was broader.

IMO Micro-Services were addressing the skill gap in designing comprehensive schemas, not so much the object layer between user and data. So not modular "programming" but rather "modular design".

<comment><USER10> Might have been, I just remember it from being printed somewhere on the page on the programming manuals.

</comment></comment></comment></comment><comment><USER12> Feels like a lot of old knowledge was discounted / ignored and the mistakes are being rediscovered.

Feels a bit like the Hexagonal Architecture being rediscovered.

Micro service with half life of 1.5 years? Does that mean that enough planning is not being done? Or leadership failure at software planning level?

Collaboration between teams at scale is very hard but that is what the leadership layer is for - to collaborate more not build more micro services.

<comment><USER13> Or how about plain old onion architecture... even older than hexagonal.

This is literally scaled/distributed domain-driven design (DDD).

I have felt strongly that folks got so caught up in the hype of yet another new thing they forgot how to extend what came before.

It feels like a reinvention of existing ideas at larger scale, and a pattern we keep repeating.

I'm not complaining, of course - new things are possible and being learned through this innovation. I do feel we should be more careful on the cutting edge, to see how it relates to where we came from.

Put another way, reinventing the wheel is not pointless if you come out with a better thing, or better wheel. But don't forget what was good about the previous wheel before you throw it out?

<comment><USER14> I'm confused. You're saying that people are reinventing existing ideas at larger scale, but you also are saying that people don't know how to extend what came before? Those sound like the same exact thing.

<comment><USER13> You're not confused, but there is a nuance. I'm trying to walk a fine line of not criticizing them for discovering this late into their process (maybe they knew all along but were busy inventing), but also questioning why they couldn't see this sooner. Trying to get to the heart of what took this innovation/recognition/learning to happen.

I am making an observation - when each new "fad" or "hype cycle" tech starts, it seems as though the pattern knowledge of what came before is discarded, or, disregarded as "legacy" or possibly even just forgotten. It feels like a knowledge transfer is missing. It would be terrible if, we, as an industry aren't passing down knowledge and reinventing hard won pattern discoveries efficiently.

Did this pattern Uber discovered come from studying onion architecture, DDD, etc first, finding the limitations, and then scaling them?

Or did this arise from throwing away everything that came before (or not knowing about it), forging an undiscovered path, and then rediscovering the old patterns could be applied? If the latter, what can be learned to make this process of discovery and linkage to existing patterns more efficient?

I think this article shows innovation is tricky, or, the risk (and potential reward) at the bleeding edge. Leaving behind design constraints of what came before might be necessary.

Maybe I'm trying to say, as an industry we need to balance exploitation of previous knowledge and our attitudes about how we feel about "legacy", with the unquenchable thirst for the next new innovation?

</comment></comment></comment></comment><comment><USER15> I felt bad for Uber engineering force while reading whole article. They swamped themselves into that microservices hell due to pressure for teams velocity and TTM, and created enormous tech debt in the process. Now they are trying to patch it up with ridiculous means like putting JSON inside of protobuf messages. I really hope this article could be a warning for management of growing startups for what could happen if you squeeze features out of your team, but managers usually speed-reading those articles just to order "do like Uber did".

</comment><comment><USER16> I'm not entirely sure why this is sold as innovative new approach. Over the last few years, I've seen and developed micro services that are indeed cut down to specific functionality, and I've done ones where the domain was the scope. The latter has proven to produce bigger services, but a more maintainable ecosystem. Also, the division for micro services should also be dictated by the context of the business, and not just the current whims of the devs.

</comment><comment><USER17> While I work on much smaller codebases and so don't have any particular insight into how DOMA will work for such large organizations, the piece that I really liked here is how the separate their different general layers of services.

The key to any service being usable outside of the exact context it was first written in is to ensure no product specific business logic is added to it.

By splitting out infrastructure from general business from product specific services, you can do a much better job of understanding, and therefore controlling where where product specific logic is allowed. This in turn will make your lower level services far less coupled to the exact context they are first used in.

For smaller orgs, this is by far the more useful information, rather than how to deal with 2200 microservices.

</comment><comment><USER18> Yup. So micro services of micro services. Clearly defined interfaces. Single entry point for other services/domains to interact with. seperation of concerns. The fundamental law will always be true : [https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_softw...](https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering)

</comment><comment><USER19> Somewhat off topic but maybe someone can enlighten me:

> Uber has grown to around 2,200 critical microservices

Even thinking about the very largest systems I've worked on, I can't think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?

<comment><USER20> Hmm, would it be easier to imagine PayPal or Stripe requiring a lot of services? Given its volume of payments, Uber has basically had to re-implement PayPal internally, custom-tailored to its own flow. Companies at this size/scale basically contain multiple whole companies within them. Think of like all the SAAS services that your company relies on, and then imagine that your company now owns all of them and all the services that come with them.

<comment><USER21> Uber uses Stripe and PayPal to process payments. They don't need to reimplement either, and doing so would be a bit of a waste.

It's worth pointing out that not all of the 2200 services may be user-facing. Some may be internal, such as admin tooling or CI services. That said, 2200 seems like a lot!

<comment><USER20> Sorry, I think you are a bit mistaken about how payment platforms work. Stripe and PayPal provide an interface to a country's banks. In exchange for abstracting away the underlying bank infrastructure, you pay them a fee for every transaction. Stripe and PayPal support a limited number of countries and a subset of the bank's functionality. So if you want to interact with any new countries or access any non-supported financial instruments, you'll have to directly integrate with the banks and implement those yourselves. To give you a sense of scale, Uber's payments volume is like 10% of Stripe's.

<comment><USER22> Curious; where did you get the 10% number from

<comment><USER20> Here's an estimate of Stripe's yearly transaction volume at $200 billion [https://www.forbes.com/sites/christianowens/2019/09/21/strip...](https://www.forbes.com/sites/christianowens/2019/09/21/stripe- isnt-overvalued-at-35bn-you-just-dont-understand-twenty-first-century- commerce/)

Here's Uber's announced results of $18 billion in gross bookings [https://investor.uber.com/news-events/news/press-release- det...](https://investor.uber.com/news-events/news/press-release- details/2020/Uber-Announces-Results-for-Fourth-Quarter-and-Full-Year-2019/)

Round that to significant figures and you get 10%.

</comment></comment></comment></comment></comment></comment><comment><USER23> They say they draw inspiration from DDD and CQRS, yet seem to miss one crucial factor. And no, I'm not talking about bounded contexts. They still focus in re-use of commodity rather than addressing why their microservice approach didn't work. Their strategy for defining how functionality moves down the stack is not bad, but it's not anchored towards the right thing. It's the consistency boundary (or aggregate root if you will). It's the circle you draw around your business rules and say "this group needs to remain consistently enforced". This defines your unit of scale, not re-use. So while they are headed in the right direction, I fear that they are still missing a fundamental piece of information to steer on.

I was employed by Uber (I quit after a couple months), and the idea's that they now hint towards were largely rejected by the engineers, and that was less than a year ago. Uber is just in the position to throw a large sum of money at making wrong decisions and getting away with it, because it's not their money. It's VC funny money.

DISCLAIMER: Yes, I did indeed create this account to be able to reply anonymously.

</comment><comment><USER24> I recently read Domain Modelling made Functional [0] and one of the under- recognised benefits of using Domain Driven or oriented designs is that (if done right), _business workflows_ and processes become well explained for developers and minimises surprises from business closer to release dates. For e.g., an order processing system will have lesser assumptions by developers and tech leads because someone with enough knowledge of the business process from order processing will be able to guide you.

[0][https://pragprog.com/titles/swdddf/](https://pragprog.com/titles/swdddf/)

</comment><comment><USER25> I don't like that they _define_ microservices as components communicating via RPC, because this precludes other models like pub-sub.

</comment><comment><USER26> I despise Uber as a company, but I've always loved them as a technology group ever since I used to go to their meetups in NYC. You can always count on Uber to throw a great party and also come up with the worst possible technology.

If you want to know how not to do things, Uber is a very good place to look.

<comment><USER27> And all the people who worked there will consider the fact that they did 1) something and 2) were successful means that that 'something' had anything to do with it, and therefore we should keep doing it.

Not that this is unique to Uber, mind. I just described half of my coworkers too.

</comment></comment><comment><USER28> I'm honestly not trying to be snarky here but I didn't know there was any other way to design microservices (with intention) that weren't domain oriented.

<comment><USER29> I've seen one service per database table, and have had architects seriously think that a table equals a bounded context. Then they try to work out how to do two-phase commit across micro services.

<comment><USER28> Oh that. I've had to merge services like that.

People are always grabbing nouns and thinking they're microservices.

</comment></comment></comment><comment><USER30> Basically clumping microservices

<comment><USER31> I believe this is only the first point. It's also establishing a hierarchy of these "clumps" (layers), strict APIs representing a single clump for other clumps to consume (gateways), and a pattern for clumps to extend functionality of other clumps without polluting their models (extension architecture).

</comment></comment><comment><USER32> > as Uber grew from 10s to 100s of engineers with multiple teams owning pieces > of the tech stack, the monolithic architecture tied the fate of teams > together and made it difficult to operate independently.

I think this is key sentence. Microservices does not make a lot of sense for teams of 10s, while are a great tool for team of 100s.

</comment><comment><USER33> Seems to me that big progress will be made when we can decouple system boundaries from network calls.

<comment><USER34> I still think the approach of baking the entire enterprise into 1 gigantic binary is the best. Stack traces are so much easier to work with compared to distributed logs and side effects.

We are already at a point where you could hypothetically do this for a reasonably-sized organization. A 64 core CPU can support a huge number of clients. Stuff like .NET Core scales really well if you want to build something complex like this. One big binary that occupies an entire physical host is an extremely compelling development model. Literally everything becomes a direct method invocation. You can also have type enforcement and atomic releases for the entire enterprise. Also makes a monorepo an obvious choice for source code management.

<comment><USER35> This falls apart when you care a lot about availability and therefore want a particular service to be stateless. Then you add some feature that needs a tiny bit of state and suddenly you can't scale up and down as easily and need to start paying attention. This rolls forward into a big ball of mud - <USER2> monolith can be tricky too at scale

<comment><USER34> One trick is to leverage the fact that you have 1 type domain, and to develop a common persistence abstraction for the entire enterprise. Then, all of your business entities can be pushed through it for a consolidated replication flow. This can be [a]synchronously replicated to additional node(s) as required, potentially with replication rulesets defined in application code as well.

It sounds like a complex monster until you build it one time. Then you are basically done. The leverage you get when you have 1 way to do everything is extremely powerful. I do recognize there are scenarios where you cant force one persistence abstraction on all use cases, but there's no reason you couldn't have a TimeSeriesEntity (keyed by time) in addition to a typical BusinessEntity (keyed by a unique integer). Both could have unique replication implementations, but it would still be standardized and all nodes would be speaking the same protocol because they all derive from the same source.

The monolith only remains a monolith in operational terms until the engineering team develops some imagination.

</comment></comment></comment></comment><comment><USER36> Very interesting and seems like a logical next step with things get a bit too messy with micro services.

One thing that was not touched on - how is security done in DOMA?

* Is auth happening at domain gateways or at each service?

* Similarly for encryption, does it terminate at Domain GW or at each service?

<comment><USER37> Hopefully both

</comment></comment><comment><USER38> Nice to see Uber rediscovering domain-driven design principles.

</comment><comment><USER39> If you can't make a monolith work, then you will fail even harder trying to make a Microservice Architecture work.

</comment><comment><USER40> Microservices are about scaling teams, not tech.

</comment><comment><USER41> Uber thinks they only have that many services? Yikes, double, or triple the number... several years ago. Maybe they have fewer now?</comment>


Save Forbidden Planet NYC - <AUTHOR> https://pluralistic.net/2020/04/24/slicey-boi/#union-square <comment><USER2> The whole "donate to local business" trend is perplexing to me.

I know some folks who are collecting donations for local bars in the area. It sounds noble right?

But then think of the reverse of this situation. Let's say times are good for the bar and I lose my job, as a loyal regular at my favorite bar. Will they pour me drinks and serve me food for free until I get back on my feet?

Nope! They sure won't. Maybe I'll get _one_ on the house? But that's about it.

Ultimately, it's not our responsibility as customers, and it's not even remotely practical, to make sure everyone surrounding us has planned for fiscal emergencies. Nobody's donating to my savings account to support my three to six month emergency that every financial expert recommends. Why is this different for small businesses?

Why can't these businesses hang on for a few months when they've now got zero payroll and likely have a lot of leeway with their landlords and mortgage lenders? (I'm not saying it's easy)

A small business without that basic emergency fund is going to inevitably go out of business, isn't it? COVID-19 just accelerated the process.

And much as I don't like the big chain stores taking over the cool hip trendy local weirdness, I also think there's a very clear demand for that sort of thing. The corporate scapegoats outlined in the article weren't really responsible for any of this, they're just sort of thrown in as an emotional appeal.

And the whole idea of "these stores used to be everywhere, now they're a dying breed" emotional appeal should apply equally to Sears and Macy's right? Should I donate to them as well?

<comment><USER3> Are you willing to pay 2-3x for your drinks at the local bar? If not, there's your reason why they don't have 2-3 months's cash stockpiled.

I own minority shares of several restaurants. I have zero management control, roughly 1% equity in each restaurant. But I get full insight into their books, revenues, costs. All three are profitable, each returned my capital investment in under two years, each pays me roughly 20% return every year on my investment.

Each has (well, had) about 6 weeks' cash on hand at the start of the shutdown here in mid–March. Each had a line of credit good for roughly another month (in theory). But in practice the LOC is used to balance out month–to–month expenses and revenues. Some months the liquor has increased 5% over last month for no apparent reason and no, you don't have much leeway to renegotiate as there's only two distributors in the area. So the LOC has already been tapped, not necessarily maxed out.

Oh, and funny thing, banks have been trimming LOC limits to whatever you've drawn already. If you had a $15000 LOC limit in February which you'd drawn $5000 on for expenses, your bank trimmed the limit to $5000 in March.

Each restaurant in a typical month breaks even the third week of the month and is profitable the last week of the month. In reality they lose money for a couple of months of the year but that's balanced by higher profits other months of the year.

In normal business times it all balances out.

Right now isn't normal. Employees are demanding to continue getting paid, vendors demand to get paid, the landlord wants his damn rent, and all of the cities which are demanding that you pay your employees and not lay anyone off? Yeah, they're demanding that you pay your various taxes.

And there's no revenue. None. You try take out and lose money every night because not enough people are buying alcohol (which is where you get your profit on an average night). You don't want to go down the Grubhub/Seamless route because of the vig they demand.

So you close your doors "temporarily".

There's no "unemployment insurance" for businesses. There's business interruption insurance, but, surprise, insurance companies are slow walking responding to and validating claims (and AFAICT they've rejected all claims for these restaurants and anecdotally none of the other small businesses I know have been able to get any insurance payments).

So…everyone's demanding money, no one's paying. You can either try these gofundmes, or close.

In my case all of the restaurants are planning to fire employees, sell off inventory, and close. They ran numbers about recapitalizing but since there's no clarity on when restaurants can return to normal (and I mean truly normal, not 50% seating reduction, because that doesn't work unless you can increase prices by 50% or more) — without clarity on how long this continues, it's more pragmatic to conserve cash, close the business, and reopen if/when normalcy returns.

<comment><USER2> Like I said, it's all been exposed as the house of cards that it is. Your enlightening information on the way the restaurant industry works doesn't really make that mode of operation sound very good.

And like you said, your investment as an owner has returned 20% every year. Where does that go? Those kinds of returns are unheard of if I were to stick that money in an index fund.

So, business owners want to have their cake and eat it too - they want the reward (20% return on investment yearly) without the risk. The business closing is the risk.

Which goes back to my original point, which you didn't address: why does any of this situation make it in the customer's interest to spend their own cash on protecting someone else's for-profit business? Will the customer get a slice of that 20% yearly return on investment?

Literally donating to your boss is now being seen as a noble pursuit.

As a household it'd be completely insane to operate on a six week runway - though I realize that potentially _most_ Americans do. Still, those Americans have unemployment insurance and they have the ability to take up other jobs.

Maybe some more restaurant owners will figure out that basing profit solely on alcohol and running on lines of credit was a bad idea in the first place. Maybe restaurant prices will go up. Maybe restaurant prices are set too low in the first place - because more restaurants exist than need to. Most people are better off cooking food and making their own drinks - to answer your question on whether I'd pay two or theee times more for my drinks at the bar: I was pretty sure that's what I was already doing when I went to the bar.

<comment><USER3> It's all economics. Restaurants only exist because there's a market for them. The customer gets the product they pay for. If the market goes away (as it has), the businesses will go away. If people are willing to pay more, then some sort of business will return to fulfill that market.

And…this is capitalism. You seem to think capitalism should be something different. At its base, capitalism is I provide a product or service that you want, and it's cheaper (from your perspective) to buy it from me than build it / raise it/ create it / whatever yourself. We've been conned into believing capitalism is entirely something else, it's stocks and bonds, and going public and creating third order derivatives to shift risk onto some unsuspecting entity seeking higher returns.

20% return sounds awesome, right? It's about $1000 a year. The entire capitalization of a given restaurant (of the size/style I invest in) is about US$350,000. That's enough to rent, build out, and equip the space, pay for all the various fees, hire the initial crew and initial marketing. If they're successful they start paying back the investment in about a year. IF they're not successful 1) I lose the money (that's the risk) and 2) they typically fail fast, within 60-90 days of opening.

I had one restaurant that opened to great fanfare mid–2012. In October it was flooded due to hurricane Sandy. It never reopened. Another six months it would have been on better footing, but that first year you're upside down in debt and the insurance companies know that if they drag their feet long enough the business will be forced into bankruptcy by creditors who will settle for a meager distribution from insurance.

I mostly know about restaurants and software companies and…while software companies have more flexibility right now, I don't know of any small company that just hoards a ton of cash as a routine business practice. Your investors will demand that it get distributed as part of regular dividends or a special dividend. If you're public a "shareholder activist" will buy the minimum amount of shares necessary to make a shareholder action to divest the cash or replace management.

The entirety of small business in the US is you raise some money some how, you open the business, you pay off your debts and investors, and enjoy the profits (if any) or you close. If you (again, as a small business, and not someone with access to capital markets) were to bank 60-90-120 days of operating cash and your creditors or investors learned that, you'll be turfed out of your company, or lose access to credit and investment, or a combination of both.

And to your point: you're right, the customers could (and likely will) let the businesses fail. And then they'll blog and whine about how "My City has Changed!" and why are all restaurants now variations on Taco Bell.

Honestly, I don't see any of the restaurants I'm invested in reopening. I'll be out roughly US$50k. About 180 employees will be out of jobs. And it's not because no one donated to their gofundmes, I just don't think it's a viable business in a Covid-19 world.

I think there will be some sort of restaurant experience post Covid, but it'll be split between low end fast food take out/delivery and high end ($100/pp or more plus drinks). Barring widespread testing and/or a vaccine, the local diner, restaurant, hipster mayonnaise fetish joint, is dead.

<comment><USER3> I mean, you seem to be taking the position that all should have prepared for the extremely unlikely scenario that the entire economy of a region would shut down for weeks if not months at a time, and if businesses failed to prepare for that then they deserve to close. And that's fine and all, but that's 100% contrary to the standard way small businesses in the US have operated. Any business hoarding cash for such an unlikely scenario would be relieved of that hoard of cash through one absolutely legal method or another, it's the American way.

|reply tagged to my own post by mistake.

<comment><USER2> No, I'm not taking the position that any business deserves to close due to an extreme scenario. My position is that it's absolutely normal for the business owner to shoulder that risk - 1/5 of small businesses fail in the first five years, right? So the whole idea of donating money to save a business is a illogical when they are expected to fail.

I'm very simply taking the position that donating to for-profit businesses is almost never a noble cause, even if it is a "mom and pop," and that I'm confused why people are doing this when they should be more worried about their own finances, worried about their own job security, etc. With all respect to you, I think your responses are just taking us down a lot of tangents to my original point (I've admittedly followed you down that rabbit hole). I can't find in your responses where you directly address why someone should donate to a for-profit business, especially when these donation funds are often managed by the owner.

The root question is this: why should an individual donate to any particular small business at this time? How would donations have any chance of rescuing a business compared to a fully operational business? Why would anyone donate to the business ownership class over something like a local food bank or even just directly giving money to their unemployed friends and family?

And despite your explanations of how the restaurant industry works, I still don't think the story adds up. I don't think the city is knocking down doors for tax money. Businesses don't pay taxes on losses. I don't think commercial landlords expect to get paid right now and I don't think they're evicting just yet when there's no business to replace the evicted. They have incentive to negotiate. I don't think restaurants have to pay suppliers for supplies they aren't getting. And they certainly don't have any obligation to pay their 100% hourly tip-supported staff.

<comment><USER4> False dichotomy: you can do both of course.

And in my state, a food producing state, the food banks sell off their excess inventory to anybody willing to pay dime on the dollar (Scout events, festivals etc) because cash is more useful to them.

Never mind noble; it can be selfish to wish a favorite restaurant stays in business. Discretionary income is exactly that, to be spent at your own discretion.

We could all quit restaurants entirely and spend every waking moment collecting and donating to food banks etc. But we don't. It's not essentially different from the previous comment (false dichotomy) to say that. And of course we don't do either one.

<comment><USER2> The food bank thing is just an example. It's an example of something worth donating to: a non-profit charity organization that can redirect funds to help people in some way.

So yes, you can do both things. You can donate to whatever you want.

My whole argument here is that donating to a for-profit business is never noble and never logical. If you give money to a for-profit entity you should either receive a product, service, or ownership stake in return.

Again, my whole argument is that this crisis has made many people in an act of group-think start considering donating to _for profit_ entities, especially ones that frequently churn in the first place, to be a desirable action. It's not, full stop. Nobody should do it.

Another example: my gym has an option to continue paying dues to support their "employee relief fund." But the owners of the gym administer this fund. How do I know it won't be used for profit? It's not a 503(c) organization. The owners could just keep 90% of it and give 10% to the employees and that would be perfectly legal.

So it's the same thing with all of these hastily-arranged informal restaurant/bar donation funds. There's no oversight, there's often not even an official organization that's behind them.

<comment><USER4> I patronize three small mon-and-pop restaurants. I'm supporting my neighbors. Where does that fit in this utilitarian view?

<comment><USER2> It completely fits in.

You wouldn't patronize your mom-and-pop restaurants if they burned your food or charged $30 for a box of Kraft Macaroni and Cheese. You also say the word "patronize" which means you receive a service or good in return for your payment.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


C-Corp or LLC as Foreigner? - <AUTHOR>

We are a business based in Europe, and we decided to etablished a new branch of our business in US next year. (to attract more potential clients) I read a lot on the subject, and as a foreigner, two choices come to my mind: C-Corp and LLC. Thing is, I really don't understand which one have the most benefits, as we are just two employees in Europe, and will maybe get 3 more over US (delocalised over US Territory, no actual office).
All the US business will be handle in US meaning revenue and taxes will be paid overthere.
For this purpose, we are also looking to determinate the best location for our company. I heard a lot about Delaware, Nevada and Wyoming for taxes reasons, is this where I should be looking at ?
As you guys have more experience over company creation I was wondering if you could help me or if you could point me to someone who could help us to put something in place.
I will go back to my research Thank you guys. <comment><USER2> Titusak -- I am a US-based business attorney and I can help out, or at least help answer some questions. Please post your email address I'll get in touch.

</comment><comment><AUTHOR> Thank you jayess, let's keep in touch.</comment>


Ubiq: A Scalable and Fault-Tolerant Log Processing Infrastructure (2016) - <AUTHOR> https://ai.google/research/pubs/pub45805 <comment><USER2> Let me take this opportunity to say I'm appalled all research at Google has been rolled into "AI." Ubiq has nothing to do with machine learning, but you can't access it without wading through a swath of Google-branded AI marketing material. The domain research.google.com now redirects to ai.google. If you want to search for _any_ research publications by Google employees, you will be searching on a domain that first and foremost highlights the AI research teams. In a particularly egregious example, all quantum computing research has been filed under "Quantum AI." The "Recent Publications" section exclusively highlights machine learning research despite there being more recent research by other teams. I can go on.

In my opinion, this move threatens the scientific integrity of Google's research. It's clear that researchers in distributed systems, fundamental theory, security and privacy, networking, language development, etc. are second class citizens. I wouldn't be surprised to learn that there's organizational pressure to inject machine learning into as many publications as possible, even if it dilutes the overall diversity of research.

<comment><USER3> It's not just research. Android improves battery by 30%, no one bats an eye. But 1/3 of that improvement is thanks to machine learning - off to the Google IO we go!

30% and 1/3 not the exact real numbers, just showing a concept.

</comment></comment><comment><USER4> > It also guarantees exactly-once semantics for application pipelines to > process logs in the form of event bundles.

Well, it's got my attention.

<comment><USER5> FWIW Kafka 0.11+ supports exactly-once also.

</comment></comment><comment><USER6> huh...I interviewed with Google about 4-5 years ago and one of the interviewers spent a bunch of time asking me questions about something just like this, but from a "theoretical" perspective.

Pretty interesting to see this actually happen and see where Google ended up with it.

</comment><comment><USER7> I wonder if the name is a nod to Ubik by Philip K. Dick

<comment><USER8> That too is what I thought of. Though in the book the product is of dubious quality and constantly changing what it promises. So it's hard to be believe someone thought it a good idea to associate their product

<comment><USER9> I think you may have misinterpreted what Ubik is in the book. It's not a product, and it seems to be the manifestation of some kind of creative force that negates entropy. The commercials quoted in each chapter are not real commercials in the book.

</comment></comment></comment><comment><USER10> Published in 2016

<comment><USER11> Thanks! Updated.

</comment></comment><comment><USER12> The most scalable, fastest reaction time and simplest log processing tool is awk.

<comment><USER13> Ok, I'll bite. Most scalable, you say. I have 250TB of Django logs, how do you recommend I use awk to process them to determine the 99th percentile response time that's faster than using SparkSQL?

<comment><USER14> SparkSQL doesn't support gz. Are your logs splittable on a file-by-file basis or are they in gz format?

Where are your logs stored? Is that a distributed storage? Will SparkSQL not eat all of the bandwidth of it's ethernet interfaces?

Yeah; sure.

<comment><USER13> It's not so much that SparkSQL doesn't support gz as that gz is slow because you can't parallelize the reads. Regardless, parquet format in hdfs so yarn can allocate containers local to the chunk to be processed. Scales nicely.

<comment><USER14> Yeah, but you are making an assumption I've got these 350Gb of logs in HDFS format. Which takes time to set up.

<comment><USER13> Not really, you said SparkSQL doesn't support gz, which is incorrect and the thrust of my comment. The anecdote about parquet is orthogonal to gz support.

pedantic sidebar: hdfs isn't a file format, it's a distributed file system layered over a traditional on-disk filesystem. For example you might have: json logs, in a gz-formatted file, tracked in the hdfs filesystem, stored on disk in an ext4-formatted filesystem.</comment></comment></comment></comment></comment></comment>


Lost backstage at the O2... LonDumb Part III - <AUTHOR> http://trickaduu.com/2012/12/21/londumb-part-iii/

<comment><USER2> Good read!I never heard of a triple A ticket before. How did you manage to get that?

<comment><AUTHOR> Connections, the only way to go!</comment></comment>


Computer knowledge 'undervalued' - <AUTHOR> http://news.bbc.co.uk/2/hi/business/7143417.stm <comment><USER2> Of course most companies value initiative. Typical corporate culture makes it a scarce resource.</comment>


Ask HN: Company wants to aquire my website. Can you give me some advice? - <AUTHOR>

A company has been interested in acquiring my website and I'm looking for some advice from the HN community.
They turned down my initial offer, but expressed interest in negotiating a deal where they pay less up front and then continue to pay me based on growth. I would continue to work on the website and be paid as a contractor.
My website would become part of their large network of high traffic websites and through cross-promotion they say they could drive a lot of new users to my site, which I don't doubt, as my site fits in very nicely with their network of sites.
I'm looking for any examples of how a deal like this could/should be structured. Obviously I'm not going to be paid based on a percentage of pageviews, indefinitely. Should I propose we set up a number of traffic milestones and be paid when a milestone is hit? I understand it's hard to give advice without details, but some general advice and precautions would be very helpful. Has anyone here done a deal like this before? <comment><USER2> This is a shit deal.

What they are essentially doing by tying your pay to the growth of the site is _pushing all of the risk onto you_ , and you're getting NOTHING in return for assuming the liabilities that come with. If they don't have the cash on hand to pay your full asking price upfront and instead want to pay it in installments (with interest, of course) then that's fine: they assume the risk of their purchase and operations, as well they should. But that's NOT what they're asking. They're asking you to do it.

edit: For example, say a month after they acquire your site, the company decides your site and only your site is going to start running huge, 45-second flash video ads for all incoming traffic. Why just you? Because they've invested far less time and money in your brand than their others. You get to be the guinea pig for their stupid business plan ideas because you're the most expendable. Wham. You're fucked, they're not.

<comment><USER3> Agreed. Also why did you make an initial offer?

People have debated the merit of "he who says a number first loses" on HN before, but in general there is a lot of truth to it. If they are interested in purchasing, show them whatever info they need and let them make YOU an offer. The final price can only go up from there.

<comment><USER4> Agreed, if you make the first offer you should only be going big. You think $10k is fair, offer $20k.

I remember my father-in-law was at a garage sale and saw a tub full of barely used golf balls (better than the ones they sell in walmart at a stupid price like $12 for 15). He asked 'how much?'; she offered $10, he countered with $5 and she took it. We counted them, it ended up being 300+ golf balls. He would have been more than happy to pay $1 a dozen and consider it a steal ($25 for all the balls - like $240 for worse condition balls in walmart) _without_ the rubbermaid container; he got that for free.

You don't want to be the person selling your company for $50,000 when on the straight market it would be going for $500,000.

<comment><USER5> This example demonstrates value of asymmetry of information when making a deal, but not "don't make first offer" principle. Obviously the lady was ignorant to the true value of the balls, as any non-golfer would.

<comment><USER4> It wasn't that she had a lack of access to the information (IE a non-golfer randomly acquiring the balls), he husband was an avid golfer and she said her son was semi-pro. She simply didn't care to get the information before selling a product, which is another lesson entirely.

</comment></comment></comment></comment></comment><comment><USER6> Assume that any money that is contingent is not ever going to be paid. Get enough upfront that you wouldn't feel ripped off if you never got another dime. Shit happens and they'll be in more control than you.

To ensure the highest possible chance of getting the rest of the money have it put in escrow. Structure it so that the escrow service pays out the money according to a very simple metric. Using Google Analytics is probably a reasonable method, as it's a third-party and not open to _direct_ manipulation.

If they're not willing to put the money in escrow that's a huge red flag that they're expecting not to have to pay it out. Accept no excuses on this point, increase the upfront payment accordingly, or don't accept the deal.

<comment><USER7> _Using Google Analytics is probably a reasonable method, as it's a third-party and not open to direct manipulation._

It's easy to manipulate Google Analytics numbers downwards (as the company would want to do): Remove or break the javascript.

<comment><USER6> This is why you have a lawyer write the agreement. They're really good at covering this kind of stuff.

</comment></comment></comment><comment><USER8> It is very hard to give you any advice due to the vagueness in your post. Personally, if its < 100K deal as it _sounds_ from your post, I'd just want the cash without any future commitment. You say they want you to work as a contractor - what if you quit the next day?

Bottomline: if it is a tiny deal, figure out a fair value for your site, get the cash, work for them without any longterm commitment so you can quit tomorrow if you'd like.

When I sold a site in high school for 5 figures, I was so over it the next day. That would have been a problem if I'd made a commitment to stay and maintain.

You say they turned down your initial offer. I was expecting the other way around. I know when I got the initial lowball offer, I multiplied it by 5. I sold it for 4x the initial offer.

</comment><comment><USER9> Read "Bargaining for Advantage" as soon as you can - it'll give you incredible ideas for how to frame your arguments, and how to creatively negotiate a better deal for both you and the acquiring company.

Do you have a lawyer who understands internet companies / startups? I'd highly recommend finding one to counsel you, because you run a high risk of having the acquiring company's lawyers taking advantage of you without you realizing it.

</comment><comment><USER10> Did they approach you or did you approach them?

If they approached you, you're in the drivers seat, set a good cash price up front and do not rely on any money after the transfer has taken place. If they don't take that walk away. They'll be back, or someone else will be or you'll be left running your own business. Either of those are good.

If you approached them then maybe this is not the right party for you. Walk and try elsewhere. If you keep getting shitty deals focus on improving your product, grow the installed base and if you can start making inroads on the companies that you looked at to buy you out.

</comment><comment><USER11> They want your product!!!. You set the rules unless they see that you are craving for a "little" money.

They want you website because they are going to earn profit from it (trust me the company looking to acquire already analyzed the possibilities) Don't forget that!!!

</comment><comment><USER12> This is about a company, but it sounds like something right up your alley: <http://news.ycombinator.com/item?id=1639523>.

</comment><comment><USER13> I think you're possibly getting taken for a ride here.

You can take either A> Convertible Debt or B> Non-convertible debt.

Convertible Debt would be you agree to some smaller payment, with an option to convert the debt payments into a certain amount of revenue share if it does in fact work out very well. Non-convertible debt would just be payments over time. But in neither case should you take this currently offered deal.

</comment><comment><USER14> You really need to provide much more detail about the type of site you're running, how/if it makes money, whether you're comfortable working as a contractor for the larger company, etc.

Also, know that traffic milestones are way too easily taken advantage of (inflation and deflation of numbers is very simple in practice) -- I would suggest coming up with another way of tracking your growth than by pageviews.

</comment><comment><USER15> I'd be a buyer in deals like this, where I get the seller to make the money for me to buy them. Who wouldn't?</comment>


Objections to Remote Work - alex-warren https://alexwarren.uk/2020/07/27/objections-to-remote-work <comment><AUTHOR> It definitely has to do with the company processes and culture as well. Companies like Automattic, Gitlab, Zapier have nailed it. The problem lies in companies where the Management layer was always involved in bureaucracy and politics. In general, Great remote companies imbibe a culture where employees are self starters and motivated to get things done.</comment>


Zuul 2: The Netflix Journey to Asynchronous, Non-Blocking Systems - <AUTHOR> http://techblog.netflix.com/2016/09/zuul-2-netflix-journey-to-asynchronous.html <comment><USER2> There are some discussion on Reddit: [https://www.reddit.com/r/programming/comments/53thtt/zuul_2_...](https://www.reddit.com/r/programming/comments/53thtt/zuul_2_the_netflix_journey_to_asynchronous/)</comment>


LibreOffice 6.0: Release Notes - <AUTHOR> https://wiki.documentfoundation.org/ReleaseNotes/6.0 <comment><USER2> Discussion about the 6.0 release from 18 days ago: [https://news.ycombinator.com/item?id=16273046](https://news.ycombinator.com/item?id=16273046) (156 comments)</comment>


MIP* = RE - <AUTHOR> https://arxiv.org/abs/2001.04383 <comment><AUTHOR> Some related links:

An introduction to the area from before this new breakthrough -- [https://www.ams.org/journals/notices/201910/rnoti-p1618.pdf](https://www.ams.org/journals/notices/201910/rnoti-p1618.pdf)

Gil Kalai on the mathematical implications -- [https://gilkalai.wordpress.com/2020/01/17/amazing- zhengfeng-...](https://gilkalai.wordpress.com/2020/01/17/amazing-zhengfeng-ji- anand-natarajan-thomas-vidick-john-wright-and-henry-yuen-proved-that-mip-re- and-thus-disproved-connes-1976-embedding-conjecture-and-provided-a-negative- answer-to-tsirelso/)

Lance Fortnow -- [https://blog.computationalcomplexity.org/2020/01/quantum- pro...](https://blog.computationalcomplexity.org/2020/01/quantum-provers-to- infinity-and-beyond.html)

KW Regen -- [https://rjlipton.wordpress.com/2020/01/15/halting-is-poly- ti...](https://rjlipton.wordpress.com/2020/01/15/halting-is-poly-time-quantum- provable/)

Boaz Barak -- [https://windowsontheory.org/2020/01/14/mipre-connes- embeddin...](https://windowsontheory.org/2020/01/14/mipre-connes-embedding- conjecture-disproved/)

Scott Aaronson -- [https://www.scottaaronson.com/blog/?p=4512](https://www.scottaaronson.com/blog/?p=4512)</comment>


You should be using Boot and ClojureScript - <AUTHOR> http://escherize.com/2016/02/29/boot-with-cljs/ <comment><AUTHOR> Hi, I'm the author.

I used to use Leiningen for this, but found that it was hard to understand what project.clj was actually doing, to get figwheel, etc working. So once I figured out how well boot fit this use-case, I wanted to share the love!

<comment><USER2> I applaud trying to spread the news about these awesome technologies, but personally I think it would be much more helpful to _not_ hide what's going on behind a template generator. The build.boot file itself is easy enough to write[1], and that is really the huge value proposition with Boot vs. Leiningen plugins.

[1]: A simple example: [https://github.com/pandeiro/jamal/blob/master/build.boot](https://github.com/pandeiro/jamal/blob/master/build.boot)

<comment><AUTHOR> I agree with you that there is tons of value in digging into the various boot tasks that make this workflow/tutorial possible. The reason I decided not to is that the linked tutorial on modern-cljs# 1-3 does a great job of that!

[1] - [https://github.com/magomimmo/modern- cljs/blob/master/doc/sec...](https://github.com/magomimmo/modern- cljs/blob/master/doc/second-edition/tutorial-01.md)</comment></comment></comment>


UDP co-creator on UDP (and NSA killing end-to-end encryption in TCP) - <AUTHOR> http://www.reed.com/blog-dpr/?page_id=6 <comment><USER2> While it's _interesting_ that the NSA blocked encryption in TCP, I'm not convinced it would have been a good idea to do it at that level in practice. Encryption has moved on quite a lot since then (at the very least due to Moore's law holding for all that time). Changing the TCP stack (typically in the kernel) every time encryption moves forward would probably be worse than the current situation of using SSL/TLS. TCP itself has held up pretty well all these years; SCTP and such seem to have had zero impact on its popularity. (not that I'm an expert on either networking or encryption)

<comment><USER3> SSL/TLS has gone through numerous revisions, many of them after painful flaws, and was seen at the time it was created as a relatively cutting-edge design --- particularly vis a vis negotiation and flexibility. There is no chance encryption baked into TCP would have survived. How would you even key it? This story seems a bit apocryphal. I'm sure someone had it on a whiteboard somewhere, but...

<comment><USER4> You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way.

Key and cipher negotiation could easily be shoehorned into the three-way- handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.

But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.

<comment><USER3> Everything about this comment is horrifying.

Start with AES-CTR (which wouldn't have been an option in 1979; counter mode hadn't been invented): you can't use TCP sequence numbers as counters; among other things, multiple segments can be sent with the same sequence number, and while the byte described at the stream offset of those sequence number (usually, but not always) agrees with every other packet, no other guarantee exists about the nature of those segments. Reuse of a counter in CTR mode is a devastating flaw.

Running DH over an unsecured connection with no previous trust anchor is also a recipe for disaster; attackers don't even need a fully-functioning man-in- the-middle to break it; they just need to be able to inject two segments, one in each direction, to fixate the derived key.

Everything else you propose to layer on top of this DH + AES-CTR connection is handwaving; if you have to run "application-layer" TLS, what's the value of hardcoding (broken) crypto into the TCP layer?

Sorry for the rabid response to a well-intentioned comment, but wow I couldn't disagree with you more strongly.

</comment></comment></comment></comment><comment><USER3> Thrilled to have an authoritative source for the silliness of the URG pointer in TCP; now I can point people who think it has some value to the post that says it's a vestigial organ from when protocols needed to accomodate old teletypes.

Startled to see him say that the Internet should have been loose source-routed by default. I see the end-to-end argument in favor of it (it would have made it possible for software developers to override and theoretically improve global routing), but LSRR would have had far-reaching consequences --- for instance, all IP traffic would be trivially spoofable bidirectionally; also, it might have played havoc with CDNs.

Reed's paper "The End To End Argument In System Design" is required reading for pretty much everybody.

</comment><comment><USER5> whats really weird is that at last years Defcon Dan Kaminsky did a demo showing that DNS lookups were actually faster in TCP than UDP. His explanation of why: "... and I have no idea."

<comment><USER3> No, they aren't. TCP DNS is 10-20ms slower than UDP DNS against large DNS servers, and probably much worse against slower DNS servers.

I don't know what Dan did to generate this result, but whatever it was, it appears to have been wrong.

(Heading off a silly argument: the test I just did to confirm this did _not_ make new connections for each query; the 3WH was amortized over all the requests).

<comment><USER3> Here's the inevitable Twitter cripple-fight between me and Dan:

<http://bettween.com/tqbf/dakami/Jan-03-2011/Jan-04-2011/desc>

Here's what I think happened:

* Dan wrote this DNS proxy thing for DNSSEC (which, don't use DNSSEC, it's evil) called "phreebird".

* Phreebird uses libevent, which tends to produce zippy fast servers, so Dan benchmarked it and found TCP was faster than UDP.

* But Dan made a bunch of mistakes with libevent and, in fairness, BSD sockets in general; in particular, he only events the read side of the conversation --- his writes block. Since the socket buffers on the TCP side are spread out across a bunch of sockets, and there's only one UDP socket buffer, the UDP socket blocks a lot.

Dan says that when he says TCP is "faster", he means "it gets better throughput, even though it may not get better latency". Now, I think "latency vs. throughput" is a refuge for scoundrel arguments, but just to make sure, I checked, and if you wail on Google DNS with a TCP connection, you _cannot_ in fact clear 1000 queries faster than if you firehose it with UDP. This just makes sense, since TCP has congestion control overhead and strict in-order delivery and UDP doesn't.</comment></comment></comment>


To Facebook the answer must be no - <AUTHOR> http://www.scripting.com/stories/2010/04/21/toFacebookTheAnswerMustBeN.html <comment><USER2> One of the whole points about JSON is that you can write a serializer/deserializer in a few lines of code. It's a ridiculously simple, standard format.

Compare that with massive bloated complex XML parsers.

Good on them for using JSON.

<comment><USER3> _"One of the whole points about JSON is that you can write a serializer/deserializer in a few lines of code."_

Not without a good library for parsing. I'd be impressed by a robust JSON parser written in a few lines of code using just the standard library of any language.

<comment><USER4> <http://awwx.ws/combinator/toc>

</comment></comment></comment><comment><USER5> _My programming environment doesn't have a JSON serializer or deserializer_

Its 2009 man, grow up Dave. XML lost.

<comment><USER6> Dave != XML; Dave == RSS

But yeah, json is becoming the syndication format.... Are there standards for json objects yet?

<comment><USER7> _Dave != XML; Dave == RSS_

RSS ⊂ XML

</comment></comment></comment><comment><USER8> I realize this is Dave Winer and his place in the industry... but....

Is it just me or does this read like an old out-of-date guy that doesn't like change?

<comment><USER9> I syndicated his blog for the better part of a year and found most of his posts to be misguided. I think you're right that he just doesn't like it when things change.

</comment></comment><comment><USER10> It's ludicrous to me that Dave on the one hand refuses to use JSON but then says the OAuth is "easy".

My personal experience is that JSON is very easy and getting OAuth signatures right is like stabbing yourself in the eyes with hot needles.

<comment><USER3> He said it's easy because he already has it implemented. No work required.

</comment></comment><comment><USER11> "Facebook is to be the identity system for the web. A company? That just can't work. I can't believe he doesn't know that. Even Bill Gates didn't have the audacity to propose that!"

Dude, you don't remember Passport?

<comment><USER12> Granted that Microsoft did come out with Passport, so Dave is wrong there. But yeah, I agree completely.

</comment></comment><comment><USER13> I really don't want Facebook to be the identity of the Internet.

</comment><comment><USER14> I can't decide what is more comical. That he's going to write off FB and Twitter because parsing JSON is too hard. Or that he thought the Open Graph was a bad idea in 1997 and still thinks so today, and apparently is proud of it. Or that he thinks FB could buy Microsoft.

</comment><comment><USER15> It must be frustrating to develop when you have to look at everything through a two decade old lens. Dave has had some brilliant ideas, but sticking with a hacked together dead environment is making him irrelevant.

<comment><USER16> _It must be frustrating to develop when you have to look at everything through a two decade old lens._

You don't _have_ to though. I've seen a lot of stuff reinvented already, some of it badly. That doesn't stop me from doing the pragmatic thing most of the time though.

<comment><USER15> Have was the wrong word, but Dave is unwilling to change so it's the same end result.

</comment></comment></comment><comment><USER17> I didn't know that Dave Winer is the dad in "Shit My Dad Says"! Wow!

</comment><comment><USER18> "My programming environment doesn't have a JSON serializer or deserializer"

I did not realize that in 2010 any mainstream environments did not have a JSON library!

<comment><USER7> He must be using COBOL on Crutches.

<comment><USER19> He should upgrade: <http://www.coboloncogs.org/INDEX.HTM>

</comment></comment></comment><comment><USER20> Summary: Zuck is like BillG, and having Facebook be the identity provider for the web would be a bad thing.

</comment><comment><USER21> Holy shit, Dave Winer still exists!

</comment><comment><USER22> Someone needs to write a JSON-to-XML mapper for poor Dave so he can still read the streaming internet.

</comment><comment><USER23> I knew I'd regret clicking a scripting.com link...how this stuff gets 28 upvotes is beyond me.

</comment><comment> loup-vaillant I hoped to see a political argument, and instead saw a technical, unimportant one.

Because I agree with the title: Facebook promoting unnecessary centralization and large scale spying, the answer must be no. We just need a decentralized replacement, so it _can_ be no.</comment>


Show HN: Vue's Hacker News 2.0 App in TypeScript - <AUTHOR> https://github.com/kevguy/vue-hackernews-2.0-typescript <comment><USER2> Lots of casting variables as `any`. This is an anti-pattern in TypeScript and, while convenient, basically destroys the key benefits of using TypeScript.</comment>


Show HN: Certainty – Automated cacert.pem management for PHP projects - <AUTHOR> https://github.com/paragonie/certainty <comment><AUTHOR> If you've ever looked into a PHP project and seen these lines:

      curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
      curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

...then you already know exactly what motivated this project to exist.

<comment><USER2> ...never seen anything like that before anywhere, nope, >__></comment></comment>


Ask HN: What are some of the best paying companies in the Bay Area? - <AUTHOR> In the recent days after having conversations with friends I've found out that Glassdoor data is inaccurate for smaller companies. Given that, I wanted to know what are some of the best paying companies in the Bay Area. When I say "best paying", its for a software engineering, individual contributor role. So far my conversations show that Google and Facebook are the top ones, but there are SF based unicorns which are not that far behind. <comment><USER2> Netflix

</comment><comment><USER3> Look at the data at Paysa.com

The attraction of startups is that your .01% of the company will turn into big money. Maybe. Look at the jobs listed at angle.co (AngelList)

Consider if you want to make, say, $20K more and be bored, or work at a company that copies, not innovates.</comment>


When asked, vast majority of businesses say IP is not important - <AUTHOR> http://topromotetheprogress.wordpress.com/2013/12/20/when-asked-vast-majority-of-businesses-say-ip-is-not-important/

<comment><AUTHOR> I wonder if this is because a few very large companies hog all the IP to themselves. In other words, only a few specialists like Proctor and Gamble really put any emphasis on this in their business. That's why they mentioned that grocery stores are an IP intensive business, because they are filled with products from Kraft Foods, P&G, and a few other large multinational companies who are very dependent on branded products.

Most businesses, although they do have a brand to protect, put a lot more emphasis on quality and service. They don't need to worry if someone else sells the same product under a different brand, because buyers are not fooled by the lower quality and poor service products that knockoffs peddle. There are only a few industries like clothing where knockoff products can get traction in the market.</comment>


BlackBerry vs iPhone: What If There Is No Winner? - <AUTHOR> http://7thursdays.wordpress.com/2008/07/03/blackberry-vs-iphone-what-if-there-is-no-winner/

<comment><USER2> Hopefully the winner will be webkit. With iPhone, Android and Nokia S60 all using webkit for their browsers users will become accustomed to better mobile web experiences, like iphone.facebook.com. This may pressure manufacturers to switch to webkit to also let their users use iphone web apps, leading to a more harmonious thingy</comment>


Great New Free Email Tracking – what do you use? - <AUTHOR> Got really annoyed at Yesware for ending its free trial, and I found these guys:https://chrome.google.com/webstore/detail/rocketbolt-email-tracking/pkapfpgbgfcojflnfmhnplkkkcdcmkfj
RocketBolt seems really great so far, and it includes Rapportive-style social profile pulls in addition to standard email tracking.
What does everyone here use for email tracking? (Or does everyone here use a pixel blocker :) <comment><USER2> Yeah, I'm basically the worst because I use a blocker so other people can't track me, but I love tracking them.

I've been using Yesware, but no way am I paying for it. I'll give RocketBolt a shot, thanks.

</comment><comment><USER3> I use RocketBolt for email opens now as well. The profile building is interesting... basically a social stalking tool for sales leads.

</comment><comment><USER4> I use Streak (a YC company, I believe), which has email open tracking built in. It's meh... gets the job done, I guess, but it's not really their focus. I definitely use it more for the CRM component.

Haven't heard of RocketBolt. I'll check that out.

I think Hubspot has something. Was it called Sidekick? I can't find anything about it anymore.</comment>


Show HN: Our local Pinboard startup project - <AUTHOR> http://koaloa.com

<comment><USER2> That spinning logo is horrific. We're not in 1999 any more. It totally distracted me from what was going on in the rest of the site.

</comment><comment><USER3> I love the design and transition effects.

</comment><comment><USER4> what is your business model?

</comment><comment><USER5> Absolutely horrible design.</comment>