PostGraphile Instant GraphQL API for PostgreSQL Database - <AUTHOR> https://www.graphile.org/ <comment><USER3> I absolutely love the idea of these "thin layer over the DB" systems that turn a database into a "mostly-fledged" API, but my biggest problem with them is the edge cases.

When I need to drop out of the system and do something more, most of them require very specific "plugins" or "tools" to integrate with the system, locking you to that technology pretty hard, and often being difficult to achieve exactly what you need in anything resembling "ideal". Sometimes I need a unique authentication model which is difficult to model with these systems, or I need to do some data conversion or processing on top of what is being stored/retrieved, but only in one small part.

I'd love one of these kinds of things that is flipped around. Let me create the server, let me write the authentication and user system in the application language, then let me define which endpoints I want the "automatic" system to do the heavy lifting on.

Not only would this alleviate my fears of lockin to a technology that might die in a few years, but it would also allow me to start adding it to current projects easily.

<comment><USER4> Hi, PostGraphile maintainer here. Excellent points! This is actually where the powerful GraphQL ecosystem comes in really handy - with functionality such as GraphQL schema stitching (e.g. graphql-weaver) you can use something like PostGraphile to rapidly build your MVP and easily augment it, extend it or combine it with other GraphQL schemas to build exactly what you need. You could also use something like graphql-binding from graph.cool to build your dream GraphQL schema, and then just call out to PostGraphile under the hood - there's no need to expose the PostGraphile schema directly to the public if you don't want to!

With version 4 of PostGraphile I've been really concentrating on the ways that people might want to customise or extend the system, whilst also giving it a welcome speed boost (and reduced memory usage). We're pretty close to a v4 beta now :)

