I enjoy the general feeling of the book, like claustrophobia inside something that grows infinitely. That's the best way I can describe it, but I haven't gotten more than a quarter of the way through. I do need to go back and fully read it.

I often have a lot of time between projects, and am able to really think about things, and write the code that I'm happy with. Even when I do that, I do some more research, or work on another project, and immediately I'm picking apart sections of my code that I really took the time to "get right." Sometimes it can be worse if you are given vast amounts of time to build your solution, where some form of deadline may have pushed you to make decisions you were able to put off. At least that's my perspective on it, I feel like if you love writing software, you are going to keep improving nearly constantly, and look back at what you've done and be able to pick it apart.

To keep myself from getting too distressed over looking at past code now, I tend to look at the overall architecture and success of the project (in regards to the performing what it was supposed to, not necessarily monetarily). If I see a piece of code that I feel could have been written far better, I look at how it fits into the rest. I tend to work on very small teams, so I'm often making architecture decisions that touch large areas of the code, so this may just be from my perspective of not working on a large team. I still do think if you care about your craft, you will be harsh on yourself, more than you deserve.

Although I probably don't make nearly as much as that COBOL developer over 20 years later, I would be willing to bet that I am happier and haven't locked myself into a specific technology the way that developer probably has. Money is great, but if you actually care about what you do, I expect that being stuck on the same codebase for years isn't too satisfying (at least on code you didn't have a hand in creating from the very start). Too many people translate money into happiness, and I guess there is a balance there, but usually it's not possible to maintain happiness based off money when you do the same thing day in and day out.

I don't blame companies that already tied up in IBM tech for sticking with what they already have. As boring and dated as IBM tech might be, it's still running a ton of infrastructure, and you don't get to be that kind of company without being solid and reliable. That's what companies want, even if a development team wants to flex their skills in something new and not tied to IBM.

I started House of Leaves a couple times, but I always end up spending more time online than reading fiction. I need to actually sit down and read it. I used to read lots of fiction before my addiction to technology. Every five years or so, I go back and read Herman Hesse's Steppenwolf, but it's a fairly small book to get through. I bought the House of Leaves version that has color coding and bizarre layout (not sure if that was always in every version). I suppose I spend enough time watching horror movies and playing odd games that I could afford the time to read House of Leaves.

I do watch a lot of amateur found footage films on YouTube, along with analog horror. I remember when Blair Witch Project first came out, and it reminded me of strange dreams and nightmares I've had, and I think that's part of where the attraction to liminal spaces comes from. It's something humans can relate to, but it's harder to put a specific label on the feeling you get when consuming this type of content.

Maybe I'm misunderstanding the link to Chinese vs. non-Chinese router vendors?

Eventually I got all the devices marked from origin to their patch cables in the server room, and I started looking into the Squid cache. It turns out that they were caching everything, as well as blocking websites. I figured out what websites they needed to do their job, and turned off caching, while also learning the ACLs for blocking websites. Anything else was allowed, but the Squid cache would hold a copy for some set amount of time (I think it was 24 hours, so if it was legitimate they only had to wait a day, but it also saved on bandwidth by quite a bit - although think this was used more to monitor user activity).

It was frustrating as someone new to large LANs, as well as to in-house caching, but had been using Linux since an early version of Slackware in the later 1990's. Even to this day, as someone that writes software and does DevOps, that knowledge has helped my debugging skills tremendously. Dealing with caching is a skill I feel you need to be burned by in order to finally understand it, and recognize when it's occurring. I cut my teeth on Linux through a teacher that set up a web server in 1997, and not only gave students access to upload their web files, but also a terminal to message each other and see who was online.

Or instead, is it mistakes being made migrating to Azure, rather than Azure being the actual problem? Changing providers can be difficult, especially if you relied on any proprietary services from the old provider.

I didn't downvote you, but I suspect combining PRs with issues is what most people have an issue with. Issues obviously help to improve software, but only through the fixing or writing of new code.

Maybe I'm in the minority, but I also think that if it were a requirement to never close source your project after it's already been open sourced, we'd have far fewer projects available that are open source. Often a project is created on a company's dime, and open source, to draw attention to the developer skills and ability to solve a problem. If the code was legally disallowed to be close sourced in the future, we might see far less code available universally. A working repository of code is potentially a reference for another developer to learn something new. I don't have any examples, but I know for a fact that I've read code that had been open source, and later close sourced, and learned something from the open source version (even if it was out of date for the latest libraries/platform).

I hate that a company can take a fully open-source project, and then turn it into a commercial offering, dropping support for the project's open source model. I am fine with a project's maintainers stopping support for a project because they have other things to deal with, or just are burnt out. I understand that both of these things are allowed under the specific license you choose, and still believe you should have the freedom to do what was done here (although not agreeing with the idea of what was done, I still think it should be allowed). If you want to guarantee your code is allowed to live on as fully open, you pick that license. If you don't, but want to contribute as a means to selling your talent, I still think the world would have far less software if this was discouraged. The source is still legal from before the license was changed, and I feel that even if the project doesn't get forked, it is still there for others to learn from.

With that said I'm wondering if there has ever been a legal case where source was previously fully open source, then became closed source, and someone was taken to court over using portions of the code that was previously open. It seems like it would be cut and dry about the case being thrown out, but what if the code was referenced, and then rewritten? What if there was code in the open source version that obviously needed to be rewritten, but the authors closed the source, and then someone did the obvious rewrite? This is more of a thought experiment than anything, but I wonder if there's any precedent for this, or if you'd just have to put up the money for attorneys to prove that it was an obvious change?

It sounds like you've got some great options either way. I wish I had a neighbor growing up that had cool music gear (although I did get to grow up with a dad that got me into computers before I could read, so that definitely built my love for technology). Sounds like you're the kind of dad more kids these days need in their lives.

When I last reissued an EV SSL (recently), I had to create a CNAME record to prove domain ownership, as well as provide the financial institution's CEO's information which they matched up with Dun & Bradstreet and called to confirm. The entire process took about three days to complete.