1,121 karma · joined May 16, 2015
Gibson's style may very well be overly self-congratulary and deserving criticism, and many could agree on that. But this piece still reads like inordinate amount of effort just to show somebody and their work in negative light, without actually checking their product and evaluating it rationally and equitably. Even if there are bad things to say about Mr. Gibson's style or his software, the software may still be working and useful, and no attempt at serious evaluation was made.
> And I think it's fair to ask someone who is selling a piece of software for $89 to provide some backing for their claims beyond ones that would only pertain to largely-obsolete hardware.
I agree it is fair to ask, and Mr. Gibson seems like a reasonable ,easy to talk person. Did you try? He has a podcast, Twitter and a newsgroup discussion forum.
The only way that is certain to check the memory cells is to overwrite the whole drive, flush all disk cache (power cycle the system), read all the written bytes, and check that the values read are the same as the values that have been written. This could be accomplished e.g. by setting up encryption on the whole drive on the block level (e.g. on Linux, LUKS), writing zeroes to the open (decrypted) volume, and after power cycle, opening (decrypting) the volume again and checking that all bytes read are zero.
A simpler, less reliable, but still worthy test would be to do the same, except instead of checking the read values, just throwing them away (e.g. on Linux, redirecting to /dev/null). The disk firmware should still try to read all the sectors, and if it is not lying too much, show read problems/reallocated sectors in the SMART data.
> And solid state drives... while there is no doubt performance degradation over their lifetimes, failure modes tend to be all-or-nothing.
Not all drives are perfect until they suddenly die. In my experience, even modern-ish SSD drives (mainly Samsung 870 EVOs...) do develop problems continually. I've seen them both failing quite quickly, and also RAID controller rejecting several of them after some time of working well, then the drive still lived and could be used elsewhere, but in SMART data had bad numbers, including bad sectors (I know, it's SSD!). It's not all-or-nothing failure with SSDs.
> So what about SpinRite? Yeah, what about it? Why spend so much time (ours time) prepping ground for taking down something you do not really use, or have analyzed in detail? Why do you care?
> he doesn't seem to have updated his website in some time... By association, I suspect that GRC's flagship product, SpinRite, doesn't get a lot of active maintenance either.
What kind of a novel thought construction is that? These things need not be correlated. And if you checked, you would find he actually does update Spinrite, recently to 6.0 and 6.1.
> It seems reasonable on the surface, but it wouldn't make much sense with a drive with internal error correction.
It does make sense, because error correction isn't perfect, and sometimes you do get different data from the same sectors, after repeated reads (I've witnessed this on an 18TB drive, I don't know if it was due to a bad drive, or some bug somewhere along the way to my monitor, but it did happen. The drive works well now.).
And if the problem is an unreadable sector(s), and you want to read it, the more times you try, moving the head from different directions, with different internal state while reading (temperature, firmware, platter), the greater the chance one read will succeed.
> even tools dedicated to that purpose (like the open-source badblocks) are becoming rather questionable in comparison to the preemptive capabilities of modern HDDs.
Tools "like badblocks" - writing and reading the whole drive - are not questionable. They are the only quick way of checking if your new drive from the supplier has defective media. I don't do it with all drives, but when I have time and I want the drive to be solid, I do the test, and drives that log bad sectors get returned to supplier.
> their mentions of how SpinRite is a very powerful tool that one shouldn't run on SSDs too often, absolutely reek ...
Maybe there's a good reason for that, like there is a reason for not doing too many write benchmarks on SSDs. Flash degrades on writes, and maybe even on reads a little.
> I don't think SpinRite started as a scam, but I sure think it ended as one.
Based on what - it seems, old claims from an old webpage and bad logic arguments on why the claims are not believable for modern hardrives. Without checking and reporting on the new Spinrite on real drives with problems.
I've never used Spinrite, but this article did not convince me of anything, except the author doesn't like Gibson/his product, and writes a bad blog post about it.
https://en.wikipedia.org/wiki/The_Secret_War_(TV_series)
There is also a related book "Most Secret War":
I have exactly this problem. I need to run centos7-era binary application on rocky9, and of course, it does not compile on the new gcc compiler in rocky9, and also some libraries are missing/have changed too much.
I was thinking I will run the app in a centos7 container on rocky9 machine, but this creates lots of unwelcome complications and additional work.
I'm not very familiar with Nix, but it seems one could install Nix on rocky9 and then somehow use it to build my application against the centos7 devel libraries. Do you think this is a plausible pathway for compiling and running such an old application? It would be great if I could just compile the old app on the new system and forget about containers.
Nuclear experts consider it safe because of existing regulations and because it is hard for sketchy company to launch a new plant.
A nuclear accident creates a big and costly disaster suddenly. People don't like sudden big problems but can live with continuously growing ones.
Burning hydrocarbons is much more acceptable in that regard. CO2/dust pollution is accepted by society, because it is continuous and dilutes well. Killing millions is socially acceptable when it happens randomly all over the planet. Radioactive pollution due to coal burning is/should be negligible, most is(should be) filtered out in the smokestack scrubbers.
I don't like fossil power plants, but they are much easier to build and more acceptable to people than nuclear ones. That's why regulation and security have to be high with nuclear, to make it acceptable to most of society.
> civilization-ending danger
I don't think climate change is a civilization-ending danger in the coming decades. It already creates political problems, migration. If we keep pumping CO2 then maybe in hundred years.
Nuclear energy can be done safely as long as it is run by competent nuclear energy physicists/technicians with real authority, so they can and will shut down stupid ideas such as operating outside parameters because economy/boss said so. This seems to rule out commercial organizations. NRC is more benevolent than that, maybe they should actually be even tougher.
We should allow only competent states to build and operate nuclear plants, so science and rules take precedence to money and boss boot-licking.
This may push nuclear energy into unprofitable territory, depending on the market conditions, infrastructure, water and people resources. Which is fine by me - nuclear energy in some areas is so important for grid stability we should have it even if it is unprofitable.
> However, z/OS also implements 64-bit Java, C, C++, and UNIX (Single UNIX Specification) APIs and applications through UNIX System Services – The Open Group certifies z/OS as a compliant UNIX operating system – with UNIX/Linux-style hierarchical HFS[NB 3][NB 4] and zFS file systems. These compatibilities make z/OS capable of running a range of commercial and open source software.[3] z/OS can communicate directly via TCP/IP, including IPv6,[4] and includes standard HTTP servers (one from Lotus, the other Apache-derived) along with other common services such as SSH, FTP, NFS, and CIFS/SMB.
https://en.wikipedia.org/wiki/Z/OS
Although I like the argument that having an OS that does not require use of C is an interesting feature. Then it's really about the quality software platform, more than about the magic hardware.
Can you link some specific example? That may be an interesting read.
Inertia, regulators, and company having lots of money to the point they don't care (banks...) explains mainframes. They do the job well, so why bother replacing them if you don't care that they cost more.
> "Sun is responsible" for the problem, said a project manager at a large European bank that was affected by it. The manager spoke on condition of anonymity. "Their architecture was fundamentally flawed because there was no ECC checking on the cache memory. This is something you get in even the lowliest Intel processor that costs a few dollars," he said in an e-mail message.
https://www.computerworld.com/article/2585204/sun-fixes-serv...