benwr

OP:

> Now, ask yourself what it's going to take for a car to know this. It's not going to be some specialized set of driving instructions. It's going to require a holistic view of, well, everything, and I will repeat my feeling that it will undoubtedly end up with a sense of self as a result.

Whatever it is that it would take, is demonstrably present in LLMs. The point I'm trying to make here is that the author seems not to have connected this fact to their assertion that current LLMs are coked up parrots.

And yeah the author is correct that the systems have some rudimentary sense of self! It's a confusing situation and I'm not personally thrilled about it! But things are changing quickly, and it's especially important to be paying attention to what's actually true rather than assuming the things are what you saw when you used one for five minutes in 2022.

> It's early in the year. You want to drive straight through the middle of Chinatown in SF. Why might that be a bad idea?

In case anyone is wondering: yes obviously even the dumbest current models correctly answer, given this prompt verbatim, that it's because of lunar new year.

Maybe IQAir? They do have paid plans, it looks like.

Sure, I'm not saying it's unreasonable.

The big selling point of `soanm` is that you don't need to have anything extra installed on a typical distribution (not even ssh!) and you don't need to know any extra configuration language, or how to use a special library, or anything beyond shell scripting. Of course, you also trade a lot of functionality away: The programs you write aren't declarative, and so on. But personally I don't care about that when provisioning a new dev machine. I'd much rather just run some quick scripts.

Interlingua is a similar project for primarily Romance languages: https://www.interlingua.com/interlingua-en/

Entropy of a single password isn't actually a well-defined concept; entropy is always about a distribution. "Entropy calculators" that look at your password and tell you "its entropy" are making assumptions about how you chose the password.

We care about the distribution from which you drew the password, because that lets us analyze how difficult it would be for an attacker who knew your password selection process to brute-force the password. Just knowing the password itself isn't enough information to determine that (though of course you can judge how hard it would be for an attacker once you know their brute forcing strategy).

More often for e.g. work computers.

I mostly agree, but I do find myself choosing a new FDE and login passphrases about once a year, and I wish that I could choose these using something like Diceware, but memorable enough that I wouldn't need to write them down at all. Thinking about how I might do that is what ultimately led to this post.

This is a fair question; I've been thinking about "weird" password choice strategies recently, for which it can matter. For example, if you want your password to be an English sentence, choosing sentences based on random parse trees will produce duplicated sentences with ambiguous parses.

I've done a fair bit of research into this, and as far as I can tell, the entire internet does this thing you've never seen. For example, https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a... implies the use of Shannon entropy.

I hadn't looked at yjs; I'll check it out! [edit: It looks to me like yjs is much more flexible than my design here, but doesn't include an ability to move ranges of lists to different locations]

Darn, and just after I'd implemented it myself in terrible beginner Rust! I might get started reimplementing it using your tool :)

If anyone is interested, I've been trying to think about the problem of moving ranges in a list-structured CRDT for a couple of weeks now for a side project, and I've got a candidate that seems to satisfy the most obvious constraints. I'd be really interested in any feedback / holes you can poke in my solution!

Rough notes are here:

https://docs.google.com/document/d/1p1K3sxgKGYMEBH72r-lnP9Gn...

Sure - I still think the title is misleading. "Was always a scam" implies that everyone in the sharing economy has been lying for decades in order to make money. I don't see any evidence presented in the article that supports that implication.

And when looking at it through a reasonable lens as you do in your comment, I also don't understand the urge to treat it as though "sharing economy" companies are somehow evil or deceptive. They're just responding to market conditions in a way that (at least in the short term) produces value for both drivers and riders. There are other arguments you can make about whether this is bad in the long term due to e.g. dynamics around regulation, but that's an argument about how things will play out in the future, not about past or current bad faith on the part of Uber or AirBnb.

The title seems totally unsupported by the article to me. A less misleading one might be "The 'sharing economy' has evolved into a collection of large, unregulated, rental businesses"

This is a critical response to https://news.ycombinator.com/item?id=18609375 ; in the comments is a response by Jamie Farnes, the author of the paper, and a rebuttal by the blog's author.

This tutorial starts by explaining how things work, and only later shows you magic. That's exactly what I like about it, actually. Almost every coq tutorial I found (I tried software foundations, cpdt, and several shorter online tutorials) fails to explain what you're doing before you do it.

This problem went away for me when I turned off my ad blocker.

Strongly agree. I only found Lean after a couple of weeks of struggling to pick up coq. In my opinion, this tutorial alone makes lean a better choice for beginners.

Specific critiques about how you can improve your blog post:

1. Data is always necessary to back up claims like these. Almost _any_ kind of quantitative data will do - just a simple average! just give me something I can replicate on other data sets. Similarly, just saying "we made up these variables as a combination of these other variables and called them Flavorfulness and Musicality, look how nicely our circles line up!" is not useful to anyone - a formula or methodology would be.

2. As a software engineer, I came to this post expecting to find a way to improve myself. I invested time in reading it because I expected a payoff in the form of, for example, a metric I could apply to my own work. I suspect that the author of this post intentionally gave the impression that the post contained tools like this. I didn't find anything remotely like that.

3. More generally, this post does not show signs of being written with the reader in mind. You have not given me any new information that I can apply; instead you have given me a marketing pitch (we did this data analysis, we promise! Don't you want us to work with you?) dressed up like information.