> It's little things like errors automatically prompting you to open a graphical debugger

If this is the concept of "mainstream" and sensible "user experience" it sounds like Haiku is a complete bunch of horseshit. (And this feature is easily available in Windows anyway)

https://www.nytimes.com/wirecutter/blog/picking-smart-deadbo...

Notice that they essentially rake (with the godawful demonstration of "picking") on what looks like a Level lock to then make the conclusion that AlL Locks are pickable because even an idiot that doesn't know the difference between picking and raking can do it.

Mass market smart locks are a dumpster fire and they have the full support of the mass media. The #1 Wirecutter smart lock pick has this exact same flaw - a shitty cylinder that is prone to trivial bumping and that could easily be improved - the cheapest big box deadbolts have better cylinders. Someone had commented on that article (since removed) about this flaw - and the moron behind the Wirecutter smart section has just gone on and on about how this isn't a real problem, bla, bla - even had the audacity to post of a video of I'm guessing him demonstrating a poor raking attempt on one of these crappy locks to "prove" how "easy" locks are to pick - yes you dumbass, if you only use shitty locks with no protection.

He followed up with the gem that "the point of the lock picking lawyer is to show that any lock can be picked" - Again, no, idiot - the LPL does a tremendous amount of education to expose trivial weaknesses in particular products that can and should be addressed - he often points out when products provide a reasonable level of security for the price. The Level lock and the Ultraloq (the NYT top pick), do not. Fuck Wirecutter and the New York Times, enjoy your referral money you dishonest pricks. (U-Tecs customer service is also shit tier, something they even admit in their own review)

https://www.nytimes.com/wirecutter/blog/picking-smart-deadbo... The premise of this article seems to be - there are some high priced smart locks (that we promote) that are easy to bump open, therefore all locks are easy to bump, and you shouldn't factor pick resistance into buying decision at all. And also: raking and bumping is in the same class of difficulty as pin picking (this difference has been explained to them - this is not for lack of information).

https://www.nytimes.com/wirecutter/reviews/the-best-smart-lo...

Actually is that the Level lock they demonstrate on back in October? Notice that isn't a Schlage - I'd like to see him try that.

Another thing they keep bringing up this ANSI Grade 1 nonsense - I have looked - I cannot find any evidence of 3rd party certification for their top pick. It's all bullshit.

https://buildershardware.com/Certification-Program/Certified...

Nah, only historically. Yes, "8-bit" refers to the ALU. Back in the day, 16-bit was similar. But even then it was muddy, because when talking about operating systems like Unix or NT the key question about bitness would be in the context of a 32-bit flat addressing model, not really the data width.

By the time the 64-bit era rolled around, the "64-bits" definitely referred to address space.. The original Pentium had a 64-bit data path and had instructions (MMX, eg PADDQ) that could operate on 64-bit numbers - no one would call it 64-bit. By the early 2000s with the big push to mainstreaming 64-bit, it was all breaking out of the 4GB address space limitation - not the width of data.

> define the bitness of CPUs by their capacity to add numbers in one go

This is nebulous and therefore troublesome to define. Are we talking about the ISA or the internal circuitry (ALU and/or data path)? Is the 68000 a 16-bit or 32-bit CPU?

I mean that's some rose-tinted shit if I ever heard it, 95 especially. 98 OSR2 improved quite a bit on the situation, but I don't recall having a great time with 95. It was still a glorified DOS extender in many ways, often slow to start up and shutdown, PC hardware and drivers were a mess and system stability therefore poor. This was right at the beginning of the concept of "PnP" in the PC world (plug and play) and it was a cruel joke most of time.

Windows 2000 being from the NT line was peak Windows in many ways. I resisted XP but it was ok for most people admittedly.

Quite frequently. It's not that uncommon at all. Bad disk cables, defective disks, etc it's not all that rare. The filesystem is in a place to either detect and/or correct these problems. Only some do.

> I've never cared what filesystem was on my local PC because it's basically irrelevant with modern tech.

I'm glad you've been lucky but silent file corruption is not an "irrelevant" problem as data densities increase.

Filesystems with data checksums include btrfs, ZFS, ReFS, NILFS. But very commonly used filesystems, xfs, ext4, NTFS, APFS, exFAT do not have this feature (some of them do have metadata support).

