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.

No. WhatsApp does not keep delivered messages, and, by default, messages are end-to-end encrypted and cannot be read by WhatsApp.[1] As shown in the screenshots of the reporting feature in the article, reporting causes your phone to send (forward) the relevant messages from your phone to WhatsApp as part of the report. For reporting a user or business, the relevant messages are "most recent messages" from the user/business. For reporting a group, the relevant messages are "most recent messages" in the group.

This feature does not change the privacy story for WhatsApp in any way. You already trust users you are chatting with to not copy or screenshot private messages and share them. You already trust the app to not forward or store your messages without your consent.

[1] See bullet point "Your Messages" under section "Information We Collect" on https://www.whatsapp.com/legal/privacy-policy.

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

No. Look at the cookbook application (http://weboob.org/applications/qcookboob). It incorporates multiple sources of recipes behind a single, consistent, tailor-made interface. This pattern repeats in the other applications. They are not taking a single website and transforming it into a native application. They are building applications to service specific domains that use the web as a data source.

They are also bringing web content into the command line. They have a large number of console applications. For example, there's a command and REPL for tracking shipments.

Putting aside the misunderstanding of what this actually is, the premise of your question seems to be that "simply replacing" one technology with another can't be "liberating." I think that's wrong in general as well for the specific example of transforming a web app to a native one (though these seem to be Python, not C++). The web has constraining properties: browsers that provide rich interaction with modern web content are resource intensive; different websites have wildly different accessibility stories (and the lack of UI and terminological consistency in content is, itself, a hurdle for some people); ads, popups, and other distractions are harmful to load times, network usage, and user experience; and on and on. There's plenty of examples of transformations from one technology to another that trade out the source's constraints for the destination's.

For the specific problem of easily setting up Python environments, you may wish to look into pipenv: https://pipenv.pypa.io/en/latest/

“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.

There may be situations where 15-30 direct reports is workable, but that is a very large number of reports. Academic studies generally settle on a maximum effective team size around seven, give or take a few[1]. In my own experience, I saw diminishing returns and reduced satisfaction in my management performance after ten direct reports. These issues resolved with a restructuring.

But you don't have to take academic studies or anecdotes to heart. Some back-of-the-envelope calculations suggest there are severe challenges to effectively and healthfully directly manage 30 people. Take the typical 40 hour week[2]. With 30 direct reports, that gives a maximum of 40/30 = 80 minutes/week to devote to each individual employee. If the manager does a weekly or bi-weekly 30 one-on-one, that leaves about an hour on average to deal with any issues.

Of course, not every employee has high priorities issues at the same time. But we've only considered the individual, one-on-one work of the manager. There is also the team-wide and cross-team work. And, it turns out, team size also dramatically increases the time and effort these other facets take.

Consider the typical daily stand-up (blech), used to keep the team aligned. If the manager allots (and strictly enforces) five minute slots per team member, that meeting still takes 2.5 hours. People won't be happy with that, and it will cut into the managers limited time to actually make progress on individual and team issues. Even if the manager splits the meeting (to spare team members for a super long meeting), the manager needs to attend each one to stay abreast of the big picture.

Likewise, we presume that if a team has 30 reports, it's because what they are working on is of critical business importance. There are more demands from sibling teams in the same org, more budget and staffer reviews with higher-ups, more hours spent with HR and recruiting. (Alternatively, the manager is empire-building. But that doesn't really help the calculation. The time that the manager would've spent on delivering business value is instead spent on politics.)

Even if you think you can keep all these balls in the air, it's hard to not conclude there are incredibly tight windows here. And the whole thing is very fragile. If you fail to identify, understand, and address a critical issue, it can quickly infect other team members.

[1] See, for example, https://knowledge.wharton.upenn.edu/article/is-your-team-too...

[2] I know. We often work more than that. The exact number doesn't really change the story, especially since we're talking about retaining our physical and mental health.

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()

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")

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.

I think your issue isn’t with universities and certainly isn’t with me. Reading between the lines, I think your complaint is with the systemic over-valuing of university degrees by parents and industry. That pushes people into universities that don’t want or need the education provided.

If that’s your issue, I completely agree with you. That’s why, in my comment, I actively encouraged people to do vocational training (boot camps) or teach themselves. If you want to learn to program, those are much better ways than to do a CS degree.

That doesn’t make CS worthless. It’s just different. The CS education provided by a university isn’t meant to train you to be a programmer. It’s broader than that. And it’s also, in some ways, deeper because it dives into CS topics that you won’t ever need for work.

I think that’s totally fine. The vocational and university systems have coexisted for a long time and serve different purposes. Pushing people into the university system that are better served by vocational training is an issue. But throwing away the university or pressing it to become purely vocational training is, I think, both unnecessary and deeply harmful to society.

This is a very strange article and premise to me. A university education is not vocational training. A CS education includes courses in programming, but learning to program—indeed, learning CS—is only a part of the education you are signing up for at university.

I arrived at university having already worked for a couple years in open source and a bit of contracting. I worked as a professional programmer throughout my undergraduate degree. I was bored by most of the introductory programming courses. The liberal arts, being around other young adults, the theoretical CS parts, the electrical engineering bits, and some of the project work were the only valuable parts, but that was plenty of value to me.

Going to university to learn to program is like going to university to learn refrigerator repair or how to play the guitar. Vocational and on-the-job training will go deeper into the craft. If you only want vocational training, go to a vocational school, get a private teacher, or teach yourself. Don’t go to university just to learn a skill. You certainly can, but it’s not an efficient way to do that. People study music in university to become better rounded musicians, not to learn an instrument. Same with CS.

I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response?

Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows they aren’t. NASA isn’t going to launch a vehicle that they know isn’t ready. Video games, hardware, and movies get delayed. Our software project can have features cut or the release date changed. And, for the most part, it’s okay.

That deadlines are “soft” in some sense doesn’t undercut any of the substantive points made against them, nor does it actually evidence any of the claims made for them.

You don’t need a deadline to establish priorities and ensure the team is focused on those priorities. Nor does a deadline actually prevent procrastination. We all have had homework due that we have rushed to finish because we were watching TV, playing games, out with friends, or whatever. So too with software engineering.

Anyway, if you are using sprints, there actually are due dates. It’s just there are a lot of them occurring in rapid succession, and we don’t commit to what we’ll finish in the following due date until after the impending one.

Hmm. That’s neat. But usually someone has a bank card or other membership card with a support line on it. Is there some reason to not just call one to report the found wallet?

The times I’ve found a wallet, I’ve called one of those support lines. The support person was able to contact their customer to give them my phone number. The customer called/texted me, and we arranged for them to pickup the wallet. This has worked every time to get the wallet back to its owner within a couple hours of my finding it with minimal inconvenience to me.

I don’t see what legal or technical argument you’re making.

Technically, of course you can identify IP ranges owned by certain entities and restrict their access. That’s trivial, so what do you mean when you say the internet doesn’t work like that?

Legally, there’s plenty of region locked content for copyright and censorship reasons. A distributor might region lock because they don’t have distribution rights in particular regions. Are you saying distributors can’t publish free content at all because they can’t choose who sees it but would be breaking copyright law to publish to everyone? Or a site might region lock because certain content is censored in particular countries. Can you not publish anti-regime articles because a totalitarian country is on the Internet?

The entire world isn’t and shouldn’t be held hostage to the most restrictive laws that exist in the world. And the answer isn’t blocking on the requesting end because that’s technically much harder and blocks much, much more content. So what am I missing?

Edit: Forgot to include the other end of the spectrum. If I, as an individual, host my own site on my own hardware with my own connection that I pay the bandwidth for, can I deny a suspected not network?

This is wrong. CUE has optional closed schemas marked by a double colon. The V3 entity you’re talking about is explicitly declared to be a closed definition and therefore disallows unknown fields in entities that claim to accord to the V3 type. Not all definitions are closed.

Even for those that you choose to close, it’s a matter of having different code for different definitions. The claim that it just automatically breaks isn’t true even when closed definitions are used.

BTW, this feature speaks to CUE’s intended purpose as a configuration language. It is (or at least can be) nice to ignore unknown fields in transmitted payloads for forwards and backwards compatibility. But if I’m trying to configure some software and misspell a field, I probably want the configuration file to fail validation, not have the software run with an unintended configuration.

Are property crime stats adjusted in any way for wealth, inequality, or cost of living?

The ability to apply the same argument to another situation has no probative value. Any policy has its pros and cons. One can support vacancy taxes/fines without supporting other taxes on unused possessions.

The “set” command lets you override the positional arguments but starting at $1. You cannot directly set $0. But you can set BASH_ARGV0, and the value of $0 changes accordingly.

Webex Teams includes what used to be called Cisco Spark. Spark is a Slack clone.

It’s funny. I know the front-facing camera followed demand and was at least partially meant for things like FaceTime and taking photos with friends. But it also fed back into and catalyzed the normalization and popularization of selfies and vanity.

Throughout most of my life, we would break out physical photo albums or an occasional VHS to reminisce. They’d be group photos, vacation pictures, captured moments from a birthday or wedding. I can’t imagine how we would react to a friend pulling out a photo album that contained the stuff many popular Instagram accounts post. They would seem psychotically narcissistic.

Yet, we aren’t that far removed in time from selfie sticks being a joke. And it feels like we are an eternity apart in how our attitudes have adjusted.

I agree it’s likely the office is bugged. But a pocket WiFi device the watch has previously connected to is a perfectly plausible way for him to have had Internet access.

There’s a strong argument against disclosure of internally discovered bugs (security or otherwise) that have no evidence of user impact. Internal efforts to find and fix bugs improve actual quality/safety but, if indiscriminately announced, harm perceived quality/safety. We have seen repeatedly how bad security reporting of actual weaknesses can drive users to more risky alternatives or behaviors, lowering actual security and privacy. It’s just too easy to say that all major security defects should be announced or that no major defects should ever exist.

There are about 430 developers that could have exploited this vulnerability. There was no evidence in the available two weeks of logs of it being exploited. And the number of users and types of data available make Google+ a low value target. The decision to not announce was reasonable, common, legal, and moral.

It sets a poor standard to suggest they should have acted different because they’re now under fire from people with far darker motives than reporting truth or advocating for consumer privacy. Those exploiting the story for their own gain should be shamed rather than capitulated to.

In my experience, it’s typical for senior leadership at a large company to have a carefully orchestrated departure. No internal announcement would be sent until after a press release is prepared. The set of people that know would be kept extremely small, even to the point of keeping direct reports in the dark.

If Facebook truly was unprepared, it’s reasonable to assume they weren’t expecting the announcement.