I guess I just think that language snobbery is a facet of generalized snobbery: things that are common are looked down upon, while esoteric things are elevated.
I think there's also a point to be made about polysyllabic words sounding more sophisticated than monosyllabic ones, but I don't think I need to prove it.
I think the former is the only explanation that stands up to analysis, "people" are impressred by words like "plinth", even though it's monosyllabic.
Bullshit. Red Hat's kernel isn't static - it moves just like any other. So if one says "You must use Red Hat 7.3" and another says "You must use Red Hat 8.0", you could be screwed in any case.
Red Hat's kernel has traditionaly changed much less than the vanilla kernel, and it includes patches that these applications need (like the O(1) scheduler). And for over a year now almost all ISVs have been targeting the Red Hat Enterprise Linux distribution, which hasn't changed signifcantly in well over 18 months... and they've said that version won't change for at least another 3-4 years.
And it still has features, that Oracle etc. need, that you can't get in the 2.4.x kernel.
So sure, if you want to wait another year or so and you can get an Oracle install from 18 months or so ago to work... then it'll be "less work".
That's right. Because the source code to chkconfig or service isn't available at all. Oh yeah, that GPL thing.
Is this some kind of sad joke? Debian is about the only distribution that doesn't include chkconfig/service etc.... it's GPL'd, and people have tried to add it to debian... but NIH rules.
As for the "ISVs shouldn't do any configuration" comment, then hey what are you complaining about... you get to extract the files manually and install them manually and configure the environment manually (including the all the right patches for the kernel, binutils, libc and the rest). You apparently have the world you want to live in, now you get to live in it. However I'd bet that most people don't want to live in your world.
If a company says "Red Hat Only!" then they...
They wrote a program, that works under Linux, not under Red Hat.
No, they wrote a program that works under a particular version of Red Hat Linux. This isn't a subtle difference.
If it's kernel version dependent, state the kernel versions it was tested under - or better yet, give the source tree! (wow!)
They do, it's whatever kernel Red Hat are shipping, you can get the source. ISVs need some common point, or you are going to have Oracle requiring kernel A and SAP/Veritas/etc. requiring kernel B which aren't mergable.
If it's library dependent, give the library versions. If it's library dependent, static link the damned thing.
And if they need dlopen() to work, oh sure they could just install a glibc with the right patches and play LD_LIBRARY_PATH games to get it working.
There is nothing that runs under Red Hat that can't run under Debian.
Well unless they call "chkconfig", or "service" or, configure some file in/etc/sysconfig/ or require Java. I suppose they could just ship their own distro.... yeh just what I want: 15 different distros. to manage, I'm running Oracle/Veritas/WebSphere on this box and SAP/Streams/PowerPath on that one over there.
For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?
Oh, yeh that's right, because files not existing is really "exceptional" isn't it? This is an anoying wart for FileInputStream IMO, because now instead of doing all your relevant work in the call (Ie. does the file exist) you have to mix into all the real exceptional conditions like a NULL exception, out of memory, API errors like IllegalArgumentException (and even other non-exceptional things like the file being a directory).
Although I'll admit having both an exceptions API and a none exceptions API is probably worse than just either. EOFException is just as bad in that regard.
So, for now, Microsoft seems to have produced a working next-generation form solution before any of the open groups or competitors.
But it's always easier to make the compromises you want, for what you want, than it is to work with a group and come up with something everyone is happy with. So this isn't a supprise, or even unexpected.
In contrast, dietlibc warns of many other functions, e.g. unportable functions like sendfile, security risks like system and {tmp,temp}nam,
Great so if you autoconf for sendfile() then you still get a warning, how intelligent. system() is debatable, I'd say it was rarely used and rarely used badly... however tmpname/tempname both produce link warnings with glibc.
functions introducing bloat into your programs like all stdio stuff
*laughs*... yeh, because almost no C programs use stdio. Mind you due to the terrible printf in dietlibc a link time warning for printf/sprintf/fprintf/etc. is probably a good thing.
But a simple look at any bugtrack should back me up. Most errors are due to memory leakage, buffer overflows and other artifacts of C programming.
Bugtrack will almost certainly tell you that buffer overflows are a large source of security bugs but this doesn't back you up at all, as there are a lot of good C string APIs and using one that stops buffer overflows is trivial.
Literate programming means writing well in code. It means much more then comments and I urge you to some research into it.
I'm well aware of what literate programing is, and it is little more than writing everything twice. It makes the actual code very hard to read IMO, due to copious amounts of "coments".
While you could argue that TeX is "perfect", the debian network interface code is much less useful than the Red Hat version and changing it was much harder.
In that case then open source programs will continue to suffer from too many bugs.
In your opinion, in my opinion having the people who implement the code design the code makes for a much better result.
1) Stop using C. Use object oriented languages and languages that offer garbage collection. You will immediately reduce bugs by 80%
That number looks like you pulled it from somewhere the Sun don't shine. I guess it's possible that you remove 80% of the simple bugs in your code, but even then I'd find that number hard to swallow. And if you introduct simple things like a string API I'm not going to believe a number anywhere near 80%.
2) Make code more literate. Use pre and post conditions, demand that all contributors use lots of asserts. Make liberal use of interfaces
"literate" code is often the wrong approach, when I want to say things well in English I don't write the same thing in Japanese next to it... I just spend time writing it well in English.
assert()'s are nice as are the assert()s called pre/post conditions. Interfaces in the Java sense I doubt buy you much from a lower bug count POV.
3) Designate a few people as architects of the project. These people should do nothing but write and design interfaces and maybe write class stubs with pre and post conditions and have the rest of the team complete the classes.
Even if you assume that people can easily take these roles (Ie. someone not doing any implementation knows what the interfaces should be... err yeh right, not). It's just not going to happen in the OpenSource world IMO, implementing someone's very good spec. isn't much fun... implementing one less than that gets much less so.
4) Unit testing, unit testing, unit testing.
Duh, testing helps reduce bugs.. I'm shocked. A bunch of projects do this now, some have a large "make check" pass... and some don't, sure. But for instance I know a bunch of the samba people have private win32 labs to do regression testing, I'd be supprised if that wasn't similar for the apache/etc. people.
Actually, GConf was a particularly good example because it is possible to write new storage backends for GConf as plugins.
I'm sure that a GConf plugin that stores every key in its own file is extremely straightforward to write. Then the people who have "seen the light" will use that plugin, while the rest of the world is stuck with the (probably less efficient) XML files.
It's not obiouvs it'd be faster, as was said. Because you are trading the XML parsing for a pine of system calls. It's easier to write... sure. But you have to write the XML one anyway because that's what 90%+ of your userbase is going to need, and because of the 90%+ stats you'd probably write that first.
So then, yes, you can possibly write the extra stuff so it works only on reiserfs4... and it will possibly be faster. Or you could just write an libdb/LDAP/MySQL/Oracle backend, which is much more likely to be the fastest.
That's the problem with the whole thing, it can't buy you any features... because using those features will mean large parts of your users won't have them (or your users will go somewhere else where the designer doesn't design for things they don't have); And it's very unlikely IMO to be faster than a real database, so you don't get any speed improvments using it.
So what exactly is the point? That it's much easier to design simplistic apps. that work like crap for 90%+ of people, but that perform okish if you are using the one true FS? Sounds worthwhile.
GConf was a better example.
[...] It'd be *much* easier to use GConf if in order to read a value, you didn't have to load up the GConf libs (which in turn depend on CORBA), or parse XML files.
No GConf was a terrible example, because reiserfs doesn't solve that problem. Even if reiserfs came out with all their planned "new fs" stuff tommorow, and all the distributions released an OS upgrade the next day after fixing all the security problems in all the apps (think apache serving metadata for files).
So even then, after all that, you'd need to use GConf and it'd need to do all the same stuff... because Solaris/FreeBSD/OpenBSD/etc. are all not going away, and they sure as hell aren't going to include reiserfs. Then there's all the people still using older distros, or who are still running from "upgrades" so have ext2 or ext3 instead.
Hans is just on crack if he thinks everyone is going to require reiserfs as the database for their apps. Look at for instance, the "glibc" extensions like obstacks or asprintf()... noone uses them, why? Because then your apps. don't work anywhere.
but then what's the point of overloaded operators?
Indeed, using a function is more readable; more efficent; and allows you to have more than one idea of an add for a complicated type (without doing heniously confusing things with different types on the right hand side), the C programers have been saying this for years.
Yeh, whatever you do, when making comparisons between FreeBSD and Linux always choose the version of FreeBSD "out in a couple of months" and the lowest common denominator of all Linux distributions.
The choices are: use BroadCom's closed-source bcm5700 driver, [...]; or use the community supported tg3 driver, which has really great performance, but will randomly, when under load for more than 24 hours, start passing only one in about one hundred packets.
The "community" supported tg3 driver, is now both recommended by broadcom and been stable under very high loads for months (at least with all the Red Hat customers, who have the drivers that they helped write and fix).
The thing is many people think the purpose of Linux is to "beat" MS windows. While I think that it will surpass MS in the server area, the desktop may or may not happen, or it may take a number of years for the desktop.
While Linux may well co-exist with say the mainframe OSes or FreeBSD or QNX, I find it hard to believe that Microsoft will let it co-exist with Windows. If they keep 90%+ of the desktop they'll kill Linux in the server. They've shown no desire previously to co-exist with anything, and I can't see them starting now.
But the most important point is that Linux will ALWAYS be around and it is not a competitor of any OS. It is a movement "By the Poeople and For the People". So whether it "beats" MS and takes 90% of the desktop and or server market does not matter. There will always be plenty of developers working on it commercially, academically and non-commercially.
You need members to have a movement, if MS can reclaim the businesses it's lost and/or stop hardware vendors from supporting it. Linux will have lost, it'll be that thing we tried back at the millenium and it will die.
Take Drag and Drop. I have a pdf document on my desktop. I open mail, drag it in, it attaches. I drag web addresses to the desktop, the link is made. I drag the web address to my bookmark bar, the bookmark is made.
Yeh, I do this all the time... under Red Hat. There are still problems, but it's not quite that bad.
Another thing about OSS is that it is so hell bent on copying Windoze that it rarely innovates. I've seen very little non-clone applications come out of the OSS movement. I dare you to name any desktop applications that are innovative. Certainly I can name quite a few server ones, but we are not talking about serving apps here. OSS has no "killer" desktop apps, just mediocre clones.
Well I'm assuming you are removing mozilla, emacs, ctwm (one of the first to have virtual desktops... or maybe it was tvwm... to long ago) etc. from the list.
Then there's also the small things, for instance after using galeon then I hate using almost any browser due to the way you can filter images (it says "block images from X", which is often only a "small" difference of displaying the host... but that small thing changes the usability immensly -- and this is where OS X has the edge, a noticable amount of "small" things thoughout the UI).
However this is also a case of there being a lot of work to do to applications to get features that people know they want, so that leaves little time to experiment. Also there isn't anything you can really point to as "innovation" in Window XP... sure it's prettier, and there are probably a bunch of small things that make life easier... but nothing huge you can say hey look at that.
a microkernel architecture does not require that every single little OS process runs in a separate address space.
Then, by that definition, Linux 2.4.x is a microkernel. The filesystems, and the networking layer (and each of the different protocols) are all seperate modules... which are only very loosly tied to the core.
Sure, most of those don't have a specific process associated with them... but that's mainly an efficency thing. Even then on my laptop there are eleven different processes that are kernel spawned/owned processes.
There are two versions of Windows.Forms: one uses Gtk# and another one uses Wine for its implementation.
Ahh, cool. You should make that fact more obvious. From what I had read it looked like you either needed to write directly to Gtk# or install wine and use Win.Forms.
As an author of a security book and of a well known security application, how much do you feel code cleanliness/quality affects security of products?... Or do you feel that only a very few products should worry about security?
For instance from looking at nmap-3 it's, ignoring the style, littered with magic numbers _esp_ for things like size of an array of char (which is the only concept like a "string" that nmap has) and also more than a few obvious misuses of strncpy() etc. to go along with it.
Contrast this with other security concious programs, like vsftpd and postfix, and it's like the difference between night and day.
Obviously anyone putting nmap at the end of a CGI is just asking for pain, but one traditional view is that this isn't wouldn't be the problem of nmap... but of whoever decided that it was security concious, not just a "security" application.
It still boggles my mind that C is used to do any high-level programming (ie, anything besides api's to system calls, and writing drivers and kernels).
Depends, I don't see any real server apps. written in perl/python/php (Ie. smtp, nntp, ntp, ftp, http, etc.)... and although we're starting to see some small GUI apps. written in python, they are almost uniformly terrible and fail to run or anything but the developers box.
Some of us just don't mind thinking about the materials as we build the bridge, because let's face it... you aren't going to be happy if the bridge is made of glass.
And ten times as long to find all the strange bugs and buffer overflows that eventually show up as exploits.
This really isn't a problem with C, and half decent C programer can make a simple string API that is safe (and I think you'll find all the secure apps. do this). Or you can even just use one someone else already made. However a lot of people "learn to paint" with C, and too often those early rough sketches end up being used by a lot of people.
Re:Journaling File System: for those who don't kno
on
Looking at Longhorn
·
· Score: 1
This is not true. ext3 and ext2 have the same disk representation but they don't share code, at all.
When ext3 was created it was a fork form the ext2 code base... so the above is mainly just misinformed/. crap. It's like saying OpenBSD doesn't share code with NetBSD.
Yes, it's true, that the implementation that had to be changed for the journalling code in ext3 didn't get moved back to ext2... but that was so that ext2 didn't have any kind of changes (from an engineering POV any change is bad).
Indeed all "new" ext2 features seem to be going into the ext3 driver only. The ext2 driver is just being kept for ultra stability.
Since the EULA is a legally binding document that the user is entering into willfully, an OS restriction could easily be a part of that. (Now, whether shrinkwrap license agreements with more fine print then a mortgage are a good idea, that's another story)
It's not obvious that the above is legal though, for a normal company. For a company that owns/controls both the OS and product, it's even less likely.
Let's say, for example, that a bug in FoxPro is found that represents a security risk - MS can use Windows Update and other means to get a patch out to their Windows-based customers, but what do they do for the WINE-rs? That's a loose end that I certainly wouldn't want to deal with...
So what about the business with a firewall that doesn't allow machines to connect to microsoft's update servers... are you saying that MS should be allowed to say you can't firewall their products? What about if you run more than one service on that machine, and the update breaks the other non-MS service... should they then be allowed to require you to update?
Most companies solve this problem by saying it isn't supported on platforms, they don't support. Not that it is not allowed to use it on platforms they don't support.
Yes, slightly misleading IMO, the LSB currently says you can only have 1 dependancy, on the LSB itself, so presumably he meant "if they followed the guidelines provided by the LSB, you would not have dependancies". That's one way to solve the problem. It's not a very good way though.
Is that even possible with rpm? I didn't think it was posible to turn off autodetection of libc etc.
Of course, even if you do, then whne you compile something on 8.0 with glibc updates it won't work on a system without those updates.
Slashdot Mirror
I think the former is the only explanation that stands up to analysis, "people" are impressred by words like "plinth", even though it's monosyllabic.
Red Hat's kernel has traditionaly changed much less than the vanilla kernel, and it includes patches that these applications need (like the O(1) scheduler). And for over a year now almost all ISVs have been targeting the Red Hat Enterprise Linux distribution, which hasn't changed signifcantly in well over 18 months ... and they've said that version won't change for at least another 3-4 years.
And it still has features, that Oracle etc. need, that you can't get in the 2.4.x kernel.
So sure, if you want to wait another year or so and you can get an Oracle install from 18 months or so ago to work ... then it'll be "less work".
Is this some kind of sad joke? Debian is about the only distribution that doesn't include chkconfig/service etc. ... it's GPL'd, and people have tried to add it to debian ... but NIH rules.
As for the "ISVs shouldn't do any configuration" comment, then hey what are you complaining about ... you get to extract the files manually and install them manually and configure the environment manually (including the all the right patches for the kernel, binutils, libc and the rest). You apparently have the world you want to live in, now you get to live in it. However I'd bet that most people don't want to live in your world.
If a company says "Red Hat Only!" then they ...
...obviously have more of a clue than you do.
No, they wrote a program that works under a particular version of Red Hat Linux. This isn't a subtle difference.
They do, it's whatever kernel Red Hat are shipping, you can get the source. ISVs need some common point, or you are going to have Oracle requiring kernel A and SAP/Veritas/etc. requiring kernel B which aren't mergable.
And if they need dlopen() to work, oh sure they could just install a glibc with the right patches and play LD_LIBRARY_PATH games to get it working.
Well unless they call "chkconfig", or "service" or, configure some file in /etc/sysconfig/ or require Java. I suppose they could just ship their own distro. ... yeh just what I want: 15 different distros. to manage, I'm running Oracle/Veritas/WebSphere on this box and SAP/Streams/PowerPath on that one over there.
Oh, yeh that's right, because files not existing is really "exceptional" isn't it? This is an anoying wart for FileInputStream IMO, because now instead of doing all your relevant work in the call (Ie. does the file exist) you have to mix into all the real exceptional conditions like a NULL exception, out of memory, API errors like IllegalArgumentException (and even other non-exceptional things like the file being a directory).
Although I'll admit having both an exceptions API and a none exceptions API is probably worse than just either. EOFException is just as bad in that regard.
But it's always easier to make the compromises you want, for what you want, than it is to work with a group and come up with something everyone is happy with. So this isn't a supprise, or even unexpected.
*sigh* that link should be... this one
Great so if you autoconf for sendfile() then you still get a warning, how intelligent. system() is debatable, I'd say it was rarely used and rarely used badly ... however tmpname/tempname both produce link warnings with glibc.
*laughs* ... yeh, because almost no C programs use stdio. Mind you due to the terrible printf in dietlibc a link time warning for printf/sprintf/fprintf/etc. is probably a good thing.
Bugtrack will almost certainly tell you that buffer overflows are a large source of security bugs but this doesn't back you up at all, as there are a lot of good C string APIs and using one that stops buffer overflows is trivial.
I'm well aware of what literate programing is, and it is little more than writing everything twice. It makes the actual code very hard to read IMO, due to copious amounts of "coments".
While you could argue that TeX is "perfect", the debian network interface code is much less useful than the Red Hat version and changing it was much harder.
In your opinion, in my opinion having the people who implement the code design the code makes for a much better result.
That number looks like you pulled it from somewhere the Sun don't shine. I guess it's possible that you remove 80% of the simple bugs in your code, but even then I'd find that number hard to swallow. And if you introduct simple things like a string API I'm not going to believe a number anywhere near 80%.
"literate" code is often the wrong approach, when I want to say things well in English I don't write the same thing in Japanese next to it ... I just spend time writing it well in English.
assert()'s are nice as are the assert()s called pre/post conditions. Interfaces in the Java sense I doubt buy you much from a lower bug count POV.
Even if you assume that people can easily take these roles (Ie. someone not doing any implementation knows what the interfaces should be ... err yeh right, not). It's just not going to happen in the OpenSource world IMO, implementing someone's very good spec. isn't much fun ... implementing one less than that gets much less so.
Duh, testing helps reduce bugs .. I'm shocked. A bunch of projects do this now, some have a large "make check" pass ... and some don't, sure. But for instance I know a bunch of the samba people have private win32 labs to do regression testing, I'd be supprised if that wasn't similar for the apache/etc. people.
It's not obiouvs it'd be faster, as was said. Because you are trading the XML parsing for a pine of system calls. It's easier to write ... sure. But you have to write the XML one anyway because that's what 90%+ of your userbase is going to need, and because of the 90%+ stats you'd probably write that first.
So then, yes, you can possibly write the extra stuff so it works only on reiserfs4 ... and it will possibly be faster. Or you could just write an libdb/LDAP/MySQL/Oracle backend, which is much more likely to be the fastest.
That's the problem with the whole thing, it can't buy you any features ... because using those features will mean large parts of your users won't have them (or your users will go somewhere else where the designer doesn't design for things they don't have); And it's very unlikely IMO to be faster than a real database, so you don't get any speed improvments using it.
So what exactly is the point? That it's much easier to design simplistic apps. that work like crap for 90%+ of people, but that perform okish if you are using the one true FS? Sounds worthwhile.
No GConf was a terrible example, because reiserfs doesn't solve that problem. Even if reiserfs came out with all their planned "new fs" stuff tommorow, and all the distributions released an OS upgrade the next day after fixing all the security problems in all the apps (think apache serving metadata for files).
So even then, after all that, you'd need to use GConf and it'd need to do all the same stuff ... because Solaris/FreeBSD/OpenBSD/etc. are all not going away, and they sure as hell aren't going to include reiserfs. Then there's all the people still using older distros, or who are still running from "upgrades" so have ext2 or ext3 instead.
Hans is just on crack if he thinks everyone is going to require reiserfs as the database for their apps. Look at for instance, the "glibc" extensions like obstacks or asprintf() ... noone uses them, why? Because then your apps. don't work anywhere.
But before C++ perl came along and took PL, so the only thing left was the '\0' ... which is about right for the language.
Yeh, whatever you do, when making comparisons between FreeBSD and Linux always choose the version of FreeBSD "out in a couple of months" and the lowest common denominator of all Linux distributions.
The "community" supported tg3 driver, is now both recommended by broadcom and been stable under very high loads for months (at least with all the Red Hat customers, who have the drivers that they helped write and fix).
This isn't true as long as the app. doesn't override the WndProc method. See miguel's comment
While Linux may well co-exist with say the mainframe OSes or FreeBSD or QNX, I find it hard to believe that Microsoft will let it co-exist with Windows. If they keep 90%+ of the desktop they'll kill Linux in the server. They've shown no desire previously to co-exist with anything, and I can't see them starting now.
You need members to have a movement, if MS can reclaim the businesses it's lost and/or stop hardware vendors from supporting it. Linux will have lost, it'll be that thing we tried back at the millenium and it will die.
Yeh, I do this all the time ... under Red Hat. There are still problems, but it's not quite that bad.
Well I'm assuming you are removing mozilla, emacs, ctwm (one of the first to have virtual desktops ... or maybe it was tvwm ... to long ago) etc. from the list.
Then there's also the small things, for instance after using galeon then I hate using almost any browser due to the way you can filter images (it says "block images from X", which is often only a "small" difference of displaying the host ... but that small thing changes the usability immensly -- and this is where OS X has the edge, a noticable amount of "small" things thoughout the UI).
However this is also a case of there being a lot of work to do to applications to get features that people know they want, so that leaves little time to experiment. Also there isn't anything you can really point to as "innovation" in Window XP ... sure it's prettier, and there are probably a bunch of small things that make life easier ... but nothing huge you can say hey look at that.
Then, by that definition, Linux 2.4.x is a microkernel. The filesystems, and the networking layer (and each of the different protocols) are all seperate modules ... which are only very loosly tied to the core.
Sure, most of those don't have a specific process associated with them ... but that's mainly an efficency thing. Even then on my laptop there are eleven different processes that are kernel spawned/owned processes.
Ahh, cool. You should make that fact more obvious. From what I had read it looked like you either needed to write directly to Gtk# or install wine and use Win.Forms.
As an author of a security book and of a well known security application, how much do you feel code cleanliness/quality affects security of products? ... Or do you feel that only a very few products should worry about security?
For instance from looking at nmap-3 it's, ignoring the style, littered with magic numbers _esp_ for things like size of an array of char (which is the only concept like a "string" that nmap has) and also more than a few obvious misuses of strncpy() etc. to go along with it.
Contrast this with other security concious programs, like vsftpd and postfix, and it's like the difference between night and day.
Obviously anyone putting nmap at the end of a CGI is just asking for pain, but one traditional view is that this isn't wouldn't be the problem of nmap ... but of whoever decided that it was security concious, not just a "security" application.
Depends, I don't see any real server apps. written in perl/python/php (Ie. smtp, nntp, ntp, ftp, http, etc.) ... and although we're starting to see some small GUI apps. written in python, they are almost uniformly terrible and fail to run or anything but the developers box.
Some of us just don't mind thinking about the materials as we build the bridge, because let's face it ... you aren't going to be happy if the bridge is made of glass.
This really isn't a problem with C, and half decent C programer can make a simple string API that is safe (and I think you'll find all the secure apps. do this). Or you can even just use one someone else already made. However a lot of people "learn to paint" with C, and too often those early rough sketches end up being used by a lot of people.
When ext3 was created it was a fork form the ext2 code base ... so the above is mainly just misinformed /. crap. It's like saying OpenBSD doesn't share code with NetBSD.
Yes, it's true, that the implementation that had to be changed for the journalling code in ext3 didn't get moved back to ext2 ... but that was so that ext2 didn't have any kind of changes (from an engineering POV any change is bad).
Indeed all "new" ext2 features seem to be going into the ext3 driver only. The ext2 driver is just being kept for ultra stability.
It's not obvious that the above is legal though, for a normal company. For a company that owns/controls both the OS and product, it's even less likely.
So what about the business with a firewall that doesn't allow machines to connect to microsoft's update servers ... are you saying that MS should be allowed to say you can't firewall their products? What about if you run more than one service on that machine, and the update breaks the other non-MS service ... should they then be allowed to require you to update?
Most companies solve this problem by saying it isn't supported on platforms, they don't support. Not that it is not allowed to use it on platforms they don't support.
Is that even possible with rpm? I didn't think it was posible to turn off autodetection of libc etc.
Of course, even if you do, then whne you compile something on 8.0 with glibc updates it won't work on a system without those updates.