Activism | Astrology | Astronomy | Blog | Credit Card Boycott | Firefox Add-Ons | GNU/Linux | How To Guides | Ideas | Languages | Music | Opinions | Pictures | Second Life | Self-Help | Software | Windows

About This Site | Contact Apollia | Disclaimer | Updates

Eryss.Com - Non24.Com

Eryss.Com Forum - Non24.Com Forum

Donations | Services (none available currently)

Request Free/Libre/Open Source Software or Documentation, or Ask Programming Questions (but only if you're very patient)

Or, Donate In Second Life

GitHub

Under the GNU General Public License v3.0.

Copyright (C) 2013 Apollia

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

Contact info: http://astroblahhh.com/contact-apollia.shtml

A copy of the license is included in the section titled GNU General Public License.

Why did I choose the GNU General Public License (GPL) rather than the GNU Free Documentation License (GFDL)?

Because the terms in the GFDL about invariant sections made me uneasy. I didn't want modified versions of this page possibly acquiring unremovable new sections. If people want to use or modify relatively small parts, I want them to be free to do so without having to also reproduce the entirety of all the invariant sections too.

I've only been using Linux, also known as GNU/Linux**, frequently since Feb. 2011, and I'm definitely still very far from being an expert on Puppy Linux**, Linux in general, or computers in general. I have some experience programming (mostly in PHP**), but still don't know as much as I'd like about that, or most anything else.

But, in the past couple years, I did manage to learn plenty of useful trivia related to Puppy Linux, which I picked up by necessity (or just for fun) as I attempted to make myself at home in Linux and figure out how to do things I needed (or wanted) to do.

And that effort succeeded quite well - I'm now happier and more at home with Puppy Linux than any other OS (operating system) I've used in my life so far, and it has been my primary OS since around March or April 2012. (Puppy was also what I usually used from Feb. 2011 to September 2011.)

My second favorite is Windows XP - which I actually still use quite frequently, though nowadays, I usually use Windows XP in a VirtualBox** inside Lucid Puppy Linux 5.2.8 version 004, except for things that don't work in VirtualBox, like Second Life** and various other games.

I actually still find Windows XP quite likeable - in my experience, it's very stable/uncrashy, user-friendly, and boots (starts up) pretty quick if you install it from scratch rather than just living with whatever bloatware might've been installed by whoever you bought your computer from. A pity Windows XP isn't free, libre, and open source. It's not as customizable as Puppy, nor as fast, and I don't like that Windows XP relies so much on a hard drive, but still, it has served me well and continues to do so.

But, back to the topic of Puppy. I actually devised a rather unusual way to set up Puppy Linux. I'm not sure anyone else currently does anything like what I do - but perhaps it will catch on someday, once I release my setup scripts.

They'll be here someday:

I've relied on Puppy (off and on) since around Feb. 2011. I was pushed to it by various computer problems which made me reluctant to keep running Windows XP all the time, for fear that Windows XP might be too rough on my old hard drive which had been making odd little noises.

Originally, until Feb. 2012, I mostly used a writable multisession live DVD** of Lucid Puppy 5.2, which I had customized with most of my favorite customizations by saving additional sessions to the disc. I soon realized that adding additional sessions was making Puppy slower to start up, so I decided that rather than saving minor settings changes to the disc, I ought to just write some Perl** scripts I could run whenever I wanted to update my settings.

That worked nicely, but that's as far as I took the setup script idea back then, since my customized multisession Puppy live DVD was working well enough for me, and so it wasn't really necessary yet for me to make it possible to quickly set up everything from scratch after booting my computer with an uncustomized Puppy.

My computer then was a 2.21 GHz dual core processor with only 1 GB of RAM. In my experience, that was a tolerable amount of RAM but not quite comfortable in Puppy, at least for me, since I couldn't have every program I might frequently want to use all installed at the same time.

In August 2011, I finally acquired a cheap computer (amazingly, only $15.00 - yes, fifteen dollars - from the local library) which I felt comfortable experimenting with. Something like 1.8 GHz, probably a single core processor, and definitely 512 MB RAM.

So, for less than a few weeks, I curiously experimented with full installations of Puppy and frugal installations with Pupsave files, to see if I was missing out on anything by running Puppy exclusively from a live DVD.

However, I soon realized that I trash my system with ruinous changes much too often to be able to run Puppy in a way that doesn't make it easy to undo the damage just by rebooting.

So, I definitely couldn't use a full installation (since that immediately saves changes to disk). I thought maybe I could live with a frugal installation if I could just find a way to make it not autosave at shutdown or any other time (just like a live CD or DVD) - but I couldn't figure out how to do that. So, I gave up on both those types of installations.

But one thing I did like about those kinds of installations was that they booted a lot faster than Puppy on a live DVD.

512 MB RAM was far too little for me to comfortably use Puppy exclusively in RAM on that computer. Of course, it worked - Puppy is known for being able to run with only a small amount of RAM - but I couldn't install as much of the software I was accustomed to.

So, since I could do a heck of a lot more on that underpowered computer with the far harder to break Windows XP, I used Windows XP almost exclusively on that computer. It was my main system from Sept. 2011 to Feb. 2012, since I was trying to avoid using my best computer for fear of hastening its possibly impending hard drive breakdown.

Several months later, in Feb. 2012, I acquired my current main computer - a 3.4 GHz dual core processor with originally 2 GB of RAM, which I later upgraded myself to 4 GB. My best computer in my life so far. (And astonishingly, this system was only $99, shipping included, from eBay**. Still not really comfortably affordable for me, but a really great price nonetheless. The 2 GB extra RAM I had to buy elsewhere was around $30, almost a third of the cost of the computer itself. Alas, this computer did develop hardware problems that started about 9 or 10 months after getting it. Still is my best system ever, though.)

It had no hard drive, which I preferred. (And I still prefer to never add an internal hard drive, because of the dreadful problems I've had with hard drives over the years.)

However, I think the lack of a hard drive confused Puppy because it surprisingly wouldn't boot with a live DVD alone. Can't remember the details exactly, but I think sticking in a USB Flash drive (possibly even without putting Puppy on the Flash drive yet) may have made it bootable with a live DVD.

In any case, since I believe I had to use a Flash drive no matter what I did, I guess I might've figured I might as well just install Puppy on the Flash drive, since it would be faster than booting with a DVD anyway.

So, I ended up using a frugal installation of Lucid Puppy Linux 5.2.8 version 004 on a Flash drive - but this time, I refused to create any Pupsave file, since the autosaving was a huge nuisance for me, and I didn't want to wear out my Flash drive.

However, I had no intention of using just a plain uncustomized Puppy all the time, so I had to think up a way to bring back my custom settings that didn't involve a Pupsave.

At some point, it occurred to me that I could probably extend my old idea of using Perl** scripts to add custom settings to my Puppy. I could make a whole lot of different little setup scripts to add in all of the programs and custom settings I need. And in the end, hopefully I'd be able to go from a totally uncustomized Puppy, to a Puppy extensively customized as I wished, in just minutes after startup.

Happily, I managed to accomplish that (I think as far back as March 2012), so now I'm totally independent of having to use a Pupsave file, or having to save sessions to a live CD or DVD. :-)

And I can make myself at home with various other Puppies quite quickly (as long they're similar enough to Lucid Puppy 5.2.8 version 004), because my setup scripts and the .pet files and other software I collected for Lucid Puppy 5.2 and 5.2.8 seem to mostly work fine in other Ubuntu Linux**-based Puppies.

All I need to do after starting up my computer with a plain uncustomized Lucid Puppy 5.2.8 version 004 is - open my Flash drive and click a single setup script, which starts numerous other little Perl scripts I wrote, which each do one or more important little tasks, like changing the time zone; making the extra keys on my keyboard work and configuring them to do useful things; installing a certain .pet file and custom settings that go with it; etc.

I even have different setup scripts to install very different arrays of programs and settings, depending on what I want to work on. Having different setup scripts is particularly useful on computers with an uncomfortably small amount of RAM, where you have to pick and choose between what programs you want installed because there's not enough RAM for all of them.

I still haven't released my setup scripts, since poverty, heartbreak, and more important projects got in the way - but, when I do, they'll be here:

I found 2 GB of RAM to be a pretty comfortable amount of RAM in Puppy (double what I had on my previous best computer), and 4 GB has been even better (quadruple!) and more than I typically need.

I don't know if my computer would even be able to accommodate more RAM than that, but if it could (and if I felt courageous enough to risk installing it), I'd have to switch to a 64-bit Puppy to use the extra RAM, because any 32-bit OS (operating system) can only use up to 4 GB of RAM.

But, I can already do what I want quite comfortably, so, no need to upgrade. As things are, Lucid Puppy Linux 5.2.8 version 004 gives me 1.6 GB of "personal storage space" in my RAM disk, and I guess it uses the rest of my RAM for its own purposes.

I usually don't completely do without any hard drive at all, but I love having that option.

I still refuse to install an internal hard drive, so, when I use a hard drive, I use a hard drive inside an external enclosure which connects to my computer via a USB cord. Sometimes I turn on some other hard drives in other enclosures so I can back up data, or look at files I don't have on my main hard drive, or run a second VirtualBox**.

(Though, it is possible to run more than one VirtualBox on the same hard drive. I just prefer not to, since I assume it's probably less work for each hard drive if you only run one VirtualBox per hard drive.

I suppose I might be able to run VirtualBox on a USB Flash drive if I had a large enough Flash drive and was perpetually wary of the possibility that it might wear out my Flash drive and become inaccessible someday - but I haven't tried it yet.)

If (or when) my main computer breaks down completely, it won't be as major a problem as it would have been in the past, because none of my data will be stuck in an internal hard drive. I can easily just plug my hard drive enclosures and Puppy setup Flash drive into some other computer, and carry on pretty much the same way as usual. (Though not as comfortably on any system with less RAM.)

VirtualBox**, which I learned about in Feb. 2012, made it incredibly easier for me to transition into running primarily Linux most of the time.

Running Windows XP in a VirtualBox virtual machine is amazingly like running real Windows, aside from the aforementioned inability to play many games (like Second Life**), some not-especially-bothersome differences I didn't note above, and some definitely bothersome differences I write about below - related more to Puppy or Linux than to VirtualBox, though.

In the not-so-bothersome department - things sometimes seem a bit slower and choppier. For example, Notepad++** in VirtualBox seems to load and scroll files slower than in real Windows XP. Notepad++ still works great overall, though - and I still haven't yet encountered the incredibly aggravating freeze crash that happened to me frequently when running Notepad++ in Wine**. Sometimes I start up VirtualBox just so I can use Notepad++, since I still don't know of any code editor for Linux that has the two simple but invaluable features I love - the word you're highlighting being highlighted everywhere, and bookmarks that enable you to skip around in the file just by pressing F2.

(But luckily, Puppy's usual default editor Geany** is actually great - it too has customizable colors, syntax coloring, and pop-ups that show you the names of PHP** functions and what arguments they need. Anyhow, both Notepad++ and Geany are open source, so, it's theoretically possible to make a Linux version of Notepad++ (though I wasn't able to figure out how to do it in 2011 or so), or to modify Geany, which is maybe the more plausibly achievable option for me.)

VirtualBox is generally much better and more reliable than using Wine** to run Windows software. Also, I feel much safer using VirtualBox than Wine, because I always worry that Wine might make my Linux system vulnerable to Windows viruses.

I can even watch Netflix** in a Windows XP VirtualBox, with quite decent, pretty smooth quality, even on my old 2.21 GHz dual core computer with only 1 GB of RAM!

The audio quality is one of the few things I miss from Windows XP that I haven't yet been able to duplicate in Linux. (Though I still haven't tried very hard yet, since I doubt I'd be able to figure it out anytime soon, and I have too many more pressing things in my life to deal with.)

I do find the default audio quality in Puppy quite listenable and enjoyable (which is fortunate, since I can't change it much outside of the DeaDBeeF music player).

But, my non-virtual machine Windows XP audio really just sounds better, and my SBLive sound card makes it easy (but only in Windows) to add effects like reverb. (Which is more important than you might think - "Reverb is like sugar in your cereal", someone aptly wrote on a website I used to frequent.)

The only equalizer I've been able to get to work in Puppy is the one in the DeaDBeeF music player. And, though I figured out how to play MIDIs in Puppy itself (not just VirtualBox), I mostly haven't been able to get MIDIs in Puppy or VirtualBox to sound as good.

In Puppy, some of my collection is listenable and even enjoyable (though different-sounding), but not all, and there are frequently missing notes and instruments. And in VirtualBox, the timing is a little off or slowed sometimes (for which reason I never went to the trouble to find some reverb software to substitute for not being able to use my SBLive sound card reverb).

But, at least MIDIs in Puppy or VirtualBox generally sound better to me than MIDIs on a Mac**. (To be precise, a MacBook from 2009.)

And, given that Puppy (and Linux) are free and open source, and thus it's possible to modify and improve them far more extensively than anything closed source (like Windows) - I do have hope that someday, it will be possible for me to have just as good or even superior audio quality in Puppy.

See the Wikipedia article on "Free, libre, open source software".

"Free, libre, open source software" is often abbreviated as "FLOSS", and "free, open source software" is often abbreviated as "FOSS". It's the opposite of closed source software.

"Free" refers more to freedom (as in liberty) than to price, though it's very common that such software is also free as in price. And if you think about it, things that are free in price actually contribute to freedom (as in liberty) too - since most people in the world (including me) are very oppressed by financial problems. See: Poverty Facts and Stats, from GlobalIssues.org.

Having free software can really help make poor people's lives better and give us a better chance to find a way out of poverty, and makes it so fewer poor people are faced with horrible choices such as either buying food, paying bills, or buying some incredibly expensive proprietary software in the hope of being able to use it to make a living.

(Actually, when I was younger, I went into debt to buy some expensive proprietary software which I thought I might be able to make money with, but, after buying it, I thought of some good reasons to change my mind about using it for that - so, buying it only worsened my financial situation, quite a lot.)

Things that are free in price make you free to spend your money on other things, such as things that would benefit you far more than closed source software. That's definitely an important and valuable freedom, but, there are actually even more important freedoms that free, libre, open source software provides. (More on that throughout this lengthy explanation.)

Many people are understandably confused by the word "free" in "free software", and assume it only refers to price - which is probably why someone came up with the term libre, which itself seems confusing at first encounter, and jargony.

So, maybe people who want to be really clear about what they mean by "free" or "libre" software should call it "freedom software"? :-) Or "open source software that gives you freedoms that closed source software nefariously deprives you of"? Or "software of liberty"? :-)

Those terms may sound humorous, like something a comic book superhero might use. :-) But, even so - at least they're clear(er) and perhaps better than using an ambiguous term like "free" and then being upset about it when people don't understand, and worse still, don't even know they don't understand.

At least "libre" doesn't have the double meaning in English that "free" has, so fewer people will assume it only means free as in price. But "freedom" or "liberty" are clearer right off the bat.

On the other hand - at least people searching the web for "free software" (as in price) will more easily stumble onto the Free Software Foundation website than they would if "free software" were usually called "freedom software". :-)

Anyhow, I guess I'll just go along with the crowd (for now) and usually keep calling it free, libre, open source software. If I called it "freedom software" or "software of liberty", people might laugh at me for talking like The Tick. :-)

By the way, the 2001 live-action version of The Tick is legally watchable at: http://www.crackle.com/c/thetick Crackle.com** is a legal, ad-supported streaming video website which is watchable in Puppy** and presumably other forms of Linux, even though Crackle's FAQ doesn't say so. According to Crackle, The Tick is rated PG. But be warned, there is swearing and other vulgarity. If your Puppy doesn't have Adobe Flash** (which is, unfortunately, closed source software) already installed, the simplest way to watch Crackle (or YouTube**) in Puppy is probably to just use either the Chrome** or Chromium** web browser, since they have Flash built in. Chrome and Chromium .pet files are available for many Puppies. There are apparently some free, libre, open source Flash players, but I haven't tried any out myself yet.

OK, back to the topic. :-)

With free, libre, open source software, the software's source code is available to you, and you have the opportunity to compile it yourself, and the freedom to modify it as you wish (or as you need to, such as if it doesn't do what you need yet, or if it's glitchy). You are also free to share the software and source code and any modifications you made, as well as free to give it away, and usually even free to charge for it.

A more thorough and official explanation of free software: What is free software? - GNU Project - Free Software Foundation (FSF)

Having source code is like having a cake recipe which you can modify at will to adjust to your tastes (or special needs, like if you're diabetic and can't consume sugar).

Meanwhile, having only compiled software executables with no source code is like having no recipe, and only a finished cake that you can't really do much of anything with besides eat it.

You can't magically uncook it and put its ingredients together in a new and improved way (except, with software, there is such a thing as decompilers, but reverse engineering violates many closed source software licenses). And without the recipe, you can't easily make a new or improved one nearly just like it from scratch. If you try, it will involve a whole lot of guesswork and will likely turn out much different.

If it's a yummy cake (and you're not diabetic), you might not mind being stuck with it. But if it's a nearly perfect cake with a few frustrating flaws, you might find the cake's imperfectability quite aggravating.

Or, it might be a yummy cake made with aspartame (an artificial sweetener with a bad reputation) - such a bad flaw that you have no (wise) choice but to give up entirely on eating the tantalizingly yummy but irreparable cake. Which is a pity, because if you had the recipe, you could make a perfectly edible one almost just like it, just with a healthier sweetener instead of aspartame.

It's very common in Windows** and on Macs** that you're not given source code for software - instead, usually only compiled executables. Windows and Macs are full of closed source software, and the Windows and MacOS operating systems (OSes) are themselves examples of closed source software - already-compiled, "already-cooked cakes" that you can't fundamentally modify or improve yourself, or at least it's nowhere near as easy as it would be if you had their original source code.

And another common attribute of closed source software is that you typically must use it under a software license that restricts your freedom to tinker with it - so it probably isn't even legal to really fundamentally modify or improve the software (even if you can technically figure out a way to do it), and it most likely isn't legal to share your modified versions. (Continued below.)

And now for another (partly) humorous digression... It's a good thing most other things aren't sold under licenses similar to closed source software licenses. Imagine your toilet got clogged. You're perfectly capable of unclogging it yourself - but, unfortunately, actually doing so would be illegal, because the act of unclogging your toilet would violate your toilet license - the toilet equivalent of a proprietary software license or end-user license agreement (EULA). The toilet license is also known as the rear-end user license agreement. :-) Under the terms of the toilet license you had to accept before you were legally allowed to even install the toilet you bought and paid for - the only entity legally entitled to fix your toilet is the company who built your toilet. If you dare to fix it yourself, or even if you hire an unauthorized plumber to do it for you, you're breaking the law, and may be subject to enormous penalties. That's basically what closed source software is like. :-) And free, libre, open source software is like, toilets whose toilet licenses permit you to unclog your own toilet, hire anyone you want to unclog it for you, share your toilet with anyone you like, and build derivative toilets based on the design of your original toilet - under the condition that you may never put your own derivative toilet under a restrictive toilet license, like the licenses that the big evil toilet corporations all put on their toilets. And public domain software is like, toilets with no toilet licenses at all, which you can do whatever you darn well please with, without having to read or abide by any darn toilet license of any kind. But unfortunately, the lack of any restrictions at all means that evil toilet corporations can make their own versions of those unrestricted toilets, put them under restrictive toilet licenses, and thereby turn them into freedom-destroying toilets of oppression - more cash cows for the evil toilet corporations which make a fortune from their monopoly on the "service" of solving problems in their own products that they won't let anyone else fix. You might say, "Big deal, people don't have to buy toilets from evil toilet corporations. They're totally free to use libre toilets, or no toilet at all." But, the evil toilet corporations try to suppress the libre toilets by getting patents on various toilet technology, much of it absurdly obvious, like one-press flushing. :-) (Reminiscent of the infamous "one-click buying" software patent.) So if you make a libre toilet which flushes after pressing its handle just once, you might be guilty of patent infringement. Many libre toilet makers, intimidated by the threat of being sued by an incredibly wealthy evil toilet corporation, give in and instead make toilets which don't flush unless you press the handle twice - giving evil toilet corporations a competitive advantage because of the greater convenience of one-press flushing. Evil toilet corporations also have patented the act of tearing off sheets of toilet paper. (Reminiscent of Apple** patenting the page turn.) And with their armies of lawyers and public relations people, paid for by their ill-gotten riches, the evil toilet corporations can easily sway both the legal system and public opinion to their evil favor. Thanks to the evil toilet hype machine, unfree/un-libre toilets (and related unfree/un-libre products like maxiPads) are considered trendy and cool. The creepy spyware surveillance devices and various other things built into the toilets to obstruct unauthorized unclogging are portrayed as "cloggy protection" (reminiscent of copy protection) - supposedly completely justified measures necessary to enforce the rear-end user license agreement. Evil toilets contain all sorts of different TRM (Toilet Rights Management) schemes. (Reminiscent of DRM - Digital Rights Management). A common example of TRM cloggy protection is locked metal grates with holes large enough to let most waste pass through, but which effectively obstruct the insertion of plungers. If anyone unauthorized attempts to remove the grate, that sets off a built-in alarm, which alerts the evil toilet company and the authorities. Crackers of evil toilets developed a circumvention technique, basically involving a waterproof vacuum cleaner with a nozzle slim enough to fit through the cloggy protection grate - but this was soon thwarted by a TRM update which added a motion detector, a sophisticated video camera capable of swiveling to look in different directions and of storing and transmitting far more data than the original still camera, and new audio capabilities, to record any suspicious noises or conversation possibly indicative of an illegal unclogging attempt. The owners of evil toilets actually didn't have to accept the upgrades, but if they didn't, their toilet went into lockdown mode and became unuseable until they did accept. (Similar to online services that don't let you continue using them until you accept a new Terms of Use agreement.) One TRM scheme that tends to annoy even the most avid fans of evil toilets is the 20-second legal warnings which you must listen to before the toilet opens and retracts its anti-sitting spikes. (Sort of reminiscent of the unskippable legal warnings shown before you're allowed to watch many DVDs.) More recent innovations included pepper spray, and the attachment of an aquarium compartment containing beautiful but deadly jellyfish, stingrays, and miniature frickin' sharks with frickin' laser beams attached to their frickin' heads. Usually the aquarium serves decorative purposes, for which it is much-praised, but the release of these creatures is triggered automatically when illegal unclogging attempts are detected. Many owners of evil toilets just accept and excuse the surveillance by saying, "I have nothing to hide." And they excuse the obstructions of unauthorized unclogging by saying, "I wasn't interested in trying to break the law anyway. Of course, the toilet corporations have to have cloggy protection, or else they won't be able to make a living. Besides, what a beautiful aquarium! And toilets with anti-unclogging grates are less splashy than those dreadful, primitive libre toilets. Those amateur toilet makers don't know what the heck they're doing." So, despite the various nuisances, the evil toilets are still quite popular, and are considered sleek, elegant, stylish, far more professional and polished in general than libre toilets (as well as much easier to figure out), and a status symbol. It is thought that only geeky weirdos and poor people like to unclog their own toilets, while normal people prefer to pay a toilet-corporation-authorized plumber exorbitant amounts of money to do it for them. And while it's true that some "geeky weirdos" do genuinely enjoy unclogging their own toilets - for many, it's not the unclogging itself they like, but simply the freedom to unclog their own toilets without having to pay a ton of money to an evil toilet corporation to get it unclogged. As well as the freedom to build their own superior toilets which don't have 20-second legal warnings, lockdown mode, autoclose, anti-unclogging grates, anti-sitting spikes, alarms, surveillance, pepper spray, jellyfish, stingrays, mini sharks, lasers, risks of fines and jail time, and which don't get clogged as often, to make it so everyone is more free to spend their time, money and energy on more important things in life, instead of having to waste time, money, and energy on recurrent, needless toilet-related inconveniences resulting from ridiculous proprietary restrictions, deliberately bad design, and planned obsolescence. But, even more important than increasing people's freedom from relatively minor first world problems is to stop the evil corporations from continuing to exploit tremendously underpaid, overworked, and otherwise poorly-treated sweatshop labor. Despite the fact that the evil corporations are tremendously wealthy and could easily afford to pay their workers a fair amount of money - instead, they greedily exploit their poor workers. But fortunately, creating and using free, libre, ethical alternatives, and boycotting products created using sweatshop labor, are effective methods of pressuring evil corporations to change their evil ways, since using alternatives reduces the evil corporations' power and wealth, and makes it a lot harder for the evil corporations to succeed in their attempts to establish monopolies or oligopolies**. The more ethical competition the evil corporations have, and the more awareness the public gains of various corporate evils, the more difficult it gets for the evil corporations to continue profiting from their unethical ways, as more and more people choose ethical alternatives instead. Especially as the ethical alternatives become more and more polished, elegant, stable, convenient, and easy for non-technical people to use - which counters some of the strongest popular arguments in favor of continuing to use un-libre products. But even if evil corporations had no ethical competition - their business models would probably still be unsustainable in the long term, and are doubtless already harming their profits, as well as the world in general. As more and more people become impoverished because of the zombieconomy's corporate vampirism, such as huge, usurious fees and interest rates for credit cards, loans, and other financial so-called "services", excessively high bills for basics like a place to live and transportation, having to pay too much for other things that could be much cheaper (like software upgrades), or being forced to buy insurance - that decreases evil corporations' profits (and actually also makes it more difficult for most anyone to make money), since any business needs customers who can afford to buy things. Quite possibly, in the long run, the only way evil corporations will manage to stay in business or remain competitive is if they at least superficially clean up their act and start acting more ethical, even if they never have a true change of heart. Otherwise, they'll continue ruining the world for us all, including themselves. The poorer almost everyone gets, the harder it will be for almost anyone (including evil corporations) to financially survive. And the more we'll all miss out on all the wonderful things people might have created if we had not been financially oppressed. And that's just the tip of the iceberg of harm done by evil corporations. The satirical story in this box about evil toilet corporations, toilet licenses, toilet-related patents, ludicrous cloggy protection measures, etc. is fictional, and will remain fictional forever, I hope. But unfortunately, closed source software, software licenses and their many problems (including the fact that they're usually not read by Richard Dreyfuss), software patents (including the page turn and one-click buying), planned obsolescence, spyware, ridiculous restrictions on closed source software you bought and paid for, which forbid you from making any needed repairs or modifying it in any other way (among countless other absurd restrictions), the unethical use of tremendously underpaid, overworked, and otherwise poorly-treated sweatshop labor, various other major issues I didn't even mention, irritating Digital Rights Management (DRM) and copy protection schemes which can interfere with perfectly legal and legitimate uses of stuff you bought (such as by making you wait 20 seconds for unskippable legal warnings to go away before you can watch a DVD you bought), being pressured to accept new Terms of Use to be allowed to keep using a service you paid for, and the "zombieconomy" of vampiric evil corporations and their vast multitudes of destructive effects on the world and all our lives - are real. Many of the misdeeds of evil corporations are so bad that it makes the closed source software business (and the fictional evil toilet corporations) seem saintly in comparison. That's quite off-topic for this page, but, you can easily search the web for more info.

