jimrandomh

No, the allegations in that article are not accurate; I remember discussion of it at the time. The story there is that Nya Dagbladat applied for a grant from FLI, passed the first phase of the grant-award process, and was rejected during due diligence. Then after the rejection had already happened, espo.se ran the article you linked to, which made it sound like they had funded or were going to fund them, which they weren't.

This is what happens when government officials are too severely ignorant of economics, and try to make things cheaper by decreeing prices. They decree a price for something that is below what it costs to provide, and all the sellers stop selling.

> "Most people don’t want to live in Manhattan or similarly dense settings. I’m not sure why the state or voters felt it would be okay to take away local choice or why they thought it would be easy."

If that were true, apartment prices in Manhattan and similarly dense places would be a lot cheaper. The fact that people are willing to pay a premium to live somewhere is a direct expression of the fact that they prefer to live there.

The main reason local jurisdictions resist construction is because landowners (not to be confused with developers) benefit from doing so. The artificial shortage of housing drives up the price of their property.

The project tells people to put a line in their zshrc which fetches and runs a script. To spell out why that's worse than a normal auto-updater would be: it enables the server operators to distinguish users who have installed it in a way where they can serve malware, from users who are downloading it once for inspection purposes. For example, they could serve malware only to IP addresses that have fetched the script every day for a month. Random curious developers and security researchers are very unlikely to do that, but someone who actually put this line in their zshrc would.

This would also explain why it's pointed at the developer's server, rather than a GitHub URL: if it were a GitHub URL, it would be impossible to do malicious substitutions like this.

The reason you can't get heart rate data from Oura is that they don't want people looking at it except in aggregate, because then they would notice the accuracy problems and data gaps.

That's a small observational study from 1993, with p>.05 outside of the subgroup analysis. Whatever search strategy led you to it is severely flawed.

Typical usage of blood glucose monitoring (by diabetics) is simultaneously safety critical, and only borderline good enough accuracy. There's a standard metric for accuracy here, MARD (mean absolute relative difference).

There is a long history of companies promoting themselves to investors as having working noninvasive glucose monitoring technology, which, if you look at the actual accuracy scores, is only moderately correlated with glucose, nowhere close to the accuracy required. If Apple ships a noninvasive glucose monitor with an MARD of 20, the primary effect will be to set a trap for the stupid: diabetics will attempt to use it to save money, since it will be much cheaper than using real CGMs (which are consumable), and people who try to do this will die.