<comment><USER5> I 100% agree with what Benjie said. With things like schema stitching (see [https://blog.graph.cool/graphql-schema-stitching- explained-s...](https://blog.graph.cool/graphql-schema-stitching-explained- schema-delegation-4c6caf468405)) it's getting super simple to compose GraphQL APIs and therefore use PostGraphile as a "GraphQL database".

Static GraphQL bindings even allow to take this even a step further by mapping the GraphQL API capabilities to your (typed) programming language. This kind of gives you a typed "GraphQL ORM" without the typical downsides of a ORM (performance, API limitations etc).

If you're interested, this blog post further describes these concepts: [https://blog.graph.cool/reusing-composing-graphql-apis- with-...](https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql- bindings-80a4aa37cff5)

</comment></comment></comment><comment><USER6> Cool project. But potentially dangerous if used as a CRUD ORM layer.

I'd only recommend using something like this for the read model of a CQRS/Event Sourced system.

Capture the commands and send them to business logic, that then updates the database. If you let a generic framework handle writes, it is like putting the business logic in the client. In that case SQL would be simpler.

<comment><USER7> You can manage that with mutations which correspond with PostgreSQL functions to do the writing in the Postgraphile system.

        create or replace function addFrobnoz (fooId uuid, frobnoz uuid)
        returns void as $$
        declare
            foo row;
        begin
            -- fetch and validate foo wrt. frobnoz
            select insertIntoEventStore(
                   "frobnozAdded",
                   json_build_object('frobnoz', frobnoz));
        end;
        $$ language plpgsql;

Where `insertIntoEventStore` does what it says, maintains a monotonic sequence, etc, etc. Postgraphile can discover the _command_ functions as mutations and map them the GraphQL mutations spec for you. Then your projections just fill in the read tables for you and that's what Postgraphile will read from.

And if you need side-effects like sending email or stream more complicated aggregates there are lots of options in PostgreSQL to use the `notify/subscribe` system or use extensions to publish off to a message queue directly.

</comment></comment><comment><USER8> What's its authorization story?

More generally, how good actually is authorization in graphql?

Official docs seem to essentially say "not our problem!", while various tutorials say "here's the best hack we could come up with".

(just my impression. I really want to believe in graphql, but often the topic appears mostly bypassed)

<comment><USER9> Last I looked for postgraphile, they suggest you hand all that off to row- level authorization mechanisms, which admittedly got a lot more performant in postgres 10.

</comment></comment><comment><USER10> Interesting, I've been working on something similar but the other way around. You define your GraphQL schema and the framework provisions tables. Right now I have a very alpha dynamodb backend, working on Google Cloud Datastore right now. Postgres was going to be next. I don't feel comfortable with it yet to share here.

<comment><USER4> You should consider talking to Johannes Schickling of graph.cool; they seem to be very interested in that sort of thing and they've got some really cool open source going on right now. Johannes is a really nice person - I'd definitely recommend you have a chat.

<comment><USER5> Thanks a lot for the mention, Benjie!

optimuspaul, I'd be very interested in learning more about your project, as this is something we're looking into as part of our roadmap. Would be great to have a chat in our Slack: [https://slack.graph.cool/](https://slack.graph.cool/)

</comment></comment></comment><comment><USER11> In case anyone is curious, this is a rename of PostGraphQL.

<comment><USER12> "NOTICE: PostGraphQL will be renaming to PostGraphile with the release of v4. You can replace postgraphile in the documentation with postgraphql if you're running postgraphql@next"

> > [https://www.graphile.org/postgraphile/introduction/](https://www.graphile.org/postgraphile/introduction/)

</comment></comment><comment><USER9> I have been deep-diving into graphql lately, as it seems like it very completely fixes the client-side N+1 query problem (you can specify everything, including children of children in hierarchical data, that you'll need to render a page in a single fetch request), and the return-to-rpc feel of mutations is also kind of nice after feeling a bit over-constrained by REST conventions for some edge-case mutation actions.

That said, when I looked last postgraphile didn't handle has many and belongs to many relationships out of the box. I do this a lot, with a mostly-standard pattern of naming and so on, with a join table in postgres. This lets me do stuff like "sort this list by the timestamp of when the member of the community was added" (which is an extra column in the join table because it belongs to the relationship between the two entities and not either entity in particular), or put other (often role-based) metadata on a relationship - <USER2> community_profile_membership table has a level column noting whether the member is also a moderator, for example.

So far, I've been building stuff manually using apollo tools and with facebook's dataloader library to reduce the number of queries needed to fulfill the request (most common query scenarios end up with three total queries, one for the root object, one for the relationships, and one to inflate the relationship values). Naturally, this could be fewer if I took postgraphile's approach.

Are there plans for building hmabtm style relationships into postgraphile?

</comment><comment><USER13> I see this as a very positive direction for back-end persistence services. There are similar projects underway for .Net and SQL Server. Also, there are compatible front-end libraries that follow suit. What I find most compelling is to finally be reunited with the RAD (Rapid Application Development) approaches that we had 30 years ago.

<comment><USER5> GraphQL is finally an API standard that strikes the right balance between simplicity and flexibility and has the potential to be the only query language most developers have to learn – and could therefore fulfil the idea of ODBC.

In regards to other SQL databases, we're currently working on a GraphQL database proxy that turns your database into a GraphQL API. We're starting with MySQL but have other databases like PostgraphQL, SQL Server, Oracle, DynamoDB on the way.

</comment></comment><comment><USER14> Whenever I see GraphQL implementations I'm interested in two things:

      1. How do you secure it?
      2. How do you make sure that queries are performant?

Typically these are left "up to the implementation" and are probably both harder than the problem graphql proposes to solve itself. Took at look at this and here is what I could figure out:

1\. Use postgresql's row based access control. This is not a bad solution at all.

2\. No clue. I see that you can write your own custom queries that could be used to optimize special cases, but the point of GraphQL is to be able to do composition and having to use custom queries that do a bunch of things in one query defeats the purpose. Is there any other way that this is handled? Or is just hoping that naive composition of SQL fragments will result in reasonable performance for a majority of cases?

<comment><USER4> Great questions! You're right with number 1: RBAC + RLS (+ custom mutation functions if you need them). For number 2, the solution is currently naive composition of SQL fragments, CTEs, and trusting PostgreSQL to find optimal solutions to admittedly quite complex queries, but this is just the initial implementation. I can confirm that v4 is already significantly faster than v3 at complex queries, but there's still a lot of optimisations left to throw at it (e.g. not converting everything to JSON in the database (which seems to be very expensive), and instead passing down the raw types that PostgreSQL can handle in a significantly more performant manner), and that's before we even get around to writing a query engine that can perform query transforms and optimisations. I hope that PostGraphile can already give better performance than a traditional naive GraphQL SQL + DataLoader solution, but I'm not concentrating on perf right now - correctness first (and tests to back it up), THEN perf optimisations :)

</comment></comment><comment><USER15> Does anyone have experience with long-term usage of these automatic DB to API systems?

I always worry about change management and inefficient designs.

<comment><USER16> I can't talk about PostGraphile, but that's my experience using anything automated. Even your run of the mill ORM's drive me nuts. Abstracting out schemas is fine, but when it comes to query creation, I need to be in COMPLETE control of what is happening.

<comment><USER17> This isn't an ORM, is it? I poked at it in an earlier (PostGraphQL) version and it feels like a query translator from GraphQL to SQL and back, to me, with no munging onto or into objects, at all. ORMs are for people who love their programming language but don't want to touch the database.

This is kinda the opposite of an ORM. Nearly everything is in the database and this is a wrapper that allows you to build your app in your database.

<comment><USER18> You're thinking of code-first ORMs (to use the EF terminology), where you write classes and the tool maps them to tables and queries.

These GraphQL tools, however, act a lot like a database-first ORM, where you provide a database and the tool generates code in a different paradigm (OO for ORMs, Graph QL here). It is indeed the opposite direction, but ORMs can work that way too.

<comment><USER17> Yeah, I guess GraphQL is delivering JSON "objects". Nonetheless, developing for it is a completely different experience from any other ORM I've ever poked at (not saying it's better, just very different).

</comment></comment></comment></comment></comment><comment><USER19> Hmm, isn't that nearly exactly the same what PostgREST has been doing?

<comment><USER20> Edit: Apparently this is based on [https://github.com/postgraphql/postgraphql](https://github.com/postgraphql/postgraphql) which makes sense!

<comment><USER4> This _is_ PostGraphQL, we're renaming to PostGraphile with the official release of v4 which should happen in the coming months.

<comment><USER20> Yep, my bad! Thanks for PostGraphQL, we are using it in production with lots of success :)

</comment></comment></comment></comment><comment><USER21> I know that these ([https://www.nrecosite.com/graphql_to_sql_database.aspx](https://www.nrecosite.com/graphql_to_sql_database.aspx)) guys are working on such component and have adapter for PostgreSQL (based on description)

</comment><comment><USER22> I've played around with Postgraphile extensively and it's a wonderfully refreshing way to build apps.

That said, you are programming in Postgres instead of your language of choice so the learning curve is real. And refactoring code felt more complicated because you have to delete a constraint and then add one back in, you can't just modify a constraint in Postgres.

So, if you have your app mapped out it definitely is faster than most other app generators. But, for ongoing maintenance and custom functionality like image uploads it feels more complicated to me.

</comment><comment><USER23> Fascinating. Anyone using this for their side project or in production?

</comment><comment><USER24> I was confused how this compares to PostGraphQL at first, until I read in the footer:

> "PostGraphile was originally authored as PostGraphQL by Caleb Meredith."

This should probably be made more obvious from the get-go.

<comment><USER4> Yeah, renaming things is always painful. We're renaming the project because "GraphQL" is owned by Facebook and we don't want any trademark disputes down the line. We've mentioned the rename in a number of places but I suppose we could always add it to more places - where would you suggest?

It's worth noting that the entire GraphQL schema generation in v4 is a ground- up re-write (that's where the "graphile" comes from - it was originally a separate project), we've kept the top level APIs from v3 though (e.g. the web layer). This has enabled the performance improvements, plugin system, and greater customisability.

</comment></comment><comment><USER13> I'm curious if this is compatible with AWS Aurora, and if anyone has tried it

</comment><comment><USER25> Anyone else find it kind of funny that this feel like an ORM? We come full circle!

<comment><USER26> graphql on postgres is literally orm. objects are graphs. and graphql inherits all the same problems as the last 1000 attempts to do this. unless you're facebook who uses an eventually consistent graph datastore!

<comment><USER27> Developers run into all kinds of trouble when they use an orm without understanding the underlying execution model. Before starting Graphcool I lead the team that scaled a consumer site into the top 1000 visited sites globally. A well tuned SQL server and Hibernate took us a long way :-)

One of the biggest foot guns when working with ORMs is lazy data loading. This is a feature implemented by most advanced ORMs that allow the developer to pretend that the entire data model is in memory without having to actually fetch all data on every request. The reason this is so dangerous is that you end up passing objects around that other developers then misuse to fetch "just a little more data". Over time this can lead to tens or hundreds of roundtrips to the database for a single request.

GraphQL tackles this issue head on by encouraging the developer to specify all data dependencies up front. Client side tools like Apollo and Relay even help you collect data requirements from multiple related components and construct a minimal covering query. This means that there is only one request, and the underlying query engine has all information available.

I'm pretty excited to bring these same concepts to the server with GraphQL Bindings: [https://github.com/graphcool/graphql- binding](https://github.com/graphcool/graphql-binding)

<comment><USER26> Declaring data dependencies is interesting, but unfortunately the vision you describe is not possible in the general case. Just in contrived toy cases. You show me a Facebook scale application hydrating its data in one request, and I'll show you that it isn't built on RDBMS. Case in point: Facebook. Case #2: GraphQL has a shitty programming language built into it, to make decisions about data fetching closer to the database.

Perhaps we should code the entire app in stored procedures? (which might even actually work)

<comment><USER13> Absolutely you should code the entire app in stored procedures. The arguments for doing so have long been stronger than the arguments against doing so.

<comment><USER26> Where can I learn more about this?</comment></comment></comment></comment></comment></comment>


Mozilla overhauls Firefox smartphone plan to focus on quality, not cost - <AUTHOR> http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/ <comment><USER4> Trying to shoehorn a performance hungry HTML5 OS on low-end phones was a complete waste of time. Just read this review of the $35 Firefox phone [1]: it's completely unusable to the point that even typing is difficult. What an embarrassment.

I bought the mid-spec Flame developer device out of curiosity, and it's not much better. Everything feels slow, sluggish and unresponsive. Even Android 2.x was better.

My quad-core i7 desktop still occasionally struggles to render the latest and greatest HTML5 stuff at 60 fps. How on earth do they expect a phone to do the same?

[1] [http://arstechnica.com/gadgets/2014/10/testing-a-35-firefox-...](http://arstechnica.com/gadgets/2014/10/testing-a-35-firefox- os-phone-how-bad-could-it-be/)

<comment><USER5> Android 2.x was not better than Firefox OS 2.x IMHO. I have them all here and I really enjoy the Flame running 2.x, it was my primary smartphone until February.

One don't need HTML5 at 60fps. One need HTML5 apps that work. Movies are not 60fps. The only place where you need 60fps is games and that type of game is not the objective of the devices you've seen running Firefox OS.

What is needed is quality HTML5 apps. The old Pre2 and Pre3 webOS devices had some pretty amazing HTML5 apps. The usability was great even if the phone slowed sometimes. UX is better than FPS. Usability trumps benchmarks.

The problem is when you code for the high-end place of the spectrum with evergreen browsers and stuff and try to shoehorn that into a phone. thats when misery happens.

Instead of reading a review from written by someone used to high-end devices and ubiquitous networking. Look for those people in India and South America who are buying Firefox OS devices as their first smartphone because they couldn't afford a higher-end device. Look for their feedback. Many are accessing the web on a personal device for the first time. Its a life transforming opportunity once the doors to the vast knowledge repository of the web is open. I can go on for hours on where Firefox OS shines but I will not bore you. Just don't try to compare it against Android and iOS devices, that was never the objective.

<comment><USER4> > One don't need HTML5 at 60fps. The only place where you need 60fps is games > and that type of game is not the objective of the devices you've seen > running Firefox OS.

Smooth response is absolutely essential for touch usability. Without it, you can not have any sort of precision on an already imprecise input method. To achieve this, you really do need to near 60 frames per second.

When the simplest list (let alone a complex web page) constantly trails behind your finger and has to catch up with rendering, it becomes very difficult to find what you're looking for. It's crucial that what happens on screen is connected to what you're doing, or you have to constantly try and consciously correct for the software that just can't keep up.

A budget phone doesn't need to match the latest and greatest iPhone 6 in smoothness, but there is a baseline performance that has to be met for usability.

> Many are accessing the web on a personal device for the first time... just > don't try to compare it against Android and iOS devices, that was never the > objective.

If you actually read the review I linked, it turns out the $35 phone is practically worthless for any web browsing or just about anything. And once you go past that price point, FxOS has competition. Android One and low-end OEM's like Micromax already provide devices that are years ahead in performance, usability and functionality.

<comment><USER6> > Smooth response is absolutely essential for touch usability. Without it, you > can not have any sort of precision on an already imprecise input method. To > achieve this, you really do need to near 60 frames per second.

I would love to see mobile devices that are not touch based. Touch requires a very high premium on performance. Buttons would have worked wonders. For a FirefoxOS phone where it is Gen 1, the start should have been a button phone and every developer would be required to create an interface that would work well with buttons.

<comment><USER7> Yes, I personally would love to get back to having real tactile buttons. It feels sort of crazy that your only choice any more is a touch screen--I think there might be a market in higher end devices without a touch screen too.

</comment></comment></comment></comment></comment><comment><USER8> This is a welcome change from Mozilla, but I think they should take it a step further and ditch Firefox OS completely. The original reason d'etre of Firefox OS was that it would run on lower spec'ed and cheaper hardware than Android could, but that's not an efficient use of their limited resources for a couple reasons: 1) Mozilla could contribute to Android to improve it's performance on cheaper hardware. 2) Moore's law is making powerful hardware more affordable for the world's poorest people, faster than Mozilla can get Firefox OS and an attractive app ecosystem off the ground.

Mozilla should instead focus on freeing Android from it's dependency on Google. Everyday, apps become more and more dependent on Google Play services, the proprietary set of libraries that Google controls on Android devices. Developers need an open version of Google Play Services (Mozilla Mobile Services?) and even a competitive app store (10% commission instead of 30%?). The natural next step would be to create their own distribution of Android and release it on quality hardware. Not only would they be furthering the cause of free software and open computing, but they would have a revenue stream to continue their mission.

<comment><AUTHOR> You're confusing strategy with the objective that strategy was intended to achieve. The real reason for Firefox OS was because

a) everything is moving to mobile, and

b) every mobile OS ships its own browser which is not Firefox.

We know from Netscape how hard it is to stay relevant against that kind of pressure, and there isn't even a way to cry "Anti-trust!" because none of these players are monopolies. They just all behave the same way.

<comment><USER8> If Mozilla creates their own distribution of Android and sells phones with it, then they're extremely relevant in the mobile space. Take a look at the principles of the Mozilla manifesto[1]. Nowhere does it say, 'we need to have a relevant web browser'. It's a bigger mission about an open internet, unrestrained communication, libre software and ultimately end-user sovereignty. When Mozilla.org was created, the best way to achieve those goals was by having an awesome libre browser. As you rightly point out, the world has gone mobile, and the way for Mozilla to continue their mission is by releasing a mobile OS built with their principals in mind. If this was 2007, building Firefox OS may have been a viable strategy. But it's 2015, and the quickest, and in my opinion the only, way to succeed is with a distribution of Android with Mozilla services.

[1] [https://www.mozilla.org/en- US/about/manifesto/](https://www.mozilla.org/en-US/about/manifesto/)

<comment><USER9> You make a good point. One possible objection: does that actually allow them to do what they are trying to do? Is Android flexible enough for them to bend it to their will?

</comment></comment></comment></comment><comment><USER10> I've always thought that Mozilla's strategy with Firefox OS was very optimistic/ambitious. It was first conceived just as cheap Chinese Android smartphones were beginning to make inroads into developing markets[1]. In such markets, simply reducing the cost of the phone from $80 to $25 won't increase smartphone penetration as much as you might think because the cost of the phone itself comprises only a small part of the total cost of ownership - <USER2> customer still has to pay for a mobile data plan.

That leaves the "open web" approach as the major differentiator between Firefox OS and Android. Whilst I'm a fan of open standards, I doubt the average consumer is going to care enough for Firefox OS to make inroads into Android's dominance of the low-cost smartphone market (in fact, I'd question whether they'll care at all).

At this point, if I were on the Mozilla Foundation board, I think I'd be pushing for a cost-benefit assessment of continued investment into Firefox OS.

1: [http://www.technologyreview.com/news/424454/android- marches-...](http://www.technologyreview.com/news/424454/android-marches-on- east-africa/)

<comment><USER10> Coincidentally, less than 24 hours later, this story crops up, demonstrating how different the mobile phone market is in developing markets: [https://news.ycombinator.com/item?id=9604049](https://news.ycombinator.com/item?id=9604049)

</comment></comment><comment><USER11> I can't help but feel some "couch coach" desperation with Mozilla's confusion at where should they aim at.

Google has Android which is open source but "spyware" prone and suffers from vendor incompetence/uninterest in updates -- in fact this will bite Google sooner or latter. While Apple's iOS is privacy aware but closed source and carries a huge price premium.

On the other hand Mozilla is known for open source and for caring for privacy. Furthermore with Snowden's revelations, at least among the IT crowd, as well as governments, there is interest for a secure system.

Give me a high-end phone [1] which focus on privacy.

Something that supports a stack like Xposed and Xprivacy out of the box.

Something whose baseband processor is decoupled from the other processors. And if possible the source code for the sensors or at least the ICD, so that you have an alternative to binary blobs.

Give me something that supports encryption and can get consistent no hassle OTA updates.

And make it with a compatibility layer to Android's apps [2]

I'm all for open source, but Android just ends up being nothing but an headache. A better solution would be welcome.

[1] just look at the OnePlus One for $350 [http://en.wikipedia.org/wiki/OnePlus_One](http://en.wikipedia.org/wiki/OnePlus_One) In fact Mozilla should have partnered with them.

[2] [http://en.wikipedia.org/wiki/Hybris_%28software%29](http://en.wikipedia.org/wiki/Hybris_%28software%29)

<comment><USER12> Does iOS really carry a price premium? My experience, similar to the old Mac/PC debates, is the difference is actually minimal at most when you compare with actually equivalent hardware.

<comment><USER13> It only exist in the premium class, so in that sense, if you want iOS just for the iOS, you are stuck buying premium hardware.

I do think iOS devices are generally a good deal (in the sense that they are worth the money),but that doesn't mean they are not premium nor premium priced. Quality costs money.

</comment></comment></comment><comment><USER14> I have never understood the "we'll win at the lo-end" approach. Android was designed for lo-spec devices. ART has moved android a little bit away from that focus, and so has some bloat in Google's proprietary apps. But Android can still be tuned for and run on very modest hardware. Competing against Android on lo-spec hardware is not a winning plan.

For the class of IoT devices that are capable of running Linux, Google thinks they can turn Android into a "headless" configuration that uses Android's runtime and base classes, presumably minus the UI classes. Android is, in fact, pretty darn efficient.

And on top of all that, Mozilla thought a Web runtime could be made as efficient as a Java-ish runtime that has a very memory-efficient component architecture? That's just strange.

</comment><comment><USER15> I really want Firefox OS to be a success. After working in AOSP firmware for last 5 years and dealing with vendor walled gardens, I wish there was a truly usable open source phone.

<comment><USER16> Firefox OS isn't any better than Android when it comes to vendor walled gardens. Mozilla doesn't enforce in any way any openness of the platform - <USER3> just provides the open OS. It might be more complete experience than what AOSP alone delivers, but it's still up to vendor to provide, or not, any freedom when it comes to usage of the device.

Heck, your platform doesn't even need to be open to be able to market it with Firefox OS brand! They have a set of rules you have to fulfill, but basic stuff like unlocked bootloader isn't even part of them.

</comment></comment><comment><USER17> This sounds like a good change. Hopefully it would bring in a really good experience, not just a clone of the Android One series that compromises on hardware because of price.

Quoting from the email, "This will be the phone that you want to use, and will use every day." For this to be true, these are some of the key things for Mozilla to focus on:

* The responsiveness of the UI.

* A good camera (at least 5MP).

* A decent amount of memory to hold multiple apps (in dormant mode) and reduce startup times of recently used apps.

Running Android apps may be a good interim strategy while apps targeted and optimized for Firefox phones are developed. But this assumes that the phones can run them well. Otherwise it would just backfire completely, leaving Firefox phones as useless devices.

I can't wait for a well performing Firefox phone that's widely available (even if that means costing a few hundred dollars or equivalent)! It'd be great if Firefox can come to fourth place or (gasp) third place in the mobile OS wars.

<comment><USER18> Third place is going to take a lot of work. Microsoft sold 8.6 million Lumia phones last quarter.

The only way I see it happening would be if Mozilla gets some big partner in e.g. China to push Firefox phones.

<comment><USER19> And Microsoft is only able to sell as many thanks to Nokia's brand recognition prior to buying them (Nokia was selling 95% of all of the Windows Phones before Microsoft acquired the phone division - which just shows what a huge impact Nokia's brand name had on Windows Phone, and without it WP would be at <0.5% market share).

<comment><USER20> The phones sold last quarter were not branded Nokia.

<comment><USER21> New Lumia models introduced were branded Microsoft. Previous Lumia models launched as Nokias (830 etc) remain Nokia branded.

</comment></comment></comment></comment></comment><comment><USER22> Sounds like they have no idea what to do now. Not having any apps is probably the biggest disadvantage that can't easily be undone. Android compatibility needs to be to the point where it's flawless for this to make any sense. Personally I'd rather see iOS compatibility but that's very unlikely to happen.

Different idea: why not work on something like PhoneGap that's powered by Firefox? If you can create a super powerful framework/dev environment that rivals native (and uses all the smarts and resources of Mozilla to address all current flaws of these existing frameworks), then you could have devs building in a more cross platform & "open" manner. From there you might actually have enough apps compatible to run Firefox os, or better, have that not matter as much because you're what's underneath every app.

I have a hard time seeing Mozilla make inroads at this point otherwise.

<comment><USER23> I don't think the flaws in phone gap and other tools are things that Mozilla can fix, at least not without support from Google/Apple, who really have no incentive to help.

</comment></comment><comment><USER24> Mesh networking is the killer mobile app - FirefoxOS should focus on this, as it fits with their ethos.

The developing world doesn't need telephones, they need secure and convenient means to transfer data wirelessly and code that works with sporadic, slow, shared connectivity. Frankly, they need crypto plus mesh networking.

Make it a platform for privacy-controlled social networking, high scores, app updates ... it should differentiate far enough to win users.

Basically, make it the hacker's choice ... then, you'll get applications, too.

A cheap version without GSM or CDMA would be an option.

<comment><USER25> Mesh networking + crypto seems to be an incredibly disruptive technology that I'm surprised hasn't seen wide market adoption. The technology obviously exists and works, as it has been shown being used by protesters or in disaster relief areas. Why has this not been proliferated world over, from developing countries to cheap internet providers? (Not calling anyone lazy or stupid, I'm legitimately curious as to what social, technical or legal roadblocks must be holding this tech back)

<comment><USER26> I ran a mesh networking startup about 2 years ago. A few details about it are here: tricorder.org/eric/uplink.html. From my perspective, there are two main barriers:

1) It's hard to explain to customers who are used to the current ISP internet access paradigm. This barrier can be overcome.

2) Not only do you need to win customers, you need to win a critical mass of customers within a focused geographic area. #2 is very, very hard imo.

<comment><USER24> First up, good job writing up your idea in hindsight. I think it differs slightly from mesh networking on mobiles with high latency transfer expectations / custom apps fairly significantly. You were trying to provide the internet as a service for free in real time, I think the killer app is actually embracing store and forward again.

For problem #1, if it works at the consumer level then I think people don't really care about _how_ it works.

For #2, I think the current model of 'use free wifi from coffee shops, hotels, bars, restaurants' that seems globally dominant would work fine.

</comment></comment></comment></comment><comment><USER27> So Mozilla's clever idea to attack the low end of the market outside the US has failed and now they want to pivot. The rub is that now they are competing with Android and iPhone, which have years of head start and gigantic app stores. They aren't pursuing compatibility with those existing app stores, so that will be a disadvantage. And they don't have resources like there are behind Windows Phone.

Even to take a niche, they need a remarkable positive differentiator. As the quote in the article says, "In the mass market, that's basically impossible." Rhetoric like "change the world" isn't it - the specifics matter. "Embrace the web" isn't a differentiator when all Smartphones can browse websites. I welcome you to find in that article anything but a few planned features which might just keep Firefox OS alive without necessarily giving it a competitive advantage.

After watching a few years, I'm not sure even Mozilla knows what the differentiator will be to consumers, because what I always see from them in this kind of press-release piece are vague phrases like "the open web". So for years I have been a little confused about exactly what they are trying to do. A possible clue is that whenever you drill down on projects to which these catchphrases have been applied, what it really boils down to is more Javascript. Please try an experiment: every time you see "the open web" mentioned by Mozilla, see if the same sentence makes as much sense substituting "Javascript."

For years this has bothered me because "the open web" does not literally mean "Javascript," yet Mozilla and its fans consistently equivocate between the two. What I realize now is that this isn't because Mozilla is confused about the difference, it's because their core allegiance is to Brandan Eich's brainchild and phrases like "open web" are just a chosen mode of evangelizing Javascript. Maybe Mozilla doesn't know exactly what an all-Javascript world will exactly bring to consumers, but they want it anyway because that is their understanding of their mission.

The problem with this is that Javascript advocacy doesn't necessarily have a lot of benefit to consumers or even to programmers other than diehard Javascript fans. To be plain, basically nobody gives a rat's ass if their phone uses more Javascript than Java. It doesn't make anything more open to use Javascript rather than other technologies, openness is a matter of licensing and maybe development process. In practice you still end up with a lot of Javascript APIs specific to Firefox OS (and therefore a collection of apps).

<comment><USER28> I don't know how you're missing it but apps on phones are like desktop software vs the web. Mozilla wants to win that battle and make it possible to use the open web on multiple devices. You won't be limited to a particular OS and APIs, you can just use FireFox OS or the browser and you're good to go. Using JavaScript is an alright decision especially when you have asm.js and you have TypeScript and flow if you want static typing or type annotations.

The flaw in the plan is that no one has tried to get something like Google Docs working on Firefox OS/Mobile and then tried to tune and optimize performance until it worked properly.

If they focused on getting heavy websites to load in under a second come hell or high water, they would have made the web browser king on the phone. Instead we have Facebook cutting out the browser by caching the content of news sites.

<comment><USER29> >You won't be limited to a particular OS and APIs

You will, of course, be limited to the APIs available in standard Javascript. At the moment that means missing a lot of things that people might want to be able to do (or need to be able to do to write things that act like freestanding apps instead of websites). The way Mozilla tried to get around that was to add a lot of Firefox OS specific APIs and then claim that those APIs were part of 'the open web' because they were going to submit them for standardisation at some point in the future.

Mozilla seem to think that they are the sole arbiter of what the web standards are. The APIs they want to add are 'open' and 'standard' and anybody who is against adding those APIs is an entryist enemy of 'the open web'. APIs proposed by other vendors that Mozilla dislikes are an attack on the open web.

That's not how it works.

Things only become standards (formally or de facto) when all (or nearly all) of the big browser vendors support them. That's the definition of an open standards based platform - it's lowest common denominator. If you don't like that reality then you don't like open standards based platforms. There was little sign that the other browser vendors had any interest in adding a bunch of FirefoxOS specific APIs (just as how Mozilla have rejected various proposals from other vendors over the years).

You can argue that all this is very unfair. Why should Apple and Google and Microsoft have veto power over what APIs are available on FirefoxOS? But this is a trap of Mozilla's own choosing. It's the fundamental problem with the dream of a single platform standard for all user facing software. It creates a tight sandbox (both software architecturally and politically) that gives the big players veto power over everything. The idea of a single grand standard platform with perfect compatibility across all devices is certainly alluring, but it has huge downsides that nobody ever seems to really want to talk about. And that's before you get to the technical issues to do with the web standards being pretty crappy for complex GUI development.

</comment></comment></comment><comment><USER30> So, mobile devices are an aspirational purchase in many of the developing nations Mozilla was reportedly targeting with these devices. People buy phones that _look like_ high end phones in the US, because that's part of what they want from a phone.

I'm not saying low cost phones in developing nations aren't a good goal. That's a wonderful thing, and I think I can understand how the people at Mozilla, who almost always prioritize doing good over doing well, would make the mistake of thinking that building a phone that is good for people in the developing world would be a good way to start their mobile effort.

But, and as much as I hate to say this because it reveals a crass consumerism that has infected the world and patient zero is the US, the reality is that modern phones are luxury items that need some of the trappings of luxury...even in developing nations, where they look to the west to define their fashion and trends. If Mozilla can't win a developed world market, they won't be able to convince people in developing nations that what they've built is worthwhile, _especially_ when there are knockoff Android devices that only cost a few bucks more, which are much closer to what people in the developed world are using.

I could see how it might even seem patronizing to the poorest folks.

I don't know what Mozilla should do; I'm not a mobile mogul. But, I want a Firefox phone. I've wanted one since they announced they were making them. I want one a lot, actually. But, I don't want a shitty phone that's less powerful than my last three Android phones, no matter the price. It's also never been clear to me, as an American, where I can even buy a real FxOS phone. There are dev phones, but they seemed to always just be "sign up for our waiting list" or whatever, which is not something I really do.

</comment><comment><USER31> Focus on one app: Whatsapp. Say this is the mid 90's and you want to make a dent on the mobile market. So you keep costs low and put a cheapo camera on the thing along a semi-decent mp3 player. But there is one big problem: your Konia 1 phone does not run SMS. Nobody buys the thingy. What went wrong? Oh, its quality, let's put a hi-end camera and try again!

It's all about the apps that people use. Remember MS Office? Oh, nice Macs said the IT managers, do they run MS Office?

Go cut a deal with Zucker and get Whatsapp for FFOS then the phones will sell.

<comment><USER32> They must be aware of this since LINE does run on Firefox OS. I think deal is in progress.

</comment></comment><comment><USER33> There is room for FirefoxOS:

\- No performance regressions. Somehow, the blazing fast device I bought a couple of years ago now feels sluggish. Core apps should be timeless: the dialer, the keyboard, task switcher shouldn't be slower two years after purchase.

\- Graceful degradation. Websites have no easy way to detect how fast a device is, so they are built for the majority with a bias for the newest and fastest. The result is that cheap and old devices get obsoleted even for the simple stuff. If a $25 phone is as powerful as a 2000 computer, then let the developer feature-detect it and design for it.

\- Good permissions. I don't know the solution but there's a problem. Android's model is depressingly bad. iOS's is too dumbed-down to be trustworthy. Firefox's granularity is good to have but web developers seem to assume the user is always going to grant the permission. I always grunt at websites which want my position to find a store near me and display a blank page when I reject it.

\- Timely OS updates. Firefox already has a fast release cycle regardless of the desktop OS. Why can't mobile be the same? I believe kernel patches are less of an issue with web apps because the kernel isn't the first line defense.

\- Reasonably priced. The $100-200 range is already full of good Android devices. Just make deals with manufacturers to sell a Firefox version of those. They already sell dozens of different phones, so it should be feasible to convince them to add a couple identical devices with a different OS. FirefoxOS only needs one good device.

\- Security. Better sandbox the blackboxes (drivers and radio).

Those were my pain points, but I'm willing to make sacrifices:

\- 60 FPS isn't that important for me. I care more about response time when I tap something.

\- Most animations/transitions won't be missed. Some add value but marginally so. Most are arbitrary and useless.

\- Most apps won't be missed. I only use a few.

Apple is margin-driven. Google is ad-driven. They already cause pain to the consumer and market dominance will only make matters worse. They also are walled gardens so they cause pain to the developer. Mozilla is indeed in a similar position to that of the 2000s.

</comment><comment><USER34> I have wanted these phones for the longest goddamn time.

The LG or KDDI Fx0 was the coolest looking phone I have seen in the last 5 years. But it was unreasonably priced at nearly 400 USD

I recently stumbled across the geeksphone revolution which actually seems to be a high-end phone and at a nice pricetag of less than 200 USD.

</comment><comment><USER35> Rust could be a great platform to build a new mobile OS on. Non-garbage collected so it'd be fast and efficient on low-memory ARM devices. Just like Obj-C really gave iOS a headstart on java-based Android. Doubly-so if they want to continue to target the low-spec end of the market.

</comment><comment><USER36> I used a Keon as my only phone for summer 2013 – summer 2014. Basic apps were good, but — ironically for a web-based phone — the _browsing_ experience was my biggest negative. Not the actual page layout/etc. — that is just Gecko and worked fine if you didn't try to open too many tabs. The problem was the browser lacked basic features like find in page, sync, and adding search engines.

I switched to a Moto E, and I think it actually lags a little more for things like opening the clock app, but I'm basically addicted to Fennec's reader view and sync.

(The "system browser" in FxOS 3.0 is also a major regression on tab UX IMO.)

<comment><USER37> I think the system browser in 3.x is a significant UX improvement. The old browser app always felt like trying to impose an Android-like world-view on a system where the system was supposed to be a browser all along.

<comment><USER36> I get that and thought I would like it, but I guess I still use the (web) apps and the web browser quite differently. I hope further refinements change my mind!

More specifically, I tend to open and close a lot of tabs, which involves more steps now, and I want new tabs to open in the background.

</comment></comment></comment><comment><USER38> Something I don't see talked about too much, but what I think could be the most exciting thing about the Firefox phone, is that a web app (hosted on the web) could have full access the the dialer, sms, camera, and all of a phones capabilities.

I think then you might see a whole range of independent homescreens and app suites developed and offer some well designed alternatives.

I'm a nexus 4 user and I really don't like all the basics. The dialer, contact list, messaging. I think they are confusing and difficult to navigate.

</comment><comment><USER39> I never understood their focus on cheap phones. Firefox OS (and web technologies in general) is a poor fit for low-spec devices.

</comment><comment><USER40> The fact that ubuntu and mozilla are both launching open phone platforms that compete in exactly the same space baffles me. The fact that ubuntu has it's own browser based on blink, and firefox is convinced that all you need is a browser is just....

</comment><comment><USER41> Mozilla could make a rustphone where apps run 10X as fast as all that webby crap, never crash, and don't force the user into frequent hardware upgrades just to keep the UI responsive. Make smartphones that are as reliable as dumbphones.

</comment><comment><USER42> I would love it if someone would come along and offer an android experience while applying an value framework like the Mozilla manifesto. Not saying this _has_ to be Mozilla, though it would make sense for them to do it.

</comment><comment><USER43> My idea of a quality Smartphone:

Small (ipod mini or nano sized),

Durable and Water proof,

long lasting battery,

E-inc (or similar) display,

Able to play music while using navigation

and

Able to play music while browsing the web.

If Mozilla can put this phone together I'll buy it in a heartbeat.

<comment><USER44> I'm not sure something that small would be useful for many "smart" tasks. I recon about 3.5 inches is the sweet spot.

<comment><USER19> There's _no way_ 3.5" is the "sweet spot" these days. Maybe for primary school students, at most. Otherwise kids want phones with larger screens these days, too. I'd say 4.3" should be the minimum for just about anyone. Phones are more compact than the days of iPhone 1, and most of them are 16:9 now, which would make 3.5" way too cramped for using the keyboard.

</comment></comment></comment><comment><USER45> Why not both? Choice is good, and unless there is a good reason for only being able to choose one, I'd say offer devices is various price ranges.

</comment><comment><USER46> Can someone shed some light on why they would now allow android but not native app(aka not JS based)? It seems strange.

<comment><USER47> There is an apkjs IRC channel on mozilla [1] so they might cross-compile Android apps via emscripten to asm.js. Couldn't get any info from moz when I asked around in that channel.

[1] [http://search.mibbit.com/networks/Mozilla/%23apkjs](http://search.mibbit.com/networks/Mozilla/%23apkjs)

</comment></comment><comment><USER48> If that's the plan, won't it make much more sense to start from open-source android and move from there ?

<comment><USER49> Only if there's a realistic way to put emphasis on the web part again at some point. Otherwise they'll just become yet another Android-alike (effectively handing control over the platform to the Android developers at Google).

The nice thing about web technologies is that there isn't a single party that controls the APIs. I don't know any other comprehensive API collection with this property (POSIX is in the same ball park, but which POSIX-only application is mass market compatible these days?)

</comment></comment><comment><USER50> I'm still confused as to what Mozilla actually does.

At one point they(or the company that spawned them) built a web browser that they sold. Then they were the non-profit offshoot of that keeping an open source browser alive.

But now they're... erm... what is it exactly that they are? They're a non- profit that sells browser searches, or something. I'm confused.

<comment><USER30> [https://www.mozilla.org/en-US/about/manifesto/](https://www.mozilla.org/en- US/about/manifesto/)

In short, they try to save the Internet from being run by a few corporations or governments. So, minus cape, they're trying to do superhero things that are often at odds with the biggest companies in the world. Whether they succeed in that with any given project is up for debate, of course.

So far, Firefox phones have been a flop. Personally, I want one, because I care about privacy and I care about the open web, but I don't really want a shitty $25 phone. This news is good for me, but I don't know what it says for Mozilla's vision in the mobile market.

I've heard people suggest that Android took a while to catch on...but, it really didn't. By the time Android had been on the market for a year, it was clear (to me, anyway) that it would become the dominant player for many of the same reasons Wintel became the dominant desktop platform. Firefox OS doesn't have much to show for the time they've been on the market. It was never even clear to me I could buy a "real" phone (i.e. not developer phone) in the US running FxOS.

</comment></comment><comment><USER51> So my comments the other day [1] were pretty to point then.

[1] [https://news.ycombinator.com/item?id=9587570](https://news.ycombinator.com/item?id=9587570)

</comment><comment><USER52> Mozilla at one point had momentum before Chrome came up and wasted it while letting Firefox become slow and memory hog (This was before Chrome came out, I am not commenting on latest versions).

I don't see Mozilla turning around because they are trying to be followers where both Apple and Google are executing well enough at least to maintain Status quo. Why go after Smart Phone Market while at best you can be 3rd or 4th best (with less than 5% market share)?

</comment><comment><USER53> It feels like they barely tried. There's been _ZERO_ ways to acquire this phone in the USA!

Why is it so hard to sell an unlocked smartphone direct to consumers in the USA?</comment>


Deprecating the RC4 Cipher - <AUTHOR> https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/ <comment><USER2> Better late than never! There is a RFC for that as well ([https://tools.ietf.org/html/rfc7465](https://tools.ietf.org/html/rfc7465)).</comment>


Bitbucket vs Github - <AUTHOR> http://tilomitra.com/bitbucket-vs-github/

<comment><USER2> >However, their private-repo based pricing model is obscene, in my opinion.

Completely, 100% agree. It's ridiculous. I would use Github exclusively if not for their ass-backwards pricing scheme.

I'm a freelancer, I have about 60 closed source projects from clients and BitBucket lets me have them online for free.

Meanwhile if I used Github I would have to pay 84$ / month to host the same content.

That's RIDICULOUS.

Github, please. Unlimited free private repos for up to two contributors. Anything else and stsart charging. Lots of people want to use your site, but don't because of your greedy pricing scheme.</comment>


Kubernetes Journey – How to setup the HAProxy Cluster with high availability - <AUTHOR> https://itnext.io/kubernetes-journey-up-and-running-out-of-the-cloud-how-to-setup-the-haproxy-cluster-with-high-ee5eb9a7f2e1 <comment><USER2> I don't understand why you would use HAProxy here. Generally on k8s, you'd use a LoadBalancer (backed by eg. metallb on bare metal) to route external traffic into your cluster. This goes for both 'normal' payloads/services and the Kubernetes API endpoint itself.

In addition, it seems like the quorum configuration shown here is pretty poor - only uses two nodes. This is a recipe for split-brain.

<comment><USER3> > Generally on k8s, you'd use a LoadBalancer

Are you sure? All encountered k8s installations (including ones rolled from scratch by me) use Ingress controllers as the option for getting traffic into the cluster. Community NGINX Ingress controller is the de facto standard. One need to use LoadBalancer service type because of its managed origin (metallb is a different beast and I wouldn't recommend it, if you need to load balance traffic to your ingresses on on-premises infra, it's better to do it outside of k8s). Anyway, you lose all flexibility and observability of Ingress solutions with LoadBalancer service types if you use them directly as traffic routers to your backend.

<comment><USER2> They're complementary - LoadBalancer Services are L3, Ingresses are L4+. More often than not in-cluster Ingress providers (eg. nginx-ingress-controller) will in fact use LoadBalancers to actually route L3 traffic into the cluster in the first place.

Without being able to create LoadBalancer services there's no easy way to get any traffic into your cluster other than using NodePorts, and these have tons of shortcomings.

<comment><USER3> NodePort is a bad practice for a such case, you are right. You get additional unnecessary routing on CNI level between the cluster nodes just to get traffic into the Ingress controller pod, for example. The solution here is to use hostNetwork mode with the pool of workers solely dedicated to scheduling Ingress controllers. Traffic directly hits NGINX/Envoy/HAProxy/Traefik/whatever and gets into the cluster without additional intermediates. You need a load balancing solution for this pool of Ingress controllers, that's right, but as I said before, this setup gives you the flexibility to cook load balancing as you desire.

BTW, community NGINX Ingress controller is able to ingress L3 (TCP) traffic into the cluster.

<comment><USER2> > You need a load balancing solution for this pool of Ingress controllers, > that's right, but as I said before, this setup gives you the flexibility to > cook load balancing as you desire.

Sure, but this means that you cannot use LoadBalancers, which is painful. It means every payload has to be configured both at k8s level and then externally. That somewhat defeats the use of k8s as a self-service platform internally in an organization (other dev/ops teams need to go through a centralized ops channel to get traffic ingressing into the cluster if for some reason they can't use an Ingress).

> BTW, community NGINX Ingress controller is able to ingress L3 (TCP) traffic > into the cluster.

Yes, but it's configurable via a single ConfigMap (which limits self-service if you're running a multi-tenant orga-wide cluster, unless you bring your own automation), and still you only have one namespace of ports, ie. a single external address for all ports - unless you complicate your 'external' LB system even further.

With all these caveats, I really don't understand why not just run metallb.

</comment></comment></comment></comment></comment><comment><USER4> When we migrated to k8s we stuck with haproxy instead of using ingress for some of the reasons others have outlined already -- we've been running haproxy for a decade. Our configurations are tuned for our applications, we know the cpu usage and failure modes, and haproxy 1.9/2x support for srv records made it really easy. Bring able to trust k8s and our health checks and drop our previous 3 vm + vrrp setup was a no brainer!

<comment><USER4> That got us on k8s faster and gave us time to evaluate if we /really/ needed a service mesh or not (we don't, but the tracing is nice so we might still add istio yet). We may move to ingress based solutions eventually but our ecosystem is big and there's a lot more bigger fish to fry for now!

</comment></comment><comment><USER5> Anyone wonder if k8s is about to enter its trough of disillusionment phase?

<comment><USER6> Indeed. I'm still holding off, in the hope it will go away (like Openstack), but it does seem like it has some more stamina as a project.

<comment><USER7> Sticking to Docker for local projects for now

<comment><USER8> No thanks. It's a huge security dumpster fire as well.

<comment><USER3> Well if you're uncomfortable with its priviged daemon, you can always switch to CRI-O with Red Hat tooling for it. But for all my years with Docker as the container runtime, all security related problems have occured within the backend code, not Docker, not Linux cgroups, not Linux itself.

<comment><USER9> I've worked with some big customers in the financial industry, and this is exactly what we do. Podman implements the same CLI as docker, so you can basically just `s/docker/podman/g` (as long as you don't use docker-compose).

It's also a lot easier to debug and see what's happening without that daemon sitting in the middle of all the traditional linux tools.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Please, before making your criticisms, understand the purpose of what was written.

The official documentation itself addresses this.

[https://kubernetes.io/docs/setup/production- environment/tool...](https://kubernetes.io/docs/setup/production- environment/tools/kubeadm/high-availability/#create-load-balancer-for-kube- apiserver)

</comment><comment><USER10> If you have a L3 IP network within your datacenter, doing a BGP anycast of the VIP to a bunch of HAP servers is the best way to go. With ECMP, you can have your cake and eat it too – all of your HAP nodes will be handling traffic and when one of the nodes die, other nodes pick up the load nicely.

</comment><comment><USER11> everything old is new again? If there is not any good easy method in Kubernetes as q3k describes than why should somebody go into this overengineering approach?

<comment><USER12> as someone that works in operations.. This is pretty common think. Lets still do things how we did it on bare metal inside kubernetes.

They are stuck in the same mindset and just think Kubernetes is a automation tool.

I see it all day long as I interview people.

<comment><USER13> > as someone that works in operations.. This is pretty common think. Lets > still do things how we did it on bare metal inside kubernetes.

Because haproxy and nginx are proven technologies with limited and very well known failure modes, which means there's exactly 5-6 well documented, well understood and very well known ways haproxy and nginx can fail.

Experienced ops people understand that one does not optimize for the blue skies -- during "everything works wonderfully" all non completely broken technologies perform at approximately the same level. Rather these people optimize for the quick recovery from the "it is not working" state.

<comment><USER14> The article, though, suggests also adding corosync and pacemaker. So 4 things on top of the already complex K8S. I bet someone later throws in a service mesh. Imagine troubleshooting all that.

<comment><USER15> That's exatcly in order to blow in this fog that you want to install a layer7 load balancer designed with observability in mind. Seeing what's happening is critical when everything changes by itself under your feed. With a component like haproxy you get accurate and detailed information about what's happening and the cause of occasional failures allowing you to address them before they become the new standard.

<comment><USER14> That explains nginx. Running a corosync cluster inside a k8s cluster, with a separate pacemaker cluster resource plane, etc, though. No thanks.

<comment><USER16> 1000 times this. Corosync and pacemaker alone are more or less as complex as K8S itself. Well, I'm exaggerating a bit but really, all the HA clusters that I saw, done with corosync in the past 10 years ended up failing anyway (and with fireworks!) one way or another. Add this on top of Kubernetes? No, thanks. Life is stressful enough.

<comment><USER17> Yup. Corosync + Pacemaker can and will implode in a spectacular fashion exactly when you don't want it to. And 2 node cluster will split brain sooner rather than later. I'd rather use keepalived if required, since it's a lot easier to understand and manage.</comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: Which one to choose: Serverless or Containers? - <AUTHOR> I've read about people switching over from Docker (container) to AWS Lambda (serverless) but what scratches my head is, are there any performance (latency and cold start especially) difference? I mean, both are quite similar, so there shouldn't be any difference at all?
Let's say you create a single function that returns a certain calculated number, and you deploy this as Lambda function and to docker. My guess is that both should perform that function equally fast, am I wrong?
My question: Why should you prefer one over the other?
My understanding is that AWS Lambda functions are just like Docker except they're "smaller" and stateless and only runs when the function is being called. <comment><USER2> With docker you can run a different operating system and version of the app dependencies for each application (and each container can have different configuration and environment), and you can run it locally on your computer. Aws Lambda is extremely limited compared to that, no?

</comment><comment><USER3> serverless have limitations on the computing power time and memory limits. Also they need to finish in 300 seconds or something like that.</comment>


Show HN: HTTP/2 HPACK Compression Go Library - <AUTHOR> https://github.com/chrismoos/hpack <comment><USER2> How does this compare to `net/http2/hpack`, now in the standard library?

<comment><AUTHOR> One of the main differences is this one uses lookup tables for faster decoding of Huffman compressed data as opposed to using a tree (which is what the stdlib one uses). It also offers some additional encoding options for users that want more control of header field indexing.

<comment><USER3> Yes, let's get your version into Go if it's better.

(I wrote Go's quickly. I've never profiled it, delaying that until Go 1.7, which opened for development yesterday)

<comment><AUTHOR> If I'd like to get some of the enhancements in there, is this the route to go? [https://golang.org/doc/contribute.html](https://golang.org/doc/contribute.html)

<comment><USER3> Yup! That documentation is too daunting IMO but it's complete and not many steps, despite all the words. Especially if you're a Go programmer already. (just go get the code review tool)

I'd start with filing a bug against Go to track the overall process.

<comment><USER4> This is why I love open source projects, and shows just how open source Go is.

Fantastic.</comment></comment></comment></comment></comment></comment>


Coronavirus Crisis Could Cost World Up to $2T: United Nations - <AUTHOR> https://www.ndtv.com/world-news/united-nations-coronavirus-crisis-could-cost-world-up-to-2-trillion-2192504 <comment><USER2> A T here or a T there. Its just money. people's lives matter more rn.</comment>


You can now create files on GitHub - <AUTHOR> https://github.com/blog/1327-creating-files-on-github <comment><USER2> Github is the ultimate no-bullshit company. Any new announce is about some good feature or small improvement that matters: no annoying things to try to protect the company in some odd way, no greedy tactics to make more money in subtle ways. They are completely focused on their users and their product. I wish more tech companies could follow this example.

<comment><USER3> _"Github is the ultimate no-bullshit company. Any new announce is about some good feature or small improvement that matters"_

It's funny that you should say this, because I have pretty much the exact opposite impression. Most of their feature announcements are for dubious changes that don't make my life better (web-based CLI? Stars-vs-followers?), but more to the point, they've left _really important_ things to languish (for example: their code search sucks, and their issue tracking system is just barely usable.)

I don't get the sense that GitHub is rowing in the same direction as a company. Their product isn't improving in any consistent way, and for all of the _changes_ that they announce, I'm having a hard time of thinking of the last one that made a positive impact on my life. Certainly, I've never before needed to create a file in github via the web, and I probably never will.

<comment><USER2> Well I guess here it is really about tastes because I think the bug tracking system is one of the best features of the site.

The feeling you have of them not moving in the right direction probably is about their development model where internally people think at improvements and submit a pull request or something alike, but I guess they also have some long term projects that try to pursue as a whole.

But well the real point here is that we are talking about different things. I mean, you may not be happy with what _they accomplish_ and I may be happy instead, but the company is in general focused into evolving their product while not annoying users.

<comment><USER3> _"I think the bug tracking system is one of the best features of the site."_

It's a fantastic tool for avoiding annoyance with bug reports by losing track of tickets. It's perfect for that.

Seriously, though: any ticketing system that doesn't have a way to assign and sort by priority is just fundamentally broken (and no, tags don't count). But almost everything about the usability of the thing is goofy: bulk updating allows you to inadvertently delete tags (oops! hope you didn't need those!), you can't filter based on assignee, and it's easy to get stuck in a view where managing/filtering tags is impossible, with no indication of how to get to the _useful_ interface again (why do they even _have_ a view like that?)

But truth be told, I recognize that GitHub isn't an issue-tracking tool. That's fine. I have these sorts of complaints about nearly every part of the web interface. It's gotten to the point where I avoid using the web UI whenever possible -- it's just a hosted git repo, nothing more. And given that the _product_ is little more than a UI wrapper around git...well, I feel like these are pretty core problems for a user-focused team. So what are they focusing on, anyway?

<comment><USER4> This is definitely a taste thing. I've worked with issue systems that support priority in the past and found them frustrating - I much prefer being able to invent my own concept of priority using tags (which is exactly what we've done using GitHub issues). I also find the web UI a joy to use, and frequently refer to it over using command-line or desktop git browsing tools.

<comment><USER5> I agree that Github offers superb code browsing, and their issue tracker seems to be reasonably usable for small projects.

However, I fear that Github's issue tracker might not work at scale. I closely follow just one "large"[1] project that's hosted on Github; most of the developers on that project are accustomed to Bugzilla. Now I've never even used Bugzilla myself, but here are some things off of the top of my head that I remember them longing for:

1) The ability to attach files to issues.

2) The ability to denote dependencies between issues and generate dependency diagrams.

3) The ability to assign priority to issues (achievable using tags, but perhaps there's some advanced functionality I'm not aware of).

4) Ability for users to vote on which issues are most important.

5) Advanced search options (sometimes just having even _basic_ search would be nice... half the time I have better luck searching their issues via Google than using Github's own search tool[2]).

6) A responsive web front-end.

The reason that they use Github's built-in issue tracker in the first place is because everyone and their mother has a Github account, so it lowers the barriers to entry for filing a bug report. And there's no question that they've benefited enormously from this, and the user-engagement that it enables. But the detriments to productivity are real, and the advantage of Github's network effect hasn't stopped them from repeatedly considering migrating their issues to Bugzilla.

And I don't think it would kill Github to abandon their "tags fulfill EVERY USE CASE" position and bake in some more features for advanced users, especially if they hope to capture a bigger share of the more "serious"[2] projects out there (which would only be to their benefit, considering that "serious" projects are the ones that are willing to buy paid accounts for all the users in their organization).

[1] "Large" in this case meaning: hundreds of Github forks, thousands of Github stars, hundreds of thousands of lines of code, a half-dozen full-time developers, and, most pertinently, several thousand issues (and growing at an increasing rate).

[2] Case in point: I just now tried to search for the issue wherein I offered to do the legwork of migrating their database to Bugzilla should it come to that. The title of the issue contains the word "Bugzilla". The text of the issue itself contains the word "Bugzilla" multiple times. Several of the comments contain "Bugzilla". And yet a search for "Bugzilla" using Github's issue search tool reveals only one issue, completely unrelated to the issue I was looking for.

[3] "Serious" in this case meaning: a codebase with hundreds of thousands to millions of users, dozens of full-time developers, and hundreds of thousands of issues.[4]

[4] <https://bugzilla.mozilla.org/show_bug.cgi?id=800000> [5]

[5] Help I've gone mad with footnote power [5]

[6] While you're here, fun fact: I once went looking for the Github project with the largest number of total issues, and here's what I eventually settled upon: <https://github.com/mxcl/homebrew/issues>

</comment></comment></comment></comment></comment></comment><comment><USER6> Inside a Jekyll repo on Github:

        New file button = New Post (rich editor)
        Branch and new file = Draft
        Edit button (owner) = Edit
        Edit button (reader) = Submit correction
        Pull request = Submit Guest post
        Pull request comment = Copy/content editor
        Issues = Idea/Suggestion bucket
        Commit button = Publish and deploy

If there was a way to do the live markdown preview using the css (maybe you could inline link it?), then you have a pretty complete blog engine for hackers. This would be an awesome feature IMO.

Github would then be the place where you put your code, write your blog, track your issues, paste snippets for IRC (Gist), display your business card (profile info), and host your talk slides (SpeakerDeck). The next logical step to me would be integrating conferences/user groups (ala Lanyard/Meetup.com).

PS. @github feel free to hire me to help build it out :P

<comment><USER7> I love this idea for Github and think it would be a really exciting move for them! One thought though - could the Git protocol† for editing, correcting, guest posts etc not also work well as a more general protocol for hacker bloggers?

Something like a meta tag on the index page for the blog, pointing to the git repository‡? (be it on Github, Bitbucket, or your own server) A simple command-line tool (or browser extension) would assist in checking out the repository, and you could issue the pull request with whatever communication protocols you have in common (no need to re-invent the wheel here).

† It needn't just be for git, of course - it could work with many (any?) distributed version control systems (Mercurial and Bazar spring to mind)

‡ I realise you may not necessarily want everyone to have access (even read- only) to your repository - for example, you may have future, draft posts in un-merged branches. The beauty of distributed version control is that there's no canonical server - so there's no reason the public one has to have any branch pushed to it other than master.

<comment><USER8> There's a "rel=vcs-*" microformat :

<http://joeyh.name/rfc/rel-vcs/>

</comment></comment></comment><comment><USER9> Could this be the eventual IDE in the cloud so many others have failed at? Start with getting everyone's code in the system, get them viewing code in your system, commenting on commits daily, then "hey while you're here, why not just edit the file in this little editor"...fast forward several more iterations/improvements and then you find yourself never leaving the web editor.

<comment><USER10> Cloud9 IDE is actually a very nice cloud-based editor that already hooks into Github and others.

<comment><USER11> I've been using it to write production code for almost 6 months now. Over the last month, they've eliminated all the minor annoyances. It's solid and works. I couldn't complain even if I wanted to. The codebase is also very approachable. I needed a feature, wrote it, pull request, and they accepted it.

<comment><USER12> Cool! What are the main benefits you noticed when comparing it to the traditional offline model?

<comment><USER11> With a traditional IDE, you have to install it everywhere. With me, that would be a half-dozen computers, with 500MB lost on each one. With Cloud9, it's installed on the server and I can access it anywhere there's a net connection. Updates are centralized, you only need to do it once.

And it's funny, but the IDE is actually more performant in the browser. Well, I was using Aptana before, which is essentially Eclipse and that's known to be slow.

Also, it just feels natural to have your IDE right next to the end product. IDE in one tab, web app in the other.

</comment></comment></comment></comment></comment><comment><USER13> This is fantastic news. I think this qualifies Github as a complete blogging engine now, with the plethora of static site generators available.

<comment><USER14> Agreed. I've used it for a blog and a promotional site for a few months now.

</comment></comment><comment><USER15> This is awesome for a number of reasons.

The biggest is probably that you can now have people helping out without teaching them git. Like people helping with translation, they could just copy the original file and translate it locally, then paste it in to a new file. Way cool.

</comment><comment><USER16> Excellent timing. One of the elements on my TODO list was to add the Github API to my app to create files that I can then have the user edit. Now I can just use a link instead.

</comment><comment><USER17> I get the feeling that the various "online IDE" projects may be quickly superseded. If anyone could pull that off, it's Github - just getting Github integration working is hit-and-miss with most of the others. If it could include some live preview functionality for HTML/CSS/JS for mockups and Markdown for writing, it would quickly become vastly useful.

Does anyone know what text editor they're using? I assume it's CodeMirror, but I could be wrong.

<comment><USER18> I believe the editor is ACE:

<https://github.com/blog/905-edit-like-an-ace>

<https://github.com/ajaxorg/ace>

</comment></comment><comment><USER19> I bet it is very satisfying to just constantly ship cool new discrete features like this for a product like GitHub.

</comment><comment><USER20> This is awesome for drive-by commits of documentation and such. Marvelous.

</comment><comment><USER21> Sorry to be off topic, but does it bug anyone else that the language Github uses for their native client is "Clone in Mac" and "Setup in Windows", as if the name of their client is "Mac" and "Windows", etc. Not only is this confusing, because they're naming the product the same as the OS, but it's also a little insulting because it's almost like saying that the normal command-line Git client doesn't run well on those platforms.

I appreciate that they want to draw attention to their native client product, but I really wish they would give it a proper name so that they don't have use the name of the OS instead.

<comment><USER22> These buttons are only displayed for users who have installed those tools. We're not using it as advertisement, we're making it convenient for people who have already installed the tool.

<comment><USER21> Are you sure about that? I do not have the tool installed (or anything like it, since I use command-line git), but I see the "Clone in Mac" button on every single github repo I view in my browser.

</comment></comment></comment><comment><USER23> I'm a little surprised by the unanimous positive response here. Usually any mention of a new GUI for any git functionality gets at least some negative feedback. I count this as progress!

</comment><comment><USER24> I think it is a great decision on where to place the create new file button, it seems obvious when you see it but is such a simple solution. Or is it just me?

When I read their tweet I was interested to see how they had integrated it with everything else. Off the top of my head I couldn't think of an ideal place without the whole UX feeling clunky. Well done Github!

</comment><comment><USER25> This is a great new feature. Another thing this reminded me of is how good the github team is at releasing new features, clearly explaining them, and getting them integrated smoothly and across a wide user base. Its very impressive to me since this is rarely done well IMO.

</comment><comment><USER26> Nice to see Github releasing more consumer features lately (deleting branches on merge, now creating files, etc). After not seeing a significant update for months, I thought Github forgot about the consumers in their more focused efforts towards enterprise users.

</comment><comment><USER27> This is really wonderful. Great for those of us who work from tablets frequently.

<comment><USER28> Agreed. The ability to edit files from the browser made fixing website typos on-the-go trivial, and this gives even more power to developers whose current machine limits terminal access (Prompt on the iPad + a remote server works wonders, but too often I've had only a colleague's tablet or smartphone to work with).

</comment></comment><comment><USER29> Ha, I just requested that two weeks ago via their feedback page. They didn't really told me that they were so close to implement that.

Now I'm still missing to configure the default settings of the builtin editor.

</comment><comment><USER30> Finally! I often want to share small scripts and having to create a repository locally first is much less convenient than just pasting the file online.

<comment><USER31> Gist is great for that too: <https://gist.github.com/>

<comment><USER32> Also this: <https://github.com/ConradIrwin/jist>

<comment><USER33> I wrote one too!

<https://github.com/voltagex/python-gist>

</comment></comment></comment></comment><comment><USER34> What about creating a folder?

</comment><comment><USER35> Is it possible to disable this feature so that people can't randomly commit code to a core repo on a team?

<comment><USER36> Have you tried switching to the fork-and-pull-request model instead of everyone directly committing to the main repo?

(It's how many, many open-source projects run, and GitHub has a good write-up of it here: <https://help.github.com/articles/using-pull-requests> )

</comment></comment><comment><USER37> Don't they then need to be able to support mergetool? I mean editing, which this essentially is, seems to open a whole can of worms. What if someone else creates a README and pushes to the same branch while you are in the process of creating a README?

<comment><USER38> I assume the push would fail?

</comment></comment><comment><USER39> This is really cool! One tiny feature request: Remember my last settings for tabs/indentation.

</comment><comment><USER40> That's really cool. Would be even nicer if you can upload any file and attach it to a github issue. That's the only thing keeping us from moving our issue tracker to github (private repository). Unless I missed some sneaky way of doing this?

</comment><comment><USER41> So this means that when github tells you, "We recommend adding a readme to this repo" you can actually do it right there! It's even a link now. Ah this is so great.

</comment><comment><USER42> Not only is this a great thing (well, everything about github is pretty great) but now I know that the funny icon can be called "breadcrumb".

</comment><comment><USER43> I just realized you can edit files. Is that new too? Or is it only the file creation that's new?

<comment><USER44> Only file creation is new. I had been wondering where file creation was since they added editing though. This is very welcome.

<comment><USER45> Yeah, how long have they had file editing for? I remember seeing it last year, and realizing how quickly I'd hit a wall if I couldn't create new files.</comment></comment></comment>


Another Apple Rejection Story – GIF Finder - <AUTHOR> http://blog.mattcheetham.co.uk/apple-rejection-goodbye-gif-finder/

<comment><USER2> Dealing with Apple's review process is a pain sometimes. We recently submitted an app which made it through the review process but was rejected for screenshots. We thought the screenshots were fine, so we appealed. I think we lost the appeal, but we still haven't received a phone call. So we just went ahead and changed the screenshots, but we've been in review for the last few days (should have taken a few hours for metadata only review). I'm beginning to suspect our app may have been banned/rejected.</comment>


#define CTO OpenAI - <AUTHOR> https://blog.gregbrockman.com/define-cto-openai <comment><USER2> This story makes it crystal clear how much openAI is accelerating research, for now mostly on reinforcement learning.

I'm sure this is talked about over and over again, but could someone please lead us through the AI safety rationale behind this? With gym and universe openAI is slashing a few months (years?) off the singularity countdown, most likely. What's the upshot? Why is the expected value of these initiatives positive? The uncertainties seem extremely large.

Edit/PS: To put it more bluntly, and be more specific: are there any projects that openAI is choosing NOT to pursue even though they would be very useful/cool for the research community (à la gym and universe), but where it has had to explicitly restrain itself, because the expected value from an AI safety perspective is negative?

<comment><USER3> Less about influencing the _velocity_ , more about influencing the _direction_. Technologies tend to reflect the values of their inventors. We want to ensure this technology is beneficial to humanity — meaning, that it's good at all, and that it benefits the many rather than the few.

We also think safety matters, and it should be researched in lockstep with advances in the capabilities. We have good relationships with MIRI and FHI. Our safety researchers published (together with Google Brain) a roadmap of concrete safety problems [1] and work to provide tools to prevent ML systems from being subverted [2].

No one yet knows the precise details of how AI should play out. But I'd certainly prefer that, whenever it gets close, one of the organizations actually making the advances has no incentives besides ensuring a good outcome.

[1] [https://openai.com/blog/concrete-ai-safety- problems/](https://openai.com/blog/concrete-ai-safety-problems/) [2] [https://github.com/openai/cleverhans](https://github.com/openai/cleverhans)

<comment><USER4> > Technologies tend to reflect the values of their inventors.

 _Maybe_ for single-use or "constrained" technologies (to be honest I don't even believe that - how does a B-52 Stratofortress reflect the values of Orville and Wilbur Wright?). But isn't the whole point of generalized AI that it's _not like_ other technologies? Even if "regular" technology reflects the values of its inventors, what reason is there to believe that an AI will? AI is a technology that can use itself.

<comment><USER5> AI will only have a will of its own it is designed as such, and that means it would have a reinforcement learning system on top of lower sensory and action modules. Even if it is based on RL, it will do what it's reward signals tells it to do.

<comment><USER4> > AI will only have a will of its own it is designed as such

Humans weren't designed to have a will, and yet we seem to have them.

> it would have a reinforcement learning system on top of lower sensory and > action modules.

Isn't that what OpenAI is doing with Universe? It's simulated sensory/action modules now but I don't see why they couldn't be hooked up to real ones.

<comment><USER6> > Humans weren't designed to have a will, and yet we seem to have them.

I have no idea how you could possibly infer this.

<comment><USER4> Which part? I don't think humans were designed - we're probably the result of an evolutionary process without intentional design - but "humans were designed by God to have free will" would be a counter to my statement, yes.

If your complaint is my claim that we have a will, I'm using the common-sense version encoded into our legal and cultural system. I agree that we don't have a good concept of what intentions are, or how they causally connect to actions, but I do know that for at least some of my actions I experience something called "intent" before I undertake the actions.

My overall point was that the capacity for intent can arise through an evolutionary process without being designed in, but it does rest on the two assumptions I just listed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I think there's a bug: this replaces all occurrences of 'CTO' with 'OpenAI'.

<comment><USER8> I thought the article would be about replacing CTOs with AIs, based on the title.

</comment></comment><comment><USER9> Nicely put together, sounds like the first place in a long time where I simultaneously would love to apply and feel completely intimidated by what is clearly a really amazing team of people.

Guess I need to figure out how to get more ML papers published!

</comment><comment><USER10> Congrats on the success so far Greg. Watching the progress has been great. Being a bit involved with gym and also the unconf has given me a peek in to how things are run and I have to say - it's a startup. It evolves fast and isn't afraid to take calculated risks. That's a great thing to have for something as open ended as what you guys are trying to do.

It looks like a blast and I will continue to keep an eye on things. I used your previous post to help define a lot of the scope of my position for myself. I look forward to seeing more of this story unfold.

</comment><comment><USER11> Nice write-up - it makes me wish I lived in SF (or USA for that matter) so I could apply for a job there.

<comment><USER3> Many people weren't living in SF when they applied (though they do live here now). We will happily sponsor visas!

<comment><USER11> Thanks for replying! I won't be applying because relocation is not an option for me in foreseeable future, so I'll stick to local (EU) or remote jobs. But if there was something that would make me want to move, such a job would be it. Kudos!

</comment></comment></comment><comment><USER12> I really enjoyed reading this journey! inspiring and motivating to hear people centered around a common goal with a unique and forward thinking team structure.

It made me reflect on my best moments in software development and how they have been similar short bouts of intensity.. weekend long to 2 week long periods of intense and undivided focus at progressing a task through to completion, time where every other concern fades away, a flow state where I will wake up immediately with new ideas or problem solve in the shower.

Sure, that level of concentration is unsustainable for the long run, but this article has made me consider that I may have to structure my life around being able to repeat these kinds of stints more often, 'embrace your funk' as some would say!

</comment><comment><USER13> i think they can advance computers' capabilities, but they will never create consciousness without first understanding consciousness. From my perspective-- if there goal is as lofty as it is regarding achieving singularity and all that--they are going about this from the wrong angle. Perhaps it's nice to fuel the ego with the concept that you're safely ushering in the singularity, but I see it as more of a spiritual and psychological conquest. And if that's the case, you're likely on more of a path of personal learning, evolution and growth, rather than building the underpinnings of a future idiocracy.

I think all these guys have gotten ahead of themselves and are dealing with things they are the least suited to understand. This is spiritual stuff, no amount of obsessing and hiding behind your computer screen getting high on delusions of grandeur are gonna do the introspection for them, which is an absolute prerequisite to having any understanding of consciousness.

I look forward to automation though. Just know the singularity is not coming any time soon, if ever. It's funny to watch guys who are basically atheists like Ray Kurzweil with very little spiritual experience think they are playing god.

Have these people ever consciously astral projected or even tried? I mean these are people who typically doubt that stuff. However, my perspective is: if they aren't living in that world--i.e. the world of consciousness explorers, the mystical, where astral projection is possible, reading the many books by spiritual journeyman like Robert Monroe, etc--they have a major blindspot. The most they will ever do is build a computer able to pick ripe fruit or avoid hitting other cars. This is hardly consciousness. I mean as a percentage of the capabilities of consciousness, it's like .00001%. Consciousness is creating ideas. And that's maybe just one aspect of consciousness. No amount of machine learning will take the place of the higher truth of our reality system that makes such creativity possible. You will have to attain that wisdom through dedication to the spiritual path, and even then, it's likely not something you can just hand out to anyone--at least not in a way that will be effective for the recipient. You see what I'm saying? You won't unless you've pursued spirituality and had a few mystical experience of your own. ..Next: say you attain that piece of wisdom--the way the reality system works is not so you can easily just automate it. And if you can because you have now become a consciousness creator, well then, it's likely not automated through machinery, but through more biological and mental/telepathic means. Now, you either know exactly what I'm talking about or you have a bunch of doubt to cast--for what I'm saying is breaking down your own beliefs, and that's not comfortable for you--but if you do know what I'm saying, then you know the people behind this OpenAI initiative won't be able to achieve their aims. I wish them the best of luck though, and look forward to advancements in machine learning. I think they would be more productive if they understood what they were up against though. It would allow them to set more realistic goals--or perhaps set them on a path do the spiritual introspective work first.</comment>


MSFT has canceled "Courier" tablet — reportedly - <AUTHOR> http://www.electronista.com/articles/10/04/29/leak.has.ms.dropping.dual.screen.courier/

<comment><USER2> And Gizmo claims that Frank Shaw at MS says:

"At any given time, we're looking at new ideas, investigating, testing, incubating them. It's in our DNA to develop new form factors and natural user interfaces to foster productivity and creativity. The Courier project is an example of this type of effort. It will be evaluated for use in future offerings, but we have no plans to build such a device at this time."

</comment><comment><USER3> Apart from their keyboard and mice this was the first microsoft device I was looking forward to :). While it might not be a mainstream need, a device with great pen based input and support for math symbols would be great for what I do.

<comment><AUTHOR> How can you claim that it was to be "a device with great pen based input"...?

I thought it was only at a _concept_ stage?

<comment><USER3> I didnt say it was, I was merely saying that a pen based device is an unexplored niche, one that I was hoping the courier would fill.

</comment></comment></comment><comment><USER4> It was only ever a design exercise. I suspect that Microsoft never had plans to develop and sell the courier. However, based on the excitement and demand, I wouldn't be surprised to see one of the hardware vendors pick-up the torch.

</comment><comment><USER5> And commenters are already moaning the loss (of non-existent product) already at <http://www.crunchgear.com></comment>


Most useful projects solved or helped with a website - <AUTHOR>

What do you think the most useful projects would be to humanity which could be helped or solved using a website? Can you name any that are running strong now? <comment><USER2> 1\. Transparent, instant, geographically-relevant market pricing data.

2\. Voting, Republic-style (not to be confused with democratic-style).

<comment><AUTHOR> What is the difference between republic style and democratic style voting?

<comment><USER2> (Representative) Republics use hierarchical voting: citizens elect representatives, representatives vote on issues and elect representatives from their own pool for higher bodies. Democracies give one vote to every citizen on all issues. Examples are Washington (the state) voter initiative system and Senatorial elections post-1913 (they were originally elected by state legislature. see [http://www.senate.gov/artandhistory/history/common/briefing/...](http://www.senate.gov/artandhistory/history/common/briefing/Direct_Election_Senators.htm)).</comment></comment></comment>


Reporting Code Diff - <AUTHOR> http://codebetter.com/blogs/patricksmacchia/archive/2009/08/04/reporting-code-diff.aspx <comment><USER2> In case it saves anyone else the few minutes' work it took me to figure out what this actually is and why anyone would care:

There's a tool called NDepend, which supposedly does all sorts of analysis on C# and VB.NET code. It has a vaguely SQL-like query language in which you can express things like "find all methods that are public, were present in an earlier version of this code, but aren't there any more" and can generate reports based on the queries. (Query language briefly described at <http://www.ndepend.com/Features.aspx#CQL> .)

The article being linked to here was written by (I think) the (principal?) author of NDepend, and describes how to use it to produce a report on what has changed in your code between two versions: what methods have been added, had their visibility changed, etc.

I'm not quite sure why Anon84 (1) posted a link to that blog entry rather than something more general about NDepend and what it can do, or (2) didn't post any further explanation. But perhaps my perceived lack of #2 is just because I'm dim...

<comment><USER3> Smacchia is definitely the author of NDepend and he _loves_ to post about it (mostly in .NET circles, this is the first I've seen outside of that), but position it in a way that he uses the product and shows it off, but not by talking about the product, but by talking about all the methodologies it extols and all the things you should be doing that this product will make you feel guilty about not doing.</comment></comment>


Starship delivery robots - <AUTHOR> https://www.starship.xyz/ <comment><USER2> Seems like the kind of idea that could be easily disrupted by a self-driving car designed with lockers to store packages. Such car would be able to go faster and further than this robot and store more packages as well.</comment>