So, if there are any problems with closed source software, you generally either have to live with them, or beg (or pay) the copyright holder of the software to fix the problems for you - which they might or might not ever get around to doing, or they might do a bad job of it, or a job that is OK but doesn't really match exactly what you wanted, so you still end up having to live with something that isn't precisely tailored to your needs.

And when you upgrade to the "fixed" version, you'll just have to hope that the upgrade doesn't also contain unrelated changes that will break things that were already working just fine in the old version. It might be very hard to tell for sure what was changed, because you can't look at the original source code to check.

(I have very little experience with decompilers or reverse engineering, but, my guess is the source code produced by decompiling probably usually isn't as human-readable as the original source code.)

With closed source software, and/or compiled executables (even of open source software), you're basically at the programmers' and copyright holder's mercy. Using such software generally takes a lot of blind trust, because it can be hard to tell if the programmer(s) or copyright holder might have built in some kind of malicious malware such as spyware, or perpetrated some planned obsolescence, and you also can't check the original source code yourself for any catastrophic (or even minor) unintentional glitches.

Even excellent programmers can and do make unintentional mistakes - sometimes very major mistakes, because programming can often be very difficult and mind-boggling. So, that makes it even more terrible to be stuck with a black box whose inner workings you can scarcely examine or improve.

Not even the best programmers could guarantee that their work is perfect enough that it will never, ever have to be changed or fixed someday. And even if they could guarantee that their work is perfect - no one should be forced to just blindly trust that anyone's work is as perfect as is claimed by the author, copyright holder, or anyone else.

Many of the above problems are greatly alleviated with open source software - assuming you're compiling from source code yourself, instead of downloading already-compiled compiled executable versions of open source software. (If you ever use already-compiled software, make sure you get it from sites you trust, software repositories you trust, or people you trust, because you might have no easy way of knowing if the person who did the compiling might have deliberately put in some malware, or unintentionally created some glitches.)

If you compile your own software from source code, or run open source interpreted scripts, then you're only at programmers' mercy to the extent that you lack the technical expertise to understand the software you're compiling or running, or to the extent that you lack the time/energy to examine or test the source code/software for potential problems.

It's probably impractical to search for deliberate malware or unintentional glitches lurking in the source code of every software package you use, and if you can't understand the code, you might not recognize something bad even if it's right in front of you. But at least it's far more likely with open source software that you'll be able to track down and weed out problems - if not now, then at least at some point in the future. Or you could have someone more knowledgeable check things out for you.

So, even running open source software does often, in practice, take some blind trust, even if you compile it yourself - but at least you have the option to not so blindly trust, since you can keep copies of the source code you compiled from, and examine it anytime you want. Whereas with closed source software, you have fewer options - you can blindly trust it, or perhaps decompile it into maybe not so human-readable code, but not having the probably more readable original source code probably puts you at a disadvantage when trying to understand the code.

Much free, libre, open source software is released under a copyleft license which is intended to protect and preserve your freedoms that closed source software licenses try to deprive you of. One very popular copyleft license is the GNU General Public License**.

A minority of free, libre, open source software is released into the public domain. That's what I have frequently done with my own software, though there are some good arguments in favor of releasing software under a copyleft license - for example, a copyleft license can prevent derivative works based on open source software from being made closed source. That might prevent evil corporations from mooching as much off of the free but often brilliant and wonderful labor generously done by free/libre/open source programmers.

I've been having increasing misgivings about releasing my own work into the public domain anymore. Maybe my reasons for releasing things to the public domain are too frivolous and/or naive.

I love the fact that public domain software frees you from having to worry about any tedious legal-related crap or having to fulfil any requirements whatsoever, since you're free to do whatever the heck you want with public domain stuff. It frees you from the nuisance of having to read a boring software license, and frees me from the nuisance of having to put boring software license notices all over the place.

Also, I think a world with fewer lawsuits would be a much better world, so, I don't like the idea of feeding the legal industry monster by giving the world more fodder for people to sue each other about. (But, on the other hand, maybe suing big evil corporations might be one of the more effective ways to try to stop evil corporations from getting away with doing evil things?)

The public domain seems more truly free than any software license that requires you to do anything. I always feel refreshed and free when encountering public domain stuff, and burdened and annoyed when confronted with any license, even a nice enough (but usually long and boring) copyleft license. I find legalese extremely tedious, even if it's employed in the service of good rather than evil.

But, even though in those ways I prefer the public domain - maybe it would really be best to protect my work with a copyleft license. I'll have to make up my mind about that when I finally finish a really important project.

Note, April 12, 2013: I decided several days ago to start using the GNU General Public License** more often. I was greatly influenced by hearing in FLOSS Weekly 26 (around 38 minutes onward) that the incredibly generous author of SQLite**, who released SQLite into the public domain, gets paid what sounds to me like unfairly little money by the incredibly wealthy companies that use (and no doubt profit from) SQLite. Shame on those companies for not paying people what they deserve!

One of the best things about Linux, also known as GNU/Linux**, is that most software for Linux is free, libre, open source software. Even the Linux operating system (OS) itself is free, libre, open source software. So, even though Linux is far from perfect yet - at least anything free, libre, and open source (including Linux) is theoretically a lot more perfectable than anything closed source.

And if you can't do something yourself, maybe you can hire someone who can, or maybe someone will even create you something for free. (By the way, I offer Free/Libre/Open Source Software Programming Services.)

However, not all Linux software is automatically free, libre, open source. It's actually possible even in Linux to download an executable for which the source code just isn't available. For example, f.lux. (Unless I'm mistaken.)

And Puppy .pet and .sfs software installer files usually don't include complete source code inside of them, probably to keep the .pet or .sfs file's size as small as possible. Instead, .pet and .sfs files tend to contain compiled executables - though those are usually programs whose source code is freely available to download somewhere.

So, even installing .pet and .sfs files takes some blind trust in the maker of the .pet and .sfs file, as well as trust that the site or software repository you're downloading it from didn't get hacked and didn't get its files infected with malware. And the same for the .iso files containing entire Puppy Linux systems. As of 4/18/2013, I have never yet heard of malware in a .pet file, .sfs file, .iso file, or in Puppy Linux at all, but no doubt it's possible. There is such a thing as Linux malware.

At the moment, Linux malware is relatively rare (similar to Mac malware), probably mainly because Linux and Macs are less popular than Windows, but, as Linux gains in popularity, that might change someday. Also, Puppy is often criticized for the fact that Puppy typically runs things as the root user. So, please be careful.

Another thing you might find surprising is that even though Windows** and MacOS are closed source, there is plenty of free, libre, open source software available for Windows** and Macs**.

Oh, and I found out firsthand last year (2012) that you can actually boot Puppy Linux** on a MacBook from 2009. :-) I think that's the best thing about a Mac. :-D

That MacBook seemed incredibly pathetic, clumsy and cumbersome in comparison to my Puppy system's speed, elegance, comfort, flexibility and customizability. (Actually, the MacBook had a tough time competing with my Windows XP systems, too.)

Only running Puppy instead of MacOS on the MacBook made the MacBook begin to rival my main Puppy system. :-) But the MacBook still couldn't beat it, because that 2009 MacBook has a slower processor. :-) And even the screen wasn't as nice as I expected from a Mac.

