Puppy 1.0.7beta test iso available

News, happenings
Message
Author
flavour
Posts: 125
Joined: Thu 08 Sep 2005, 20:26
Location: Bicester, UK

'md5sum -b'

#21 Post by flavour »

ok, another small issue, the md5sum included with BusyBox doesn't support the '-b' option.
This option has been the recommendation for creating DotPups:
http://www.goosee.com/puppy/wikka/DotPup

All seems to work fine if the '-b' is omitted (binary detection is automatic - on Linux at least)

Maybe the fix is therefore to update the docs...

F

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#22 Post by GuestToo »

yes ... the -b option never was necessary, it's overkill ... often overkill prevents potential problems later on, sometimes it causes problems

GuestToday

#23 Post by GuestToday »

after updating from 1.0.7a to beta, my desktop icons for "setup" and "edit" changed to gears. Looked in globicons file and they pointed to now non-existent icons. Fixed by changing mapping to new 48x48 icon versions. Not sure if this is unique to me or others may have similar problem. I was already using pup001 with 1.0.7a...maybe that was the reason?

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#24 Post by BarryK »

GuestToday wrote:after updating from 1.0.7a to beta, my desktop icons for "setup" and "edit" changed to gears. Looked in globicons file and they pointed to now non-existent icons. Fixed by changing mapping to new 48x48 icon versions. Not sure if this is unique to me or others may have similar problem. I was already using pup001 with 1.0.7a...maybe that was the reason?
The Developer News page warns you about this.

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#25 Post by pakt »

... new 48x48 icon versions
That reminds me, I wanted to say that having all the icons the same size (48x48) is a big visual improvement. Nice one.

Paul

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#26 Post by Lobster »

The descriptions are better too. For me the intriguing part is OpenGL. Games, 3D - what can we do with this now being a part of Puppy?

Meanwhile try the web2 section of this new social browsing service . . .
http://www.browsr.com
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

GuestToday

#27 Post by GuestToday »

BarryK wrote:The Developer News page warns you about this.
Barry, apologies, I saw that you wrote:

If you have a customised desktop, be aware that your desktop icon layout will be replaced, but backed up as /root/Choices/ROX-Filer/globicons.bak and PuppyPin.bak.

I assumed that meant that a new globicons (with mappings to new icons) would be written, but in my case it didn't. I didn't have the backup files and my old globicons was still there (pointing to removed icons).

I also like all the icons the same size. I guess the new globicons is somewhere in usr_cram that I can move?

Thanks!

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#28 Post by kirk »

Lobster wrote:
For me the intriguing part is OpenGL. Games, 3D - what can we do with this now being a part of Puppy?
Now if you want to install a game that needs OpenGL (or Mesa) you'll probably just need SDL. I Tried some of the games that I had compiled that required SDL and Mesa. I only loaded SDL and they worked. The SDL libraries are are a few hundred K, might be worth including.

PeterSieg
Posts: 363
Joined: Wed 04 May 2005, 16:06
Location: Germany, 37603
Contact:

1.0.7b + xorg doesn't work in qemu+vmware4.5 ?!

#29 Post by PeterSieg »

Hi just want to let you know, that:

1.0.7b + xorg doesn't work in qemu+vmware4.5 ?!
Just black screen after the screen saying 'probing takes several seconds'.
Waited app. 2-3 minutes...

xvesa works fine...

PS
Have fun :)

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#30 Post by kethd »

The glitch with power-down exit dead-ending at hung state on computers without power management ability (could not CTRL-ALT-DEL reboot, manual power-down forced) seems fixed with 107a -- Thank You Barry!

Good to see the ash help in 107b. But the presence of bash should be acknowledged, and at least some links to the great Internet docs for it. (And the Puppy wiki ash/bash pages should maybe at least be linked to.)

The "How to write programs for Puppy" section of Help is still very outdated. Needs to acknowledge both bash and PuppyBasic presence.

Maybe I am the only one left suffering under the delusion Puppy might be hosted on a 64MB flash device, but I have found out the hard way this is not currently feasible; it just does not fit. (My device was just over 64,000,000 bytes, but even with a true 64MB device you would end up at best with a PUPXXX file with no headroom at all.) Having left that milestone behind, I'm fine with the size of standard Puppy slowly inflating say another 10MB, as long as we feel we are getting maximum efficient funciton for the added size.

