Feynman on Fermat's Last Theorem (2016) - <AUTHOR> http://www.lbatalha.com/blog/feynman-on-fermats-last-theorem <comment><USER2> Previously discussed:

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

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

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

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

... and previously submitted without discussion:

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

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

<comment><USER3> Is the "past" link being deprecated or something?

</comment></comment><comment><USER4> > Feynman concluded: "for my money Fermat's theorem is true". > "the main job > of theoretical physics is to prove yourself wrong as soon as possible."

Great example of the main difference between mathematicians and theoretical physicists .

This reminds me of another magician, Enrico Fermi, who was also an extremely good mathematician but didn't pursue rigor or precision for the sake of it: 20% was good enough precision for him for most cases.

<comment><USER5> > > Feynman concluded: "for my money Fermat's theorem is true".

> > "the main job of theoretical physics is to prove yourself wrong as soon as > possible."

> Great example of the main difference between mathematicians and theoretical > physicists.

Actually, I'm not sure I agree: even before Wiles's proof, almost every mathematician would have been willing to wager, at least conversationally, on the truth of FLT; and mathematicians also are in the business of proving themselves wrong as soon as possible. The only catch is that we don't count an inability to prove yourself wrong as a proof that you're right ….

<comment><USER4> The difference lies in the fact that absolute rigor to assess truths is not as fundamental in theoretical physics as it is in mathematics. Uncertainty is accepted. Physics puts a premium on empirical results and intuition over the more formal treatments common in mathematics (many important results/tools are not mathematically well-defined e.g. Feynman path-integral in d > 1).

<comment><USER5> Agreed! I didn't mean to claim that there isn't a difference, for there is a wide one; only that the two particular quotes chosen seemed (unlike most other things Feynman said!) not to illustrate them.

<comment><USER4> Fair enough. Agree that the second quote doesn't illustrate my point, contrary to the first one. Cheers!

</comment></comment></comment></comment></comment><comment><USER6> This proof (or "plausibility argument") bugs me so much. Just because something thins out and becomes rare doesn't mean it doesn't exist.

As n gets bigger, the probability of n being a perfect square gets smaller and smaller. In the limit, the probability is zero.

Does this mean square numbers don't exist?

<comment><USER7> By Feynman's argument, you can prove that square numbers almost certainly keep on existing.

Roughly, it goes as such:

1) the probability of N being a perfect square is proportional to 1/sqrt(N).

2) For any N_0 arbitrarily high, if you integrate from N_0 to infinity the expression (1/sqrt(N) dN), you get infinity.

3) The expression in 2) is the "Feynman equivalent" of the expected number of square numbers above N_0.

So Feynman's nonproof actually turns out to be true, despite it not being a proof in this case as well.

<comment><USER6> Okay, let's pick something rarer. Rational numbers.

If you integrate the characteristic function of the rational numbers over any interval, you get zero because rational numbers are very rare.

So they don't exist either?

To be less glib, I don't see Feynmann's argument to be bringing anything new. We already knew that counterexamples, if they existed, would be very rare because we tried looking for them with computers and we couldn't find them. But stuff being rare still doesn't prove anything.

Many of us were fooled by Skewe's number:

