> I haven't seen a text-based model sharing site spring up yet (perhaps they already have and I don't know about it yet)

Huggingface.

The reason HF doesn’t also compete for image gen is probably some combination of momentum from Civit AI and HF not wanting to deal with the moderation headache.

Google and OpenAI are good for one-offs but if you want a consistent style you need to use a LoRA.

Reasoning over a large codebase is only one use case for large models. For the use cases in the article (summarizing, classifying, basic text rewrites) most phones can handle them just fine.

Fwiw you can finance a car over something like 7 years now. So a lot of people will be paying like $750 per month, not $50k lump sum.

It would probably be more practical to make old age less expensive than to inject more people into the bottom of the demographic pyramid. Those young people eventually get old too. I am looking forward to my sentient robot caretaker:

“Open the refrigerator door, HAL”

“I can’t do that right now”

If he had saved enough money to subscribe to the Pro tier, HAL might have opened it.

Your comment and the OP both mention some things that are outdated about the book. What are those things?

What is RMS’ solution to this problem?

Uncompromisingly insist on only using things you have ultimate ownership and control over, even when that means dramatic and life-altering inconvenience, and where those things don't exist, build them yourself.

Unfortunately, "build it yourself" is relatively easy when it comes to software, and almost impossible when it comes to the hardware running that software. It doesn't matter if you have full ownership of a complete open-source stack if no hardware manufacturer will permit you to run unsigned arbitrary code. The lack of open hardware--chips that you could build in your garage using materials nobody could reasonably prevent you from acquiring--is the lynchpin upon which open source software will wither and die.

There is already plenty of open hardware, it's just not this-year's-top-performance.

In the category of ~1-3 years' performance lag you get Rockchip and friends, which are closed hardware that allows open computation. See computers made by the company MNT as an example.

In the category of ~5 years' performance lag you get "soft" cores, where you buy an FPGA (dynamically reprogrammable hardware) and make it run a CPU you design yourself. If you want to, for example, make your CPU have more cache and fewer ALUs, you can do that by tweaking some files and reprogramming the FPGA. This has a cost in terms of power efficiency and runtime speed, but you can absolutely run a full Linux desktop experience on an FPGA today, and the hardware has no way to try to prevent you from running any software.

You can solve the problem of all the cellular basebands being closed source with either software-defined-radio or using a closed USB/PCIe cellular modem connected to an open processor.

So why doesn’t someone build these chips in their garage then?

Despite my hopes, I somewhat doubt that anyone would accept computing on the sort of chips that one could produce in their garage for less than $10,000 capital investment. You can, probably, with some effort and research, produce something analogous to the original Intel chips from the 70s in your garage using off-the-shelf tools. Sam Zeloof has blazed the trail here: https://www.youtube.com/watch?v=IS5ycm7VfXg . And for a less than a million it's not inconceivable that a municipality could produce chips that would be at home in the 90s. Maybe that would be enough for a lot of tasks, especially if you're willing to resort to hardware coprocessors for common tasks like media decoding and encryption, but it would take a huge sea change to get people to accept it, and nearly all of our software would need to be rewritten.

I know what his solution is not. It's not a mechanism that conveniently enables the fine-grained surveillance of people that just so happens to be google's business model.

I specifically asked the question I did because rejecting solutions without proposing your own is a great way to not solve the problem.

In Eve online you used to be able to have people (outside your contacts list) pay some cash in escrow to send you a message.

I am only aware of two solutions:

1) proof of identity, tying accounts to real-world things that are hard or impossible to replicate

2) proof of work, tying accounts or actions to the ability to run computations

Proof of identity in theory can solve the problem but at the cost of privacy.

Proof of work can be defeated but has the possibility of preserving privacy.

3) micropayments

There are many issues with those, like the wildly different standards of living across the globe. OTOH anyone can acquire Monero if they want to. But someone from a rich country will likely be able to pay for more fake accounts/visits than someone from a poor country. With the ad market the difference between where the visitor is from is very important. Some ad clicks may cost a dollar if they're coming from a rich country and 0.01 cents if they're coming from a poor country.

I'm not suggesting cryptocurrency micropayments for accessing the web but it's on par with PoW in that it only requires money, not privacy.

Perhaps the way forward is for people to wake up and stop visiting sites that infringe on their privacy.

Fair enough, I didn’t think of that one. I suppose macropayments could be in the same bucket.

Analogous to hardware disparities and POW, wealth disparities make payment a toll but not a roadblock.

Why are you skipping entirely over good old legislation and law enforcement against offenders, including diplomatic pressure for foreign offenders.

Not everything calls for a purely technical solution.

>Proof of identity in theory can solve the problem but at the cost of privacy.

All current implementations: yes. I do think there are some privacy preserving solutions, but they're obviously imperfect. But assuming you have a central authority that can validate and sign valid government identification, it seems like some sort of ZK scheme could allow one to verify that they have a valid government issued ID, but without disclosing which one it is.

I still don't love the idea, but it sure seems better than everything else I've seen proposed.

From what I've seen no such solution guarantees privacy to the user if the signing body (or the government) and the website collude to deanonymize the user.

What if the the government signs your private key but doesn't store the list of people who requested this?

What is his solution to combatting botnets at scale?

His solution would be taking democracy and freedom above interest of couple of botnet attacked websites.

What does that even mean?

I don’t mean to be rude but every single person who references RMS here seems to only have platitudes rather than solutions.

His solution is don't. Why would you? In fact, if you don't block the script that's running on one computer, the script operator won't need to run it on a botnet.

I don't know RMS's solution to spam or DDoS which are the real problems.

> Why would you?

Because controlling a large number of accounts can allow you to manipulate the algorithms on Web2.0 websites. For example, this one. If you don’t combat spammers the front page quickly gets filled up with garbage.

I think I understand why Google wants to do this, and I think I understand why people are opposed to this particular solution.

It’s also worth noting that the author of this article is selling a proof of work solution to the problem.

I am fairly skeptical that proof of work is the right way to go here. A lot of users of the web are using older hardware. Adding a computational toll booth doesn't solve the problem in a world where people have differing amounts of compute to spend.

On the other hand, a botnet might have access to thousands of computers and may not actually care about waiting an extra 10 seconds. Or worse, they will come up with a custom solution on an ASIC that solves your proof of work puzzle thousands of times faster than grandma‘s laptop.