DebianDog - Jessie (21 June 2017)

[fredx181]

Don`t know the "Drama " behind the curtain

You are not the only one.
I think nobody knows, except Toni himself.
Can only guess what he means with:
"pretending so well you have nothing to do with my decision to leave the forum", because he didn't say what "I have to do with it".
I only know what happened in the mintpup thread (the discussion about memory usage reported compared in mintpup and xenialdog).
Of course I wasn't the nicest person at some point in that discussion... but I don't think that's his reason only to leave the forum.

Thanks for your support.

Fred

[fredx181]

The only option left is to find a way to restore justice and bring Toni back. Here's one aspect, I'd like you pay attention to: when Toni mentioned competition in that exchange, you failed to see the bigger picture. There was no competition in that particular exchange. But there was and still is competition between the original DD project and DD Porteus. As paradoxical as it may sound, Toni made a huge mistake by allowing Porteus Boot into his project. In the end Porteus Boot just sucked out all the oxygen out of the whole project. That's what, you guys are failing to see. That's what needs to be reconciled. Mind you *reconciled* - not rejected one in favor of the other. Let's go back to square one.

You might have a point, suppose you're right, I think that Toni first needs to open communication again.
Anyway I can live with a DebianDog without porteus-boot.
Probably it's too late, too much has happened.

Fred

[backi]

Yes.... remember this fucking ram usage thing .

In Xenial Dog... Htop showed ram usage on my machine quite high ...so i asked if anybody else could confirm .
Suddenly things went out of control .

Never understood why Tony felt so offended.....
Since that point i feel somehow confused and guilty .
I shouldn`t ....But i do .

Let me steal some Lyrics from Pink Floyd :

How I wish, how I wish you were here.
We're just some lost souls
Swimming in a fish bowl
Year after year
Running over the same old ground.
What have we found
The same old fears.

TONY.... Wish you were here.

I wish Tony would come back ....and we all become friends forever.

Let there be Peace on Earth

[fredx181]

Since that point i feel somehow confused and guilty

Don't!!! period.

Fred

[fredx181]

OK, let's continue with the "community project"
(well, to be honest I really am confused about the future of DD, but can't resist to reply on something I find interesting )

rufwoof,
Is there a hidden meaning in your remastering concept?
I'm thinking at the top of my mind and can't get the gist of it. Please, don't get me wrong, but remastering is a very basic thing. It boils down to the following:
1) You remaster to preserve the changes to the system without *any* save/persistence options.
2) Or, alternatively, you preserve the changes via save/persistence options.
It's that simple, a binary choice: either remaster, or use persistence/save, but don't mix them together. I remaster a lot and use Toni's remastering script, that he created a long time ago at my request (see the attachment). It is extremely simple, but works flawlessly not only on DD but any Debian/Ubuntu live. Fred has a GUI remastering tool, that also works nicely.

I think it's a nice concept that rufwoof has made.
Suppose you choose to save to file/folder several times and at some point you want to make remaster with the changes included, then the advantages are:
- very quick, no copying done, just mountiing using aufs to overlay main filesystem.squashfs + changes (and LZ4 compression is very fast).
- the main filesystem.squashfs will instantly be "replaced" (automatically add new entry in filesystem.module file), no manual copying/replacing required.
- The changes will be deleted (after reboot) so no hassle to do that manually (after all, the changes are already included in the remaster, so should be removed from existing save file/folder).

As it is now it only supports changes folder deletion but I'm working on it to support also deletion of savefile contents (e.g. changes.dat) after remaster.

Fred

[backi]

Cool way to remaster .Very simple and useful .
Good explanation of that concept ..

Let "us" get back to our senses again after this "shocking" incident .

[dancytron]

OK, let's continue with the "community project"
(well, to be honest I really am confused about the future of DD, but can't resist to reply on something I find interesting )

rufwoof,
Is there a hidden meaning in your remastering concept?
I'm thinking at the top of my mind and can't get the gist of it. Please, don't get me wrong, but remastering is a very basic thing. It boils down to the following:
1) You remaster to preserve the changes to the system without *any* save/persistence options.
2) Or, alternatively, you preserve the changes via save/persistence options.
It's that simple, a binary choice: either remaster, or use persistence/save, but don't mix them together. I remaster a lot and use Toni's remastering script, that he created a long time ago at my request (see the attachment). It is extremely simple, but works flawlessly not only on DD but any Debian/Ubuntu live. Fred has a GUI remastering tool, that also works nicely.

