On Thu, 10 Aug 2023 11:12:05 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 10/08/2023 06:41, 23k.304 wrote:
> > No such thing as "read only" with SD/Flash tech.
> >   Even reading them means re-writing them. Really !
>
> I believe that to be completely wrong.

Nope - but it's not quite as it sounds for details see this patent:

https://patents.google.com/patent/EP2077559A2/en

TL;DR reading does degrade the storage in flash memory which means
it needs to be rewritten before it degrades too much, which takes thousands
to millions of reads depending on the type of cell.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 11/08/2023 10:32, Ahem A Rivet's Shot wrote:
> On Thu, 10 Aug 2023 11:12:05 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 10/08/2023 06:41, 23k.304 wrote:
>>> No such thing as "read only" with SD/Flash tech.
>>>   Even reading them means re-writing them. Really !
>>
>> I believe that to be completely wrong.
>
> Nope - but it's not quite as it sounds for details see this patent:
>
> https://patents.google.com/patent/EP2077559A2/en
>
> TL;DR reading does degrade the storage in flash memory which means
> it needs to be rewritten before it degrades too much, which takes thousands
> to millions of reads depending on the type of cell.
>

Yes, that is what I found, also. Essentially a read is between ten and
a thousand times less destructive than a write.

But in the context of a PI running Raspios or other Linux, with adequate
RAM, 99.99% of reads will be from cache, not the card, anyway. So you
can safely ignore this theoretical issue

Obviously if you are building a busy NAS device, where such conditions
do not apply, you would not be using an SD card anyway.

--
"Women actually are capable of being far more than the feminists will
let them."

On Fri, 11 Aug 2023 12:21:01 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> Yes, that is what I found, also. Essentially a read is between ten and
> a thousand times less destructive than a write.
>
> But in the context of a PI running Raspios or other Linux, with adequate
> RAM, 99.99% of reads will be from cache, not the card, anyway. So you
> can safely ignore this theoretical issue

You pretty much have to ignore it anyway it's all internal to the
device where you have no access to change anything.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

In comp.os.linux.misc 23k.304 <23k304@bfxw9.net> wrote:
> On 8/10/23 3:13 PM, Rich wrote:
>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 10/08/2023 06:41, 23k.304 wrote:
>>>> No such thing as "read only" with SD/Flash tech.
>>>>   Even reading them means re-writing them. Really !
>>>
>>> I believe that to be completely wrong.
>>
>> It is, at least as a general statement in regards to flash memory.
>> There may be /some/ flash "drives" (used generically to refer to SD and
>> SATA disks) where if the controller detects an issue with the read, it
>> may decide to reallocate the data to another set of flash cells.
>>
>>> And unless you can provide some sort of evidence to back up that
>>> assertion, I have to say I consider it utter bollocks
>>
>> Consider the source....
>>
>> I suspect he has mixed up flash technology with DRAM technology, where
>> reading a row from DRAM
>
> "Flash" is a "smart device". It has a controller.
> One function is "wear-leveling", but another is
> "rewrite on read". YOU never see this stuff.

More utter bollocks from the nymshifting troll.

DRAM's rewrite on reads - flash does not.

In comp.os.linux.misc 23k.304 <23k304@bfxw9.net> wrote:
> On 8/10/23 6:12 AM, The Natural Philosopher wrote:
>> On 10/08/2023 06:41, 23k.304 wrote:
>>> No such thing as "read only" with SD/Flash tech.
>>>    Even reading them means re-writing them. Really !
>>
>> I believe that to be completely wrong.
>
> Look it up. I don't have time to do all your research.
>
> YOU don't do the re-write, the logic for that
> it is built into the flash device, hidden in the
> background.

> Reading kinda blanks what's there, and then it has to be re-writ.

That's the DRAM read cycle, not the flash read cycle.

>> And unless you can provide some sort of evidence to back up that
>> assertion, I have to say I consider it utter bollocks
>
> Well, have fun with the bollocks ...
>
> I was there long before any of this tech was
> invented, learned the good AND bad. A lot of
> the bad has been *disappeared* of late ...

