[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 19/01/12 19:00, Gordon Henderson wrote: > > My experience over the years is that most people can not, and do not > want to do a Windows/Linux/OSX install from scratch. They just don't > care. They want to turn a computer on and have it "just work". Well, sure, but I thought we were talking in the context of installs on a Raspberry Pi board - if you're buying one for yourself, you better know how to be able to install linux yourself because you are REALLY not the target audience otherwise. Of course for the main intended audience (kids in school) then having a preinstalled SD card available would be really handy otherwise the poor kids will spend more time trying to figure out installation instead of actually learning programming or whatever on them. But even then, their teacher bloody better well know how to prep an image and have it ready to deploy or they are one seriously poor IT teacher. > >> And to respond to Gordon, yeah, the bootloader is cooked into the SoC >> firmware blob unfortunately > > I don't see why that's unfortunate. If it can boot off LAN, USB and > SDCARD then it's no differnt from an x86 PC BIOS. Well, actually it's completely different - it provides very similar functionality admittedly (from the pragmatist viewpoint that is all that counts as well) but the BIOS is generally very well understood and potentially even re-flashable with 3rd party tools such as coreboot, etc. That is not the case with the entirely closed, undocumented proprietary blob sat on the Broadcom SoC. As I said, see senior kernel dev Alan Cox's misgivings on this exact subject. > >> (see the Raspberry Pi mailing lists for >> linux guru Alan Cox not being exactly thrilled about this) > > I'm not on their mailing lists and there appears to be are no publicly > accessable archives.... A lot of it is reproduced in the forums: google to the rescue! http://www.raspberrypi.org/forum/projects-and-collaboration-general/lack-of-broadcom-documentation?value=alan%20cox&type=1&include=1&search=1&ret=all >> but it won't >> have much effect on end users as your imagined scenario of booting the >> ARM netinst image and going from there is exactly what I plan to be >> doing when mine arrives. > > So that's fine then. Do you have a link to somewhere that gives > details on the boot? Just search through the forums as above, there's plenty of stuff there already. Annoyingly, things aren't quite as clean as just do PXE and walk away, again thanks to the stupid Broadcom GPU bootloader code. PXE is x86/64 only just for a start and the GPU needs to bootstrap code from an SD card just to initialize itself (duh) but once you're there, it should be easily possible to boot a custom setup and use uboot/nfsroot-enabled-kernel-and-pivot/whatever to get some more flexibility. In my predicted usage model, having to constantly change stuff on the SD card is going to get old real quick - I'll be setting it to netboot ASAP and will then be feeding it multiple images/distros/experiments from a server. Being spoilt with ZFS+iSCSI has made me come to hate local storage full stop these days - everything should be on a snapshotting, copy on write backend (except laptops, obviously!). > And I wish they'd fix their website it's f'ing slow in firefox - I can > launch chrome and open up their FAQ page before firefox even renders > it )-: > > Gordon > Hmm, you're not wrong actually - I'd not noticed before as I'd rather just give away my life history on facebook that willingly use the walking privacy violation that is chrome but taking a moment to test it, you're right. It is slower than firefox. No idea what's going on there chief. Should point out that I'm not using the standard versions of either though and have javascript blocking enabled in both (and my dev version of firefox is only a tiny bit slower at that): Google Chrome 18.0.1010.0 Mozilla Firefox 12.0a1 On a related note, I highly recommend that anyone vaguely proficient who isn't scared of compiling should be building the firefox nightlies themselves - I've been using them on multiple distros (several Linux and Mac OS) for months and they're much better, much faster and more stable. Add-ons don't break with nightly-testing-tools installed either: I literally haven't had a single failure using nightlies yet, and I hammer firefox mercilessly all day every day, frequently with 30+ tabs. Awesome stuff from Mozilla, I don't know why the slashdot retards and their ilk complain about firefox so much recently... Cheers, Mat -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq