dromtrund
If you buy a product that's more expensive, you'd be a fool if it's not superior to other products, so it's hard not to get personally invested in the idea that they are.
Most families would provide for their own if it was required, but it's not a scenario most people ever need to consider, even as a backup, as bad luck alone can't put you in that situation, you'd need to actively seek it out.
That has to be at least 5 years ago, but even back then, 99% of their software was out in the open. Now, their SDK is open source, their official toolchain is based on the Linux Foundation's Zephyr toolchain and their docs are open and buildable. Their support is done on an open forum and complete data sheets are available both as PDFs and (with the exception of the nRF51) as web pages. They aren't allowed to publish their LTE stack because of operator licensing, their Bluetooth link layer is still distributed as a library and some upcoming SoCs aren't publicly available yet, but aside from this, they're as open as they can possibly be.
I have always done this subconsciously, and although I can attribute a lot of my personal growth to this trait, it's also the source of a lot of self-loathing. If you can't accept the parts of you that differs from who you want to be, you'll spend a lot of energy focusing on perceived mistakes that others didn't even notice.
I wouldn't normally drive more than 1000km in one trip though, and that's at most once per year.
With the 3k€ lower price, a range of 430km, and fast charging stations every 30km along the major highways, there's just no reason to pick the Golf.
We still have a PHEV in addition to our electric car, but there's no reason to. If we're going on a 500km road trip, we'll take the electric BMW i4, no question.
A few other aspects: - dark mode by default - web tech UI, not terminal - decent looking widgets and decorations
I don't think these are the main selling points for vscode, but they do all of this better than their competitors.
Smartphones might genuinely be a thing future generations will look at asking "what were you thinking?", but this argument is completely moot, as it could be used against literally anything.
Studies will suggest that electricity is not harmful until it is. Studies will suggest that freedom of speech is not harmful until it is. Studies will suggest that touching grass is not harmful until it is.
Both this and encrypted communication interpretation works a lot better than the commenter above you claims. They've either not tried this sniffer, and are only making claims based on assumptions, or they haven't learned how to use it properly.
It's definitely not as good as commercial sniffer hardware, but it's perfectly fine 90% of the time, and the price is two to three orders of magnitude lower.
This sniffer is set up to follow the channel jumping, but instead of participating in the packet exchange, it just listens for both parts. As the channel jumps are predetermined, the sniffer can sleep between these events, then start the radio up to listen on the right channel at the right time.
The hardware does not support listening to multiple channels at the same time, so to follow a connection, the sniffer needs to listen to the connection establishment exchange to learn the timing and channel pattern for the connection.
Device discovery and connection establishment runs on three channels, but all beacon packets (advertisements) are sent on all three channels, so the sniffer only needs to listen to one of them.
The connection requests are sent as immediate responses to an advertisement. If we want to be sure we catch all connection requests for a specific device, we can choose to "follow" its advertisements, which are sent on each of the three channels in sequence.
The sniffer is implemented by interacting directly with the radio hardware peripheral, which acts just like a state machine with states RX, TX, idle, and a few warmup states.
I'd argue that the need for downcasting in a method working on the inner context would also be a code smell, and that you might want to reconsider the context split. In some cases, there's no way around it (like async events), but it might be more appropriate to pass additional context or a callback instead, to avoid a circular dependency.
If more people were asking for it, I would try again, but the time spent per user to set up a pipeline for each extension just doesn't make sense at the moment. I'd rather spend those nights adding features for the existing mainline users. Cynical perhaps, but there's no reward for making extensions, so there's a limited amount of time I can spend on it.
For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful.
When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales.
I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
If this is an issue in your workday, you should bring it up with management or the individual rejecter. If someone has the authority to kill PRs, they should also be required to put in the effort to understand it and/or be available for discussion at an earlier stage of the development process. PRs shouldn't ever be rejected without mutual agreement - neither internally in an organization, or in an open source project.
Norway already has state grants for innovative startups, which when boosted by oil money, could generate a similar environment for entrepreneurs and innovative business, allowing people and companies to take larger risks. If this is executed correctly, it would make Norway the spearhead of whatever the next oil is, since companies from other countries will get pushback from their investors when taking the same risks or going for years without generating revenue.
When the oil runs out in 20 to 50 years, the future of the norwegian ecomony depends on finding new industries. Any spending of oil money that doesn't go towards securing this is irresponsible, IMO.