sarah31

hmmm....well have you tried uninstalling eject (mdk may be using the independent eject app out there)? it sounds like something you installed or did ahs meesup the configuration of your desktop icon and messed with your actual device's function because the only time you may not be able to manually eject the cd trya is if you have a disc mounted and even then you can sometime s get away with it ( i know i have manually ejected the cd tray with the device button many many times while having a disc mounted). so my guess is that some app you recently installed or tweaked has buggered things up.

excuse the stupid question but did you try : eject /mnt/cdrom(2) ? it has been some time since i have used eject on the cli. it shouldn't technically make a difference but who knows.

any errors? i have some ideas but cannot give any concrete answers without seeing errors

well i did give you some suggestions previously. if you have no logged off (no not shut down) then back in then perhaps qt is not being detected yet becuase the path addtions may not have taken effect. alternatively if you have then perhaps the configure scripts are looking for qt named in a standard fashion while the rpms you installed may have changed the naming on some of the paths. (ie configure scripts are looking for qt in /opt/qt or /usr/local/lib/qt or /usr/lib/qt while the rpms have a qt3 in place of qt). in which case you will need to set the path in your configure options. (see ./configure --help for your options)

well according to your listed installed packages you do have gnome-python. did you try just running the configure script for the source to see what happens? another common issue after installing some packages which include lib files is that often their presence is not fully detected until you log out then in. (it is not common but will occurs especially if their are functionality scripts involved with them) your other option is uninstalling all of the depends then reinstalling them.

by sharing you mean without physically transferring the files over correct? if you just want to transfer files scp works rather well imho and you don't have to worry about interfaces and config files you just have to have ssh setup on each box. i transfer files between my mac and linux box all the time via scp.

well the preferred way is not really something you should decide. but using rpm's is usually the desired way for most people as compiling can be a bit if a pain at times, especially if you are not very experienced at it. anyway you really should give us a better idea of : error messages what makes you think it is not installed whether or not you have all the required depends installed for using gdesklets. and anything else that you think may help. being verbose is not a bad thing imho, because right now i have no idea how to solve your problem.

well there could be a few things going on here. first did you run ldconfig since installing qt and its suppporting files? did you install developement/lib/includes packages? did you run ./configure --help to see if you can set the path to your qt location? (do you know where qt is installed) have you logged out then in since installing qt and related packages? generally if you have everything install for qt and it is in your $PATH and ld conf then it should be autodetected and if it is not then you have to determine if qt is in in your paths. (which could be as easy as logging in them out).

well likely all you have to do is symlink the java modules to the right mozilla directory. when you installed 1.6b you broke/orphaned the old symlinks. it is a really easy task to do the symlinks and infact the mozilla plugin page should tell you how to do it. using a prepackaged version of the plugin (ie a current rpm) likely may not work if the install paths are not not matching where they should install to for 1.6b. basically my guess is that it is NOT a bug with moz.

um a security distro that uses unstable sources (yes i realize unstable is not necessarily referring to the actual source) that "may break" your system? that's pretty halfassed.

why does linux have to be user friendly DOlson? i am no fricken linux whiz nor have ever been but i know when it is more beneficial to do something my self instead of the computer holding my hand. you mistake hardware detection and gui this and that as user friendly. what most people are promoting is laziness and lax system security. if you have the sytem do everything for you in linux you are completely screwed if you pretty little detection system gets screwed up. what will you do when your x breaks? it is not fricken ahard to be aware of what your system contains and it takes about the same time to set up your system if you know what you have as it does to have some stupid system detect your crud via some slow interface. really take your head out of your butt. user friendly only comes with user experience and good documantation not some stupid ass tool

