While upstreaming is incredibly important for long-term support it isn't nearly as exciting as the reverse engineering work the people mentioned were responsible for
Didn't know that, thanks. Then speakers are actually a pretty big data source. I bet most people don't assume their speakers can be listening. I wonder if you can get internet connection over bluetooth aux or what'd be the best way to get someone to let you send data home on a speaker.
i did some cursory digging, but i don't really want to read the A2DP or AVRCP specifications to see how much data is allowed in the non-audio payload. Besides, PAN exists, but i imagine you have to do something on your phone to allow it.
Most of these expensive things also have wifi, though, don't they?
> Connect your devices and control everything with our soundbar that integrates your favorite voice assistants and smart services like Built-in Alexa², Chromecast³, Airplay 2⁴ and more.
Imagine there's a machine that you can deposit dollar bills and it registers in an internal database how much you have. The machine calls these stored values as wrapped dollar. You can withdraw your wrapped dollars back as dollar bills whenever you want.
This machine also allows you to send these wrapped dollars to other people - it just subtracts from your balance and adds to the other person's.
What this guy did is transferring his wrapped dollars to an address no one controls instead of withdrawing as he should. This address was the machine's address, but it's not programmed to handle the balance in it's own account and it runs code that can't be upgraded, so any values sent there are lost.
In this example dollar = ETH, wrapped dollar = WETH, machine = the WETH smart contract.
The real problem here was thinking a ETH transfer (dollar bill deposit in the example) works the same as a WETH transfer (database transaction in the example).
Thanks. This all sounds so complicated and frankly scares me away from using these technologies. I would be worried about making this kind of mistake or worse.
You only need an internet connection the moment you're activating the eSIM for the cryptographic keys to be downloaded. From that moment forward it acts just like a regular SIM card.
Pressing ctrl-d a couple of times, seeing what will change, and typing something is most of the time easier and faster than thinking about a regex. At least that's how I feel
Yep, I can see that being easier depending on what you prefer, I just wanted to point out that the feature wasn't unique to multiple cursors, since it was being described as "find and replace on steroids".
Possibly, however since the writeback behavior is configurable I expect you could test that thesis by changing the aggressiveness of the writeback draining.
Due to the hierarchy of dns you can ask to a root server who handles .com, then to that server who handles google.com, then to that Google server, who handles mail.google.com, and then you can connect to it. If you allow anything to be a TLD the root servers need to know about everything, which isn't really feasible
> If you allow anything to be a TLD the root servers need to know about everything, which isn't really feasible
I wonder about that: The number of TLDs in my scenario would be approximately equal to the number of user-registered[0] domains now.
The .com root servers already need to know a large fraction of all 'user-registered' domains, and will need to scale to a much larger set of data as the number of domains grows.
Therefore, I expect that scaling to all 'user-registered' domains wouldn't exceed the root servers' capacity.
[0] I can't think of the technical term at the moment, but domains such as ycombinator.com, bbc.co.uk, ox.ac.uk, etc. Second-level isn't quite correct (see the .uk examples), and I know parsing the user-registered part is a bit of a challenge; see https://publicsuffix.org.
