HN user
Better gate control results in lower leakage compared to fins, and there are probably also some better thermals associated with this approach due to the surrounding metals. However, the density is crap - stackable nanoribbons are likely the better path.
The rest is just atrocious marketing smoke and mirrors from a zombie company that is essentially dead, but somehow manages to linger on as a shell of its former glory.
And on top of that, you can make almost any material lase. There have been entertaining experiments where folks used yogurt, apple juice, hair dye, and other fun liquids in pumped lasers, exploiting some molecular band transition that was accidentally good enough.
I'm afraid that's not even remotely true. Just two counterexamples:
- MLC flash storage devices use multiple levels to store/retrieve bits [1], - Lots of control systems are implemented with analog PIDs [2]. A trivial example is a jellybean voltage regulator that computes the adjustments needed to maintain a stable output voltage independent of the load.
[1] https://en.wikipedia.org/wiki/Multi-level_cell [2] https://control.com/textbook/closed-loop-control/analog-elec...
That's indeed done all the time in electronics: for example, RF CMOS usually trailing on a node three or four generations behind the bleeding edge.
However, all-optical/photonic computing is just intrinsically so much worse than electronics. On top of the issues that I touched on, there are also other fundamental problems, e.g. distribution of power: photons like to get absorbed by nearby electrons. How do you then supply all the active devices (switches/lasers/etc.) with power while maintaining some semblance of signal integrity and dense integration?
In principle, yes, but: - lower wavelength light is harder to confine within waveguides (or transmissive optics), and messes up atoms when colliding (think of x-rays), - finding an efficient source at lower wavelengths is one of the main struggles of the semiconductor industry.
Switching/routing usually requires significant information processing (e.g. decode packet header, match destination address against routing tables, etc.). This necessitates 10k or more gates. All-optical computing can't deliver this level of integration density, nor the performance at reasonable power levels.
Maybe there will be some smart way to pre-encode routing information onto packets to reduce processing requirements, but I doubt that such a network could scale.
No - that's just a neat trick to enhance the precision in the measurement of non-commuting observable quantities of interest.
In reality, all-optical computing is mostly a terrible idea: fundamentally, it cannot reach the integration density of electronics. It boils down to the elementary differences between Fermions (electrons, neutrons, etc.) and Bosons (photons, etc.). Their intrinsic behavior determines the interaction with matter, i.e. conductive/absorptive properties. As a result, optical wires (waveguides) have to be sized roughly at a wavelength (hundreds of nm), whereas electrical wires can be much smaller (<30nm and below). Suppose you want to build an amplifier: all the claimed speed benefits of this optical device would vanish in the path delay of the feedback loop.
But just like graphene, carbon nanotubes, and other fads, you can publish fancy papers with it.
That is an extremely common practice in the industry. Every large chip design house does this to maximize line yield - it is called "binning" [1].
[1] https://en.wikipedia.org/wiki/Product_binning#Semiconductor_...
No, that's just some marketing verbiage with no real physical correspondence.
So many hyperbolic claims that boil down to a moderate 33% area benefit with very little data about mundane things like long-term reliability, or process variation.
Every time an article mentions some buzzword like 'graphene', it turns out to be just a load of baloney. Graphene can do everything but leave the lab.
Linearity, on-state loss, pole-to-pole isolation, and breakdown will be atrocious. It makes for a nice clickbaity publication though.
That's a great re-implementation from some stuff I did eons ago [0].
BIOS passwords are indeed a complete joke as means to secure access. There are a bunch of vendors out there who moved the authentication off from the BIOS/CPU to the KBC (keyboard controller) - Toshiba and Lenovo are among them. Still, it's ludicrously easy to circumvent these.
[0] https://dogber1.blogspot.com/2009/05/table-of-reverse-engine...
I do not understand the proclaimed 3X increase of design cost per finfet node, particularly in the context of digital ICs. Most cell designs are highly repetitive, so the increased design complexity should only add a one-time offset to the total chip cost. Hence, the total design cost should be comparable to previous nodes, i.e. well below 2X. I understand that purely analog designs are a different beast, but it doesn't make any sense to use advanced nodes for these in the first place (ft/fmax drops as a result of higher-than-linearly scaled CGS).
The bypass algorithms have largely remained unchanged when the industry moved to EFI. Most vendors (Lenovo, Dell, Acer, Asus, Toshiba, Fujitsu, ...) simply wrapped their bypass algorithms into some DXE driver and called it a day.
Apple is doing a much better job than all the rest of the PC vendors. Even those vendors that I haven't published keygens for [1] have just stupendously unsound bypass mechanisms for BIOS passwords.
[1] https://dogber1.blogspot.com/2009/05/table-of-reverse-engine...
No, it won't: on the length scale of a chip, the power efficiency of an electrical-optical-electrical transmission line is an order of magnitude worse than direct electrical transmission, regardless of the actual technology. Also, optical transmission lines are huge in volume in comparison to electrical lines.
The GPU is still an ARM Mali T6xx which is mostly unsupported, i.e. removing Chrome OS and running "pure" linux is going to be dreadfully slow for lack of 2D/3D acceleration. It's a shame that ARM hasn't released any technical datasheets for their Mali GPUs.
If you get around replacing chrome OS with linux and reflashing the firmware with uboot, you'll lose GPU acceleration (3D and 2D). ARM is pretty shitty about releasing specs for their GPUs, so the Chromebook GPU (Mali T604) remains unused.