Continuing some tests, here on eeePC 1001xp (2Gb RAM) 3.7.3 E22 & USB/persistant mode:
Launched redshift, swapoff, conky, by Terminology...
Installed Tor, Vivaldi, Yandex (from witch I'm writing right now) all going well except some download windows that are too big and impossible to size down, even with the alt+pad trick, because in the poping menu, there is not the "resize with keyboard" option (that come sometimes in a context I didn't find for now)!
Having to stop the mouse in the borders & change screens only with the bar or keyboard shorts...
On my Precision's I'm thinking about -off course install fresh Elive- but testing Mint transformation to Elive, and CAELinux as well... Mint should be easy, CAE possibly more difficult due to the fact that it's an already integrated & optimized system (and I didn't know it really for now)...
A question: In order to, in the same time, fit this "new" installation with reiser4 (originally on ext4), what should be the best way for doing it..?
I imagine to do brand new install of those directly with reiser4 before transfiguration by Elive, but the "best" problem is to morph already used/fitted/setted systems to Elive/reiser4..!
Not in 3.7.x ? I tried to copy my photos from the iphone in the windows computer unsuccessfully, then I tried from the recent Elive and it worked like a charm
cairo-dock overwrites it (just move it upper then) unless you are running the desktop with the composite option
nope, there's not a lock feature in e16
Just uploaded with the remaining tasks for it should be a much better (more stable & fixes) version with also fine-tuned things, like cairo-dock default settings and other preconfigured things. @zbd I assume this version fixes all the "low ram" issues with the installation and deals it much better
installer? I assume you mean "live boot" (after first boot menu), you cannot boot the 64bit version in a computer that doesn't supports 64bit (most of netbooks in fact lol)
IMPORTANT: DO NOT USE BTRFS !
it is dangerous and unreliable filesystem even in these new version, your data is in danger (i had a second forced shutdown and lost my partition, being entirely unrecoverable), so bad btrfs...
try with 3.7.4, there should be fixes for these low-ram cases, also don't use btrfs
hum, this is curious and should not happen... but i added a code to make a second attempt on these cases (3.7.4)
mmh that's right, from internet seems like the cpu has 64bit, maybe is a bug in kernel (or grub/loader) autodetecting the cpu or maybe a bios option, curious in any case
(@Rebel450): I had issues using the 390 version too on one of my computers, not sure where is the problem (maybe kernel version, maybe nvidia drivers...), but if somebody knows with certanity that this version of nvidia drivers works for its card, could be good to know if the issue is really with this version of driver (that should work with this version id). Note: 3.7.4 could have updated drivers if they were updated from debian
@triantares@Rebel450 : im lost about the suggestion to remove the nvidia drivers from install maybe i didn't understood the point, but as explained in another place, the actual behaviour is:
user boots in Live mode (as much as he wants) selecting free or privative drivers (since this is the first boot tests, he will know from this point if the privative or the free drivers works better for him)
when the desktop has started successfully (and only after that, which means "drivers correctly working"), the user can install elive on HD
the same settings he selected about his nvidia are used for the installed system
and this (the last line) is IMHO the best option because ensures that the drivers correctly works, doesn't needs to ask anything to the user, will make sure that will install the same way, etc... so what if the user don't want to use privative drivers? well, just boot with the free drivers option in live mode before to enter to the desktop and start installing other thing than "autodetected / autoselected" would be a complication for the end-users
hum, i wonder if this was due to a recyclated (previous OS) conf in /etc, or by an automatic printer configuration detection (which if im not wrong there's an automatic configurator somewhere in elive) or... maybe something like that
mmh yeah, they are created on new user but not when migrating users (that doesn't has it), mmh, noted to improve in the installer
noted, that will be improved too for next builds (wrong "default WM" set)
mmh but that should be a good default case for computers that has touchscreen (only), and i dont see a way to autodetect it
@triantares this is useful info, you could move that post entry to a howto page
in fact looks like the entire "dbus" connection is lost after suspend (hibernate specially?), not sure if is a e16 specific issue, probably the dbus address changes and the desktop doesn't reach it anymore, this causes multiple issues bettween applications like probably touchpad connection
or.. maybe the touchpad just doesn't correctly restores after suspension (hardware specific cases)
maybe a bug from debian-upstream, hopefully fixed for their buster release (which is near) - note: try apug to see if updates fixes that
it requires swap, but IMHO the implementation is wrong and it should create a temporal file in the / root filesystem with the space required to store the ram contents and then hibernate (this won't take more time than just write in swap, in fact), maybe a future feature for elive lol
that's a beautiful wallppaer makes desktop look powerful
@Terry_Rosinski : I had data corruption due to using btrfs and I was working on recovering everything... also I was moving to colombia for 2 months
elive-skel upgrade .config/cairo-dock
the second will update your cairo-dock with improved settings, the third is a own feature for the autolaunched applications
btw as an option we could also just improve the e16 code to add the feature
even better than the e17 experience on elive 3.0 stable ? it is really well featured! (but may feel a bit slower)
added "alt + f8" for that, if you apug and restart desktop configurations
btw e16 allows you to have windows (bigger than screen) shared between their multiple desktops, so you can go back/from them and reach the other window elements
mmh, but i dont see the relation of these window sizes with e16 / elive, they -should- be already small (autoconfigurations for font sizes)
check the comments in the 3.7.4 betatesting page, but if you want to move, you should do a clean install and then copy the files
windows are too big in size, not only on small displays;
if needed I could forward a screenshot (?)
@triantares and me, @Rebel450 meant - remove the whole (Nvidia) alien driver install OPTION from the installer at all - (even on Debian it's already a desaster to find and install the correct driver variant for the Nvidia cards!)
The by default installed video driver (noveau) works fine in nearly all cases,
so there is need to struggle with hundreds of possible video options - THIS IS NOT OUR BAG OF POTATOES -
= the effected users can install their alien drivers by themselves better,
after the main install process and they are on a well running system!
The target : Sytem is running with acceptable results on video
is already reached - without fighting with Properitary! drivers - after the system install !!!
Sorry, but these are (outdated) useless efforts,
which leads in many cases to a system with showing just the prompt....
= EXACTLY -- why spoil everything with risky optional drivers ?!??!!! = NO
just leave it behind - or you want to become also a Nvidia driver specialist?!
Even Debian sucks here badly - leave it...
and - these driver are NON_FREE drivers at all - so why the f**k ?!
yes, make a screenshot so i dont understand why they should be big, so they should be auto configured to best fit
nope, only -some- cards, users will always need to have the nvidia privative drivers option available and easy to install, also, multiple screens doesn't works with nouveau, only with privative
i still don't understand the wanting to remove a feature, which is entirely optional and asks the user "do you want to use it?"
that's what the live mode provides, in an easy and guided way that doesn't needs users to know how to use the terminal or similar stuff, also, installling these drivers by their own is extremely difficult for most of users, it requires to be out of X and know some terminal things, also since the live and installed mode already boots in X there's no way to "not be in X"
if im correct, @yoda needs the privative ones, he should understand how good is to have this option this way, to not include these "do you want to use them" options will be extremely difficult for users to install them
and even worse: it will make lots of computers to simply not be able to run elive at all (computers which requires the privative ones)
i dont see any reason of why removing this optional (needed) feature should be an improvement
What I'm saying is: It's a minor adjustment to the greeter.conf (as "onboard" is allready installed) and could also be very helpfull.
Not only for touchscreens but wacom interfaces too or just with the mouse. On top it's a life-saver if you just spilt coffee or coke over your keyboard .....or if not sure you picked the right layout, before.
I don't mind adding a HowTo but putting it in the greeter.conf by default is alot easier.
As for detecting, which I still don't deem nescesary: How about "xinput", it should be running by the time one reaches the greeter screen?
It looks like dbus to me, I lose the mouse in e17/22 too. Alas I cannot recreate this thing consistently ..... it just sometimes happens. I've been waiting for it too happen again, so I can try out some things but it just doesn' t come up.
Wouldn't this only work if your partitions are not encrypted?
I was looking to get ALT,CTRL+L to work but haven't found a way yet, without using gnome-screensaver. How does the one in e22 work? i.e can' t that be implemented in e16?
On top I have some issues with the "restart" button on cairo dock......systemd doesn' t want to stop before waiting for power-management is stopped, which sometimes takes quite long .... up to 5 min,
As to the nvidia drivers:
This assumption is not entirely true. In some cases this leads to a black screen on reboot. That's what initially happened with my Haswell-ULT on 3.7.1 and again with QubesOs too.
All in all, it's just a matter of choice to offer the drivers in Live mode or later after Install. Either one has their pros and cons but I can see why you prefer all options available in live mode.
My thought was: When in doubt, use vesa/framebuffer and tackle difficult cards in a later stage or here through the forums or ..keira, of course.
it also works when there's encryption: system boots -> ask for unlock pass -> checks swap for restoring hibernation -> restore system
not really, in e17 / e22 it works because uses an emodule for that, the EFL libs gives a lot of possibilities but e16 doesn't use EFL, they was created after e16
then we are talking about a different bug... if works on live it should work on installed, the same drivers are used, etc..
if you can reproduce it, please tell me so we will check why they not works
and yes, in such case is an important bug (unable to boot the installed system for these nvidia cases)
That's way to intricate anf long for me. Half way through I've allready forgotten the initial defs.
All I'll do is break everything.
Interesting all the same ..... maybe I'll have a bright moment and see the [en]light[enment].
It just happened!
Waking took a very long time ..... I just had a black screen.
CTRL,ALT +F1 took me to tty1 where I did some reading of logs. Tried F7 again and screen came up.
But no touchpad, touchscreen works though.
Tried a few things but removing and adding the module "psmouse" did the trick.
"sudo modprobe -r psmouse" to remove it
"sudo modprobe psmouse"
mmh, but this sounds more like a hardware-specific issue, like having difficulties to restore the hardware things, im pretty sure it only happens on that machine, this should be probably fixed with newer versionf of laptop-module-tools or acpi packages
about dbus, you can see that by running things from terminal, like launching thunar (probably), you will have dbus errors, i have not tested this much btw
alright, the screenshot shows some suspend difficulties, maybe update your bios firmware?
or also, try to google for "machine model + suspend", you would probably found some acpi / udev rules to add for recover correctly from suspension (like your commands)
This could well be the case.
I have some strange behaviour on "shutdown" and "reboot" from the cairo dock too.
The machine stops short when shutting down, systemd waiting for a/some power management tools to shutdown. Giving it 5 min wait time. I can shorten the wait time, I know ..... but usually I don't wait and force it to stop through the power button.