On the other hand, it would also be good to make available instructions that require minimum expertise for cutting down a standard Puppy to actually fit in a 64MB flash device.

I have made the switch from Gujin to linld, for bootloading from floppy FreeDOS or ide MS-DOS... I recommend HDoption-1 be changed to use linld on generated boot floppy, or anything other than Gujin. Will try to write up all the gorey details soon.

Guest

#31 Post by Guest »

Just tried the '07 beta.....Xorg works with the Neomagic chipset


Regards
BH

Guest

#32 Post by Guest »

But after comparing it against ,04 with Xfree86 it seems slow in scrolling through web pages, tho I didn't tweak xorg.conf too much

Regards BH

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

LINLD vs. GUJIN

#33 Post by kethd »

LINLD vs. GUJIN

After spending a day testing DOS bootloaders on Puppy 1.0.7b over a broad range (P-120 to AMD Duron 1000MHz, 16MB to 256MB) the sad results are that linld is mostly better, but loses to Gujin when there is just barely enough memory (32MB).

On fast computers, linld is just slightly faster. On slower computers, linld is progressively faster than Gujin -- quite significant on slow computers.

However, with just 32MB of RAM, Gujin works and linld fails. (So I cannot recommend linld as the Puppy standard. The search for the best bootloader continues...)

With less than 32MB, they both fail. But a traditional native installation of Puppy (HDoption-2 GRUB-MBR) boots all the way to GUI on 32MB. And 24MB. And even 16MB! With 24MB and a swap drive, you could probably do almost anything, if you have enough patience. This information will be relevant to some old laptops.

With the computers most people are likely to use, the biggest potential improvement would be to eliminate the time to copy usr_cram.fs to ram. If it could just be mounted and have the boot continue, while it was being transfered to cache in the background, and then locked in to cache ram whenever than transfer completes, that might be ideal...

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#34 Post by kethd »

Perhaps I was too hasty about the 64MB boundary:
"Puppy version 1.0.7 is released. The live-CD iso file is 60.46M."

So, even though I was not able to cram the various files of 107b onto a 61MB CF-IDE (DOS bootable), maybe there is some way to make some 64MB USB devices act like a CD, and have everything fit, even if there is no room for any PUPXXX.

Etienne

Re: LINLD vs. GUJIN

#35 Post by Etienne »

kethd wrote:LINLD vs. GUJIN

After spending a day testing DOS bootloaders on Puppy 1.0.7b over a broad range (P-120 to AMD Duron 1000MHz, 16MB to 256MB) the sad results are that linld is mostly better, but loses to Gujin when there is just barely enough memory (32MB).

On fast computers, linld is just slightly faster. On slower computers, linld is progressively faster than Gujin -- quite significant on slow computers.

However, with just 32MB of RAM, Gujin works and linld fails. (So I cannot recommend linld as the Puppy standard. The search for the best bootloader continues...)

With less than 32MB, they both fail. But a traditional native installation of Puppy (HDoption-2 GRUB-MBR) boots all the way to GUI on 32MB. And 24MB. And even 16MB! With 24MB and a swap drive, you could probably do almost anything, if you have enough patience. This information will be relevant to some old laptops.

With the computers most people are likely to use, the biggest potential improvement would be to eliminate the time to copy usr_cram.fs to ram. If it could just be mounted and have the boot continue, while it was being transfered to cache in the background, and then locked in to cache ram whenever than transfer completes, that might be ideal...
Hello Puppy users, hello kethd,

First, I am sorry to be late to answer all those mails about Gujin, I was
in holidays for all this time and did not read that much my E-mail to
find the only non-spam mail I got in two weeks. Moreover there has
not been one message containning the word "Gujin" in this forums
for quite some time - I stopped searching the forums every day...

The memory size problem and the time needed is due to the fact that
TINY.EXE in Gujin is decompressing itself the initrd file, and gives the
decompressed version to the kernel. All other bootloaders give the
on disk version. The main reason is to check the content of this file,
by checking the CRC32 of the decompressed data.
Because anyway the kernel has to decompress itself this file, it is
unfair to measure the time to start: all the CPU time needed to
decompress is either before starting the kernel or after starting it.

The main difference (and bad point in some configuration) is that
the kernel will decompress the initrd after initialising the virtual
memory/swap device and Gujin needs physical memory for that
- part of the decompressed initrd cannot be swapped to a swap
device at Gujin boot time.

