Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

For talk and support relating specifically to Puppy derivatives
Message
Author
Keisha
Posts: 469
Joined: Tue 18 Nov 2014, 05:43

#4216 Post by Keisha »

fredx181 wrote:Hopefully you stay being the one in charge for this thread :) Fred
I agree and I second that motion.

Desktop application icons are only for complete noobs. They are indispensible for getting started quickly. But they are useless as soon as you have four or five open windows.

With DebianDog's Openbox file manager and xfce4-panel (and the same applies to lxpanel), and with the file manager, a console terminal, a browser and a few favorite apps in the Applications Launch section of the panel, desktop application icons become irrelevant.

One advantage of Openbox over the present version of the jwm file manager which comes standard with Puppies is, a rightclick on any open point between windows on the desktop will open the main menu. Another advantage of Openbox over jwm is, middle-click on blank space anywhere on the desktop brings up a windows list. A third advantage of Openbox over jwm is the ability to set margins.

One advantage of lxpanel and xfce4-panel over the panel which comes with jwm is, multiple windows of the same application can be grouped in the taskbar, so they occupy only a single lozenge on the panel. Clicking that lozenge opens a drop-up menu with all the open windows. If you set your prompt just so in /etc/profile, so as to show the current working directory in the urxvt title bar, you can tell which directories your eleven open urxvt windows are each open in--and the same is true of the Openbox windows list.

The combination of Openbox, xfce4-panel (or lxpanel), and wbar (or cairo-dock) vanquishes any set of desktop application icons, no matter whether the standard Rox pinboard version or your nicons.

Desktop application icons then become, to the experienced user, nothing but a distracting display of clutter.

Desktop document icons, and desktop drive/partition icons, can be useful, but the logical way is to group them close together, not scatter them all over.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4217 Post by saintless »

Hi, Fred.
Official download site and backup site updated with the latest files. I will do the same for backup site 2 in the next few days.
I will edit this file with new fixes and updated packages with information what is changed/fixed/improved.
If you have different idea about the updates we can change it.
fredx181 wrote:Just for info: I'm working on a new apt2sfs using the chroot method with unionfs-fuse.
I wish I discovered unionfs-fuse earlier, it's a very clean and safe way to use for apt2sfs, all installing happens in the chroot and separate 'write' directory (from which the module can be made).
Also I'd like to make a cli version, it's a work in progress.
Thanks, CLI will be useful for me. It is real pain to find or compile working yad for Lenny :) . I have now working yad-0.9.1 but it does not work well with your yad scripts.

I suggest any improved package to be added with higher version number in DD repository (without removing the old version). Then apt-get upgrade will do the job. Or reading the above link the user will have information what changes are made and what to upgrade or not by using apt-get install package-name. And downgrading to older package version will work too.
Hopefully you stay being the one in charge for this thread :) Fred
Too early to say yet. We shall see...

Edit: BTW DebianDog utilities thread is updated with pictures and information about latest changes in some programs. I know many new scripts from you are missing there but I will try to add them in time, Fred. Or you can post some of them if you like to have the information available there sooner.

Toni
Last edited by saintless on Tue 03 Feb 2015, 11:00, edited 2 times in total.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4218 Post by saintless »

Hi, Keisha.

Thanks for this information. Most of the improvements and fixes in Jwm version are also Fred's work. I'm sure he will keep working on OpenBox version in the future. I guess also we will make Jessie upgrade in time for both versions.

But Jwm is perfect for my needs. My favorite is KDE-3.5 BTW.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#4219 Post by mcewanw »

Yes, I prefer JWM too. Seems that little bit more efficient in terms of resource usage on my somewhat old computers. DD openbox version is nice though, so I can imagine it is also popular.

William
github mcewanw

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#4220 Post by anikin »

Keisha wrote: ....Is this relevant to the fact that doing a dist-upgrade from Wheezy to Jessie (in DebianDog) brings the need to log in at boot time, before the desktop comes up?

If yes, then how is this applicable to DebianDog?--i.e. please give a step-by-step of how I get rid of the login prompt.
It just occurred to me, I should have asked Toni first, before posting, because he created that thread for howto's, not for discussion.

I don't know what dist-upgrade did for you - did it make systemd as default? If yes, you probably can't autologin as root - then just follow the info. If the upgrade didn't break your sysvinit - it is not relevant/applicable.

The one thing about a dist-upgrade I know is that, it will not produce a clean, 100% Jessie. Wheezy, strictly speaking is NOT systemd compatible. I've done my due diligence in this regard with quite a bit of research. I think, Toni will build DD Jessie from the ground up, once the ISO becomes available. It will have systemd as default. That is when my post will be of some use/relevance, I hope.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4221 Post by saintless »

Hi, Anikin.
It is fine everyone to post howto information in DebianDog howto thread. It si better to keep discussions out of howto thread and move them (like you did now) here or in DebianDog main thread.
Actually DebianDog-Jessie and SID will be dits-upgrade from Wheezy.
Fred already made modifications for porteus-boot for systemd and the information is posted here:
http://murga-linux.com/puppy/viewtopic. ... 990#777990
Since many programs will need systemd in Jessie we should make systemd or sysvinit boot easy to change by the user.
Fred's Porteus-Wheezy from the first post in this thread uses systemd by default for example. Maybe Fred will make some suggestions about systemd when jessie becomes stable and I do not mind to have default systemd boot in DebianDog Jessie and Sid.

Keisha,
apt-get dist-upgrade from DebianDog-Wheezy should not break autologin as root unless you have login manager installed (and activated) as dependency for some later installed from you programs.
OpenBox version does not have login manager. Jwm version has xdm login manager deactivated by default. Typing xdm-start or xdm-stop activates and deactivates autologin in jwm version.
Check /etc/inittab for some changes from the original /etc/inittab included in DebianDog iso. You can copy /etc/inittab from the iso to test if autologin works. Otherwise give more information about DD version (openbox or jwm) and is the login prompt from GUI or command line + the content of /etc/inittab and /etc/X11/default-display-manager

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#4222 Post by fredx181 »

Hi All,

I'd like to add to the discussion that we still have choice to use systemd or initscripts.
To use initscripts just remove systemd (ignore the error at the end and reboot):
This I did on Jessie:

Code: Select all

root@dog:~# apt-get purge systemd
Reading state information... Done
The following extra packages will be installed:
  sysvinit-core
The following packages will be REMOVED:
  systemd* systemd-sysv*
The following NEW packages will be installed:
  sysvinit-core
0 upgraded, 1 newly installed, 2 to remove and 19 not upgraded.
Need to get 133 kB of archives.
After this operation, 6015 kB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://snapshot.debian.org/archive/debian/20150214/ testing/main sysvinit-core i386 2.88dsf-58 [133 kB]
Fetched 133 kB in 0s (210 kB/s)   
Preconfiguring packages ...
dpkg: systemd-sysv: dependency problems, but removing anyway as you requested:
 init depends on systemd-sysv | sysvinit-core | upstart; however:
  Package systemd-sysv is to be removed.
  Package sysvinit-core is not installed.
  Package upstart is not installed.

(Reading database ... 32446 files and directories currently installed.)
Removing systemd-sysv (208-6) ...
Selecting previously unselected package sysvinit-core.
(Reading database ... 32430 files and directories currently installed.)
Preparing to unpack .../sysvinit-core_2.88dsf-58_i386.deb ...
Unpacking sysvinit-core (2.88dsf-58) ...
Setting up sysvinit-core (2.88dsf-58) ...
Not restarting sysvinit
(Reading database ... 32454 files and directories currently installed.)
Removing systemd (208-6) ...
systemd is the active init system, please switch to another before removing systemd.
dpkg: error processing package systemd (--purge):
 subprocess installed pre-removal script returned error exit status 1
