Setting up multiple users in Puppy

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

Setting up multiple users in Puppy

#1 Post by Nathan F »

Multiple users is a topic that comes up on a fairly regular basis on this forum. I've talked about it before, as have quite a few others. I recently made the faux pax of suggesting we might include some support for non-root usage in the community edition of Puppy and my remarks set of a volly of criticism fromcertain individuals, which I did not expect. I'd rather not hijack the thread for an argument I didn't want to have anyway so I'm starting this thread to be a central place for the discussion of how to get a multi-user setup running in Puppy, what constitutes a working setup, and what pitfalls may occur along the way.

I have to make a couple disclaimers here -
  • * It has been suggested that I fork Puppy and produce a multi-user build along with other members of the community who are keen on it. This I will NOT do. I just plain have too many projects to support already. I will support multi-user functionality in Grafpup, and I am willing to share the work that I have done with anyone who wants to duplicate it or create something similar.

    * The methods I am using are in some cases experimental, and are definately not for a new user to try and set up. While I have security in mind there is even a chance that occasionally one of my changes might make a system less secure than if it were running solely as root, although I doubt that is actually the case.

    * Encrypted save files are not the same thing as a multiple user system. They are a fantastic feature and can offer some of the functionality, but a true multiple user setup is a completely different animal.

    * I will not respond to criticism of the nature that Puppy does not need multi-user support, or suggesting that this project is not worthwhile. Don't bother, I think there are enough people who want to see a multi-user Puppy system, and I will work to have your comments removed from this thread if you troll here. I'm not here to debate it, I'm here to assist others in implementing it if they want to try.
Going along with my last disclaimer I don't even intend to make a case for why a person would want multiple user accounts in Puppy. You probably know if you do already. If you don't, that is also fine with me.

For now I will describe a rough overview of the changes that need to be made (if you are following my methods) to get a setup off the ground. I will provide more details as the thread progresses, and probably a good deal of code. There is a chance I may offer runnable packages or patches against Puppy, but I make no gaurantee to that effect.

The main things preventing Puppy from being truly multi-user are :
  • * Most Puppy configuration and startup scripts reference or create files in /root or /etc rather than in $HOME.
    * The directory /tmp is not writable by anyone other than root.
    * Certain dev files also have restrictive permissions.
    * The X server must be suid root to run X with another user.
    * Tinylogin must be suid root to allow normal user to use su.
The most blatently root-centric script in Puppy is xwin, which constantly makes the assumption that you are root when you run it. Quite often in the script it creates files in /root or in /etc, which would normally be in $HOME. Going along with that .xinitrc must also be altered to reference files in $HOME rather than in /etc or in /root. Otehrwise not only will another user not have permission to run the X server, but there will be only one system configuration for things like the desktop icons, background, and windowmanager and all users will be locked into the system defaults.

A quick example would be the setting for which WindowManager to start:

Code: Select all

CURRENTWM=`cat /etc/windowmanager`
This is in .xinitrc. The file /etc/windowmanager is created by xwin and overwritten every time you call xwin using an argument, ie 'xwin icewm' write 'icewm' to /etc/windowmanager. If you are not root obviously you won't have permission to do so. So we would change this snippet in xwin:

Code: Select all

#0.9.9 enables to start a specific w.m. from commandline...
if [ $1 ];then
 echo -n "$1" > /etc/windowmanager
 #note, $HOME/.xinitrc uses this file.
fi
Something more appropriate would be this:

Code: Select all

#0.9.9 enables to start a specific w.m. from commandline...
if [ $1 ];then
 echo -n "$1" > $HOME/.config/windowmanager
 #note, $HOME/.xinitrc uses this file.
fi
Then .xinitrc must be changed to reference $HOME/.config/windowmanager rather than the file in /etc. However, this type of issue comes up over and over again in these two files. I will provide a modified script sometime soon, when I have debugged a bit better. Currently I can run Xorg no problem using my modified xwin and .xinitrc but Xvesa is still a problem, because the video wizard also has issues.

Files in /dev that I know for sure have whacky permissions are /dev/null /dev/dsp /dev/zero and /dev/ptymx. You have to change permissions on just about all of the /dev/pty* and /dev/tty* files to allow a normal user to run an x-terminal, the most important being /dev/ptymx.

The directory /tmp must have permissions set to 777, because all system users must be able to read as well as write in /tmp. Some programs will just plain refuse to start if they cannot access /tmp. This is not a security risk really, because nothing that important goes in there and you still won't be able to modify or delete files created in /tmp by another user.

To burn cd or dvd rom media as a user other than root cdrecord has to be suid root in Puppy. This is a known security risk and I recommend against doing it, but if you must get burning working for everybody this is how it can be done. Several distros have patched cdrtools to get around this, but I'm not all that knowledgable how to do it.

To run X as a normal user it must be suid root. There is no way around this that I know of and Puppy is one of the only distros that do not have Xorg suid root.

Doing this to tinylogin is a matter of preference though. You may not actually want another user to be able to use su. Personally I don't see a lot of harm in it.

Properly setting up sudo on a system can make administration much easier, and provides a good way to allow normal users access to functions they would normally be denied. For instance I have hacked pmount to allow a normal user to load the usb storage module using sudo, and run a script which has been carefully set up to add an entry to fstab for a pendrive, so it may be mounted with write permissions for that user. These things must be done carefully, however, or gaping security holes can be opened up in a system.

It is not a bad idea to change a couple things in /etc/fstab, either, to allow users to mount cd or dvd drives. This is done with the 'users' flag in the mount options.
[/code]/dev/cdrom /mnt/cdrom iso9660 noauto,users 0 0

Code: Select all


In addition, the command line tools for working with users in Puppy are primitive. I have added to my system the real useradd binary, because Puppy's adduser is a link to tinylogin and does not create a user correctly. Deleting users is also a proble but I haven't crossed that bridge yet.

That's enough for now I guess. Like I said I will provide some more specifics shortly, and probably some actual modified scripts. I hope to get a good healthy discussion started here and hopefully help some people who have been wanting to try this for a while. I have been developing a selection of gui tools for user administration, specifically for Puppy and derivatives, as well as systematically hacking a lot of scripts to work more generally, all of which I intend to share to interested parties.

Nathan
Bring on the locusts ...

gamfa
Posts: 113
Joined: Thu 27 Oct 2005, 00:29
Location: So. Central Indiana, USA

#2 Post by gamfa »

Well...I'm for you Bud. Ever since I saw a mention that you were working on this I have been watching your site for info on it. I am strictly a HD user and the fact of running as root all the time is what has kept me from using puppy as my full time desktop. I have spent too many years having "NEVER NEVER run as Root" beat into my head. I'm just not comfortable doing it full time.
"Don't tell my cattle that I have leather seats in my truck"

"I don't let my schooling get in the way of my education"...Mark Twain

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#3 Post by rarsa »

Excelent introduction to your ideas Nathan.

Here are a couple of pointers:

Some time ago I asked Barry -and he obliged- to include the Desktop base directory standard Environment variables.

Part of the intention was to start setting the stage for writing well behaved applications that look in the custom places for configuration and data files instead of hard coded paths.

I think that it wouldn't be too dificult to create a bash script with a function to return the actuall path for the file by just giving the Environment variable and file name.

e.g. getfullpath "myfile.conf" CONFIG

Would search for the file first in $XDG_CONFIG_HOME and if not found, search in each of the paths specified under $XDG_CONFIG_DIRS.

I assume there is an standard way of logging in a user as most every distro does it, so How are they doing it?
[url]http://rarsa.blogspot.com[/url] Covering my eclectic thoughts
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#4 Post by Lobster »