And so far, across about 20 different nymshifts, you've spouted by far
more incorrect bullshit than correct information (that and significant
irrelivant Abe Simpson like 'asides').

> "Flash" is not just some dumb memory chip despite
> how it tries to present itself to the user, it
> has a CONTROLLER. One function is "wear-leveling"
> but another underlying function is the "re-write
> on read" aspect.

Flash does not rewrite on read -- DRAM does, but not flash.

In comp.os.linux.misc Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Thu, 10 Aug 2023 11:12:05 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 10/08/2023 06:41, 23k.304 wrote:
>> > No such thing as "read only" with SD/Flash tech.
>> >   Even reading them means re-writing them. Really !
>>
>> I believe that to be completely wrong.
>
> Nope - but it's not quite as it sounds for details see this
> patent:
>
> https://patents.google.com/patent/EP2077559A2/en
>
> TL;DR reading does degrade the storage in flash memory which
> means it needs to be rewritten before it degrades too much, which
> takes thousands to millions of reads depending on the type of cell.

This patent is describing what TNP posted in his other thread about
"disturbing" adjacent cells:

Quoting from early in the description:

The read disturb error is such a phenomenon that, when data on a
certain page of a certain physical block are read out frequently, data
being stored in a cell on other pages of the data read block are
changed.

And a little further on they detail the number of reads necessary to
trigger the refreshing rewrite:

For example, among currently available products, the single-level
cell (SLC) type has the limit of the number of data read of 100,000
to 1,000,000 times and the multi-level cell (MLC) type has the
limit of the number of data read of 10,000 to 100,000 times
(generally, these limits tend to be lowered as the data reading
frequency is increased).

However the nymshift troll is presenting its false argument as "all
reads cause a rewrite".

On 11/08/2023 13:20, Ahem A Rivet's Shot wrote:
> On Fri, 11 Aug 2023 12:21:01 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Yes, that is what I found, also. Essentially a read is between ten and
>> a thousand times less destructive than a write.
>>
>> But in the context of a PI running Raspios or other Linux, with adequate
>> RAM, 99.99% of reads will be from cache, not the card, anyway. So you
>> can safely ignore this theoretical issue
>
> You pretty much have to ignore it anyway it's all internal to the
> device where you have no access to change anything.
>
Well not exactly, the argument was about minimising reads as well as
writes to minimise wear.

My point was to get back from armchair theorising to practicalities. In
practice the disk cache reduces regular reads issues to the card, to zero.

--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

On 11/08/2023 15:13, Rich wrote:
> In comp.os.linux.misc 23k.304 <23k304@bfxw9.net> wrote:
>> On 8/10/23 3:13 PM, Rich wrote:
>>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 10/08/2023 06:41, 23k.304 wrote:
>>>>> No such thing as "read only" with SD/Flash tech.
>>>>>   Even reading them means re-writing them. Really !
>>>>
>>>> I believe that to be completely wrong.
>>>
>>> It is, at least as a general statement in regards to flash memory.
>>> There may be /some/ flash "drives" (used generically to refer to SD and
>>> SATA disks) where if the controller detects an issue with the read, it
>>> may decide to reallocate the data to another set of flash cells.
>>>
>>>> And unless you can provide some sort of evidence to back up that
>>>> assertion, I have to say I consider it utter bollocks
>>>
>>> Consider the source....
>>>
>>> I suspect he has mixed up flash technology with DRAM technology, where
>>> reading a row from DRAM
>>
>> "Flash" is a "smart device". It has a controller.
>> One function is "wear-leveling", but another is
>> "rewrite on read". YOU never see this stuff.
>
> More utter bollocks from the nymshifting troll.
>
> DRAM's rewrite on reads - flash does not.

That sounds about right to me.

--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

