Limiting the capacity of SD cards for the pi

The Heinlein novel "Starman Jones" had a character who mixed metaphors with great aplomb. I remember sayings like "Let sleeping dogs bury their own dead," and "Let's strike while the iron is in the fire and let the bridges fall where they may!"

Speaking of IBM ancestry, that sounds a bit like the IBM utility DEBE (Does Everything But Eat), which let you do a lot of the same things from a mainframe console. I ported a version of it to a couple of Univac mainframes. Lots of fun.

:-)

Still, if you'd really like a written reference, it's hard to go wrong with Beej's Guide to Network Programming

Nice man pages (e.g. rsync) contain a section labeled "EXAMPLES". Too bad they're few and far between.

The sneaking suspicion I have had all my life since I first enocountered it, that BSD 'sockets' were a truly awful way to interact with a network device was borne out in my attempts to get networking working on the PICO with the LWIP library. Badly documented it may have been, but the overall ideas were a lot easier to get to grips with.

Look into System V streams if you want to see a truly awful way to interact with a network device.

I did, once. :-)

sudo -i

is quicker to type.

---druck

I had the misfortune of using it as transport for an early fault tolerant distributed database application. It was interesting.

dd is basically the standard image file (etc.) reader/writer program on Linux. I thought you might have been using it already, but since reading more posts I see you were doing everything from Windows. TNF has already described dd and /dev/zero in ample detail.

The aim is just to create an empty file which some Linux programs can then use pretending that it's a physical drive, then when everything's set up that file's contents can be copied over to a physical drive. The complicated part is really in copying the system files into the empty image file first. Resizing partitions would be easier for you.

Resizing the last parition isn't difficult in a program like GParted (which will need to run on Linux). What might be confusing then is that your disk imager program will probably still create an image file that's too big to fit on smaller SD cards. The image _can_ still work on smaller cards because the data in the unpartitioned section at the end of the image file is now ignored in use anyway, but you'll have to convince your image file writer program to just write as much data as will fit. That might be easy or it might be impossible, depending on the program.

The last time I used image file writers on Windows was for floppy disk images, so I'm not sure whether modern ones are suitable for this. With dd you can use the "bs" and "count" options to stop it reading/writing data from/to the image file at the end of the last partition (if you get your maths right to work out where that is in bytes and divide that by the "bs" value in bytes to use for the "count" value - this is one of dd's less convenient aspects).

Wow, I gave up on CUPS a few years ago when they changed things and I couldn't find any documentation on the web to explain how to make it work the way I had it before. Now I'm using lprng, which is also faster, although I'll admit that I'd have to check the docs again to remember how to set up a new printer.

Maybe it's all a secret effort to bring about the paperless society by force? :)

su - is even quicker

Yes, windows to you but I'm in the Black Country so it's Winders around here. :-)

Thanks for the useful and educational post.

Cheers,

Bob.

Oh well in that case just give the pi an 'ecky thump' and it will behave

:-)

I though that expression was Yorkshire is that where you are?

Bob.

Nay lad, Oi be in Safferk, innit? Land of Queen Boudicca, et al...

Bostin! (ex-Mancunian, now living in Wolverhampton).

'su -' needs a password entered (on my system(s))

so does sudo...on mine