Page 4 of 32

Re: mounting ext4

Posted: Tue 06 Mar 2012, 11:01
by shinobar
shinobar wrote:Or, you can copy the file /root/Choices/MIME-types/application_x-ext3-image to 'application_x-ext4-image'
DaveS wrote:application_x-ext4-image is already there.
The file '/root/Choices/MIME-types/application_x-ext4-image' does not exist in slacko-5.3.2.6-SCSI.iso nor slacko-5.3.2.6p-SCSI.iso.

Re: mounting ext4

Posted: Tue 06 Mar 2012, 12:03
by DaveS
shinobar wrote:
shinobar wrote:Or, you can copy the file /root/Choices/MIME-types/application_x-ext3-image to 'application_x-ext4-image'
DaveS wrote:application_x-ext4-image is already there.
The file '/root/Choices/MIME-types/application_x-ext4-image' does not exist in slacko-5.3.2.6-SCSI.iso nor slacko-5.3.2.6p-SCSI.iso.
Odd. I have slacko-5.3.2.6-SCSI.iso, and it is there. Wonder where I got it from :(
You are correct, it does not show up in the .iso image.

Re: mounting ext4

Posted: Tue 06 Mar 2012, 12:27
by shinobar
DaveS wrote:Odd. I have slacko-5.3.2.6-SCSI.iso, and it is there. Wonder where I got it from.
If you have frugal install (or CD + savefile), you can see under /initrd/pup_ro2 comes from the main sfs, and under /initrd/pup_rw you can see what comes from PET or somewhere.

Re: mounting ext4

Posted: Tue 06 Mar 2012, 12:36
by DaveS
shinobar wrote:
DaveS wrote:Odd. I have slacko-5.3.2.6-SCSI.iso, and it is there. Wonder where I got it from.
If you have frugal install (or CD + savefile), you can see under /initrd/pup_ro2 comes from the main sfs, and under /initrd/pup_rw you can see what comes from PET or somewhere.
Came as part of the 'right-clicks' package .. apologies.

Posted: Tue 06 Mar 2012, 13:55
by pemasu
Kernel 3.2.X presents new Logitech usb device module which handles new unifying feature:
CONFIG_HID_LOGITECH_DJ=m -----> =y
seems to fix the problem with Logitech usb devices which uses the new unifying feature.
There are now several reports of succesfull device recognition with recompiled 3.2.9 kernel with
CONFIG_HID_LOGITECH_DJ=y
From: Nestor Lopez Casado <nlopezcasad@logitech.com>
With this driver, all the devices paired to a single Unifying
receiver are exposed to user processes in separated /input/dev
nodes.
Keyboards with different layouts can be treated differently,
Multiplayer games on single PC (like home theater PC) can
differentiate input coming from different kbds paired to the
same receiver.
Up to now, when Logitech Unifying receivers are connected to a
Linux based system, a single keyboard and a single mouse are
presented to the HID Layer, even if the Unifying receiver can
pair up to six compatible devices. The Unifying receiver by default
multiplexes all incoming events (from multiple keyboards/mice)
into these two.

Posted: Wed 07 Mar 2012, 11:32
by Sage
During the initial setup on moderately old kit, if a reduction in the default resolution is selected a black band appears across the bottom of the screen. This is an entirely new feature in 5.3.3beta. On older still kit, the size of this band is large enough to obscure the next selection screen.

Posted: Wed 07 Mar 2012, 12:14
by Jasper
Re Sage:

After an earlier clueless and careless report of a problem with Slacko's software, Sage decided it was his hardware problem, but he did not apologize for his mistake then - so we should not expect an apology now.

Addendum:

Today, 11th March 2012, Sage wrote (note 1) "In this case, the issue turned out to be the smart new little monitor, which fits in the corner of my desk (note 2), but cannot access the higher resolutions with nV cards.

Notes:

1 Extracted from another thread: http://www.murga-linux.com/puppy/viewto ... 212#611212

2 Perhaps this desk is the command and control centre from which Sage runs dozens of distros and even more computers simultaneously.

No mount-sfs problem using Slacko-5.3.2.4-RC2

Posted: Wed 07 Mar 2012, 19:09
by mikeslr
Hi all,

Frugal install of Slacko-5.3.2.4-RC2 to Ext4 partition. The same is able to mount SFSes on that partition as well as on a partition formated as ntfs.

Hope this helps figuring out the problem under K.5.3.2;6.

mikesLr

Posted: Sun 11 Mar 2012, 04:38
by futwerk
a few new backgrounds.

Posted: Mon 12 Mar 2012, 09:57
by 01micko
Thanks futwerk,

-

Every one else ... Just an update...

I am quite busy with real life at the moment, but things should settle down over the Easter period. I'd like to get another beta out before then, see what happens :)

After that Slacko will enter a new phase, perhaps even 64 bit only.
It will also be based on Slackware -current packages (until 14 is out). I am running Slackware current (120227) at the moment and it's fantastic! You would think it's a final release.

Moving to 64 bit arch will lift the size of the iso somewhat. I'll likely include Mesa in the build as well as some other useful stuff, however it will still be light, there will not be unnecessary bloat. The target will be well under 180MB iso.

A major niche of Puppy is the USB key install and lightness gives Puppy the advantage in this area. I would still rather stick with aufs, seems less buggy to me but the USB bug is critical, we'll see soon if it's fixed.

So for now, keep testing 5.3.2.6x.. I have 5.3.2.7x on the cooker.. :wink:

Cheers

Posted: Mon 12 Mar 2012, 10:34
by Sage
perhaps even 64 bit only.
Please not! Saluki is taking care of all the more recent HW, but I am installing and recommending your Slacko 5.3.3beta for a load of pretty old kit, including resurrection projects for charities and landfill avoidance stuff. It runs just fine on everything; Slackware has a long and proud history. Loss of this distro to 64bit or even deferring to USB install is a retrograde step for 80% of the kit coming this way; most of them are incapable of successfully booting from USB, with or without FDD assistance. Moreover, it also runs perfectly well under AMD64 on modern 64bit machines in 32bit mode and accomplishes 95% of regular functions.
If there were anything else on the wish list it would be a 50Mb .iso version, which has recently been attracting renewed interest on the Forum.

Posted: Mon 12 Mar 2012, 11:08
by 01micko
Quote:
perhaps even 64 bit only.

Please not!
Well it is a perhaps... perhaps I'll drop PAE if I go 64 bit and keep 32 bit support chugging along with the smp kernel. Pure speccing at this stage.

The immediate future is still 533 with support for 32 bit arch and 32 bit PAE. I'm not a huge fan of PAE but while there's demand I'll build it, and I haven't had time to venture in to 64 territory except for a brief flirt with Iguleder's roar-ng, a fascinating project for which I wish I had time.

Firstrun-1.9.9

Posted: Mon 12 Mar 2012, 11:47
by shinobar
Firstrun-1.9.9, test release, intended to be compatible with the recent woof.
http://www.murga-linux.com/puppy/viewtopic.php?t=58312

Re: Firstrun-1.9.9

Posted: Mon 12 Mar 2012, 11:49
by 01micko
shinobar wrote:Firstrun-1.9.9, test release, intended to be compatible with the recent woof.
http://www.murga-linux.com/puppy/viewtopic.php?t=58312
Thanks, I'll test it all out in 5327 :)

Yes to 64-bit and 32-bit-SMP : No to 32-bit-PAE

Posted: Mon 12 Mar 2012, 14:20
by mikeslr
Hi 01micko,

I am pleased to follow where ever your interest takes you. But if time/real-life places limits on how many paths you can follow at once, and you can only choose two, than like Sage I would suggest continued support for the 32-Bit NON-PAE version followed by an interest in the 64-Bit version.
Somehow I've acquired 6 computers. All, regardless of their age and resources, can run 32-bit SMP. Only my youngest can run 32-bit PAE, and not among them is my Thinkpad T42, Those which can run 32-bit PAE, can also run 64-bit.
Although newer kernels and being based upon a different distro may alter these results, I doubt if the alternation will be substantial. In 2009 and 2011, Phoronix ran benchmarks comparing 32-bit, 32-bit-PAE, and 64-bit Ubuntus. Performance using the 64-bit systems was sometimes substantially better than under the 32-bit systems, regardless of wthether the 32-bit was, or was not, PAE. Occasionally, the 32-bit-PAE out-performed the 32-bit-non-PAE, but even then the performance gain was small. I would suggest in real-world terms, imperceptible.
See:
http://www.phoronix.com/scan.php?page=a ... _pae&num=1 and
http://www.phoronix.com/scan.php?page=a ... ae64&num=9
A 32-bit-SMP is needed for Puppy's expected "market": Older-computers with limited resources. A 64-bit appeals to those having modern equipment. I would think it would be a rare-bird who could not run a 64-bit but would benefit by 32-bit-PAE.

mikesLr

Posted: Mon 12 Mar 2012, 14:34
by Jim1911
Hi Mick,

You are on the right track. Already there is a Slacko puplet version out that uses the so called 32/64 bit super kernel. Kirk has a new Fatdog 64-600 about ready for testing. Unfortunately, TazOC is ill and hasn't been able to continue support for LHP 64-514 or his 32 bit 503 which are both fine pups. Hopefully, he will get well and return.

64 bit is still the wave of the future. The need for 32 bit is dimensioning. Puppy cannot afford to remain as support for just older hardware.

Cheers,
Jim

Posted: Mon 12 Mar 2012, 15:17
by Sage
the performance gain was small
Over the years, I've spoken with a number of industry specialists about 64bit. They all said much the same - 64bit advantage depends very much on application. The two main hold-ups in PC use are the HD and your ISP. Since most folks use their PC s (not mobiles!) to send emails, browse the Net, write to their mum and the Revenue, virtually no 64bit advantage accrues. More than anything, the future points firmly to the release of massive numbers of allegedly obsolete boxes - the perfect vehicle for Puppy and for preventing landfill. Don't join the lemmings unless your profession demands it!

Posted: Mon 12 Mar 2012, 15:22
by pemasu

Posted: Mon 12 Mar 2012, 20:22
by 01micko
pemasu wrote:Aufs bug has got new bug fix:
http://murga-linux.com/puppy/viewtopic. ... 556#611556
That is great news! I'll recompile k3.1.10, seems the best balance between old and new for the time being.

Posted: Mon 12 Mar 2012, 20:27
by Jades
5.3.2.6 still running nicely on the Pentium D. I've noticed that SFS-Load bleats about unionfs support being experimental but I haven't encountered any oddities while using the SFS files I have loaded.