Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 20 Aug 2014, 10:47
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
pUPnGO - 6Mb ISO - Basic Building Block Puplet
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 55 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 53, 54, 55, 56, 57, 58 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2232

PostPosted: Thu 12 Dec 2013, 04:46    Post subject:  

Yes, be very careful with e2defrag as it is very old. Don't use it on anything you don't have a copy of elsewhere.

Somewhere here I have a gtk1 app which shows the fragmentation status of a drive or file -but I don't find it right now -something with 'dav' in the name IIRC. Ahh, here it is, but it's not on my site davl it's called:
http://davl.sourceforge.net/
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Thu 12 Dec 2013, 11:46    Post subject:  

e2defrag is maintained - cant say its safe - but seems quite up to date.
Thanks for the gdavl-link - cool!
snap0005.png
 Description   
 Filesize   114.37 KB
 Viewed   592 Time(s)

snap0005.png

Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2232

PostPosted: Thu 12 Dec 2013, 15:05    Post subject:  

He, He, that davl really reminds of the windows tool for that. Ummm, are you gonna patch it so that it uses e2defrag to actually do a defrag instead of just showing fragmentation??? Yeah, Yeah, Yeah?? Just kidding, but I think I read you okay -most of the time.

Nice find there about e2defrag. from the website:
Quote:
This poor ancient package used to be known as the defrag packge but was removed from Debian and hence Ubuntu due to it not having had a maintainer in many years and suffering from bit rot. I am rescuing it from the bit bucket.

Very nice indeed.
There is also e4defrag included with e2fsprogs, but nothing for ext3. I still use ext3 for my daily use as ext4 still 'hits a bump' every now and then.
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 479
Location: State of Jefferson

PostPosted: Thu 12 Dec 2013, 18:40    Post subject:  

goingnuts wrote:
From dmesg:
Code:
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sdc4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.

Code:
# find /mnt/sdc4 -iname *.jpg -o -iname *.jpeg |wc -l
1204

and foremost running on unmounted sdc4:
Code:
Foremost started at Thu Dec 12 05:35:32 2013
Invocation: foremost -v -T -t jpg /dev/sdc4
...
1512 FILES EXTRACTED
   
jpg:= 1512
Drive holds mostly source packages, unpacked/packed. Quite a lot of deletion and unpacking/compiling/packaging is done on an everyday basis...

The jpg´s found - are lots of small icon-images, background-images where some seems to come from webpages or manpages...

That's about 300 (or 20%) that aren't from jpg files.
data=ordered appears to not result in the file contents getting saved in the journal...as far as I can tell.
I'd say that's reasonable....
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Fri 13 Dec 2013, 02:28    Post subject:  

amigo: Smile
Ibidem: I don't catch your point: "find" finds files not deleted, foremost finds deleted files...

To speed up testing and avoid using drive with precious content I created a smaller (6Gb) partition by resizing 2 ntfs - and then create the new in between with gparted.

To start out its ext2.
Code:
# find /mnt/sdc9 -iname *.jpg -o -iname *.jpeg | wc -l
0

Then I run foremost on unmounted partition
Code:
# foremost -v -T -w -t jpg /dev/sdc9
...
526 FILES EXTRACTED
       
jpg:= 526

So jpg-left overs from the ntfs can be found...
Now I try to wipe with
Code:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024

df reports
Code:
/dev/sdc9              6048132   6048132         0 100% /mnt/sdc9

I let the files stay and umount partition. So now I expect to find nothing there with foremost (drive is full):
Code:
0 FILES EXTRACTED
Smile
Then I delete the two files created with dd and run foremost again and
Code:
0 FILES EXTRACTED
Good! This is the expected behavior - now I need to verify that if the drive is fragmented the above wont wipe free space...later today...
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 479
Location: State of Jefferson

PostPosted: Fri 13 Dec 2013, 13:04    Post subject:  

goingnuts wrote:
amigo: Smile
Ibidem: I don't catch your point: "find" finds files not deleted, foremost finds deleted files...

From what I understand, foremost finds all files having that signature, whether deleted or not.

BTW, there are a few files that contain embedded jpegs...some mp3 files, for example. But if it's mainly source code, that's irrelevant.
Quote:

To speed up testing and avoid using drive with precious content I created a smaller (6Gb) partition by resizing 2 ntfs - and then create the new in between with gparted.

To start out its ext2.
Code:
# find /mnt/sdc9 -iname *.jpg -o -iname *.jpeg | wc -l
0

Then I run foremost on unmounted partition
Code:
# foremost -v -T -w -t jpg /dev/sdc9
...
526 FILES EXTRACTED
       
jpg:= 526

