jljljl

Sure, but you have to reinvest that money too. And it's a bit misleading to take just the FastThing cost and disregard the GoodThing costs.

For example -- it took 10 days to build a JS prototype, but 10 more years of evolution before it became the dominant Web Development language.

A lot of red-tape and delays in modern projects is contending with debt from "Fast" projects

For the Van Ness Bus Line example: one reason there were major delays was because maps of underground sewer lines and plumbing were inaccurate, and needed to be relocated. The 6 years of construction was really a bus lane + major sewer infrastructure project.

Which brings up another reason why some of these projects were Fast -- they operated in places where there there wasn't existing infrastructure or residents to deal with, or cut corners on planning and mapping, which future projects now have to deal with.

https://sfstandard.com/transportation/van-ness-brt-bus-rapid...

  Immediately after breaking ground, construction delays began. Existing maps of old gas, water and sewer lines flowing beneath the center of Van Ness Avenue proved inaccurate, slowing excavation and causing the city to bring in utility contractors. The utility placement also made the BRT’s center-lane design a challenge: Any future sewer and water repairs would disable bussing for the duration of repair. Plus, overhead bus electrical wires would need to be fully removed for the safety of the crews. Water and sewer infrastructure needed to be moved to the outside lanes to keep the center-lane BRT design — deemed the best for traffic flow.

That sounds like a huge speculation/hypothetical — is there evidence that was or is happening?

To answer your question, it would depend on what the account was doing. Scraping abuse could likely be handled in a more targeted manner.

