I would not recommend Safari as I have completely stopped supporting it many years ago due to Apples hostile approach towards developers and the fact it's broken beyond internet explorer levels and has been in this sorry state for at least a decade. I don't know if people still using it have some special use cases or just don't know you can install another browser.
Sure. But CVEs don't enumerate RCEs/vulnerabilities that reveal user passwords - they care about a superset of all of that. And when you look at the common vulnerabilities in phpBB3, "phpBB3 hasn't had a single severe vulnerability" seems like very selective language.
I am merely giving my unprofessional opinion that phpBB(1+) has only caused harm. A significant portion of leaks seem to be attributed to it. They really could have done better, and their reputation is forever dead.
To make clear: I am sure that the current version of phpBB works just fine and isn't as disease ridden as we all know it to be. However, the fact that all of these issues have existed for so long means that perhaps we need to take a look at the software as a product and determine that its performance has not been good enough, and to expect similar performance in the future.
Beware of VirtualBox. While part of it is free, it's not very useful without the extension package. This package is easy to download on the same website as VirtualBox, but... it's not free.
Even better Oracle tracks the ips that download this extension and after a suitable amount of time they will come knocking on your company's door asking for an insulting amount of money (e.g. more expensive than VMware) or get sued. You need to read the fine print of the additional Eula printed in really small letters on the VirtualBox website to figure out the extension isn't free. It's almost a honeypot tactic. Scummy.
I don't know how Macs fare, but on Linux the extension package is not really a great feat, mostly adds RDP and some faster USB modes, but USB passthrough is marginal at most anyway.
That's a reductive way to phrase it, but more or less yes.
It's arguable if the container is "virtualized linux" as they all share a single linux kernel. In reality there's one virtual machine, one linux kernel, and many linux userspaces (one per container), which is kinda the whole point of containers.
Over docker+linux, the virtual machine is the only additional layer.
fwiw, I personally don't use macOS, so I've only got virtualized linux (containers) run by docker running on linux running on my hardware.
Are you trying to make a point or something here? Like, yes, we've built layers of abstraction that include different types of virtualization (VMs and containers), and they compose. Is that all you're observing?
> Are you trying to make a point or something here?
Nah, just curious/intrigued by how these stack.
OS-level virtualization is very much a thing. I'd be interesting to compare this to the approach taken by Docker Dekstop for Mac. I bet they do something quite similar (hypervisor-based virtualization like Virtualbox) - nothing fancy like WSL1 that I believe runs a sort of "tortured" Linux kernel inside the NT kernel.
WSL1 didn't run a Linux kernel at all - it was implementing the Linux user-space API over the Windows NT kernel. Well, some of it - not enough to run Docker, for example.
Docker on Windows and Mac does the same as what is described above - it runs a Linux VM and runs the docker server inside that, and then does a little magic to expose native OS paths and so on to that VM. On Windows, it uses WSL2 by default now, but WSL2 is also a Hyper-V VM in the end, with some Windows magic to blend it more nicely in Windows workflows.
That’s how it has to work when there’s a kernel mismatch from host to guest. You’re implying more layers than there actually are.
- MacOS running a hypervisor
- A Linux VM with Docker installed.
- A Linux container running on that VMs kernel.
Containers on Linux aren’t virtualized (normally, you could use runV I suppose if you wanted). The only overhead is the extra disk space to extract the root fs of the container image and the namespacing.
I’m also using Hyperkit w/ minikube, and after some heavy setup automation it works pretty great. What I worry about, though, is what I’m going to do when I switch to a Mac w/ Apple Silicon. AFAICT Hyperkit is x64-only.
From a skim read of both blog posts it's still impossible to understand what's actually new in this version. Just introduce the features in the post, no?
