Here is the thing: Dropbox has no business being anything other than a cloud storage solution. Stop trying to do everything, it's too difficult and too expensive. Find what you're great at, and just improve it little by little. Stop adding shit.
Never, ever used any additional Dropbox services. All I need it to do is be a reliable cloud storage. Nothing else.
Lower the price below Google Drive and be better at being Google Drive than Google is. It wouldn't be that hard. You wouldn't need to be more expensive if you weren't pissing money away on acquisitions no one wants all the time.
ah yes, make your product cheaper than the same thing from company that has the greatest number of free software offerings with the largest user bases in the world
The changelog states: "Added support for “differential” uploads. When large files are edited, Drive for desktop will now upload only the parts of the file that changed."
Okay, but let's say Google implements that. Than Dropbox is toast, right?
It's such a shame, because I absolutely believe that simpler products which focus on one thing and do it well are basically always a better user experience (and I personally try to use them wherever possible). But I think the business case is hard.
You have no business telling anyone what their business is. Dropbox has "business" doing whatever they want to try to make great products, achieve their mission and turn over some cash.
If "being a Chinese national" is an argument for "not trustworthy", I'm sorry but "being an American national" also becomes an argument for "not trustworthy". By about 400% more (and I'm being nice).
What the OP of that comment and yourself have missed is that Google is not trustworthy enough to give it permission, which the user you're responding to pretty much suggested as a solution (Google should be trustworthy to be given a one-off permission).
The amount of times Google has been caught out doing things they shouldn't be means that no, no one has to prove that it's a reasonable assumption that Google follows policies, not even their own.
It's for you to prove that they can be trusted (good luck with that!).
In that case what do you care if you click yes or no? If you don't trust Google to abide by their own terms what makes you think they'll respect your "no"? Surely at that level of trust you would just stop using their product?
This issue comes up in my role a lot, where I am often dealing with various environmental conditions and human factors, plus multiple integration points between various software and hardware systems.
The answer is that you keep working at it iteratively using a combination of logging, reporting, and defensive programming to systematically narrow down the possible causes. Sometimes you never arrive at a true root cause, but you get close enough that you can mitigate the problem and finally close the ticket out. At the end of the day, the customer/user doesn't care as long as it works.
However, what will really piss them off is telling them your hands are tied until they can reliably reproduce the issue for you. It's important they understand that you are working on it, and typically they will go out of their way to help solve the problem when they feel taken care of.
A very small number of users have this bug (and tbf, it's a really bad bug), and are unable to consistently reproduce it and it seems none of the developers have been able to (the seemingly random nature of the bug occurring is not helping). How is it supposed to be fixed?
You add more and more diagnostics (e.g. logging) in that area till you manage to track down the bug. Over several years this should be possible.
At that point you can either fix the bug directly or do it properly by first reproducing the bug (in a test) and then fixing it.
Said another way - If they can't reproduce it, they can't close it.
They may well have fixed it already, but without a way to reproduce it the only prudent behavior is to leave it open and wait for the next diagnostic file to be uploaded.
That's not the only prudent behaviour, as the OP said, the prudent behaviour is to add more diagnostics and guards against the conditions that lead up to the bug.
Okay, let's assume more diagnostics and guards were added.
Now re-answer the above questions with these assumptions.
- How do you fix a bug you can't reproduce?
- How do you *close* a bug report when you can't reproduce?
Being generous here, we're assuming there's 17 years worth of diagnostics and safety guards added but through that time the bug still isn't reproducible. Let's try to answer the questions under these assumptions.
If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.
> There's no sense keeping it open unless there are ongoing reports of the issue.
I think you've misunderstood. There's other options.
Let's consider this from a failure analysis standpoint. Here's our options
- You have incorrectly marked issue as solved
- You have incorrectly left the issue marked as unsolved
*Which error case would you rather have?*
The classic example of this design choice is with a safe. Let's imagine you are building a safe. If the safe fails, would you prefer that it fails into a state that is unlocked or into a state that is locked? The answer isn't so obvious, as it actually depends on how it fails, right?
A very common example is when designing skyscrapers. The choice is that when a skyscraper fails, there is a strong preference that it falls in on itself (think 9/11). Why? Because if it falls to the side then it takes out other buildings and can create a chain reaction (a related famous example being housing in Industrial Revolution London and fire...)
Your action is a valid option, but it is not the option that I would chose. I think what they did was perfectly fine. They left it open (to avoid tricking anyone to thinking it is solved when the status of solved is actually unknown) and marked with additional information about lack of verification/reproducibility. Essentially, it is marked as stale.
So we're back to the earlier question:
- How do you *close* a bug report when you can't reproduce?
Or we can frame differently: "How do you close a bug report if you have no indication that the bug was resolved nor exists?"
I don't think one more user report is going to be the difference that pushes them over the finish line after two decades. Let's not pretend the developers have been taking this bug seriously.
They still have it marked as unreproducible. What do you expect them to do if they can't reproduce?
So yeah, I do think more user reports can help. At worse, it will make them take it more seriously if there are more reports.
You also are falling to observation bias. You can see linked in the issue as well as by searching that there are similar issues that were resolved and marked solved. So I don't think they were just doing nothing as everyone seems to be assuming.
The way I've dealt with that in the past is putting into into Review or whatever the equivalent is, make a note ("cannot repro, but attempted potential fix in version XXXX, moving to review, please reopen if anyone reports this again) and then if nobody reports it still happening for x amount of time (e.g. 12 months), close it. Can always reopen it if it gets reported again beyond that.
Yes, we know. We are not saying "privatize the browser" because as you rightly pointed out, privatisation is a guaranteed route to the utmost corruption.
A lot people on HN got their early programming chops from Stack Overflow and spotty internet tutorials, and have made the mistake of thinking that everything else can also be learned this way.
I'm neither, but I tried learning Spanish from a "language teacher" and it didn't work. I'm not alone. I've spoke to dozens who had the same experience.
Years later I learned from people with the same method I described.
The AI models (large LANGUAGE models) of today seem very close to replicating that experience.
Try telling ChatGPT with voice mode "let us talk about X in [pick language]... Correct me when I'm wrong and explain why".
I'm curious where you think it's failing.
What do you feel is missing to replicate a good language teacher?
> The style the author presents is vivid, uses powerful imagery and metaphor and finally, at times, is genuinely funny. More qualitatively, the author incorporates a unique identity that persists throughout the entirety of a long form essay.
This is incredible you would say that because you'll never guess what it reads like.
That's just the view of bureaucratic machines which prefer to have some stable identifier in the relevant field on paper form (it doesn't matter if it's for ethnic cleansing or “celebrating diversity”), and then shape the reality until it fits.
Even though it might be hard to ignore the well-budgeted choir of well-intentioned promoters of status quo, you still don't have to believe in this concept.
Never, ever used any additional Dropbox services. All I need it to do is be a reliable cloud storage. Nothing else.