senfiaj

What about TOR or VPNs + faking user agents?

Ah, sorry, yes, tried with a very different message. But it can still read when telling that the text is formed by movement. AI doesn't see the world the way we do, so it's understandable. https://chatgpt.com/share/6a522660-929c-83eb-91ff-66b7873420...

I downloaded the message video, renamed it to test.mp4

Still could read https://chatgpt.com/share/6a5221f0-e3fc-83eb-bc15-74420002b6...

I gave him this video file https://streamable.com/1bxxyf

No, it can https://chatgpt.com/share/6a521e9b-c754-83ed-9d8e-cf653894eb...

Yeah, I'm so sick of hearing "it's way faster to install app on linux by using terminal than using that bloated gui softare center".

What happens if I cover the camera?

> For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.

IMHO, the complexity of kernel and compilers is usually more justified and less accidental. At least non technical people are rarely the cause.

In my company it's a bit more complicated, but I have the spirit of your thoughts. I think business software (such as the ERP-like software I work on) is often an entropy magnet from the complexity point of view. It doesn't strive to be simple and elegant because business / finance world is messy. Whether all the complexity and messiness of the financial world is accidental or justified, this is irrelevant for me because I don't care about their business problems. It will be soul sucking anyway.

> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive.

This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.

> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night.

Joel Spolsky disagrees here: https://www.joelonsoftware.com/2001/02/12/human-task-switche...

Yeah, same thoughts. And this industry is becoming so volatile, I'm not sure what will happen tomorrow. I mean it's highly unlikely that AI will replace developers at least in the next 10 years, but I'm not sure what will "software developer" become. Certain people love to work with details. If AI is taking away this joy, I'll rather retire as early as possible from this volatile industry.

Even before LLMs ORMs are good enough to cover most of the use cases. Only some complicated use cases needs raw SQL. So you can use both.

What's the problem with using ORMs for 95% of the cases and using raw SQL only for the remaining 5% where ORM isn't sufficient? One important benefit (aside from writing less code) of ORMs is type checking which is important for maintainability in large complex projects.

Yes, that was my point. But Windows might still allocate pages lazily (i.e. reserve them and actually allocate only when the program writes into them). The difference from Linux is that it will only reserve if the allocation has a reasonable size and the total committed allocation doesn't exceed certain safe limits / quotas, so it will be possible to safely swap on disk later under low memory conditions.

Well, if Firefox also works on other OSes, it probably should gracefully handle failing allocations, isn't it?

So it's a footgun because a lot of low quality software?

But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?

There was also a bug in the Linux kernel, or did I miss something?

As I understand, Windows can also lazily allocate pages, but it does after making sure the memory budget is adequate in a case of low physical RAM pressure and is guaranteed to be backed up by a page. But yeah, Linux approach is really sloppy.

I think Windows doesn't do OOM kill, it just fails fast for unreasonably large memory allocations. If the allocation is succeeds, the committed virtual pages are backed up (or more precisely guaranteed to be backed up) by a page file.

I think Windows also uses something similar to Linux memory overcommit (maybe call it "lazy page allocation"), but probably all the available virtual memory is backed by the page file, the OS has limit for the allocation size and all the edge cases are handled well under low memory conditions. For example, think about stack memory. Megabytes of stack space can be reserved for each thread, but since programs rarely use the whole stack, it's not rational to immediately allocate all the physical pages, it will waste a lot of memory (especially for multi-threaded programs). The stack grows on demand when the program hits a guard page.

In short, Windows partially does the same lazy thing but unlike Linux with its optimistic overcommit, it is stricter about commit/backing-budget reservation.

> To download apps on an iphone, you need an apple id.

iOS is worse than MacOS. I was only talking about MacOS.

Well, they might still do it but less aggressively. For example, only when using MS Store or only some specific services. Apple uses a similar strategy with MacOS. Online accounts can also be convenient with with service integrations, provided they are optional. Also, I slightly disagree that average users don't care at all. Even setting aside ideological reasons, mandatory online accounts are terrible if there is no internet or the system must be preinstalled for another person (although the person who installs is not that average user). The system should be functional in offline mode.

> Windows 11 requiring TPM, Secure Boot and being all react wasn't great.

For me a bigger concern is that Windows 11 requires MS account, and making harder and harder to bypass it. This is a disrespect for my freedom and privacy. The hardware is not the biggest issue because it might catch up eventually. https://waspdev.com/articles/2026-03-12/i-ll-probably-never-...

The source, conventions are quite similar to Linux. So, probably some level of POSIX compliance + reusing standard libraries (such as mlibc) helped a lot.

Cool. I also had similar idea: https://github.com/surenenfiajyan/3d.js . But your one looks richer in features.

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.

> In 2026, we have to worry the a discontiguous memory space looks flat.

Well, there are large/huge pages (2MiB/4MiB/1GiB) that reduce this problem.

> 8086 can't address 2MB of memory

This was just for illustration, not claiming that actual 8086 does this.

> Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...

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.