“If you build it, they will come.” Paraphrasing, Ray Liotta as Shoeless Joe Jackson, Field of Dreams.

A little more than two years ago, Barry K announced an ingenious vision: Woof -- a “magic script” whereby Puppy Linux could, by using the applications developed in ANY other Linux distributions and maintained on their repositories, avoid both the energy-wasteful processes of personally having to reinvent wheels each time there was an improved kernel, and the resource wasteful process of maintaining the webspace needed to publicly provide the source files of “our” special variants of wheels. Since then, he --with the help of others-- has taken great strides toward bringing his vision to fruition.

Ubuntu advertises that “The Ubuntu repositories contain thousands of packages, and with 3rd party repositories you can get even more.” debian binaries were, primarily, the source of those packages. Arch Linux “provides many thousands of binary packages within its official repositories whereas Slackware official repositories are more modest.” So when I first learned of woof, I had two immediate thoughts: “beyond my skill set”, and “Wow! Access to the tens of thousand of packages advertised by other distros.”
I have since learned that the relationship between a “package” and an “application” is about the same as that of a muffler to an automobile: not particularly useful on its own. And some packages are less: just a specialized screw holding the muffler in place. The reality is that there are comparatively few applications, and little reason that there be very many more. A Puppy comes stocked with a species of application for eachgenus of applications you actually will use on a daily basis, and these are the same applications you’ll find in every other distro. Applications beyond those found in the ‘stock Puppy’ fall into three categories: variations, specialized programs, and variations of specialized programs. For example, Puppy’s stock wordprocessor is Abiword. An available variant wordprocessor is LibreOffice. There are many occasions when all you need is a simple text editor like geany. There are other times when Abiword’s formating capabilities come in handy for drafting short documents. And there are others, still, where the more robust capability of LibreOffice to handle large documents, emulate MSWord’s format, or utilize templates, may be required. But just how many species of the genus wordprocessor does one need? Falling under theorder “specialized applications” are video editors. The ‘stock Puppy’ does not necessarily include one. Among such specialized applications is the supposedly ‘simple’ OpenShot Video Editor. And a more complete --but intellectually challenging-- variant would be Cinelera. How many video editors does one need?
Puppy, by now, has it own version of almost any application you can name. But more importantly, you will be hard pressed to find in any distro a genus of applications not also found in every other distro.
Since in theory any distro can be woofed, three inter-related questions arise: (1) Is there a detriment to woofing too many distros; (2) Does it make any practical difference which distro we woof; and (3) Is there any distro whose woofing might be the most beneficial?
Your answers to these question are invited, especially if you have experience with woof, and the distro you recommend or disapprove. But as I see it, resolution of these questions is intimately bound up with two issues: (1) What role does Puppy play in the Linux community? and (2) what are Puppy’s strengths and weaknesses?
I discovered Linux about five years ago. I was looking for an alternative to running XP on an IBM Thinkpad 600e: Pentium II, 190 Megs of Ram. I wanted an operating system which wouldn’t so hog its limited resources that the running of actual applications became painful. As I was unwilling to euthanize its current OS before I was certain of being able to replace it with something better, in my search I included the condition that the OS had to be able to run from a LiveCD. And I wanted something which I could just boot-up and put to use: no opening the black box and jiggling the wires required. Early on in my search I discovered such useful google terms as “lightweight" “recommended for old computers." Soon, that search revealed Puppy, whose mission statement was:

1. Puppy will easily install to USB, Zip or hard drive media
2. Booting from CD, Puppy will load totally into RAM so that the CD drive is then free for other purposes
3. Puppy will be extremely friendly for Linux newbies
4. Puppy will boot up and run extraordinarily fast
5. Puppy will have all the applications needed for daily use
6. Puppy will just work, no hassles
7. Puppy will breathe new life into old PCs

But before I found Puppy, I also found --and rejected-- Archlinux. ‘Though it met the requirements of “lightweight” and “recommended for old computers,” -see, however, footnote-- it could not, at that time, be run from a LiveCD. And it was definitely not Newby Friendly. Even learning the jargon necessary to get it to run at all involves --for a Linux newby-- a considerable learning curve.

