Panel Clock Calendar Starting on Wrong Day
by Thomas J. Baker
I reported a bug against tzdata for FC5
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189718) about my
panel clock starting on Monday instead of Sunday. My rawhide system
doesn't have the problem, it starts correctly on Sunday. Both systems
have the locale set to en_US.UTF-8 and both tzdata rpms look the same
(tzdata-2006d-1 and tzdata-2006d-1.fc5). I've read that my problem is
due to incorrect locate data which i assumed came from tzdata. I
reported the bug on Sunday but haven't received any response. Is anyone
else seeing this error on FC5 or rawhide? Is tzdata where the locale
data is packaged?
Thanks,
tjb
--
=======================================================================
| Thomas Baker email: tjb(a)unh.edu |
| Systems Programmer |
| Research Computing Center voice: (603) 862-4490 |
| University of New Hampshire fax: (603) 862-1761 |
| 332 Morse Hall |
| Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb |
=======================================================================
18 years
rawhide report: 20060426 changes
by Build System
Updated Packages:
Xaw3d-1.5E-8
------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 1.5E-8
- Rebuild for new imake build rules
* Tue Feb 28 2006 Than Ngo <than(a)redhat.com> 1.5E-7
- update Url #183314
beagle-0.2.5-3
--------------
* Fri Apr 21 2006 Alexander Larsson <alexl(a)redhat.com> - 0.2.5-3
- Update to 0.2.5
- Update patches
cairo-1.1.2-1
-------------
* Tue Apr 25 2006 Carl Worth <cworth(a)redhat.com> - 1.1.2-1
- Update to new upstream 1.1.2
- Port forward the embedded bitmaps patch (now committed upstream to
1.1.3)
- Drop build-fix and chunk-glyphs patches which now come from upstream
cracklib-2.8.9-2
----------------
* Tue Apr 25 2006 Nalin Dahyabhai <nalin(a)redhat.com> - 2.8.9-2
- update to 2.8.9
- only create compat symlinks for the dictionaries if we aren't installing
them into the old locations
cups-1:1.2-0.5.rc3.2
--------------------
* Tue Apr 25 2006 Tim Waugh <twaugh(a)redhat.com> 1:1.2-0.5.rc3.2
- Patch pdftops to understand 'includeifexists', and use that in the
pdftops.conf file (bug #189809).
dbus-0.61-5
-----------
* Tue Apr 25 2006 John (J5) Palmieri <johnp(a)redhat.com> - 0.61-5
- Backport patch from dbus-connection.c
- Allows interfaces to be NULL in the message header as per the spec
- Fixes a problem with pendings calls blocking on a data starved socket
ethereal-0.99.0-1
-----------------
* Tue Apr 25 2006 Radek Vokál <rvokal(a)redhat.com> 0.99.0-1
- update to 0.99.0
* Tue Apr 25 2006 Radek Vokál <rvokal(a)redhat.com> 0.99.0-0.svn.2
- fix crash when tuning columns (#189428)
gcc-4.1.0-11
------------
* Tue Apr 25 2006 Jakub Jelinek <jakub(a)redhat.com> 4.1.0-11
- update from gcc-4_1-branch (-r113149:113242)
- PRs c/25875, c/26774, fortran/18803, fortran/25597, fortran/25669,
fortran/26787, fortran/26822, fortran/26834, fortran/27089,
fortran/27113, fortran/27122, fortran/27124, target/21283,
target/26961
- fix number of iterations computation (Zdenek Dvorak, #189376,
PR tree-optimization/27285)
- fix handling of volatile in the inliner (Andrew Pinski, Richard Guenther,
PR tree-optimization/27236)
- strip useless type conversions in the inliner (Andrew Pinski,
Richard Guenther, PR tree-optimization/27218)
ghostscript-8.15.2-2
--------------------
* Tue Apr 25 2006 Tim Waugh <twaugh(a)redhat.com> 8.15.2-2
- 8.15.2.
- No longer need build, krgb, pdfwrite, str1570 patches.
glibc-2.4.90-1
--------------
* Tue Apr 25 2006 Jakub Jelinek <jakub(a)redhat.com> 2.4.90-1
- update from CVS
* Mon Apr 24 2006 Jakub Jelinek <jakub(a)redhat.com> 2.4-6
- update from CVS
- NIS+ fixes
- don't segfault on too large argp key values (#189545)
- getaddrinfo fixes for RFC3484 (#188364)
gnome-power-manager-2.15.1-1
----------------------------
* Tue Apr 25 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.15.1-1
- Update to 2.15.1
gnome-terminal-2.14.1-11
------------------------
* Tue Apr 25 2006 Kristian Høgsberg <krh(a)redhat.com> 2.14.1-11
- Bump for rawhide build.
* Tue Apr 25 2006 Kristian Høgsberg <krh(a)redhat.com> - 2.14.1-10
- Fix selection atom name intialization (patch from Kjartan Maaras).
- Lower vte requirement to 0.12.0-2 which is what fc5-bling has.
imake-1.0.1-4
-------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 1.0.1-4
- Fix ExtraXawReqs to reflect reality (libXp is unneeded)
isdn4k-utils-3.2-45
-------------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 3.2-45
- Rebuild for updated imake build rules
* Tue Apr 25 2006 Than Ngo <than(a)redhat.com> 3.2-44
- add capi service
kde-i18n-1:3.5.2-3
------------------
* Tue Apr 25 2006 Than Ngo <than(a)redhat.com> 1:3.5.2-3
- add kde-i18n-Lithuanian
kernel-2.6.16-1.2157_FC6
------------------------
* Tue Apr 25 2006 David Woodhouse <dwmw2(a)redhat.com>
- Drop the last remnants of the 'make bzImage on all arches' silliness
netdump-0.7.16-1
----------------
* Tue Apr 25 2006 Thomas Graf <tgraf(a)redhat.com> - 0.7.16-1
- update to version 0.7.16
pam-0.99.3.0-3
--------------
* Tue Apr 25 2006 Tomas Mraz <tmraz(a)redhat.com> 0.99.3.0-3
- added pam_namespace module written by Janak Desai (per-user /tmp
support)
- new pam-redhat modules version
* Fri Feb 24 2006 Tomas Mraz <tmraz(a)redhat.com> 0.99.3.0-2
- added try_first_pass option to pam_cracklib
- use try_first_pass for pam_unix and pam_cracklib in
system-auth (#182350)
* Fri Feb 10 2006 Jesse Keating <jkeating(a)redhat.com> - 0.99.3.0-1.2
- bump again for double-long bug on ppc(64)
pm-utils-0.18-1
---------------
* Tue Apr 25 2006 Peter Jones <pjones(a)redhat.com> - 0.18-1
- Make it work cross-distro
rhythmbox-0.9.4.1-2
-------------------
* Tue Apr 25 2006 Matthias Clasen <mclasen(a)redhat.com> - 0.9.4.1-2
- Update to 0.9.4.1
rpm-4.4.2-19
------------
* Tue Apr 25 2006 Paul Nasrat <pnasrat(a)redhat.com> - 4.4.2-19
- Add --trusted stubs from upstream
selinux-policy-2.2.35-2
-----------------------
* Tue Apr 25 2006 James Antill <jantill(a)redhat.com> 2.2.35-2
- Add xm policy
- Fix policygentool
* Mon Apr 24 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.35-1
- Update to upstream
- Fix postun to only disable selinux on full removal of the packages
tar-1.15.90-2
-------------
* Tue Apr 25 2006 Peter Vrabec <pvrabec(a)redhat.com> 1.15.90-2
- exclude listed02.at from testsuite again, because it
still fails on s390
* Tue Apr 25 2006 Peter Vrabec <pvrabec(a)redhat.com> 1.15.90-1
- upgrade
wpa_supplicant-1:0.4.8-9.fc6
----------------------------
* Tue Apr 25 2006 Dan Williams <dcbw(a)redhat.com> - 0.4.8-9
- Enable Wired driver, PKCS12, and Smartcard options (#rh189805#)
* Tue Apr 11 2006 Dan Williams <dcbw(a)redhat.com> - 0.4.8-8
- Fix control interface key obfuscation a bit
xfig-3.2.4-19
-------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 3.2.4-19
- Rebuild for updated imake build rules
xorg-x11-server-utils-1.0.1-3
-----------------------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 1.0.1-3
- Eliminate a spurious Xprint dependency from xset.
xorg-x11-utils-1.0.1-2
----------------------
* Tue Apr 25 2006 Adam Jackson <ajackson(a)redhat.com> 1.0.1-2
- Remove a spurious Xprint dependency from xdpyinfo.
* Fri Feb 10 2006 Jesse Keating <jkeating(a)redhat.com> 1.0.1-1.2
- bump again for double-long bug on ppc(64)
* Tue Feb 07 2006 Jesse Keating <jkeating(a)redhat.com> 1.0.1-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5
GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5
GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5
cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5
cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5
dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5
dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5
gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
Broken deps for ia64
----------------------------------------------------------
rgmanager - 1.9.31-3.ia64 requires ccs
Broken deps for ppc64
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for s390
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5
Broken deps for s390x
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
18 years
Still much more than 350 sockets needed!
by Wiese, Hendrik
Hello again,
we still need to know how to increase the maximum number of
possible open sockets per IP address! Here we got the problem
that no more than 350 sockets are possible. On another Linux
(based on LFS) it is no problem to open far more than 5.000
connections on the same way. So we know that it is possible.
So how can we break this limitation? Some kind of sysctl?
Kernel patch needed? Anything else?
It's urgent, so any kind of help would be greatly appreciated.
Thanks a lot!!!
regards,
H. Wiese
18 years
FC5 kernel updates
by Bojan Smojver
Maybe slightly off topic here (not sure)...
Are there plans to bump up FC5 kernels to 2.6.16.6, given that several
stable kernel updates contained security fixes? Or is FC5 unaffected by
the ones mentioned in kernel release notes (i.e. wrong arch, features
that are not compiled, already patched by FC specific patches etc.)?
--
Bojan
18 years
AIGLX questions -- the x86_64 bit question
by Alan
Have the x86_64 problems been resolved? The AIGLX wiki has not been
updated since FC5t3.
Also, what is the status of the NVIDIA drivers? (I find it weird that XGL
has NVIDIA working but not ATI and AIGLX has ATI working, but not NVIDIA.)
--
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis
18 years
RE: corrupt package message during FC5 install from NFS.
by Aggarwal, VikasX
Hi Paul,
I moved onto using FC5 Gold, earlier I was on FC5test3.
I am trying to run "anaconda --test -m nfs:/FC5 ". After giving the
root password in the installation steps, installer pops same error box
again which I used to get with FC5test3. It says --
"Unable to read package metadata. This may be due to a missing
repodata directory. Please ensure that your install tree has been
correctly generated. failure: repodata/repomd.xml from anaconda: [Errno
256] No more mirros to try."
The contents of FC5 are directly copied from CD{1-5}. I built and
installed anaconda from SOURCE.rpm (anaconda-11.0.5).
What can be the problem?
Appreciate your help.
Thanks
-vikas aggarwal
-----Original Message-----
From: Paul Nasrat [mailto:pnasrat@redhat.com]
Sent: Friday, April 21, 2006 1:15 PM
To: Aggarwal, VikasX
Cc: Anaconda-devel-list(a)redhat.com; fedora-devel-list(a)redhat.com
Subject: RE: corrupt package message during FC5 install from NFS.
On Fri, 2006-04-21 at 13:05 -0700, Aggarwal, VikasX wrote:
> Thanks !!
> Now I have this error for my custom distro.
> " Unable to read package metadata. This may be due to a missing
> repodata directory. Please ensure that your install tree has been
> correctly generated. failure: repodata/repomd.xml from anaconda:
[Errno
> 256] No more mirros to try."
>
> I am doing anaconda --test -m nfs:/fedora
ls /fedora
ls /fedora/repodata
I'd expect
/fedora/base
/fedora/RPMS
/fedora/repodata
Then repomd.xml primary.xml.gz and some other files in repodata:
comps.xml
filelists.xml.gz
other.xml.gz
primary.xml.gz
repomd.xml
Paul
18 years
Fedora core suggestions
by Alo Tsum
Fedora Core 5 is a truly amazing OS and one I think has the potential to
really do great things. Looking forward to what the Fedora Project has the
potential to do, especially with its new focus I decided to give some
suggestions as to what could possibly be done starting with Fedora 6 and
onward. Some of my suggestions are definitely based on the OS itself but
others are also concerning the general focus and outlook of the Fedora
Project itself. I hope my suggestion are not regarded as offensive in anyway
and they are only meant to highlight the greatness of Fedora as well as to
reflect my strong desire to see this project take off and propel the Linux
OS to new heights.
First suggestions has to do with the software side of things. We users need
a competent software installer which is graphical based. One that functions
much the same way that the windows installer works. This installer should
track dependencies naturally and place icons on the desktop or give the
option to have icons for the software just installed to be placed on the
desktop of the user as well as in the applications menu. Also when watching
the Boston Linux conference the suggestion was made to offer a hard disc
manager much like windows offers for formating and receiving hard drivers
etc after installation.
My second set of suggestions will deal with the over all focus and structure
of the fedora project. I was listening to a pod cast interview with the head
of the fedora project where in, the topic came up of some how generating
revenue to put back into the project and make it more self sufficient. So I
have a few suggestions which I think the Redhat company itself should take
note of. Firstly Redhat while promoting Linux among enthusiast is also in
the business of making money. On that front I believe that they should not
only attempt to evangelize Linux in the government, education, and corporate
sectors; they should also attempt to get Linux in each and every home. The
reason being is if people are starting to use Linux in their homes and they
are comfortable with it, employers will be more likely and willing to deploy
a operating system which is different in many ways to windows on the
interactive level. Reason being is when people have to stop to learn new
technology this cuts down on productivity and as a person who works for a IT
department in a major university I can also vouch for the fact a IT team
will not be willing to suggest an infrastructure restructuring when they
know, supporting users on something foreign to them is going to increase
their workload 10 fold. So bottom line, more users both advanced,
intermediate and beginners need to be converted to the Linux faithful but
now the question becomes how?
The Fedora project is the perfect tool for this and here is how. The fedora
team should focus SOLELY on making the operating system run as smoothly and
as fast as possible, interacting with a HUGE number of hardware
configurations. Installation needs to be as smooth as silk and upgrading
needs to be fail proof from version to version. Previously installed drives
with personal user data needs to be able to be retained without fail from
upgrade to upgrade if the user isn't doing a clean install. Now I would like
to move on to "partnerships" Fedora project should look into making
"partners" or some other creative term to define other Linux projects and
organizations. In this partnership Fedora will tightly enforce standards
which will ensure that any software created to run on fedora is following
say the OIN and the GPL standards to the letter to ensure an user friendly
and secure/stable operating system that runs smoothly. Many people in the
Linux community may grumble about this suggestion however life is about
progression and when things do not change and evolve and progress to new
levels then they are doomed to become extinct (think dinosaurs here) or at
the very least remain niche applications. If Fedora project implements such
a model, they do not have to worry about making certain software for the OS
which would take far to much time and man power to create. Prime example
would be the hard disk manager or even the software installer. This sort of
work could be left to groups who's soul purpose is to make such software and
by following strict guidelines they would become Fedora project "partners"
and in turn they would be promised that their software will be included in
the fedora core release. Also by following strict guidelines this software
could be implemented in other Linux distributions which are also following
said guidelines. This would take the pressure off of Fedora and they can
then focus on whats important which is making their OS run like silk. Again
let me stress this approach is keeping in mind that projects such as Fedora
and other Linux distributions desire to penetrate more into the home desktop
market, which then also means more users will or could eventually equate to
greater adoption of the platform in other industries as a result of user
awareness and user comfort with the Linux platform. I should also mention
that those software development groups that do not comply could be offered
as Fedora extras so the community still has choices which is really part of
the appeal of Linux.
Okay so with all that said how could this generate income? Well lets say
Fedora project comes up with one of the first 100% standard enforced
distributions which is as user friendly or even more so than MS windows. Now
say a "ambassador" from Fedora can start making the rounds to Dell and other
companies and attempt to get them to start offering this FREE Linux
distribution on some of their PC models, which would also allow for lower
prices on the retail side for them (ie Dell, Gateway etc.) as the OS is FREE
and that cuts down on cost which the end user ends up incurring. But we
still have not addressed revenue for the Fedora project, and this can be
done by following the Redhat model of offering technical support. Fedora
project could basically offer technical support certification and training
to Dell staff as an example so they (the PC manufacturer) can then take over
supporting the platform for their end users, which also equates to revenue
for these companies in the long run because they can offer extended tech
support to end users at a premium. Fedora core could charge a VERY minimal
fee for this training, so say charge enough that it would generate revenue
that can then be pumped back into the project and at the same time would
still make it cheaper for Dell and other companies to go with Linux on some
desktop offerings as opposed to having a windows only offering.
The future of Linux if to be taken seriously should not be relegated to just
the business, government, and education world as far as standards,
reliability, and software / hardware vendor support is concerned. The brand
will grow far more rapidly if consumers are adopting the standard at home
and at work so basically this is a bottom up approach. This of this, more
desktop users in the home also means more software sales for major companies
because you will have more people buying video games and other such things
which will also mean more companies willing to adopt the platform because
software offering become greater.
There needs to be a consorted effort on the parts of all parties involved to
take Linux to that next phase of existence other wise Linux as a brand,
while it may grow some what will not see its full potential. With the
software being a open and free model we still have to realize with a flurry
of hodge podge coding and no standards insight the end user ends up losing
at least as far as the home front is concerned. Most people are forced to
run duel boot Windows and Linux systems because software makers and hardware
manufactures have not fully bought into the Linux model and we as a
community only have ourselves to blame for that. This approach will also
take some evangelizing to the software makers of such things as yum and KDE
however I believe that those who do not see the need and importants of doing
such things will render themselves obsolete in the long run. Just look at
the Unix model, and we can see what the disasters of not doing this can
incur.
18 years
New Ideas - how about a GUI for /etc/fstab
by G.Wolfe Woodbury
There are some automatic tools that manipulate parts of the fstab,
but there isn't a GUI that understands all of the various pieces and
options that go into the fstab of a Fedora Core system.
It would be nice if there were a GUI editor that would allow the addition
of NFS, CIFS and other network filesystems to the fstab with some handling
of the options that they require.
Submitted for discussion.
18 years
yum + mulitarch + updates
by dragoran
I have noticed that when I have package foo-1.0.i386 installed and some
other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the
i386 one.
(livna mplayerplug-in was it here).
Updates should not be crossarch a i386 package should only be updated to
a i386 one (same for x86_64).
Any reason for doing this? Or is this a bug thats needs to be filled?
18 years
Mozilla in FC6
by Bojan Smojver
So, what was the conclusion regarding Mozilla in FC6 (i.e. as a set of
libs for things like Epiphany)? Is it being dropped in favour of FF or
is it staying?
Don't want to start a flame war, just being curious...
--
Bojan
18 years
