WebGPU Shading Language - <AUTHOR> https://gpuweb.github.io/gpuweb/wgsl.html <comment><USER2> Kudos to Google for moving this along! A few weeks, the HN community picked up [0, 1] on a presentation [2] about the Tint shading language, a WebGPU shading language prototype. It's great to see them formalize their prototype into a draft spec.

Thank you to those who are working hard on bringing WebGPU to the masses!

[0]: [https://news.ycombinator.com/item?id=22316777](https://news.ycombinator.com/item?id=22316777) [1]: [https://news.ycombinator.com/item?id=22351285](https://news.ycombinator.com/item?id=22351285) [2]: [https://docs.google.com/presentation/d/1qHhFq0GJtY_59rNjpiHU...](https://docs.google.com/presentation/d/1qHhFq0GJtY_59rNjpiHU --JW4bW4Ji3zWei-gM6cabs/edit)

</comment><comment><AUTHOR> Some context: browser vendors are working on a successor to WebGL, and there's been a debate over what shading language to use.

A text based language would be easier for beginners (since they wouldn't need to install a separate shader compiler) and would avoid sites that need dynamic shaders having to download and run a shader compiler in the browser.

Using SPIR-V bytecode would benefit from a large amount of work put into an existing standard and an open source compiler ecosystem that many companies are already using.

It looks like a decision has been made to accept a text based language, but one that is defined based on SPIR-V semantics and is easily convertible back and forth from SPIR-V. This seems like a great trade off since if it works out it should have the main advantages of both approaches.

<comment><USER3> Thanks for posting ;)

Just curious if anyone has actually gotten the WebGPU bits to run? Getting a device context, executing commands. Currently on CrOS. Able to install vulkan, rust-wasm, and wgpu. But then I just get initialization errors. WebGL 2.0 Compute works when enabled in Chrome 79. My interest is in creating web gpu grids for scientific computing</comment></comment>


Web apps web apps web apps every body doing web apps whats about real apps - <AUTHOR>

Hi
i just read every body doing web apps (including HN ) did people stop doing some real applications or they just stop publish them for example: 3d , distributing servers ,batch servers ,Games (not flash or text ) desktop stuff,security and so on ... <comment><USER3> They're still there, but not a very hot topic.

For new concepts, the web is a much more attractive platform - <USER2> development, fewer (but not no) compatibility issues between platforms, etc.

<comment><AUTHOR> yeah i know all that , but this is boring .. well starting to be boring. who is doing c++ application here ?</comment></comment>


I had to remove ES File Explorer because it's carrying malware - <AUTHOR> https://plus.google.com/+PeterdaSilva/posts/EV8tY6bEaSJ <comment><AUTHOR> Internet (and Usenet) old-timer Peter da Silva 1) seeking a featureful file manager for Android due to 2) malware inclusion of his current choice.

The problems of Android are another element of this. Despite a huge promise, Android consistently over-hypes and under-delivers on hardware, OS, security, privacy, and most especially, an overtly user-hostile application ecosystem.

Google need to think long and hard what they want Android to be, and how to make it that.

<comment><USER2> Google doesn't need to do anything. No matter how bad Android gets, you and the general public will lap it up. Where else are you going to go? More on topic I use the File Manager application that came with CyanogenMod. It seems pretty simple, I don't know if it meets your needs or is malware free. These days I assume everything on Android is some form of spyware or malware and so I don't keep any financial or similarly sensitive information on it.

<comment><AUTHOR> Apple, Amazon, Ubuntu, and Mozilla are three alternatives to Google either presently or in the not too distant future (there's also Microsoft though they've got their own issues).

I don't know that any will succeed, but I suspect one or the other eventually will.

Android as it stands sucks. Badly.

I know. I'm typing this on it.

</comment></comment></comment><comment><USER3> This just happened to me this morning! They've added a "lock screen override" with ads.

Proper interruptive & misleading model tricks you into turning it on ("you just plugged in your phone, enable rapid charger?")

Honestly I knew the very second AFTER I clicked a rapid OK that I'd probably done something wrong.

Wasn't too hard to fix, but man, is that ever scammy.

Wasn't hard to find out it was coming from ES file explorer.</comment>


Windshield Cracks Hold Secrets of Impact - <AUTHOR> http://physics.aps.org/articles/v6/48?referer=rss <comment><USER2> What cracks me up about whindshield damage is that _every_ time I get a new car within 2 days or so I get a stone on the windshield chipping my otherwise perfect view. I always get it fixed but you can't help but notice the repair (especially at night they can be quite annoying).

Of course, after the initial maiden impact nothing else will ever happen for the duration of the ownership of the car.

This is probably somehow related to Murphy's law. The secret to these impacts seems to be that I'm behind the wheel and on any highway at all. I've contemplated not driving the car for 2 weeks after buying but I'd hate to admit that I'm getting superstitious about this.

<comment><USER3> I feel your pain. I had a new-ish car I was taking on its first road trip, about 4000 kms into the middle of Australia and back. Ten kilometres out of Melbourne, and a car coming the other way threw up a small stone which hit the windscreen and caused a six inch crack almost right in the centre of my field of view. I had to put up with that crack for the next 3990 kms and three weeks. Aargh!

</comment></comment><comment><USER4> They have videos showing the regular structure of cracks in Plexiglas (4 cracks and 8 cracks), and a photo of many cracks appearing in what may be automotive glass.

The thing that struck me (no pun intended) is that Plexiglas is a polymer and thus has a more-or-less regular repeating internal structure, while glass is amorphous, with little internal structure. So comparing the crack structure between them after similar impacts probably wouldn't give you the same information about the energy input. Which might be the point, but it appears they're comparing apples & oranges, so lessons learned in glass vs. lessons learned with polymers wouldn't be transferable.

Also - automobile windshield glass is laminated (to prevent shards of broken glass flying around the inside of your car), and there are different materials used for the laminating plastic & adhesive, depending on the "recipe" chosen by the manufacturer. So the crack structure would be different between them, and again, I doubt the lessons are transferable.

<comment><USER5> If you read the article, you'd know that they tested both Plexiglas and automotive glass. The scaling relationship that they found experimentally between speed of impact and number of cracks they then verified theoretically.

Different specific windshield designs will, of course, vary. But this is a good starting point across designs.

<comment><USER4> My point is that it _isn't_ a good starting point across designs, because the designs vary so much as to make their formula inapplicable in the general case.

Now, if they said that their formula was consistent within a certain class of materials & construction, I'd buy it. But even then with the Plexiglas, their formula predicted 7 cracks, while the experiment produced 8. They need to explain that, and I'm saying it's because of the near-crystalline internal structure of Plexiglas. If they had altered their hypothesis & and prediction, and then retested, and did some analysis to explain it (perhaps I'm wrong - maybe its because of some other factor and not the internal structure) I'd buy it.

<comment><USER5> It is a scaling rule for a statistical phenomena, not an exact formula. For different kinds of surfaces, you'll have a different constant.

Getting 7 cracks versus 8 in the experiment is actually a pretty good fit. Particularly since repeating the experiment multiple times would be unlikely to give the exact same number of cracks. (The cracking pattern does have a lot of randomness in it.)

