Well, this is really off the wall. I find it hard to believe that the last 3 Fedora releases all worked fine, yet RHEL5 does not. Perhaps it was based on Fedora Core 4? It doesn't sound all that old.
In case you hadn't noticed, "ls -Z" and "ps -M" are helpful.
Common problem: you built a library (a *.so file) without compiling all the object files (the *.o things) with gcc's -fpic or -fPIC option, and/or you forgot to specify -shared when linking.
When you make this kind of screw-up, you cause something called "text relocations". These don't even work on non-x86 and Debian bans them anyway for reasons related to memory usage. A text relocation means that the loader patches the code itself, rather slowly, when loading the shared library. This requires memory to be both writable and executable, which is a no-no for security against buffer overflows. SE Linux is usually set up to prohibit this by default.
If your broken shit runs as a server or gets loaded into a web browser, you greatly decrease security. You suck. Fix your shit.
I'm a developer too. I've upped my standards. Up yours!
Granted, I'm using something a tad different. I've used all three of Fedora Core 5, Fedora Core 6, and Fedora 7. Not a one of them have had SE Linux prevent yum from working. I just su to root and install stuff. I can't imagine that RHEL would be worse than all 3 of the most recent Fedora versions.
That's with the default policy. The strict policy is harder, but not by much. You just need to log in with the correct role; this is a RTFM problem.
First of all, don't make the compiler have setuid-like rights and don't give it arbitrary write control over a home directory. That was pure idiocy.
For ages, UNIX-like systems have used setgid (not setuid) to solve this for game high-score files. It does allow a bug in the game (an exploit perhaps) to corrupt the files, but your favored solution doesn't fix that either. Linux adds append-only files, which might be desirable for the compiler log example.
SE Linux is overkill, but we can certainly use it as an alternative to setgid. Make the file world writable. Invent an SE Linux type for it, such as fort_stat_t. Invent an SE Linux role for the compiler, such as fort_r. Mark the files appropriately. Define SE Linux policy such that processes in the fort_r role can only write to files with type fort_stat_t or with the type you use for home directories. Also define SE Linux policy such that nothing else may write to files that have type fort_stat_t.
I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.
Stuff can get painful if you go grabbing 3rd-party crap from proprietary developers without neither a clue nor a care.
Even there though, the popular stuff has already been figured out. For example, suppose you want acroread or flash or vmware. Use google, and search for the stuff being spewed into the log. Skip past the idiots who just disable SE Linux; it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.
Typically you find instructions for some "chcon -t foo_t/usr/lib/libfoo.so" command, often needed because the app developers were total idiots who couldn't figure out how to run gcc correctly. Run that and be happy.
(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)
People say "give me a 300dpi image" when asking for a JPEG. WTF? You can print any JPEG at 300dpi. You could print a 32x32 icon at 300dpi. You could print a 30000x30000 monster image at 300dpi. The physical dimensions are not specified, so there is no way to determine the needed pixel size. WTF?
I used "sRGB" specifically because it is defined in terms of CIE-XYZ. Your random CMYK is not.
There is no sCYMK. There are numerous device-independent RGB spaces, one of which will even reproduce correctly on your web site. (sticking to the gamut of your web site, sRGB, will ensure that the colors match there too) Go ahead and use Adobe Wide Gamut RGB if you like pain though; at least it is a perfectly functional device-independant color space.
GIMP does have ICC-based color management now, but it has other problems that make this point moot. GIMP fucks up the gamma and uses 8-bit channels.
If you really need a large gamut (and are OK with the result not being reproducable on your web page) then you can use Adobe Wide Gamut.
If you wish to avoid posterization, you work in a 15-bit or 16-bit color depth. You can still use the sRGB primaries.
JPEG was not a suggested alternative! PNG is OK. (it does support color space info and 16-bit depth) You can also use OpenEXR or your app's native format.
One might change to a different press for increased volume, for lower costs, because the press house went out of business, for a small run of a few extra copies, etc.
You're embedding a color profile. You're thus expecting the press house to do a color space conversion. Why do two lossy conversions (with rounding errors, etc.) when you could have done just one if you'd sent the RGB instead?
Second of all, the point about monitor calibration applies in either case.
CMYK is not a device-independent color space. As such, you CAN NOT safely ship it off to some random printer and expect good color reproduction. Well, I guess you could expect it and then be sorely disappointed!
The proper conversion from device-independent RGB (sRGB unless you like pain) to printer ink is done by the printer driver or press house. It takes into account numerous ugly details of the printing process (exact ink color, dot gain, paper color, drying time, soggy paper concerns, worse...) and several economic/quality tradeoffs.
TIFF is a way to waste disk space. It's used by people who think "300 dpi" (used in place of pixel dimensions) is meaningful for a digital image, and by people who think that abusing CMYK makes you a Real Professional.
BTW, if you press house is so stonage that they prefer some random uncalibrated CMYK over a proper device-independent color space, go elsewhere! You'll get random quality variation from people who are that clueless.
If he were sincere, he'd respond in kind: with a defensive arms race involving anti-ICBM systems.
The guy is an old KGB leader who probably misses the comfort of the cold war. He's now also a politician if we assume the elections are legit, so he also likes winning points for standing up against the USA.
It'd be real nice to grow tropical fruit in New England.
The USA will get that Mexican climate, fitting for the new owners. The old owners can move to that uninhabited area called Canada. We all get more space; the continent is kind of triangular with the big part up north.
Alaska is way bigger than Hawaii.
Opening up the Northwest Passage would be great for trade. Opening up the whole Arctic Ocean would be even better. Right now the area is a damn worthless because of the ice.
You're a rare weirdo. Much of the web won't work without scripting, or at least won't work well.
You're missing out on the nicer wiki/blog editors, live updates to the price of a computer purchase as you add/remove components, tolerable web mail interfaces, and (if your CPU is fast) the experimental slashdot interface.
Those are just the nerd things. I'm told there are numerous non-nerd things on the web as well, with far more scripting.
Even something as harmless-looking as a NULL pointer read can indicate an exploitable crash. It may mean a stack overflow. It may just be a NULL pointer read, which is (almost unbelivably) exploitable on Windows because of the way plug-ins and exception handlers work.
Let's not confuse the portability problem with the ability to programatically access the data. You damn well can script Office. (way better than OpenOffice too BTW) Portability is a whole different issue.
Slashdot Mirror
Nope. You MUST use -fpic or -fPIC to build the object files. Without that, the code itself is not PIC.
Well, this is really off the wall. I find it hard to believe that the last 3 Fedora releases all worked fine, yet RHEL5 does not. Perhaps it was based on Fedora Core 4? It doesn't sound all that old.
In case you hadn't noticed, "ls -Z" and "ps -M" are helpful.
Common problem: you built a library (a *.so file) without compiling all the object files (the *.o things) with gcc's -fpic or -fPIC option, and/or you forgot to specify -shared when linking.
When you make this kind of screw-up, you cause something called "text relocations". These don't even work on non-x86 and Debian bans them anyway for reasons related to memory usage. A text relocation means that the loader patches the code itself, rather slowly, when loading the shared library. This requires memory to be both writable and executable, which is a no-no for security against buffer overflows. SE Linux is usually set up to prohibit this by default.
If your broken shit runs as a server or gets loaded into a web browser, you greatly decrease security. You suck. Fix your shit.
I'm a developer too. I've upped my standards. Up yours!
on-topic of you!
:-)
Really!
Granted, I'm using something a tad different. I've used all three of Fedora Core 5, Fedora Core 6, and Fedora 7. Not a one of them have had SE Linux prevent yum from working. I just su to root and install stuff. I can't imagine that RHEL would be worse than all 3 of the most recent Fedora versions.
That's with the default policy. The strict policy is harder, but not by much. You just need to log in with the correct role; this is a RTFM problem.
Maybe true: "two dozen server applications"
Maybe true: "over 1100 packages which make up RHEL5"
Not true: anywhere near 1100 server applications in RHEL5
RHEL5 probably ships about two dozen server applications. That's plenty. What, you need a gopher server?
Well actually you don't even need SE Linux.
First of all, don't make the compiler have setuid-like rights and don't give it arbitrary write control over a home directory. That was pure idiocy.
For ages, UNIX-like systems have used setgid (not setuid) to solve this for game high-score files. It does allow a bug in the game (an exploit perhaps) to corrupt the files, but your favored solution doesn't fix that either. Linux adds append-only files, which might be desirable for the compiler log example.
SE Linux is overkill, but we can certainly use it as an alternative to setgid. Make the file world writable. Invent an SE Linux type for it, such as fort_stat_t. Invent an SE Linux role for the compiler, such as fort_r. Mark the files appropriately. Define SE Linux policy such that processes in the fort_r role can only write to files with type fort_stat_t or with the type you use for home directories. Also define SE Linux policy such that nothing else may write to files that have type fort_stat_t.
I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.
/usr/lib/libfoo.so" command, often needed because the app developers were total idiots who couldn't figure out how to run gcc correctly. Run that and be happy.
Stuff can get painful if you go grabbing 3rd-party crap from proprietary developers without neither a clue nor a care.
Even there though, the popular stuff has already been figured out. For example, suppose you want acroread or flash or vmware. Use google, and search for the stuff being spewed into the log. Skip past the idiots who just disable SE Linux; it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.
Typically you find instructions for some "chcon -t foo_t
(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)
Heh. No, really, 300dpi (as used) is moronic.
People say "give me a 300dpi image" when asking for a JPEG. WTF? You can print any JPEG at 300dpi. You could print a 32x32 icon at 300dpi. You could print a 30000x30000 monster image at 300dpi. The physical dimensions are not specified, so there is no way to determine the needed pixel size. WTF?
I used "sRGB" specifically because it is defined in terms of CIE-XYZ. Your random CMYK is not.
There is no sCYMK. There are numerous device-independent RGB spaces, one of which will even reproduce correctly on your web site. (sticking to the gamut of your web site, sRGB, will ensure that the colors match there too) Go ahead and use Adobe Wide Gamut RGB if you like pain though; at least it is a perfectly functional device-independant color space.
GIMP does have ICC-based color management now, but it has other problems that make this point moot. GIMP fucks up the gamma and uses 8-bit channels.
If you really need a large gamut (and are OK with the result not being reproducable on your web page) then you can use Adobe Wide Gamut.
If you wish to avoid posterization, you work in a 15-bit or 16-bit color depth. You can still use the sRGB primaries.
JPEG was not a suggested alternative! PNG is OK. (it does support color space info and 16-bit depth) You can also use OpenEXR or your app's native format.
One might change to a different press for increased volume, for lower costs, because the press house went out of business, for a small run of a few extra copies, etc.
Say, what if you use a 6-ink process? CMYK for that too?
Being THE standard doesn't mean it isn't moronic.
Nearly everything is fine as sRGB, especially since you may want identical colors on your web site. For the rest, there's Adobe Wide Gamut RGB.
That'd work, barely, in a hacky way.
You're embedding a color profile. You're thus expecting the press house to do a color space conversion. Why do two lossy conversions (with rounding errors, etc.) when you could have done just one if you'd sent the RGB instead?
Second of all, the point about monitor calibration applies in either case.
"live updates to the price of a computer purchase as you add/remove components"
Note: "live"
The price changes immediately. You don't have to press a "submit" button and/or wait for the page to load.
That's not a case of "web application developers can't do their jobs" at all. (assuming they don't trust the price your browser computed!)
CMYK is not a device-independent color space. As such, you CAN NOT safely ship it off to some random printer and expect good color reproduction. Well, I guess you could expect it and then be sorely disappointed!
The proper conversion from device-independent RGB (sRGB unless you like pain) to printer ink is done by the printer driver or press house. It takes into account numerous ugly details of the printing process (exact ink color, dot gain, paper color, drying time, soggy paper concerns, worse...) and several economic/quality tradeoffs.
TIFF is a way to waste disk space. It's used by people who think "300 dpi" (used in place of pixel dimensions) is meaningful for a digital image, and by people who think that abusing CMYK makes you a Real Professional.
BTW, if you press house is so stonage that they prefer some random uncalibrated CMYK over a proper device-independent color space, go elsewhere! You'll get random quality variation from people who are that clueless.
LA is definitly OK to lose. NY is a maybe.
Please take Camden, Miami, Houston, and New Orleans.
If you have any neutron bombs, please cleanse San Francisco of the fruits and nuts.
If he were sincere, he'd respond in kind: with a defensive arms race involving anti-ICBM systems.
The guy is an old KGB leader who probably misses the comfort of the cold war. He's now also a politician if we assume the elections are legit, so he also likes winning points for standing up against the USA.
Lovely game to play, huh?
Create a presentation in OpenOffice Impress some time. Make a few dozen slides in a variety of styles.
Open up the result. WTF? The lines are eleventy-zillion characters long.
Pretty-print it somehow. Still, WTF? It's highly redundant, and even includes a huge mass of style-like stuff for slide types you never even used.
It'd be real nice to grow tropical fruit in New England.
The USA will get that Mexican climate, fitting for the new owners. The old owners can move to that uninhabited area called Canada. We all get more space; the continent is kind of triangular with the big part up north.
Alaska is way bigger than Hawaii.
Opening up the Northwest Passage would be great for trade. Opening up the whole Arctic Ocean would be even better. Right now the area is a damn worthless because of the ice.
Uh, I'm not kidding. Stuff this in your .emacs file:
(setq term-setup-hook 'vip-mode)
(global-unset-key "\e\e")
(put 'eval-expression 'disabled nil)
If you run emacs in a gnome-terminal, you get the anti-aliased fonts. Start gnome terminal, run "unset DISPLAY", and be happy.
(IMHO the 6x13 xterm font called "fixed" beats any anti-aliased mush, but to each their own!)
You're a rare weirdo. Much of the web won't work without scripting, or at least won't work well.
You're missing out on the nicer wiki/blog editors, live updates to the price of a computer purchase as you add/remove components, tolerable web mail interfaces, and (if your CPU is fast) the experimental slashdot interface.
Those are just the nerd things. I'm told there are numerous non-nerd things on the web as well, with far more scripting.
A damn lot of crashes are exploitable.
Even something as harmless-looking as a NULL pointer read can indicate an exploitable crash. It may mean a stack overflow. It may just be a NULL pointer read, which is (almost unbelivably) exploitable on Windows because of the way plug-ins and exception handlers work.
First of all, the use of "Extensible Markup Language" (XML) would lock us into today's misguided technology fad.
Second of all, "file format used by only one vendor" doesn't disqualify Microsoft's OO-XML. Remember, Novell will be supporting it.
Third of all, there is no exception for formats like MPEG!!! OMG, WTF!!!
Result: this effectively mandates that OO-XML replace PDF, with videos being embedded in OO-XML to acheive compliance.
Let's not confuse the portability problem with the ability to programatically access the data. You damn well can script Office. (way better than OpenOffice too BTW) Portability is a whole different issue.