|
Puppy developer news:  Older news |  Later news |
Puppy Linux 2.15 Community Edition releasedThe release announcement is on the Community News page: http://www.puppylinux.org/wikka/LatestNews The file 'puppy-215CE-Final.iso' is 131MB and is available from our primary host ibiblio.org: http://distro.ibiblio.org/pub/linux/dis ... uppylinux/ Ibiblio also has mirrors, that are often much faster, see links here: http://www.puppylinux.com/download/index.html Various Puppy enthusiasts are providing downloads. See the Forum thread here: http://www.murga-linux.com/puppy/viewtopic.php?t=17032 Note, if you are unable to download (perhaps being on dialup) and want to purchase a CD, I won't be processing orders for another 5-6 days as I am preparing a new CD (and having a bit of an Easter break!). craftybytes
Barry
- will your proposed 2.15CE CD also include all the relevant '.sfs'
packages that can be used with the "Community Edition" ..?If so - yes please for the purchase of a CD ..!! Also - will there be a different price for the '2.15CE' CD vis the $AU9.00 for the 'Unleashed" CD's..? PLUS - when do you expect to release the 'final' for v2.16..? Just curious as if it is within the same timeframe as for the preparation of the '2.15CE' CD - then I would also be very interested in purchasing a copy of v2.16 Unleashed CD as well..- will help to keep the postage costs down if both CD's could be sent in the same postpak..!! Good work being performed all around for our favourite linux distro.. PUPPY ROCKS.. BarryK
Craftybytes, ha ha, I'm in Easter-holiday mode right now, haven't
thought out all those details yet. Possibly some of the other guys,
like Nathan, might be offering a CD with 2.15CE and SFS files, so stay
tuned to Forum announcements.2.16 ...don't know any release dates yet. RickRandom
For folks in the UK, I would provide some 2.15CE CDs if asked...contact me via the main forum.craftybytes
Barry - hope you are having a good Easter break ..? OK - will have to wait and see then what transpires - eh...!!Enjoy your well earned break.. BarryK
We already have some patches and updates for the just-released Puppy 2.15CE. See this forum thread:http://www.murga-linux.com/puppy/viewtopic.php?t=17065 Tui
I am not too sure how to use these notice boards, but sorry if I am in the wrongplace. I posted a question at " Beginners Help" - Puppy V2.15CE FINAL!, maybe someone can solve the problem for me regarding the detection of my onboard e-net chipset. Tui. Is this a problem of software download or my finger trouble ? Devildog
This is truly a remarkable distribution. Thank you to all the participants that contributed to making Puppy 2.15 Community Edition a reality. Your time and efforts are greatly appreciated. Puppy is amazing. . . Pete
Barry,Nice edition but is there a problem saving to SATA drives on shutdown? My copy just hangs after it says it is Saving to SDA1, please wait. After half an hour it still hasn't shutdown and I have to manually close down my Notebook. When I re-boot it says the Puppy File System is corrupt. I then have to utilise Windows to delete the pup saved sfs file. I have also found that I can no longer run my WiFi Network link, as it doesn't recognise my WEP Key, even though it is a good Key. My WiFi hub uses 64bit WEP. It will however run my Ethernet link, so I can still use the Internet, albeit via Ethernet Cable. PeteG PeteG
Barry,I resolved both problems by running Puppy 2.14 and then 2.15. File now saves to SATA drive and RutiL now recognises my WEP Key. New look is much better than previous versions. Keep up the good work. Donaldo Cuellar (udafmcd<at>gmail.com)
 excellent version, Puppy rules!!!!!!!!Ron