Running from CD and finishing session gives the option to save. When I boot Puppy I have two potential configurations (not the same us mult-user) but did the 2.14 script also give me a password option? Someone might have suggested that . . . and I got a little confused . . . :oops:

With a password protection and an option to encrypted the .sfs file some of the important functions of multi user would be there? You will still be running as root BUT only on your configuration . . .

Maybe I don't understand the situation clearly and why MU (Mult User) needs to be available without admin / su capacity

I don't require multi user but for those sharing a machine or confidentail info on a laptop, the option would be a wonderful enhancement.

Good luck Nathan. :D
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#5 Post by Nathan F »

Multi-user support is just about at the kernel level in *nix. User data is stored in several files in /etc, passwd, group, and shadow (which holds the passwords in encrypted form). The OS is smart enough to be able to set some variables without doing an 'export HOME={path]' like you have to do with the xdg directories or path, etc. Just try this:

Code: Select all

echo $HOME
It will always return the path to your home directory, no matter what user you are runing as.

As for a standard method of logging in, there is and there isn't. As in most things *nix there are various small utilities, with one of the most important being /sbin/login, which in our case is replaced with a symlink to tinylogin. Most Linux systems use runlevels and are capable of booting into text mode or graphical mode, Puppy again being an exception, which makes it's boot process simpler. This is not a big deal here. The basic configuration for each runlevel is set in /etc/inittab, which usually uses a program such as getty or mingetty (there are other varients) to get an interactive console. If nothing else is specified in inittab, these programs will run by default /sbin/login, which is in charge of authenticating and logging in a user. Most distros now defrault to runlevel 5, which traditionally is set up to get a console and then immediately run a graphical login manager. These vary but the older and slimmer ones are all but unused these days in favor of kdm or gdm, parts of KDE and Gnome respectively. A few oddballs like Vector use wdm, which is based on WindowMaker libraries and is a good deal more efficient. More on this later.

In Puppy's case we have no runlevels and a very simple inittab. There are just two virtual consoles (tty1 and tty2), and since no runlevels are specified we default to using tty1. In Puppy's inittab Barry has this set up to run the program 'autologinroot', and because of the way getty is working it runs continuously so if you log root out getty will immediately run autologinroot again.

When a user logs in, in order to set the environment up the file /etc/profile is sourced. This is where variables like $PATH or $XDG_DATA_DIRS are set. Other things can be set here as well, such as the shell prompt, default shell (yes, there is more than just Bash), etc. Since this reads as a shell script, programs can also be run in it. For example, in Slackware (and a lot of traditional Unix systems) the program fortune is run on login, giving you one of several thousand fortunes stored on the machine, many of which are just small bits of comedy. Not really useful but it broke up the boredom of an empty console prompt. In Puppy, Barry has devised a method to determine if this is the first login since bootup and if so, it automatically runs xwin. So this is how we are able to go straight into the desktop when the boot process completes.

This is all of course simplified, but it gives a general idea what normally happens when a Linux machine boots, and what some of the differences are in Puppy.

Can some of this behavior be changed? Absolutely. In the simplest multi-user setup You would leave the inittab and profile files alone and just switch over to tty2 when you wanted to log in as someone else (using alt+F2 at the prompt), once you made it possible for another user to run X that is. But by removing the call to autologinroot in inittab, you can have the machine default to a text mode login prompt. I've gone a step further in my experimentation and replaced autologinroot with a call to a graphical login manager on my machine. So far I have used slim (Simple Login Manager), wdm, and kdm successfully in Puppy, although not very successfully with Xvesa so far because Xvesa must be run with all options specified at the prompt. So when my hard drive install boots up it presents with a simple graphical login now.

There are of course issues with doing this as well. The call to xorgwizard upon first boot happens in the xwin script, along with several other basic initializations, so creating a live cd based on Puppy which goes straight to a login prompt rather than a root desktop requires some extensive modification. It is easier to leave the default behavior alone on first boot, and then change over to a different configuration for subsequent boots if desired.