I think it's a nice concept that rufwoof has made.
Suppose you choose to save to file/folder several times and at some point you want to make remaster with the changes included, then the advantages are:
- very quick, no copying done, just mountiing using aufs to overlay main filesystem.squashfs + changes (and LZ4 compression is very fast).
- the main filesystem.squashfs will instantly be "replaced" (automatically add new entry in filesystem.module file), no manual copying/replacing required.
- The changes will be deleted (after reboot) so no hassle to do that manually (after all, the changes are already included in the remaster, so should be removed from existing save file/folder).

As it is now it only supports changes folder deletion but I'm working on it to support also deletion of savefile contents (e.g. changes.dat) after remaster.

Fred

I also like rufwoof's concept. It is something different than the traditional Puppy remastering, and maybe needs a different name. But it is certainly a very useful concept. I don't see it as replacing traditional remastering, so much as a different tool to do a different thing.

I worry a little bit about what happens if someone messes it up somehow and it fails. I see a newbie remastering in a sfs or pet file that came from Puppy or somewhere else and somehow breaking the dpkg database. Or screwing it up in some other unknown way. Maybe there ought to be a way built in to "step back" in that case. If I understand how it works correctly, something as simple as renaming the old squashfs and save file/folder instead of overwriting them would accomplish that.

As far as the drama, I'd recommend ignoring it. It is just software, and amateur hobby software at that. It's not worth the drama. If you like the project and its direction, then work on it. If you don't like the project and its direction, then don't work on it or fork it and have your own project.

[mcewanw]

Whatever you decide to do Fred, this and similar are Toni's threads, as he has just demonstrated. I think you need to start a new thread or threads and no longer use the DebianDog name for your alternative project since DebianDog is Toni's. i.e. you need to formally fork the project under new name for your one.

I think there probably always was some underlying tension between the JWM versions of Toni and the Openbox versions of yourself, though it was Toni who encouraged both versions to be developed together under one project (which made sense in terms of development effort and you worked very well together for a long time).

A community project model is probably hard to manage (since agreements needed between many 'heads') but should at least reduce any idea and friction surrounding ownership. Toni is certainly correct that proper credit should always be given to everyone who was a part, big or small, in creation though I for one don't care if I was ever mentioned at all (didn't do much anyway, as I know).

William

[mcewanw]

Seriousness aside, and thus somewhat off-topic. Even my less-technical-interested wife was full of curiousity abouf the current Puppy-DebianDog drama. Being on here does sometimes feel like being part of a Puppy Big Bang Theory/Bravo Reality Television over-the-top soap sometimes. I suspect my own mind, and those of most other Scots, has been damaged by a social environment molded by generations of extreme Presbyterian seriousness.

However, the instilled Robert Burns type fear of the Devil burnt into the Scottish consciousness does tend to be unhealthily (more like healthily) balanced by an often whisky-induced humour - so I find myself not knowing whether to over-the-top laugh or over-the-top cry. In Scotland, I think we tend to end up doing both at the same time, which certainly adds to the drama, but nevertheless allows us to enjoy life even when forced to sit on wooden kirk benches, being traditionally terrified by our devil-threatening kirk ministers.

No wonder we end up somewhat crazy after that bitter enforced basic diet of salt porridge, haggis, and (almost thankfully) whisky.

Living for a long time in the Antipodes has failed to drive any of that Devil out of me unfortunately - I still feel the witches are chasing my horse's tail and my accent remains the exact same.

[rufwoof]

Observation:

Running with main filesystem squashfs fully extracted to the save space (save folder/partition) and the snapmergepuppy type 'save' is slow to run through the first time, 30 seconds or so. Subsequent saves run through in a couple of seconds.