On Fri, 11 Aug 2023 16:10:20 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 11/08/2023 13:20, Ahem A Rivet's Shot wrote:
> > On Fri, 11 Aug 2023 12:21:01 +0100
> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> >
> >> Yes, that is what I found, also. Essentially a read is between ten
> >> and a thousand times less destructive than a write.
> >>
> >> But in the context of a PI running Raspios or other Linux, with
> >> adequate RAM, 99.99% of reads will be from cache, not the card,
> >> anyway. So you can safely ignore this theoretical issue
> >
> > You pretty much have to ignore it anyway it's all internal to
> > the device where you have no access to change anything.
> >
> Well not exactly, the argument was about minimising reads as well as
> writes to minimise wear.

Yeah that was silly.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 11/08/2023 13:20, Ahem A Rivet's Shot wrote:
>> On Fri, 11 Aug 2023 12:21:01 +0100
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> Yes, that is what I found, also. Essentially a read is between ten
>>> and a thousand times less destructive than a write.
>>>
>>> But in the context of a PI running Raspios or other Linux, with
>>> adequate RAM, 99.99% of reads will be from cache, not the card,
>>> anyway. So you can safely ignore this theoretical issue
>>
>> You pretty much have to ignore it anyway it's all internal to
>> the device where you have no access to change anything.
>>
> Well not exactly, the argument was about minimising reads as well as
> writes to minimise wear.
>
> My point was to get back from armchair theorising to practicalities.
> In practice the disk cache reduces regular reads issues to the card,
> to zero.

For what you've described as your use cases for the PI's, yes, the
Linux disk cache should minimize the number of reads that hit the SD
card. That is once it has booted and reached its normal operational
steady state.

You should end up seeing very close to zero reads and writes to the PI
sd cards given what you've described to us. Certianly a low enough
rate that even a less than stellar card should last for quite a long
time.

On 8/7/23 9:55 AM, The Natural Philosopher wrote:
> On 07/08/2023 12:55, Jan Panteltje wrote:
>> No Empire Has Lasted Yet in history, US is way over the hill.
>> Likely Texas will soon leave that Union... the others will follow.
> Yes, these 19th century Empires are a bit passé..the end of Russian
> federation, the European Union, the United states - all are possible and
> more, or less likely as time moves on.
>
> In an unlikely turn of phrase, in rapidly changing world contexts, they
> are simply  too big to survive.
>
> What suits downtown New York does not suit wilderness Utah. And vice versa.
>
> federalisation at least and possible independence, whilst maintaining
> overall ties under some NATO and Interpol style pan national
> organisations would seem to be the way forward

First off, NO state will be leaving the USA - it's
actually illegal, they can and will send in the army.
Bet on it.

As for "differences" ... that was part of the whole
idea of a United STATES. Not every environment, every
local culture, every local need, is the same. Truly
"national" govts like to forget that - and it causes
BIG problems. Can even cause bloody revolutions where
everyone suffers horribly.

As for "empires" - there's a FALLACY to "empire" in
the usual meaning. They only survive by engulfing
more and more - and every bit they obtain soon
becomes a management EXPENSE. It's doomed. From
Sumer and Akkadia all the way to Rome and the
Mongols and Ottomans, this has been the horrible
horrible truth of "empires". They are about EGO,
not fiscal reality.

But then this was SUPPOSED to be about what to do
with /var/log :-)

In article <ua960d$3chlq$1@dont-email.me>,
druck <news@druck.org.uk> wrote:

> Secondly stop systemd spamming /var/log/syslog with all sorts of
> crap you have no interest in. Create a file called
> /etc/rsyslog.d/drop.systemd.conf containing

> # Drop messages from f***ing systemd
> :programname,startswith,"systemd" stop

The latest bookworm release (32 bit lite) October 10th 2023 does not
seem to have the directory

/etc/rsyslog.d

and so I created it and copied drop.systemd.conf into it. Is that the
right thing to do ?