> it's basically irrelevant with modern tech.

Unnecessary e-peening aside - Why do you think this is the case? What specifically about modern tech makes it irrelevant?

Define this.

But the simple, practical answer is no.

The "original process" of integrated circuit design was cutting rubylith - this was well into the 70s. The venerable MOS 6502 was done this way as was the Intel 8008.

The verb tapeout was used for litho prior to integrated circuits though, back into the 40s.

But you should realize that PCBs and integrated circuits predate generally available computers and digital data storage.

> exported to a data tape for transport to the fab.

There was an article in The Register years ago that promulgated this misattribution - it was generally never a reliable source, no exception here.

No I don't see how their post allows one to infer that Namecheap "immediately" resold the domain. Their policy is a 30 day grace period, and within that 30 days the domain should become non functional, so if you're actively using it then you would know something is up.

Sounds like jamiek88 was squatting on a somewhat desirable domain and is just sad they couldn't follow some basic instructions.

I have no idea what the "because of COVID" thing is about.

Ummm.. then maybe get a better registar? It's not like there aren't many to choose from.

1990? No system without soft microcode? That's a very restricted definition of system for the field of computing in 1990.

In addition to the point elsewhere made that you're sort of implicitly denying the magnitude of the differences here - the latency differences are on the order of 1000s.

The other way of separating is if the OS (or some kind of software trap handler more generally) has to get involved. A main memory read to a non-faulting address doesn't involve the OS - ie it doesn't ever block. However faulting reads, calls to "disk" IO, and networking IO (ie just I/O in general) involving the OS/monitor/what have you are all potentially blocking operations.

It depends on your network and disk - and yes SSD and "slow" ethernet are the common case, but there is enough variation (say an relatively sluggish embedded eMMC on one end and 100 GbE for the networking case), that there's no point in making some distinction about disk vs network latency - for a general concurrency abstraction they're both slow IO and you might as well have a common abstraction like IOCP or io_uring.

> concurrency purposes it may make more sense to treat it like you would memory I/O (use threads) than like you would network I/O (where you'd use non-blocking APIs and event queues).

No, case in point, Windows had IOCP for years such that you could use the same common abstraction for network and disk. The fact that the POSIX/UNIX world was far behind the times in getting its shit together doesn't mean much.

And why, fundamentally, can you not use blocking APIs with threads for networking?

Cache is a memory. And which cache, by the way? Even L1 cache on modern processors doesn't have 0 latency. And this is a rather poor way of describing hyperthreading - the CPU doesn't really "switch" - the context for the alternate process is already available and the resource stealing can occur for any kind of stall (including cache loads), not just memory. Calling this a "switch" suggesting it is like a context switch is very misleading. It's not similar conceptually.

In any event, by this definition even a mispredicted branch or a divide becomes "blocking" - which sort of tortures any meaningful definition of blocking.

The essential difference is - memory accesses to paged in memory (and branch mispredictions, cache misses) are not something you typically or reasonably trap outside of debugging. mmaps, swaps, disk I/O, network accesses are all something delegated to an OS - and at that point are orders of magnitude more expensive than even most NUMA memory accesses. I sort of see where you're coming from - but I don't think it's a useful point.

This is a somewhat confusing analysis you have here. Direct read/write from memory for all intents and purposes doesn't block. Why do you say that reads and writes may also block?

The reason memory blocks is because it needs to page in or out from secondary storage - which makes this statement "the only real difference between main memory blocking and disk blocking is the amount of time they may block." not really true

This is an absurd argument. They have nothing to do with each other. If you'd rather be a store clerk then why should expect you to have much motivation or competence to be a developer?

If you're into idiotic discourse, go ahead and list 1000 open source projects on SourceForge just to "strengthen" your argument.

Tell me - what do most people in industry use for: image editing, video editing, audio and sound design, CAD, EDA, ERP, EMR, logistics, finance - you know actually getting stuff done with those things you mentioned above? Never mind that the vast majority of software written is line of business software.

The landscape of free/open source software has not changed much since the 90s. The market share has increased, some of the names have changed, but it's still the same types of stuff that it excels at (languages, OSes, frameworks).

I think you're in a bubble. The world still runs primarily on closed source and proprietary software and services.