If I'm not mistaken 286's protected mode wasn't really that popular because it breaks real mode DOS programs. Meanwhile, 386's 32-bit protected mode with paging and virtual 8086 mode was a big success.
And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types. Paging later made this kind of thing look like one flat array, a thing segmentation could not: making non-contiguous physical RAM appear contiguous to the program.
Maybe (I think it's possible in protected mode), but it still has an allocation problem, imagine there are programs A, B, C in the memory. Later, A and C are unloaded, leaving 2 free holes, totaling in 2MB. Now you want to load a 2MB program, but there is no unfragmented 2MB free block. The only solution I see, is to shift some loaded programs, which might be slow and even risky. Paging makes this problem much easier. Also, paging makes permissions and memory sharing more granular.
For its time it was a decent idea. Software was smaller and simpler. But today (and even before 64-bit) software is larger, more complex, we also need memory protection / isolation and more flexible memory allocation / sharing, so paging memory was not introduced for nothing.
But once you have written in assembly, you could start to write the next version in the higher level language. The first version (written in assembly) doesn't necessarily have to produce the most optimal code, just good enough and correct. Most of the improvements can be done in the self hosted compiler (in a higher level language). So this period did not have to last many years.
Writing an optimizing production ready compiler doesn't seem to be an easy task, even today. I mean you can fork a compiler or look at the code, but maintaining your own one alone doesn't seem to be realistic.
>> - not writing compilers in assembly
Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.
32-bit int isn't too much overhead. Just 3 additional bytes. I bet it's almost always better than c style strings. In the vast majority of situations the price isn't that bad, considering you make strings much more secure and potentially faster in string manipulations.
Well, not saying to always use it, but if the string size is big enough, the overhead of 2 ints becomes relatively vanishing. For generic dynamically sized strings it probably has more advantages than disadvantages. But in any case, sure, if every single byte matters or some structure requires specific memory layout, then fine. I just don't think these things are the majority of use cases. Keep in mind that the cached lengths can increase performance, since you don't have to recalculate string lengths.
Exactly, you can't write clean concise code when working with c strings. Almost every c string manipulation requires cognitive load: "Is the buffer size enough (including null terminator), should I reallocate it?", "I need to have the offset from the last concat, to make next concats performant", "Umm, shold I put null terminator at i or i + 1?"... It really sucks, it's akin to death by thousands of cuts.
I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.
Actually, WASM32 usually runs in a 64-bit browser, so it can utilize most of the 64-bit instructions and general purpose registers. The problem is it's much harder to ensure that 64-bit pointer don't access browser critical data structures such as stack or heap contents. At least for WASM32, the pointer arithmetic is easily forced to be 32-bit in natively running JIT-ed code without dramatic performance loses. So, it's guaranteed that the WASM32 module won't access anything further than 4 or 8GiB (4GiB + 4GiB, when doing more complicated effective memory addressing instructions), thus, it's easy to cage a 4GiB memory block and surround it with guard buffers of comparable size inside a 64-bit virtual address space. With WASM64 you can't do this optimization because 64-bit pointers easily access your browser's memory, you have to add a lot of runtime bound checks if the compiler static checker can't guarantee landing inside the safe address range.
Not sure about SIMD. If you mean WASM, the main advantage of WASM32 over WASM64 is execution speed if it runs on a 64-bit runtime. This is because pointer accesses are simply 64-bit base pointer + 32/33-bit offset (the 32-bit pointer value in WASM program + some 32-bit optional offset). Since the offset in the memory access is already trimmed to 32/33-bit (in a 32-bit half of the register) at machine instruction level there is no possibility to escape the 8GB virtual memory cage that Chrome allocates, thus no need for additional runtime checks. WASM64, on the other hand, can escape without such checks.
Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
But this raises the barrier to entry into programming if LLMs are capable of doing the vast majority of junior/mid level tasks. This can ruin the lives of many average people for whom programming was one of the few truly possible jobs. I have a friend whose initial interests are not related to IT and he is not particularly passionate about programming, but it still brought him a decent income (unlike the profession he was passionate about). This is the people I'm talking about, they need some fucking stable job that brings income.
I guess it was awkward to use languages that had higher level than assembly in order to write 16-bit programs that required more than 64KiB of memory. And also not quite portable, since they were all tied to x86 CPU. Those were messy times I guess. A somewhat similar story was 32-bit PAE, where the the CPU could address more than 4GiB physical memory, but software was still 32-bit and virtual addresses were capped at 4GiB. Linus was right that you must have more virtual memory (preferably 10+ times more) than physical, otherwise you have to jump through hoops. https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...
>> Chrome's PIP is a stupid workaround for Windows and Mac because they do not have robust window management.
What are you talking about? It's very convenient when I watch video while I do some work or entertaining thing on other web page or app. It's fine if you don't want to use it but many people do.
Yes, exactly. This security paranoia makes the devs' lives much more complicated. I have seen many apps turning off advanced features, such as screen color pickers. Automatation tools can be broken. Apps cant know their window positions, etc. You can see countless dev rants about Wayland and how it's generally unpleasant experience to work with.
As far as I know, there are multiple Wayland implementations. Which is also not good because it creates fragmentation and potential inconsistencies (some subtle differences in behavior, differences in bugs, etc). Maybe Hyprland solves the issue, but I don't want to use this DE just because it solves this particular issue. I have tons of other needs and preferences.
What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications.
Not saying that X11 is not broken and should not be replaced, but many Wayland's decisions harm user experience more than X11.
The argument is from the generator implementation point of view. Using regular escape is much simpler. Unlike regular escape, you still cannot use CDATA for attribute values. CDATA might quickly become a footgun because it can give you a false sense of security. Regular escaping is much more universal and also works with HTML content / attribute values.
> I'm not sure how CDATA makes "debugging confusing," and in any case using CDATA blocks inside an article seems like a pretty rare case; like I said, I haven't done that myself.
Debugging can be confusing when you actually encounter that closing sequence, the text becomes much less readable and seems kind of broken. With regular escape the content is more distinguishable (even though harder to read) from the structural XML. Actually, its rarity can be more of a problem because you might never know about it and not even handle it in your own serializer at all. The "magic" of CDATA is dangerous. You might not believe it, but many developers still don't do any proper escaping when injecting text in DOM elements. They often do element.innerHTML = "Some untrusted text". I have seen such things countless of times.
> The OP seems to argue "don't use CData, because the escape sequence for ]]> looks confusing" - and that's just vibes, not a proper argument.
There are more arguments listed. One major one is about not being uniform. You still cannot use it for attribute values. CDATA might quickly become a footgun because it can give a false sense of security. Regular escaping is very universal and also works with HTML content and attribute values.
My first impression was also that such a huge project was too good to be true (especially that it is supposed to replace Ubuntu) if it was written from scratch. And then also noticed that it was AI assisted. Didn't run it and don't know how much of this was done by the author himself. Also I don't understand what is this "third state".