Aussies' fix for 'stagnated' email  - <AUTHOR> http://www.smh.com.au/technology/technology-news/aussies-fix-for-stagnated-email-20120221-1tkqd.html <comment><USER2> > "The market that we're going for initially is sort of independent > professionals and small businesses that tend to have personal accounts [and] > maybe several work accounts,"

I'm glad they're only aiming at a small group of people who actually have problems with email. The weekly "re-invent email" posts are getting quite tiresome, the majority of people have absolutely no problem with email, email is an incredibly simple concept and it works for almost everyone.

<comment><USER3> I dunno, for most people in corp environment it is a total nightmare mish-mash of to-do list, calendar, notes, and assorted hate mail from their bosses.

In short, email is fucking awful and the bane of my existence. At one point I was getting north of 200 emails a day from people demanding meetings, todos, updates, and pieces of information. Please someone... reinvent it!

<comment><USER4> Nobody gets 200 emails per day all directly asking for something. If you do, as already said, that's a process and staffing issue, not email's fault.

The good thing about the old subject line of an email is that you usually can tell whether it's something you need to look at now or save for later, move to another folder, or delete. You can also quickly see whether you are the main target or just CC'd.

Speed reading can also assist in processing email. Sometimes you just know whether you need to read something thoroughly, or can glance over.

<comment><USER3> AS an FYI -- I was working on the largest merger between two US banks. 150-200 emails a day was a standard for many people making it almost impossible to digest all the information.

Speed reading, as you suggest, would not be a good solution to finding mission-critical information. As far as I know, no collaboration tool exists that could handle the complexity that we were dealing with. We tried quite a few, and pushed SharePoint to its limit.

</comment></comment></comment></comment><comment><USER5> I already built this back in 2009

