Just noticed a recently added 900 directory in the FatDog source repository:
Will there be a new release in the next time?
Thanks for your feedback!
Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators
Just noticed a recently added 900 directory in the FatDog source repository:
Will there be a new release in the next time?
Thanks for your feedback!
Neo_78 wrote: Wed Apr 05, 2023 9:13 pmJust noticed a recently added 900 directory in the FatDog source repository:
Index of /fatdog/source/
Will there be a new release in the next time?
Thanks for your feedback!
Greetings, Neo_78!
As a longtime FatDog user, I can say that it has always been worth the wait.
While the developers work, we wait! In time, good things will come.....
I rather like twm. Especially the 'kill' window mechanism...
In fact I was running exactly that a couple of weeks ago albeit as a very small alpine linux running Xvnc in a container with twm as the window manager (accessing the alpine linux from host via vncviewer) - size of alpine arrangement about 35MB uncompressed as far as I remember - I'll find out, I'm repeating the same again in the next few days. Good thing about twm is none of that taskbar fancy conky or whatever and so on, which simply use CPU/RAM and act as a constant distraction. Instead, twm, kust a simple window manager mechanism. Can still run the exact same apps - who needs more.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
Three days ago, I happened to find that there is a FatDog 900 ISO file, whose name is fatdog.iso, on https://distro.ibiblio.org/fatdog/broken/900tip/ . And I found that such ISO file is updated frequently. It seems that it is a "broken" version because "broken" is used in the pathname of the above-mentioned URL.
Yesterday I downloaded an ISO file with time stamp May 6, 2023 and burned it on a USB memory stick. Then I used that USB memory stick to boot my PC up. This version of FatDog 900 works quite well and it is not broken at all.
I took 2 screen shots as shown follows.
Have been testing for a couple of weeks. It definitely has some broken bits and is a fair way away from release, but definitely 900 is on the horizon.
@p310don @jamesbond It really is an excellent wallpaper design.
Looking forward to 900
i downloaded the ISO and made a frugal install on Windows NTFS partition.
I was pleased to see how far it has progressed
Recent KRITA and Blender 3.5 appimages worked.
CSR Bluetooth dongle could be connected, however when I clicked on a wav file only a couple of seconds would
play and then it would stutter and not play. Other Linux distros wouldn't connect this dongle at all.
I noticed that the HELP button in the 'SMB Browser' app doesn't mention how to set up a SAMBA server.
Fortunately I knew that I had to run 'Fatdog64 Folder sharing Manager'
My chromebook was able to spot the server easily.
My wacom tablet connected automatically and worked with GIMP
Lastly there appears to be strange incompatibility with Window partitions.
My menu.lst file seems to work at finding fatdog64 on a Windows partition
Code: Select all
## start section Fatdog64-900
title Fatdog64 900
find --set-root --ignore-floppies /fatdog900/vmlinuz
kernel /fatdog900/vmlinuz pfix=fsck psubdir=fatdog900
initrd /fatdog900/initrd
boot
However when I boot I just get a console i.e. fd64.sfs is not found.
From the error message I could see that fatdog64 couldn't locate fd64.sfs.
So I transferred it to a partition that is EXT4 formatted and it was found during booting.
________________________________________
Yes, I have experienced a change in how FATDOG boots as it affects past methods of booting without issues. Same symptoms as you show.
Past methods afforded booting FATDOG successfully in various manners including booting via its ISO files from ALL the known forum boot methods. With this current alpha, booting is no longer possible.
I am sure this will be corrected as FATDOG progresses toward GA from Alpha.
I noticed that the list of SFS files to load at boot time requires the save file to be created
first, otherwise the list of SFS files is forgotten.
_____________________________________________
don570 wrote: Fri May 19, 2023 9:41 pmI noticed that the list of SFS files to load at boot time requires the save file to be created
first, otherwise the list of SFS files is forgotten.
_____________________________________________
You can load SFS at boot time in two ways.
First, you can use the "extrasfs" parameter in the kernel command line. This doesn't get forgotten because it is written in the bootloader config file (grub.cfg, refind.cfg, etc).
Second, you can load sfs as usual and "keep it for the next boot". This does require a savefile, because the information is saved into the savefile (which is inside RAM if you never create a savefile before, and it's lost when it is rebooted). This is by design. Fatdog's philosophy is not to touch other partitions that doesn't belong to it, so it doesn't create config files / marking files elsewhere until a savefile is created.
Thank you for test and review, @don570.
don570 wrote: Mon May 15, 2023 10:29 pmHowever when I boot I just get a console i.e. fd64.sfs is not found.
From the error message I could see that fatdog64 couldn't locate fd64.sfs.
So I transferred it to a partition that is EXT4 formatted and it was found during booting.
Indeed.
In this leaked __internal test version__ (remember, 900 isn't released yet, not even as alpha ), we build the ISO with fd64.sfs located externally. The initrd would be able to find the fd64.sfs from the medium if it is located at the root partition, but from your grub stanza I can see that you probably put it under /fatdog900 folder.
To tell initrd where it is, you need to use the basesfs parameter, something like "basesfs=ram:device:sda2:/fatdog900/fd64.sfs" or something like that. If you are using SSD with NVME interface, then you need to also use the "coldplug" parameter.
In the release version, we will build Fatdog the usual way (with fd64.sfs inside initrd), but for the internal-test version, we would probably continue to do it this way as it is faster for us to do it (thus cutting down time needed to build and test a new test version).