Agreed. Ignorant fools who have no idea about smart pointers and containers should shut their traps rather than pontificate about C++, since they know nothing about its first principles. They probably also think you have to use *scanf in C++.
This is a very responsible move by Tesla which takes guts. They are changing the charger design to ameliorate a problem that has nothing to do with the car and nothing to do with the charger and everything to do with the house wiring. Obviously the nutjobs will point their skinny little fingers and accuse Tesla of papering over their own flaw, which is a lie.
The issue posed by The Gavster, which you completely sidestep, is how do you know what has been backported from later kernel development into RH's version of 2.6.32. My answer pointed out that if you are running RHEL, you have paid for RHEL support, so just ask them already (or read the release documents if your are bashful - they are extremely thorough).
Obsiously the RH response in any given case (as you allude to) is going to be either: 1) Yeah, that made it into 5.x already, or 2) Yeah, that's not there yet but will be in 5.y, or 3) Yeah, we can send you a patch for that and you can compile the kernel SRPM, or 3) Sorry, there are no present plans to ever put that in 5.
I smell Windows culture in this reply. Anybody running Windows can upgrade python at any time. In the real world, it's not so easy. Anyone using RHEL5 is stuck with python 2.4 as/usr/bin/python as long as he uses RHEL5, period. RHEL5 is not yet EOL, and still has a large and important user base. Is it your proposal to tell everyone using RHEL5, defense contractors and all, to go to hell as far as your product is concerned?
RHEL6 is the same story. It has 2.6 and will always have 2.6. RHEL6 is absolutely current. There is no RHEL7 yet.
I might be missing something. Undefined behavior clearly labeled as such in the language spec, is undefined, period. It could do anything up to and including erasing your home directory contents. It doesn't matter if that undefined behavior is allowed to vary. Do not code undefined behavior. End of problem.
So because the language itself depends on the exact configuration of whitespace in the code, which can't be discerned thoroughly via ordinary tools used in the ordinary way like cat, less, vi, emacs, we make them use a special editor? Some of us are not too thrilled with that.
I haven't used python a lot. I never got a straight answer to how python deals with a mixture of tabs and space characters in the indenting. So I am at great pains to only use space characters in what python code I write. That is absolutely pointless extra work to deal with. For me and for anyone I give the code to who might need to edit it.
Forgive me for pointing this out, I know I am an asshole for putting it this way, but as the others have essentially pointed out, "upgrading"/usr/bin/python outside of what the distro does for you is a bone headed mistake. You are free to install anything you want wholly within/opt or/usr/local and be guaranteed that in so doing you can't in any way break the OS or anything properly written to work with the OS. Most distros, or at least addon repos, have sanely designed packages like python2.4, python2, python3, etc, that can be freely added without breaking anything existing. The most they will put in/usr/bin is a symlink of python3 to wherever the newly instealled python3 binary is.
Your prima donna "piece of software" that demanded python3, without giving you a side load of same so you would have no difficulties, is amateur crap, but it's easily fixed. Just edit the shebang lines of all the python scripts and change "python" to either the python3 symlink or the python3 binary.
P.S. - don't think I would ever claim that I have never made bone headed mistakes in my life, even in IT work. We all do; getting them corrected is how we learn.
Corporations like to think they are in charge, and they get away with far too much, but they are still trumped by the government (society). For example, in most jurisdictions there are limits to how much liability you can disclaim in connection with implied warranties. The government can take those TOS and EULAs, rip them the hell up, and blow the pieces in the coporations' faces.
Liability is more than just monetary. If your friend commits vehicular homicide, the friend will be the one who goes to trial and then prison. You may still have liability if you knew, or should have known, that he would drive your car tecklessly, but primary liability will be his.
Sigh. Much of this is incorrect. Only the kenel package was changed to put all the patches into a single conglomeration. And this had nothing to do with the CentOS 6.0 delay. Why should CentOS care about the format of the patches? Patches are patches. CentOS (and Scientific Linux for that matter, and the others) doesn't care about the individual patches; just the entire batch, and there they are. Understand that CentOS does not do its own bugfixes. It just propagates those originating from RHEL.
The hold-up with CentOS 6.0 was for several reasons which are enumerated elsewhere on thispage.
By the way, forgive the correction to a post I can't find now, but CentOS does not predate SL. The first release of SL (2004-05-10) was 4 days before the first release of CentOS (2004-05-14). PUIAS predated both of them, and there were other clones that were older - CERN, Fermi, and others.
The FAQ also admits that Red Hat will now owns a majority of the board members, and the board can only take new members via a majority of the board agreeing.
Thank you. You have reassured me that sanity prevails. I can see why paying for one RHEL license and then surreptitiously using it to support 1000 CentOS installations is stealing plain and simple.
Red Hat would have a tough time telling you what OTHER operating systems you can and can't use, though - as OP implied.
Color me baffled. It is ridiculously simple to add EPEL and the other add-on repos to CentOS. I do it exactly the same way on CentOS as on Scientific Linux (and PUIAS, etc): "yum localinstall "http://blah/blah". You are on your own with any of these third party repos on any of these distros. As for atrpms: [shudder].
It depends on definitions. If NetFucker Inc. uses GPL software in a router they sell, who is the "user" of the GPLed software - NetFucker, or the end user of the router? Or both?
GPL is a license that says what you can and can't do with the software. Anyone who violates any of the terms of the license is at liability. Having said that, I don't think the "distributor" label is of significance except as an aid to visualization. it is hard to see a likelihood for the ultimate end user to ever to be in violation. I am not aware of any cases where legal proceedings were brought to bear on an ultimate end user. It's not like the decrepit SCO end game debacle.
The headline is absolutely preposterous, based on utter ignorance. There IS NO CentOS "development" to "help". None. Nada. CentOS simply nabs RHEL source code, debrands it but leaves it otherwise verbatim, and recompiles it into packages with the exact same name and content. Period. It is an excellent way to get an easy to install functional 100% clone of RHEL, and updates, for zero cost, but minus the formal paid support. That is all it ever claimed to be.
One does have to wonder what is ACTUALLY going on here. Presumably Red Hat wants to harness somehow all the energy around CentOS. One suspects the installed CentOS base is vastly larger than the RHEL installed base, and there is a whole lot of energy in unpaid peer support. Presumably Red Hat is eyeing that energy enviously. For CentOS' part, it is much less clear what they gain. Possibly Red Hat gave them an ultimatum, implying or spelling out that they could make their life a living hell, by making it very hard to recompile the source, perhaps as simply as threatening to contaminate the source so thoroughly with Red Hat branding that it would be impractical to "clean" it.
This is all guesswork, but it at least makes some degree of sense as a possibility. Officially, there is absolutely no hint what the motivation is on either side.
Likely the guys at Scientific Linux and the other RHEL clones, the ones that apparently won't be under this new golden umbrella, will have some ideas of substance about what is going on.
Absolutely correct that gcc and clang are nech and neck. One leapfrogs the other, or at the very least matches it with respect to tracking the evolving c++ standard, with each release.
Re the license, GPL is not as free as BSD, end of story.
You got a new car because a set of new shocks and radiator hoses after 20 years was too much to contemplate? And a couple of latches and a fan? [scratches head]
I could completely understand it if the body and frame and undercar pieces were rotted to hell.
As I recall in the 50s you were due for a valve job routinely at 100,000 or so - but hardly a ring job. I guess I don't think of a valve job as an "engine rebuild".
I also recall the cost of a valve job in a V-8 being around maybe one or two C-notes. Ah, the old days.
Even now you can just replace cylinders. It's called top overhaul. General aviation folks do it all the time. Car owners rarely - most want a new car, I guess.
Er, it might have something to do with the fact that the cylinders are part of the engine block and cannot be replaced other than by getting a new or reman engine block. Your point is still well taken, though. Hardly anyone will get a new engine block or engine head, though either is much less than the price of a new car.
The engine is about the LAST part of the car to wear out, given reasonable care and maintenance. An engine actually WILL last a half million miles without major overhaul as it is - only if your treatment is not assholish. An automatic transmission is much more liable to seddenly fail completely, often with no warning. If you are stuck living in the rust belt, the body, frame, brake and exhaust components, are by far the shortest lived due to corrosion.
Ethanol has only about 2/3 the energy density of gasoline, and methanol less than half. Whether you call that "running fine" depends on your point of view. And modification most certainly is required. The stoichiometric air/fuel ratio for alcohols is majorly different from that of gasoline. If using a carburetor you need to rejet, if electronic fuel injection you must remap the mixture in the ECU. Also, the requirements for seals in the fuel system is different.
Slashdot Mirror
What is wrong with that AC pest anyway?
Agreed. Ignorant fools who have no idea about smart pointers and containers should shut their traps rather than pontificate about C++, since they know nothing about its first principles. They probably also think you have to use *scanf in C++.
I'll get in before the nutjob Tesla detractors.
This is a very responsible move by Tesla which takes guts. They are changing the charger design to ameliorate a problem that has nothing to do with the car and nothing to do with the charger and everything to do with the house wiring. Obviously the nutjobs will point their skinny little fingers and accuse Tesla of papering over their own flaw, which is a lie.
The issue posed by The Gavster, which you completely sidestep, is how do you know what has been backported from later kernel development into RH's version of 2.6.32. My answer pointed out that if you are running RHEL, you have paid for RHEL support, so just ask them already (or read the release documents if your are bashful - they are extremely thorough).
Obsiously the RH response in any given case (as you allude to) is going to be either:
1) Yeah, that made it into 5.x already, or
2) Yeah, that's not there yet but will be in 5.y, or
3) Yeah, we can send you a patch for that and you can compile the kernel SRPM, or
3) Sorry, there are no present plans to ever put that in 5.
So your point in the last paragraph is ... ?
Agree. He made the case very convincingly.
I smell Windows culture in this reply. Anybody running Windows can upgrade python at any time. In the real world, it's not so easy. Anyone using RHEL5 is stuck with python 2.4 as /usr/bin/python as long as he uses RHEL5, period. RHEL5 is not yet EOL, and still has a large and important user base. Is it your proposal to tell everyone using RHEL5, defense contractors and all, to go to hell as far as your product is concerned?
RHEL6 is the same story. It has 2.6 and will always have 2.6. RHEL6 is absolutely current. There is no RHEL7 yet.
I might be missing something. Undefined behavior clearly labeled as such in the language spec, is undefined, period. It could do anything up to and including erasing your home directory contents. It doesn't matter if that undefined behavior is allowed to vary. Do not code undefined behavior. End of problem.
So because the language itself depends on the exact configuration of whitespace in the code, which can't be discerned thoroughly via ordinary tools used in the ordinary way like cat, less, vi, emacs, we make them use a special editor? Some of us are not too thrilled with that.
I haven't used python a lot. I never got a straight answer to how python deals with a mixture of tabs and space characters in the indenting. So I am at great pains to only use space characters in what python code I write. That is absolutely pointless extra work to deal with. For me and for anyone I give the code to who might need to edit it.
Forgive me for pointing this out, I know I am an asshole for putting it this way, but as the others have essentially pointed out, " upgrading " /usr/bin/python outside of what the distro does for you is a bone headed mistake . You are free to install anything you want wholly within /opt or /usr/local and be guaranteed that in so doing you can't in any way break the OS or anything properly written to work with the OS. Most distros, or at least addon repos, have sanely designed packages like python2.4, python2, python3, etc, that can be freely added without breaking anything existing. The most they will put in /usr/bin is a symlink of python3 to wherever the newly instealled python3 binary is.
Your prima donna "piece of software" that demanded python3, without giving you a side load of same so you would have no difficulties, is amateur crap, but it's easily fixed. Just edit the shebang lines of all the python scripts and change "python" to either the python3 symlink or the python3 binary.
P.S. - don't think I would ever claim that I have never made bone headed mistakes in my life, even in IT work. We all do; getting them corrected is how we learn.
Well, if you've got RHEL you have support, so you could, like, ASK them. Now, if you've got CentOS, Scientific Linux, et al you can't do that.
Corporations like to think they are in charge, and they get away with far too much, but they are still trumped by the government (society). For example, in most jurisdictions there are limits to how much liability you can disclaim in connection with implied warranties. The government can take those TOS and EULAs, rip them the hell up, and blow the pieces in the coporations' faces.
Liability is more than just monetary. If your friend commits vehicular homicide, the friend will be the one who goes to trial and then prison. You may still have liability if you knew, or should have known, that he would drive your car tecklessly, but primary liability will be his.
Sigh. Much of this is incorrect. Only the kenel package was changed to put all the patches into a single conglomeration. And this had nothing to do with the CentOS 6.0 delay. Why should CentOS care about the format of the patches? Patches are patches. CentOS (and Scientific Linux for that matter, and the others) doesn't care about the individual patches; just the entire batch, and there they are. Understand that CentOS does not do its own bugfixes. It just propagates those originating from RHEL.
The hold-up with CentOS 6.0 was for several reasons which are enumerated elsewhere on this page.
By the way, forgive the correction to a post I can't find now, but CentOS does not predate SL. The first release of SL (2004-05-10) was 4 days before the first release of CentOS (2004-05-14). PUIAS predated both of them, and there were other clones that were older - CERN, Fermi, and others.
The FAQ also admits that Red Hat will now owns a majority of the board members, and the board can only take new members via a majority of the board agreeing.
It's a takeover.
Why would they? Do you have any understanding of the relationshipo of CentOS SRPMs to RHEL SRPMs?
Thank you. You have reassured me that sanity prevails. I can see why paying for one RHEL license and then surreptitiously using it to support 1000 CentOS installations is stealing plain and simple.
Red Hat would have a tough time telling you what OTHER operating systems you can and can't use, though - as OP implied.
Color me baffled. It is ridiculously simple to add EPEL and the other add-on repos to CentOS. I do it exactly the same way on CentOS as on Scientific Linux (and PUIAS, etc): "yum localinstall "http://blah/blah". You are on your own with any of these third party repos on any of these distros. As for atrpms: [shudder].
It depends on definitions. If NetFucker Inc. uses GPL software in a router they sell, who is the "user" of the GPLed software - NetFucker, or the end user of the router? Or both?
GPL is a license that says what you can and can't do with the software. Anyone who violates any of the terms of the license is at liability. Having said that, I don't think the "distributor" label is of significance except as an aid to visualization. it is hard to see a likelihood for the ultimate end user to ever to be in violation. I am not aware of any cases where legal proceedings were brought to bear on an ultimate end user. It's not like the decrepit SCO end game debacle.
The headline is absolutely preposterous, based on utter ignorance. There IS NO CentOS "development" to "help". None. Nada. CentOS simply nabs RHEL source code, debrands it but leaves it otherwise verbatim, and recompiles it into packages with the exact same name and content. Period. It is an excellent way to get an easy to install functional 100% clone of RHEL, and updates, for zero cost, but minus the formal paid support. That is all it ever claimed to be.
One does have to wonder what is ACTUALLY going on here. Presumably Red Hat wants to harness somehow all the energy around CentOS. One suspects the installed CentOS base is vastly larger than the RHEL installed base, and there is a whole lot of energy in unpaid peer support. Presumably Red Hat is eyeing that energy enviously. For CentOS' part, it is much less clear what they gain. Possibly Red Hat gave them an ultimatum, implying or spelling out that they could make their life a living hell, by making it very hard to recompile the source, perhaps as simply as threatening to contaminate the source so thoroughly with Red Hat branding that it would be impractical to "clean" it.
This is all guesswork, but it at least makes some degree of sense as a possibility. Officially, there is absolutely no hint what the motivation is on either side.
Likely the guys at Scientific Linux and the other RHEL clones, the ones that apparently won't be under this new golden umbrella, will have some ideas of substance about what is going on.
Absolutely correct that gcc and clang are nech and neck. One leapfrogs the other, or at the very least matches it with respect to tracking the evolving c++ standard, with each release.
Re the license, GPL is not as free as BSD, end of story.
You got a new car because a set of new shocks and radiator hoses after 20 years was too much to contemplate? And a couple of latches and a fan? [scratches head]
I could completely understand it if the body and frame and undercar pieces were rotted to hell.
As I recall in the 50s you were due for a valve job routinely at 100,000 or so - but hardly a ring job. I guess I don't think of a valve job as an "engine rebuild".
I also recall the cost of a valve job in a V-8 being around maybe one or two C-notes. Ah, the old days.
Er, it might have something to do with the fact that the cylinders are part of the engine block and cannot be replaced other than by getting a new or reman engine block. Your point is still well taken, though. Hardly anyone will get a new engine block or engine head, though either is much less than the price of a new car.
The engine is about the LAST part of the car to wear out, given reasonable care and maintenance. An engine actually WILL last a half million miles without major overhaul as it is - only if your treatment is not assholish. An automatic transmission is much more liable to seddenly fail completely, often with no warning. If you are stuck living in the rust belt, the body, frame, brake and exhaust components, are by far the shortest lived due to corrosion.
Ethanol has only about 2/3 the energy density of gasoline, and methanol less than half. Whether you call that "running fine" depends on your point of view. And modification most certainly is required. The stoichiometric air/fuel ratio for alcohols is majorly different from that of gasoline. If using a carburetor you need to rejet, if electronic fuel injection you must remap the mixture in the ECU. Also, the requirements for seals in the fuel system is different.