It's unlikely that you would ever be running SELinux without knowing it. Yes, it comes with distros like RHEL4, but it's not turned on.
It's enabled in enforcing mode by default in Fedora Core 6 and Red Hat Enterprise Linux 5. See how unobtrusive it is? People don't even know it's on;-)
On a side note, someone did mention yum to me I'm not sure if it's available on RHEL because of the reasons stated above. You can use fedora rpms in it but apparently that can bork the system and for a production machine it's not worth testing.
yum is included as part of Red Hat Enterprise Linux 5, but it's not in any of the earlier releases.
> Netscape released their version based on a release of Firefox with security holes when a patched version of Firefox already existed.
It's not as cut and dry as that. There is an extensive QA process that companies such as Netscape go through. They probably had builds in testing for a few days before the Firefox vulnerability was announced publically.
Netscape decides when to release and when not to, and what fixes to include and what not to. They could have reasonably released a day later to address the fixes, but they had a deadline to meet, and they chose to meet it.
> Do you think this has a chance of being addressed if I did file a bug?
As opposed to the no chance you'd get without filing one? Yes. For what it's worth, it was tried at one point (you can find.spec files in older sources I think). I'm unsure as to why it still isn't the case.
> Its not done till I can install it in a way that won't screw up my system later on down the track. > Mozilla makes great software, but never finishes it - that's for the distro packagers to do.
And you didn't really finish your comment. What specific qualms do you have? Please clarify. And even better, please make sure a bug is filed at bugzilla.mozilla.org
> If Dag and the Debian guy (and whoever else for whatever other distro) could hook up with the Moz people, you'd have a much better experience.
Red Hat, IBM, Sun, and a few other distributors have people in touch with the Moz guys. In fact, all of those companies employ people to specifically work on Mozilla.
This particular bug has been in bugzilla for quite some time. Not sure why you think it was fixed "immediately".
Because it was fixed immediately. The bug that has been around for 2 years is requesting a generic solution and a policy change, not a specific solution for a specific problem. Furthermore, the generic bug is as of yet unpatched. How can an unpatched bug be the shell bug if there is a patch, xpi and new release to fix the shell hole? Granted, a solution for that generic bug would have prevented this specific bug altogether, however it does not change the fact that the specific bug with regard to shell was fixed immediately.
Odd that their website says as low as $2. Their press release [PDF] dated today (October 1st, 2003) says:
With the support of Atari, StarROMs is trying to do for classic video games what Apple's I-Tunes is doing for on-line music. StarROMs prices range from 99 cents to $6 per video game title.
Well, if the claims are true and they are using copyrighted music, the RIAA and record labels have shown in the past that they will go after people with out caring who they are. They have no direct connection to the Matrix (AFAICS), and it wouldn't matter to them whether they are sincere fans of the movie or bootleggers. I wonder if the fanimatrix people tried contacting the copyright holders....
Their disclaimer says "Although copyrighted materials (e.g. music and sound fx) do appear in this film, we hope that the spirit of goodwill will prevail in allowing us to feature their work on our movie in the hopes that it will promote their own talents."
I like the idea, but it seems far fetched that the copyright holders will actually go for this...
> If SCO wins their case against IBM, that will pretty much invalidate the GPL for Linux, at least in respect to IBM contributions.
I don't see how SCO winning defeats the GPL. IANAL, but AFAICT, the point upon which SCO's case relies upon is whether proprietary code owned by SCO was put into the linux source by IBM without permission. The GPL provides safety against that with...
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.
...and if they win the case, it would potentially reinforce that section of the GPL. It seems to me that IBM is trying to get SCO on clause 7 which says...
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
Also, don't forget that many contracts tend to follow that if one thing is found by a court to be illegal, the rest of the contract shall remain in full effect. So it seems to me that IBM's suit does have some merit. It may be possible that one portion is found to be illegal, while other portions stand. It should be fun to watch this pan out.
> Uh... When I heard the term "restricted music", I have the mental image of "Parental Advisory: Explicit Lyrics" or something like that. Maybe "copyrighted music" is a better term?
No, that's redundant. All music is (implicitly) copyrighted by the authors who generally transfer the copyrights to record labels as part of their record deal. I'd suggest "music the record labels don't want you to copy" but that's just as redundant.
There has been a native SVG implementation in the Mozilla tree available for ages. In the 0.9.7 or 0.9.8 time frames, IIRC. However, it will not be turned on by default in any build because it requires libart which is licensed as LGPL only.
Mozilla.org has already refuted allowing it be distributed by default in the bug which allowed libart to be checked in to the tree under the other-licenses/ directory of the cvs repository. The reasoning was that Mozilla sources are released under the MPL and the extra license could potentially cause extra headaches for distributors (as far as ensuring compliance with them, keeping track of them, etc.). Additionally, there are already enough licenses for distributors to deal with, and Mozilla.org should be looking to decrease that number, not increase it.
Without a doubt, Netscape has been the largest single contributor to the Mozilla project. Of course, they want to see Mozilla (and their Netscape branded derivative in particular) succeed. But Netscape does not control the project. Sure, they have their influences with what their developers work on, but there's nothing wrong with that. Outside contributors have their influence of what they work on too.
You said "Mozilla is furthering the agenda of a very large corporation" which I would agree with. Mozilla furthers the agenda of several other companies as well: OEone, ActiveState, IBM, etc... But Mozilla could not do that alone. If Mozilla has played a part in furthering Netscape's agenda, Netscape has played an even bigger part in furthering Mozilla's agenda. The staff and drivers of mozilla.org try hard to ensure that happens.
This may not be the best example (there are many others that would suit better) but I was reading bug 7 0 7 4 6 at the time, and figured I would post a few comments from it:
------- Additional Comment #13 From Blake Ross 2001-03-20 14:35 -------
By the way, having sat on these changes for over two weeks (and enduring multiple merge conflicts), I'm not particularly interested in waiting until someone finds the time to fix the other commercial cases. These changes are going to break Alphanumerica and MozDev products also, as well as potentially any other xul-based app out there, and while I'm certainly willing to help, they're not waiting until every commercial vendor's branch is ready (such is pre-1.0 development).
------- Additional Comment #17 From David Hyatt 2001-03-20 16:21 -------
Blake, I feel your pain, but I work for Netscape, and therefore can't approve a patch that will bust up the commercial tree.
Are there any volunteers to convert the rest of commercial (outside of AIM)? I would do it myself, but this kind of bug just kills my hands.
------- Additional Comment #18 From Mike Shaver 2001-03-20 17:05 -------
Hyatt: acting as module owner, you certainly _can_ permit a change that will break a closed source base, especially after the developer (Blake) has gone to such reasonable lengths to get someone to fix said closed source base. There are lots of other source trees, as Blake points out, that will break because of this (in the short term), and he's offered to help with the ones whose authors are not actively preventing them from providing such assistance (as is Netscape/AOL, in this case). We held off until 0.8.1 to minimize the pain of this checkin, and the time has come to bear what pain remains.
If you don't feel that your employer will let you fulfill your Mozilla-module-owner responsibilities, please let us know, because that's the kind of problem that we have to solve quickly.
------- Additional Comment #19 From Brendan Eich 2001-03-20 17:42 -------
Module owners whose employers pay them to keep commercial add-ons working along with their Mozilla modules have to wear two hats: one for their employer, one for Mozilla. If there's a conflict, Mozilla wins, or we need a new module owner (at least _pro tem_). Life's rough. Let's get these changes landed.
It sounds like all but Mac builds have been tested in any case. True?
No. The patch was a 1 liner. patch -R would have either reverted it completely or not at all. I would imagine that the file in question was hand edited. The eHTMLTag_userdefined portion was removed but the 9 was not changed back to an 8.
"The Mozilla team had been alerted to major bugs which only recently appeared in the browser"
Sorry. Just because you filed a bug and posted a comment on another does not mean the Mozilla team was alerted. If there is a showstopper bug, filing it in Bugzilla does not guarantee it will get noticed if everyone is busy with final preparations for a release, and trying to get ready for the impending alpha. Don't forget that the people involved with Mozilla get tons of email from bugs, review requests, etc. as well as have real lives in which they eat turkey and go Christmas shopping. Bugs sometimes slip through the cracks. Hop on to IRC next time and make sure that one of the drivers, or even a developer or QA person knows about your bug if you think it is an absolute showstopper.
It definitely sucks that this bug was in a release. But things happen. Hopefully it won't again.
I'm surprised that: A) this is considered a serious bug--who actually uses DHTML? and B) they're "recalling" the release, as it were. Tainted Mozilla meat.
Is it not enough reason that this is a bug? We should stop release for all bugs! But seriously....
A big reason is that DHTML is pretty much just a way of saying the W3C DOM and a few DOM Level 0 (no spec) APIs. This bug effectively cripples our standards support and I would definitely call that serious.
On top of that, with every release, there is a chance that some embeddor will want to base their product off of it. Embeddors generally like DHTML, and this would be a show stopper for them.
yum is included as part of Red Hat Enterprise Linux 5, but it's not in any of the earlier releases.
> Netscape released their version based on a release of Firefox with security holes when a patched version of Firefox already existed.
It's not as cut and dry as that. There is an extensive QA process that companies such as Netscape go through. They probably had builds in testing for a few days before the Firefox vulnerability was announced publically.
Netscape decides when to release and when not to, and what fixes to include and what not to. They could have reasonably released a day later to address the fixes, but they had a deadline to meet, and they chose to meet it.
> Do you think this has a chance of being addressed if I did file a bug? As opposed to the no chance you'd get without filing one? Yes. For what it's worth, it was tried at one point (you can find .spec files in older sources I think). I'm unsure as to why it still isn't the case.
> Its not done till I can install it in a way that won't screw up my system later on down the track.
> Mozilla makes great software, but never finishes it - that's for the distro packagers to do.
And you didn't really finish your comment. What specific qualms do you have? Please clarify. And even better, please make sure a bug is filed at bugzilla.mozilla.org
> If Dag and the Debian guy (and whoever else for whatever other distro) could hook up with the Moz people, you'd have a much better experience.
Red Hat, IBM, Sun, and a few other distributors have people in touch with the Moz guys. In fact, all of those companies employ people to specifically work on Mozilla.
Because it was fixed immediately. The bug that has been around for 2 years is requesting a generic solution and a policy change, not a specific solution for a specific problem. Furthermore, the generic bug is as of yet unpatched. How can an unpatched bug be the shell bug if there is a patch, xpi and new release to fix the shell hole? Granted, a solution for that generic bug would have prevented this specific bug altogether, however it does not change the fact that the specific bug with regard to shell was fixed immediately.
Wouldn't that be covered by a simple NDA?
Odd that their website says as low as $2. Their press release [PDF] dated today (October 1st, 2003) says:
Don't forget about users of laptops and other portable devices who occasionally do turn their machines off.
http://www.csulb.edu/colleges/coe/ae/rockets/aeros pike/ft-1/flight-1.htm
Come on, its not like it's rocket science or anything... ;-)
> Did you notice that Animatrix and Fanimatrix actually end with 'matrix' not just 'trix'?
Um, actually they end with 'animatrix'.
Well, if the claims are true and they are using copyrighted music, the RIAA and record labels have shown in the past that they will go after people with out caring who they are. They have no direct connection to the Matrix (AFAICS), and it wouldn't matter to them whether they are sincere fans of the movie or bootleggers. I wonder if the fanimatrix people tried contacting the copyright holders....
Their disclaimer says "Although copyrighted materials (e.g. music and sound fx) do appear in this film, we hope that the spirit of goodwill will prevail in allowing us to feature their work on our movie in the hopes that it will promote their own talents."
I like the idea, but it seems far fetched that the copyright holders will actually go for this...
> If SCO wins their case against IBM, that will pretty much invalidate the GPL for Linux, at least in respect to IBM contributions.
I don't see how SCO winning defeats the GPL. IANAL, but AFAICT, the point upon which SCO's case relies upon is whether proprietary code owned by SCO was put into the linux source by IBM without permission. The GPL provides safety against that with...
...and if they win the case, it would potentially reinforce that section of the GPL. It seems to me that IBM is trying to get SCO on clause 7 which says...
Also, don't forget that many contracts tend to follow that if one thing is found by a court to be illegal, the rest of the contract shall remain in full effect. So it seems to me that IBM's suit does have some merit. It may be possible that one portion is found to be illegal, while other portions stand. It should be fun to watch this pan out.
No, that's redundant. All music is (implicitly) copyrighted by the authors who generally transfer the copyrights to record labels as part of their record deal. I'd suggest "music the record labels don't want you to copy" but that's just as redundant.
Mozilla.org has already refuted allowing it be distributed by default in the bug which allowed libart to be checked in to the tree under the other-licenses/ directory of the cvs repository. The reasoning was that Mozilla sources are released under the MPL and the extra license could potentially cause extra headaches for distributors (as far as ensuring compliance with them, keeping track of them, etc.). Additionally, there are already enough licenses for distributors to deal with, and Mozilla.org should be looking to decrease that number, not increase it.
http://www.nytimes.com/2002/12/18/movies/18LORD.ht ml
Why not read the Ogg Vorbis FAQ about this?
You said "Mozilla is furthering the agenda of a very large corporation" which I would agree with. Mozilla furthers the agenda of several other companies as well: OEone, ActiveState, IBM, etc... But Mozilla could not do that alone. If Mozilla has played a part in furthering Netscape's agenda, Netscape has played an even bigger part in furthering Mozilla's agenda. The staff and drivers of mozilla.org try hard to ensure that happens.
This may not be the best example (there are many others that would suit better) but I was reading bug 7 0 7 4 6 at the time, and figured I would post a few comments from it:
FWIW, the patch was:
"The Mozilla team had been alerted to major bugs which only recently appeared in the browser"
Sorry. Just because you filed a bug and posted a comment on another does not mean the Mozilla team was alerted. If there is a showstopper bug, filing it in Bugzilla does not guarantee it will get noticed if everyone is busy with final preparations for a release, and trying to get ready for the impending alpha. Don't forget that the people involved with Mozilla get tons of email from bugs, review requests, etc. as well as have real lives in which they eat turkey and go Christmas shopping. Bugs sometimes slip through the cracks. Hop on to IRC next time and make sure that one of the drivers, or even a developer or QA person knows about your bug if you think it is an absolute showstopper.
It definitely sucks that this bug was in a release. But things happen. Hopefully it won't again.
Is it not enough reason that this is a bug? We should stop release for all bugs! But seriously....
A big reason is that DHTML is pretty much just a way of saying the W3C DOM and a few DOM Level 0 (no spec) APIs. This bug effectively cripples our standards support and I would definitely call that serious.
On top of that, with every release, there is a chance that some embeddor will want to base their product off of it. Embeddors generally like DHTML, and this would be a show stopper for them.
cvs up -r MOZILLA_1_2_BRANCH mozilla/client.mk
cd mozilla/
gmake -f client.mk
Of course, that source is apt to change and is not necessarily the final 1.2.1 release, blah blah blah...