The first source (which you're citing for the volume number) warns against making this sort of volume estimate and inferring differences between men and women hunting, in part because of the small sample size of women hunters and because women tended to hunt in pooled/group settings.

The pooled/group setting difference is something that the original paper also calls out.

The paper actually makes no claim about the percentage of time that women hunt relative to men.

So I’m not sure where you got the data for your last sentence

The paper doesn’t make a statement about the frequency or prevalence of women hunting, and it does describe different hunting behaviors and patterns between men and women in the discussion.

I think the paper’s goal is not to say women hunted as frequently as men, but to disprove the idea that there was a sharp and rigid division of labor in subsistence societies.

Twitter reported in their financial statements that less than 5% of their monetizable daily active users were spam or fake accounts. They did disclose some errors in methodology in 2022, but not enough to make a substantial difference to that estimate. They shared their methodology for estimating with Musk’s acquisition team and with the SEC.

One can claim that Twitter was lying about this number. But if he could prove they were lying, Musk would have gotten out of the deal.

Instagram requires a login to view most posts, but it doesn’t rate limit it’s most active users.

Pre-Elon the bot count was something like 5% of active users, meaning a broad approach like this will affect significantly more real users than bots. There are probably more fine tuned ways to reduce bots that don’t degrade the experience for your biggest users.

The problem is this will reduce impressions by unique users as well. Once a user hits the daily tweet limit (easy to do if you scroll and view a few viral threads), they can't view any more ads for the day. A few viral or high engagement threads could significantly reduce your audience for 24 hours.

Additionally, if Twitter CTR is low, then you need a _lot_ of unique users to actually generate conversions. Low CTR + Low impressions reduces the value of the ad.

Yeah, this basically restricts users to viewing a handful of popular threads per day.

A few thoughts:

1. I'm not sure that an account that heavily browses twitter is zero value to advertisers. If anything, those are more engaged users with Twitter, _and_ Twitter should have more data and thus better targeting for that user.

2. The marginal efficiency of not showing an ad to a saturated user is probably offset by the reduced potential audience for your ad. Once you've seen 600 tweets, you can't use Twitter or view any more ads. That can shrink the daily audience significantly.

3. Users now need an account to view _any_ tweets. This further reduces the reach/audience for Twitter ads. If Twitter ads already have low CTR or referrals, and now their potential reach is cut, then they have no value.

I have blocked ads most places, but I use Twitter in ad-supported mode + receive ads through the app. I'm a good example of a user they'd be advertising to, and now I can't use it.

Twitter managed to withstand high load and scrapers before. Did this suddenly get significantly worse? Is it bad enough that caching or engineering solutions couldn't address the problem?

One reason it _could_ get worse is because Twitter effectively disabled and paywalled their API, which many of these groups could use instead of scraping

This seems like death for an ad supported model on Twitter. Why would you buy ads on a social network that deliberately restricts the number of posts (and thus ads) that a user can view?

This seems like death for an ad supported model on Twitter. Why would you buy ads on a social network that deliberately restricts the number of posts (and thus ads) that a user can view?

If you like the properties of Nix, but find it confusing, you should check out Devbox! It simplifies the process of creating Nix-powered dev environments:

https://github.com/jetpack-io/devbox

So overhead for a single app might be comparable, but each subsequent Electron app that I replace with a Safari Web App would use significantly less CPU/RAM

Does using Slack as a Safari Web App reduce resource consumption vs the Electron app? This seems like a huge deal if so

I don't think the answer is to have every version at the nixpkg head, for exactly the reasons you mentioned.

But I do think there's a search issue where mapping the version field of a package to the commit hash or nixpkgs version is not trivial or user-friendly, especially for multiple packages.

I do think Flakes help with the "throwing away old versions" issue. They also help with the monorepo issue by encouraging developers publish the Nix derivation in their own repo.

But they currently have a bit of a discoverability issue, and they need adoption by legacy packages to completely fix the problem.

I thought this too, but we got a lot of requests for better version search + pinning. Adding overrides and looking up the right commit hash is a pretty cumbersome for a first time user.

For new projects though, I agree that using `latest` is generally the way to go.

Versioning is a bit easier with Flakes because they're generally published in their own Git repository, meaning you can use tags or branch refs to publish/install specific versions of a package. You can usually do something like `github:org/repo/ref#package` to get what you need.

Finding a specific version of a package is also really difficult. It requires you to find the commit hash in the Nixpkgs repo that last contained it, and there isn't a central search engine that lets you map version to commit.

We ended up building package version search into the Devbox CLI for this reason (https://www.jetpack.io/devbox/docs/guides/pinning_packages/#...). There's also a 3rd party site that lets you search for Nix package versions (https://lazamar.co.uk/nix-versions/)

Not if it helps them find and remove the AirTag. It might have a deterring effect if the Airtag was somewhere hard to remove

The thing that always fascinated me about LCARS and Star Trek interfaces was the labelling -- rather than a label that tells you what a button does, or whats being visualized on screen, you'll get a random-seeming number or an unlabeled chart.

Most of Starfleet Engineer training must be memorizing what those number labels mean...

Nix is a great option for reproducible dev environments. However, the Nix language is pretty complex, which can make adoption and buy in tough.

One solution that my company is working on is Devbox, which tries to provide the usability of tools like Yarn or Brew with the reproducibility of Nix.

You can check us out at https://github.com/jetpack-io/devbox

You might be interested in Devbox (http://jetpack.io/devbox)! We built Devbox because we were frustrated with our Docker based dev environments, and our goal is to provide the power of Nix with a more accessible interface (similar to yarn or other package managers).

We're open source and rapidly adding features, you can check us out on Github at https://github.com/jetpack-io/devbox

If you're looking for an alternative for creating dev environments, you should check out Devbox [https://jetpack.io/devbox]. Our goal is to combine the usability of tools like Brew or Yarn with the reproducibility and reliability of Nix.

The "assuming it could be done" in my comment referred to "finding a way to force latent cells to release their viral load rather than remaining latent". I'm not an immunologist, but if there was a mechanism, it would probably kill the rewritten cells. Then the released viruses would be eliminated with anti-retrovirals.

If this same mechanism kept infected cells from remaining latent, eventually you would clear the virus.

So I don't know the answer to your question, but my answer was assuming an answer existed :)