Raspberry Pi 4 - fast enough for a desktop?

the problem I found is that I couldnt set the screen icon text to anything readable

but otherwise that is what I did that wasn't TOO bad

YMMV, but I use 40" 4K TVs and monitors like this all day and find the pixel density at 100% scaling about right (Linux and macOS, not sure how Windows is). You can't necessarily focus on all of the screen at once, but often there are things going on (like a compile I'm keeping an eye on, or a web page that I'm comparing to some other thing, or an enormous GUI in some CAD package) that use different parts of the screen at different times.

If you run one app maximised the whole time, and especially a text editor, I can see that would be less than comfortable. For instance, I'm writing this in the middle of a 40" screen and the 80 text columns are 14cm wide and the window is 27cm tall. Meanwhile I'm watching a compile, and have a web browser, some PDFs and a CAD package on screen at the same time.

I recently added a high DPI mouse as well, which makes pointing at things across 4K a lot more pleasant.

Theo

Yes, very promising too.

tests suggest the new Pi will be, perhaps not better but certainly in the same class although I'm waiting for 3rd party software to be recompiled to be certain - I looked at the dependency lists and decided to leave it to those who know what they're doing.

Definitely: looking at the specs a safe shutdown rather than full ups could be covered by a simple usb portable powerbank.

If you read the small print in the licencing document that came with your Pi you will see that licences were granted for 1, 2, 4 AND 8 GB versions.

Cheerio,

Micron, vendors of the DRAM chip on the Pi 4, go up to 32Gbit (=4GByte) LPDDR4 chips.

So an 8GB version would need them to release a higher density DRAM chip ($$$) or a board respin to take a second chip, assuming the BCM2711 supports that.

Ah yes:

Theo

I am not sure how a USB powerbank would tell the Pi to shut down.

I have a Pico UPS on a Pi 2. It has what it calls FSSD - file-safe shutdown. Whether it is 'switched off' or the battery runs low it will invoke demons to shut the system down in an orderly way.

A small, non-backed-up 5v wall wart will provide a logic level that goes low whenever mains power fails. Two resistors will convert it to a 3.3v logic level.

Good idea. I'd probably make those resistors fairly low value, otherwise the output capacitor may hold charge as long as it can sustain the leakage on the Pi's GPIO (very long) before the voltage drops enough to signal the failure.

However it won't tell you if the power bank is getting low - eg if the power came back after an outage (so the power bank is near empty) and then goes out again.

Theo

It seems to me that the tool for this would be a small in-line power bank: inputs (from mains or main battery bank or whatever) across a medium chunky capacitor, with a signalling line on the outside isolated from the cap, so that when the input voltage drops it can send a shutdown and power the Pi off the capacitor for those few seconds.

(Actual circuit design is left to someone who knows what they're doing.)

Agreed. A total resistance of 1K (5mA) ought to be fine, since a couple second delay is appropriate.

True, but battery run time should be at least several minutes and shutdown time several seconds, so this is certainly a second-order effect, down by a couple orders of magnitude.

On Sat, 29 Jun 2019 01:42:01 -0700 (PDT), James Harris declaimed the following:

Not the most useful observation, but...

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

---druck

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.

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.

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.

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?

There are a number of RTC modules for the Raspberry Pi, which are ideal for what you are doing.

While you've got one of those on order, it is possible to configure NTP to poll far quicker. See man ntp.conf minpoll and maxpoll.

---druck

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