Renaming Boot Directories

[pikpik]

Hi,

I'd like to make the names of the boot directories in MINIX easier to
type (at the boot prompt, for example) and clearer about what they're
for. Currently, the boot directories are as follows:

/boot/minix: versions of bootable parts

/boot/minix_default: the original parts from installation

/boot/minix_latest: the latest parts, whether they're the installation
ones or updated ones

First, I'd like to remove the "minix_" prefix from the "default" and
"latest" directories. I think it's currently redundant and that
removing it would make things shorter and easier to type.

Second, I think "default" is misleading. Its name seems to imply that
it's what starts normally. But it isn't; that's what "latest" does.
I'd like to rename this to something else.

Possible options include: original, old, obsolete,
probably_nolongerworking, release, install, generic, and vanilla. I
prefer "old" or "original," but "install," "release," and "generic"
describe the fact that it came from the installer.

In summary, I'd like to make the boot directories look like this:

/boot/minix: contains bootable parts

/boot/{old, original, install, generic, release}: contains bootable
parts from the initial installation

/boot/latest: contains the initial or updated parts, whichever's more
recent

Should the current situation be changed? What would you like?

Thank you,
pikpik

[Antoine LECA]

pikpik wrote:
> /boot/minix: versions of bootable parts

BTW, previously there were at most 4 versions there; nowadays only 3 are
kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
command ls -t "$base_dir" lists the new .temp/ directory as well, so is
offset by one (the . is ignored since it is run by root); as a result
adding the option |4 to the "not much here" case would make sense IMHO.
Of course the $3 below has to be adjusted to $4 as well.

> /boot/minix_default: the original parts from installation

Well, you are free to move there any "stable" version; this is
particularly important to do when some milestones (the ones usually
documented in docs/UPDATING) are crossed, since more often than not it
is not possible to step back (easily) to those versions.