So jpg-left overs from the ntfs can be found...
Now I try to wipe with
Code:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024

df reports
Code:
/dev/sdc9              6048132   6048132         0 100% /mnt/sdc9

I let the files stay and umount partition. So now I expect to find nothing there with foremost (drive is full):
Code:
0 FILES EXTRACTED
Smile
Then I delete the two files created with dd and run foremost again and
Code:
0 FILES EXTRACTED
Good! This is the expected behavior - now I need to verify that if the drive is fragmented the above wont wipe free space...later today...

My suspicion had been that it was something to do with the journalling. But it looks like it probably isn't, so I don't have any ideas.

Last edited by Ibidem on Fri 13 Dec 2013, 15:39; edited 1 time in total
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Fri 13 Dec 2013, 15:34    Post subject:  

Ibidem: thanks for the explanation. I might have had a few mp3-files there as well - but the found images did not look like mp3-stuff.

The continuation of the journey comes here:

Now I fill partition with unpacked/extracted source files and large amounts of videos.

fsck reports 145 non-contiguous inodes (0.2%) - and foremost says:
Code:
19 FILES EXTRACTED
       
jpg:= 19
??? I recognize a scrambled video-cover between them - so best guess is that they have entered via the copy of files to the partition...

Now I delete something until approx. 90% of drive still filled.
fsck reports same 0.2% fragmentation. - and foremost find same things as before...
I fill partition with dd, delete the created dd files - and foremost finds - same as before.

OK - time to exercise e2defrag. It goes without problems. fsck reports 18 non-contiguous inodes (0.0%) and gdavl reports fragmented files: 23.
Foremost finds - same 19 jpg files. I do the dd filling again - hoping - but no luck. Those files that foremost finds are resistant.

One last trial: I delete things down to 55% filled partition, run e2defrag, fill partition with dd and run foremost - now only 18 files are found - only 1 has gone.

Well - one more: delete everything - fill with dd - foremost finds nothing now. So whenever creating a new partition it might me good practice to do the dd-thing before starting to use the partition - just to get rid of all old stuff.

Now that was at lot of testing and unfortunately with a poor outcome concerning a simple privacy app. But it seems that e2defrag works and gdavl is a nice tool too. And foremost finds things quite well - so thats a good tool for undelete files...
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4334

PostPosted: Sat 14 Dec 2013, 23:36    Post subject:  

In case anyone is building jwm with translucency support...
I tracked down steam's patched xcompmgr:
http://repo.steampowered.com/steamos/pool/main/s/steamos-compositor/steamos-compositor_1.14.tar.gz

it may also need:
http://repo.steampowered.com/steamos/pool/main/s/steamos-modeswitch-inhibitor/steamos-modeswitch-inhibitor_1.8.tar.gz

NOTE: They left a bunch of debugging code lying around.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Sun 15 Dec 2013, 08:55    Post subject:  

technosaurus: Thanks for the links!

I realize that no pUPnGO2013 is going to be published - maybe a 2014...working on it.

Having fun with the basic core at the moment - converting various original puppys to squash-3.1 formate and loading them after boot - thats easy kernel switch - if you like 2.6.25.16.
snap0011.png
 Description   wary on top of pupngo
 Filesize   91.34 KB
 Viewed   304 Time(s)

snap0011.png

Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4334

PostPosted: Sun 15 Dec 2013, 14:44    Post subject:  

I've been messing with reimplementing hotplug here if anyone is interested in playing with it. Currently it does about the same that mdev does, but since it is written in shell, it can easily be modified.

Re: kernel... It would be nice to have some of the new syscalls (rfkill, finit_module) backported to 2.6.32 (oldest maintained LTS kernel) and use that for a 586+mmx kernel. I suggest this because anything less does not run many things efficiently (486 only got to ~133Mhz with a few exceptions) and there are still mainstream CPUs that are not 686 (technically they are but they are missing CMOV) but AFAIK they all have mmx (but not necessarily 3dnow and others)
We should use 3.10 (the newest LTS) for other architectures (basically what musl-libc and aboriginal linux support) ... for non-x86 architectures it is essential to use a newer kernel since much work on these has been a result of android and has accelerated over the last few years.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Sun 15 Dec 2013, 15:10    Post subject:  

Might be a stupid question - if such exist...but I have been wondering why it is so important with Puppy to be build for other than i486? Is speed/features using i586/i686/64bit really recognizable?

I run AMD Athlon 64/3000+ with 1Gb ram and have no issues with speed/features - even though I am stuck in P412. I even build all stuff for pupngo with -mtune=i386...
Back to top
View user's profile Send private message Visit poster's website 
starhawk

Joined: 22 Nov 2010
Posts: 2825
Location: Everybody knows this is nowhere...