I have also created a compromise configuration which will probably debut with the next Grafpup snapshot. In this configuration, root is automatically logged in but the immediately runs the command to start the login manager rather than xwin, at least on the first login of a session. So you get a graphical login, but if something goes wrong it will dump you back to a root shell. My kids don't know how to escape from X by using Alt|Ctrl|Backspace yet so this in itself is secure enough for use in my home, for the time being.

The thing is that there is no limit to the different configurations that could be run on Puppy. What I would like to do is help some other users achieve whatever it is they deem the best way to get users logged in, because I don't really think there is one right or wrong way to do it, really. I'm not a security fanatic, mind you, but I do have reasons why I don't want a root desktop coming up automatically at every boot.

One interesting story. When Flash 9 first came out one of my daughter's favorite game sites immediately upgraded all of their software so that it required the newer version. She was using the computer and requested that I install it, so I did. The next day I was still trying to figure out why all of my Mozilla browsers were crashing all the time. Then I figured out that it was the flash plugin, so I removed it. Less than two hours later, after we let her use the computer again, none of the browsers were working anymore. She took it upon herself to install the flashplayer again. I'd rather not have a situation where my ten year old kid is able to make global changes like this to my computer and break an installation for the rest of us.

I don't want to debate the merits of a multi-user system here but I will point out that this is one of the fundamental strengths of *nix over Windows. If there ever was a really potentially bad piece of malware written that attacks Linux or Unix, it would be stopped dead in it's tracks inside the home directory of the user who acquired it. No other user would be affected, and it could be very easily cleaned up. This just isn't the case in Windows, not even in NT, not even in Vista. Unfortunately it also isn't the case if you are running as root, ie in Puppy. We get by because nobody has tried an attack yet, mainly because a general attack on Linux would fail. But a general attack directed at Puppy could be devastating, were ever one launched, just the same way attacks against Windows computers can be devastating. In our case it would be so completely unexpected I think it would hurt more.

Nathan
Bring on the locusts ...

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#6 Post by John Doe »

Nathan F wrote:As for a standard method of logging in, there is and there isn't. As in most things *nix there are various small utilities, with one of the most important being /sbin/login, which in our case is replaced with a symlink to tinylogin
Seems the current default root login behaviour could co-exist with a multiuser login by simply doing something like this:

1-Replace the /sbin/login symlink with a shell script.
2-Add /sbin/login.bin (original login binary)
3-Put something like this in the new login script:

(paraphrased logic)

#call tinylogin with blank root pass
if [ exec tinylogin == fails ]
#if tinylogin fails, root has a password. the other login is called
/sgin/login.bin
fi

jimhap
Posts: 63
Joined: Sat 03 Mar 2007, 16:51
Contact:

#7 Post by jimhap »

Nathan, I think you should redo the puppy to make it multi-user build. Why?

You may be right about one thing, that hackers don't want to hack Linux, since it's impossible. BUT however, if you want to know a story my friend told me, here it is:
(just facts, NOT really a story)

My friend told me that because he works @ NASA, he has non-root access to a MAC OS X terminal by SSH. His co worker told him that in the log file, HACKERS tried every single Windows/Linux way to hack in! Every hour, 10 attempts.... :x

------------------------
Hear that? It is true! And it scares me! Hackers just are hungry to hack a computer for some reason...... :?

And worse, if any hacker tried to hack puppyOS, it would be VERY easy!!!!
And furthermore, they even can delete besides my pup save files, my whole HD!!!! :x

So if you can or anyone can please make a multiuser build?

And about typing

Code: Select all

