My USB stick gives none of those errors.

This post discusses the Control Centre -}"Choose Startup Services" tool.

The wrapper script needs to be modified (employ a lockfile, or killall sysv-rc-conf prior to calling sysv-rc-conf)
to guard against launching multiple concurrent sysv-rc-conf instances.

"Why would a user launch multiple instances?"
Aside from fat-fingered / accidental double-click, consider that when user clicks"Choose Startup Services",
an inherent delay occurs (2+ seconds, tested on a 2.8GHz core2Duo w/ 800MHz RAM)...
which can lead the user to presume that"nothing happened" in response to first click.
Another"why": user (me) might get the bright idea to keep one instance open for reference, hoping to keep track of what the previous/default state was.

If user has already (within 15min?) authenticated via sudo, the wrapper script currently
launches sysv-rc-conf without presenting password prompt, yes?
I think that's how/why, on various occasions, I've accidentally launched of multiple instances...
...and (oops) upon realizing the double, click the titlebar X to close the second window.

Bug? Set aside the notion of concurrent instances and test just this:
1)"Choose Startup Services"
2) while sysv-rc-conf is running, click titlebar X to close the application window
In my testing, this (consistently) results in sustained 100% CPU load ~~ requiring kill by pid or sudo killall sysv-rc-conf intervention.

Along with suggesting a change to wrapper script, here's a feature request:
inject a scripted"sysv-rc-conf --list /documented/path" into the build-iso script
(and same would be beneficial within iso-snapshot and live-snapshot script)
so the user has a frame of reference (is cron supposedta be autostarted for runlevel 4? for runlevel 6?) can refer to the"as-shipped" state of startup services.

The sysv-rc-conf helpscreen mentions"press 'r' to view prior state"
but, pressing 'r' seems to abend the program.
sysv-rc-conf 2> ouch.txt:
"Can't call method 'userdata' on an unidentified value
at /usr/bin/sysv-rc-conf line 251."

skiddoo there is definently something going on with your install. Between these comments and your comments about the icons, there is something really wrong. Here's a screenshot of mine, default everything.

After anticapitalista pointed out"same iconset", I didn't post a followup but realized that fuzzy post was a mistake (and sleepheaded bad reporting) on my part. I now realize that those"nice big redX icons" are still present, but they are only displayed for removables, not for fixed drive partitions (different from my typical usage and past testing, HDDs are present on THIS test system)

dolphin, thanks for checking (and for refuting). You screenshot indicates IceWM? JWM?
Not that it should make a difference, but my observations were from a fresh liveboot (haven't messed with lxappearance) fluxbox session.
Or so I thought. Tomorrow I'll check"inxi -g" for that desktop box and will retest using another PC.

On a related note (inclusion of using"Other Desktops" menu item during testing), I was going to ask someone else to test/recheck this:
if I launch"dillo" from a fluxbox session then switch to IceWM or JWM via"Other Desktops"... and back to fluxbox, the dillo window creeps upward.
After a few switches between WMs, the window's titlebar winds up out of reach (offscreen, above the top edge).
I haven't tested this extensively, but it seems repeatable, and (somehow) possibly only affects the application window containing dillo.

I noticed that bleachbit is absent.
Wondering whether that's due to space limitations, or whether it has fallen into disfavor?

I'm content with the decision to omit spacefm, but wanted to mention:
if/when user installs spacefm package, its auto-generated desktop menu item"bleachbit (as root" {sic} winds up broken/malformed.

launch streamtuner2. Click edit -} properties

? missing font ?
I'm seeing placeholders (for missing unicode glyphs?) displayed for the"Channels" and the"Features" tab headers

usr/share/wallpaper

The following tweaks will shed 1.5Mb or so

Wooden.jpg 685Kb
--} mtpaint --} resave as jpg @85 --} 186K
To my eye, no remarkable loss of quality

shells-massage-therapy-sand 749Kb
--} mtpaint --} resave as jpg @92 --} 189K
To my eye, no remarkable loss of quality.
@85 --} 125Kb, but I'd error on the safe side and choose @92

sleek-antiX.png 168Kb
--} mtpaint --} resave as jpg @92 --} 39K
To my eye, no remarkable loss of quality

antiX-galaxy.jpg {notes missing}Kb
--} mtpaint --} resave as jpg @92 --} 15Kb
To my eye, no remarkable loss of quality
and can copy this smaller resaved version to the other places it's used (gfxboot? inside live-init?)

reporting a frustrating usability issue in iso-snapshot:
User has opportunity (button offered within iso-snapshot gui) to choose a custom destination directory during the workflow.
On the following screen, user has opportunity to edit iso-snapshot.conf
PROBLEM: clicking the"edit" button resets/erases the custom destination specified by the user (even if the conf file is just viewed, not actually edited).

After tripping over this tonight, deja vu... I'm fairly certain I reported this same issue when testing iso-snapshot prior to MX-15 release.

reporting a (non-reproduceable) bug in iso-snapshot:

Via the provided"browse" directory picker, I chose /live/boot-dev/snapshothere
but iso-snapshot choked, like that's a too-long pathstring.
The string wound up being truncated, with the final slash char of the path absent
/live/boot-devhere
and, alongside this malformed pathstring, the gui errmsg stated 'no such path'.

I renamed the intended target directory to something shorter, like"snaps" (sorry, didn't jot the exact dirname in my notes)
and iso-snapshot was able to successfully browse/select that as destination path (live/boot-dev/snaps)

edited to add: During later runs, I chose custom destinations bearing pathstrings even longer
than the (above) failed example, and iso-snapshot successfully used those paths.


additional notes regarding iso-snapshot use:

During operation, 300 or so error lines are spammed to the ui scrollbox"cannot change ownership to uid 0"
followed by a line stating"tar: exiting with failure due to previous errors".
The error message burrrrrp is non-fatal, but is confusing to the user. No"exit" happens; afterward, the ui informs it is proceeding with mksquashfs.

During some runs, iso-snapshot doesn't completely cleanup files from its working directory.
It may (especially if operation doesn't complete successfully) leave behind stray files pathed in e.g. /home/demo/snapshot/iso-snapshot-eVh8g/

--------------------------------

I also tested live-remaster (personal) and successfully booted afterward. I have not tested the"rollback" feature (and don't plan to, unless requested).

??? live-remaster... is the script which instructs"don't close this box, even if sez 100%"
Well, FWIW, following its 14 minutes (or so) of 100% CPUload churning... yep, it seemed to stop working.
No CPU load, no drive activity, no incremental increase in consumed amount of RAM.
I ran out of patience about 20 minutes later, and clicked to interrupt it.
dialogbox: ARE YOU SURE? ARE YOU REALLY ABSOLUTELY SUPERDUPER SURE YOU WANT TO QUIT?
I responded"No"
and it immediately"sprang back to life" (CPU load/activity resumed) reporting successful completion within 1 minute.
Coincidence?
It was actually working the entire time?
It was 45seconds away from successfully completing when I interrupted?
Naw, although I've rarely used this tool aside from occasional testing...
(I prefer to 'snapshot' instead, safekeeping a copy of the iso on another PC)
...it sure seemed like the script was"stuck in limbo, playing dead until I intervened".

skidoo wrote:I noticed that bleachbit is absent.
Wondering whether that's due to space limitations, or whether it has fallen into disfavor?

I'm content with the decision to omit spacefm, but wanted to mention:
if/when user installs spacefm package, its auto-generated desktop menu item"bleachbit (as root" {sic} winds up broken/malformed.

I'm going to assme you mean bleachbit, not spacefm. Just checking!

skidoo wrote:The default desktop theme has a usability issue specific to GTK3 apps (synaptic, roxterm) ~~ no border
(nor contrasting background color) is rendered for checkbox input fields. Unticked inputs are essentially invisible.

Two quick examples:
Launch roxterm. Open a second roxterm tab. Click 'X' to close the window (and observe the resulting dialogbox).
Launch synaptic. Visit the multi-tabbed"preferences" box (and note the"invisible" checkbox input elements).

I see something like this with Dark theme, but not with the default Light.

skidoo wrote:launch streamtuner2. Click edit -} properties

? missing font ?
I'm seeing placeholders (for missing unicode glyphs?) displayed for the"Channels" and the"Features" tab headers

I see this too, but not sure what the fix is.

skidoo wrote:usr/share/wallpaper

The following tweaks will shed 1.5Mb or so

Wooden.jpg 685Kb
--} mtpaint --} resave as jpg @85 --} 186K
To my eye, no remarkable loss of quality
...

Nice find __{{emoticon}}__

Testing 16-RC1 Live
Two minors details, a possible bug and a question:

1. When entering a new Live session after logging out the keyboard layout that one sets at boot reverts to QWERTY.
2. Libreoffice has Java activated by default but no JRE's installed. May also impact starting time
3. Installer won't display in fluxbox-* session (default boot options)
As shown in the screens below it starts but won't show. Killing it and re-launching makes it appears... in the dock. But only shows up if I force"Maximize". Quite awkward. Shifted to other desktop and only got that behaviour in fluxbox-*s.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/FGd.png"
linktext was:"http://pic.al/FGd.png"
====================================


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/GGd.png"
linktext was:"http://pic.al/GGd.png"
====================================


4. Install on a logical volume??
Installer does not recognize LVs.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/LGd.png"
linktext was:"http://pic.al/LGd.png"
====================================

Is there a workaround in case installing into an lvm2 setup is wanted?

Desktop choice impact on resources
Wanted to see how the desktop compare in term of resources and responsiveness.
- Fluxbox and JWN taxes the less RAM (default boot options)
- JWN felt particularly responsive I mean notably more than the others on my setup.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/CGd.png"
linktext was:"http://pic.al/CGd.png"
====================================

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/DGd.png"
linktext was:"http://pic.al/DGd.png"
====================================

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/HGd.png"
linktext was:"http://pic.al/HGd.png"
====================================