"Inefficiency" is a dishonest euphemism. This is the result of corruption. The former SF public works director is in prison (https://www.justice.gov/usao-ndca/pr/former-san-francisco-pu...), but SF city government is structured in a way that there are many agencies that each get a chance to create a delay if not bribed. From the article:

> Under city law, for example, installing the Noe Valley toilet — even the free one — requires that the Recreation and Parks Department coordinate with or seek approval from San Francisco Public Works, the Planning Department, the Department of Building Inspection, the Arts Commission, the Public Utilities Commission, the Mayor’s Office on Disability, and Pacific Gas and Electric.

Bribes are expensive. The structures created these organizations created in order to make it possible for them to extract bribes are also expensive, even to those who do not pay.

No. High-mileage drivers have a reason to prefer electric vehicles, since they're cheaper to operate per-mile than gasoline vehicles.

It sounds like calling it a "strike" is kind of misleading, because the workers who are "striking" aren't Tesla employees, they're employers for _other organizations_ who are refusing to do their jobs (for those other organizations) in order to sabotage Tesla. I don't think there's a plausible claim, here, that these unions are acting in the best interests of Tesla's workers; rather, they're working to maximize the power of _the unions themselves_.

This headline is intended to deceive people who don't know how much energy smartphone batteries store. They avoid using standard units (kWh) because if they used standard units, the number would look small, and they want to make it look big.

They haven't yet demonstrated that they can accurately steer it during reentry, nor that they can maintain communication with it in order to activate the FTS if they need to. So they're aiming it at a big empty patch of ocean, since aiming it at land would run the risk of missing the landing target by a significant distance and going somewhere populated.

Starship is funded by NASA and built by a for-profit corporation, like SLS is and like the Space Shuttle was. The difference between SpaceX and the contractors that built the Shuttle and SLS is that those contractors kept their CEOs' names out of the news, and gouged like crazy.

When it comes to distance from an exploding rocket, inverse-square works in your favor. It's relatively straightforward to calculate an upper bound on how big the blast can be based on the amount of energy in the fuel.

(I believe the closest you can get without going into the exclusion zone is about five miles.)

Getting too close is dangerous, but they won't let you get close enough to be in danger; the safety perimeter on these things is set quite conservatively. Exploding on the launch pad is very expected and planned for.

Given that Twitter is the target of a lot of manipulation attempts, some of which come from intelligence agencies, having a .onion service seems like an actively bad thing. This seems like the sort of thing that a spy who snuck through the hiring process would build. Leaving it unmaintained seems worse than taking it down (especially since that implies a lack of monitoring that would invite abuse), but it definitely ought to go down.

> "Three ex-SpaceX supervisors told the publication Musk would have yellow machinery repainted to black or blue and some workers were told not to wear bright-yellow safety vests when the billionaire was on-site."

This would be pretty bizarre if true. There's a cottage industry of people taking pictures of SpaceX's Boca Chica facility for YouTube, so I skimmed one by RGV Aerial Photography which has lots of shots of their construction equipment. It was mostly yellow. This isn't a perfect test, I suppose there could have been some specific thing that he wanted repainted? But, I think this is probably BS.

Don't forget, every time a bribe changes hands, there are _two_ criminals: the one who paid the bribe, and the one who received it. SF city bureaucracy is notorious for using flimsy pretexts to destroy projects, which is exactly what you would expect to see if they've designed a system to extract bribes, and are making examples of people who fail to pay.

I'm also in the "still using Yarn 1.x" camp. The problem is that yarn is installed to the global path by a package manager from outside the Javascript ecosystem, which means that the same install of yarn is shared between all the projects I might run on my system, including projects I don't maintain myself and including projects that aren't maintained at all. I'm open to other JS package managers if they offer benefits, but the one that runs when I type "yarn" in my shell has to be backwards-compatible with 1.x, forever. Repositories like Debian/apt-get and homebrew operate on a similar philosophy, and still offer only 1.x.

So... why didn't they just put a package-manager version number in package.json? I would have no problem with projects requiring Yarn 2+, if upgrading to Yarn 2+ didn't create an obstacle to continuing to run everything else that still uses Yarn 1. As it is now, I'm not willing to even _try_ the newer versions, because I expect to have to revert and I'm worried that I'll lose a day to the mess that the uninstall/revert will create.

This is an interesting source of evidence, but I think the analysis might be wrong because it only accounts for the direction of lateral motion, and doesn't account for the fact that the main direction of travel around the moment of impact isn't northeast or west, it's _down_. The speed would also not have been constant.

I believe you would get the same effect even if it was traveling straight down: rising pitch from acceleration due to gravity, then falling pitch as the angle to the camera goes from zero to 90 degrees.

This is interesting as a gimmick, but it seems wildly impractical compared to charging a power bank from an A/C outlet in a public place. I expect most homeless people would rather have a power bank that's larger or cheaper than one that can charge from bike pedal power.

(I also submitted this as an Express Comment in the proceeding. If you agree, consider also filing a comment.)

A lot of issues around IoT device security are hard, but there is one simple and easy piece of policy that would be a big win:

Make the requirements stricter if the product contains a microphone than if it doesn't.

Some device makers are putting microphones into devices that don't need them, to support functionality that isn't useful, just because microphones are cheap. For example, TCL (a Chinese television brand) puts microphones into its remote controls. They do this because while most people don't want to control devices by voice, a few people do, and microphones are very cheap. This is a problem because anything with a microphone in it is a valuable target for hackers; compromising a TV remote with a microphone is _useful_ to them, in ways the compromising eg a wifi-connected clothes dryer would not be. If adding a microphone to a device created additional legal requirements, vendors would stop putting them in places where they lack a legitimate purpose, and there would be fewer insecure microphones floating around.

Previous discussion on LessWrong: https://www.lesswrong.com/posts/DgzdLzDGsqoRXhCK7/transforma... and EA Forum: https://forum.effectivealtruism.org/posts/ARkbWch5RMsj6xP5p/...

Both previous discussions contain multiple independent refutations of the core claim (the argument stacks quite a few errors on top of each other).

It matters whether the CCDH's accusation was true or false.

US free speech law, in practice, does usually protect liars. That's generally a good thing, because there's a lot of grey area. But I think it's terrible if we, as outside observers, get caught up focusing on the legal wranglings and who we like and dislike, before seriously asking the question of what's true.

I don't have access to much in the way of data about Twitter. My own feed is healthy, but it's mostly composed of people I know who I've chosen carefully, so people who follow more indiscriminately might have a different experience. But I did check out the CCDH's recent blog posts, randomly clicked on one about LLMs, and it seemed pretty dishonest to me (they prompted it with jailbreaking prompts, then in the summary made it sound like it would say offensive things without jailbreaking.)

Browser plugins that access your email are a very-high-risk category for malware, so much so that if I see an ad for one I wouldn't personally give it the benefit of the doubt. Combine that with A/B testing for different product ideas, and the clickthrough experience not actually ending in a plugin which can be malware-scanned, and rejecting it under the "circumventing systems policy" seems correct to me. The reviewer can't distinguish between "the plugin was not served because this is a fake test for a product that doesn't exist", and "the plugin was not served because the malware doesn't want to send a sample of itself to the reviewer".

> The quotes and other horror-scenario errata also come off a little thin. If Hinton really, genuinely believes the world is ending, then why is he working on the generational successor to backpropagation [1]?

That paper was published 27 Dec 2022. He quit Google in order to warn people about AI on May 1 2023. He realized advancing AI will lead to the world ending and so he _stopped_.

So, downtown SF has a lot of vacant commercial and office real estate. They'd like people to convert some of those vacant storefronts into businesses. Ok, now consider it from the perspective of a would-be businessperson considering set up shop in one of those storefronts. What will happen?

I think most would-be store openers will think of the famous ice cream shop: https://www.sfchronicle.com/local/heatherknight/article/s-f-... . The city bureaucracy of San Francisco has a reputation, and the reputation is that they will destroy you, Vogon-style. The same goes for building housing, or converting commercial space to housing, or doing anything else that involves the permitting process.

Legislation to reform the processes is nice, but I don't think SF can even credibly commit to follow the laws it passes, where bureaucratic obstruction is concerned. Solving the problem would require either much more drastic reform, or loudly announcing that staff in the relevant institutions have been 100% replaced.

There is a difference between disagreeing with predictions about the future, and accusing the people making those predictions of lying about their own beliefs. This article does the latter.

And, ngl, it's been pretty wild watching the AI risk-skeptical narrative pivot from claiming that AI risk is a fringe issue which no experts think is plausible, to claiming that a large fraction of the relevant experts are lying about their beliefs.

No, they're not lying. The people who signed the letter did so because they believe what it says.

> buying bankrupt crypto podcasters

I haven't heard of anything like that happening; what is this referring to? Are you claiming that a podcast was secretly sponsored rather than natural?

The established norm is that scrapers have to download robots.txt and support the standard robots.txt features, notably including `Crawl-Delay` which sets a rate limit. This is the established standard by which websites tell scrapers what the rules are for scraping them.

This tool is scraping sites, it has webmasters reporting actual disruption, it doesn't have robots.txt support. When people complained (eg in https://github.com/rom1504/img2dataset/issues/48), the author's stance was basically "PRs welcome". It looks like a third party recently contributed a PR to make it respect robots.txt (https://github.com/rom1504/img2dataset/pull/302), albeit without `Crawl-Delay` support, which is not merged yet.

I have seen the same thing with other recent AI tools (eg https://github.com/m1guelpf/browser-agent/issues/2) and I think it's important to defend the robots.txt convention and nip this in the bud. If a bot doesn't make a reasonable effort to respect robots.txt and it causes disruption, it's a denial-of-service attack and should be treated as such. No excuses.