> In the electronics industry, a "jelly bean" component is one which is widely available, used generically in many applications, and has no very unusual characteristics—as though it might be grabbed out of a jar in handfuls when needed, like jelly beans. For example, the μA741 might be considered a jelly bean op amp.
The μA741 is still manufactured and it historically was a jellybean part, but I'm not sure it counts as one today. The performance is low and it's not something anybody is likely to use in new designs. I think the LM358 is a better example of a jellybean part. It's cheap and widely available and still commonly used, mostly because unlike the μA741 it works with a single-ended 5V supply (the μA741 needs both +5V and -5V).
Before I moved my career to embedded software I was always incredulous when I read articles claiming such and such device has 100s of chips in it. Now I know this to be true I am still amazed at how many "moving parts" each little device has (or to put it more intelligibly, how many semi-autonomous subsystems each computer system consists of) - it's a miracle we routinely manage to make them work. The pinnacle of processor cramming must the modern smartphone which just beggars belief. I'm more surprised there's only one microcontroller on that board.
It's a bit "scary" because this is a non optimized "controller" from 2013. With today's processes and market evolution, anything could be a multicore arm processor in disguise. You can never be sure about anything anymore since it can be virtual information generated by some logic/source.
There was one time I booked a flight. A few days before departure, that particular flight had an accident (Asiana 214 at SFO): I need to check if my flight will still depart as scheduled, so I dig my mailbox and the reservation confirmation email I received months ago(!) now says "Your flight is canceled." Apparently emails can be retroactively rewritten, WTF.
How is an email that loads remote assets "creepy as fuck"? It actually sounds useful in this case, all he had to do is look at an email to see what was going on with his flight. It doesn't have to be sophisticated, imagine an HTML email loading an image through a URL like so:
/asiana/status?flight=214&date=2017-03-17
Pretty simple to return a standard "On Time", "Delayed" or "Cancelled" asset.
In part because it means that a property you take for granted in email (namely, that you can reference it later without it having changed) is violated. (This would permit all sorts of things involving documents being retroactively edited to whatever is convenient for the party sending the email.)
In part because you could use this to implement detection of an email having been "read" when the remote asset is fetched.
(These are just why I find those sorts of emails irritating and sometimes creepy.)
If you don't mind getting tracked, then you probably won't find it creepy.
I, on the other hand, get annoying letters form my bank saying I never open their emails, so they won't let me password reset via email anymore. Uh, OK, I'll waste the bank's money calling, I suppose...
...Well, because UI sucks, and email contents aren't supposed to change. If there's a small box saying "Current status of your flight", that would be one thing, but the whole contents of the email can change and (unless I check the raw HTML of every email) there's no indication which part is immutable. And I consider myself a computer-literate person. Mostly.
Imagine you book a hotel online, fly to another country, arrive at the hotel. "I have a reservation." "May I check your reservation?" "Sure, just a second." You take out your iPhone and open the email: but while you were flying the online booking site had a server meltdown and the data was corrupted.
"Uh, sir, the email says 'Unfortunately, there is no room available at this hotel now. Would you like to check other hotels in the area?' And it's dated three months ago."
"What the..."
I now always print flight/hotel reservations upon booking. That will be safe until nanomachine overlords arrive, I guess. Low-tech solutions FTW.
I tried to work out how to do that at one point. I didnt succeed. So you can sleep well. Far as concealment, there was a $50 spray that made envelopes translucent to point you could see what was inside them.
Unrelated note: I bought that book on Hamilton's methods. Finished it last night. Really enjoyed it outside of the filler, repetative, and overselling parts. The sections on requirements, specs, and spec-to-code (in abstract) were still accurate today for the most part. The HOS method itself reminded me of original LISP where its power and beauty came from how it reduced everything to a few primitives. Like LISP 1.0, there were severe usability & performance problems that prevented wider success. Fun to at least read on an early attempt.
Why bother changing the paper... climb into eyes and show the retina cells whatever you want...
---
Oh hey awesome! Could you see applications for e.g. sitting down with a non-technical person and having them construct working software? That was something that really interested me: the claim that non-programmers could use it.
What you say about how it reminded you of LISP is just fascinating. When I had refined my attempt to implement some HOS-like thing I eventually came up with something that I recognized (later, when I had learned LISP) as a crude subset of that.
Imagine a system that uses a stack, like Forth, but the words/functions are built out of the three primitives (Sequence, Branch, Loop) in, uh, "HOS-style". Give it S-expr syntax and squint and I see a crude proto-LISP. ;-D
"Why bother changing the paper... climb into eyes and show the retina cells whatever you want..."
Alternatively a psychadelic reaction in the brain combined with something like Oxytocin's claimed properties for enhancing trust. Then the person that shows up convinces the person in contact with the paper that what they're told is true. Many possibilities.
" Could you see applications for e.g. sitting down with a non-technical person and having them construct working software?"
What I see is it's like a combination of old CASE tools, a bit of functional programming, logical composition (see LCF provers), and a pile of dishonest marketing (aka "overselling"). I'm currently in a discussion about it elsewhere given Dijkstra personally nuked it while others found problems. Email me if you want and I'll give you a summary of some of that along with controversies that aren't settled yet.
Frankly if one look at a 70s mainframe one have all the parts there, only running on transistors and tubes.
"All" we have really done is shrink said transistors, and the boards holding them, down to something that can fit on a fingernail.
Thing is that most of the people that are into computers these days don't know it, unless they dig into history. Because the mainframe world was so insular that microcomputers virtually started from a blank slate.
Most of the "cloud" stuff people are going gaga over right now could be done on a 80s mainframe.
Computing has been coasting on Moore's law for some 3+ decades.
Such tools have existed for long time. NSA tools catalog had a tool[1] that took control of HDD firmware and provided Application persistence across re-formatting. Date mentioned on the brochure[1] is June 2008.
Of course most of your PC peripherals have their own processor, if sufficient documentation is available, PC peripherals can be easily weaponised. They can even have a wireless implant that allows HDD to communicate with outside world, and trigger exploit (send data, or trigger code execution), remotely.
Things like this are why I will never trust any computer with privacy.
There are processors and memory systems everywhere. There are so many entry points for snoop attacks which can be completely invisible unless you know exactly what to look for.
If your freakin' hard drive can be running linux or a web server then how can you ever trust anything?
