anticapitalista wrote:If we go down that road, why not just use the version in antiX jessie with your fixes?

skipped past that possibility b/c you had already mentioned"it wouldn't build"

skidoo wrote:

anticapitalista wrote:If we go down that road, why not just use the version in antiX jessie with your fixes?

skipped past that possibility b/c you had already mentioned"it wouldn't build"

It wouldn't build on stretch ie I mean creating a fresh deb. The one on antiX-16 installs just fine on a-17.
I'm tempted to go down this route, not exactly through pinning, but by renamimg the deb as an epoch version. Not quite sure how to do this exactly, but stevo over at MX Linux does. This would avoid 'possible' messages from synaptic about 'you have held packages'.

Re - conky. I'll need to think more about this. conky-legacy sounds the way to go though and make it conflict with conky (proper) so anyone who wants the lua added bloat can install it.

More work *sigh*

serving conky-legacy is a great idea, IMO.

noobslab did so 3-4 years ago (offered a package)
in order to continue supporting the gobs of pre-existing conky configs which are in wide circulation

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.noobslab.com/2012/07/conky-collection-for-ubuntulinux.html"
linktext was:"http://www.noobslab.com/2012/07/conky-c ... linux.html"
====================================


related thought:
SparkyLinux (or, izzit Voyager?) ships a"conky manager" utility which I had grabbed a copy of, with intent to
mebbe someday modify and repackage. I can't recall whether it manages legacy, or new, or both.

If conky-legacy is offered the maybe gufw should be ported in the same way as gufw-legacy.

skidoo - could you check that gufw in antiX jessie repo does in fact work as you wanted it too. Thanks.

anticapitalista wrote:check that gufw in antiX jessie repo does in fact work as you wanted it to

Prior to posting the earlier message, I did perform the steps I described.
I can confirm that it"works identical to how it worked on antiX16".

Only reason I patched was in response to multiple help requests/inquiries bemoaning"it always sez OFF".
How I want it to work... is moot.
I wanted a windoze-y type app, one that displays notification bubbles when logged events are triggered
so created (and am using) this: {edit: link removed}

More work

Back during the alpha, when you 'splained"will no longer fit on CD", that's when *I* sighed.
I don't boot from CD, but the notion of striving to support folks who still do seems like a noble mission.

Repeating what I opined back then, avoiding webkit bloat (by not caving for sake of shipping gufw) is half the battle won.
Also, I'm still willing to supply a list of HUUGE"example" files bundled into LibreOffice, which can be culled by the build-iso script...

skidoo wrote:

More work

Back during the alpha, when you 'splained"will no longer fit on CD", that's when *I* sighed.
I don't boot from CD, but the notion of striving to support folks who still do seems like a noble mission.

Repeating what I opined back then, avoiding webkit bloat (by not caving for sake of shipping gufw) is half the battle won.
Also, I'm still willing to supply a list of HUUGE"example" files bundled into LibreOffice, which can be culled by the build-iso script...

I doubt that even with all the changes, the iso will still fit on a cd. I would be very happy to be proven wrong on this.

I would be very happy to be proven wrong on this.

are you still doing core/mini-or-whatever/full versions? because if youre not, i can probably make a cd-size version of something. once i know what the plan for 17.x is, i can stop asking this question (thats not an ultimatum, more like an ez-help guide.)

figosdev wrote:

I would be very happy to be proven wrong on this.

are you still doing core/mini-or-whatever/full versions? because if youre not, i can probably make a cd-size version of something. once i know what the plan for 17.x is, i can stop asking this question (thats not an ultimatum, more like an ez-help guide.)

We have net, core, base and full. All used to fit on a cd. Now, full is 808MB. Base is c 600MB (not uploaded).
My doubt is that all the apps we include on full iso can still fit on a cd. I have tried to do this hundreds of times, without success. Stretch is bloat compared to jessie, just like jessie was bloat relative to wheezy. It seems every Debian version upgrade adds around 100MB even when using exactly the same apps.

i definitely get and appreciate what youre saying-- before s5d took over i was relying on wheezy for practically everything.

im curious (and capable of figuring out) exactly what full has that base doesnt; and at least as curious what skidoo wants in full that isnt in base. though its possible he just thinks its nice when everything fits on a cd-- i agree. i removed things from refracta until it fit on a cd, later the official version got smaller too.

i understand this may not work out per your preferences. it sounds like base is probably good enough for cd users, i almost chose it over full myself.

Eyeballing the LibreOffice clipart samples directories again, I'm feeling deja vu ~~ I'm now vaguely recalling that when I suggested this previously, anticapitalista tested & found that those svg et al files are highly compressible....

@figos,"sudo locate installed-files.txt" ~~ a package manifest is shipped in the iso.
Can diff the manifests of base (whichever fits on CD) & full... and supply a script which installs the remainder atop base.
User could liveboot base from CD, run the remainders script, selectively purge THEIR CHOICE & generate a CD-sized remaster.
A Tips-n-Tricks topic can coach DIY removal of unneeded locale -related files prior to snapshot (shaves 80--90Mb from full iso).
Someone recently posted to ask"how can I know if it will fit?" and the rule-of-thumb response I read was"approx 2.6GB, when compressed, fits on CD".

the compression is squashfs though, yes? meaning that antix 17 (like 16, as ive already decompressed, altered, and recompressed both simply for a lark to get those screencaps) is already compressing them.

i think i use xz compression when i dont have"fastcomp" set to 1 for just trying out changes, implying that if a.c. compresses them one way, they will only be less compressible when it goes to the squashfs file. IN OTHER WORDS, i cant figure out how compressing the svg clipart can change the bottom line here.

what would be really cool is a way to get the compressed size for each each file. we generally create the tar and then compress, so when we retrieve the compressed and uncompressed size (using unxz -list for example) we only get the tar size/summary rather than the compressed size for each file. the best we could do is uncompress the whole thing, compress each file individually and note the new size. unless theres a fancy script to do that per-file, which i think is also possible.

The native Firefox in AntiX 17 Beta is a lot slower opening than it is in AntiX 16.1 .
Using the same laptop, just swapping the SSDs.

firefox esr in stretch (and antiX-17) is awful, I agree.

antiX-17 will ship with legacy versions of conky and gufw to save on bloat (c12 MB saved on live iso size). stevo over at MX Linux has kindly build the debs. Those users that prefer the shn (shiny new shit conky/gufw bloat) will still be able to do so.
Only drawback is making sure you use a correct .conkyrc for the legacy or lua version.