My save 'folder' is the sda1 partition. If as part of startup I run a background script that does nothing more than find all files on that partition then the first run of 'save' (snapmergepuppy) is as fast as subsequent runs.

i.e. it looks like reading in all of HDD inodes in advance into disk cache significantly speeds up the first run of 'save'.

My script to do that pre-fetch looks like (the first few lines are just to identify the /lib/live/mount/persistence/sda1 save 'folder' in my case - the heart of the script is the find . >/dev/null line).

Code: Select all

#!/bin/bash
LABEL=`cat /proc/cmdline | awk 'BEGIN{FS="persistence-label="} {print $2}' | awk 'BEGIN{FS=" "} {print $1}'`
BASE=`mount -l | grep "\[$LABEL\]" | grep -m 1 /lib/live/mount/persistence | awk 'BEGIN{FS=" "} {print $3}'`
if [ -z "${BASE}" ]; then
  exit
fi
cd $BASE
sudo find . >/dev/null

I've just added that to ~/.config/lxsession/LXDE/autostart i.e. my startup ... running it under root.

[fredx181]

Post deleted, had a few drinks too many yesterday.

[rufwoof]

Is it ok to disable ModemManager service (I'm on cable and don't use modems nor have any intent to use any modems)?

$ sudo systemd-analyze blame

Code: Select all

          7.279s wicd.service
          6.922s ModemManager.service
          5.357s preload.service
          5.042s exim4.service
          3.617s polkitd.service
          3.586s lightdm.service
          2.828s ufw.service
          1.825s live-config.service
          1.707s alsa-restore.service
          1.648s systemd-logind.service
          1.638s rc-local.service
          1.635s speech-dispatcher.service
          1.632s irqbalance.service
          1.631s ntp.service
          1.613s avahi-daemon.service
          1.584s keyboard-setup.service
          1.306s nfs-common.service
          1.037s rsyslog.service
          1.008s udisks2.service
           991ms networking.service
           926ms systemd-modules-load.service
           911ms rtkit-daemon.service
           818ms kbd.service
           520ms kmod-static-nodes.service
           519ms rpcbind.service
           430ms sys-kernel-debug.mount
           407ms dev-mqueue.mount
           396ms dev-hugepages.mount
           351ms systemd-tmpfiles-setup.service
           351ms console-setup.service
           264ms systemd-remount-fs.service
           254ms systemd-tmpfiles-setup-dev.service
           251ms systemd-user-sessions.service
           224ms systemd-journal-flush.service
           131ms systemd-random-seed.service
           116ms user@1000.service
            97ms systemd-setup-dgram-qlen.service
            81ms udev-finish.service
            66ms systemd-udev-trigger.service
            57ms systemd-update-utmp.service
            54ms systemd-sysctl.service
            30ms systemd-udevd.service
            18ms user@118.service
            15ms plymouth-read-write.service
            12ms plymouth-quit.service
             7ms tmp.mount
             6ms live-tools.service
             5ms systemd-update-utmp-runlevel.service
             4ms plymouth-quit-wait.service
             2ms sys-fs-fuse-connections.mount

$ sudo systemctl disable ModemManager.service
Removed symlink /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
Removed symlink /etc/systemd/system/multi-user.target.wants/ModemManager.service.

[fredx181]

Being on here does sometimes feel like being part of a Puppy Big Bang Theory/Bravo Reality Television over-the-top soap sometimes.

B-quality soap, it should stop!

