wootest

It's not a "deep dive" of the power adapter - it's part of a "deep dive" series of the laptop model, writing an article each about individual components.

The page has a link to activity from 2008. OpenStack started in 2010. In other words, this project had the name before OpenStack.

Which in turn reminds me of: http://simonwillison.net/2022/Aug/16/efficient-pagination-us...

That's fair but in a lot of cases you verify the email for your account and there is activity associated with that account. There are many reasons other than to send unwanted marketing emails for the service to need to get in touch with you, including the many cases where you're entering the email address because you want to be notified of something.

Ignoring every other benefit and concern, verification in the way proposed is a bad idea because part of the verification process in most cases is verifying that the service can send messages to you that actually get delivered. If you do this and then send the first "log in link" email which gets held up as spam or putatively malicious since some server has the temerity to not be located inside the US, doesn't have a DKIM signature, etc, you haven't really verified everything that you need to know. Of course, those things can change at the drop of a hat anyway, but I'd rather have verified that 1 time than 0 times.

If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.

Slightly off-topic, but according to that page, the project has "-1246658 Bytes Project Storage".

Grammar is not the most important thing, but it's hard to exemplify tone and voice without having the common language to talk about them and grammar is that language. I'm guessing the article starts with it because tone and voice is the most universal aspect, not because it's the most important aspect to technical writing. The rest are very hands-on details but that might not apply to everyone.

The two-axis diagram on diataxis is a great way to categorize documentation and all of them have different needs and indeed call for different voices. I have seen a number of projects where the only documentation produced is tutorials or itch-scratching posts for this one thing, and then when a feature changes somewhere you have a mountain of out-of-date information because everything was hard-wired to this combination of dependencies, versions and circumstances (whereas a manual could have been updated quickly and that would be that). And on the flip side, plenty of projects where there is a dense compendium for every detail and it's hard amid all the implementation details of the clustering gossip protocol versioning to find the little list of items you want to know to set the thing up to begin with - linked to the particular sections to read more about installation, configuration, backup, etc.

JavaScriptCore is a constituent part of WebKit, which is pretty much available on washer-dryers these days. But the macOS/iOS/etcOS framework part of JavaScriptCore that adds Objective-C/Swift layers is only available for those platforms, yes: https://developer.apple.com/documentation/javascriptcore

Fossil is an SCM system - https://fossil-scm.org/. Are you suggesting that every piece of software ever kept in, say, git repositories are therefore maintained by the same team?

Where does it say that the authors/contributors of LumoSQL is the SQLite team or from the SQLite team? There are meeting notes at https://lumosql.org/src/lumosql/file?name=doc/meetings/lumo-... which does not overlap with the SQLite developers page: https://sqlite.org/crew.html or with commits going a year back on SQLite's Fossil timeline.

The strongest the README gets is saying "The LumoSQL and SQLite projects are cooperating", which is closer than any other effort I've seen, and welcome if the SQLite project ever wants to swap out the underlying storage engine, but doesn't really mean that the SQLite team "works on LumoSQL" or vice versa. Certainly it looks like LumoSQL has put significant work into the cooperation by using Fossil and by "not forking" which may have made the cooperation palatable.

