Posts by DJohnson 14 publicly visible posts • joined 26 Jul 2020
Thank you, Iain and the whole team, for posting this kind of news. I'm guessing the lack of 'engagement' this many hours after it dropped was due to everyone doing roughly the same thing: Rushing to download the files and start planning the update before someone starts screaming about it. Thankfully (at least late last night in the US) the download site behaved itself. This time....
Aye. If I ever decide to buy another house, I'm going to see if Cy (https://www.youtube.com/@cyfyhomeinspections) has any recommendations for upstanding quality inspectors in my region. The "inspection" on my current 1950's abode was a joke. "You've turned off all the breakers, and the bathroom is still on...isn't that a problem?" "Nope, all good"
I would have sworn that somewhere I'd seen that NASA originally indicated that it was Japan who was responsible for the batteries because they were the ones who originally sent them up. Perhaps I'm too tired to search properly, all I've found tonight is a comment on Reddit: https://www.reddit.com/r/space/comments/1c7g45q/comment/l07ryiy/
A fair question, but the answer is 'portability'. The only glimpse the guest OS has of the real hardware is the CPU make & model. The rest is all an abstraction, so at any point in the future you can shift to a new/different system (even with wildly different hardware) and the VM will be blissfully unaware. You don't need to hope and pray that 1) the OS doesn't complain about X and Y changing, or 2) the admin updating config items doesn't miss one.
Yeah "reload after arrival" is what led me to conclude that a known-good starting point would be needed. From there sure you can install a normal read-write OS and decrypt a set of SSH keys, etc.
Oh nothing special, just a privacy-loving American contemplating travel to Europe and the Middle East in the future. I figure the odds of someone _actually_ taking an interest in me or my gear is low, but if I can come up with a rough plan that doesn't cost much (in money or time) then it's worth a little extra precaution.
Along the same line, I'm still looking for a USB-connected mass storage device based off of an EPROM. "Are you insane?" Maybe but hear me out.
I want a portable near-universal bootable device which is _inconvenient_ to change or erase, and which would require breaking a tamper-evident seal to do so. Something I could travel with and know that even if it's out of my sight for short periods, the intact seal is a good sign that it's contents have not changed. If border security wants to read it, go ahead. Make copies for all I care. But when I get to my destination I can use it to boot a system to a software environment I trust, and from there I can import other (more mundane) storage.
The closest I've found are a line of flash drives from Kanguru (https://www.kanguru.com/) that have a physical write-protect switch. The one I bought for my initial playing around isn't going to win any speed awards but that's fine. I figure I could file off the tip of the switch plastic and use a clear heat-shrink sleeve as the tamper-evident seal over it.
The prominence of EEPROM and the explosive mis-use of the term 'ROM' in the last 20 years has not made my searches very productive... but I suspect there wasn't any great interest in UV-erasable storage with 2-4GB per chip.
Sure, with the free license ESXi runs quite happily by itself. The only real downside is limitations on what APIs are available for things like backups. Getting a vCenter license is going to set you back a pretty penny, I wouldn't expect a home lab to pony up for it.
If you do though, remember that vCenter doesn't _do_ anything directly so having it hosted in the cluster it manages is fine. In fact, that's pretty normal. My only caution would be if you plan to run a Distributed vSwitch: Do us a favor and pre-create an "Ephemeral" portgroup. That saves a bit of hassle in certain failure recoveries.
GAH, no, please no! An organization I support is behind a cable modem, and due to ISP-enforced port limits the only approach I can currently use is the DNS verification. The DNS provider has no provision for automating the record update so I have to do this manually. I'm probably not the only one who does NOT need yet another weekly critical-to-someone task.
It's one of those delightful issues that may not show obvious symptoms for days or weeks, so it's actually easy for people to do all the right testing and still miss this. If you're looking at the vmkernel log you *might* notice some extra churn before host issues pop up.
And yes, they are "noticing" because of people opening support cases.
Avionics require regular updates of their local database to remain safe and certified, and I'm betting that this is either impacting the ability of users to download, or Garmin's ability to create and post the new updates. My 'smart watch' is basically a toy, and nobody cares if it's functions are limited for a (long?) time. But if my ${X} million dollar aircraft can't do its job I'm going to have my legal team re-check those Garmin contracts.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
