Ask HN: Is there an email service that allows plaintext and respects my privacy? - <AUTHOR> Plaintext as in non-HTML.
I've been searching to no avail. Tutanota and protonmail do not support it, and I don't want to use Gmail.
I'd prefer it be free. <comment><USER2> Privacy there are some, plaintext-only. I don't know. You may just host a email-server yourself if you want to get what you're looking for.

</comment><comment><USER3> I would recommand Fastmail (fastmail.com). Not free, but they respect your privacy and there are options to compose and read email in plaintext.

</comment><comment><USER4> I'm curious why you don't want to use HTML.

<comment><USER5> Tracking is one reason.

Every time I get an email saying "We noticed that you haven't been opening our emails", it makes me smile.

<comment><USER6> FastMail also has an option to filter out tracking links from HTML emails (from everybody, or just from unknown senders), while still giving the ability to see pretty HTML formatting if you want it.

</comment></comment></comment><comment><USER7> outlook.live.com has a plain text setting / bottom arrow on new/compose page

</comment><comment><USER8> I wrote one. It's a side project, and dear to me, and private but you can use it if you'd like. Email in my profile.</comment>


Mark Zuckerberg: Our Biggest Mistake Was Was Betting Too Much On HTML5 - <AUTHOR> http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/ <comment><USER3> As others have been pointing out feverishly on Twitter: the problem wasn't them betting too much on HTML5. Their problem was developing piece of shit apps that happened to use HTML5. They tasked amateurs who didn't know what they were doing into building a hybrid native app container which in turn embedded HTML5 content. Plenty of other developers (Instagram and LinkedIn come to mind) have figured out how to do that right, and in a way where it is seamless to the end user and for all intents and purposes feels exactly the same as a native app.

I'm not saying that it's an easy problem. You have to find the right balance between which components should be native or not. It's clear from the other problems that Facebook's been able to solve that they know how to hire top- notch developers. They just failed to do so for their mobile efforts, which just reinforces the stereotype that they don't "get" mobile.

<comment><USER4> Yes, yes, a million times yes. Facebook is very resource intensive (in terms of data+media loading over the wire) but there are certainly ways to work around this. Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good example of this. The main problem with HTML5 media apps today is that they must be developed with a primary focus on optimization _from the start_. This is unfortunate, and will hopefully change, but it _is_ possible. But seriously, saying "HTML5 failed you" when you don't even compile your scripts and initial resources to require a minimal amount of requests is just ludicrous.

To clarify: I'm not saying that facebook's HTML5 developers can't hold their own -- they produced a great looking mobile app with a truckload of functionality (and believe me, I understand code bloat). Maybe someday it will run flawlessly on mobile. But right now to produce a nice experience in HTML5 you must optimize from the start. Run your code on the device from day 1, not in Chrome with the vertical web inspector! Host your scripts on dev servers with artificial lag. Figure out what's slowing you down on day 1 and _work around it!_ And one day you won't have to :)

<comment><USER5> > _Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good > example of this._

An app which all of 50 people use --and many of them curse while doing it.

<comment><USER6> According to comScore, Yahoo Mail is the third largest mail provider with over 300 million users.

Kicker:

> in the U.S., Yahoo is No. 1, with 96.6 million active users

