Mentioned here_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

No, for two reasons:
- Bad performance of FUSE
- Booting Linux from NTFS is a bad idea

However, you can add the ntfs-3g package if you really need good NTFS support. At the moment, Subito is able to boot from ext2, ext3, ext4, xfs and btrfs; I have tested it only against ext4, though.

nooby wrote:

And can the OS Subito or others created by your program boot frugally?

Yeah, any distro built using roar-ng can boot in two modes - either "live" or "frugal", in Puppy terms. Support for "full" installation is not provided because it makes the boot process much more complex and introduces many questions.

nooby wrote:

Isolinux or grub4dos or grub2? or all of them?

Subito comes with syslinux, but you can add any boot loader you wish. Boot loader support has nothing to do with the distro itself._________________My homepageMy GitHub profile

Filesystem in Userspace (FUSE) is a loadable kernel module for Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a "bridge" to the actual kernel interfaces.
...

FUSE is particularly useful for writing virtual file systems. Unlike traditional file systems that essentially save data to and retrieve data from disk, virtual filesystems do not actually store data themselves. They act as a view or translation of an existing file system or storage device.

_________________I use Google Search on Puppy Forum
not an ideal solution though

I just happened to think about my problems trying to create an ISO using roaring.
I had devx and the kernel source SFS files loaded for the version of Puppy (Lupu 520) I was running.
So in making the ISO, do I have to load the kernel SFS for the version I am trying to make?
I have tried twice now to make an ISO by just using the script files in order and both times ended up with an 8 meg ISO.
That is along with the compile packages script stopping with errors on Perl and the previous file another was having problems with.
I am evidently missing some step in that I do not think the file system is getting created successfully.

From now and on, everything related new to Puppy is considered deprecated
and unsupported; time to move on, to better package management, modern
package formats and cleaner code.

The main reason Puppy support is dropped is its non-standard nature.
For example, PET packages already ship in a split form, while roar-ng
performs automatic splitting. All the Puppy-specific code is now removed,
which means roar-ng lost many LOC.

So if you use Puppy Lupu maybe that fails due to puppy being so structurally. different Sorry poor grammar.

Edit Correction I was wrong Iguleder explains

Quote:

Nope; this changes apply to the next version of roar-ng only.

_________________I use Google Search on Puppy Forum
not an ideal solution thoughLast edited by nooby on Sat 11 Feb 2012, 07:40; edited 1 time in total

So if you use Puppy Lupu maybe that fails due to puppy being so structurally. different Sorry poor grammar.

Nope; this changes apply to the next version of roar-ng only.

8-bit wrote:

So in making the ISO, do I have to load the kernel SFS for the version I am trying to make?

No, just the devx.

8-bit wrote:

That is along with the compile packages script stopping with errors on Perl and the previous file another was having problems with.

roar-ng does not compile packages

zomzilla wrote:

my only question would be where could i find info on changing the compatable distro? i would love an arch based puppy or maybe one with funtoo's portage

It's works like Woof - edit DISTRO_SPECS. But you'll also have to implement support for that distro in the same way I did for Slackware.

Bear in mind that the next version will be much more flexible in this area - it will be much simpler to provide this support.

EDIT: fresh development news!

I have merged Builder (my automated package building infrastructure) into roar-ng as a fourth script, 4buildpackage. This script runs after 3builddistro (which produces a working distro) and builds a package automatically (from build scripts contained in the devx skeleton), inside this distro, using chroot. This allows easier porting - now it's possible to build a "barebones" distro, then use 4buildpackage to build all applications for it (inside it, automatically) and rebuild it, this time with the new packages, to achieve the final result.

So far it works really well and it's much faster than the previous incranation. This also joins the major improvements I implemented in roar-ng in the past week._________________My homepageMy GitHub profile

Here's a development snapshot, partially tested, for the curious and passionate developers

It has many fundamental changes; examine the "conf" directory before you attempt to use it.

I'm currently running 4buildpackage on all the packages included in the previous version's package list, to test it. At the moment, it will fail to download stuff from the Subito packages repository, since it doesn't exist. I'll upload all packages once I'm done building them.

I'm currently working on my own distribution, Subito GNU/Linux, which is a strong competitor to Puppy Linux meant to unify its qualities with those SLAX had and put heaps of the Arch Linux and Slackware KISS goodness on top. The idea is to be the first distribution that appeals to advanced users those appreciate the speed and size of "live" distributions but also like the simplicity of Arch.

Here's an assorted list of random rants and complaints about Puppy Linux and its infrastructure, most notably Woof:

1 Puppy Linux's code (especially the code that originates in Woof) is of poor quality; the only solution to this problem is a complete rewrite.
You're mostly correct, here ...
2 Woof is extremely hard to develop for, because it contains thousands of commented-out lines of legacy code and lacks proper documentation. Any part of a distribution-building infrastructure should consists of 100%, purely good code, otherwise its output will inherit its horrible quality.
Agreed.
3 Puppy Linux has a hard dependency on many ancient, deprecated packages (such as nenscript or installwatch) that cannot be built with today's compilers. A good example for this is gtkdialog: nobody's going to port it to GTK+ 3. Puppy was not designed with the possibility of future porting or "sister" distributions in mind: it cannot be ported to another architecture easily, period.
Yes, those hard dependencies on ancient, deprecated packages _should_ be weeded out. Be a bit careful with what could be compiled in a certain environment, or another, though. Gtkdialog -> gtk+ 3, don't know, but, who knows ...
4 According to Barry, Woof 2's blessing to the world was architecture-independence, but this is a lie! The reason its first generation lacked this feature is the fact It uses a chroot call to perform certain operations, but the new version just saves the target architecture and the one it was built on in a file and performs these final operations at boot time, contributing to Puppy's horrible boot speed. This isn't the right way to implement portability.
Cannot comment, am an all x86 bloke ...
5 Woof is slow; it performs all string operations using pipes, downloads files one-by-one from a single mirror and does the big no-no of shell scripting, which is recursion (e.g endless chains of fork() and exec()).
Agreed, woof is slow. However, roar-ng's speed could be improved upon, though it's signicantly faster than woof(2) ...
6 Puppy Linux boots slowly, because it has to search all partitions for its files and dynamically loads specific drivers to determine each partition's type. Also, its kernel package is split between the initramfs (the initial file system used to locate the main one) and the main file system itself, which causes mess and makes Woof less generic.
As you'd know, woof-built puppies searches all partitions, unless a partition is specified at boot-time. Splitting of kernel package between initramfs and the main file system causes _mess_ in what way?
7 With every change to Woof, Puppy Linux becomes more and more ignorant of standards. Although the usefulness of some is debatable, compliance makes development easier, since everybody else follows them.
? - /opt/* ???
8 Altough newer versions of Puppy Linux ship with a more exotic choice of window managers, much of its infrastructure still relies on the traditional JWM and ROX-Filer, which are non-standard in many ways. Woof's desktop integration of the two and the partial support for standards are implemented in dirty ways and make it hard to use Puppy as a development platform.
Yes? And how is cwm more standard?
9 The PET package format used by Puppy's packages is quite messy and hard to work with. Moreover, it uses the traditional gzip compression, which provides a low compression rate in today's standards.
Lower compression rate than xz, agreed. Messy? What's so messy with a bog-standard gz-package with a tucked-on md5sum, including a package-specs-file?
10 Puppy Linux's organizational structure is bad for continuity. Its development team consists of a small group of dedicated volunteers and Barry Kauler, who holds all intellectual property and takes care of all big decisions. Because of this, many fans develop their own, low-quality derivatives that lack creativity or special features, which frustrate novice users because of limited support.
The ease of re-mastering a puppy, or of woofing up your own (in spite of above stated awkwardness of woof(2)) has been a long-time development-choice of BK, as I gather. How roar-ng will ease the frustration of novice users is, yet, still yo be seen ...
11 Old (7.3 and below) versions of the X.Org X server had very limited support for automatic hardware detection (provided by the deprecated HAL daemon) and required a configuration file. Many tools were developed to accomplish this, most notably SaX2 and Puppy's xorgwizard. However, newer versions rely on udev, which is indeed reliable and therefore, hardware detection is good; these tools are no longer needed, but Woof still contains xorgwizard, to provide compatibility with those old versions (most notably, version 7.3, as found in Puppy Linux 4.3.1 and Wary Puppy). The hardware support of Woof-built distributions with later versions is much worse and they suffer from a longer boot sequence, for no reason.
Automatic hardware detection is not always that good ...
12 A distribution built using Woof is limited to the use of packages from Puppy Linux and packages from an optional, other distribution.
As it stands, as of 2012-02-11, using roar-ng is limited to another distribution, with the optional add-mixture of a _certain x86_64 sample distro_ .....
And, for legacy 32-bit:ers ???
13 It is extremely hard to add support for new distributions in Woof, because support for existing ones is provided as conditions in existing scripts.
Yes, agreed. But, on the other hand, how easy is it to add local packages and local package-lists to roar-ng-002, like a roar-ng tester just queried?

To conclude - I think it's time for someone to fork Puppy Linux and compete with it, head-to-head. It's a good product which deserves a better future and more care. The only way to provide this is a revolution and not the ugly evolution, which made me write this.

Innovation, professionalism and rebelliousness: this is my motto. And yours?

There is no doubt, at all, that you're extremely innovative, cunning, canny, and .... But, rebelliousness can, sometimes mistakenly, be interpreted as youngish cockiness, and vice versa ....

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum