SDCard -- install here and deploy there?

Do not use that, it loads beta firmware. "sudo apt update && sudo apt -y full-upgrade" gets generally released firmware (and all the other updates).

Vict-what? -- Victim?

At work I use to boot my machines only every few months and some even once per year. For headless servers this is sufficient. But these have typically 16 GB of RAM or even more.

We are talking about a "Raspberry A" with 256 MB (MegaByte). Under load this amount will be eaten up soon. That was one of the reasons for inventing repeated reboots. On more sophisticated RPIs with 1 GB this is not necessary of course.

Markus

??? WTF ???

Good grief...

Reboots to cure memory leaks ? IOW reboots as a workaround for bad programming! That has never been acceptable in my book since times when

I ran a 256Mb Rpi for a long time as router, DNS, DHCP, VPN and asterisk server, it never needed regular reboots. These days I need more CPU and better networking in the router (gigabit PPPoE takes a fairly fast processor).

Yeah, back in the real world it's an optimisation problem. Is it more efficient to reboot a server or invest time debugging leaky code. Time is money.

But seeing that the code is leaky is dead simple: just run top and look at the display every so often.

Out here in my bit of the real world if we create a service that we can't stop leaking then we arrange to restart the *service* periodically because our customers look on unexpected reboots with great disfavour. They like their expensive servers to be serving not rebooting.

NOOBS is a system to not be touched by man or beast.

It spoiled perfectly good cards by turning on the irreversible write protect bit in the SD controller on the card. The card someway works, but the partitioning cannot be rectified.

On a normal Raspbian card, gparted works fine, but of course, it has to be run on a Linux machine separate from the target Pi. I used Ubuntu 20.04LTS on a VMware virtual guest.

Very good point

No doubt. However many customers like cheap code delivered fast.

I have tended to work on projects where rapid development time was crucial and once developed it was often cheaper to throw hardware at problems, rather than developer time.

Yes, it is often dead simple to see that code doesn't work, however fixing it....

I this type of thinking is precisely why there is so much bad code with security vulnerabilities in the wild.

If you cant afford to do it right how on earth can you afford the losses from a data breach?

Yes, seeing that a bit of code doesn't work is simple, but realising that it might be a memory leak, not so much unless its Java, when you get told in no uncertain terms what happened if your program hit the size limit on the JVM's memory allocation pool.

I'm always surprised by the number of people don't know that 'top' exists, let alone understand what it can show you.

Data Breach? pah!, peanuts. I could show you how to write code to really lose money.

In the 1990s, one of our UNIX servers (hostname "ozz" - yes, someone couldn't spell: I know the Wizard was from Oz) was a real pig to get all the processes running after a reboot - it required a lot of black-art tinkering by one of the UNIX gurus. Consequently it was never restarted Fortunately it never need kernel rebuilds for incorporating new device drivers. Surprisingly, in view of its kittle and vulnerable state, it wasn't connected to a UPS. One day there was a fairly dramatic power cut, when a JCB working nearby put its jib through a high-voltage cable (*). Whereas everyone else went to investigate the loud explosion, the brilliant flash and the cloud of black smoke, ozz's "handler" went into paroxysms of despair at the amount of time he was going to waste getting it going again when the power eventually came back.

(*) The JCB partially melted. The driver was less lucky.

I can remember when I bought my first computer, in 1981, a CPM/3-based "Wren" (*). I decided that I could just about afford the RAM upgrade from 16 KB to 256 KB, but I couldn't justify or afford the disk upgrade from 2 floppies to 1 floppy and a 5 MB hard disk.

My first IBM-compatible PC, based on an 8086, came with a 20 MB HDD. It ran MS-DOS fine, but it wasn't up to running Windows 1 - and I used up most of the HDD even installing it from the multitude of diskettes that I borrowed from work to try it out of curiosity.

(*) I remember it was the first time I'd even driven in London, in the car that I'd bought a few weeks earlier after passing my test - navigating along the A40, Marylebone Road/Euston Road, Gray's Inn Road to Theobalds Road where the shop was. I even managed to find my way back home again ;-) The Wren still worked until I last tried it a few years ago, when I found that the PSU (a very obsolete design) had finally packed up.

A bit later than 1981 I think - CP/M 3 didn't come out until 1983 CPN for the Torch (1982) was based on CP/M 2.2, I'd have just ported CP/M 3 if it had been available.

Certainly was !

I first learned to program in Algol 60 on an Elliott 503 with 8 Kwords (39 bit words) with input on paper tape and output on a lineprinter.

Then learned assembler on an ICL 1901 with 4KWords of 24 bit memory, card input, compiler loaded from magnetic tape and output on a lineprinter.

My first home machine was as a 48KB system with an MC6809 running FLEX-09 from two floppies. Input from keyboard, output to an Epson dot matrix printer (remember them?).

At work I was programming an ICL 2966 mainframe running 12 online database systems, for a few hundred uses, written in COBOL and on 16MB RAM. with a roomful of 400MB, washing machine sized disk drives. (you can go see one at TNMOC at Bletchley Park).

Mutter..mutter - tell that the the kidz of today and they won't believe you...

Now a Lenovo T440 laptop with 8GB RAM and 500 GB disk, running Linux, with Internet connections and a laser printer does everything I need and is fast enough to avoid waiting except for system updates.