What about extlinux, part of syslinux, would that be an option, for the installed system, if the iso used syslinux. If I remember, all you would need to do is change the names of the config files.

We now have a /boot/syslinux/ directory in addition to the /boot/isolinux/ directory on the Live iso. We also provide a /boot/grub directory on the LiveUSB even though we boot with isolinux. This makes it possible to give people several different bootloader options when they make a LiveUSB and each option provides the user with the same bootloader UI and menus.

IIRC, extlinux will work with the /boot/syslinux directory but not with /boot/isolinux. I think we added the syslinux directory so LiveUSBs made with Unetbootin would use our bootloader and bootloader menus.

anticapitalista wrote: Time to think about the next release cycle.
[...]
Just remind me or point me to the threads here at the forum.

Sent privately to avoid cluttering the topic with 52 items/links.

Grub legacy most likely is not usable with (U)EFI so grub2 should be an option within the installer and you can default to grub-legacy unless a (U)EFI system is detected. Thoughts on this?

Well, if grub-customizer, or what it is called, is included, grub2 is not that bad... but I have no idea how it works... Just that I have managed to get it to work.
I think that IF we have to have grub2 in there, we should just use that, and forget old-grub.

DeepDayze wrote:Grub legacy most likely is not usable with (U)EFI so grub2 should be an option within the installer and you can default to grub-legacy unless a (U)EFI system is detected. Thoughts on this?

There are other things that would have to change for us to boot and install on UEFI systems. Making antiX install on UEFI is a bigger project than just changing boot loaders.

Thanks for the input and points raised will be considered.

Here is another one to think about.

Should we release a bugfix antiX-13.2 full only version for 32 and 64 bit that sticks to the Wheezy repos?
If so, should we include any new features or simply have it as a bugfix release?

What would be easiest for you people?
It doesn't matter to me... I want both, when it is ready

or simply have it as a bugfix release?

I'd think that would be easier for all the new users I point like the pied piper to this distro.
AntiX has a reputation of being for advanced users vs Crunchbang on low end hardware.
AntiX saving grace is your kernel Anti that works on all gear. Crunchbang at least has
not gone that route yet.

What was just said is, Just my opinion for new migrating XP users. If it was just me. Yeah

If so, should we include any new features

then I am the happy camper. __{{emoticon}}__

Option 2 is to keep doc folder and slim the iso by removing apps

Removal (exclusion in the remaster) of the following
should free up plenty enough space to allow the docs path content to remain.

/usr/share/icons/HighContrast/icon-theme.cache
this 73 Mb file can be excluded from remastered copy

/usr/share/icons/gnome/icon-theme.cache
this 79 Mb file can be excluded from remastered copy

dzz over at the refracta forum insists it's safe to exclude *.pyc files
that would free another 70Mb"files on disk"

