Heat Death of the Internet
computergeek125 @ computergeek125 @lemmy.world Posts 0Comments 255Joined 2 yr. ago
computergeek125 @ computergeek125 @lemmy.world
Posts
0
Comments
255
Joined
2 yr. ago
They confirmed that there was a range of CPUs affected by a fabrication issue outside of the press release that went to media. So while we know about the i7/i9, manufacturing process is often shared between different CPU models and with Intel being opaque about what they found it's hard to understand what actually happened and what's truly unaffected.
Ref: GamersNexus
https://youtu.be/OVdmK1UGzGs
Gonna be honest I did not figure that one out.
I assumed he was part of a hunting party and had been injured separately.
Oh thank goodness, that was one of my main complaints with the system. Did they ever get around to requiring sudo like Macports (and any other reasonable system level packages manager on BSD/Linux)?
If it's anything like when I used a Mac regularly 7y ago, Homebrew doesn't install to /bin, it installs to /usr/local/bin, which only works for scripts that use env in their shell "marker" (if you don't call it directly with the shell). You're just putting a higher bash in the path, not truly updating the one that comes with the system.
TLDR: probably a lot of people continue using the thing that they know if it just works as long as it works well enough not to be a bother.
Many many years ago when I learned, I think the only ones I found were Apache and IIS. I had a Mac at the time which came pre installed with Apache2, so I learned Apache2 and got okay at it. While by release dates Nginx and HAProxy most definitely existed, I don't think I came across either in my research. I don't have any notes from the time because I didn't take any because I was in high school.
When I started Linux things, I kept using Apache for a while because I knew it. Found Nginx, learned it in a snap because the config is more natural language and hierarchical than Apache's XMLish monstrosity. Then for the next decade I kept using Nginx whenever I needed a webserver fast because I knew it would work with minimal tinkering.
Now, as of a few years ago, I knew that haproxy, caddy, and traefik all existed. I even tried out Caddy on my homelab reverse proxy server (which has about a dozen applications routed through it), and the first few sites were easy - just let the auto-LetsEncrypt do its job - but once I got to the sites that needed manual TLS (I have both an internal CA and utilize Cloudflare' origin HTTPS cert), and other special config, Caddy started becoming as cumbersome as my Nginx conf.d directory. At the time, I also didn't have a way to get software updates easily on my then-CentOS 7 server, so Caddy was okay-enough, but it was back to Nginx with me because it was comparatively easier to manage.
HAProxy is something I've added to my repertoire more recently. It took me quite a while and lots of trial and error to figure out the config syntax which is quite different from anything I'd used before (except maybe kinda like Squid, which I had learned not a year prior...), but once it clicked, it clicked. Now I have an internal high availability (+keepalived) load balancer than can handle so many backend servers and do wildcard TLS termination and validate backend TLS certs. I even got LDAP and LDAPS load balancing to AD working on that for services like Gitea that don't behave well when there's more than one LDAPS backend server.
So, at some point I'll get around to converting that everything reverse proxy to HAProxy. But I'll probably need to deploy another VM or two because the existing one also has a static web server and I've been meaning to break up that server's roles anyways (long ago, it was my everything server before I used VMs).
Advanced Dungeons and Dragons - one of the early editions of the book
https://en.wikipedia.org/wiki/Editions_of_Dungeons_%26_Dragons#Advanced_Dungeons_%26_Dragons
A static PNG tile database for world.osm is even larger. Without a solid vector tile solution, this is the most efficient data format for disk space.
Also, there's a post render CDN cache in front of the rendering layer to offset load, plus there's I think some internal caching in renderd. It's a pretty complex machine, but databases of the world are in fact huge.
OSM's core tile servers have dozens of cores, hundreds of GB of RAM each, and the rendering and lookup databases are a few TB. That's not trivial to self host, especially since one self hosted tile server cannot always keep up with a user flick scrolling.
Edit: car GPS maps and the old TomTom and Garmin devices have significantly less metadata embedded than a modern map.
Oh for sure
I saw a meme somewhere along the line that Excel is the third best tool for every job.
A paywall?
WSJ the paywall??
For your consideration, I present an anti-paywal-inator!!! TO THE ARCHIVES! https://archive.is/5VPB5
Virtual servers (as opposed to hardware workstations or servers) will usually have their "KVM" (Keyboard Video Mouse) built in to the hypervisor control plane. ESXi, Proxmox (KVM - Kernel Virtual Machine), XCP-ng/Citrix XenServer (Xen), Nutanix (KVM-like), and many others all provide access to this. It all comes down to what's configured on the hypervisor OS.
VMs are easy because the video and control feeds are software constructs so you can just hook into what's already there. Hardware (especially workstations) are harder because you don't always have a chip on the motherboard that can tap that data. Servers usually have a dedicated co-computer soldered onto the motherboard to do this, but if there's nothing nailed down to do it, your remote access is limited to what you can plug in. PiKVM is one such plug-in option.
Getting production servers back online with a low level fix is pretty straightforward if you have your backup system taking regular snapshots of pet VMs. Just roll back a few hours. Properly managed cattle, just redeploy the OS and reconnect to data. Physical servers of either type you can either restore a backup (potentially with the IPMI integration so it happens automatically), but you might end up taking hours to restore all data, limited by the bandwidth of your giant spinning rust NAS that is cost cut to only sustain a few parallel recoveries. Or you could spend a few hours with your server techs IPMI booting into safe mode, or write a script that sends reboot commands to the IPMI until the host OS pings back.
All that stuff can be added to your DR plan, and many companies now are probably planning for such an event. It's like how the US CDC posted a plan about preparing for the zombie apocalypse to help people think about it, this was a fire drill for a widespread ransomware attack. And we as a world weren't ready. There's options, but they often require humans to be helping it along when it's so widespread.
The stinger of this event is how many workstations were affected in parallel. First, there do not exist good tools to be able to cover a remote access solution at the firmware level capable of executing power controls over the internet. You have options in an office building for workstations onsite, there are a handful of systems that can do this over existing networks, but more are highly hardware vendor dependent.
But do you really want to leave PXE enabled on a workstation that will be brought home and rebooted outside of your physical/electronic perimeter? The last few years have showed us that WFH isn't going away, and those endpoints that exist to roam the world need to be configured in a way that does not leave them easily vulnerable to a low level OS replacement the other 99.99% of the time you aren't getting crypto'd or receive a bad kernel update.
Even if you place trust in your users and don't use a firmware password, do you want an untrained user to be walked blindly over the phone to open the firmware settings, plug into their router's Ethernet port, and add https://winfix.companyname.com as a custom network boot option without accidentally deleting the windows bootloader? Plus, any system that does that type of check automatically at startup makes itself potentially vulnerable to a network-based attack by a threat actor on a low security network (such as the network of an untrusted employee or a device that falls into the wrong hands). I'm not saying such a system is impossible - but it's a super huge target for a threat actor to go after and it needs to be ironclad.
Given all of that, a lot of companies may instead opt that their workstations are cattle, and would simply be re-imaged if they were crypto'd. If all of your data is on the SMB server/OneDrive/Google/Nextcloud/Dropbox/SaaS whatever, and your users are following the rules, you can fix the problem by swapping a user's laptop - just like the data problem from paragraph one. You just have a team scale issue that your IT team doesn't have enough members to handle every user having issues at once.
The reality is there are still going to be applications and use cases that may be critical that don't support that methodology (as we collectively as IT slowly try to deprecate their use), and that is going to throw a Windows-sized monkey wrench into your DR plan. Do you force your uses to use a VDI solution? Those are pretty dang powerful, but as a Parsec user that has operated their computer from several hundred miles away, you can feel when a responsive application isn't responding quite fast enough. That VDI system could be recovered via paragraph 1 and just use Chromebooks (or equivalent) that can self-reimage if needed as the thin clients. But would you rather have annoyed users with a slightly less performant system 99.99% of the time or plan for a widespread issue affecting all system the other 0.01%? You're probably already spending your energy upgrading from legacy apps to make your workstations more like cattle.
All in trying to get at here with this long winded counterpoint - this isn't an easy problem to solve. I'd love to see the day that IT shops are valued enough to get the budget they need informed by the local experts, and I won't deny that "C-suite went to x and came back with a bad idea" exists. In the meantime, I think we're all going to instead be working on ensuring our update policies have better controls on them.
As a closing thought - if you audited a vendor that has a product that could get a system back online into low level recovery after this, would you make a budget request for that product? Or does that create the next CrowdStruckOut event? Do you dual-OS your laptops? How far do you go down the rabbit hole of preparing for the low probability? This is what you have to think about - you have to solve enough problems to get your job done, and not everyone is in an industry regulated to have every problem required to be solved. So you solve what you can by order of probability.
Okay that's fair. Their pricing is awful in general, and that's especially egregious for something that used to be free
There's probably specific ticket queues and wiki/doc spaces for each support team.
Problem with an app? Send it to the internal dev/support team. Then if needed it gets routed.
(USA) Having eaten at Dominos, Papa Johns, and a large selection of local places only one local place was worse then Dominos. The rest were all light-years better.