Vanilla Dpup 9.2.0 Preview

[wiak]

@wiak Try apt install firmware-sof-signed

Yes, thanks; audio works for me on this laptop now.

[dimkr]

preview15 will be uploaded soon and adds https://github.com/puppylinux-woof-CE/woof-CE/pull/3130, an X port of Puppy's Wayland input device properties wizard.

[dimkr]

preview16 will be uploaded soon. All the fixes and improvements that went into previous builds are now integrated into woof-CE, except one (gplaces is removed).

preview16 is built from woof-CE, as-is, except 4 additions:

• Update to the latest JWM - https://github.com/puppylinux-woof-CE/woof-CE/pull/3132

• Fix for pupsave-backup (it was broken since 2017!) - https://github.com/puppylinux-woof-CE/woof-CE/pull/3131

• The mouse/touchpad wizard - https://github.com/puppylinux-woof-CE/woof-CE/pull/3130

• Support for man pages in the main SFS - https://github.com/puppylinux-woof-CE/woof-CE/pull/3127

(I prefer to get these four changes merged into woof-CE before the final 9.2.0, to start off on the right foot, but it's not a must.)

Consider preview16 to be a "release candidate" of sorts: I will gladly fix remaining critical issues, but anything else can wait for 9.2.1, 9.2.2, etc'. Big thanks to anyone who helped test these preview builds and make 9.2.0 a well-polished release!

[Duprate]

Hi Dimkr! I installed Vanilla Dpup 9.2.0 Preview 16. Everything is working fine. I'd just like to make a suggestion: I think Firefox-esr could be in a separate file (adrv_vanilladpup_9.2.0.sfs). So, whoever doesn't want to use it, just remove the file. After configuring the savefile, I converted it to ydrv_vanilladpup_9.2.0.sfs, as I did in previous puppies (adrv, browser) (ydrv, savefile). After that, I don't add anything else like savefile (pfix=ram,fsck). Immutable system forever, no bugs or defects!
What is the real need for the bdrv_vanilladpup_9.2.0.sfs file?

[Duprate]

It was also observed that, after the initial configuration, setting the time zone, for me, America-São_Paulo, the time is correct. When I start any of the other systems installed on the PC, the system time is 3 hours ahead.

[dimkr]

What is the real need for the bdrv_vanilladpup_9.2.0.sfs file?

bdrv contains apt and the Puppy->Debian delta that makes Puppy more Debian compatible. It doesn't have to be a separate SFS really, but putting it on top of the main SFS (in the aufs stack) adds some safety.

I think Firefox-esr could be in a separate file (adrv_vanilladpup_9.2.0.sfs).

It's a problem. apt keeps track of installed packages, and apt's state is part of bdrv. The moment you install or remove a package, the current apt state is copied to the save file/folder. Therefore, if both adrv and bdrv contain apt state files (with Firefox installed, and without it) but you remove adrv at some point, apt still thinks Firefox is installed. The whole concept of SFSs is incompatible with package managers.

Also, the main SFS vs. adrv split causes other problems, like inconsistencies in setup-spot.

I think users who want to customize Vanilla Dpup should just rebuild it (I don't mind writing a guide, if the current ones aren't good enough), instead of trying to customize the installation by removing or modifying SFSs, or by "remastering". It's easier to build your own dpup, and the result is much more elegant (because unused dependencies are dropped).

[williwaw]

I think users who want to customize Vanilla Dpup should just rebuild it (I don't mind writing a guide, if the current ones aren't good enough), instead of trying to customize the installation by removing or modifying SFSs, or by "remastering". It's easier to build your own dpup, and the result is much more elegant (because unused dependencies are dropped).

Dima, can you point to a current guide that illustrates your recommendations for the more elegant method?

[dimkr]

Dima, can you point to a current guide that illustrates your recommendations for the more elegant method?

This is by far the quickest way to build Vanilla Dpup:

https://github.com/puppylinux-woof-CE/w ... -on-GitHub

The only difference is that you need to use https://github.com/vanilla-dpup/woof-CE if you want to use the same stable woof-CE.

[Duprate]

It was also observed that, after the initial configuration, setting the time zone, for me, America-São_Paulo, the time is correct. When I start any of the other systems installed on the PC, the system time is 3 hours ahead.

Actually, this is the problem that can derail my use of Vanilla Dpup 9.2.0 ...

[williwaw]

This is by far the quickest way to build Vanilla Dpup:

https://github.com/puppylinux-woof-CE/w ... -on-GitHub

The only difference is that you need to use https://github.com/vanilla-dpup/woof-CE if you want to use the same stable woof-CE.

Thanks for that. I will try to get up to speed with github.

On a different subject, I have been trying to extract the .sfs in 9.2.0. (trying to run vanilla in a container)

three out of the five sfs's extracted ok (with both tools I tried) but both tools failed to extract puppy and bdrv sfs's. Perhaps they are different somehow?

[dimkr]

three out of the five sfs's extracted ok (with both tools I tried) but both tools failed to extract puppy and bdrv sfs's. Perhaps they are different somehow?

Mounting can fail if your kernel is built without support for zstd decompression. zdrv, fdrv and kbuild use xz compression, and that can explain why you can decompress only three.

[dimkr]

It was also observed that, after the initial configuration, setting the time zone, for me, America-São_Paulo, the time is correct. When I start any of the other systems installed on the PC, the system time is 3 hours ahead.

Actually, this is the problem that can derail my use of Vanilla Dpup 9.2.0 ...

Vanilla Dpup automatically synchronizes your clock when you go online, like most distros other than Puppy. But it synchronizes the clock without changing the timezone (because it doesn't know your location).

Maybe your timezone is not set correctly in the other operating system: your Puppy uses GMT-3, as you configured, but the other operating systems think you're in GMT-0, so they don't subtract 3 hours from the timestamp saved to the system clock.

[williams2]

Vanilla Dpup automatically synchronizes your clock when you go online,

I don't care if you set the system clock.

But, please do not touch my hardware clock without asking permission first.

I set my hardware clock to an accuracy of about +- 0.04 seconds (probably more like +-0.004).
That was about 634 days ago. (When Fatdog changed my hardware's clock settings.so I had to set it again. grrr.)
My hardware clock is a little more than 1 second fast per day.
So I set /etc/adjtime so that it adds about -1.102557 seconds per day.
So that when the system clock is set from the hardware clock,
it is correct to about +- 0.5 seconds. (after about 2 years of drift.)

So, please leave my hardware clock alone, unless you ask permission first.

[williams2]

Maybe your timezone is not set correctly in the other operating system:

Also, are your OS's all using local time or are they all using UTC?
What do you have in /etc/adjtime. ?

If one is using localtime and another is using UTC, if you set one correctly, then the other will be wrong by 3 hours.

Usually, you need to use local time if you are dual booting with MS Windows.

[dimkr]

So, please leave my hardware clock alone, unless you ask permission first.

There's a reason why NetworkManager, ConnMan, etc' synchronize the clock against the NTP server specified by your router. Many computers have inaccurate clocks (I have more than one of those), and some computers with bad batteries fail to save the time. When time is not set correctly, HTTPS handshakes start to fail, file system timestamps are messed up and so on.

If you really want to disable the NTP client, you should edit /etc/connman/main.conf. Most users want things to "just work", even if the hardware clock is faulty.

[wiak]

jamesbond explained it perfectly in long ago post:

https://forum.puppylinux.com/viewtopic.php?p=5550#p5550

This is because most puppies choose to keep the hardware clock (hwclock aka RTC) in local time.
This is a __VERY__ bad practice inherited from Windows days (which it inherited from MS-DOS, and MS-DOS always stored hwclock in local time because ... well just don't get me started).

Unix systems, on the other hand, traditionally always keep hwclock in UTC.

His sentiments are echoes by Arch Wiki:
https://wiki.archlinux.org/title/System ... e_standard

If multiple operating systems are installed on a machine, they will all derive the current time from the same hardware clock: it is recommended to adopt a unique standard for the hardware clock to avoid conflicts across systems and set it to UTC. Otherwise, if the hardware clock is set to localtime, more than one operating system may adjust it after a DST change for example, thus resulting in an over-correction; problems may also arise when traveling between different time zones and using one of the operating systems to reset the system/hardware clock.

Overall, the issue has and continues to be a nightmare for decades; Puppy tends to use localtime I believe. Some distros (presumably FatDog use UTC) and others just rely on NTP to set things up (but shutdown routines might be changing the hardware clock thereafter to match...). No easy answer to that mess. My distro disclaimer would be: don't blame me if your other distro clock gets messed up - I have no idea what I am doing.

[dimkr]

just rely on NTP to set things up (but shutdown routines might be changing the hardware clock thereafter to match...).

NTP doesn't set the timezone.

You need to understand the difference between the timezone and the timestamp. These are two separate variables, not one.

NTP is used to set the timestamp, and the timezone is used to display that timestamp in a human-readable way. Most distros either set the timezone based on location (possibly, after an IPv4-to-location conversion) or let the user specify the timezone, during installation.

If the system clock is set correctly by NTP but the timezone is incorrect, HTTPS handshakes will succeed and files won't be "created in the past", because these things use timestamps in UTC, or with a known timezone (so an application can compare a given timestamp with the system clock, by adding or subtracting the timezone). However, the time shown in the JWM tray won't be the correct wall clock time, until you select your timezone.

I opened https://github.com/puppylinux-woof-CE/woof-CE/pull/3139, and I think it makes sense to change the default to UTC. However, the user still has to select the timezone, because NTP doesn't do that, and I don't like the alternative (automatic detection that violates the user's privacy).

[Grey]

Puppy uses GMT-3

It was with an error of three hours that Puppy showed the time when I used it in parallel with Windows. But I found a simple and elegant way out of the situation.

I just deleted Windows And switched to free software.

[wiak]

NTP doesn't set the timezone.

Of course I always set my timezone (whether NTP being used or not), which is Pacific/Auckland for my case.

[wiak]

I just deleted Windows And switched to free software.

yeah, sure, but try Puppy then FatDog and maybe your free software will still demonstrate some issues. I think no-one can make their mind up, but recommended is to adjust everything to use UTC (at least that's what Arch recommends for sensible reasons). Forum members have been posting about these same time-machine issues for decades; well that goes for lots of stuff.

[Duprate]

It was also observed that, after the initial configuration, setting the time zone, for me, America-São_Paulo, the time is correct. When I start any of the other systems installed on the PC, the system time is 3 hours ahead.

Thanks to everyone who commented on this! I followed the guidelines contained here. Again, in the initial setup of all operating systems, I just ticked "Hardware clock set to UTC". Now everyone is timing the right time. A simple, recurring problem that only affects those who have many systems installed. Sometimes we don't know or forget how to solve the issue! Thanks!

[Grey]

@Duprate
Designer-fussy mode is enabled
----------|
The beaver and ring of Void protrude beyond the edges of the front side of the folder. It's okay, but:
1. Stylistically stands out from the overall picture.
2. The illusion is created that they are glued, not drawn.
On the other hand, these are the first and last folders and we can say that this was intended
----------|
Designer-fussy mode is off.

[Grey]

By the way, when I'm just browsing the forum without logging in, the time under the posts is shown three hours earlier than after logging in. I don't really care about it, we just talked about it and I remembered

[Duprate]

Okay, Grey!

Testing with kernel 5.18.1-lxpup64 .... Papaya with sugar!

[Grey]

Okay, Grey!

Don't pay attention. I'm just grumbling. I'm a little angry with Brazil The fact is that all the women of my family forced me to download from torrents ALL the Brazilian TV series that were shown in Russia in the 90-2000 years. Not only do I have a backup hard drive full, but I also have to (I was forced to) watch it all

What has already been reviewed:
Por Amor, Laços de Família, Mulheres de Areia, O Rei do Gado, Andando nas nuvens, A Próxima Vítima, Senhora do Destino, Avenida Brasil...

As a result, I can no longer look at the statue of Christ the Redeemer (& Susana Vieira. God, she's EVERYWHERE! )... We'll be watching O Clone soon, and I don't remember if there's a statue there anymore.
The best character... Tonho da Lua (Mulheres de Areia).

[Duprate]

Oh! I'm sorry, Grey! I felt sorry for you.... It's a lot of punishment! Still had to watch it all.... You must be devastated! Brazilian TV is bad! I only watch some news, and also NETFLIX on the internet, which has the same quality as Brazilian TV!

[Duprate]

Wow! I think we got lost, and got off the main subject....

[mikeslr]

From OP:
"A preview build of 9.2.0 is uploaded to https://github.com/vanilla-dpup/release ... -preview16 (x86_64) and https://github.com/vanilla-dpup/release ... -preview16 (x86)."

Links are broken. Hunting on github for the most current 64-bit leads to https://github.com/vanilla-dpup/releases/releases/. None of the downloads provides a operating system deployable as a frugal from a hard-drive.

[Duprate]

I downloaded vanilladpup-x86_64-9.2.0-preview18, from:

https://github.com/vanilla-dpup/release ... -preview18

Testing .... ROXapps (LibreOffice_7.3.2.2, Gimp_2.10.7, Clamav0.105.0, Wine-3.3 32bits + patch 32bit-compat-slacko-14.2 and AppsPortable Platform with various programs and games, Firefox 101.0, Google Chrome, Brave and Vivaldi) ... everything working perfectly, as in the other systems installed.

Dimkr: Any future release intentions as overlayfs instead of aufs?

[dimkr]

Links are broken. Hunting on github for the most current 64-bit leads to https://github.com/vanilla-dpup/releases/releases/. None of the downloads provides a operating system deployable as a frugal from a hard-drive.

Have you tried preview18?

(And this is a preview, not a final release, don't expect the links to work forever)

Dimkr: Any future release intentions as overlayfs instead of aufs?

Yes, I want to get rid of aufs. It breaks often and it's buggy.