Failed to issue method call: Unit lib-init-rw.mount not loaded.
Failed to set capabilities on file `/usr/bin/systemd-detect-virt' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Then reboot (initscripts will be used then).
After reboot do (to complete the removal of systemd):

Code: Select all

root@dog:~# apt-get purge systemd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  acl libsystemd-daemon0 libwrap0
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  systemd*
0 upgraded, 0 newly installed, 1 to remove and 19 not upgraded.
After this operation, 6176 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 32454 files and directories currently installed.)
Removing systemd (208-6) ...
Purging configuration files for systemd (208-6) ...
dpkg: warning: while removing systemd, directory '/etc/systemd/system/multi-user.target.wants' not empty so not removed
Processing triggers for dbus (1.8.6-1) ...
[ ok ] system message bus already started; not starting..
Fred

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#4223 Post by anikin »

Hi Toni, Fred, Keisha et al,

Right you are, Fred. We can easily hop between sysvinit and systemd. The fact, that Jessie will have systemd as its default init, doesn't mean a user is forced to accept it.
By now, it is well known that Debian Jessie will not be using sysvinit as its boot system by default. But how can one keep using sysvinit in Jessie? It is fairly easy, and here are a few recipes, courtesy of
Erich Schubert
http://www.vitavonni.de/blog/201410/201 ... stemd.html
and Simon McVittie.
http://smcv.pseudorandom.co.uk/2014/still_universal/

If you already are using Wheezy and want to upgrade to Jessie and keep sysvinit as your boot system, create a file /etc/apt/preferences.d/use-sysvinit with this content before you upgrade:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1

This file content will tell apt and aptitude to not consider installing systemd-sysv as part of any installation and upgrade solution when resolving dependencies, and thus tell it to avoid systemd as a default boot system. The end result should be that the upgraded system keep using sysvinit.

read more here: http://people.skolelinux.org/pere/blog/ ... essie.html

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#4224 Post by fredx181 »

Hi anikin,
If you already are using Wheezy and want to upgrade to Jessie and keep sysvinit as your boot system, create a file /etc/apt/preferences.d/use-sysvinit with this content before you upgrade:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
Yes, thanks, this seems to be a nice way to prevent upgrading to systemd.

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4225 Post by saintless »

Thanks, Fred and Anikin.
Links to your posts added in systemd post in Howto thread:
http://www.murga-linux.com/puppy/viewto ... 990#777990

Toni

User avatar
atv
Posts: 27
Joined: Wed 16 Nov 2011, 15:44
Location: Tambo, Ecuador

How to change the suspend/sleep/screen saver timeout

#4226 Post by atv »

Hi Tony, Fred and All.
You guys have been very busy since last time I looked. :D
I wanted to download the latest DebianDog ISO, but due to my super slow connection, the system either suspends
or hibernates due to no mouse activity, so when I return to check, I find the download has stopped. Is there any way
to keep the connection active or stop the suspend/sleep etc from occurring?
Thanks in advance, keep up the excellent work!

Regards, Andres

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4227 Post by saintless »

Hi, Andres.

I don't know if it will help but you can try typing this in terminal to stop suspend/sleep:

Code: Select all

xset s off -dpms
Maybe you will get faster download with one of these download links:
http://smokey01.com/saintless/DebianDog/
http://kazzascorner.com.au/saintless/De ... og-Wheezy/
https://www.mediafire.com/folder/9d9nm6 ... _Saintless
https://9eb8f45ca0acc9dd68fbe8a604cd729 ... og-Wheezy/

Toni


User avatar
atv
Posts: 27
Joined: Wed 16 Nov 2011, 15:44
Location: Tambo, Ecuador

#4229 Post by atv »

@saintless; Thanks it worked just fine.
Code:
xset s off -dpms

I noticed that if I delete the old changes.dat and reboot, then after I bring the system up and do the update, then I create a new changes.dat so I try to reboot and the SAVING FILE popup stays on even after the saving occurs... it stays this way forever. if I force shudown and start again it works fine and the changes are ok. Did I do this wrong?

regards, Andres

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4230 Post by saintless »

Hi, Andres.
atv wrote:I noticed that if I delete the old changes.dat and reboot, then after I bring the system up and do the update, then I create a new changes.dat so I try to reboot and the SAVING FILE popup stays on even after the saving occurs... it stays this way forever. if I force shudown and start again it works fine and the changes are ok. Did I do this wrong?
I see nothing wrong in your actions. What is the filesystem type of the partition where changes.dat is located?
Is it OpenBox or Jwm iso? Both use different way of calling the saving process. OpenBox uses obshutdown and Jwm uses lines inside ~/.jwmrc
I will try to reproduce this problem.
Note if you made a lot of changes it could take some time to copy all in new created save file.
Maybe Fred will suggest something later.

Toni

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4231 Post by saintless »

Hi, Andres.

Thanks, it seems like a bug in Jwm version when booting porteus-boot without persistent, then making some changes like apt-get update, then creating new save file changes.dat and trying to reboot. I get the same problem described from you.
I will try to find and post fix soon. I have to find and compare all related files in OpenBox version to see if they have some differences. Unfortunately obshutdown does not work well with Jwm version and I can't use it.

Edit: It works well after fresh boot (no extra changes or only system settings changed), create save file and reboot just after that.
For some reason having more changes to copy in /mnt/live/memory/images/changes-exit freezes the copy process and wmreboot script can't finish the job.

Edit2: Not a bug after more testing. Andres, it just takes more time for copying all the changes in new created changes.dat. For example simple apt-get update will copy inside around 105Mb and it takes 4 minutes on my machine.
Just let it finish and reboot will continue. And do not try to reboot again or do something else after click on Reboot button. The system will freeze trying to execute several reboots.

Toni

User avatar
atv
Posts: 27
Joined: Wed 16 Nov 2011, 15:44
Location: Tambo, Ecuador

#4232 Post by atv »

Thanks, Toni; In my system it took approximately 20 minutes.... In these older and slow internet connections, you need patience.

regards, Andres

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

used RAM calculation change found htop 2.0.1 vs htop 1.0.3

#4233 Post by mcewanw »

Well I may indeed be stupid or daft (or competitive) as it seems to have been suggested, and the htops are in fact identical but somehow work differently in MintPup and XeniaDog. However, I don't think so in this case. I have now read some of the htop source code and believe the following (note that I'm still checking this and will revise the findings if necessary; I have to reinstall Xenial and get its wireless working again to download htop again):

SUMMARY (in terms of /proc/meminfo stats):

The MAJOR increase in htop report in latest htop versus older one is that /proc/meminfo/Shmem is being added to the UsedMem total (though effect is slightly reduced since SReclaimable is being subtracted). Shmem is relatively large...

According to htop 2.0.1: usedMem = TotalMem - FreeMem - Buffers - Cached - SReclaimable + MemShared

whereas for htop 1.0.3: usedMem = TotalMem - FreeMem - Buffers - Cached

REMEMBER to divide answers by 1024 if converting from KiB to MiB etc.

EDIT: the new free and top in Xenial match the new htop, by the way, in terms of the /proc/meminfo stats they display - though 'usage' is displayed without shmem added and with Sreclaimable and SUnreclaim (I think) subtracted (as part of buff/cache) as far as I remember. Note that buff/cache in Xenial free and top includes Sreclaimable (and, I deduced via calculation only, SUnreclaim). I should really check with the new free/top source code, but too busy to bother now. SUnreclaim would be a difference (since not used in new htop) and dubious one, so maybe I'll check the free/top source code later... EDIT2: Done. See my next post.

EXPLANATION:

htop version 2.0.1

https://github.com/hishamhm/htop/blob/m ... cessList.c

or can download the sourcefile as tar.gz from main htop download page.

The following are the values used from /proc/meminfo (from lines 655 to 675 of above function source code):

MemTotal becomes totalMem
MemFree becomes freeMem
Cached becomes cachedMem
Buffers becomes buffersMem
MemShared becomes sharedMem
SReclaimable becomes sreclaimable

Calculation done in line 640 function LinuxProcessList_scanMemoryInfo

line 683: usedMem = totalMem - freeMem
line 684: cachedMem = cachedMem + sreclaimable - shmem (in version 1.0.3 cachedMem is left as Cached value; i.e. sreclaimable is not added and shmem is not subtracted)


In linux/Platform.c

line 203:

usedMem -= buffersMem + cachedMem (i.e. usedMem = usedMem - buffersMem - cachedMem)

where cachedMem = cachedMem + sreclaimable - shmem (where shmem is sharedMem)



htop version 1.0.3

The program isn't broken into different platforms so looking at source code for function ProcessList.c:

same /proc/meminfo stats used can be found declared from lines 898 to 917 (much the same as for htop version 2.0.1 but SReclaimable not being used.

but from line 923, htop 1.0.3 calculates usedMem simply as:

usedMem = totalMem - freeMem

and leaves Cached (cacheMem) as provided by /proc/meminfo (i.e. doesn't add sreclaimable or subtract shmem).

htop 1.0.3 later recalculates cacheMem in MemoryMeter.c thus:

line 31: usedMem -= buffersMem + cachedMem; (i.e. same as in htop 2.0.1 but remember that cachedMem here does not add sreclaimable nor subtract sharedMem)

William
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#4234 Post by mcewanw »

Downloaded 'free utility' source code from http://packages.ubuntu.com/xenial/procps

In 'free utility' source code sysinfo.c:

kb_main_total is /proc/meminfo/MemTotal
kb_main_free is /proc/meminfo/MemFree
kb_page_cached is /proc/meminfo/Cached
kb_main_buffers is /proc/meminfo/Buffers
kb_main_free is /proc/meminfo/MemFree
kb_slab is /proc/meminfo/Slab, which, I believe I read somewhere, is same as SReclaimable+SUnreclaim in /proc/meminfo
kb_main_shared is /proc/meminfo/ShMem

RAM used calculation is from lines 706:

kb_main_cached = kb_page_cache + kb_slab;
kb_swap_used = kb_swap_total - kb_swap_free;
kb_main_used = kb_main_total - kb_main_free - kb_main_cached - kb_main_buffers;

which is same thing therefore as:

free utility RAM used

= MemTotal - MemFree - Cached - Buffers - Slab

= MemTotal - MemFree - Cached - Buffers - (SReclaimable + SUnreclaim)

EDIT: Found a nice link about more of this kind of stuff...

https://blog.famzah.net/2014/09/22/know ... ory-usage/

William

EDIT2: Personally, I think the htop calculation (which doesn't use SUnreclaim) is slightly better, since how can unreclaimable memory be subtracted since it is used memory? So I think SUnreclaim value should be added back onto 'free utility' used statistic to give a more realistic report. But what would I know?
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4235 Post by saintless »

According to this post the thread stays open as a community project:
mcewanw wrote: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.

Post Reply