For my master thesis I did a lot of digging into the research on success factors for startups. And at least based on what I found back then, you're right. The correlation is weak between any factor like this and success. Generally positive though, so it does make sense to try doing some planning. But it's definitely not a requirement.
In general, observable factors doesn't strongly correlate with success. Probably both because there are so many to choose from and because the real world is complex and typically doesn't align well with any predefined plan.
Feature request: Make it default behavior on phones that you can have multiple passwords, connected to different profiles. With no way to determine how many profiles a phone have.
I'm sure there's some people here working on mobile operating systems, might be worth considering?
Didn't it start with asm.js, a subset of javascript serving as a way to compile C code to be run in a browser? Then browser makers figured that it'd be better to have a dedicated target for this. So while it can be used to achieve performance in specific scenarions, it's largely designed with the goal in mind to be able to run non js code in a browser. The wasm toolchain Emscripten encompasses this notion quite clearly as it emulates things like filesystems etc. If the main goal was faster execution, they would probably have gone a different route. PRobably even gone for a new language altogether.
I'd like a toolchain better targeted for the pure acceleration use case though. Emscripten adds a lot of bloat and edges just to serve out of the box posix compatibility. Which is nice for quick demos of "look I can run Doom in the browser"-kind. But less useful for advanced web app usage, where you anyways will want to keep control of such behavior and interact with the browser apis more directly.
It's the difference between proportional voting vs winner takes it all. In the latter case you can't really hold politicians accountable, as you will have to choose between effectively throwing your vote away or voting for the one opposition candidate, that often will be just as bad.
While the UK have some level of representativeness, each circuit has a winner takes it all structure, making change quite hard to achieve on a larger scale.
Maybe he's actually wearing protective gear? Jeans with slide tolerant layers and padding are pretty common as warm weather gear and there are jeans style jackets as well. If you don't know what to look for it can be hard to tell the difference to regular clothing.
* Have a license
* Wear appropriate gear
* Follow speed limits
* Don't drink and ride
* Aged somewhere 30-50
* Have more than a few months experience on your bike
* etc.
You are statistically "one of the safer ones". Not safe, you are never truly safe when in traffic.
It takes away the ability to know what it does though, which is also often considered an important aspect. By not publishing details on how to train the model, there's no way to know if they have included intentional misbehavior in the training. If they'd provide everything needed to train your own model, you could ensure that it's not by choosing your own data using the same methodology.
IMO it should be considered freeware, and only partially open. It's like releasing an open source program with a part of it delivered as a binary.
To me it sounded like click bait. So I checked comments and concluded that it was indeed about the very visible RDS signal and not some hidden channel used by some secretive agency that would indeed be somewhat mysterious.
I don't think the fact that it worked in generating clicks is really an argument for bait titles. Given the positive comments about the content I think some editorializing could have been helpful to focus on the hacking journey aspect though, which seems to be the point rather the specifics of RDS itself.
I sure hope this does not mean a reduction in quality, one of Legos big benefits has been the longevity, lego pieces from the 70s are still in my family's rotation. Reuse should always come before recycle.
They didn't specify what they qualified as a multivitamin, my guess is that the definition is rather loose due to the scale of the study. There's a lot of different mixes of multivitamins in the store. You would buy the one that fit's the efficiency pattern you want to prevent. If your goal is to specifically reduce mortality rather than prevent short term fatigue, you would need to pick the right one.
From what I can tell, they haven't ensure that the long term consumption pattern was consistent either, so they may be mixing people who took multivitamins for a year around the initial study with those who took it every day for their whole life. That would reduce the effect size significantly.
The general advice on vitamin supplements is usually to take the ones you have explicit reasons for taking and to focus more on food in general. This study, while possible useful as a way to debunk highly unrealistic claims of multivitamin effectiveness, doesn't really change the picture here.
tsan will catch a bunch of potential race conditions for you, under the condition that you run it somehow. How to make sure it's run? Well, add a test for the relevant code and add it to your tsan run in your CI and you'll certainly catch a bunch of race conditions over time.
This has saved me a bunch of times when I've be doing work in code with proneness to those kind of issues. Sometimes it will just lead to a flaky test, but the investigation of the flake will usually find the root cause in the end.
I like the idea of focusing on the key notion of wether the task will succeed or not. A challenge in these things are to design things such that users understand what is communicated, and you also want something that fits the style of the app overall.
Personally I'm a fan of progress bars that indicates actual progress rather than any estimates the developer though would be good to provide. But if getting-stuck probability could be hinted at it would be great.
Maybe, whenever the bar gets stuck, it can slowly start greying out based on the probability that it's completely dead? That way an attentive user can use this as a clue for when to reload and try again, while not breaking the previous behaviour or introducing too much confusing information.
It's clearly not properly designed to be for swedish, this is noted in the reply, apart from some letters being off, it lacks åäö. But it's still not clear why they would use "u-boat" for u. While apparently correct english (never heard it), it being Swedish ubåt seems higher likelihood to me.
I'm wondering if they might have combined mixed two designs, as a lot of the letters works in both. Maybe they looked at two pictures and didn't realise one was for another language? It seems possible to me that they'd design the ball based on product pictures, and those are often not showing all angles of a product.
Weight gain does often happen a few years post treatment. Even then it's beneficial compared to no intervention, which would most likely have them be even worse off five years later. Long term health outcomes are better for those who get treatment than those who don't.
The dichotomy is relevant if you are of the opinion that some of the foundational design choices of Carbon makes it less viable as a C++ successor based on the similarity of those choices to other projects that were struggling due to this. The talk is arguing for the validity of the construct with various examples, not just Dart.
The construct can be useful without being the end-all answer to what should be done and I would definitely advice you to watch the full talk if you haven't yet. And the consider how each point may apply or not apply to Carbon. Don't just dismiss it on the notion that Carbon is different from Dart.
Actually, I'd encourage you to reach out to Herb Sutter and ideally meet up in person to discuss the matter. Your goals are aligned in many ways and while you have different approaches a lot of good can come out of sharing ideas.
It's not at all hard to build a sane codebase in C++ if you are a group of experienced C++ devs with an eye for detail. Not saying mistakes never happen, but most of the time the tools available are sufficient to build correct code if you know how to use them right.
However, the problems abound when you have less experienced devs in a less structured environment and working with legacy C or C-style code, the latter often being the reason for why C++ was used in the first place. For this, something like cpp2 can be revolutionising as it makes it easier to write correct code and provides mechanisms to disable many of the unsafe patterns.