What is more important is that if the sqrt scaling rule proves reasonably consistent across a wide variety of types of materials, then testing the cracking pattern for different kinds of impacts across different kinds of windshields becomes a much more tractable problem.

The obvious followup becomes how angle of impact matters. My hope would be that it is something reasonably simple - such as very little is deposited by friction, so it is only the component of the velocity normal to the surface that matters.

Establish those two things reasonably well, and now you're in a good position to measure every kind of windshield a handful of times, and you have some useful information for forensics on all kinds of windshield cracks.

</comment></comment></comment></comment><comment><USER6> Public service announcement: if you have a crack in your windshield that is smaller than a U.S. dollar then it likely can be repaired. If it can be repaired, most insurance companies in the U.S. will waive your comprehensive deductible. That's right - the glass company will either direct bill the insurance company or the insurance company will reimburse you. Either way, if your insurance company is like most it will not cost you anything to have it repaired.

Another fun fact is that any day you have a small chip or crack, it can instantly turn into a huge crack that is unrepairable. So if you have a small chip or crack get it repaired right away. Check with your insurance company - it will probably cost you nothing.

<comment><USER7> Also, if you live in Florida, Kentucky, Massachusetts, or South Carolina and have comprehensive insurance, there is no deductible for a windshield replacement.</comment></comment>


Show HN: Time, Track and Log CPR Events - <AUTHOR> https://itunes.apple.com/us/app/code-runner-pro/id1318832552?mt=8 <comment><AUTHOR> Code Runner Pro let's healthcare professionals time, track and log data during CPR. It also includes a metronome for chest compressions.</comment>


Researchers quantum teleport particle of light six kilometres - <AUTHOR> http://sciencebulletin.org/archives/5445.html <comment><USER2> Not quite as impressive when you know, and if you don't you should before opening this link, that "quantum teleportation" is not teleportation. It was a cool-sounding name at the time, but has nothing to do with sci-fi style teleportation: nothing disappears from one place and then shows up in another.

"Quantum teleportation" is a process of information duplication using particles that already exist, and have been positioned such that there is enough distance between them that we can rule out direct interaction between them (that we know of given the current state of physics). Quantum teleportation is the process by which we then manipulate only the particles on one side of the distance divide, such that particles on the other side "end up" reflecting the same state that the ones we manipulated were.

Although "ending up" is probably the wrong term, because we use particles in special states of which we already know they're entangled, then split them up (which does not cancel entanglement) and then we make use of their entanglement property: running an algorithm involving particles on one side should yield the exact same result as running the same algorithm on the other side, so a much more interesting algorithm is one that you run on one side in one way, and on the other in a different way, to effect a "data copy" without ever actually copying data (and very much without any kind of teleportation. The fact that you run your process with "the same particle" is the special part. Being able to even have two particles that are literally the same is a pretty bizarre bit of physics)

<comment><USER3> At the subatomic level, is there any real difference between information and a "thing"? Seems mostly philosophical and arbitrary at that point.

<comment><USER4> I think what you are really asking is: _what is the substantial reality of 'the thing', if it is merely 'information'_.

All following quotes are from the documentary "Atomic Physics and Reality" [1 - 'emphasis' mine.].

John Wheeler:

        Einstein admired Bohr and Bohr admired Einstein. And you
        recall that Einstein felt that 'reality' exists, in effect,
        'out there', something independent of us. And the position
        of Bohr was rather this: that 'reality' is only a word and
        we have to learn what the right way is to use that word.

John Bell:

        Bohr, I think, quite in early in life had decided that
        ordinary concepts such as space and time simply wouldn't work
        at the atomic scale. And it was always a bit unclear what
        Bohr would replace those concepts by, if anything. But
        Einstein was very attached to the space-time description, and
        thought that one should try very hard to extend it into the
        atomic domain.

        And this was the root of the disagreement between the two men.

David Bohm:

        Bohr had developed a view in which he essentially would say
        that 'reality' was unknown or unknowable, or even had no
        meaning, 'reality' by itself. Reality, except at the large
        scale level of ordinary experience, atomic reality had no
        meaning, and all that we have are 'phenomena', produced in
        an 'experiment', and that quantum theory deals with the inter-
        relationships of all these phenomena.

Abner Shimony:

        Bohr was not a professional philosopher. How much of the
        traditional philosophers he read, one does not know. But
        he was an extremely intelligent man and he must have thought
        through some of the issues that professional philosophers had
        thought through very deeply. And certainly one of the issues
        that he had though through considerably, with some help I
        think from reading, was the Kantian issue of the status of
        'the thing in itself'. The 'thing' as it really is, quite
        apart from Human 'perception' of it.

        Bohr, like Kant, was very suspicious that one can say anything
        significant, intelligent, controllable, about 'the thing in
        itself'. [Bohr] once said that physics or science in general
        was not about 'nature' but about nature exposed to our
        'observation'. And that is very Kantian.

\--

