The issue with a client app backing up dropbox and onedrive folders on your computer is the files on demand feature, you could sync a 1tb onedrive to your 250gb laptop but it's OK because of smart/selective sync aka files on demand. Then backblaze backup tries to back the folder up and requests a download of every single file and now you have zero bytes free, still no backup and a sick laptop.
You could oauth the backblaze app to access onedrive directly, but if you want to back your onedrive up you need a different product IMO.
Shoutout to Arq backup which simply gives you an option in backup plans for what to do with cloud only files:
- report an error
- ignore
- materialize
Regardless, if you make it back up software that doesn’t give this level of control to users, and you make a change about which files you’re going to back up, you should probably be a lot more vocal with your users about the change. Vanishingly few people read release notes.
I honestly didn't even realize Backblaze had a clientside app. Very happy user of Arq - been running a daily scheduled dual backup of my HDD to an external NAS and Backblaze B2 for years with zero issues.
I for one would pay for Arq on Linux as I now do on Mac. It would be fantastic to be able to use the same "it just works" backup solution on all my computers.
And I've used enough "gold standard" commercial applications, like the one being discussed in this very article, that I don't trust those either. If you recoil in horror at code written by LLMs, I'm afraid that the vendors you're already working with have some really bad news for you. You can get over it now or get over it later. You will get over it.
I can audit and verify Claude's output. Code running at BackBlaze, not so much. Take some responsibility for your data. Rest assured, nobody else will.
You are not wrong, but I just don't have time. My choices are pay someone or throw my hands up. I have been paying backblaze. But I recently had a drive die, and discovered the backups are missing .exe and .dll files, and so that part of the restore was worthless.
What time I do have, I've been using to try and figure out photo libraries. Nothing is working the way I need it to. The providers are a mess of security restrictions and buggy software.
My favorite Peanuts comic was always the one where Linus is standing at an intersection next to a 'Push Button To Cross Street' sign. He is sucking his thumb and clutching his blanket despondently.
In the last panel, Charlie Brown tells him, "You have to move your feet, too."
That seems like a pretty straightforward issue to solve, to simply backup only those files that are actually on the system, not the stubs. If it's on your computer, it should able to get backed up. If it's just a shadow, a pointer, it doesn't.
Making the change without making it clear though, that's just awful. A clear recipe for catastrophic loss & drip drip drip of news in the vein of "How Backblaze Lost my Stuff"
Not what I meant: The other cloud storage services connected to the computer, eg OneDrive. Those files, when they are just stubs. I'm saying that Backblaze could simply not backup stubs, if the person isn't syncing the actual file to their drive. If they are, backblaze should back it up.
The point of the stubs is so you don’t have to know which cloud files are actually on your device at any given moment, because they will be fetched automatically. Marking files as “always local” is a niche feature, and in any case has nothing to do with whether you want those files backed up.
To have this thing you’re not supposed to need to worry about affect whether your files got backed up is exactly the problem here. The goal is to back up your files, whether they’re in the cloud or not.
I sympathize with Backblaze’s problem with their file change monitor, but then they should considee implementing connectors for OneDrive, Dropbox, etc. and back up files directly from the cloud.
Of course it is. So *you* don't have to know which cloud files are actually there. Doesn't mean backblaze can't know, and should work within that paradigm rather than not backup anything.
As for your (the user, not necessary you personally) expectation that Backblaze would backup the stubs (im not sure that would really matter, as you said in your own comment) regardless of its stub status, that's unreasonable-- that Backblaze would travers the stubs and... why? temporarily download them, upload to backblaze? That's not what they ever stated would happen and is a big stretch to expect what amounts to the extra service of backing up cloud drives simply because a user decides to have what amounts to a an 'ln <soft link>' to to a network drive. The do explicitly exclude that.
What is not reasonable on their part is to change any service at all that had previously been happening, regardless of whether it was or was not within the ToS, and likely contract law wouldn't support a claim on their part that there was an implied contract through ambiguity which courts will typically resolve in favor of an injured party, especially one in a position of lesser power in the relationship. I'm not claiming that's what happened here, my reading of any ToS has the same legitimacy as this comment on that. I'm saying they do claim they'll backup whatever is on the computer and unexcluded. and its wrong as a matter of basic provisioning of service to a customer of what was offered. That's the limit of my claim.
“We only back up stuff from your computer” has always been their stance, and clearly it’s a way to reduce their costs. I can understand not wanting to engage in the “please backup these 10TB I have in Dropbox” requests.
I think backing up the materialized files is appropriate. That’s what they (used to) promise.
Imagine if they could detect stab or real file huh? Space technology, I know! Or just fucking copy them as stubs and what's actually downloaded as actually downloaded! Boggles the mind!
Or maybe just do what they do now, but WARN about that in HUGE RED LETTERS, in the website and the app, instead of burying it in an update note like weasels!
The whole "just sync everything, and if you can't seek everything, pretend to sync everything with fake files and then download the real ones ad-hoc" model of storage feels a bit ill-conceived to me. It tries to present a simple facade but I'm not sure it actually simplifies things. It always results in nasty user surprises and sometimes data loss. I've seen Microsoft OneDrive do the same thing to people at work.
Same. I lost a lot of photos this way. I've recently moved over to Immich + Borg backup with a 3-2-1 backup between a local synology NAS and BorgBase. Painful lesson, but at least now I feel much more confident. I've even built some end-to-end monitoring with Grafana.
Thanks... hence, 3-2-1 backups with offsite :) appreciate it though. Will definitely be rolling my own NAS in the future, I just needed something easy at the time.
My own approach to simplicity generally means "hide complexity behind a simple interface" rather than pushing for simple implementations because I feel that too much emphasis on simplicity of implementations often means sacrificing correctness.
This particular example is a useful one for me to think about, because it's a version of hiding complexity in order to present a simple interface that I actually hate. (WYSIWYG editors is another one, for similar reasons: it always ends up being buggy and unpredictable.)
That would make sense for online-only files, but I have my Dropbox folder set to synchronize everything to my PC, and Backblaze still started skipping over it a few months ago. I reached out to support and they confirmed that they are just entirely skipping Dropbox/OneDrive/etc folders entirely, regardless of if the files are stored locally or not.
That doesn't really make a lot of sense, though. Reading a file that's not actually on disk doesn't download it permanently. If I have zero of 10TB worth of files stored locally on my 1TB device, read them all serially, and measure my disk usage, there's no reason the disk should be full, or at least it should be cache that can be easily freed. The only time this is potentially a problem is if one of the files exceeds the total disk space available.
Hell, if I open a directory of photos and my OS tries to pull exif data for each one, it would be wild if that caused those files to be fully downloaded and consume disk space.
Right, but even if that’s working it breaks the user experience of services like this that ‘files I used recently are on my device’.
After a backup, you’d go out to a coffee shop or on a plane only to find that the files in the synced folder you used yesterday, and expected to still be there, were not - but photos from ten years ago were available!
That shouldn't be seen as Backblaze's problem. It's Dropbox's problem that they made their product too complicated for users to reason about. The original Dropbox concept was "a folder that syncs" and there would be nothing problematic about Backblaze or anything else trying to back it up like any other folder.
Today's Dropbox is a network file system with inscrutable cache behavior that seeks to hide from the users the information about which files are actually present. That makes it impossible for normal users to correctly reason about its behavior, to have correct expectations for what will be available offline or what the side effects of opening a file will be, and Backblaze is stuck trying to cope with a situation where there is no right answer.
There’s no reason to think that would happen - files you had from ten years ago would have been backed up ten years ago and would be skipped over today.
Good point (I’m assuming you’re right here and it trusts file metadata and doesn’t read files it’s already backed up?)
It would still happen with the first backup - or first connection of the cloud drive - though, which isn’t a great post-setup new user experience. It probably drove complaints and cancellations.
I feel like I’ve accidentally started defending the concept of not backing up these folders, which I didn’t really intend to. I’d also want these backed up. I’m just thinking out loud about the reasons the decision was made.
It's generally now handled decently well, but with three or four of these things it can make backups take annoying long as without "smarts" (which are not always present) it may force a download of the entire OneDrive/Box each time - even if it never crashes out.
This is a complexity that makes it harder, but not insurmountable.
It would be reasonable to say that if you run the file sync in a mode that keeps everything locally, then Backblaze should be backing it up. Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
> Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
When you have a couple terabytes of data in that drive, is it acceptable to cycle all that data and use all that bandwidth and wear down your SSD at the same time?
Also, high number of small files is a problem for these services. I have a large font collection in my cloud account and oh boy, if I want to sync that thing, the whole thing proverbially overheats from all the queries it's sending.
Reading your comments, it sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files. I know you haven’t technically said that, but that’s what it sounds like.
I assume you don’t think that, so I’m curious, what would you propose positively?
> I know you haven’t technically said that, but that’s what it sounds like.
Yes, I didn't technically said that.
> It sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files.
I don't argue neither, either.
What I said is with "on demand file download", traditional backup software faces a hard problem. However, there are better ways to do that, primary candidate being rclone.
You can register a new application ID for your rclone installation for your Google Drive and Dropbox accounts, and use rclone as a very efficient, rsync-like tool to backup your cloud storage. That's what I do.
I'm currently backing up my cloud storages to a local TrueNAS installation. rclone automatically hash-checks everything and downloads the changed ones. If you can mount Backblaze via FUSE or something similar, you can use rclone as an intelligent MITM agent to smartly pull from cloud and push to Backblaze.
Also, using RESTIC or Borg as a backup container is a good idea since they can deduplicate and/or only store the differences between the snapshots, saving tons of space in the process, plus encrypting things for good measure.
This. You should not try to backup your local cache of cloud files as if those were your local files. Use a tool that talks to the cloud storage directly.
Use tools with straightforward, predictable semantics, like rclone, or synching, or restic/Borg. (Deduplication rules, too.)
My understanding of Backblaze Computer Backup is it is not a general purpose, network accessible filesystem.[0] If you want to use another tool to backup specific files, you'd use their B2 object storage platform.[1] It has an S3 compatible API you can interact with, Computer Backup does not.
But generally speaking, I'd agree with your sentiment.
But if the files are only on the remote storage and not local, chances are they haven't been modified recently, so it shouldn't download them fully, just check the metadata cache for size / modification time and let them be if they didn't change.
So, in practice, you shouldn't have to download the whole remote drive when you do an incremental backup.
You can't trust size and modification time all the time, though mdate is a better indicator, it's not foolprooof. The only reliable way will be checksumming.
Interestingly, rclone supports that on many providers, but to be able to backblaze support that, it needs to integrate rclone, connect to the providers via that channel and request checks, which is messy, complicated, and computationally expensive. Even if we consider that you won't be hitting API rate limits on the cloud provider.
Sometimes modification time of a file which is not downloaded on computer A, but modified by computer B is not reflected immediately to computer A.
Henceforth, backup software running on computer A will think that the file has not been modified. This is a known problem in file synchronization. Also, some applications modifying the files revert or protect the mtime of the file for reasons. They are rare, but they're there.
The problem is, downloading files and disk management is not in your control, that part is managed by the cloud client (dropbox, google drive, et. al) transparently. The application accessing the file is just waiting akin to waiting for a disk spin up.
The filesystem is a black box for these software since they don't know where a file resides. If you want control, you need to talk with every party, incl. the cloud provider, a-la rclone style.
Unless it does something very weird it won't trigger all those files to download at the same time. That shouldn't be a worry.
And, as a separate note, they shouldn't be balking at the amount of data in a virtualized onedrive or dropbox either considering the user could get a many-terabyte hard drive for significantly less money.
> Unless it does something very weird it won't trigger all those files to download at the same time. That shouldn't be a worry.
The moment you call read() (or fopen() or your favorite function), the download will be triggered. It's a hook sitting between you and the file. You can't ignore it.
The only way to bypass it is to remount it over rclone or something and use "ls" and "lsd" functions to query filenames. Otherwise it'll download, and it's how it's expected to work.
I think you might be confusing Backblaze reading files and how Dropbox/OneDrive/Nextcloud/etc. work. NC doesn't enable this by default (I don't think), but Windows calls it virtual file support. There is no avoiding filling the upload buffer, because Backblaze has zero control over how Dropbox downloads files. When Backblaze requests that a file be opened and read, Windows will ask Dropbox or whatever to open the file for it, and to read it. How that is done is up to whatever handles the virtual files. To Backblaze, your Dropbox folder is a normal directory with all that that entails, so Backblaze thinks that it can just zip through the directory and it'll read data from disk, even though that isn't really what's happening. I had to exclude my Nextcloud directory from my Duplicati backups for precisely this reason -- my Nextcloud is hosted on my server, and Duplicati was sending it so many requests it would cause my server to start sending back error 500s.
And no, my server isn't behind cloudflare, primarily because I don't have $200 to throw at them to allow me to proxy arbitrary TCP/UDP ports through their network, and I don't know how to tell CF "Hey, only proxy this traffick but let me handle everything else" (assuming that's even possible given that the usual flow is to put your entire domain behind them).
Dropbox and onedrive can handle backblaze zipping through and opening many files. The risk is getting too many gigabytes at once, but that shouldn't happen because backblaze should only open enough for immediate upload. If it does happen it's very easily fixed.
If it overloads nextcloud by hitting too many files too fast, that's a legitimate issue but it's not what OP was worried about.
The issue you’re missing is that the abstraction Dropbox/OneDrive/etc provide is not that of an NFS. When an application triggers the download of a file, it hydrates the file to the local file system and keeps it there. So if Backblaze triggers the download of a TB of files, it will consume a TB of local file system space (which may not even exist).
It does keep them permanently. Dropbox is not a NAS and does not pretend to be one.
> When you open an online-only file from the Dropbox folder on your computer, it will automatically download and become available offline. This means you’ll need to have enough hard drive space for the file to download before you can open it. You can change it back to online-only by following the instructions below.
Same exact behavior for OneDrive, though it apparently does have a Windows integration to eventually migrate unused files back to online-only if enabled.
> When you open an online-only file, it downloads to your device and becomes a locally available file. You can open a locally available file anytime, even without Internet access. If you need more space, you can change the file back to online only. Just right-click the file and select "Free up space."
Maybe it'll, maybe it won't, but it'll cycle all files in the drive and will stress everything from your cloud provider to Backblaze, incl. everything in between; software and hardware-wise.
That sounds very acceptable to get those files backed up.
It shouldn't stress things to spend a couple weeks relaying a terabyte in small chunks. The most likely strain is on my upload bandwidth and yeah that's the cost of cloud backup, more ISPs need to improve upload.
I mean, cycling a couple of terabytes of data over a 512GB drive is at least full 4 writes, which is too much for that kind of thing.
> more ISPs need to improve upload.
I was yelling the same things to the void for the longest time, then I had a brilliant idea of reading the technical specs of the technology coming to my home.
Lo and behold, the numbers I got were the technical limits of the technology that I had at home (PON for the time being), and going higher would need a very large and expensive rewiring with new hardware and technology.
4 writes out of what, 3000? For something you'll need to do once or twice ever? It's fine. You might not even eat your whole Drive Write Per Day quota for the upload duration, let alone the entire month.
> the technical limits of the technology that I had at home (PON for the time being)
Depends on your device capacity and how much is in actual use. Wear leveling things also wear things while it moves things around.
> For something you'll need to do once or twice ever?
I don't know you, but my cloud storage is living, and even if it's not living, if the software can't smartly ignore files, it'll pull everything in, compare and pass without uploading, causing churns in every backup cycle.
> Isn't that usually symmetrical? Is yours not?
GPON (Gigabit PON) is asymmetric. Theoretical limits is 2.4Gbps down, 1.2Gbps up. I have 1000Mbit/75Mbit at home.
How do you know how often those files need to be backed up without reading them? Timestamps and sizes are not reliable, only content hashes. How do you get a content hash? You read the file.
If timestamps aren’t reliable, you fall way outside the user that can trust a third party backup provider. Name a time when modification timestamp fails but a cloud provider will catch the need to download the file.
The issue really isn't that it's not backing up the folder (which I can see an argument for both sides and various ways to do it) - it's that they changed what they did in a surprising way.
Your backup solution is not something you ever want to be the source of surprises!
I also discovered gdu recently. It's really good. It saves me running du -h --max-depth=1 | sort -h a million times trying to find where the space has gone while you're stressing about production being down.
I had the Voodoo 1 with VGA passthrough from the 2D card. When you loaded a game you'd head a little clunk from a relay on the Voodoo taking over the VGA signal and you knew you were about to have a good time. Doesn't seem that long ago!
I was obsessed with both history and computers when I was young. I've stayed a little close to history by building my career around problems domains in which C is the language of choice.
It's not quite Software Archaeology, but I've run across enough "old code" [1] in my career to keep me happy.
[1] One example is: In 2008 I had to modify code written in 1991 for a long-term Psychology study on rats. It had executed hundreds of times per day for ~17 years at that point. Fun times.
A close family member did just that. They absolutely love history and are super well informed about lots of interesting subjects. The downside is it basically sets you up for becoming a history teacher and that's not the most rewarding career there is.
That's just how the law works apparently, if there's a UK law passed that makes smoking illegal in Paris then smoking is illegal in Paris. The practicalities of this are to be worked out later.
Smoking in Paris is harmful to the health of UK citizens residing in Paris. I'm not sure why UK hasn't banned that yet.
When OSA was announced I really expected the US to state clearly that they wouldn't let UK to threaten US citizens with millions of fines if they practice their rights to Free Speech.
Because this is what's happening, the UK is making open threats against US citizens when they practice their rights to Free Speech. See e.g. Lobsters' take on it: they just wanted to have a webforum in the US but they couldn't because a foreign country threatened them with huge fines. No protection from the US.
"Just geoblock UK" seemed like a good enough in practice solution, although it is more action needed than I'd prefer.
I don't know how I missed this. Yes, geoblocking should be on ofcom. If they don't like my forum, then instead of sending me a ridiculously big check, putting me on interpol, capturing me at the airport etc, just tell their ISPs to block my forum.
In principle it sounds like a reasonable idea but the obvious problem is that people can become domiciled elsewhere, or structure their income to avoid this. It would be interesting to know what's been planned to mitigate that.
I don't need an answer to point out that your response is relevant to probably 3 or 4 people every year who:
- live in Washington State; AND
- are compensated at least in part in options; AND
- are compensated in excess of $1M a year; AND
- are compensated far enough in excess of $1M a year that they are willing to spend time and money lowering that tax liability
But the answer is "you can't, at least not legally" for everyone except those few people.
It may indeed be the case that the candidate promised one thing and the voters acting irrationally (or correctly assuming he's a liar) voted with an expectation of him doing the exact opposite. The GP, however didn't say anything about voting. He was talking specifically about the mismatch between campaign promises and actions taken once in office.
Well yeah but he is a pathological liar, fraudster and a criminal. This was well known during 2nd election campaign.
Expecting to hold any promises just because they were said and got him where he wanted is a bit naive, don't you think? Or does the idea of 'but now he will act completely differently to his entire prior life!' makes any sense to you?
Trump also has said "I will bomb the shit out of them -- I don't care" on the campaign trail.
I think a relatively accurate model of the people's opinion towards intervention might be quite simple: it is good if we win relatively swiftly and bad if we lose and/or don't gain anything, and the opinion at the time is shaped (and over time altered) based on their estimate of the outcome, but no politician says it that way so it is always cast as black and white pro-war/anti-war.
In the current case, I think many Americans, even Democrats, recognize the regime in Iran as a threat that needs to be dealt with somehow (a deal or an intervention). Their worry is the cost and ramifications, not some ulterior principle. If Trump brings home a win and some oil to boot soon-ish, you're going to see positive sentiments more clearly. If this drags on, the backlash will be there, and will be phrased as "MAGA never wanted the war" and along your lines of isolationist promises not kept.
Trump's approval rating among his base is still overwhelmingly high. They know what they were voting for, and they still support him. They know that Trump lies like he breathes, and they are perfectly fine with that. Trump supporters themselves are largely liars. They do not openly state the positions they actually hold. That Trump says X and does Y is fine because his supporters say X and believe Y. Words are a game to them, a means to accomplish a goal rather than something to communicate honestly with.
The most important thing to understand about Trump and conservatism in general, by far, is that there is one central principle that underpines the entire ideology: hierarchy. Going back to the time of kings and nobility and clergy, through to the present day.
"Conservatism consists of exactly one proposition, to wit: There must be in-groups whom the law protects but does not bind, alongside out-groups whom the law binds but does not protect."
One set of laws for the people higher in the hierarchy, and one set of laws for the people lower in the hierarchy. Things that are okay for them to do are not okay for you to do. Wars started by Democrats are bad. Wars started by Republicans are good. They know this is not convincing rhetoric to anyone who is not part of the in-group, so they lie about their reasons and play games with words. This, however, is what they truly believe.
It is why every action they take appears hypocritical to their opponents, but in actuality, it is perfectly consistent with their values - it is good when they do it, because everything is good when they do it, and it is bad when somebody else does it, because everything is bad when somebody else does it. It is why "the only moral abortion is my abortion". It is why the exact same policies executed by different presidents will have the same approval rating by democrats, but a completely inverse approval rating by republicans (eg 40% of Democrats approve of either Obama or Trump striking Syria, while 20% of Republicans approve if Obama does it and 80% approve if Trump does it). It is the single consistent trend through all of their policies. They know exactly what they were voting for, and that is for the man who represents their hierarchy. The games he plays with words are part of the platform.
Edit: I have rewrote the message quite a bit, apologies if anything doesn't make sense.
It may be the case that his base is still just following him and supportive of whatever he does.
But the number of people who voted for him vastly exceeds his “base”, and the entire MAGA movement is basically predicated on a form of isolationism, or at least not pro-intervention. Part of the reason it became popular was as a reaction against the wars in Iraq and Afghanistan.
So I don’t think it’s as simple and one dimensional as you paint here. Which is exactly why I think it’s a systemic problem: many people probably voted for him because of the campaign promises of being against foreign wars.
But will they still support him if gas prices and general inflation spike hard, as is nearly a given if Trump doesn't back out from the war?
My impression is that most of his voters are selfish and couldn't care less for other people's woes (migrants, sexual abuse victims, Iranians or whatever), but will care if his antics hit their own pockets. I'm not American so I may well be wrong, though.
Yes, they will still support him. Republicans dying of COVID would still deny its existence on their deathbed, so you can be sure there is no consequence that is too far for them. Farmers bankrupted and people who lost jobs because of Trump's policies continue to support him. Inflation is bad when Democrats do it, but it is fine if Republicans do it, as with all things, because that is how their hierarchy works.
Their support is not the result of a rational calculation of self-interest, and never was. If it was, a base of rural and poor people would never be supporting a coastal city New York elite born with a silver spoon in his mouth as "one of them". But they do, because he is one of them in the way that matters to them. They are fighting for something larger than themselves, and are completely committed to a cultural war for social hierarchy.
> if gas prices and general inflation spike hard, as is nearly a given if Trump doesn't back out from the war?
As an aside, I don't think there is any backing out of this war. If somebody launched a missile at your country and killed hundreds of schoolgirls, and destroyed ships on diplomatic missions while leaving the survivors to drown, while also assassinating your country's leader (but not out of any intention of liberation), would you just let things go because they stopped bombing? Of course you wouldn't. Your country would continue to retaliate. And it is trivial to punish America. Even if America unilaterally decided to "declare peace" and withdraw from attacking Iran, Iran has every reason to continue locking down the gulf and making Americans pay the price. Unlike with tariffs, there is no backing down from these price increases even if Trump gets cold feet. But, even so, there is no reason to believe it will move the needle on his base. There is already talk of "short term pain for long term gain" among those who realise this.
As much as I tried to discount sweeping accusations made against voters, increasingly I am beginning to think that a lot of those who support this administration really want to see a "whiter" and more Christian U.S. It's getting harder for me to deny.
If there are single-issue voters supporting this admin, I suspect for many that issue is not "stay out of foreign wars" but something closer to going back to some mythical time in the U.S. that looked more like Currier and Ives.
Congrats on letting it finally sink in, but I honestly don't understand how this fact wasn't clearly evident from even his first term. His base absolutely eats up any rhetoric around making the country 1. more white and 2. more christian. You don't even really have to be listening for subtle dogwhistles anymore. They're saying these things openly now.
> As an aside, I don't think there is any backing out of this war. If somebody launched a missile at your country and killed hundreds of schoolgirls, and destroyed ships on diplomatic missions while leaving the survivors to drown, while also assassinating your country's leader (but not out of any intention of liberation), would you just let things go because they stopped bombing? Of course you wouldn't. Your country would continue to retaliate. And it is trivial to punish America. Even if America unilaterally decided to "declare peace" and withdraw from attacking Iran, Iran has every reason to continue locking down the gulf and making Americans pay the price. Unlike with tariffs, there is no backing down from these price increases even if Trump gets cold feet. But, even so, there is no reason to believe it will move the needle on his base. There is already talk of "short term pain for long term gain" among those who realise this.
Yeah, that's a good point. And the fact that the new leader's closest family members were killed in the attack won't help. But I suppose the Iranian regime might want some stability, and the Gulf countries are very interested in the end of the war because for them it's pretty much an existencial treat. So maybe there's a scenario where Trump gets to declare a GREAT VICTORY because he supposedly destroyed Iran's nuclear capability or whatever, Iran gets money from the Gulf countries and the regime gets stability, and the Gulf countries get... well, avoiding ruin.
I guess the percentage of crashes due to hardware is high because people with faulty hardware are experiencing the vast majority of crashes. It sounds kind of dumb when put like that, I'm actually surprised it's that low a percentage.
I guess the percentage of crashes due to hardware is high because people with faulty hardware are experiencing the vast majority of crashes.
It is not that simple, it does not only depend on the hardware but also the code. It is like a race, what happens first - you hit a bug in the code or your hardware glitches? If the code is bug free, then all crashes will be due to hardware issues, whether faulty hardware or stray particles from the sun. When the code is one giant bug and crashes immediately every time, then you will need really faulty hardware or have to place a uranium rod on top of your RAM and point a heat gun at your CPU to crash before you hit the first bug, i.e. almost all crashes will be due to bugs.
So what you observe will depend on the prevalence of faulty hardware and how long it takes to hit an hardware issue vs how buggy the code is and how long it takes to hit a bug.
reply