Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Remko van der Vossen (wich AT stack.nl) wrote [08.07.19 07:39]:
> > 
> > IANAL :-D. I'll be glad to assume you are one and update it accordingly
> > though ;-)
> 
> This has not really anything to do with IANAL, anything a person or
> group produces has copyright, but in some nations you have to claim the
> copyright by adding a copyright notice like this.
I was referring more to how the copyright years can or cannot be
extended. I know what copyright is, but I don't know if copyright claims
can arbitrarily be updated/extended. It's not my area. Hence, IANAL :).
(P.S., AFAIK the Berne convention made the requirement for *stating*
copyright unnecessary for actually having copyright, though I could be
wrong)

> > > Defautl fstab could contains also "usbfs /proc/bus/usb".
> > 
> > Perhaps commented out would be better? Also, I'm not sure how many users
> > will want/need this of users who wouldn't know to add it on their own (I
> > suspect most people who would actually get use out of it know enough to
> > add it, though of course I could be wrong).
> 
> We've had the issue of what to put and what not to put into fstab
> before. I think it would be a good idea to include a smgl dir in
> /usr/share/doc with various example configuration files like fstab and
> some documentation how to use SMGL, perhaps simply some html dumps of
> the wiki. Then simply refer to the example in a comment in /etc/fstab.
> That would satisfy the needs for those wo want examples without
> cluttering the config file itself or the /etc directory as some have
> observed.
There have been several ideas kicked around about how this sort of
problem should be handled, but no agreement has been reached yet as to
the best solution. IMHO, the best solution would actually be to have a
spell for the documentation/examples, so that the user could easily cast
or dispel all of the example files. Also, it would fit into a nice
bundle (smgl-example-confs or somesuch).

> How about using sync instead of umount? Then everything is definately 
> written to
> disk and no mounts will be forgotten and you don't have the problem of
> unmountable filesystems which you'd have when using umount -a...
This is an idea I will have to look into. We (the cauldron people) have
also kicked around ideas about modifying the shutdown procedure itself,
and making it able to simply switch directly into the installed system
(pivot_root or switch_root) rather than even requiring a reboot. Either
way, this is probably something for future development, rather than
immediate. We'll see.

> I consider it a good thing to simply have a tarball of the whole system,
> as I have said above I prefer to simply have a shell and a tarball
> nothing else.
There are pros and cons to both approaches. Having a single tarball is
simpler to manage and install from (just one tar command to install the
system). However, it doesn't allow for optional spells (which means that
every install must include stuff that the user might not want, and might
be missing things the user does want), and it also requires duplication
of binaries between the ISO and the tarball, increasing the size of the
ISO. Having sets of tarballs will allow us to have optional spells and
to reduce redundancy between the ISO and tarballs, saving space, but
will complicate the install procedure a little. However, in accordance
with our philosophy, we really have to go with sets of tarballs,
otherwise we aren't in agreement with "what the user wants, and only
what the user wants".

> Hmmn, that is quite annoying. I personally don't like initrd and those
> kind of things, if I can do without I'd prefer it. So for me I'd find it
> quite annoying if the installer would install an initrd by default. I'd
> rather just use a chroot tarball if there was an initrd installed by the
> installer.
I agree, except in the cases that the ISO doesn't boot for people. The
previous devel ISO didn't need an initrd, but wouldn't boot properly on
(at least some) SATA hardware, due to different kernel drivers
clobbering each other. If I can find a way to support all the hardware
and avoid using an initrd then I will do that. If I can't, and I have to
choose between the "annoyance" of an initrd, and the failure of not
booting, I will go with having an initrd to help boot the kernel. Right
now I am still trying to find the best balance. I will experiment with
the kernel configuration a little more, and hopefully the next release
will fix these problems without needing an initrd, but if it needs one
then so be it.

-- 
Justin "flux" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgphzJLC0nf0M.pgp
Description: PGP signature