On 15 Oct 2019 03:41:09 GMT
Robert Riches  wrote:

>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
>

Just done the same myself. It works considerably better than Raspbian for my
purposes :)

--
W J G

--- SoupGate-Win32 v1.05