BPF comes to firewalls - <AUTHOR> https://lwn.net/SubscriberLink/747551/7b37e1ce398c30c0/ <comment><USER2> At Cloudflare we use BPF in firewall extensively. We blogged about this in past:

* [https://blog.cloudflare.com/bpf-the-forgotten-bytecode/](https://blog.cloudflare.com/bpf-the-forgotten-bytecode/)

* [https://blog.cloudflare.com/introducing-the-bpf-tools/](https://blog.cloudflare.com/introducing-the-bpf-tools/)

* [https://blog.cloudflare.com/introducing-the-p0f-bpf-compiler...](https://blog.cloudflare.com/introducing-the-p0f-bpf-compiler/)

We even have a piece of software called "floodgate" which is pretty much a custom runtime for iptables compiled down to BPF. It's using proprietary driver magic to offload the firewall rules engaged during large L3 attacks, and runs them with high performance in userspace. More:

* [https://blog.cloudflare.com/meet-gatebot-a-bot-that-allows-u...](https://blog.cloudflare.com/meet-gatebot-a-bot-that-allows-us-to-sleep/)

More BPF integration in iptables is a very good idea. The interesting bit is how to deal with more complex things like haslimits, limits, ipsets and conntrack integration.

</comment><comment><USER3> So the Berkeley Packet Filter is now being used for packet filtering? What a wonderful development! What will they think of next? :)

<comment><USER4> Yes the title caught me off guard as well. As a BSD user for many years, it is strange to think of it as "new".

<comment><USER5> eBPF is far evolved from "classic" BPF, though. There is a historical relationship (hence the name) but they're very different animals at this point.

Also, the traditional use of BPF wasn't to filter network traffic, but only to sieve data flowing to userland tools like tcpdump.

</comment></comment></comment><comment><USER6> For anyone who don't know: nftables has its own byte code interpreter for filtering too. And at the time nftables was created, bpf already existed in Linux.

The author's argument against using bpf is that it's hard to reproduce the human readable rules from bpf byte code. Wonder how bpfilter is going to should this problem.

</comment><comment><USER7> What we are missing from linux today is a networking subsystem that allows for configurable efficient hardware offloading.

Without hacking up everything, like it is done in consumer routers these days.

Will BPF handle that better than nftables?

<comment><USER8> In this age where major security flaws are being discovered in hardware, do we really want to offload network filtering to what might be black box hardware with limited/no auditability?

<comment><USER9> There are various levels of offloading. There are basic operations like checksum offloading that existed for a long time and it's optional. Not sure anyone would complain about the auditability of that one. (you would see errors on the next hop if it didn't work correctly)

<comment><USER10> I interpreted OP's point as moving that kind of complexity to a black box would open it up to being compromised and then leveraged as a backdoor into your system, or as a botnet, etc.

</comment></comment></comment></comment><comment><USER11> > Developers should be careful, though; this could prove to be a slippery > slope leading toward something that starts to look like a microkernel > architecture.

That's an interesting warning. Pushing more tasks out of the kernel would seem like a good idea to me. I thought Torvalds' argument against a microkernel design was more about performance than complexity. Is that incorrect?

<comment><USER12> I assumed this was a joke, based on early Linux vs microkernel debates.

</comment></comment><comment><USER13> For those interested in a really technical deep-dive on BPF, check out: [http://cilium.readthedocs.io/en/latest/bpf/](http://cilium.readthedocs.io/en/latest/bpf/)

If you have questions on BPF and Cilium for advanced firewalling, you can also ask them on the cilium slack: [http://www.cilium.io/slack](http://www.cilium.io/slack)

</comment><comment><USER14> After many years of learning the many options to iptables, I can only say it's about time. The iptables command is one of the least ergonomic ones I use regularly.

That said, while BPF syntax is great for simple cases, the boolean logic gets pretty messy in a hurry if you want to do something weird.

Simple case comparision:

      iptables: iptables -t filter -A FORWARD -p tcp --dport 80 -j ACCEPT

      theoretical bpf: allow forward tcp dst port 80

Note that the capitalization in the first command is not arbitrary, it must be there for the command to work, exactly as shown. Also, I didn't switch to the double dash option on dport frivolously, there is no single dash option for this incredibly common feature. Plus the manpages are split into a bunch of different parts and the SEE ALSO section at the bottom is woefully incomplete, making it difficult to track down exactly the page you need.

That said, incorporating all of the features from iptables into a BPF syntax is going to require a considerable expansion over what you get with tcpdump. Things like marked packets, NAT, state tracking, etc... all need to be grafted onto the language somehow. And of course everything needs to be well documented because a lot of sysadmins are going to need to learn this in a hurry and bad documentation will make them hate it and insist on keeping iptables instead, warts and all.

<comment><USER15> There are two man pages: iptables(8) and iptables-extensions(8). What other man pages are you referring to?

<comment><USER14> I had remembered the conntrack stuff being in a different manpage, but maybe that's faulty memory on my part.

<comment><USER15> The iptables-extensions(8) manual page is fairly recent. AFAIK, previously, there was no manual page, but maybe it was scattered over various pages.

</comment></comment></comment></comment><comment><USER16> What do sysadmins generally use BPF or other more advanced firewall systems for?

I've administered only a few production systems, and the firewalls I configured were always very simple. Reject all traffic incoming except for port 22/23, 80/443 and outgoing except for to certain package management systems, that sort of thing.

I admit I've done some slightly more complex things to rewrite things to implement some virtual network thing, but I don't think I did that in production.

</comment><comment><USER17> One potential advantage of the new BPF code for firewalls is that may make it easier to excise code owned by a certain copyright troll....

<comment><USER18> Are you referring to Patrick McHardy a former contributor to Netfilter?

[https://www.theregister.co.uk/2017/10/18/linux_kernel_commun...](https://www.theregister.co.uk/2017/10/18/linux_kernel_community_enforcement_statement/)

</comment></comment><comment><USER19> "The Linux kernel currently supports two separate network packet-filtering mechanisms: iptables and nftables. For the last few years, it has been generally assumed that nftables would eventually replace the older iptables implementation; few people expected that the kernel developers would, instead, add a third packet filter. But that would appear to be what is happening with the newly announced bpfilter mechanism. Bpfilter may eventually replace both iptables and nftables, but there are a lot of questions that will need to be answered first."

Goshdarnit. I've been trying to get ahead of the curve and have been learning and implimenting nftables, and now you're telling me I might need to learn something else! Such is the life of a sysadmin I suppose.

"The use of BPF enables the writing of firewall rules in C"

Have you seen the rulesets people write in other firewall languages? This seems scary to me.

"One of the core design features for bpfilter is the ability to translate existing iptables rules into BPF programs."

nftables also does this, but I suggest not using it and writing fresh

"even though it would be likely to supplant nftables relatively quickly. Instead, Miller said in the discussion that nftables failed to address the performance problems in Linux's packet-filtering implementation, driving users toward user-space networking technologies instead. There is a real possibility that nftables could end up being one of those experiments that is able to shed some light on the problem space but never takes over in the real world."

Ok, well I have some questions here. First, show me the benchmarks. Also, nftables is still much faster than iptables in my benchmarks, so it has largely delivered. Of course it's difficult to compete with an asic offload, but I do see how there could be lots of potential with bpf if it offloads to the interface. That said, the real potential I see is for nftables and bpf to coexist in the future as a replacement for iptables or for iptables and bpf. nftables solves a lot of real problems and working with it has been really enjoyable for me compared to years of iptables rules (I always refused to use the layer-on-top-of-iptables abstractions, so I'm talking about pure iptables.) A quick glance at bpf seems like it would be worth it for extremely high requirement cases where the investment would be worth it (just noticed the cloudflare comment for example), but for the rest of us mortals in IT deps with limited budgets, time, and knowledge workers, it seems a bit too heavy to just start implimenting.

I could be wrong, but I really hope nft succeeds despite this.

<comment><USER20> I'd really like it if instead of having "kernel developers add a third packet filter", said developers would sit down a bit and agree on how to manage firewalling at the userspace level. iptables feels like a tool that was developped to test out netfilter rules (that is, the kernel part) but not really for actual use. That would explain why there are so many frontends that attempt to abstract away the ugliness. I've seen too many "firewall setups" that are just a script calling iptables for each rule. While this works, it can be dangerous as well: if you edit the file and mess up a rule, there's a risk that only part of the ruleset is loaded. Hopefully, the operator won't have locked himself out in the process. Of course, there's the iptables- persistent package for atomically loading a ruleset (in Debian at least). The problem is that there's also a netfilter-persistent package. What's the difference between the two ?

How is one supposed to pick ? Then, there's also nftables. I've only glanced at it, and it looks promising but it seems there are some things that are missing. A comment in the article says that TCP MSS clamping has been added only recently. By the looks of it, it appears to be "almost there" but not quite ... which is a shame.

I'm hoping whatever implementation ends up prevailing will solve the various technical problems (performance, features w.r.t filtering capabilities) but will also provide a sane way to manage it. I feel kind of sad with the current situation. With my developer hat on, I am continuously impressed with the networking features available on Linux (Netfilter, XDP, ...). With my operator hat on, I find the general lack of usable tools as well as the inconsistency maddening.

</comment></comment><comment><USER18> systemd implemented eBPF-based per-unit IP access lists and accounting [1] in version 235.

[1]: [https://github.com/systemd/systemd/pull/6764](https://github.com/systemd/systemd/pull/6764)

</comment><comment><USER21> This is what project Cilium does - [https://github.com/cilium/cilium](https://github.com/cilium/cilium)

<comment><USER22> From your link:

>A new Linux kernel technology called BPF is at the foundation of Cilium. It supports dynamic insertion of BPF bytecode into the Linux kernel at various integration points such as: network IO, application sockets, and tracepoints to implement security, networking and visibility logic. BPF is highly efficient and flexible.

</comment></comment><comment><USER23> The NPF firewall in NetBSD also uses BPF as its rule engine along with a JIT for several CPU architectures.

</comment><comment><USER24> This reminds me of a cloudflare blog post I read a few years back about the xt_bpf module for iptables.

[https://blog.cloudflare.com/bpf-the-forgotten- bytecode/](https://blog.cloudflare.com/bpf-the-forgotten-bytecode/)

I wonder if the projects are related.

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

</comment></comment><comment><USER26> Really please to see BPF making further progress, well done and thank you to those involved in the implementation, testing and review process across the various projects involved.

</comment><comment><USER27> Well, more user-controlled code executed by the kernel means more fun! And more work for security researchers.

</comment><comment><USER28> I'd look at Dragonfly's stack first, as that's outperforming Linux at the moment.

<comment><USER29> _I 'd look at Dragonfly's stack first, as that's outperforming Linux at the moment._

Apples, Oranges, etc.

<comment><USER29> Instead of senseless downvotes, how about some comments instead? Dragonfly isn't Linux, it is a BSD, therefore the OP is comparing apples to oranges. If you disagree, say why, don't just hit the downvotes. HN is rapidly becoming the Reddit for technosnobs.

<comment><USER30> I would guess that both of you received downvotes because both comments failed to provide any explanation for the view expressed. I think it's good practice on HN to briefly introduce a technology where it's safe to assume that a majority are not very likely to be familiar with it, so that the comment becomes meaningful on its own.

If you had stated: "You are comparing apples to oranges here because Dragonfly only exists on BSD, not on Linux, and as such may not be a viable choice for most users." I think you would have received no or substantially fewer downvotes. If you then had in addition to that provided a quick explanation (or more) of what "Dragonfly" is, you would have gotten upvotes instead, because that would have taught a number of us something we did not know yet.</comment></comment></comment></comment>


Boston Dynamics Spot - <AUTHOR> https://www.bostondynamics.com/spot <comment><USER2> It'd be really nice if vendors for specialized hardware like this could give at least a ballpark figure without me having to give a bunch of info to some sales rep (if that's even possible; the "Contact Sales" button just brings me to a page with no content - just the header and footer). Will Spot be $50? $500? $5000? $500000? $50000000? How about Handle or Pick? If I don't have a ballpark, I don't know if it's even worth calling for a quote.

This is a problem that seems to be endemic among vendors that sell things to businesses; they always seem to be hush-hush with the price, which strongly suggests to me that they're going to try to screw me.

<comment><USER3> I figure the old adage still holds: "If you have to ask, it's too much."

<comment><USER2> What's insane is that vendors will do this even for products that are very obviously not "too much". I shouldn't have to call a sales line and give a bunch of information just to get a ballpark figure on what a urinal cake will cost me, lol.

</comment></comment></comment><comment><USER4> It seems like they are discouraging individual non corporate purchasers. Can't a man have his robotic dog?

<comment><USER5> I guess it will be quite expensive.

</comment></comment><comment><USER6> black mirror in the making :)

</comment><comment><USER7> Raas</comment>


Outputs vs. outcomes: what's the difference and why does it matter? - <AUTHOR> https://github.com/joelparkerhenderson/outputs_vs_outcomes
My teammates are asking about the technology industry concepts of "outputs" vs. "outcomes". So I wrote this simple summary.
Constructive feedback, data, and anecdotes all welcome. <comment><AUTHOR> Link: [https://github.com/joelparkerhenderson/outputs_vs_outcomes](https://github.com/joelparkerhenderson/outputs_vs_outcomes)</comment>


If you have REST, why use XML-RPC? - <AUTHOR> http://joncanady.com/2010/01/14/if-you-have-rest-why-xml-rpc/ <comment><USER2> It's more work to write a client library for XML-RPC/SOAP, but a single one of those libraries is likely to work with any such service you encounter. Most users never have to write one themselves.

On the other hand, it's easy to write an HTTP "REST" client library. But it seems that everyone has a different idea of what REST is. Amazon's implementation of REST isn't even close to the generally-accepted definition, for instance. Indeed, you need (to write) a separate client module for every service you use, and that's where REST fails.

Because it's so easy to write a REST service, it seems more like REST is an excuse for lazy server writers to get by.

</comment><comment><USER3> SOAP an its ilk seem the easiest solution at first glance. Say I've got a server that can blat a frobnitz, what could be simpler than supplying a pair of functions?

      int[] GetBlattableFrobnitzIDs();
      void BlatFrobnitz(int frobnitzId);

Two functions that just magically appear when you point your IDE at a server and tell it to automatically generate a proxy class. Simple!

What's the REST alternative? Getting the list of IDs is okay, but how do you give a "blat" instruction? Until you've experienced REST in anger, its not obvious what you need to do.

Go beyond superficial uses and REST shines, but a beginner used to calling library functions might not see it.

<comment><AUTHOR> If I'm operating a Frobnitz service and my documentation doesn't indicate how to Blat a given Frobnitz, then the failing isn't my communication layer, it's my documentation.

<comment><USER4> _No!_ REST begs you not to have any separate documentation that is mandatory to understand your API.

The response from the Frobnitz resource should contain hypertext that indicates how to Blat it: at least the method and url.

<comment><AUTHOR> Both are good! Documentation helps ease users in, while proper hyperlinks make the service discoverable.

</comment></comment></comment></comment><comment><USER5> A lot of questions are of the form "XML-RPC does X, but it isn't clear how to do X in REST", and the answer to most of those questions should be "You wouldn't design the system to do X when taking the REST approach."

Think of it this way: XML-RPC is structured programming, which is all about the subroutines you call, the data you pass to them, and the data you get back. REST is object oriented programming, which is all about the data and the methods you use to interact with the data.

In REST, a type of resource is like a class, a specific resource is like an object, and all objects have some/all of the same basic methods: OPTIONS, HEAD, GET, PUT, POST, DELETE. These methods always have the same purposes:

        OPTIONS: which methods does this resource support
        HEAD: what is this resources metadata
        GET: get a representation of the resource
        PUT: store a new representation of the resource
        POST: create a new resource and return its URI
        DELETE: get rid of the resource

The HTTP standard defines the responses to all of these methods, except for the specific representations. The defined responses include the status codes to return, the resource metadata (various HTTP headers), and how to specify the Content-Type header which identifies the representation being returned. The standard also specifies how the client should tell the service which representations it knows how to handle, in order to negotiate and find a useful content-type.

Where REST services differ are:

       1) What resources are available
       2) What are the representations for each resource
       3) What additional arguments are supported for each method and representation. (Query parameters for HEAD and GET, content body for POST and PUT.)

Another typical pattern for REST services is that, for every resource type, there is also a collection resource. To create a new resource, you PUT to a specific resource URI, or you POST to the container. Which you choose to implement as a service designer depends upon who's responsible for deciding the URI for the new resource; if the client decides use PUT, and if the service decides use POST.

One commenter asks (paraphrasing) "How do I use REST to call a function and pass an array as the third argument, and get back a sensible error if I pass a hash instead?". My response is that you probably wouldn't be doing something like that with a REST service. It's difficult to be more specific without a concrete example, but right from the top I'd say you're not calling functions in REST, and you need to invert your thinking in order to switch between XML- RPC mode and REST mode. (Similar to the way you can never really work well with OOP as long as you're thinking in terms of subroutines rather than classes and objects.)

<comment><USER6> This is why some of us still prefer to use XML-RPC. We just want to make an API, and don't need any of the other baggage, especially if we can no longer map our existing software design to a REST approach.

At least with real object-oriented programming you can come up with your own method names.

</comment></comment><comment><USER7>
        Python 2.4.3 (#1,...)
        Type "help", "copyright", "credits" or "license" for more information.
        >>> import xmlrpclib
        >>> server = xmlrpclib.ServerProxy("http://www.something.invalid/xmlrpc")
        >>> server.namespace.function(True, ["A", "B"], {"q": [1, 2, 3]})
        {'A': 8, 'B': ['hello', 8]}

"REST" can't match that. "REST + some other stuff I layer on top" can, but you have to bring more to the party; for instance, you can decide that everything will be JSON coming back, but you had to decide that, so you had to do the work. On the other hand as is so often the case with this increased responsibility you get more power; XML-RPC has no decent binary capabilities, for instance, which is easy with REST.

That doesn't mean the work isn't worthwhile. My personal feeling is that if XML-RPC meets your needs, you should probably use it, but if it doesn't, don't hesitate to move on. RPC is a crazy and cruel world, though; here there be dragons. REST is better than starting from scratch in most ways but you can still end up down the rabbit hole surprisingly quickly. For instance, REST tempts you into considering caching in a layer designed for caching human document accesses; this may or may not actually have the semantics you are interested in and it can get subtle.

<comment><AUTHOR> I'm confused about your Python example and how REST can't achieve that.

      bash$ curl http://my-fake-service.com/people/1.json
      {name: "John Doe", address: "123 Fake St"}

I think opposite you, however. My feeling is that REST will probably meet your needs, and if for some reason you're required to use XML-RPC, then use that. It all depends on your starting point and biases.

<comment><USER8> Not so much "can't" achieve it, but doesn't.

With xmlrpclib, serving functions over XML-RPC is a library import, a server class instantiation and a one line instruction to serve a function, and on the client side an import, a connection and a function call.

After that they behave much as any other functions (+latency), parameters are encoded and return values decoded all behind the scenes, neither the server function nor the client need have any special 'written-for-XML-RPC' changes for it to work.

It's more a case of a well implemented Python module than an inherent win over REST - there could be a similar module for REST-RPC created, but AFAIK there isn't one at the moment.

<comment><USER7> REST-RPC is obviously possible, but would be additional stuff on top of REST, and... I guarantee you that REST advocates would flip out. By and large they think that having things that don't cleanly map down to RPC is a benefit; they would object that a function call lacks the richness to fully represent the results of a REST invocation: Did you get a cached value back? Can you get to the HTTP headers? Can you set cache header on the request itself, or other HTTP headers? And there's a lot of truth here. Basically, REST-RPC would be "an RPC mechanism built on top of REST", but would not be "REST that is also RPC"; REST-RPC must necessarily be at least one of "a significantly limited subset of REST" or "more complicated than a simple function call".

Despite the fact I'm not willing to write off XML-RPC as absolutely useless as I believe there are times for simplicity, I also tend to agree that for industrial strength purposes RPC is a bad metaphor and you basically lose if you try to use RPC. It's just that I don't think REST is the right direction; I head more in the direction of message passing, as laid out in

[http://www.erlang.org/pipermail/erlang- questions/2008-May/03...](http://www.erlang.org/pipermail/erlang- questions/2008-May/035207.html)

And REST would agree with at least some of that; at least REST isn't hiding the fact that your function call is not local from you. But it falls afoul of many of the criticisms, too.

</comment></comment></comment></comment><comment><USER6> I like how XML-RPC support is built into Python. If a server supports XML-RPC, I can get an instant command-line interface that feels like using an ordinary library. The data structures that XML-RPC supports are mostly the same as JSON: arrays, hashes, integers, floats, and strings. There are also date/time values, which are automatically deserialized as Python datetime objects, and binary values which are transparently base64-encoded. Being able to use native types is a plus over dealing with XML trees. The lack of object types, in contrast with SOAP, is a feature in my opinion, since it keeps the interface portable across many languages.

XML-RPC uses XML and HTTP, but it hides both from the programmer. I think it is a mistake to criticize XML-RPC for not integrating deeply with HTTP, because HTTP is not really the point of XML-RPC. It's just an implementation detail. It happens that HTTP and XML libraries are everywhere, so XML-RPC lets you tunnel a simple RPC protocol through an infrastructure that is common across many programming languages.

Every REST interface I have tried to integrate with uses HTTP error codes differently, treats the GET/POST/PUT/DELETE commands in its own peculiar way, and has unique requirements for authentication. I am not at all sure that deep HTTP integration is appropriate for APIs. Regardless of the protocol (or "architectural style", if you insist), documentation of data structures, calling conventions, and error codes is essential, and just saying "we use HTTP" is insufficient to communicate these details.

Disclaimer: I wrote the xmlrpc-light library for OCaml. <http://code.google.com/p/xmlrpc-light/>

<comment><AUTHOR> _Every REST interface I have tried to integrate with uses HTTP error codes differently, treats the GET/POST/PUT/DELETE commands in its own peculiar way, and has unique requirements for authentication._

I can't defend systems that (for example) misuse HTTP status codes or ignore HTTP authentication, but this puts it at the same level as XML-RPC, which re- invents error codes, methods, and authentication _every time_.

 _documentation of data structures, calling conventions, and error codes is essential, and just saying "we use HTTP" is insufficient to communicate these details._

I absolutely agree. Documentation is essential for a web service, regardless of how you provide that service.

<comment><USER6> To say that some systems "misuse" HTTP status codes implies that there is a correct way to use them. What is the correct way to use HTTP status codes for an API? They weren't even designed for APIs. Where is this specified? Since REST is just a style, not a standard, correct use of status codes is undefined. As a result, everyone uses them differently. For example, what is the correct status code to send when a new resource has been created?

XML-RPC does not try to force an existing set of error codes on you. You start with a blank slate. This means you do have to come up with a plan for how you are going to use error codes, but the same is true of REST; the only difference is that you don't have to fit your error model to an existing set of codes designed not for APIs but for serving documents to a web browser.

<comment><AUTHOR> _For example, what is the correct status code to send when a new resource has been created?_

From <http://en.wikipedia.org/wiki/List_of_HTTP_status_codes>

201 Created The request has been fulfilled and resulted in a new resource being created.

This isn't to say you shouldn't document how your service responds to requests, just that there are response codes you can use that are widely understood.

If you want you can respond to everything with 200 OK and require clients to parse responses to understand how your service handled a request, but again this is the same thing XML-RPC gives you.

<comment><USER6> So then, sending a 302 redirect in this case would be incorrect? That is how most web forms operate, and the web is RESTful by definition.

<comment><USER9> The web is not, in general, RESTful. State-changes on GET are common, for instance. Client state is regularly held in server-side sessions. PUT and DELETE are essentially unsupported.

<comment><USER6> I hope I'm not beating up a straw man here, but I have seen many claim that REST is a good solution that scales well because the web is built on the REST philosophy. The principles of REST are why the web is a success, and so if we use REST, we can attain the same benefits. What you seem to be proposing is that the web is not a good example of REST.

If this is the case, is there any good example of REST? I have yet to see a web service API that does not require one to read the docs to do URL construction, which violates the HATEOAS principle. The only examples I know of where HATEOAS is satisfied are HTML forms, as I mentioned, Atom feeds, and OpenSearchDescription. None of these are elaborate APIs (or APIs at all) where one would even need to consider something like XML-RPC.

I think HTML forms are a perfect example of REST, since they supply the client with all necessary information to build the next request, and URLs do not need to be constructed manually. The way 302s are used to redirect to the newly- created resource makes web browsers behave more RESTfully, since they prevent reloads from resubmitting POST requests. This is a very common practice today, and I would consider it one of the best examples of REST done right, and yet it uses a different HTTP response code than the proposed standard of 201 Created.

All I'm trying to do is show that there are at least two codes, 201 and 302, that properly RESTful services might return, to support my argument that response codes are not uniform across all REST services.

<comment><USER9> "I hope I'm not beating up a straw man here, but I have seen many claim that REST is a good solution that scales well because the web is built on the REST philosophy. The principles of REST are why the web is a success, and so if we use REST, we can attain the same benefits."

I don't think this is correct. REST piggybacks on the web's architecture, but I wouldn't say that the web is built on the REST philosophy, in part because REST postdates the web's initial growth. The web was a success almost in spite of itself, but REST wins by cherry-picking the good bits.

"If this is the case, is there any good example of REST?"

There is an interesting discussion of this and HATEOAS here: [http://www.suryasuravarapu.com/2009/03/restful-api-and- hateo...](http://www.suryasuravarapu.com/2009/03/restful-api-and-hateoas- conundrum.html). The examples given are Amazon S3 and the NetFlix API.

"The only examples I know of where HATEOAS is satisfied are HTML forms, as I mentioned, Atom feeds, and OpenSearchDescription."

A plain GET link can be an embodiment of HATEOAS. Remember, it's _application_ state, not _resource_ state that's key here.

"I think HTML forms are a perfect example of REST, since they supply the client with all necessary information to build the next request, and URLs do not need to be constructed manually."

Some are, some aren't. It depends what HTTP method you're using and what the server does with the request that makes it RESTful (or not). From that perspective, plain links are just as RESTful as forms - provided they're treated correctly.

"The way 302s are used to redirect to the newly-created resource makes web browsers behave more RESTfully, since they prevent reloads from resubmitting POST requests"

Preventing resubmissions is more about interface design than REST, though. From REST's point of view it's not wrong to repeat a POST. I'd argue that strictly speaking either a 201 or a 302 might be correct, depending on what you're POSTing. If you've just POSTed to a collection URI, then a 201 response with a list of collection member resources would be just as correct as a 302 with the address of the newly created resource. The latter is more conventional, but as I say, that's a UI concern, not because one is more RESTful than the other. There are other ways to protect the server from resubmission problems, but they involve more work for the developer.

If you're PUTting, I'd argue that a 201 should always be correct, but given that browsers don't support PUTs directly anyway, that's not relevant here.

"All I'm trying to do is show that there are at least two codes, 201 and 302, that properly RESTful services might return, to support my argument that response codes are not uniform across all REST services."

I hope I've shown that it's not in any way inconsistent to support both.

<comment><USER6> You have. Thank you.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> First let me say I'm not arguing for XML-RPC. See my actual question at the bottom.

One nice thing about protocols like XML-RPC is they're well defined, unlike the somewhat abstract idea of "REST", which leaves a lot of room for interpretation.

You end up with lots of different REST API styles created by people of various levels of competence and understanding of what REST is. It makes it harder to create client libraries that handle the mundane aspects of communicating with these APIs.

Projects like httparty and rest-client do help somewhat, but they end up injecting their opinion of what the "correct" way to do REST is.

So my question is: has there been any effort to codify REST API best practices into a lightweight REST "protocol", such that it would be easy to write generic client libraries, yet still obey the principles of REST?

<comment><USER11> ActiveResource ?

[http://api.rubyonrails.org/files/vendor/rails/activeresource...](http://api.rubyonrails.org/files/vendor/rails/activeresource/README.html)

</comment></comment><comment><USER12>
      but now we're discussing specific implementations, which is a separate issue.

The author states that specific implementations is a separate issue, but it really isn't. You can't ignore that a good implementation will mean that people will actually use your pet mechanism over someone else's. Most people don't want to reinvent the wheel, so they're not going to be writing the lib to handle the wire protocol, they're going to use a library that does what they need.

REST is heavy, and XML-RPC unnecessarily so. Facebook's Thrift (<http://incubator.apache.org/thrift/> ) is a lightweight alternative to both.

(That said, REST in Python is fairly easy - <http://developer.yahoo.com/python/python-rest.html> )

<comment><USER13> "Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml."

I have a very hard time believing that is a lightweight alternative to anything.

For REST all you need is an http library.

<comment><USER12> Ah. The on-wire protocol is what is lightweight. The framework certainly isn't. For simple REST via an http library, how many bytes actually have be encoded before you send it, and be decoded at the other end? (Keeping mind that Thrift originated at Facebook may make the overhead from REST seem more relevant.)

</comment></comment></comment><comment><USER14> XML-RPC is just what it says, a protocol for calling remote functions, isn't it?

It gives you a unified means to specify functions, along with parameters and their types, and gives errors when the requests don't match the definition. With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing?

Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. Now what if there are two parameters, how do I know which comes first if someone else wrote it who doesn't use the same style as I do?

If I'm querying for an employee, is it clear that I should use employee/110.jpg and not employee.jpg/110 or employee/110/jpg or employee/110/query/jpg, or somethere else?

<comment><USER15> _With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing?_

No, you wouldn't. as generalk sayed in his comment (<http://news.ycombinator.com/item?id=1053384>), it's the reverse, namely with REST over HTTP you'll make use of HTTP, which perfectly provides the functions to accomplish the task of invoking a method remotely without having to implement this important part on your own. I'll try to make an example.

let's pretend you have a method called _GetEmployeeByName(string name)_.

with REST you'll implement this method and allow your users to invoke it via <http://myservice.com/employee/simpson>. the invocation, parameter-passing, error-handling etc. is done via HTTP, so theoretically no work is needed on this part, since you don't have to _implement_ HTTP.

with XML-RPC the thing is pretty different. you'll implement the method, but what you have to do now is -- as described in the article -- find a library (or implement your own) that will generate all the needed XML files etc.

you see, with REST over HTTP you just skip the XML-generating-and-some-more- task and let HTTP _do_ the work. why reinvent the wheel when HTTP is suited pretty well for this part of the task?

I hope this clarifies everything a little bit.

<comment><USER14> > you'll implement this method and allow your users to invoke it via > <http://myservice.com/employee/simpson>

That's fine of course for the trivial example, but what if my third parameter is an array, and I want to see a sensible error if I pass a hash table? What are the rules for which parameters go in the URL, whether they are delimited by ".", "/", or something else, and when they come as JSON in the request body, and how many there are, and what format they should come in?

> find a library (or implement your own) that will generate all the needed XML > files etc.

Is this a problem? Many many such libraries exist which make exposing RPC calls nearly as easy as writing function declarations. (After all, that's what it's for - remote functions.) When I'm writing normal functions, I don't pass a request type, and a parameter string with various arbitrary delimiters, along with a possible big blob of text, and use that to fit every possible function, dealing with it in my own individual ad hoc way, do I?

<comment><USER15> I have to admit that I haven't experimented a lot with REST, so maybe some REST-experts here on HN will help me out answering some of these questions or give feedback regarding the answers that will follow in the next paragraphs :)

regarding question 1: I think it's all a question of how your method behaves -- or how it is implemented. if your method requires JSON, then you'll have to feed it JSON. if your method requires 2 parameters, then you'll have to give it 2 parameters (e.g. myservice.com/?param1=123&param2=456).

regarding question 2: no, it's definitely not a problem, until the library is not maintained anymore or god knows what else. well, yes, it's more intuitive to write a plain simple function then to construct a very complicated request string as you mentioned.

as I already stated above, I don't have enough experience with REST at the moment to give you a more precise response, so I hope this one suffices. I also hope that somebody here on HN with more experience in the REST field will answer your question more precisely, so I can learn a thing or two, too :)

</comment></comment></comment></comment><comment><USER9> It's shameless-plug-time, I'm afraid:

      http://github.com/regularfry/xmlrpc_annotations

A library I knocked together a while ago to generate C# interface files for an XMLRPC service by annotating the Ruby source. It could be extended to other languages, but I never bothered.

I used it to serve the interface file directly from <http://example.com/service/Foo.cs>. Works nicely for what it does.

To bring this comment lurching somewhat closer to the topic at hand, would this be a feasible approach for RESTful interfaces?

</comment><comment><USER16> The first answer that comes to mind is tooling. At one extreme you have SOAP, where your IDE can make complete proxy objects from a WSDL file. At the other end is REST, where normally you're in luck if there's a nice client library to translate request/response into objects, but otherwise you're left with API documentation. (Is anyone really using WADL?) Somewhere in between is XML-RPC, where you're more than likely to find some kind of reflection method to call such as client.get_methods or something similar.

<comment><USER17> I'm going to take this opportunity to shamelessly plug an open source project I've started for easily turning requests/responses into .NET objects: <http://restsharp.org>

</comment></comment><comment><USER18> I'm not much of a fan of the bloat that SOAP has acquired, but to me the point of something XML-based isn't so much the transport side but instead the API- publishing side. The point of a WSDL or similar descriptor is to define what's available: what methods you can call, what types of data they take, and what sorts of data they return. Generally, you can query the server for the WSDL in addition to actually executing the calls. To me that's the primary advantage, and the reason why a lot of clients prefer SOAP (or some other XML-RPC approach): it's because it provides a clear, published API that you can hand off to someone and have them program against, and there are tools for basically every language that can interpret that API. For statically-typed languages, those tools can also help make sure that your calls are at least syntactically valid, i.e. you're not making calls to methods that don't exist, or passing Strings in for integer parameters, or referencing fields off the result object that aren't there, etc. That might not seem like a big deal, but when you're calling a totally unfamiliar API, it can help you get up to speed much faster, and when you have clients that rely on that API, it really helps everyone's peace of mind when they can be 100% sure that API isn't changing on them.

I'm not aware of an similar, standardized, machine-readable equivalent for REST service documentation, though I'd certainly love to know about it if there is one.

<comment><USER4> True REST abhors the idea of separate "standardized, machine-readable documentation" like WSDL. The biggest point of REST is that _Hypertext Is The Engine Of Application State_ \-- but unfortunately most people focus on bullshit naming conventions that are largely False REST.

Every response should contain hyperlinks to other resources, where the structure/metadata around it indicates what's on the other end. It should still be self-describing even if the URL is completely opaque -- "nice URLs" do not make you RESTful.

You should never need an "endpoint" or any documentation at all, whether machine or human-readable. I should be able to explore your whole API just using HTTP. Ideally you'd use the exact same URLs for your API and browser- human interfaces, using the Accept: header to get different representations of the response.

Almost everybody fucks this up, and just uses 'meaningful' URLs that you're expected to build yourself, and lots of sassy human documentation to tell you what the constants are.

<comment><USER18> I would then argue that REST and XML-RPC fit in different niches and solve different problems, even if there's some substantial overlap between them, so people like the OP that argue that REST completely obviates the need for XML- RPC is missing the point.

Human exploration of a loosely-defined API is great for certain use cases, but doesn't provide the hard API contract and level of tooling that is what lead to the adoption of SOAP in the first place. So people like the OP that whine that people don't get it, and insinuates that everyone who uses XML-RPC instead of SOAP is some sort of unenlightened idiot, aren't making a compelling case if they just ignore the whole reason why SOAP is popular.

</comment></comment></comment><comment><USER19> Keep fighting the good fight, XML-RPC needs to die.

</comment><comment><USER20> _But our clients use XML-RPC_

 _Touché._

Client: But your design is in Latin, which I don't speak...

Engineer: Yes, but Twitter is written in Latin...

Client: You're fired.

Client needs as an afterthought are why engineers are considered by most to be professionals, while programmers are considered fodder for outsourcing to low- wage countries.

<comment><AUTHOR> Just in case there's some confusion: that's exactly my point. Not the part about engineers vs. programmers, but the "client needs trump personal preference" bit. In our case, in order to be players in the industry, we have to support XML-RPC/SOAP.

(edit: typos)

</comment></comment><comment><USER21> XML-RPC is useless now that BERT-RPC exists, imo.

<comment><USER6> XML-RPC is still supported by more languages, and doesn't require third-party libraries for Python or Ruby users. But this looks interesting, thanks for mentioning it.</comment></comment>


New Type Of Killer Whale Found Swimming In Southern Ocean - <AUTHOR> https://www.npr.org/2019/03/07/701101633/new-whale-species <comment><USER2> orcas are awesome, to me, because they showcase cooperation, intelligence, and success unheard of in the animal kingdom. other than humans poisoning them, killing off and poisoning their food supplies, and hunting them, they have no predators or anything preventing their success. they are truly amazing.

i would even argue that they don't "fight" great whites. orcas are faster, larger, and significantly more intelligent than great white sharks. it seems it is an easy enough kill for the pods that know how to hunt them. in fact, great whites off the coast of south africa have been known to leave the area when orcas arrive. that's right: great whites are seemingly afraid of orcas.

it is sad to me humans don't understand them more and still capture and enslave them for entertainment. we also are wreaking havoc in their ecosystems and food sources. they showcase intelligence i am not aware of in any other animal besides humans.

for example, there is a technique they use such that they trick prey that they are leaving. normally, mammal hunting orcas stop vocalizing when hunting. so by leaving the area and vocalizing after an unsuccessful hunt, they relax their prey by signaling they've given up. however, they have communicated to each other to leave a single orca behind that stays silent to catch the prey once it relaxes. then the rest of the pod comes back to share.

<comment><USER3> Apparently they train humans to hunt for them:

[https://en.m.wikipedia.org/wiki/Killer_whales_of_Eden,_New_S...](https://en.m.wikipedia.org/wiki/Killer_whales_of_Eden,_New_South_Wales)

<comment><USER4> Holy crap - that's totally what happened. Fascinating...

"[Killer whale nicknamed] Old Tom's role was commonly to alert the human whalers to the presence of a baleen whale in the bay by breaching or tailslapping at the mouth of the Kiah River, which is one of the smallest rivers... This role endeared him to the whalers and led to the idea that he was "leader of the pack," although such a role was more likely taken by a female (as is typical among killer whales)".

<comment><USER5> Too bad the humans fucked it up by breaking the deal:

>Old Tom forced a small whale to the surface, where Davidson harpooned it.[1] Because he wanted to get off the water before a storm arrived, Logan attempted to bring the carcass ashore without Old Tom eating the tongue and lips.[9] Old Tom apparently grabbed the tow rope in his mouth and lost some teeth in the struggle,[7] with Brooks recounting that Logan said "Oh God, what have I done?" when he realised that Old Tom had lost teeth.[1]

>When Old Tom's corpse washed ashore in 1930, the mouth had abscesses from missing teeth and he may have died of starvation.[7][9][1]

<comment><USER2> it really sickens me how much pain humans bring to the world through selfishness. i had heard of the cooperation story and old tom before, but not the conditions of this particular incident and his death. it seems the orcas in his pod disappeared after being hunted by whalers soon after, according to the wiki article.

<comment><USER6> Be fair. We can bring a lot of pain through cooperation. Cooperating with the orcas seems like a good example.

</comment></comment></comment></comment></comment></comment><comment><USER7> For whatever reason, Orca's are an unusually fascinating subject.

If there is an article about orca's, I'm gonna read it.

The only thing more interesting than an orca, is an orca fighting a great white.

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

<comment><USER8> Awesome amature animal analysis but the alliteration from the announcer is awfully annoying

</comment></comment><comment><USER9> Thanks.

I love killer whales. I also love that its called a "Type D"

Sounds like a different spec setting for "killer"

I wonder, as killer whales are dolphins, if this may be a porpoise/dophin/killer-whale derivative?

I also wonder if the shape of the head, being more rounded, has to do with its sonar capabilities. Perhaps associated with the range, or the spread of its ability to detect/stun critters with sonar.

<comment><USER10> "Killer whale" is a mistranslated. Nobody ever really thought of them as whales. In english, "killer whale" means a whale _that is_ a killer. French and english swap words and this moved from french to english without the swap. The proper translation should have been "Killer of whales" or "whale killer", the thing that kills whales.

<comment><USER11> This seems like a folk etymology, and a dubious one at that. A quick investigation of support turns up a Wikipedia article that's cited to an about.com post that's cited back to the Wikipedia article (where they claim a Spanish etymology), and the Spanish-language article on the topic is cited back to the same About.com post. :P

<comment><USER10> There is knowledge beyond wikipedia. I still trust books

</comment></comment></comment></comment><comment><USER12> One of my favorite visual stories about Orcas and Sperm whales

What makes it even more special is that I've been to the exact spot and seen pods of Sperm whales (sadly, no Orcas)

[https://www.theguardian.com/environment/gallery/2017/mar/29/...](https://www.theguardian.com/environment/gallery/2017/mar/29/sex- death-sperm-whales-orcas-indian-ocean-in-pictures)

<comment><USER2> that's awesome. thanks for sharing that. orcas and whales have some complex relationships. i have seen some research suggesting that humpback whales have begun interrupting orca hunts, even when they're hunting other species and not necessarily humpback whales.

at the end of the story you linked, it seems the orcas did their wave dashing technique on the boat. this has been filmed with the bbc crew having it done to them as well. the orcas had just finished off a seal i believe, and did the same technique with the filmers in the boat.

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

it looks like they were just halfheartedly doing it, so i am curious if they were sending a message or just training or experimenting.

</comment></comment><comment><AUTHOR> Also [https://www.apnews.com/355cf8f5397f439d993431328cbf2bfa](https://www.apnews.com/355cf8f5397f439d993431328cbf2bfa).

</comment><comment><USER13> My understanding is that we think Orcas are speciating already with some focusing on hunting seals and others hunting salmon and they don't have overlapping hunting grounds.

Additionally they seem to differentiate and prefer their 'own' type so we might be actually witnessing a new species there in and of itself.

<comment><USER14> It's hard to be sure this is speciation because orcas teach each other to hunt. So these differences across populations could be cultural!

<comment><USER2> orcas definitely have culture, but these type d really look quite different from other orcas. in an article i read about these type d orcas, it mentioned that scientists have considered before whether the other types should be separate species or not. to my knowledge, they do not interbreed between types, and if they do or can, it is rare. there are other orca types that are still poorly understood, including the offshore orcas in the pacific northwest.

</comment></comment></comment><comment><USER15> This reminds me of the pygmy sub-species of Blue Whale that live in the Indian Ocean.

</comment><comment><USER16> "The team was able to snip off small tissue samples from the whales by firing a harmless dart, attached to a line, into their skin."

Is it just me, or does shooting them with a projectile that tears out some of their flesh seem to not be "harmless", inherently?

<comment><USER17> Or is it more akin to a biopsy? Not harmless, but very unlikely to be more harmful than a scratch.

<comment><USER18> Scratches can be harmful though, they're an easy vector for infection.

</comment></comment></comment><comment><USER19> Truly stunning animals. But why don't they fling us through the air when given the chance..

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

</comment><comment><USER20> Very interesting.

Always fascinated by the Orca species.

It's my understanding there has never been a reported killing of a human by Orcas and that they possess a very interesting and not entirely understood brain.

Apex ocean predator, hunting in packs.

<comment><USER21> Maybe never reported in the wild?

[http://news.bbc.co.uk/1/hi/8535618.stm](http://news.bbc.co.uk/1/hi/8535618.stm)

</comment></comment><comment><USER22> Nature is frightening. There was once a creature swimming in the ocean that even Megalodon feared.

<comment><USER22> Did my quick research. Actually I was wrong. Mosasaurus lived in a different era and adult Megalodon would probably be larger, so looks like Megalodon had no real threats.</comment></comment>


Google launches browser based testing envrioment - <AUTHOR> http://googletesting.blogspot.com/2011/10/take-bite-out-of-bugs-and-redundant.html

<comment><USER2> This looks cool but the link to the project is broken :|</comment>


Writing a Scheme interpreter from Scratch - <AUTHOR> http://lambda-the-ultimate.org/node/3766 <comment><USER2> They're being posted directly here: <http://searchyc.com/scheme+from+scratch?sort=by_date>

No need to post a link to a link.</comment>


At the Door of the Loony Gas Building - <AUTHOR> http://blogs.plos.org/speakeasyscience/2011/08/24/at-the-door-of-the-loony-gas-building/ <comment><USER2> But what happened to Midgley after washing his hands in TEL?</comment>


Google Street View's beefed-up privacy blurs cow's face - <AUTHOR> https://www.theguardian.com/technology/2016/sep/16/beefed-up-google-street-view-privacy-blurs-cows-face <comment><USER2> Google blurs too many signs and street numbers.

Blurring number plates is almost pointless now. There are so many systems recording them that the random ones that appear in Google StreetView barely matter.</comment>


Boeing loses big order for 737 Max aircraft - <AUTHOR> https://www.bbc.co.uk/news/business-48899588 <comment><USER2> Probably the surprising thing is how _few_ orders they have lost. My understanding is that this is because it is very very difficult for an airline to change from Boeing/Airbus to Airbus/Boeing. They need to retool their whole supply chain and retrain all their ground staff and pilots.

...but several airlines are talking about it. Notably American [https://airlinerwatch.com/american-airlines-eyes- airbus-a321...](https://airlinerwatch.com/american-airlines-eyes- airbus-a321xlr-to-retire-its-boeing-757-200-fleet/) and United in the US [https://airlinerwatch.com/united-airlines-considers- airbus-a...](https://airlinerwatch.com/united-airlines-considers- airbus-a321-xlr-for-replacement-of-its-aging-boeing-757s/) are both considering replacing old Boeing planes with Airbus.

<comment><USER3> If you look at the orders by customer[1], you will see quite a few that exclusively or mostly fly 737's.

It would be costly for an airline to have to retrain almost all their pilots, mechanics, etc on a new aircraft...and to purchase all the associated supporting equipment.

And, the Max has significantly better fuel efficiency, seating capacity, etc than other 737 models. Falling back to an earlier model isn't easy either.

They are banking on the general public forgetting about it over time. Which has happened in the past.

[1] [https://en.wikipedia.org/wiki/List_of_Boeing_737_MAX_orders_...](https://en.wikipedia.org/wiki/List_of_Boeing_737_MAX_orders_and_deliveries)

<comment><USER4> > They are banking on the general public forgetting about it over time. Which > has happened in the past.

Which almost always happen. Good strategy. Works for politicians, abusive spouses, big companies. What incentive would they have to do otherwise since society most often offers short outburst of rage, then focuses on something else ?

<comment><USER5> What would be gained by destroying Boeing? And what would be lost?

<comment><USER6> You don't need to destroy Boeing, but we do need to tell them to suck it up and design a new plane. The sooner, the better.

<comment><USER5> There's nothing wrong with the 737MAX airframe. It's a software problem with the MCAS system.

<comment><USER7> Unassisted non-compliance with FAR 25.173 begs to differ.

Keep in mind MCAS would not have existed to malfunction if the airframe was capable of complying with existing regulations unaided.

This fact alone means that the airframe does have something wrong with it.

<comment><USER5> FAA regs require an active yaw damper, because all swept wing airliners would be dangerously unstable without it.

There is no difference in principle here with the MCAS system.

<comment><USER8> Except that unstable pitch is more dangerous than yaw?

<comment><USER5> Yaw instability has resulted in fatal crashes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> All airlines should cancel MAX orders. After watching the CEO defend their position in the Q2 shareholder's meeting, he killed the reputation of Boeing from investors, people and customers. Boeing deserves nothing but financial punishment and consequences of the people that died in the two crashes.

Edit: Link to the meeting [https://youtube.com/watch?v=xOQmQpKHVWA](https://youtube.com/watch?v=xOQmQpKHVWA)

<comment><USER10> This completely unrealistic. CEOs will always defend the company. That is their job.

<comment><USER11> Their job is to maximize shareholder value. Which could certainly be accomplished in some cases by forthrightly admitting to wrongdoing. The problem is that almost invariably this action immediately precedes said CEO deciding to spend more time with his/her family.

<comment><USER12> _Their job is to maximize shareholder value._

This is false. A CEO's job is to run the company. The Board's job is to _protect_ a shareholder's investment, which does not mean maximizing it.

The lie that a CEO's job is to maximize shareholder's value didn't become a popular meme until CEOs were suddenly awarded large stock compensation grants during the Reagan era, and is entirely about CEOs maximizing their personal holdings to the detriment of every other shareholder.

<comment><USER13> This is wrong. CEOs have wide latitude to decide _how_ to maximize value, and how to measure value, but that is still their job.

CEOs raiding short term coffers is a different issue.

</comment></comment></comment></comment></comment><comment><USER14> The problem is, most airlines who ordered or are considering to order the 737 MAX have not much choice. The only real competitor is Airbus. But not only does Airbus alreay have filled order books, so cannot deliver any additional orders in a reasonable time frame, but also this would move the market into a near-monopoly, something that airlines are trying to avoid strongly, as that would remove their negotiation powers with the manufacturer.

This shows, that a duopoly can be as bad as a monopoly and can degenerate into one quickly. Consequently, it should be avoided as much as possible. Merging Boeing with McDonnell Douglas was a big mistake by these events. As was, not to develop a successor to the 737 even long before the MAX development started. After 40 years, tweaking a very successfull design isn't enough any more, there should be a proper successor.

Unless some more large flaws are discovered, the 737 MAX won't be cancelled and it will be bought. The market is trapped. Airlines, who operate on 737 only will have to change their operations soon, as the MAX can be only a gap- filler now. But on short notice there is no other possible replacement available. Boeing will certainly start a replacment design soon, but that won't arrive till the late 20ies. This might of course be the opening for new aircraft companies to enter the market, e.g. Chineese companies or Japanese.

<comment><USER15> In the back and forth, one thing I haven't heard much on is what could have been done to result in a clean-sheet design.

The timeline looks like Boeing was publicly leaning towards a clean sheet redesign until the end of 2011. Then, seemingly out of the blue, American made this announcement on 7/20/2011.

"As part of the Boeing agreement, American will take delivery of 100 aircraft from Boeing's current 737NG family starting in 2013, including three 737-800 options that had been exercised as of July 1, 2011. _American also intends to order 100 of Boeing 's expected new evolution of the 737NG, with a new engine that would offer even more significant fuel-efficiency gains over today's models. American is pleased to be the first airline to commit to Boeing's new 737 family offering, which is expected to provide a new level of economic efficiency and operational performance, pending final confirmation of the program by Boeing. This airplane would be powered by CFM International's LEAP-X engine."_

[http://news.aa.com/news/news-details/2011/AMR-Corporation- An...](http://news.aa.com/news/news-details/2011/AMR-Corporation-Announces- Largest-Aircraft-Order-In-History-With-Boeing-And- Airbus-07202011/default.aspx)

Afterwards, Boeing fairly quickly announces they'll be offering an up-engined 737 NG design.

Presumably the issues were noted at some point in the development process (~2013?).

At that point... the FAA should have been the one pointing out development issues would cause serious regulatory problems? Afaik, they don't have the funding or personnel for that level of design integration.

And like agile, the farther down the road after that decision we get, the more money is at risk and the more constrained options are.

So the answer here seems like deeper and earlier regulator involvement in the development phase?

I'm honestly having difficulty coming up with a plausible sequence of events that would have resulted in a different outcome. When Airbus released the A320neo mid-development cycle for Boeing, the die seemed cast.

<comment><USER14> Yes, I agree. What I meant was, considering that the 737 was designed in the 60ies, they should have a successor development started much much earlier (like 2000). Even with the predecessor of the MAX they were running into ground clearing issues leading to its asymmetric engine housings.

</comment></comment></comment><comment><USER16> Last week Boeing announced that it would give $100m to help families affected by the two crashes.

Thats not even 300k per died person. And if you search for the price for an 737Max, you guess what it's about 100m per plane ..

<comment><USER17> In Indonesia, minimum wage is around USD 1500 annually, and not everyone gets that. Fresh grads in white-collar jobs might get maybe USD 3000 per year, or USD 5000 in the capital. If you make 5 digits you're doing well, like USD 25k per annum for a data scientist or 60k for a head of IT (those would be exceptional top jobs there, mind you). [1]

So, for the median individual in Indonesia it's several decades worth of salary, and it will help the affected families a lot. I assume that the situation in Ethiopia is not too different.

[1] [https://www.robertwalters.co.id/content/dam/robert- walters/g...](https://www.robertwalters.co.id/content/dam/robert- walters/global/files/salary-survey/salary-survey-2019-south-east-asia-greater- china.pdf)

</comment></comment><comment><USER18> > Last month IAG said it intended to buy 200 Boeing 737 Max aircraft.

So they lost an order of 20 planes but recently signed an order for 200?

Not all bad news.

Regardless it's good to see real economic consequences being suffered by a company typically anointed for success by the US gov.

<comment><USER19> I think it's not an order per se, but a letter of intent.

I'm sure it contains some pretty good discounts and opt-outs in case Boeing cannot fulfill their Max obligations.

<comment><USER20> And note IAG currently has a _lot_ of A320s and no 737s: getting the IAG order would be a _big_ deal, but it could equally just be IAG trying to get into a stronger negotiating position with Airbus.

<comment><USER21> > but it could equally just be IAG trying to get into a stronger negotiating > position with Airbus.

And Airbus are negotiating from a much stronger position than they were a year ago. Selling a plane that is actually airworthy does that for you.

</comment></comment></comment></comment><comment><USER22> Less than a months production. For context, Boeing has over 7 years of MAX production in backlog.

</comment><comment><USER23> It's either Boeing loses orders or airlines lose the orders. Knowing what I've learned about the 737 just from reading the news and analysis here, I wouldn't want to get on one for a few years after it goes back into flying.

<comment><USER24> That totally depends on what the fix for the Max becomes. If it is something along the lines of all planes receive the optional equipment as well as software updates that takes into consideration that the human is constantly countering the decisions software makes the human wins, then I'd be okay with it. As it is, you know that all Max pilots have become or are becoming very familiar with how to disable MCAS.

<comment><USER23> How much testing will the fix undergo before being deployed?

How much testing will each fixed plane undergo before the first passenger flight?

</comment></comment></comment><comment><USER25> Good. They deserve to lose it... Let the market correct.

</comment><comment> open-source-ux VOX has a good explainer video on what caused the 737 Max to crash twice for anyone who doesn't know the details. Essentially, Boeing installed sensors and software to automatically push the plane nose down if the plane angle was too steep as it ascended. This software/sensor combination is implicated as the cause of the recent crashes in Indonesia and Ethiopia.

 _The real reason Boeing 's new plane crashed twice_:

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

<comment><USER15> At this point, I think everyone on HN who doesn't specifically block Boeing articles is aware of the reason.

</comment></comment><comment><USER26> Probably politics more than anything to do with the crashes.

<comment><USER27> What do you mean by "politics"?

<comment><USER26> The airline in question is controlled by the government of Saudi Arabia.

<comment><USER27> That's not really an answer to the question.</comment></comment></comment></comment>


Jeff Bezos Is Now Worth More Than Bill Gates Ever Was - <AUTHOR> https://www.bloomberg.com/news/articles/2018-01-08/bezos-s-net-worth-tops-105-billion-as-amazon-climbs-in-new-year <comment><USER2> The article says "Gates is only other person to have built 13-figure fortune" but isn't $100B a 12-figure fortune? I suggested we count zeros instead which would make Bezos a level 11 and Gates a high level 10: [http://www.kmeme.com/2017/11/the-richer- scale.html](http://www.kmeme.com/2017/11/the-richer-scale.html)

</comment><comment><USER3> Measuring paper wealth is an exercise in too many assumptions. It doesn't take into effect any exogenous factors such as interest rates, and depends upon a vast, fragile edifice to protect his property rights--there are probably 100,000 people protecting his net worth.

<comment><USER4> Measuring paper wealth in such an exceptionally massive, highly liquid market with such a long track-record, is extremely easy in fact. It requires few assumptions.

There's absolutely nothing fragile about what's protecting his property rights.

Quite the opposite. It has endured for hundreds of years while the most of the rest of the world has constantly failed and been remade by war, famine, poverty, social collapse, political upheaval and shifting borders.

What political structure or arrangement would you name from the last thousand years or so that has endured better or longer exactly? There are few.

</comment></comment><comment><USER5> ....because Gates gives his money to his foundation (lowering his net worth) and Bezos doesn't.

</comment><comment><USER6> Yes, that's how inflation works.

<comment><USER7> Don't you also have to figure in GDP, etc? It's a relative number.

[https://en.m.wikipedia.org/wiki/List_of_wealthiest_historica...](https://en.m.wikipedia.org/wiki/List_of_wealthiest_historical_figures#Early_modern_to_modern_period)

<comment><USER6> That's right, but the media doesn't think that way. It's always the most expensive painting sold ever, the biggest box office hit, and so on.</comment></comment></comment>


Ask HN: Advice on a Video Skill Sharing Encyclopedia - <AUTHOR>

I'm after some advice regarding creating an encyclopedia of short videos tutorials on life skills to be shared freely on the web.
I classify a life skill as any human task that one person is proficient in which interests at least one other person somewhere. This could range from how to chop an onion to teaching computer programming. The reason for choosing videos as the primary medium is that many skills are better taught by visual instruction, such as cooking, crafting, painting. I would argue that there is currently a lack of comprehensive video instructions for many of these skills on the web.
Similar to Wikipedia, I would like to organise the site like an encyclopedia, in order that there is only one article/video per skill - this is to avoid confusing the users, repetition and to ensure that only the best content is shown as the definitive guide to a task.
I would appreciate any feedback on this idea - is it original? Is it good/bad/stupid/crazy? Also, if anyone is interested in taking this a step further please get in touch.
Thanks. <comment><USER2> Ok.. so, regarding religion, or sex, or sexual preference. WHICH video will present the "correct" position? Will you take a Christian stance on religion, or Muslim, Jewish, etc?

How long will be the video on Sharia Law? Will the segment on the stoning of small children and women be shot with a handycam at an actual event?

Will you show the proper way to hold the rocks, and which part of the head should be hit with proper force?

In other words, define "definitive"?

Cheers.</comment>


Ask HN: Review our website thinktutorial.com - <AUTHOR>

Hi there!
We just released a new website called thinktutorial.com. The goal of the simple website is to provide users with extremely simplified tutorials, and straight to the point.
The main intend is to provide a simple reference for everyone to link to. Let me explain: If a co-worker or family member ask you an IT questions, you usually just say "google it!". Now, you can provide an actual link with free content: ThinkTutorial.com.
The tutorials there do not include programming/photoshop tutorials (yet). Let us know what is missing, what needs to be added, what tutorials would you like to see there ?
The idea of thinktutorial is to genuinely help and provide value.
Thank you in advance for your feedback! <comment><USER2> Very nice clean design, though I was confused as to if the banner at the top was an ad for another company, or if that was explaining your service, as it of course was listing for Lydia.com with the tagline 'what do you want to learn today'.

I suggest that a big banner add there won't do as much for you as describing your service.

That brings me to the second point. You've got all the tutorials nicely lined up at the top of the page, but no real navigation with the exception of the search box. No description of your service until below the fold.

Personally, for a start-up, I'd like to see a description at the top of the page.

Your description says 'Think Tutorial is a database of simple...'.

I wouldn't use the word database as that is a technical description of how you're built. You want to give the user the reason for why you exist, not what you are.

Having the bebo stuff on the front-page doesn't make much sense to most people unless you are in an area where bebo is popular (I have no idea where that is) based on your tag cloud, I think you would be better off with microsoft excel or some tutorials like that.

I think the microsoft office icons are more recognizable than the bebo.

<comment><AUTHOR> Thank you for your feedback!

UPDATE: We removed the most recent post from the front page and currently the page are loaded by rand() every time you reload the page, to show a more diverse set of tutorials.

</comment></comment><comment><USER3> a) Design is nice and clean. kudos for that. b) You could add the application tags below each tutorial icon. Currently you have bebo tutorials on your front page, I do not know the bebo logo so I had to click your view-friends-profile tutorial to see it was for bebo. c) Speed and snappiness for search and tags could be improved. d) Are the tutorials on the front page your best tutorials ? e) Adding some customer testimonials as they come in would be nice.

Overall pretty good idea and execution. Blogspam means that google queries for technical queries is pretty broken now,and something like this which offers reliable reputable howtos within a niche might get user uptake.

<comment><AUTHOR> Thanks for the feedback!

a) Thanks! b) Ok we will think of something more efficient. c) Ok noted. d) No the tutorials at the front are the most recently posted. May be we can add a "Most Popular" Tab? e) It's free, you meant users comments right?

<comment><USER3> I just meant that your frontpage is your chance to wow new users with your best content. So over time you might want your most viewed tutorials to show up there not your most recent. By testimonials I meant if you had some end users write you notes about how much they liked your tutorials you could include snippets of what your users said and which tutorials they liked.

<comment><AUTHOR> Noted. I didn't think of it this way! Great idea!

</comment></comment></comment></comment><comment><AUTHOR> Clickable Link: <http://www.thinktutorial.com></comment>


Auto-antonym - <AUTHOR> http://en.wikipedia.org/wiki/Auto-antonym#Examples

<comment><USER2> Perhaps this is why so many people are confused by the multiple uses of "yield" in programming. For example, in a generator context, the metaphor is that the generator yields (produces) an element. In a threading context, a thread yields (concedes) to other threads.

<comment><USER3> Actually, this is why yield is such an excellent word. If you yield X from a generator, that does two things:

1\. Produce the value X from the generator.

2\. Yield execution to the calling context.

i.e. exactly the two meanings of yield.

</comment></comment><comment><USER4> English having a few words with multiple if opposite meanings doesn't make it hard to learn. It's hard to learn due to the inconsistency in letter sounds, especially vowels, from word to word. Other languages such as Spanish are easy to pronounce because they use the same rules for letter sounds for all words.

Title was changed to be a bit less inflammatory now, or is it flammatory? I think they both mean the same thing...

<comment><USER5> Does most people who learn English as a second language learn both how to read and speak at the same time?

Native English speakers (as with all languages) learn how to speak years before they learn how to read. This makes inconsistencies in letter sounds irrelevant to having good conversational English and leaves learning the inconsistencies later, where you learn common rules that cover most of the language and absorb all the rule breakers while reading.

</comment></comment><comment><USER6> Another confusing one: _inflammable_ , which means _capable of being set on fire_ but follows the same pattern as other words in which the prefix _in-_ connotes negation, e.g. _inflexible_.

<comment><USER7> Further confusing the issue: inflammable means exactly the same thing as flammable.

<comment><USER8> Ugh, what a country!

 _Such a nice day. I think I'll go out the window!_

</comment></comment></comment><comment><USER9> Definitely interesting... but is anyone else finding some of these to be a stretch? "Fast" wasn't very convincing for me since the latter is part of an idiom. "Moot" I'm just straight up disagreeing with.

<comment><USER10> I have no idea where they are getting an additional meaning for "moot". Perhaps they mean the admin of 4chan is worthy of discussion?

<comment><USER11> I'd still recognize both meanings for the _verb_ "moot": to propose something for discussion (to moot a proposal), or to render further consideration of something unnecessary (to moot a court case).

My dictionary says that "moot" as an adjective also has both meetings, but I don't recognize the 'suitable for discussion, under consideration' meaning. Wiktionary says that that meaning is current in the U.K. and "dated" in the U.S.; I'd never heard it before.

</comment></comment></comment><comment><USER12> ...and yet, a child with no prior experience of human language can pick it up without much fuss. So what advantages does a child have over a stereotypical adult learner? I'd say these are the key points:

1\. Lack of assumptions. Words often have multiple meanings, don't assume you know all ways a word is applied, instead pay attention to how context alters the meaning(s) you are already aware of. 2\. Immersion, a.k.a. throwing yourself in at the deep end. 3\. Openness to new information. Could also be highlighted with the word 'playfulness'. Enjoy your progress.

<comment><USER13> Language learning in children is one of the hardest to explain phenomena in psychology, linguistics and neuroscience. Trying to sum it up in three bullet points doesn't do it justice and is a gross oversimplification.

<comment><USER12> What do you find hard to understand about it? We have limited understanding of how our brains work, that I grant you, but if you're looking at the progression we follow in learning a language (i.e. at a more top level view than at the neuroscience level) then the process is much simpler to understand, it's all to do with recognition, association and conversation. Recognition in both the sense of copying sounds we hear and in recognising facets of the world around us. Association in learning to attribute certain sounds to what we experience. Conversation in learning that by making specific sounds and noticing the reaction of others, we show ourselves that the sounds have purpose in the world around us.

As our skill with language develops, so too does our self awareness, which is a whole other can of worms, but the skills we take to start off are simple to summarise, in my opinion.

<comment><USER13> Sometimes a view can be so high-level that you don't see anything meaningful anymore.

All three steps you mention are not nearly understood from either a philosophical or a biological view.

We don't know how an infant recognizes sounds: Is that some innate ability in humans or is that something that has to be learned as well? If the first, what are the basic building blocks of recognizing things? If the later, how is it learned? Think about that what we perceive as language is highly post- processed. A lot of filtering is done on sound before it becomes conscious language. Are those filtering rules innate? Are they learned? How does an infant know the difference between language and other sounds?

Association is even harder. We cannot really start to imagine how association and memory work.

Conversation is less tricky but still struggles with the question: Is it a priori knowledge we use to recognize a reaction?

All your three steps require seem obvious, but are incredibly hard to explain in full. I think you are oversimplifying the problem and only look at the most obvious parts of it. Consider a simple question: Why can infants learn language but not arithmetic given the same process you just described? Basic arithmetic is arguably a lot simpler and about as natural as language, but still won't be learned by most infants. If your answer somehow includes language as a fundamental building block of what makes us human, then you are also taking a stand on some of the things I pointed out earlier and have to unite your theories.

<comment><USER12> "Sometimes a view can be so high-level that you don't see anything meaningful anymore."

High level abstractions are valid tools for building a map of a specific domain. Please understand that having a high level map does not prevent you from exploring deeper if you find the subject interesting, nor does it rob you of the tools to do so... all you need to do is keep on asking 'Why?', 'How?', 'When?', etc... until you're satisfied.

"We don't know how an infant recognizes sounds: Is that some innate ability in humans or is that something that has to be learned as well?"

"How does an infant know the difference between language and other sounds?"

"Why can infants learn language but not arithmetic given the same process you just described?"

I grouped these questions, as I wish to answer them all together. Firstly, I would propose that the recognition of sensory stimuli is innate, which includes sounds. The roots of recognition can be traced back to the sensory stimuli we experience early on. Consider the sound of a baby screaming, which is typically the first sound they make after being born. A baby screaming in pain will typically be physically comforted shortly afterwards. Linking screaming with a subsequent response of comfort could easily be the start of our understanding of language, the senses working in tandem helping our early understanding of the world grow.

Arithmetic is more complex than the relationship between scream and comfort.

"We cannot really start to imagine how association and memory work."

We can 'start to imagine' that though, through neural networks, brain scans, etc....

Please understand, if you are interested in this subject, I appreciate other approaches (such as neuroscience) can help build a fuller picture, but high level approaches are still valid when building up intuition for a subject.

</comment></comment></comment></comment></comment><comment> matt-attack It's missing my favorite auto-antonym phrase "off the menu".

<comment><USER14> You can't add too much water to a nuclear reactor.

</comment></comment><comment><USER15> I'm confused why English is always said to be hard to learn - those concepts mentioned exist in other languages as well..

Even to the opposite, i'm not sure if there's a language where there are _no_ words with 2+ different/opposite meanings?

<comment><USER6> English is a lumpy mishmash of West German, Scandinavian, and Old Norman, leavened with generous helpings of Latin, Greek, and borrowed words from dozens of other languages. That makes for a big basket of grammatical, spelling and pronunciation exceptions held together by vestigial declensions and duct tape.

All in all, a delightful language to read and write if you know it, but a tar pit if you're trying to learn it.

<comment><USER16> I've heard that English speakers are far more tolerant of sentences that don't follow the rules and can still understand what is said (eg "the mat cat sat upon"). A French friend said that it can be difficult to understand if the speaker merely gets the gender wrong.

<comment><USER17> When I played with constructing my own language, one of my concerns was how much poetry and wordplay that a logical semantic consistency prevented. For instance, "I pick... you!" is impossible in a language where the direct object comes earlier in the sentence.

</comment></comment></comment></comment><comment><USER18> Auto-antonyms exist in many other languages. Also the examples are mostly very unusual, or so context-dependent that I'd be surprised if anyone actually made a mistake because of them. Most have a different usage based on the meaning - like "to yield [to sb]" / "to yield sth".

Actually English is rather easy compared to most languages. No genders for objects, no declination, very minimal and rather consistent conjugation, no cases, etc. I wouldn't say it's confusing to learn (relative to other choices).

<comment><USER19> I've heard (from non-native speakers) that English grammar's really easy, but it's the pronunciation and conversely spelling that sucks. It's 90% phonetic, but that other 10% is pretty wild.

<comment><USER17> Ironically, this is because English likes to drag other languages into dark alleys, beat them up, and rifle through their pockets for loose vocabulary. That vocabulary tends to come with a different pronunciation.

</comment></comment></comment><comment><USER20> I would disagree with "cleave" also. "Cleave from" means the opposite of "cleave to", but I would argue that that's because "from" means the opposite of "to", not because "cleave" means the opposite of "cleave".

<comment><USER19> "Cleave from" isn't a valid construction. A little boy cleaves _to_ his mother's leg, but you wouldn't say he later cleaves _from_ it. Similarly, you can cleave a log with an axe (notice no preposition), but you can't cleave it again with all the nails in the world. (Though you could cleave one piece back _to_ the other.)

Notwithstanding the verbs' transitivity, they also have distinct etymologies. From the same Wikipedia article:

> For instance cleave "separate" is from Old English clēofan, while cleave > "adhere" is from Old English clifian, which was pronounced differently.

</comment></comment><comment><USER21> "Citation" can mean "commendation" or a "summons to appear in court."[citation needed]

...Oh the irony

</comment><comment><USER22> another nice big list of these at Wordnik: <http://www.wordnik.com/lists/contronympho></comment>


When OO and FP meet - <AUTHOR> http://blog.jessitron.com/2014/02/when-oo-and-fp-meet-mytype-problem.html

<comment><USER2> I feel like this person has never seen Haskell or done any code that handles contracts.</comment>


TinyPNG launches Photoshop PNG compression plugin - <AUTHOR> https://tinypng.com/photoshop

<comment><USER2> $35 for something I can already do for free? Ok.</comment>