HN user
Thanks. It has indeed been down multiple times recently, both for active DDoS and for maintenance in response.
A week ago, there was a post titled “Fastmail is having problems again”, so today, “yet again” seemed adequate:
By the way, is the “yet” what is regarded as “editorialized”? There’s hardly any “original title”, apart from frequently changing status updates in the body.
Their response from a few days ago, including mentions of similar services affected, e.g. Mailbox.org and Posteo: https://fastmail.blog/company/fastmail-fights-off-ransom-cyb...
Analysis of the same tracking mechanisms from September 2018, and its discussion on HN late last year: https://news.ycombinator.com/item?id=21034849
Popularized by Dwight Eisenhower in the 1950s, as per https://quoteinvestigator.com/2017/11/18/planning/
There is a very old version of this, indeed:
“Plans are worthless when the fighting is once begun, and all depends on the inspiration of the moment.” (1877)
You’re right about the gold rush being over. But what certainly remains true is that, although your product may be failing, it could be possible to identify individual features or adjacent markets that are more promising.
For YouTube and Groupon at least, it definitely was the latter. This can be seen in the sources.
Thanks a lot for tracking that down! I would also say the change of some metadata in a non-static page is fine.
Well, would you say that the pivot from a dating app to what YouTube is today is a joke? Is that just a refined product? Same for games turning into social networks or productivity tools.
You would be right – if the point was “just pivot and you’ll succeed”. It’s not.
You’re right, these are perfect additions. No idea how they could have been missed. Thank you!
This is great. We also need companies and founders with great visions that ultimately don’t have to pivot. And I’m sure there are many of them.
By the way, is there any source for that blog post that proves its existence and form back to 2006? The Wayback Machine only has it until 2016, but perhaps the URL changed.
Sure, there are lessons here. And it’s certainly not “just work on anything”. It’s really that the initial idea is often overvalued, as you already said, that execution is more important than ideas, that you should constantly (re)validate your idea, and that you should be ready to pivot.
We know this from “The Lean Startup”, but practical examples can show why some aspects are important. And it’s not just small teams and solo founders from startups and young companies that may place too much importance on a great initial idea. It’s certainly also the general public, where most people belief that successful startups are the result of a genius having a clever idea. See basically every movie about inventions (and young companies). That general public also includes a lot of (potential) investors.
@media (prefers-color-scheme: light|dark|no-preference) { ... }
https://drafts.csswg.org/mediaqueries-5/#descdef-media-prefe...
They dropped in-app subscriptions on Android as well in May 2018. But why?
Unless I’m mistaken, the Google Play Developer Policy allows you to use a different payments provider, such as Stripe, in a case like Netflix or Spotify’s:
Developers […] must use Google Play In-app Billing as the method of payment, except for the following cases: […] Payment is for digital content that may be consumed outside of the app itself […]
Source: https://play.google.com/intl/en/about/monetization-ads/
At least in the past, Skype has been doing exactly that, for example.
We may need permissions for our dependencies (cf. Android apps). Ryan Dahl already did this with Deno, specifically because he saw weaknesses in Node: network, environment variables, file system, sub-processes.
We may need reproducible builds and reproducible minification. If we want developers to audit their own dependencies, in case we deem that practical, packages cannot ship their own minified sources. Auditing the non-minified source is hard enough.
We may need (for-profit) organizations that audit packages and award their official seal which you can trust before you add or update a dependency.
We may need better standard libraries and fewer micro-packages.
Mold is not always black, is it? It can have other colors as well, e.g. yellow.
You can buy test kits that you expose to your rooms’ air for some time, and then a lab will grow the mold inside the Petri dishes to “amplify” what has been collected in your home. That may be expensive, though, and not easily available everywhere, and perhaps even prone to contamination “in transit”?
Really sorry to hear that.
Sorry to ask, but I’m not really sure I got it right: Do you think the DIY air purifier was the cause of these health problems? Or did it at least contribute by letting the mold come back (inside)?
As others have noted, a dehumidifier could help. But what prevents mold from growing inside these dehumidifiers as well? Sure, they’re mainly built from plastic and metal, so no paper as in your case. Will that be enough to prevent mold (or bacteria)?
Otherwise, a dehumidifier could turn into yet another health hazard over time.
Could mold grow inside of a dehumidifier as well? I mean, water is constantly passing the components inside. Or does mold need organic material (such as the paper inside the DIY filter) and thus will not grow on the dehumidifier that consists largely of plastic and metal?
You can keep both. You probably have not told your tax consultant that Paddle acts as the merchant of record. That means you don’t actually have any relationship to your customers when it comes to taxes. That’s Paddle’s role. Instead, your single “customer” is Paddle, whom you will probably get a single transaction from per month.
Setting `network.http.referer.XOriginPolicy` to `1` in Firefox’s `about:config` is actually a pretty reasonable choice for all browsing, and balances privacy with preventing your favorite sites from breaking.
Yes, I agree with you. And plain old arrays or switch statements are the simplest format that I know, understood by developers of (almost) any background.
Can understand that reasoning, and often do the same. Though it's important to keep in mind that quality is not something that can only be achieved by paying any random party some amount of money.
Developing and drafting things in the open can produce the same level or even higher levels of quality.
Since the project is not a commercial product, though, I don't care what solution you use :)
Totally aware of that. Reviewing individual translations again, and repeating this from time to time, is definitely something that can and should be done in the future.
So there's obviously an easy fix to the problems you outline, which are no fundamental problems.
Translations. Say, the English one is the official and legally binding one, and the Chinese and Spanish translations are only for added convenience, without any legal effect.
It's a whole different matter, though. Using automatic machine translations is still not what is done here, and you can't compare human translations with that.
Regarding legal expertise, I or anybody else could go through this with a lawyer next week and have a review, including a "pull request" of required changes, no more than a week later.
For the translation, of course the process was not copying and pasting words into Google Translate one by one and using the result. The translation process has been much more thorough.
Of course we know gettext. But gettext is less portable and less user-friendly, especially for users who use PHP only casually. That's also the reason why some of the largest PHP frameworks don't primarily use gettext for translations.
The solution here is pragmatic and works. You can measure performance, if you think this is really an issue.
Thanks! What you wanted to say is this proves that terms of service, just as a privacy policy, can be generated from templates and be used in practice, right?