I don't disagree with your sentiment, but I think it's interesting that this reached the front page of HN at all, and I have to think it's _because_ of the cult of personality around Musk.
Some of these comments suggest that having satellite internet onboard a cruise ship is a new thing. It's certainly not.
After some quick googling it looks like the current provider is O3b Networks (now part of SES), using modem equipment manufactured by ST Engineering iDirect.
I somehow doubt that when O3b Networks won that contract in 2013 it made the front page of HN. But now, there's "SpaceX's Starlink" in the title and it sits on #7 on the front page with 130+ comments.
I don't venture too far on the internet, but the only thing like a cult of personality around Musk I've seen is the anti-Musk cult going on and on about how he is a "garbage human", he's a fraud, not a real engineer, and how annoying his cult followers are, when it comes to any vaguely related topic.
This story for example, of the comments where Musk is first mentioned in a thread, 3 (including the dead one) are anti-Musk, and 1 is neutral (using Musk as shorthand for Musk's businesses), and zero are positive. Nothing rabidly pro-Musk.
So I rather think stories like this are being upvoted because people like hearing about travel, internet and comms, rockets, satellites, and the like. I don't think it's very charitable to think it's only due to some vapid Musk fan club.
I've been playing around with it for a bit, but I don't really see what it has to offer that Vagrant doesn't already do.
"multipass launch" and "multipass shell" do the same as "vagrant up" and "vagrant ssh".
Vagrant has been around since 2010 and is super mature by now. Multipass seems to be limited to LTS Ubuntu releases, for now at least. There are Vagrant boxes for all Ubuntu releases but also Debian, CentOS or whatever else you would want to run.
The advantage over Vagrant is that it's a lot less complex. I've tried Vagrant on Windows before and really struggled with it, when all I wanted was a quick and easy way to launch lots of VMs.
They're marketing this as a "mini-cloud". If it can only network through NAT, that eliminates all use cases where the VM instances would act as a server.
I'm a sysadmin, so I like tools like this to test out provisioning of servers with configuration management such as Ansible or Puppet.
Running tests at the end where I actually test the endpoints of the deployed services would be really nice to have, but impossible to do through NAT.
I guess that's a niche use case for this because Vagrant had the same issue for a long time, where setting up a bridged network was not possible or required some hacks.
> They're marketing this as a "mini-cloud". If it can only network through NAT, that eliminates all use cases where the VM instances would act as a server.
Think about this as if you want to carry around 3-4 hosts running different services and interacting with each other... on your laptop.
You don't really want bridged networking, because you connect to a different network and screw up the entire environment with different numbering, etc.
This way you can be on a plane without network access and still get work done, or carry a complete demonstration environment to a customer site, or...
For a DevOps tool this seems way more developer-oriented than ops-oriented.
This streamlines the use cases where I need a _local_ VM that I can access from my workstation; I don't need (or even want) a tool like this to generate VMs that are externally accessible.
Vagrant — as you pointed out — already does the thing you want it to do. It's more powerful, more flexible, and more complicated.
I'm missing something - even without bridged networking, the VMs should still be able to network with each other, and the VM host should also be able to reach each VM. So I don't see how the lack of bridged networking prevents you from testing the deployed VMs. Do you need to control the tests from somewhere outside the VM host?
NAT networking does not imply the host running Multipass can access ports exposed on the VMs, quite the opposite. Host only would imply that, but not typical NAT in a virtual machine. Not saying it’s not possible with Multipass, just saying it shouldn’t be assumed it does.
Generally if you are on a router performing NAT, you have routes to the hosts behind the NAT. Whenever I've used VMs with NAT I've been able to interact with the NAT'd network from the actual hypervisor host.
Yes, VirtualBox is an exception, because it does its own weird NAT.
VMware:
> The host computer has an adapter on the NAT network (identical to the host-only adapter on the host-only network). This adapter allows the host and the virtual machines to communicate with each other for such purposes as file sharing. The NAT never forwards traffic from the host adapter.
Libvirt/KVM:
> By default, guests that are connected via a virtual network with <forward mode='nat'/> can make any outgoing network connection they like. Incoming connections are allowed from the host, and from other guests connected to the same libvirt network, but all other incoming connections are blocked by iptables rules.
Hyper-V lets you connect from host to NAT'd guests, though the documentation doesn't explicitly say this. Parallels works this way too. Xen is a weird one, because it doesn't really do the NAT itself; if you follow the Linux instructions it'll work the way I describe.
While I agree, some hypervisors act differently, but my original comment stands as due to at least one major hypervisor not allowing direct host access to NAT’d VMs, you can’t assume it works given no context.
Either way, thanks for the research. I stopped after checking VMware.
I thought it might be since it's so obvious but discussing a similar topic with coworkers a few days back had a similar situation where someone just frames the argument in a time window that explains their narrative - I wouldn't be surprised if someone argued this because of the US economic dominance post WW2
This particular horse is mentioned in the very first sentence of the introduction of the paper.
I think it's a worthwhile study, especially considering such dogs are currently still used in law enforcement. It's important to be aware of the shortcomings and biases of this methodology, and to do so in a sound, scientific manner.
Interesting; I believe the creation of the 500 bill was at the request of Germany. This is the second visible 'give in' from Germany after not getting their candidate at the head of the ECB. Makes you wonder what they have traded this for.
I'd agree (and that's what I did) except here I'd suggest "maybe wait until they solve the core overheating issue".
Mine is idling at 64°C now that I took off the official cover; with the cover on, it was idling just below the CPU throttling point of 80°C, which meant that almost any computation caused it to start intermittently locking up.
Odd, mine is idling at 49 C in a 21 C room. This is the 4G version running fully updated Raspbian without the desktop (one of the updates fixed the USB controller using a lot of power at idle).
Mine is 4G too; I installed heatsinks on it couple hours ago and it now sits at 61°C idle, with an external HDD attached (but not under I/O load) to USB 3 port. Slightly better, though arguably still ridiculously high.
It looks like it'll be mitigated (https://www.tomshardware.co.uk/raspberry-pi-4-firmware-updat...), but not necessarily fixed- making a difference of a few degrees. Active cooling makes a huge difference, which is why it baffles me that the official case has no ventilation.
I did not buy the official cover, but a cheap top/bottom (but not side) acrylic case that included a fan, and also applied 3 heat sinks which came in the basic kit that came with the pi from canakit. It idles at 47°C and can browse "new reddit" at 59°C. A samba share its hosting causes it to run at 59°C during file transfers to an external SATA drive connected to the USB 3 port. I'm pretty happy with it considering all the complaints about heat issues. Only issue I've had so far is that you cannot reliably power more than one external hard drive with this. A second one will need its own power adapter.
There was a firmware update, so make sure you applied that. Might help bring the temps down a bit.
You'll be waiting for a Pi4+ or a Pi5, then. They've had similar "minor" bugs with trivially easy hardware fixes on older boards, but punted on fixing them until the next major version. I could be wrong, but AFAICT, they've never done a minor board revision for an already released Raspberry Pi.
