Time to get some feedback about how you would like to see antiX progress.

Some thoughts.

1. Login manager
Replace slim login manager with lightdm or lxdm (or even xdm) or keep it.

2. Include more development libraries/applications for users that need to build for wifi and don't have any other way to connect.
That would mean including for example build-essential fakeroot (adds about 20MB to live iso).

3. Include virtualbox-guest-utils etc so that user gets full screen in Virtualbox when running live and installed. Useful for those users who run antiX only in VB.

4. SpaceFM now has a dialog component so it may be better to use it instead of gtkdialog/yad. It means re-wrting our scripts.

5. Scrap using dialog/yad altogether and use PyGTK instead.

6."Modernise" the look of antiX by using a 'fresher/newer' icon set especially in antiXCC.

Please comment and add your thoughts.

That would mean including for example build-essential fakeroot

Sounds cool. I usually install those anyways though after first install. Never had a problem getting online though with hardwire ethernet with any of the isos, core,base,or full. I guess dial up users may need something extra though.

Not sure if updating themes for icewm and fluxbox and getting rid of old unused ones may be a good idea or not. Just throwing that out there.

I like what lagopus has done pretty much with the antixcc look lately also.

Login Manager. I will leave that up to everyone else. I installed xdm (just a slim mis-adventure on upgrading) and can say it is light as hell but butt ugly.

anticapitalista wrote:Time to get some feedback about how you would like to see antiX progress.

Some thoughts.

1. Login manager
Replace slim login manager with lightdm or lxdm (or even xdm) or keep it.

Ixdm ? (but I never used it) or keep slim

2. Include more development libraries/applications for users that need to build for wifi and don't have any other way to connect.
That would mean including for example build-essential fakeroot (adds about 20MB to live iso).

No opinion, not for ordinary people like me... And for using such tools, I need a working connection... to browse on the net the manual...

3. Include virtualbox-guest-utils etc so that user gets full screen in Virtualbox when running live and installed. Useful for those users who run antiX only in VB.

No opinion, I don't use virtual box for now (installed once on a Windows machine and used antiX 8.5 as guest, forgot how I did it!)

4. SpaceFM now has a dialog component so it may be better to use it instead of gtkdialog/yad. It means re-wrting our scripts.

ya(yad)?
from the manual:

A command enclosed in backticks (`), not to be confused with apostrophes ('), evaluates to a string containing the stdout output of the command. This output is then double-quoted (") and passed to eval, which interprets it (sets the variables). (Be sure to double-quote the backticks as shown above or some data may be lost!)

Sorry, not for me

5. Scrap using dialog/yad altogether and use PyGTK instead.

6."Modernise" the look of antiX by using a 'fresher/newer' icon set especially in antiXCC.

antixCC and family should support themes (in gtk dialogs and ice wm menus icon paths are hard-coded) see point 5.

1.)
I would replace slim with lightdm, however there are some issues I would like to resolve before switching.
The primary issue being that changing the .desktop session files in / usr/ share/ xsessions/ to start a custom script, a xmessage comes up that closes the session.
Ultimately I think it should work ~/.xinitrc or similar so that we can add our session startup commands. Example: $DESKTOP_CODE session logging for wallpaper.py, add-start, add-key etc...

lxdm ... need to wait for further development, at this moment I would prefer anything over lxdm. There are to many bugs, configuration options are very finicky, and it requires alot of base changes to antiX IMO. I have not tried anything with the session handling in lxdm.

2.)
I cannot say if this is beneficial or not. With my history / luck on building from source no matter how many development libraries and applications are installed, there is always one missing or improperly seen.

3.)
I do use antiX in vbox, but I have always had it run in full screen. Though I do not use virtualbox for more than testing applications / distrobutions, I think it may be a good thing to include.

4-5.)
A respectful no to spacefm dialog, all the scripts would then depend on spacefm (ok if it remains a default FM). On top of that, it was a real pain to convert to yad ( though I find yad very useful ) and I am sure it would be the same for spacefm dialogs. If we are going to convert our scripts again we will work the scripts into pygtk. IMO between lagopus and I, I believe over, 50% of the antiX gui apps are already well on their way of converting to pygtk. If in the future yad is used or not, I would like to see it included in antix as it is very, very, useful for a gui tool in your bash scripts.

6.)
As lagopus says.
Though I do not have the knowledge of how it works, I know based on pygtk apps lagopus has made and others online that we can use the system icon theme. Then we can pick a icon theme that we think best fits antiX and if others do not like the icon theme simply change the system icon theme.

6."Modernise" the look of antiX by using a 'fresher/newer' icon set especially in antiXCC.

Like this?






========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://distrowatch.com/?newsid=07304"
linktext was:"http://distrowatch.com/?newsid=07304"
====================================


It is a little heavier than us though.

i loved lagopus's versions of the control center and exit script, i would like to see them included in future antix.

One of my friends, whom I've convinced to use antiX, likes it, and I've even gotten him into using IceWM, still comments that it would be GREAT to have a 64 bit version of antiX available. While that may prove to be beyond the scope of this release, consider it a feature request from a friend who is favorable toward antiX - he may even stop by here. If it can't be done, understood; I still appreciate all the GREAT work we do here. I don't have a 64-bit box, but he does, and if we implement a 64 bit system, I am sure that I can talk him into testing it for us.

anticapitalista wrote:Time to get some feedback about how you would like to see antiX progress.

It is always helpful to learn of and understand the motivation behind suggestions for change.

In general terms I would prefer to avoid going down a route which ties antiX into any particular application or methodology (other than is neccessary i.e Debian) and becoming restricted by them.

Without becoming overly formal, might it be possible to have some form of analysis of the expected impact/benefit of proposed changes? These might be compared to indictors in the current release as a basis of comparison. A starting point might be something like:
* What existing/reported antiX issues does it address
* Storage footprint in both the ISO and when installed
* Expected change in RAM demand
* Expected change in CPU demand
* ...

These may help ensure antiX remains a truly lightweight distro, after all it is not just about the resources used in a quiescent state following a reboot. It is also about actually using the system and lightweight apps - something that antiX really does deliver well.

This is not to say that antiX should remain frozen and unchanging. It is very tempting to introduce change simply because it is interesting and rewarding to do. The suggestions are simply another means to help ensure antiX continues be what it presently excels at being - a lightweight turnkey distro+application set that runs well on both new and old hardware.

I agree with SamK on his points made. Please do not take any of my posts in this thread to heart. I was mostly just posting in this thread to supply info on different things that members might not be aware of. Basically translated. What ever the community decides to go with. I can live with.

My favorite feature in AntiX is how much space is taken on the hard drive after install and the lightness on ram and cpu when running. I don't want any of my posts to give the impression I think other wise.

Greetings from the friend Masinck mentioned! Yes I do like antiX and I do wonder if it would not be a good thing to think about a 64 bit version. Why? Well the great glacier of change seems to be slowly sliding that way. RAM is inexpensive and so 4 to 8 Gigabytes no longer is unusual. If support for PAE kernels drops off then a 64-bit development path makes sense? I say all this as perhaps the least technical user on thiis board so bear that in mind.

How do I run antiX?

1. Most typically from a 16 or 32 Gig jump-drive on this System 76 laptop while Debian stable, testing and unstable run on the main drive.

2. Present log-in is fine, preferred WM is IceWM.

3. antiX-core is terrific. I use h2's scripts to finish it out. When I do that I can make antiX whatever I want to make it. I have built versions with both KDE and Xfce. Interestingly I come back to IceWM as most compatible with the idea of a Linux that is light and portable.

4. Re wireless: The problem is the plethora of chips. Ceni will suffice to get a person an ethernet connection from which the proper wireless firmware can be downloaded. BTW Ceni is essential equipment for me. Hang on to that, please.

That said this seems a good compromise point:"Include more development libraries/applications for users that need to build for wifi and don't have any other way to connect. That would mean including for example build-essential fakeroot (adds about 20MB to live iso)."

5. No firm feeling about anti's other questions, probably because I am not sufficiently technical to understand what he is asking in all cases.

6. Last thoughts: If we think about the world outside the United States we need to kep antiX light and we should want users to be able to easily configure it in their native languages. I appreciate the efforts that have been made to do that.

My thanks to anti and the people who produce antiX!

rokytnji wrote:I don't want any of my posts to give the impression I think other wise.

Just to provide clarification, my post is intended to be general in nature. No criticim was intended or implied towards any individual in the community or any other post.

Nice to see all the comments here, and also the sensitivity and appreciation that has been expressed. Like others, I am very happy with what we have, appreciate the opportunity to discuss future possibilities, then ultimately balance the decisions on what we choose to do based on time, skill, availability, and the overall goals of the project. Good discussion here; I hope it continues, and as development begins, I hope that those with some developmental skills that can be shared will do so. We've had great help from Dave, John, and several others over the years, plus our usual array of people helping to document, promote, answer questions, and more. Those are areas we are strong in, and will hopefully continue to do what we've always done best.

I am reading, but I am too scared to say anything __{{emoticon}}__



__{{emoticon}}__ __{{emoticon}}__

0) I too would like to see a 64-bit antiX. This is the main thing that prevents it from being my main rescue cd/usb. It was trivial for me to make a 64-bit version of the antiX kernel. I realize most of the work is in making the rest of the system 64-bit. I'd hope most of that could be automated somehow.

1) When LightDM is ready I think we should migrate to it but not before. IMO SLiM is dying but is not yet dead. Better to err on the side of switching a little late rather than too early. Less alienation.

2,3) build-essential fakeroot, virtualbox-guest-utils: Could these issues be dealt with by meta packages (or something like that) in the repository? Just make it really easy for people to who want them to add the extra packages. I can imagine other packages such as for dvd playback.

4,5) SpaceFM dialog, PyGTK: I've already invested heavily in making a Bash library that seamless works with Yad for GUI and on the command line. IMO we should stay on this direction so our scripts work both in the GUI and on the CLI. One way or another I think most of our core scripts should seamless work on the CLI and in the GUI. This is easier for developers and for users IMO. Maintaining separate CLI and GUI versions of scripts is nuts.

6) I don't know. My biggest gripe (which is not very big) about the CC is that I need to actually click on the icons because clicking on the text does nothing. I'm usually not a big fan of upgrades that only change appearance and don't add/improve functionality but I have to admit such upgrades can be helpful and desired. I will defer to the judgement of others here.

BitJam wrote:0) I too would like to see a 64-bit antiX. This is the main thing that prevents it from being my main rescue cd/usb. It was trivial for me to make a 64-bit version of the antiX kernel. I realize most of the work is in making the rest of the system 64-bit. I'd hope most of that could be automated somehow.

From what I see most of the apps in antix are already available in the 64 bit repositories. The scripts are just that... scripts. From what I have seen they work on 32 bit and 64 bit as long as the dependancies are there. I am not entirely sure if it would be that much different, but I have never used a 64 bit system daily, only 32 bit with a PAE kernel.

BitJam wrote: 2,3) build-essential fakeroot, virtualbox-guest-utils: Could these issues be dealt with by meta packages (or something like that) in the repository? Just make it really easy for people to who want them to add the extra packages. I can imagine other packages such as for dvd playback.

The installer I have been working on to replace the mepis one will allow for the installation of such software upon installation. However in this case I think anti is woried about those that cannot connect to the internet, that are in need of building their nic card driver from source. For these people, the development libraries would need to be preinstalled of included on the cd as debs to install, either way they would need to take up space on the cd.

BitJam wrote: 6) I don't know. My biggest gripe (which is not very big) about the CC is that I need to actually click on the icons because clicking on the text does nothing. I'm usually not a big fan of upgrades that only change appearance and don't add/improve functionality but I have to admit such upgrades can be helpful and desired. I will defer to the judgement of others here.

Lagopus's new antixcc.py includes the image and text in one button, and all the buttons in the window occupy the full window space. So on top of it being prettier, it would fix your biggest gripe __{{emoticon}}__
Another big thing that I like about his newer control center it reads the content from an xml file. So to add new pages and buttons / change the order of the buttons no longer requires editing the script. All upgrades in the future would then not *require the interface to change, only the functionality. Implementing lagopus's new control center would also allow the control center to be tailored to the window manager. Example: when running icewm you would not need to see entries for fluxbox and jwm. This should be simple enough to add into it by reading $DESKTOP_CODE as most of my scripts now do. However as in my previous post if we switch to lightdm that method may need to change.