A good industrial designer makes it about the user. A bad industrial designer makes it about themselves, the manufacturer, etc.
10,014 karma · joined June 10, 2010
This isn't about the Apple Card. It's about an iOS app called "Cards" which lets you physically mail personal cards straight from your iPhone.
The current situation with AI is that everyone is going as fast as possible. So, we can logically eliminate speeding up because it's impossible by definition. And we can practically eliminate staying the same speed because why make a big fanfare and coin a special term to announce that you're keeping the status quo. By process of elimination, it must mean slowing down.
It's very hard to understand. It doesn't make sense that a criticism of the camera would be an insult to the subjects of the photo.
The criticism is that the image isn't an accurate representation of the subjects. If B is bad, and B != A, it doesn't follow that A is bad.
It creates a new chat which has the conversation up to that point and a link to the conversation you branched it from.
The UI isn't tree-like, though. It's more like Git where each branch name is just mixed in with the rest of the soup of references.
So even on a 56k modem, it might take less than 1 second to load each image.
You could also optimize it so it skips intermediate images if the user types fast. Suppose the user mashes "12345" in a fraction of a second. You start loading "1.jpg" on the first keypress. When you've finished loading "1.jpg", the field contains "12345", so skip straight to loading "12345.jpg".
The demo page's JS doesn't seem to include any optimization code like that. It just updates the img src whenever the text changes. Yet my browser seems to do it automatically! If I mash several keys, the console network log shows only some intermediate images get loaded.
I guess the browser is smart enough to know that, by the time it would have started the download, the resource no longer exists in the page. I'm not sure if browsers ~20 years ago did this, but it would have been worthwhile given how slow networks were.
Practically speaking, I might just allocate an array of 100 pointers. That's only 400 bytes. Then as you encounter each filename, allocate just enough memory for the actual length of the string (plus null terminator) and store the pointer in the array.
OK, but isn't the kernel keeping the directory listing in the disk cache? Won't that prevent extra physical I/O if you do just read the directory twice?
If so, then in the second pass, it's all cache hits, and you're just paying the cost of calling into the file system. Hopefully that's pretty fast. But even if not, it's still absolutely dwarfed by the physical I/O required for the first pass. Windows XP era storage was spinning hard drives, not flash.
And if not, then I'm probably going to put my user icon coding task on the back burner and go ask the kernel team why a seemingly very common usage pattern isn't optimized.
(I realize he's not claiming the performance benefit was significant. I'm just trying to see it in the right perspective.)
It took me a while to figure out I had to click "Explore" to get to the specs, so I'm saving you the trouble.
As long as I'm griping about the web site... Apple, when you introduce a phone with a new and different form factor, please just tell me the dimensions straightaway. This one is shorter and wider than most phones. Is it too wide to fit in my pocket? I need the dimensions to answer that question.
(I'm not trying to be pedantic, but if someone is having trouble finding the button, the exact text is helpful.)
Also, here's where the button takes you: https://deepmind.google.com/science/weatherlab
In both cases, the company operating it promises they did lots of things to make it safe. SDC companies talk about testing, redundancy, simulations, and statistics. LLM companies talk about alignment, sandboxes, defense in depth, and restricting access to dangerous capabilities.
The one substantial difference I can see is that LLM chats are (nominally) passive but SDCs are active. In a chat, you're just having a conversation and then you're choosing how to act. When riding in a car, you the user are not in the loop between AI and taking action that affects the world around you. So they might be designed and engineered a bit differently. A SDC can't get you to agree to review the steering and braking decisions before they're put into action. Since you're not being asked to take that responsibility, it's more defensible to infer that the service has done whatever is necessary to make it safe.
Visi On[1] was a graphical operating system for the IBM PC that actually existed as a commercial product, though definitely not a very successful one. It was made by VisiCorp, the same company that created VisiCalc (the first spreadsheet for a personal computer).
It was demoed at COMDEX in 1982, before the Apple Lisa was released. It came out after the Lisa but slightly before the Macintosh.
Here's their promotional video from 1983: https://www.youtube.com/watch?v=kc4wFeVvKTI
Fun fact: Bill Gates saw the demo at COMDEX, and at first he was skeptical that it was really running on an IBM PC. But ultimately he was so impressed he decided[2] to start developing a product called Microsoft Windows.
---
Also, do you have the same issue with the demonyms Manhattanite or Seattleite?
In other words, if company A and B both offer you a product for $N, but A protects your privacy better than B, then A might get more customers. This competitive advantage can be an incentive for privacy.
However, there definitely limitations. If the value of this competitive advantage is less than the revenue they make by selling your data, then it's not a strong enough incentive. It also only works if consumers care about privacy and take the time to factor it into their purchasing decision.
But the photo caption paraphrases him and says that the white paint fights (as in prevents) the heat, which uses similar words but a different logic to it (but the same overall meaning).
If I've got that right, then I think the blame lies on whoever wrote this article for making it confusing.
Oops, I got one wrong.
Copyright("©"): compose + "c" + "o".
The one I had is bigger: Ⓒ vs. ©.
For whatever reason, the OS documentation lacks a list of allowed compose key sequences. But they are intuitive enough that you can find many of them through experimentation. For example:
Musical sharp ("♯"): compose + "#" + "#".
Interrobang ("‽"): compose + "!" + "?".
Letter "ñ" as in "jalapeño": compose + "n" + "~".
Copyright ("ⓒ"): compose + "(" + c + ")".
BASIC[1] came out in 1964, and Pascal[2] came out in 1970.
---
[1] https://en.wikipedia.org/wiki/Dartmouth_BASIC
[2] https://en.wikipedia.org/wiki/Pascal_(programming_language)
All of which are things people have on occasion believed to be true and found out later they were wrong about.
When there isn't a zero-risk option, the question becomes which risk is smaller.
With any type of bank card, there's a bank that guarantees to a merchant that they will later receive a payment. With a debit card, the guarantee is backed by money you have on deposit. With a credit card, it's backed by the bank's money, which is higher risk for the bank.
Two US companies, VISA and Mastercard, have big networks for processing transactions with bank cards. These networks act as intermediaries to connect merchants (who want to accept payments) and banks (who issue cards) together. It's much simpler for a merchant to send a request to (say) VISA than to figure out which bank issued each customer's card. The payment networks also define, publish, and enforce standards and rules for the payment process.
These networks aren't banks. But they are, in a sense, bank card companies because they are part of the bank card system.
So in other words, European consumers have an account at a European bank that issues them a card they can use for purchases at European businesses, but US networks connect it all together.
https://en.wikipedia.org/wiki/Four-tube_television_camera
This says the main reason for four-tube is image registration. Basically, the incoming light is optically split up into red, green, and blue, and these go to separate sensors. Being separate sensors, they may not be physically aligned. So if you sum R + G + B together to get luminance, the picture will not be sharp.
You can solve this by adding a fourth (black and white) tube for luminance. Since it's just one tube, there is no alignment issue for the luminance part of the picture. And the eye is less sensitive to color, so while the color alignment issues remain, they aren't very noticeable.
At first when I read this, I assume the camera must have to somehow combine the fourth tube's signal with the other three tubes' signals. But since both NTSC and PAL encode luminance and chrominance separately, apparently this isn't necessary. It's the TV that combines them. With a three-tube camera, the sensor signals have to be split into luminance and chrominance. With a four-tube camera, you just take luminance from one sensor and chrominance from the other three sensors.
Suppose you make a 1 kB change in a 50 MB file. That causes a 64 kB chunk to be created and stored. Disk space is wasted.
But since the 50 MB file was already stored as a sequence of 64 kB chunks, there is an existing 64 kB chunk that is very similar to your new 64 kB chunk. You can store your new chunk as a delta to that, so only ~1 kB of disk space is used.
Admittedly, it's complicated and inelegant. But it allows both deduplication between files (one of the reasons Lore chose chunks, apparently) and efficient space usage for small changes.
Back in the 1990s, a Mac sysadmin showed me a clever trick for this.
Get one specific Apple Desktop Bus keyboard that has a soft power key on it, I believe the Apple Extended Keyboard[1]. Then get a Bic pen[2]. Push down the power key on the keyboard, and while it's still down, wedge the pen cap between the key and the keyboard case.
The pen cap is the perfect size and shape to hold the key down, and Bic pens are easy to find. There are no ill effects from having the power key down all the time, and the Mac will boot up after a power failure. So you don't have to drive to work just to push the power button.
This was especially handy considering you sometimes needed to use Macs as servers (file server, printing, certain Mac-only applications, etc.), but Apple did not make servers.
---