"Stagnant" development is probably as much of a red-herring as "security" in this context. Either problem is addressed with far less work by contributing updates to CVS. No, I suspect that CVS was replaced because of the fact that it is distributed under the GPL, and BSD people find that somehow distasteful.
Whatever. I'm past license wars, and the OpenBSD people can do whatever they like. Meanwhite, I'm off to learn subversion.
So, to cut out the bile and name-calling, your concern is in two parts: the pserver mechanism is unmaintainable and there's no API.
Now, ask yourself which is harder: writing a new pserver layer and an API or re-writing the entire toolchain? What's more, which one hurts an existing open source project from which OpenBSD has derived untold benefit over many years?
I'm sorry, I just don't accept your "dungheap" metaphor as a valid reason for abandoning this tool when there are many tools which OpenBSD has contributed to fixing and/or adding features to.
Both are, um, not that highly respected and are seen as pretty incompetent.
Ok, I'm trying to keep my tin-foil hat in the drawer, but you do realize that that is exactly what you want the public to believe, right? I mean, it's not really "conspiracy theory" so much as intellegence work 101: you don't display your competence if you can help it.
It shouldn't be hard to write a test suite which will generate normal-looking traffic and test what gets logged at the firewall against what that traffic should look like. Since you yourself are writing that test suite you know exactly, down to the last bit, what the traffic should look like.
In your original message, you made it sound as if it would be trivial to detect such tampering, and now you suggest that you could write a test suite that should be able to detect such a thing, given a sufficiently isolated, known-clean baseline.
Those two outlooks are wildly different. Which one did you intend?
Let me see if I understand this... there were some security problems with CVS as-is, so the OpenBSD folks did the right thing and reviewed the code, discovered any remaining problems and submitted... no, no it seems they instead wrote their own CVS.
Doh.
For those not familiar with the state of the world, this is going to mean a slower/longer transition to subversion (the logical successor to CVS), less interoperability between operating systems for developers and yet another tool that the OpenBSD people (who clearly did not have enough work to do already), to support. It will also mean that while they were clearly an interested party who was deriving benefits from a project and had expertise to contribute, they instead opted out and left the tool that had done so much for them to fend for itself.
What happened to OpenBSD? Wasn't it an actual member of the open source community at one point?
Oh well, as long as no one tries to make me use their mutant CVS, I'll be happy.
"Well since the firmware on your video card is limited to a certain size, and is patched into the system board BIOS, with any modern OS the bios is completely bypassed. And if you have an AGP video card, there's no way it can even see PCI bus traffic without the CPU being involved."
Certainly bridging the AGP/PCI gap would be difficult (not impossible, and would certainly be more detectable), but a) not everyone uses AGP b) next generation systems won't have this unfortunate distinction.
"I'm not even going to go into the whole saving screen shots into outgoing HTTP headers."
I was suggesting IP headers of HTTP traffic, actually.
"I don't think our law enforcement professionals would want to be chasing down the logs of web servers just hoping that little bits of data were saved."
Why would you care about the end-point servers? You just tap in at the ISP. In the US ISPs are required to provide facilities to allow law enforcement to trap traffic, given a warrant. I'm sure the same is true for many other countries. The catch is, forcing the data out to the ISP in the clear.
"If they're using any sort of hardware logging, it'll be a keylogger, or maybe something like the innards of a ethernet KVM."
Which is essentially what I described, only more carefully hidden.
"If this is anything like what I see in Government, some scumbag will convince them to buy some miracle spyware product for an outrageous price, and it'll be easily removed by HiJack This! and turn into a laughing stock."
Not to join the tin-foil hat crowd, but simple logic suggests that your observation of incompetence does not preclude competent tools existing at the same time.
Tempest has been around for ages, as have hardware keyloggers and video transmitters (not Ethernet KVM). These techniques have been used successfuly against criminal and government organizations of all sizes.
Pure software approaches exist as well, including hijacking software update sessions (this requires vendor cooperation in most cases) including OS and virus detection, riding on the back of detectable malware as a smokescreen, etc.
"If it's on my computer, and I have a reason to go looking for it, I'll find it, and I'll break it. Guaranteed. You cannot hide things from someone on their own computer."
I disagree. Bad intrusion software is easy to detect. Good intrusion software is difficult to detect. Top notch intrusion software can exist for years under the nose of skilled people who are looking for it.
Also, what makes you think that the good stuff will be software? Ever wonder what all of that firmware on your video card does? If it just detected certain kinds trigger conditions (perhaps on the bus from certain kinds of ethernet packets being latched off of the network card) and responded by taking a screenshot and saving it into some unused header space in outgoing HTTP requests (hard to grab and re-write from the bus, but I'll bet you could do it)... how would you know? No disk activity. No increase in network usage. No software running on the main CPU...
Better yet, just put it in the network card... that market is totally cut-throat, so I'll bet that anyone who offered a network card manufacturer a large sale or two in exchange for some extra firmware... well...
"Yet another technology that will have absolutely no effect on the big time criminals and will waste money catching the little guys that weren't really capable of getting away in the first place."
Well, it will enforce a kind of evolution, right? The guys who manage (however they do it) to survive this kind of attack will win. That might not be the biggest fish.
"notice this would be only for proprietary software. If the source code is generally available, why would the author need to put it on deposit with the copyright office"
I think you may have misunderstood my statement. What I had said was that forcing a cash outlay in order to obtain copyright means that open source projects lose the benefit of copyright. This means that, for example, the GPL becomes unenforcable without spending money to host the materials (which, I presume would mean a renewal fee every time you produced a new version, which would have to be hosted... I have no idea how anonymous CVS would work).
This means that you restrict copyright to those who can afford it. Also, since copyright doesn't expire any more (i.e. we perpetually extend it, as upheld by the Supreme Court), you've solved the abandonware problem (not really, see below), at the expense of most open source software's licensing.
You seem to be assuming that open source developers would continue, undaunted if they knew that their work would be absorbed by proprietary software that could afford to put it under copyright (remember that copyright is the reason that you can't call someone else's work yours).
There are many problems with this theory, and while I'm sure you could construct a rational argument or resolution for each one, the resulting system would be far more complex than the simple copyright system we have today. Further, re-instituting an expiration period for copyrights with an optional one-time renewal would solve all of the same problems with almost no complication.
"source-code obfuscation - That is fine - that is trade secret protection"
No it's not, please re-read my post. I was saying that no proprietary software company is going to submit readable source code to the USPTO if they know that it will be released. Thus, the benefit of submitting that source is moot. Instituting a readability requirement is a slippery slope. What constitutes readability? If my variable names are all 600-character things that are only refered to through three layers of indirection is that obfuscation or eccentricity? Who decides? Who is denied copyright protection because the USPTO doesn't like their programming style?
You also seem to be misunderstanding trade secret protection. Trade secret protection simply means that you gain some extra teeth with respect to enforcing non-disclosure. If you release source that's obfuscated, you have no trade secret status under any law I'm aware of.
Sorry for the late followup, but a few points you may not have considered:
1. That would destroy open source licensing as it uniformly relies on copyright, which very few open source projects (especially at first) could afford given your "owners expense" idea.
2. Trade secret protection would not provide any protection against unlimited duplication. Why would software not be as protected as books in that regard?
3. You will simply fund a large number of source-code obfuscation companies, and piles of unreadable source code will be submitted to the USPTO for copyright regulation compliance.
I think the free market pressures that are moving open source forward are a better tactic, though I'd really like to see a copyright term for software (heck, for everything, but software is a good start) of 14 years, renewable once.
Does anyone know of a good, high-resolution light pollution map? That would really help. In N.E., the best place to go is usually Vermont or Maine, with some decent viewing in the less touristy / highway-laced portions of western MA and northern NH.
Woefully, for this shower, NE is going to be cloudy:-(
I have one password that I use for generic stuff I don't care about someone cracking.
Then I have my PIN for bank stuff.
Then there's my home, work and high-security passwords.
The last three I use a program that I wrote to generate. It's available from my home site, but I haven't really fully released it yet (this is just an alpha version). Eventually, I'll upload it to CPAN.
Oh, you can see the difference between JPEG and non-JPEG alright, you're probably just looking at a bad example that masks the differences.
The problems with JPEG are legion (though it's an amazingly cool format for preserving the sense of the image without nearly as much storage).
For starters, JPEG drops a LOT of color information, which will usually result in images where subject matter that has very sharp color contrast (but not intensity) will be washed out. For example, take a picture of a jar of multi-flavor jelly beans. You'll find the differences are stark.
As far as re-saving, this is solvable, but only by someone who knows what they're doing. You need to be very careful about how much you change the colors in the image (because they'll be re-truncated on saving), and you MUST NOT change the upper-left origin (e.g. by cropping) or change the scale of the image. Actually, that's a bit of a lie, but correctly cropping or scaling JPEG images is tricky. You need to do so only in units of 64x64 pixels, as measured from the origin, and scaling is still going to cost you some quality (though not as much if you go up or down in units which are powers of 2). This is because JPEG images compress each region of 64x64 seperately, and loss artifacts will conform to those dimensions (this is why JPEG artifacts look blocky). If you crop to a non 64x64 boundary and re-save, you're introducing a conflicting set of artifacts and you lose a huge amount of quality.
"since digital photography has gotten so wide spread I am seeing much more "bad" photography"
I understand your frustration.
Film was hard to work with, and only people who knew what they were doing could extract useful results from it.
Then some wingnut that thought he could play God introduced the concept of advancing film. Oh, that was a sad day. All of a sudden you had moron after moron taking shot after shot with no regard for the fundamentals.
Then... auto focus. The phrase is blasphemy and ushered in a wave of blasphemers who weren't even smart enough to understand what it was they were desecrating.
And today we have digital photography.
Is the digital camera a useful, powerful tool with unique properties which are, for the most part, as yet untapped? Sure it is. So was the 35mm camera.
Will it, through ease of use, introduce throngs of idiots into the industry? Of course. Same thing happened in computer science, but there we still get our share of brilliant, insightful professionals and the same will be true of photography.
Don't hate the tool for being easy to use. Digital photography has a great deal of promise, and there are plenty of gifted photographers using such cameras... yes, there are real artists using the medium, and they don't need Photoshop to take your breath away or make you really think about their subjects. Give them a gigapixel camera and I'm sure they'll astound us.
Meanwhile, I just want a CCD with enough real eastate that I can not only really piss off, but actually cause a purist to break down in tears by saving to JPEG;-)
"Why? 8x10 cameras have existed for 100 years. Using modern film and a drum scanner will create a digital image with more than 1Gb of pixel data.
There are dozens of reasons to want very high resolution digital imaging. It cuts down on cost, waste, time, storage, and gives you many lighting options that you don't have with film (though film has its own advantages).
The primary reason, though, would simply be that photographers are using digital cameras in many places where they work quite well, and they would like them to eventually be the primary workhorse for most photographic needs.
Do you have JavaScript turned off? If you do (and perhaps if you have certain JavaScript features turned off, which Firefox/Mozilla does let you do), then it can't possibly work.
It works under firefox under Linux (Fedora Core 3 FWIW).
It's not really a bug, but a clever use of standards to mislead. It relies on JavaScript and popup windows (though it works fine with "good" popups, which Firefox and Mozailla allow).
This bug is probably best addressed by some small fixes from the browser vendors for the short-term, but with a re-evaluation of JavaScript and HTML to guard against social engineering by the standards bodies.
I find that the Gnome people in general don't like toolbars and tend to prefer right-click-menus. This is good for simple apps (like the file browser) but a poor decision for more complicated apps.
I can see where you're coming from, but in general I think that even the most complex apps benefit from simplicity and well groomed context functionality (context menus being one example).
The problem is that there are very few examples of well-groomed context menus. For examples of how far astray this can go, look at The Gimp... *shudder* Don't get me wrong, I love The Gimp, but I love it for its power, not for ease of use (I don't want to think about how much of my life has been spent searching for a particular filter or tool in those "context" menus).
Accuse me of ranting if you wish (I'll just ignore the ad hominem), but the fact of the matter is that you and I found definitive, and wildly different results.
I'm glad you've found ways to avoid dealing with SuSE and Red Hat directly. That will probably help you to avoid the kind of painfully poor pricing information I had to wade through.
Last weeks West Wing had a good example of these types of 'affronts' Sigh. Only in America would someone reference a fictional TV show as a source of information
Didn't sound to me like anyone was saying, "go see the West Wing instead of a reference work," just tying in current pop culture to the news. This is a good thing, and I wish there were more shows that tied current events in to pop culture the way The West Wing does. Sometimes I disagree with the show's implied or stated conclusions, but I'd rather have a show I disagree with politically than yet another reality show.
Clearly Novell is a company that needs to get its act together. You claim to have found a $349 price for support. I hunted forever and found a $900 price tag (not for zenworks, for SuSE Enterprise Linux 9 support).
Red Hat as simple, clear pricing that is exactly the right price point for their customers. SuSE will do fine with little businesses, but once you get to a certain size, you no longer consider it unreasonable for your vendor to say that you have to clear your configuration through them... after all, you're pushing out hundreds or thousands of boxes, and one-offs are no longer acceptable.
Your experiences seem to point to the frustration of trying to treat RHEL as a small business option. SuSE or White Box are better options for you, I would think.
Slashdot Mirror
"Stagnant" development is probably as much of a red-herring as "security" in this context. Either problem is addressed with far less work by contributing updates to CVS. No, I suspect that CVS was replaced because of the fact that it is distributed under the GPL, and BSD people find that somehow distasteful.
Whatever. I'm past license wars, and the OpenBSD people can do whatever they like. Meanwhite, I'm off to learn subversion.
Why is there not a moderation option, -1, Use the Freaking URL tag?! Slashdot may still add in its annoying space, but at least the href works.
1 54242&tid=8&tid=7
For those who still want that link in a usable form, it's http://bsd.slashdot.org/article.pl?sid=04/12/06/1
So, to cut out the bile and name-calling, your concern is in two parts: the pserver mechanism is unmaintainable and there's no API.
Now, ask yourself which is harder: writing a new pserver layer and an API or re-writing the entire toolchain? What's more, which one hurts an existing open source project from which OpenBSD has derived untold benefit over many years?
I'm sorry, I just don't accept your "dungheap" metaphor as a valid reason for abandoning this tool when there are many tools which OpenBSD has contributed to fixing and/or adding features to.
Something rings hollow.
Both are, um, not that highly respected and are seen as pretty incompetent.
Ok, I'm trying to keep my tin-foil hat in the drawer, but you do realize that that is exactly what you want the public to believe, right? I mean, it's not really "conspiracy theory" so much as intellegence work 101: you don't display your competence if you can help it.
It shouldn't be hard to write a test suite which will generate normal-looking traffic and test what gets logged at the firewall against what that traffic should look like. Since you yourself are writing that test suite you know exactly, down to the last bit, what the traffic should look like.
In your original message, you made it sound as if it would be trivial to detect such tampering, and now you suggest that you could write a test suite that should be able to detect such a thing, given a sufficiently isolated, known-clean baseline.
Those two outlooks are wildly different. Which one did you intend?
Let me see if I understand this... there were some security problems with CVS as-is, so the OpenBSD folks did the right thing and reviewed the code, discovered any remaining problems and submitted... no, no it seems they instead wrote their own CVS.
Doh.
For those not familiar with the state of the world, this is going to mean a slower/longer transition to subversion (the logical successor to CVS), less interoperability between operating systems for developers and yet another tool that the OpenBSD people (who clearly did not have enough work to do already), to support. It will also mean that while they were clearly an interested party who was deriving benefits from a project and had expertise to contribute, they instead opted out and left the tool that had done so much for them to fend for itself.
What happened to OpenBSD? Wasn't it an actual member of the open source community at one point?
Oh well, as long as no one tries to make me use their mutant CVS, I'll be happy.
"Well since the firmware on your video card is limited to a certain size, and is patched into the system board BIOS, with any modern OS the bios is completely bypassed. And if you have an AGP video card, there's no way it can even see PCI bus traffic without the CPU being involved."
Certainly bridging the AGP/PCI gap would be difficult (not impossible, and would certainly be more detectable), but a) not everyone uses AGP b) next generation systems won't have this unfortunate distinction.
"I'm not even going to go into the whole saving screen shots into outgoing HTTP headers."
I was suggesting IP headers of HTTP traffic, actually.
"I don't think our law enforcement professionals would want to be chasing down the logs of web servers just hoping that little bits of data were saved."
Why would you care about the end-point servers? You just tap in at the ISP. In the US ISPs are required to provide facilities to allow law enforcement to trap traffic, given a warrant. I'm sure the same is true for many other countries. The catch is, forcing the data out to the ISP in the clear.
"If they're using any sort of hardware logging, it'll be a keylogger, or maybe something like the innards of a ethernet KVM."
Which is essentially what I described, only more carefully hidden.
"If this is anything like what I see in Government, some scumbag will convince them to buy some miracle spyware product for an outrageous price, and it'll be easily removed by HiJack This! and turn into a laughing stock."
Not to join the tin-foil hat crowd, but simple logic suggests that your observation of incompetence does not preclude competent tools existing at the same time.
Tempest has been around for ages, as have hardware keyloggers and video transmitters (not Ethernet KVM). These techniques have been used successfuly against criminal and government organizations of all sizes.
Pure software approaches exist as well, including hijacking software update sessions (this requires vendor cooperation in most cases) including OS and virus detection, riding on the back of detectable malware as a smokescreen, etc.
"It's a nice one-time speed bump, but it does solve the hard problems, just puts them off for another year."
I think that's kind of the point to ML. After all, if we suddenly discovered a way to increase density by 10x, then we'd have defeated ML.
"If it's on my computer, and I have a reason to go looking for it, I'll find it, and I'll break it. Guaranteed. You cannot hide things from someone on their own computer."
I disagree. Bad intrusion software is easy to detect. Good intrusion software is difficult to detect. Top notch intrusion software can exist for years under the nose of skilled people who are looking for it.
Also, what makes you think that the good stuff will be software? Ever wonder what all of that firmware on your video card does? If it just detected certain kinds trigger conditions (perhaps on the bus from certain kinds of ethernet packets being latched off of the network card) and responded by taking a screenshot and saving it into some unused header space in outgoing HTTP requests (hard to grab and re-write from the bus, but I'll bet you could do it)... how would you know? No disk activity. No increase in network usage. No software running on the main CPU...
Better yet, just put it in the network card... that market is totally cut-throat, so I'll bet that anyone who offered a network card manufacturer a large sale or two in exchange for some extra firmware... well...
"Yet another technology that will have absolutely no effect on the big time criminals and will waste money catching the little guys that weren't really capable of getting away in the first place."
Well, it will enforce a kind of evolution, right? The guys who manage (however they do it) to survive this kind of attack will win. That might not be the biggest fish.
"notice this would be only for proprietary software. If the source code is generally available, why would the author need to put it on deposit with the copyright office"
I think you may have misunderstood my statement. What I had said was that forcing a cash outlay in order to obtain copyright means that open source projects lose the benefit of copyright. This means that, for example, the GPL becomes unenforcable without spending money to host the materials (which, I presume would mean a renewal fee every time you produced a new version, which would have to be hosted... I have no idea how anonymous CVS would work).
This means that you restrict copyright to those who can afford it. Also, since copyright doesn't expire any more (i.e. we perpetually extend it, as upheld by the Supreme Court), you've solved the abandonware problem (not really, see below), at the expense of most open source software's licensing.
You seem to be assuming that open source developers would continue, undaunted if they knew that their work would be absorbed by proprietary software that could afford to put it under copyright (remember that copyright is the reason that you can't call someone else's work yours).
There are many problems with this theory, and while I'm sure you could construct a rational argument or resolution for each one, the resulting system would be far more complex than the simple copyright system we have today. Further, re-instituting an expiration period for copyrights with an optional one-time renewal would solve all of the same problems with almost no complication.
"source-code obfuscation - That is fine - that is trade secret protection"
No it's not, please re-read my post. I was saying that no proprietary software company is going to submit readable source code to the USPTO if they know that it will be released. Thus, the benefit of submitting that source is moot. Instituting a readability requirement is a slippery slope. What constitutes readability? If my variable names are all 600-character things that are only refered to through three layers of indirection is that obfuscation or eccentricity? Who decides? Who is denied copyright protection because the USPTO doesn't like their programming style?
You also seem to be misunderstanding trade secret protection. Trade secret protection simply means that you gain some extra teeth with respect to enforcing non-disclosure. If you release source that's obfuscated, you have no trade secret status under any law I'm aware of.
Sorry for the late followup, but a few points you may not have considered:
1. That would destroy open source licensing as it uniformly relies on copyright, which very few open source projects (especially at first) could afford given your "owners expense" idea.
2. Trade secret protection would not provide any protection against unlimited duplication. Why would software not be as protected as books in that regard?
3. You will simply fund a large number of source-code obfuscation companies, and piles of unreadable source code will be submitted to the USPTO for copyright regulation compliance.
I think the free market pressures that are moving open source forward are a better tactic, though I'd really like to see a copyright term for software (heck, for everything, but software is a good start) of 14 years, renewable once.
Does anyone know of a good, high-resolution light pollution map? That would really help. In N.E., the best place to go is usually Vermont or Maine, with some decent viewing in the less touristy / highway-laced portions of western MA and northern NH.
:-(
Woefully, for this shower, NE is going to be cloudy
I have one password that I use for generic stuff I don't care about someone cracking.
Then I have my PIN for bank stuff.
Then there's my home, work and high-security passwords.
The last three I use a program that I wrote to generate. It's available from my home site, but I haven't really fully released it yet (this is just an alpha version). Eventually, I'll upload it to CPAN.
Oh, you can see the difference between JPEG and non-JPEG alright, you're probably just looking at a bad example that masks the differences.
The problems with JPEG are legion (though it's an amazingly cool format for preserving the sense of the image without nearly as much storage).
For starters, JPEG drops a LOT of color information, which will usually result in images where subject matter that has very sharp color contrast (but not intensity) will be washed out. For example, take a picture of a jar of multi-flavor jelly beans. You'll find the differences are stark.
As far as re-saving, this is solvable, but only by someone who knows what they're doing. You need to be very careful about how much you change the colors in the image (because they'll be re-truncated on saving), and you MUST NOT change the upper-left origin (e.g. by cropping) or change the scale of the image. Actually, that's a bit of a lie, but correctly cropping or scaling JPEG images is tricky. You need to do so only in units of 64x64 pixels, as measured from the origin, and scaling is still going to cost you some quality (though not as much if you go up or down in units which are powers of 2). This is because JPEG images compress each region of 64x64 seperately, and loss artifacts will conform to those dimensions (this is why JPEG artifacts look blocky). If you crop to a non 64x64 boundary and re-save, you're introducing a conflicting set of artifacts and you lose a huge amount of quality.
"since digital photography has gotten so wide spread I am seeing much more "bad" photography"
... auto focus. The phrase is blasphemy and ushered in a wave of blasphemers who weren't even smart enough to understand what it was they were desecrating.
;-)
I understand your frustration.
Film was hard to work with, and only people who knew what they were doing could extract useful results from it.
Then some wingnut that thought he could play God introduced the concept of advancing film. Oh, that was a sad day. All of a sudden you had moron after moron taking shot after shot with no regard for the fundamentals.
Then
And today we have digital photography.
Is the digital camera a useful, powerful tool with unique properties which are, for the most part, as yet untapped? Sure it is. So was the 35mm camera.
Will it, through ease of use, introduce throngs of idiots into the industry? Of course. Same thing happened in computer science, but there we still get our share of brilliant, insightful professionals and the same will be true of photography.
Don't hate the tool for being easy to use. Digital photography has a great deal of promise, and there are plenty of gifted photographers using such cameras... yes, there are real artists using the medium, and they don't need Photoshop to take your breath away or make you really think about their subjects. Give them a gigapixel camera and I'm sure they'll astound us.
Meanwhile, I just want a CCD with enough real eastate that I can not only really piss off, but actually cause a purist to break down in tears by saving to JPEG
The primary reason, though, would simply be that photographers are using digital cameras in many places where they work quite well, and they would like them to eventually be the primary workhorse for most photographic needs.
Freaky... I don't have either of those disabled, but you're right, I can't see how that's related. Try it with those allowed maybe?...
Do you have JavaScript turned off? If you do (and perhaps if you have certain JavaScript features turned off, which Firefox/Mozilla does let you do), then it can't possibly work.
I'm running 1.0. Sorry I thought that was a given.
It works under firefox under Linux (Fedora Core 3 FWIW).
It's not really a bug, but a clever use of standards to mislead. It relies on JavaScript and popup windows (though it works fine with "good" popups, which Firefox and Mozailla allow).
This bug is probably best addressed by some small fixes from the browser vendors for the short-term, but with a re-evaluation of JavaScript and HTML to guard against social engineering by the standards bodies.
And me without mod points... well, Mr Coward, thanks anyway for making an excellent point, which I was about to post, myself.
Point the second: always surf with Java and JavaScript off until / unless you need them.
I find that the Gnome people in general don't like toolbars and tend to prefer right-click-menus. This is good for simple apps (like the file browser) but a poor decision for more complicated apps.
I can see where you're coming from, but in general I think that even the most complex apps benefit from simplicity and well groomed context functionality (context menus being one example).
The problem is that there are very few examples of well-groomed context menus. For examples of how far astray this can go, look at The Gimp... *shudder* Don't get me wrong, I love The Gimp, but I love it for its power, not for ease of use (I don't want to think about how much of my life has been spent searching for a particular filter or tool in those "context" menus).
Accuse me of ranting if you wish (I'll just ignore the ad hominem), but the fact of the matter is that you and I found definitive, and wildly different results.
I'm glad you've found ways to avoid dealing with SuSE and Red Hat directly. That will probably help you to avoid the kind of painfully poor pricing information I had to wade through.
Clearly Novell is a company that needs to get its act together. You claim to have found a $349 price for support. I hunted forever and found a $900 price tag (not for zenworks, for SuSE Enterprise Linux 9 support).
Red Hat as simple, clear pricing that is exactly the right price point for their customers. SuSE will do fine with little businesses, but once you get to a certain size, you no longer consider it unreasonable for your vendor to say that you have to clear your configuration through them... after all, you're pushing out hundreds or thousands of boxes, and one-offs are no longer acceptable.
Your experiences seem to point to the frustration of trying to treat RHEL as a small business option. SuSE or White Box are better options for you, I would think.