I'm so sad to see Mozilla move forward with this massive attack on user privacy.
Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens of thousands of individual ISPs.
Simultaneously, it does not protect the user from monitoring by their ISP or parties situated there because the user's destination IPs remain unencrypted, as well as the hostnames via SNI (for cases of shared hosting, e.g. on cloudflare, where the IP alone wouldn't be enough).
At the moment you can disable this across your whole lan by blocking traffic to 104.16.248.249, 104.16.249.249, 2606:4700::6810:f8f9, and 2606:4700::6810:f9f9 and by DNS blackholing use-application-dns.net and cloudflare-dns.com.
iptables -t raw -A PREROUTING -d 104.16.248.249 -j DROP
iptables -t raw -A PREROUTING -d 104.16.249.249 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f8f9 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f9f9 -j DROP
And if you're using bind:
zone "use-application-dns.net" {
type master;
file "/etc/bind/db.empty";
};
zone "cloudflare-dns.com" {
type master;
file "/etc/bind/db.empty";
};
Or unbound:
local-zone: "use-application-dns.net" static
local-zone: "cloudflare-dns.com" static
But there is no guarantee that these mitigations will continue to work.
[Edit: Aside, this comment and many/most(?) comments on this thread were moved from a more recent thread with a headline "Firefox turns on DoH as default for US users". The new title which omits the on-as-default, is kinda burying the lead.]
I believe Aaron Hsu's work on tree processing for Co-dfns [0] is a novel example of tree handling - a data parallel compiler for efficient compilation on a GPU using extensive tree-oriented "nanopass" transformations [1].
Cadence was conceived and is still led by the original tech leads of the SWF.
SWF had no new features added for the last 5 years. Cadence is open sourced and is under active development.
Cadence was initially based on SWF public API. It uses Thrift and TChannel for communication and SWF uses AWS version of REST. Currently the API is not compatible with SWF as Cadence added a large number of new features and deprecated a few problematic ones. We are planning migrating to gRPC later this year.
Cadence can potentially run on any database that supports single shard multi-row transactions as a backend. Currently it supports Cassandra and MySQL.
SWF has pretty tight throttling limits. Cadence scales very well with use cases in production that require 100s of millions of open workflows and thousands of events per second.
SWF has pretty tight limits on individual payloads and number of events. For example maximum activity input size is 32k. Cadence currently has 256k limit. SWF history size limit is 10k events while Cadence limit 200k. All other limits are also higher.
Cadence has no limit on the activity and workflow execution duration.
Cadence through archival supports unlimited retention after a workflow closure.
SWF has Java and Ruby client libraries. Cadence has Java and Go client libraries.
SWF Java library is fully asynchronous and relies on both code generation (through annotation processor) and AspectJ. It is hard to set up, doesn't play well with IDEs and has very steep learning curve. Cadence Java library (as well as Go one) allow writing workflows as synchronous programs which greatly simplifies the programming model. It also just a library without any need for code generation or AspectJ or similar intrusive technologies.
Cadence client side libraries have much better unit testing support. For example the Java library utilizes an in-memory implementation of the Cadence service.
Cadence features that SWF doesn't have:
Workflow stickiness. SWF replays the whole workflow history on every decision. Which means that a workflow resource usage is proportional to O(n*n) of number of events in the history. Cadence caches workflows on a worker and delivers only new events to them. The whole history is replayed only when a worker goes down or the workflow gets out of cache. So Cadence workflow resource usage is O(n) of number of events in the history. For large workflows it makes a huge difference. It also leads to higher per workflow scale. For example it is not recommended to have workflows that execute over a hundred activities in SWF. Cadence routinely executes workflows that have over thousand activities or child workflows.
Query workflow execution. It allows synchronously get any information out of a workflow. An example of a built-in query is a stack trace of a running workflow.
Cross region (in AWS terminology) replication. SWF in each region is fully independent and if the regional SWF is down all workflows in the region are stuck. Cadence supports asynchronous replication across regions. So even in the event of a complete loss of a region the workflows continue execution without interruption.
Server side retry is an ability to retry an activity or a workflow according to an exponential retry policy without growing the history size.
Reset is an ability to restart a workflow from any point of its execution by creating a new run and copying a part of the history. For example the reset is used to automatically roll back workflows to the point before a bad deployment that was rolled back.
Cron is an ability to schedule a periodic workflow execution by passing cron string to the start method.
Local activity is a short activity that is executed in the context of a decision. It uses 6x less DB operations that a normal activity execution.
Long poll on history allows to efficiently watch for new history events and is also used for efficiently waiting for a workflow completion.
Cadence uses the elastic search for visibility. Soon it is going to support complex searches across multiple customer defined columns which is far superior to the tag based search SWF supports.
If decider constantly fails during a decision SWF records a few events on every failure eventually growing the history beyond the limit and terminating a workflow. Cadence supports transient decision feature that doesn't grow history on such failures. It allows continuing workflows without a problem after the fix to the workflow code is deployed.
Cadence provides command line interface
Cadence Web is open sourced and is much nicer than the SWF console.
Cadence supports local development through unit testing as well as using local docker container that contains the full implementation of the Cadence service and the UI.
Cadence doesn’t yet have activity and workflow type registration. The advantage is that changes to activity or workflow scheduling options do not require version bumps that affect clients.
Hey sure. I am delighted with how my project turned out, an old iPod is fantastic in the car, gym, while travelling without data allowance etc. I hadn't modded an iPod before this and it worked out ok.
Get an iPod classic, 5.5 gen if possiible (best DAC, for a nice warm sound)[1] A broken one, as long as it's not totally physically destroyed, is one way to go from ebay.
Get an offical iFlash device, I got the Quad with slots for up to 4 SD cards [2] Get some large capacity micro SD cards (x4 slots in the Quad, meaning several TBs are possible, for relatively cheap as the cards are getting cheaper by the day)
Upgrade the battery, if desired, optional but highly recommended [3]
Replace the front + back covers, clickwheel, screen as desired (pay attention to thin and thick back covers) [4]
For instructions on opening the case correctly, and replacing the parts, look on Youtube there's a bunch of decent videos explaining the process.
Look into installing rockbox[5], an open source firmware. It supports loads of audio formats and let's you escape the cluthes of itunes, to a much nicer application like Musicbee. WARNING for some reason, rockbox never worked correctly with my iPod 5.5 gen. I reinstalled several times, but songs would constantly skip while playing, even though they were fine on any other device. Therefore, I wiped rockbox again back to the Apple factory firmware, and everything works fine. I even figured out a way to sync Musicbee with the default Apple firmware.
If you really want to go nuts, you can install a bluetooth transmittor inside the newly freed up iPod case[6] I read though that the bluetooth has limited range inside the metal case, and it runs the battery down much more quickly.
Ideally the browser would listen for this type of command on a local port. So instead of needing a binary 'SendToChromium' one could simply start Chromium in listening mode:
MIT Press published a book called "The Warren Abstract Machine: A Tutorial Reconstruction" by Hassan Ait-Kaci.
This short -- 114 pages -- book about the Prolog VM has been made available for free download by the author (it's out-of-print). [0]
A good description of what it's about is at MIT Press' page for the author [1].
(While out-of-print, apparently a paperback version can be had for $21 on Amazon [2]).
Recently, I brought a Dasung paperlike HD to use as a monitor. (crazy expensive, prob should've spend money elsewhere...)
I thought some things were impossible with eink, but it proved me wrong. (video in a reasonable fps)
It has a few different ways of display. For example:
Floyd–Steinberg dithering: essentially only black and white with dithering, and the speed pretty good.
A16: uses 16 shades of grey, but the speed is horrible for moving images.
So I wonder if a mix of the two can do much better (e.g. moving objects using floyd-steinberg until it stops moving)
Before doing that, I need to know the exact limit of eink.
Are some operations slow because the microcontroller or because it is the limit of the display module itself?
This article shows such a question is not that easy to answer using the openly available information.
Also, I'm interested if there are algorithmic problems to be solved in this space. (I do research in theoretical computer science).
If you are in NYC and knowledgeable I'm very interested to chat (I know little, but I have the monitor you can play with).
> I suspect one reason for $600 devices, other than Google itself trying to reposition Chromebooks as more upmarket, is because $600 Windows laptops are still are a mess of preloaded bullshit put there by the vendor. Microsoft has tried various ways to fix this but it only tends to protect high-end models.
In the current version of Windows 10 there's a feature called "fresh start" that makes it trivial to reset to a clean OS install without vendor crap. It even automatically preserves your home directory. The only problem is that you need to know it exists, so it only benefits technical users and users with geeky friends to advise them.
And what few people know, is that Apple already had a platform where all of the “apps” were written with JavaScript + TVML (a proprietary Apple markup language) - the 3rd Gen AppleTV. If I’m not mistaken, you can still write apps for the ATV4 that way.
Plex was ported to the 3rd Gen AppleTV as an unofficial app just by running a server on your computer and redirecting DNS to it.
Considerably more relevant than what is left of HP-the-company. Every time I use my trusty HP-12C I feel a little sad for what was lost in the slash-and-burn era of Fiorina. Swiss Micros keeping the dream alive!
Somebody raised an interesting point on reddit about patent trolls:
BobTheSCV> Neverwinter Nights also implemented them, and they worked very well. I had just assumed it was patent trolls or something that kept them from being widely adopted.
I replied:
You are absolutely correct about the patent trolls!
Bill Buxton at Alias and his marketing team spread a bunch of inaccurate FUD about their "marking menu patent", which I accidentally discovered and tried to correct and get him to stop doing decades ago, but he refused, and continued to spread FUD.
So Alias kept advertising their "patented marking menus" for DECADES, purposefully and successfully discouraging their competition 3D Studio Max, AND many other developers of free and proprietary apps as collateral damage, from adopting them.
When I asked Buxton about the "marking menu patent" before it was granted, he lied point blank to me that there was no "marking menu patent", so I couldn't prove to Kinetix that it was OK to use them, or contact the patent office and inform them about the mistakes in their claims about prior art, and the fact that the "overflow" technique they were claiming in the patent was obvious.
The whole story is here:
Pie Menu FUD and Misconceptions: Dispelling the fear, uncertainty, doubt and misconceptions about pie menus.
>There is a financial and institutional incentive to be lazy about researching and less than honest in reporting and describing prior art, in the hopes that it will slip by the patent examiners, which it very often does.
>Unfortunately they were able to successfully deceive the patent reviewers, even though the patent references the Dr. Dobb’s Journal article which clearly describes how pie menu selection and mouse ahead work, contradicting the incorrect claims in the patent. It’s sad that this kind of deception and patent trolling is all too common in the industry, and it causes so many problems.
Even today, long after the patent has expired, Autodesk marketing brochures continue to spread FUD to scare other people away from using marking menus, by bragging that “Patented marking menus let you use context-sensitive gestures to select commands.”
A snapshot of Alias's claim about "Patented marking menus" from one of their brochures that they are still distributing, even years after their bad patent has expired:
>"Marking Menus: Quickly select commands without looking away from the design. Patented marking menus let you use context-sensitive gestures to select commands."
>The Long Tail Consequences of Bad Patents and FUD
>I attended the computer game developer’s conference in the late 90’s, while I was working at Maxis on The Sims. Since we were using 3D Studio Max, I stopped by the Kinetix booth on the trade show floor, and asked them for some advice integrating my existing ActiveX pie menus into their 3D editing tool.
>They told me that Alias had “marking menus” which were like pie menus, and that Kinetix’s customers had been requesting that feature, but since Alias had patented marking menus, they were afraid to use pie menus or anything resembling them for fear of being sued for patent infringement.
>I told them that sounded like bullshit since there was plenty of prior art, so Alias couldn’t get a legitimate patent on “marking menus”.
>The guy from Kinetix told me that if I didn’t believe him, I should walk across the aisle and ask the people at the Alias booth. So I did.
>When I asked one of the Alias sales people if their “marking menus” were patented, he immediately blurted out “of course they are!” So I showed him the ActiveX pie menus on my laptop, and told him that I needed to get in touch with their legal department because they had patented something that I had been working on for many years, and had used in several published products, including The Sims, and I didn’t want them to sue me or EA for patent infringement.
>When I tried to pin down the Alias marketing representative about what exactly it was that Alias had patented, he started weaseling and changing his story several times. He finally told me that Bill Buxton was the one who invented marking menus, that he was the one behind the patent, that he was the senior user interface researcher at SGI/Alias, and that I should talk to him. He never mentioned Gordon Kurtenbach, only Bill Buxton.
>So I called Bill Buxton at Alias, who stonewalled and claimed that there was no patent on marking menus (which turned out to be false, because he was just being coy for legal reasons). He said he felt insulted that I would think he would patent something that we both knew very well was covered by prior art.
Gee, who do we all know who lies and then tries to turn it all around to blame the person who they bullied, and then tries to play the victim themselves? https://en.wikipedia.org/wiki/Donald_Trump
Gordon Kurtenbach, who did the work and got the patent that Alias marketing people were bragging about in Bill Buxton's name agrees:
Gordon> Don, I read and understand your sequence of events. Thanks. It sounds like it was super frustrating, to put it mildly. Also, I know, having read dozens of patents, that patents are the most obtuse and maddening things to read. And yes, the patent lawyers will make the claims as broad as the patent office will allow. So you were right to be concerned. Clearly, marketing is marketing, and love to say in-precise things like “patented marking menus”.
Gordon> At the time Bill or I could have said to you “off the record, its ok, just don’t use the radial/linear combo”. I think this was what Bill was trying to say when he said “there’s no patent on marking menus”. That was factually true. However, given that Max was the main rival, we didn’t want to do them any favors. So those were the circumstances that lead to those events.
What's ironic is that Autodesk now owns both Alias and 3D Studio Max. Gordon confirmed that Alias's FUD did indeed discourage Kinetix from implementing marking menus or pie menus, which were not actually covered by the patent:
Gordon> After Autodesk acquired Alias, I talked to the manager who was interested in getting pie menus in Max. Yes, he said he that the Alias patents discouraged them from implementing pie menus but they didn’t understand the patents in any detail. Had you at the time said “as long we don’t use the overflows we are not infringing” that would have been fine. I remember at the time thinking “they never read the patent claims”.
Don> The 3D Studio Max developers heard about the Alias marking menu patent from Alias marketing long before I heard of it from them on the trade show floor.
Don> The reason I didn’t know the patent only covered overflows was that I had never seen the patent, of course. And when I asked Buxton about it, he lied to me that “there is no marking menu patent”. He was trying to be coy by pretending he didn’t understand which patent I was talking about, but his intent was to deceive and obfuscate in order to do as much harm to Kinetix 3D Studio Max users as possible, and unfortunately he succeeded at his unethical goal.
What's even worse is that in Buxton's zeal to attack 3D Studio Max users, he also attacked users of free software tools like Blender.
>The Alias Marking Menu Patent Discouraged the Open Source Blender Community from Using Pie Menus for Decades
>Here is another example that of how that long term marketing FUD succeeded in holding back progress: the Blender community was discussing when the marking menu patent would expire, in anticipation of when they might finally be able to use marking menus in blender (even though it has always been fine to use pie menus).
>As the following discussion shows, there is a lot of purposefully sewn confusion and misunderstanding about the difference between marking menus and pie menus, and what exactly is patented, because of the inconsistent and inaccurate definitions and mistakes in the papers and patents and Alias’s marketing FUD:
>"Hi. In a recently closed topic regarding pie menus, LiquidApe said that marking menus are a patent of Autodesk, a patent that would expire shortly. The question is: When ? When could marking menus be usable in Blender ? I couldn’t find any info on internet, mabie some of you know."
>The good news: Decades late due to patents and FUD, pie menus have finally come to 3D Studio Max just recently (January 2018)!
It's the 30 year anniversary of CHI’88 (May 15–19, 1988), where Jack Callahan, Ben Shneiderman, Mark Weiser and I (Don Hopkins) presented our paper “An Empirical Comparison of Pie vs. Linear Menus”. We found pie menus to be about 15% faster and with a significantly lower error rate than linear menus!
So I've written up a 30 year retrospective:
This article will discuss the history of what’s happened with pie menus over the last 30 years (and more), present both good and bad examples, including ideas half baked, experiments performed, problems discovered, solutions attempted, alternatives explored, progress made, software freed, products shipped, as well as setbacks and impediments to their widespread adoption.
Here is the main article, and some other related articles:
Pie Menus: A 30 Year Retrospective.
By Don Hopkins, Ground Up Software, May 15, 2018.
Take a Look and Feel Free!
This is the paper we presented 30 years ago at CHI'88:
An Empirical Comparison of Pie vs. Linear Menus.
Jack Callahan, Don Hopkins, Mark Weiser () and Ben Shneiderman.
Computer Science Department University of Maryland College Park, Maryland 20742
() Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303.
Presented at ACM CHI’88 Conference, Washington DC, 1988.
Open Sourcing SimCity.
Excerpt from page 289–293 of “Play Design”, a dissertation submitted in partial satisfaction of the requirements for the degree of Doctor in Philosophy in Computer Science by Chaim Gingold.
Recommendation Letter for Krystian Samp’s Thesis: The Design and Evaluation of Graphical Radial Menus.
I am writing this letter to enthusiastically recommend that you consider Krystian Samp’s thesis, “The Design and Evaluation of Graphical Radial Menus”, for the ACM Doctoral Dissertation Award.
Constructionist Educational Open Source SimCity.
Illustrated and edited transcript of the YouTube video playlist: HAR 2009: Lightning talks Friday. Videos of the talk at the end.
Empowered Pie Menu Performance at CHI’90, and Other Weird Stuff.
A live performance of pie menus, the PSIBER Space Deck and the Pseudo Scientific Visualizer at the CHI’90 Empowered show. And other weird stuff inspired by Craig Hubley’s sound advice and vision that it’s possible to empower every user to play around and be an artist with their computer.
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989.
Written by Don Hopkins, October 1989.
University of Maryland Human-Computer Interaction Lab, Computer Science Department, College Park, Maryland 20742.
The Amazing Shneiderman.
Sung to the tune of “Spiderman”, with apologies to Paul Francis Webster and Robert “Bob” Harris, and with respect to Ben Shneiderman.
Bartosz Milewski has a series of posts (a book, really) and recorded lectures that teach category theory with Haskell and C++ as reference points. HN discussion: https://news.ycombinator.com/item?id=14026360.
In case you haven't already used the following, please note that the NSA had an undocumented "backdoor" included which "disables" the ME. (Man, oh man, I wish I was making this stuff up.)
I put quotes around "disables" because the ME is not fully disabled. The blog's analysis does show how it is in a "safe" state, i.e. forced to ignore the outside world very early in its code path. Also, not likely to brick your computer, assuming unscrewing your case and using a SPI flash programmer hasn't already bricked your computer.
Everything you say is right. Some details look maybe a little different when viewed from the Newton team in Cupertino.
Yes, as the Dylan runtime got better, the Newton team wrote an OS in C++ with NewtonScript for scripting. There's more back story there, though.
Before any of that work started, an earlier iteration of the OS had already been written in the early Dylan, back when it was still called Ralph. There seemed to be some level of discontent in a few different quarters with that OS. Different people expressed different criticisms (that I heard). Different people assigned blame for their dissatisfactions differently.
It was all pretty good-natured, from what I remember.
But then John Scully told Larry Tesler: Let There Be an OS Written in C++. And there was. There is various gossip about exactly how that came to pass, but it did come to pass.
Larry asked me and a couple of other people to see what we could do with Dylan. We took that ball and ran with it--maybe too far. Like maybe Larry wanted us to run it down to the end zone and instead we ran it across the border and into Patagonia somewhere. We, the five of us or so, wrote a whole OS in Dylan, essentially competing with the 60 or so people working on Scully's mandated C++ OS.
I don't know why we did it exactly, except that we could, and it was really interesting. More to the point, I don't know why Apple management let us keep going with it so long. Morbid curiosity maybe? It did work pretty well, and I think there were some pretty interesting ideas in it.
From a business point of view, though, it was silly. Obviously Apple was never going to ship 2 Newton OSes. Equally obviously, it wasn't going to choose to develop our weirdo Lisp OS instead of Capps' C++ OS that was developed by almost the whole Newton team in response to an order from on high.
The period you describe, when Dylan was getting pretty good and the Capps OS had a lot of features and NewtonScript was pretty well working was well after the inflection point where the main group started working on the C++ OS. Our smaller team started on the second Dylan OS about the same time the other team started on their OS, and we made good (though pointless) headway. We used the same microkernel they did, and the same graphics infrastructure. Everything else in ours was written in Dylan. Dylan worked great.
In fact, that version of Dylan remains my favorite general-purpose programming language ever. I pretty much lost interest in Dylan when it stopped looking and working like a Lisp, but I've never liked anything else as much for day-to-day programming--not even Common Lisp, which is my go-to nowadays.
I was one of the Dylan programmers working on Senior (and Cadillac). I used to have a couple of the hardware prototypes, but I don't anymore.
I don't remember things being nasty, exactly, although I do remember that Larry Tesler authorized the switch to C++ because he was told to, rather than because he wanted to. I remember he looked kind of disappointed. The reason that I and about four other people kept workin in Dylan is that Larry asked us to see what Dylan could be used for on Newton. Our answer was "pretty much everything--see? Here's a working OS."
Realistically, that was the wrong answer, and we should have known it. I think we just got caught up in the really interesting intellectual challenge of inventing a novel OS around a novel Lisp, and nobody stopped us. As I said in the other comment, I don't know why management let us keep going as long as they did, but I'm gratedul.
I might well have been one of the unhappy faces you refer to, but C++ had nothing to do with that. By that point I had been using C++ regularly for about 4 years or so,ever since Apple first got AT&T's CFront, and in those days I still actually liked it.
Admittedly, I liked Lisp a lot better.
But no, C++ was not the source of my unhappiness. My unhappiness was because I had just poured heart and soul into a serious piece of work for about two years and I was having to say goodbye to it.
That's when I went to NeXT. A friend of mine had gone to work for them managing part of the software group and convinced Steve that he should hire me. So I went to NeXt and talked about Newton (because after two years of 100-hour weeks it was all I could talk about anymore) and Steve pitched me his hard sell about how I should be at NeXT.
That was definitely the intention. It was intended as a systems and application programming language for the Newton.
The original Apple implementation compiled to native ARM code. The runtime was intended to be competitive with C, but by the time we approached that target, large parts of the toolbox had already been written in C, and Walter Smith had created NewtonScript as a scripting language that worked as an alternative for non-performance-critical code. At that point the Cambridge team re-targetted the implementation to build Macintosh applications, but that wasn't a sufficiently compelling (to Apple management) use, and we had lost our executive sponsor when the director of the Apple Cambridge lab was promoted to a position in Cupertino.
(I'm the “Oliver Steele” mentioned on that page. I went to Apple Dylan from Skia – later released as Quickdraw GX – another technology that missed the Newton boat.)
Bresenham's line algorithms and the adaptation of the general principle to circles and arcs are absolute gems. I've used those over and over in the first two decades of my career and I never ceased to be impressed with the elegance and speed.
Surprising that people writing a book 25 years ago would not have been aware of this work.
I wonder how they define "classics" - two of my cherished titles from MIT Press are "IBM's Early Computers" (1985) and "IBM's 360 and Early 370 Systems" (1991).
They're examples of what I consider "The Perfect Computer Book".
My personal recommendations, mostly stuff I've got:
Soldering iron: I like the Hakko FX-888D. $90-110 or so. They have better if you can afford it, but that one's very good. The FX-951 is the next step up, and can take micro-soldering handpieces and has the quick-change tips. It's about $240.
Get a chisel tip, eg Hakko T18-S3, a bevel tip (T18-S6), and a bent-conical tip (T18-BR02). The conical tip is perfect for lots of general purpose work, you can use the fine point or the sides of the bend. The back of the bend can be used for drag soldering, the inside of the bend makes soldering wires together easy. The chisel tip is good for soldering things with more thermal mass (PCB-mount heatsinks) and the bevel tip is pretty necessary for drag soldering on QFP and similar surface mount packages.
Hot air station: Probably something cheap from china, there aren't any particularly affordable name-brand ones that I know of. Weller has the WHA900 for around $600.
Magnification: Get at least one of the magnifying headsets ($8-10 on Amazon) and a desk magnifier with LED ring light. Better option is an AmScope stereo microscope, such as the SM-4NTP and a ring light for it like the LED-144W-ZK. $480 total.
PCB vise: I have an Aven 17010, it works pretty well. MUCH better than trying to hold a board in the helping hands.
Flux: Get liquid flux with a syringe. Amtech is the best, but there is a lot of counterfeit stuff out there, and Amtech doesn't sell it directly (bulk orders only). https://mailin.repair/amtech-nc-559-v2-30-cc-16160.html sells the real flux.
Tweezers. Any ESD safe set.
Fume extractor: VERY important for health. You do NOT want to be breathing in flux fumes. A high-volume HIPAA air purifier on the desk works, ($150 or so) or a dedicated device like the Hakko FA430 is even better ($625).
Oscilloscope: Rigol DS1054-Z. 50MHz, hackable to 100MHz bandwidth easily. $400. There's no better cheap scope at the moment (IMO).
Function generator: Siglent SDG805. $270. Needed to give you analog signal inputs. Part of the big-3 of 'scope, power supply, and function gen.
Power supply: Get a linear supply. The Tekpower TP3005D-3 is $200, and is an actual linear power supply. The knobs are coarse adjust only (it's analog), I replaced the control potentiometers with 10-turn versions which substantially improved the accuracy of the output. There's also the Siglent SPD3303X-E ($340) if you want a digital panel version. You definitely need arbitrary +- voltages for lots of very basic circuits, PC power supplies are very limiting and too noisy if you do any sensitive analog design.
Multimeter: Get a safe one (HRC fuses, proper transient voltage suppression, etc.) Can't go wrong with Fluke, of course, but Extech, Brymen, and some others have cheap and capable handheld meters. $100-300, depending on brand. Be sure it has a micro-amp range! The really cheap ones don't, and you WILL need it if designing embedded stuff.
Logic Analyzer: Get a LogicPort. pctestinstruments.com. They're $390, for a 34-channel 500MHz device, very nice for the money. Needed if doing much digital work. (Keysight's 34-channel standalone analyzer is $12165 base price. 5GHz, but still, twelve grand...)
Spectrum Analyzer: If you're doing RF work (radio design), you'll need one. Otherwise skip it. The Siglent SSA3021X with tracking generator add-on is $1764 (pretty cheap) and quite capable (9kHz to 2GHz). It's also hackable / software upgradeable into the 3.5GHz model. The Rigol DSA815-TG is $1550, but significantly worse (smaller display, worse resolution bandwidth, max 1.5GHz, etc).
Be sure to get a GFCI outlet and a GFCI adapter or two. The oscilloscope, function gen, spectrum analyzer, etc, all are mains earth referenced, and should each have their own GFCI plug. If you accidentally connect the ground lead of any of them to something other than ground the GFCI will trip and prevent the ground traces from being blown up inside the device. They're about $20 each, well worth it IMO.
You might want an anti-static mat and wrist-strap.
Get a bunch of small drawers, eg https://www.amazon.com/gp/product/B000LDH3JC. Print labels for them, use them to store resistors, capacitors, and other types. You can fit two values of component in each drawer (though they don't come with enough dividers :/). You want at least 96 drawers for resistors and 32 for capacitors assuming you're buying 1% or 5% resistors and 10-20% capacitors (pretty normal). I bought a kit of resistors (https://www.amazon.com/gp/product/B017L9GKGK) and (https://www.amazon.com/Joe-Knows-Electronics-Value-Capacitor...) for capacitors (Joe Knows Electronics kits are good for stocking up, they have more of the most common components in their kits.)
Get some desoldering wick and a solder sucker too. Also some tip tinner, and/or a sal ammoniac block. Make sure you have a roll of kapton tape to hold parts down while you solder them (it survives high temperatures). If you'll be doing a lot of surface mount you'll want a reflow oven and solder paste.
EDIT: One tip I forgot, very important: When you buy parts (on DigiKey/Mouser or similar) make sure you buy extras. At least the number needed for the first volume discount or 10, whichever you can afford. 3x the number needed for the project at the minimum. You WILL drop parts, burn them out, and otherwise damage them. It's much easier if you already have spares, don't have to wait for shipping, and don't have to pay for shipping. This will also help you develop a parts library, as you do more projects you'll be likely to re-use common parts and already have many left over from past work.
The most important operation in QNX is MsgSend, which works like an interprocess subroutine call. It sends a byte array to another process and waits for a byte array reply and a status code. All I/O and network requests do a MsgSend. The C/C++ libraries handle that and simulate POSIX semantics. The design of the OS is optimized to make MsgSend fast.
A MsgSend is to another service process, hopefully waiting on a MsgReceive. For the case where the service process is idle, waiting on a MsgReceive, there is a fast path where the sending thread is blocked, the receiving thread is unblocked, and control is immediately transferred without a trip through the scheduler. The receiving process inherits the sender's priority and CPU quantum. When the service process does a MsgReply, control is transferred back in a similar way.
This fast path offers some big advantages. There's no scheduling delay; the control transfer happens immediately, almost like a coroutine. There's no CPU switch, so the data that's being sent is in the cache the service process will need. This minimizes the penalty for data copying; the message being copied is usually in the highest level cache.
Inheriting the sender's priority avoids priority inversions, where a high-priority process calls a lower-priority one and stalls. QNX is a real-time system, and priorities are taken very seriously. MsgSend/Receive is priority based; higher priorities preempt lower ones. This gives QNX the unusual property that file system and network access are also priority based. I've run hard real time programs while doing compiles and web browsing on the same machine. The real-time code wasn't slowed by that. (Sadly, with the latest release, QNX is discontinuing support for self-hosted development. QNX is mostly being used for auto dashboards and mobile devices now, so everybody is cross-developing. The IDE is Eclipse, by the way.)
Inheriting the sender's CPU quantum (time left before another task at the same priority gets to run) means that calling a server neither puts you at the end of the line for CPU nor puts you at the head of the line. It's just like a subroutine call for scheduling purposes.
MsgReceive returns an ID for replying to the message; that's used in the MsgReply. So one server can serve many clients. You can have multiple threads in MsgReceive/process/MsgReply loops, so you can have multiple servers running in parallel for concurrency.
This isn't that hard to implement. It's not a secret; it's in the QNX documentation. But few OSs work that way. Most OSs (Linux-domain messaging, System V messaging) have unidirectional message passing, so when the caller sends, the receiver is unblocked, and the sender continues to run. The sender then typically reads from a channel for a reply, which blocks it. This approach means several trips through the CPU scheduler and behaves badly under heavy CPU load. Most of those systems don't support the many-one or many-many case.
Somebody really should write a microkernel like this in Rust. The actual QNX kernel occupies only about 60K bytes on an IA-32 machine, plus a process called "proc" which does various privileged functions but runs as a user process. So it's not a huge job.
All drivers are user processes. There is no such thing as a kernel driver in QNX. Boot images can contain user processes to be started at boot time, which is how initial drivers get loaded. Almost everything is an optional component, including the file system. Code is ROMable, and for small embedded devices, all the code may be in ROM. On the other hand, QNX can be configured as a web server or a desktop system, although this is rarely done.
There's no paging or swapping. This is real-time, and there may not even be a disk. (Paging can be supported within a process, and that's done for gcc, but not much else.) This makes for a nicely responsive desktop system.
It didn't actually, but in this case the computer allows things cleaner than biology. We could have gone a lot farther in making the interior of an object a real object space rather than what we did. Years later we did try that, and it is a good idea.
Also, take a look at the article I wrote for Scientific American in September 1984 "Software" that talks about organizations of active objects as "tissue programming"