It's nice to know that despite being unable to comfortably afford Apple stuff, I haven't really been missing out on much of anything. :-)

Besides, there are even many ethical reasons not to buy Apple** stuff. See Richard Stallman**'s page: Why you should not buy Apple computer products.

Open source software, like closed source software, varies dramatically in quality. Free, libre, and open source doesn't automatically equal great (even though it does always equal potentially great), and much closed source software can be useful and nicely designed despite the flaws that are inherent to any closed source software (many already explained above).

Free/libre/open source software can be vastly better on a technical level, as well as better-designed and more user friendly than the liberty-destroying and potentially expensive closed source "equivalents" - or, free/libre/open source software can be comparatively bad, rough around the edges, and not very well-designed or user friendly at all... so far.

But at least anything free, libre, and open source can potentially be fixed exactly the way you want, someday in the future - and if you gain enough technical knowhow, you could even do it yourself.

Modifying software yourself (or making it from scratch) definitely isn't (or isn't always) just a theoretical/impractical idea - though it can be with very complicated programs.

But happily, it sometimes doesn't take very much knowhow at all to make the one little tweak that makes an imperfect piece of software perfect for your needs - or to make your own programs from scratch, which can instantaneously do complicated tasks that would be extremely laborious if you had to do them manually. It's almost like magic. :-)

While with closed source software - even if you have all the technical ability you would need to make needed repairs and improvements yourself (if you had the source code), generally your only options are to beg (or perhaps pay) the copyright holder, and wait. And if the copyright holder decides they want to give that software the axe and no longer support it no matter what - perhaps because they want to try to force you to buy something else - you're stuck.

So, for example, everyone who likes Windows XP (like me) is increasingly abandoned by Microsoft**, probably largely because Microsoft probably wants everyone to buy newer versions of Windows** - even though there are probably lots of people who would happily pay to be able to keep using Windows XP.

You might think, "Big deal - Microsoft can't come to my house, delete my perfectly legal Windows XP from my computer, and confiscate my perfectly legal Windows XP CD - so, I'll have Windows XP forever no matter what." But, Microsoft actually wouldn't have to do that to make it a lot more difficult for you to use Windows XP.

After you install a fresh copy of Windows XP, you have to use the built-in activation wizard to activate Windows XP by sending your Windows XP Product Key (which is probably on a sticker on your computer) over the internet to Microsoft. You're given a grace period of maybe something like 30 days to do that before you're locked out of Window XP.

And if Microsoft wanted to, they could stop letting people even activate their copies of Windows XP, and then people who no longer have an activated copy of Windows XP (such as because their old computer broke down) would be stuck having to reinstall Windows XP like every 30 days, or whenever the grace period expires. (Or, as Microsoft probably hopes, people might instead upgrade to a newer version of Windows... and possibly new computers, if their old hardware can't handle newer versions of Windows.)

Hopefully Microsoft won't choose to do that to us poor Windows XP users, but, just the possibility that Microsoft could if they wanted to is worrying.

And I'm really glad I don't have to worry about that sort of thing at all with free/libre/open source software.

For more info about free/libre/open source software, see:

• Philosophy of the GNU Project - GNU Project - Free Software Foundation (FSF)

• Philosophy of the GNU Project - Latest Articles - GNU Project - Free Software Foundation (FSF)

• Why Software Should Be Free - by Richard Stallman**

• The Free Software Foundation

• GNU.org

• DefectiveByDesign.org

• Stallman.org

Any software, whether compiled software or interpreted scripts, in practically any programming language, can be dangerous in so many ways it would be very difficult to adequately summarize them - especially for me, since I'm definitely still quite far from being an expert on any computer-related things (except perhaps my own software that I wrote from scratch).

But, software programs and scripts are often incredibly powerful and might be capable of doing anything on your computer. This could include very bad things like deleting or overwriting files, violating your privacy or security, or who knows what else.

Even if a program or script isn't intentionally malicious, it easily might have unintentional bugs or glitches, which could range from minor and harmless, to catastrophically destructive.

So, you should be very cautious and avoid running scripts you don't fully understand, or any programs you're unsure of. Unless, perhaps, they're from a source you trust - but even in that case, it's probably good to be cautious, since even websites you'd ordinarily consider trustworthy might get hacked.

Even very tiny programs, or very short scripts, can be very dangerous. Also, sometimes programming languages have quite dangerous commands with innocuous-sounding, easily overlooked names, like PHP's unlink command, which deletes files.

(Though at least PHP's eval command and JavaScript's eval command have an appropriately mnemonic name - "eval" is very close to the word "evil".)

And when writing your own software or scripts, it's quite easy to accidentally create bugs or glitches - which, by the way, actually doesn't necessarily mean you're a hopelessly bad programmer. With anything that is often so complicated as programming, I think making mistakes is pretty normal and practically unavoidable

Even the best, most experienced programmers make mistakes (though experience surely helps them make a lot fewer). Also, it's difficult even for incredibly wealthy corporations to release problem-free software, judging by all the security holes and other bugs that need to be fixed with annoyingly endless-seeming updates. So, even throwing immense amounts of money at the problem can't guarantee perfect software.

And those problems aren't restricted to closed source, proprietary software. Even major and popular free, libre, open source projects tend to have problems and endless-seeming updates too, though theoretically fewer problems, and theoretically problems might get detected and fixed quicker, since many more people get to eyeball, test, and fix the code.

Programming generally requires strict attention to detail and logic - a lot more than is usually called for in everyday life. Programming is like giving orders to an employee (your computer) who is 100% obedient, and often dazzlingly fast and talented - but who is absurdly literal-minded and has to be told precisely what to do, or else it's not going to get done properly.

If you ask your employee to go to the coffee shop across the street and buy you some coffee, they'll do it - but if you forgot to tell them to be careful and look both ways before they cross the street, they easily might get hit by a car, because they'll just mindlessly and unhesitatingly cross the street while looking straight ahead and utterly oblivious to any oncoming traffic.

And if you forgot to tell them that after buying the coffee, they must return to your office and give it to you, they'll just stay in the coffee shop all day, not knowing what to do after your last instruction ("buy coffee"). :-) And they won't even be relaxing and having fun. Instead, after fulfilling your final instruction, they'll end up just standing at the counter staring like a zombie until escorted away or given additional orders.

And things might not even go that well, if you forgot to ever teach your employee precisely how to hold a cup of liquid without spilling it. :-)

