- Yeah, I don't see a way to get around the fact that space is a fabulous insulator. That's precisely how expensive insulated drink containers work so well.
If it was just about cooling and power availability, you'd think people would be running giant solar+compute barges in international waters, but nobody is doing that. Even the "seasteading" guys from last decade.
These proposals, if serious, are just to avoid planning permission and land ownership difficulties. If unserious, it's simply to get attention. And we're talking about it, aren't we?
- Call me old-school, but I really liked how EV certs looked in the browser. Same with the big green lock icon Firefox used to have. I know it's all theatrics at best and a scam at worst, but I really feel like it's a bit of a downgrade.
- The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.
- A NAS will use a network file protocol (SMB/NFS/AFP/SFTP etc) to access data rather than direct disk access, so the types of failures are different. Generally you don't really have to "eject" but disconnecting during a large transfer can cause incomplete writes.
The main risk with directly attached storage is that most kernels will do "buffered writes" where the data is written to memory before it's committed to disk. Yanking the drive before writes are synced properly will obviously cause data loss, so ejecting is always a good idea.
Generally, NAS is a bit safer for this type of storage because the protocols are built with the assumption that the network can and will be interrupted. As a result, things are a bit slower since you're dealing with network overhead. So, like everything, there are some trade-offs to be made.
- Yeah, this is textbook "shadow IT" that could easily lead to something going seriously wrong. It's a fun example, but not something to aspire to.
Ultimately the problem is that in a lot of big corps, IT is basically unaccountable for setting things up wrong. Their only KPI is tickets closed, not the quality or success rate of their fixes.
- Chopping the plug is a very good idea, everybody should practice that.
I once had a recurring problem with patch cables between workstations and drops going bad, four or five in one area that had never had that failure rate before. Turns out, every time I replaced one somebody else would grab the "perfectly good" patch cable from the trash can beside my desk. God knows why people felt compelled to do that when they already had perfectly good wires, maybe they thought because it was a different colour it would make their PC faster... So, now every time I throw out a cable that I know to be defective, I always pop the ends off. No more "mystery" problems.
- Heh, very true. These days most new cars have a 1.0-1.5 turbo (or hybrid) rather than a larger 2.0 NA. And even 20 years ago most European cars were around 1.5 or less because of their higher fuel prices and registration taxes.
I'm a bit spoiled with the beefy 2.5 in my Mazda... Though it's still about 480 HP less than this beast ;)
- When cost and reliability is no concern, you can do truly crazy things...
> 2.0-liter boxer engine ... 670 horsepower and 680 lb-ft of torque
Those are V10 numbers coming from something the size you'd find in an econo-box.
Obviously unlike your Camry this thing is not going to do 300,000 KMs over its lifetime, and will be rebuilt frequently. This is the extreme end of the engineering tradeoff, and it's interesting to see what happens when the scale tips all the way over.
- It's funny, because it's also one of the most "gotcha-filled" things you can do. Click the wrong box, and they'll stick you in a seat with no leg room or make you pay extra for a carry-on bag. I have very little confidence that an AI would be able to make the "correct" choice on an airline ticket consistently without making a rather impactful mistake.
- All you need to know about Toronto is that the generational effort to build a raccoon-resistant trash can has failed every time. They're unstoppable beasts!
Example: https://www.cbc.ca/news/canada/toronto/raccoon-resistant-bin...
- Ah, interesting. Much more complicated than I'd think, especially as somebody not from those parts.
https://xkcd.com/1739/ - but with "terraforming"
- No wonder the lake is drying up with so much irrigation for agriculture, and an absurd number of golf courses in a very small area.
https://www.google.ca/maps/@33.6867973,-116.2608676,25994m
It's clear to me as an outsider that California has serious water sustainability problems. I mean, how long can this last?
- That was exactly the goal with the Buffalo Bicycle project, and I'd say it worked pretty well. Make a bike that's mechanically simple & reliable, maintainable with common tools, and train technicians to fix and upkeep them. Basically create the Toyota Landcruiser of bikes. I kind of want one, even though it's a "bad" bike by the standards of most western audiences (heavy, slow, ugly, etc)
https://buffaloride.org/buffalobicycle https://worldbicyclerelief.org/product-development/
- Nextcloud, and before it Owncloud, have been "in production" in my household for nearly a decade at this point. There have been some botched updates and sync problems over the years, but it's been by far the most reliable app I've hosted.
In terms of privacy & security, like everything it comes down to risk model and the trade-offs you make to exist in the modern world. Nextcloud is for sharing files, if nothing short of perfect E2EE is tolerable it's probably not the solution for you, not to mention the other 99.999% of services out there.
I think most of the problems people report come down to really bad defaults that let it run like shit on very low-spec boxes that shouldn't be supported (ie raspi gen 1/2 back in the day). Installing redis and configuring php-fpm correctly fixes like 90% of the problems, other than the bloated Javascript as mentioned in the op.
End of the day, it's fine. Not perfect, not ideal, but fine.
- Forwards is up, up is back, back is down, down is forwards.
- DO has been shockingly reliable for me. I shut down a neglected box almost 900 days uptime the other day. In that time AWS has randomly dropped many of my boxes with no warning requiring a manual stop/start action to recover them... But everybody keeps telling me that DO isn't "as reliable" as the big three are.
- I put a little analog clock on my desk that's set to UTC time. It helps a lot with converting logs to get a quick reference.
- Another great lens to see this is "Normal Accidents" theory, where the argument is made that the most dangerous systems are ones where components are very tightly coupled, interactions are complex and uncontrollable, and consequences of failure are serious.
- This is another case where it's highly important to "plant your flag" [1] and set up all those services like Search Console, even if you don't plan to use them. Not only can this sort of thing happen, but bad-guys can find crafty ways of hijacking your search console account if you're not super vigilant.
Google Postmaster Console [2] is another one everybody should set up on every domain, even if you don't use gmail. And Google Ads, even if you don't run ads.
I also recommend that people set up Bing search console [3] and some service to monitor DMARC reports.
It's unfortunate that so much of the internet has coalesced around a few private companies, but it's undeniably important to "keep them happy" to make sure your domain's reputation isn't randomly ruined.
[1] https://krebsonsecurity.com/2020/08/why-where-you-should-you...
The biggest problem is that most of the popular tools are built for the target audience of "dedicated infra team", when in reality most k8s users don't really have that.