I'm not an expert on this, but know enough to know the KVM doesn't need its own IP. In fact, the KVM I replaced it with provides ethernet to both my machines (at the same time) without getting its own IP.
The network was active for both machines connected to it. And it had its own IP. So 3 MAC addresses in total. I didn't ever open it up. But maybe someone will be interested in buying one and exploring more.
The KVM didn't have any documentation on anything related to its network interface. I ran a port scan on it but didn't know if there was a way to log into it.
I recently discovered a similar concerning security issue with my KVM. In my case it was a pretty standard KVM for multiple machines to share a keyboard, mouse, and screen but also Ethernet. One day while looking at my home network I noticed the KVM had its own IP and was transferring GBs of data everyday. I quickly blocked it from my network. But having used it for a number of months I worried that with screen capture and access to all my input devices, someone could have gotten access to pretty much everything I use. I wasn’t able to figure out if any data was actually being sent off my network and I really didn’t want to put myself in any more risk so I just threw it in an electronics recycling bin. Pretty scary what a network connected KVM could maliciously do.
The book uses Scala & ZIO but intends to be more about the concepts of Effects than the actual implementation. I'd love to do a Flix version of the book at some point. But first we are working on the TypeScript Effect version.
Author here. Yeah, the Go language feels very archaic when using more modern languages. Some things I miss when I use Go: immutability as a default, monadic error handling, type classes, higher-kinded types, high-level collection operations (map, flatmap, filter, etc), ADTs, extensive pattern matching, expression-orientedness, and explicit null handling.
The switch to Google Maps will definitely be nice since their current maps are crap. Not sure about the other pieces but it probably can't get worse than it currently is. I have the newest XC90 and the on-screen stuff is absolutely horrible. I run into many bugs every day and the response from support has been abysmal.
"Where will the next great programming language come from?"
Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)
> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.
While 12 Factor does say that processes should be stateless I've never thought it really meant it. Connection Pools and in-memory caches are pretty typical in 12 Factor (or all non-serverless) apps. And for me that is what makes serverless kinda silly. Some global state is actually pretty useful when you can avoid the overhead of initializing things or going over the network.
I actually feel and do the exact opposite. I find code on slides to be boring. When I present I want to give the audience an experience like they will have. Live coding can do that well. But it certainly can go bad quick. Live coding on stage takes a TON of practice. Most presenters don't put in the prep so it comes out boring and fail-prone.
Probably the most important thing I've learned in 10 years of tech presentations is that every person in the audience learns in a different way and wants something different. You can't please everyone no matter what you do.
The difference is that a password manager must be able to decrypt a password in order for it to be used, while ideally websites only store one-way hashed passwords which if stolen aren't always useful at gaining access to other sites.
A year into this I'd love to hear a cost benefit analysis including infrastructure & ops cost, uptime, disaster recovery, security management (key rotation, heartbleed-like threat mitigation, etc), and overall developer happiness.
The reloading part of Play doesn't use bytecode manipulation, it simply creates a new classloader with the newly compiled stuff and then uses the new classloader on subsequent requests. There are other pieces of Play 1 & 2 that do bytecode manipulation. In Play 2 this is pretty minimal when using Java / EBean.
I'm also curious about this. If there is no downside of filing a false DMCA complaint then what prevents someone from causing the receiver a ton of unnecessary work?
Good point. I should have put more details in there. I prefer static typing with good type inference because it allows me to have a compiler validate a lot of my code pre-runtime. Otherwise I'm left with tests and actually running all of the code to do that validation. The value of this for large code bases has been worth the tradeoffs in my experience. But since this is one of the most debated things in programming I don't expect to sway anyone. I'm happy to leave this as an item of "it depends" / personal preference.