So, with programming, you have to think things through carefully and break tasks down into basic (sometimes excruciatingly basic) steps. This can be especially difficult with complicated tasks you yourself are having trouble understanding, but writing down each step in plain English instead of plunging straight into code can help a lot.

Besides nuts and bolts, you also probably should think about the big picture, the overall software design. If you pay no attention to that, it might be a bit like trying to build a house by haphazardly nailing (or duct-taping) random pieces of wood, etc. together without following any blueprint at all.

A great book I read about programming in Oct./Nov. 2012 was Code Complete, 2nd edition**. Lots of useful tips in that, which probably both experienced and beginner programmers can learn a lot from.

There are a great many easy ways to accidentally make scripts vulnerable to hacking. With web scripts especially, you need to be on guard against things like SQL injection attacks, and all sorts of other things I'm also not particularly qualified to write about.

Here are a couple informative pages, but you should definitely do your own research. There is quite a lot to learn.

• Security of your site - Dangerous Software! - A basic introduction.

• IBM.com: Seven habits for writing secure PHP applications - Looks like a pretty thorough summary. But I wouldn't assume it (or any other page) is 100% comprehensive - simply because, when it comes to security, you should probably always assume there's always more to learn, because new, previously unsuspected exploits get discovered all the time, and there are so many already known that even if you know a lot, it's unlikely you've learned about everything.

And some Wikipedia pages. (You should always take Wikipedia with a grain of salt because Wikipedia can be edited by anyone.)

• Vulnerability (computing)

• Category: Computer security exploits

• Category: Injection exploits

• Category: Web security exploits

If you really want to try out some software or scripts you don't fully trust, maybe a relatively safe way to do it might (or might not?) be to create a VirtualBox** virtual machine with no internet access, and run the untrusted software in that?

I'm not sure, though - I hope there's no way for software inside a VirtualBox to hack VirtualBox from within the virtual machine, and access your real system.

If you're running Puppy Linux**, it's very likely that a lot of files in your system are exclusively in a RAM disk, and not being saved immediately to a (so-called) permanent storage medium such as a hard drive, Flash drive, or writable CD/DVD.

Anything that is in a RAM disk is only in temporary memory and can easily be lost when your computer is shut down.

Puppy does give you some options for saving RAM disk changes, like by saving sessions on a writable multisession live CD or DVD**, or saving stuff to a Pupsave file on a hard disk or Flash drive, but, as I explain below, those have some drawbacks, and I prefer immediately saving things myself to permanent storage media.

So, when you're running Puppy, and creating or saving files you want to keep - it's very important to be certain you save those files to a permanent storage medium, rather than only the RAM disk.

It's terrible to find (as I did at least once) that something you worked on for a while has irretrievably vanished into thin air because you accidentally saved it to the wrong place - inside the RAM disk instead of on permanent storage - and shut down your computer.

So, please be careful and make sure you really are saving files you want to keep to a permanent storage medium. See: Where to Find Your Permanent Storage Media in a Puppy Linux System

I believe full installations of Puppy and some frugal installations - those in which you've already created a Pupsave file and are not running Puppy in RAM - might be the only kinds of Puppy where changes get saved immediately to permanent storage. So, more likely than not, you need to be on guard against accidentally saving things to the RAM disk rather than permanent storage.

Not that the RAM disk is a bad thing. Despite the above danger, I think Puppy running in RAM is actually quite a good thing in a lot of ways. See: Why the RAM Disk is Nonetheless a Good Thing

Depending on how you run Puppy, there is often a built-in way to save RAM disk changes to some form of permanent storage. But even if the way you're running Puppy permits you to make a Pupsave file, or save sessions on your CD/DVD, I think it's generally safer, more immediate, and more reliable to just immediately save your files yourself to a permanent location.

With a writable multisession live CD or DVD**, you could lose files if the power happens to go off or Puppy crashes before you click the Save button to write your new files to the disc, or before you save your session at shutdown. Or, you might accidentally say no when asked to save your session.

You could also run out of space on the CD or DVD relatively quickly (compared to a larger disk like a hard drive or large varieties of Flash drive), and unless you save big files to the /archive/ folder (explained on this page), recent big files could stop older files (such as customizations you made in an earlier session) from being loaded into RAM at bootup.

And writing to CDs or DVDs is relatively slow compared to writing to a hard drive or Flash drive.

With a frugal installation of Puppy running in RAM, then, if you haven't created a Pupsave file yet, I believe losing files in the RAM disk would be a danger until you shut down and say yes when it asks if you want to create a Pupsave file. And, you might accidentally say no when asked to create a Pupsave.

If you already have a Pupsave file, then, I believe losing files might be a danger until you either manually save stuff to the Pupsave file, or the automatic save happens at whatever interval it is set to happen, or you shut down (which I think might cause an automatic save).

Another possible problem is, I've read of people having problems with corrupt Pupsave files. And Pupsave files, like CDs and DVDs, are limited in size compared to hard drives or large Flash drives.

