antiX-16 stable based is 698MB. Exact same apps on testing is 798MB!

Yeah, that's why I asked and chimed in about looking to save space.
I had experimented with upgrading and snapshotting the antix15.1b, and wound up with an even bigger (than 798) iso size.
Even by axing many (non-locales) stuffs that I would rather not touch, like
-- /var/lib/mlocate/mlocate.db
-- /usr/share/icons/*/icon-theme.cache
-- all of the 256px iconfile subdirectories
the goal of reaching CD size seemed like an excercise in futility. My experiment did not omit smtube+webkit though. That's why I mentioned it above.

Due to the presence of the buggy synaptic v0.82.5 (AND v43 iceweasel) in the testing repo,
I would prefer to have jessie base for live with option to"choose stable or testing repos" at time of install.

Here is my plan.

1 - Upload a bugfix/upgrade of antiX-15. This should appear fairly soon. Those using antiX-15 have no need to install this iso. It is aimed at new downloaders.

2 - antiX-16, at the moment, will be jessie based, but with a 4.3/4/4 kernel and lots of changes since antiX-15 (not just bug fixes). At the moment testing is in a state of flux. New gcc, new qt, but many apps still using the older versions. This partly accounts for the extra 100MB fat from jesssie to testing.

anticapitalista wrote:...antiX-16, at the moment, will be jessie based....

Sticking with Jessie is a really good decision.

Given the remarkable success since antiX adopted Stable, it will be regrettable if every new release does not offer Stable with Testing as an alternative. Converting an installation mid cycle from Stable to Testing can be done. We found some time ago, converting an installation from Testing to Stable mid cycle cannot be done.

anticapitalista wrote:...antiX-full will fit on a cd

Keeping the antiX ISO at CD size is a welcome decision.

In terms of space saving, for probably 99% of average antiX users, VIM does is totally superfluous. It is so difficult to learn, remember and use that it is only of value to coders that use it every day. In my view it is not a good fit in a generalist desktop distro.

In view of previous posts in which I alluded a reducing amount of discussion between devs and community it is good to see it begining to happen again. It is encouraging to see. Hopefully it will steadily increase.

How about a record tracker of what is being considered and a short account of the reasons for accepting or declining. Something similar was used during the development of antiX-15.

what are the odds of seeing some of the MX-apps in place of some of the antiX ones. MX-User and MX-PackageInstaller are two obvious choices. the antiX user app is a little complicated and there is not real reason not to share the work done for MX-PackageInstaller in antiX (since it can parse 32bit and 64bit options so only appropriate options for a given architecture are displayed). I know some qt stuff would have to be installed, so maybe space would be an issue. MX-user might need tweaked I guess to remove the desktop management aspects, but the user management and group management are extremely nice.

anyway food for thought.

One thing I personally have noticed is that the Jessie programs are so much more bloated than the Wheezie ones. Is it from trying to be sure to include code that will work on"every" machine or not, I don't know. Like the old Intel / AMD wars of coding back at the turn of the century.

dolphin_oracle wrote:what are the odds of seeing some of the MX-apps in place of some of the antiX ones. .

I know we are trying to keep AntiX separate from MEPIS MX, but it appears that one or the other is a sub-set of the other (in Linux terms). If the intent is to keep AntiX strictly for the older machines, would it be wise to utilize more"modern" programs for more"modern" machines? Just a thought within my rambling.

Just adding the 2 MX apps that d_o mentions takes the iso to well over 700MB.
I would prefer to port those qt apps to gtk/yad or find a way to reduce some of the dependencies.

@d.o.
first what version of user-management do you have? are the tabs on the side?
second in which way is it more complicated? I see that the framing makes it a bit cluttered but the options seem similar to me other than the shell selection in the add tab.

The newer group-management is not completed as far as I remember but it was going to be the same as add and remove groups and add / remove users to groups.

Once upon a time I believe the actions in both programs were modeled after mepis user assistant to remove the need for qt.

dolphin_oracle wrote:MX-User and MX-PackageInstaller are two obvious choices.
...
I know some qt stuff would have to be installed, so maybe space would be an issue.

My reading of the d_o post is that improvement of the antiX apps is what is being suggested. Fundamentally it is seeking to transfer the functionality of the apps so that antiX may benefit from an improved experience. The post does recognise that there may be dependency and space issues so

anticapitalista wrote: Just adding the 2 MX apps that d_o mentions takes the iso to well over 700MB.
I would prefer to port those qt apps to gtk/yad or find a way to reduce some of the dependencies.

This seems a good way to go. Take the lessons learned and bring those across in a lean way rather than gaining the functionality together with its baggage.

anticapitalista wrote:Just adding the 2 MX apps that d_o mentions takes the iso to well over 700MB.
I would prefer to port those qt apps to gtk/yad or find a way to reduce some of the dependencies.

I was afraid of that on the dependencies. The filter code (32bitonly, 64bitonly) should be easy enough to add to metapackage-installer. It took adrian no time to at all to add it to mx-packageinstaller.

dave wrote:@d.o.
first what version of user-management do you have? are the tabs on the side?
second in which way is it more complicated? I see that the framing makes it a bit cluttered but the options seem similar to me other than the shell selection in the add tab.

The newer group-management is not completed as far as I remember but it was going to be the same as add and remove groups and add / remove users to groups.

tabs on the side. its the default app in antiX-15 I'm looking at.

The missing group management is what I'm most interested in. The old user assistant could not manage groups that were not created by the assistant, and the current user app doesn't have group management at all. mx-user can, and I think that feature of group management is a must. The shell choice tab is exactly what I was thinking of when I said complicated. I know antiX veers towards choice in all directions, but even adduser doesn't make you choose a shell, instead defaulting to something (bash I guess).

samk wrote:My reading of the d_o post is that improvement of the antiX apps is what is being suggested. Fundamentally it is seeking to transfer the functionality of the apps so that antiX may benefit from an improved experience. The post does recognise that there may be dependency and space issues so

Exactly. Obviously if those features are added to the existing apps, I think they are fine as is. there is nothing magic about qt after all.

I was also thinking that you may not need to update the menus at log in. Now that apt-get has menu hooks (a nice move by mr. dave by the way), running the desktop-menu update just delays the desktop coming up. my eeepc has such problems getting to a desktop that I'm still looking for the culprit, although adding dbus as a dependent startup to slim has solved it for now.

more other item would be auto-populating the /media directory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default. That's another big question that is often asked in the forums.

(e)udev rule?

dolphin_oracle wrote:more other item would be auto-populating the /media directory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default.

Yes, that would be a big PLUS.

dolphin_oracle wrote:more other item would be auto-populating the /media directory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default. That's another big question that is often asked in the forums.

(e)udev rule?

udevil handles the automount for spacefm correct?
do you know if possible to have udevil as a depend separate from spacefm for those that do not wish to have spacefm?
That way I think between an udev rule and udevil mount it could function ok (better than when pmount was used in the past)

Dave wrote:

dolphin_oracle wrote:more other item would be auto-populating the /media directory with inserted usb sticks/drives. even if they aren't mounted, it would be nice if they showed up in rox by default. That's another big question that is often asked in the forums.

(e)udev rule?

udevil handles the automount for spacefm correct?
do you know if possible to have udevil as a depend separate from spacefm for those that do not wish to have spacefm?
That way I think between an udev rule and udevil mount it could function ok (better than when pmount was used in the past)

I would agree with that. and yes, udevil is already a separate package. and its included on the iso already. spacefm used to default to pmount, but now I believe spacefm defaults to udevil (I think udevil also written by IgnorantGuru who wrote spacefm).

interestingly enough, devmon is also included on the iso already, and uses udevil by default for mounting. It doesn't seem to be running though. just running devmon is enough to get automounting of usb sticks (mounted by udevil by default).

if udevil is used to mount everything (which is ok with me, consistency, etc...) then rox preferences could also be modified to use udevil as the mounter/unmounter.