spoondan

There’s no need to speculate that Melinda had special knowledge. Epstein was convicted of procuring a child for prostitution in 2008 and was subsequently a registered sex offender. Bill admits to attending dinners with Epstein until 2011.

Kimono is 着物 which transliterates to “wear-thing.” It’s the word for clothes, not just the traditional robes, and it’s not etymologically related to a word for Winter in any language.

Japanese has many -mono words based on verbs: tabemono 食べ物 is food (eat-thing), nomimono 飲み物 is a beverage (drink-thing), tatemono 建物 is a building (build-thing), kudamono 果物 is fruit (reward-thing; the Japanese word for “to fruit” being related to the verb for achieving, similar to English “come to fruition”).

Similarly, awesome is great, but awful is terrible. And terrible and terrifying are bad, but terrific is awesome.

Maybe. But a possible contributor for the 1918 flu pandemic's relative obscurity is that it overlapped with World War I and was followed within ~20 years by the Great Depression and World War II. It occurred during one of the most turbulent times in modern history.

In contrast, the 2020 pandemic is presently not sharing the spotlight. Maybe something of comparable impact will happen. Or maybe it'll be forgotten regardless. But I don't know that the 1918 pandemic's status is all that illustrative.

No. If Alice reports Bob, the report only includes the most recent messages from Bob to Alice as forwarded from Alice's local copy of their chat. No other messages are made available to WhatsApp. None of Bob's other messages to other people are included, nor could they be since Alice wouldn't have them. In your scenario, if Alice was law enforcement or cooperating with law enforcement, her reporting Bob and then them subpoenaing WhatsApp would only grant them circuitous access to messages from Bob they already had on Alice's device.

But it isn’t a good point absent the bad assumption that the mentally ill are more dangerous. It only takes one bicyclist that’s fallen off his bike to kill you. So what?

I appreciate that they decided to apologize, but I find this statement lackluster at best. A better, more earnest apology would properly address the major concerns Jeremy raised. This touches on just two of the issues and then only superficially. I don't expect them to lay everything bare and pay public penance. I'm not interested in assigning blame. But apologies ring hollow when you don't even discuss what, if anything, you feel you did wrong.

In fact, in committing only to "improve our process to avoid this from happening," it reads as if they take no meaningful responsibility for how they handled informing Jeremy. It feels as if they are sorry Jeremy was stressed out for a week but unapologetic for any of the numerous and hard-to-defend actions they took to cause that stress. They blame the process, as if it required them to inform Jeremy of a complaint they weren't ready and willing to discuss with him, to assure him they'd give him details the following day and then renege on that, to not give him adequate time to understand the accusation and formulate a response. And it is apparent, from the story as both sides tell it, that far from a "crucial miscommunication," the Committee was accurately communicating what they thought. Their error was in prematurely drawing conclusions and not giving Jeremy the benefit of the doubt.

They also don't address the confusion around having two differing codes; the serious and counterproductive issues with Codes of Conduct prescribing acceptable behaviors (instead of proscribing unacceptable ones), especially when such prescriptions are vague; or Jeremy's accusation that the Committee, itself, failed to follow their own Code(s) of Conduct and Enforcement Guide. And while I would not want or expect them to discuss the specifics of Jeremy's case (unless they have his consent to do so), I do think it's necessary to discuss the issue of whether they believe merely making someone uncomfortable through disagreement on relevant topics can (let alone should) be the sole/primary basis for a finding of misconduct, especially when the people made uncomfortable are not even the person that is being disagreed with.

Perhaps they've given Jeremy a more in-depth and sincere apology and explanation in private. But I don't think that suffices. Like Jeremy, I believe that Codes of Conduct can (and often do) play an important role in improving our communities and events. I'm sure the Enforcement Committee would claim to believe this as well. But the numerous mistakes they've made in this matter do serious harm, not just to Jeremy, but to the larger cause. The way to mitigate (if not remedy) those harms is by honestly admitting to mistakes