argh! damn progeny. all it sounds like is they want to make a windows like installer and system. taking the thought out of module loading (automating it) and automating hardware detection is stupid. the less people know about their system the more they depend on other people and the more likely they are to waste too much money on useless techs. does linux/*nix need standards? yes but not standard installer and standard hardware detection. i don't want a fancy installer or the installer to detect my graphics card, sound card, and so forth. i don't want some dumbass installer to turn on a bunch of service as a default (ideally NO services should be turned on unless a user/sysadmin says so). lsb.....they can get stuffed. the lsb has no ear for suggestions from smaller distros they just want to make the rules their way and as a result try and marginalize other distros who simply think what the big six do is ridiculous (ie starting turning services on as a default). there was a time when i would have liked what progeny is trying but now i think there are enough idiot systems out there and not enough idiot proof ones. thankfully the *nixes still make its users think for themselves.

Interesting - may well be worth waiting for that then. I did wuite like arch when I tried it. I couldn't get it working quite how I like for the desktop, but I reckon it might be perfect for my little server... i have a ftp install i586 port complete. see the announcement on the arch forum for some things to know.

i would like to see a 20% share .... but realistically on the desktop i cannot se it happening. most people out there do not want the hassle of *nix. and as for viruses.... they will come... not through the email but through exploits in the code. open code has it's drawbacks.

any bug local or not that allows user unlimited access is pretty serious. pc world though mostly reporting on ms stuff does report, in an unbiased manner, on other pc oses and and such. this article is pretty straightforward reprting what the problem was and what kernel it affected. i am certainly glad that there are some developers out there that are not complacent about linux security. most *nix users like spreading their own fud that *nixes are "so much more secure" than other oses. (in fact thay are pretty secure but humans program the kernels and humans make mistakes)

bah just switch to xfce4 already. you know you will anyway in time so skip all the pain and effort :P :P :P :D

So why do you hang out on a Mandrake Forum if you don't like it and don't use it? because it is way better than hanging out at justlinux or linuxquestions. too many people there have big heads. but back to 2.6. it think it would be unwise for any distro to use it default when it is first released. i can't imagine that they will quash all bug before first full release. there are things that just don't work with it, udev is very green still, etc. i don't even think my distro will go to 2.6 as the default kernel when it is full released. it just does not make sense. i am not inclined to use it until udev is better developed and i figure out why my first test of it killed hosed my system (i suspect a reiserfs bug). even 2.4 was not very reliable until later releases. really my issues here are not mandrake, that stuff was only mentioned in passing and with respect to some of your points. my issue is the kernel developers treatment of kernel components

well to be honest while i don't like fvwm myself i do have to admit that it is a hackers dream. most of the other wm do not offer as much configuration wise. there are boundaries in other words. fvwm is not like that. yes openbox is nice i used it for almost a year before i moved over to xfce4. i will likely look at openbox, ratpoison or fvwm for my i586 development box though. so thanks for making me think about fvwm again. nice screenies and a kudos on a good plug for fvwm ---- with most of the wm attention on the *boxes it is always nice to see fvwm and other wms pushed.

This is Cooker stuff we are playing with..... udev=experimental boil and bubble toil and trouble Did you hate Redhat Package Manager technology when it was developed? I remember all of us geeks knew that it was the downfall of Linux.... So far in cooker ml, everyone who has lost their mouse needed to have it identified as mousedev, and hotplg does manage it now. The test kernels in ml did not use udev, this is the first 2.6 kernel that does. Ahh, now I see you found it. Devfs and Udev are both loaded; devfs id kernel control, udev is userspace control. I had to change my radio to /udev/radio0 from /dev/radio0 to work. Had to add bttv to modprobe.preload to get TVTime to work with my tv capture card. When I boot back to a 2.4 kernel (to test and compare), all devices pointed at /udev/* still work. After 24 hours, I'm changing lilo now to this 2.6.0-0.1 kernel as default. Tim ah no you mistook what i said i was not referring to mandrake developers putting udev in the kernel ... i was talking about kernel developers having udev in the kernel. RPM....i came around after the advent of RPM. i quickly grew tired of it. RPM is and always will be a less intelligent means of packaging up a binary. now they are trying to make RPMs do more than it was ever designed for and it just is not working. RPM is old tech and should be retired. udev is a good concept and is functional to an extent but it needs work and as such it should be marked in the kernel config setup as expiremental and despite the cooker being an expiremental part of MDK i think it is very cavalier of them to use udev at this time. but i kind of expect that from mandrake as they are infamous for bells and whistles while functionality takes a hit. that is why i gave up on mandrake shortly after i started with it. actually i think it is high time the kernel developers started separating out expiremental features of the stable branch kernels (of course this comment does not apply to 2.6 test kernels). if linux ever wants to hold more than a five-10 percent share of the market they HAVE to start being a little more wise in how they handle kernel development.

fvwm is okay but is ugly. not that i need eyecandy perse but looking at its theme which must have been designed by a three year old hurts my eyes. the other problem i had with it is that the diting of files is not intuative enough. personally there are lots of other wm out there that are lighter faster and as configurable (like openbox2 and i suppose three but three uses xml in alot of their config files which makes it very tedious for editing) all that being said for control freaks fvwm would definitely be a fun thing.

in all the reading i have done on udev i just would not even bother with it. it far to lame to get anything done. i cannot believe they would not mark udev as experimental and just keep devfs as the main option for now. when i used 2.6 i skipped udev support altogether and just used devfs and i had no issues. you do have to make sure that you include /dev/pts and edit your fstab to use it. mind you this has nothing to do with your issues. likely having both udev and devfs loading is causing problems.

i ran 2.6 on a test box. did not notice any handling differences. i had it installled in a very sparse arch linux install. the only place i noticed a speed difference was boot and the launch of a few apps. but the speed difference were very very minor like stepping from an AMD XP 1800+ to a 1900+. i am sure those micro seconds would add up but it would take a long time. i think this kernel needs a bit of work both in the code and documentation. it should be a greatr kernel by 2.6.6 or so though which would be way sooner than 2.4 became stable

chmod u+x (or maybe just +x) <scriptname> to execute (in a terminal): ./<scriptname>

um when people used typewriters they made less spelling mistakes. hell they actually had to learn to spell. as for the strikers getting all caught up.....that was the seventies machines those got replaced in the 80's and nintied with those nifty balls. type writers never got viruses either.

/usr/lib/win32 if it does not exist create it (you likely will have to create the directory as root)