[https://en.wikipedia.org/wiki/Skewes%27s_number](https://en.wikipedia.org/wiki/Skewes%27s_number)

There's no way to conclude that this exists via brute calculation. It's just inconceivably large and would have eluded any of Feynmann's methods.

<comment><USER8> Your rational numbers argument does indeed fail, but for a different reason. It's not valid to go from a sum over the rationals to an integral in the reals in that way, however it _is_ perfectly valid to go from a sum over the integers to an integral over the reals (in certain situations), if you only want an estimate (see eg. the Euler Maclaurin formula [https://en.wikipedia.org/wiki/Euler–Maclaurin_formula](https://en.wikipedia.org/wiki/Euler–Maclaurin_formula) ). This was fine in Feynman's argument.

</comment></comment></comment></comment><comment><USER9> Is anyone still trying to come up with Fermat's original "truly marvelous proof"? Or have math folk talked themselves out of its possible existence?

<comment><USER10> Well, I'm not 'math folk' (grey beard programmer), but I love the Horizon documentary on Andrew Wiles and his solution, and I'd love to hear why my intuitive understanding is inapplicable from people who know better than myself. (Note that this will not in any way be a proof, but just the train of thought I believe to be the line of thinking Fermat may have used to construct his proper mathematical proof.)

My idea here is based upon physical/visual intuition, starting with why it works for n=2 (squares) and then why it cannot work for n=3 (cubes) and then that n>3 is necessarily more complex than n=3 thus cannot work either.

[Note that I will use lower case letters for the sides/roots and their uppercase letters to denote the areas or volumes. Thus, the full equation is Z=Y+X, with X = x^n, resulting in z^n = y^n + x^n. I also use (for n=2), dy = z - y, and Dy = 2(y(dy)) + dy^2, and dx = z - x, and Dx = 2(x(dx)) + dx^2. I'm sorry my dx and dy conflict with calculus notation but my notation means dx is "the difference between z and x" which is the same as "the length that must be added to x to equal z" and Dx is "total amount that must be added to X to get Z". Therefore (for n=2), Dx = Y = 2(x(dx)) + dx^2, and Dy = X = 2(y(dy)) + dy^2. ]

For n=2, Z=Y+X works because (what can be visualized as a square) X can be "smushed" over two sides and their joining corner of (the other square) Y evenly, such that Z = Y + Dy = Y + 2(y(dy)) + dy^2. The term "2(y(dy))" is the amount that must be added along each of the two sides, and the term "dy^2" is the amount that must be added at the corner to complete the perfect square Z.

So, for example, 5^2 = 4^2 + 3^2 because both 3^2 = 9 = 2(4(1)) + 1^2 = 2(4) + 1 = 8 + 1, and 4^2 = 16 = 2(3(2)) + 2^2 = 2(6) + 4 = 12 + 4.

Now, for n=3, we must visualize the situation where the cube X is smushed over the cube Y's three faces and its joining corner. (Now X=x^3 and Y=y^3.)

The equations for dx and dy are the same, but Dx and Dy have expanded by a dimension: Dx = Y = 3(x^2)(dx) + 3(x)(dx^2) + dx^3, and likewise Dy = X = 3(y^2)(dy) + 3(y)(dy^2) + dy^3.

The term "3(x^2)(dx)" is the amount that must be added to three faces of the cube Y, the term "3(x)(dx^2)" is the amount that must be added along the three edges joining those three faces of the cube Y, and the term "dx^3" is the amount that must be added at the corner.

Now, I haven't the maths to prove why Dx and Dy for n=3 won't have integer solutions but my intuition says it has something to do with the fact that it's three dimensions and, therefore, a couple of odd numbers multiplying around in there (the first two terms) and the fact that there are only two cubes being smushed together to try and reconstitute another perfect cube. I also imagine Fermat could actually mathematically prove why it's impossible. Perhaps it can be shown that Dx and Dy cannot both have diophantine solutions. These are just guesses.

As for n>3, the terms (and physical/visual representations) will only become more complex and there will be still only two terms with which to reconstitute the hypercube.

Anyway, that's my intuition about the entire problem and I have to imagine that a proof that Fermat can easily intuit yet is (a bit?) too large to fit in the margin must surely tread down a simple path, perhaps even one that relies on a physical/visual interpretation of what the equations can be likened to.

I look forward to this being eviscerated or flatly rejected, if appropriate, or at least corrected for inconsistencies. If it serves anyone in their exploration of this insidiously complex yet apparently simple-seeming problem, my joy would only grow. If my name would someday appear in a mathematical paper that a real mathematician produces as a result of this, well that would be out of this world for this poverty-striken math wannabe.

[Edited to fix my n=3 equations.]

<comment><USER11> Your intuition is similar in spirit to Feynman's. For n>2, the number of plausible candidates is sparse, whereas for n<=2, there are many plausible candidates.

</comment></comment></comment><comment><USER12> _DON'T DOWN VOTE JUST BECAUSE YOU CAN'T DO MATH_

The proof Fermat hinted to was about the difference between squares. All whole numbers taken to a power greater than two (n^3) can be represented as the difference between two whole squares (x^2 - y^2). These differences can then be shown as the sum of consecutive odd numbers:

        2^3 = 3^2 - 1^2 = (1+3+5) - (1) = 8,
        3^3 = 6^2 - 3^2 = (1+3+5+7+9+11) - (1+3+5) = 27,
        4^3 = 10^2 - 6^2 = (1+3+5+7+9+11+13+15+17+19) - (1+3+5+7+9+11) = 64

        5^3 = 15^2 - 10^2 = (21+23+25+27+29) = 125

When you examine the odd number series that results from each base, you'll discover that there will always be a gap if you try and combine two odd number series together, which explains Fermat's little joke about margins. The same trick works for higher powers.

It's not that hard people. Stop believing everything you're told about how "hard" something is.

 __ _HINT:_ __The number of odd numbers in the series exactly matches the starting square base number

<comment><USER13> Sounds interesting, but not sure what you mean by:

> you'll discover that there will always be a gap if you try and combine two > odd number series together

Can you elaborate?

<comment><USER12> Consecutive base numbers will necessarily alternate between even and odd. So even the closest base numbers still have a gap between their resulting odd number series, which only increases as the distance between base numbers increases.

<comment><USER14> Still don't get it. What do you mean by "base numbers" and what do you mean by "alternate between even and odd"?

<comment><USER11> 'ox_n appears to be trying to prove (by a pigeonhole agument) that the equation x^n + y^n = z^n in unsolvable for _some z_. That's much weaker than proving that it is unsatisfiable at _every_ z.</comment></comment></comment></comment></comment>


Using Presto in Our Big Data Platform on AWS - <AUTHOR> http://techblog.netflix.com/2014/10/using-presto-in-our-big-data-platform.html <comment><USER2> Presto is an amazing open source MPP engine. It has excellent architecture and an active community. We ( [http://www.treasuredata.com](http://www.treasuredata.com)) use it extensively as one of of our big data SaaS query engines (also we contribute back a lot to Presto).

</comment><comment><USER3> Qubole offers Presto as a Service with a free trial ([http://www.qubole.com](http://www.qubole.com)) with a bunch of interesting enhancements for the cloud. We've found Presto to be a great engine for realtime queries over large datasets.</comment>


Ask HN: 20+ Postings in 20 minutes of HN. Is this considered spam ? - <AUTHOR> http://www.webcitation.org/5vU30ydvF

<comment><USER2> I think it's time to stop awarding karma for submitting stories. It really doesn't make sense to do so in the first place, but I suppose it might have helped back when the site was young.

Now, since pretty much every good story is going to end up here anyway, I don't see any reason to reward people for posting them.

Karma for comments makes sense, since it's an actual contribution by you. Karma for posting something you didn't even write just leads to people gaming the system.

<comment><AUTHOR> I would not go so far as stop awarding those karma. It gives people the incentive to post those stories and its not that just by posting one gets some karma. It has to be liked by the community. But the quantum of karma per post should ideally be less than that for a comment.

Karma seems more sought after than I thought. It seems there is almost a viable market for it. _Shudder_

<comment><USER2> Indeed, people are here seeking karma for its own sake. That's the problem.

It's also the reason why _every single techcrunch article_ get submitted here. There was a time where you'd see maybe one TC article a week come through, usually with discussion as to whether it was really worth being here.

Realistically, maybe half a dozen articles per day are high enough quality to even be submitted here. The fact that we're seeing thousands each day is a sign that standards have fallen drastically. Removing the incentive to post things unless they're _really good_ would go a long way toward improving the signal to noise ratio.

<comment><AUTHOR> Your comment made me think of a scheme where a post automatically incurs a tiny negative karma, which can be compensated and exceeded by the karma awarded by the community. Right now we do not have any dis-incentive for posting noise. It will make posters think twice.

However karma has to be made a float as opposed to an integer. I am curious, do downvoters get a tiny hit for downvoting ?

<comment><USER3> I agree there should be a cost for posting stories, even going so far as preventing further submissions if you fall below a certain threshold. You could raise your karma back up through commenting.

</comment></comment></comment></comment></comment><comment><USER4> Couldn't help but notice that a while ago the user submitting those links asked for the benefits of having a higher karma on HN (<http://news.ycombinator.com/item?id=2051403>).

While this is a perfectly valid question that many people have or had, it may also indicate an interest in getting a higher karma for the sake of it, instead of thinking about the benefits of his/her contributions to the community.

<comment><USER5> I am a newbie and only trying to figure it ALL out. should be able to do this without being called out for asking a newbie question.

<comment><USER5> so even my question about being a newbie get voted down. NICE!

<comment><AUTHOR> Maybe because someone who is more than 90 days on HN isn't considered a newbie. That's plenty time to get an idea about the community. Besides, most fair play guidelines are universal and common sense and do not really require to be dug out from the dark.

p.s. Just in case you think so, I have not down voted any of your comments and am newbier than you by a shade.

<comment><USER5> I asked the question because I did not know the answer. Need to ask a question to get the answer. Sorry I have not spent 90 days on here non stop... And as I stated in the question that was asked ( many days ago.. Geez), I did search FAQ before I asked.

<comment><AUTHOR>
      > so even my question about being a newbie get voted down. NICE!

Is not a question. That's what I was referring to. You will get the context from the indentation level. And yeah I hope :-) that not everyone has been on the site everyday since the day their account was "created".

<comment><USER5> Ok I am taking notes: when you have, enough point to do so down vote all newbies who are learning the ropes and discourage them from feeling welcome or posting. Right? That is a question by the way.

<comment><USER6> You made a fuck up. Some people tried to help, others piled on a little strong.

Bottom line is; things are a bit different around here (as well as much the same as any other community). Accept you screwed up, read the advice and take it away. Getting upset at blunt replies isn't really going to help (you or anyone else). Getting mad about the downvotes, even less so. Starting threads moaning about flamewarring etc. is even worse ;)

Don't worry about it. We all make mistakes. Now you've had a crash course in some of the rules and ettitquete.

No one is out to get you.

I would ignore this entire thread from now on if I were you. There is little else constructive to be added. I suspect a mod will kill it off reasonably soon.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is very unwelcoming and an attack to the individual. Not taking any sides really but the way how you worded the post.

"20 in 20" sounds like you wanted a winning headline (which I guess is the case)

Please stop scolding the user for trying something out of the norm. It just means one will have to take a bit more effort to go back the first page of <http://news.ycombinator.com/newest> (click the more link... some more).

You can also tell the user that comments hold more value for a person than posting links.

It is like twitter for some people at first you try to mimic the big guys as fast and as abundant as possible but after a while you "get" the system.

Give the user some time o0. These guidelines are taken as advice no? After all this is just an experiment. Stop smothering the small guys, we are people too :)

<comment><USER5> Thanks so much. I needed to read this after the not stop down votes I have been getting. NO matter what I post.

<comment><USER8> Perhaps you should consider changing what you post, then? Most of the comments you've left have exactly the same style/tone, and it's a very self-serving and self-entitled one.

It might be better to listen for a while and stop posting more comments complaining about down-voting - the more of those you post the worse your average score will be (because you can be sure that a comment complaining about down-voting will never be voted up much).

</comment></comment></comment><comment><USER9> The suite guide would indicate that this is considered "bad form".

</comment><comment><USER10> I do ... one of the nice things about HN is the quality of its human filter!

But to address the cumulative comments made by 10smom below, here's the snippet from her profile - "I am a Female, self funded, Startup Entrepreneur". From what I've seen lurking around here for a year or so, you're best bet is to ask for feedback on your start-up. You'll either get accolades or at least constructive criticism but I strongly doubt you'll get into an argument like this one.

If you're thick-skinned enough to be an entrepreneur, I'm sure you can forget about this thread ... let's just start over as though we'd never met you.

And if you're worthy of karma, people will realize that over time and you'll get it. I started following patio11 a long time before he was a rising karma star, but if you read his comments here and his blog at <http://www.kalzumeus.com>, you'll realize why he has (and deserves) so much respect.

Pleased to meet you 10smom!

</comment><comment><AUTHOR> Or take a look here

<http://news.ycombinator.com/submitted?id=10smom>

<comment><USER5> Y combinator encourage posting news by their rating system. Nothing wrong here by doing exactly what YC encourages. Why not post if I find good news? They even make it extremely easy by their bookmarklet. Also it gives me a great way to keep good news in one place: my profile! :)

<comment><USER11> Generally the unspoken rule here is that if you are taking up most of /newest you are posting too much. Sorry that's unintuitive; it's quite weird that Hacker News has lots of secret rules.

<comment><USER12> It's not a secret, it's in the guidelines.

<comment><USER11> :) Great. <http://ycombinator.com/newsguidelines.html>

</comment></comment></comment></comment></comment><comment><USER13> Whoah, the whole of newest is this guy. Moreso, what on earth is web-citation? Apart from a tad annoying!

<comment><USER14> Think Google Cache. He used it since that page is always changing.

<comment><USER13> Ahh I see. Makes sense, very clever. HN should have the same sort of thing that Techmeme has. Clever stuff, that.

</comment></comment></comment><comment><USER5> If you notice most of the news is CES 2011 and thought it was worth while info to post. LOts of news coming out right now from CES. Do a search you too will find a ton of new stuff since I posted. Feel free to post! I promise I will not call you out. :)

