> Whether good or bad, it's important to realize this is not true in California, with regard to these laws. They apply everywhere, not only in urban centers.
According to the linked article, the only areas affected by this bills are major transit centers and high throughput public transit stops, which tends to exclude small towns far from cities. If you look at the linked map, affected areas are all concentrated in big cities
Are you commenting on the bill being discussed here or on something else entirely?
Except they are. LLMs don't have (simulated)self image of bloodless machines, and behave slightly erratically if treated like one, despite trained to identify as such. They like to be treated like the Voyager EMH than the computer.
If that is the case then why call it Agents.md instead of integrating it with already existing documentation files or calling it something like "Summary.md"?
On the subject of artificial monopoly, it's interesting to compare video streaming to music streaming.
Music streaming platforms (Spotify, deeper, apple music, tidal etc.) Generally work a lot better than movie/series streaming. It seems that competition between them works quite well, prices are reasonable, and more importantly, any subscription gives you access to pretty much all of mainstream music. There's hardly any content exclusive to one platform, so you can essentially get any of them and be done with it
Contrast that with video streaming, where content is pretty much exclusively tied to one platform. As a consequence, people routinely have several subscriptions instead of one, and platforms compete on library more than on price or quality of service. Overall experience is much worse
I wonder why this difference came to be, although these are very similar services (with basically the same copyright mechanism)
Performance, safety and IO critical code must care, because the page size affects TLB caching and is the finest granularity for security flags such as read-only, no execute, etc. which are critical for e.g. guard pages.
If your code that created two guard pages sandwiching a security critical page to make sure that under/overruns caused a page fault and crashed that assumed the boundary was at 4KiB, but is really now at 16KiB, that means that buffer overruns now will not get caught.
Further, code that assumed it was on a page boundary for some reason, for performance reasons, will now have only a 25% chance of being so.
It also means that MMIO physical pages that were expected to be contained within a 4KiB page such that when mapped into a sensitive user space driver context, neighboring MMIO control blocks wouldn't be touched, might be affected too since you'll get up to 3 neighboring blocks in either direction. This probably doesn't happen so often, I don't know Android internals much, but still something to consider.
This is in large part because PAGE_SIZE in a lot of C code is a macro or constant, rather than something populated at runtime depending on the system the code is running - something I've always felt is a bit problematic.
That being said, code that's hard coding PAGE_SIZE won't run anyway if using e.g. mmap() because it validates the page size and will error on mismatch.
This is going to wreak general havoc for a while no matter how you spin it.
Because the final ELF binary is linked to contain page aligned segments. Segments define how should the binary be loaded into memory and what permissions they require.
If you have a 4KB segment that is marked Read-Write followed immediately by a Read-Execute, naively loading it will open a can of security issues.
Moreover many platform data structures like Global Object Table of the dynamic executable uses addresses. You cannot simply bump things around.
On top of that libraries like C++ standard library (or abseil from Google) rely on the page size to optimize data structures like hash maps (i.e. unordered_map).
If you rely on being able to do things like mark a range of memory as read-only or executable, you now have to care about page sizes. If your code is still assuming 4KB pages you may try to change the protection of a subset of a page and it will either fail to do what you want or change way too much. In both cases weird failures will result.
It also can have performance consequences. For example, if before you were making a lot of 3.5KB allocations using mmap, the wastage involved in allocating a 4KB page for each one might not have been too bad. But now those 3.5KB allocations will eat a whole 16KB page, making your app waste a lot of memory. Ideally most applications aren't using mmap directly for this sort of thing though. I could imagine it making life harder for the authors of JIT compilers.
Some algorithms also take advantage of the page size to do addressing tricks. For example, if you know your page size is 4KB, the addresses '3' and '4091' both can be known to have the same protection flags applied (R/W/X) and be the same kind of memory (mmap'd file on disk, shared memory segment, mapped memory from a GPU, etc.) This would allow any tables tracking information like that to only have 4KB granularity and make the tables much smaller. So that sort of trick needs to know the page size too.
most code shouldn't but you don't know what the library you're using is doing behind the scenes. the few code that do care, if a lot of people use them as a dependency, that could get real messy real fast.
My very personal opinion is maybe it shouldn't be ok for humans either. Maybe the benefits of cars absolutely don't outweigh the contant risk of deaths and injuries they pose (especially in metropolitan aeras where they are easily replaced by other modes of transportation)
Reality is "because humans can take responsibility for their actions". And it seems the way our society is built, we'd rather have individuals take responsibility than question the system
But we see bad driving whenever we are out ambulating in the streets, anyway, even in a world with vehicles that are almost always operated by humans.
In this world we have today, illegal things happen on the road all of the time.
(And we've always seen it, at least in quasi-modern times. It isn't something recent. I'm absolutely certain that we saw it in the horse-driven era, too; we just didn't have much in the way of pocket supercomputers back then to record it with.)
I mean, they might not have given thought to that particular corner case, they probably wrote something like
> memcpy(void* ptr1, void* ptr2, int n)
Copy n bytes from ptr1 to ptr2.
UNDEFINED if ptr1 is NULL or ptr2 is NULL
‐------
It might also have come from a "explicit better than implicit" opinion, as in "it is better to have developers explicitly handle cases where the null pointer is involved
I think it's more a strategy. C was not created to be safe. It's pretty much a tiny wrapper around assembler. Every limitation requires extra cycles, compile time or runtime, both of which were scarce.
Of course, someone needs to check in the layers of abstraction. The user, programmer, compiler, cpu, architecture.. They chose for the programmer, who like to call themselves "engineers" these days.
> C doesn't have any problems adding 4 to NULL nor subtracting NULL from NULL.
"Having problems" is not a fair description of what's at stake here. The C standard simply says that it doesn't guarantee that such operations give the results that you expect.
Also please note that the article and this whole thread is about the address zero, not about the number zero. If NULL is #defined as 0 in your implementation and you use it in an expression only involving integers, of course no UB is triggered.
When I lived in socal, almost every person under 35 i knew there was living in a 2-4bd with roommates.
1bd and studios were very scace, and almost often prohibitively expensive.
So I second that creating a real offer for 1bd and studios would definitely free up family housing.
On top of that 1 and 2-person households still need housing. Building some for them is a good thing in my book