The same remark is valid as well for the most ancient version kept in
boot/minix/* directory (which could have its own symlink the same way as
boot_minix_latest does).

> /boot/minix_latest: the latest parts, whether they're the installation
> ones or updated ones

<...>

> Second, I think "default" is misleading. Its name seems to imply that
> it's what starts normally. But it isn't; that's what "latest" does.
> I'd like to rename this to something else.
>
> Possible options include: original, old, obsolete,
> probably_nolongerworking, release, install, generic, and vanilla.

I thought about "stable"; but "release" or "install" seems just as good


Antoine

[pikpik]

Hi Antoine,

I hope you are doing well.

On Friday, July 27, 2012 1:24:23 PM UTC-4, AntoineLeca wrote:

pikpik wrote:
> /boot/minix: versions of bootable parts

BTW, previously there were at most 4 versions there; nowadays only 3 are
kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
command ls -t "$base_dir" lists the new .temp/ directory as well, so is
offset by one (the . is ignored since it is run by root); as a result
adding the option |4 to the "not much here" case would make sense IMHO.
Of course the $3 below has to be adjusted to $4 as well.

Ok. I had not thought much about this. Would you really prefer having four versions available?
 

> /boot/minix_default: the original parts from installation

Well, you are free to move there any "stable" version; this is
particularly important to do when some milestones (the ones usually
documented in docs/UPDATING) are crossed, since more often than not it
is not possible to step back (easily) to those versions.

The same remark is valid as well for the most ancient version kept in
boot/minix/* directory (which could have its own symlink the same way as
boot_minix_latest does).

Oh, sorry. I think I was too vague about this. I don't wish to change behavior, but I do want to change the names.

 

> /boot/minix_latest: the latest parts, whether they're the installation
> ones or updated ones
<...>
> Second, I think "default" is misleading. Its name seems to imply that
> it's what starts normally. But it isn't; that's what "latest" does.
> I'd like to rename this to something else.
>
> Possible options include: original, old, obsolete,
> probably_nolongerworking, release, install, generic, and vanilla.

I thought about "stable"; but "release" or "install" seems just as good

Ok. That sounds good. Do you think "default" is ambiguous? I'm having second thoughts about changing it, but I still think it's confusing.

In summary, here are the changes I see:

- Show the 4 most recent boot versions

- Rename "minix_default" to: minix_stable, minix_release, or minix_install

Also, what do you think of this?

- Remove the "minix_" prefix

Thank you,
pikpik

[Antoine LECA]

pikpik wrote:
> I hope you are doing well.

Yes, thanks.

> On Friday, July 27, 2012 1:24:23 PM UTC-4, AntoineLeca wrote:
>>
>> pikpik wrote:
>>> /boot/minix: versions of bootable parts
>>
>> BTW, previously there were at most 4 versions there; nowadays only 3 are
>> kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
>> command ls -t "$base_dir" lists the new .temp/ directory as well, so is
>> offset by one (the . is ignored since it is run by root); as a result
>> adding the option |4 to the "not much here" case would make sense IMHO.
>> Of course the $3 below has to be adjusted to $4 as well.

BTW, using shift or even better
[ $1 != ".temp" ] || shift
would achieve the same effect, perhaps in a more obscure way.

> Ok. I had not thought much about this. Would you really prefer having four
> versions available?

Often I figure the last version is obviously incorrect, then I quickly
enter the source tree, fix the bug, quickly recompile and restart.
This works fine with the present system as well, of course.

Now, sometimes I am too quick, and the fix is incorrect. Or I forgot
something obvious just before the make hdboot (or whatever it is called
these days); with the ancient system, I was still able to get back at
the N-2 version; in fact when I figure it out, I then erase the N and
N-1 versions which are known wrong, and I can continue working.

With the new system however, the N-2 version is not any more there :-(
Of course the clear way to go is to clean up immediately any version
which is known to not working, and I finally learned to go that way; but
even then I accidentally erased the N-1 variant more than once; so I
found out that change to be a great help to me.

Since it looks like I am alone pushing it however, I guess I am not the
typical developer, and perhaps it is better to not make any such change
to the source tree.

> Do you think "default" is ambiguous?

Yes definitively, and as you point out it does not carry the meaning of
the obvious behaviour.


Antoine

[pikpik]

Hi Antoine,

On Tuesday, July 31, 2012 4:31:08 AM UTC-4, AntoineLeca wrote:

> On Friday, July 27, 2012 1:24:23 PM UTC-4, AntoineLeca wrote:
>>
>> pikpik wrote:
>>> /boot/minix: versions of bootable parts
>>
>> BTW, previously there were at most 4 versions there; nowadays only 3 are
>> kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
>> command ls -t "$base_dir" lists the new .temp/ directory as well, so is
>> offset by one (the . is ignored since it is run by root); as a result
>> adding the option |4 to the "not much here" case would make sense IMHO.
>> Of course the $3 below has to be adjusted to $4 as well.

BTW, using shift or even better
        [ $1 != ".temp" ] || shift
would achieve the same effect, perhaps in a more obscure way.

So, that simply removes the last one? If so, then I'm not sure. It seems like if you had one existing version, then the new one would be added, the old one would be "shifted" out, and you'd be left with only one. Is this correct? 

 

> Ok. I had not thought much about this. Would you really prefer having four
> versions available?

Often I figure the last version is obviously incorrect, then I quickly
enter the source tree, fix the bug, quickly recompile and restart.
This works fine with the present system as well, of course.

Now, sometimes I am too quick, and the fix is incorrect. Or I forgot
something obvious just before the make hdboot (or whatever it is called
these days); with the ancient system, I was still able to get back at
the N-2 version; in fact when I figure it out, I then erase the N and
N-1 versions which are known wrong, and I can continue working.

With the new system however, the N-2 version is not any more there :-(
Of course the clear way to go is to clean up immediately any version
which is known to not working, and I finally learned to go that way; but
even then I accidentally erased the N-1 variant more than once; so I
found out that change to be a great help to me.

Since it looks like I am alone pushing it however, I guess I am not the
typical developer, and perhaps it is better to not make any such change
to the source tree.

Ah. This makes sense then. I think if the MINIX team agrees, then it is very worthwhile.

Perhaps it is wasteful of space? Nonetheless, I think this function should be designed developers (especially like you) in mind. 

 

> Do you think "default" is ambiguous?

Yes definitively, and as you point out it does not carry the meaning of
the obvious behaviour.

Ok, thanks.

[Antoine LECA]

pikpik wrote:
> On Tuesday, July 31, 2012 4:31:08 AM UTC-4, AntoineLeca wrote:
>>> On Friday, July 27, 2012 1:24:23 PM UTC-4, AntoineLeca wrote:
>>>>
>>>> pikpik wrote:
>>>>> /boot/minix: versions of bootable parts
>>>>
>>>> BTW, previously there were at most 4 versions there; nowadays only 3
>>>> are kept; I tracked it to [release]tools/mkboot, rotate_oldest(): the
>>>> command ls -t "$base_dir" lists the new .temp/ directory as well, so is
>>>> offset by one (the . is ignored since it is run by root); as a result
>>>> adding the option |4 to the "not much here" case would make sense IMHO.
>>>> Of course the $3 below has to be adjusted to $4 as well.
>>
>> BTW, using shift or even better
>> [ $1 != ".temp" ] || shift
>> would achieve the same effect, perhaps in a more obscure way.
>>
>
> So, that simply removes the last one?

Sorry, you lost me along the way... (or it is a bit more complex.)

The script does remove one "release" (and only one) when it detects
there are "too much" releases in the store.

As it stood initially, it passed silently when there were 4 releases or
less (the new one, and up to 3 older kept); when there are 5 or more, it
tried to delete the fourth more recent, or more exactly, the third more
recent of all the ones existing before the new one is created.
The idea behind that logic is to keep the oldest, since it is assumed to
be a rock-solid, heavily-tested one, which is retired (manually) only
when the stars are really aligned (also, it adapts to the teaching logic
on MINIX as used in exercises: the oldest one is the reference version
then.)

The new way creates the release _before_ doing the cleanup (while the
logic of the script was not adjusted: this is my whole point.)
As a result, it passes silently when there were 3 releases or less (the
new one, and up to 2 older kept); when there are 4 or more, it tried to
delete the third more recent (taking the new one into account.)


I understand logic has to evolve sometimes, particularly since the aims
of MINIX are changing; however I feel that one was perhaps a bug or a
missed point, rather than a feature.

If so, then I'm not sure.
> It seems like if you had one existing version, then the new one would be
> added, the old one would be "shifted" out

No; the one which is shifted away is the first in the list, i.e. .temp,
the new added one.


Antoine

[pikpik]

Hi Antoine,

I'm afraid I have to separate this into a separate change. I'll revisit it once the /boot directory renaming is finished.

Thank you,

pikpik

[pikpik]

Hi,

I've put my changes online for this. You can view them in my repository. Please read my notes when considering them.

Thank you,

pikpik