PostPosted: Sun 15 Dec 2013, 15:32    Post subject:  

techno, goingnuts, et al., pardon the n00b question, but why can't a new kernel be compiled for i486? Are the 3 series kernels totally incompatible with that processor?

(I don't know a thing about kernel level stuff, so please be gentle Shocked )

_________________
Loving X-Slacko 2.1!
Custom Build: HP MOCA-AR + Core2Duo T7200 + 4gb RAM + 256gb SSD
...just needs a pretty case Wink
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4334

PostPosted: Sun 15 Dec 2013, 16:39    Post subject:  

starhawk wrote:
techno, goingnuts, et al., pardon the n00b question, but why can't a new kernel be compiled for i486? Are the 3 series kernels totally incompatible with that processor?

(I don't know a thing about kernel level stuff, so please be gentle Shocked )
486 is possible but pointless, even dillo-0.8x runs slowly on these systems that are now 20+yrs old and likely close to component failure. AFAIK there is only 1 manufacturer still making i486 (the vortex86sx) and the price is not better than other things on the market (they even make a 586 with mmx). If some chinese firm starts mass producing a high speed, SMP 486 in bulk due to patent expiration this logic would change, but for now the best option is i586+mmx since the rest of the low end CPUs (via, vortex*MX, cyrix, geode,...) in current production and the mainstream CPUs produced over the last 20 years (PentiumMMX+, amd-k7+,...) will perform best with this configuration.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2232

PostPosted: Mon 16 Dec 2013, 04:48    Post subject:  

'-mtune=i386' is superfluous because glibc doesn't support i386 since 10 years ago.
The jump from i386 to i486 brings the most significant performance benefits for any single jump in kernel arch. i486 is still the best arch to choose if you want to support really old hardware -I'm thinking particularly of geode processors. My current KISS-linux is using i586 which actually is not a good choice. Historically, i586 has had less use and certain combinations of glibc/gcc/binutils will not work for i586 -whereas they work(ed) fine for i486 or i686.

I'm going to be upgrading KISS soon and am going to change to i686 -I figure that there are so few Pentium I's out there that they can be ignored. i686 means a minimum of Pentium II which still offers a way-back reach. And, I still use non-SMP kernel configuration and non-SMP kernel headers for glibc. I figure that SMPÜAE belongs to 64-bit systems. Yes, there are smp processors which are not 64-bit, but even though an SMP-enabled kernel will run on *some* non-SMP machines, they will not run on all of them. So, you'd still need both smp and non-smp kernels for 32-bit systems.

3-series kernels can still be compiled for 486, but 386 is no longer supported at all. And since i586 is an 'iffy' choice, one should either stick with i486 or jump to i686.

All of these choices are made much easier when working with a truly modular system where things are thought-out and built with flexibility in mind. And having a good system for building packages makes it possible to maintain more than one package tree for different arches from the same sources and build scripts.

Looking forward, then 64-bit is the only way to go. But, if wanting to look back at the same time, then it is time to have builds of multiple arches. Of course, you have that now with fatdog & Co., but the common build system is not there. A rethink is needed because trying to build robust systems by robbing packages from here and there is simply not maintainable.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 780

PostPosted: Wed 18 Dec 2013, 16:20    Post subject:  

technosaurus & amigo: Thanks for the detailed explanations! Still not sure if I now know if there are any advantage by compiling applications with i486 versus i686 in respect to size/speed/features when running Puppy. It seems that if we use i486 we make sure they will run with old cpu as well as new cpu. If i686 is chosen only "newer" cpu will be supported.

For the kernel version my experience is that P216 will run (boot) on pentium1 but P412 will not. Is it possible to compile P412 kernel to run (boot) on pentium1 as well or is there a clear break at a certain kernel number where pentium1 was excluded? Could explain the need for the P412retro version...

I have 2 old notebooks which refuse to boot P412 based pupngo but they happily boots P216 based. P216 & P412 can share squashfs if version 3.0 is used. It only have minor influence on the squashfs-file size as shown below testing compressing the main-sfs files of Puppy-3.00:

org_P300_main.sfs unpacked: 217M
squashfs3.0 (gzip): 77M
squashfs3.1 (gzip): 76M
squashfs4.0 (gzip): 76M
squashfs4.2 (gzip): 76M
squashfs4.2 (xz): 64M

If possible this opens for a shared core-pupngo-sfs for kernel P216 & P412 as well as shared application squashfs-files. Might even open for a shared initrd. Could mean a quite compact 2-kernel version might be possible...
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 55 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 53, 54, 55, 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1534s ][ Queries: 12 (0.0408s) ][ GZIP on ]