/var/cache/apt-show-versions/*
about 7Mb here. Can be excluded from the remaster. Will be automatically regenerated as needed

etc/skel/...recently-used.xbel
only a 200kb (but it should have been excluded)

also in skel, a LINK to wikipedia page, vs local copy of the page + all the embedded imagefiles would free 5Mb

/live/linux/run
dir contains entries, including pid files (should these have been excluded?)

mlocate.db
content of the database file is stale (falsely shows many *.deb files are present)
remastering workflow should call updatedb immediately prior to creating squashfs

antixFull has 58 locales configured
although"vi" (vietnamese) is not in the"supported" list,
quite a few odd"vi" (and other"not on the supported list") language files are present in various dirs.
How would a user of a"not listed among the supported locales" language ever discover/use these odd files?

/var/cache/apt-xapian-index/index.1/*
about 3Mb here
must be leftovers, b/c apt-xapian-index isn't installed

/usr/share/themes/Adwaita/backgrounds/*.jpg
1Mb of imagefiles which will probably not be missed, if absent

@skidoo, thank you for all of the suggestions.

There is a big difference between the compressed size and the uncompressed size of some of the files you mention. We are primarily interested in the *compressed* size. For example, in antiX-13.1_full, /usr/share/icons/HighContrast/icon-theme.cache is 74M uncompressed but compresses down to under 1M when using xz compression which is what we use for the squashfs files in our iso's. If we had 10x better compression, we would probably shove in 10x more stuff into the squashfs. Unfortunately, the growth in the size of software packages is rapidly out-pacing improvements in compression which is why we have to prune.

I mounted the antiX-13.1_full iso and then mounted the /antiX/linuxfs (squashfs) file within it for the tests I made below. Some of my numbers are significantly different from the ones you gave. I use"du" for uncompressed sizes and either"xz" or"tar tJf" for compressed sizes.

All the"*.pyc" files in antiX-13.1_full take up only 8.7M uncompressed. If this is true, I think it is better to leave them in rather than force them to be recompiled at run-time. Recompiling not only takes up time but it takes up RAM on the Live media and the recompilations are lost on reboot unless persistence is enabled. As a benchmark the squashfs file in antiX-13.1_full is 666M (compressed) while"du" says it contains 2.3 Gig (uncompressed). This is an average compression ratio of better than 10:3. Of course some files compress much better than others.

Thanks for catching the extra .deb entires in mlocate.db. This is probably due to a bug in the make-antiX-iso script. The following code is run inside a chroot just before we make the squashfs file: I know we (I) had a bug in that line but I thought it was fixed a while back. Maybe it is still not sufficient to prune those entries. I would much prefer to not have to umount the device mounted at /var/cache/apt/archives in order to exclude its contents from the locate database. We keep that mounted separately so we can cache the .deb files between the creation of different .iso files. I suppose I could mount an empty directory on top of /var/cache/apt/archives from within the chroot before running updatedb. Or perhaps I misunderstood what --add-prunepaths does.

On antiX-13.1_full the entire / etc/skel directory takes up 4.7M uncompressed. 2.9M of this is in the .mozilla/ directory. We have played a few tricks to try to keep the size of that directory down but we are again up against the problem where files just get re-generated anyway and then they take up RAM on the Live system. The entire skel directory compresses down to 614K using xz. But I think it is essential to move things like the Document/ subdirectory out of / etc/skel to save RAM on the live system because everything in skel gets copied to RAM when we create the demo account.

Some of your other suggestions look good to me but I'm not familiar enough with the packages involved to know if the files should be pruned or not.

I think you've given some great suggestions that will help cut down the size of the iso files but I don't think it is enough to get us back onto a cdrom without significant other removals. The biggest hiccup is that those big cache files compress down to less than 1.5% of their original size. But moving Documents/ out of skel/ will save us 1.2M of RAM on the live system.

anticapitalista wrote: Should we release a bugfix antiX-13.2 full only version for 32 and 64 bit that sticks to the Wheezy repos?

Yes.

anticapitalista wrote: If so, should we include any new features or simply have it as a bugfix release?

Bug fix only (but see the following idea).



The Debian model of preserving the reliabilty of its stable release is one which antiX might adopt. Debian stable does not introduce additional features to applications but does address known issues, i.e. security vulnerabilities. Occasionally, it amalgamates these into a revised ISO which is then released as the most current version.

Perhaps antiX might take this opportunity to do something along the lines sketched out below.



Indentify Stable v Testing
It seems there is the potential for some confusion with this. Users that have installed the stable 13.1 may assume 13.5 is the latest stable version and so install it. Might it be worth considering appending a suffix to the ISOs?

Example
antiX-13.2-Stable
antiX-13.5-Testing
In this way the difference between the two streams is more obvious and the risk of misidentification is reduced.



Bug Fixes and Regressions
For antiX these are broadly similar to the Debian Stable security upgrades.

ISO
It is advantageous to have the current version of the antiX-Stable ISO as bug free as possible. This will give the best experience to potential new users. Towards this goal, antiX might periodically amalgamate resolved bugs and regressions into a further bug fix release ISO. Each such ISO to be denoted by a minor number, e.g. 13.x.

Repo
The current practice continues unchanged. These will be applied when a user conducts an upgrade via Apt or Synaptic.



Additional/New Features

ISO
Extra features become available in an antiX-Stable ISO at each release for which a new major number is allocated, e.g. X.0.

Repo
An"Extra Features" download area (not repo) might be created for antiX-Stable users.

• The area will include a .deb of each feature that will become available in the next ISO.
• Each .deb will not depend on any unstable Debian repo. It wil be 100% compatible with Stable.
• As each new feature is developed and tested it is added to the area.
• An extra-feature.deb is not installed via Apt or Synaptic.
• To allow the user to choose whether or not an extra-feature.deb is to be installed, it must be manually downloaded and installed via gdebi, or similar.
• An additional tab to be added to Dillo which automatically points to the Extra Features area.
• A separate html (or plain text) file to be available in the area for each .deb. This might include a brief but meaningful description of the .deb, together with a description of how to install it.
• Possibly an item in the antiX menu or Control Center to launch Dillo as Extra Features.
• A reference to Extra Features might be added to antiX wiki and FAQ.
• As each .deb is added to the area a corresponding post might be added to the Announcements forum.

I think exoodles should be removed. some of the packages it offers are outdated or incorrect, and it messes with the sources lists and doesn't clean them up afterwards. for instance, installing google-chrome through exoodles doesn't work due to dependency issues (installs unstable instead of stable). This also adds a"google-chrome.list" to sources.d. Just running the script enables the multimedia repos, in a file called"multimedia.list".

Either remove, or set up the"edit config files" button in the control center to open all .list files in sources.d. I didn't even realize those repos were enabled because I usually use the control center to edit my source lists. and unless you watch the output of apt-get in the command line, its non-obvious that those repos are being polled.

piddly thing, the antix control center .desktop file doesn't specify an icon.

Regarding size and fitting everything on one CD, here are my thoughts:

1. Produce one CD, but omit the docs from it.
2. However, some people, for whatever reason, have difficulty getting information. It would be nice, for their benefit, to make a documentation library CD available for them. Some of these people go to inexpensive CD shops and have CDs built for them, which they can purchase for $5-10. By having CDs available, these people are not shut out completely. We could also document where to find such CDs and collaborate with one or two such CD houses, or if anyone has a connection, start one ourselves.

Regarding GRUB, the trade off appears to be between size, simplicity, and access to newer boot and drive features.

GRUB 2 does tend to automatically find all systems and distributions, but it has an unwieldy approach and takes away the ability to easily edit the config file; config editing is possible, but ridiculously complex, and arguably unnecessarily so. I don't know why they didn't keep the config file editing capability when they redesigned; to me that was the number one feature of GRUB Legacy.

Therefore, GRUB Legacy has a really nice advantage of allowing you to edit its configuration without having to reload the values.
1. This can (playing the other side for the moment) create issues if you mess up the config file contents.
2. The other issue is that GRUB Legacy is not being actively maintained and there are more and more hardware configurations that it may or may not support, especially as BIOS configurations continue to change.

I almost hate to say it, but it may be wiser to bite the bullet on GRUB 2 now. It really has not caused problems for me lately compared to the initial release; most of the differences between GRUB Legacy and GRUB 2 formats are now smoothly resolved; with over a dozen distributions between the systems I have, I'm no longer running into issues with GRUB 2; I reluctantly recommend that we go with GRUB 2. (FWIW, I ran the recently released Lubuntu 13.10 Beta 2 Live, then installed it; GRUB 2 worked there and the results were fast and predictable; I think we can do just as well or better with antiX, even with GRUB 2 in place of GRUB Legacy).