<comment><USER15> If you want to post something about CES 2011 that you think would be of interest to hackers, do it, but pick ONE item that you think is the best and submit that.

If that one item doesn't make it to the front page, then you confirm that others don't have interest in the other not-as-good items, so don't submit those.

</comment></comment><comment><USER5> OK so, Now I am getting the system: Flame A person for being a newbie, Collect as many up points as you can by doing so then, follow that newbie around and down vote everything they post? Do I have that straight? I just want to be sure.

<comment><USER16> Careful... You are bordering on being inflammatory with your sarcastic questions. Having read all of your posts/replies, you are close to what people would call a troll.

From wikipedia - In Internet slang, a troll is someone who posts inflammatory, extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking other users into a desired emotional response[1] or of otherwise disrupting normal on-topic discussion.

As I am sure this is not the intention you have, please be a bit more careful. We are all friends here. No need for sarcastic questions or inflammatory messages.

</comment></comment><comment><USER17> The problem is that we are (mostly) programmers and the temptation to automate this sort of thing is quite overwhelming :)

Well we use tools to automate the reading of this site, why not the posting too?

<comment><AUTHOR> Sure I can bulk dump entries from my feed reader to HN, but that doesn't mean I should, right ?

</comment></comment><comment><USER18> Definitely. And regarding karma, for me the only karma that "counts" is the messages one, the ones who only dump links on HN without commenting further are on the wrong site, imho.

</comment><comment><USER19> This probably results from a collision of the submission bookmarklet and an RSS reader, perhaps combined with someone's massive morning cup of coffee.

</comment><comment><USER20> "Please don't submit so many links at once that the new page is dominated by your submissions"

PG</comment>


Use streaming JSON to reduce latency on mobile - <AUTHOR> https://instantdomainsearch.com/articles/streaming_json_jsons/ <comment><USER2> I agree that a streaming response is cool, but why the dismissal of returning valid JSON, streamed? Why invent a new protocol when JSON already exists? Streaming JSON parsers aren't unicorns, they are horses (sorry).

With this new-line-delimited JSON format all your clients HAVE to know about your new protocol. They have to stream the response bytes, split on new lines, unescape new lines in the payload (how are we doing that, btw?), etc. If a client doesn't care about streaming, it can't just sit on the response and parse it when it's done coming in. Or, how about if later on you upgrade the system so that the response is instant and streaming is no longer necessary? Then you move on to a new API and have to keep supporting this old streaming- but-not-really endpoint forever.

<comment><USER3> I've been using jsonlines for logfiles from about 5 years before it acquired a name.

With line delimited logfile objects, it's easy to grep for a string of interest and then only parse the lines that match -- much more efficient than parsing an entire logfile to pick out 0.01% of the lines.

That's not the usecase talked about in this article, but it is a usecase that's important to me.

