"They're basically denying a warranty for something that happens after purchase."
Which, in so many countries is just forbid by law.
It doesn't stop the seller from trying since, at least on my country, "average Joe" is absolutly ignorant about the laws that defend him as a consumer. After all, if only one out of one hundred goes to court and wins they are still making profit out of the other ninety nine.
"The thing is that it wasn't a FPYITA prison [and] His sentence was less than 2 years"
I'm with you it seems ridiculous. In fact, I think it looks so ridiculous it's time for the tinfoil hat: what do you think it's less surprising? A millionaire that probably isn't lacking (lots of) funds in some fiscal paradise who scapes from a low security prision that looks more like a summer camp than a prision only to kill himself, his wife and daughter within 48 hours, or an action from his crime sindicate fellows in order to avoid the guy to sing like a canary to the feds about them and to send a very clear message to others that might be looking for such a way to go out the gang?
"Some small motherboard manufacturer has flawed ACPI tables and refuses to fix them, therefore they MUST out to sabotage Linux? I feel I've missed a step in your logical deduction here."
You missed not just a step but the entire issue.
You have a manufacturer that provides different ACPI BIOS tables for different operative systems. They even have one explicitly tailored for Linux although the manufacturer says it doesn't support Linux. Then the ACPI BIOS table explicitly tailored for Linux is different from the Windows ones in a way that it is not only non-ACPI-compliant (though the vendor insists in certifying it as such) but even breaks in not a clear manner a Linux install.
Couple it with the fact that Microsoft, a convicted monopoly abuser, is the favoured vendor from current state of affairs and already has a proven track record of getting into agreements with OEMs and manufacturers in order to make competitors look like flawed.
It certainly took money from the vendor to reach such a state of matters. Do you really think the most probably cause to be "general profit-driven apathy"?
"Why the poster persists in sticking with such a POS board with obviously wrong BIOS is beyond me."
1) The point being here not that Foxconn produces "obviously wrong BIOS" but that Foxconn might be producing "maliciously wrong BIOS".
2) Do you really think that, in case there is in fact an unpublished agreement between Microsoft and Foxconn to make Linux look like shit the former won't look for similar agreements with other vendors/manufacturers?
3) Do you really think that, in case there is in fact non-published agreements between Microsoft and other vendors/manufacturers to make Linux look like shit, average "Joe user" (or even me, for that matter) will know the real cause to make an informed decision, as free-market theorists require as a must for a sane economic environment, unless somebody takes the time and effort to vawe the hidden facts?
4) Given the exposed arguments, do you still really think this is really "a tempest in a teacup". I do not think this is a tempest in a teacup but a very serious issue.
"A system which spews diagnostic messages will fill up/var, and is far more than an "annoyance". If Debian Stable had such a bug, it would be inexcusable. People rely on it to run critical production systems."
Such a problem may be by itself a "critical" bug, but then, making the offending package dependant on logrotate (if not already) and configuring it to rotate logs at a sane rate would avoid/var being filled by default, thus lowering the buglevel from "critical" to "normal". Maybe such a solution is not good enough for you, but it is reasonable and as long as it is good enough for the guy doing the hard work, it's the solution that you will find on the end product -but, hey, you are not only free but even hailed to offer your own hard work to reach for an even better solution.
Engineering efforts are always full of trade-offs or else functional goals would never reached (things can be always done better -at the cost of the diminishing returns law). But then, as every other effort where people is involved there might arise (and *do* arise) personal conflicts. That's what the technical comitee comes into the equation.
Morale: the more you get involved into the Debian world the more tools you get to make it aligning towards your goals, and that's what open source is all about -but, hey, if you find what it's for you a better deal, for instance putting your money on an "enterprise" distribution such as Red Hat, or even Microsoft Windows, by all means go for it.
"We might like free software because it is free as in speech, but most companies tend to like it because it is free as in beer."
And that's surprising... how? Companies are basically about money, so I can't find suprising that the word "money" appears on each and every company backed-up argument. Not necesarily to say "less" money, but money will be on it.
So you will find arguments like these: * It costs a lot of *money* so it must be good * We are tight on *money* so this solution looks apropiate * It seems more *money* using this very popular but privative operative system, but we will recover it because wages for technical personnel will be lower due to its popularity * I don't have to expend six months to get approved the *money* for that open source app, so it's good. * We save *money* because we can go with best bidder for the support of this open source app. * We save *money* bacause we have an all-encompassing support contract from this important vendor * We don't risk *money* using this software because we can sue the offering company * We don't risk *money* because since it's open source we are not opened to a vendor lock-in strategy * Etc.
"So the assumption is that someone who has worked with proprietary technologies is incapable of working with OSS technologies?"
I don't think so.
I think the parent poster is more on the line that if the candidate has not experience on the open source world, its ability to manage it is still to be seen. If there're candidates that won't have such uncertainty it's just reasonable to stick with them.
"Because I'd say thats pretty much completely contrary to my experience."
That's your experience. Mine is that even at the code monkey level there's people that just don't grasp the open source "thingie" as there is people that is heavily uncomfortable using closed source software.
"I would say that putting that kind of arbitrary restriction on your hiring process may be cutting you off from some valid talent."
Quite true, the point being "arbitrary". It's arbitrary to only hire blond people for a java developer position; it's not arbitrary to hire someone SQL fluent for a DBA, and I don't think it's arbitrary to hire people with open source experience on a shop pushing open source "philosophy" (it *might* be arbitrary to push "the open source philosohpy", though, but that's out of scope).
"What the article didn't mention was this was probably due to lack of financing to actually hire a SQ team rather than preferring to run a software company w/o QA."
Which company, disregarding the financial ability, would want to have a QA dept. when they can go without it?
In a world that doesn't value quality that much, QA is a liability you should avoid as much as you can.
"When using svn+ssh check-in method you have to play around with all sorts of group permissions and sticky flags"
Just don't use it. Use Apache/webdav instead.
On the other hand, when you use ext method with ssh on CVS (you are not using pserver except -maybe, for anonymous check outs, do you?) you end up with exactly the same gaming about group permissions and sticky flags so, again, I still don't see your point except that you don't know how to work with subversion (and you knowledge about CVS doesn't seem to be so deep either).
"Two scenarios: the first, the administrator uses CVS.. he types cvs admin -o 1.3 and revision 1.3 is gone! Phew! The second, the administrator uses SVN.. he says "uh, I'll get back to you on that in a few days..""
I can do that in about ten minutes... by hand; just seconds if scripted (I have done it so rarely I just didn't find the pressure to script it). On the other hand, it will take me about half an hour to do the same with CVS on a lucky day (sorry but no: it's not as simple as "cvs admin -o 1.3": that will delete a revision for *ONE* file. For the general case that you need to delete a whole revision made up of a bunch of files you will have to search *by hand* which files did got into that check in -and you will need to be careful: cvs ci not being atomic there's the chance for a different checkin to be intermingled with the one of your interest, look for their revisions and delete their history at such revisions one by one).
"Because of this one point of difference I still don't believe SVN is a mature product."
Because I don't know how to use the tool, I don't want to believe the tool is a mature product. Quite an intelligent argument.
"for someone who already knows what he is doing it is unbelievably painful to have someone sitting there, constantly interrupting his train of thought, adding pointless detail like "Ooh, you missed a semi-colon!", and requiring constant explanation of every character typed."
You have not done "pair programming".
"Pair programming" is not simply "two guys programming with just one computer"; it is a complete paradigm. And it states that if the two of the pair are of significatly different seniority it is the "junior" the one that will type and the senior the one that will direct, so it is impossible that your pair will stop you with the "you missed a semicolon" since you won't be typing. All in all having different level of expertise is only advocated on training or patronage sessions, it's not for the day-to-day bussiness (some exceptions can be made, like two seniors with different background, say a database expert or a bussiness code expert and a UI one on an XP environment. But then, the UI expert will be typing the "functional" code and the bussiness one the presentation layer). If you are really so above your average mates, then you would only be pairing, say, 10% of your time, not for the coding but for spreading experience. The rest of the time you should be co-working with somebody on your same level or left alone if you are the only "rock-star" programmer.
"It is bad because when I'm not coding I'm just being annoyed by the other persons' horrifically bad coding."
You have not practised "pair programming" and you have a personality problem too: I will concede code from that people is really horrid; still it's up to you being annoyed or being glad for the opportunity to share your knowledge and build a stronger team both on your interest and your company's.
Apart from this, I'm with you: pair programming is of interest mainly for juniors (either junior to junior or from time to time, senior to junior) or seniors but that only when they are sailing unknown waters (so they become "juniors by context").
"man it doesn't matter if I am five years old as long as I maintain a good standard SA practice."
That's right. Experience does matter when you are to overule a sensible standard SA practice with another better fitted to current environment.
"You actually agree with me and fail to admit it..."
Not at all. It seems you forgot what the point for this thread was. I'll refresh your memory: it is about the approach that "if you don't have a test system for each and every update you must be an incompetent sysadmin". My point is that "an old PC for a test system" doesn't hold water and don't produce a better output than a sensible sysadmin doing properly his job.
"you should be rpm'ing to the path of your cvs/svn tree for dns servers, THEN pushing out to a test server, THEN testing the test server, THEN pushing globally. Failure? O yea that's what cvs/svn rollbacks are for..."
And my point is that while you are still convincing management for all this expenditure (both machinery and time), I already finished my maintenance tasks and I'm doing productive work (and yes, I maintain configuration files within a SVN-based repository).
About fifty production servers. Not such a big number but still not a short one either.
"Not only is this bad administrative practice"
I know this is not by itself an argument, but I based my administrative practices on a decade and a half of experience. Maybe -and I only say "maybe", I did think about the pros and cons of my strategies prior to put them into execution... and I've been able to test the results against reality after that.
"BUT as anyone who uses rpm at all knows, your configs are *usually* moved to.rpmsave."
Yes. That's why I... a) Forgot about rpm-based distributions so many years ago (not that this reason is the only one, but it was one among others -clumsy update policies was another one specifically regarding Red Hat) b) I never allowed for automatic updates on any server I admin c) Even when I always manually updated the servers I always run find/etc/*.rpm* after it when on a rpm-based target
On a side note, do you really find defensible for a distribution to take away a locally modified configuration file? Abort or really big notice is the only reasonable policy, but it seems Red Hat hasn't learnt it in all this time.
"I almost suspect this is like an Ubuntu mole or something"
Youngsters always tend to think that the world has always been as they see now.
"You mean to tell me you don't even have an old desktop machine sitting around with RHEL on it to "play" with?"
Neither you, it seems, or you would know "an old desktop machine" leaves out so many corners that it just doesn't matter to have it.
This very bug would be avoided by just looking at the update going on; just that. How many authoritative DNServers do you own that you can't afford this?
But then, let's go real: will your "old desktop machine" cover you from a bug regarding hardware interface? (like a kernel upgrade trashing your NIC) err... nope. Will your "old desktop machine" cover you for a bug that only shows itself after some hours/days? err... nope. There's a point were only the "real thing" will be an "equivalent enough" system for testing. And then, you can afford such kind of redundancy when the system is really thrasing money like crazy when stopped. I know we tend to think of ourself we are the masters of the company, that without us, they would crawl to a grinding halt but, while this idea has some merit, it's only a minimal percentage of the installed base that would get profit from such a so-completly redundant environment.
As it has been already stated, real admins will have real world common sense. For this kind of issue, just not allowing for automatical updates, have a look at the system after the update and hope for the best is the most profitable stanza for the vast majority of situations.
And then, if you are using Red Hat you are paying specifically for timeable and working security updates, as in you are not paying for use licenses, you are not paying for software licenses nor software copyright, you are just paying for the convenience of Red Hat itself providing you with tested binary updates. So if their updates are not confiable, what the hell are you paying them for?
"I just wanted to point out that not all bugs have to be a security problem."
And everybody else was trying to tell you that that's not the point. Of course that not all bugs *have* to be a security problem. The problem is that you don't know *which* of them will be a security problem.
Even your -1 +1 second contrieved example is conceiably leading to a security problem: Some subsystem notices somehow that system time is off by one second to BIOS time by looking directly on the BIOS reading function (so it doesn't know it gets corrected the moment it's written back). Now, trying to do its best, it takes system time and skews it by the off second. After few hours, the time skewing grows up and since the system is authorized via a Kerberos realm, the time skewing forces a DoS in the best case or allows for a reply attack in the worst.
An OS is a complex thing and its interactions tend to grow as 2^n, being "n" the number of considered subsystems. There's no way you can cope with all present and future interactions so you can be sure to dismiss *any* security hazard from any bug.
"A bug that ends up with a computer game character able to jump incredible distances instead of the 'normal' distance doesn't seem like much of a security hole to me."
So what? That only means you didn't find a way to exploit it, not that there isn't.
a) So making use of that bug on an on-line for-the-money game allows me fradulently earn a lot of money? Hummm... who would think of it? b) The recent DNS flaw: it has been there for years; it's only now that somebody found a way to make it into a security vulnerability. As I say, that *you* don't see how can it be exploited, it doesn't mean it *can't* be exploited.
So what we have is: a) Linus' branch is a development branch, not apt for the end user, so he says he is not going to pay special attention to some attributedly "security" bugs. Since it's a development branch all he is insterested into are "bugs" and "features" and that's all. b) Even if he tried to mark some bugs as "SECURITY" it is for sure it will only give you a false sense of security, because there will be non tagged as "SECURITY" bugs that will be explotaible -it's only that the one writing the log didn't figure how by that time. c) If the Linus' branch was meant for stable usage by end users (which is not) and he tagged bugs known to have security implications as "SECURITY" (which he doesn't) he would be opening himself to a legal liability nightmare:
c.1) Company A sues Linus because since he so liberally marked a bug as "SECURITY" he made too easy for a cracker to get into Company A logical premises by just trying exploits agains all "SECURITY" bugs one after the other. We call it fault of due diligence so we sue you.
c.2) Company A sues Linus because he didn't see the security implications of a given bug so he didn't mark it as "SECURITY". Not being marked as "SECURITY", Company A didn't apply the patch and then a cracker managed to crack into the premises. Again, Linus is sued for that.
c.3) Linus marks all bugs as what they are: "bugs". It's up to the "recieving end" to asses how they will impact on their systems and assets. Company A cannot sue now since it's up to them to patch or not to patch without an evaluation of impact from Linus.
"this assumes that only large distributions will exist in near future."
Exactly, and that's my opinion too. But this is no news: this is the predicted outcome from the very day Torvalds said (by the early days of the 2.6 branch) that he was focused no more on producing stable code but on pushing forward kernel development. Linus' branch has been of no direct use for public comsumption for some few years now.
"imagine that somebody has to read full changelogs for ALL packages (included in the distro)... that's just not realistic and insane."
It may be is "not realistic and insane", but that's exactly what happens. The body that makes so it's called "Linux distribution". Probably what you meant was that no *single* *person* is expected to read full changelogs. So what? I bet no single person has ever read all changelogs for Boeing 747 development but still it flights, doesn't it?
"The problem arises when you are using Linux in environments which must meet certain Government (SOX etc)"
Then you are not using "Linux"; you are using "Some Linux Distribution". Let it be, if the case arise, the "Some Linux Distribution" the one dealing with the problem, not some abstract concept you have in your mind but not really anywhere within your company.
"To meet these requirements you must routinely audit your systems and when you audit your systems, you need to classify security related bugs (vulnerabilities ) found, and having clearly marked security related bugs"
To the most of my knowledge at least SUSE and Red Hat explicitly do this, and Debian too, only implicitly, by only allowing security fixes on their Stable branch, so what's the problem, again?
"will help these auditors/tools do a better job."
Better job... than what? Do you want an easy to grasp concept, since you seem to be so much in need of them? Here it is: all and every bug is a security related bug; it's only that for some of them we didn't figure how to exploit them... yet.
"May be for a kernel developer , security related bugs are on the same level as any other bugs"
Quite a sane approach, indeed.
"but for an end user of the Linux system"
An "end user of the Linux system" DOES NOT USE Linus' kernel from kernel.org. If you are using Linux now, just execute on the command line the following: `uname -sr`.
Does it say "Linux 2.6.26" or "Linux 2.6.26-git6". It doesn't, does it? Then you are not using the product Linus Torvalds is talking about, so your cautions are moot.
"Otherwise how are Linux vendors supposed to create security-fix only updates ?"
By doing their damn job. Right at the launch of the 2.6 branch, Linus himself stated that his branch of code was no more apt for "end user" consumption and that it were the distributions' job to stabilize it and add or delete functionality at leisure (not that this was a thing that the distribution were not already doing).
"Or do you expect every one to blindly upgrade the kernel every time a new point release comes out ?"
I myself do that (or almost): as soon as the Debian team tells me that there's a kernel upgrade on Stable, I (almost) blindly apply it. Were I using SUSE or Red Hat I'd surely do the same anyway. All in all, you are talking about things you just unknow or are trying to be a clever troll, your choice.
"There is no reason why a song should make royalties 95 years after its released."
There is, when you put it on proper perspective: Your song forgotten 95 years ago is today used on a movie, a TV advertisement or pushed up on Youtube by a freak fanboy.
Of course, as already stated, that's not money the author is going to ever collect, but the recording companies. It's not a surprise, since they are the ones with the big amounts of time and money to be used on lobbying governments in order to perpetuate their situation. You have seen the current trend of resurrecting songs, characters or scripts. Being current entertaiment industry focused mainly to teenagers, they have a very interesting propiety: they have no memory of "the old days" (of course: they weren't there in the old days, after all). So now you see the malefic plan for world domination from the entertaiment bussiness: you have a successful author today. After a few years you (the company) bury all their crations; they author starves so he sells his copyrights to the company for peanuts (if he didn't so right away when signing his first contract with the company). After fifty years, when nobody remembers the old fart, ta-chin! Big rediscover of how great the author was; books on his memory, new "remasterized" versions of his work, the funky-du-jour version, etc. And all without depending on today's creative inability or having to pay a dime for caprices of a nasty "rock-n-roll star" of today.
Hey, Walt Disney made tons of money just taking characters of old from the public domain and then getting steel-hard copyrights on the derivatives. How much easy it would if there's no public domain to take them from (where anyone can take them before us) but only our own corporate funds.
You can bet that by 2045 there will be a massively marketed revival of the rock'n roll from the seventies... and you can bet it won't be Mick Jagger the one pushing it.
"The royalty/residual model is also used in other industries (e.g. insurance)"
Yessss... and it's a private agreement between the two parts going directly into the contract. I have no problem with that.
"For example, Having sold an insurance policy that continues making money, the salesman may continue being paid for a number of years (depending on the company's compensation strategy)."
That's exactly the point. The insurance company and the salesman entry into an agreement by which the company will pay a percentage of that policy's benefit to the salesman: it's all between the insurance company and the salesman. Of course, I have absolutly zero problems if, say, Sony reaches an agreement with, say, Elvis Costello so Sony will pay a percentage of its benefits on Costello's songs up to the seventh generation. The point is that it's *ME*, the end user, who never entered into such agreement the one who will pay to the seventh generation. In my opinion, that's not a bussiness model, that's a legally backed extortion plan.
"I'd prefer that we used a hexadecimal system [...] The only advantage a base-10 system has over hexadecimal is that most people have 10_(10) fingers so they know how to count to 10_(10)"
But that's a no-brainer! We just force everybody to use Emacs for about two generations and then Humans will be more than ready to finger-count base-16.
Maybe. I must say I didn't see clear what exactly your were your point.
"They leave it up to every user to determine if the distro is right for them."
Instead of marketroid speech as in the automotive industry? You really don't believe the "Nisatra Beast All-terrain" makes you more "macho", do you?
"In the car world they make it very clear, this Aveo is a piece of crap that will get you good gas mileage. This CLK 63 AMG will get you laid but forget about gas mileage."
Yeah, you *do* believe it will make you more macho. Jokes, apart, "Ubuntu is a community developed, Linux-based operating system that is perfect for laptops, desktops and servers.", "redhat redefines automation. Replace rac in your sack and save real money. Red Hat will show you how", "SUSE Linux Enterprise. Your company needs to be ready for everything", "Debian is a free operating system (OS) for your computer.". And that just out of their respective web front page. Regarding their public image, Ubuntu is "Linux for humans", Red Hat and SUSE are "your entreprise partners", Debian is "your Linux free as in free speech". Maybe they have not the best marketing department overthere but they do try to offer an image.
I think the "problem" is on the user side: you are quite akin to cars (you have seen them from your infancy), you even "know" how a computer looks like and behave (ala Windows), and you find yourself entering on a new, unknown, market and you find yourself quite lost. Well, think for a moment about high speed trains: it is not an "amateur" niche, there are thousand of millions there but still, I bet you don't know about the glaring differences among Siemens, Dassault or THSRC products. Linux distributions are new to you an easy to get your hands on them, so you go the easy way and just start to test them without much thinking (if a single CD costed you 2000US$ you probably would get more informations about which one to choose).
Probably "enterprisy" vendors are aware of this "problem" about product discrimination and their marketing departments working hard on it; for the rest of them, it simply is not a concerning problem.
"Personally I like the competition, but the lack of standardization is harming Linux adoption."
So what?
Probably there are similitudes with prissioners dilemma. On one hand, it is not Red Hat concern "linux adoption", nor it is Novell's. Red Hat is worried about Red Hat adoption and Novell is worried about SUSE adoption, not "linux" (and Microsoft is worried about Windows adoption, for that matter); on the other hand, a concerted approach from all the "enterprisey" vendors on "linux adoption" probably would open the "linux niche" so widely that all of them would benefit, even if their direct rivals benefit too (remember Red Hat rivals are Novell and Ubuntu, not so much Microsoft).
"They either need to consolidate all the distros"
Why the heck is going Novell to consolidate towards Red Hat, or the other way around? On a capitalist free market the key is diferenciating not consolidate.
"or start making it clear why you should choose this major distro over that major distro."
They do... where it pays for. So you had problems choosing between Fedora or SUSE Open Edition? So what? There's not a penny on the table. On the other hand, surely Novell tries to make their case against Red Hat or Canonical's Ubuntu on the enterprise market (there were the money is). It's difficult, since at the same time they try to make their case and to target the same market niche (as it's real hard to choose among the offers from different makers on the same market segment on cars and so many times the consumer ends up making his head out of no relevant -and so, marketing-driven, "percieved" advantages), but they try.
"but Ubuntu?"
It targets enterprise and big ISV (as in projects for the government) vendors.
"Fedora?"
It is the growing field for the Red Hat's corporate users of tomorrow.
Slashdot Mirror
"They're basically denying a warranty for something that happens after purchase."
Which, in so many countries is just forbid by law.
It doesn't stop the seller from trying since, at least on my country, "average Joe" is absolutly ignorant about the laws that defend him as a consumer. After all, if only one out of one hundred goes to court and wins they are still making profit out of the other ninety nine.
"The thing is that it wasn't a FPYITA prison [and] His sentence was less than 2 years"
I'm with you it seems ridiculous. In fact, I think it looks so ridiculous it's time for the tinfoil hat: what do you think it's less surprising? A millionaire that probably isn't lacking (lots of) funds in some fiscal paradise who scapes from a low security prision that looks more like a summer camp than a prision only to kill himself, his wife and daughter within 48 hours, or an action from his crime sindicate fellows in order to avoid the guy to sing like a canary to the feds about them and to send a very clear message to others that might be looking for such a way to go out the gang?
"So let me get this straight."
Let's see.
"Some small motherboard manufacturer has flawed ACPI tables and refuses to fix them, therefore they MUST out to sabotage Linux? I feel I've missed a step in your logical deduction here."
You missed not just a step but the entire issue.
You have a manufacturer that provides different ACPI BIOS tables for different operative systems. They even have one explicitly tailored for Linux although the manufacturer says it doesn't support Linux. Then the ACPI BIOS table explicitly tailored for Linux is different from the Windows ones in a way that it is not only non-ACPI-compliant (though the vendor insists in certifying it as such) but even breaks in not a clear manner a Linux install.
Couple it with the fact that Microsoft, a convicted monopoly abuser, is the favoured vendor from current state of affairs and already has a proven track record of getting into agreements with OEMs and manufacturers in order to make competitors look like flawed.
It certainly took money from the vendor to reach such a state of matters. Do you really think the most probably cause to be "general profit-driven apathy"?
"Why the poster persists in sticking with such a POS board with obviously wrong BIOS is beyond me."
1) The point being here not that Foxconn produces "obviously wrong BIOS" but that Foxconn might be producing "maliciously wrong BIOS".
2) Do you really think that, in case there is in fact an unpublished agreement between Microsoft and Foxconn to make Linux look like shit the former won't look for similar agreements with other vendors/manufacturers?
3) Do you really think that, in case there is in fact non-published agreements between Microsoft and other vendors/manufacturers to make Linux look like shit, average "Joe user" (or even me, for that matter) will know the real cause to make an informed decision, as free-market theorists require as a must for a sane economic environment, unless somebody takes the time and effort to vawe the hidden facts?
4) Given the exposed arguments, do you still really think this is really "a tempest in a teacup". I do not think this is a tempest in a teacup but a very serious issue.
"A system which spews diagnostic messages will fill up /var, and is far more than an "annoyance". If Debian Stable had such a bug, it would be inexcusable. People rely on it to run critical production systems."
Such a problem may be by itself a "critical" bug, but then, making the offending package dependant on logrotate (if not already) and configuring it to rotate logs at a sane rate would avoid /var being filled by default, thus lowering the buglevel from "critical" to "normal". Maybe such a solution is not good enough for you, but it is reasonable and as long as it is good enough for the guy doing the hard work, it's the solution that you will find on the end product -but, hey, you are not only free but even hailed to offer your own hard work to reach for an even better solution.
Engineering efforts are always full of trade-offs or else functional goals would never reached (things can be always done better -at the cost of the diminishing returns law). But then, as every other effort where people is involved there might arise (and *do* arise) personal conflicts. That's what the technical comitee comes into the equation.
Morale: the more you get involved into the Debian world the more tools you get to make it aligning towards your goals, and that's what open source is all about -but, hey, if you find what it's for you a better deal, for instance putting your money on an "enterprise" distribution such as Red Hat, or even Microsoft Windows, by all means go for it.
"We might like free software because it is free as in speech, but most companies tend to like it because it is free as in beer."
And that's surprising... how? Companies are basically about money, so I can't find suprising that the word "money" appears on each and every company backed-up argument. Not necesarily to say "less" money, but money will be on it.
So you will find arguments like these:
* It costs a lot of *money* so it must be good
* We are tight on *money* so this solution looks apropiate
* It seems more *money* using this very popular but privative operative system, but we will recover it because wages for technical personnel will be lower due to its popularity
* I don't have to expend six months to get approved the *money* for that open source app, so it's good.
* We save *money* because we can go with best bidder for the support of this open source app.
* We save *money* bacause we have an all-encompassing support contract from this important vendor
* We don't risk *money* using this software because we can sue the offering company
* We don't risk *money* because since it's open source we are not opened to a vendor lock-in strategy
* Etc.
"So the assumption is that someone who has worked with proprietary technologies is incapable of working with OSS technologies?"
I don't think so.
I think the parent poster is more on the line that if the candidate has not experience on the open source world, its ability to manage it is still to be seen. If there're candidates that won't have such uncertainty it's just reasonable to stick with them.
"Because I'd say thats pretty much completely contrary to my experience."
That's your experience. Mine is that even at the code monkey level there's people that just don't grasp the open source "thingie" as there is people that is heavily uncomfortable using closed source software.
"I would say that putting that kind of arbitrary restriction on your hiring process may be cutting you off from some valid talent."
Quite true, the point being "arbitrary". It's arbitrary to only hire blond people for a java developer position; it's not arbitrary to hire someone SQL fluent for a DBA, and I don't think it's arbitrary to hire people with open source experience on a shop pushing open source "philosophy" (it *might* be arbitrary to push "the open source philosohpy", though, but that's out of scope).
"They want to use these people to implement open source projects that fit their needs, for free (beer)."
That's intriguing. Are you saying they won't pay the wages for those people?
"If something is -in- the database (committed), then it will not get lost, no matter how abruptly you pull the plug on the box."
1. Transaction commited
2. Abruptly plugged off machine
3. Corrupted filesystem
4. Last backup is from last night
There: something was -in- the database but it's still lost.
"What the article didn't mention was this was probably due to lack of financing to actually hire a SQ team rather than preferring to run a software company w/o QA."
Which company, disregarding the financial ability, would want to have a QA dept. when they can go without it?
In a world that doesn't value quality that much, QA is a liability you should avoid as much as you can.
"When using svn+ssh check-in method you have to play around with all sorts of group permissions and sticky flags"
Just don't use it. Use Apache/webdav instead.
On the other hand, when you use ext method with ssh on CVS (you are not using pserver except -maybe, for anonymous check outs, do you?) you end up with exactly the same gaming about group permissions and sticky flags so, again, I still don't see your point except that you don't know how to work with subversion (and you knowledge about CVS doesn't seem to be so deep either).
"Two scenarios: the first, the administrator uses CVS.. he types cvs admin -o 1.3 and revision 1.3 is gone! Phew! The second, the administrator uses SVN.. he says "uh, I'll get back to you on that in a few days..""
I can do that in about ten minutes... by hand; just seconds if scripted (I have done it so rarely I just didn't find the pressure to script it). On the other hand, it will take me about half an hour to do the same with CVS on a lucky day (sorry but no: it's not as simple as "cvs admin -o 1.3": that will delete a revision for *ONE* file. For the general case that you need to delete a whole revision made up of a bunch of files you will have to search *by hand* which files did got into that check in -and you will need to be careful: cvs ci not being atomic there's the chance for a different checkin to be intermingled with the one of your interest, look for their revisions and delete their history at such revisions one by one).
"Because of this one point of difference I still don't believe SVN is a mature product."
Because I don't know how to use the tool, I don't want to believe the tool is a mature product. Quite an intelligent argument.
"for someone who already knows what he is doing it is unbelievably painful to have someone sitting there, constantly interrupting his train of thought, adding pointless detail like "Ooh, you missed a semi-colon!", and requiring constant explanation of every character typed."
You have not done "pair programming".
"Pair programming" is not simply "two guys programming with just one computer"; it is a complete paradigm. And it states that if the two of the pair are of significatly different seniority it is the "junior" the one that will type and the senior the one that will direct, so it is impossible that your pair will stop you with the "you missed a semicolon" since you won't be typing. All in all having different level of expertise is only advocated on training or patronage sessions, it's not for the day-to-day bussiness (some exceptions can be made, like two seniors with different background, say a database expert or a bussiness code expert and a UI one on an XP environment. But then, the UI expert will be typing the "functional" code and the bussiness one the presentation layer). If you are really so above your average mates, then you would only be pairing, say, 10% of your time, not for the coding but for spreading experience. The rest of the time you should be co-working with somebody on your same level or left alone if you are the only "rock-star" programmer.
"It is bad because when I'm not coding I'm just being annoyed by the other persons' horrifically bad coding."
You have not practised "pair programming" and you have a personality problem too: I will concede code from that people is really horrid; still it's up to you being annoyed or being glad for the opportunity to share your knowledge and build a stronger team both on your interest and your company's.
Apart from this, I'm with you: pair programming is of interest mainly for juniors (either junior to junior or from time to time, senior to junior) or seniors but that only when they are sailing unknown waters (so they become "juniors by context").
"man it doesn't matter if I am five years old as long as I maintain a good standard SA practice."
That's right. Experience does matter when you are to overule a sensible standard SA practice with another better fitted to current environment.
"You actually agree with me and fail to admit it..."
Not at all. It seems you forgot what the point for this thread was. I'll refresh your memory: it is about the approach that "if you don't have a test system for each and every update you must be an incompetent sysadmin". My point is that "an old PC for a test system" doesn't hold water and don't produce a better output than a sensible sysadmin doing properly his job.
"you should be rpm'ing to the path of your cvs/svn tree for dns servers, THEN pushing out to a test server, THEN testing the test server, THEN pushing globally. Failure? O yea that's what cvs/svn rollbacks are for..."
And my point is that while you are still convincing management for all this expenditure (both machinery and time), I already finished my maintenance tasks and I'm doing productive work (and yes, I maintain configuration files within a SVN-based repository).
"Do you admin one single Linux box?"
About fifty production servers. Not such a big number but still not a short one either.
"Not only is this bad administrative practice"
I know this is not by itself an argument, but I based my administrative practices on a decade and a half of experience. Maybe -and I only say "maybe", I did think about the pros and cons of my strategies prior to put them into execution... and I've been able to test the results against reality after that.
"BUT as anyone who uses rpm at all knows, your configs are *usually* moved to .rpmsave."
Yes. That's why I... /etc/*.rpm* after it when on a rpm-based target
a) Forgot about rpm-based distributions so many years ago (not that this reason is the only one, but it was one among others -clumsy update policies was another one specifically regarding Red Hat)
b) I never allowed for automatic updates on any server I admin
c) Even when I always manually updated the servers I always run find
On a side note, do you really find defensible for a distribution to take away a locally modified configuration file? Abort or really big notice is the only reasonable policy, but it seems Red Hat hasn't learnt it in all this time.
"I almost suspect this is like an Ubuntu mole or something"
Youngsters always tend to think that the world has always been as they see now.
"I guess the syadmins could put in an option in a configuration file somewhere on what files to "keep untouched""
chattr +i /path/to/file
Hey, it works even on non-configuration files!
"You mean to tell me you don't even have an old desktop machine sitting around with RHEL on it to "play" with?"
Neither you, it seems, or you would know "an old desktop machine" leaves out so many corners that it just doesn't matter to have it.
This very bug would be avoided by just looking at the update going on; just that. How many authoritative DNServers do you own that you can't afford this?
But then, let's go real: will your "old desktop machine" cover you from a bug regarding hardware interface? (like a kernel upgrade trashing your NIC) err... nope. Will your "old desktop machine" cover you for a bug that only shows itself after some hours/days? err... nope. There's a point were only the "real thing" will be an "equivalent enough" system for testing. And then, you can afford such kind of redundancy when the system is really thrasing money like crazy when stopped. I know we tend to think of ourself we are the masters of the company, that without us, they would crawl to a grinding halt but, while this idea has some merit, it's only a minimal percentage of the installed base that would get profit from such a so-completly redundant environment.
As it has been already stated, real admins will have real world common sense. For this kind of issue, just not allowing for automatical updates, have a look at the system after the update and hope for the best is the most profitable stanza for the vast majority of situations.
And then, if you are using Red Hat you are paying specifically for timeable and working security updates, as in you are not paying for use licenses, you are not paying for software licenses nor software copyright, you are just paying for the convenience of Red Hat itself providing you with tested binary updates. So if their updates are not confiable, what the hell are you paying them for?
"I just wanted to point out that not all bugs have to be a security problem."
And everybody else was trying to tell you that that's not the point. Of course that not all bugs *have* to be a security problem. The problem is that you don't know *which* of them will be a security problem.
Even your -1 +1 second contrieved example is conceiably leading to a security problem:
Some subsystem notices somehow that system time is off by one second to BIOS time by looking directly on the BIOS reading function (so it doesn't know it gets corrected the moment it's written back). Now, trying to do its best, it takes system time and skews it by the off second. After few hours, the time skewing grows up and since the system is authorized via a Kerberos realm, the time skewing forces a DoS in the best case or allows for a reply attack in the worst.
An OS is a complex thing and its interactions tend to grow as 2^n, being "n" the number of considered subsystems. There's no way you can cope with all present and future interactions so you can be sure to dismiss *any* security hazard from any bug.
"A bug that ends up with a computer game character able to jump incredible distances instead of the 'normal' distance doesn't seem like much of a security hole to me."
So what? That only means you didn't find a way to exploit it, not that there isn't.
a) So making use of that bug on an on-line for-the-money game allows me fradulently earn a lot of money? Hummm... who would think of it?
b) The recent DNS flaw: it has been there for years; it's only now that somebody found a way to make it into a security vulnerability. As I say, that *you* don't see how can it be exploited, it doesn't mean it *can't* be exploited.
So what we have is:
a) Linus' branch is a development branch, not apt for the end user, so he says he is not going to pay special attention to some attributedly "security" bugs. Since it's a development branch all he is insterested into are "bugs" and "features" and that's all.
b) Even if he tried to mark some bugs as "SECURITY" it is for sure it will only give you a false sense of security, because there will be non tagged as "SECURITY" bugs that will be explotaible -it's only that the one writing the log didn't figure how by that time.
c) If the Linus' branch was meant for stable usage by end users (which is not) and he tagged bugs known to have security implications as "SECURITY" (which he doesn't) he would be opening himself to a legal liability nightmare:
c.1) Company A sues Linus because since he so liberally marked a bug as "SECURITY" he made too easy for a cracker to get into Company A logical premises by just trying exploits agains all "SECURITY" bugs one after the other. We call it fault of due diligence so we sue you.
c.2) Company A sues Linus because he didn't see the security implications of a given bug so he didn't mark it as "SECURITY". Not being marked as "SECURITY", Company A didn't apply the patch and then a cracker managed to crack into the premises. Again, Linus is sued for that.
c.3) Linus marks all bugs as what they are: "bugs". It's up to the "recieving end" to asses how they will impact on their systems and assets. Company A cannot sue now since it's up to them to patch or not to patch without an evaluation of impact from Linus.
"this assumes that only large distributions will exist in near future."
Exactly, and that's my opinion too. But this is no news: this is the predicted outcome from the very day Torvalds said (by the early days of the 2.6 branch) that he was focused no more on producing stable code but on pushing forward kernel development. Linus' branch has been of no direct use for public comsumption for some few years now.
"imagine that somebody has to read full changelogs for ALL packages (included in the distro)... that's just not realistic and insane."
It may be is "not realistic and insane", but that's exactly what happens. The body that makes so it's called "Linux distribution". Probably what you meant was that no *single* *person* is expected to read full changelogs. So what? I bet no single person has ever read all changelogs for Boeing 747 development but still it flights, doesn't it?
"The problem arises when you are using Linux in environments which must meet certain Government (SOX etc)"
Then you are not using "Linux"; you are using "Some Linux Distribution". Let it be, if the case arise, the "Some Linux Distribution" the one dealing with the problem, not some abstract concept you have in your mind but not really anywhere within your company.
"To meet these requirements you must routinely audit your systems and when you audit your systems, you need to classify security related bugs (vulnerabilities ) found, and having clearly marked security related bugs"
To the most of my knowledge at least SUSE and Red Hat explicitly do this, and Debian too, only implicitly, by only allowing security fixes on their Stable branch, so what's the problem, again?
"will help these auditors/tools do a better job."
Better job... than what? Do you want an easy to grasp concept, since you seem to be so much in need of them? Here it is: all and every bug is a security related bug; it's only that for some of them we didn't figure how to exploit them... yet.
"May be for a kernel developer , security related bugs are on the same level as any other bugs"
Quite a sane approach, indeed.
"but for an end user of the Linux system"
An "end user of the Linux system" DOES NOT USE Linus' kernel from kernel.org. If you are using Linux now, just execute on the command line the following: `uname -sr`.
Does it say "Linux 2.6.26" or "Linux 2.6.26-git6". It doesn't, does it? Then you are not using the product Linus Torvalds is talking about, so your cautions are moot.
"Otherwise how are Linux vendors supposed to create security-fix only updates ?"
By doing their damn job. Right at the launch of the 2.6 branch, Linus himself stated that his branch of code was no more apt for "end user" consumption and that it were the distributions' job to stabilize it and add or delete functionality at leisure (not that this was a thing that the distribution were not already doing).
"Or do you expect every one to blindly upgrade the kernel every time a new point release comes out ?"
I myself do that (or almost): as soon as the Debian team tells me that there's a kernel upgrade on Stable, I (almost) blindly apply it. Were I using SUSE or Red Hat I'd surely do the same anyway. All in all, you are talking about things you just unknow or are trying to be a clever troll, your choice.
"There is no reason why a song should make royalties 95 years after its released."
There is, when you put it on proper perspective: Your song forgotten 95 years ago is today used on a movie, a TV advertisement or pushed up on Youtube by a freak fanboy.
Of course, as already stated, that's not money the author is going to ever collect, but the recording companies. It's not a surprise, since they are the ones with the big amounts of time and money to be used on lobbying governments in order to perpetuate their situation. You have seen the current trend of resurrecting songs, characters or scripts. Being current entertaiment industry focused mainly to teenagers, they have a very interesting propiety: they have no memory of "the old days" (of course: they weren't there in the old days, after all). So now you see the malefic plan for world domination from the entertaiment bussiness: you have a successful author today. After a few years you (the company) bury all their crations; they author starves so he sells his copyrights to the company for peanuts (if he didn't so right away when signing his first contract with the company). After fifty years, when nobody remembers the old fart, ta-chin! Big rediscover of how great the author was; books on his memory, new "remasterized" versions of his work, the funky-du-jour version, etc. And all without depending on today's creative inability or having to pay a dime for caprices of a nasty "rock-n-roll star" of today.
Hey, Walt Disney made tons of money just taking characters of old from the public domain and then getting steel-hard copyrights on the derivatives. How much easy it would if there's no public domain to take them from (where anyone can take them before us) but only our own corporate funds.
You can bet that by 2045 there will be a massively marketed revival of the rock'n roll from the seventies... and you can bet it won't be Mick Jagger the one pushing it.
"The royalty/residual model is also used in other industries (e.g. insurance)"
Yessss... and it's a private agreement between the two parts going directly into the contract. I have no problem with that.
"For example, Having sold an insurance policy that continues making money, the salesman may continue being paid for a number of years (depending on the company's compensation strategy)."
That's exactly the point. The insurance company and the salesman entry into an agreement by which the company will pay a percentage of that policy's benefit to the salesman: it's all between the insurance company and the salesman. Of course, I have absolutly zero problems if, say, Sony reaches an agreement with, say, Elvis Costello so Sony will pay a percentage of its benefits on Costello's songs up to the seventh generation. The point is that it's *ME*, the end user, who never entered into such agreement the one who will pay to the seventh generation. In my opinion, that's not a bussiness model, that's a legally backed extortion plan.
"I'd prefer that we used a hexadecimal system [...] The only advantage a base-10 system has over hexadecimal is that most people have 10_(10) fingers so they know how to count to 10_(10)"
But that's a no-brainer! We just force everybody to use Emacs for about two generations and then Humans will be more than ready to finger-count base-16.
"Try using it to save or select a file in a directory with a few thousand files in"
Or try to find a file under a "dot" directory.
"I think you missed my point"
Maybe. I must say I didn't see clear what exactly your were your point.
"They leave it up to every user to determine if the distro is right for them."
Instead of marketroid speech as in the automotive industry? You really don't believe the "Nisatra Beast All-terrain" makes you more "macho", do you?
"In the car world they make it very clear, this Aveo is a piece of crap that will get you good gas mileage. This CLK 63 AMG will get you laid but forget about gas mileage."
Yeah, you *do* believe it will make you more macho. Jokes, apart, "Ubuntu is a community developed, Linux-based operating system that is perfect for laptops, desktops and servers.", "redhat redefines automation. Replace rac in your sack and save real money. Red Hat will show you how", "SUSE Linux Enterprise. Your company needs to be ready for everything", "Debian is a free operating system (OS) for your computer.". And that just out of their respective web front page. Regarding their public image, Ubuntu is "Linux for humans", Red Hat and SUSE are "your entreprise partners", Debian is "your Linux free as in free speech". Maybe they have not the best marketing department overthere but they do try to offer an image.
I think the "problem" is on the user side: you are quite akin to cars (you have seen them from your infancy), you even "know" how a computer looks like and behave (ala Windows), and you find yourself entering on a new, unknown, market and you find yourself quite lost. Well, think for a moment about high speed trains: it is not an "amateur" niche, there are thousand of millions there but still, I bet you don't know about the glaring differences among Siemens, Dassault or THSRC products. Linux distributions are new to you an easy to get your hands on them, so you go the easy way and just start to test them without much thinking (if a single CD costed you 2000US$ you probably would get more informations about which one to choose).
Probably "enterprisy" vendors are aware of this "problem" about product discrimination and their marketing departments working hard on it; for the rest of them, it simply is not a concerning problem.
"Personally I like the competition, but the lack of standardization is harming Linux adoption."
So what?
Probably there are similitudes with prissioners dilemma. On one hand, it is not Red Hat concern "linux adoption", nor it is Novell's. Red Hat is worried about Red Hat adoption and Novell is worried about SUSE adoption, not "linux" (and Microsoft is worried about Windows adoption, for that matter); on the other hand, a concerted approach from all the "enterprisey" vendors on "linux adoption" probably would open the "linux niche" so widely that all of them would benefit, even if their direct rivals benefit too (remember Red Hat rivals are Novell and Ubuntu, not so much Microsoft).
"They either need to consolidate all the distros"
Why the heck is going Novell to consolidate towards Red Hat, or the other way around? On a capitalist free market the key is diferenciating not consolidate.
"or start making it clear why you should choose this major distro over that major distro."
They do... where it pays for. So you had problems choosing between Fedora or SUSE Open Edition? So what? There's not a penny on the table. On the other hand, surely Novell tries to make their case against Red Hat or Canonical's Ubuntu on the enterprise market (there were the money is). It's difficult, since at the same time they try to make their case and to target the same market niche (as it's real hard to choose among the offers from different makers on the same market segment on cars and so many times the consumer ends up making his head out of no relevant -and so, marketing-driven, "percieved" advantages), but they try.
"but Ubuntu?"
It targets enterprise and big ISV (as in projects for the government) vendors.
"Fedora?"
It is the growing field for the Red Hat's corporate users of tomorrow.