Check out 1blue3brown’s excellent YouTube video lesson on quantum computing and Grover’s algorithm:
https://youtu.be/RQWpF2Gb-gU
Goes through qubits, state vectors and Grovers algorithm in a highly visual and intuitive fashion. Doesn’t discuss the underlying quantum mechanics in depth, but does mention and link out to resources for the interested viewer to delve deeper.
Fabs are specific to the manufacturing of integrated circuits.
EE encompasses more than just manufacturing of ICs, for example research and applications in radio propagation and EM/wireless, signal integrity, antenna design, coexistence/desense, advanced power electronics, control systems, simulation/solvers, etc.
This is true, although for wireless applications you can follow the recommendations of the IC vendor and the remainder of the work is RF-engineering, not research. That's why I said fab, not lab. But yes, you are right to a great extent. The main point is that the hard EE work can be prohibitively expensive for individuals and smaller companies.
I think you're oversimplifying this. Lots of RF research is done with a DAC, an ADC, an FPGA, and a frontend made of discretes (sometimes also with off-the-shelf boxes connected with SMA connectors). A lot of power electronics research is done with microcontrollers and discrete parts. Digital circuits research often stops on an FPGA or in a simulator.
You can do a lot of actual original work without a fab.
Sibling poster did a good job explaining how research relies on labs.
Agree that complex EE work can be expensive for individual and smaller companies, indeed :)
A comment on the application side:
> "[..] for wireless applications you can follow the recommendations of the IC vendor and the remainder of the work is RF-engineering"
Zoom out to the system level, and you cannot just rely on IC vendor recommendations, and this kind of engineering can still require access to $$ labs.
Similar to complex software systems: for example take a large scale distributed system made out of many individual frameworks and services. The system as a whole may now exhibit emergent behaviour, and have failure modes due to the complexity of the system.
Same happens in complex EE designs, your design might pack in multiple cutting edge RF radios such as mmWave, UWB, with bespoke power amplifier, detection and antenna designs. Add in EM from multiple clock domains, high power distribution circuits, digital noise from FPGAs/CPUs, and EM from nearby sources. You can easily have noise couple from sources causing unintended issues in other subsystems. The vendor may say "keep a way from sources of noise", but your application may still be to engineer a solution that fits in the design envelope of a modern smartphone. The system level design needs to be engineered for EMC and coexist/desense, and validated which takes a ton of lab simulation and measurement/characterization work.
Hilarious. Reminds me of Pioneer CDJs as well, even on the flagship CDJ-3000 models. If you read the user manual it says:
> About using MP3 files
> This product has been licensed for nonprofit use. This product has not been licensed for commercial purposes (for profit-making use), […].
You need to acquire the corresponding licenses for such uses. For details, see […]
The format itself is patent-unencumbered. That doesn't mean I couldn't still write a non-free decoder and license it to Pioneer for use in their CDJs. Due to organizational inertia, I suspect that's what's going on here (e.g., they licensed a decoder from Fraunhofer or another commercial implementer twenty years ago, and have been using the same one since).
In this case, everyone at Pioneer knows their CDJs are used almost exclusively for commercial purposes, and perhaps they couldn't get away with lying about it in the fine print.
Agree on this. As a layman in Australia, i had a friend who was coming back from the USA and asked him to buy me an iPhone before its release in AU (late-2007 iirc, iPhone 3G launched in Australia in 2008) and promptly jailbroke it so i could get it on an Australian carrier.
When i whipped it out in public, take a photo at concerts, etc. random people would come up to me and ask me to play with it -- thats when i knew for sure Apple were on to something, a complete game changer that captured the attention of the public.
Not how Apple and others are doing. Internet access and cloud accounts are not a requirement to integration. You need standards and conventions. Now, eveyone is doing its own thing and company wants to control your devices to the point they can brick them within a few years.
Explaining this in sufficient detail would make a really long text, so I'll just give one very isolated point:
Bascially, the internet is a dark forest. A lot of things "ordinary" people do all the time is insanely privacy-violating (just to give one example: if you send a message to a person who is not insanely privacy-conscious and capable (meaning very knowledable about technology) of preserving your privacy, malicious entities can spy on you).
So, for the product/OS to be capable of keeping your privacy, it will have to prevent you from doing an insane amount of things against your reflexes, comfort and what you learned about politeness.
Indeed, this is a common vector for leaking PII and sensitive data. For example, what looks like an innocuous logging/print statement in an exception handler ends up leaking all sorts of data.
And it gets more messy when you start to ingest and warehouse data logs for on-call monitoring/analytics/etc, and now you have PII floating around in all sorts of data stores that need to be scrubbed.
In a previous job, we handled credit card numbers. We added PII detectors to logging libraries that would scrub anything that looked like a credit card number. We used client-side encryption where the credit card numbers are encrypted on the client before sending to the backend, so the backend systems never see the plain credit card numbers, except for the system that tokenizes them.
reply