Hello:

Not so much.

I'm sorry to have to report that I made a mistake when evaluating my results.

The line I added to the manager-settings.conf has no effect on how wicd starts up.

I installed wicd-curses but there's no option (I can find) that does what I want to do.
ie: that Wicd does not switch on Wi-Fi at  boot time and uses just the wired connection.

Sorry for the confusion.  :^ /

Cheers,

A.

Hello:

No ...
It is not in "Preferences" but that's because not all possible settings are represented in the GUI.

In /etc/wicd there are three configuration files which can be opened/edited (as root).
The one that has the settings reflected in Preferences is manager-settings.conf:

[Settings]
backend = external
wireless_interface = wlan0
wired_interface = eth0
wpa_driver = wext
always_show_wired_interface = True
use_global_dns = False
global_dns_1 = None
global_dns_2 = None
global_dns_3 = None
global_dns_dom = None
global_search_dom = None
auto_reconnect = True
debug_mode = 0
wired_connect_mode = 1
signal_display_type = 0
should_verify_ap = 0
dhcp_client = 0
link_detect_tool = 0
flush_tool = 0
sudo_app = 0
prefer_wired = True
show_never_connect = True

I saw the wired_connect_mode = 1 line and guessed that there probably was a possible default setting ie: wireless_connect_mode = 1 which would accept the value 0.

I added it and it worked.   =-)

So:
Open manager-settings.conf (need to be root) and add the line wireless_connect_mode = 0.
That will have Wi-Fi off when the app starts and will survive a reboot.

Of course, you can turn Wi-Fi on again but it will not survive a reboot unless you either delete the added line or set it to wireless_connect_mode = 1   

Cheers,

A.

Hello:

Hmm ...
Please check the thread, specifically my second post:

chris2be8's suggestion to chmod 755 /var/log/lost+found could not be easier to implement as it stops the error messages generated by conky by allowing it to access the file.
These error messages were the sole cause of the huge .xsession.errors bloat, so it seems to me that it is the simplest solution. (as always, YMMV)

The crontab solution you suggest controls the size of the .xsession.errors file but generates another set of logfile entries (three lines in auth.log instead of the single line in .xsession.errors we had before) every time conky tries to read the file (every 2 sec.), so it actually makes things worse.

The alternative to stop logging sudo access to auth.log (would not know how to do it) does not seem healthy.

In any case, I set it up because it is a good idea to keep the .xsession.errors file at bay, in my case at 30 minute intervals, a max of 2Gb and min of 1000 lines which would seem to be more than adequate.

Thanks for your input.

Cheers,

A.

Hello:

I see ...

OK

Fortunately I recently learned (here) how to properly generate a sudoers file.
Done.

Just to check:

groucho@devuan:~$ conky
conky: desktop window (1800003) is subwindow of root window (728)
conky: drawing to desktop window
conky: No compatible double buffer extension found
conky: drawing to single buffer

Now my .xsession-errors file will not get filled up with 18Gb of '/var/log/lost+found': Permission denied errors.

Edit:
This solution, neat and efficient, has nevertheless spawned another log overpopulation problem:

Every time

exec sudo du -sch /var/log

is run (every 2s), three lines get written to auth.log.   
This makes absolutely perfect sense as it's exactly what auth.log is for but it also means that auth.log will grow three times fraster than .xsession-errors grew. (!)

Oct 13 12:17:49 devuan sudo:  groucho : TTY=unknown ; PWD=/home/groucho ; USER=root ; COMMAND=/usr/bin/du -sch /var/log
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session closed for user root
--- snip ---

I think I may have seen a fix for this but I'll have to look and get back.

In the meanwhile, do you have any ideas as to how to cope with this?
I will temporarily go back to where I was before the fix to conky to keep log growth at bay.

Thanks in advance.

Best,

A.

Hello:

I sort of toyed with the idea before I realised it was way over my head.

I have the code that came with the *.deb I once downloaded.

Yes.
It seems to have been abandoned.

I once contacted the developer/maintainer/website and at first it seemed that something would happen, maybe just the necessary update so that it would be useful again.
But that did not go through.

Blackberry Desktop was only available under MSWindows and unbelievably did not have an address book, so you were stuck with syncing to POS Outlook Express and nothing else.

The grace of this very simple Barry Desktop app was that you could download -> edit/modify -> upload/sync the address book/contact information and even make a backup under Linux.
Maybe that was the reason it was dumped?

I recall that there were a set of libraries (OpenSync?) that stopped working at some time so that was a problem for some part of the app, but the download -> edit/modify -> upload/sync for the addrerss book worked fine.

Edit: (5' and some memory juggling later)
I now recall that the problem was with the syncing libraries due to the demise of the OpenSync framework (or something to that effect).
But you could browse, modify and save the contact database to the unit as well as make a backup so it was really very useful.

I don't get it ...
My trusty Palm IIIxe is still running strong and if anything breaks or I happen to lose it, I have an extra one + a box of full spare parts to put one together in under 20' if needed, just need 2xAAAs.

And j-Pilot is mature and still going strong at v1.8.2 with a great following.

As for the 9320 Curve, I just cleaned up three years worth of grime and replaced the case.
Good as new.

But it seems that I'm stuck with doing the XP/OE/BBD dance in my Devuan VBox.

Thanks for your input. 

A.

Hello:

Thanks for the fast reply. :^ )

I see.
I would have thought it was read from 'somewhere' in the filesystem.

Not to mention that the issue would rise once again on an update of said binary.

Done.
Not what I sought to do but it works.

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i ww
[   509.446] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   509.447] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   509.447] (WW) Disabling Keyboard0
[   509.447] (WW) Disabling Mouse0
[   509.500] (WW) Unresolved symbol: fbGetGCPrivateKey
[   509.500] (WW) NVIDIA: The Composite and Xinerama extensions are both enabled, which
[   509.500] (WW) NVIDIA:     is an unsupported configuration.  The driver will continue
[   509.500] (WW) NVIDIA:     to load, but may behave strangely.
[   509.500] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the
[   509.500] (WW) NVIDIA:     X server.
[   510.975] (WW) NVIDIA(0): Not registering RandR
[   511.046] (WW) NVIDIA(1): Not registering RandR
[   511.174] (WW) NVIDIA(2): Not registering RandR
groucho@devuan:~$

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep fonts
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/cyrillic,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
groucho@devuan:~$ 

Nah !

I fully agree that the warning is indeed harmless.
But I am one of those people that opine that if the warning is there, it is because whoever wrote the routine thought it best to put it there and label it as a warning (WW) and not as default setting (==), for example. So it should be taken care of.

These things are like dust: harmless but eventually they pile up too high and then they clog up something.

We're always bitching when some routine goes south and there's no indication of what went on.

Thanks for your input.

Cheers,

A.

Hello:

Welcome and thank you. :-)

OK.
Nice sampling.

Seems something common then?

I went Ubunbtu -> Mint --> CrunchBang --> PCLinuxOS, allways two at the same time and got here for the same reasons with the exception of # ! which Newborough (developer) gave up on. 

So I plan to stay here for the long run.

Same here.

But there's a problem at boot time, right before the desktop comes up: on two of my three monitors I get artifacts made up of a sort checkerboard type design in black, grey and white square/rectangular portions of different sizes which last a few seconds.

Apparently no big deal but it is rather annoying.

I think it is (?) a problem with the package or the driver version used in the package because I did not get them (error in dmesg or artifacts) when I ran PCLinuxOS on this same rig. ie: exactly the same hardware but using Mate instead of Xfce.

Do you get any artifacts like the ones I am attempting to describe?
Maybe it's an issue due to the three monitor setup?

Ideally it would be good to know the origin of the error and act upon that.

Thank you very much for your input.

Cheers,

A.

Hello:

Well ...

1.

2.
Once I found out that the one I wanted was Firefox-55.0.glibc2.3.4-x86_64, I went looking for it but the repo jumps from 52.9 to 60.4.

That's about it.

Cheers,

A.