hi everyone, I am Imrael and I have just installed antiX 7.5-test2 on my notebook. Now I think I am going to share my experiences with everyone __{{emoticon}}__

Having used Ubuntu 7.10 for a while, I wanted a distribution that was less bloated and more powersaving for my nb. I had my first steps with fluxbox as alternate window manager in ubuntu, but there, I had some problems with backlight changing etc. When I tried the antiX live CD most of what I needed (apart from wireless lan... broadcom chipset d'oh) ran out of the box, so I decided to give antiX a try (attracted by look and functionality I have to admit __{{emoticon}}__ )

Installing antiX was really easy, thanks to the Mepis installer.
I was wondering a little about the User/root password distinction (I used Ubuntu before, where there is no root) but there was no problem at all.

Having completed the installation, I was happy to see my screen resolution at 1280x800(which I didn't have without manual hacking of xorg.conf in Ubuntu 7.10) and the backlight keys working ootb.

First thing I changed was the Conky file, to adapt to my laptop.
(temperature sensor, clock speeds for both cores, battery percentage and estimated runtime)

Noticing my cpu went berserk at full speed, I learned how to reduce frequencies etc. without gnome panel icon.

Something I still wonder, is how some programmes are still root only (ifconfig o_O, hdparm). I was used to run at least ifconfig several times a week for checking my wireless state in university (their network sucks btw), so I almost went through the roof when I got the message that bash couldn't find ifconfig. But maybe there is a sense behind everything *g*

Now being connected to my router, I wanted to try the smxi script, to see what it actually can do. I followed the instructions on the website and everything worked fine, including the changed from runlevel 5 to 3.
I did a distro-upgrade based on the sidux repositories and then installed the newest sidux kernel (2.6.25-12). Being interested in a small system without bloat, I removed some definitely useless modules (intel wireless etc...). I was also presented a screen where I could activate and deactivate a lot of services, but my knowledge of what was useful and what not, was quite little, so I just made a mental note to try that again lateron.

After a reboot, I found the grub menu a bit broken, as the lines were too long, and the entry of Mepis - Latest Kernel didn't work anymore (seems I have to remove that one manually). Booting up the new sidux kernel worked perfectly (btw, is there a way to get the console font smaller, as in normal antiX bootup? Due to wrapping and big font, I can't read anything during the boot process).

Conky presented me the new Kernel name and I could tell all those joking Windoze Users in my favourite IRC-Channel, that my Laptop didn't break as they predicted __{{emoticon}}__

Now I tried something that I hoped to get rid of by using a new distribution: hard drive speed measurement...
My Ubuntu annoyed me by managing only ~10mb/s transfer speed with my sata hdd. This sucked, as I transfer files from nb to Desktop regularly.
Even with the new kernel, there was no improvement __{{emoticon}}__ Gotta look for a solution elsewhere.

I tested sound afterwards and it works fine (tested with a youtube video, which works also fine). I just had to crank up the volume, as it was set to 0.

So far, I have still many things on my todo-list, but now I have time until october __{{emoticon}}__

ToDo:
- Setting up my Broadcom WLAN chip
- fixing the HDD Transfer Speed
- allowing some more programs to non-root users (ifconfig, hdparm blah...)
- restoring my backupped files
- telling Conky that Runtime goes up when on AC, not down
- testing dvd playback and cardreader
- adding my dell nb's multimedia keys to the fluxbox keylist
- most things I have forgotten __{{emoticon}}__


So far I am very impressed of antiX and I will definitely try to get the most out of it, so that I have a very slim, university work/entertainment (depending on the quality of the lecture __{{emoticon}}__ ) notebook, that runs fast and looks great. Nice work Anti and all of your supporters !

best wishes from Berlin
Imrael

Welcome to Antix.

What model is the broadcom chip? I use the bcm43xx. The smxi script updated the modules and the firmware for and it works great. It also worked out if the box before I used smxi to upgrade the kernel(now at 2.6.25-9.slh.1-sidux-686)

For root access use su in the terminal or sux for graphical apps. Once you enter su and password there is no reason to keep sudo'ing.

As for the large font at boot up, This is because of the smxi script, not the script itself but an issue with how grub works and the script. h2, the author of the script is working on it.

Good luck and let us know how your doing.

the broadcom driver b43 legacy was already installed. I used apt-get to install the fwcutter, which downloaded the driver file.

Right now I am trying to get the wlan0 interface up, but apparently I do not know how *shy*"ifup wlan0" ignores the unknown interface wlan0...

@sudo: I don't like being root, normally just a short sudo is enough, but how can I change the programs, so that I can use them as normal user as well... atleast ifconfig and other commonly used programmes do not need to be root only on my system.

You might be able to change the permissions on the bin file for each one you want.

My wireless shows it's using the b43 driver not bcm43xx.

You can set up sudo if you wish to work as it does in 'buntu.

But, better IMO and Debian's:

All you have to do, in a terminal is:
su
password
filename

or

su -c appname

You'll be prompted for root password.

Oh and welcome to antiX. Nice summary of your experience so far.

humm... well maybe I get accustomed to that way of handling things.

Another question: My backlight function keys work wonderfully, but after a while, the backlight is set back. How can I turn that off, so that the backlight is only controlled by the function keys?

A few issues: the large font is from what I could see with my antix tests, because the default mepis /boot/grub/menu.lst is not correctly setup, or is not default or standard. That's totally out of my control, by the way, that's something you might want to change in antix as a long term goal.

The standard way to get new kernels to add the options you want, in this case, #kopt......... vga=791
to each new kernel is to have that kopt line, which is used by each new kernel you install for its default boot parameters.

So the solution that that issue is in releasing the initial antix with a more standard menu.lst file, including the desired default kernel parameters set in #kopt.

That's totally out of my hands, just to clarify. Distro specific issue.

All you have to do to add your normal user to the full system path, which is why root commands don't run, is to find this file:

.bashrc in your home directory, or set the master for it, in /etc/profile ( I think, that's what it is in debian/sidux), then find the PATH item, and add: /sbin:/usr/sbin: to the default paths, and then when you type in the command for your function bash won't complain about not being able to find it.

Again, that's a default decision made by the distro constructors, it can be changed, I also prefer user to have full access to all system commands, for the same reason, I don't want to login as root to run something like ifconfig. But that's easy to fix.

You can also just add these paths to the .bashrc PATH variable as well, then when you logout and log backin, you'll have full access to all system commands as user.

Hard disk transfer speed using linux kernels I tend to find in general are pretty weak, but they are improving steadily. same disk to same disk, however, is going to be slow, because it's reading and writing to different parts of the disk at the same time, which means the little disk reading arm has to jump all over the place at super fast speeds.

Also, I've found that if you leave everything off in the system, don't do anything else, the linux kernel tends to handle sustained long term large data transfers radically faster than if you ask it to multitask signficantly. The kernel basically decides that the transfer is a background process, not as important as the foreground action you start. That's what it looks like to me anyway, it's one of the issues I believe CK of CK patch fame I think was studying closely before he gave up on the kernel devs and moved on to something less frustrating.

Also, a very wise decision to NOT turn off services using that option. Turn off the wrong one, and your system will not be bootable, basically, it's dead. I have had another gui product recommended, bum, that apparently does a nice job filtering out all required services, and only showing you stuff that your system does not need.

All in all pretty good user feedback.

Re user and root, all real unix type systems use that method, only ubuntu and a handful of others decided that was too 'complicated' or whatever, and use sudo instead. But rest assured, pretty much all unix and linux history, except ubuntu, uses the standard user level and root level identities, as it should be. After a while you'll find that sudo is just annoying, and you'll view it, I think, as an oddity that has no real place in a unix type system.

- telling Conky that Runtime goes up when on AC, not down

Actually, when the laptop is on AC, Conky is displaying the time until the battery is fully charged.

status so far:

WLAN
====
I copied back my wpa_supplicant.conf file, where the data for my wireless networks are stored. Using fwcutter, I installed the broadcom firmware, so that in my eyes, wlan should work. Strangely enough when I use
I am presented the message in an infinite loop. Stopping the process with CTRL-C, appears to kill my wlan chip (atleast the LED goes dark)


BOOTUP
=====

As h2 mentioned, I tried putting vga=791 in the kernel options. For about 2 seconds it works *g* 2 penguins in the top and small font. But then my screen goes black and I get green artifacts until boot process brings up xdm.


MISC
====

My keymapping seems to be reset to whatever, every reboot. No matter if I change it using the Control Center or using setxkeymap.

Nano in standard terminal has white fields, so I can't read the hotkeys or messages anymore.

Adding the paths to the PATH Variable in /etc/profile worked fine. Thanks for the advice __{{emoticon}}__

@thinkpada21: makes sense __{{emoticon}}__

Bootup, you also need to add nosplash to the kernel options.

For keymapping maybe the problem is that /etc/bash.bashrc and .bash.rc contain this line.
export LC_ALL=en_US

Also check /etc/environment.

Not sure what is wrong with /etc/profile. It is the same as the one in sidux. It does have /sbin:/usr/sbin in the PATH.

Same with grub/menu.lst. Not sure why it isn't working properly.
I have # kopt=root=/dev/sda1 ro nosplash quiet vga=791

I don't have wireless, so I can't help out.

For nano, just edit the fluxbox menu and set the terminal part to just read wterm -e nano or use roxterm -e nano

The nosplash I've never needed to use, but we don't use splashy in the first place, but as noted, that fixes the problem, so that's one problem solved I couldn't figure out.

I recommend looking at the default /boot/grub/menu.lst a bit more, the versions I saw were not standard in terms of their structure, and it would be worth fixing this issue if new kernels will be installed routinely I think in general.

I haven't looked at 7.5 yet though, so I don't know what its default menu.lst is like.

Another critical issue, by the way, if you are you going to be running slh kernels, is that they use new libata, not the deprecated libpata, and that means they have a non static /dev/sdx, and do not support /dev/hdx at all in either menu.lst or /etc/fstab.

This means that for reliable disk mounts, either LABEL or UUID must be used, not /dev/sdx or /dev/hdx.

This issue is far harder to deal with than you might realize, and it's going to come up and bite people, for example, if you have one disk, /dev/hda, and you plugin another one, say a usb disk, and the next boot the system might decide to assign the usb drive /dev/sda and the static disk /dev/sdb, thus making boot totally fail.

Long term, this issue is going to have to be resolved, since libata is the future, and libpata is the past, and is essentially deprecated if I understand this stuff right.

I took another look at the /boot/grub/menu.lst, and what's happening is simple, and easy to fix: the mepis grub is not compatible with debian update-grub, I'd recommend rewriting the default menu.lst and making it conform to the syntax expected by debian update-grub, which will then easily handle the kernel updates. Note especially the use of the Automagic kernel list space. Simply change the default kernel stuff to fit that syntax, then new kernels will correctly be added to the list. Get rid of the 'last mepis kernel' stuff, I don't think it fits with how update-grub works.

Sorry, I should have posted this in dev section, not here.

h2 wrote:[.......................]
I recommend looking at the default /boot/grub/menu.lst a bit more, the versions I saw were not standard in terms of their structure, and it would be worth fixing this issue if new kernels will be installed routinely I think in general.

While I do not really mind the non-standard structure evident in the Mepis /boot/grub/menu.list, there is another aspect of the"mepis grub" which is far more serious:
It cannot boot most newer kernels (like >= 2.6.24) when installed in the bootdisk MBR. That's probably the reason that the sidux grub (newer version than Mepis of grub-gfxboot) is used in antiX M7.5test1. anticapitalista noticed the same problem with the Mepis grub in the MBR

I haven't looked at 7.5 yet though, so I don't know what its default menu.lst is like.

The same structure exists in 7.0 and 6.x

Another critical issue, by the way, if you are you going to be running slh kernels, is that they use new libata, not the deprecated libpata, and that means they have a non static /dev/sdx, and do not support /dev/hdx at all in either menu.lst or /etc/fstab.

This means that for reliable disk mounts, either LABEL or UUID must be used, not /dev/sdx or /dev/hdx.

This issue is far harder to deal with than you might realize, and it's going to come up and bite people, for example, if you have one disk, /dev/hda, and you plugin another one, say a usb disk, and the next boot the system might decide to assign the usb drive /dev/sda and the static disk /dev/sdb, thus making boot totally fail.

Long term, this issue is going to have to be resolved, since libata is the future, and libpata is the past, and is essentially deprecated if I understand this stuff right.

I took another look at the /boot/grub/menu.lst, and what's happening is simple, and easy to fix: the mepis grub is not compatible with debian update-grub, I'd recommend rewriting the default menu.lst and making it conform to the syntax expected by debian update-grub, which will then easily handle the kernel updates. Note especially the use of the Automagic kernel list space. Simply change the default kernel stuff to fit that syntax, then new kernels will correctly be added to the list. Get rid of the 'last mepis kernel' stuff, I don't think it fits with how update-grub works.

I agree. But let's keep the way that Mepis 7.0 -and antix M7.5test1- do recognize changed partition data at boottime: Sidux 2008.2 does not do that. If one reformats an existing partition in Sidux (either from a livecd or from gparted within sidux or a newly installed distro) on an unmounted partition, then at the next reboot that partition's UUID is not correctly identified and cannot be automounted anymore.
This is something that is different in Sidux; antiX does not have the same problem. antiX identifies the correct UUID of all partitions at boottime and all partitions show up in /etc/fstab. Not so in Sidux 2008.1 (and 2).

Any insights as to why?

Regards, Ko

I have long believed that using uuid in user modifiable files was always a serious mistake, because of the issues it creates re formatting, and the fact that uuid presents you with no meaningful information at all in terms of what it actually is re your physical hardware. It is my belief that the correct method was always to let some internal function in the system handle that, as you suggest happens in antix/mepis.

This is how windows has done it for over a decade, and I honestly do not understand why libata handling doesn't also do it this way.

UUID should never have been used as an identifier, the system should have used a human readable format, and internally tracked it. I believe that sidux is doing the very best they can do given the reality of how the components they use work, but I can't say more than that, and I don't want to misrepresent what they do. I do know the problem was very difficult to handle re keeping the stuff in sync with default and standard debian requirements, but I know nothign specific.

I can't answer the question about why, it may be a mistake, but all that hal/udev etc stuff is very complicated, and occurs below the level I work at in the s**i scripts, so I won't pretend to know or understand it at that level. I do know that the use of UUID is a mistake in its present form because they are not human readable, the system should transparently track that itself, internally, using uuid, but not externally, using whatever method works, and uuid stuff shouldn't appear in anything a user will configure manually.

Because the more you look at this problem the more complex it starts to look (ie, if the system internally uses uuid to track a partition name, what then happens when it's reformatted and gets a new uuid), my actual suspicion is that the entire problem was not handled as elegantly, from kernel to userland and stops in between, as it could have been, leaving this messy solution, which to me clearly is not a long term fix, but the sidux solution will always work in all cases given the design of the libata system internally, which is why they use it. It of course fails on reformat, but I honestly cannot think off the top of my head of how the system could ever know that a reformatted swap, for example, was teh same as teh previous swap, especially in complex cases like new disks, multiple new partitions, etc. The more you look at this problem, the harder it starts to appear, and I believe this is why sidux chose the solution they chose, it's always reliable on install, in almost all cases.

The more I think of it, the more I think this is more a debian issue, because one thing I noticed while testing debian testing and sid is that the official debian installer does NOT allow you to not reformat both swap and / on instlal. This has a very serious repercussion for all other systems on the box that mount swap by uuid, obviously, since if you install debian and another system is on the box, you have to then reedit uuid on the other system's swap in /etc/fstab. That's obviously unacceptable. I work around this by using LABEL, but even then you have to reset the swap label each and every time you install a debian test install on the box, which is silly.

I think the grub/menu problem in antiX is that Mepis installer overwrites what is in /boot/grub/menu.list!

I made the grub changes, installed test3, but the boot menu shows vga=normal, even though I changed it to vga=791.

Once the 'new' grub/menu is edited to include the changes, update-grub, install a sidux kernel, the correct kernel parameters are there ie vga=791 nosplash quiet.

using vga=791 or vga=792 on the newly installed sidux kernel didn't work for me. Strangely enough for the old mepis kernel before I installed the sidux kernel it worked.

I tried all possible permutations of vga=791, quiet, nosplash but only if I omit vga=791 my screen doesn't go black after a while and displays green artifacts. Now my font is not small, but with quiet and nosplash, I can at least read the boot messages, which is what I initially wanted.

I worked around the keymapproblem by adding"setxkbmap de" to my fluxbox startup. Gotta look what I would have to use, to eliminate dead keys (getting ~ only by typing it, followed by a space, is a little annoying, but I mainly needed the pipe on the button it is supposed to be)

Still, I got no way further with my wireless lan. Later this day I will try wpa_supplicant with the option if lots of debugdata, maybe I can find a reason there.

Thanks for all your help guys ! Makes me feel home already __{{emoticon}}__