Edit: the rest of your post really requires a lot of studying to understand! (Presbyterian, haggis, found out a little, but it's surely not enough to know really about, of course). Anyway, All the best! Take care!

[mcewanw]

Edit: the rest of your post really requires a lot of studying to understand! (Presbyterian, haggis, found out a little, but it's surely not enough to know really about, of course). Anyway, All the best! Take care!

Much explained here:

https://en.wikipedia.org/wiki/Tam_o'_Shanter_(poem)

Adios

[anikin]

Whatever you decide to do Fred, this and similar are Toni's threads, as he has just demonstrated. I think you need to start a new thread or threads and no longer use the DebianDog name for your alternative project since DebianDog is Toni's. i.e. you need to formally fork the project under new name for your one.

I think there probably always was some underlying tension between the JWM versions of Toni and the Openbox versions of yourself, though it was Toni who encouraged both versions to be developed together under one project (which made sense in terms of development effort and you worked very well together for a long time).

A community project model is probably hard to manage (since agreements needed between many 'heads') but should at least reduce any idea and friction surrounding ownership. Toni is certainly correct that proper credit should always be given to everyone who was a part, big or small, in creation though I for one don't care if I was ever mentioned at all (didn't do much anyway, as I know).

William

Maybe, for the time being it will be best not to rush to forking, opening new threads, thinking about new names and such. After all, the situation isn't irreparable. It looks much better today, than a couple days ago. The good thing is Toni is posting again. True, he isn't singing kumbaya, but I think he's open to communication and ready for a comeback.

[saintless]

But if someone would mark this thread as closed, I wouldn't be sad, because it's not fun and/or useful anymore.

Your wish is my command.

There is an e-mail on my github account profile in case you like me to remove any other of yours scripts.

As I wrote - good luck with the community project.
Mine github page has nothing to do with your work and shouldn't stop it.

Pleas everyone - stop posting here. The thread is closed.

Toni

[ttuuxxx]

Cleaned up and closed until saintless ask to have it reopened. Respect the developers wishes Guys !!
ttuuxxx

[saintless]

According to this post the thread stays open as a community project:

As I say, all dogs are community projects; no-one can ask for that work to be locked or deleted without agreement from the other contributors.

[backi]

Hi Toni !

It`s a pleasure to see you back in Town !
NOT kidding........

So Let`s praise the Lord ......Halleluja....!


Regards !

[AndresC2]

Hi Tony thanks for your response!

http://murga-linux.com/puppy/viewtopic. ... &start=540

This is my first script.

add another tray in JWM with icons from /etc/jwm/debian-menu and Update when reload script.

default Position New Tray Bottom y="-1" you can change Top y="0"

put JWM-Tray in /home/user and make executable chmod +x.

in .jwmrc add:

<Program icon="your-icon.png" label="JWM Tray">/home/user/JWM-Tray ; jwm -restart</Program>

<Include /home/user/.jwmrc-tray </Include>

your need for test.

apt-get install menu jwm xfe htop

the Script:

#!/bin/bash

# AndresC2 2017-10-03, 'JWM-Tray-Update' for Jessie Debian 8.

grep -Ev "Menu|Programming|touch|JWM|Python|Top|Bash|Dash|Sh|uxterm" /etc/jwm/debian-menu > /tmp/debian-menu

#### Change Text ####
sed -i 's/<Program/<TrayButton/g' /tmp/debian-menu
sed -i 's_</Program>_</TrayButton>_g' /tmp/debian-menu

sed -i 's/confirm="false">/confirm="false">exec:/g' /tmp/debian-menu
sed -i 's/label/popup/g' /tmp/debian-menu

#### htop don't show icon in debian-menu ####
# <Program label="htop" confirm="false">x-terminal-emulator -T "htop" -e sh -c "/usr/bin/htop"</Program>
#### Add icon to Htop ####
sed -i 's/popup="htop"/popup="htop" icon="htop.png"/g' /tmp/debian-menu

#### Add sudo to XFE ####
sed -i 's_exec:/usr/bin/xfe_exec:sudo /usr/bin/xfe_g' /tmp/debian-menu

#### Build JWM-Tray ####
echo ' <?xml version="1.0"?>

<JWM>

<!-- Tray attributes: autohide, width, border, layer, layout, ( y -1 for bottom, 0 for top ) -->
<Tray autohide="false" border="0" y="-1" halign="center" height="35" layout="horizontal">' > /home/user/.jwmrc-tray
echo "" >> /home/user/.jwmrc-tray
cat /tmp/debian-menu >> /home/user/.jwmrc-tray
echo "" >> /home/user/.jwmrc-tray
echo '</Tray>

</JWM>' >> /home/user/.jwmrc-tray

sed -i 's/^ *//g' /home/user/.jwmrc-tray

#sleep 1
#clean up
rm -f /tmp/debian-menu

exit 0

# Thanks