Bob.

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 11/08/2023 13:20, Ahem A Rivet's Shot wrote:
>> On Fri, 11 Aug 2023 12:21:01 +0100
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> Yes, that is what I found, also. Essentially a read is between ten
>>> and a thousand times less destructive than a write.
>>>
>>> But in the context of a PI running Raspios or other Linux, with
>>> adequate RAM, 99.99% of reads will be from cache, not the card,
>>> anyway. So you can safely ignore this theoretical issue
>>
>> You pretty much have to ignore it anyway it's all internal to
>> the device where you have no access to change anything.
>>
> Well not exactly, the argument was about minimising reads as well as
> writes to minimise wear.
>
> My point was to get back from armchair theorising to practicalities.
> In practice the disk cache reduces regular reads issues to the card,
> to zero.

For what you've described as your use cases for the PI's, yes, the
Linux disk cache should minimize the number of reads that hit the SD
card. That is once it has booted and reached its normal operational
steady state.

You should end up seeing very close to zero reads and writes to the PI
sd cards given what you've described to us. Certianly a low enough
rate that even a less than stellar card should last for quite a long
time.
. Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
From: Jim H <invalid@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Isn't life wonderful
Sender: Jim Higgins <invalid@invalid.invalid>
Reply-To: invalid@invalid.invalid
Message-ID: <pa8nfihioe89m630diicgo4u7uktprd2j0@4ax.com>
References: <ud7dd2$20oga$1@dont-email.me> <ud7fsn$2143u$1@dont-email.me> <20230905173756.aef6b78f14655e9b0d15b860@eircom.net> <wwvtts8jt2d.fsf@LkoBDZeT.terraraq.uk> <ud9lhc$2f529$4@dont-email.me> <ud9qdu$2dslj$1@dont-email.me> <8lhhfitqr03fabmt37qk0b33l6hnsveo15@4ax.com> <udaokq$2dslj$3@dont-email.me>
User-Agent: ForteAgent/8.00.32.1272
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 20
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 08 Sep 2023 22:36:31 +0000
X-Received-Bytes: 1880
Xref: rslight comp.sys.raspberry-pi:8020

On Wed, 6 Sep 2023 20:49:30 -0000 (UTC), in
<udaokq$2dslj$3@dont-email.me>, Martin Gregorie
<martin@mydomain.invalid> wrote:

>On Wed, 06 Sep 2023 18:45:43 +0000, Jim H wrote:
>
>> Really? I had a drive thru ATM reboot on me once, The boot screen said
>> it was running Windows.
>>
>There are several ATM manufacturers, and anyway the models I worked on in
>the late '80s and '90s are quite unlikely to be around now. I forget who
>made the ATM varieties I was familiar with or what, if any OS, their FSMs
>or equivalent ran on: its quite likely that some ATM makes and models ran
>under Windows.

The one that rebooted on me and displayed a Windows screen did so
maybe a year ago. If it mentioned what version of Windows, I don't
recall.
--
Jim H
. Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tauno Voipio <tauno.voipio@notused.fi.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Limiting the capacity of SD cards for the pi
Date: Wed, 20 Sep 2023 16:15:44 +0300
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <ueera0$2ume0$1@dont-email.me>
References: <5ae53c469cbob@sick-of-spam.invalid>
<5ae5599655bob@sick-of-spam.invalid> <ue7352$dmc3$1@dont-email.me>
<5ae55f08eebob@sick-of-spam.invalid> <ue7717$e079$7@dont-email.me>
<5ae5653ec8bob@sick-of-spam.invalid> <5ae569ba7ebob@sick-of-spam.invalid>
<slrnugegu8.vum.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
<5ae5792215bob@sick-of-spam.invalid>
<slrnugg2jt.vum.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
<uea9tv$1ttgl$1@dont-email.me> <uebh29$2803p$2@dont-email.me>
<uebsd7$2a1j4$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Sep 2023 13:15:44 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="782683fbff76655bbb2aac12dd89a205";
logging-data="3103168"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19g2D47Dk1ft+Xd8RyjharUjube7YdUgEs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:5mMNe7rJWbhCPG1yoaJOvpQcqjc=
Content-Language: en-US
In-Reply-To: <uebsd7$2a1j4$1@dont-email.me>
Xref: rslight comp.sys.raspberry-pi:8020

On 19.9.2023 13.16, Chris Elvidge wrote:
> On 19/09/2023 08:02, The Natural Philosopher wrote:
>> On 18/09/2023 20:54, druck wrote:
>>> On 18/09/2023 09:29, Ian wrote:
>>>> If you log in as "root", or get a root shell by calling "sudo bash",
>>>> things work as expected:
>>>
>>> sudo -i
>>>
>>> is quicker to type.
>>>
>>> ---druck
>>>
>> su - is even quicker
>>
>
> 'su -' needs a password entered (on my system(s))

So should all other methods to aquire superuser privileges.

There seems to be around RaspiOS setups with one user
permitted in the /etc/sudoers without password.

--

-TV

.
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.szaf.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED.chiark.greenend.org.uk!not-for-mail
From: Theo <theom+news@chiark.greenend.org.uk>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: PCBs available
Date: 13 Oct 2023 10:18:40 +0100 (BST)
Organization: University of Cambridge, England
Message-ID: <yqC*ClKsz@news.chiark.greenend.org.uk>
References: <ug8lq4$2fkip$1@dont-email.me> <yqC*NXHsz@news.chiark.greenend.org.uk> <ugatpu$324nh$1@dont-email.me>
Injection-Info: chiark.greenend.org.uk; posting-host="chiark.greenend.org.uk:212.13.197.229";
logging-data="2979"; mail-complaints-to="abuse@chiark.greenend.org.uk"
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-22-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
Xref: rslight comp.sys.raspberry-pi:8020

Pancho <Pancho.Jones@proton.me> wrote:
> I assumed it was a standard board. A 5v/240v relay is a common
> requirement. I used a very similar board, before I switched to using
> Shelly/Sonoff type devices. It even had 4 relays, when I only wanted one.

Chinese relay boards aren't uncommon, eg:
https://www.ebay.co.uk/itm/262499095094

- on that one there are optocouplers between the inputs and the relay coils,
for some reason (maybe they were cheaper than transistors, or they really
don't trust the relays' isolation?)

The nice thing about TNP's board is there's a mains to 5V converter on
board, which means you can power the board from the mains that you're
switching. Otherwise you need to arrange for a separate DC power supply,
and that gets annoying in a tight space - with this board you don't need a
separate power supply for the Pi.

Theo
. Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ahem A Rivet's Shot <steveo@eircom.net>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Mystery - rpOS - Browsers Will NOT Display Web iframe Content
Date: Fri, 3 Nov 2023 14:44:45 +0000
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <20231103144445.e977934df49a1acf990c54a5@eircom.net>
References: <OFmdnRCCao67uKr4nZ2dnZfqnPadnZ2d@earthlink.com>
<slrnujfp7p.28o.jj@iridium.wf32df>
<5vWcncVhx55_8KX4nZ2dnZfqnPGdnZ2d@earthlink.com>
<uha9de$hv0v$1@dont-email.me>
<1l6dnS_Sdd5dLaX4nZ2dnZfqnPqdnZ2d@earthlink.com>
<uhailc$ke2o$1@dont-email.me>
<Y8C*L+Ktz@news.chiark.greenend.org.uk>
<uhbj92$tbnt$1@dont-email.me>
<iWSdnWf4XuDy2aL4nZ2dnZfqnPidnZ2d@earthlink.com>
<uhnpm5$cfbo$1@dont-email.me>
<uhvs99$24hec$1@dont-email.me>
<ui0ho8$29jjj$1@dont-email.me>
<468034896.720650318.256887.p.g.hardy-btinternet.com@news.individual.net>
<ui2hd0$2nrsp$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="3cf9b8feaf92607a1754b5ff1965fcde";
logging-data="2973949"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fb0BW1c4OuWkr3jEyR/0BFBhTnDuuyKw="
Cancel-Lock: sha1:91yHj+J4Mzg2hrtrtKcMU07BKCA=
X-Newsreader: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
X-Clacks-Overhead: "GNU Terry Pratchett"
Xref: rslight comp.sys.raspberry-pi:8020

