Linux ans VB
by Joseph GOODRICH
Hello,
I'm actually trying to run a VB application with Linux and it won't work,
even with
"Wine".
Do you think it can work with Fedora ? If it can, I'll just have to download
it and enjoy running VB with Linux !!
Thanks a lot.
Joseph Goodrich.
_________________________________________________________________
Hotmail : un compte GRATUIT qui vous suit partout et tout le temps !
http://g.msn.fr/FR1000/9493
20 years, 1 month
Magicdev doesn't automount the CD drive
by Pyroman[FO]
I can only mount the CD drive manually or by clicking on "CD-ROM" in
"Computer". When I insert the disc into the drive it doesn't mount or
put the CD icon on the desktop even though I have "Mount discs when
inserted" checked.
Here is my fstab entry for my cdrom
/dev/cdrom /mnt/cdrom udf,iso9660 user,owner,kudzu,ro 0 0
It's an IDE cdrom on /dev/hdc, this is a Dell laptop so it's removable,
though it's obviously not removed :) Double clicking on the CD-ROM
mounts the drive fine and I have no trouble unmounting it as a normal
user. It's just not getting mounted when the disc is inserted. I have
connected my USB camera and it mounted fine and placed an icon on the
desktop. I even tried gnome-volume-manager and it won't mount it until
I click on it.
Pyroman[FO]
20 years, 1 month
[proposal] to split individual IM config out of xinitrc xinput script
by Jens-Ulrik Petersen
In order to improve the maintainability of the xinput script
in xinitrc and to make adding new Input Methods (IMs) easier
in the future, Akira Tagoh and I recently came up with the
idea to split all the individual IM code out of xinput and
put it into separate config scriptlets that would be owned
and maintained by the individual IM packages.
The idea is basically to replace all the IM specific code in
xinput by something like this:
lang_region=$(echo $tmplang | sed -e 's/\..*//')
XINPUTDIR=/etc/X11/xinit/xinput.d
if [ -z "$XIM" ]; then
if [ -r ${XINPUTDIR}/$(LANG) ]; then
. ${XINPUTDIR}/$(LANG)
elif [ -r ${XINPUTDIR}/$(lang_region) ]; then
. ${XINPUTDIR}/$(lang_region)
fi
elif [ -r ${XINPUTDIR}/$(XIM) ]; then
. ${XINPUTDIR}/$(XIM)
fi
where $XINPUTDIR would contain scriptlets installed with
alternatives by the individual IM packages (htt, chinput,
xcin, nabi, kinput2, skkinput, etc) and alternatives
symlinks for each locale through /etc/alternatives to the
default IM for it. For example:
/etc/X11/xinit/xinput.d/hi_IN -> /etc/alternatives/xinput-hi_IN
/etc/X11/xinit/xinput.d/ja_JP -> /etc/alternatives/xinput-ja_JP
/etc/X11/xinit/xinput.d/ko_KO -> /etc/alternatives/xinput-ko_KO
/etc/X11/xinit/xinput.d/zh_CN -> /etc/alternatives/xinput-zh_CN
/etc/X11/xinit/xinput.d/zh_TW -> /etc/alternatives/xinput-zh_TW
[It is not sure whether it better to support symlinks for
both ll_CC.ENCODING and ll_CC separately or not. Perhaps
only ll_CC or even just ll is sufficient?]
and then for example there would be symlinks like
/etc/alternatives/xinput-hi_IN -> /etc/X11/xinit/xinput.d/htt
/etc/alternatives/xinput-ja_JP -> /etc/X11/xinit/xinput.d/kinput2-canna
/etc/alternatives/xinput-ko_KO -> /etc/X11/xinit/xinput.d/nabi
/etc/alternatives/xinput-zh_CN -> /etc/X11/xinit/xinput.d/htt
/etc/alternatives/xinput-zh_TW -> /etc/X11/xinit/xinput.d/xcin
[For FC the default IM would actually be htt (if installed)
for all these locale, but I just put in various IMs here to
illustrate.]
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119785
for more details and comments. Unfortunately it is getting
a bit late now for FC2, so this idea may have to wait for
FC3.
The only weakness of this compared to the current xinput
setup that I can think of is that it doesn't allow for any
fallbacks: eg if htt is running use it otherwise use kinput2
with Canna say instead. But in practice people don't
usually switch IM all the time, and the flexibility gained
outweighs this small loss. Also users can still easily
override the IM configuration by setting XIM (and optionally
also XIM_PROG and XIM_ARGS) in their ~/.i18n" file or
system-wide in "/etc/i18n".
Comments and feedback on the scheme and design are most welcome.
Cheers, Jens
20 years, 1 month
Re: [RFC] User Accesable Filesystem Hierarchy Standard
by Jamethiel Knorth
>Date: Tue, 6 Apr 2004 21:46:45 -0400
>From: Alan Cox <alan(a)redhat.com>
>
>On Tue, Apr 06, 2004 at 09:36:24PM -0400, Jamethiel Knorth wrote:
> > Actually, the idea does allow people to install shared programs. Part of
> > the purpose of this is that a user can install a shared program without
> > escalating their privileges. Of course, a system can be set up to
>prevent
> > this. The main advantage in a home environment is that, if a user does
> > install something, it needn't be installed with root permissions.
>
>Your typical home user will install prebuilt packages using the tools
>provided with the system. In a non home environment you rarely want users
>installing anything, and with SELinux you can go so far as to make
>just about anything user originated (scripts included tho its a bit
>tricky) non-executable. This is good as it turns "I got this cool christmas
>card and ran it" into "I asked the sysadmin why it wouldnt run and she told
>me
>about trojans".
This is meant to be useable by any system, not only a Linux system, and not
only an SELinux system either.
Many environments do not have sysadmins. Those with sysadmins could have
different permission sets. This does nothing to prevent this. In those
environments (home desktop) without sysadmins, the result would often be "I
got this cool christmas card and it wouldn't run so I just typed in my root
password and then it worked fine. Hey, why is my computer F'ed up?"
And, this system would be used by the package manager as well. There is
nothing preventing a package manager from supporting this, although the
support will likely not be immediate.
Also, after a little more thought, the 'shared' directory will be changed in
the next revision of the draft, so that it isn't a specific requirement.
That is merely going to be a group directory which is optional and has a
standard name (somewhat like '/home/' is optional in the FHS).
> > Looking at the current situation with Windows, it's fairly reasonable to
> > assume that regular users will intentionally install programs without
> > properly checking what they are and who made them. If they do this with
> > root privileges, the program could influence every portion of their
>system
> > and this could cause catastrophic problems.
>
>"Other people fire shotguns at random without warning, lets all do that"
More like, "People have a tendency to fire shotguns at random without
warning. Mayhaps we should expect them to."
>Maybe there is an argument for a /usr/local/ with default labels that
>prohibit privileged roles using the contents and which doesn't require
>total superuser rights to write into.
>
>That also solves
> - The 10,000 private installations of epic problem
The 10,000 private installations can be solved by a decent package
management system which will notify the administrator of multiple
installations. This system will also make it more likely an administrator is
aware of a private install if a user's home directory is allowed to have
execute permissions. Obviously, if they are not allowed that, the
administrator decided not to follow this standard. The standard is intended
to organize user access to the filesystem, which is not desired in all
situations.
> - The cross platform problem
This is fairly well solved by the different <distro>/<arch>/ structures.
Also, when config/ is moved into those <distro>/<arch>/ directories, this
will aid in allowing a user to have configuration files for multiple
environments, which would apparently be an improvement over the current
system.
> - Non-exec /home
Additionally, this standard adds a way to have programs and documents easily
shared throughout groups with the addition of group directories, which is
currently rather lacking. The last time I ran into a group project, the
sharing of stuff was so much trouble, people decided to just share out
massive swaths of their home directories and hope no-one else messed with
them.
_________________________________________________________________
Tax headache? MSN Money provides relief with tax tips, tools, IRS forms and
more! http://moneycentral.msn.com/tax/workshop/welcome.asp
20 years, 1 month
Re: [RFC] User Accesable Filesystem Hierarchy Standard
by Jamethiel Knorth
>Date: Wed, 7 Apr 2004 13:25:43 +0300
>From: "Doncho N. Gunchev" <mr700(a)globalnet.bg>
>
>On Wednesday 07 April 2004 04:56, Jamethiel Knorth wrote:
> > Date: Mon, 5 Apr 2004 16:39:18 +0300
> > From: "Doncho N. Gunchev" <mr700 globalnet bg>
> > >
> > >On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote:
> > >>
>....
> > > Let's say we have program foo from package foo-1.0-1.sparc.rpm
>which has
> > >a .desktop file in ~/.<distribution>/share/applications/foo.desktop.
> > >--- cut ---
> >
> >+------------------------+---------------------------------------------------+
> > >| ~/.<distribution>/share/ | Architecture independent files used by
>programs |
> > >| | in ~/.<distribution>/<architecture>/bin/
> |
> >
> >+--------------------------+-------------------------------------------------+
> > >--- cut ---
> > > In this case if a user uses his home from a nfs share on ix86
>mahine
> > >he/she will see this application in his/her kde/gnome start menu, but
>will
> > >not be able to run it (it is the sparc version, not the ix86). Another
> > >problem could be shared files that are little-endian/big-endian
>dependent.
> > >The space could be saved by hardlinking identical files which are not
> > >suposed change without being removed first (/usr/share/doc/*/*).
> >
> > There will likely need to be separate menu entries in each
><distro>/<arch>/
> > directory, but that's really up to the desktop's to introduce. I don't
>think
> > this standard in any way prevents that from being added. Or, they might
>be
> > able to add some extensions to the XDG standard (or whatever the new
>menu
> > standard is) to allow different entries according to distro and
> > architecture.
> Could work with extra tags in the .desktop entries or with some sort
>of
>tag, extension, etc. I'm still not sure what happends with programs that
>use architecture dependant data ordering (big-endian and little-endian).
>Probably the programs must be fixed, but to me it looks much more simple
>having only a BASEDIR and all bin,etc,lib,... dirs there. Installation
>programs (rpm,dpkg...) or the user can still hardlink/symlink files.
>
> >
> > > What about uafhs being configurable via /etc/uafhs? It could be
> > >something
> > >like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a
> > >script
> > >will be needed to setup this variable at login time and the install
>tools
> > >should be made UAFHS-aware (or at least I hope so). The main idea is to
> > >allow
> > >a user to login from same/different distribution(s) and architecture(s)
> > >simultaneously. I have RH9 + FC1 with shared /home partition and this
>leads
> > >to many problems with all .dot(files|dirs) in my home dir (kde for
>example)
> > >even without logging in simultaneously.
> >
> > I had been considering this problem a little, but was unsure how large
>of a
> > problem it was, as I have never had parallel distribution installs. I
> > considered having '.<distro>/<arch>/config/' instead of '.config' to
>avoid
> > this, but my concern was that this would mean the directory had a
>totally
> > non-constant location, and many programs wouldn't use it. Of course,
> > distribution builds could use it well enough, but something installed
>from a
> > tarball might be hard to convince. If this were the case, the '.config/'
> > directory wouldn't actually clean up the dotfiles in the home directory,
>as
> > it was intended to do.
>
> If something compiled from tarball uses BASEDIR=UAFHSBASE I think
>there
>is no problem except for all dotfiles in the home dir. If such a program is
>UAFHS-aware there should be no problem at all I hope...
So, a reasonable solution seems to be to just require that $UAFHS_DISTRO and
a $UAFHS_ARCH variables be present, so an installing or running program can
look in the right place. Thus, a private install could use
--prefix=~/$UAFHS_DISTRO and
--whatever-the-other-prefix-var-is=~/$UAFHS_ARCH and shared/group installs
could do likewise but in something besides ~/.
The system would just be required to properly declare $UAFHS_DISTRO and
$UAFHS_ARCH on startup, which would be very simple, quite as declaring the
PATH variable, and all the other environment variables that are about.
Then, when looking for config files, a program could always look in
~/$UAFHS_ARCH/config/ to find the config files which are relevant at the
moment. The only downside might be that your configuration files you go to
the trouble of setting up on one system would be totally absent on another.
Creative symlinking might get around that, but I have doubts. Maybe someone
could think of a good tool to keep that stuff synced.
As you might have some knowledge about this, I'll ask: There are a few
directories which, after looking, I realized were probably distribution and
architecture independent which I wanted to place outside of the distro
folders in these sections. The only ones I noted were font and dictionary
files, as I don't see where those change from system to system (except
possibly with the byte-order changes from architecture, but they're already
in the architecture independent folders). Are these files actually distro
independent, and are there any other major file groups that are as well?
_________________________________________________________________
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2
months!
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361a...
20 years, 1 month
Re: [RFC] User Accesable Filesystem Hierarchy Standard
by Jamethiel Knorth
Date: Mon, 5 Apr 2004 16:39:18 +0300
From: "Doncho N. Gunchev" <mr700 globalnet bg>
>
>On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote:
>>
>>This is a proposal for a standard to accommodate the accessibility of the
>>filesystem by end-users. We request discussion on this as a new standard.
>> >The
>>URL to get to the document is:
>>
>>http://www.csis.gvsu.edu/~abreschm/uafhs/
>>
>>I am a member of the Ark Linux team, who is interested in seeing the Linux
>>desktop become a viable option. I apologize for the cross-posting.
>>
> I really dislike all these hidden dotfiles/dotdirs in my home directory
>and am happy to see someone is working on this. I was thinking it would be
>better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see
>much
>more general ideas here, so here's what I think looking at it:
>
> Let's say we have program foo from package foo-1.0-1.sparc.rpm which
> >has
>a .desktop file in ~/.<distribution>/share/applications/foo.desktop.
>--- cut ---
>+------------------------+---------------------------------------------------+
>| ~/.<distribution>/share/ | Architecture independent files used by
>programs >|
>| | in ~/.<distribution>/<architecture>/bin/
> |
>+--------------------------+-------------------------------------------------+
>--- cut ---
> In this case if a user uses his home from a nfs share on ix86 mahine
>he/she will see this application in his/her kde/gnome start menu, but will
>not be able to run it (it is the sparc version, not the ix86). Another
>problem could be shared files that are little-endian/big-endian dependent.
>The space could be saved by hardlinking identical files which are not
>suposed change without being removed first (/usr/share/doc/*/*).
There will likely need to be separate menu entries in each <distro>/<arch>/
directory, but that's really up to the desktop's to introduce. I don't think
this standard in any way prevents that from being added. Or, they might be
able to add some extensions to the XDG standard (or whatever the new menu
standard is) to allow different entries according to distro and
architecture.
> What about uafhs being configurable via /etc/uafhs? It could be
>something
>like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a
>script
>will be needed to setup this variable at login time and the install tools
>should be made UAFHS-aware (or at least I hope so). The main idea is to
>allow
>a user to login from same/different distribution(s) and architecture(s)
>simultaneously. I have RH9 + FC1 with shared /home partition and this leads
>to many problems with all .dot(files|dirs) in my home dir (kde for example)
>even without logging in simultaneously.
I had been considering this problem a little, but was unsure how large of a
problem it was, as I have never had parallel distribution installs. I
considered having '.<distro>/<arch>/config/' instead of '.config' to avoid
this, but my concern was that this would mean the directory had a totally
non-constant location, and many programs wouldn't use it. Of course,
distribution builds could use it well enough, but something installed from a
tarball might be hard to convince. If this were the case, the '.config/'
directory wouldn't actually clean up the dotfiles in the home directory, as
it was intended to do.
As you use a parallel install, how large of a problem is this? I mean, I
truly don't know. Also, would moving the config directory into the
distribution and architecture directories solve this properly?
_________________________________________________________________
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2
months!
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361a...
20 years, 1 month
Fedora Bug Day: Aprl 07 2004: I'm not quite dead...
by Jef Spaleta
..in fact.. I'm feeling better.
What: Fedora Bug Day:
To every bug..turn turn turn...
there is a resolution...turn turn turn...
and a time for cobweb cleaning in the bugzilla.
Or in plain but misspelled english, Let's spend a little time over the
next 24 or so hour period, digging into bugzilla and trying to help
clean out some of the bugreports that are cluttering up Fedora bugzilla
in an effort to make it marginally easier for developers to navigate the
'zilla and find reports that need fixing. Several types of bugreports
are screaming for community invovlement:
1) duplicates bug reports for problems already resolved that can be
cleaned out
2) bug reports about potentially real problems that need more
information and/or confirmation before developers can make head way
3)sundry other situations
Who:
pretty much anyone with a web browser and a bugzilla.redhat.com and/or a
bugzilla.fedora.us account, and want to contribute to the fedora
development process. Users of all skill levels can make a positive
impact on keeping bugzilla's bug reports better organized for developers
via Fedora Triage effort by learning how to be a package shepherd of
sorts:
Alan Cox I think said it best:
"Track the bugs in your favorite package/component:
* try to make a few minutes everyday to look through the new bugs filed
in the last day for the package you want to watch.
* Sign up for the upstream mailing lists and bug tracking system, so you
can more effectively be able to move bugs reported to Fedora upstream
where they are more likely to be fixed."
And to put a finer point on it Warren Togami adds:
"Most projects don't have anything like an effective bug tracker of
their own. Because of that, what we need are volunteers to serve as
liaison to upstream projects. They should be members of those upstream
mailing lists and pay attention to news/patches/security alerts there.
Such helpers if they are diligent would be like assistants to the
package maintainers, and learn things as they go as well as gain trust
in the process"
Where: #fedora-bugs channel on freenode irc network
How:
Come to the #fedora-bugs channel on the freenode irc network tomorrow
and be a part of the discussion. Go to bugzilla.redhat.com and try to
find a Fedora Core bugreport that you think is should be closed out, get
the attention of one of the triagers or developers sitting in channel
waiting in a grip of white knuckle anticipation to discuss with you
whether the bug should be closed or not. ( difficulty of trying to flag
someone down to talk to in channel might be a little time sensitive,
please be patient and don't be discouraged if someone doesn't respond
right away ) Use the bug day opportunities to start down a path of
contributing to fedora development by becoming a package shepherd, or
general fedora triager.
Huh: No Clue What I'm talking about when I say the phrase Fedora
Triage?
Take a quick look at the fedora-triage-list archives:
https://lists.dulug.duke.edu/pipermail/fedora-triage-list/
These messages should hopefully tell you what its all about in more
detail:
http://tinyurl.com/ywma3 - Summary of my vision for Fedora Triage
http://tinyurl.com/23alw - My short term goals and long term plan
-jef"damn..its Wednesday already"spaleta
20 years, 1 month
Re: Forward looking to FC2 final and SELinux
by Jef Spaleta
Jesse Keating wrote:
> So, it's not a matter of have SELinux in the distro or not, it's a >
matter of usability and exposing the RIGHT option to the end user. >
Much like other advanced features are hidden from the (to borrow
> Jef "I have a big middle name" Spaleta's phrase) average meathead, >
SELinux should be not exactly hidden, but just disabled by
> default. It would go a long way toward making the distro
> desireable.
While deftly skirting publicly positioning myself on the should selinux
be defaulted to on. I thought i'd take a moment to clear up
my definition of "meathead" which i think is being used incorrectly
in this situation. Meatheads are those people who deliberately choose
to not use the defaults without having an appropriate understanding of
the consequences. They will do things like go out of their way to enable
even hidden options just because they read a one page 12 step howto,
that doesn't make an effort to explain how badly things can go and makes
no effort to educate beyond the best case situation.
Meatheads tweak their systems...but do not learn anything about their
systems until after the noticed it has gone horribly wrong and have no
idea when exactly it went horribly wrong during the 100 or so specific
tweaks they performed.
In my lonely and opinionated world view.... meatheads are a completely
different subgroup than the AT user that ESR likes to wax eloquent
about. AT's or as I like to call them... office and home professionals,
want to get tasks done sane defaults and other usability and utility
issues should be designed with them in mind.
As much as I want to learn and understand about the inner-workings of
the tools I use, i know normal people don't have nearly anywhere the
same comprehension fetish that I have. My general rule is... if its
something I want as a feature to make my life easier..its clearly NOT a
good idea for office and home professional userbase.
Meatheads are a complete contrast with the office and home professional
group that Aunt T is a member of. They obsess over detailed featuritis
compared to enhanced general usability and work flow...and yet they can
not be considered technically proficient (yet) because they have not
learned basic troubleshooting skills when doing clearly advanced and
experimental tweaking...skills like skimming documentation that comes
with the software before screwing around.
</rant off>
So in this situation...defaulting selinux to off in the installer..isn't
going to protect meatheads, but it will probably protect the office and
home professionals, since they will more likely than not need to install
3rd party applications, if selinux continues to have trouble with tasks
like that. Identifying critical,frequent, and infrequent computing
activities that the office and home professional userbase need to do to
accomplish routine tasks and how selinux interferes with those
activities will probably go a long way to estimating the impact selinux
is going to have on that part of the userbase. And I know, that my
personal use patterns diverge wildly from what an office and home
professional user would be expecting to do every day or week or month or
whatever, so i joyful expect problems with fc2 with selinux on or off.
-jef"bug day email next...after i get a soda"spaleta
20 years, 1 month
Strange Kudzu Behavior: Update 2
by Pyroman[FO]
I have been able to replicate it outside of the boot process. I still
haven't been able to figure out the determining factor, but I can get
/etc/init.d/networking, ifup and ifdown to fail on their own now. So
it's not specific to booting.
Pyroman[FO]
20 years, 1 month
Re: Updated qlogic driver
by Nate Bradley
Here is his first reply :
0n Mon, 2004-04-05 at 19:57, Nate Bradley wrote:
> any plans to include additional qlogic drivers i.e. qla22xx and
qla23xx
> in the kernel
ehhhh have you even looked at the kernel ... we already include those.
------------------------------------------------------
"He answered your question in the first email, and even told you where
you could look to
verify."
Politely : You are wrong. Jesse Keating.
Read the reply's again, carefully, and please point out where he told
me to look. Better yet, what the name of the actual module is. In
addition, his reply wasn't that helpful considering the additional
configuration needed for the module to load during boot.
Nothing personal really. I just think he's rude.
20 years, 1 month
