e_y_

It would likely get voided as unconscionable if they just unilaterally demanded it, but it might hold up in specific circumstances (if the user is well-aware of the salary demand when they accepted the contract, and the user gets some proportionate value out of giving Apple a percentage of salary).

A lot of big manufacturers have had recalls (for things like laptop batteries, vehicle batteries, the infamous Hoverboards, etc) so I wonder what Anker's batting average is compared to others. It's clearly a hard problem and squeezing in the level of density that customers expect means potentially thinner safety margins.

It's not just a theory. It's well documented that Apple has a bunch of APIs and protocols (like AirPods proprietary low latency wireless instead of Bluetooth, NFC was not allowed until years after Apple Pay) that are not available to 3rd party developers. They will sometimes open things up after they've given their own products years of head start because apparently owning most of the ecosystem and having undying brand loyalty from their users isn't enough.

Actually for many years even to build regular Bluetooth devices that did anything besides audio, you needed to add a special chip (Made for iPhone chip) to your hardware to verify that it was an authorized Apple Accessory. Pebble had one, but any 3rd party apps that wanted to send data to the watch (like Uber app, sports apps, random indie apps) had to get allow listed to communicate with accessory devices like Pebble.

Ambulances are expensive enough that people are hesitant to call them, sometimes even in life threatening situations.

And if the person is unsure whether the situation is critical, they might try to "sleep it off" rather than driving or getting a ride, because ER is also kind of expensive and you could be stuck there all day.

If we're talking about public tracking: package theft

And Waymo doesn't currently operate on highways for passenger service (I think they have authorization to, but they're only testing on highways right now).

They should be able to get to SFO from Millbrae Ave and San Bruno Ave without getting on the highway proper, although it'll likely be a lot slower unless you're getting a ride from nearby. While SJC can serve downtown SJ and Santa Clara without getting on a highway.

Most likely both agreements had been in negotiations for a while and not something they just pulled together last week in response to SJC, although it's possibly they could have used it as leverage (hey we've talking to SJC ...)

Most cities don't have the density and wealth of Manhattan. How do we solve the last mile problem for everyone else?

Taxi services can potentially complement public service by filling in the gaps: last-mile connections (home to train station) and backup service late at night when transit runs less frequently or not at all.

There's a risk that robotaxis could become too cheap and people use them for point-to-point transportation because it's faster. This could be mitigated through taxes on robotaxis (with incentives to connect people to transit) and/or car usage in general, or maybe using robo-buses to provide a middle ground between personal convenience and system efficiency.

Could also be a big challenge if you have dozens or hundreds of autonomous cars in the area that need manual intervention to get them out (plus the people who get stuck there)

This seems unlikely. People are creating libraries and they're getting a lot of downloads because they're genuinely useful. It's a lot of work to write and maintain a library just for resume street cred.

I think the ecosystem has more of the opposite problem: engineers create libraries to scratch a particular itch, because they needed to solve a problem for their own project, or maybe it seemed like an interesting solution that they wanted to share with the world. If the person was working for a company, they may even be paid to maintain it for a while.

A bunch of other projects start depending on it, but the original creator/maintainer has moved on. They might not even be using the library for their own projects any more, nor paid to work on it. Now they're stuck maintaining it out of a feeling of obligation, or maybe it's a passion, but at a certain point it becomes unsustainable and the project becomes unmaintained or under-maintained (huge backlog of tickets). Maybe they find new blood to help out, maybe they don't.

To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.

For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.

There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.

There's quite a few formats that are self-describing already, so having a format that can skip the type and key tagging for that extra little bit of compactness and decoding efficiency is a unique selling point.

There's also nothing stopping you from serializing unstructured data using an array of key/value structs, with a union for the value to allow for different value types (int/float/string/object/etc), although it probably wouldn't be as efficient as something like CBOR for that purpose. It could make sense if most of the data is well-defined but you want to add additional properties/metadata.

Many languages take unstructured data like JSON and parse them into a strongly-typed class (throwing validation errors if it doesn't map correctly) anyways, so having a predefined schema is not entirely a bad thing. It does make you think a bit harder about backwards-compatibility and versioning. It also probably works better when you own the code for both the sender and receiver, rather than for a format that anyone can use.

Finally, maybe not a practical thing and something that I've never seen used in practice: in theory you could send a copy of the schema definition as a preamble to the data. If you're sending 10000 records and they all have the same fields in the same order, why waste bits/bytes tagging the key name and type for every record, when you could send a header describing the struct layout. Or if it's a large schema, you could request it from the server on demand, using an id/version/hash to check if you already have it.

In practice though, 1) you probably need to map the unknown/foreign schema into your own objects anyways, and 2) most people would just zlib compress the stream to get rid of repeated key names and call it a day. But the optimizer in me says why burn all those CPU cycles decompressing and decoding the same field names over and over. CBOR could have easily added optional support for a dictionary of key strings to the header, for applications where the keys are known ahead of time, for example. (My guess is that they didn't because it would be harder for extremely-resource-constrained microcontrollers to implement).

I never went to parties in high school, but based on my experience going to parties in college and as an adult, I imagine your individual experience at the parties would be very different depending on your social groups, social skills, and so on.

Although even as a non-participant, witnessing a party first-hand would be more informative than the filtered version you get from Hollywood.

Also depending on how many corners you're willing to cut. Half the cost but a 1% chance that it turns around and targets a friendly? Some countries would take that trade.

I wonder if Ukraine has been removed from the exclusion list since then. A quick Google search says that the keyboards layouts are different from Russian keyboards.

The heat load of the ISS is a handful of astronauts and some equipment and whatever it absorbs from the sun. Not an entire data center or a nuclear rocket which is where the radiator discussion comes into play.

As someone who isn't a Go programmer, on the face of it using strings (struct tags) for field metadata seems pretty backwards compared to Rust macros (which parses the metadata at compile time) or Java annotations (which are processed at runtime but at least don't require parsing a string to break apart options).

The accidental omitempty and - are a good example of the weirdness even if they might not cause problems in practice.

https://en.wikipedia.org/wiki/Big_dumb_booster

There's also many advantages to being able to lift something large/heavy in one go, rather than smaller payloads that need to be unfolded (like JWST) or assembled in space, which can drastically increase the development costs.

The Slickdeals comment thread for the HP Touchpad firesale has over 285,000 comments

https://slickdeals.net/e/3220862-hp-touchpad-9-7-wifi-tablet...

Have you seen Adaptation (2002)? It has a wildly meta, fictionalized/comedic portrayal of Susan Orlean's book and the creative process of screenplay writing

Yes. These people are the rank-and-file, doing good engineering work until the USDS got hijacked by Elon's crew.

It's also harder to speak out when you're a US government employee, but now that they've been fired ...

On desktop, CPU decoding is passable but it's still better to have a graphics card for 4K. On mobile, you definitely want to stick to codecs like H264/HEVC/AVC1 that are supported in your phone's decoder chips.

CPU chipsets have borrowed video decoder units and SSE instructions from GPU-land, but the idea that video decoding is a generic CPU task now is not really true.

Now maybe every computer will come with an integrated NPU and it won't be made by Nvidia, although so far integrated GPUs haven't supplanted discrete ones.

I tend to think today's state-of-the-art models are ... not very bright, so it might be a bit premature to say "640B parameters ought to be enough for anybody" or that people won't pay more for high-end dedicated hardware.

I would generally agree, but in many cases 1) people don't read the comments/replies, 2) interesting responses get drowned out by low-quality responses, 3) the criteria by which useful responses get highlighted can be skewed by a variety of factors, including vote brigading and algorithmic bias or sometimes just a bias towards the earliest comments (which get upvotes, which then get more views, which get more upvotes).

Sometimes it's good to know where people stand when they're shooting themselves in the foot.

Waymo is pretty good (but not perfect) as far as safety, but there's too many ways it can get stuck. Including vandalism from humans like "coning". And if a significant number of them are on the road, it could gum up traffic when that happens.

I still think it'll do well because even if you need to hire 1 person to remotely monitor every 10 cars (I doubt Waymo has anywhere near that many support staff) it's still better than having to pay 10 drivers who may or may not actually be good at driving. But to really take over they'll need to be much more independent.

The Information claimed today that ByteDance is renting GPUs in the cloud, although ByteDance denies it (well, they call it "inaccurate" which is not exactly a strong rebuttal).

https://www.tomshardware.com/tech-industry/artificial-intell...

They're industrial robot arms, not humanoids, although the concept of android workers getting paid an hourly fee or "wage" (going to their masters, an android rental corporation) would be fascinating.

You can be smart and still slip up, especially under pressure (and as we're learning, possibly mental and physical pain). Presumably one of the reasons why professionals are better is that, beyond working experience, they have a lot of practice.

"Engineers are more likely to be terrorists" is different from "terrorists are more likely to be engineers".

You can imagine that engineering is a useful skill for terrorism and thus terrorist organizations might spend extra effort trying to recruit engineers. They may also have a higher survival rate working on behind the scenes tasks rather than firefights and suicide missions, which could cause a survivorship bias in data collection.

(It's also interesting how many foreign leaders and dictators have engineering or science degrees, and/or went to US universities prior to becoming leading figures in their home countries.)