Hardware setup used for this test:
Good ol' Athlon 1GHz, spinning HDD, 1GB RAM (emulated via qemu-kvm & cpulimit)

Torrent
Please note the RC1_386-full ISO is uploaded to
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://linuxtracker.org/index.php?page=torrents&category=2007"
linktext was:"LT"
====================================
should go public any moment (available in LT's feed already)

EDIT
Responsiveness and RAM usage are nothing but impressive:
- Default with Firefox-esr, LO spreadsheet, Mirage and playing music: 250 MB
- Same with fluxbox: 230 MB
- Same with JWM: 240 MB
- Same with
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://pic.al/MGd.png"
linktext was:"JWM and Palemoon replacing FF: 190 MB"
====================================
(24% memory less than default).
These are only numbers but really say something though __{{emoticon}}__

{blush}
d_o, yes I meant bleachbit

spacefm, a few months ago I was tempted to suggest it should be pinned, at version 1.0.4 until or unless someone
rebuilt 1.0.5 to exclude the newly-added foofoo features (no thanks, I don't want auto-generated thumbnails of video files)
and the resulting (multiple libs, several Mb) package dependencies incurred by v1.0.5

Toward avoiding duplication of effort, I'll mention that I've tested the launchability of, via the desktop menu, all the RC1 preinstalled programs.
I haven't waded through testing all the ControlCentre launchers, but not much has changed within cc for this release, right?
Holler if there's anything specific which needs testing.

skidoo wrote:{blush}
d_o, yes I meant bleachbit

spacefm, a few months ago I was tempted to suggest it should be pinned, at version 1.0.4 until or unless someone
rebuilt 1.0.5 to exclude the newly-added foofoo features (no thanks, I don't want auto-generated thumbnails of video files)
and the resulting (multiple libs, several Mb) package dependencies incurred by v1.0.5

Toward avoiding duplication of effort, I'll mention that I've tested the launchability of, via the desktop menu, all the RC1 preinstalled programs.
I haven't waded through testing all the ControlCentre launchers, but not much has changed within cc for this release, right?
Holler if there's anything specific which needs testing.

we've got an tool for setting automount of usb devices in control center, which should work on the rox desktop as well as spacefm (doesn't rely on spacefm). There is also a set font size tool for changing the dpi of the display. It was meant for those with high dpi monitors, but I've come to really like the 120 setting even on my small screen.

I've edited and updated my earlier post regarding iso-snapshot. Ultimately, it successfully generated usable xz and gz -compressed isos.

page describes gtk theme checkbox bug I'm experiencing. Still, it provides no clue why we're seeing different results when testing same iso,

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://bugs.eclipse.org/bugs/show_bug.cgi?id=463733"
linktext was:"https://bugs.eclipse.org/bugs/show_bug.cgi?id=463733"
====================================


edited to add:
I've now booted to 3 different PCs using the RC1 liveUSB, one with radeon card, another with discrete nvidia card, another having onboard intel gpu.
FWIW, testing didn't apply cheatcodes, didn't involve non-default graphics driver, and same result ("invisible" checboxes) on each of the 3 PCs.

If we've downloaded a previous Alpha or Beta image and continuously updated, other than identification strings, should we have essentially the same software?

I think I have b2 @Home and in recent days/weeks, it has been running well. One distribution (Fedora 23) that I had been using to control the MBR seemed to have an issue - when updating it's system list, interactively it would list antiX 16, but after a reboot, it would display and select an old, no longer existing antiX 15 or 15.1 image. Curiously, if I would go to the GRUB 2 command line, say set root='hd0,gpt7', then chainloader +1 then boot, antiX 16's view of the distributions on the GPT formatted disk would appear, so I could get in.

More recently I put a stable version of openSUSE 42.1 Leap in charge, and it correctly identified each distribution and I was able to directly access antiX 16.

I've occasionally run across seemingly minor issues that are probably defects, but they've been difficult to isolate in the limited amount of time I've had available to test, and I've not reported anything because I've not been able to create a useful, reproducible defect report. But over the course of time, it appears that many (most) of the"minor" quirks have disappeared, so they've probably been reported and fixed for the most part.

If I can spare a few minutes, I'll try to grab the release candidate and try it out again. The installer, as far as the primary installation functionality, works fine. I tried a couple of the live options to retain content at various points. I had the most success saving the base configuration in a Frugal setup and saving a home directory in Frugal was also successful. I did not, however, inspect every possible combination or dig deeply for inconsistencies; it appears that a few people have done that reasonably well.

I agree that the software looks close to readiness and a few weekends of polishing and refining are quite likely to complete yet another really good, flexible system that allows you to start simple and extend a configuration in any direction you want - Frugal storage for removable images, full installations of light, intermediate, or full-featured software, so I am very confident in the direction the work has taken and I use it frequently, even in the test configuration.