The problem of checking which data is given in the initrd memory
is quite important because most USB device *do not* report read
or write errors from the medium, and so you can get this kind of
errors after formating a CompactFlash using an USB adapter,
and the standard mke2fs:

> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1742: unaligned directory entry
> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1747: unaligned directory entry
> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1751: unaligned directory entry

This is simply few bytes which cannot be written in one sector.
If you use an IDE->CompactFlash adapter you will see those error
even running a standard Linux kernel, as I did.
You can also copy a big file to the medium and then compare it with
itself to immediately spot the problem.

You seem also to have a problem with the command line length, with
Gujin version 1.2 (I discourage strongly using previous versions, with
tiny.exe the command line is *not* correctly passed - v0.9 is not
good neither for other reasons).
One difference in between Gujin and other bootloaders is that the
name of the kernel file is given as the first parameter on the
command line in some cases - that could explain the small difference:
What is the content of "cat /proc/cmdline" when you are running
into problems?
The other main problem I have is: why do you need so long a line?
This command line is made to be edited by hand so should not
be too complex by design.
Also - I do not treat differently loading in CONFIG.SYS or AUTOEXEC.BAT,
so any difference in command line length is directly due to the
command line length available in CONFIG.SYS "SHELL=" - DOS used
to have a maximum of 80 char for it.

By the way, I do understand why you need to boot DOS and then use
a USB DOS driver on computers which cannot boot from USB devices,
but I am not sure why you want to do so, and so use TINY.EXE instead
of completely installing Gujin on a USB FLASH drive by:

Code: Select all

./instboot boot.bin /dev/sda --disk=BIOS:0x00 --geometry=/dev/sda
(You need to download the install-1.2.tar.gz file from sourceforge and
untar this file using Linux) (adding --full parameter will completely
erase the device and show you if some sectors have write problems)
(The Flash drive will contain a FAT filesystem so you can mount it
and write kernel and initrd to it after initialisation).
At least, booting without DOS solves the license problem (you are not
allowed to distribute MS-DOS) and it solves also the HIMEM problem,
some of them limit the maximum memory block to 64 Mbytes.
Booting with FreeDOS helps there, but it has another problem: the
simulated floppy disk (coming from the USB emulation) interract with
the real floppy and the BIOS disk number may be wrong: that is one
reason why they are displayed if you completely install Gujin in a
USB drive.
Also booting directly helps having a bootable CDROM and bootable
USB drive with the same structure (same kernel and same initrd).

I am not sure I replied to all your questions here, if not feel free to
post answers (I am sorry sourceforge forums are not easier to use,
but because I do not pay for it I cannot complain...)

Etienne.

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#36 Post by kethd »

Etienne,

Very nice to hear from you!

I think that 1.2 truncates a CONFIG.SYS line shorter than 0.9 does, under FreeDOS under the same conditions. So this would have to be the fault of Gujin? I suggest that Gujin always by default echo the actual commandline it is going to fully process.

linld can accept up to about 256 characters (or eight parameters) to pass to the kernel/init, in a file. This is extremely useful and helpful in Puppy, for potentially troubleshooting rc.sysinit. (Because rc.sysinit is extremely difficult to edit, it is desireable to make it highly flexible based on parameters passed by the bootloader.) Please add this feature, in a way compatible with linld.

I only partially understand the issues with decompressed image.gz, but I am quite sure other DOS bootloaders are over-all more efficient, regardless of who is doing the job when. More to the point, I know for sure that this computer is capable of decompressing image.gz about five times faster than Gujin is actually doing it; I'd be happy to try to work with you to speed it up. (Esp since so far in my experiments only Gujin can bootload a standard Puppy in 32MB.) It seems like maybe the simplest quick fix would be to allow a switch to Gujin to bypass the uncompression that you do and have Gujin just pass the uncompressed file like other bootloaders do? (To test this, be sure to use a computer that is only a Pentium-I.)

Thank you for writing so much detail; I will try to study further.

(We should move this all onto a Gujin thread in Puppy forum, but I am not sure how to do that -- you could start one, and just link to it from here?)

etienne

#37 Post by etienne »

kethd wrote: (We should move this all onto a Gujin thread in Puppy forum, but I am not sure how to do that -- you could start one, and just link to it from here?)
http://www.murga.org/~puppy/viewtopic.php?p=30993#30993

Post Reply