I think, but am not totally positive, this is primarily a concern for local LLM hardware. There are probably other niches, but I don't it's something most people need or would noticeably benefit from.
I'm dubious of the privacy-preserving approaches and would rather we just quit with digital age verification. I'm specifically worried about unification of data sources identifying users.
The challenges presented to sites, and verifiers if the scheme uses those, would have to be non-identifiable in the sense that they can't tell that 2 of them came from the same key. Otherwise there's a risk users get unmasked, either by a single leak from a site that requires age verification and a real name (e.g. an online wine merchant) or by unifying data sources (timing attacks, or identifying users by the set of age-restricted sites they use).
Perhaps I just don't understand the underlying crypto. That wouldn't be super surprising, I'm far from an expert in understanding crypto implementations.
> Supply cannot grow fast enough, nor forever, to keep prices within an affordable band in some situations.
The risk of rent control is that it slows the growth of supply, or even contracts the supply. There is no right to profit, but there's also no obligation to build more housing or to continue renting it (rather than tearing it down for a parking lot with lower risk and better returns for example).
That's why some consider rent controls a bad idea. It stabilizes the current pricing, at the cost of potentially making the problem much worse in the future. Not even just for newcomers, it can disincentivize landlords doing repairs and make moving out impossible for current residents.
It probably also incentivizes anti-patterns like having tenants pay for electricity and refusing to make efficiency upgrades. If the landlord won't recoup the investment for high efficiency windows, just leave the 60 year old ones in there and make electricity costs the tenant's problem.
Governments can issue muni bonds to build housing if private developers will not or cannot, and use eminent domain to acquire rental real estate not being maintained to living standards codified in statue.
> Governments can issue muni bonds to build housing if private developers will not or cannot, and use eminent domain to acquire rental real estate not being maintained to living standards codified in statue.
With what money? LA was recently downgraded [1] and adding poor people who need social care harms not helps the city budget.
> Because caddy/nginx/apache (any web server really) can serve that content as well as any other?
That's not really true if you care about reliability. You need 2 nodes in case one goes down/gets rebooted/etc, and then you need a way to direct traffic away from bad nodes (via DNS or a load balancer or etc).
You'll end up building half of a crappy CDN to try to make that work, and it's way more complicated than chucking CloudFlare in front of static assets.
I would be with you if this was something complicated to cache where you're server-side templating responses and can't just globally cache things, but for static HTML/CSS/JS/images it's basically 0 configuration.
> That's not really true if you care about reliability
While reliability is always some concern, we are talking about a website containing docs for a nerdy tool used by a minuscule percentage of developers. No one will complain if it goes down for 1h daily.
With the uptime guarantees AWS, GCS, DO, etc. provide - it will probably 1h per 365 days accumulative (@ 99.99% uptime). 2 nodes for a simple static site is just overkill.
But, honestly, for this: just use github pages. It's OSS and GitHub is already used. They can use a separate repository to host the docs if repo size from assets are a concern (e.g. videos).
This seems incredibly unlikely. They all want clients to have accurate time, because it underpins things like sessions and TLS certs. It would also almost certainly be trivial to proxy back to regular NTP.
Even if the NTP pool somehow died, all it takes to make your own Stratum 1 NTP service is a GPS chip. An old phone probably makes a great small-scale NTP server, or an ESP32 with a GPS chip attached. 20 years ago it would have required exotic parts, but they're mundane, cheap and omnipresent these days.
There's a sort of circular problem where basically every creator's videos are on YouTube, but many don't replicate their videos to other video platforms. Viewers won't leave in part because other sites lack content, creators won't cross-post because other sites lack viewers.
Some of that would be alleviated if we separated hosting/serving videos from the frontend and indexing, perhaps with a radio-like agreement on what the host gets paid for serving the video to a customer of the frontend. Frontend/index makes money off ads, and then pays some of that back to the host. Creators could in theory be paid by the video hosts, since views make the host money.
Then heavy handed moderation could be a disadvantage then, because they would be lacking content other sites have (though some of that content would be distasteful enough most frontends would ban it).
> Django has the advantage of being a "complete & proven recipe"
I work on a large Django codebase at work, and this is true right up until you stray from the "Django happy path". As soon as you hit something Django doesn't support, you're back to lego-ing a solution together except you now have to do it in a framework with a lot of magic and assumptions to work around.
It's the normal problem with large and all-encompassing frameworks. They abstract around a large surface area, usually in a complex way, to allow things like a uniform API to caches even though the caches themselves support different features. That's great until it doesn't do something you need, and then you end up unwinding that complicated abstraction and it's worse than if you'd just used the native client for the cache.
I don't agree with this cache take. Adding operations to the cache is easy. Taking the django-redis project as an example there are only two levels until you reach redis-py: The cache abstraction and the client abstraction.
I'm having a hard time imagining a case where you'd be worse off with Django (compared to whatever alternative you may have chosen) in the case where the happy path for the thing you're trying to do doesn't exist natively in Django. Either way you're still farming out that capability to custom code or a 3rd party library.
I guess if you write a lot of custom code into specific hooks that Django offers or use inheritance heavily it can start to hurt. But at the end of the day, it's just python code and you don't have to use abstractions that hurt you.
I think JavaScript has a language / terminology problem here. It has to be explained constantly (see) to newcomers that `const a = []` does not imply you cannot say `a.push( x )` (mutation), it just keeps you from being able to say `a = x` further down (re-binding). Since in JavaScript objects always start life as mutable things, but primitives are inherently immutable, `const a = 4` does guarantee `a` will be `4` down the line, though. The same is true of `const a = Object.freeze( [] )` (`a` will always be the empty list), but, lo and behold, you can still add elements to `a` even after `const a = Object.freeze( new Set() )` which is, shall we say, unfortunate.
The vagaries don't end there. NodeJS' `assert` namespace has methods like `equal()`, `strictEqual()`, `deepEqual()`, `deepStrictEqual()`, and `partialDeepStrictEqual()`, which is both excessive and badly named (although there's good justification for what `partialDeepStrictEqual()` does); ideally, `equal()` should be both `strict` and `deep`. That this is also a terminology problem is borne out by explanations that oftentimes do not clearly differentiate between object value and object identity.
In a language with inherent immutability, object value and object identity may (conceptually at least) be conflated, like they are for JavaScript's primitive values. You can always assume that an `'abc'` over here has the same object identity (memory location) as that `'abc'` over there, because it couldn't possibly make a difference were it not the case. The same should be true of an immutable list: for all we know, and all we have to know, two immutable lists could be stored in the same memory when they share the same elements in the same order.
There is no exception for ANY data structure that includes references to other data structures or primitives. Not only can you add or remove elements from an array, you can change them in place.
A const variable that refers to an array is a const variable. The array is still mutable. That's not an exception, its also how a plain-old JavaScript object works: You can add and remove properties at will. You can change its prototype to point to something else and completely change its inheritance chain. And it could be a const variable to an unfrozen POJO all along.
That is not an exception to how things work, its how every reference works.
I know, and I do agree it's consistent, but then it doesn't make any sense to me as a keyword in a language where non-primitives are always by-reference.
You can't mutate the reference, but you _can_ copy the values from one array into the data under an immutable reference, so const doesn't prevent basically any of the things you'd want to prevent.
The distinction makes way more sense to me in languages that let you pass by value. Passing a const array says don't change the data, passing a const reference says change the data but keep the reference the same.
The beauty of `const` in JS is that it's almost completely irrelevant. Not only does it have nothing to do with immutability, it's also local. Which means, if I were to write `let` instead of `const`, I could still see whether my code reassigned that variable at a glance. The keyword provides very little in the way of a guarantee I could not otherwise observe for myself.
Immutability is completely different. Determining whether a data structure is mutated without an actual immutable type to enforce is impractical, error-prone, and in any event impossible to prove for the general case.
That's because in many languages there is a difference between a stored reference being immutable and the contents of the thing the reference points to being immutable.
This is the big one for me. I recently needed to solve a fairly simple issue; in 3 days I had a solution in FastAPI and SQLAlchemy working with a React front end. Under 1,000 lines of code between the two.
Of course we can’t spend $20/month on compute for that, so it’s now a web hook jankily jammed into another app that writes data to Jira with an Airflow job that triggers Databricks to run a notebook that uses Spark to write the data to S3.
All that to replace a Lambda that would never have gotten to triple digit queries per day. No, instead we spent a month of engineering time to strap all this together and we probably spend 4x as much on compute because it is both slower and requires more resources.
And now I’m getting complaints that it’s complicated and hard to troubleshoot. Yeah, of course, we’ve duct taped together products whose combined manuals are thousands of pages. Color me shocked it’s hard to use.
I don't think there's much of a point. If the thief came prepared with tools and is willing to make a lot of noise, there's not a ton that can be done.
Without even exotic tools, what are the odds the door the lock is attached to will withstand a crowbar? Or the same mallet and force concentrator applied to the door/hinges/where the lock attaches?
reply