“Mendaciously pretending,” is over the top. Even if you don’t agree with the author’s point, even if you think the tested users are idiots or unrepresentative, there’s simply no justification for calling the author a liar or suggesting he’s anything less than earnest.

It’s entirely possible that none of these users thought to use the menu bar for these tasks. I, for one, have never thought to use the “Go” menu to get to the enclosing folder. Why? I don’t know. Maybe I’m dumb. I guess it didn’t occur to me that such a frequently needed action would be provided and yet not given dedicated UI in the window frame.

Similarly, I “know” how to set the default program to open a file from the info pane, but I always end up re-discovering it because I do it so infrequently, and it’s not intuitive to me to find it under “Get Info.” I always doubt it until I find it there.

Nor does it matter where macOS inherited usability issues from: they still exist in macOS, they still affect macOS users.

I also think you’ve taken the wrong point. I don’t read the post as arguing that macOS has just as many discoverability issues as iOS or that it’s not in better in some ways. Instead, it seems to me the author is clearly arguing that macOS also has discoverability issues even for daily and power users, and thus we should re-evaluate both how good macOS’s discoverability is and how bad iOS’s is.

There’s an important point to be made here about the gap between theoretical and practical security. Overly elaborate password policies (excessive complexity demands, passwords expiring, no reusing last five passwords) end up causing annoyed users to make bad decisions that compromise password security.

Similarly, an excess of popups doesn’t increase security. It annoys users to the point they stop thinking about individual security decisions.

There’s an important intersection of security research and HCI that doesn’t get discussed as much as it needs to be.

It’s interesting to me that these kinds of things are not catalogued and advertised like other vulnerabilities. This is an exploitable information leak using an endpoint that many other services likely have.

About 15 years ago, I built a system like this for a web application. I defined a series of core extension points such as the request router and authentication and authorization providers. Modules provided extensions that connected to the core extension points, as well as define their own extension points that other modules could connect to. Dependency injection was used throughout so that implementations could be easily swapped (mostly used for the tests). It took quite a bit of time to develop this framework, but, as a result, everything was modularized, contained, and composed.

It was a complete nightmare to reason about and work with, even for me, and especially for newcomers. A natural way of trying to understand a system is to look at its entry point. With a system like this, it looks like a skeleton:

    let di := DependencyContainer.make()
    let moduleSystem := ModuleSystem.with_container(di)

    di.register_singleton[IModuleSystem](moduleSystem)

    moduleSystem.find_and_register_modules()

Where do we go from here? The next logical step is into `find_and_register_modules` or into the documentation for the module system (just kidding: I was a "senior engineer," I didn't write docs).

We are left with a lot of questions. How does anything happen? It's somewhere inside the modules, but which one? Does the order that modules are loaded matter? The answer is maybe. Clearly, there are places where order of operations matter. For example, the main navigation should be ordered. How do we accomplish that? (The answer for my system was to have the interface for navigation extensions specify there was a `readonly weight: Float64` attribute. But then to actually understand why things are in the order they're in, and to get things ordered correctly, you need to look up the values for other navigation items. It's secret coupling.)

More recently, I saw a team at my previous company build a system like this. There were dozens of interfaces and implementation classes and code for composing all of this, and the end result was you couldn't just go somewhere and see what was happening. What we really want to see is:

    match maybe_user
        Some(&user) => nav.add(UserProfileNavItem.for_user(user))
        None => nav.add("Login", "/login")

    nav.add("Browse", "/browse")
    nav.add("Search", "/search")
    nav.add("Help", "/help")

Do you have to make a change here whenever something gets added? Yes. You do. But the idea that your program needs infinite flexibility in all areas is simply wrong. And, in fact, everything ends up secretly coupled and inscrutable.

For this reason, my advice has long been to limit extensibility to specific, narrow use cases (for example, filters in an image editing program). Do not build entire systems around extensibility. You are not building an abstract system, so don't waste your time with unnecessary and obscuring abstractions.