Also, the SQLite project has been consistent on wanting to write all the code for SQLite themselves and not merge in patches (https://sqlite.org/copyright.html). Them working on another exploratory project would be a way for them to absorb those changes back into SQLite in a way that wouldn't be incompatible, but it would have to be the same team doing the changes for that to be consistent.

I understand the pedagogical example as a stark contrast, but this choice is immediately turning me off the product. Startups and the companies they grow into have spent decades helping themselves to data to track and identify and write clauses into their policies and terms of use to be able to stockpile behavioral data for a potential future "pivot" if nothing else.

We are living in a world where it is more based in fact to assume that companies will help themselves to this kind of information under a variety of pretenses than that they won't. The only reason people will assume differently is if they trust the company, the product and the people behind it. The policy seems to be doing its part, but trust needs to be built by every conversation with a potential future customer. If the question that pops up is "how can I be anonymous if I pay you each month", the resulting argumentation should not be able to be construed as "we're sorry, but we're not going to help be your burner phone", which the comment I'm replying to is toeing dangerously close to.

People search for many things and it could detail their interests, their current location, their financial troubles. The commitment needs to be "we will never, never, never, ever, do anything like this", and not just "it doesn't make sense for us to do this". Because if someone wanted to build in that sort of tracking, it could "make sense" from a business standpoint to do this in that the data, if collected, has a lot of value on the market.

Even if the incentives are indeed aligned to keep the paying customer pleased, we also need to know that if we do walk away, that at that point there will not possibly be anything left as an artifact that a future buyer could do anything with. This assurance will be most effective if it's rooted in trust and values rather than in practical concerns; the practical concerns are valid, but only if they are restraints that have been applied in search of an objective by yourself, instead of "it is not currently in our business plan". (As an extreme example, consider a bank saying "we'd never pick items out of our customers' safe deposit boxes and sell them; it would simply be too much work".)

Basically, the facts seem reasonable enough. But you need to work on not coming off like the parent saying "well I'm sorry you want to hide things from me", which is what unprompted bringing up the covering up of criminal activity in response to questions of anonymity and privacy does. I understand that those concerns do come up in thinking responsibly about a product like this from all angles, but making it a part of a discussion with a potential customer disrespects and denigrates their fundamental needs enormously, the same needs that would make them attracted to the product in the first place.

Many designs does this implicitly. At least one, the original iPhone keyboard autocomplete/suggestion algorithm, did it explicitly.

Ken Kocienda's book Creative Selection has a very good chapter on the algorithm being built piece by piece, but finding out words being created by surrounding keys was part of collecting all the candidates.

They even used this in marketing. One of the pre-original-iPhone-launch videos was focused just on the on-screen keyboard (probably because almost everyone thought it was a really kooky idea at the time), and used the example of explicitly pressing "O-U-Z-Z-A" but still getting "pizza" as the autocomplete because it was the closest recommendation.

One of the iOS versions a few years ago became incredibly fond of including the space bar and considering alternatives with slightly off key presses near the space bar split into two or more words. When you're using a language with a lot of compound words like Swedish, this yielded some almost postmodern corrections with one or more words often completely different (but close on the keyboard, of course). I don't know if this was a tweak to the manual algorithm going off the rails or an AI version that wasn't quite tuned well yet.

Sounds like you're re-making the arguments in the article without realizing it.

No amount of work will make the inherently complex less complex, but doesn't have to be more complicated than it has to be. That's what "as simple as possible" means. If you have to peel down a strange interpretation of a problem or a misguided attempt to "dumb it down" before you get to the complexity, it's definitely more complicated. Over-simplification is pretending the complex doesn't exist, or chipping away at some parts until it looks simple, or straight-up disbelieving that there are complex needs and forgoing them.

I haven't read "Don't make me think", but I have read other books by the same author and his general message is that everything should be clear and approachable such that you can tell what things are and spend your energy actually solving the problem or accomplishing what you want to accomplish.

The author of this piece (and perhaps the author of "Don't make me think", which I haven't read) respects only the simple desires of the majority of users. S/he does not respect the complex desires and needs of minorities of users, nor the potential for the majority-user to refine and develop their needs and desires.

This reading pairs poorly with this quote from the article: "And I’ve found that good products, ones that respect their users, give them more control." If the author really was out to knee-cap software, that's an odd sentiment to hold. I think you're in agreement with the author, but somehow take offense at the word "simple", maybe taking it as meaning "stripped down in function". There are certainly a lot of products, services, companies and people who take it to mean that.

Implementation may be strictly mechanical if you have everything planned out NASA-binder style, but surely there'll still be a need to adjust the plan from time to time? Then there's debugging and maintenance, both of which may not require all your creativity all the time, but if you're creatively sapped, you're walking into it with a few tires already slashed. At least that's what I've found in my own experience. It's not that you have to be creative constantly, it's that you have to be able to summon up the capacity to be creative at any given time.

That's not an exclusive or.

No points for "based on LLVM" and "opt-in as you please side by side with Objective-C"? (Side by side with Objective-C probably does not require the Obj-C runtime, but it's hard to see how it wouldn't want to use it.)

I did not predict ARC. I'm not a genius, oracle, memory management expert or compiler writer.

I love Siracusa, but what he's been saying is "well, they're gonna need something or they'll fall behind". Which is a fine bet and was a prescient analysis even in the rounds before. Copland 2010 was his idea in 2005 that they'd essentially have something new and modern by 2010, which they didn't, but they had started evolving Objective-C again and added GC, so they hadn't been completely standing around.

I made a separate bet, saying that "they're working on a new language with these characteristics". For four years, this was an insane idea, they're not going to go all that trouble just to chuck Objective-C, I was mad and should be ignored. This week, that line of dismissal argument changed into "in hindsight, he was only stating the painfully obvious and anyone could have done that", which is nice and weird and a reversal fit for Steve Jobs.

That said, both Siracusa and I completely missed ARC, which is basically probably what made Swift worthwhile.

Yes, I may have been wrong on that part. Or it was planned but not started yet. Or Chris Lattner read that post and thought "we've gotta get on that". Or whatever.

Regardless of that, a lot of details match (opt into it, side-by-side with C and Objective-C, compiler based on LLVM, not based on C, modern language, specifically made to match the frameworks).

This news post is from January. Nadella was appointed in February. Although he's been leading that department for years, so I guess you could say that, but it's not due to him becoming CEO.

Thanks, that's very kind. As you say, it all hinges on every single one of their big mistakes being correctable now and avoidable in the future. Microsoft doesn't have to figure out how to be Apple or Google or what have you; it has to figure out what products they're missing and what the products they already do have has to do in the year 2014 to be relevant. That's not completely different from what they did in the year 2004, but it won't be solved by serving up what they had in 2004 either, nor by skipping to what they think is the endgame.

Beacons are passive. They have an ID and you're supposed to know what that ID means by some other band of communication or intrinsic knowledge.

I can't find a use case for telling the Mona Lisa that you have a dentist appointment or a pending call. You will probably have to pair with the device to get ANCS to start relaying notifications; iBeacons couldn't work if they had to require pairing.

I never said they'd make a watch. I said it's curious that they're so obviously aiming it at a very resources-constrained device (or optimizing out the wazoo for energy efficiency) for which they don't have a client of their own or an announced third-party client. You'll note that they didn't announce "iOS in the Nebulous Theoretical Arbitrary People Transporter" and hope people take it from there.

With iOS in the Car, whatever they're using - probably AirPlay or something riding the various MFi (made-for-iWhatever) protocols - is already transmitting screen images. If they have a notification protocol like ANCS, they will probably not reinvent it, but iOS in the Car already involves several of their own protocols, so why use yet another connection - and if they do, why invent a new protocol and publicly document it for this use case?

Maybe it's about roaming notifications to OS X Mavericks, but there are no (revealed) commands for getting i.e. app icons.

Actually, whether they make a watch or not, it's very curious to see them introduce a new binary protocol in the open. If this is a turn towards being more open, I welcome it. It's far from enough, but it's a start.