A bit more on SD and SSD...wear characteristics.

Am 12.08.23 um 12:26 schrieb Pancho:

Discussions with fake identities are futile. The Natural Philosopher snipped-for-privacy@invalid.invalid

Am 12.08.23 um 12:41 schrieb Jörg Lorenz:

Before and after Covid I have no intention to talk to masked and anonymous people.

Why are you talking to me?

Well why don't you STFU then? You have no way of knowing who here is using their real name, or even if they have a real name. Many people have more than one name they commonly use.

As for publishing a real email address, you must be bonkers. I have enough spam as it is.

Try to find out yourself.

Trying to police a newsgroup that is not moderated will not work.

If you don't like the discussion filter it out of your feed, either by poster, or by thread. Complaining will not stop it and just adds to the noise, or gets your articles filtered out by others.

That's how usenet works.

Regards, Dave Hodgins

Just to add a data point to this more and more ridiculous off-topic meta discussion, for Usenet purpose only, email address in my From: header, as well as in my .signature, is quite real and working. I cannot remember the last time, if ever at all, I received spam email at that address. Lucky? Maybe.

Absolutely.

I don't feel it would be worth ones while.

Am 12.08.23 um 13:23 schrieb David W. Hodgins:

Sure. I made my point clear in the first answer to the OP. But so many users thought they had to add something meaningful.

Case is closed for me now and the OP is (again) in my killfile. I will always react to anonymous and impolite wisenheimers the way they deserve in my opinion.

What I observe since I participate in the usenet Anglosaxons often weigh free speech higher than a minimum standard of decency and politeness that helps to increase their credibility.

Believe me, after 22 years in the global usenet I know how it works. Unmoderated Usenet is much more beneficial to all of us if the regulars are very disciplined.

What a pompous prick.

I completely disagree, since he, after a technical discussion (to prove the conclusions), went on to give useful advices specific to Linux, i.g. the one about "noatime" mount option, and the stuff about logging on a ram disk. You seem to be polemising for misterious reasons

At the point where you _need_ something to work for a decade, it's probably worth looking at industrial SD cards rather than off-the-shelf ones. These are commonly characterised by using SLC flash, which trades storage capacity for more write cycles.

NAND flash types:

Here's sales info from another industrial SD card manufacturer, who elsewhere also advertise SD cards with an "advanced wear levelling algorithm":

And to add another data point: I get a few spam messages per day at the real, live email address in my signature. Until recently, I used my email service provider's spam filter to get rid of the repeat offenders but switched to a home-grown filter program after I got blasted with several per day from random-ish invalid domain names. Having "spamtrap" in the name field seems to help.

Indeed. It does seem that with the price of computing power falling so massively, there is little reason *not* to add wear levelling to SD cards. Which ultimately renders them as reliable as any other NAND based flash device.

My interest is, as always, to understand just enough to get the job done, which in this case means I want about 10-15 years of reliable operation on a 24x7 basis.

Having noted that in normal operation as far as I have built it, the unit is not accessing its SD card AT ALL apart from a daily write to some logs, I think that there I will stop.

There happens to be a sufficiency of RAM to regard the SD card essentially as EAROM.

That will do nicely.

Hence the primary metric for SSD longevity is TBW (terabytes written).

Those are pretty good. However within a certain range I still rec FRAM. It's REALLY good and you can get I2C or SPI interface. Capacity, alas, is a bit limited. But, if your app requires keeping track of peak figures, current state and such ... things that ARE going to change a fair bit but MUST be remembered between reboots ....... if you want a decade you don't use SD or on-chip flash.

Well, as mentioned, there may be "sneak" writes of various kinds. Those who make distros for PIs and such TRY to shift everything off into RAM but they can MISS stuff, or discount "lesser" stresses on SD. The focus of such distros is still aimed more at "hobbyists" than "industrial" and they make judgements accordingly.

I wrote a multi-channel environmental monitor for "field" use a few years ago. It took 12 samples per hour. Does not sound like much, but it adds up. The device also HAD to store a lot of high/low and random params which could change every sample.

For that I chose I2C FRAM. No wait states, effectively unlimited re-writes. Better than SD or on-chip EEPROM.

This is NOT a solution for jamming an entire OS into unless it's DOS 2.x but you (and hopefully the distro writers) do your best to shift all the OS stuff into RAM and kinda hope for the best. The params in the FRAM take care of reboots, save "the state".

The horse is dead. Quit beating it. If you find a topic annoying, killfile it. (You do know how to use your newsreader's killfile facility, right?)

FWIW, I find you more annoying than this topic, so...