I now see there's no default"foo" user account. Sorry about the bad report.

Regarding permissions, as a followup to what trutyka mentioned, I tested this:
controlCentre --} ManageUsers
After creating a new user account, browse to the newly-created /home/newusername path
and note the permissions ~~ most everything is world-readable (which is probably too generous, overly lax)

Found that viewing youtube itty bitty box on a forum I mod at does not hurt the iBM T23. Size of embedded window below. Plays snappy and sharp.



This is with iceweasel open even. Swapping out the hard drive tomorrow. Will give Semplice 7 a go and see what I will see. I figure a hard drive full install is a true test vs a live session run.

Semplice will run inxi so I can show what is being used on what.

Edit: Ran smtube from command line just for grins.
Damn. Hurt my feelers. __{{emoticon}}__

Using space-openbox, obconf is shown in the menu but is not installed.

(I feel it should be installed if space permits.)

Chris

Where/How did you get the space-openbox option?

anticapitalista wrote:Where/How did you get the space-openbox option?

Doh! Sorry Anti, I'd forgotten I had test-installed LXDE, which presumably brought OB with it.

It looked a good combination though...!

I'll do a fresh install before I do any more testing.

Chris

Just a update so far. Swapped out drives after uploading certain backups to the cloud.
Semplice 7 = pretty spiffy opening screen then hard freeze. They sure have changed the looks from what Little I saw.
BBQ Linux Cream = No matter which of the multitude window managers I try and boot into. Lockup and freeze kicks in also.

Even> Puppy Slack0 5.9.3 made me reconfigure xorg and roll with vesa. The savage driver was making things slow.
Right now using Puppy Legacy 2 and xorg is cooperating. But. Kernel 2.6 does not have the ralink module and I needed to
transfer by usb a new wpa2 script made by the developer John Biles into / so when I find a .pet file for the wireless.

I can do a test for his stuff while figuring out my my stuff. Pretty stubborn? Huh?

My AntiX 15 rc1.1 hard drive is in the laptop bag for the moment. But it is looking like AntiX is the bees knees for these
unsupported savage chips. Every distro I have tried that loads the savage drive. Locks up.

Would it be possible to include bash-completion in antix-15 final?

On my antiX-15-RC1 harddrive install I temporarily enabled the devuan repo and installed it's 1:2.1-4.1+devuan2 version bash-completion package.

The Debian Jessie 1:2.1-4 bash-completion isn't installable.

kmathern - RC1 was superseded by RC1.1 which no longer uses the devuan repos precisely because bash-completion does not install. In RC1.1 bash-completion is installed.

anticapitalista wrote:kmathern - RC1 was superseded by RC1.1 which no longer uses the devuan repos precisely because bash-completion does not install. In RC1.1 bash-completion is installed.

Okay, I hadn't seen that mentioned in the RC1.1 changes.

I just downloaded RC1.1 and bash-completion is installed.

Min-WM Desktop Colour


Ref uppermost of snapshots in attached graphic.
In a min-[icewm|jwm|fluxbox] session, using home and root persistence, the desktop is set to a single (solid) colour. This is displayed as expected.

A save is performed during shutdown.

Ref lowest of snapshots in attached graphic.
At reboot the min-WM session is started OK but the desktop colour setting fails and the desktop is displayed as black. The setting is known to the system i.e. it persists across the boot up. Upon opening the No Wallpaper section of the antiX Wallpaper utility, the wanted colour has been retained in the utility interface, demonstrating it survived the reboot, but it is not applied.

cat /proc/cmdline The attachment desktop_colour_pre_and_post_boot.jpg is no longer available

SamK wrote:Min-WM Desktop Colour


Ref uppermost of snapshots in attached graphic.
In a min-[icewm|jwm|fluxbox] session, using home and root persistence, the desktop is set to a single (solid) colour. This is displayed as expected.

A save is performed during shutdown.

Ref lowest of snapshots in attached graphic.
At reboot the min-WM session is started OK but the desktop colour setting fails and the desktop is displayed as black. The setting is known to the system i.e. it persists across the boot up. Upon opening the No Wallpaper section of the antiX Wallpaper utility, the wanted colour has been retained in the utility interface, demonstrating it survived the reboot, but it is not applied.

cat /proc/cmdline

Code: Select all

nosavestate vga=788 persist=root!,home lang=en_GB quiet splash=off disable_srv=LX

desktop_colour_pre_and_post_boot.jpg

confirmed on installed system as well.

additionally, if you then move to a standard icewm setup, the selected color is used.

the same is true for min-fluxbox and min-jwm.

my first thought is that desktop-session does not utilize the home user desktop-session wallpaper configuration for the min* wms, but rather the version in / etc/desktop-session/wallpaper.conf.

I asked Dave about this and he said:

When choosing a min- option nothing is started but the window manager along with the xdg compatibility / desktop code variables being exported. All startup stuff like the window manager startup, conky, desktop-session startup, xdg autostart, wallpaper, menu building, file comparison, etc is all disabled.‎ So the wallpaper is not even existent, he is just seeing a blank X sessions screen with a window manager.

So it's not a bug as such.

Re Min-WM Desktop Colour

anticapitalista wrote:... just seeing a blank X sessions screen with a window manager.

So it's not a bug as such.

Whatever term is used to describe the matter, it represents a loss of useful functionality in antiX-15 compared to antiX-13.2.

The following screen shots are from antiX-13.2. IceWM is running without ROX or SpaceFM desktop management, which is pretty close (can be more-or-less equivalent) to min-icewm in 15. In this state in 13.2 it is possible for the user to decide what should be enabled or disabled, including the desktop colour. In 15 this is no longer offered.

Displaying a single solid colour often has an extremely small RAM cost compared to the use of a graphic file. It is both a viable and useful tool that enables the user to choose and manage the way in which their system is set up. It is particularly relevant when using older, less capable kit, which presumably is one of the main targets of min mode.

Every other mode of antiX (including console) enables some form of management of the backdrop/background. Forcing the position of having no choice for min-WM mode is a less than even handed approach and is an unnecessary restriction of user choice. These scripts are antiX specific tools over which we have control.

Ideally, the min-WM mode should represent a base platform upon which the user has the option of switching on whatever they wish. It should include their choice of backdrop being retained across reboots. This functionality is present in the current stable release and should be retained in forthcoming release.

Illustrating backdrop colour retained across reboots in 13.2

Illustrating backdrop colour retained across reboots in 13.2

min- option does not give user the option to set a desktop background.

If you want the same functionality as in antiX-13, you need to choose the icewm option and change etc/desktop-session/desktop.conf to use:

NOTIFICATION_DIALOG="false"
LOAD_STARTUP_FILE="false"

or if you want startup, just edit the startup file in etc/desktop-session and comment out what you do not wish to autostart.

Here is antiX-15-full (final), running root persistence and a background colour selected and kept on reboot.

As anticapitalista says,
Min mode is exactly that boot the minimal amount of items but still leave a usable X windows with a window manager. Yes it is more for the machines that cannot boot the default setup or if the user incorrectly edits the configuration files they could still use min mode for try and fix. Really I guess you could rename it safe-icewm/jwm/fluxbox.