You might get the impression from the preceding section that the RAM disk is a bad thing. But except for the above danger (which is thankfully avoidable if you're careful), I actually think Puppy** running in RAM is a very good thing - especially if you have a large amount of RAM - and I think the benefits greatly outweigh the drawback of having to be more cautious than usual to avoid data loss.

Thanks largely to Puppy's ability to run exclusively in RAM, Puppy is the fastest OS (operating system) I've ever used. Computers work much faster when they have the programs you want to run and/or the data you want to work with fully in RAM, and thus don't have to read the programs/other data from a relatively slow physical disk, nor write temporary files (like a web browser cache) to a physical disk.

I also love being able to experiment with my system a lot more recklessly than I would dare with an OS (operating system) that immediately permanently saves every change I make.

If I mess anything up, all I have to do to get back to a fresh, clean (but also nicely customized) system is reboot, and run my setup script. (See Apollia's Puppy Setup and History with Puppy for more info about my actually rather unusual way of doing things.)

Another reason I love Puppy so much is because I much prefer running an OS (operating system) that doesn't have to constantly mess around with my hard drive, and in fact doesn't even require a hard drive at all.

In the past, I had such harrowing experiences with one failing hard drive, and one old and squeaky (but astonishingly, still not failed yet) hard drive that I just love being able to comfortably do without any hard drive at all.

I still suspect my one hard drive that failed might've been sent to an early grave by inconsiderate overuse by Windows XP.

Another thing I like is saving big downloaded files to the RAM disk and then copying them to my hard drive, since I think that might be easier on my hard drive than having my hard drive written to the entire time the file is downloading.

For the same reason, I like building TrueCrypt** volumes (if they're small enough to fit) inside the RAM disk, then copying them to their permanent location. Also, TrueCrypt volumes are built tremendously faster in the RAM disk.

I also like having temporary workspace folders inside the RAM disk, where I can fool around with temporary files without having to clean them up later.

Puppy typically has two clipboards (at least that I know of).

1. An ordinary clipboard that behaves like the clipboard in Windows - where, to copy things, you just select some text (or something), and press Ctrl and C at the same time on your keyboard (or select Copy from the Edit menu of whatever software you're using).

   To paste text (or whatever) with this clipboard, you can either press Ctrl-V, or select Paste from the Edit menu of whatever software you're using.

   
   

2. A pernicious other clipboard that often captures any text you highlight, without you having to do anything extra.

   To paste text with the second clipboard, you click the middle mouse button or mouse wheel.

That second clipboard can be dangerous in at least two ways I can think of. First, here's how it can be dangerous to your privacy.

If you highlighted a lot of private text on your computer, thereby unknowingly storing it in the second clipboard - then, conceivably, while browsing the web, you could accidentally click your middle mouse button and send your private text over the internet.

Luckily, at least the Firefox web browser lets you disable pasting with the middle mouse button, but only within Firefox.

• Type about:config in your Firefox address bar and press return.

• Then, in the Filter text field, type "middlemouse".

• Change the preference middlemouse.paste to false.

Another bad thing that can happen as a result of the second clipboard is, you can accidentally paste a lot of stuff you didn't mean to paste into a console window. Depending on what's in your clipboard, that could be quite dangerous.

An annoying (and potentially dangerous) thing about the rxvt console** is that the only way rxvt lets you copy or paste text is via the second clipboard.

Sorry, I don't yet know how to disable middle-click pasting universally throughout Puppy Linux.

So, please be careful.

Another clipboard-related problem with Puppy is that closing programs (and sometimes even just opening programs) can wipe out your clipboard.

That means, if you copy something in a certain program, then close that program (or even a completely different program - Firefox definitely does this) before pasting whatever it was, you'll most likely find that when you do try to paste it, your clipboard will be empty.

Or, if you copy something in an rxvt** console window, then open another rxvt console window and try to paste, you sometimes might find you can't paste.

So, please be careful to avoid data loss.

pClock is a small, useful program with various clock-related tools that is built into various Puppies. Fortunately, the following glitch should never affect you if you never open pClock, and even if you do use pClock, it will probably take a long time for this glitch to get to be a major nuisance, and long before it reaches that point, you can kill the processes that cause the problem - instructions below.

Some versions of pClock have some kind of infinite-loop glitch which floods the file /tmp/xerrs.log with error messages, writing to it every second, and also writing to the files /root/.pclock/tmp/timer and /root/.pclock/tmp/NANOSEC every second.

There's a Puppy forum thread where people reported the same problem. Page 55: Dpup Exprimo 5.X.3.4.12 with 3.4.2 kernel.

I don't know all the versions of pClock or Puppy this happens with, but, the pClock program in Lucid Puppy 5.2.8 version 004 is definitely affected. It begins immediately after opening pClock.

By the time I noticed this glitch, my /tmp/xerrs.log file had slowly grown to 308 MB, but fortunately that took a long time - I hadn't shut down or rebooted my computer for nearly a month (March 13th to April 7th, 2013) because of hardware problems of some sort that have been making my computer really difficult to successfully boot. I'm not sure what day I had used pClock, but probably sometime in March, and I noticed the problem on April 7th.

Then when I deleted xerrs.log, the 308 MB RAM it was taking up didn't even get restored to my total of "personal storage space".

To stop /tmp/xerrs.log from continuing to grow, I had to kill the infinitely looping processes pClock had started but never ended (even after closing pClock).

I did that by going to the System menu, then the System Status and Config submenu, then Pprocess process manager, searching for "pclock" (without quotes), then highlighting and killing all the processes that said:

sh -c while [ ! -f /root/.pclock/tmp/end_while ]; do func_time; sleep 0.05; done

Rox-Filer is the default file manager in probably most Puppy Linuxes**.

Rox-Filer's manual is here: http://rox.sourceforge.net/Manual/Manual/Manual.html

In Puppy, when you're browsing windows full of files and folders, the content of those windows (except for the window title bar) is most likely managed by the Rox-Filer file manager (unless your Puppy actually uses some other file manager).

Also, the Puppy desktop background (otherwise known as the Rox-Filer "pinboard"), which displays whatever desktop wallpaper you're using and holds various icons by default (like "file", "help", "install", etc.), is managed by Rox-Filer.

If you're a Windows** or Mac** user, you'll find that the Rox-Filer desktop (pinboard) doesn't work as intuitively as the Windows desktop or Mac desktop. For just one example: anything dragged and dropped onto the desktop isn't moved there - instead, a shortcut to the item at its original location is created.

Surprisingly, the window title bar of Rox-Filer windows isn't actually managed by Rox-Filer. Window title bars of any program's windows are handled by whatever window manager you're using - which, in Puppy, is frequently JWM (Joe's Window Manager) or OpenBox by default, though I prefer IceWM (despite the maximum of 4 additional desktops), since it looks nicer to me and has nicer, unflickery menus.

Your window manager also manages the taskbar which is probably at the bottom of your screen, which by default contains a list of open windows, the time of day at the lower right, and allows you to access the Puppy equivalent of the Windows Start menu by clicking the menu button at the lower left of the taskbar.

If you right-click directly on the desktop (pinboard), a right-click menu created by your window manager will appear. If you single-click instead, a different menu created by your window manager will appear.

And if you right-click on an icon on the desktop (pinboard), a right-click menu created by Rox-Filer will appear.

By default in most Puppies I've tried - when you try to drag and drop files from one folder to another, a little menu appears containing 4 options: Copy, Move, Link (absolute), and Link (relative).

This wouldn't be quite as bad if Puppy didn't have so many folders in a RAM disk. But, since Puppy does - that little menu is a menace, since it makes it all too easy to accidentally select Move instead of Copy.

That could be a disaster, if you tried to copy some files from a permanent storage medium to a temporary folder in the RAM disk, but mistakenly clicked Move instead of Copy, and never realized that the files you thought you copied (and thought were safely stored in your permanent storage medium) actually got moved to the RAM disk, and hence deleted from the original permanent storage medium. In that case, whenever you finally shut down your computer, your files would be gone, unless you saved a session to your writable multisession live DVD** or have a Pupsave file. (But you still might have problems if your disc or Pupsave file doesn't have enough memory to hold your files.)

So, I think it's far safer to change the Rox-Filer file manager's default settings so dragging and dropping files with the left mouse button always just copies them, instead of making that menu appear.

The settings for that can be found in Rox-Filer's Options window in the Drag and Drop section.

Here's how to get there and fix the settings:

• Right-click on anything in a Rox-Filer window (other than the title bar or the "toolbar" containing icons like an arrow, a house, etc.) to make a menu appear, and select Options from that menu.

• In the Options window, highlight Drag and Drop in the list at left.

• Now in the right side of the Options window, there should be a section titled When dragging files with the left mouse button, with two radio buttons below. Choose Copy instead of Show a menu of possible actions.

• Below that section, there should be a section titled When dragging files with the middle mouse button, also with two radio buttons below. Unfortunately, these are two lousy, dangerous choices - Move and Show a menu of possible actions. In this case, the menu is the lesser evil, so choose Show a menu of possible actions.

• Click OK to save your settings.

The Rename dialog in the Rox-Filer file manager has a glitch where it not only lets you edit the file's name, but also the file's path. So, if you accidentally edit the file's path instead of just its name, your file will be moved to that other path.

If you lose track of a file because of this glitch, hopefully you'll be able to find your file using the Pfind program in the Filesystem menu.

In case your Puppy's default setting is driving you crazy - that setting is controlled in the Rox-Filer file manager by the Single-click navigation checkbox in the Filer windows section of the Options window.

Here's how to get there and fix the settings:

• Right-click on anything in a Rox-Filer window (other than the title bar or the "toolbar" containing icons like an arrow, a house, etc.) to make a menu appear, and select Options from that menu.

• Now, you're probably at the correct place in the Options wiindow already, but if not, highlight Filer windows in the list at left.

• The Single-click navigation checkbox should be in the right side of the Options window now under Window behavior.

• Adjust as desired, then click OK to save your settings.

• Click on any already-open Rox-Filer file manager folder window, or open one (such as by clicking the file icon on your desktop).

• Press / (slash) on your keyboard to bring up a Goto text input field at the bottom of the folder window.

• Type (or paste) whatever path you like in the Goto field.

• Click on the Rox-Filer file manager folder window whose path you want to find out.

• Press / (slash) on your keyboard to bring up the Goto text input field at the bottom of the folder window.

You can highlight the path by pressing Ctrl and A on your keyboard at the same time, and then copy the path to your clipboard by pressing Ctrl and C.

Then, whenever you want to paste the path somewhere (such as a text editor window), you can press Ctrl and V.

See Wikipedia: Symbolic link

Symlinks are very useful special little files which point at files in other locations. Wikipedia says: "programs that read or write to files named by a symbolic link will behave as if operating directly on the target file."

Symlinks give you a way to get around storing things directly in the Puppy RAM disk. If a program expects a file/folder to be at a location inside the RAM disk, but you want to keep that file/folder in a permanent storage medium, then, in the RAM disk, you can put a symlink which points at the file/folder in its permanent storage medium - and in general, this should work just fine.

(Unless you're dealing with a particularly irritating nosy program which notices you're using symlinks and objects to them. I believe that happened to me once, but I can't remember the details.)

A symlink can have either a relative or absolute file path or folder path as its destination. A relative symlink's destination will be a relative path - a path which will vary depending on where the symlink is located.

An absolute symlink's destination is a complete, absolute file path or folder path which will always stay the same regardless of where the symlink is located.

If you're used to Windows XP shortcut files, you'll find that symlinks won't behave exactly as you might expect them to. For example, symlinks to folders, when opened by the Rox-Filer file manager, cause Rox-Filer to lose track of what folder path you're really at, which can be quite confusing.

So, I don't recommend using symlinks just like you would use Windows shortcuts. If you just want a quick way to get back to a certain folder, it's better to make a double-clickable Bash** script or Perl** script or something. For example:

http://astroblahhh.com/software/perl/simple-folder-opener-v1_1.txt

http://astroblahhh.com/software/perl/simple-folder-opener--fewer-comments-v1_1.txt

To create a symlink using the Rox-Filer file manager:

• Right-click on the folder or file you want the symlink to point at. A menu will appear.

• Go to the menu item File '[name of the file you right-clicked]' or Dir '[name of the folder your right-clicked]', and choose Link... from the submenu. (Be careful, "Link..." is just above "Delete".) A little Symlink window should appear.

• Put in whatever file name (and optionally, path) you want for the symlink.

  
  

• Decide whether you want a relative or absolute symlink (see above for explanations of those), and set the Relative link checkbox accordingly.

  
  

• Click the Symlink button.

To quickly and conveniently create a new file using the Rox-Filer file manager:

• Go to the folder where you want to create a new file.

Then, either:

• Press Ctrl and N at the same time in your keyboard.

• Or right-click anywhere inside the folder window (other than the title bar or the "toolbar" containing icons like an arrow, a house, etc.), go to the New menu, and choose Blank file.

To open a window where you can set the permissions on a file using the Rox-Filer file manager:

• Highlight the script and press Ctrl and P on your keyboard at the same time.

• Or, right-click on the script, go to the "File '[name of your script file]'" menu, and choose Properties.

Alternatively, you can use the chmod console command. See: FreshTutorial.com: Chmod Linux and UNIX command tutorial

chmod is particularly useful if you have lots of files whose permissions you need to change. The -R (also known as --recursive) option helps with that.

See What is the difference between shell, console, and terminal? from Superuser.com.

I've generally been pretty foggy on the differences between them myself, so I've often used the terms shell, console, terminal, and sometimes even command line or command prompt just about interchangeably, which I think is what many other people do too. But there are shades of difference in meaning between all of those terms, so see the links to get a better idea of the differences.

In a shell/console/terminal window, you can type shell/console/terminal commands at a command prompt, and that can make all kinds of things happen in your Puppy Linux** system.

In fact, there are things that you can't do any other way, because not all Linux commands (or software) have a graphical user interface (GUI). (That's actually even true of some Windows commands and software.)

When you first encounter the concept, the shell/console/terminal/command line/command prompt may superficially seem like just a primitive relic of computing history - but actually, it can be very powerful and convenient. And once you grasp how great it is, you might begin to consider it barbaric when software doesn't give you extensive capabilities for controlling it through a command line.

What is rather primitive, in my opinion, is how unintuitive and undescriptive (to human readers) the commands often are. Seldom are things as readable as plain English. But, at least there's quite a lot of documentation around the web about these venerable old relics, and you often needn't limit yourself to only looking at Puppy Linux-related pages about them.

(Though sometimes it is a good idea to look at Puppy-specific pages, one reason being because Puppy sometimes uses Busybox commands instead of the full versions of commands, and they don't always act the same or have all the same features.)

Oh, and another primitive thing is, the rxvt terminal emulator**. It works OK, but it's so no-frills it's a bit painful to use, and I particularly dislike its use of Linux's pernicious second clipboard, which I'd like to disable completely if I knew how.

There are many different kinds of shells in existence, and the default in many Puppies is Bash**.

Here's An A-Z Index of the Bash command line for Linux.

You're not limited to having to manually type Bash commands to execute them - you can also make Bash scripts, which are simply text files containing many different shell/console/terminal commands. (To make a Bash script file executable, put the line #!/bin/sh at the top, and give it at least the Owner:Executable file permission. See How to Set File Permissions.)

Here's a Bash Guide for Beginners.

But, be warned - Scripts (or Any Software) Can Be Dangerous.

You're not limited to that A-Z list of Bash commands - you can also run software you've installed (or which comes with Puppy) by typing commands for it. For instance, to run PHP**, Perl**, or Python**, you can type php or perl or python.

(PHP and Perl won't do anything entertaining if you type just their names like that - but Python will give you a fun interactive shell, if you have Python installed.)

Sometimes it's possible to run things by typing a period and slash followed by a file name, like:

./configure

Seems to work for Bash scripts, maybe other things too, I don't know. Another shell command for running Bash scripts is sh followed by the name of the Bash script you want to run.

I definitely don't recommend trying to run files indiscriminately. If you don't have any idea what a file is, it's probably best to leave it alone.

You can use this command to get info about many commands:

man [then the name of whatever command you're curious about]

man is short for "manual", as in, helpful explanatory documentation.

Usually, rather than displaying built-in documentation, Puppy will try to open a web page on the internet related to that command (or whatever gibberish you typed).

(That, by the way, could be a privacy hazard, so don't type your secret innermost thoughts into a console window after the "man" command unless you want them sent over the internet.)

Using the Rox-Filer file manager:

• Go to the folder you want to use as the working directory.

• Press ` (the backtick key, located most likely below the Esc key) on your keyboard to open a console window.

To display the current working directory, use the pwd command.

Any volumes (disks or disk partitions) you've mounted already (and haven't yet unmounted) can be accessed through folders inside:

/mnt/

The folders will probably have odd names like sda1, sdb1, etc. (This page helpfully explains those names.)

Different disks each receive names/folders with different third letters. For example, on my computer, sda and sdb are usually my Flash drives, and sdc is usually my hard drive. (Though the order can easily change if I plug any of those disks into different USB ports.)

Different partitions on the same disk will all have the same third letter in their folder name - for example, sdc1 and sdc2 are two different partitions of the disk sdc.

However, if you haven't mounted any disks or partitions yet, your disks and partitions won't even be in /mnt/ yet.

You can get a list of your currently-mounted volumes (disks or disk partitions) with this console command:

df

That command also happens to list some other things, such as loop devices. (That includes TrueCrypt** volumes - if you use TrueCrypt - and any .sfs files you have mounted.)

Actual disks and disk partitions will have names like sda1, sdb1, etc. (That's explained in more detail above).

If you're mainly a Windows** user, you might not be used to the idea of having to mount volumes (disks or disk partitions) before you can use them. But in Linux, that's necessary - and so is unmounting them before you physically disconnect them from your computer, or shut down your computer.

This page from the Ubuntu documentation wiki has a scary warning about why it's important to unmount things: Mount/USB

Quoted from there:

Before disconnecting devices, you must unmount them first. This is similar to "Safely Remove" in Windows in that the device won't unmount until data is finished being written to the device, or until other programs are finished using it. This applies to all types of storage devices, including flash drives, flash cards, external hard drives, ipods and other media players, and even remote storage like Samba or NFS shares.

Failure to unmount before disconnecting the device can result in loss of data and/or a corrupted file system. There are no exceptions to this rule. Be safe - unmount your drives before disconnecting them!

More on unmounting below.

Happily, most Puppy Linuxes make it simple to mount your disks and disk partitions and start browsing them. There's usually a row of icons for each disk and partition along the bottom of the Puppy desktop. Just click on the icons to mount and/or open whatever volumes you like.

Once mounted, folders (really, mountpoints) for your volumes can be found in this folder:

/mnt/

Before you shut down your computer, it's very important to unmount any volumes (disks and disk partitions) that have been mounted. Also, before you physically disconnect any disk from your computer, you should unmount it (if it's mounted).

This page from the Ubuntu documentation wiki has a scary warning about why it's important to unmount things: Mount/USB

Quoted from there:

Before disconnecting devices, you must unmount them first. This is similar to "Safely Remove" in Windows in that the device won't unmount until data is finished being written to the device, or until other programs are finished using it. This applies to all types of storage devices, including flash drives, flash cards, external hard drives, ipods and other media players, and even remote storage like Samba or NFS shares.

Failure to unmount before disconnecting the device can result in loss of data and/or a corrupted file system. There are no exceptions to this rule. Be safe - unmount your drives before disconnecting them!

According to this quite old forum thread, Puppy attempts to automatically unmount everything at shutdown, but, I prefer to always do it manually just to be safe.

If you intend to physically disconnect a disk while your computer is on, you'll definitely have to manually unmount it (if it's currently mounted), since of course, Puppy can't read your mind and just know that you're about to suddenly disconnect something.

To manually unmount a volume (disk or disk partition) - right-click on the volume's desktop icon to bring up a menu, and choose Unmount [volume name] (if currently mounted). Careful not to accidentally click too hastily, though - when the right-click menu comes up, the "Remove item" menu item might be positioned right under your mouse cursor. Fortunately, "Remove item" will only remove icons from the desktop, and not actually do anything to your disks or partitions.

But, it's irritating to remove the icons unintentionally, because the only way I know to get them back is to use the "Restart X server" menu item in the Shutdown menu - which you shouldn't use until you've saved anything you're working on, and closed all your problems, because, depending on your Puppy, "Restart X server" might immediately restart X Windows without even asking you for confirmation.

To attempt to unmount all mounted volumes (disks or partitions) - right-click on any disk or partition's desktop icon to bring up a menu, and choose Unmount ALL mounted partitions. (The same warning applies here too.)

In Lucid Puppy 5.2.8 version 004, I've sometimes encountered a glitch where a volume that is definitely unmounted still has the desktop icon of a mounted volume.

When that glitch happens, the only way I know to make the proper icon display is to restart X windows, but read the warning above before doing that.

More often, though, volumes (disks and partitions) that look mounted (judging by their icon) really are mounted.

You can get a list of your currently-mounted volumes with this console command, explained in greater detail above:

df

It's very common that unmounting might not work right off the bat. If there are processes currently using a volume (disk or disk partition), you won't be able to unmount the disk or partition until those processes are stopped, either by closing programs to stop the processes in a nice, natural way - or forcibly (and potentially dangerously) killing the processes.

The alert box for an unsuccessful attempted unmount will give you the numbers of the processes that are using that disk or partition. (Instead of numbers, it might even say "kernel", and I assume - without having ever tried it - it's probably very dangerous to try to kill the kernel, since the kernel is basically the core of Linux, if I'm not mistaken.) I recommend that you do not click the KILL button, but instead note the process numbers and click EXIT.

Then, go to the System menu, then the System Status and Config submenu, and choose Pprocess process manager. (That's not a typo.) There, you can look up the process numbers and see what processes are using your disk or partition. And, if you really want to and think it's safe enough, you can kill those processes, but please be careful.

Be careful about saving files to folders in /mnt/ that belong to volumes (disks or disk partitions) you mounted then unmounted. After you unmount a volume, there will still be a folder for that volume in /mnt/ even though the volume is no longer mounted.

But if you save anything to that folder, it will be in the RAM disk only (where it's only in temporary memory and unless saved somehow, could easily get lost when you shut your computer down), because that folder is now just an ordinary folder instead of a mountpoint (which actually accesses a real disk or partition and enables you to save things on it).

And remounting the volume will not cause the files in the RAM disk in that folder to be merged with the actual contents of your volume. In fact, after remounting your volume, you won't even be able to see the files you accidentally saved in that folder on the RAM disk until you unmount your volume again.

To really save those files to your volume (disk or partition), unmount your volume, move the files you accidentally saved to the non-mountpoint folder elsewhere, then remount the volume, and move or copy the files to their proper place inside the volume.

In many Linux save dialogs, you can save bookmarks to locations you go to frequently - but, because of the above problem, you should never bookmark the top level of a volume (disk or partition) - like /mnt/sda2/ - but instead a deeper folder, like: /mnt/sda2/Saved Files/

Otherwise, if you mounted then unmounted sda2 - then, when you tried to save things to /mnt/sda2/, you'd accidentally be saving things to an ordinary folder inside the RAM disk (where they could easily get lost when you shut down your computer), instead of a mountpoint that actually accesses a real disk or partition and enables you to save things on it.

Most Puppy Linux** variants don't have a full set of software development tools such as compilers already built in.

So, generally, the development tools are made available in a DevX file in .sfs format, which you can often download in the same directory where you got the .iso file containing your variant of Puppy Linux.

Different variants of Puppy generally each have their own DevX file, and you must use the DevX file which was made for your Puppy.

See: Where to Get Puppy Software

The DevX file may contain compilers for C, C++, and Vala. The DevX also may contain a full version of Perl**, (instead of the stripped-down version that comes with many Puppies), and Python**.

DevX files also contain tons of other stuff, but I'm not sure where you'd find a complete list of contents.

A .pet file is a convenient installer file for software which can be used in one or more variants of Puppy Linux**.

More info here:

http://puppylinux.com/development/createpet.htm

http://puppylinux.org/wikka/Pets

.pet files generally contain compiled executable software rather than source code. That gives you the convenience of not having to compile the software yourself - but, you should be cautious to get .pet files from trustworthy sources.

As of 4/18/2013, I have never yet heard of malware in a .pet file or in Puppy at all, but no doubt it's possible. There is such a thing as Linux malware. So, please be careful.

See: Where to Get Puppy Software

A .pet file can be installed either by double-clicking on it or single-clicking on it, depending on how you have your file manager software (such as Rox-Filer) configured.

Warning: If a file already exists at a location where a .pet intends to install a file, the install will mercilessly overwrite the existing file. (.sfs files, I've found, are more considerate.)

If you want to install a .pet through a shell command, you can use the command petget, followed by either the .pet name (if the .pet is in the current working directory), or a path to the .pet otherwise.

(To find out the current working directory, use the pwd command - short for "print working directory".)

If you're curious about the exact contents of a .pet file, you can make a copy of the .pet, and rename its filename extension to .tar (instead of .pet), which, in many Puppies, will make the file open by default in xarchive.

Then, using the "Extract" button in xarchive, you can decompress/extract the file's contents into a folder.

There are two special Bash** scripts that a .pet can optionally contain, and if they exist, they will be run under the following circumstances:

• If there's a pinstall.sh script in the first folder of the .pet, it will get run after the .pet installs.

• If there's a puninstall.sh script there, it will get run after the .pet is uninstalled.

I don't know if there's a console command that can uninstall a .pet.

The only way I know to uninstall a .pet is through the Puppy Package Manager. You can open that with the console command ppm, or else click the install icon on your desktop and then click the button next to the text Click button to run the Puppy Package Manager.

Then, to uninstall a pet, click on an item in the list of installed .pets, and a dialog will pop up asking if you want to uninstall it.

Warning: Uninstalling a .pet will delete even files that you edited after installing the .pet. (.sfs files, I've found, are more considerate.) Folders installed by the .pet will remain, along with files you yourself added to those folders, but files that were installed by the .pet inside those folders will be deleted.

An .sfs file is another kind of installer file for software which can be used in one or more variants of Puppy Linux**. An .sfs file works quite differently from a .pet.

.sfs files are less intuitive to work with than .pet files, and harder to explain, but, once you learn how to use them, it turns out they too are useful and fairly convenient (except for some glitches you might run into).

.sfs files generally contain compiled executable software rather than source code. That gives you the convenience of not having to compile the software yourself - but, you should be cautious to get .sfs files from trustworthy sources.

As of 4/18/2013, I have never yet heard of malware in an .sfs file or in Puppy at all, but no doubt it's possible. There is such a thing as Linux malware. So, please be careful.

See: Where to Get Puppy Software

For how to load an .sfs file, see: How to Load an .sfs File

The rest of this "What is an .sfs file?" section is skippable, and just tries to answer the question of what .sfs files are, despite me not fully understanding them myself (especially on a technical level). Apologies if I got anything wrong.

SFS is apparently short for SquashFS**, which is short for Squash File System.

If I understand it correctly, Puppy Linux (judging by the page How Puppy works from the official Puppy Linux site) uses something called UnionFS**, which (according to Wikipedia) "allows files and directories of separate file systems, known as branches, to be transparently overlaid, forming a single coherent file system."

So, basically, I guess, UnionFS makes it so Puppy Linux can have different layers of file systems that all appear to be a single file system, even though they aren't. And, if I understand correctly, each .sfs file can be thought of as another layer that you can (theoretically) just add or remove whenever you want.

(In theory, whenever you want, but in actuality, there are sometimes glitches that don't let you unload the .sfs file. Below, I've tried to explain the various glitches I've noticed, as well as fixes I've found, if I've found any.)

So, when you load an .sfs file, the filesystem stored in the .sfs file is made to appear as though it is in your filesystem, even though none of the files within the .sfs are really in your main filesystem. You could say, .sfs files' contents are "in the world, but not of it". :-) And the files from the .sfs can (in theory) easily be removed just by unloading the .sfs file. (In theory, because in practice, there are sometimes those darn glitches.)

In contrast, .pet files really install files into your actual main filesystem layer, rather than doing the .sfs trick of just making files appear to be there while they really exist in a separate layer.

Another difference between .pet files and .sfs files is, I don't think there's any equivalent in an .sfs file for the optional pinstall.sh and puninstall.sh scripts that run when a .pet file is installed and uninstalled.

When .sfs files are loaded using SFS_Load, they are treated as loop devices. This can cause conflicts with other loop devices you might have, such as TrueCrypt** volumes.

There are also various other glitches I've encountered when using .sfs files.

There are apparently multiple ways to load an .sfs file, but, I only have ever used one - a method that doesn't require a reboot. So, that's the only method I'm going to describe here.

This method might not be ideal for your setup, especially if you're using a full installation of Puppy, which I've read handles .sfs files differently than other types of Puppy setups. Anyway, there are different instructions at http://puppylinux.org/wikka/Squashfs which might help. And for people with full installations: How to Add a SFS file to a Full Installation

I'm unaware of console commands that will load or unload .sfs files. There might be some, but I don't know what they are.

The following method involves the program SFS_Load. SFS_Load is included with various Puppies, such as the one I nearly always use, Lucid Puppy 5.2.8 version 004.

1. First of all, you should consider whether or not loading an .sfs is even worth the trouble, given the glitches you might run into.

   Also, since I have a rather unusual Puppy setup and never use a Pupsave file and don't save sessions to a writable multisession live DVD** anymore, I don't know exactly (nor firsthand) what will happen if you use .sfs files in a setup where you do have a Pupsave file, or save sessions to a live CD or DVD, or are using a full installation of Puppy.

   So, please be cautious.

   
   

2. It's probably best to put the .sfs file in a volume (disk or disk partition) where it won't matter if you run into the aggravating glitch where Puppy sometimes won't let you unmount your disk or partition after having loaded an .sfs file (even after you seemingly successfully unloaded your .sfs file later). A disk or partition where you have nothing important would be best.

   It's pointless to copy the .sfs file to the RAM disk, because some other glitch will prevent you from loading it.

   
   If you load the .sfs file while it's on a normal volume (disk or partition), and you run into that aggravating glitch and have to shut down your computer without unmounting your disk or disk partition, then, next time you start up Puppy, you should probably scan that disk or partition for errors before continuing to use it.

   In the sfs-Related Glitches I've Encountered section, I provided some instructions for doing that (at least if your disk or partition is using the ext2, ext3, or ext4 filesystem format) in a box titled Scanning and Repairing Uncleanly Unmounted ext2/ext3/ext4 Volumes with the Dangerous e2fsck Command. However, the instructions are dangerous, so please be careful.

   Continuing on...

   
   

3. Don't try to open the .sfs file by double-clicking on it. (Or single-clicking, depending on how you have Rox-Filer configured.)

   All that will do is mount it read-only in a way that will let you explore its contents, but it won't actually "install" the files, or in other words, won't merge them (virtually) into your existing filesystem.

   If you do accidentally mount the .sfs file the wrong way, wait a while, then double-click it again to unmount it. (The instruction to wait is because it's possible I might have run into the aggravating glitch described below because of trying to unmount an .sfs file too quickly after I just mounted it.)

   
   

4. Instead, right-click the .sfs file, and in the menu that appears, go to File '[name of your .sfs file]' and choose sfs_load from that submenu.

   Then, I'm not even sure what all the options it gives you do exactly, but, I always choose the NOCOPY option from the dropdown, then click OK.

   
   If you have a not-so-recent Puppy, you might not have sfs_load in the menu. To be able to load .sfs files in Lucid Puppy 5.2, I had to download SFS_Load from here on the Puppy Linux Forums, since it wasn't yet built into Lucid Puppy. It worked great, though.

Right-click the .sfs file, and in the menu that appears, go to File '[name of your .sfs file]' and choose sfs_load from that submenu.

Then, when asked if you want to unload the .sfs file, click OK.

I'm unaware of console commands that will load or unload .sfs files. There might be some, but I don't know what they are.

If you're curious about the exact contents of an .sfs file, I recommend first copying the .sfs file to either your RAM disk (if you have room), or a location where it won't matter if you run into the aggravating glitch which makes it so sometimes you can't unmount the disk or partition where you loaded an .sfs (even if you seemingly successfully unloaded the .sfs later).

The RAM disk would be best, or else a disk or partition where you have nothing important.

Then, you can double-click the .sfs file (or single-click, depending on how you have Rox-Filer configured) to mount it read-only in a way that will let you explore its contents, and which won't actually "install" the .sfs, or in other words, won't merge the .sfs file's contents (virtually) into your existing filesystem.

The console command losetup, which does things with loop devices, will show which .sfs files are loaded.

If you happen to use TrueCrypt**, it will also show you what TrueCrypt volumes are mounted.

The worst, most dangerous-seeming glitch I've encountered when using .sfs files is when somehow, despite unloading an .sfs file, Puppy still thinks the volume (the disk or disk partition) the .sfs file was on is somehow in use by the system, and thus Puppy refuses to unmount the disk or partition the .sfs file is on.

It doesn't always happen, but it's aggravating when it does, since I haven't found a solution aside from prevention.

Not sure if it affects just me because I slightly modified the sfs_load script in the Puppy I use, or if this glitch already existed.

In my experience, this glitch might occur in conjunction with a glitch where the .sfs file is supposedly unloaded, but its contents still exist in your filesystem. (Actually, maybe it always happens that way and I just usually didn't notice.)

One time this glitch happened, I think maybe what somehow caused it was, I somehow confused Puppy by double-clicking on an .sfs file and then unmounting it too quickly after that, and/or using sfs_load on it too soon after that. Can't remember exactly what happened, and I'm not sure that's really what caused it.

In any case, I recommend that you avoid loading (and avoid even browsing) .sfs files that reside in a volume (disk or partition) that contains anything important, because if you shut down your computer without unmounting your volume properly, your volume could possibly end up with errors because of the "unclean unmount".

I don't recall ever having had a serious problem so far (like actual errors in my volumes) from this .sfs glitch making me shut down without being able to unmount a volume, but it probably is a danger, so I go out of my way to avoid this glitch, just in case.

I do that by copying any .sfs files I wish to use to a nearly empty hard drive partition which has nothing important on it. (I would prefer copying them to my RAM disk, but I found some other glitch makes it impossible to load .sfs files located in the RAM disk.)

If you did end up having to shut down without being able to unmount your disk or partition, the dangerous instructions in the Scanning and Repairing Uncleanly Unmounted ext2/ext3/ext4 Volumes with the Dangerous e2fsck Command section might help, but, please be careful in case I got anything wrong.

The second worst glitch I've encountered when using .sfs files is also scary, and potentially even dangerous - but, fortunately, as far as I know, it never harmed any of my TrueCrypt** volumes so far. (It probably could under certain circumstances, though.)

Basically, TrueCrypt and .sfs files (which are both treated as loop devices when they're mounted) seem to fight over loop device slots.

(Which is probably an indication that you probably need to be on guard against problems/conflicts between SFS_Load and any software that, similar to TrueCrypt, also uses loop devices. Sorry, I don't know of any other examples.)

If you only ever have less than 4 TrueCrypt volumes mounted at any one time, you might not run into this problem. But once you have 4 or more TrueCrypt volumes loaded, then, when you try to load an .sfs file using SFS_Load, you'll find that your 4th loaded TrueCrypt volume isn't accessible anymore, and TrueCrypt will oddly list your volume's mount directory as something like "pup_ro4" (not sure, just recalling this from memory, and recreating this glitch is too much trouble at the moment). Any .sfs files loaded after that will cause much the same problem with any TrueCrypt volumes beyond the 4th one.

This is frightening, but, as far as I know, it never did any actual harm so far to any of my TrueCrypt volumes. My guess is it probably could be harmful, though, such as if the TrueCrypt volume happens to be being written to at the moment an .sfs hijacks its loop device slot.

Fortunately, I think I found a solution, but I'm uneasy about releasing my very slightly modified version of the sfs_load script, because I'm afraid I might've unknowingly created problems somehow through my reckless quick-and-dirty changes. And besides that, the version of sfs_load I modified is now outdated. So, I'm just including a description of my changes rather than an actual script.

Anyhow, what I did was, I edited the sfs_load script at /usr/sbin/sfs_load to make it so that when it has to choose a loop device number for an .sfs file, it chooses loop device numbers starting at 20 instead of starting at 4.

I've used this solution since March 2012 with seemingly no problems... but sometimes I wonder if maybe I accidentally somehow created the problem above of sometimes being unable to unmount disks/partitions after having loaded (then seemingly successfully unloaded) an .sfs file on them. Not sure if the problem was there already, or if I introduced it.

This once happened to me at the same time as the glitch where you can't unmount a volume containing an .sfs file, even after unloading that .sfs file. Perhaps it always accompanies that other glitch (and I simply didn't notice most of the time).

When this happened to me, SFS_Load didn't think the .sfs file was loaded, and the system seemed not to think was is either, since losetup command didn't list the .sfs as a loop device.

Yet, the contents of the .sfs were still in my filesystem, and Puppy wouldn't let me unmount the partition the .sfs file was in, claiming the partition was in use by the kernel.

• Sometimes an .sfs file might refuse to unload. I've found one solution - restarting X Windows by selecting "Restart X server" in the Shutdown menu. But before you do that, save all your work and close your programs, because choosing "Restart X Server" that will close all of your programs without even asking for confirmation.

  Also, "Restart X Server" is very near the Shutdown and Reboot menu items, which also don't ask for confirmation in Lucid Puppy 5.2.8 and other Puppies.

  Once X Windows restarts, you should hopefully be able to unload the .sfs file.

  
  

• It seems to be impossible to load an .sfs file which is located inside the RAM disk. You can browse inside it, but not load it.

• If you have an .sfs file in a path which contains a space anywhere in the path, you won't be able to browse inside the .sfs file by double-clicking it until you move it to a path with no spaces.

  
  

• If, while you have an .sfs file loaded, you delete a file that was "installed" by that .sfs file, then, that file will stay apparently deleted even if you unload and reload the .sfs. (However, the original .sfs is untouched - the seemingly deleted file still exists in the .sfs.)

  To get the file back, follow these steps:

  • Unload the .sfs file.

  • Put a file of the same name as the file you deleted in the same location as the file you deleted.

  • Delete the file you just put there.

  • Then, load the .sfs file again, and the copy of that file from inside the .sfs should reappear. (You might have to click Rox-Filer's "Rescan directory contents" button - two blue arrows chasing each other in a circle - to make it visible.)

What happens if files already exist where the .sfs intends to put files? The existing files will remain where they are and not be replaced with the files from the .sfs file when the .sfs file is loaded.

What happens if you edit files that were put there by an .sfs file? Doing that doesn't actually alter the contents of the .sfs file, but any edited files will remain where they are after you unload an .sfs file, instead of vanishing as they would have had you not edited them.

What happens if you save a Pupsave file or a session on a multisession Puppy live CD or DVD while you have an .sfs file loaded? I don't know, I haven't tried it, but I feel wary of the idea, and if I had a writable multisession live CD or DVD** or Pupsave file I cared about, I would be reluctant to do that without having tested first to make sure it works safely.

What if you use an .sfs file with a full installation of Puppy? I have no first-hand experience with that, and with that too, would be wary of trying it without testing it first to make sure it works safely.

I've read that .sfs files work differently in full installations, compared to how they work with other ways of running Puppy (frugal installs or a live CD or DVD). This page might help you: How to Add a SFS file to a Full Installation

Simplicity, and not having to be bothered with the glitches you might run into when using .sfs files.

Plus, anything installed with a .pet is fully installed in RAM (unless you have a full installation of Puppy, or a frugal installation which isn't running in RAM), which might or might not be noticeably faster than loading software that resides on a physical disk.

Installing .pet files uses up some of your total "personal storage space" RAM, but, I usually find that preferable to having to put up with the glitches of .sfs files.

Particularly since I have 4 GB of RAM - which is a lot, the maximum most any Puppy Linux can use, except for the few 64-bit Puppies. 4 GB of RAM somehow only gives me 1.6 GB of "personal storage space", but, that's usually more than enough for me.

With .sfs files, I'm not sure if there's an easy built-in way to permanently save the software in them to your Puppy system.

But with a .pet, all you need to do is install the .pet, and it will be permanently available on future reboots of your Puppy if you save your Pupsave file after installing the .pet, or save a new session to your writable multisession Puppy live CD or DVD**, or have a full installation of Puppy.

To save RAM. One nice thing about .sfs files is that you can load large .sfs files even if you have a rather pitiful amount of RAM, thus enabling you to use some great software packages you could never install as a .pet for lack of RAM. Somehow, loading .sfs files doesn't use up "personal storage space" RAM.

Also, uninstalling an .sfs file (unless you run into some of the above glitches) might be overall a cleaner process than uninstalling a .pet, since files "installed" by an .sfs (if I understand it correctly) aren't put in your main filesystem layer, but instead exist in a separate filesystem layer (at least until they get edited - then they get added to your main filesystem layer), and this layer can usually be easily removed (except if you run into some of the above glitches).

Meanwhile, files installed by a .pet are put directly in your main filesystem layer, so, uninstalling a .pet means files have to get deleted from your main filesystem layer. And, as explained in What is a .pet file? - .pet uninstallation is not as considerate as .sfs uninstallation, since .pet uninstallation will remove even files that you edited after they were installed.

For more info about filesystem layers in Puppy, see: How Puppy works, from the official Puppy Linux site.

.pet and .sfs files generally contain compiled executable software rather than source code. That gives you the convenience of not having to compile the software yourself - but, you should be cautious to get .pet files, .sfs files, and other Puppy software from trustworthy sources.

As of 4/18/2013, I have never yet heard of malware in a .pet file, .sfs file, .iso file, or in Puppy Linux at all, but no doubt it's possible. There is such a thing as Linux malware.

So, you should be cautious to only install software that comes from sites you trust, software repositories you trust, or people you trust.

For an even stronger dose of paranoia, see this section of What is free, libre, open source software?

I'm only going to provide some basic tips here, and not try to create a comprehensive list of good places to download Puppy software from.

Even if a site is not listed here, it might very well be a good source of Puppy software.

• An official Puppy download site I often have downloaded from: http://distro.ibiblio.org/puppylinux/

  It has .iso files and DevX files for various different distros of Puppy Linux, as well as many .pet and .sfs files.

  
  

• A page at the official Puppy Linux website which lists various download sites: http://puppylinux.com/download/

  
  

• Probably it's safe to download software from any of the software repositories you can access by clicking the quickpet button on the Puppy desktop, or the install button on the Puppy desktop and then clicking the Puppy Package Manager button.

  However, I personally prefer downloading files from the ibiblio.org link above, because I haven't figured out a way to keep copies of the .pet and .sfs files downloaded through the Puppy Package Manager or Quickpet.

  
  

• At the Puppy Linux Discussion Forums, there are plenty of .pets, .sfs files, etc. which are contributed by members - but since membership is totally open to the public, it would be best to be more cautious about what you download from there.

  I would be more inclined to trust software contributed by well-established members known to the community, who have a lot of posts - though even with them, I prefer to download software whose discussion threads have been around for a while, and the threads have some replies, and no one has mentioned any major problems with the software.

Lots of software is written in a compiled language whose source code must be compiled into machine language before the software can be run. Some examples of compiled languages are C, C++, Vala, and Java (not to be confused with JavaScript). For more, see Wikipedia's List of programming languages by type.

This is in contrast to interpreted languages. Scripts in interpreted languages aren't compiled, but are instead run by an interpreter. Some examples of interpreted languages are PHP**, Perl, **, Python**, and JavaScript (not to be confused with Java). For more, see Wikipedia's List of frequently used interpreted languages.

The below instructions are going to be about to how to compile something in the C programming language, since I've never yet compiled a software package in C++, Vala, or any other compiler that might be available in my Puppy's DevX file.

Also, I'm just going to write about the kind of compiling that involves these commands:

./configure
make
make install

I think that's the most common kind of compiling, but could be wrong. As of 4/18/2013, I still don't know how to compile things any other way, such as using CMake**.

Happily, the below may turn out to be much easier than you might think.

In Puppy Linux**, to be able to compile software from is source code, you'll typically need the DevX file for your Puppy, which you can often download in the same directory where you got the .iso file containing your variant of Puppy Linux.

See: Where to Get Puppy Software

The DevX file is provided in .sfs format, so, when loading it, you should take the precautions you should take with any .sfs file - see How to Load an .sfs File.

When you load the DevX file, all the software development tools provided in it immediately become available to you.

Next, you'll need the source code of some software you want to compile. Search the web for the official website of whatever software it is, and you'll probably find the source code somewhere on that site, like in a Downloads section.

I'm going to compile PHP** 5.4.13. Its source code is available from:

http://php.net/downloads.php

I don't know why they offer it in two different compressed files, but, you only need one.

However, I got both, just because I was writing these instructions and wanted to test some things.

I got php-5.4.13.tar.bz2 (the smaller file), and php-5.4.13.tar.gz.

Source code in general is usually downloadable in a single archive file, such as a .tar.gz file (also known as a tarball), or a .tar.bz2 file (another kind of tarball), or a .zip file (which Windows users might be familiar with).

I like to download source code to a location in my RAM disk, and then extract the files and compile them in the RAM disk, just to avoid making my hard disk work. But, that's optional and unnecessary, and if you have too little RAM, you shouldn't bother with putting the archive file in the RAM disk.

If you do put the archive file in the RAM disk, remember to save a copy of the archive file to a permanent storage medium, if you want to keep it.

First, make sure you have the archive file at a path which doesn't have any spaces in it. (Lots of things in Linux get confused if your path has any spaces in it.)

In Puppy, you can just double-click on a tarball (or .zip, or other archive file) to open it in the archive software XArchive. (Or single-click, depending on your Rox-Filer settings.)

You might have to wait a surprisingly long while for XArchive to load your archive file.

Opening php-5.4.13.tar.bz2, about 12 MB (11,545,777 bytes), located in my RAM disk, took 1 minute and 13 seconds on my computer. 3.4 GHz dual core processor and 4 GB of RAM, and it does most things in Puppy much faster than that. So, I think XArchive is just unusually slow at loading files.)

Opening php-5.4.13.tar.gz, about 14 MB (14,596,605 bytes), took 1 minute and 11 seconds in my RAM disk, and only about a second longer on my hard disk, so, not much difference.

Once XArchive has loaded your archive file, don't click any of the files listed.

Just click the Extract button, and put in a folder path where you want the contents of the archive file to be extracted to. The folder path doesn't have to exist already - XArchive can create it for you. Use a path which has no spaces, because spaces in paths confuse many things in Linux.

Fortunately, XArchive is pretty fast at extracting/decompressing files - it literally took about 3 seconds to decompress the .tar.gz file in my RAM disk. The decompressed files were around 136 MB (135,602,176 bytes).

On my hard disk, decompressing the .tar.gz file was surprisingly only a bit slower - about 4 seconds.

Open the now-decompressed folder of source code. Frequently, there will be a README file and/or an INSTALL file - which are usually plain text files you can just double-click on to open in your Puppy's default text editor (which is probably Geany**).

The documentation included with the software you intend to compile will probably tell you important, useful things that I can't possibly know or write about here (unless you're compiling PHP 5.4.13, as I am as I write these instructions.)

The included documentation might not all be important, and plenty might be skippable. However, it very likely could be useful to follow at least some (and quite possibly all) of the instructions in those files, and if the instructions I'm giving you conflict with those instructions, you should probably favor the instructions in those files.

The PHP 5.4.13 Readmes look irrelevant for my purposes, and the INSTALL text file is very long and full of stuff that looks mostly useless to me at the moment.

I found when I was compiling 5.2.17 for Astroblahhh GLMP-GTK and Astroblahhh PH-GTK that I was able to get by pretty well just ignoring most of that text, and it looks like the same situation with PHP 5.4.13.

Follow the instructions here: How to Open a Console Window Which Uses the Folder You're In as the Working Directory

The next steps might or might not be ridiculously easy.

If you want to understand ./configure and the rest of the installation process in greater depth, see: Understanding software Installation (configure, make, make install), from CodeCoffee.com

With many software packages, all you have to do is type:

./configure

...and that's all you have to do for this step. If I recall correctly, that may have been all that was necessary to configure MariaDB** and FreeType** when I was making Astroblahhh GLMP-GTK.

But with other software packages, there might be ways you want to customize things. PHP, for example, gives you quite a few different options, most of which I don't even fully understand what they do.

With PHP, you can type this to get a big list of options:

./configure --help

And you can build big, long command lines like this (the one I used to build PHP 5.2.17 for Astroblahhh GLMP-GTK and Astroblahhh PH-GTK):

./configure --with-readline --enable-zip --enable-mbstring --enable-fastcgi --with-mysql=/usr/local --with-mysqli=/usr/local/bin/mysql_config --with-pdo-mysql=/usr/local --enable-ftp --with-gd --with-ttf --enable-gd-native-ttf --with-freetype-dir=/usr/local/lib/

(That exact command line, however, won't work unless you've already installed MariaDB** and FreeType**. For more info about the above command line, see the Astroblahhh GLMP-GTK Readme.)

While I was trying to figure out how to make the above command line, ./configure often complained about various little problems and halted before completion, until I finally got everything right, then it all went smoothly.

Lots of mostly meaningless (to me) text scrolled by, finally concluding with (among other things) "Thank you for using PHP." So, I could finally go on to the next step.

Running the plain ./configure command with no additional options in the PHP 5.4.13 source code folder in my RAM disk, the configuring took about 40 seconds.

Doing the same thing in the PHP 5.4.13 source code folder on my hard drive, the configuring took about the same amount of time, about 40 seconds.

If you want a very basic, scarcely-customized PHP whose only special feature is the PHP interactive shell, which is similar to the interactive shell in Python** or J**, you can use this command:

./configure --with-readline

That should give you an easy way to tell if PHP is really working. After compiling and installing, you'll be able to use this command to start the PHP interactive shell:

php -a

(We haven't reached the point where that command will work, yet.)

Here's that nice article again: Understanding software Installation (configure, make, make install), from CodeCoffee.com

This is one of the easiest steps. Just type:

make

If I recall correctly, that's all I ever had to do for this step.

make is the command that actually does the compiling and makes executables out of the source code. It can take a while, or it can be pretty quick, depending on how much source code there is.

Running make on PHP 5.4.13's source code in my RAM disk took 4 minutes and 38 seconds.

The same for PHP 5.4.13 on my hard disk took significantly longer - 5 minutes and 48 seconds.

After you successfully run make, you might get a suggestion to run the command make test - but, so far, I've never seen how that could be useful to me. There probably is a use for it, but, I believe you can skip that if you want.

If you run make more than once (such as because you're trying different ./configure options, or you edited something in the source code), the make command might take much less time to complete - I guess because make doesn't bother to rebuild everything if it sees compiled executables already exist.

But, that can sometimes cause problems, and I guess that's why the make clean command exists - make clean deletes previously-generated executables.

After running make clean, the make command will be slow(er) again, since it's recompiling everything.

Here's that nice article again: Understanding software Installation (configure, make, make install), from CodeCoffee.com

Another of the easiest steps. However, you should first make sure you really want to clutter up your system with newly-installed software. (Actually, though, Linux already seems hopelessly cluttered already, regardless...) I don't yet know of an easy way to reverse the process and uninstall everything.

make install is the command that puts the executables compiled in the previous step (by the make command) into their proper places in your Puppy system.

If you're OK with that, simply type:

make install

That might be the last step. But, with some software, there might be additional configuration, etc. you might have to do before things will work right.

In the specific case of PHP, there are these additional steps:

• You must make a copy of either php.ini-development or php.ini-production (which you can find in the PHP source code folder), rename it to php.ini, edit it as you wish, and put it in /usr/local/lib/php.

  
  

• If you want to use PHP with the Hiawatha** web server (which is built into many Puppies), you need to edit Hiawatha's configuration file at /etc/hiawatha/hiawatha.conf.

  You'll need to add a line like this:

  CGIhandler=/usr/local/bin/php-cgi:php

  
  

• Maybe some other steps I'm forgetting.

Astroblahhh GLMP-GTK and Astroblahhh PH-GTK conveniently take care of those (and other) annoying things automatically.

If, before compiling PHP, you used the --with-readline option for ./configure, you should now be able to start the PHP interactive shell using this console command:

php -a

Happily, this is also quite easy. The process is almost exactly the same for either a .pet file or an .sfs file, up until the last few steps.

1. First, follow the instructions in How to Compile Software from Source Code. But, skip the make install step, and come back to this section.

At this point, you should have some compiled software sitting a source code folder, which you've never run the make install command on.

2. Open the folder that contains your source code folder (not the source code folder itself).

3. Give the source code folder a clear, descriptive name that you want your .pet file or .sfs file to have. (No need to end the folder name with ".pet" or ".sfs".) Use no spaces, and make sure there are no spaces in its entire path, either, because spaces in paths confuse many things in Linux. Also, after the name, put a dash followed by a version number. (That's required by the console command new2dir we're soon going to run.)

4. Open your source code folder, and follow the instructions here: How to Open a Console Window Which Uses the Folder You're In as the Working Directory

You might be wondering, how are you supposed to get rid of all the clutter in the source code folder and only include the essentials (the compiled executables) in your .pet or .sfs file?

The answer is - the new2dir make install command. (But don't type it yet.)

The new2dir command makes it so the files that the make install command installs in various places throughout your Puppy system also get copied to locations inside a single directory.

The reason running plain make install before would have been a mistake is because it might have confused the new2dir make install command into copying only some, but not all, of the files that make install tries to install. I think that's because make install probably pays attention to what files are already installed, so if it sees those files already at locations in your Puppy system, it doesn't bother trying to reinstall them - so you wind up with an incomplete new2dir-made directory.

Another thing that can be problematic is, the new2dir make install command allows the files to be installed in your Puppy system as well. So, repeating the new2dir make install command has the same problem as running plain make install before running new2dir make install.

So, that means if you're trying to build a .pet or .sfs, and find you need to change something and recompile, you might have to do that with a fresh Puppy system which hasn't ever had that software installed in it before - otherwise new2dir make install might not capture all the files you need. Or, it might. I think it might depend on the software.

PHP 5.2.17 and PHP 5.4.13 definitely end up missing some important stuff in the new2dir-created folder, if you run new2dir make install more than once, or ever ran make install before new2dir make install.

5. Warning: An odd thing about the new2dir make install command is that, even when running it on a directory inside my RAM disk, for some reason it somehow makes my hard disk (which I keep in an external enclosure which I connect to my computer via a USB cord) very busy.

   Almost the entire time the new2dir make install runs, my hard disk makes a lot more noise than usual, rhythmic, every second or so. (Maybe it's somehow related to the fact that my hard disk is where I have my DevX file.)

   So, if you have a hard disk in an external enclosure (like me), and don't want it being pestered for no good reason, you might want to unmount it and turn it off while running the new2dir make install command.

   I'm not sure if it does that to every hard disk (or every disk?), or just the one with my DevX file on it, but I don't really want to turn on another enclosure hard drive to test this. Maybe if I had a hard disk with nothing important on it, I would. Also, another idea that comes to mind is copying my DevX file to one of my USB Flash drives, but if new2dir is for some reason doing writes of some sort instead of just noisy reads, I don't want to wear out my Flash drive, so, not going to test that either.

   I tested this on a different computer (my old computer) with an internal hard drive and the loaded DevX file on it, and the same problem happened.

   
   

6. Type this console command:

   new2dir make install

   Then, follow the instructions the new2dir command will give you.

   When new2dir is nearly finished running, it will ask you if you want to run the dir2pet script (which will create a .pet). You can if you want - and in that case, you'll have only one last step to follow, because after following dir2pet's instructions, your .pet file will be made and ready to use.

   But, if you want to create an .sfs file, or want to add more files to your .pet or .sfs, and/or want to add a pinstall.sh script and/or puninstall.sh script (see What is a .pet file? for more info about those) - there are more steps, and you should tell new2dir not to run dir2pet.

The following steps and are only necessary if you wish to add more files to your .pet or .sfs, and/or want to add a pinstall.sh script and/or puninstall.sh script. (See What is a .pet file? for more info about those. Those are only useful in .pet files - I know of no equivalent in .sfs files.)

7. If you want your .pet or .sfs to install more than one software package, follow the preceding steps for each one.

Once you do that, you'll have a variety of directories (one for each software package you compiled) produced by new2dir make install.

8. Create a new folder. Give it a clear, descriptive name that you want your .pet or .sfs to have. (No need to end the folder name with ".pet" or ".sfs".) Use no spaces, and make sure there are no spaces in its entire path, either, because spaces in paths confuse many things in Linux. Also, after the name, put a dash followed by a version number.

   
   

9. Now, you need to combine all the folders created by new2dir make install into your new .pet folder or .sfs folder. Open each new2dir folder and copy their contents to your new .pet folder or .sfs folder, but don't overwrite folders that exist in multiple new2dir folders, just combine everything.

You can regard the top level of your .pet folder or .sfs folder as equivalent to the / folder in your Puppy system. Once your .pet folder or .sfs folder is turned into an actual .pet or .sfs - then, when your .pet file is run, or your .sfs file is loaded, files inside (for example) the path [whatever your .pet/.sfs folder's path and folder name are]/usr/ will be installed inside /usr/ in your Puppy system.

So, using a .pet file or .sfs file, you can put files anywhere you want in your Puppy system. If you're making a .pet - be cautious not to add files to your .pet folder at locations that would cause your .pet to overwrite files in your Puppy system that you don't wish to overwrite.

.sfs files seem not to have that problem - if a file already exists at a location where the .sfs file wants to put something, the existing file should be left alone. However, judging by all the .sfs-related glitches I've encountered, you might want to be cautious with .sfs files too.

10. Optionally, if you're making a .pet file - you can put a pinstall.sh script and/or puninstall.sh script (see What is a .pet file? for more info about those) at the top level of your .pet folder. (Again, those are only useful in .pet files - I know of no equivalent in .sfs files.)

11. Also optionally - you can add whatever other files or folders you want.

Once you have all the files and folders you want inside your .pet folder - it's time to make the .pet file or .sfs file.

12. Open the folder that contains your .pet folder, and follow the instructions here: How to Open a Console Window Which Uses the Folder You're In as the Working Directory

13. Type this console command:

    dir2pet [name of your .pet folder]

    Then, follow the instructions dir2pet will give you.

At this point, your .pet file is hopefully created! There is just one more important step.

14. Test your .pet file to make sure it's working properly. If things aren't working, you might have gotten mixed up about where you were putting certain directories or files, causing some folders and files to accidentally get installed to the wrong places in your Puppy system.

    You should also check to make sure your (optional) pinstall.sh or puninstall.sh scripts are really working. (See What is a .pet file? for more info about those.)

13. Type this console command:

    mksquashfs [name of your .sfs folder] [whatever name you want the .sfs file to have].sfs -noappend

That's even easier than making a .pet file - the command will simply execute with no further input required.

At this point, your .sfs file is hopefully created! There is just one more important step.

14. Test your .sfs file to make sure it's working properly - but, of course, use the precautions you would use when loading any .sfs file. (See How to Load an .sfs File.)

    If things aren't working, you might have gotten mixed up about where you were putting certain directories or files, causing some folders and files to accidentally get installed to the wrong places in your Puppy system.

Activism | Astrology | Astronomy | Blog | Credit Card Boycott | Firefox Add-Ons | GNU/Linux | How To Guides | Ideas | Languages | Music | Opinions | Pictures | Second Life | Self-Help | Software | Windows

About This Site | Contact Apollia | Disclaimer | Updates

Eryss.Com - Non24.Com

Eryss.Com Forum - Non24.Com Forum

Donations | Services (none available currently)

Request Free/Libre/Open Source Software or Documentation, or Ask Programming Questions (but only if you're very patient)

Or, Donate In Second Life

GitHub