[http://techcrunch.com/2009/12/01/inbox2-one-inbox-and- commun...](http://techcrunch.com/2009/12/01/inbox2-one-inbox-and- communications-stream-to-rule-them-all/)

And here is the desktop client which is now open-source: <http://www.techshout.com/img/inbox2.jpg>

People do not need this and will not leave their existing email clients because they simply do not see email as being 'stagnated'. It works and gets the job done.

There are lots of problems to fix around email, but a new inbox interface is not one of them.

My advice to you would be to go build on top of for example gmail. There are massive number of things that suck horribly. Yes, search is one of them.

Inbox navigation is another one, but keep in mind that there is a reason why the current line based inbox interfaces work.

The third one is attachments, but that is one I am already tackling with my new startup www.fileboard.com

<comment><USER6> Did you even read the article, or did you just come here to toot your own horn? All of your "advice" is exactly addressed by Fluent, e.g. built on top of Gmail, better search, better inbox navigation, and better attachment handling.

I have no idea how successful Fluent will be at all those things, but it's just peculiar when a site says "we're tackling problems x, y, and z" and you come along and say, "your ideas suck, try addressing problems x, y, and z instead."

<comment><USER5> Lol @ thinking that IMAP and gmail are the same thing

Having spent the last 3 years of my life tackling this problem I would say I am pretty qualified to say this solution sucks.

And they are totally not solving the problems I mentioned, they are building a new mail client. Which tends to be a completely different thing.

Anyways just my 0.02$

</comment></comment></comment><comment><USER7> Can we put the actual url in [1]

Looks very inspired by by Sparrow.app [2](OS X mail application). Though they have improved on the UI in some aspects.

Great that people are still trying to make email better.

[1] <http://fluent.io>

[2] <http://sparrowmailapp.com/>

<comment><USER8> I actually purchased Sparrow, but I don't use it.

It was slow and had some UX quirks/bugs.

For a time I fired it up every once in a while as an email-backup solution, but I got lazy so I don't even do that now.

<comment><USER8> Eg. I usually have Gmail open in other browsers in Windows even if I run Sparrow on the Mac, and it takes several minutes for Sparrow to notice that a message has already been read, which is super annoying.

</comment></comment></comment><comment><USER9> Congrats to Fluent! Great design and a slick UI.

The stream view is an interesting concept, but we've found that many people don't have a nice inbox of messages as shown in the preview. In fact, it's quite the opposite: messages from friends, family, and coworkers are often overwhelmed by notifications, newsletters, and mailing lists. However, your Amazon shipping and Twitter notifications aren't spam, you just don't want to see them in the same context.

I'm working on Glider (<http://glider.io>), a fix for the mess in your inbox. You already know which kinds of emails are important to you, so instead of obscuring that information, we think the best solution is to sort and display emails by sender and context.

We did a soft launch on HN a few weeks ago (<http://news.ycombinator.com/item?id=3519917>), and would love to know what you guys think. Good luck as well to the Fluent team!

<comment><USER10> A word of advise: Asking me to give you access to my email account is a very big leap of trust. I can't see what your product does without taking that leap - so I don't.

<comment><USER11> I quite agree that it takes trust. We do have a demo up for a safe hands-on with the product (demo.fluent.io). We certainly take your privacy seriously. Here's a bit more on that: <http://fluent.io/privacy.html>

<comment><USER12> "We are well versed in industry-leading privacy practices." \- What is your country of jurisdiction (i.e. what government can access my email)? Google is based in the US and you are in Australia.

</comment></comment></comment></comment><comment><USER13> "we sort of present you with the information that you need _to immediately action on it_."

Really? _Really?_

I expect better from my fellow Australians, even if they _are_ Sydney-siders.

<comment><USER14> Fwiw, that's the SMH reporter misquoting us from an in-person interview.

However, we'll try to live up to Australian standards better in the future =)

<comment><USER13> Then I retract my slur on Sydney and all her works.

Except for the journalists.

(What did you actually say, in your recollection?)

<comment><USER15> FWIW, it was the original quote <http://dl.dropbox.com/u/26309/action.m4a>

Regards, Ben Grubb (the journalist)

<comment><USER16> Yep. Audio matches written quote.

Kudos Ben on your quick rebuttal of the misquote claim. And for an article full of links to all the companies and technologies you're writing about.

</comment></comment></comment></comment></comment><comment><USER17> Is e-mail that freaking broken for everyone?

I must seriously not have the same problems. With gmail spam filters and priority inbox the last thing I need is to visualize my e-mails in a twitter like stream.

I can't be the only one one that jumps for joy when someone actually e-mails me something akin to a personal letter.

<comment><USER4> Nope. Email not broken for me.

I like it how it is because filters and sensible organising of inboxes is not hard.

Not interested in email streams at all. I'd prefer to keep streams for the kind of information that doesn't require action or response frequently per item. Emails often require action or attention, and it's far better they exist as subject line items in a date-ordered list for easy retrieval, sorting and archiving all at once.

<comment><USER18> But I'd like to take my stream like conversations back to a simple, open, distributed (in the sense of server control) protocol like SMTP and away from Facebook Messenger (for example).

It's just a bit of message passing, why should email NOT also handle multiple participants and almost-real-time conversations well?

Twitter is a different beast, it's a public stream, but what does FB messenger offer over email, other than an improved user experience? (for some value of improved...)

</comment></comment></comment><comment><USER19> _standard gripe about technologies being declared "dead" merely because they are no longer growing, rather than because they are suffering from a vanishingly tiny user-base_

<comment><USER20> 'Dead' doesn't exist in the article, it's a (pointless) bit of editorializing by the submitter.

The article revolves around email having _stagnated_ , which pretty nicely fits the "no longer growing" part.

</comment></comment><comment><USER21> The attachment feature alone is a something I would pay for; I deeply miss Xoopit an we'll-organize-your-attachments plugin which gave my inbox a life. I also like how you can view message and reply without having to go to a new page. The only problem I see is it's taking me away from my comfort zone (gmail).

</comment><comment><USER22> We've been thinking hard about innovating email. Interestingly, I don't think reading the emails is where the real problems are, its in composing the emails.

</comment><comment><USER23> What I'd really like to see is a P2P, encrypted, bittorrent-based mail system, basically something that works similar to bitcoin, but used for sending encrypted mail instead.

No central servers, just a single blockchain recording all encrypted messages on the network and shared over a bittorrent network, and an easy-to-use client that doesn't make normal people think too hard.

Encrypt a message with your recipient's public key, submit it to the network, it's accepted into the blockchain, and they decrypt it on the other end with their private key when the msg propagates to their client. Private (at least until computing power catches up with the encryption algorithm), decentralized email without ads, popups, etc.

Give it a nice Apple-ish/fluent.io-ish/sparrow-ish interface, transparent encrypting and decrypting, and some way of optionally associating email addresses with public keys so normal users don't have deal with intimidating hashes (optional only though, still want the ability to send directly to more anonymous public keys).

While you'd still need some method of preventing block chain forking, you wouldn't have to worry as much about double spending and transaction verification since you don't care whether someone sends the same message multiple times to different recipients (as you do with bitcoin).

One of the biggest problems would be dealing with exponentially increasing blockchain size. Bitcoin already has this problem and its transactions consist only of relatively terse amounts of data. With full emails (and attachments?) you'd have to implement a method of cropping and perhaps archiving the blockchain, or otherwise solving that problem, or it will quickly become unweildy and destroy the user experience (esp for people with slow connections).

Perhaps clients store the blockchain a certain number of blocks back, and then beyond that they only store their own sent and received messages? Not sure...

The genius of bitcoin is that it is a solution to a difficult algorithmic problem in distributed systems [1] which can be repurposed for other implementations. It is already being repurposed for a distributed DNS [2] and distributed voting systems for elections [3], why not a distributed encrypted email system as well?

Just throwing this out there without really thinking it through thoroughly atm... Thoughts? Feasible? Probably the biggest problem is knowing that one day all your emails would essentially become public domain when hardware catches up...

1\. [http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origi...](http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origin)

2\. <http://dot-bit.org/>

3\. ddg-fu failing me atm, will add this later.

<comment><USER24> You would lose interop with existing email infrastructure. the problem is that hosted email brings everything back to being too centralized (for eg. most of the email I send doesn't leave the google servers). Take a product that implements its own smtp server, nice PGP integration and a nice interface over it like the one in OP. users may be more likely to want something like that (I know I do - I can't wait to switch away from Gmail) rather than an entirely re-invented messaging system.

<comment><USER23> >You would lose interop with existing email infrastructure.

Yeah, when I mentioned the ability to associate email addresses with public keys, I wasn't very clear. I did't mean regular email addresses, but was actually thinking of bitmail-only email addresses. Perhaps ones based on Namecoin .bit domains.

But I wasn't suggesting interop with existing email infrastructure, this would be completely separate. In fact, the idea would be to disrupt and supplant the regular email we all know and love, at least for some use cases where privacy is paramount.

Everyone would have their bitmail client which they could use to send encrypted email, as well as their regular Gmail addresses and whatnot. Most people have multiple emails anyway, this would just be one more.

One nice thing about bitcoin, which would carry over to bitmail, is that despite the core technology (the official client) being completely outside and orthogonal to the current financial system, it's very easy to use for its fundamental purpose. Sending and receiving bitcoins is just simple. I envision the core bitmail client would work similarly and be similarly simple. No need for interop as long as there are specific optimal use cases for it (say, Arabs and others coordinating against oppressive regimes, stuff like that).

</comment></comment></comment><comment><USER25> My new take on email: leave it alone and go fix something that's actually broken.

I'll take an open source clone of Gmail, thank you very much, especially as they continue messing with the interface for the sake of it and with the privacy policy for kicks.

While we're at it, I'll also take an implementation of conversations in ThunderBird, to make it more like Sparrow, which is quite nice on the desktop.

</comment><comment> johnx123-up Ah, title got changed from "Ex-Google Wave engineers new take on Email (email is not dead yet)" to "Aussies' fix for 'stagnated' email"

</comment><comment><USER26> The best thing Gmail has going for it are the shortcuts. They're the best feature for ripping through an email backlog. I hope anybody working on an email client includes shortcuts for everything. Once you get used to them, it's painful touching your mouse.

<comment><USER27> I take it you never used mutt?

That is how you rip through thousands of emails in insanely short times. Much MUCH faster then gmail.

<comment><USER28> Marginally faster. There's only so fast you can make email because you still need to comprehend it. And BTW, comprehension + shortcuts is the killer feature of Gmail. Having a nice GUI facilitates comprehension which allows you to act faster. There are many reasons why an individual might prefer mutt, but "Much MUCH faster than gmail" is overstating the case quite a bit.

</comment></comment></comment><comment><USER29> Is it my imagination or is this a lot like the vision for Mozilla Raindrop. I was quite disappointed that they started talking about it and then stopped work on it almost at the same time. The ability to pump all of your messaging into a single client and have it prioritise what was important seemed a no- brainer to me.

I'd love to have rss/tweets/fb/g+ updates alongside emails for people I care about rather than maintaining increasingly complex methods of keeping up to date with each in different apps

</comment><comment><USER30> To me, this looks like webmail to read webmail. Pretty though. I doubt I'll use it, as it's another entity to trust with my privacy. If it was a replacement for Gmail entirely I'd consider it.

I'm still searching for a decent desktop email client, something that looks like this and works on both Windows 7 and Mac OSX. It's a shame that this is a web app, it doesn't solve any problem that I have.

</comment><comment><USER31> Slick interface and the instant search makes me want to use the product.

But I like and trust email because it is stagnate. How is this different than Buzz (dead) or my other 'streams' like G+/Facebook/Twitter? I don't want my email to be a stream, because if I miss one, that could be devastating. I don't want email to evolve, because it is the only thing I can trust that won't become realtime.

</comment><comment><USER32> If the mail is still hosted at google, hosted in the USA with all the government snooping and extreme paranoia and everyone is out to get us attitude, with the NSA, CIA and whatever other corporate/government crime syndicate reading it, then it fails to fix the biggest flaw in gmail. And that is the lack of privacy.

</comment><comment><USER33> Looking at these comments it seems I am the only one blown away by this. It's amazing! Email for the social network generation. We've become accustomed to feeds, and for a good reason: it's efficient.

The feature where a panel slides in from the right allowing you to view more is such a great time-saving feature.

<comment><USER34> You are not the only one blown away by this. This story is on the first spot of HN.

Great UI, I love the attention they paid to some details.

</comment></comment><comment><USER35> Don't use the Konami code in the app if you want to get anything done this evening! Incredibly slick UI.

</comment><comment><USER36> What an over-engineered, proprietary interface-ey mess. But at least people are still plugging away.

<comment><USER33> Anyone ever use Opera mail? _Perfect_ interface and features. I guess it's just overlooked because, you know, it's Opera :(

<comment><USER37> If I remember correctly, I (reluctantly) had to switch to t-bird back in the day because it didn't do STARTTLS+IMAP. It was perfect, otherwise. I'm yet to see a faster way to search through mail.

</comment></comment></comment><comment><USER38> "Email has "stagnated" and three Australians who quit Google say they have built a product that will change the way we interact with email and allow us to get through our bulging inboxes "20 per cent faster"."

Google Wave anyone?

</comment><comment><USER39> It is a nice idea but to me it seems more suitable as an app for tablet/smartphone then a replacement for GMail. I wonder if they're just aiming to get bought out by Google.

</comment><comment><USER40> E-mail is stagnated not because of technologic restrictions. Beautiful UI though!

This is a people problem, not a technology one. Sorry, just don't see it 'fixing' a problem.

</comment><comment><USER41> It reminds me of a similar service, ZeroMail [1] (also from Australia). The UI for Fluent is intuitive, and a nice break from Gmail (esp. with Gmail's new look).

Given the influx of e-mails I get a day from listservs, friends, business contacts, customers and random services (Groupon et al.), I see this already busy interface getting cluttered very fast. That said, I only tried the demo and would be interested to see what it looks like on my actual inbox with real people.

[1] <http://zeromail.com/>

<comment><USER42> Funny, the bit in the article where they mentioned zeromail and talked to the zeromail founders also reminded me of zeromail.

</comment></comment><comment><USER43> Great to see that someone is still innovating on EMail. GMail was last major +ve change that happened to EMail and its been too long.

</comment><comment><USER44> Very smooth interface, from what I can see. FYI on demo.fluent.io I'm getting HTTP 400 error trying to connect to the websocket.

</comment><comment><USER45> Wow, the interface is really nice. But I don't think it would work for my daily mail use. I'm too familiar with my mutt setup.

</comment><comment><USER33> Mozilla Raindrop aimed to reinvent email too. I was so excited for it to launch, but they discontinued it.

</comment><comment><USER46> The only thing I feel is broken about [web-based] email right now is that it can so easily be snooped on.

<comment><USER47> By the email provider or by third parties? https fixes the first part. You can't do much about the second in web-based email.

</comment></comment><comment><USER48> Soooo, the solution to stagnating email... is to make it look like Facebook.

Not what I'd call "fair dinkum", but...

</comment><comment><USER49> Great interface! A big improvement over Gmail and anything else out there that I'm aware of.

</comment><comment><AUTHOR> aside: how/why did the title change from the original that I posted? (I gave a title, but it seems to have forgotten that and reverted to the article?)

<comment><USER50> Editors can (and do) change the title to avoid editorializing: <http://ycombinator.com/newsfaq.html>.

<comment><AUTHOR> Thanks - that explains it. Although I object to just using the headline of the page (as I think the ex-wave is more relevant than the 'aussies' bit - but I guess there is novelty for the rest of the world).

</comment></comment></comment><comment><USER51> At least they left the vowels in the name.

<comment><USER11> Over beers, "flnt" seemed good... but sanity prevailed.

</comment></comment><comment><USER52> yeah pretty much bored after seeing gmail interface. some innovation required. its good.

</comment><comment> johnx123-up Technology stack, please? Scala?

<comment><USER53> I'm guessing Java.

<comment><USER54> Java, Guice, jQuery, and JAX-RS, at least. Dhanji has been deeply involved on those technologies for a long time.

</comment></comment></comment><comment><USER55> With Gmail's "new" interface, I am finding it more and more cumbersome to navigate around. I practically run my business through Gmail - so it's great to see another stab at this interface to make things more meaningful and practical. Goodluck with Fluent.</comment>


3 things I wish somebody would build - <AUTHOR> http://arnorhs.com/2010/05/14/3-things-i-wish-somebody-would-create/

<comment><USER2> For the first point, there resources out there, but I personally don't think there are many that are that easy to use and work with other social sites. This is actually an interest of mine and is the first side project that I have started working on. I hope to have something out there in the not-to-distant future and I hope to get feedback from people like you who are also looking for such an app.

<comment><AUTHOR> Great. I would use it. Build it and I will come :)

Do you need help?

<comment><USER2> Possibly. I'm a Python guy doing this is Pylons so if you have experience with that, I would take some help. Also, if you have any experience with interfaces, that's my weakness.

</comment></comment></comment><comment><USER3> Anyone who's interested in working on #1, has some time, and can work with Rails3/Ruby, send me a note. Contact info in my profile.</comment>


HTTP2 [pdf] - <AUTHOR> http://daniel.haxx.se/http2/http2-v1.7.pdf

<comment><USER2> From the article: _"The protocol is only useful for browsers and big services" This is sort of true. One of the primary drivers behind the http2 development is the fixing of HTTP pipelining. If your use case originally didn 't have any need for pipelining then chances are http2 won't do a lot of good for you._

This may be a big issue, and may impact net neutrality. You get better performance if your stuff is inside a pipe from a Big Service. This makes Google look good. It also increases the relative benefit of running everything through a content delivery service.

This, in turn, creates a use case for CDNs which suck up all the components needed to display a page by whatever means necessary and deliver them to the end user over one HTTP2 connection. It then makes sense for the CDN, not the end user page, to be the advertising insertion point. If ads are loaded from a third-party ad server, they might not show up before the user is done viewing the page. This sometimes happens now. With server-side control of ordering within a single HTTP2 pipe, advertisers tied in with the CDN can be sure that ads will appear when the advertiser wants them to appear.

So there's a net neutrality issue. When multiple streams are multiplexed over a single pipe, the server gets to determine who goes first. Control over that order is valuable. That control may end up in the hands of the CDN, not the site operator.

<comment><USER3> Unless the client is able to change/enforce the priority of the streams or block a stream altogether with a reset. Then it should still be possible to strip out the ads through some Adblock-like mechanism.

I see how this could potentially shift the ad-bearing responsibility to CDNs, but I'm not seeing how it's any more of a net neutrality issue than what we've got now. Could you propose a hypothetical scenario?

<comment><USER2> Whoever owns the big single pipe gets to determine what goes into it first. A CDN can insure that preferred ads go in early, so they always appear before the content is fully loaded. Ads that don't go through the CDN may show up, eventually.

There's also an encryption issue. The big pipe is one SSL/TLS session under a single key. Whoever owns the big pipe gets to see everything. Things like embedded Facebook content, normally encrypted with Facebook's keys, can't go through the big pipe unless they accept the CDN looking at their traffic.

It's not clear how all this plays out, but it definitely implies more centralization.

</comment></comment></comment><comment><USER4> Slightly off-topic, but I know Google is working on efforts to completely replace TCP with something specifically designed for web applications. Does anyone know if they also plan on optimizing HTTP 2.0 to fit the new transport protocol they're trying to design, or vice versa?

It's currently implemented as a layer over UDP: [http://en.wikipedia.org/wiki/QUIC](http://en.wikipedia.org/wiki/QUIC)

<comment><USER5> See this presentation: [https://www.youtube.com/watch?v=hQZ-0mXFmk8](https://www.youtube.com/watch?v=hQZ-0mXFmk8) Slides, with quote about why quic is being worked on: [https://docs.google.com/presentation/u/0/d/13LSNCCvBijabnn1S...](https://docs.google.com/presentation/u/0/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present?slide=id.g2b4eb9937_815)

</comment></comment><comment><USER6> Good document and read. Got a question about using separate CDNs for image serving. The initial HTTP connection to the host takes a while, especially with a long latency for some countries if there's no close server to the user so by splitting it up into separate image hosting servers, that may actually cause longer... love to hear thoughts on this as that's always been my thoughts?

</comment><comment><USER7> Thanks for a great document.

I think in the future all protocol diagrams should use colored lego blocks. That was fantastic.

</comment><comment><USER8> I wonder how many experimental deployments we're missing out on due to the pay-to-play mandatory SSL CA regime.

<comment><USER9> [https://letsencrypt.org/](https://letsencrypt.org/) is a new promising solution to the 'pay-to-play' system

<comment><USER10> But what if the organization behind it goes bankrupt or some browser removes the CA because one of the sites has malware?

I think this whole CA system is needlessly complex. Your registrar should be providing you with a free certificate for your domain and that should be the end of the hassle.

<comment><USER11> I'm working on Let's Encrypt, and I'd be happy to see domain registrars reduce the need for Let's Encrypt by issuing cryptographic credentials to domain registrants.

Every CA that issues DV certs for public DNS names takes registrars' databases as the ultimate ground truth about domain ownership -- at least for the domains that the CA is willing to issue for -- so the DV-cert-issuing world is reliant on them to be correct, secure, up-to-date, and so on. That's true whether the CA is using whois data plus DNS data, or just DNS data, to verify domain control.

(In saying that, I thought about the idea that Let's Encrypt may use safeguards to limit issuance based on historical observations of domain control and prior issuance history by other CAs. For example, our draft ACME spec has a mechanism where we could ask a requestor to prove control of an existing subject key from a cert that we know was issued for the same subject domain by another CA. So if we've already seen a valid cert in the wild, or in Certificate Transparency, for example.com, we could say that you have to show that you have control of the key in that cert before you can get a new cert from Let's Encrypt for example.com. But all of those things ultimately go back to what registrars said in the past, even if some of them are independent of what registrars say today.)</comment></comment></comment></comment>


The speed of BGP network propagation - <AUTHOR> https://blog.benjojo.co.uk/post/speed-of-bgp-network-propagation <comment><USER2> This article doesn't seem to account for the idea that removed and the announced have a different latency compared to a new announcement. For example if we withdraw a prefix and then announce it 10 minutes later propagation is WAY faster than if we announce a new prefix or withdraw for a few days and then announce again.

Edit, but cool article.

</comment><comment><USER3> Why is it beneficial to quickly announce a 'test prefix'? Couldn't you position fast/slow propogation instead as trusting/untrusting providers?

<comment><USER4> It is beneficial for real changes to be propagated quickly, but it's irresponsible to use real traffic, so they used a test prefix -- a range of addresses without users.

Trusting / untrusting isn't likely to be the difference between propagating the route in 10 seconds vs 60 seconds. That's not enough time to do anything meaningful trust wise --- either the provider checks the routing dbs and routing PKI or they don't, but a survey of providers that accept or not poor routes is another story.</comment></comment>


Linux 5.8-rc1 - john-shaffer https://email@example.com/ <comment><AUTHOR> This is about 1-2 months old (dated Jun 14th)? 5.8 is out already. [https://kernelnewbies.org/LinuxChanges](https://kernelnewbies.org/LinuxChanges)

</comment><comment><USER2>
      we have modified about 20% of all the files
      in the kernel source repository

also

      despite not really having any single thing that stands out

So, is this a ton of bugfixes? A "Snow Linux" as-it-were? If so that will be awesome.

<comment><USER3> I really like that no single thing stands out. It shows that a lot of people were working on a lot of different things, which is a sign of a healthy project... not that I would otherwise think of Linux as an unhealthy project.

</comment></comment><comment><USER4> As someone who has nowhere in the vicinity of 1% of the responsibility to insuring that a code base is clean and performs its intended function- who is reviewing all these pull requests? It cant be Linus, right? How are the folks with PR privileges vetted?

Fully admitting to ignorance here, but to me it seems that this problem is way to big to prevent bad actors from participating. I would love to hear thoughts to the contrary.

<comment><USER5> There's sorta like a "tree" of maintainers for each part of Linux -- with Linus at the top of the tree. When you make a patch for the kernel, there's a script you can run on the patch:

scripts/get_maintainer.pl

It'll output the appropriate subtree of maintainers who "own" the code in the kernel that the patch applies to. Then, you can email your patch to them. The maintainer will send the patch up the "tree" until (hopefully) it ends up in Linus' repo.

<comment><USER6> What happens after Linus dies? Could there be an schism between opposing successors?

<comment><USER7> Two years ago Linus took a break and Greg Kroah-Hartman was leading the project during that. Greg normally maintains the LTS branch of the kernel (and possibly many other things also).

</comment></comment></comment></comment><comment><USER8> I've lost track of linux versioning, but do folks here know how the next LTS kernel line is determined?

Looking at kernel.org, the last LTS was the 5.4.z series, so I'm curious when the next LTS branch will be cut to use these features in most distros.

<comment><USER9> Looking at past releases[0] it appears every 5th release so since 5.4 was the last stable release, the next release at 5.9 should be LTS.

[0]([https://www.kernel.org/category/releases.html](https://www.kernel.org/category/releases.html))

<comment><USER10> Also worth noting for people that use distribution kernels, a distributions LTS kernel may or may not match the official one. Just something to be aware of.

</comment></comment></comment><comment><USER11> If you're interested in async I/O, keep an eye on the io_uring changes.

<comment><USER12> Easily 5-10 years before most of us can expect to use that in a work context.

<comment><USER11> I assume you mean because of the time it'll take to trickle down to production kernels? Does that take 5-10 years?

<comment><USER13> It depends on your domain.

RHEL7 has another year[0] of support left (until August 30, 2021), and is based on kernel 3.10 [1], which was released in 2013 [2]

RHEL 8 is expected to see support through 2029, and is based on kernel 4.18, which was released in 2018.

Redhat does backport changes, but tends to avoid backporting feature changes.

If you want to be able to use "recent" features of software, you are probably not running running Redhat But, many companies prefer the stability of systems that have been battle tested, and so are perpetually years behind the bleeding edge in terms of features.

[0] [https://access.redhat.com/support/policy/updates/errata/](https://access.redhat.com/support/policy/updates/errata/)

[1] [https://www.redhat.com/en/blog/what-latest-kernel-release- my...](https://www.redhat.com/en/blog/what-latest-kernel-release-my-version- red-hat-enterprise-linux)

[2] [https://kernelnewbies.org/LinuxVersions](https://kernelnewbies.org/LinuxVersions)

<comment><USER14> I don't mean to start an off-topic debate on this, but I just have to say that personally, I run into issues caused by using old software on our EL7 boxes _all the time_. For example, cgroup memory limits are broken on Red Hat 7 kernels as far as I can tell (most versions have a memory leak, but iirc the most recent has a panic instead). They're missing all sorts of features that are useful for usability or reliability.

I'm just personally not convinced we really win much with the trade off as a society :p

<comment><USER12> Memory control group code is replete with bugs throughout 4.x kernels, way beyond RHEL 7. This is one of the big problems with getting locked into "LTS" kernels. It takes a long time to discover all the nameplate features that don't actually work.

</comment></comment></comment></comment></comment></comment><comment><USER15> Could the lockdowns and the extra time at home be partly responsible for this achievement?

<comment><USER16> I wouldn't discount it, but I think many software devs continued working from home instead of getting laid off. maybe all those kernel contributors found themselves with an extra 2/3 hours in the day without the daily commute? Not to mention not being able to carry out daily social lives + leisure activities

<comment><USER17> There are a lot of us developers out there who have had _less_ free time during the lockdown. Whether it's because of having young kids or doing charitable work in the local community for those less fortunate.

<comment><USER18> Or you're a dev working in healthcare.

<comment><USER19> HAH wow this hit way too hard. I don't have a shred of free time. I should be working on the backlog right now as I post.

</comment></comment></comment></comment></comment><comment><USER20> I am wondering if kernel developers had more time to spend on the project because of all the recent virus lock-downs. That could account for the higher- than-usual number of files changed, and overall bulk.

<comment><USER21> Are you assuming these are hobbyists who now have more free time?

The majority of kernel hackers are paid to work on it.

<comment><USER22> When they worked in the office, and now work from home, they would have much more time (no commute!) even if they get paid

</comment></comment></comment><comment><USER23> 800,000 new lines of code. No matter how you count them that's a lot of typing.

My main project has 95 libraries and is nowhere near that massive.

<comment><USER24> That's a lot of new surface area for attacks. A lot of new code quickly worries me.

<comment> tedk-42 What if it's 790000 lines of new/updated tests and 10000 of new functionality?

<comment><USER25> The day a ratio anywhere close to that happens in the Linux kernel, be alert for all the flying pigs outside.

<comment> tedk-42 Hahaah TIL - Not a contributor, nor do i have the C skills to know what's going on in the code base to understand it

</comment></comment></comment></comment></comment><comment><USER26> 5.8-rc1 was 2 months ago; 5.8 went through rc7 and was released as final last week.

</comment><comment><USER27> Seems this is biggest in terms of # commits / lines of code / etc.

But does anyone have opinions on what the most "impactful" linux releases ever was?

</comment><comment><USER28>
      Andrew Morton (7):
        updates
        more updates
        yet more updates
        still more updates
        even more updates
        some more updates
        updates

Real illuminating merge log there bud :-)

<comment><USER29> I'm surprised this is allowed in the linux kernel. I am not familiar, but assuming these are commit messages, that's pretty damn pathetic.

<comment><USER30> These are only merges - they don't matter. The actual functional commits are excellent beyond anything you would ever find in your company VCS.

<comment><USER31> Git and Subversion even allowing single line "-m" commit messages was a mistake. You would see a lot better messages if they forced you to use the editor. I bet a lot of programmers don't even know you could do multi line messages and assume there is some short-ish character limit. I know I did for a long time

<comment><USER32> I feel a huge pain of resignation when I am forced to use multiple lines to describe a single commit. There is almost no audience for any line of the commit message other than the first line. As far as line length goes, any practical means of displaying the messages, like gitk or git --oneline, is unfriendly to lengthy lines. Gerrit will display all the lines of the tip commit's commit message, so one can amend that commit to create a summary of the others, but then of course the other commits are not as visible.

The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic:

[https://stackoverflow.com/questions/2290016/git-commit- messa...](https://stackoverflow.com/questions/2290016/git-commit- messages-50-72-formatting)

<comment><USER33> As someone who has had to dig deep with git blame, I tremendously value a good long multiline commit message. At the very least it can save the trouble of having to dig up some obscure mailing list discussion or bug report to figure out why a change was made, assuming that exists at all. If it doesn't, all you have is the git commits.

<comment><USER32> Imagine you followed 50/72 AND the "title" was required to reference "[JIRA-1234]" or "Bugzilla-1234".

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> The number of lines in the amdgpu driver sadly does not mean that it would be usable in any way. The amount of red in dmesg is just sad when you're stuck with USB-C DisplayPort graphics.

</comment><comment><USER35> I am looking at the changelog, even if we ignore drivers being used not in Server Environment, and improvement from Security, Networking, I am wondering how are BSDs going to compete?

<comment><USER36> Increasingly, they don't.

I don't think a Linux monoculture is good, but from the perspective of an individual or organisation choosing which OS to use, there's less and less reason to choose a BSD.

<comment><USER37> Yeah, completely. Competition and alternative approaches are what pushes us forward. The fanboi culture of "*BSD is dying", "use Chrome" etc. which tech communities seem to encourage makes it worse.

Keep doing it the hard way, trying something different and running your code on a different browser and OS. In the long run, Windows and the BSDs have done a lot to make Linux good, in the same way that Android and iOS push each other forward. I'm just hoping folks keep adopting Firefox.

</comment></comment></comment><comment><USER38> I remember reading that he got a new threadripper-based workstation. It seems like he is putting it to good use.

</comment><comment><USER39> Subject: Linux 5.8-rc1 Date: Sun, 14 Jun 2020

</comment><comment><USER40> I'm a little wary of the types of metrics: LOC, updates, file changes, merges.

Those are tertiary issues at most.

Features, quality, issues resolved etc.. is mostly what matters.

</comment><comment><USER41> Notably missing: "I want to thank everyone involved for all the work they put into Linux, this is really a community driven project."

<comment><USER42> Except Linux by and large is written by paid programmers</comment></comment>


RBS to axe 3,500 IT and back office jobs - <AUTHOR> http://www.computerworlduk.com/news/careers/3237871/rbs-to-axe-3500-it-and-back-office-jobs/?cmpid=sbycombinatoranguyen <comment><USER2> Hmm, just when I'll be entering the job market. I wish I knew what that number meant in relative terms, some way of visualizing how much more difficult my job prospects just became.

<comment><USER3> BBC Scotland is describing it as "RBS move to boost Scottish jobs"!

<http://www.bbc.co.uk/news/uk-scotland-11165360>

<comment><USER4> Unusually biased for the BBC. It quite simply makes good business sense. Living costs in most of Scotland are significantly lower than most parts of England, salaries are similarly lower. Edinburgh in particular has always had a strong standing in the finance industry so has a large pool of skilled workers.</comment></comment></comment>


The laws of Australia will trump the laws of mathematics: Turnbull - <AUTHOR> http://www.zdnet.com/article/the-laws-of-australia-will-trump-the-laws-of-mathematics-turnbull/ <comment><USER2> "The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia."

:facepalm:

<comment><USER3> This must be satire

<comment><USER4> When it comes to politicians, sadly, statements such as this are often all too true.

Many (if not most) politicians operate in a separate frame of cognitive dissonance where they firmly believe that because they put "it" into a law, that everyone will now immediately follow the law to the letter and obey whatever commandment was "it".

Somehow, the counter evidence of the mere existence of "criminals" (whom, by definition, are those who _do not obey_ the law) fails to dissuade them from this alternative viewpoint that "because they (politicians) say so, it will be made so".

The result of this hubris on their part then results in gaffes such as this one where a politician believes that even such things as physics or mathematics will also "obey his written law, because he said so".

</comment></comment></comment><comment><USER5> I'm curious what is contained in this bill. Is there an online link somewhere?

It would be cool to see Schneier break it down.

</comment><comment><USER6> Help. My head hurts.</comment>


Product Review: Kinesis Advantage ergonomic keyboard - <AUTHOR> http://jseliger.com/2009/07/20/kinesis-advantage/ <comment><USER2> The review is helpful in mentioning that the thumbs have more keys to control with the Kinesis keyboard than with typical keyboards. That raises a question: what's a good input device for someone with basal joint arthritis in both thumbs? Mice are hard on such people, and even using the spacebar with the right thumb is dodgy on a conventional keyboard for such people? What's good for users who don't want sore thumbs?</comment>


Man Interrogated By FBI For Wearing Google Glass At The Movies [confirmed] - <AUTHOR> http://www.businessinsider.com/man-interrogated-by-fbi-for-wearing-prescription-google-glass-at-the-movies-2014-1?op=1 <comment><USER2> The original article that broke the story: [http://the- gadgeteer.com/2014/01/20/amc-movie-theater-calls-...](http://the- gadgeteer.com/2014/01/20/amc-movie-theater-calls-fbi-to-arrest-a-google-glass- user/)

</comment><comment><USER3> > The officer asking the questions identified himself as "Bob Hope" of the > "movie association" — presumably the MPAA

FBI, MPAA, ICE?

Before you voluntarily want to have a "terrifying" chat with someone for an hour, you just might want to figure out who you're dealing with.

</comment><comment><USER4> It's not FBI, it's ICE (Immigrations and Customs Enforcement) which is now part of the DHS.</comment>


Yes, Evernote is down just when you need it - <AUTHOR> https://twitter.com/search?src=typd&q=evernote%20down <comment><USER2> You should have anticipated this. It's the nature of "the cloud" that you have no control over how the service is functioning.

That's exactly why I host webapps myself and generally prefer standalone applications over web based ones.</comment>


Chevron buying Anadarko for $33B as crude prices rise - <AUTHOR> https://abcnews.go.com/Business/wireStory/chevron-buying-anadarko-33b-crude-prices-rise-62351800 <comment><AUTHOR> Fun fact: Anadarko is the company formerly known as Kerr Mc-Gee and made famous by the movie Silkwood.</comment>


Ask HN: Experience with immigration lawyers - <AUTHOR>

Greetings. Since there are many non-Americans living and working in the US on this site, I was wondering if some of you would be willing to share your experience with immigration lawyers. I was considering getting one approximately a year ago to help me make a plan how to obtain a green card and eventually a citizenship, but then, after doing some research on the Internet about the US immigration laws, it did not seems to me as if a lawyer could really bring anything new to the table as the laws are fairly straightforward. Nevertheless, today I had a discussion with someone who, despite not having personal experience with immigration lawyers, claimed that a lawyer's expertise can help a lot in the whole process. This made me reconsider my opinion so I would be interested hearing about your experience.
I'm not sure if this is relevant but I'm a rising college junior originally from the Czech Republic attending a college in Massachusetts who wishes to stay in the US after graduation. I have seen the similar old threads about immigration issues on HN but this thread is more about experience with immigration lawyers rather than the process itself.
Recommendations for immigration lawyers in Massachusetts are also very welcome.
Thanks to all in advance. <comment><USER2> I'm not a lawyer, but I have a little experience.

After completing college you should be eligible for an OPT (optional practical training) visa, which will let you work in the US for a year. You can use that time to catch on with a company who will sponsor you for an H1B.

Speaking more personally, I've dealt with a family-based immigration case but not employment based. I filed my family-based petition _mostly_ on my own, and took it upon myself to learn all the applicable laws and forms and stuff. I say "mostly" because I had a lawyer act as a consultant, and he gave me reviewed my forms, gave me some tips about how to package the filing, and set expectations. It was a lot less expensive than hiring a lawyer to file the application, and it was a big help.

<comment><AUTHOR> Thank you for your response. I'm aware of OPT and H1B but from what I have heard, H1B is nicknamed indentured servitude for a reason. The employer is often aware of the fact that the employee has to comply with any of his requirements as if the employee gets fired, and he is unable to find another job soon enough, he'd have to leave the country. Furthermore, I'm not exactly fond of the idea of being an employee, I'm leaning more towards self- employment or founding a startup. But I guess beggars can't be choosers.

<comment><USER2> Yeah, the H1B definitely has a bunch of issues and there is that lock-in affect which is... unfortunate. I would say the employers are always aware of H1B requirements, just some choose to abuse them. You can transfer an H1B visa, but it is a bit of a time-consuming process. H1B's are also only issued in October, which is another limitation.

How long have you been in the States? Would citizenship be an option? In any event, in your case it would be appropriate to have a consultation with an immigration lawyer who can walk you through the various visas that are available and help you figure out which one best matches your situation. There are other employment visas but I am not particularly well-versed in what they are.</comment></comment></comment>


The Startup Failure Boom, And What To Do When It Happens To You - <AUTHOR> http://www.fastcompany.com/1841038/the-startup-failure-boom-and-what-to-do-when-it-happens-to-you

<comment><AUTHOR> Great reflective post on diving into a startup from another world (in this case finance)</comment>


To finish projects on time, start every single step as late as possible - <AUTHOR> https://twitter.com/fortelabs/status/770671266625785856 <comment><USER2> "26/ Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co"

Wow, I just don't know what planet this employer lives on where employees supposedly _enjoy_ sitting around idle until suddenly "holy crap tight deadline must crunch to make it!" Every once in a while, fine that stuff happens, but if a job were consistently putting me in "roadrunner mode" for every project, I'd be out of there in roadrunner mode too. Preferably before the anxiety and pressure turns into burnout.

<comment><USER3> Tiago here.

Roadrunner mode probably sounds a lot like the "crisis mode" we're all used to in most orgs, but it's actually more like supercompensation principle in all types of learning and training. You focus w/ everything you have, and then recover. Most orgs try to balance capacity, which results in this steady state of draining yet not really productive work. Theory of Constraints (which is what this thread is based on) says you should instead balance flow.

<comment><USER4> But why not say "starting working at the correct time" and address the issue head on vs. playing psychological games?

<comment><USER3> But what is the correct time? There is a whole subfield of project mgmt dedicated to exploring the theories around this question. And the line between "psychological games" and "psychology" is very thin, some would say non- existent.

<comment><USER4> Exactly my point, figure out the correct time and optimize for that, introducing what's effectively a neurosis seems kinda of neurotic way to work :)

<comment><USER3> But there is no correct time. That's a deterministic paradigm, whereas tasks are probabilistic events, with a distribution of possible points. Take a given task, and there are versions or scenarios where it takes 1x units of time, all the way to 100x. What critical chain does is help the worker play with the 3 sides of the PM triangle, time, budget, and scope, in a way that optimizes for the global throughput, not just their little local optimum.

<comment><USER4> That makes sense. Yep.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I seriously love Tiago's work. I don't know if anybody remembers, but I once wrote a post about procrastination that got to the frontpage of HN, a couple of years ago [1]. And since then, I've been basically reading everything relevant I've been able to get my hands on. (Here's a 'research review' of sorts: [2]).

I'd put Tiago squarely in my top 3-5 list of 'People Who Get It'. I highly recommend reading the rest of his work on the subject. [3]

__

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

[2] [http://visakanv.com/1000/0333-procrastination- pt1/](http://visakanv.com/1000/0333-procrastination-pt1/)

[3] [http://www.fortelabs.co/blog](http://www.fortelabs.co/blog)

<comment><USER6> No rss on that blog, is this a thing now?

Harder to follow unless I go to Medium

<comment><USER3> Yeah, sorry about that. Next best thing is to sign up for email updates: [http://www.fortelabs.co/blog](http://www.fortelabs.co/blog)

</comment></comment></comment><comment><USER7> Isn't there a bit of a trick here in knowing when is "as late as possible" and not "too late"? Does this not require knowing _exactly_ how long everything will take?

<comment><USER8> Another way of saying this is, do not waste effort by starting early on non- critical tasks. This all has to do with the critical path, the series of sequential, dependent tasks that determine the minimum project length.

Think of building a four-legged chair with multiple people (A, B, and C). You need to cut the wood into legs, a seat, and a back. You need to buy wood from the lumber yard, and buy screws and glue from the hardware store. You need to sand and finish the wooden pieces. You need to assemble the pieces with screws and glue.

The naive approach would be to have everyone go buy materials (and wait for everyone to get back), then together cut the wood (and wait for everyone to finish cutting), then together finish the wood, then together assemble the chair. This takes a longer time, because people will wait at each step, if there is any difference in task completion time between people. The length of each stage is the maximum of each individual task completion time.

The critical-path approach would be to send A to wood store. A returns and starts cutting leg 1, not waiting on B to return. B starts sanding the leg 1 completed by A, while A starts cutting the next leg, 2. C starts by finishing leg 1 after B finished sanding, while A starts cutting leg 3, and B starts sanding leg 2. Near the end, A has finished cutting the chair back, and goes to the hardware store to buy the screws and glue. A returns and starts assembling the chair as the pieces become ready.

Note how much earlier all the wood was cut in the naive approach. This is "early starting". In the critical-path approach, the cutting of each piece by A was delayed until it was needed by B for sanding. Buying the screws and glue was delayed until much later, when they were finally needed for assembly. That is because the critical path is:

(Buy Wood) -> (All Parts Are Finished) -> (Assemble Chair)

Other tasks can be delayed as appropriate, when doing so allows more resources to be spent on the critical path. I.e., wait until you are almost ready to assemble the chair before you buy the screws and glue, as time is better spent on getting those pieces finished!

I hope that makes sense.

</comment></comment><comment><USER9> A story split in 37 tweets. Are some clients supposed to display that better than 1/, 2/ etc? What happened with Twitter's experiment with the 10,000 characters limit? [https://news.ycombinator.com/item?id=10844306](https://news.ycombinator.com/item?id=10844306)

<comment><USER10> > A story split in 37 tweets

I don't understand why people do this instead of just writing a blog post and tweeting a link to _that_.

<comment><USER11> Writing it inside Twitter means people can't share/like [retweet/favorite] the whole thing, but instead readers will pick specific parts they find most interesting. This gives the author more finely grained data about which sentences hit the mark for their audience.

<comment><USER12> Some sites (Medium comes to mind) allow readers to "highlight" sections, and even expose some threshold of those "highlights" to other readers. It may be that that feature isn't used enough to give authors much data, but I also wonder how much people use Twitter the way you describe.

</comment></comment></comment></comment><comment><USER13> Someone taught me, years ago, some technique (don't remember the name) where you would move all the tasks to begin in the last possible day.

Then, study the critical path to exclude all those "extra fat" that everybody includes in each task, assuring that the critical path is really critical, without hiding days/hours that would lead to procrastination in the critical path. Save it to an "emergency buffer".

Review if something else became the critical path. Repeat until stability arises.

Now, manage it, use your buffer when required, always take care if something else becomes the critical path (as everything will begin in the last possible time).

And, even if something becomes critical path and takes more time than required, you have some buffer...

<comment><USER14> Reminds me of Goldratt's Critical Chain - he of Theory of Constraints (TOC), The Goal, etc

<comment><USER15> Reminds? It is a direct quote of Critical Chain, see #37

</comment></comment></comment><comment><USER16> Well yeah of course this is one way of thinking, in that if you could use the early times to do something else meaningful then why not, instead of wasting all of the time on that one single thing which might not be improved that much by all the additional time. That's true to an extent. A good example I can think of is the exam preparation for university entrance exams in China. It's a common practice by high schools to dedicate all three years to it at the expense of other useful developmental activities for students, which is an absolute waste. Just at most one year is totally enough, as proven by some alternative high schools.

However, I'd still argue that the problem of most people/individuals (especially as contrasted to huge organizations with loads of formal methodologies) is still delaying/procrastinating too much instead of too little. Too much pressure sucks, so is a rushed product/result compared with a carefully prepared one. So no, unless you really know very clearly what you're doing and how your plan will work out, which 99% of people have no clue about, start as early as possible, much earlier than your estimate, otherwise you'll definitely regret it. Though I acknowledge that this guy mostly talks about management methods, not productivity for individual endeavors.

</comment><comment><USER17> Here is the full text:

1/ The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do)

2/ First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions

3/ It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven

4/ Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space

5/ Third, even if u do finish a step early, that gain will be wasted: next person won't be ready

6/ Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy

7/ Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)

8/ Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"

9/ Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)

10/ 70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc

11/ Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty!

12/ But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to?

13/ So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle

14/Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot

15/ Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)?

16/ So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent

17/ Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed

18/ This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!

19/ Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!)

20/ If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained

21/ The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible

22/ Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform.

23/ Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams

24/ Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"

25/ This helps ppl not multitask, since they only have one task at any given time, and it's late!

26/ Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co

27/ ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time

28/ 3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed

29/ U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have

30/ Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have

31/ The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity

32/ To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel!

33/ BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think

34/ And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily

35/ There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use

36/ The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise

37/ If u want to know where all this comes from, Critical Chain Project Mgmt: [https://en.wikipedia.org/wiki/Critical_chain_project_managem...](https://en.wikipedia.org/wiki/Critical_chain_project_management)

<comment><USER18> And here it is reformatted into paragraphs:

The key to finishing projects on time is to start every single step as late as possible (exactly the opposite of what most PMs do). First, because only progress on the critical path matters for final delivery, therefore all other starts are distractions. It would be like spending hrs on a huge dinner prep by making all the side dishes, only to realize u forgot to pre-heat oven.

Second, starting early doesn't mean you'll finish early. Parkinson's Law: the task simply expands to fill the extra space. Third, even if u do finish a step early, that gain will be wasted: next person won't be ready. Starting a step early actually has all sorts of negat conseq, which is why procrastination is evolutionarily & logically a good strategy:

* Starting early increases likelihood u don't have all info and prereqs, making rework likely (i.e. estimate blowout)

* Starting early increases the surface area for interruption attacks (internal & external), since u "have plenty of time"

* Starting early explodes the amt of lead time not spent actually working (i.e. Touch time)

70-99% of task lead time is waiting time, queueing, pending confirmation, waiting on approval, learning, rampup, setup, etc. Ppl complain about estimation being hard, but it's not "uncertainty". It's them starting things early due to supposed uncertainty! But maybe the worst effect of starting early is that ppl start late anyway. Who actually begins a step before they have to? So you get worst of both worlds: a LONG plan with huge lead times, which are ignored as ppl do everything last minute. Vicious cycle.

Last reason early starts suck, is they give illusion of safety. But Murphy doesn't hit everywhere evenly, he concentrates chaos at 1 spot. Irony is this is self-reinforcing: did you hit the deadline because u executed well, or because you had excessive safety (100-200%)? So person who adds the most excessive safety is rewarded for "hitting their estimate," as if estimating and executing are independent.

Late starts fix all this: when the step is "released," they have barely enough time to finish if they go at full speed. This pressure helps them focus, get into flow, ignore distractions/interruptions, optimize for 1 thing, get it done!

Procrastination isn't an issue, because they're already behind, since u also cut their estimated lead time in half (oops!). If they finish on time it's actually a cause for celebration, and the next person can actually take advantage of the time gained. The PM knows what to focus on, since u start with few steps (critical path ones) and only gradually begin new ones as late as possible.

Another benefit: once crit path person passes hot potato, they're free! U don't assign them new work, that would be punishing perform. Late starts also help with resource contentions (the same person doing 2 steps), esp important in cross-funct creative teams. Instead of "start everything NOW!" You're saying "U must not start anything until the last poss moment. Focus on the current task!"

This helps ppl not multitask, since they only have one task at any given time, and it's late! Ppl are generally happier: focus + flow + roadrunner mode (only 2 speeds, 100% & 0%) + fast results = happiness for both emp & co.

ANOTHER benefit of late starts: u have much better estimation data, since lead time now more closely approximates touch time.

3 main results of all this: throughout (output x sales) explodes, lead time per project plummets, and huge excess capacity is revealed. U read that right: earlier u start steps, the later u deliver projects, the more excess capacity you're likely to have. Why? Because the almost universal response to late projects is "we need more capacity!" False. U need to use what u have. The busier everyone in your co seems to be, the more confident I am that you have tremendous, double-digit excess capacity.

To add insult to injury, emps in such companies also say they're "too busy to invest in productivity." Speed up the hamster wheel! BUT to use late starts, u also need buffers. Bec some steps do in fact go late, just not as many and not as late as u think. And I don't mean buffers as a general concept, u need very precisely placed and sized buffers divided into zones, updated daily. There is a buffer for every purpose: project buffers, feeding buffers, iteration buffers, bottleneck buffers. Gotta know which 1 to use. The PM's job becomes easy: just watch the buffer penetrations. No need to do anything until it gets to Zone 3 or 2, all else is noise 37/ If u want to know where all this comes from, Critical Chain Project Mgmt: [https://en.wikipedia.org/wiki/Critical_chain_project_managem...](https://en.wikipedia.org/wiki/Critical_chain_project_management)

</comment></comment><comment><USER15> Actually the PM BOK (Project Management Body of Knowledge) added Critical Chain in the 5th edition (current one is 6th edition).

[https://4squareviews.com/2013/04/18/5th-edition-pmbok- guide-...](https://4squareviews.com/2013/04/18/5th-edition-pmbok-guide- chapter-6-critical-chain-method/)

</comment><comment><USER19> Ah, so I guess he'd approve of the way I stumbled through university :)

I get what he's saying, but I can't imagine adhering strictly to this would be healthy. I've waited until the last minute to finish enough projects to know how stressful and anxiety-inducing it can be, and have enough experience to know that my time estimates are never accurate.

<comment><USER16> I think the caveat is obvious here, that this is a method that applies to organizations with the help of a lot of formal methodologies, not individuals. For individual endeavors, it's always the right idea to start as early as possible, since without all the formal methodologies and structural control your estimate will always be literal laughing stock. Starting at the last moment is the absolute thing _not_ to do for an individual who has no clear idea/experience about project management on her own(95% of people really). Not to mention another issue deadly enough on its own is that there's simply nobody supervising a hard deadline for your own projects, unlike within a company structure. If you do so, just wait for series of trainwreck to happen to you. I think this is proven by countless examples and experience already and nobody would really object to that.

</comment></comment><comment><USER15> One amazing attempt to apply project management to software development can be found in the work of Steve Tendon at [http://chronologist.com/blog/2012-09-25/critical-chain- proje...](http://chronologist.com/blog/2012-09-25/critical-chain-project- management-in-TOC/)

</comment><comment><USER15> I just wish more people would read Critical Chain books, there are several very interesting books that discuss this technique - including some that were released just last year.

amazon.com/dp/1934979074/

amazon.com/dp/1499660901/

amazon.com/dp/1498746039/

amazon.com/dp/0884271536/ \- the original book that started it all

</comment><comment><USER20> Twitter? Really?! I guess that fits with the overall _missive_.

<comment><USER3> Well, 15m of tweeting on BART has led to dozens of high-value interactions, new followers, and insights for the upcoming blog post. Not bad as a case study!</comment></comment>


React 16.4 release notes (pointer events) - <AUTHOR> https://reactjs.org/blog/2018/05/23/react-v-16-4.html <comment><USER2> Pointer events integrate inputs from mice, touchscreens, and pens, making separate implementations no longer necessary and authoring for cross-device pointers easier. The one input API to rule them all!

Except... of course Pointer Events doesn't work in Safari. Safari doesn't even support the regular mouse event "buttons" property which has been in the specs forever, which is a constant source of Safari specific bugs in my experience. Nothing happens when you click? Oh, you must be using Safari!

Why is input handling such a pain in the behind!

<comment><USER3> Safari is the new Internet Explorer

[https://www.safari-is-the-new-ie.com/](https://www.safari-is-the-new-ie.com/)

<comment><USER4> Until another browser implements proper tail calls as per the spec, I'll still have great respect for Safari, quirks and all. It's the only browser where you can write fully functional, continuation passing style code without fear of blowing the stack.

And all the fear mongering over "it makes debugging haaard" is just frustrating. Debugging is hard, there's just no way around it.

The Develop menu in Safari is also without equal in my experience. Quick access to almost a dozen settings each of which requires either command line arguments or buried toggles and restarts in Chrome (or myriad extensions).

I do wonder why the console doesn't use a monospace font. That's not the only problem with Safari, but it's one of the most off-putting, glaring issues. Makes you feel like the browser isn't intended for serious work. Which I guess some people would say is true.

<comment><USER5> > I do wonder why the console doesn't use a monospace font

I use Safari dev tools exclusively and can report that the console does indeed use a monospace font. I wonder how you configured your setup to use otherwise.

<comment><USER6> Any reason you prefer Safari dev tools over Chrome's?

</comment></comment></comment></comment></comment><comment><USER7> I'm just excited for [https://reactjs.org/blog/2018/03/27/update-on-async- renderin...](https://reactjs.org/blog/2018/03/27/update-on-async- rendering.html) , and curious to see how it works in our code.

<comment><USER8> Absolutely ! Any news on that btw ?

<comment><USER9> the Suspense PR was merged in for this version ([https://github.com/facebook/react/commits/master?after=fa7fa...](https://github.com/facebook/react/commits/master?after=fa7fa812c70084e139d13437fb204fcdf9152299+69)) so you can absolutely start trying it out in 16.4. with the requisite warnings that it is still unstable. I keep a repo of all publicly discussed stuff on async react here: [https://github.com/sw-yx/fresh-async- react](https://github.com/sw-yx/fresh-async-react) for people's research convenience.

<comment><USER10> I think these commits were taken out of the release. At least I couldn't find them when I took a quick look: [https://github.com/facebook/react/commits/v16.4.0](https://github.com/facebook/react/commits/v16.4.0)

<comment><USER9> it was merged from acdlite's branch. look harder :)

</comment></comment></comment></comment></comment><comment><USER11> Great release. I am still desperately waiting for passive/once events support though. VueJS integrates them in a trivial way:

        <div v-on:scroll.passive="onScroll">...</div>

Would love to have this simplicity in React.

</comment><comment><USER12> The pointer events contribution comes from PSPDFKit, a company that sells PDF SDKs for mobile, desktop and web. It's used in [https://pspdfkit.com/web/](https://pspdfkit.com/web/)

</comment><comment><USER13> A curated list of awesome React Components & Libraries: [https://reactjsexample.com/](https://reactjsexample.com/)

</comment><comment><USER14> In the grand scheme of things this sounds like one of the more boring version bumps but I'm sure a lot of people are going to be really excited about this.</comment>