I know there was recently thrown around the idea of printing up custom Haiku USB keys…again.
The 32GB USB drives only cost about a $1-2 more at any quantity than 2GB drives… how about using those and perhaps even bundling most of the packages in HaikuDepot with the drive? Also 2GB drives will almost certainly be slower and lower quality. Apparently you have to image the drives yourself so… you’d probably just want to plug a bunch in a hub and write a script to DD, verify then move to the next drive. It’s a lot easier to convince someone to buy a 32GB drive for $15 than a $2GB one for $8 just to cover costs and no profit to Haiku.
Also shouldn’t it be possible to build a combined 32/64 bit USB image perhaps EFI/BIOS selection? Perhaps 3 partitions Haiku 32bit , 64bit and a repo partition etc…?
Probably about 3.5min per GB to image USB 2 drives assuming 5MB/s (par for the course for cheap USB drives, could much faster though)… approx 115min to Image 32GB.
13 port hub is $20 And would keep a USB port busy for an entire day unattended.
With some programming to detect each freshly plugged in drive and queue it for imaging … you could potentially write over 65+ drives a day with 5 hubs. Without too much boring work.
If that is too time consuming perhaps an option to mirror the entirety of HaikuDepot repos to the drive, after booting up so you can use it offline?
Charge $20 for each drive and it would put nearly 1300 in haiku’s coffers for the first 100 sold and about 1400 after that. The problem though would be labeling and mailing them all… I did a quick check and charging $15 Haiku would only make about $5.50 per drive on Amazon and about $8.5 if someone did the fulfillment in house assuming a buck per drive to ship if sold at $15 a bit more at $20. Perhaps even charge more $40 perhaps since it’s a lot of software… and so as to make it worthwhile for whoever is doing it?
Hope you haven’t forgot about the USB2/3 throughput. The bandwidth will be divided between the devices, so the copy process could be much longer.
AFAIK the boot loader prepares some data for the kernel, so i assume a 32 bit boot loader cannot boot 64 bit Haiku, and vice-versa. 64 bit image could be UEFI+MBR compatible, i think, but the UEFI loader didn’t complete yet, and maybe it won’t be ready for the prime time at the release of R1B1.
Oh, and i wouldn’t make any assumption about the USB key quality.
It depends on the computer, but for one hub I was assuming the throughput of one port and only copying to one drive at a time… I don’t really trust USB enough to copy multiple drives reliablyto begin with. Totally a valid point though. So you may only be able to do 10+ a day depending on copy speed.
The host controller even on 2.0 should have 60MB/s aggregate… across the ports although YMMV.
Well the 32bit bootloader should work everywhere (presumably)… and it could chainload the 64bit one perhaps?
Wh…at?! It only takes a couple of minutes to write a Haiku ISO on a USB3 stick. That’s the least amount of time required to handle everything in an order: printing the label with the buyer’s address, sticking the stamp on the envelope then put the USB drive inside, then take it to a post office or a shipping company, then notify the customer it’s been done.
Sure, it’s definitely a cool idea to write a daemon to look to USB devices in the hub’s ports, check if the USB drive is empty, write and check the image then notify when it’s done, but again, writing a USB drive takes so little time that it would be done before you handle the rest of the required things for that order.
What would be really cool and geeky, not to mention professional, would be to be able to pass a certain parameter (e.g. bootcheck=usb_port_x) to the boot loader, using QEMU, so that a special program in Haiku can report the successful boot to a networked PC.
Regarding 2 GB versus 32 GB, keep in mind that people using Haiku to revive old hardware may run into a 2 GB BIOS limit on USB booting: some will accept a <2 GB partition, but some won’t accept a device with a total reported capacity greater than 2 GB.
Some wording to this effect should be sufficient though, and people needing the smaller size could be suggested to burn their own.
I really think no one in the right mind would seriously try Haiku on a 386/486. And my old 586 PC had a HDD 2.1GB in size, and that wasn’t the maximum supported by the BIOS, but back then we didn’t even have USB.
On my Celeron 300MHz PC I didn’t have USB, and it wasn’t a big deal back then, but I later added a PCI adapter just for kicks. And I used a 20GB HDD inside it, so the BIOS was well equipped for that. However, in that day and age there was no USB boot. However, the maximum amount of RAM on that motherboard was 384MB RAM (3x128), which is really insufficient for anything productive these days.
In my Pentium 4 PC I have 1GB RAM, which is still not enough to do significant work nowadays, but it obviously has support for USB booting, HDDs over 100GB and stuff like that. But as a single-core machine, it’s really unfit for a modern multi-tasking, multi-threaded OS and apps.
My 9-year-old Core 2 Duo laptop with 4GB RAM and a Samsung 850 Pro SSD does very well with Haiku. The only problem is the graphics card support (ATI Radeon 4300), but whatever… the point is any PC sufficiently modern to boot from USB is good enough to handle USB drives even bigger than 32 GB, no problem. I used a 256 GB USB3 stick and a 2TB USB HDD with that old laptop and both worked just fine.
I have, among other things, an AMD Phenom II x4 965 @ 3.1 GHz………running on a board that has a 2 GB USB boot limit, but no such ancient limit for hard disc booting. This one also will not boot from either a Corsair USB 3 or a no-name USB 3 from MicroCenter: «No system disk», or similar message.
My comment war meant to refer only to USB booting BIOS limits. I have observed both of the types of limit which I mentioned, though I have only one such sideways BIOS myself.
Also a Vaio B100B laptop with a single-core Celeron-something that has zero BIOS ability to boot USB (instead, I put Plop Boot Manager on hard disc and it can chainload either USB or other options). I think this one can then boot at least 4 GB USB…but the interface is 1.1 so takes a long time. Better to use CD-R! (-:
Of course, I burn my own USB or CD-R, so I think this is not for myself.
Is this a partition size limitation or an oh I see a device that is too large and die issue? Theoretically the 2 Haiku USB boot partitions would be within 2GB easily… that’s why I suggested a separate partition for the packages.
My sparcstations for instance will read as big a disk as you can throw on the scsi bus… however won’t boot from more than 1-4GB depending on the model (/boot/ always has to be less than 4GB on 64bit, 2GB on sun4m and 1GB on sun4c otherwise the blocks of the files could be outside ther range it can see).
Well that’s assuming you are burning the USB’s from *nix… Haiku’s USB3 support isn’t up to snuff as I understand it. Also I was refering to the time it would take to copy 2+ haiku images + the entire haikuports repo or as much of it as could fit in 32GB.
Also these drives are probably USB 2.0 a USB 3 hub could probably handle writing them all at once though…
The reason I mention scripting it… is because you can set it and forget it and come back later and it’s done and tested. If you have to stand there and watch it even with faster USB 3 imaging it’s more burdensome.
It only takes a couple of minutes to write a Haiku ISO on a USB3 stick. That’s the least amount of time required to handle everything in an order: printing the label with the buyer’s address, sticking the stamp on the envelope then put the USB drive inside, then take it to a post office or a shipping company, then notify the customer it’s been done.
):
However, the maximum amount of RAM on that motherboard was 384MB RAM (3x128), which is really insufficient for anything productive these days.
I used a 256 GB USB3 stick and a 2TB USB HDD with that old laptop and both worked just fine.