As originally envisioned, woofing Archlinux was specifically mentioned. Today, among the Puppy variants is our official release, Lucid Puppy 5.2, approximately 65% of whose build is from Ubuntu binaries. We have Wary, built from T2 binaries. We have people working on perfecting sPup, built primarily from Slackware binaries. And we’ve had several version of dPup, built from debian, at least one of which, gposil’s, almost progressed beyond beta. What ain’t we got? Besides dames, a woofed Archlinux.
Maybe Arch presents technical difficulties rendering it incompatible with Puppy? A “well-minded” search of the Forum reveals that we have several devs familiar with Arch, that scripts from Arch have been used on occasion, and one or two Forum members who mentioned they were attempting to woof Arch. But there is no active ‘Woof Arch’ thread , and the one previous thread suggesting it died from lack of enthusiasm.
Let me be clear. I am not a dev. “A man must know his limitations.” Dirty Harry Callahan. But I am no longer so much of a newby as to be intimidated by Linux’s jargon. Having acquired a 64-bit computer and wanting to get the most of it, I rediscovered Archlinux. Yes, there’s a fully functional 64-bit version. I’ve downloaded Archlinux’s latest snapshot ISO, read its guides and researched other information providing an overview, have a grasp of its strengths and weaknesses, and I’ve resized a hard-drive partition in preparation for its installation. But that’s as far as I’ve gotten. I am not the person to build a woofed Archlinux. Perhaps, however, I am the right person to drum up support that it be built. My research regarding Archlinux’s strengths and weaknesses suggested that it may be the best distribution for woofing: its strengths are our weaknesses, and vice-versa.
Commensalism is a relationship between two organisms where one organism benefits but the other is neither harmed, nor benefits. Mutualism is a relationship between organisms in which both organisms benefit. Puppy’s relationship to Slackware, debian and Ubuntu is commensal. But a woofed Archlinux would be mutually beneficial.
Our strengths: Puppys pretty much accomplish the goals laid out in the Mission Statement. Archlinux’s weaknesses are (1) it is not newby friendly and hassle-free; (2) An Archlinux LiveUSB requires at least 3 gigs, and creating one is far more technically complex then a Puppy LiveUSB. While, by this time, an Archlinux LiveCD can be built using either Archios or larch --and the latter seems to be similar in conception to a Puppy LiveCD’s-- using either system is far more technically challenging than building a Puppy LiveCD.
Our Weaknesses: We have too much of a good thing. There is no such thing as the “Puppy Distribution.” There’s Ttuuxxx’s 2.14x Updated, the 3.0 Series, the 4.12 Puppy and Pupplets, the 4.20 Puppy and Pupplets, the 4.31 Puppy and Pupplets, Puppeee and Fluppy, and sPups, and dPups and Lucid Pups, derivatives of any and all of them, and more. The first Newby question is “Which will run on my computer?” To which a dozen answers will be given, that can be summed up with the statement “Well, burn a couple and see which runs best.” And the second Newby question, “How do I know if this unofficial app will it work on my system?” And the third “Why doesn’t the application I installed from XYZ distribution, upon which my Puppy was woofed, work?”
Puppy Package Manager is good as far as it goes in trying to bring order into a system which has ‘grown like Topsy.” But it is not perfect. Some apps in the Wary repository will run under sPup, or uPup; and some won’t. Some in our Lucid repository will run under sPup; vice-versa, and some won’t. And multiply that condition by every Puppy Version, every variant of that version using a different kernel, and then some. It may all depend upon what other apps you’ve installed, and the library versions they used.
Iguleder’s pdebthing and pslackthing brings an improvement. But these are useful in only two of our menagerie, and the fact that there is more than one app reveals that even they are only a partial solution.
It is in the area of Package Management that Archlinux excels. As it currently stands --without any modifications we might make to conform it to our goals--
Arch installs a base Linux system, and then the user can configures it and expand it depending on his needs.
Central to Archlinux is the Pacman software manager. It is capable of resolving dependencies and automatically downloading and installing all necessary packages. In theory, a user need only run a single command to completely update the system. Pacman combines a simple binary package format with an easy-to-use build system. The Arch Build System (ABS) provides a way to easily build new packages, modify the configuration of stock packages, and share these packages. This makes it possible to easily manage packages, whether they be from the official Arch repositories or the user's own builds. Pacman keeps the system up to date by synchronizing package lists with the master server. This server/client model also allows users to download/install packages with a simple command, complete with all required dependencies. Pacman uses compressed tar archives for all of the packages, each of which contains compiled binaries. Packages are downloaded via FTP; it can also use HTTP and local files, depending on how each repository is set up. It complements the Arch Linux Build System (ABS) used to create packages from source.
Although Pacman, itself, employs the command-line, frontend GUIs are available using QT, Java, PyGtk2, and less importantly, Gnome and KDE. A cursory review of Archlinux reveals its heavy reliance on use of the command line. Here our devs experience in developing lightweight GUI’s could produce a system more inviting to newbies and casual users.
Like Puppy --and unlike Ubuntu-- Archlinux is designed to be simple and lightweight. Its repositories contain, as far as I can see, most, if not all, of the applications found in debian or Ubuntu. Unlike Puppy, Ubuntu, debian, and Slackware, Archlinux is a rolling distribution: That means that rather than having to install a new version, and reinstall applications, whenever a new kernel or new applications become available, you can upgrade your existing system to employ those innovations. After your first Arch installation a simple "pacman -Syu" command will always keep you up to date. We, of course, could find a way for Newbies to do it by clicking a button.
Unlike Slackware, Archlinux is “bleeding edge.” Unlike Ubuntu and its derivatives, Archlinux packages are not “bloated” by the need to run under any possible system configuration. Rather, as I understand it, the Arch build system only installs those libraries, drivers and modules, required by your architecture and desired by you. The user decides what will be installed and executed and every component of the OS is transparent, accessible and replaceable. That philosophy, and the way it is implemented, is similar to that of Slackware and may appeal to those of our devs who are Slackware-fans.
Our second weakness is that, although we have an active forum with numerous members, only a handful of them are technically savvy. When those go off in different directions, less is actually accomplished, and that which is accomplished takes longer. Our devs, however, are volunteers motivated by the joy of solving puzzles and sharing their time and talent with others. So, if “shot-gun approach” were the only objection, the response “the joy is in the journey” would win out.
The Pacman Software Manager was designed so that it could be installed on another Linux distribution, and then using it from that distribution, build a “Archlinux” system. I downloaded it, and all its dependencies, and created a NON-FUNCTIONAL SFS, that is it didn’t run under Puppy Lucid. But, that’s me and I rarely know what I’m doing in the absence of detailed instructions. Getting Pacman to play nice in Puppy may, however, be a puzzle our devs would enjoy solving. And obtaining a viable Arch Linux Build System under Puppy may also pose more than a simple challenge. [Shinobar’s ingenious solution in the dpup-482 thread to the obstacle that Synaptic ordinarily requires a “Full Install" provides hope that there will be a solution to problems]. In solving those challenges we may, however, find allies in the active Archlinux Forum, with its many technically savvy members.
Consider for a moment the following goal: a newby friendly operating system, which can easily be installed and run from a USB or CD, employing Puppy’s modular approach --one lightweight app of each genus necessary for common daily usage --to which other SFS apps can be loaded as needed, and employing Archlinux’s techniques so that after the initial boot-up your operating system can be easily reconfigured, upgraded, maintained and expanded to the maximum potential of your hardware and your personal objectives.
It is a goal, I would suggest, to which the journey would be joyous, or at the very least, instructive.

(Footnote: In its present configuration, Archlinux can not be installed on systems less powerful than i686 based machines: that is pentium pros and pentium IIs, i.e. computers manufactured more than 13 years ago. But then, can Puppy Lucid run on even older hardware?)

I did download the archiso-live-2011-01-04.iso and tried to make a frugal install but it could not see a file it needed. But it did boot a long way into the script.

I am lazy so I gave up after a few hours of fruitless attempt to find a working menu.lst code to it to boot on NTFS. Maybe it need an USB to boot but I was too lazy for that one too.
If somebody made an easy description on how to make a frugal install of archiso-live distro then many Puppyites got used to see it as a good thing to have a woofed Arch to use? _________________I use Google Search on Puppy Forum
not an ideal solution though

He himself was unlucky to get his computer fried and was sent a used one and that one had not enough memory so he use Slitaz on that one instead while he wait for his big Desktop to be available in a local shop or sent after from a webshop.

And thanks, cinclus_cinclus for suggestions on creating persistent storage.

You've encouraged me to think about tackling a live-Arch from the other direction. Unfortunately, right now I'm having problems with my CD burner, and none of my Puppies would mount the ISO. I'll have to open the box and see if I can sort out the burner problem.

If I understood it right, godane built ariso-live using techniques similar to those used to build Puppy, including squash files. That suggests that it may be able, or modifiable, to use Puppy's technique of loading and unloading applications in SFS format "on the fly". Some one who know what they're doing can probably mount it, and see how it was constructed.
But from two comments on his blog --some people with nVidia cards being unable to boot [I know, nooby, that you didn't have that problem]-- I wonder if in building a Live-Arch, some of Arch's hardware recognition capability was lost. Which raises two other questions: Whether godane's techiques also sacrificed the two aspects of Arch by which Puppy could benefit:
(1) routines for keeping track of what you've already put on your entire system, so that only necessary "parts" are installed or upgraded as need be; and
(2) the capability of upgrading apps and even the kernel from an active system.
Or, in other words, Pacman and the Arch Build System.

mikesLrLast edited by mikeslr on Sat 29 Jan 2011, 14:53; edited 1 time in total

(Footnote: In its present configuration, Archlinux can not be installed on systems less powerful than i686 based machines: that is pentium pros and pentium IIs, i.e. computers manufactured more than 13 years ago. But then, can Puppy Lucid run on even older hardware?)

Yes. Mostly Lucid 5.2 is compiled for i386 so it could run on older computers--but I agree-i686 is no big deal nowadays. Ubuntu did something clever I think--while the i386 libraries are default--it also provides the i686 libraries--Lucid 5.2 does *not* contain the i686 libraries by default for reasons of saving space but they are available in the Puppy Package Manager. Oddly, a few Lucid programs had a problem running on an AMD K6 cpu--but there is a K6-pack available in PPM also.

Anyway, I look forward to an ArchPup. One thing I have always liked about Arch is the "rolling release" model and I think that would make it easy for someone to very easily update an ArchPup. Best wishes.

Since in theory any distro can be woofed, three inter-related questions arise: (1) Is there a detriment to woofing too many distros; (2) Does it make any practical difference which distro we woof; and (3) Is there any distro whose woofing might be the most beneficial?
Your answers to these question are invited, especially if you have experience with woof, and the distro you recommend or disapprove. But as I see it, resolution of these questions is intimately bound up with two issues: (1) What role does Puppy play in the Linux community? and (2) what are Puppy’s strengths and weaknesses?

There's is no real detriment to having more puplets. The distro chosen does select which devs will be interested in it. Selecting one that will draw new developers into the Puppy community would be a plus. I think the arch community would be a good place to poach from.

Although, I personally don't think Puppy's architecture is that good of a match for other distro's packages. I mean why dedicate the months of effort to make Puppy elegant, simple, and small if the same effort is not applied to the packages. It's like putting a roof rack on a Miata.

In the main, I agree with Jemimah that other distros' packages may not be the best fit for Puppy's architecture. The ability to use them, or some of them, is a plus, but does not play to Puppy's strength. That, as I see it, is a small, lightweight OS, that can run as a frugal install from (more or less) any medium, providing a full set of packages needed for 'everyday' use, but expandable 'on the fly' via squash files. What I'd like to see for Puppy --perhaps as a squash file-- is something like Archlinux's Pacman and Arch Build System, enabling (a) upgrading of apps and systems 'on the fly' and (b) semi-automatic compiling of new apps from source using the AUR repository. [Being able to use apps in Archlinux's repositories would be a plus, but not essential].
Playdaz, I wish I had the skill set, or years to learn them, but as I've mentioned I'm not the guy to build an Arch-Puppy. At 68, building new mental synapses required to analyze technical problems from within their discipline is an up-hill battle. My strength is that I've spent 48 of those years looking beyond the immediate problem at the "whole picture" in many disciplines. And I was inspired long ago by Bobby Kennedy: "I look at things which have never been, and ask 'Why not.'"

Which is why I suggested that someone who knows what they're doing should look at how godane developed a LiveArch ISO, and whether he had to sacrifice Pacman and Arch Build in the process. And perhaps they might also look at larch and Archiso..

mikesLr

P.S. For those still interested in Archlinux. I burned godane's iso to a CD on a different computer --my wife's XP box. I was then able to mount the CD and examine the files, but only after installing a pet which handles xz compression. Although I was in Lupu, I used the one gposil posted for dpup as it was handy. I was also able to copy Archiso-live's folders to a new partition. But it didn't boot, reporting about a file-system mismatch. I'll explore more later. Just wanted to note that xz was the format godane used. I don't know how that would complicate things.
One other thing I discovered is I'm not certain how much assistance can be had on the Archlinux forum. Unless I missed something, all versions of frugal install were developed by godane.
I'm in the process of installing Archlinux 64-bit on my "main" computer: the one I rarely get to use. But that's, in part, a way to build some mental synapses: doing is more effective than just reading.

Amigo's src2pkg project should allow semi-automatic compiling and packaging from any type of source package.

The problem is that a lot of things just don't compile unmodified. I guess with build systems like arch or gentoo, a developer makes the necessary changes to the source code for you. Deciding what build flags to use, what dependencies are truly necessary, which libraries should be static and which dynamic, and what cruft can be removed is also a highly creative process - not easy to automate,

Which, with Puppy, leaves you in the exact same boat. If a developer is needed to mangle the souce before it gets to the user, that developer may just as well create a binary package.

Upgrading the base, on the fly, is also tremendously complicated, especially with Puppy as a lot of the applications are interconnected. And a remaster is needed to reclaim the space freed be removing old apps. This is another thing that the Puppy architecture is particularly unsuited for.

The main obstacle that keeps Puppy from having its own fully stocked repo is simply a shortage of package maintainers. Add to this the fragmentation of puplets, which is sort of inevitable, even without woof, because Puppy trades flexiblity for small size and ease of use - so nearly everyone with the requisite skill is going to want to create their own custom version.

We could try to fix this problem by creating a Puppy build kit along the lines of Puppy Unleashed - much less flexible than woof with a much shallower learning curve and having a legitimate community repository. Then at least we'd all be using the same sources. You'd still need a veritable army of developers to keep up with the churn of new application versions.

Thanks Jemimah for mentioning src2pkg. As you said not everything can be automated -at least not from the start. all major distros have some system or method ofr automating building or rebuilding packages. But each distro does things differently than others in one way or another. Hence there is always a need for distro-specific modfications to some or many packages. Each distro has maintainers for each package and every distro uses some sort of 'recipe' for each package. Once a recipe is created, the package can be built automatically as long as no more changes are needed.

One of the biggest things that Puppy is missing is just such a system where each package has a recipe for building it. That precludes any sort of automation or repeatability of builds and means that any port of puppy to anbother mavhine architecture would be as excruciating as the original build. In contrast, debian or fedora use the samme recipes for any architecture -the recipes are created with this in mind, so that if a ceratin arch needs a certain patch not needed by other arches it gets applied automatically when building for that arch.

src2pkg provides for the same compatibility and somewhat like gentoo, it lets you download, compile, package and install in one fell swoop. What src2pkg provides that *no other system has*, is the ability to create *some* packages without any human intervention. It can actually draw from any human intervention which ahs gone before -by using configuration and compilation options created/proofed by debain or rpm maintainers. The real beauty of src2pkg is that it provides this very easy usage for people who know nothing about packaging, while also allowing for advanced packaging using tweaked recipes.

Sometimes it involves a lot of work to produce a perfect package using a customized recipe, but having that recipe then makes it a snapp to update the package to a new version or build the same sources on another architecture. And the recipes are much more concise than many paragraphs of prose on someone's blog or forum.

My view is that puppy should use *no* packages from other distros. Mixing and matching packages from other distros is simply crazy. The less puppy has in common with other distros, the more this is true. Probably around half of the stuff used to make puppy are not available in the repos of other distros -I mean on other distro includes all of what puppy uses. So, building puppy will always involve compiling and creating some packages which are not available elsewhere or that need puppy-specific modifications. If there was a way of automating the production of packages -once the recipe is established, rebuilding the packages would be very easy for the purpose of upgrading the package version or rebuilding for a new distro version or machine architecture.

To me, even using basic packages from another distro is insane. Doing so means you are always chasing some other dogs tail - trying to implement version upgrades according to soemeone elses schedule and priorities. the big guys have hundreds of developers and maintainers -debian has way over 1000 package maintainers! A small team can never hope to keep up with such a project. It sounds tempting to directly piggy-back on their work by using their packages directly. But, a small team would always be overwhelmed just trying to work out which upstream changes should be applied here, which should be ignored and which need tweaking.

Trying to have a ppup, spup, dpup, upup, apup simply means that the few developers and contribs who are talented enough to do *anything* significant are always gonna be spread out over many sub-projects -and this leaves little time and talent for developing and implementing *core concepts* which are essential to the identity and feel of your project.

To me, one of the biggest disadvantages of nearly all LiveCD distros is that they encourage forking or the production of derivatives. This hard to avoid because the main release inevitably contains a mix of software which is not suitable to everyone. The first and main argument is always over which browser to include. And then on and on. So, people whose preferences are different start producing derivative releases with different choices of software. What a waste of talent. Why not, instead, work on finding a way to make the distro more flexible or customizable. There are a few projects which provide a web-interface so that a user can have a cutom iso created for them which includes the software they want. Such a thing would be great for puppy and could stop a lot of waste of talent.

Having a package-based build system which is consistent and well thought out would make it possible to create all sorts of variants -for other arches as well. It would make puppy 'legitimate' in the eyes of other Linux developers and allow for incorporating the efforts of more contributors (or detractors with their derivatives) into the mainstream effort. I don't really mean to be derogatory about authors of variants being detractors. The point is that there is no good mechanism for consistently incorporating their efforts into the main production for the good of all users and devs.

Thanks for all these insights in the many considerations for to get things to work.

My participation in this is more like a clumsy user that stumble on a used Car that is very different from all the cars one are used to with autmatic gears and anti spin of wheels and you almost are like sitting in Cockpit of an airplane needing to check that all the instrument show it is ready for take off. then you even need the clearence of the -Tower people and the Weather report too.

I failed booting Minino the other day. I spent some 6 hours on it.

I failed to boot Slitaz many times this month and spends many hours on it and I failed to boot Swift too and then suddenly found a suggestion on how to do an iso boot on the HDD and that one worked but then you have this unexperienced driver syndrome.

the machine booted the OS but the user has no practice in setting up the controls so I failed to listen to my video clips due to the HDD forbidden to mount something. Totally beyond my comprehension how one tell it to be allowed.

So it is Puppy for me until the other Linuxes get more user friendly.

But I have Archiso and it almost do anything but it fails to change the menu.lst due to only read permissions despite I logged in as root user.

I am downloading ArchBang iso to see if that one behave as Arciso version.

When Archiso dev got his computer fried by the power supply activing up then his new computer sent to him as a donation had too small resources to work with Archiso so he used Slitaz instead.

Maybe the laptop only had 256MB memory? So such considerations are important too.

the devs of Lupu 5.2 wrote that they skipped many SW due to the requirment to be able to run in RAM on a 256MB machine.

So is not the best approch to make a puppy that is as small as possible and then have all programs on the hardware as clickable programs and each user decide how big machine he need?

A kind of IronCore version of Puppy but working as good as Lupu in the set up. Or based on Fluppy so it works on my Acer D250 too._________________I use Google Search on Puppy Forum
not an ideal solution though

And thanks, cinclus_cinclus for suggestions on creating persistent storage.

I tried Godane's Archiso 20100825

mikeslr wrote:

If I understood it right, godane built ariso-live using techniques similar to those used to build Puppy, including squash files.

He uses modified LinuxLiveScript (LLS)

mikeslr wrote:

That suggests that it may be able, or modifiable, to use Puppy's technique of loading and unloading applications in SFS format "on the fly".

you simply use arch2lzm and put the generated LZM-modules - up to 127 - into one of the module-folders of your USB-live-stick as for instance 'optional'.

mikeslr wrote:

But from two comments on his blog --some people with nVidia cards being unable to boot [I know, nooby, that you didn't have that problem]-- I wonder if in building a Live-Arch, some of Arch's hardware recognition capability was lost.

I am on a PC with Intel G45-Chipset mainboard (Intel-chipset graphics) and on a netbook (Intel Atom based).

mikeslr wrote:

Which raises two other questions: Whether godane's techiques also sacrificed the two aspects of Arch by which Puppy could benefit:
(1) routines for keeping track of what you've already put on your entire system, so that only necessary "parts" are installed or upgraded as need be; and

thanks nooby. i had the same issues and failures as you with the previous arches. now i have downloaded the arch in your link and clicked it open in puppeee4.4-08, copied the iso contents to a folder, and booted with

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