As for how to market yourself: first you should convert your academic CV to one that is suited for the type of companies you are applying for. Unless you wrote something that ended up in Nature or some other super high profile journal, companies typically don't care about your publications. What they do care about is things like: can you communicate well? How well can you organize things on your own? Do you handle stress well? You did a PhD, so the answer to those things is yes, you just need to write that in your CV in a way a company recruiter/interviewer understands, even if they themselves are not from academia. So you don't have two halves that belong to different resumes, you are just one person and you just translate your resume to the "language" that your prospective job provider speaks.

Finally, your list of skills does not need to be a perfect match for what a company is looking for. Of course, there needs to be some overlap, but as long as it means you can pick up new things quickly, it will be fine. That and being a good fit for the company's culture are the most important things.

I did not start out with a unicorn role, but in I found ways to apply my physics background in my current job.

As for CMYK support: why do designers even need to use this? Sure, not every RGB is the same, and it took some while before we even got sRGB as some standard, but the same goes for CMYK: every printer has its own profile. I had the displeasure of trying to get the CMYK profile of a "professional" printing company that only accepted files in CMYK, and they didn't even know which profile their printers used. Ideally you would send a RGB file including the display profile your screen uses, and then the printing facility converts that to whatever CMYK they need.

Of course there are also special colors or effects outside of RGB/CMYK that you might want to use when printing something, that's something else.

The three drawbacks of the original TCP algorithm were the window size (the maximum value is just too small for today's speeds), poor handling of missing packets (addressed by extensions such as selective-ACK), and the fact that it only manages one stream at a time, and some applications want multiple streams that don't block each other. You could use multiple TCP connections, but that adds its own overhead, so SCTP and QUIC were designed to address those issues.

The congestion control algorithm is not part of the on-the-wire protocol, it's just some code on each side of the connection that decides when to (re)send packets to make the best use of the available bandwidth. Anything that implements a reliable stream on top of datagrams needs to implement such an algorithm. The original ones (Reno, Vegas, etc) were very simple but already did a good job, although back then network equipment didn't have large buffers. A lot of research is going into making better algorithms that handle large buffers, large roundtrip times, varying bandwidth needs and also being fair when multiple connections share the same bandwidth.

I'm hoping Charles Stross knows this, and you should take his predictions as "this is what would happen if we did absolutely nothing about it".

While I would like a pure Linux phone, I think the only reasonable course of action is Android with something like Samsung's DeX on top. Maybe that is something they could do, but I don't see this happening any time soon.

So, there is nothing revolutionary going on there, this paper is more about how to build a system with micro-LEDs and a photodetector and how to remove any inherent biases in that system, with the obvious benefit of being able to make something very compact.

Definitely. And not only companies; even Debian rejected some packages because the upstream owners added restrictive "desires" on top of the actual licenses.

I see only two possible paths for another GPU on RPis in the future: either Broadcom drops the VideoCore GPU and switches to Mali or Adreno (which I think is unlikely), or RPi stops using Broadcom SoCs and switches to something completely different. Still unlikely, but now that they have the RP1 chip taking over most of the I/O functions, it would not be too hard for them to change and still make boards that retain compatibility with existing hats.

Still, the RPi is made at a certain pricepoint, which very likely precludes putting in a flagship SoC, so even if they change, I'm not sure it will do wonders for GPU performance.

Tinc 1.1 should make setting up easier; it has a CLI to set up and add nodes without having to manually edit config files. And you can generate invitation URLs which can make it even easier.