I'm using an old version of Postman with their servers blocked through the system hosts file. I keep meaning to migrate to whatever the next best thing is but this setup just works for me.
this is really microsoft's fault for handing out kernel access to random 3rd parties, none of which are doing anything special that microsoft couldn't implement themselves (AV, anti-cheat, security)
Or do what Apple does, disallow kernel extensions, and provide rigid kernel faciltiies for VPN clients, EDR agents, etc. to use, so they don't have to implement custom code resident in the kernel.
Apple can disallow kernel extensions because it fully controls the entire hardware and software stack. Everything that would need to be an extension is already in the kernel and Apple knows all of those things.
Use LTSC, it's marketed for "enterprise" but it's functionally identical to the regular versions with the bonus of advanced configuration that lets you disable AV, forced updates, telemetry, ads, etc.
I looked on Microsoft's site but all it says is
to contact their sales team. Did you have luck with that process? Usually when a company says 'contact sales' that means it is very expensive.
It seems like Microsoft are afraid to make it easily available because if word got out every enthusiast and power user would switch leaving them without the ongoing ad revenue.
You need to buy into Volume Licensing, which requires at least 4 licenses. You can't buy it directly from Microsoft, but there are resellers that will sell it to you ( https://appsource.microsoft.com/en-us/marketplace/partner-di... ). It works out to about $200.
Afterwards, you'll be able to buy an LTSC license. It's around $300 per device.
I'm pretty sure that individuals can't just buy any Enterprise edition, this one included. Everyone, or almost everyone who's running LTSC outside of enterprise settings is doing so through "other, mysterious ways" that I'm not sure I can mention on here. There may also be unrelated scripts that can strip a normal install of Win10 into something resembling LTSC, but I might be misremembering.
I mean how should I know? The point is that I suspect there could be another option, which is that the pressure hull could have failed without imploding.
So, yes it seems insane, and having seen pictures which look both like that is a liner and ones where it looks like its not, I don't know. There is very clearly an outer shell offset from the pressure hull. Whats on the inside isn't as clear, but I'm not sure why they would be running cables out of the floor when they could just be running them out closer to the arm/etc if there is space behind.
Although from a human comfort perspective, I'm not sure why there isn't a little foot well/bench either. There is obviously stuff under the floor, but it also looks fairly hollow too.
No. I know what DI is. The debate is similar to imperative vs. OOP. But this is not exactly what I am referring to. Literally look at the second example, it's DI over and over and over again.
I am referring to DI 100%. Function composition works better and is a replacement for DI. You're the one that isn't getting it.
Either way, imperative programming and OOP are orthogonal concepts. There never really was an argument about imperative vs. OOP.
Additionally function composition is an FP concept. I'm not promoting FP over OOP here... far from it, I am simply saying that specifically for DI, you can borrow a pattern from FP and use it in place of DI because function composition is a much better pattern.
Not sure why the author decides to single out DI frameworks as a problem. In most cases DI is just an implementation detail for how the framework serves up its abstraction layer over the underlying mechanisms. For example, Spring is built around injecting beans so it can wrap them in proxies which provide transaction managements, security, etc. Sounds like he's really just criticizing frameworks in general.
On the topic of DI, it's such a simple and common-sense design "pattern" that it shouldn't even have a buzzword label. All it means is that, given service A which uses service B, it's not service A's job to instantiate B and provide B with its required sub-dependencies (DataSource, config params, etc). A should only consume B without concerning itself as to how B was created in the first place. This is usually handled by some "container" service whose job is to build-up every other service and make them accessible to one another so they may be strict consumers without transitive dependencies.
There's a hundred ways to mask your selling identity, this law won't change anything except, as usual, placing more bureaucratic baggage on honest sellers.