On 8/7/23 9:55 AM, The Natural Philosopher wrote:
> On 07/08/2023 12:55, Jan Panteltje wrote:
>> No Empire Has Lasted Yet in history, US is way over the hill.
>> Likely Texas will soon leave that Union... the others will follow.
> Yes, these 19th century Empires are a bit passé..the end of Russian
> federation, the European Union, the United states - all are possible and
> more, or less likely as time moves on.
>
> In an unlikely turn of phrase, in rapidly changing world contexts, they
> are simply  too big to survive.
>
> What suits downtown New York does not suit wilderness Utah. And vice versa.
>
> federalisation at least and possible independence, whilst maintaining
> overall ties under some NATO and Interpol style pan national
> organisations would seem to be the way forward

First off, NO state will be leaving the USA - it's
actually illegal, they can and will send in the army.
Bet on it.

As for "differences" ... that was part of the whole
idea of a United STATES. Not every environment, every
local culture, every local need, is the same. Truly
"national" govts like to forget that - and it causes
BIG problems. Can even cause bloody revolutions where
everyone suffers horribly.

As for "empires" - there's a FALLACY to "empire" in
the usual meaning. They only survive by engulfing
more and more - and every bit they obtain soon
becomes a management EXPENSE. It's doomed. From
Sumer and Akkadia all the way to Rome and the
Mongols and Ottomans, this has been the horrible
horrible truth of "empires". They are about EGO,
not fiscal reality.

But then this was SUPPOSED to be about what to do
with /var/log :-)
. Path: i2pn2.org!i2pn.org!news.nntp4.net!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: comp.os.linux.misc,comp.sys.raspberry-pi
Subject: Re: Weird code crash
Date: Thu, 14 Sep 2023 09:23:01 +0100
Organization: terraraq NNTP server
Message-ID: <wwv8r99b1ui.fsf@LkoBDZeT.terraraq.uk>
References: <udu5c4$2gutd$1@dont-email.me>
<VGs*53kqz@news.chiark.greenend.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
logging-data="72477"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:mOnC6mbA9zk4vhGKsfxWiDRIXZ4=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
+r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Xref: rslight comp.os.linux.misc:12284 comp.sys.raspberry-pi:8028

Theo <theom+news@chiark.greenend.org.uk> writes:
> In comp.sys.raspberry-pi The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Sep 13 11:26:36 heating-controller systemd[1]: relayd.service: Main
>> process exit
>> ed, code=killed, status=6/ABRT
>> Sep 13 11:26:36 heating-controller systemd[1]: relayd.service: Failed
>> with resul
>> t 'signal'.
>> Sep 13 11:26:36 heating-controller systemd[1]: relayd.service: Consumed
>> 15.074s
>> CPU time.
>>
>> I rebooted it, and after awhile - about ten minutes, it happened again -
>> that is the above trace.
>>
>> I restarted it manually, and it hasn't crashed since.
>>
>> The web is flooded with instances of this messaqe all on different
>> platforms and applications, and it would appear this is a very generic
>> message possibly to do with memory issues.
>
> You're getting SIGABRT which is typically something bailing due to memory
> corruption, eg corrupting metadata so that malloc can't work, or a
> double-free.
>
> I would compile it with debugging enabled: '-g' or '-ggdb' flag to your
> compiler. Then run it under gdb:
>
> $ gdb ./myprog
> (gdb) run
>
> and see if it dies. If it does you can get a backtrace to indicate where
> the fault occurred:
>
> (gdb) bt
>
> It may be that starting it under systemd is different in some way that it
> doesn't show up when running it by hand. You could try setting as your
> systemd command:
>
> gdb -ex run -ex bt --args /usr/local/bin/myprog arg1 arg2
>
> which will run it and then dump a backtrace when it's finished. You may get
> 'no stack' if it succeeded and didn't record one.

Also:

* I would also have a look at the kernel log; if it’s a kernel-generated
signal then there’s usually a log message about it.

