HN user
In the case of NotebookLM, the AI generated podcasts aren't competing with existing podcasts, they're competing with other ways of consuming the source material. Would I rather listen to a real podcast? Yes. But no one's making a real podcast about the Bluetooth L2CAP specification.
I've found some still have a weird tendency to defend bad UX on apple products, even if it's obviously bothering them. I've heard similar sentiments as in the article too, especially about the app store, but it's not something people go around announcing to everyone anymore, like they used to.
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.
This is true, but this was never really a problem for the adoption. Spec delays, no firmware upgrade support, and most importantly no proper backing by phone or gateway vendors. Thread and matter seem to have fumbled their opportunity though, so it might not be too late.
Isn't named registers an advanced enough feature that it shouldn't be optimized for new users?
In the US, wages, vacation, healthcare, pension plans and care for the elderly are private arrangements set up by everyone individually (technically). The Nordic model is a collective arrangement, where safety nets are provided by the government, benefits are governed by law and compensation is governed by collective agreements between unions and employers.
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.
Contrast that to the last time I worked with Nordic in a professional manner, I had to sign NDAs to get the full documentation and toolchain
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.
Think of yourself as the person you want to be, not the person you are.
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.
Odd not to see Zephyr mentioned at all, it's got way more activity than most (all?) of the projects listed, and many of the sponsors are actively involved.
Yes, actually. I have to charge for 30-40 minutes every 5 hours or so. That fits well with my meal schedule, and most charging stations are at or close to restaurants or shops. Charging at these stations is almost as expensive as gasoline though.
I wouldn't normally drive more than 1000km in one trip though, and that's at most once per year.
A VW Golf starts at 35800€, and a VW ID.3 starts at 32800€, taxes included. Overall, electric cars are a bit cheaper than their counterparts, but not a lot. However, today, petrol is 2.15€/l and electricity is 0.013€/kWh. That's 11.20€/100km versus 0.185€/100km for the ID.3, literally two orders of magnitude cheaper. Everyone charges at home, and there's also a 40% discount in toll roads, which saves me about 8€ per day I'm commuting.
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.
It's not obvious if you come from emacs, but the keyboard centric navigation is very different from traditional IDEs, that usually come with a wide array of buttons with weird icons at the top.
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.
studies will point that radiation are not harmful until they are.
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.
This is true, but the connection request only comes on one channel. The sniffer can be set up to follow an advertiser though, which makes it jump to the next channel in the sequence as soon as the time window for sending a connection request after the advertisment is gone. It picks up connection requests virtually every time in this mode.
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.
I wrote some of the firmware for this sniffer. As others mention, Bluetooth Low Energy works on multiple channels, with connections jumping from channel to channel in a predefined pattern. Bluetooth stacks are implemented to act as one of the two parts of a connection, and there are no apis that would let you change this, as it's normally not relevant.
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.
3) isn't really practical without some storage mechanism though. Sure, you can make a change that sits in ram until the next power cycle, but you could do that with firmware too if you plan for it. Whether you store the raw data in executable flash or in some external eeprom doesn't really change the workflow much.
Truly one of the greatest albums ever made IMO.
+1, this approach will also highlight cases where you're trying to generalize something that isn't as generic as you thought.
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.
I have published some extensions with about 300k users in total. So far, I've only had two people ask me to publish on open-vsx. I did make one attempt, but something broke in the signup procedure, and it took 3 weeks for someone from support to come back to me with a fix, so I had moved on.
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.
I'm someone else, but I did the same thing 5 years ago.
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.
I also joined in 2010-ish, and although the big subreddits have been declining forever, some of the niche ones have improved massively because of the increased number of users. To me, reddit is two parallel user experiences - interesting discussion in niche subreddits matching my interests, and mindless doom scrolling through the big, astro turfed generic subreddits. There used to be more overlap between the two, but the days of interesting comment threads in the default subreddits are definitely gone now.
drive-by take-down by someone with none of the context.
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.
I assume they read the code that tries to parse the data, and come up with formats that don't fit. If the code is open, they don't need accounts to see it
It'll only evaluate the pointer once. It's possible to make this a function though, that might be preferable
Yes. This example is supposedly a common starting point for this type of application: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble...
Whenever Starbucks try to break into a new city, they'll lower their prices, allowing their stores to take a loss for the first few years, just to starve out the competition. Smaller shops don't have the economical buffer to fight this, and Starbucks eventually take their customer bases and becomes the dominating shops.
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.
Spotify clogs the write queue on my workstation (w/ssd), giving me 2 second freezes every 5mins or so. I don't know if it's this bug, but the disk write numbers and database file match, and the only remedy is exiting Spotify.
My grandmother had it too. In my aunt's words, after she passed: "It's like losing my mother twice - first the person dies, then the body"
I read it as a separate diff 200 lines later. But I guess pull requests could easily have that big diffs in a public repo