gphoto2 and libgphoto2
by Dennis Bjorklund
Is there a reason why gphoto2 and libgphoto2 are in the same package and
not two seperate ones? I'd like a separate libgphoto2 package. The library
is used by more frontends then just gphoto2.
--
/Dennis Björklund
20 years
- 3
- 3
FC Dev 1.91 on PPC
by M Galvin
So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running
on my Mac. I was able to boot from the CD i created from this iso...
but for some reason the keyboard doesn't work, or better yet, the
boot image doesn't recgognize my keyboard. Its a regular Mac USB
keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could
not find a ppc-list so i am posting here in hopes that someone has
had a similar issues.
Any help is greatly appreciated
Thanks in advance
-------------------------
M Galvin
Lead Programmer
Simplified Complexity
http://www.simplifiedcomplexity.com
20 years
- 3
- 2
switchdesk bug?
by Warren Togami
I am pretty sure this is a bug, but I don't know enough about how the
desktop starts. I suspect this makes no functional difference?
1) Run switchdesk.
2) Do not change anything, but Click OK.
3) cat .Xclients-default
#! /bin/bash
# Created by Red Hat Desktop Switcher
WMPATH="/usr/bin /opt/bin /usr/local/bin /usr/X11R6/bin"
for wm in $WMPATH ; do
[ -x $wm/startkde ] && exec $wm/startkde
done
exit 1
4) Run switchdesk.
5) Click on KDE, Click on GNOME, Click OK.
6) cat .Xclients-default
# Created by Red Hat Desktop Switcher
exec gnome-session
20 years
- 1
- 0
Re: [RFC] User Accesable Filesystem Hierarchy Standard
by Jamethiel Knorth
>From: Robert Marcano <robert(a)marcanoonline.com>
>Date: Wed, 31 Mar 2004 16:51:55 -0400
>
>On Wed, 2004-03-31 at 15:47, Gary L Greene Jr wrote:
>
> > On Saturday 27 March 2004 06:05 pm, Robert Marcano wrote:
>...
> > >
> > > I am sure that the filesystem can be arranged in order to make it more
> > > easy to use to the desktop user, Your ideas of a shared directory is
> > > nice, but letting the user "Easily install software without escalating
> > > their privileges" is something that I don't like. The only way that I
> > > like a shared directory is if it is mounted from a filesystem with the
> > > "noexec" flag.
> > >
> > > I think that the software installation can be made easy with the help
>of
> > > a better "Add/Remove Programs", and the security aspect could be
> > > enhanced with the help of a SELinux policy for this program(s) (I am
>not
> > > an expert in SELinux, so I could be wrong)
> >
> > The problem with adding software installation only through the root
> > directories is that you still need to have root privileges to install a
> > program. This proposal is to allow people to install programs, but not
>as
> > root. This adds no new abilities. None. It just makes it easier.
>Already,
> > people can install any program in their home directory, it is just a lot
>of
> > hassle. This is just a way to organize it.
>
>For what I have learned of SELinux, I think that it could be used to
>give special privileges to certain processes (for example the Add/Remove
>programs of the distribution) to do whatever it wants on the system by
>defining the appropriate SELinux policy. For example the policy can
>allow to a program to install new files on /usr/{bin,lib,share,...} or
>update the files of a previously installed version of the application
>without asking any root credentials to some users of the system, or all
>if wanted. This is the more secure way I think it can be done
SELinux is a tool with the ability to provide a secure way to access other
directories. However, this is not a Linux standard in particular. If it is
intended to be a standard, it needs to support any system which uses a
hierarchal filesystem in the usual Unix manner. However much I like
SELinux's abilities, that seems to be an extension which needs to be added
by a distribution.
>... continues ...
>
> > The purpose is for home installation. Here is a sample setup: I have a
> > computer used by four people. I own it and want to run it. I want to
>allow
> > the other people to install programs without asking me. This lets them
>do
> > installations without needing to be root.
> >
> > This doesn't pose a security issue because the programs installed thus
>do not
> > have higher privileges than those of the user that installed them.
> >
> > This will in fact improve security on many home installations because
>users
> > will not need to be constantly entering their root password and will be
>less
> > likely to just turn the root password off.
>
>Leaving to another time my differences with your proposal ;-), I think
>that you must add to your document information about the search order of
>the PATH, LD_LIBRARY_PATH, etc. You can include for example that for
>security reasons it is mandatory that the system libraries and
>executables need to be loaded before any user installed ones; or the
>other way: in order to allow the upgrade of system installed
>applications the search path is reversed to allow that. What the
>standard will recommend? changes to LD implementation in order to allow
>the load of the user installed shared libraries. or the usage of the
>environment variable LD_LIBRARY_PATH
Interestingly enough, the order of items in the PATH and LD_LIBRARY_PATH are
not part of the previous FHS standard and I see no reason to standardize
them in an extension. This merely deals with the directory layout. That is a
separate level which might need a separate standard of its own.
>Do you know that a lot of user oriented applications store files on
>/usr/share (and others)?, and that directory is defined at compile time
>(nearly on every application that uses it), so you will need to build
>the application specially for the directory you are deploying, and on
>"home installations" the users will not build their custom versions
I was under the impression, from personal experience, that almost all of
them define a $PREFIX and can use any share which is appropriate to that
prefix. Moving the directories into a format more like '~/.system/bin/'
would give a full set of standard directories to install to, just as is
currently available to allow installation into several areas.
Although some binary distributions may not support this, that is
unavoidable. It is supportable, and they should support it, and there is
little that can be done if they do not. (If there is a work around, please
inform me.)
>
> > Also, note that this is not intended for server installs, as is stated
>in the
> > proposal.
> >
> > Thank you for the feedback.
>
>Hope this helps
>
>--
>Robert Marcano
_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar FREE!
http://toolbar.msn.com/go/onm00200414ave/direct/01/
20 years
- 1
- 0