echo $HOME
It doesn't show /root in my puppy.
It shows:
sh-3.1# login jimhap
Password:
warning: cannot change to home directory
# echo $HOME
/home/jimhap
#
And even going back to bash 3.0, it still does:
(and proof)
sh-3.00# login jimhap
Password:
warning: cannot change to home directory
# echo $HOME
/home/jimhap
# bash --version
GNU bash, version 3.00.16(1)-release (i486-t2-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
#
Maybe Puppy has some multi user support.....[/quote]

User avatar
Gekko
Posts: 443
Joined: Sat 22 Jul 2006, 09:57
Location: Sydney, New South Wales

#8 Post by Gekko »

Try mkdir /home/jimhap?

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#9 Post by Nathan F »

Code: Select all

sh-3.1# login jimhap 
This logs in jimhap, so then doing "echo $HOME" reports jimhap's home rather than root's home. Also, the home directory for user "jimhap" does not seem to exist.

I'm glad to hear there are a few people interested in multi-user support. However, I'm not ready to commit time to yet another project right now. I would be more than willing to answer questions about how to do it yourself, and share the work I have done so far. But I can't maintain and support what would end up being another fork of Puppy and a distribution in it's own right. Now, if enough people were willing to put in some sweat equity a community project could be formed around the idea.

Nathan
Bring on the locusts ...

jimhap
Posts: 63
Joined: Sat 03 Mar 2007, 16:51
Contact:

#10 Post by jimhap »

Maybe someone can.......
I'm not a Linux amateur at all, just a beginner, although I do know some commands.

If there was a hacking, maybe more people will contribute.....

After all, hackers crave for access to a computer.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#11 Post by Dougal »

Nathan made a nice list to start with, but I don't recall he mentioned how hard it will be do do each thing...

I think modifying the various scripts will be trivial.
Also /tmp being 777: /tmp is just created in the init script and chmod-ed (arbitrarily?) to 777...

The only thing that might be a little hard will be if we need to do some rewriting.


I think I might have found a solution to the problem with the xorgwizard:
I don't really know how Xorg runs with users, but from digging into iso's it seems like there's only the one xorg.conf and /etc/X11/Xsession is the equivalent of our xinitrc (and gets config options from $HOME/.xsession and $HOME/.Xsession).

Since in "first boot" we want Puppy to behave as before (=run as root), the xorgwizard can be run as it is now. Only root can modify (i.e. delete) xorg.conf , so we don't need to worry about the xorgwizard.

I don't know exactly where the user can specify personal Xorg settings (like screen resolution), but what we can do is have a "tweak xorg" wizard, that will enable them to set those settings. (so the xorgwizard will not be available for normal users)

The only other time the xorgwizard will run is when changing HW -- but that is something only root should do (and is not likely to be frequent on multi-user machines).

(there's another, somewhat primitive, way to personalize Xorg: each user will have xorg.conf copied to, say, $HOME/.etc/X11/ and will be able to modify it. Then, whenever xwin runs, it can link /etc/X11/xorg.conf to it)
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

jimhap
Posts: 63
Joined: Sat 03 Mar 2007, 16:51
Contact:

#12 Post by jimhap »

Now that's an idea to start with. As Nathan said, this can form into a project.
Soon if I fell ready I will sticky another topic for multi-user support. :D
ALOS Software
[url=http://www.alossoft.com/forum/]FORUMS[/url]

Now developing:

CoolPup
v1.0.0 BETA

Click [url=http://www.murga-linux.com/puppy/viewtopic.php?t=17682]here[/url].....

ted142
Posts: 10
Joined: Sat 19 Aug 2006, 02:07
Location: State of Liberty

User Specific Applications

#13 Post by ted142 »

I've had the same musings and in a way miss the impenetrable shield of my 1.07 CD days. The first time I explored "naughty" sites was with puppy (by naughty think what you want but it usu involved visiting very "mc" looking message boards "not-necessarily-porn" ) Anyway. After reading this thread I thought about web 2.0 applications, thin clients, virtualization. I see a group of people both raving how open and moldable *nix OS and apps are and yet discussing how puppy needs to change entirely or at least in several delicate places which may have to be redone with any future upgrades.

What if the ftp client, web browser, chat client--ie the "reach out" applications could be re written or wrapped in code which isolates that application or forces that application to act "as if" it was limited--meaning no on-the-fly installations outside of the bubble so to speak. Kinda like running a Xen instance of a browser where Xen usually redirects hardware and accesses (as does vmware) the instance is authorized to--giving it a place to save, to run, to be free--all within a bubble. Puppy would still act as Puppy--outside of the bubbled applications. You could chose to run the application outside of the bubble (perhaps passworded--defaulting to bubbled)

This would include my man's daughter's flash plug-in dilemma where (assuming flash worked) he could allow her browser instance to contain such code and the rest of the family doesn't have to deal with it. Because the browser bubble forces her to log in to go out on the web--she is automatically operating inside the bubble--safe to download mp3's and other trojan/virus laden crap (it is coming--most of the worlds computers are not running XP and creating "creative code" for BSD, web-enabled cellphones, playstations is just a step away from *nix these days).

The most useful part of not running as root in most of our cases seems to surf safely and try out some code from time to time. I'm an integration specialist not a coder but couldn't something like an quemu, or other emulator be written/adapted to allow such control measures? If so this could probably be put as a pet package like wine would be. Xen works at the kernel level for the most part but could seamonkey be "xenified"? Any thoughts? I wouldn't be suprised if I just suggested walking straight up a cliff with regard to coding, but that's where inexperience comes in.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#14 Post by Nathan F »

Interesting, but really I think in the big picture it is both easier and better to support multiple users on the system. For things like plugins they can easily install into the users home directory. Actually, on my box I have a lot of software installed just into my home, whether it might be Windows apps running in wine or things I compiled with "--prefix=/home/nathan". A lot of applications with Linux installers will automatically install into $HOME if you are not root, actually.

The thing is that workarounds are just that. I would choose to dig in and fix a system's inherent flaws 100% of the time rather than to just patch them or find ways around them. I can use Windows as a good analogy. Security in Windows is in the form of add on layers that try to fix a flawed basic design. It cannot ever be as secure as Linux or Unix because it was not designed and concieved to be. A virus or piece of spyware written for Linux could completely screw up your user account, but unless you executed it as root it would stop right there every time. That is the real reason nobody writes malware for *nix in the real world, not because of the fact that Windows has the market share (as a lot of trolls will claim).

Unfortunately as of right now none of that applies to Puppy. I'm not a paranoid idiot however. Probably the situation can continue for a while longer without any problems. At the same time though, our forums and wiki are already tempting targets for a lot of lowlife internet scum. I wonder how long it will be before they look at the os itself and do the math.

OK, lecture mode over now. I just realized I did something I said I wouldn't do, that is I debated the merits of a multi-user system.

Nathan
Bring on the locusts ...

amish
Posts: 615
Joined: Sun 24 Sep 2006, 23:15

#15 Post by amish »

What if the ftp client, web browser, chat client--ie the "reach out" applications could be re written or wrapped in code which isolates that application or forces that application to act "as if" it was limited--meaning no on-the-fly installations outside of the bubble so to speak. Kinda like running a Xen instance of a browser where Xen usually redirects hardware and accesses (as does vmware) the instance is authorized to--giving it a place to save, to run, to be free--all within a bubble. Puppy would still act as Puppy--outside of the bubbled applications.
puppy has had exactly that for some time. search the forum for: howto spot
The most useful part of not running as root in most of our cases seems to surf safely and try out some code from time to time. I'm an integration specialist not a coder but couldn't something like an quemu, or other emulator bewritten/adapted to allow such control measures?
you could try running qemu (available as .pup) as spot, but it probably makes more sense to run apps like seamonkey and gaim or xchat as spot without emulation.
sadly, it is not possible to separate politics from free software. free software - politics = unfree software.

ted142
Posts: 10
Joined: Sat 19 Aug 2006, 02:07
Location: State of Liberty

#16 Post by ted142 »

I don't know about "multiple users" but I would think supporting a package and how it interfaces with puppy version 2.x or 3.x would be, for the most part, less of a job than supporting a whole fork of puppy--which ultimately sounds like it would end up as "pupuntu" by reviewing the reasoning behind the above and other discussions. I just want to slip on some protection without rebooting or "no save" or whatever--particularly if its only going to be for a quick 20 minute session before I get back to critical research.

For example, I can start a vmware instance from an image in my workstation and wreak some ugly damage to the image by typing goggle.com or otherwise and its all contained quite nicely--bad active x scripts seem to be contained as well. But starting an operating system within an operating system just to "safely" leave the box--so to speak--seems like overkill. The effect is achievable with xen (even more so with virtual-enabled CPUs) with less resource consumption, but still overkill.

Barry seems driven to decrease Puppy's complexity with each evolution which is almost unheard of in "progressive development". Most of you cats are buying into this and getting real creative with simplicity and that rocks. I think, as you point out often enough, that a lot of this creativity is self-expression and we must choose our avenues of expression. Each of the derivatives offers insight into the hearts, minds and passions of their creators/maintainers and it is with great respect and admiration that I look upon graphpup, pizzpup, etc...as well as what Barry (and friends) has achieved.

pupuntu---hmmm

well off to look at what spot can do for me....

amish
Posts: 615
Joined: Sun 24 Sep 2006, 23:15

a bit of design philosophy

#17 Post by amish »

pupuntu
of the dozen or so distro's/derivatives i've tried since 1999, ubuntu was the first thing i was able to do anything useful with. i still use it to rip ogg files since i don't know how to install the ogg codecs for ripperx in puppy. (puppy can play mpg/mp3/ogg but writes wav or mp3... ripped oggs SOUND Beautiful.)

but i was unable to install anything without a connection to the internet (hold on, what i mean is that i had to have UBUNTU connected to the net, which wasn't possible and still isn't for me) and the package management wouldn't let me uninstall ANYTHING either. i appreciate that app-i-don't-care-about requires app-i-don't-care-about that-i'm-trying-to-uninstall but really, fine if you must bother me with that detail, but LET ME DO IT!

guesttoo's wonderful simple (in all aspects) package system in puppy changed all that.

because of this simplicity, ubuntu was left behind as the first distro that i could use for anything, for puppy: the first distro that i could use for anything that wasn't already a standard feature.

i had been trying to install dosemu (or dosbox when it came out) for 8 years, and thanks to mu, i was able to install dosbox (FINALLY) and run dos apps in linux. i was also able, within 6 months, to install dosemu at long last.

ubuntu i had to reinstall because of the way it forces you to not be root. sudo is a fine OPTION but when mandated IT SUCKS.

all in all, i can't freaking stand ubuntu.

now a word on simplicity

simplicity isn't simple. think of it as compression: yes, compression makes a file smaller but it takes a sophisticated (complex) algorithm to make it compress. the more compression there is, the more complex a process is usually required.

similarly, every time you make something mroe simple, you have to put More Thinking into the process of making it simple for someone else.

so there are at least two levels of simplicity:

internal simplicity: the stuff under the hood that is working invisiably and automagically

external simplicity: the kind you must be referring to an increase of. yes, optional wizards (even by default) are a good thing when you put a lot of thought into their design.

what drives most distros/foss software projects/and eventually, commericial products like windows into extinction are an imbalance of external and internal simplicity.

for example: dotpup was very simple. dotpet is more complex. this can be okay (and it might be)

dotpet seeks to make things externally more simple. this is not a bad thing. but when the internal mechanisms are not designed in a simple way, they become difficult or impossible (or impractical) to maintain and are abandoned for something "better."

note that i mean someday, puppy itself will be replaced with something better because not enough people could keep puppy simple. but if we take care of him, puppy can last as much as a decade or two (as redhat might, or as dos really actually has.)


while it's good to make things externally simple, if the constant effort to make things simple on the outside makes them more and more complex on the inside, eventually the internal complexity will start to show up as far as the user is concerned: it doesn't work, and now you need complex fix-its and sometimes those don't work.

i'm saying something significant here:

1. too strong/careless a drive to make something simple for the user

-> 2. things become too complex internally to maintain

-> 3. things start to become too complex for the user

making it more simple to use makes it more complex to use. that's the paradox, and the thing that the best devs go to great care (and employ great brilliance) to avoid.

with luck, when things get unbalanced, they get rebalanced. when they don't get rebalanced, they simply stop being used.
sadly, it is not possible to separate politics from free software. free software - politics = unfree software.

jimhap
Posts: 63
Joined: Sat 03 Mar 2007, 16:51
Contact:

#18 Post by jimhap »

Hmmmm..... I can somewhat say I can see your point.....

You may be thinking like Windows XP. If you logged in as a limited user, you would be limited to any installs(very untrue! viruses can still install). However, to stay in that limited way but if needed to install a program, you can login as an admin.

But still....... how would you bubble EVERY single program????? I'm not disagreeing too much, but LOTS of programs use the NET. Of course, for me, I use Firefox with ad blockers and stuff, but still, you have those popups that fly loose.

I'd stick to the multiuser idea. If you just "bubble/limit" everything, hackers can still find a way OUT of the bubble/limitation, and hack your computer.

As a regular user, you would have destruction of your HOME dir, but never anything else.

I definitely agree with you on one thing-about puppy needing a rebuild.
By statistics, Puppy's 28th on the list.(as said by hit counts on distrowatch.com, scroll down and on the right, you'll see the list. if you wonder why am I wrong, 1 i did a check today, and 2 I did the "last 7 days" option) I was suprised to hear that Puppy had lost 372 visitors(hpd based)!!!

What Puppy need's is a groom, a a vet checkup, and a pamper.
What I really mean is that Puppy need to be rebuilt with multiuser, some secure things, and a redesign of puppy's website-a bit user repelling....

jimhap
Posts: 63
Joined: Sat 03 Mar 2007, 16:51
Contact:

#19 Post by jimhap »

(the above post was ment for the "bubble/limitation idea)

Ubuntu is good, but as I heard, it loves the NET and never wants to part with the NET.....

Puppy solved hat. It doesn't need the NET that much.
Even to uninstall it doesn't need to have the internet......

Anyway, back too the multiuser:

Yes, there ARE bots that love this site, and before long the BOTS will tell the hacker about the site, and before long the hacker will know wht puppy is, and if the hacker wanted the hacker could hack people's computers(trying to find IPs).

Thoughtfully, Puppy is kinda simple. But, Puppy just needs that "oomph" to get popular....
When I first started using Puppy(going to puppyos.org) I almost thought that puppy was a discontinued project, just by the look!But then I discovered that Pupppy was alive, and MUCH better than I thought!!!!!

I am right now attempting a redo of the site.
-----------------------------------------------
Comparison of Puppy and Ubuntu:

________________________________________________________
Features......................| Puppy..........................| Ubuntu...................|
Ease of use ........................YES ..............................YES(with NET) |
App Installer.........................YES...............................YES
..........# of apps....................???.................................???

(I will wdit this as I find more differences. If you're a mod, you can edit this to add more hings....)

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#20 Post by GuestToo »

The directory /tmp must have permissions set to 777
it might be better to set /tmp to 1777 ("so that anybody can write there, but they can't rename or delete other users' files")

setting up Puppy to run as multi-user does not automatically make Puppy safer ... even one tiny error could open a security hole that a proverbial truck could be driven through

Post Reply