Psync 0.9

Forum member tasmod (Robert) has created a neat little app to synchronise the clock to an Internet time server. There are some caveats but it looks good, and fills another niche in Puppy's comprehensive application-suite. Forum thread:

http://murga-linux.com/puppy/viewtopic.php?t=42978

This will be in 4.3beta1. I am approaching the point of freezing the package selection as the beta approaches, however this is a stand-alone package that is small and does not (I think) potentially compromise anything else in Puppy.

---

Comments

Optional UTC
Username: Pizzasgood
This is a little bit off topic, but it would be nice if Puppy had a built in way to specify whether it interprets the HW clock as utc or localtime. Localtime is great for cooperating with Windows, but being able to tell Puppy to use utc (without modifying scripts) would be nice for the people who dualboot with other linux distros. It isn't hard to do. AFAIK only three files in Puppy need modification (/usr/sbin/timezone-set, /usr/sbin/set-time-for-puppy, and /etc/rc.d/rc.country). I already implemented a simple form of that here: http://www.murga-linux.com/puppy/viewtopic.php?t=41680 The patch won't quite apply all the way in 4.3, but it's pretty simple to complete by hand and anyway I already uploaded a package for 4.3 pre-beta-reloaded that contains the modified files a couple posts down in that thread. I also set up a simple gui for choosing which one to use and updating the hw or software clock to match. I believe Psync would need some slight modifications to support utc if this were to be used. It would just need to look and see if /etc/clock exists, and if so source it. Otherwise initialize the HWCLOCKTIME variable to 'localtime'. Then when using hwclock to interact with the hardware clock it would use the '--$HWCLOCKTIME' option rather than '--localtime'. Also, while I'm here, I tested Edit-SFS the other night and it worked fine. Are you sure you didn't try to edit a .sfs file from a different version of Puppy? I notice that 4.3 is unable to mount the files from 4.2, and vice-versa (I assume they use different compression algorithms). I do intend to look at polishing it a bit sometime in the next month. The next two weeks in particular are going to be chaotic as I start my senior year of college so I don't really know _when_ this month.

re: UTC
Username: BarryK
"pizzasgood, That might be another one we have to hold over to pup 4.4. Yes, the kernels from 2.6.29 onward have squashfs 4.0 which is incompatible with earlier sfs files. This is a problem that we have been discussing. It means that if we build 4.3 with two different kernels, say the "standard" with 2.6.25.16 and the "advanced" with 2.6.29.6 then anyone who creates an SFS file will have to create two of them. Messy. I wonder if it is possible to read a sfs file and determine what version of mksquashfs was used to create it? I just tried something: [code]# disktype pup4-416.sfs --- pup4-416.sfs Regular file, size 74.58 MiB (78204928 bytes) Linux squashfs, version 3.1, little-endian Compressed size 74.58 MiB (78201196 bytes) Block size 128 KiB[/code] ...ok, as I have 'disktype' in the initrd, I reckon that I could test an sfs first, if it's the wrong version then put up an information message.

Tags: woof