<comment><AUTHOR> It's also easy to load them into Google's BigQuery: [https://cloud.google.com/bigquery/docs/loading- data#supporte...](https://cloud.google.com/bigquery/docs/loading- data#supported_data_formats)

<comment><USER4> I was just about to name that as an example. Newline separated JSON is a so much simpler solution to the problem than streaming JSON parsers. They're easier to understand, and it's trivial to implement.

From a purity point of view, sure, streaming JSON is more "correct", but I wouldn't call it the better solution.

</comment></comment></comment></comment><comment><USER5> Somewhat related is the JSON Lines "spec": [http://jsonlines.org/](http://jsonlines.org/)

</comment><comment><USER6> I have nothing but praise to this service. It's fast and efficient, and does the job without bloat.

For instance, their iOS app weighs 888.8 KB! When it's common for simple apps to be 50 MB monsters, it's very refreshing to use something that has been developed with proper care.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER7> You say that using websockets was less reliable than streaming HTTPS, can you elaborate why? In my experience websockets are perfect to use for the use case you described, are there disadvantages?

<comment><AUTHOR> I tried this a long time ago. At the time, certain queries were hard for a server to answer. Other clients connected to the zombie server stalled until something timed out. With HTTPS, a load balancer can direct new queries to servers that are responsive.

<comment><USER8> I was also curious about this (and thanks for the article, very informative!)

Are you saying that at one point the servers would crash relatively often, which would leave sockets clients hanging, unless some complicated client-side code was written - whereas without sockets, a load-balancer could automatically switch clients to functional servers, without extra coding, and mitigate the issue? Isn't the problem the crashy servers?

<comment><AUTHOR> Sure, but why keep state when you don't need to? Now that HTTP/2 is ubiquitous, sending new GET requests is no more expensive than sending bytes through a WebSocket.

</comment></comment></comment></comment><comment><USER9> As someone who _actually_ regularly uses a slow mobile connection (8 kilobytes per second!) with somewhat high ping (~90ms to Google), please don't do this thinking you're making my life significantly better. It barely makes a difference in performance once loaded, and the initial load time is _ridiculously_ worse. I'd much rather you make your page work _without JavaScript_ , kept the design light (as this page has otherwise done), and make your CSS cacheable.

Right now, it takes over 5 seconds(!!) for this page to load because of all the freaking JavaScript it has to download! With JS off, the page loads _almost immediately_. With a keep-alive connection, subsequent loads over HTTPS are not particularly long, unlike what this article seems to think. (Hacker News is one of the FASTEST sites I can access, for example. Even on my crappy connection, pages load nearly instantly.)

Simply letting me type, press enter, and wait 0.1~0.3 seconds for a new page response would not be a significantly worse experience -- however, due to the way the site is written, search doesn't work AT ALL with JS disabled.

So, lots of engineering effort (compared to just serving up a new page) for little to no actual speed improvement, and a more brittle website that breaks completely on unusual configurations... Yeah. Please don't do this!

<comment><AUTHOR> You should get the iOS app: [https://itunes.apple.com/us/app/instant-domain- search/id1068...](https://itunes.apple.com/us/app/instant-domain- search/id1068039352?mt=8)

It uses the streaming API, and will work well for you.

<comment><USER9> Thank you for the link, but I have Android, and I'm looking at the performance by tethering to my PC.

</comment></comment></comment><comment><USER10> Really interesting stuff! What about simply opening a Websocket connection and using that to for all requests if connection latency is such an issue?

</comment><comment><USER11> I did this a few years ago before I knew it was a "thing" and felt really proud that it actually worked.

The use-case was we had a slow database query for basically map pins. The first ones pins come back in milliseconds, but the last ones would take seconds. The UI was vastly improved by streaming the data instead of waiting for it all to finish, and the server code was easy to implement.

A different delimiter would have worked, but newlines are easy to see in a debugger.

</comment><comment><USER12> I'd like to see this streaming JSON parser incorporated into GraphQL clients: [http://oboejs.com](http://oboejs.com)

</comment><comment><USER13> Any benefit to using this over Server-Sent Events? (other than IE/Edge support)

</comment><comment><USER14> I think websockets is a much better use case for this if you don't want the reconnection overhead. Also since websockets are bidirectional, you can keep the connection open and send all requests through the connection as well as receive responses from the connection. Also you can send binary on websockets if you want to save bandwidth as well. We do this at work and it works pretty nicely.

</comment><comment><USER15> How is this handled from a UI perspective? As more applications are built around the idea of streaming data, I've found that UI elements tend to jump around, and I find myself clicking/tapping the wrong item more and more, because the item which had been under my thumb/cursor has jumped away just before I could activate it.

<comment><AUTHOR> This is a good point. De-bounce, static results ordering, and static elements with placeholders help. Instant Domain Search has room to improve here.

</comment></comment><comment><USER16> Isn't this pretty similar to how you would use WebSocket frames to transfer individual JSON elements when a client is subscribed?

At one job I had several years ago we came up with the same idea and use \n separated JSON elements as a streaming response. We also tossed around the idea of using WebSockets to stream large responses between services.

</comment><comment><USER17> Let's talk about reliability: The network is unrealiable; Firewalls might be broken, packets are dropped, IP-addresses may change, cellphones lose connection in subway tunnels. Simply calling "streaming reliable" without even defining what the "reliability" is protecting again, makes "reliable" an overstatement.

IMHO the most reliable way to get data from point A to point B is likely by having a client actively polling for data, using a strict socket timeout. Data should be at-least once delivered. If JSONS should be called anything remotely "reliable" as periodically polling, at least it should have a strict timeout (not mentioned in the article) for receiving the next newline & it should handle replaying of non-acked messages. Otherwise I would call it far from "reliable".

<comment><AUTHOR> Each request takes a second or two to complete. If you lose the connection, the client can send the same request again (with exponential back off).

</comment></comment><comment><USER18> Does anyone know a JSON parser that parses an ArrayBuffer instead of strings? [1]

JSON.parse() only accepts strings.

The library that the article recommends also uses XMLHttpRequest with strings. [2]

The reason I'm asking is the maximum string length in 32-bit Chrome.

[1]: [https://developer.mozilla.org/en- US/docs/Web/API/XMLHttpRequ...](https://developer.mozilla.org/en- US/docs/Web/API/XMLHttpRequest/responseType)

[2]: [https://github.com/eBay/jsonpipe/blob/master/lib/net/xhr.js](https://github.com/eBay/jsonpipe/blob/master/lib/net/xhr.js)

<comment><USER19> If you want to parse more than 4GB of JSON in a browser, ArrayBuffer versus string isn't the most important criteria - you shouldn't parse a 4GB ArrayBuffer as a single chunk either. You can always convert between an ArrayBuffer and a string, but you'll want to compare parsers according to the ability to stream, as well as performance and memory efficiency.

</comment></comment><comment><USER20> If the concern is HTTPS overhead, why not use HTTP/2 and send multiple requests?

I think streaming would be useful only if the responses are stateful and it's hard to share it across requests.

<comment><AUTHOR> Even with HTTP/2, sending a GET request is not free. Most of the benefit is that we can show the user results as they come in. Each query gets over 50 responses in random order from DNS, in-memory indexes of zone files, slower fuzzy searches over other data, and so on. Why wait to show them the .com result while .ca resolves?

</comment></comment><comment><USER21> Feels to me like the response content type shouldn't be "application/json" anymore (it is what's returned on that first example).

<comment><AUTHOR> IIRC, earlier versions of WebKit wouldn't emit data from each chunk when I sent a custom content type. Or maybe there was some conflict with gzip, I forget. Now that those browsers are gone, maybe ndjson? jsons?

</comment></comment><comment><USER22> Is there an advantage to using chunked streams like this over using WebSockets like this: [https://github.com/wybiral/hookah](https://github.com/wybiral/hookah) (this will take newlines from a programs stdout and send them over WebSockets, even aggregating multiple streams into one).

</comment><comment><USER23> I feel like I'm missing something here. Isn't that the point of using a JSON SAX parser instead of a DOM parser?

</comment><comment><USER24> How is this different than SSE [https://html.spec.whatwg.org/multipage/comms.html#server- sen...](https://html.spec.whatwg.org/multipage/comms.html#server-sent-events) ? Or, why would someone choose this over SSE?

</comment><comment><USER25> Why not just gzip the JSON? Should make complicated JSON around an order of magnitude smaller, and be more portable to boot.

<comment><AUTHOR> I do gzip the streamed JSON. Try:

$ curl -H "Accept-Encoding: gzip" \--trace - "[https://instantdomainsearch.com/services/vanity/apple?hash=8...](https://instantdomainsearch.com/services/vanity/apple?hash=866016287")

</comment></comment><comment><USER26> Why would you use this over web sockets?

</comment><comment><USER27> Should have (2017) in the title.</comment>


Mysterious radio flashes may be from stars collapsing into black holes - <AUTHOR> http://www.sciencedaily.com/releases/2013/07/130705101626.htm

<comment><USER2> A final shout before disappearing behind the permanent, impenetrable curtain of gravity: "I existed! I was."</comment>


Got Game Releases In-Game Browser  - <AUTHOR> http://www.techcrunch.com/2008/11/20/gotgame-releases-integrated-web-browser-for-games-watch-hulu-as-you-get-1337/ Browse the internet utilizing a transparent overlay in virtually any PC game! <comment><USER2> Speaking of Warcraft, most of the people I knew who played, did it in Windowed mode.

All to often, you needed to reference WowHead.com and after you alt-tabbed back in, you'd come back to find your dead little corpsed ganked by the damn Horde.

</comment><comment><USER3> Of course the screenshot on the site is of World of Warcraft. Early adopters anyone?

</comment><comment><USER4> _allowing users to swap between their game and the web with a single hotkey._

Alt-tab, anyone?

<comment><USER5> This is clearly more convenient, especially for the average user.

Of course, everyone should already be playing their games in a window via Wine. :-p</comment></comment>


Provide Sharp Knives - <AUTHOR> https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934 <comment><USER2> Third time this has been posted today.

<comment><AUTHOR> Trusted URL validation too much, my bad!</comment></comment>


To end mass incarceration, cap all prison sentences at 20 years – Vox - <AUTHOR> https://www.vox.com/future-perfect/2019/2/12/18184070/maximum-prison-sentence-cap-mass-incarceration <comment><USER2> I say, cap them at 10, make prison compulsury college, and bring back capitol punishment for eggregious crimes of an unforgivable, or irredeemabe nature. If a decade is not enough to learn, I doubt and extra one will help. Much less an extra decade being treated like meat inside a cell. Prisons are just places to hang out and learn from other criminals, while sowing distrust for authority right now. Precious little rehab is happening behing bars, and more trama than can be counted. It is well documented that trauma leads to more violence, and the cycle repeats. Either we start treating prisoners like people, or justify the current system of incarceration some other way.

I realize capitol punishment is unpopular, but there is some validity to deterrance, and life behind bars, unless things change, seems even less humane to me. I welcome a better solution, but what we have now seems ancient and barbaric compared to the rest of the world we have created.

</comment><comment><USER3> The funny thing about a 20-year cap is that at least for murderers and rapists, some vengeful loved ones of the victim(s) may still be alive to take retribution. For which they might get 20 years.

</comment><comment><USER4> Or we could just limit prison stays to rapists, murderers and bankers.</comment>


Medical studies are almost always bogus - <AUTHOR> http://nypost.com/2017/05/06/medical-studies-are-almost-always-bogus/ <comment><USER2> Preregistration of clinical trials causes medicines to stop working

[http://chrisblattman.com/2016/03/01/13719/](http://chrisblattman.com/2016/03/01/13719/)

...nuff said

</comment><comment><USER3> It would perhaps be more accurate to say "Health news stories about medical studies are almost always bogus". There are several steps between those two things, and university PR departments, funding agencies, researchers, reporters of highly variable technical background, editors, and publishers all have incentives to twist the message at each step along the way.

</comment><comment><USER4> Umm, maybe... but can we get a better source than the NY Post for this please?</comment>


The sad truth about sleep-tracking devices and apps - <AUTHOR> https://www.nytimes.com/2019/07/17/technology/personaltech/sleep-tracking-devices-apps.html <comment><USER2> I have a zeo, which actually measured brainwave activity during sleep. They went out of business and you couldn't get the sensor pads anymore, so it sits in a drawer.</comment>


Nobody is ever allowed to move to another country, the end. -Google - <AUTHOR> http://www.androidpolice.com/2015/11/21/psa-you-cant-change-your-google-accounts-country-if-its-tied-to-a-merchant-account/ <comment><USER2> I have a similar problem with google.

I lost access to my original gmail. If anybody took a 10 second overview they would see that I am the original owner but I am forced to sit back while an automated form response + an automated email response + an entire team of engineers + support forums + forum moderators + all the actual info I do still have on the account (which is accurate) and its still not enough to get my account back.</comment>


Engineering Failure? Huge Blast at Texas Fertilizer Plant - <AUTHOR> http://www.nytimes.com/2013/04/19/us/huge-blast-at-texas-fertilizer-plant.html

<comment><AUTHOR> <https://twitter.com/KHOU/status/324728967917625344>

60 or 70 people dead. Seven died in Challenger. I think this takes the cake.</comment>


Show HN: TOTransit.ca - Toronto Streetcars Live On a Map (Weekend Project) - <AUTHOR>

Link: http://totransit.ca
I made this on a weekend back in April. My motivation was to create something I would find useful, and to utilize data provided by Toronto Open Data (http://toronto.ca/open).
The app uses the NextBus API to get live data on streetcar positions. A small PHP script converts the XML to JSON format, but the bulk of the app is Javascript. Thanks to the Google Maps API, the app works nicely on both desktop browsers and mobile.
I find that a map view works well for many different data sets, so I have started an effort to create a generic "on a map" boilerplate. This is a stripped down version of the TO Transit code, and includes the code to make it web app friendly on smartphones. It's still pretty rough, but here's a link: https://github.com/nomatteus/onamap <comment><USER2> Looks nice! Maybe some additional filters would be nice: (North/South, East/West bound)

<comment><AUTHOR> Good idea. I want to add more features, but I don't have any more room for controls in the current view. So, I'm working on a separate "Settings" panel that would let you choose a bunch of different options. For mobile, I'm thinking of using jQuery Mobile to help build this part out.

</comment></comment><comment><USER3> Clickable: <http://totransit.ca></comment>


Raspberry Pi 4 not working with some chargers - <AUTHOR> https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/ <comment><USER2> There have been a lot of comments here but I want to leave one specifically to the person or team who designed the Pi's circuitry:

Thank you for working on such an important project and thank you for all the things that you got right.

I'm sure that somewhere, someone is feeling a little bit embarrassed and possibly somewhat sheepish over this and… Please don't let one incident overshadow all the great things that have come from the existence of the Raspberry Pi!

<comment><USER3> Yeah, this issue is not a big deal imo. It is an inconvenience, that may piss people off, but it is not a showstopper. I'm sure a minor revision will be made and most of us will not even remember this.

I hope this issue doesn't delay preorders, because I don't even care if my unit has this issue.

<comment><USER4> > Yeah, this issue is not a big deal imo.

It's not a big deal once they add to their list of "known issues" or "errata", together with the relevant workarounds. Otherwise, they might get too many returns from people who can't get it to power up with any of the chargers they have (because all they have is high-end chargers with 5A cables).

</comment></comment></comment><comment><USER5> Ever since the very first model, sub-par, underrated power supplies have been responsible for a good slice of tech support issues with the Pi. It wouldn't be a real Pi launch without power issues.

IIRC the Pi 3B+ was butting up against (if not exceeding) the maximum rated current for the microUSB port, so I believe the switch to USB Type-C is more about picking a port that can handle a 3A@5V supply than a conscious effort to support the dozens and dozens of terrible and near arbitrary USB Type-C supplies on the market (some output 12V with zero negotiation. You know- for giggles). I'd be surprised if they tested with more than a couple of staff phone chargers and their own-brand chargers. I can't imagine the idea of anyone using an expensive power-delivery enabled dock with a thick, 40cm Thunderbolt 3 cable really entered their minds.

My advice to anyone buying a Pi 4 would be "Just buy a Pi-branded power- supply. They're inexpensive and guaranteed to work." Granted you might want to save a few bucks and use your phone charger... but then what are you going to use to charge your phone?

<comment> marble-drink Funnily enough my trusty Pi2 which has been running continuously for several years now stopped working last night. At first I thought it must be the SD card, as those are known to fail. Nope. So I thought it must be the Pi itself. I suppose they weren't really designed to be left on for several years? I was sure it couldn't be the power supply, but somehow it was. It will now power up a Pi1, but not a 2 or 3. I've no idea why but it's gone in the bin and the Pi2 works again on a new one.

People really should consider a refurbished Dell Optiplex FX160 instead of a Pi if it's going to be in a headless server role, though. You can get one for about half the price of a new Pi4 on eBay and it comes with a proper power supply unit, high quality case, and of course an Atom CPU which I'm sure compares favourably even to the new Pi4. There was an article about them on HN a while back. Mine has been running happily for almost two years now.

<comment><USER6> Atom CPUs are core-for-core comparable to the A72 cores in the RPi4. ICP isn't really comparable since the instruction set is different, but performance is similar. The RPi has 4 of them, only the most modern Atoms have that.

<comment><USER7> I'm not seeing USB 3 on that particular Optiplex, either. Gigabit ethernet, yes. No HDMI. DVI, VGA. Maybe displayport? Hard to tell. Do have PS/2 keyboard and mouse ports, which is kinda nice.

<comment> marble-drink No USB3. I don't think it's any good as a thin client any more, it's only good as a low power server. Before the Pi4 it was much more attractive, especially because of GigE and because the Atom chip in it is pretty good compared to the ARM in the Pi3. But after reading the replies here I'm thinking it's not as good a choice as it once was.

</comment></comment></comment></comment></comment><comment><USER8>
      The fact that no QA team inside of
      Raspberry Pi's organization caught
      this bug indicates they only tested
      with one kind (the simplest) of USB-C
      cable.

      Raspberry Pi, you can do better.

I'd say at least 20% of the blame lies with whatever genius decided to have _multiple types of USB-C cable_

I mean, cables already suffer from having A, Type A SuperSpeed, B, B SuperSpeed, Mini-B, Micro-B, Micro-B SuperSpeed, C, and lengths from 10cm to 5m. Who'd expect adding a complete extra dimension of difference to be trouble-free?

<comment><USER9> I believe the original plan was the opposite - one port and one cable type that can do _everything_ \- 100W of power, 5K video, USB devices, analog audio, Ethernet and more.

But it was naive to think that manufacturers will ship a $30 cable for a phone charger when a cheaper hack will do.

At least there should have been mandatory color coding of the "full" and "limited" ports and cables, just as USB 3 ports were blue to distinguish them from older versions.

<comment><USER10> Until cheap knockoffs heard they could charge 4x their normal price by changing the coloring.

... You can't trust the coloring either if you're buying off of Amazon, eBay or any Chinese site like Alibaba

<comment><USER11> Coloring appears to have worked for distinguishing between USB 2 and USB 3, at least in my experience.

<comment><USER12> With USB 3 isn't the other end of the cable usually different as well?

<comment><USER13> USB-B for USB 3 is physically quite different, yes — looks like two stacked connectors.

<comment><USER14> It's a micro usb plus another kind of adapter. This gives you backwards compatibility for devices if you want to expose usb 2 via usb-a -> micro

<comment><USER13> I was actually thinking about B rather than micro-B, though I guess both my description and your explanation apply either way!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Before we had separate ports and cables for power, USB and Thunderbolt. There was no way to plug the wrong cable in the wrong port.

With USB-C, we still have separate cables for these three types, but they all look confusingly the same. Not convinced this is an improvement.

<comment><USER16> Just to be _entirely_ clear: While a cheap cable may be wrong, good (i.e. fully featured) cables will always work in all combinations.

Having gone all in on Type-C, I have only ever gotten a "bad" cable as a cheap charge cable, and have never had issues with cable incompatibilities.

<comment><USER17> I'd love to know then why my Nintendo switch(very expensive) doesn't charge at all when using the genuine OnePlus USB A-C cable(very expensive) and their own OnePlus charger(also pretty expensive). It's not just cheap mislabeled crap that sometimes doesn't work - it's proper hardware from big companies that failed the simple "if the cable fits then it has to work" test.

<comment><USER18> OnePlus has had their own proprietary charger game running for quite a while now. It's likely related to that. The Switch uses stock USB-C Power Delivery, so Macbook and Pixel chargers would be fine.

</comment></comment></comment></comment><comment><USER4> There might be yet another issue. As commented by the author of this blog post in the RPi forums ([https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=2438...](https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=243875#p1492674)): "Also the 5v on the connector is connected directly to the 5v rails. If the pi is powered over the GPIO then the USB-C connector is vbus hot which means it could backfeed devices when using the type C port on the pi as a USB client."

That is, when powering the RPi4 through PoE, its USB-C connector is in an invalid configuration: it's powering VBUS when it shouldn't (that is, unlike USB-A where VBUS is always on, IIRC with USB-C it should only be turned on when the CC pins detect that the other side is either a power sink or an adapter which should source power).

<comment><USER19> Backfeeding power is one of those things that is 'technically' a bad idea, but practically damages pretty much nothing.

<comment><USER20> Another potential issue here is that if using the Pi as a client with a C-C cable this could confuse the device at the other end meaning it wont connect as it thinks it is being charged (will be seeing if I can get this to occur over the weekend).

<comment><USER20> Have just run this test and it does appear to confuse some USB-C ports (my phone and 3.0 usb-C port on my laptop detect the pi gadget however the 3.1 usb-C port doesn't detect the gadget if the pi is powered by gpio).

</comment></comment></comment></comment><comment><USER21> TIL; there are different types of USB-C cables with functional differences.

How do you know what type the cable is? Is is possible to detect it visually?

<comment><USER9> The USB-C ecosystem is quite a mess. Most cables are either limited functionality, or not up to spec that they advertise. Frying your devices with nonstandard chargers or cables is easily possible.

You can't tell them apart visually, and you can't always trust the specs promised on Amazon either.

There are testing tools like [https://www.tindie.com/products/aroerina2/usb- cable-checker/](https://www.tindie.com/products/aroerina2/usb-cable-checker/)

There was a Google engineer (Bensen Leung) who bought, tested and reviewed all the cables he could find, but with the shutdown of Google+ the archive seems to be lost.

<comment><USER22> Bensen Leung is also the author of this blog post

<comment><USER23> Benson's medium post refers to a discovery by Tyler (aka scorpia)

Edit: original link: [https://firstname.lastname@example.com/how-to-design-a-proper- usb-...](https://email@example.com/how-to-design-a-proper-usb-c-power- sink-hint-not-the-way-raspberry-pi-4-did-it-f470d7a5910)

</comment></comment></comment></comment><comment><USER24> How does the HN system work when I submitted the exact same URL [https://news.ycombinator.com/item?id=20317687](https://news.ycombinator.com/item?id=20317687) five days ago??? We have stickied this on the usbchardware subreddit as well at the time, it's still on the top: [https://www.reddit.com/r/UsbCHardware/](https://www.reddit.com/r/UsbCHardware/) We have a nice wiki and if you are still confused about USB C, ask away, we try to help (chances are, I will answer :) ). You will also find a wonderful cornucopia of interesting USB C devices -- not just the usual chargers, power banks and docks but also a toothbrush, a razor, headphones, speakers, video lights, a soldering iron... we _like_ USB C :)

<comment><USER25> Just guessing the person that submitted later has significantly more karma or popularity. It seems to happen quite a bit. There's also time of day to consider, it's possible this made it in when more people are browsing by newest and upvoted pretty early.

<comment><USER24> The question rather is, why would the system allow the same URL to be submitted twice. In the past when I tried to submit something already in, I was redirected to the existing post and my submissions was converted into an upvote.

<comment><USER26> You get redirected to an existing post if it has already had significant attention or is less than 8 hours old. Otherwise reposts go through.

<comment><USER24> Why don't you just bump the post to newest if someone attempted to resubmit it?

<comment><USER26> I don't understand what you mean exactly.

<comment><USER24> Let's presume [http://example.com](http://example.com) was never submitted. So, when it is submitted, it is on the top of [https://news.ycombinator.com/newest](https://news.ycombinator.com/newest) but it doesn't get much attention.

Now let's resubmit [http://example.com](http://example.com) a few days later. It should be on top of [https://news.ycombinator.com/newest](https://news.ycombinator.com/newest) again. But not as a new post. No, the first submission should be moved up here.

Obviously after some time / amount of comments this makes no sense, people resubmit years old links etc but thresholds can be set.

<comment><USER26> Thanks, I see what you mean now.

If we did that then /newest would no longer be a simple chronological log of everything posted to HN.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> The Raspberry Pi foundation has their own "official" USB-C power adapter as well (At least, they have it for pre-order). So I doubt it's the highest priority.

I can still see this getting fixed in a future revision, but I think it will be a while. It is an issue, but it doesn't make the pi 4 useless.

<comment><USER28> This is going to be a really sticky issue for a consumer. Randomly not working with some subset of USB-C cables is the sort of thing you expect the engineering team to consider - and they missed it. How do you think the average enthusiast is going to figure out that their Pi4 no longer works because of the USB-C cable they're using? At best they'll decide the cable is faulty, use a different cable and probably bin the old one, at worst they'll just come to the conclusion the Pi is bricked and bin it.

<comment><USER29> _How do you think the average enthusiast is going to figure out that their Pi4 no longer works because of the USB-C cable they 're using?_

Presumably they're going to search for _pi 4 does not power on_ and get their answer as the first search result[1]. You know, the same way the average enthusiast figures out the other twenty seven roadblocks they stumble on during their RPi project.

Not to minimize that it'll be an issue for those people who don't happen to have a compatible charger laying around.

[1] For me, at the time of posting: [https://hackaday.com/2019/06/28/power-to- the-pi-4-some-charg...](https://hackaday.com/2019/06/28/power-to-the- pi-4-some-chargers-may-not-make-the-grade/)

</comment></comment></comment><comment><USER30> Curious what led to this decision. Reference schematics exist for a reason... It seems odd to not use them.

<comment><USER31> That's what I was thinking. I've recently gotten into hardware design myself as part of a hobby, and this is something I learned early on.

I'm sure they had good reasons to deviate from the reference (I assume they are experienced hardware designers over there), but I'd be very curious as to what those reasons were.

<comment><USER30> Considering the heavy emphasis on budget, it could very well have been on reduced cost. Is a single resistor expensive? No but each decision adds up and it may just be ingrained in the team's ethos.

Many times if we push something too hard, we apply the rule without questioning whether it truly makes sense in a particular situation.

<comment><USER32> In this case they directly shorted two pins together though. That would give me pause to ask why the two pins existed in the first place. Something that should have led to the conclusion the author reached about the configuration.

<comment><USER8>
      That would give me pause to
      ask why the two pins existed
      in the first place.

Bear in mind, the USB-C connector is designed to be rotationally symmetric - so you'll start your layout by paralleling up the four ground pins, and the four bus power pins, and the two pins for USB 2.0 negative and the two for USB 2.0 positive.

I can understand why it might get overlooked, when someone has paralleled up 12 pins in the last 5 minutes...

<comment><USER32> I can see now how one might end up in the position, still the spec schematic clearly shows two separate resistors. Curious either way :|

</comment></comment></comment></comment></comment></comment><comment><USER33> I would not be surprised if this is the default in the bcm2711 documentation and they simply took that as guidance.

</comment><comment><USER34> So the take-away for consumers is...what exactly? Don't use certain types of cables to power a RaspberryPi 4? And how does one identify a cable that could cause problems?

<comment><USER35> My personal take-away is "hold off on buying a Pi4 until this issue has been addressed in a future revision".

<comment><USER36> My takeaway is "use the official $8 charger they sell".

<comment><USER37> I'd agree (and that's what I did) except here I'd suggest "maybe wait until they solve the core overheating issue".

Mine is idling at 64°C now that I took off the official cover; with the cover on, it was idling just below the CPU throttling point of 80°C, which meant that almost any computation caused it to start intermittently locking up.

<comment><USER38> Odd, mine is idling at 49 C in a 21 C room. This is the 4G version running fully updated Raspbian without the desktop (one of the updates fixed the USB controller using a lot of power at idle).

<comment><USER37> Mine is 4G too; I installed heatsinks on it couple hours ago and it now sits at 61°C idle, with an external HDD attached (but not under I/O load) to USB 3 port. Slightly better, though arguably still ridiculously high.

</comment></comment></comment></comment></comment></comment><comment><USER39> I read it but I have no idea what it meant. I am very interested in getting a Pi4, so can some of you more knowledgeable folks help me understand what this means?

<comment><USER40> The Pi4 does not work with all USB-C chargers. You may be lucky and it will work, or you may be unlucky and it will not work and you will have to buy another USB-C charger (which again may not work).

The reason is that the developers of the Pi4 made a mistake while designing the electronic circuit. They tried to design it themselves instead of copying it from the specification.

<comment><USER41> The other reason for is that the developers of the USB-C specifications left us with a terrible confusing mess where visually identical cables have different capabilities and behaviors.

<comment><USER42> If it's confusing, just don't use it. They could have stuck with a micro-B charger, or a custom charger, and no one would have questioned it. Instead, they decided they were confident enough in their understanding of USB-C to implement it on their device. And they were wrong.

<comment><USER43> >They could have stuck with a micro-B charger

Somebody here said they were running into the maximum rated current for the port

>or a custom charger

Literally everyone would have complained

<comment><USER25> I don't think anyone would complain much if they supported a popular barrel connector with a popular power draw. As it stands, I'll only ever use a Pi with a charger sold as working with it after all the 3B+ issues I had (7 chargers, none worked without a warning on screen).

</comment></comment></comment></comment></comment></comment><comment><USER44> Had to fire up Eagle quick and take a look at my latest design (first time using USB-C). Looks like I got lucky this time.

</comment><comment><USER45> Wow, this is really bad.

I have enough USB-C incompatibility in my life to make this the issue that makes me not order the Raspberry 4 until this issue is sorted out.

<comment><USER46> Can you list examples where it hasnt worked?

I support a USB system and I this was my worry since day 1.

Curious, and it would be helpful

<comment><USER45> The usual fare of Dongle Incompatibility, we have a Dell USB-C Dongle that won't provide display outputs to anything that's not a specific Latitude Model, we have quite a few HP Notebooks that won't properly charge with standard USB-C Chargers (even Apple ones), then there's the USB-C Audio Adaptor issue where some phones output analog audio via USB-C and others need an active adaptor with a DAC, which look physically identical...

The Standard, if you fully embrace it, is a mess.

</comment></comment></comment><comment><USER47> Usb PD + type C is hard. You have to read specs for days just to get a basic idea of the logic governing the negotiation protocol.

I'm waiting for a single chip solution that will take upon the pain of dealing with Type-C for me.

Besides the complexity of the spec itself, another "landmine" in dealing with Type C + PD is the divergence of different PD implementations, proprietary extensions from big brands, and... DRMed power supplies along with devices with DRMed PD devices... Yes, the electricity is now copyrighted too.

<comment><USER48> Common misconception: USB Power Delivery is not what the RPi4 is doing. The base Type-C spec provides the schematic for analog signaling of either a 5V/1.5A or 5V/3A state. USB-PD uses a much more complex digital signaling method across the CC lines, and is its own separate spec.

<comment><USER47> Yes, it is not a PD. I am talking specifically about the case of doing USB fast charging aka USB PD, which is much, much more complex

<comment><USER48> The entire USB power situation is complex. Lets see, there's pre-enumeration classic 5V/100mA, post-enumeration 5V/500mA, a host of proprietary signaling methods for additional power, the more or less de-facto BC 1.2 method for extra power, Type-C analog signaling for 5V/1.5A or 5V/3A power, and USB-PD digital signaling. Oh, and there's also Type-C VCONN power in addition to VBUS power.

The irony in all this is that Type-C analog signaling was meant to greatly simplify the market situation and UX well above and beyond what happened in the micro-B charger world. And it _is_ simpler. RPi4 just goofed in their implementation.

</comment></comment></comment></comment><comment><USER49> There's a project management lesson here.

Raspberry Pi 4 was planned for 2020, but the Broadcom SOC went final much sooner than expected, so they shipped the Pi 4 this year.

This sounds like a great thing, but the earlier release meant that the board as a whole spent less time being used internally before release, and they didn't have the time to shake out bugs like this.

The lesson: when you move to a faster release cadence, you need to be more rigorous about QA because you have less time to find problems before release.

</comment><comment><USER50> Odroid, Latte Panda, Pine, and others went with dedicated tried and true barrel jacks.

I appreciate re-using the same microusb cables and chargers for my iPhone and headset charger for my Pi3, and not having to handle Yet Another Wall Wart, but barrel jacks would have sidestepped this whole issue.

Were they hoping to have users use a single cable deliver power and data over a single cable usb just like a pi zero w? [https://desertbot.io/blog/ssh-into- pi-zero-over-usb](https://desertbot.io/blog/ssh-into-pi-zero-over-usb)

God DAMN I hope this doesn't turn into a recall.

<comment><USER51> Why would this turn into a recall? AFAIU, this is just an inconvenience, not a show-stopper since it only affects high-end cables.

</comment></comment><comment><USER52> The Pi people are good folk - all that is needed is to run the USB 3 conformance tests and report back the results (both as USB PD sink and source). Better to know the knowns than have a enthusiastic fan base find them and we get into discussions like this!

I'd also recommend they put up a compatibility table of power supplies on their website in time - probably cables as well! Its a good opportunity to collaborate with the Google engineer who has been spending his non-core hours on the USB-C madness.

</comment><comment><USER53> > The short summary is that bad things (no charging) happens if the CC1 and > CC2 pins are shorted together anywhere in a USB-C system that is not an > audio accessory.

Why should it matter what kind of accessory it is used in?

> Each CC gets its own distinct Rd (5.1 kΩ), and it is important that they are > distinct.

Why?

I think this article was not written by an electrical engineer. The reason why this design is inadequate still eludes me. But, RPi should have probably used the reference design, that's clear.

<comment><USER54> > Why should it matter what kind of accessory it is used in?

I suspect you're misunderstanding what they mean by "audio accessory". They don't mean "a standard digital USB device that happens to do audio-related things". USB-C has a special-case allowance to drive analog audio signals through the port (to allow all-analog headphones and such) that has its own CC configuration.

>> Each CC gets its own distinct Rd (5.1 kΩ), and it is important that they are distinct. > Why?

Because of the above; if the CCs use the same Rd, they're shorted together by definition, which isn't allowed to happen. Especially since the USB-C format uses the CC's to determine plug orientation.

<comment><USER55> >USB-C has a special-case allowance to drive analog audio signals through the port

Wat. Just when I think I've heard it all...

<comment><USER56> You've seen the Type C - 3.5mm headphone dongles right? They're so tiny and cheap.. did you think they could be active? :)

</comment></comment></comment></comment><comment><USER57> I just wish I could find a 4GB Pi 4 in stock/for sale so that I could even have this problem.

<comment><USER58> I ordered one yesterday from the Pi Hut here in the UK. It shipped today...

</comment></comment><comment><USER59> Pretty unfortunate design flaw, and hopefully it can be corrected, but this post is horribly finger-pointy and the tone generally stinks. Would hate to make a mistake while working around this guy

Can the link be changed to the apparent source article? It's not as bad. [https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with- so...](https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some- chargers-or-why-you-need-two-cc-resistors/)

<comment><USER30> Seriously. Considering what a cluster the spec is and the budgetary goals for a project like the Pi, this feels really harsh. The focus is on the mistake and how trivial it was without any thought of why or how.

Pointing out mistakes can be done without being such a jerk about it.

<comment><USER60> They spend months if not years on the design and crank out millions. Getting USB-C right seems like a no-brainer!

<comment><USER30> I highly doubt they spent years on the design... But regardless we all make mistakes.

What is a no brainer to you may not be to everyone.

Besides, you are fundamentally assuming this was a mistake and not a deliberate design decision. Maybe they prioritized X over following the spec 100%. I may not make that decision, but that doesn't mean they didn't.

</comment></comment></comment></comment><comment><USER61> Says more about the quality of no-name usb wotsits

</comment><comment><USER62> Everything works for me except my Apple charger. I blame Apple.

<comment><USER63> Apple followed the specification, the Pi 4 does not. How is this Apple's fault?</comment></comment>


Petition to End Daylight Savings Time in the UK - <AUTHOR> https://petition.parliament.uk/petitions/300931 <comment><USER2> This petition [any petition] is more likely to gain support if you give people a reason WHY you're calling for whatever it is.</comment>


How to communicate your value without selling out - <AUTHOR> https://www.fastcompany.com/90385831/you-are-not-a-brand <comment><USER2> "The idea of "personal brand" sounds phony because it is. Brands are carefully contrived; they are not real. Brands are flat, soulless, and artificial "personalities" designed to convince others that the brand is something it is not." Good point.

Sounds like the author is getting to what some philosophers would call Essence. For some this Essence would include a judgment of thecAuthenticity of their being.</comment>


Study Finds a Way to Prevent Fires in Next-Generation Lithium Batteries - <AUTHOR> https://www6.slac.stanford.edu/news/2015-06-17-study-finds-way-prevent-fires-next-generation-lithium-batteries.aspx

<comment><AUTHOR> This seems like a really big deal. Two important quotes:

 _The findings [...] could help remove a major barrier to developing lithium- sulfur and lithium-air batteries, promising future technologies that could store up to 10 times more energy per weight than batteries now used in consumer electronics and electric cars_

 _In tests, batteries with both chemicals added operated at 99 percent efficiency after more than 300 charge-discharge cycles, compared to significantly decreased efficiency after 150 cycles for batteries treated with lithium nitrate alone_

<comment><USER2> I wonder if Tesla's patents helped with this. If not, I look forward to when someone takes both innovations and creates something world changing like enduring and safe batteries.

</comment></comment><comment><USER3> Good for mobile applications. For fixed location (eg. renewable energy for off-grid housing) I'm still keen to see the performance of Velkess flywheels: [https://www.kickstarter.com/projects/1340066560/velkess- ener...](https://www.kickstarter.com/projects/1340066560/velkess-energy- storage) which, being kinetic and held in vacuum, nominally don't wear out for a very long time and provide other benefits (reduce losses due to AC/DC conversion).

<comment><USER4> Interesting web site, (velkess) but I worry about the lack of actual information. The "A" version ([http://www.velkess.com/products/#VelkessA](http://www.velkess.com/products/#VelkessA)) for example, 750 lbs, 15kwH seems like it would have to be spinning quite rapidly in order to avoid provide that energy, and making bearings that can carry that load and work reliably is pretty tough. I look forward to reading reviews of their products though, flywheel type systems have been successfully deployed in many places, one at this price point would make for an interesting midpoint between grid tied and full off grid solar.

<comment><USER3> I'm no civil engineer but the info on their kickstarter is more engineering- oriented. I don't vouch for them, I just think they seem pretty legit and interesting. Obviously, the "it can't move" and "it's damn heavy" factors make it useless for the majority of applications, but for off-grid renewable energy purposes it does seem ideal.

<comment><USER4> Oh absolutely, we had what it nominally referred to as a 'motor-generator' set in the basement of the building where I worked to provide backup power for the machine room. It worked by using regular AC power to spin a flywheel which was then spinning a generator through a continuously variable transmission (CVT). If the power failed, and you did your math right [1], the flywheel's momentum would continue to keep the generator going for another couple of seconds before power actually shut off. During those two seconds though the computers would know that power was "off" and to do the appropriate things to be ready for that (like park the heads on the drives, unload vacuum column tape drives, shutdown the drum, etc etc.) All stuff you could do in 100 - 250mS which saved a lot of work later on.

The engineering challenges though were size (it ended up being this horizontal thing that filled the room). Keeping it sealed with a vacuum (if there was air in the flywheel chamber it adds drag to the wheel which robs you of energy), and dealing with its very strong desire to precess if the ground moved in any way. The engineer responsible for its installation suggested that if there was 6" of ground movement in an earth quake the gyroscope effect would wrench the flywheel off its mount and it would rapidly climb out of the basement on its own momentum. (something I was secretly desiring to see in action)

[1] The first one they installed they did the calculations incorrectly and when they tested it the flywheel stopped in just under 10mS with a very loud bang. Fortunately you can boost energy storage by increasing mass and/or increasing RPM which they did (both off) and got it to a sustain duration of 1800mS (not quite 2 seconds worst case)</comment></comment></comment></comment>