Trouble
with 2.15CE, pupsave does not work right. The network driver would not
load the proper driver (forcedeth) -2.14 loads it just fine. How do you
install OpenOffice..sfs to an ide hard drive. Like the look and feel of
the distro ...but there is work to do. |
Puppy v2.16experimental2 for testinghttp://www.puppylinux.com/test/ THis is not a general release. Ihe 'experiment' uploads are for testing various new ideas. The main new feature since exp1 is the SFS boot management. The above link also has 'openoffice-2.2.0.sfs' which is designed to work with 2.16exp2. Preferably test without any prior 'pup_save' file. If there is one, boot with 'pfix=clean' to force an upgrade. Not recommended to use with a 'pup_save' that you rely on for daily use. The default is to load any suitable SFS files that are found at /mnt/home (same place as the 'pup_save' file). The BootManager, found in the System menu, enables you to change to whatever you want to load. 'openoffice-2.2.0.sfs' has /root/Choices/ROX-Filer/PuppyPin and globicons, also /etc/profile.d/openoffice.sh and these are enhancements that Puppy now recognises. The first two files specify desktop icons, and you should see these appear on the desktop when the SFS file loads, and if you choose not to load it then the icons should disappear. I did some work on the frugal install to hard drive, but it still isn't right. Boots okay, but doesn't recognise a 'pup_save' file when booting. I'll get that fixed soon. So, frugal isn't suitable for testing the SFS Boot Manager. Works when boot from CD and USB though. One pont if doing manual installing. Get rid of the 'root=/dev/ram0' if you have it as a boot parameter, as the ramdisk is no longer used. Another point: although I refer to it as 2.16 it is internally 2.15, so 'devx_215.sfs' will work. Lobster (ed.jason<at>gmail.com)
Should really be testing Viz but could not resist - like the stardust theme very much :)Leon
Puppy 2.16e2 works well.I use frugal install on vfat partition. I had to move the initrd.gz file from hda/boot to hda/. That was not necessary for Puppy prior to 2.14. Puppy successfully saved my settings to pup_save.2fs file and mounted it at reboot. I recommend to use 8 characters long sfs filenames to avoid problems when moving them from one directory to another on vfat by using batch files in Windows to manage more then one frugal install configurations . The new sfs file BootManager and OpenOffice.org works well. That is really nice improvement. I immediately change the new GTK theme to Default color theme. What I'm still missing in Puppy is English spell checker for AbiWord and numlockx to have a choice to turn on Numlock key at X start as I suggested at Puppy Developer Forum. My Puppy 2.16e2 hda/boot/menu.lst frugal install file: default 0 timeout 0 title Puppy-p2.16e2 rootnoverify (hd0,0) kernel (hd0,0)/boot/vmlinuz PMEDIA=idehd initrd (hd0,0)/boot/initrd.gz boot My old Puppy 2.14 hda/boot/menu.lst frugal install file: default 0 timeout 0 title Puppy-p2.14 rootnoverify (hd0,0) kernel (hd0,0)/boot/vmlinuz root=/dev/ram PMEDIA=idehd initrd (hd0,0)/boot/initrd.gz boot Wolf Pup
Since the ram disk isn't used anymore, does WakePup2 need to be fixed?BarryK
Wolf
Pup, yes, the reference to /dev/ram0 will also have to be removed from
WakePup. Actually, I tested with WakePup and Puppy still booted, so
perhaps that parameter just gets ignored if the kernel sees that
initrd.gz is a cpio archive.But, to do it properly, the param should be removed. Pakt probably has a later test version of WakePup2 so can incorporate this change as well. BarryK
Leon,
I mulled over it, but I don't understand your comment that you have to
move initrd.gz from /boot to /. If GRUB/LILO specifies it as in /boot,
that should be it.Ah, interesting that the 'pup_save' does work with your frugal install! Regarding a full install to hd, the Universal Installer has a bug. The bug is in the 'grubconfig' script, which comes up with a dialog box saying that GRUB will be installed to 'unionfs', whereas it should come up with the partition that s being installed to, for example '/dev/hda7'. It can manually be changed in the dialog window, but I'll get it fixed soon. Apart from that, Puppy did a full install and booted up fine. A little bug in BootManager. It has a checkbox that has a text stringstating that it will cause all SFS files to load, which is the default. But, it only loads those with '_215' -- the correct version number -- in the name. Leon
Barry,1. I use grub4dos 0.4.2 on Windows 98SE. Although one copy of initrd.gz file is in C:\boot directory and if I delete or rename another copy from c:\initrd.gz to c:\initrd.gz_ then boot process stops at: Now executing 'init' script in initial-ramdisk... (Note initial-ramdisk is retained and in /initrd after bootup) Loading kernel modules... Looking for Puppy in hda1... Using personal data file pup_save.2fs which is on partition hda1 ERROR, cannot find Puppy on 'idehd' boot media. PUPMODE=9 PDEV= Exited to initial-ramdisk (/dev/ram0) commandline... At first boot it was the same except: PUPMODE=1 PDEV= 2. After Puppy mounted openoffice-2.2.0.sfs file I renamed it to 8 character long filename ooo_220.sfs but BootManager reported: Sorry, there are no SFS files in directory /mnt/home You will need to download and place one there first. Then I renamed it to ooo-220.sfs. BootManager found it and Puppy mounted if at reboot. After reboot I noticed that my desktop background that I set before reboot changed to the default. Leon
[/url]I'm sorry, I made a mistake by typing HTML tag for:http://sarovar.org/projects/grub4dos/ BarryK
Ah, I understand both problems now.1. yes, the init script checks for initrd.gz at c:\ Now, that's an interesting problem... Puppy will need to read where the actual initrd.gz is supposed to be, that is, c:\boot. I presume that GRUB passes 'initrd=/boot/initrd.gz' on the kernel commandline, so the 'init' script can read that. 2. When the BootManager and init script see '_220' they think it refers to Puppy version number, and reject it. Change to something like 'oo-2.2.0.sfs'. ...that needs to be clarified in the BootManager. spam
seamonkey sucks ):DennisF
Notes posted here:http://www.murga-linux.com/puppy/viewtopic.php?t=17085 Sine Nomine
Hi Barry,Enjoy your Easter Break! For "spam". Use semonkey to go to mozillazine.org. Find links to FF3(Gran Paradiso Alpha3) release notes. Click on the link then download the *.tar.gz to my-documents. When the download is complete, close seamonkey. Open a terminal window, cd to my-applications mkdir ff3 cd ff3 use pupunzip(?) to unzip the alpha into the ff3 directory. cd firefox ./firefox (YOU ARE NOW RUNNING LATEST FIREFOX RELEASE CANDIDATE!!!) Fishy (barrowjo<at>gmail.com)
Downloaded > HD install > installed Opera 9.1 > working beautifully.Now to figure out how to install the OO.sfs. Please advise if anyone has the time. I do note that Barry mentioned grub wanting to save to unionfs as mine did the same. Living life on the edge as I am not a programmer but really good at formatting partions and starting again. Fishy
Followed instructions - downloaded openoffice-2.2.0.sfs and moved it to
/ (where puppy had automatically put the pup_save file). I renamed it
ooo-220.sfs and used System > Boot manager to select it for
inclusion with no result. I then made a /mnt/home directory and moved
the pup_save.2fs , ooo-220.sfs and zdrv_215.sfs into it. When I tried the boot manager after the above movement I got an xmessage box informing me that there were no .sfs files in /. I am a lttle confused. I accepted the basic structure during the install and am getting confused. Pup_save.2fs and zdrv_215.sfs are added to / not /mnt/home as some comments suggest they should be. Are the .sfs files supposed to be in /mnt/home or in /? BarryK
DennisF, I've made a note about that background image setting getting lost. Will see what I can do about that.Curious
I'd like
to try this one, but before I bother with the download, I wanted to
make sure that there is some way to use the SFS files with a hard disk
install.So far, I've not seen that this is possible - I've certainly seen no docs on how to do it, although I presume there's some way to do it manually. If I understand this correctly, the boot manager still might not let me use and/or control SFS files if I'm booting from an installed hard disk image. Any pointers to how to do this, if it's possible now? BarryK
Leon and DennisF reported some usability issues with BootManager.I think that I have fixed the problem of the background image reverting to the original. The checkbox in the BootManager has been renamed to explain exactly what it does, to avoid confusion. The popup-help window has extra explanation, in particular explains not to name a SFS file with '_xxx' (where xxx is three numeric digits) as Puppy interpretes this as a Puppy-version number and will reject the file if the xxx is not the same as the current version of Puppy. Note, I'm planning 2.16exp3 for this coming Sunday night, and there is a very big surprise ...I keep finding more bunnies in my magician's hat, and this time it is an Easter Bunny! ...well, to be released a bit after Easter, but it was inspired over Easter. PaulBx1
I'm
not quite understanding what is going on with the sfs file management,
but it occurs to me to ask, is the "How Puppy Works" page still
accurate in 2.16? Also, is this enough of a change to be calling it
2.20 instead? Just a thought...BarryK
PaulBx1, exp3 is only an experiment. I have placed Squashfs-lzma and
e2compr patched kernels in Unleashed so anyone can build and experiment
with these spcial Puppies. However, the 2.16-final will most likely
have the plain ordinary Squashfs and no ext2-compression. So,
2.16-final is the same as 2.14 (with input from 2.15ce) with
incremental improvements, but architecturally the same.I have emphasised that the 'experiment' in the name means that. hey who wants to talk puppye 
|
'ls' command with colorThen the light came on. I changed from Busybox ls to the full ls program, and the Busybox ls was configured to have color turned on by default. So, I have place this line into /etc/profile, which should fix it: alias ls='ls --color'BarryK
Oh no, a trap for the unwary. It has to be this:[code]alias ls='ls --color=auto'[/code] It seems that Busbox ls works like the 'auto' option. That is, ansi color codes are only output when printing to a tty, not when ls is used in a script. Without 'auto', the '--color' defaults to '--color=always' which will break some scripts. in rxvt nogo in rxvt bash well done kind regards duh John Doe
Does 'ls -d' work in the new version or still just give a period?I'm looking forward to that working with fingers crossed. |
Geany, Firelog updatedgeany-0.10.2 geany_NLS-0.10.2 firelog-1.2.1 Our Puppy enthusiast NoobieDoobieDo has now got a home page for Firelog: http://linux.blowshard.net/firelog See also the Forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=13975 DesertPuppy
Barry,
I noticed that some of the files now have NLS in their name such as:
geany-0.10.2, geany_NLS-0.10.2 do we need to download both files or
just one or the other and what does the NLS stand for ?BarryK
The
_NLS files have international language support, if the package offers
it. You only need it if you want something other than English.
|
Pmount "improved"To achieve a constant window like in MUT would require a complete rewrite of Pmount, and probably not using Gtkdialog. Instead, I have retained the window after a button is pressed, and when the new window is ready to be drawn, the previous is deleted and the new one drawn immediately. What you see is a brief flicker, at least with a fast CPU ...maybe that is still going to be annoying. Gee, I just looked at the clock, I started this at 6am and it's now 1pm. Well, I'll have lunch then forget about Puppy until this evening. |
"too big" icons in JWM fixedWihout going into lengthy explanation, to problem is the 'jwm-xdgmenu' utility. I modified the source of this and updated the Unleashed package, it is now 'xdg_puppy-0.7.6-3'. I also uploaded rarsa's source, with my small mod., to http://puptrix.org/sources/alphabetical/x/ which is the source repository for Puppy,courtesy of Ted Dog. For the user, what this fix means is that the problem just goes away. It doesn't matter what size icon is specified in the .desktop file, it will get scaled down to 16x16. Rarsa, if you read this, could you grab that and put the small mod into your svn repository... you will see my initial "BK" in the source where the mod is. rarsa
Will do.
|
FreeBasic, murgaLua, GladeFreeBasic is a compiler, and is in 'devx_216.sfs' (not yet released). Docs also, but it is recommended to read the docs at the home website. murgaLua runtime interpreter 'murgaLua' is now in Puppy, and the GUI-builder 'fluid' is in the 'dev_216.sfs' file. Glade is a GUI builder for GTK2 applications. This is now in 'devx_216.sfs'. Glade generates XML files that can be used by Gtkdialog3, GINS and FreeBasic, as well as C/C++ apps. There is a need to create an up-to-date guide to rogramming in Puppy, with all these new tools to choose from. Well, in the meantime, here are some links (also read down this blog): Gnocle/Tcl introduced here: http://www.murga-linux.com/puppy/viewtopic.php?t=15639 GINS introduced here: http://www.puppylinux.com/forum/?1172392169 MurgaLua introduced here: http://www.murga-linux.com/puppy/viewtopic.php?t=10113 Some discussion comparing Gnocl/Tcl, GINS, murgaLua, Gtkdialog here: http://www.murga-linux.com/puppy/viewtopic.php?t=15914 Gtkdialog: There is a helpfile at /usr/share/doc/gtkdialog.txt We are now using version 0.7.18 and the executable is 'gtkdialog3' -- do NOT use 'gtkdialog' or 'gtkdialog2'. If you have the 'devx_215.sfs' loaded, there are examples at /usr/share/doc/gtkdialog/examples/ -- it is essential to study these to understand how to use gtkdialog -- please note though, the examples run 'gtkdialog' executable which you will have to change to 'gtkdialog3' -- temporary messyness only. FreeBasic: http://www.freebasic.net/ GINS with PuppyBasic: http://www.murga-linux.com/puppy/viewtopic.php?t=15801 Example app using GINS: http://www.murga-linux.com/puppy/viewtopic.php?t=12394 Glade: If you have the 'devx_216.sfs' module, it has Glade, otherwise, Glade is a PET package that can be downloaded from ibiblio. Lobster (ed.jason<at>gmail.com)
I am
VERY glad to find the MurgaLua interpreter in Puppy. I would recommend
a friendly scouring of DSL for any code we might share for 2.16. Lua is
a very powerful front end to C and I wonder what caused this change of
mind?Is anyone up for maintaining (going through Barrys developer blog and adding updates) the 2.16 page? http://puppylinux.org/wikka/Puppy216 Any thoughts on a codename for 2.16 - I favour Puppy "Love"? Viz goes well, thanks to Warren and to those contributing code. I am using Viz + Open Office, Web and packages .sfs. It really is a pleasure to use and in future a window manager .sfs might be possible? A new programming sfs would also be a worthy project. A new T2 has just been released incidentally. One last comment before I forget, I am using the Firefox program adbocker in Seamonkey 1.8. How? Well I just installed on the offchance it would work and it does . . . Maybe there are other firefox addon programs that will work with Seamonkey, in particular the newer version? Anyone available for testing? kirk
Now that puppy has murgaLua, dvw86 has a really cool looking control panel:http://www.murga-linux.com/puppy/viewto Don't know how much is working, but sure looks nice! BarryK
Here is a Puppy Forum thread where we discuss GINS:http://www.puppylinux.com/forum/azbb.php?1172392169 What came to light in that thread, posted by Billcnz, is another GTK2 binding that works with all languages: http://www.gtk-server.org/intro.html BarryK
Hey,
does anybody else hate their laptop keyboard? I have to type vey
carefully, else keypresses don't register -- when posting here I have
to go back and fill in missing characters. ...see 'vey' above?And I have to be very careful my hand doesn't go anywhere near the touchpad. I've got an Acer Aspire 3681WXMI. kirk
Barry,You probably need the Synaptics/Alps setup in Xorg. See: http://www.murga-linux.com/puppy/viewto My wife has an Acer Aspire 3690, it uses the synaptics touch pad. The Tap to click function will drive you insane. Dougal added it to his xorgwizard modification a week or two ago. kirk
No, I
think the Aspire 3690 uses an Alps touchpad. Doesn't matter scroll down
to last couple of posts on that link and download the
synaptics-alps.pup.
|
User customisation of the desktopThen, as we have been discussing in recent reports in this Blog, if SFS files are loaded they may also want to have deskop icons. For example, 'openoffice.sfs' may have desktop icons for its wordprocessor, spreadsheet, etc. Then if Puppy is booted with an SFS file removed, the desktop must no longer display those icons. I have implemented a generic solution for all of the above. I'm pre-announcing this as it is written but not yet tested. At a version upgrade or change in the SFS layers, the desktop is upgraded, retaining user customisations. If any icons overlap, they are shifted. Any icon that is no longer valid is deleted. In the case of SFS files, they can have their desktop icons in /root/Choices/ROX-Filer/PuppyPin and /root/Choices/ROX-Filer/globicons. For the openoffice.sfs example, these files would only have the information for the OpenOffice icons, and the first bootup with this SFS layer enabled, Puppy will merge these icons withthe main PuppyPin and globicons files. Actually, it doesn't matter if SFS files have duplicate entries (pointing to the same executable) as in the main PuppyPin, as duplicates are removed. It won't be absolutely perfect. For example, you may have a custom icon that you created on the desktop. After a version upgrade or new SFS file loaded, your custom icon may get moved -- but, at least it is still there! Jeffrey
Well done Barry.I've created scripts to generate the dsktop icons for a new version of Puppy because I often re-install and don't want to repeat all my work. But if the underlying desktop files or formats ever change my script wouldn't work, so I'm glad to hear of your solution. kirk
Sounds great. Guess puplets may be a thing of the past, replaced by
.sfs files. Any thought about raising the maximum number of sfs files
that can be unioned? Or would it be too much of performance hit?craftybytes
I
think that we (puppy users) should 'take a step back' from wanting
many, many, many '.sfs' files to be loaded at the same time - and 'take
stock' - as to - "how" we as users - actually USE puppy on a day-to-day
basis .. !!!What I mean is - do we need to have 'multiple' .sfs files loaded - if we only use 4 or 5 "applications" at a time - the ability to load 'multi' .sfs files looks attractive - BUT - DO WE REALLY NEED TO ..?? I would suggest that instead we think about the possibility of - "REMASTERING" - .sfs files such that as users - WE - can make up our own .sfs files to suit our own 'usage' preferences - and still be inside the "limitations" of the unionfs system that puppy is built on ..!! Currently the existing - 'unionfs / .sfs / initramfs / .2fs' - structure WORKS VERY WELL for Puppy - so if it works - WHY TRY AND FIX IT IF IT AIN'T BROKE ..?????? If we have 'remastering' for puppy - why not 'remastering' for .sfs files as well..? Would simplify things I'd say.. Just my 2 c's worth.. Nathan
It seems like the sfs system is evloving to a modular system for expansion.. good work Barry.Maybe, if there ever is a PuppyPC on the market, the Puppy Foundation could distribute/sell these on a memory stick.. eg the Development-on-a-stick, OO-on-a-stick, etc, and when the stick is intserted, it is dynamically loaded. Kinda like an expansion cart for a console.. only cool. anyhows.. good work Barry. The only thing I can see wrong with Puppy is integration (minor) and lack of shinyness (minor). But still... GOOD WORK!!! GuestToo
it is possible to easily switch between multiple desktop configurations (icons, wallpaper) ... with one clickfor example: gxmessage -timeout 30 -center -buttons "_1,_2,_3,_4,Cancel" -default Cancel -bg lightgreen " Choose a desktop" case $? in 101) exec rox -op /root/Choices/ROX-Filer/PuppyPin ;; 102) exec rox -op roxdemo1 ;; 103) exec rox -op roxdemo2 ;; 104) exec rox -op roxdemo3 ;; *) exit ;; esac this could allow you to have the standard Puppy desktop, and also to have the choice of one or more personalized desktops which Puppy should leave alone BarryK
I've been testing it, works well.User additions to the desktop are retained, but deletions are a problem. It's okay if you delete an icon that you yourself had earlier created, but if you delete one of the "official" icons, that is one of those that were there originally, it will come back later at a version upgrade or when you change the SFS layers. I thought that I could keep a record of user-deletions and prevent them from returning, but then they would be blocked forever, and I didn't think that was good. I think the most important thing is that you won't lose icons that you have created. If you delete official icons and then they come back later, well, that's just a bit of an annoyance only, and you can take a few minutes to delete them again and re-arrange the icons. |
Menu updated when SFS files loadedWell, it started me thinking, and coding. I simplified the previous code, so that if Puppy boots up and finds the unionfs layers have changed, then a purge of whiteout files is done -- the logic of that is slightly simpler than before. The current and previous unionfs layers are recorded in /etc/rc.d/BOOTCONFIG, and after the switch_root, /etc/rc.d/rc.update reads BOOTCONFIG and if it sees that the layers have changed then the master help page is regenerated and the menu is regenerated (by the fixmenus script). So, if you bootup with a new SFS file loading, let's say 'kde.sfs', then the help page and menu will be correct. Desktop icons though... not so easy. I'll leave that one for now. Perhaps it would be sufficient just to test if any are invalid and delete them -- if for example the 'kde.sfs' file is removed and some user-created desktop icons then become invalid. I could add that, unless someone has a briliant idea how to do it better. BarryK
Another thing, an SFS file might need to run some config script at every bootup, maybe to setup environment variables.There is a directory, um, /etc/init.d (is that it?), in which scripts can be placed. Puppy can then run ll scripts that are found in that directory. This is a standard Linux thing, I think... anyone know the details on this? BarryK
Looking in Vector Linux, /etc/profile.d directory seems the right place.Nathan
/etc/init.d is usually reserved for services and daemons like httpd or
ftp, or event things like gpm. I'm already using it that way in
Grafpup. It sounds to me like /etc/profile.d might be better.Dougal
Barry,I have played around recently with adding/removing desktop icons and have thought of a way that icons can be added for sfs files -- the only question is whether it's worth the effort (maybe people will create more .sfs addons, now that you have the new options?). Anyway, here it is, you decide: If an sfs needs to add icons, it will contain a script for doing it, located in an agreed-on directory, say /etc/profile.d/pinboard. [I can make a template for it, I already have the code] There will be a special script, say /usr/sbin/refresh-PuppyPin, that will 1) remove from the pinboard any "dead" icons (if a sfs is no longer used) [I've also got code for this] 2) run the scripts in the directory above This file can be run **in the background** either in rc.local0 or in xinitrc, after the pinboard has been started (this is good if people want to add sfs files on-the-fly… maybe when we have Aufs?). All this shouldn't be hard to implement, it's just a question of if there's a point in doing it… Barry Kauler
Okay, it's done. I lifted code straight out of /etc/profile in Vector and put this into /etc/profile in Puppy:[code]#v2.16 this need arose when considering SFS files that may require special env. variables. #this code is lifted straight from Vector... # Append any additional sh scripts found in /etc/profile.d/: for profile_script in /etc/profile.d/*.sh ; do if [ -x $profile_script ]; then . $profile_script fi done unset profile_script[/code] This is inserted near the end of /etc/profile, after everything else is done. Here is an example file from Vector, /etc/profile.d/seamonkey.sh: [code]#!/bin/sh PREFIX=/opt/seamonkey if [ -d $PREFIX ] ; then export PATH="$PATH:$PREFIX/bin" export MANPATH="$MANPATH:$PREFIX/man" export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$PREFIX/lib/pkgconfig" fi[/code] Jeffrey
The way that Unixes general work:/etc/init.d (System V at al) contains scripts to start and stop services (cron, nfs, inet, etc) with /etc/rc.d/rc[0-6].d directories containing symbolic links to the services to be started or stopped when entering or leaving a given run level. So for run level 5 (multi-user with NFS) I would expect to see /etc/rc.d/rc3.d containing a symbolic link from say S40nfs to /etc/rc.d/init.d/nfs (with /etc/init.d and /etc/rc.d/init.d being linked together). The "S40" part of the symbolically linked filename indicates that this script is to be run to Start a process (when going to run level 5) and it is ordered such that it wll start after other ones prefixed S00-S39 and before any prefixed S41-S99. There are corresponding K00-K99 scripts for stopping (Killing) services when changing say from run level 5 down to run level 2. /etc/profile.d contains scripts to be run when a user logs on. These scripts are executed in-line by the /etc/profile script itself, eg for i in /etc/profile.d/*.sh do if [ -r "$i" ] then . $i fi done This is a suitable place to initialise variables for particular applications, eg by creating /etc/profile.d/vim.sh. It is also common to have a vim.csh in case the user is logging on with a csh in which case the script would be called from /etc/csh.login instead. On AIX (IBM's Unix) there is a very nice feature in the /etc/environment file, which is read by every process as it starts. So if there are system-wide environment settings that need to be made this is a great facility. This feature is more relevant when a Unix machine is used as a server than a single-user workstation so it is less relevant for Puppy Linux. In your case you may as well use /etc/profile because you have set Puppy up to log on after booting automatically, so /etc/profile gets executed at the end of the boot process. [I see that you've just decided to go with the /etc/profile.d standard, which is good. It allows for easy and clear customisation to be added to Puppy without having to edit the base /etc/profile file. Thanks.] Barry Kauler
Pakt has made a start with loading desktop icons when a SFS file is loaded:http://www.murga-linux.com/puppy/viewtopic.php?t=16739 I am running with this ball now... I've added code to /etc/rc.d/rc.update that generalises this loading of extra desktop icons: [code] #v2.16 if unionfs layers have changed, may need to fix menu (etc)... if [ -d /initrd ];then #test it isn't full hd installation. . /etc/rc.d/BOOTCONFIG if [ "$LASTUNIONRECORD" != "$PREVUNIONRECORD" ];then echo "Unionfs layers have changed since previous boot, fixing menu..." #master help index has to be updated... /usr/sbin/indexgen.sh #Reconstruct configuration files for JWM, Fvwm95, IceWM... /usr/sbin/fixmenus #pakt suggested we can also add more desktop icons... #create master files so original desktop icons can be restored. first, backup... [ ! -f /root/Choices/ROX-Filer/PuppyPin0 ] && mv -f /root/Choices/ROX-Filer/PuppyPin /root/Choices/ROX-Filer/PuppyPin0 [ ! -f /root/Choices/ROX-Filer/globicons0 ] && mv -f /root/Choices/ROX-Filer/globicons /root/Choices/ROX-Filer/globicons0 #this is the awkward part... cp -f /root/Choices/ROX-Filer/PuppyPin0 /root/Choices/ROX-Filer/PuppyPin cp -f /root/Choices/ROX-Filer/globicons0 /root/Choices/ROX-Filer/globicons for LAYERNUM in 3 4 5 do if [ -f /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/PuppyPin ];then grep -v -E 'pinboard>|<\?xml' /root/Choices/ROX-Filer/PuppyPin >/tmp/PuppyPinTmp grep -v -E 'pinboard>|<\?xml' /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/PuppyPin >>/tmp/PuppyPinTmp echo '<?xml version="1.0"?>' >/root/Choices/ROX-Filer/PuppyPin echo '<pinboard>' >>/root/Choices/ROX-Filer/PuppyPin sort -u /tmp/PuppyPinTmp >>/root/Choices/ROX-Filer/PuppyPin echo '/<pinboard>' >>/root/Choices/ROX-Filer/PuppyPin fi if [ -f /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/globicons ];then grep -v -E 'special\-files>|<\?xml' /root/Choices/ROX-Filer/globicons >/tmp/globiconsTmp grep -v -E 'special\-files>|<\?xml' /initrd/pup_ro$LAYERNUM/root/Choices/ROX-Filer/globicons >>/tmp/globiconsTmp echo '<?xml version="1.0"?>' >/root/Choices/ROX-Filer/globicons echo '<special-files>' >>/root/Choices/ROX-Filer/globicons cat /tmp/globiconsTmp >>/root/Choices/ROX-Filer/globicons echo '/<special-files>' >>/root/Choices/ROX-Filer/globicons fi done fi fi [/code] So, for a new permutation of unionfs layers at bootup, this code block will run and update help page, menu, and desktop icons. Raffy
Thanks
for the attention our developers and Barry are giving this matter. It
is very timely for the Puppy 2.15CE where sfs is expected to be used a
lot. Of course Barry started the version 2 series with the loading of
multiple sfs in mind. :)I hope we can translate this soon to the Diskless Remote Booting feature of Puppy... BarryK
It's
all very well having a BootManager, but people have to know it's there.
It's existence in the "System" menu is not quite good enough. So, I
added code to /usr/sbin/delayedrun, a script that runs just after X has
started. If a user has not used the Boot Manager before, and has
downloaded an extra SFS file, the BootManager will launch
automatically, with the SFS-selection window open. The user may not do
anything, may just exit, but at least will know of its existence (it
has its own help file that explains its purpose).craftybytes
Barry,A slight problem with 'menu' in 2.14 - that maybe also in 2.15CE (& could be 2.16) - is when a new prog has been installed and needs an "icon" in the menus - if there is not a 'designated' icon (in the prog installer) of the required size - the icon selected for use in the menus looks to "default" to the global size - which could be 48x48 or 32x32 ..  This tends to make the pop-up submenus vary in size when 'displaying' icons - if one icon is of incorrect size (larger) - then all icons in that menu are displayed as larger - even if they are listed as the correct size .. There is a 'special' xml file in /Choices/ROX-Filer for 'globicons' - so maybe we need a similar xml file to be set up for "menu" icons as the default.. Just a thought.. BarryK
Craftybytes, there is a fix for this, at least for JWM. It just hasn't
been implemented yet. I've made a note though, this must be fixed for
2.16 release. The fix is that it won't matter what size the icon is, it
will get scaled down to 16x16 to match the others -- the .jwmrc file
can be made to do this.Dougal
Barry,as I mentioned before, I've already messed with adding/removing icons and it's not as simple as the method you and Pakt are using: What if different layers have icons in the same place?? You cannot just assume that the creators of different sfs files will choose "unused" locations, since the user might have changed the locations of the default icons. You need to have code that tests to see if there's no existing icon where you want to put the new ones and if there is, look for a free location. As I mentioned, I have code I can send you, just don't hastily implement something like happened with 2.14 -- in the end it just causes disasters. craftybytes
Thanks Barry - hopefully you'll have a 'Unleashed' CD for the 2.15CE versions + a 'Unleashed' CD for 2.16 ..?Am awaiting in much anticipation for the - v2.16 Unleashed CD - so as I can 'play' once again with Puppy & see what advances and improvements have come our (puppy users) way since versions 2.13 & 2.14..!! TIA.. BarryK
I
don't know about an Unleashed CD for 2.15CE, as I don't know where all
the packages are. That is, we have PET packages at ibiblio, but the
2.15CE developers have some extra ones, in particular the core
package,'0rootfs_skeleton-2.15'.Dougal, I have already implemented a solution. The code I posted earlier was just an initial experiment. If you have code for me to consider, feel free to send it. |
Puppy 2.15 Community Edition Release Candidate 2 availablehttp://www.murga-linux.com/puppy/viewtopic.php?t=16673 Phil
Is there a seperate devx_215.sfs available for download. I have found 215.sfs files for:OOo fltkc pgs web but nothing for devx BarryK
Okay, look here:http://distro.ibiblio.org/pub/linux/dis PkaG
Thanks Barry :)Mirrored: http://www.pkagfiles.net/puppy215CE/RC2 http://www.pkagfiles.net/puppy-mirror-i |
A Boot Manager for Puppyhttp://www.murga-linux.com/puppy/viewtopic.php?t=16486 I've done it differently, and only implemented the choice of what SFS files to load (so far). I created script /usr/sbin/bootmanager, and a menu entry in the "System" menu. The script reads from and writes to a configuration file /etc/rc.d/BOOTCONFIG, which contains variables. The only variable so far is EXTRASFSLIST, which is a space-delimited list of SFS files to load at bootup. For this to work, the init script reads from (and writes to) BOOTCONFIG. If variable EXTRASFSLIST is missing, it defaults to the normal auto-loading. If EXTRASFSLIST exists, the specified SFS files are checked that they exist and if they have version-number that it is correct, then the files are added to the unionfs layers. What was immediately good about this for me personally, is I sometimes want to bootup but not load the 'devx' file. The BootManager GUI makes doing this a piece of cake. I have just tested booting from USB Flash, I put 'devx_215.sfs' into it, booted and it got loaded, then ran BootManager and choose not to load it, rebooted and it did not load. Great! If you have multiple SFS files, you can also choose order of loading, that is what Unionfs layer each is on. /etc/rc.d/BOOTCONFIG can be extended indefinitely with variables as required. For example, the "underdog Linux" can now just be a variable, like this: UNDERDOG='hda4' ...not implemented yet though. I can't just release the 'bootmanager' script right now, as it needs the bootup 'init' to work with it. Well, 2.16exp2 should be out in the not to distant future. Dougal
Barry,while you're at it, you might want to create in the dotpup a file containing a list of ALL sfs files already loaded with that pup_save and remove the part that changes the mod of the extra sfs files. The way it is now, your init script sees that a certain sfs file has already been chmod-ed and so it doesn't do the NEWSFS loop... but the sfs could have been chmod-ed with a different pup_save. pakt
Idea:
have one of the boot scripts check if the mounted SFS file has its own
PuppyPin file - if so, copy it over /root/Choices/ROX-Filer/PuppyPin
and add its icons to Puppy's icon directory. It not, restore the
default PuppyPin file. This way the desktop can change showing the
correct icons for whatever SFS file is mounted ;)Paul pakt
Of course with multiple SFS files, the desktop could get a bit messy. The icon layouts would have to be coordinated somehow...Paul MooDog
Hi, Barry -Just want to say that I hope this new 'experimental' branch will be a permanent feature for puppy development, so there is less pressure to release betas, just different 'blue-sky' stuff for us to have a go at, before committing to an actual package and release date. As long as we have CDRWs and broadband, there's absolutely no problem with more testing! I apologise if this comment is out of line... BarryK
Dougal,
at first my response was "Aaargh, complications!", but then I figured
out a simple solution. I have abandoned the chmod'ing of the .sfs
files, and all code related to NEWSFS is now commented out in init
script.Intead, I'm saving each unique configuration of layers in BOOTCONFIG, so when a new configuration is encountered, the whiteout-file check is done. |
Opera font rendering in 2.16exp1 improvedhttp://www.puppylinux.com/forum/?1174579188 This showed me how to fix some crappy rendering in Opera. If you are testing 2.16exp1, open /etc/opera6rc and insert this line: Enable Core X Fonts=0 into the [User Prefs] section. Then restart Opera. This prevents Opera from using bitmap fonts, now my Blog renders nicely. kirk
Oh yes, My eyes thank you. kirk
No luck with Flash 9 and opera, yet.lluamco
Flash 9 does not work in opera. Use Flash 7 instead. It works for me.BarryK
Yes, 2.16exp1 has Flash 7.
|
init, pmount scripts improvedPlinej and Dougal did a lot of work awhile back on Pmount, my original drive mounter script, still alive as an alternative to MUT. You will find it in the Filesystem menu. The script is /usr/sbin/pmount. Plinej updated it for gtkdialog3 and posted it to me on 5th March -- finally I have got around to looking at it. There was just one small thing, clicking the Refresh button caused a crash, which was easily fixed -- a bit of exta updating to gtkdialog3 was required. I made one other small change -- the main "Please wait, probing hardware" box is done with gxmessage, but quite frankly gxmessage doesn't look so good. I have replaced it with yaf-splash, just that one message box (yaf-splash is also used in PETget). Dougal's and Plinej's improvements are nice, it looks real good, especially with the H2O Stadust (modified) theme. I had better post the latest script somewhere... okay, here: http://www.puppylinux.com/forum/azbb.php?1174637854 BarryK
Have posted an updated pmount script with some user-interface tweaks.zygo
Barry, could you please give pmount a setting to stop it from scanning the CD drives when it starts up. This appears to be in MUT (by editing the script) but isn't. Dougal
Barry, I couldn't find the puppyserialdetect source code in the repository. Do you know where I might be able to find it? BarryK
Dougal, I have uploaded puppyserialdetect-1.0.tar.gz source to http://www.puptrix.org/sources/alphabetical/p/
|
Puppy 2.16experiment1, bleeding edge, for developers onlyThis Puppy has the "humongous initrd.gz" which has the pup_215.sfs file inside it (the version number is still set at 215). It also has a subset of the full drivers built-in, just as before we had the "zdrv" file -- probably the only thing you will notice missing is some wireless networking drivers. The initrd is now a cpio archive and a ramdisk as-such is no longer used. Encryption of the pup_save file is supported, with the choice offered at shutdown. Various other things, as reported earlier in this Blog. This build has Opera, not SeaMonkey. Gaim missing also, as Opera has its own IRC chat. One interesting thing, for a developer who would really like to walk on the wild side. The 2.6 kernel supports the "initrd.gz" file being compiled into the kernel. This is done by specifying the path to the "initrd.gz" file during configuration. This is only if the file is a cpio achive. The initrd.gz file in this experimental release of Puppy already has the pup_215.sfs and drivers inside it, so compile inside the kernel and you get just one "vmlinuz" file of about 69M! This has to be the utlimate simplicity for newtork booting! (plus a new world record for biggest Linux kernel) Download from here: http://www.puppylinux.com/test/ ted dog
Too good, yet it is still in a iso? strap a bootloader to the front and only distribute the single file ready to run I wonder what if any GRUB install line will be, for user with fugile types of install. OH did you included the missing DVB in the recompile that I wrote about a few weeks ago. ted dog
darn: The operation timed out when attempting to contact media-nf.puppylinux.com. feel free to upload it to puptrix, you should still have the account setup as before I'll place my DOTconfig (with the corrected DVB modules) for this current kernel, and a version of DOTconfig for 2.6.20.3 [ which is faster than current used kernel ] that I got to work with a HD installed version of 2.14 Ted Dog
http://puptrix.org/DOTconfigs/linux-2.6.20.3/DOTconfig [missing SFS & UNIONFS] http://puptrix.org/DOTconfigs/linux-2.6.18.1/DOTconfig (all included) Ted Dog
Ok OK
some even worse bleeding edge ideas for the single-file-kernel
has-it-all. Multiple cpio archives can be attached to the end of a
kernel, so say multisession would be a single cat >> to the end
of a existing kernel. If my memory is correct linux kernels can be lauched directly from windows boot.ini the option passing was the problem using windows boot loader directly. [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn [b]multi(0)disk(0)rdisk(0)partition(1)\HUGEPUPPYKERNEL="puppy linux 3.0- mega kernel"[/b] Ted Dog
(from http://www.thinkwiki.org/wiki/How_to_setup_boot_loaders)Using the NT Boot Loader to boot Linux The NT boot loader is not able to boot anything else than NT type Windows systems. However, other systems boot sectors can be stored in a file on the same disk that the NTLDR files reside on and can be chainloaded from there. Hence, the procedure to integrate Linux into your NT boot menu is outlines like this (we assume that the NT boot loader is properly installed already): * Install a Linux boot loader (LILO or GRUB) into the boot sector of your Linux partition. * Copy this boot sector into a file. * Copy that file to the root level of the Windows partition. * Add an entry to chainload that file to the NT boot menu. BarryK
Ted Dog, the config used for the kernel in 2.14 and later is here:http://puptrix.org/sources/kernel-2.6.18.1/ I can't remember if I enabled what you wanted, so if not can do so next time. I plan to jump Puppy to a later kernel version sometime but in no hurry for now as there are some issues with some third party modules not compiling. Yes, Ted Dog again !!
mirrored (faster download for most)http://puptrix.org/isos/puppy-2.16exper PkaG
Mirred:http://www.pkagfiles.net/puppy-test Sage
Don't
usually look at exptls, alphas, betas, being a mere user, but the
incorporation of Opera was too promising to miss. For what it's worth,
this exptl. version, for me, far surpasses v2.14 - I like it.
Absolutely nothing wrong with the Opera fonts. Bit of tidying at boot
up - the dots could be confusing? Otherwise, everything a regular user
could ask for. Opera certainly speeds things up; in a compact distro
this [b]the[/b] [i]rational[/i] choice.sad ted dog
nope my DVB drivers are still left out CONFIG_VIDEO_CX88=m # CONFIG_VIDEO_CX88_ALSA is not set # CONFIG_VIDEO_CX88_BLACKBIRD is not set # CONFIG_VIDEO_CX88_DVB is not set # sniff, sniff Raffy
Not to worry, Ted, that should be in when the newer kernel is used. Downloading now but it is slow so will resume in the morning... Sine Nomine
Thanks Barry,I am not a developer but I am using pre-alpha 2.16 on 667mhz celeron with 192mb RAM. I used Opera to down load firefox 2.0.0.3 & after saving to the hard drive & rebooting puppy thinks that I have 1.2G of RAM & I cruising the web!! Thanks again. Sine Nomine kirk
Posting this from 2.16E. Made an encrypted pup_save, worked well. Did a frugal install, grub boot. Symlinked zdrv_214.sfs to zdrv_215.sfs zdrv_216.sfs, didn't know which one. Rebooted and had my wifi drivers loaded. The network wizard doesn't save profiles and doesn't seem to work with WPA anymore or I don't know which of the new options to choose. The Fonts on this page don't look as sharpe. Maybe Opera? Don't care for the grey background in ROX windows. Not sure how low ram computers will handle the big initrd.gz. One problem that's been around for the last few versions, when booting with multiple pup_save files, if you choose "0 -- none" don't use a pup_save file, then your prompted again with the same options. With 2.14 this would happen twice. With 2.16E I had to enter "0" four times. Not a big deal though. Maybe the optional kernel modules that are currently "not set", should be set to M. I needed the saa7134-dvb module. Although, might make the zdrv file too big. Does boot fast. Nice to see ext3. New theme looks sharpe. Nice work Barry. Sage
kirk
wondered about low RAM computers. Testing suggests that the lower limit
is now >128Mb, but addition of another 32Mb will suffice.
Furthermore, this one doesn't like overclocked Intel boards, but is
happy with massively clocked AMD ones - another reason I always avoid
Intel! Concurring with above, this version offers a substantial speed
improvement.Probably good enough as is for most of my needs.JohnRoberts
Hi Barryis there any chance in the near future to update GParted to a newer release, something like 0.3.3 or 0.3.4??? Also, recently, I had a chance to test a backup/restore/cloning tool: DRBL/Clonezilla (http://clonezilla.sourceforge.net/) in the form of a LiveCD (Clonezilla Live & DRBL-Live...). It proved to be one heck of a tool. I cloned an XFS based system from an 80GB disk to a 320GB disk. I really wonder if it is possible to have Clonezilla as a PET package... What do you think??? JR Sage
...except I couldn't install to HD. hdc seems to be mounted by default
and the Installer complains it cannot find hdc. Trying to unmount hdc
via MUT causes a lock-up.Raffy
This baby is quick. With Opera running, I still have 10% of 256 MB RAM free.Tried frugal install first but failed. I will try again... John Doe
Kernel ModulesPlease consider these three also: <i>Miscellaneous filesystems</i> CONFIG_HFSPLUS_FS=m <i>Multi-device support (RAID and LVM)</i> CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m Raffy
Runs fine on live CD but nope, "can't find Puppy" in frugal install...Cthisbear
Barry!I hate Opera and it played up on some of my bank sites. I still use Puppy 1.07 for most banking and ISO burning, because it's just so good..gone but never forgotten. Mozilla in Puppy Viz RC1 ran very fast..so why are we going backwards. At least some Windows refugees have heard about Firefox or used it..so Mozilla shouldn't be too hard. Your Xvesa worked first time as usual.. Mr Never Fail of Puppies, I wish some others would learn the Xvesa lesson. Otherwise fab as usual...The Ian Thorpe of Linux developers. Chris Sage
Glad
you were able to confirm that Installer has an issue, Raffy - doesn't
seem serious, just that it can't see the source. Probably an easy fix
for BK.Cthisbear seems unfamiliar with Opera, which is infinitely superior to all other browsers in respect of which he complains as it can be set to emulate any other browser. It's the only one that will render every website no matter whatever bizarre or undesirable SW was used in their construction. kirk
On the
frugal install, I just copied the two files to hard drive, and edited
grub, Didn't try the installer. I like new stuff to play with like
Opera. Don't know if I'd want to trade it for Seamonkey & Bluefish.Craig
SageI beg to differ, Opera will not work on my bank site. I have tried every emulation setting and still no go. I know puppy is not a democracy and I understand the reasoning for switching to Opera but I prefer Mozilla or firefox. Craig marshal
this version does not seem to work pxe. I keep getting an error pup not found hddis there something new to be added to the pxelinux.cfg default file ? John Doe
The crypt password selection dialog absolutly MUST have a validation entry dialog. Perhaps this is in the works?I've got some logic around if you need it, I could dig it up. BarryK
John Doe, yes, okay, I've made a note of that. Should be easy enough to implement.noprob
was curious about "cpio archives" did a search and came up w/thisthought it might help out? also came here to upload this experimental version of Puppy Linux,but realize this is Not for the masses. Please keep up the great work and Thank You for Puppy Linux! [blockquote]just an end user[/blockquote] |
Puppy 2.15 Community Edition Release Candidate 1Amyway, find out for yourself. Go to the Puppy Forum where there are many threads discussing 2.15CE. To download, go to this thread: http://www.murga-linux.com/puppy/viewtopic.php?t=16571 ...note, the "standard' edition is 120MB. Changing the subject, I have uploaded Opera v9.10 PET package to ibiblio. I'm using it right now. One thing that I'm not happy about is font rendering. The font setup in Opera looks quite good, on the surface, allowing the font to be set for just about everything. Despite that, plain-text pages render to small and nowhere could I see how to change that. Then, this News Blog renders in a bitmap font without any antialiasing and it looks crappy. Nathan
You
can set the minimum font size in Opera by going to the advanced tab of
the preferences window and selecting fonts over on the left. This will
ensure no fonts render below a certain predetermined size. In almost
every browser I'm aware of right now this setting is at 9 for some
reason, while in today's market a more sane choice would be at least 12
and maybe even 13. A font sized at 9 is only going to be handy with
640x480 resolution.While there you can also set things like the the default forms font, things which aren't very easily configured in Mozilla based browsers. Barry Kauler
Nathan, the font problems exist after I have tweaked all the advanced
font settings. I already had minimum font size set to 12. If anyone
else wants to play with the settings, please do -- Opera is in the
2.16experimental1 build.craftybytes
I
found that if you install the "bitstream" fonts pup, then change to
'bitstream' for the fonts in Opera - text on rendered pages appears
quite crisp and clean even down to the minimum of '8' that I've got set
in my Opera install (v9.10) - which I have been running for the past
few weeks in Puppy v2.14 with no probs at all..I usually st most of the font sizes in Opera at '12' for standard sizes - gives clean, sharp text - good for general surfing needs.. Found that many of the other 'standard' fonts rendered rather badly almost unreadable in Opera - whereas 'bitstream' is mainly the one that I come back to .. HTH BarryK
DejaVu is extended Bitstream fonts. But, Puppy only has the DejaVue
Sans (no serif) font, not the mono or serif. Opera is set to use the
DjaVue Sans as the main default and where that is used, it looks quite
nice.GuestToo
i have these options in the [User Prefs] section of opera6.iniEnable Core X Fonts=0 Enable Xft Fonts=1 Helvetica does not look good in Opera, and many web pages specify Helvetica as second or third choice, or sometimes even as first choice ... disabling the use of Core fonts disables fonts like Helvetica the fonts for Opera menus can be tweaked in $HOME/.qt/qtrc Opera also can start with various command line options ... type: opera --help GuestToo
also, setting the env variable:QT_XFT=1 might make a difference ... some of the tweaks that worked with older versions of Opera no longer work, there are different ways to tweak the settings now, but i'm not sure which still work and which no longer work |
Many PET packages updatedPlinej: transmission_gtk-0.6.1-r1518 http://www.murga-linux.com/puppy/viewtopic.php?t=12919 Plinej: pupctorrent-0.7 http://www.murga-linux.com/puppy/viewtopic.php?t=14954 Plinej: soxgui-0.9 http://www.murga-linux.com/puppy/viewtopic.php?t=13935 Rarsa: remotedesktopclient-2.15-2 http://www.murga-linux.com/puppy/viewtopic.php?t=14753 Rarsa: pvolume_mixer-0.3 http://www.murga-linux.com/puppy/viewtopic.php?t=15640 Plinej: pbcdripper-2.5 http://www.murga-linux.com/puppy/viewtopic.php?t=12088 Plinej: pawdioconverter-0.6 http://www.murga-linux.com/puppy/viewtopic.php?t=15363 Rarsa: net_setup-2.15-1 http://www.murga-linux.com/puppy/viewtopic.php?p=99397 |
Glipper, snapmergepuppy, H2O-stardusthttp://www.murga-linux.com/puppy/viewtopic.php?t=16450 Zigbert has adapted the H2O Stardust GTK2 theme to work in Puppy. It is very small and looks nice. I have lightened up the blue buttons and made it the default for my next Puppy. Forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=16203 Andrei has done some work on /usr/sbin/snapmergepuppy. This is a script that writes the tmpfs unionfs working layer to permanent storage at regular intervals. This is done when booted from USB Flash and for multisession CD/DVD. It is an ongoing battle to eliminate unionfs whiteout-file bugs, and andrei has identified and fixed some in this script. I've given it some preliminary testing and it looks good, so it is going into the next Puppy. Forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=15980 |
Pbackup, Pfind, Pupdvdtool updatedZigbert: Pbackup v2.0.0 Zigbert: Pfind v1.0 Plinej: Pupdvdtool v0.8 Of course you won't see these in the 2.14 PETget package-selection 2-pane window, as these are later versions. They are uploaded for developers to access. However, anyone can download them individually and click to install. John Doe
I decided to give these a test, so I remastered with them and I get this:sh-3.00# pfind /usr/local/pfind/pfind: line 799: gtkdialog3: command not found sh-3.00# pbackup /usr/local/pbackup/pbackup: line 728: gtkdialog3: command not found sh-3.00# pupdvdtool /usr/local/apps/pupdvdtool/main: line 34: gtkdialog3: command not found sh-3.00# Did I leave something out? Barry Kauler
I think ibiblio has the latest gtkdialog, with gtkdialog3 executable.John Doe
Thanks! That was it. Sorry for the stupid question, I should have just searched the package directory.All three work great. |
Problem with swap partition in initramfsWith the previous ramdisk system, pivot_root made the new f.s. as '/' and the ramdisk became /initrd. If the 'init' script had executed 'swapon /dev/hda5' (for example) then after pivot_root the swap partition is then seen as /initrd/dev/hda5. This is confirmed by 'cat /proc/swaps'. With the new initramfs, after switch_root, although the swap partition seems to still be working, 'cat /proc/swaps' shows it as '/dev/hda5\040(deleted)' --which totally upsets swapoff. I puzzled over this, spent a full day searching the web for a solution. Eventually I contacted Rob Landley, who wrote the Busybox switch_root applet. Rob also wrote this: http://timesys.com/timesource/initramfs.htm After some discussion, Rob tentatively thought that it is a kernel issue, a bug. He suggested a quick and dirty hack to fix it for now, that I have implemented. This requires creating /dev as a tmpfs in the initramfs and create all the device nodes in it. Then before doing the switch_root, execute 'mount -o move /dev /pup_new/initrd/dev', which moves the mount-point of /dev into the main filesystem that will be active after switch_root. I'm not happy with having to do such a hack, but at least it works -- now 'cat /proc/swaps' shows the swap partition as '/initrd/dev/hda5', exactly as in the earlier ramdisk system. craftybytes
Does
the swap partition / file have to be loaded in the 'initramfs' - could
it instead be detected & loaded in the secondary 'init' script or
even in the 'rc.sysinit' script ..?If one can "turn" swap on / off in MUT - then there must be ways to to turn it on/ off in the 'init' script after the initial 'initramfs' has completed ..? HTH Dougal
Barry, is the new initrd still remounted rw, even though it's not a ext2 fs?BarryK
Dougal,
yes, but switch_root destroys it, so it doesn't exist after that, so
you cannot chroot into /initrd as before. However, /initrd does still
exist, but it is just a directory into which I have moved the important
stuff from the initramfs. For example, the mount points, pup_rw,
pup_ro1 etc are moved to pup_new/initrd so that they are still
accessable after the switch_root.Note, Rob's opinion about the problem with the swap partition getting lost after the swith_root is that the kernel is tracking the inode of /dev/hda5 (for example) instead of the partition, for compatibility with swap files. Although /dev/hda5 exists after switch_root, the kernel is looking for an inode that has been destroyed. Rob considers that to be essentially a bug. My hack is to mount a tmpfs on /dev and do a "mount --move" (or "mount -o move") but it would be nice if there was some way to move just the inode. PaulBx1
craftybytes makes a good point. Do we really need swap so early in the
process? If not, then isn't all this problem with the bug/hack
bypassed, by turning swap on later?I guess that depends on what happens with small memory systems. It may be that some memories are so small that swap actually gets used during boot, although that would be a little surprising. BarryK
Yes,
there are situations where we turn on swap in the initramfs. Low-RAM
situations, for example the multisession CD where we want to load as
much as possible from the saved sessions from CD into RAM at bootup.Dougal
Barry, you might also want to copy the log file from /tmp in the initramfs to the /tmp in NEWFILESMNTPNT...Barry Kauler
Dougal, yep, that's already done, plus I've created some extra log files to help with debugging.
|
The 'pup_save' file may now be ext3 filesystemA long way back, in the 1.x series, the pup_save was always ext2, then we moved to ext3, then in recent Puppies back to ext2. Read down this blog for further information. The next experimental Puppy (2.16pre-alpha) will create a pup_save that is normally ext2, but if the pup_save file is on a fast hard drive that itself has a journalled f.s. (ext3 or reiserfs) then the pup_save will be ext3. The reasoning for this is dicussed at various forum threads, including here: http://www.murga-linux.com/puppy/viewtopic.php?t=15668 At bootup, a f.s. check is only done at every bootup if it is a ext2 f.s. in the pup_save. If encrypted, then it is not done at every boot either, regardless of whether it is ext2 or ext3. The automatic logic at shutdown as described above does allow for creation of a encrypted pup_save with ext3 f.s. I don't know whether we should bar all encrypted pup_saves from being ext3. Probably best to try it and see. craftybytes
Barry,As puppy already [b]knows[/b] what media types are being used in the session (from the boot scripts) - then maybe one could allow for [i]selecting [/i] if 'pup_save' file should be saved as ext2 or ext3 ..? - I would suggest that it should "default" to what format the 'pup_save' file was originally [i] loaded [/i] by the boot scripts - but a 'selection' should be possible ..!! This would make most puppy users happy.. pakt
Barry, while you're working on init, perhaps you should finally
consider adding the Puppy version to the pup_save file, e.g.
'pup_save_216.2fs' (or with 8.3 'save_216.2fs').This would be consistent with numbering of 'pup_216.sfs' and 'zdrv_216.sfs' and make it easier, e.g. to dual-boot two Puppies and for the user to tell which Puppy a save file belongs to (without having to loop mount it first - also making the init logic a bit simpler). Paul PaulBx1
"I don't know whether we should bar all encrypted pup_saves from being ext3."I don't quite understand this statement. The only connection that this ext2/ext3 choice has to do with encryption, is that fsck's are slow with encryption. Otherwise, the only reason these discussions show up around encryption forums is that encryption often uses file-backed loop devices. Here is something I dug up earlier that explains what configurations are dangerous: ------------------------ Jani Averbach wrote: > Is there any way to mix loop-device (and in particular) loop-AES and ext3 > together in data journaling mode? Device backed loops (ext3 -> loop -> device) don't have issues with ext3 or any other journaled filesystems. However, if loop is file backed (ext3 -> loop -> ext3 -> device), the underlying file system must be mounted data=journal or data=ordered. If underlying filesystem is mounted data=writeback or if it is plain old ext2, write ordering expectation by journaled filesystem (ext3, reiserfs, jfs, xfs, or whatever) on top of loop driver is not guaranteed, and journal replay may corrupt data. Use of non-journaled file systems on top of file backed loop don't have above mentioned write ordering issues, as they must be repaired using fsck, not by replaying journal. Regards, Jari Ruusu <jari.ruusu@pp.inet.fi> ------------------------- As you can see, just having ext3 as the underlying fs does not protect you; you also need data=journal or data=ordered. Who knows what happens when the underlying fs is ntfs or reiserfs; maybe that is OK. FAT is not, I think. This is why I thought it made sense for any file-backed pupsave to be defaulted to ext2. It just makes everything easier. And let those who don't like ext2 go ahead and use ext3 if they want. See also this thread, where we hashed over this before: http://www.murga-linux.com/puppy/viewto |
'pfix=nox' boot parameterhttp://www.murga-linux.com/puppy/viewtopic.php?t=15949 I've implemented this in Puppy. The boot parameter 'pfix=nox' means "no X", so when Puppy starts you will just get the commandline. This is different from 'pfix=rdsh' which drops you out to the commandline in the initial-ramdisk, whereas 'nox' drops you out in the main filesystem after the initial ramdisk has done its thing and gone. At the commandline, you can run any cli apps, like the 'mp' text editor, and you can type 'xwin' if you want to start X. I implemented it a bit differently to the way posted in John's thread. In the 'init' script, if 'pfix=nox' is detected, the script creates /tmp/bootcnt.txt', an empty file. /etc/profile, which is the script that executes when Ash/bash is loaded, will only execute /usr/X11R7/xwin (the script that starts X) if bootcnt.txt does not exist (this is a mechanism to prevent X from restarting when you exit from X to the commandline, as /etc/profile gets re-executed everytime that Ash/Bash starts (that is, at an axit from X, Ash/Bash gets started so that you have a prompt and /etc/profile also executes). Nathan
That's
awesome. You've done it in such a way that it won't mess with my login
manager setup in Grafpup, which also uses bootcnt.txt.
|
Upgraded losetup and ls to full versionsfloordog (floordog<at>yahoo.com)
Does PuppyOS support multiple (4-5) GIGALAN ports on a Core 2 duo mobo?Jeffrey
That's interesting. The Busybox "ls" seemed pretty good. The Busybox
"ps" on the other hand is a sadly crippled beast, reporting neither
parent PID nor total CPU time accrued for each process. If it's not
enormous its addition would make Puppy Linx look more like a Linux/Unix
OS to a command-line guy like me.Nathan
Yes,
but if we just dumped ps in there without thinking it would cripple a
lot of scripts that use the busybox version. Best to do it the way
Barry has been doing, add it in alongside the Busybox version, at least
for a few releases, then perhaps take it out later after people have
had a bit of time to port their scripts.
|
Goodbye ramdiskIn Puppy Unleashed, it is easy enough to build a cpio archive from the contents of boot/initrd-tree rather than a ext2 filesystem. The created file is still named 'initrd.gz'. Only small changes had to be made, mostly for the 'init' script -- it had to be relocated at '/' in the filesystem instead of /sbin, and the script has to use 'switch_root' rather than 'pivot_root'. I modified the script so that after the switch from the "initial ramdisk" to the main filesystem, there is still an /initrd directory as before, with the unionfs layers mounted in it, as before. One advantage of the cpio "initial ramdisk" is that it doesn't actually use a ramdisk. Previously, Puppy used /dev/ram0. The new system is actually a 'ramfs' which has more efficient memory management and can be any size. So, the boot parameter 'root=/dev/ram0' is no longer required, and also for large initrd.gz files there is no longer any need for the 'ramdisk_size=' parameter. The only kernel parameters I need now, for example I just tested booting from USB Flash: initrd=initrd.gz pmedia=usbflash After the switch_root, the "initial ramdisk" is totally removed, which also means very efficient memory usage. Anything wanted to retain, such as the mounted unionfs layers and other filesystems mounted while in the initial ramdisk, are moved to a directory /initrd in the main filesystem. I'm trying to set it up so that everything looks much like it did before, so everything should work as before. Any scripts that look into /initrd will see the same stuff, as least what matters. The user won't even know there has been a change ...so, why do it? More efficient memory usage is good for PCs with less RAM, plus removal of the ramdisk size limitation does open up some future possbilities. J_Rey
Sounds excellent! I'm just curious on how this affects full/normal hd installs....Dougal
Barry, this seems great. Does it mean that /initrd will only have the few used mountpoints in it? I think some of the other mountpoints are needed for the idea of mounting/umnounting on the fly (what they're discussing in the Aufs thread). And what about trying out Aufs while you're playing with such fundementals? (or will it have to wait until you also recompile everything?) BarryK
Aufs... no, I would like to take one step at a time, bring out a
release with just the changes so far, make sure it's rock solid.
Besides, one of our Puppy enthusiasts, andrei, has tracked down some
unionfs whiteout bugs in the 'snapmergepuppy' script, which I am about
to test, so we might have unionfs working pretty good. Aufs looks
simpler though, so probably good to migrate to it sometime.I'v setup initrd.gz to it works just as before. Install to h.d. is as before, all the mountpoints as before, every as before (touch wood). The 2.6 kernel is able to create an 'initramfs' as part of the kernel, not a separate file, which caused me some confusion at fist. Then I found that it can be a separate file, just like we have been using so far, and some major distros do it this way. So the new 'initrd.gz' looks almost identical to before. It took me awhile to get 'switch_root' to work, and at first I actually had the old 'pivot_root' working which is not supposed to work in that situation. Anyway, I figured out the mods needed to the 'init' script to get switch_root to work. I'll upload a 2.16pre-alpha for people to play with soon. This is not intended to compete with 215CE, it's still rough, just for those who want to see and test the new scanning in the 'init' script, new encryption and the new cpio archive in action. Oh yes, the "humongous initrd.gz" also. craftybytes
And here I thought I was just some deadwood floating around on the fringes ..  My research into the 'initRAMFS' method also suggests that [i]encryption[/i] using "cryptoloop" with "AES" - and - file [i]swapping[/i] (re:- '.sfs' & '2fs' files) either using "unionfs" or "aufs" - should be much easier to implement.. Also there may be possibilities of not needing to use the current '2fs' / '3fs' (ext2/ext3) methods for [i]saving[/i] a session - one could actually save using the '.sfs' (squashfs) method - thus making the 'saved' files much smaller .. Anyway - I'm glad I could make a contribution - small as it was.. Dougal
Barry,
you might as well just upload the new initrd.gz, since it has all the
modifications in it... (just set the version to 214 and we'll be able
to use it with the old sfs...)J_Rey
To
expand on craftybytes' comment, I had an idea.
Compressing/decompressing on the fly would obviously slow down Puppy,
but what about on bootup uncompressing from SquashFS or similar to and
using a pup_save same as we have been but with size dependent on free
space and on shutdown compressing back down? Could be same as is but on
bootup/shutdown would compress/decompress and pup_save would
auto-resize. Of course if Puppy crashed and didn't shutdown then an
on-boot cleanup would be needed. Just an idea to consider or experiment
with....BarryK
Dougal, no, I had to make some small changes in /etc/rc.d also. I'll upload in a few days.craftybytes
Barry,J_Rey made comment re - Puppy crashing ..! Is the 'pup_save.2fs' file always mounted and open whilst Puppy is running ..? If the contents of 'pup_save.2fs' are [i]copied[/i] to the r/w layer of unionfs - then one would think that the [b]real[/b] 'pup_save.2fs' file on the CD/USB/Hard drive media could then be [i]closed[/i] AND [i]unmounted[/i] till actual shutdown/reboot - whence it can then be [i]remounted[/i] and [i]opened[/i] ready for doing the [b]save[/b] of the session ..!! Another thought - if the contents are actually [i]copied[/i] - then does the [b]real[/b] 'pup_save.2fs' file need to be retained on shutdown/reboot ..? - could not the [b]save[/b] be done to a NEW 'pup_save.2fs' file and if the 'write' was OK then the ORIGINAL file can then be deleted ..? Random thoughts just [i]flashing[/i] around in my [b]degrading[/b] vacant brain space .. Pizzasgood
Normally the save-file is mounted directly. In a USB-setup, it's only
mounted read-only and any new files are stored in ram and copied to the
save-file every thirty minutes and on shutdown.
|
Lock up your Puppy!http://www.murga-linux.com/puppy/viewtopic.php?t=15668 http://www.murga-linux.com/puppy/viewtopic.php?t=14114 I built support for loading an encrypted pup_save file into the 'init' script in the initial-ramdisk, see previous post. Over the last couple of days, I have built encryption support into the shutdown script, /etc/rc.d/rc.shutdown. Now there is a dialog box that asks if you want to encrypt the pup_save file, and you can choose 'light' (xor) or 'heavy' (aes) -- reason for this is that heavy can have a performance penalty. The shutdown script also asks for a username and password -- yes, an optional username, that gets put into the pup_save file, like this: pup_save_crypta-fred.2fs. At bootup, if there are multiple pup_save files, the choices are now displayed with these usernames, as well as the names of the pup_save files. We could have a boot parameter to further reduce boot messages and only display the usernames. These encrypted files are a step toward solving the problem of users who want to share the same Puppy-installation with spouse and kids -- now they each get their very own pup_save file to play in! Normal multiuser Linux can't do that, but of course we don't don't have the 'group' protections, to for example prevent little Johnny from mounting a partition and wiping everything. Not yet anyway  The losetup program is odd. I had to put it into the initial ramdisk, but today I found out how it could probably be made to work from the main f.s., by use of the '-p' option. Will investigate that further. John Doe
Can't wait to try it out Sage
Just
can't convince myself that this is the best approach for 'family' use
of Puppy (or other distros), especially if even more size penalties are
incurred.The obvious solution is one HD per person on a caddy system. It's not as if the average user is needing a 500Gb drive! Average users I encounter find it difficult to fill a 2GB unit. Photo, video and music phreaks would be best advised to used twin drives? Or better, boot Puppy from an USB keyfob and place data on an HD. However, we are always advocating Puppy for use on older HW, so it's not difficult to find one entire PC per family member by picking out something from a roadside skip or the local amenity tip! Sorry if you think this isn't sufficiently technical for your blog, Barry, but it does address very directly the issue you raise under today's title! Leon
Encryption and multi pup_save file system are two important and useful Puppy features.BarryK
Leon, yes, there's virtually no overhead to provide this encryption
feature, and it offers yet another way that Puppy can be used. One
catch though, is that the password input at bootup is only going to
work for a qwerty keyboard -- perhaps a kernel boot param would be
needed for other basic layouts, that PKEY parameter.Leon
Barry, no problem. Instinctively, I never use any of specific Slovenian
characters in my passwords and also never use 'y' or 'z' character to
avoid possible problems with the keyboard layout.cb88
Does
this support the encryption engine in via's c7 proc? I don't have one
but users of mini pc's and some laptops would greatly benefit since I
have heard that it is really fast up to 20Gb/sec at 2 Ghz using an
infinite random number generator to make files nearly impossible to
crack or so I have heard.http://www.via.com.tw/en/products/processors/c7/ PaulBx1
It's
very unlikely this old cryptoloop (I assume that's what Barry is using)
will support any new hardware designed for encryption.Barry, are you creating a new encrypted pupsave, leaving the old one alone? Or somehow encrypting the working pupsave? Did you retain random numbers in the generation of the pupsave, as was done in my convert-pupsave? If not, the "heavy" encryption is not really very heavy. I am happy to see this getting into standard Puppy. The size penalty is very small, and as to performance I have only noticed a slightly longer boot (when using encrypted pupsaves - no penalty without). John Doe
I too
would like to make sure that Paul's research on saving the file is
followed. What he worked out was very specific in order.--- Haven't seen the current implementation but just wanted to mention that: zcat /lib/modules/${KERNVER}/cryptoloop.ko.gz | insmod - Probably doesn't need included or loaded. If it's still there, that's my fault. After all our posting, I think loseup only uses aes (or other crypto mod) and not cryptoloop (it's something different). --- Where is 'pupsavefunc'? I still can't find it. Barry Kauler
Oh,
I'm loading the cryptoloop module. Yes, also the 'heavy' encryption is
not so heavy. It would be good if I uploaded Pup 2.16pre-alpha soon,
with all this new encryption and cpio initrd and improved scanning in
the init script. You could then use that as a basis to work on, and
make further refinements.kirk
The cryptoloop module is needed.The encryption is pretty strong, if you use a strong password. I've seen a lot of theories about how to crack it, but nothing concrete or close to easy. Has anyone suggested adding the capability to mount encrypted 2fs files as individual drives using MUT? This would really make Puppy a lot safer to use for applications that deal with sensitive data (medical, military, corporate, etc.) than any of the Win alternatives. --MDD esmourguit (esmourguit<at>tele2.fr)
Barry wrote "Now there is a dialog box that asks if you want to encrypt the pup_save file, and you can choose 'light' (xor) or 'heavy' (aes) -- reason for this is that heavy can have a performance penalty. The shutdown script also asks for a username and password -- yes, an optional username, that gets put into the pup_save file, like this: pup_save_crypta-fred.2fs. At bootup, if there are multiple pup_save files, the choices are now displayed with these usernames..." Thank you Barry, it is exactly what I hoped for. PaulBx1
"Has anyone suggested adding the capability to mount encrypted 2fs files as individual drives using MUT?"I believe this is relatively easy to add to MUT and pmount, given the work we've done on the pup_saves. We focused on the latter just because there was a big desire to protect "everything" by default. If you go the other route you have to be aware what data is in what place, but now that we have the information this change you suggest is probably well worth doing. I'm too busy right now though. BTW this encryption is trivially easy to bypass if you use swap, as your passwords can show up there in cleartext (I read an article where someone researched this on a big system, and was amazed at the info he found in the swap f |