> attitude towards user experience was more prevalent in mainstream OSs.
> 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)
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.
Oh this again. The idiots at the WireCutter already covered this and they think it's just fine.
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).
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.
> Mostly everyone else seems to define the bitness of CPUs by their capacity to add numbers in one go, not by the address space they can address.
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?
> They went from 95 and XP, some of the best operating systems from a user's perspective
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.
> when was the last time you heard about someone having file corruption on their local OS due to using a bad filesystem technology?
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?
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.
> Namecheap immediately resold the domain to a squatter
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.
> I think what I'm saying is that calling file I/O "blocking" is also not a useful definition of "block". Because I don't really see the fundamental difference between "we have to wait for main memory to respond" and "we have to wait for disk to respond".
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.
> My argument is that disk I/O is more like memory I/O than it is like network I/O
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?
> Sure it does! Main memory is much slower than cache so on a cache miss the CPU has to stop and wait for main memory to respond. The CPU may even switch to executing some other thread in the meantime (that's what hyperthreading is).
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.
> If you really think about it, the only real difference between main memory blocking and disk blocking is the amount of time they may block.
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
> If you can't take pride in a job well done as a store clerk, why the hell does anyone think you'll take pride in a job well done as a developer? That motivation is internal.
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?
Lol, are you trying to make a convincing argument? And if not, why bother replying with such nonsense.
That short list provided is not "most software", thats a smattering of infrastructure type software.
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).
If you're going to use language like "patently false" it helps to be correct. Keyless car fobs are not constantly transmitting. If they were, the battery would die quite quick.
The key combinations to disable them help to prevent relay attacks, not because they just constantly transmit.
> 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)