On 2019-10-14, Folderol  wrote:
> On Mon, 14 Oct 2019 13:01:52 +0100
> Chris Elvidge  wrote:
>
>>On 14/10/2019 12:24, NY wrote:
>>> "druck"  wrote in message news:qno2oo$759$1@dont-email.me...
>>>
>>> On 09/10/2019 20:31, Dennis Lee Bieber wrote:
>>>> > I'd updated both 3B+, 4B2G, and 4B4G to the most recent Noobs
>>>> Raspbian > last week. Today I ran "sudo apt-get update/sudo apt-get
>>>> upgrade" on > systems (main item: an SSL update). While the second 3B+
>>>> was processing > the "upgrade" phase, I plugged in the 4B2G. I was
>>>> able to run the same > update/upgrade, shutdown, swap with the 4B4G,
>>>> update/upgrade (needed two > updates -- NTP had not synched the time
>>>> and it rejected a repository for
>>>
>>> The lack of a battery-backed (or even capacitor-backed) real-time clock
>>> is a nuisance if the Pi reboots and there isn't an internet connection
>>> by the time the Pi needs it - if it takes longer for the router to boot
>>> and establish a connection than it takes the Pi to boot. I run a
>>> weather-station recording package (Cumulus) on my Pi and occasionally
>>> after a power cut the Pi has booted up with the wrong time (eg 30 or so
>>> minutes in the past) so I've had readings every minute marked with the
>>> wrong time which leads to a graph that goes back in time (!) until NTP
>>> eventually syncs the Pi's clock (*). It happens so rarely that it's not
>>> worth devising my own external battery-backed RTC solution, but it's
>>> annoying when I have to go in and hand-modify the times in the log files
>>> and restart the software so it reads and displays them on its graphs.
>>
>>I have killed and disabled the systemd service fake-hwclock.service
>>(systemd does a load/force at startup, which can screw the time
>>abominably) and then do "fake-hwclock load" at reboot (in /etc/cron.d/)
>>and run "/sbin/fake-hwclock save" as a root cron job every minute.
>>
>>>
>>>> > being invalid [the R-Pi was using the last boot time, and the
>>>> repository > was dated five days in the future ]), and shutdown...
>>>> ALL BEFORE the > 3B+ finished its upgrade of the same files.
>>>> >
>>>> > Either that 3B+ has a very slow SD card, or a distinct speed
>>>> difference.
>>>
>>>> The Raspberry Pi 4's SD card reader is many times faster than on
>>>> previous models.
>>>
>>> Have you found that access to the system drive and swap area is affected
>>> by the slower SD access of the 3B+? I also use my 3B+ Pi as a PVR (a
>>> video recorder) and I was impressed that the software I use (TVHeadend)
>>> was able to write several overlapping programmes, including in HD, to
>>> the SD card without any apparent bottleneck. I only switched to
>>> recording to USB hard drive because I needed more space than on a 32 GB
>>> SD card.
>>>
>>>
>>> (*) Sometimes it has taken maybe 20-30 minutes before the timestamp of
>>> the weather readings is correct - I'm not sure whether it's NTP that is
>>> taking that long to set the system time correctly, or whether it's the
>>> weather-station software that isn't noticing that the system time has
>>> been corrected. Both times it's happened are when I haven't been around,
>>> so I've been able to look at the system time (eg using the date command)
>>> in the interim.
>>
>
> Just as a matter of interest, has anyone tried the devuan image for the Pi?
> If so, does this startup and run better or worse than systemD distros?

I have tried and used the Devuan image for the Pi.  It worked
well enough that I plan to use Devian on the Pi for anything that
is not focused on playing video in a web browser.  IIUC,
Raspbian's web browser is optimized better for playing video.

HTH

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

--- SoupGate-Win32 v1.05