[http://news.cnet.com/8301-13772_3-20114975-52/microsoft- aimi...](http://news.cnet.com/8301-13772_3-20114975-52/microsoft-aiming-to- clean-up-hotmail-users-inboxes/)

</comment></comment></comment></comment><comment><USER7> I don't work for Facebook. I work at a mobile company that does iOS and Android development. I work daily on our Android apps. Here is my experience:

1\. The cost of maintaining iOS and Android is something like 1.5x the cost of maintaining just one or the other. Most of the investment is architecture and design. About 50% of the design is portable across iOS and Android.

2\. Developing reliable HTML5 that behaves predictably is as expensive as developing for a native platform. You may already have the skills, but that doesn't make it less expensive.

3\. Most touch frameworks (jQuery mobile, etc.) get you 85% of the way there and then you're stuck. To get an app that can compete with native in terms of realization of design, you end up with lots of non-framework code.

4\. (Android specific) The same fragmentation that hurts native development hurts support for HTML5. The test matrix for HTML5/browser compatibility on Android is almost as daunting as the native support. Different device/os versions have different web cores that have different foibles. Its just as big a grab bag as ever.

5\. Multimedia support for these environments is just atrocious. Unless you can proxy/convert all content, all but the most trivial content is inaccessible. You end up calling into other applications on the platforms which can present a much less compelling presentation to the user.

I'm not going to say its impossible. I'm leaving out all the arguments of performance because it just gets to be to specific to the use case. I have not seen a compelling example of a unified mobile & desktop browser code base that would eliminate all mobile maintenance. Besides just having people rip up my points, I'd be interested in hearing what HTML5 components people are finding make these issues manageable.

In the long run, its not black or white. We use HTML5/css/js for some things and native for most things. Its how we keep things moving but I'm sure we'll revisit this over and over to make sure we keep investing in the right platform.

<comment><USER8> Thanks you... People think that HTML5 us the second coming. Thank you for putting it in context. Use the best tool for the job. I am tired of so much hype over HTML5 - like it's the greatest thing since sliced bread.

</comment></comment><comment><USER9> Zuckerberg's harsh words are a mixed blessing for HTML5. Some people will get the wrong message and just dismiss HTML5 altogether, which isn't what he said. His main point is he regrets building native apps with HTML5, and with the benefit of hindsight, he is right.

The good thing about this is the browsers and standards people need a wake-up call. See the comments in Paul Irish's recent thread about this [1].

There are people who are content to plod along and debate the finer points of one attribute or another, while native APIs are steaming ahead. Quotes like "We burned two years" and "Betting completely on HTML5 was the biggest strategic mistake Facebook made" from Facebook's CEO are the kind of evidence that should get people to wake up and smell the coffee, if they still haven't done so.

1\. [https://plus.google.com/113127438179392830442/posts/fR3iiuN4...](https://plus.google.com/113127438179392830442/posts/fR3iiuN4kEF)

<comment><USER10> I agree, but feel that with Facebook's resources there was nothing stopping them from building a native application and a counterpart web application much like Twitter. Using a friend's device? Opt for the web interface. Using your own device? Native install.

These things can live in harmony, not exclusivity.

<comment><USER11> But, the Facebook philosophy has always been, of hacking together what works today and think about other things later. HTML5 allows rapid fluid UI(as in feed based UI) development. The native app would have taken atleast 4-6 months for a barely tested app( As an Android Developer, I can vouch for that). They got the HTML5 app running in much less time. Having a lot of resources doesn't mean better quality work. More often than not, small teams are deliberately allotted such tasks to maintain homogeneity in design and code architecture. A mobile app is special type of software where the UI is very close to the other components(i.e Event Handling, Models etc.). Putting a large number of developers on it won't make it go any faster. Think of that scenario: 200 people working on a mobile app, pumping out features and testing sequentially!!How would that even work?

<comment><USER10> I think you misunderstood my point. Facebook has the resources to have a mobile and native app developed concurrently. I did not mean throwing more developers at a problem to get it completed faster.

In my opinion he was just issuing blanket statements to warm the cold reality that Facebook doesn't care about quality.

</comment></comment></comment></comment><comment><USER12> The problem with apps developed in HTML5 that is not stressed enough IMHO is that the iOS API is good, while the HTML5 API to do a lot of advanced stuff is still limited. In short to develop a native application _does NOT take more time than developing one in HTML5_ , at least for iOS devices. I can tell this first-hand as I used to advice an iOS/Android software company in the past, composed mainly of friends of mine, and in three years of projects the native approach always won: better responsiveness, more access to lower level primitives when needed, native look and feel, easy of development.

And I'm talking about a small startup. To take the HTML5 approach to develop a mobile application for a very large company is simply silly IMHO, and Facebook CEO is right that this was an huge error in their side.

<comment><USER13> > develop a native application does NOT take more time than developing one in > HTML5

Unless you already have an HTML5 desktop app. In which case, the only thing you're doing is modifying the UI for touch-based input and a smaller screen ... which doesn't take much time at all.

Facebook's problem was that their app sucked. It didn't suck because it was HTML5. It sucked because it was done poorly.

<comment><USER12> For an HTML5 desktop app to become a _good_ HTML5 mobile app usually the changes are so big that you end anyway with a different set of code generating the output for the two "sides".

It does not matter that's HTML+CSS+JS both sides, the device, the interaction, the screen real estate, and the _user behaviour_ when seeing this content in mobility is different.

Actually the risk is that trying to make an HTML5 desktop app also good for mobile is that you overlook a lot of good interactions that are not natural consequences if the starting point is the desktop app.

<comment><USER13> > For an HTML5 desktop app to become a good HTML5 mobile app usually the > changes are so big that you end anyway with a different set of code > generating the output for the two "sides".

I'm actually working on this right now.

HTML and CSS served to both desktop and mobile are identical. HTML is just headers and an empty body tag. CSS has shared code and @media specific to each interface.

Every visual element is built through JavaScript/DOM.

Javascript is split into two sections/folders. Logic and visual. Mobile and Desktop share the logic javascript, but not the visual.

Everything you can do on the desktop, you can do on mobile. The only differences are in how the visual elements are presented.

<comment><USER14> _I'm actually working on this right now._

Having been down this path before, I predict you will find that the "last 10%" of those small, annoying things that don't quite work like native mobile apps in HTML5 will take the same amount of time to fix as developing the rest of the app.

If you don't think this is the case then either you aren't far enough along to hit the problems or your app doesn't make heavy use of hardware (which - <USER2> that it is also a desktop app - it sounds like it probably doesn't). In the second case then using HTML5 makes good sense.

<comment><USER13> > your app doesn't make heavy use of hardware

Bingo. Would be surprised if it lagged on hardware from 10 years ago.

</comment></comment></comment></comment></comment></comment><comment><USER15> I suspect history will show their three biggest mistakes to be:

1\. Allowing an IPO that was vastly overpriced.

2\. Keeping Zuckerberg in the CEO role for too long.

3\. Taking their users for granted.

Obviously the first has seriously damaged their credibility, and with it their ability to hire and retain people who could solve their problems and grow the business.

I believe the second has a similar effect. Aside from the catastrophe of the IPO, Facebook don't appear to be going anywhere strategically. The cat is out of the bag in terms of cost effectiveness (or lack thereof) of Facebook ads compared to alternatives like Google. And generating ad revenue on small- screen mobile is bound to be harder, whether you're using HTML5 or anything else, because the physical screen size only provides so much space.

The third will probably be what finally kills them. As long as they can maintain the critical mass of users, the "everyone's on Facebook because everyone's on Facebook" effect, they can get away with a lot. But no-one using Facebook goes there for the ads, and no-one really likes all the privacy invasion. These things are merely tolerated, and only up to a point, because people like being sociable and right now Facebook lets them keep in touch with their friends and family more conveniently than anyone else.

So when Zuckerberg says "Over the next three to five years, the biggest question on everyone's mind is really going to be how well Facebook does with mobile"[1], I think perhaps he's getting ahead of himself. The biggest question I would ask, if I were a potential investor, is whether Facebook will still have that critical mass of users in three to five years, or whether, like every popular social forum on the Web before them, they will have been disrupted by the new shiny.

[1] <http://www.bbc.co.uk/news/business-19565937>

<comment><USER16> I disagree pretty strongly on all three points.

The post-IPO share price decline is bad but I have not seen much, if any, evidence that it has hindered the ability to hire and retain employees. In fact, an easy case can be made that the smaller valuation creates much more upside for the RSUs that Facebook issues.

Mark is one of the premier CEOs of his generation. Removing him would be completely insane. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do.

Facebook is extremely customer-focused and I don't think the privacy dust-ups suggest strongly otherwise. It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case.

<comment><USER15> _The post-IPO share price decline is bad but I have not seen much, if any, evidence that it has hindered the ability to hire and retain employees._

Please note that those three points were my projections for how history will look back on the company. I'm not claiming there is some mountain of robust scientific evidence to support my position right now.

Having said that, anecdotes predict the real data surprisingly often, and there doesn't seem to be any shortage of Facebook people who aren't impressed at half of the money they thought they had to fund their big house purchases disappearing before they could do anything about it. And of course, it's still relatively soon after the IPO, and a lot of the funds are only starting to become available around now. You wouldn't expect a mass exodus when a lot of money was still locked up.

As for recruiting new people, again I don't suppose Facebook are about to disclose hard data that makes them look bad, but where has the buzz gone? Pre- IPO, everyone and his brother seemed to want in, presumably in part because of the potential for a huge pay-off that everyone expected Real Soon Now. Without that incentive, and with plenty of other new businesses competing in the market that don't have Facebook's baggage, I find it hard to believe that they are still attracting the same quantity and quality of applicants as they did say 2-3 years ago.

 _Mark is one of the premier CEOs of his generation. He is, by far, the single most responsible for having created a $60 billion company, something few can ever even hope to do._

Is he, really? Or was he just in the right place at the right time, and if it hadn't been him and Facebook, it would have been someone else and their start- up instead?

As for being a $60B company, I think you're a little out-of-date. They're down to just over $40B already. In any case, I'm more inclined to judge big tech companies by how much money they actually make and not some random number the markets generate and label "market cap". And as of the first earnings call since going public, Facebook were actually _making a loss_.

Obviously that wasn't a typical earnings period because of the various stock- related factors, but they're taking roughly $1B per quarter in revenues, and making around $300M per quarter of profit after adjusting for the one-offs[1]. At that rate, to justify their current $40B valuation, they would need to sustain that level of profitability for over _30 years_ , or increase profitability through growth.

But where will this growth come from? By Zuckerberg's own admission, the market is increasingly moving to mobile for their social networking; that limits the opportunities to show as many ads. Their growth in user numbers has slowed to a crawl, because there are only so many people in the world to sign up and some of the ones who did sign up are going to get bored and do something else. And the return on investment for on-line advertising is falling over time, a pattern which has been evident for quite a while now, which is a third threat to a business model like Facebook's.

In short, I don't think Facebook are anything like a $60B company. If you do, I assume you're investing heavily at this point, since you'll surely see a 50% ROI?

 _It's fashionable but trite to think Facebook will got "the same route" as properties before it. Pretty much the same thing gets said about any lasting company. It doesn't take much intelligenc or curiosity to consider that's not always the case._

Perhaps not. But usually it is, particularly in entertainment industries, and particularly in fast-moving tech industries. Ten years ago, Microsoft were riding high after the release of Windows XP, Apple were a has-been, a couple of guys had started a little company called Google that was attracting a bit of attention as an alternative search engine, and Facebook wouldn't even exist for several years.

[1] [http://www.nytimes.com/2012/07/27/technology/facebook- report...](http://www.nytimes.com/2012/07/27/technology/facebook-reports-a- loss-but-its-revenue-beats-expectations.html)

<comment><USER16> Your using the wrong FB share count. Despite what some sites report, the correct number is 2.74 billion which means $57 billion at current price.

<comment><USER15> I don't think it matters. By the argument I gave in my last post, they probably aren't worth anything like $40B. If the market cap figures everyone's quoting don't take some of the shares into account and the real number would be $57B, that just makes the valuation even more implausible.

<comment><USER16> Your incorrect corrections were rather matter-of-fact. And we are discussing the notion of Mark continuing as the CEO, not the plausibility of the company's current market value.

<comment><USER15> To be fair, I still can't find a single source to back up your higher figure, while I can find dozens with a quick Google search that quote a market cap of around the $40B that I and at least one other poster who replied to you were using. If you want the $60B you stated to mean something other than the most common valuation (market cap), you could clarify what exactly you're talking about instead, or the figure doesn't really further the discussion.

In any case, it still doesn't matter. Your argument for Zuckerberg's effectiveness is that he has built a very valuable company. Part of my argument is that it's funny money and the company isn't really that valuable at all. Whether we're thinking of the same kind of "funny money" doesn't make any difference to this argument.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Facebook has made a ton of mistakes, HTML5 does not rank anywhere near the top (it wasn't even the cause of their problems, there are plenty of well done HTML5 apps). Their app sucked, but was incredibly popular. Their new app sucks less and is still incredibly popular.

Because of their other "mistakes", I will not allow their app anywhere near my devices. A general lack of trust is a mistake that Facebook can't fix.

</comment><comment><USER18> What I find most interesting here is how so much in depth analysis is coming out of one, simple statement with a very obvious meaning. You know how people used to try to analyze the life out of Beatles songs looking for all kinds of hidden meaning, until one day Paul McCartney straight up said, "There is no meaning other than what's on the surface level."? I'm getting that same vibe here.

Mark said they bet too heavily on HTML 5. Did that mean the people who wrote the HTML 5 standards failed them? Or that Google and Apple failed them for writing code that couldn't sufficiently run HTML 5 apps? Or that they overestimated their engineers' abilities to write good HTML 5 apps? Or that they thought HTML 5 was going to be something that it isn't?

Honestly, I don't think he meant any of those things. There is no hidden meaning here: They used HTML 5. It didn't work they way they'd hoped. Now they're using something else. That's it. End of story.

Props to the guy for finding something that wasn't good and fixing it. That's what a CEO is for.

</comment><comment><USER19> It's not a surprise that a web software company would want web software to run and win everywhere, it's the same reason c++ devs want to write web apps in c++ even if that might be a terrible idea. In the end, the lesson is clear, you get what you optimize for. FB optimized for letting their web devs ship mobile code fast, and they were able to do that. The caveat is that the product they shipped wasn't that good.

Now they are optimizing for a higher quality product which requires different developer skills and resources. It seems to be paying off.

Neither strategy was wrong so much as maybe how long they stuck with a particular strategy.

</comment><comment><USER20> Browser vendors are trying to do too much. Innovation needs to move from top- down to bottom-up. Browser vendors need to provide just basic access to bare metal and let OSS do the rest.

One way to help is to ask for lower level OS apis to be exposed by browsers, so that the open source community can do the rest:

1\. Ask for UDP to be exposed to trusted web apps installed by the user. This will let the P2P community race ahead without having to wait for WebRTC to get released and then fixed.

2\. Ask for TCP to be exposed to trusted web apps installed by the user. This will instantly enable things like SMTP clients running in the browser without the need for WebSocket proxies/proprietary gateway servers.

3\. Ask for POSIX to be exposed to trusted web apps installed by the user. This will lead to an explosion of database innovation in the browser. IndexedDB is design-by-committee. Insist on proper POSIX not the FileSystem API. Borrow from the Node API. Impedance mismatch is crippling browser storage.

4\. Low-hanging fruit: ask for LevelDB to be exposed directly (<http://code.google.com/p/chromium/issues/detail?id=128865>). Most of the browser vendors are using LevelDB underneath IndexedDB, and just exposing LevelDB directly would already be a huge leap forward. No need to wait for the many IndexedDB bugs to get fixed by browser vendors.

<comment><USER21> That sounds like a horrible mess. Presenting users with "Would you like to give this site access to UDP?" is not a question most users can answer to any level of competency. Developers dream, users nightmare.

WebGL has been a good example of the difficulties you face when offering low level access- buggy graphics drivers could result in an all-out crash.

<comment><USER20> Your proposed solution and criticism thereof presume that there is only one way to delegate trust to a web app and that it should entail that the user understand UDP.

Consider Tim Berners-Lee: [http://lists.w3.org/Archives/Public/public- webapps/2012JanMa...](http://lists.w3.org/Archives/Public/public- webapps/2012JanMar/0464.html)

And Alan Kay: [http://www.drdobbs.com/architecture-and-design/interview- wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan- kay/240003442?pgno=2)

</comment></comment></comment><comment><USER22> Is it a case of HTML5 is a future disruptor, providing platforms don't try to subdue it in preference to Native? A good example is in mobile tech where a lot of apps that used data pre 3G performed poorly because the underlying technological dependencies (the data pipes, memory limitations and processing power) were not ready. Secondarily, the business models were not ready either (pay per MB).

Maybe HTML5 is in a similar position, may work well for web, but mobile app eocsystems are not yet technologically ready for it to be disrupted. We see it time and time again in history where a new tech takes a while before it becomes good enough to break through (CMOS vs CCD), (HDD vs Floppy vs Tape). (Mainframe -> PC -> Cloud)

</comment><comment><USER23> The iOS app is still crap compared to the web experience. Users can't edit, or even delete, their own comments. The length of time for likes and comments to appear is unpredictable. Sometimes very quickly, sometimes users don't see their own comments for half a minute. Art is displayed oddly. It's almost always clipped at top and bottom on the page, requiring an extra step to actually see it. They seem to be under the mistaken impression that mobile users are like Twitter users, firing shots into the darkness, instead of curled up on their couches with iPads, composing little essays and looking at family photos.

<comment><USER24> Don't forget copy and paste.

</comment></comment><comment><USER25> This is all very interesting, but I do think the concentration on HTML5 is something of a foil. Strategically, I was under the impression that Facebook was positioning itself to be a third independant force, alongside Apple and Google. Considering the state of play when facebook started up in 2006, when users flooded into the browser venue, and where the iPhone hadn't yet been released, and where the idea of socially contextualless search and data could be leveraged and superseded by the Facebook social graph, I consider the decisions made with facebooks mobile strategy to be explicable.

There was, after all, a lot of rumour that Facebook would release their own phone. This made sense if your objective is to provide an alternative to mobile OS's, and even more, to overtake your competitors. The belief including the possibility of evolutionary superiority.

Things change. Google supplies Chrome through the app store despite the restrictions imposed by Apple, and this has not weakened the power of Google at the expense of Apple. There are many examples of stepwise cooperation. It has not diminished their independance. And Facebook likewise should probably not have been so concerned that acquiescing to the other majors on mobile would pidgeon hole them as a very very big Instagram style dependant.

Facebook has lost time by being over guarded in my view. On the other hand, this admission by facebook demonstrates a recognition of a kind of failure. I suspect the notion that Facebook will grow to be an organisation that is an evolutionary step beyond Google is now viewed as the real strategic error by them.

As to HTML5 being a mistake, I could be wrong, but I don't really think that that's what he actually means. He's trying to explain himself without admitting some things.

</comment><comment><USER26> I am sorry to see any negative publicity for HTML5 adoption but I understand that FB is a special case. Saving money on mobile development is not a priority for them.

I think the situation is different for small companies and apps that have many fewer users: saving money on app development frees resources for content production.

<comment><USER27> I don't think they're saving money by making an HTML5 version. A slow app means less engaged users who are less likely to see or click on ads. At facebook's scale, that's potentially tens to hundreds of millions of dollars lost on the iPhone per year while it probably only costs a couple million to fund 5 engineers to make a decent native iOS app.

</comment></comment><comment><USER28> After some experience with html5 and javascript programming, I feel it is more and more like hacks, forcing natural application models into html5 with lots of hacks. Sure, there are applications fitting html5 well, but for many more others, I begins to doubt that html5 is a real good solution for future.

</comment><comment><USER29> What is the common understanding when people deliberately tack on _5_ at the end of HTML? I don't remember people talking about HTML _4_ like that.

Is there some expectation that HTML is suddenly a replacement for native apps? That's a rather unexpected (to me, at least) positioning of HTML.

</comment><comment><USER30> i hope this doesn't mean they will be forcing everyone into a native app. i ditched it long ago because their mobile site is quite good and 100x better for my privacy. same with yelp and youtube. gmail is good also, but i need the notifications there, so no choice but native.

<comment><USER31> Me too... their mobile site is better than their native app on android. the only drawbavck is qhe I try to share a photo it uses the native app.

<comment><USER30> i share photos by emailing them to the special fb status address. it's tiny bit more of a hassle, but i dont do it very often.

</comment></comment></comment><comment><USER32> Weren't the issues with their use of HTML5 more related to the lack of proper asset caching (CSS/JS), not so much the performance of the rendering and code execution?

When I used their app at the time, I always found myself waiting for the CSS for each view to load.

</comment><comment><USER33> What Mark Zuckerberg really said:

"When I'm introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn't there. And it's not that HTML5 is bad. I'm actually, on long-term, really excited about it. One of the things that's interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us."

[http://blog.tobie.me/post/31366970040/when-im- introspective-...](http://blog.tobie.me/post/31366970040/when-im- introspective-about-the-last-few-years-i)

</comment><comment><USER34> Slightly offtopic, but this is what I hate about tech reporting: <http://i.imgur.com/TYyKD.png>

There is an article for every statement that zuck made onstage. Getting pageviews is a priority, I guess.

</comment><comment><USER35> The main problem with native development is how you are not as flexible as your HTML counterpart. Even with the massive amount of capital that Facebook has, a full native app would always be behind.

Obviously, I don't work at Facebook so I don't know all the details, but I remember when Joe Hewitt built the native Facebook app, while it was awesome, it was lacking many features 4 months after it's release.

Since developing on iOS can take as much as 2 times longer than HTML development (+ the release cycle with Apple approvement system), it makes sense, in my mind, that they opted to have as much of HTML 5 code as possible.

DISCLAIMER: My first language isn't english.

<comment><USER36> Why isn't it as flexible? And a native app on a mobile device shouldn't try and replicate a full blown web app, it should have only the appropriate features that you would use on the go, but it should do these well and be snappy (read native).

<comment><USER35> Maybe for you, but the general public expect the same feature set. They can be presented in a different matter, but in the end they need to match. Look at the comment here, some people are complaining about lack of feature on the current app.

</comment></comment></comment><comment><USER37> It occurs to me that if someone came out with a new technology and said "hey, you can now describe your entire interface's structure in one markup language, the visual look in a second language, and the code in a third language, and then your app will run anywhere that has the required runtime interpreter" they'd be shouted down faster than you can say "go Swing".

Yet that's essentially what HTML5 apps are all about -describing the interface in markup and processing it at runtime. In what way is native not _always_ going to be better for a given platform?

</comment><comment><USER38> Guess what he's actually saying is that if you want to created "walled gardens" and locking-in users HTML5 is not the way.

So if you want to collect fees from publishers, don't own the browser or the OS (and are not the content creator) - use a closed app.

From the viewpoint of FB this might be (a short-sighted) way forward. It's not in the interest of the publishers and content providers - but again that seemingly doesn't bother FB.

</comment><comment><USER39> I'd say their biggest mistake is filtering the news feed by presumed interest. I talk to normal person after normal person who finds facebook increasingly more useless because this algorithm does not work correctly.

I sure am tired of hearing people talk about 'html5' as if the situation of native vs. browser apps is really any different now than it has been for the past 5 or 10 years.

</comment><comment><USER40> Instead it's sometimes better to build an app on top of its native environment from the early days rather than spending enormous time to figure out the best workaround for life. You might choose the tool you're most comfortable with to build everything, at the same time just never ignore the quality that the users will experience.

</comment><comment><USER41> A bad mechanic will always blame his tools. A saying the Facebook development team should print out, frame and hang in their building for all to see. Maybe Facebook should have asked the LinkedIn development team to build their app for them because they obviously know nothing about web development.

</comment><comment><USER42> I've got both iPhone and android phone, and I always noticed strange scrolling and slow response on the iphone when using the html facebook app.

I don't see these issues with the android version, and it doesn't seem like Facebook is jumping at getting a native android app out there.

Is HTML really to blame?

</comment><comment><USER43> Ditching the HTML5 app was a good call but _please_ fix the atrocious way the new app mangles images with the resizing/stretching. It really kills the speed of the overall experience when I have to enlarge every image to have any clue what its a picture of.

</comment><comment><USER44> This was just a strategy for Mark to downplay Facebook's troubles. Avoiding talking about Facebook's other problems by pushing HTML5 as their biggest mistake and saying how it's now fixed. This gives them more time and calms investors down.

</comment><comment><USER45> For those interested, here is the specific quote on video from Techcrunch's live : <http://www.youtube.com/watch?v=GBp_xCGIATk>

</comment><comment><USER46> _That_ is facebook's biggest mistake?

Is he blind or just wilfully ignorant?

</comment><comment><USER47> Finally someone gets it.

Applications should be done natively.

HTML is for documents.

</comment><comment><USER48> Sure, blame it on HTML5, the voiceless culprit. Blame it on the janitor, the office assistant, the programmer.

But never dare you touch a C*O for the failure of a corporation!

</comment><comment><USER49> This is absolute nonsense.

Here's an example of what a small team + HTML5 is capable of: <http://ro.me>

</comment><comment><USER8> I find it amusing that everyone tries to "interpret" what Zuckerberg is saying. It is in pretty clear 3rd grade English folks. Don't try to spin things too much. Of course there are always agendas, do you think that Steve Jobs didn't have agendas? I did not hear much reinterpretation of his statements in his latter years...

</comment><comment><USER50> I'm already seeing weird conclusions drawn from this. Anyone can tell you, the mobile web app for Facebook worked. Well. It was very, very fast and looked nearly pixel for pixel like the "native" Android app.

Thus, it seems pretty silly to act as if HTML5 is incapable.

</comment><comment><USER36> They are a bunch of PHP hackers, is it any wonder they can't write decent native apps?</comment>


IOS vs Android Fragmentation - <AUTHOR> http://www.businessinsider.com/chart-of-the-day-ios-vs-android-fragmentation-2012-6

<comment><USER2> Found this gem of a comment on the post:

If you're smart you'll target for your app for the OS not the device like any proper developer would do. Test it on multiple screen densities and resolutions, code auto-scaling of your digital assets job done. Fragmentation's just media hype. Commend link: [http://www.businessinsider.com/chart-of-the-day-ios-vs- andro...](http://www.businessinsider.com/chart-of-the-day-ios-vs-android- fragmentation-2012-6#ixzz1xZsn3yoh)

</comment><comment><USER3> Android seems to jump the shark more and more with each passing day. You've to work harder as a developer, catering for all the hardware and OS fragmentation in order to distribute apps on a platform riddled with piracy and sub-par apps.</comment>


What it's like to participate in Anonymous actions - <AUTHOR> http://www.theatlantic.com/national/archive/2010/12/what-its-like-to-participate-in-anonymous-actions/67860/

<comment><AUTHOR> The article was written by Professor Biella Coleman, an anthropologist and professor at NYU who studies hacker culture. She's written a lot about Anonymous, 4chan and /b/ and teaches a class on the anthropology of hackers at NYU.

<comment><USER2> Very richly detailed and clearly presented. "From at least this vantage point Anonymous starts to look more like a group of seasoned politics activists, debating the merits and demerits of actions and targets, warning for example, not to attack the media. Even if these documents cannot be taken as the totality of Anonymous, they reveal that some of the participants do engage in strategic and political thinking."

<comment><USER3> It's an appropriate counterweight, I think, to the unmitigated and much too facile condescension that some have been indulging in lately.

</comment></comment></comment><comment><USER4> It's easy to understand what anonymous is if you spend some time on 4chan/b/: it's people. Some of those people try to rally more behind some cause, be it just or lulzy, and many of those leaders will fail. Occasionally, some of the anonymous people agree and form a rally, which gains steam in the same way any fad does.

Anonymous is pure, direct democracy: equivalent to anarchy.</comment>


The Joy programming language - <AUTHOR> http://www.kevinalbrecht.com/code/joy-mirror/joy.html <comment><USER2> So called concatenative language is also a combinator-oriented language in a somewhat restricted form. Here are some historic examples of combinator- oriented languages: APL family and Backus's FP/FL (direct inspiration for the author of Joy). The fact that you denote composition of the functions with a white spaces is just a syntactic sugar. In the case of combinator-oriented language you work with various functional forms -- combinators, not just with composition, so you need to use more symbols to denote that. And in practice it's hard to find a concatenative language which would be used seriously, not just in a few hobby projects. In the same time there are impressive examples of modern combinator-oriented languages like Faust [1] and Spiral [2].

Still, the whole "concatenative" movement is interesting as a try to formalize the semantics and "improve" Forth language. See also Postscript and Henry Backer's articles [3].

[1] [http://faust.grame.fr/](http://faust.grame.fr/)

[2] [http://www.spiral.net/](http://www.spiral.net/)

[3] [http://home.pipeline.com/~hbaker1/ForthStack.html](http://home.pipeline.com/~hbaker1/ForthStack.html)

<comment><USER3> > And in practice it's hard to find a concatenative language which would be > used seriously, not just in a few hobby projects.

One could argue that piping commands in the shell is a very serious use of concatenative syntax.

<comment><USER2> In a general sense, yes, of course. Here are more examples.

1\. BNF notation. Yes, it could be surprising, but in a BNF-like language we use function-level representation and white spaces here denote sequential composition of functions -- nonterminals.

2\. In a some Lisp-like language one may use spaces to describe "abstract" composition. So, for sequential composition: "(seq func1 func2 func3)". And for parallel composition, for example: "(par func1 func2 func3)".

But in the case of real concatenative programming, which has its origin in Forth, you mostly deal with stacks and stack machines.

</comment></comment></comment><comment><USER4> Please relabel this as: "The Joy programming language (2005)"

</comment><comment><USER5> Quadratic formula in joy:

        DEFINE
        quadratic-3  ==                                # a b c => [root1 root2 ]
            [] cons cons cons                          # list of parameters
            [ [ [ [dup * swap] dip * 4 * - sqrt ]      # radical
                [ pop 0 swap - ]                       # minusb
                [ 2 * ] ]                              # divisor
              [i] map ]
            infra first
            [ [ [ + swap / ]                           # root1
                [ - swap / ] ]                         # root2
              [i] map ]
            infra first.

<comment><USER6> That doesn't seem very... joyful.

In q it's just {(q%x),z%q:-.5 _y+signum[y]_ sqrt(y _y)-4_ x _z}

This is easy to see is correct.

How do you know that Joy is correct?

I'm trying to mentally execute this. I know I haven't seen Joy before, but I've used Forth, Postscript and Lisp, so I feel like I have a lot to stand on:

\- cons seems to have the same meaning in lisp, so x y cons -> (x . y) or in Erlangish, [x|y] right?

\- x [y] dip seems to be y x

\- [x] [y] infra seems to be the same as [x y]

\- swap, first, pop, sqrt all seem reasonable

\- wouldn't [] cons cons cons _dup* be better than the extra list with [i] map ] infra first? it's not really clear to me what [i] map is doing... I see how the values have to flow, but it feels like it should be redundant.

I feel like it's immediately a lot more (mental) work. It reminds me of tracing forth code before I just gave in and started using variables like a normal person.

Is this really the best way to be introduced to Joy? Is this a typical problem that Joy programmers feel is the right way to program (and the right solution?) Am I missing something here?

<comment><USER7> Formatting note:

It will look a bit messier for the

      things*involving*asterisks

to be on their own line (indented two spaces), but that way Arc won't chew them. I'm mentioning this because I can't determine the original text myself.

<comment><USER6> Yeah, can't edit now.

        {(q%x),z%q:-.5*y+signum[y]*sqrt(y*y)-4*x*z}

</comment></comment></comment></comment><comment><USER8> I've been working on a dialect of Joy recently.[1] It's implemented in Python, in the Continuation-Passing Style. I've implemented type inference[2] and I'm almost done with a compiler (to Python for now.)

Joy combines the best features of Forth and Lisp.

It also makes "Categorical Programming" easy.[3] You can get a variety of valid computations by instantiating the same code over different categories. For example, the Joy type inferencer is an interpreter that operates on stack effect representations rather than e.g. numbers and strings. The same Joy expression that, when run on the normal interpreter gives the calculation, gives the stack effect of the expression when run on the inferencer. A subset of functions has to be overridden to make this work, but then you're good-to- go.

The mental models that you have to adopt to develop in Joy are _better_ than those for other languages. There's a purity and elegance in the Joy notation that continues to be very exciting and interesting. For example, check out "Recursion Combinators"[4] which is loosely based on the first part of the "Bananas, Lenses, & Barbed Wire" paper[5].

My interest is binary: 1.) Joy is a notation and semantics that normal everyday people can easily understand and use; I've developed a user interface based on Joy as the unifying, uh, interface (both GUI and text interaction result in a stream of Joy commands) and I'm going to be setting up "encounter groups" and live user testing starting this month. I'm going to put normal people in front of a raspberry pi that's configured as a kind of Joy kiosk and see what happens.

2.) Joy is an excellent vehicle for developing proven-correct code. Most Joy development is more akin to deriving mathematical proofs than "regular" programming. Joy delivers on the promise of Functional Programming: making software by doing math. In Joy it's easy. I can write parsers that translate existing code into Joy-as-AST and then do refactoring and simplification. Recently, (the last couple of days) I've been playing with Prolog to represent Joy code. This has worked really well. It should be easy to make powerful code transformation tools.

Anyhow, to sum up: Joy is _really_ cool. It's enormously simple and oh so elegant. Y'all should check it out.

[1] Thun [http://joypy.osdn.io/](http://joypy.osdn.io/)

[2] [http://joypy.osdn.io/notebooks/Types.html](http://joypy.osdn.io/notebooks/Types.html)

[3] [http://conal.net/papers/compiling-to- categories/](http://conal.net/papers/compiling-to-categories/)

[4] [http://joypy.osdn.io/notebooks/Recursion_Combinators.html](http://joypy.osdn.io/notebooks/Recursion_Combinators.html)

[5] [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.1...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.125)

</comment><comment><USER9> Joy has come up a few times. A powerful language built on a few clever principles is alluring, but I found it impossible to read, sadly (but I feel somewhat similar about Forth).</comment>


Loop, a new zero-waste platform that may change how we shop - <AUTHOR> https://www.fastcompany.com/90296956/a-coalition-of-giant-brands-is-about-to-change-how-we-shop-forever-with-a-new-zero-waste-platform <comment><USER2> re-using instead of recycling the containers is obviously a good idea, but it's not really an invention, it's how things used to be in the past. I applaud the concept, but really it is governments who should be applying a differential tax rate for products in re-use containers compared to those in "disposable" containers.

I'm afraid their business model is really just making a walled garden re-use system, which will really only serve to entrench brand loyalty, for those brands they allow in their re-use cartel. I can easily imagine them having received or intending to receive government subsidies for this "green" brand loyalty project. If this is the case the governments would have been better off directly organizing this in a level playing field. It won't be green if the bulk of the population can not afford these brand products, and if the off-brand products are individually too small to each organize their own re- use systems -which will also take up shop space etc for shops that co-operate- so really it should be a brand-agnostic system, and instead of subsidizing a couple of top brands for their green intentions, we should make sure that we return to re-use containers we had in the past, but with a level playing field so that it becomes easy for any brand to partake and select containers from the government catalogue, or an easy process to negotiate new containers that better meet their demands...

<comment><USER3> i.e. "Bottle deposits. You've invented bottle deposits."

A quick Google shows that the US is one of the few developed countries where this is not widespread and has been lobbied against. Here there's automated collection machines in most supermarkets, and drinks are sold in reusable plastic crates holding glass bottles.

<comment><USER2> Yes, I totally agree there is no innovation, it's always just stalling to come up with a standard against standardization. Like the limited vendor ID space in USB, etc

Here in Belgium the bottles get washed for a few cycles, and then remolten for a few cycles. And we also have the automated bottle collectors etc... Still I think there can be improvement with other containers for other product types as well, but it should really be standardized sizes, otherwise it's just sabotaging smaller shops who don't have the space to store 100 different kinds of crates for the containers, and smaller suppliers who could be blocked or taxed by the reuse container cartel.

This is why it should be a government role to coordinate the standardization so that it is open for any producers to join in a symmetric way. Then even smaller shops or neighborhood collection sites can cooperate with only limited types of crates.

I'm thinking it would need some kind of sizing standard similar to A2,A3,A4,A5 paper sizes, but instead of areas, volumetric dimensional standardization. Give each container a unique QR style code, so you can look up the product description and so on...

</comment></comment></comment><comment><USER4> When I grew up in 1980s Britain, we used to have milk delivered in re-usable glass bottles. Deliveries and collections occurred daily, and were done using an electric vehicle[1]. It's interesting to look at why this approach (popular until fairly recently) has declined.

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

<comment><USER5> If you went back further even more things were delivered to your front door. Coal holes[0] can still be seen in many streets, and there even used to be a 'pop' man who'd bring soft drinks around. There also used to be deposits on glass bottles that were washed and reused.

Talking to people who actually used to get milk delivered, the usual complaints seemed to be unpredictability of arrival, it freezing in winter and getting too warm in summer. Birds & squirrels would occasionally get to it too. I've also heard stories of milk men continuing to deliver when people were away coming back to bottles of off milk.

I think the model also works much better when there is someone at home for most of the day.

I didn't find any good information on historical milk consumption in the UK, but it wouldn't surprise me if it had decreased over time as well.

[0] [https://en.wikipedia.org/wiki/Coal_hole](https://en.wikipedia.org/wiki/Coal_hole)

<comment><USER6> The explanation in the first paragraph of that wikipedia article seems like a perfectly fine explanation, more stores started stocking fresh milk so the milkman wasn't needed as much any more because milk could just be picked up with the rest of the groceries.

<comment><USER7> Maybe in a few years we will go full circle and there will be 30-minutes delivery of fresh milk by drone.

I find interesting how Germany deals with empty bottles: [https://german- dude.de/blog/guide-recycling-bottles-germany_...](https://german- dude.de/blog/guide-recycling-bottles-germany_506/)

<comment><USER8> Works like that in Norway too. Almost every supermarket has a machine for returning bottles.

</comment></comment></comment></comment></comment><comment><USER9> I did not see a mention in this article regarding the average expected price premium for a Loop-version of a product versus a non-recycle/upcycle version of the same product.

I went looking for additional details to see if I could track down an answer, but I haven't clear indication. Granted it's a new(ish) model and the consortium is likely in the middle of market research and pricing experimentation.

A packaging industry news source, Packing Digest, has additional information about the offering and an interview with TerraCycle CEO Tom Szaky[0]. In it I get a glimpse of the subscription-based, mid-sized ordering model they seem be leaning to:

"Q:: If consumers return the package for refilling/reuse once it's empty, won't they run out of product? Or is the concept to create a pool of packages that are reused for/by different consumers? For that matter, is the concept to create a pool of packages that are used/reused for/by different brands?

TerraCycle: Loop brings to market a new subscription model: subscription based on consumption. Since the empty packages are returned to Loop, we are aware of consumers' consumption rates and replenish only when they have finished the product. The target for turnaround is two days."

Reusable glass bottle milk delivery (direct from a local dairy) and retail sales (Whole Foods, your local boutique health food store, etc.) have worked because it's a commodity product, available in reasonable quantities on demand, and bottles can be stockpiled for a time before being returned if needed. The deposit costs aren't (at least where I am located) a make-or-break situation, but ultimately I buy them less for the ecological benefits, though I recognize them, and more for the quality differences when compared to the waxed cardboard, ultra-pasteurized regional alternatives.

Would I spend more for the same P&G or Unilever products? Especially if I had to pay an upfront premium for the product, worry about a deposit, AND handle my own return shipping? I'm not sure.

[https://www.packagingdigest.com/sustainable- packaging/loop-b...](https://www.packagingdigest.com/sustainable- packaging/loop-brands-boldly-reinvent-waste-free-packaging-2019-01-24)

<comment><USER10> > _If consumers return the package for refilling /reuse once it's empty, won't > they run out of product?_

This happens for any product you buy anyway, and the solution is to always have one extra. I assume (hope) that such buffering scheme will be available.

> _Would I spend more for the same P &G or Unilever products? Especially if I > had to pay an upfront premium for the product, worry about a deposit, AND > handle my own return shipping? I'm not sure._

Personally, if it was shown to be environmentally better - or even equivalent - solution, I would in a heartbeat. I absolutely _hate_ that we use so much disposable packaging.

I also hope they eventually centralize it a bit via stores, because extra shipping ain't good for environment either.

</comment></comment><comment><USER11> I hate all the shipping, but this is a pretty cool idea. If they could setup container return and shipping centers at the grocery store, for example, then it might be cost-effective.

<comment><USER12> Everything is shipped.

The difference here is that the last mile is also done efficiently by package deliverers, rather than in a car that is empty on the way to the store, and has 1-4 bags in it on the way back.

I would also like this to reach retail, for a variety of reasons; the ecological cost of shipping is last on that list.

<comment><USER13> "...a car that is empty on the way to the store, and has 1-4 bags in it on the way back."

This may be true in general, but is not the average means of grocery transportation in their initial target markets of central New York and Paris. Dense urban centers are well-suited for efficient or zero-emission (bike courier, for instance) shipping schemes though. What retail placement of the same offers in an urban environment is actually convenience because it's easier to walk into the shop below your apartment than to schedule and wait for a delivery.

The problem to be solved here is extractive raw material waste from single-use packaging. Ecological shipping cost is non-zero, but there are zero-emission alternatives already available. Convenient zero-waste consumables, however, do not yet exist at scale.

I'm not holding my breath, but it would be huge if one or more of these large brands bet big on a zero-packaging distribution mechanism and actually pulled their packaged products from the shelves. At a certain scale that would probably increase profit margins because it reduces raw material input costs.

</comment></comment></comment><comment><USER14> Cool idea! It also seems like these brands understand some kind of reckoning is coming and are trying to get out ahead of it. I'm not opposed to the idea of reusable containers, but this model seems to come with a lot of brand lock- in.

Precycle (precyclenyc.com), a bulk grocery store in Brooklyn, is my ideal model. Customers bring in their own containers, weight them on entry, and then pay the difference in weight on their way out. Not do you save the packaging, you can purchase exact amounts of each item.

<comment><USER15> I'm totally up for paying a bit more and supporting these brands if it means less landfill and perfect recycling. This model works for a lot of things and packaging will always have advertising on it as unfortunate as that is. I've thought for a long time about government mandating containers but companies willing to do this is a great thing; I look forward to the day when I take all of the packaging with me back to the supermarket for it to be reused!

</comment></comment><comment><USER16> I'd like to know what the breakeven point is. How many times does the package have to be used before it becomes less resource intensive than single-use packaging, and how long will it take. I use honey (an example on the terracycle website) but I probably go through a bottle a year. If the breakeven is 10 uses, that would be 10 years worth of honey consumption. Even for shampoo, toothpaste, and laundry detergent I don't go through very many containers a year (but I buy big containers).

It seems like it will take years of re-use to make it less resource intensive, what's the chance a bottle will get lost, broken, or forgotten about during that time (or loop will go out of business).

<comment><USER17> The idea (I'm sure) is to avoid waste as much as conserve energy use. In fact I from an energy perspective it's probably awful. But they have to establish themselves; they have to get an inventory of products and a customer base. Then they can make deals to put recycling points in every supermarket and have their recyclable packaging available along side conventional packaging. In other words, don't think about today, think about where this can go tomorrow.

Also, if your packaging consumption consists of a jar of honey and a few personal items, you are far from typical (but good! Whole food diets are great). Many people consume lots of packaged foods and goods. In any event, you have to think of this spread across billions of people consuming goods.

Finally, reusable packaging is not new. You charge a deposit large enough to incentivize the consumer to return the packaging. This has been done with glass bottles.

I bet their angle is that they can handle a wide variety of package types and quickly calculate customer refund amounts. I.e., each container will have a unique id (QR code, rfid). I would say this is why the model hasn't worked until now...it was too difficult to manage the menagerie of containers and quickly processing refunds. So it might work for water or milk, but it wouldn't work for 300 different container types in a supermarket.

Side note: if each container has a UUID, you could track how fast people are consuming products. How much butter DID you consume last week? There are real privacy implications, as I'm sure that data would have monetary value to advertisers and health insurers.

<comment><USER16> I'm not sure that you should separate the "avoid waste" and "conserve energy", they seem intertwined to me. Recycling in the supermarket is part of their plan, but I don't know how much it matters (there are UPS trucks going through my neighborhood every day, the amount of extra energy required to stop at my house versus me driving to the supermarket seems like a wash).

My packaging consumption consists of a lot more than what I stated, I based my comments on the partners they listed and the examples they gave (on the terracycle website), they are going to have to move in to products that get used up every week or two, not ones that get used up a few times a year to actually have an impact.

Side note: the parent company, Terracycle seems like it is more about giving you the feeling of saving the environment instead of actually having a positive impact. Current promotion: recycle little-bites (a brand of muffins) packages by packaging them up and mailing them in, the cost (resources and energy) of doing that is far above any value the get from recycling a few ounces of packaging.

</comment></comment></comment><comment><USER18> I'm all for solutions to this, but I just can't see this taking off. Loop seem to be trying to be too much of the process (I don't want to buy from them), and trying to piggy back on widescale infrastructure such as UPS (whereas I want my council to collect these as part of my regular waste collection).

I think a combination of more standardised packaging, more recyclable packaging, and more local support for things like re-usable glass containers with deposits (as are common in Germany) are the way forward.

Of course brands won't like this, because when every bottle of shampoo comes in the same shaped container it's much more difficult to differentiate between brands.

<comment> dao- > re-usable glass containers with deposits (as are common in Germany)

These containers are for recycling glass, not for reusing bottles. Reusable bottles need to be brought back to the store, which Loop appears to be planning for too.

<comment><USER19> As a fellow German, I can see why this is confusing, but GP's "glass containers with deposits" refers to Pfandflaschen, not to Altglascontainer. "Deposit" is English for "Pfand".

</comment></comment></comment><comment><USER20> It's good to see this. I hope they offer the same products with the same reusable packaging in supermarkets. I go grocery shopping multiple times a week anyway and can pick up and return these items at the same time.

<comment><USER9> This is the business model improvement I'm anticipating will make all the difference. Localized supply chains (conceptually) should reduce end-consumer cost, but it will be an uphill battle until wider adoption makes it feasible.

</comment></comment><comment><USER21> Sounds like virtue signaling. I doubt the environmental impact is lower when considering the additional shipping and more durable product packaging. "But there's so much plastic in the ocean, we need to do something about it", it's called a landfill.

<comment><USER22> Per Peter Drucker, blockbuster products are lifestyle products, aka aspirational, virtue signaling.

The examples from his books that I remember are Marlboro cigerettes, Ford Mustang, VW Bug...

</comment></comment><comment><USER23> The UPS truck probably emits significantly less CO2 per delivery than the average American trip to the grocery store.

</comment><comment><USER24> At least someone is trying to fight Amazon. And this could well become a worthy competitor.

So what's really happening here?

1\. FMCGs will design new packaging meant to last 100 or more uses. So FMCGs will basically get to sit longer on home shelves & aesthetics of packaging will play a greater role in buying decisions - expect to see the iPhones of FMCG market. The longer life of packaging would soon make it a marketing horse race.

2\. Consumers will drop used products in a Loop tote, picked up by UPS for reuse. This will trigger repeat buys (and Loop is obviously providing a subscription service). That tote is nothing but Amazon Dash in new skin.

3\. Loop is a joint venture by top FMCGs so Loop will have exclusive distribution for the new-skinned products - and there you get the competitor for Whole Foods buyer Amazon.

4\. Green consumers could be scooped easily and others could just opt-in because of iPhone-like packaging that not only lifts home aesthetics but also eliminates ownership of secondary storage ware like soap dispensers, grocery containers, etc.

</comment><comment><USER25> Shipping these back and forth seems to add much more waste (and cost) to the equation.

I'd rather see grocery stores expand their "bulk sections" (where you self- serve just the amount you need and pay per weight) more. In its current iteration it's generally limited to nuts, oats, and grains and it uses a lot of plastic bags, but I know some stores that offer glass containers to purchase or you can bring your own.

Imagine being able to get almost anything in this way at the grocery store. Just want a pint of ice cream? Bring your glass jar and have the attendant scoop it for you (like at a real ice cream shop). Just want a few chips as a snack instead of the normal bags? Bring a reusable container and grab just a couple.

I feel like this offers a lot more flexibility and would truly reduce waste. A drawback though is that you have to remember to bring all your containers when shopping, but with enough practice it becomes second nature (like bringing reusable bags nowadays).

</comment><comment><USER26> Looking forward to this but my Scottish granny has been doing this for years for a few certain things.

If you go into her kitchen you will see tins, empty coffee jars, grease proof paper recovered from loaves of bread etc.

Fond memories of going to school with a pack lunch in a small shortbread tin, with nice sandwiches wrapped in a reused Warburtons loaf wrapping.

</comment><comment><USER27> I recently heard that the reusable grocery bags are actually _more_ wasteful than the single use ones because you have to use them ~500 times to break even and most people get far less use than that.

I wonder how many times you have to use your Loop metal ice cream container for this to work?

<comment><USER28> "Break even"? Who cares about the cost of reusable grocery bags.. really. We have 4 of them in our cupboard. Bought from Whole Foods. We use it everywhere we go. $40, maybe? Years ago..? That's not a real burden (to me), especially against environmental degradation, pollution, waste, etc.

There's the suggestion that paper cups are more environmentally responsible than ceramic mugs, because of the carbon cost of making ceramics. You have to use hundreds of paper cups to achieve the same environmental impact of one ceramic mug. That's a consideration I'm personally curious about...

<comment><USER27> Sorry I meant the environmental break even point. The same as your ceramics question

</comment></comment></comment><comment><USER29> I think the world needs a more efficient last mile delivery service. Like tubes or something. Guess it wouldn't be so bad if we were fully transitioned to electric vehicles, powered by renewable energy... But that's going to take 20 years at a minimum.

<comment><USER30> I thought about this for a while, and decided that spherical crates moving through tubes with rollers on the inside--occasionally a powered roller or switch--might work. But then I figured out that a spherical envelope big enough to deliver a decently-large pizza order is likely also capacious enough for a child to try to deliver himself to a friend's house.

And that means the system has to assume that every crate has a kid in it. Or a baby. Or a dog. Or a goldfish. Or a burglar. Or a bomb. Or solid concrete. Or sloshing water. Or a live sample of anthrax. You can't easily idiot-proof it, or guard against intentional acts of malice.

So you might as well go all in, and allow people to deliver themselves through it, by design, as a transit network. Make the spheres 1 m diameter, with a 525 kg gross weight capacity. People can fold themselves up inside one like a Mercury astronaut, if they like. The terminals would look like a cross between a giant bowling ball return and a roller coaster boarding platform. Unmanned crates would likely need some means of disgorging their contents, with the recipient's permission, and then returning to the sender, without direct human intervention.

But wait. That's not wheelchair accessible. So scale up the spheres again, to 2 m diameter, and 4200 kg gross weight capacity, with boarding ramps at every terminal.

It starts sounding really expensive, especially trying to retrofit a city with delivery tubes. Because now someone might want to replace an elevator shaft or two with tubes, and put one delivery terminal in every N floors. I've basically just replaced all the cars and delivery trucks with Wonkavators.

</comment></comment><comment><USER31> For anyone interested in this, check out [http://reddit.com/r/zerowaste](http://reddit.com/r/zerowaste)

</comment><comment><USER32> A smart grocery chain would put kiosks for this in their stores where you can get the refills and return the bins to drive repeat traffic. That's where this makes sense. They could save on shipping and logistics vs sending a UPS or USPS driver to each person's house for pickups.

In many major metro areas there are already bulk stores that sell soaps and foods where you bring your own reusable container in.

</comment><comment><USER33> Relevant article: [https://www.nytimes.com/2016/03/14/t-magazine/food/precyclin...](https://www.nytimes.com/2016/03/14/t-magazine/food/precycling- food-packaging.html?mcubz=1)

Interestingly, it ends with the sentence "How long, then, until Brooklyn catches on?"

</comment><comment><USER34> >>The order will show up in a reusable tote–designed by engineers at UPS to withstand repeated journeys–instead of a cardboard box.

I've always wondered why the scalable/reusable shipping box wasn't a thing. To me, this is would be an incremental improvement over current shipping.

<comment><USER35> Yes, this seems like the most logical place to start, especially with so much being shipped now.

Dumpsters are constantly overflowing with cardboard boxes. It has also basically been done before quite successfully with shipping containers.

</comment></comment><comment><USER36> > Loop will send you name-brand products

and then

> you ship the empty container back, where it gets cleaned and reused for the > next customer.

and then

> zero-waste platform

So, all the packaging and shipping back and forth is zero waste? Honestly, recycling those containers seems to be much closer to zero-waste than whatever this is.

<comment><USER37> > recycling those containers seems to be much closer to zero-waste than > whatever this is.

I'm skeptical that any community really recycles all the plastic that gets sent for recycling. Especially now that china isn't taking our trash. Personal care products like lotion and shampoo are always going to be heavily contaminated with the products, and probably need extra work.

<comment><USER36> I'm biased because I live in Sweden where recycling is everywhere. So here Loop's approach would actually increase waste :)

</comment></comment></comment><comment><USER38> Delivery trucks might have to be less full now, because you need room to bring stuff on as you take stuff off.

Previously, you could fill the truck up 100%, as long as it's in the reverse order of delivery.

<comment><USER8> But someone still had to take away the empty containers.

</comment></comment><comment><USER39> If this could be combined with amazon, then that would be amazing.

</comment><comment><USER40> Looks amazing! Can't wait for it to be in the UK!

</comment><comment><USER41> More likely not.

</comment><comment><USER42> [mis-post, replied to wrong thread.]

<comment><USER43> I think you replied to the wrong link, you are probably looking for this:

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

</comment></comment><comment><USER44> So, they are going to apply this to diapers too? You'll store up a box full of them and give that to the loop delivery man?

<comment><USER45> It's long since been done. My kids (now in their 30s) went through babyhood with cloth diapers and the weekly diaper service. Dirty diapers were simply dumped in a (airtight!) sealed bin which got left outside the door on pickup day to be replaced by a fresh bin full of clean (sterilised) diapers for the coming week.

<comment><USER46> > cloth diapers and the weekly diaper service

These days we have washing machines!

<comment><USER47> Diaper service was a massive industry at one time despite people having washing machines. Babies produce a lot of soiled diapers and having fresh sanitized diapers was a godsend. It was an early subscription model.

<comment><USER48> [Anecdote] I've had multiple friends who started out with a reusable diaper subscription for their first baby and none of them lasted even a year or tried again with their second child.

<comment><USER22> Maybe because of logistics. We had to switch from cloth to disposable once kid started preschool.</comment></comment></comment></comment></comment></comment>


Ask HN: How do you organise and discover your team's internal scripts? - <AUTHOR> As a team we have many scripts for doing various internal tasks - domain-specific things, checks for questions like "what's in prod?" and "how far along is this commit?", etc. ad nauseam.
The problem is that, with a few exceptions, the person who wrote the script knows it exists and how to use it; and might be around to chime-up with "hey, I wrote a script for that!" when someone has a problem.
But discoverability is hard, even if they're in the repo not everyone will have seen or reviewed the PR that added them.
Does anyone have some good tips to share on how to (or not to) organise such scripts or tools, and allow colleagues to better discover them? <comment><USER3> We encourage our teams to set their utility scripts as Jenkins jobs (integrated with source control).

\- The Jenkins job can have a friendly name, a description, a link to wiki article explaining how it works, and default inputs.

\- Troubleshooting wiki articles also link back to the job (_"Getting this error? Try running this job"_)

\- We don't need to worry about people having prerequisites on their machines (assuming they are installed on the Jenkins runner). They shouldn't even need to understand the language the script is written in, or how it works.

\- You've got the opportunity to integrate and chain jobs together, or trigger them based on events.

\- Pretty much everyone knows how to create and run Jenkins jobs

Of course having solved one problem (discoverability and organisation of scripts) you now have another one: Jenkins.

<comment><USER4> > Of course having solved one problem (discoverability and organisation of > scripts) you now have another one: Jenkins.

I called this phase 2. Discovery, documentation and ongoing maintenance going to be the problem. We need to another jenkins to CI/CD the main tooling Jenkins.

My other though is that there is significant market for this kind of back office tooling clean up and ongoing maintenance. If we could come with a process to clean up and package it. we could sell it. I would definitely buy it cause it gives lot of time saving for day to day toils especially in operational space.

<comment><USER5> There are hosted CI solutions that can orchestrate locally installed agents. The two that come to mind are Microsoft's Visusl Studio Team Services and AWS Code Deploy.

For both, you install a local agent that polls the website for commands. You can manually kick off a "deployment" that just downloads and run scripts. Both have agents for Windows and Linux.

VSTS is free for private environments for five users and like $5 a month for additional users for one simultaneously running agent - you can have as many agents as you want installed but only one will deploy at a time. Additional simultaneously running agents are cheap or free for each registered MSDN subscriber who is a user.

AWS Code Deploy is similar. It's free for AWS hosted EC2 instances and a 1 cent for each on prem deployment.

They both support the concept of deployment groups where you can run the same deployments on a group of machines.

Code Deploy uses a simple YML file that tells Code Deploy which scripts/batch files to run.

They both support integration with GitHub via webhooks.

</comment></comment></comment><comment><USER6> I can't believe no one here (currently) has mentioned this ... but IMO in an ideal world, the issue of too many utility scripts means that "your system" (whatever that means to you) is lacking. This leads to users/administrators needing to find ways around the system to get what they need.

The (idealistic) answer, is that when a given script finds more than a few users, or even gets used more than a handful of times ... it should be incorporated into, and formalized, in the system. Make an admin panel/portal/dashboard, put a UI in front of the script for any variables, and make it so that this function doesn't require cryptic institutional knowledge to execute.

</comment><comment><USER7> I've found that most scripts can/should belong to a specific project.

We've started adopting the `s/` method described here by Chad Austin: [https://chadaustin.me/2017/01/s/](https://chadaustin.me/2017/01/s/).

It means you always know where to look and it's easy to see what scripts exist.

</comment><comment><USER8> Version control + code review has worked for me. Even if you don't do code review normally, it's particularly helpful with making sure that someone is aware of scripts.

</comment><comment><USER9> I think the best solution is to use a tool like StackStorm, Rundeck, Wooey ([https://github.com/wooey/Wooey](https://github.com/wooey/Wooey)) or even Jenkins (as mentioned in some other comments), and standardize on adding new scripts to that system. This has the benefit of not needing to cater to individual environments -- you can get it running on a server and call it good.

I wrote and open-sourced a tool called Scrypture ([https://github.com/mosesschwartz/scrypture](https://github.com/mosesschwartz/scrypture)) some years back that partially addressed this need. It served as a central place that everyone could add their own scripts to, and it made it easy to expose the scripts through a web interface. Today I think going with one of the tools mentioned above would be more robust, but it goes to show that this is a real need for a lot of teams, and there really isn't a recognized single best solution.

</comment><comment><USER10> Have an uber-script which allows the various other scripts to register with it and provide the namespace, command, help data, args, etc.

Let's say our project is called cob, so typing `cob` would print a help screen of all the tools it knows about. typing 'cob db' would show all of the tools in the db namespace. For simplicity there is only one level of namespaces allowed. Anything under that is a command in that namespace - eg 'cob db recompute_index --column=foo' to recompute an index, 'cob deploy show_live_version --prod' to show whats in prod right now, etc.

If you're doing a task and think a tool might be available, searching through a limited set of tools based on the likely namespace and with simple help text makes it easy to find.

<comment><USER11> In Python world, we've had some success using Click ([http://click.pocoo.org/](http://click.pocoo.org/)) this way, and for SSH- heavy workloads Fabric ([http://www.fabfile.org](http://www.fabfile.org)).

<comment><USER4> We ssh-heavy workload, we use ansible. We have jenkins master with dokerized slaves where we throw the scripts in dockerized containers

</comment></comment></comment><comment><USER12> Disclaimer: I built [http://nurtch.com](http://nurtch.com) for managing executable runbooks/playbooks.

There are two core problems here,

\- Discovery: Does the script to do X exist?

\- Documentation: What does this script do? What are the parameters? How do I execute it?

Writing these scripts with Jupyter notebook solves both these problems effectively,

\- For discovery, you can search by keyword & organize in a hierarchy (e.g. folder for separate services)

\- For documentation, code snippets and instructions are interleaved in a single document.

You can host Jupyter remotely, your teammates can login, search for their scripts and execute from within the browser. No need to worry about dependencies/environment etc.

</comment><comment><USER13> \- Everyone runs the same Linux distro. There a signed Ansible repo that everyone uses to set it up, and an internal package repo for things missing from the main repos (for security reasons, nothing is installed that's not in either the distro or our repos). This ensures that everyone has the same local environment and scripts can be re-used.

\- Each project has a "scripts" folder with utility scripts and there are playbooks in Confluence on when and how to use them.

</comment><comment><USER14> First make sure that the scripts are in a vcs and if it is possible make sure that someone else looks over them before they are checked in. Often the awesome "DB_backup_script.sh" is not so awesome. If the scripts are not documented document them, so that others can use them and know their limitations. One way to allow other users to find scripts is to embed them in a grouped/sorted way into a wiki with instructions on how/when to use them.

</comment><comment><USER15> Have you considered using 1 script? For example, you could have a script called foo with multiple subcommands that do various jobs, then the process of discovery is as simple as running foo help occasionally. Coupled with some good docs, the occasional tech talk and sharing command examples on IM will soon make it part of your culture.

</comment><comment><USER16> Our current solution is to use a "toolchain" git repository that helps to automate installation of 3rd-party software (so that we're using similar versions of things like Docker, Python, etc.), but also creates a company- specific directory with installed scripts that can be added to the individual's PATH.

</comment><comment><USER17> The real trick I've found, is having regular conversations about your problems and knowing the domain experts.

For instance, I know this one guy is good at Dev Ops. I send him a ping asking a question, he forwards me to the other guy.

That's the most efficient way I've found after years of development...

<comment><USER18> Except when you're on the other side: unable to do any development because people keep coming to you with questions.

<comment><USER17> I do have it the other way, it's just redirecting or providing a link.

I ensure my management team understands and sees how many people I help. If I can spend 5 minutes several times a day - each time showing someone where a script is that saves hours.. well I've just saved the company a lot of money.

</comment></comment></comment><comment><USER19> You have three kinds of problems wrappped up in here and my software-socialist hat tells me it's all the fault of poor management:

1\. Good software engineering is about writing tools (scaffolding) around the main project (sistene chapel). If a team is not putting in something like 1/3 to 1/2 its time on tooling it is probably being pushed too hard or seeing too many of the other project warning signs we all know and love.

2\. Social contact and pride. If devs have _plenty_ of time to write their tools, then they get proud of them, make the more generic and usable and they start to market it (hey I have a script that does this is marketing as much as OSS ) Brown bag lunchtime sessions seem the perfect way to encourage this - <USER2> a Big Bank we had a kind of show and tell for internal scripts for a while.

3\. This is what senior devs, tech leads, what have you, should be doing - talking amoungst themselves and emerging the critical missing parts in the company (besides recruiting and code reviews). Again if they are not - it's a sign of too much pressure, too much silo'd working.

In the end I have some code I happily tell people about and encourage them to use - because I have invested the time to make it work well, and if I have not, I don't coz its embarrassing.

Fix the management / time / good engineering problem and you will find the scripts being shared in the canteen.

Of course fixing that is not something you have authority or influence to do. This could be a problem.

</comment><comment><USER20> In my experience doing pair programming is a great opportunity to discover such scripts.

</comment><comment><USER21> For powershell I've setup a master profile that manages and loads modules stored on an admin file share. Scripts are then added to individual modules (e.g. ad, exchange, etc...) on the share as needed which will prompt individuals to update their local copy. Version control, script signing, and other features would be nice, but in reality it's only one or two individuals updating the modules so it's more of a way to kiddy-ise scripts for other team members to use.

</comment><comment><USER22> An internal wiki for engineers and that has a list of concerns with individual articles for solving known issues/tasks. Plus a culture of encouraging each other to write or update wiki pages when they have an issue.

If you have the time and motivation to write an internal tool, you should also have the time and motivation to write down the how and why.

If you want to make a tool a part of your process, document that process and where to use the tool.

</comment><comment><USER23> I have a .local_profile script in my project root and added this[1] to my .bash_profile

So, each project has its own set of aliases and utilities in the repo.

It's not the cleanest thing to do, but it works pretty well.

[1] - [https://gist.github.com/rlopezcc/7d545a2b09a9c7a391483608a51...](https://gist.github.com/rlopezcc/7d545a2b09a9c7a391483608a51a3f3f)

Edit: Formatting.

</comment><comment><USER24> Treat them as runbooks and include them in your troubleshooting guide (or oncall guide).

Small snippets can be in a wiki or in the docs, bigger scripts preferably in a repo that everyone can run.

If they provide useful info that's not just for emergencies or troubleshooting, maybe let them run via cronjob and expose the results in a dashboard or a dedicated internal "status web page".

</comment><comment><USER25> Enforce a single Git repository for all common scripts, and enforce pull requests for every script inserted into that repository, no exceptions. Lock down `master` to either an approved releaser or a release bot to further enforce this.

Scripts that aren't in that repository are landmines waiting to explode into Critical bug reports.

</comment><comment><USER26> Most scripts do not have reusability and not warrant sharing. If they do, make them into a library.

</comment><comment><USER27> Our projects put all one off scripts in a ./sbin directory (organized as one sees fit, task-sub-dir, user-sub-dir). And each script follows a specific header. It's discovered by both Doxygen and when we grep the code base.

</comment><comment><USER28> Maybe having a dedicated slack channel would be interesting. Each new message would be pointing to documentation/PR, pinging teams that might find it useful for later use.

We use a private wiki grouping how to's, scripts, guidelines.

</comment><comment><USER29> We are trying to use [https://slab.com/](https://slab.com/) to share those kind of stuff, it's been a great addition.

</comment><comment><USER30> Using Rundeck is always an option: [https://www.rundeck.com/](https://www.rundeck.com/)

</comment><comment><USER31> We have a repository that contains various checklists & tools/scripts for all of our projects.

</comment><comment><USER32> We use an internal scripts repo and a chat webhook so our chat is notified when something is pushed.

</comment><comment><USER33> There are a couple of ways:

1) a git repo in an obvious place

2) a shared drive in $PATH

even better, a share controlled by a git repo.

</comment><comment><USER34> i have not any idea about it.

</comment><comment><USER35> Your problem (just about everyones problem) is the same problem.

If you did it, document it.

Make sure that what ever tool your using for documentation supports full text search, and tagging.

<comment><AUTHOR> > what ever tool your using for documentation supports full text search, and > tagging.

Any suggestions?

<comment><USER36> Basically any wiki should suffice for those requirements. However, integrating those requirements with other workflows tends to be trickier. Atlassian's tools (Jira, Confluence, etc.) tend to win by default, but if you're willing to do some duct-tape work other solutions are fine too.

<comment><AUTHOR> Harder to keep in sync though, if it's not somehow derived from or embedded in the source code for the scripts.</comment></comment></comment></comment>


Open source project: Func, the Fedora Unified Network Controller - <AUTHOR> http://www.redhatmagazine.com/2008/02/21/open-source-project-func-the-fedora-unified-network-controller/

<comment><USER2> SSH has a few flaws, so they created what looks like an even more complex SSL- based command transport? I don't get it.</comment>