[1]: [https://youtu.be/BFvJOZ51tmc](https://youtu.be/BFvJOZ51tmc)

<comment><USER3> Actually, I find it very intuitive that reality is just information. It's much easier than setting it apart as ineffable.

<comment><USER4> That's not what Bohr said. He said we _can 't know_ \-- per Bell "have no right to know" \-- what is "[objective] reality" [at the atomic scale].

I am personally not comfortable with using 'information'. I think Bohm's formulation "phenomena" is more appropriate. Note that, for example, the manifestation of wave/particle duality is an actual _physical phenomena_. The 'information' bit is our _observation_ of this phenomena.

And in case the question is still on the table as to _are these distinctions merely a matter of philosophical taste or aesthetics?_ , from same source cited:

Alain Aspect

       At the time of Einstein and Bohr it was just a theoretical
       discussion. You could endorse either Einstein's position or
       Bohr's position, and it was just a matter of taste.

       And then there was the great discovery by John Bell in '65 that
       it is not only a matter of taste, because according to the
       position you have at the subatomic point, you have predictions
       which are not the same.

       If you follow Einstein you have a certain type of predictions
       -- that is to say you have results that are in agreement with
       what is called the Bell's inequalities -- and if you follow
       Bohr's position you have another type of prediction which are
       in contradiction, in opposition, with Bell's inequalities.

Aspect at this point had conducted a series of EPR experiments that _proved_ that the Einstein line of reasoning was in contradiction with the obtained experimental results.

<comment><USER3> Well, I'd put "can't know" squarely in the ineffable.

But yes, I think phenomena are the atomic building blocks of science. The logical positivists at least got that right.

<comment><USER5> _> I think phenomena are the atomic building blocks of science _

Lacking context, this could seem somewhat opaque.

Would you mind clarifying which definition of "phenomenon" you are intending to convey? (eg Kantian or otherwise)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I posted this in a duplicate thread:

For those thinking that this is a step towards faster-than-light (FTL) communication: As far as I know it's fairly certain that quantum entanglement will not allow for FTL communication. Basic principle is that while measurements between both sides will be correlated, it's not possible to tell _how_ they are correlated until both sides compare measurements.

[https://en.wikipedia.org/wiki/Superluminal_communication#Qua...](https://en.wikipedia.org/wiki/Superluminal_communication#Quantum_nonlocality)

[http://physics.stackexchange.com/a/203893](http://physics.stackexchange.com/a/203893)

Given that, it seems like the touted benefit of using quantum entanglement here is in securing communications, since your measurements will no longer correlate if a third party is also measuring? At least, that's what I gathered.

<comment><USER7> Is "measurement" or "observation" a simplified term for a complex process? It can't be as simple as a human "looking" at something since there's nothing special about humans (that I know of). I really wish I had the time and capability to understood how quantum entanglement really works. It seems a lot like magic if you take the layman explanations at face value.

<comment><USER8> More people-oriented answers: [http://physics.stackexchange.com/questions/3158](http://physics.stackexchange.com/questions/3158)

Shortest answer to that question: [http://physics.stackexchange.com/a/3162](http://physics.stackexchange.com/a/3162)

>Imagine at home you put one glove in your coat without looking (and noticing it's only one of the two). After exiting the train you notice it's cold and you pull out that single glove. At this very instant you know it's either the left or the right glove, and you therefore know which one is left at home. However, no information was transmitted by your "measurement". Of course in quantum mechanics this is more complicated because of the not entirely measurable wave function, but this is the basic idea.

<comment><USER9> There are a lot of (justified) comments on that answer. A crucial point of quantum uncertainty is that it's different from classical intuition. Particles behave like waves (e.g. cause interference with themselves) until observed. That doesn't happen with the glove.

<comment><USER10> The essence of the answer is that correlation doesn't imply causation (true).

The essence of the comment is that the correlation in a quantum case may be stronger than in a classical case such as the case with gloves (also true).

The comment doesn't invalidate the answer unless you think it does imply causation (non-locality). It just says that the answer is not the whole truth: that would be the complete mathematical description of QT with corresponding procedures to connect the math with observations.

The glove analogy obviously has its limits. It doesn't make it wrong. Otherwise, the accepted quantum theory is also wrong because it doesn't describe all known phenomena (consider gravity).

> "Particles behave like wave until observed"

Consider photon: it is neither wave nor particle in a classical sense. The math is such that in some cases it is easier to describe it as wave (interference pattern), in others—as particle (photoelectric effect).

It is surprising that the familiar concepts from a human scale (such as wave, particle) are useful in such a wide range of physical phenomena. Though only because they are more familiar does not make them more real than e.g., the concepts produced by the equations of the quantum theory.

All models are wrong—some are useful. (In a sense that there is no territory under a map, only more complete or different maps)

</comment></comment></comment></comment></comment><comment><USER11> >> Researchers teleport particle of light six kilometres

I'm sure they did nothing of the sort. At best they transferred an unknown state of a photon to another photon six kilometers away, then confirmed via measuring both.

<comment><USER12> Not so fast.

There is a good reason to call it quantum teleportation and not quantum facsimile.

When you move matter from one place to another it moves, it's not copied. When move classical information (or state) , you can retain the original or multiply it many times.

Quantum teleport demonstrates interesing aspects of quantum information that makes it work like material thing. When information (quantum state) moves, it can't be copied (no-cloning theorem). You lose the original from the sending end just as you would lose a physical object you send to other place.

Quantum theorems like no-hiding theorem, no-deleting theorem, no-cloning theorem makes quantum information act more like material substance than classical information.

There is no physical of philosophical argument differentiate between "real" teleportation and "just moving state".

<comment><USER13> It does not work as material thing that is teleported. When you make measurement quantum function collapses and something that we don't know is happening and it's not teleporting anything because state is changed faster than speed of light, and no information or material can travel faster than that. This is a known paradox. Anton Zeilinger (father of quantum entanglement) is describing this in his books in more detail.

<comment><USER12> Why the assumption that teleportation means faster than light travel?

<comment><USER13> Because Anton Zeilinger has proven in his experiments that "teleportation" can happen faster than speed of light. It's what Einstein said was "spooky" about "quantum teleportation" that it contradicts theory of relativity.

<comment><USER12> Information in teleportation can't travel faster than light. Teleportation is not finished until data is transmitted at light speed.

</comment></comment></comment></comment></comment></comment><comment><USER14> Just to give a concept of how difficult this is:

> "The challenge was to keep the photons' arrival time synchronized to within > 10 pico-seconds,"

> "Since these detectors only work at temperatures less than one degree above > absolute zero the equipment also included a compact cryostat," said Tittel.

The dark fiber seems like it was important for synchronizing the clocks. And while they claim this could be used for encryption keys, that is really a roundabout way of saying that very little information was actually transmitted/received, although the article doesn't say exactly how little.

If this technology was refined, you'd just use this system to send secure messages without the need for an encryption key.

<comment><USER6> > If this technology was refined, you'd just use this system to send secure > messages without the need for an encryption key.

As far as I know, I don't think that meshes with what actually happens. This has nothing to do with the message being secure; anyone with all the pieces could read the message.

The important part is, since observation effects quantum state, the receiver can determine whether a third party observed the key. If the key matches, then there's a guarantee that it was not observed, and therefore is safe to use.

</comment></comment><comment><USER15> I had thought that quantum entanglement could not be used for communication because the state that is transmitted is random, and cannot be controlled at either end.

But, there are quotes in this article to the contrary. e.g.:

"Such a network will enable secure communication without having to worry about eavesdropping, and allow distant quantum computers to connect," says Tittel.

Was my understanding mistaken?

<comment> semi-extrinsic I took a quantum optics course once. It's true what you say that entanglement can't be used to communicate (by itself), hence no problems with relativity, speed of light etc. This is known as the No-communication theorem:

[https://en.wikipedia.org/wiki/No- communication_theorem](https://en.wikipedia.org/wiki/No-communication_theorem)

But together with a conventional communications channel (e.g. radio signals), you can use quantum entanglement to create a secure communications channel. This combination is called quantum teleportation (as opposed to just quantum entanglement):

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

<comment><USER16> Right, "Did you get it?" doesn't need to confirm the information transferred

</comment></comment></comment><comment><USER17> I don't think I understand it right.

My understanding is this:

1\. send entangled bits to two separate locations A and B

2\. determine their states (which will always be exactly opposite) on both sides

3\. send data using classical means from A to B, xor'd with the quantum measurements

4\. decrypt the data at B, with: data ^ quantum_measurements ^ 111111 (the last step being "invert all bits and ^ representing xor).

If that's it, how is this much better than sending block of identical entropy to A and B, and using a OTP? Theoretial tamper-proofness?

<comment><USER18> My understanding is that it's snooping-evident, at least in theory. If someone takes a peek at the entangled bits in transit, the entanglement will be broken and when A and B compare notes, their states will no longer be correlated. This is good for key distribution because if someone snoops a key, you know the key is compromised and throw it away.

If you have a secure way to distribute your OTP I'm not sure there'd be a benefit to using quantum teleportation at all.

<comment><USER17> But if you have a secure way of getting your quantum bits to Bob, couldn't you get your OTP there in the same way? I mean, yes, you could detect it if your stream of entangled bits is intercepted while it is going, but you couldn't detect it if it was intercepted from the get go and MITM'd.

<comment><USER19> _> >But if you have a secure way of getting your quantum bits to Bob, couldn't you get your OTP there in the same way?_

No, because you do not choose the information to be verified on either side. You're not choosing a key and "encoding" it into "quantum bits", you're measuring the quantum state of two entangled particles.

If the quantum state matches, you have provably secure transmission. If the transmission were intercepted, the act of intercepting it would cause the measurement verification to fail due to the observer effect. The parties would be able to see that the key was intercepted because the particles were prematurely disentangled.

This is quantum key distribution, which is a subset of (and often misleadingly conflated with) quantum cryptography. It is not possible to use quantum cryptography to send provably secure arbitrary data of your choosing, it's only possible to generate and distribute provably secure keys and use those for classical cryptographic communication.

The reason why it's important to call it quantum key distribution is because it makes it clearer that this only solves one problem in a greater cryptosystem. Key distribution is a significant problem in cryptography, and provably secure key distribution is a great leap forward, but it's not the only problem.

<comment><USER17> Is it possible to know when particles were prematurely untangled? Wouldn't that constitute transmitting information?

How would you tell the difference between a set of qbits entangled with the right other set of qbits, and with a different set of qbits? If an attacker were to intercept the whole stream/set of entangled particles, wouldn't he be able to perform a MITM attack by sending you particles entangled with his particles instead?

The way I mentally model "sending entangled particles and measuring them" is "sending two streams or blocks of exactly inverted random data to two locations, in a format that is impossible to recreate/forge as setting the right spins of particles is not possible". Is it so that this measurement can only be performed once, or can it be measured again later, giving the same results? Does the security of quantum entanglement come from an inability to create entangled particles with specific values, and if so, how does that solve wholesale MITM'ing, were the hole stream is intercepted on the way to one party, and then replaced by a wholy different stream with an attacker- controlled "twin" set/stream?

What I mean is, if one or both streams/sets of entangled particles were intercepted as a whole before arriving at A or B (or replaced before measurement and after arrival), wouldn't that allow for an effective MITM attack? I just find it hard to see how this technology solves the physical access problem.

<comment><USER6> An important part is that no information is actually transmitted through the qubits. Information is only effectively "transferred" when measurements can be correlated. So, you can pass a key through the qubit, but the other side won't know the key until the additional measurement information arrives for correlation.

A third party also viewing the entangled qubit would necessarily modify the measurements also, causing correlation failure. A man-in-the-middle attack would only be effective if they also intercepted the measurement information and replaced it with their own. In which case, yes naturally someone who can intercept all your communication and replace it arbitrarily can arbitrarily control your communication.

As is used today, signing the measurement information would be an effective mechanism for preventing this. The attacker should be unable to correctly sign their own measurement information, and so you will be able to detect that the key transfer is unreliable.

Once the key is reliably transferred, then it's theoretically a secure one- time pad. That is, you know that it was transferred to the party at the other end of the entangled qubit, and that it was not intercepted along the way.

</comment></comment></comment></comment></comment></comment><comment><USER20> There appears to be a great deal of conflation in many of these comments between quantum entanglement and quantum teleportation. Quantum teleportation makes use of entanglement, but is a different thing entirely.

In short, quantum entanglement is an effect that causes two quantum particles to share state instantaneously over arbitrary distances. It can not be used to transmit information faster than the speed of light, essentially because while it is possible to manipulate the particle at one end, it is not possible to arbitrarily set it to a chosen state (and as described fully in the no communication theorem)[1].

Quantum teleportation is a way to transmit _quantum information_ , ie the quantum state of a 'qubit', using both quantum entanglement and a classical communication channel. Because classical communication is required, no faster than light communication is possible. However, quantum teleportation is necessary if you want to transmit quantum information.

To very briefly sum up how it works, you start with a qubit whose state you want to transmit, along with two entangled particles, and a 'receiving' qubit that will receive the state of the sending qubit. Through an interaction between the sending qubit and the entangled particle on the sending side, the quantum state of the entangled particles is set to one of four possibilities. Which of the four possibilities resulted is sent via the classical communication channel from sending to receiving end. The receiving end then uses that information, along with the receiving-end entangled particle, to manipulate the receiving qubit into the identical state as the sending qubit, thereby 'teleporting' that state from sending to receiving end. The Wikipedia article has a more thorough layman's description, as well as the underlying math[2].

Caveat: I'm an engineer, not a physicist, so I may have made a mistake here as well, but the main take-away is that quantum teleportation is not the same thing as quantum entanglement, and its purpose is not FTL communication, but rather communication of quantum states.

[1] [https://en.wikipedia.org/wiki/No- communication_theorem](https://en.wikipedia.org/wiki/No-communication_theorem) [2] [https://en.wikipedia.org/wiki/Quantum_teleportation](https://en.wikipedia.org/wiki/Quantum_teleportation)

</comment><comment><USER21> >> Dark fibre, so named because of its composition — a single optical cable with no electronics or network equipment on the alignment — doesn't interfere with quantum technology

Isn't dark fibre either unlit capacity or leased fibres?

<comment><USER22> It is, but I don't see why it can't have a different meaning for people on a different technical/theoretical area.

</comment></comment><comment><USER23> For anyone interested, there is a great video by the PBS space time channel explaining quantum entanglement here [https://www.youtube.com/watch?v=tafGL02EUOA](https://www.youtube.com/watch?v=tafGL02EUOA)

The thing is, although the quantum state of the photom collapses instantaneously on both entangled photons, we can't manipulate at which state the photon will collapse, and so, we can't really send information using quantum entanglement.

We can't also confirm the entanglement until we can compare both measurement results or else we could send information from the future as in the quantum eraser experiment [https://www.youtube.com/watch?v=2Uzytrooz44](https://www.youtube.com/watch?v=2Uzytrooz44)

Edit: formatting and typos

</comment><comment><USER24> "if you're a photon, you might want to keep reading."

So, i stopped reading :)

<comment><USER25> It's just an if, not an iff ;)

</comment></comment><comment><USER26> Not satisfied with asking me to subscribe to their newsletter before I've even read one article, this site _also_ popped up a request that I allow them to send me desktop notifications. Do people actually fill these things out? Why does ScienceBulletin think I might even want these things?

<comment><USER27> Because obnoxious people will spam the form with emails that are not their own, as malicious behavior against acquaintences they detest.

These ubiquitous subscribe forms provide a vector for inflating the size of mailing lists. Mailing lists with more addresses sell for real money, and sell well.

It doesn't matter if the data is accurate. Only the perception of the data matters. The more addresses the better, the more datapoints per address, the higher the quality of data. The age and activity against the data matters.

There are reputable companies that trade on these details and pay the salaries of expensive developers.

</comment></comment><comment><USER28> Forgive my ignorance as I'm a software engineer and not a physicist. But does this means that in the future FTL communication will be possible. Every time I work with networking one thing always springs to mind. That is that the speed of light is a limiting factor. Will this mean that in the future latency issues will be a thing of the past?

[http://www.stuartcheshire.org/rants/latency.html](http://www.stuartcheshire.org/rants/latency.html)

<comment><USER18> You can't use entanglement to communicate. Quantum teleportation needs a classical channel to work.

> [https://en.wikipedia.org/wiki/No- > communication_theorem](https://en.wikipedia.org/wiki/No- > communication_theorem)

If you have superluminal communication, signals can travel into your subjective past, which means causality pretty much breaks down entirely. There's no theoretical reason why causality has to hold, but it would make life extremely "interesting"

<comment><USER29> There was a webcomic (or something like it) I saw a while ago that was about a single-buttoned gadget that could always predict whether you will press the button or not (don't remember the exact mechanism, but that was the jist). The story then went on about how the gadget would bring about humanity's collective philosophical collapse, because of its implications on the subject of free will.

I imagine that what you're describing about superluminal communication could be used to make a gadget like this.

I'm also wondering if anybody knows which webcomic I'm referring to. It'd be embarrassing if this turned out to be an XKCD number...

<comment><USER18> Sounds like a Ted Chiang story:

[http://www.nature.com/nature/journal/v436/n7047/full/436150a...](http://www.nature.com/nature/journal/v436/n7047/full/436150a.html)

It sounds more like an SMBC comic than an XKCD one, societal collapse for unexpected reasons is an ongoing theme.

</comment></comment></comment></comment><comment><USER30> 10 picoseconds is "one millionth of one millionth of a second"? Damn it, I must have been misunderstanding engineering units all my life.

<comment><USER31> Is it not? [https://en.wikipedia.org/wiki/Picosecond](https://en.wikipedia.org/wiki/Picosecond)

"or one millionth of one millionth of a second"

<comment><USER32> Your link says that one picosecond is one millionth of one millionth of a second.

The article itself says (or at least is written to imply) that ten picoseconds is one millionth of one millionth of a second.

Since ten is not one, one of those two statements (and definitely not ten of those two statements) must be incorrect.

<comment><USER33> I believe Wolfgang Tittel was simply defining a picosecond for the readers of the article.

<comment><USER32> You're probably right. However, the article is written in a way which at the very least heavily implies something else.

>"The challenge was to keep the photons' arrival time synchronized to within 10 pico-seconds," says Tittel. "That is one trillionth, or one millionth of one millionth of a second."

<comment><USER30> Exactly. Which is how I read it. And how anyone would read it, I would think.

</comment></comment></comment></comment></comment></comment><comment><USER34> Awesome. So a quantum network would have the photon act as a data stream, in a way it would act like a physical security key. So with a lot of work, this would be amazing for 1:1 communications. But what if I want to send my dick pick to hundreds of people at once(1:100 distribution)? Is it possible to entangle one photon with multiple?

<comment><USER6> Entanglement may be expanded to groups of particles. Also, I'd like to note that it's not necessarily that the communication is secure, but rather that third-party observation can be detected. That's why the discussion focuses on using this to send keys, and not messages themselves.

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

</comment></comment><comment><USER35> Teleportation is not possible. Quantum teleportation is the transmission of the exact state of a photon from one place to another. Still, even this happens at less than the speed of light. Otherwise it would violate causality.

The media plays fast and loose with terminology either out of plain ignorance or the desire to sell a story.

<comment> ctrl-j > Teleportation is not possible. Quantum teleportation is the transmission of > the exact state of a photon from one place to another. Still, even this > happens at less than the speed of light. Otherwise it would violate > causality.

Maybe I'm remembering my QED special topics class incorrectly, but I thought the state teleportation _is_ believed to be instant. The problem is to extract the state information, the transformation operators still need to be communicated. So you still have to get on the phone to tell your colleague across the planet what to do to see the entangled result. It's been years, so maybe I'm a little off on that?

Causality also isn't a hard-and-fast law. We've just never seen it violated before. It's one of those physics problems that is really hard to find evidence to support or discredit it.

<comment><USER36> So many advancements in physics have been the result of a smart person abandoning some "law".

<comment><USER37> Usually, in the process, discovering a deeper and stronger law.

I understand the temptation to think that every "law" is just waiting to be broken, but I can easily read the same data and come to the opposite conclusion about the strength of our current "laws".

</comment></comment></comment></comment><comment><USER38> Does modifying the state of one entangled particle then destroy the link between them? If it does, then how can you continually communicate without distance being a factor as you'll have to resupply? I hope it doesn't or there is some work around or I simply am completely asking the wrong question.

<comment><USER39> Yes, the observation destroys the entanglement.

The communication does not really happen between the state that is 'teleported' \- you still have to manually send the photons 6km or whatever. But - very crudely - you can pass information from one entangled particle to it's pair 6km away and observe the results.

So, you still have to have a fiber or whatever.

Also - because it's all probabilistic and you don't know for sure if it worked in any given instance, you still need another classical channel to communicate information about what was passed in the first place.

<comment><USER38> Thank you for answering. I am still hopeful there will be another property found out about quantum behavior that will allow instant communication to be a reality.

</comment></comment></comment><comment><USER40> This might sound like a very naive question but I am curious as to how the data was actually transmitted.

<comment><USER41> Both ends of the experiment share entangled photons produced from a single source and sent both ways. The sender performs some operations and measurements on their two photons, i.e. the photon they wish to send, and their entangled photon. They then send the result of the measurements to the receiver (this can be done any normal way you can think of; for example over a classical network).

The receiver does some operation on their entangled photon based on the results of the senders measurements. After these operations their entangled photon will be in the exact same state as the sent photon.

So to answer your question, information is transmitted classically but that information would not be enough without the use of entanglement.

</comment></comment><comment><USER42> Correct me if this sounds noobish. So they have teleported state that has Information that can be decoded to bits and bytes(?) Forget about human teleportation for a sec, isn't this a big deal in a not so far future for telecommunication?

<comment><USER43> They did nothing of the sort. Quantum physicists use words like teleport to say completely different things then what those words actually mean.

<comment><USER44> This is correct. I'll quote the article here: "What happened is the instantaneous and disembodied transfer of the photon's quantum state onto the remaining photon of the entangled pair, which is the one that remained six kilometres away at the university," says Tittel". So teleport in this case doesn't really mean teleport, it just refers to the "teleportation" or transfer of a quantum state.

<comment><USER45> I am not a career physicist, but have read much and thought deeply about these things.

> So teleport in this case doesn't really mean teleport

I would disagree with this statement. For all intents and purposes, the photon receiving the "transfer" is now indistinguishable from the photon that was transferred, before the event took place. That is to say, it has a completely identical quantum state following the transfer, and the "original" photon no longer has that "original" quantum state. They are only separate in space, and the transfer event took place at a defined "instant in time". It is is indeed ok to call this teleportation as (although this might seem odd in the practical sense) it is not possible to prove that the original photon was not teleported through space-time.

</comment></comment></comment></comment><comment><USER46> Is it reasonable to assume that more advanced civilizations would use technology like this for communication instead of radio transmission meaning that SETI is doomed and the Fermi Paradox may be no paradox at all?

</comment><comment><USER47> Similar story from yesterday (BBC) [https://news.ycombinator.com/item?id=12539375](https://news.ycombinator.com/item?id=12539375)

</comment><comment><USER48> There are no particles - only waves. Particles are, in a sense, observation artifacts. Once you grok that, action at a distance doesn't seem so strange.

</comment><comment><USER27> Click bait. Deliberate use of hotword "teleport," to exploit bikeshedding debates.

Cue endless discussions such as: What does teleport _REALLY_ mean?

</comment><comment><USER49> The Uber killer

</comment><comment><USER50> The title of the article, while probably not intentional clickbait, is incorrect. Only the quantum state of the photon was "teleported", not the photon itself. The original photon was in fact destroyed, and only the information about its state was transmitted.

<comment><USER51> This is the exact meaning of quantum teleportation: [https://en.wikipedia.org/wiki/Quantum_teleportation](https://en.wikipedia.org/wiki/Quantum_teleportation)

Changing the title to "Researchers quantum teleport particle..." would make it clearer.

On the other hand, as far as I understand quantum mechanics, there is nothing about the "original" photon that was not teleported/transferred to the new location. It would be impossible to create an experiment that could conclude that the "target" photon was not in fact the original photon. When looking at it this way, it is not so unreasonable to call the process teleportation :)

<comment><USER52> Does the teleportation happen at the speed of light? Was inspired by Regetti's Startup School talk and have almost zero background :p

<comment><USER41> Quantum teleportation requires classical communication from the sender to the receiver of the state. Whether the teleportation itself happens faster then the speed of light is up to your interpretation of Quantum mechanics. The important part is that it does not allow information (classical or quantum) to be transmitted faster then light.</comment></comment></comment></comment>


Debian network-manager: Please restore removed init script - <AUTHOR> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139 <comment><AUTHOR> I submitted this as being interesting because I feel it is a turning point in Debian's long init wars.

The most recent Debian General Resolution on init support said something like "we chose systemd but compatibility with other inits is important"

It did not clarify whether a package maintainer was allowed to remove working SysV init support and refuse to add it back, and this is now what is happening here, so I think the end result of this will set a precedent within Debian that the vote did not.

The package maintainer has remained quiet on their reasons other than "this is intentional", which again might be interesting because it might speak to whether the maintainer needs to defend their choices at all.

In a hypothetical situation, if an upstream piece of software specifically states that it doesn't support non-systemd systems then I could see how a maintainer might want to remove previously-contributed support for being a burden on future maintenance. I am not saying this is the case here, I am just saying this could be a possible argument for why it's not a black and white matter.

In Debian package maintainers have a lot of leeway on what goes on within their packages. In other Linux distributions there are often more centralised groups who would make such a decision ahead of time as a broad project goal.

In Debian these decisions can get referred to the technical committee but that is often considered "the nuclear option".

<comment><USER2> Worth clarifying, only to be precise:

"Systemd but we support exploring alternatives" was what was said in the GR (Choice B in [https://www.debian.org/vote/2019/vote_002](https://www.debian.org/vote/2019/vote_002))

So while alternatives could be supported, I guess it's up to the maintainer to decide if these chose to do so. In this case, the maintainer didn't want to, but could of course provide some better argument than "I didn't feel like it and it wasn't a mistake".

<comment><USER3> > "I guess it's up to the maintainer"

When you have a high-level direction set by the organisation, you can't have it arbitrarily overridden by individuals with no discussion and no justification. This permits individuals who act against the overall interests of the organisation in persuit of their own agendas to dictate its path simply by being obstructive or contrary. This is not being a team player, or in fact playing fair at all.

<comment><USER2> Well, to be fair, the guideline ended up being A) Support systemd and B) Explore alternatives if you want to. In this case, the author chose to do A and not B. That's following the high-level direction and not overriding anything.

<comment><USER3> I don't believe it is following the high-level direction at all. It's completely counter to it.

Dropping existing working support is deliberately and intentionally stopping alternatives from working. Refusing to consider help from others to maintain this support is deliberately and intentionally preventing alternatives from being supported.

<comment><USER2> Seems you're right, according to [https://news.ycombinator.com/item?id=24493214](https://news.ycombinator.com/item?id=24493214) (and [https://bugs.debian.org/746715](https://bugs.debian.org/746715)) which states "That includes merging reasonable contributions, and not reverting existing support without a compelling reason" which I missed when first reading about it. Thanks :)

</comment></comment></comment></comment></comment></comment><comment><USER4> Here's the commit. Unfortunately, there is no explanation in the commit message. Notice that it touches more than the van Smoorenburg rc script.

* [https://salsa.debian.org/utopia-team/network-manager/-/commi...](https://salsa.debian.org/utopia-team/network-manager/-/commit/588ae1fa93a571b7da8f969052e5fd957e65e8c8)

Michael Biebl, for those unfamiliar with Debian, is one of the maintainers of the network-manager Debian package and of the systemd Debian package, amongst a number of others; and also a contributor to systemd itself.

* [https://qa.debian.org/developer.php?email=biebl%40debian.org](https://qa.debian.org/developer.php?email=biebl%40debian.org)

* [https://github.com/systemd/systemd/commits?author=mbiebl](https://github.com/systemd/systemd/commits?author=mbiebl)

</comment><comment><USER5> And this is why, I won't touch Debian anymore. I get enough BS politics and fief building to deal with elsewhere, and if I really want a Debian package, I'll pop the .deb open, and adopt it to my system conventions.

I'm not sold on Debian's "maintainer knows best" attitude. You are not there to make decisions for the community, you are there to ensure the tools people use and want maintained are.

As soon as you lose sight of the "servant" mentality when sitting in a position of authority is about the time a defenestration is in order. The attitude of the maintainer in light of the obvious interest in that feature in that thread, the GR last year, and the lack of any justification whatsoever on the technical merits of the fix, combined with the gall of asserting the project is maintained is ridiculous. I'm legit angry now. If you can't be arsed to do your job, then stop. Stop detracting from the addition of code required to adapt something to work for a wider user base without good contextual justification, which was not provided.

<comment><USER6> Fully agreed. There was a time when Debian could pride itself on being "the universal operating system" (for whatever interpretation of that phrase), but too many maintainers seem to have adopted a "my way or the highway" approach to package maintenance. The systemd adoption was a catalyst in that direction, but it wasn't the first nor the only symptom.

</comment></comment><comment><USER7> This whole argument is a bullshit argument. I have, somewhat grudgungly I'd admit -- slowly come around to the idea that systemd might be worth the trouble. That said, there is room for more than one working configuration pattern, especially provided those patterns provide non-redundant featuresets to their respective configurations.

The last point of bitterness for me with this entire issue is the entirely uneccesary contention and strife with continuing to include sysV init. It's loved by many and used by many, just leave it alone and let the users patch it.

</comment><comment><USER8> How the maintainer handles the bug report is weird too, childish even. Not wanting to explain his reasoning and just ignoring it until it's absolutely necessary to do so.

</comment><comment><USER9> In an internal org, this kind of attitude would be escalated to management. A responsible party for software used by the public doesn't get to say "Because I said so".

inb4 "technically yes they do" \- I'm talking about expectation, not capability.

</comment><comment><USER10> This submission no longer appears at all in the 468 submissions reachable from the front page and 'More', but it is not marked [dead] or [flagged].

</comment><comment><USER11> Crikey; filing an NMU without any particular notice is not the act of someone trying to keep the peace. I'm no expert in Debian policy but surely the good form approach is to submit the patch to the bug report and give the maintainer a week to think about it.

I'd love to see SysV init support continued, but that NMU request isn't helping. Maybe try harder with the negotiating first. There could be context outside the bug report, but hostile maintenance is not the path to take. 4 people complaining in a bug report is no quorum for overruling the package maintainer either.

<comment><AUTHOR> > Maybe try harder with the negotiating first.

If you read the bug report there is a period of about 7 weeks where they are asking the maintainer why it was removed, offering to fix it, pointing out that it works fine and can just be put back etc. with no response whatsoever. I don't think there was any further negotiation that could have elicited a response.

The NMU was also delayed by 14 days in order to give the maintainer time to respond. Which they did. Within 3 hours, to simply say "please cancel [this NMU]."

Don't get me wrong: I use systemd and have no interest in going back to sysvinit, but to say the sysvinit users didn't try hard enough to negotiate here seems rather unfair.

</comment></comment><comment><USER12> I don't understand why it _needs_ to be so political. IMO, yes, he shouldn't remove it but there are reasonable alternatives such as another maintainer setting up a network-manager-sysvinit package that just includes the script (like git-daemon-sysvinit) or even an entirely new package such as network- manager-sysv containing the same files and the script. Then everyone can be happy - the said maintainer can live on without sysv and those that want sysv can live on with their specialized package.

<comment><USER13> Corollary: The most advanced forms of democracy have the most tendency of descending to something akin to a playground bickering

I think the GR is pretty clear but that doesn't seem to be the 1st time that Debian maintainers act like they own the ball and are going home with it.

</comment></comment><comment><USER14> I can understand the maintainer saying that they need people to test it because they run systemd and therefore don't have a system running another init system to test on. I can't understand removing working support.

Maybe split the SysV support into another package that is maintained by someone who is able and willing to spend the time testing it under other init systems.

<comment><USER15> It is fairly trivial to test other init systems using virtual machines, booting off another installation on USB or even by installing the other init system and rebooting. Also, delegating the testing to those using sysvinit and NM would have been just fine too.

<comment><USER3> When I was maintaining sysvinit and initscripts, and testing changes to these, as well as initramfs, lvm, and all other associated packages critical to booting, that's exactly what I did.

Before upload of every single release, it would have been tested on a battery of virtual machines using various different configurations, plus bare metal including non-x86 architectures (powerpc at the time). That was sufficient to catch the vast majority of regressions upon common and not-so-common setups. When a single mistake could effectively brick thousands of installations, you do have a responsibility and duty of care to not ever break system boot.

</comment></comment></comment><comment><USER16> It is sad Debian has devolved to this. Twenty years ago Debian was the guiding light in Linux distros, with principled technical leadership in the space. It is incredible how much damage systemd has caused on the Linux ecosystem.

</comment><comment><USER17> FWIW Network-manager depends on dbus, and dbus hard depends on systemd for some years now.

<comment><USER15> > dbus hard depends on systemd

That doesn't seem to be the case, the dbus package only depends on libsystemd0 and installing dbus in a clean chroot doesn't pull in systemd.

        $ apt-cache show dbus | grep Depends | grep -o ...systemd. | sort -u
        libsystemd0

<comment><USER6> just FYI, aptitude can identify the dependency chain between two packages. I don't know if it always finds the shortest chain, the most direct chain (choosing Depends over Recommends over Suggests), or just any chain, but on this machine (Ubuntu Xenial, the only one I can access right now):

      $ aptitude why network-manager systemd
      p   network-manager Depends libpam-systemd
      i   libpam-systemd  Depends systemd (= 229-4ubuntu21.29)

      $ aptitude why dbus systemd
      i   dbus            Depends    adduser
      i   adduser         Depends    debconf | debconf-2.0
      i   debconf         Recommends apt-utils (>= 0.5.1)
      i   apt-utils       Depends    apt (= 1.2.32ubuntu0.1)
      i   apt             Depends    gnupg | gnupg2
      i   gnupg2          Depends    gnupg-agent (= 2.1.11-6ubuntu2.1)
      i   gnupg-agent     Depends    pinentry-curses | pinentry
      p   pinentry-gnome3 Provides   pinentry
      p   pinentry-gnome3 Depends    libgtk-3-0 (>= 3.0.0)
      p   libgtk-3-0      Depends    libcolord2 (>= 0.1.10)
      p   libcolord2      Recommends colord
      p   colord          Depends    policykit-1 (>= 0.103)
      i   policykit-1     Depends    libpam-systemd
      i   libpam-systemd  Depends    systemd (= 229-4ubuntu21.29)

So yes, network-manager does seem to have a hard dependency on systemd, but dbus doesn't. Though I'm curious why network-manager should hard-depend on libpam...

<comment> dane-pgp > I'm curious why network-manager should hard-depend on libpam...

Meanwhile, some people are trying to work out why a printer driver should require switching init system to systemd.

[https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=863974](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=863974)

> Tags: wontfix

</comment></comment></comment></comment><comment><USER18> Will this be something that downstream maintainers like Ubuntu etc will be able to keep going easily, or will it basically hobble them as well over the next few years?

<comment><USER15> Ubuntu have also switched to systemd so they are unaffected by this issue.</comment></comment>


The terrible PIC ecosystem - <AUTHOR> https://www.earth.li/~noodles/blog/2016/12/terrible-pic-ecosystem.html <comment><USER2> I agree with the sentiment, and having a complete open source tool chain for processors was a huge win. But experience tells us that can also be a problem.

Atmel, which was made popular by the Arduino movement, the avrfreaks board before that and its generally amenable architecture to a high level language, was recently bought by Microchip[1], the walled garden guys.

Both had processors that had fan bases, Atmel had open source tools, Microchip closed source. But the guys with the closed source had the cash to buy Atmel when the ARM architecture started eating the 8/16 bit market alive.

What does that say?

[1][http://www.nytimes.com/2016/01/20/business/dealbook/microchi...](http://www.nytimes.com/2016/01/20/business/dealbook/microchip- technology-to-buy-atmel-for-nearly-3-6-billion.html)

</comment><comment><USER3> > I want things I can use in Makefiles and properly script, that are available > in my distro of choice and that generally work in the same fashion as the > tool chains I'm used to.

You can use the assembler, linker and other tools that come with mplabx in a traditional tool chain, with Makefiles, scripts, and your editor of choice.</comment>


Social news sites such as Digg, Nestscape, Fark, etc. are said to be losing momentum - <AUTHOR> http://www.businesshackers.com/2007/08/15/social-news-sites-such-as-digg-nestscape-fark-etc-are-said-to-be-losing-momentum/ <comment><USER2> Is this surprising to any reader here? The signal to noise ratio drops as more users join up. Also, when you have a number of balkanized sub-groups at a site who like different things, about the only content they can all agree on as 'great' is LOLcats and anti-Republican propaganda. These problems can be solved... at least if enough venture capital is thrown at the problem.

<comment><USER3> so true. I liked digg, honestly, and far past the "early adopter phase". Then it seemed like every front page story was either about what Microsoft was doing wrong (HOLY SHIT MSFT DID THIS!!!!), what new liberties Bush was taking away, etc. Or, of course, a recursively titled "Digg gains ground on slashdot", etc.</comment></comment>


The $9 CHIP Computer Reveals Its Open Source Details - <AUTHOR> http://makezine.com/2015/07/22/with-linux-and-creative-commons-the-9-chip-computer-reveals-its-open-source-details/

<comment><USER2> Olimex deconstructed that $9 computer story a while back.

[https://olimex.wordpress.com/2015/06/05/how-to-get-in-the- ne...](https://olimex.wordpress.com/2015/06/05/how-to-get-in-the-news-tell- people-that-you-will-make-and-sell-something-which-cost-you-20-for-9/)

<comment><USER3> TL;DR: It's going to be $39 after the Kickstarter.

<comment><USER4> For what it's worth, there's some debate about that. The creators have specifically said "C.H.I.P. will still be $9" -

[https://www.kickstarter.com/projects/1598272670/chip-the- wor...](https://www.kickstarter.com/projects/1598272670/chip-the-worlds- first-9-computer/posts/1286187)

Of course, time will tell...

<comment><USER2> Well, seems they might make margin on accessory and postage etc, however, the math seems pretty clear -- they /can't/ sell it at $9 and break even, so there has to be a trick...

Personally, I'd rather give my money to guys like Olimex anyway -- a notch more expensive, however these guys are /spotless/ at making everything as open as they can, and in fact, they probably 'suffer' for it as many companies seem to use their (open) designs commercially...

</comment></comment></comment></comment><comment><USER5> I'm glad to have helped fund the kickstarter. It was advertised to come with a linux distro but at the time but they didn't have many details about that. Glad to see that they're becoming part of the mainline kernel. Developments like this are going to increase the popularity of linux and smaller computing devices.

</comment><comment><USER6> Wow that's awesome that they want everything in the mainline Linux kernel. Here's hoping they pull it off!

<comment><USER7> If I understand, that would be their major advantage to Raspberry Pi? But is the graphics of CHIP comparable to the one on Raspberry Pi?

<comment><USER8> > But is the graphics of CHIP comparable to the one on Raspberry Pi?

The CHIP uses an Allwinner R8 SoC, which uses a Mali400 GPU (source: [http://www.cnx- software.com/2015/06/07/allwinner-r8-module-d...](http://www.cnx- software.com/2015/06/07/allwinner-r8-module-datasheet-and-price-is-the-9-c-h- i-p-computer-selling-at-a-loss/)). RPi uses a VideoCore IV GPU.

While there is no open source driver for Mali400 available, it has been partially reverse-engineered (lima). For the VideoCore IV there is an open source driver available, but the SoC on the RPi is special in the sense that when booting the VideoCore IV is the core to start, which later in the boot process starts the ARM core(s). On the VideoCore IV there runs a proprietary OS (probably RTOS) that is based on ThreadX. So most things the open source driver does are simply calls to this RTOS via a mailbox.

Nevertheless the RPI developers market the VideoCore IV GPU as the most open embedded GPU available. Indeed it is the only one, where an official open source driver is available and thus it is more friendly towards bare-metal programmers that want to write their own OS. On the other hand, the RTOS running on the VideoCore IV is a large blob in an instruction set that has not yet been deciphered.

<comment><USER9> That's not quite accurate anymore - there's an open-source OpenGL ES driver for the Pi that isn't just a wrapper around the binary blob on the VPU. However, you still need the proprietary blob in order to boot the Pi and actually enable the display outputs, and for accelerated video decoding. (Oh, and it has an interesting license that forbids you from using it on non- Raspberry Pi hardware.) On the Allwinner chips, it's the other way around - you can boot them, enable the display outputs and do modesetting and I think even hardware video decoding with open-source code, but OpenGL ES requires a proprietary blob. Though I think the Allwinner 2D graphics overlay hardware is fully documented, which may be enough for some applications.

<comment><USER10> >> Oh, and it has an interesting license that forbids you from using it on non-Raspberry Pi hardware.

Does that mean you can't use the Pi as a dev board for the SoC and then build a product based on that? Or I suppose you'd license the video driver when you go to buy the SoC for production?

<comment><USER9> It does, but chances are Broadcom won't sell you the SoC either so it matters less than you think. I expect it's mostly just aimed at anyone who attempts to re-purpose existing hardware based on the same Broadcom SoC.

</comment></comment></comment></comment></comment></comment><comment><USER11> An embedded shop released u-boot source. I never thought I'd see the day - this is great news.

<comment><USER12> Most embedded shops release u-boot source, just not in a very usable state, eg. based on old versions, zip package instead of version control, not following any of the development practices or internal organization of the original project... Same thing with the kernel. Excited to see mainline support!

Source: working in embedded, trying to fix how we release exactly these things.

<comment><USER13> I think the first time I started pushing for real version control and semi- reproducible builds in embedded device development was in 1991, when I was working on medical diagnostic devices. I really can not believe that in 2015 there are still places the still don't adhere to simple practises like that...many places unfortunately.

I mean it's like wearing pants. It's fine if you do not want to wear pants at home but once you're at work and doing something in a professional context it seems like a reasonable minimum bar to expect everyone to live up to.

<comment><USER12> Haha, the pants is a great example, thanks! If I may, I'll use that example internally, hopefully to good (and hilarious) effect!

</comment></comment></comment></comment><comment><USER14> Kind of amusing that the article explains how to set up the development environment using VirtualBox. I doubt many Linux kernel hackers use or want to use VirtualBox. At least, many ones working with mainline.

<comment><USER15> I'd imagine a lot of kernel developers use virtualisation during development so that they can still boot their machine (though they probably aren't running Macs).

<comment><USER2> Not ARM developers; my workstation reboots every few months, my ARM boards every few minutes :-) That is, unless you have a qemu port for the SoC in question.

That's also why my host /sbin/reboot is "echo Wrong terminal, you idiot"

<comment><USER15> Haha I generally try to colour my terminals differently to get around this same issue.

</comment></comment></comment></comment><comment> TD-Linux Awesome! I would have funded the campaign had I known this information at the time.</comment>


Ask HN: How to Web Scrape in 2020? - <AUTHOR> Are there particular libraries or scraping-as-a-service UIs you would recommend?<p>I'm particularly interested in restaurant reviews website which has been an increasingly detestable company over the years. <comment><USER2> scrapy for python is pretty good, check it out.

In most cases getting banned is the big issue. The bigger the site, the more advanced their bot detection is. You can use luminato.io to get residential and mobile IP's, but it's pricey.

Some sites will also obfuscate the DOM, ie. removing classnames and ID's, which complicates the data extraction.

[http://scrapinghub.com/](http://scrapinghub.com/) has a paid "do it for me" service, which may be an option depending on your budget.

<comment><USER3> Here is a tiny DOM walking script that evaluates all text semantics in a page demonstrating that you don't need identifiers in the code.

[https://github.com/prettydiff/semanticText](https://github.com/prettydiff/semanticText)

</comment></comment><comment><USER4> Related from 2 month ago "Ask HN: What's state of the art for screen scraping these days?" [https://news.ycombinator.com/item?id=22148803](https://news.ycombinator.com/item?id=22148803) where [https://simplescraper.io/](https://simplescraper.io/) was recommended

</comment><comment><USER5> For avoiding bans, having a large ipv6 range can help (e.g. like one you might get with a VPS at a proper hosting company). As for grabbing the content itself, I've used a lot of frameworks but I usually end up back at some combination of simple string search and regex.

</comment><comment><USER6> Depending on what you're scraping you might run into a fair few JS-Only websites that are a pain to scrape. On top of all the things mentioned here you will need to run pages through a headless browser like puppeteer. For these sites you maybe be able to reverse engineer their APIs and attempt to scrape those rather than the pages themselves.

</comment><comment><USER7> python + beautiful soup</comment>