Binary images - Githubissues

ghost commented 6 years ago

I think you need to compile new system images.

michaelforney commented 6 years ago

Yep, I've been meaning to do that for a while. Thanks for the reminder!

ghost commented 5 years ago

So?

michaelforney commented 5 years ago

What types of binary images are you in? I can think of several that might be interesting:

Bootable QEMU image (like the old oasis-20170211.qcow2)
tar archive of binaries and /etc (like the old oasis-20170211.tar.xz)
git repository of binaries for easier/quicker install than from source
Bootable TinyEMU config files, to boot locally or over HTTP (I've been experimenting a bit with temu https://mforney.org/virt/oasis-x86_64/temu.cfg and https://bellard.org/jslinux/vm.html?cpu=riscv32&url=https://mforney.org/virt/oasis-riscv32-sf/temu.cfg).

In each case, there is a question of which sets should I include? I can see a case for minimal images containing just the essentials for basic text-only usage, desktop-oriented images with velox, netsurf, etc, or just including every package.

In any case, I'm hoping to get binaries created automatically on push, since I already have travis building everything anyway.

ghost commented 5 years ago

I'd like to use Oasis on real hardware rather than Qemu. It would be nice to have a .fs image for x86 and x86_64. Maybe with a minimal set (text-only) and a complete one

Jan69 commented 3 years ago

so, how's the progress with premade images? been a few years... ;) when possible, it'd be great if there would be at least a chroot-able filesystem of Oasis available that can compile another Oasis, for example, the old image's Ninja is too old, so it can't build new Oasis...

bootable images would be extra nice extras, be they virtual or physical-bootable, as long as they can bootstrap another instance, it doesn't matter that much which package set there is exactly.

oasislinux / oasis

Binary images #8