Re: Status and outlook of LSB and FHS compliance of Fedora. -- sed -e g/lsb/fhs/i
by Bryan Smith
Bryan J. Smith _ignorantly_ wrote:
> So, LSB has gone from merely documenting and unifying "best practices" to
> actually creating its own, new standards? Is it LSB's intent to "de-UNIX"
> Linux and create anew?
Alan Cox wisely corrected:
> FHS is not an LSB creation. It was an existing body that the LSB chose
> to use as a reference
Oh, my ignorance. My sincerest apologies to anyone with LSB for this very
grave ignorance of mine. Thanx for pointing that out Alan (I think I should
shut up for awhile after this post ;-).
So the FHS is behind this? Is so, my previous post applies to FHS:
sed -e g/lsb/fhs/i
[ BTW, I read through the FHS bugs on this and I still don't understand it.
And I don't like creating new TLD for user files. Automounter, /home, /var,
/tmp seem to do their jobs quite nicely IMHO. ]
-- Re-edit: --
http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00101.html
So, FHS has gone from merely documenting and unifying "best practices" to
actually creating its own, new standards? Is it FHS's intent to "de-UNIX"
Linux and create anew?
By introducing new TLDs, these seems to be the case.
Why does LFHS wish to create more work for itself and everyone?
<suggestion>
If they want to do anything, they should create a _single_ TLD.
Maybe call it, obviously, /fhs, and then symlink everything
under it (or everything that can be).
</suggestion>
<rant/opinionated>
To give my opinion, this sounds like an entity that has moved from
standardization efforts to justifying itself with classic beaucratic
BS. And I thought the IEEE was bad at times, at least they try to
minimize impact and involve vendors in such decisions.
I just can't understand why _anyone_ would agree to TLD changes.
Things that go directly against the history of UNIX. Things that
don't change much. Are we going to start being like Microsoft where
we change things all the time?
I think UNIX has evolved, while imperfect, better than any other OS.
Things are in Linux out of Darwinism. Something I think "standards"
that are not written to document/unify "beset practices" but move
people elsewhere to where they "think" they should be are self-
defeating.
</rant/opinionated>
But I am not in a position to offer such opinions.
I have not contributed to the Fedora project in any formal capacity.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 10 months
RE: RPM filesystem?
by Erik LaBianca
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
> bounces(a)redhat.com] On Behalf Of Jos Vos
> Sent: Thursday, June 03, 2004 11:48 AM
> To: Development discussions related to Fedora Core
> Subject: Re: RPM filesystem?
>
> On Thu, Jun 03, 2004 at 10:31:51AM -0400, Tim Daly wrote:
>
> > RPMS might not be the very best format for compressed packages but
> > they could make a convenient starting point. Fedora extras would
> > be so much sweeter if you only needed to mount the DVD containing
> > the RPMS and it all "just worked".
>
> Interesting idea... but at leat the pre/post-install scripts, that
> are needed in many cases (e.g. ldconfig) cause significant problems
> if you would implement such a beast.
>
I don't think rpm in its current state is the tool to handle this. It's
designed to provide reproducible from-source builds and to maintain an
on-disk collection of files. Pre/post scripts are pretty integral to its
functionality, as are mutable configuration files.
It seems to me what you're asking for is something like Mac OS X
application bundles, which are a pretty cool idea for any sort of
application code. I don't know exactly how they do it, but a simple way
to install an application by sticking its compressed bundle somewhere
would be VERY cool for the commercial software folks, etc.
At some point I think rpm either needs to diverge into another tool for
handling applications, or another tool will have to be created to do
this sort of thing. Library dependencies are and will continue to be a
big problem for outside distributors trying to produce rpm's of their
applications. LSB folks have been working on some of these issues, I
think.
--erik
19 years, 10 months
3ware 9500
by Peter Maas
Dear Sirs:
3ware had released new drivers for there 9500S series ide raid cards under
the GNU GPL, the current kernel drivers support up to the 8500 Series. What
is necessary to have to have these drivers added to the redhat
kernel(hopefully linus's kernel also)? I have the source that is shipped
with the card if needed.
Thank You
Peter Maas
fedora(a)rooker.dyndns.org
19 years, 10 months
rawhide report: 20040603 changes
by Build System
Updated Packages:
bash-2.05b-39
-------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 2.05b-39
- Build requires libtermcap-devel (bug #125068).
* Wed May 19 2004 Tim Waugh <twaugh(a)redhat.com>
- Don't ship empty %{_libdir}/bash (bug #123556).
coreutils-5.2.1-12
------------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 5.2.1-12
- Don't call access() on symlinks about to be removed (bug #124699).
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 5.2.1-11
- Fix ja translation (bug #124862).
cups-1.1.20-15
--------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 1:1.1.20-15
- Build on ppc and ppc64 again.
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 1:1.1.20-14
- ExcludeArch ppc, ppc64.
- More D-BUS changes.
desktop-printing-0.9-1
----------------------
* Wed Jun 02 2004 Colin Walters <walters(a)redhat.com> 0.9-1
- Insert my tendrils into this package
- Bump version 0.9, just for fun
- Update to eggcups 0.9
- Remove desktop file link and stuff, we don't need it
- Remove deps on system-config-printer, etc
- Remove upstreamed eggcups patches
- Change description to remove "Nautilus"
- Bump dbus deps to >= 0.20
dictd-1.9.7-1
-------------
* Wed Jun 02 2004 Karsten Hopp <karsten(a)redhat.de> 1.9.7-1
- update
elinks-0.9.1-3
--------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 0.9.1-3
- Build with LFS support (bug #125064).
ethereal-0.10.4-1
-----------------
* Wed Jun 02 2004 Phil Knirsch <pknirsch(a)redhat.com> 0.10.4-1
- Update to latest version 0.10.4.
fonts-ja-8.0-13
---------------
* Thu Jun 03 2004 Akira TAGOH <tagoh(a)redhat.com> 8.0-13
- add BuildRequires: xorg-x11-font-utils (#125032)
gimp-2.0.1-6
------------
* Mon May 31 2004 Nils Philippsen <nphilipp(a)redhat.com>
- rebuild for Rawhide
* Wed May 26 2004 Nils Philippsen <nphilipp(a)redhat.com>
- add libjpeg-devel to BuildRequires (#121236)
- spit out slightly more informative help message if gimp-help is missing
(#124307)
* Fri May 21 2004 Matthias Clasen <mclasen(a)redhat.com>
- rebuild
irda-utils-0.9.16-1
-------------------
* Wed Jun 02 2004 Karsten Hopp <karsten(a)redhat.de> 0.9.16-1
- update
joe-3.1-1.2
-----------
* Tue Jun 01 2004 Lon Hohberger <lhh(a)redhat.com> 3.1-1.2
- Rebuild
* Tue Jun 01 2004 Lon Hohberger <lhh(a)redhat.com> 3.1-1
- Import 3.1 from upstream
- Include mktemp behavior from #124462
kdebindings-3.2.2-2
-------------------
* Wed Jun 02 2004 Than Ngo <than(a)redhat.com> 3.2.2-2
- remove -O0 on ia64
kdelibs-3.2.2-8
---------------
* Wed Jun 02 2004 Than Ngo <than(a)redhat.com> 6:3.2.2-8
- remove -O0 on ia64
kernel-2.6.6-1.411
------------------
* Wed Jun 02 2004 Arjan van de Ven <arjanv(a)redhat.com>
- add a forward port of the mlock-uses-rlimit patch
- add NX support for x86 (Intel, Ingo)
libgnomecups-0.1.6.cvs20040602-1
--------------------------------
* Wed Jun 02 2004 Colin Walters <walters(a)redhat.com> 0.1.6.cvs20040602-1
- Update to latest CVS
- Include Matthias' and my patch that makes remote queues
work, etc.
rpmdb-fedora-2-0.20040603
-------------------------
sane-backends-1.0.14-1
----------------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 1.0.14-1
- 1.0.14.
* Wed May 12 2004 Tim Waugh <twaugh(a)redhat.com>
- s/ftp.mostang.com/ftp.sane-project.org/.
sane-frontends-1.0.12-1
-----------------------
* Wed Jun 02 2004 Tim Waugh <twaugh(a)redhat.com> 1.0.12-1
- 1.0.12.
* Wed May 12 2004 Tim Waugh <twaugh(a)redhat.com>
- s/ftp.mostang.com/ftp.sane-project.org/.
selinux-policy-strict-1.13.3-1
------------------------------
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.3-1
- Update to latest from NSA
- Fix numerous bugs
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.2-7
- Fix su policy for terminal rename with new pam_selinux.
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.2-6
- Fix policy for setfiles and restorecon
selinux-policy-targeted-1.13.3-1
--------------------------------
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.3-1
- Update to latest from NSA
- Fix numerous bugs
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.2-7
- Fix su policy for terminal rename with new pam_selinux.
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.13.2-6
- Fix policy for setfiles and restorecon
setools-1.4-1
-------------
* Wed Jun 02 2004 Dan Walsh <dwalsh(a)redhat.com> 1.4-1
- Update to latest from TRESYS.
* Tue Jun 01 2004 Dan Walsh <dwalsh(a)redhat.com> 1.3-3
- Make changes to work with targeted/strict policy
* Fri Apr 16 2004 Dan Walsh <dwalsh(a)redhat.com> 1.3-2
- Take out requirement for policy file
system-config-display-1.0.15-1
------------------------------
* Wed Jun 02 2004 Alex Larsson <alexl(a)redhat.com> 1.0.15-1
- fix --reconfig and catch some exceptions for readonly root
* Tue May 25 2004 Brent Fox <bfox(a)redhat.com> 1.0.14-2
- add BuildRequires for desktop-file-utils (bug# 124181)
vim-6.2.532-3
-------------
* Wed Jun 02 2004 Karsten Hopp <karsten(a)redhat.de> 6.2.532-3
- rebuild
* Wed Jun 02 2004 Karsten Hopp <karsten(a)redhat.de> 6.2.532-2
- rebuild
* Tue Jun 01 2004 Karsten Hopp <karsten(a)redhat.de> 6.2.532-1
- patchlevel 532
- include vimrc in vim-minimal (#123205)
- add gvim icons (#110033)
xboard-4.2.7-4
--------------
* Wed Jun 02 2004 Karsten Hopp <karsten(a)redhat.de> 4.2.7-4
- add some buildrequires (#125034)
xhtml1-dtds-1.0-7
-----------------
* Wed Jun 02 2004 Daniel Veillard <veillard(a)redhat.com> 1.0-7
- add BuildRequires: libxml2, fixes 125030
* Mon Feb 23 2004 Tim Waugh <twaugh(a)redhat.com>
- Use ':' instead of '.' as separator for chown.
19 years, 10 months
[OT-Slashdot] McAfee Granted Far-Reaching Spam-Control Patent
by Chris Kloiber
Posted by timothy on Wednesday June 02, @08:01AM
from the what-the-system-isn't-meant-for dept.
Titusdot Groan writes "Infoworld is reporting that Network Associates,
makers of McAfee, have been granted a broad anti-spam patent. The patent
covers "compound filters, paragraph hashing, and Bayes rules" and was
filed in December of 2002. The patent appears to affect Spam Assassin,
Spam Bayes and many other anti-spam products and services. As an aside
Paul Graham's "A Plan for Spam" was published August 2002."
http://yro.slashdot.org/yro/04/06/01/2315239.shtml?tid=111&tid=126&tid=15...
<rant>
I almost (but not quite) wish that all linux distributions would yank
all the spam control projects out aka the multimeda stuff, and we allow
spam to go unchecked for a while. Then when the *net melts down we can
tell the idiotic governments of the world that this is all the fault of
software patents. So ban software patents now.
</rant>
--
Chris Kloiber <ckloiber(a)ckloiber.com>
19 years, 10 months
Re: Status and outlook of LSB and FHS compliance of Fedora. -- "standards"
by Bryan Smith
Chris Chabot wrote:
> Please let me begin by comming out and admitting that this whole /svr
> *edit* seems quite silly to me.
> The reasoning behind /svr is described in FHS-2.3 as: "This main purpose
> of specifying this is so that users may find the location of the data
> files for particular service and so that services which require a single
> tree for readonly data, writable data and scripts (such as cgi scripts)
> can be reasonably placed"
So, LSB has gone from merely documenting and unifying "best practices" to
actually creating its own, new standards? Is it LSB's intent to "de-UNIX"
Linux and create anew?
By introducing new TLDs, these seems to be the case.
Why does LSB wish to create more work for itself and everyone?
<suggestion>
If they want to do anything, they should create a _single_ TLD.
Maybe call it, obviously, /lsb, and then symlink everything
under it (or everything that can be).
</suggestion>
<rant/opinionated>
To give my opinion, this sounds like an entity that has moved from
standardization efforts to justifying itself with classic beaucratic
BS. And I thought the IEEE was bad at times, at least they try to
minimize impact and involve vendors in such decisions.
I just can't understand why _anyone_ would agree to TLD changes.
Things that go directly against the history of UNIX. Things that
don't change much. Are we going to start being like Microsoft where
we change things all the time?
I think UNIX has evolved, while imperfect, better than any other OS.
Things are in Linux out of Darwinism. Something I think "standards"
that are not written to document/unify "beset practices" but move
people elsewhere to where they "think" they should be are self-
defeating.
</ran/opinionated>
But I am not in a position to offer such opinions.
I have not contributed to the Fedora project in any formal capacity.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 10 months
systematic Kerberization
by Havoc Pennington
Hi,
Something we've wanted to do for a long time is create a matrix of
programs that should support Kerberos authentication, and start checking
them off. I guess this includes both client-side and server-side.
Does anyone have a good start on this?
Any real-world experience/scenarios where Kerberos support was needed
and not available? (Which things should be Kerberized first?)
Havoc
19 years, 10 months
Re: [Jackit-devel] Re: fc2, xorg, 2.6.x, scheduling latency peaks
by Fernando Lopez-Lezcano
> > > Aha! I think you are on to something! I double checked the priority of
> > > the jack clients and _they_ are not getting SCHED_FIFO!! They should be
> > > getting that priority from the jack server but they are not (and the
> > > jack server is not complaining at all so no error is being raised).
> > > Probably some change in glibc, I would think...
>
> I had begun to notice some of this, too. But, I hadn't figured out
> what was going on.
I have been banging my head on walls for a while trying to find out what
was causing the xruns...
> > Just confirmed this with a first preliminary hack (and test). Jack
> > creates new threads and to do that it sets up a pthread_attr_t struct
> > and uses pthread_attr_setschedpolicy and pthread_attr_setscope to set
> > the scheduling policy (and also sets the priority) in the struct. Then
> > pthread_create is called (with that struct as an argument) and the
> > thread is created. But the thread created is _not_ SCHED_FIFO and there
> > is no error return. If _after_ the thread is created I double check the
> > scheduling policy and use pthread_setschedparam to again set it to
> > SCHED_FIFO then the thread changes to SCHED_FIFO... go figure...
>
> Is this only with NPTL or on any 2.6.6 system?
I have only tested on FC2 and 2.6.6. I presume this means NPTL.
-- Fernando
19 years, 10 months
Re: Why are there only i686 and i586 Version of glibc and kernel? -- 486 ISA, WinChip
by Bryan Smith
Alan Cox wrote:
> Every example you give is 486 or higher ISA, as are the others you
> missed that I am aware of - SiS55x for example. Going 386->486 makes
> a really big difference.
Yeah, I'm starting to realize that (remember back to when I first looked
that Intel codebooks). The paging is definitely a major plus, along
other things.
I think I conceded it in this post:
http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00039.html
"The rule of thumb is, everything that can be built for 386 ISA,
should be built for it. Optimize for 686 architectures (PPro/II+,
Athlon, etc...), but make it 386 ISA compatible. If that is not
possible (e.g., NPTL), then 486 ISA."
But otherwise we agree on the "target 486, optimize PPro"?
Alan Cox wrote:
> 240. And it runs 586 code. Trust me I've got one 8)
240MHz sounds more like a WinChip2 with the pipelined FPU?
But if you say it's an original WinChip, I'll believe you.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 10 months
Re: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around
by Bryan Smith
Leonard den Ottolander wrote:
> This issue was discussed in the thread "Making NPTL the default for
> FC3, vanilla i386 support". Both i386s and i486s are already no longer
> supported since FC 1. Try running rpm on either of these CPUs and see
> it fail. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
FYI, the original Cyrix 686 (M1?) was only i486 compatible. You had to go
with the 686"L" or M2 to get full i586 ISA compatibility.
Frankly, I don't think people recognize the _real_ reason for trying to
keep i386/486 ISA compatibility. It's not to support old systems, but to
support i386/486 ISA embedded microprocessor cores in all sorts of black
box solutions. These solutions have full desktops/GUIs far more than you
may think.
All it takes is one major black box vendors to adopt Fedora and we're
talking over a 1% marketshare.
GCC still pumps out i386 ISA code, while making other optimizations. So
anything that has a patch or otherwise that breaks this should be
revisited. So there is still a good reason to strive for i386/486 ISA.
> So if there is the intention of making the move to i486 as the minimum
> arch we could just as well make the jump to i586.
I would continue to favor i386 with i686 (Pentium Pro) optimizations.
i586 (Pentium) causes a lot of de-optimizations in newer processors, even
Intel's own. Why? Understand that about 80% of "Pentium optimizations"
were really "errata workarounds." The Pentium was the first superscalar
x86 design, and boy did it have some real muck-ups that had to be
compensated in software (like the ALU LOAD being 3x slower, which id
found it far faster to load via integers via the FPU instead).
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 10 months