* Run the application under valgrind; depending what the issue is, that
will provide a backtrace and perhaps more detailed information. If it
is a memory corruption issue then it may identify where the corruption
happens, rather than the later point where malloc failed a consistency
check (or whatever it is).

Using valgrind (and/or compiler sanitizer features) is a good idea even
before running into trouble, really.

--
https://www.greenend.org.uk/rjk/
. Path: i2pn2.org!i2pn.org!news.hispagatos.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Limiting the capacity of SD cards for the pi
Date: Wed, 20 Sep 2023 17:44:29 +0100
Organization: A little, after lunch
Lines: 24
Message-ID: <uef7hd$314pj$1@dont-email.me>
References: <5ae53c469cbob@sick-of-spam.invalid> <650786bd@news.ausics.net>
<5ae5bad225bob@sick-of-spam.invalid> <6508d35c@news.ausics.net>
<uecvs7$2gotn$1@dont-email.me> <5ae6d95530bob@sick-of-spam.invalid>
<ueenp9$2u313$1@dont-email.me> <5ae6dcb9babob@sick-of-spam.invalid>
<ueespp$2v1m1$1@dont-email.me> <5ae6ec4278bob@sick-of-spam.invalid>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Sep 2023 16:44:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="054f6db54423c821ae90fded8316334d";
logging-data="3183411"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//x6NwhBCwuUAp9kYUhKAD1lV+dtRPrgU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
Cancel-Lock: sha1:IDopDliaQX4haQEUEmbzT4CvUUw=
Content-Language: en-GB
In-Reply-To: <5ae6ec4278bob@sick-of-spam.invalid>
Xref: rslight comp.sys.raspberry-pi:8028

On 20/09/2023 16:36, Bob Latham wrote:
> In article <ueespp$2v1m1$1@dont-email.me>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>
>> That's right. If you are sitting on the mounted mount point, it
>> cant get off! It will say 'busy'
>
> Right but that's not the reason the whole thing did nothing *after* I
> corrected that ????
>
> Bob.
>
I thought you said you unmounted it after that

--
Socialism is the philosophy of failure, the creed of ignorance and the
gospel of envy.

Its inherent virtue is the equal sharing of misery.

Winston Churchill

.
Path: i2pn2.org!i2pn.org!news.nntp4.net!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED.chiark.greenend.org.uk!not-for-mail
From: Theo <theom+news@chiark.greenend.org.uk>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: PCBs available
Date: 13 Oct 2023 15:09:41 +0100 (BST)
Organization: University of Cambridge, England
Message-ID: <zqC*PpLsz@news.chiark.greenend.org.uk>
References: <ug8lq4$2fkip$1@dont-email.me> <yqC*NXHsz@news.chiark.greenend.org.uk> <ugb97s$34vit$6@dont-email.me> <BqC*R2Ksz@news.chiark.greenend.org.uk> <kot0alF8laeU2@mid.individual.net>
Injection-Info: chiark.greenend.org.uk; posting-host="chiark.greenend.org.uk:212.13.197.229";
logging-data="28360"; mail-complaints-to="abuse@chiark.greenend.org.uk"
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-22-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
Xref: rslight comp.sys.raspberry-pi:8028

Andy Burns <usenet@andyburns.uk> wrote:
> Theo wrote:
>
> > It's a bit annoying... with no DC in the box and not wanting to risk
> > exporting mains to the Pi, or making another box with a relay, the
> > obvious option is an optocoupler, but you can't really ensure good
> > isolation unless you put it in a good enclosure, which is tricky here
> > because I'm shoving it in an existing mains box dangling on flying
> > leads. Aha, I thought, you can get optotriacs to switch AC, so what
> > about if I just get a phototriac and shine a light at it to trigger the
> > triac instead of having the LED in the optotriac. Trouble is,
> > phototriacs don't exist as a discrete component.
>
> Can't you "snap" one of these in half?
>
> <https://cpc.farnell.com/omron-electronic-components/ee-sx4070/opto-switch-slotted/dp/SC12350?>