What about an architecture, where there are pages and access permissions, but no translation (virtual address is always equal to physical)? fork() would become impossible, but Windows is fine without it anyway.
You are describing a memory protection unit (MPU). Those are common in low-resource contexts that are too simple to afford a full memory management unit (MMU). The problem with scaling that up, especially in general-purpose environments with dynamic process creation, is fragmentation of the shared address space.
You need a contiguous chunk for whatever object you are allocating. Other allocations fragment the address space, so there might be adequate space in total, but no individual contiguous chunk is large enough. You need to move around the backing storage, but then that makes your linear addresses non-stable. You solve that by adding a indirection layer mapping your "address", which is really a key/ID, to the backing storage. At that point you are basically back to a MMU.
Sure, but we're talking about a hypothetical architecture without memory mappings but with pages and permissions. Software compatibility was already tossed in the trash can at that point.
1Tb m.2 SSD cost 70 USD in summer 2025, and probably much less when bought in bulk as a chip. It doesn't make sense to install anything less than 1Tb in an expensive premium laptop. Or it should be upgradeable.
Apple's pricing is one of the reasons I am not going to buy their laptops. Expensive, and with no upgradeable or replaceable parts. And closed-source OS with telemetry.
> Lots of people more or less use their computer as a glorified web browser
For this purpose they can buy $350 laptop with larger screen.
It is clear that SVG should not support scripts and CSS in SVG files. Those who need them can simply create HTML with inline SVG tags and scripts. And SVG should contain only shapes, effects and transformations.
Or maybe we need a new image format, "SVG without scripts and CSS".
The problem with CSS is that if you want to write an SVG viewer, you have to implement a whole CSS engine, which might be more complex than SVG renderer itself. And if you create an image in an editor, like Inkscape, you don't use CSS anyway. CSS is meant to be used when you write the code manually (instead of using an editor), for example, in a web app, and in this case you could use HTML as well.
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
React is an implementation of View component of MVC, View is responsible for displaying Model contents, not for handling routes. You are trying to use the wrong tool.
I looked at the code examples and instantly saw something familiar. I remember, there was a library that intercepted link clicks, made AJAX requests and updated DOM with response, so that the page would update without reloading. If for any reason the code failed, there was just standard link navigation so you could access the content any way. I think it was pjax library.
It made the site look like a SPA without having to write any extra code. How cool is that.
HTMX resembled me this library. But it seems very narrow cased, there are only so many attributes and their values and you cannot implement anything else. While pjax is generic: you can attach it to any site which has links.
Also you cannot replace Vue (don't use React) with HTMX. For example, if you are making a diagram editor, HTMX won't be useful.
That’s a very fair point. Showing the full list makes it easier for automated scrapers to blacklist the whole pool. I’m considering moving to a 'Random Rotation' by default, and only revealing the domain picker for advanced users. Balancing discoverability and resilience is definitely the biggest challenge here.
being able to reply IS the ability to send to an arbitrary address, because the SMTP protocol makes it trivial to SEND an email from any arbitrary address.
You hit the nail on the head. From an SMTP perspective, 'replying' is functionally identical to 'sending,' which is why most disposable mail services are strictly receive-only.
The moment you allow outbound traffic, you risk being weaponized as an open relay for spam. To implement a safe 'Reply-Only' feature, Mephisto would need a sophisticated validation layer that cryptographically links the outbound reply to a specific, recently received message ID. Even then, rate-limiting would have to be extremely aggressive. For now, staying receive-only is a deliberate choice to protect the service's reputation and ensure 100% uptime.
nah its just me lol english isnt my native language so i tried way too hard to sound professional and clear... guess i overdid it and sounded like a bot. im just super nervous with 145 users right now my heart is still racing trying to keep up
There are additional protocols like SPF, DKIM, DMARC which allow to restrict who can send mail for a domain. In this case you should be able to validate the address.
That is an intriguing feature request. Most disposable services avoid outgoing mail entirely to prevent being abused for spam, but a strict 'Reply-Only' policy (where you can only send to the address that just emailed you) is a clever middle ground.
Implementing this while maintaining the zero-persistence architecture would require a secure, ephemeral SMTP relay. It’s definitely a complex challenge, but the value it adds for verifying accounts that require a response is huge. I’m adding this to the experimental roadmap!
All of these domains are already widely known because Guerrilla Mail are the ones actually running the email service, his website is a wrapper with a CORS proxy.
He doesn't own or operate the cors proxies, mail infra, domains or the api
guilty of using ai studio for the fast prototype lol but the 145 users today caught me off guard... im working on a clean production build right now to move away from the google cdn stuff. just trying to build a better ui for these apis without all the bloat and tracking! thanks for the heads up
thanks for the links sixtyj. the cat and mouse game with these lists is never ending... i agree that the ethical use cases like whistleblowing are why these tools need to exist. its a tough balance to keep them accessible but not abused.
reply