Consumer drives have this thing called being half the price, keep one spare, what the heck if it breaks go out and buy a new one, in 1 a hour, still faster than 4 hours. What kind of enterprise organization wouldn't have a few hard drives spare just in case a few failed.
The Fortune-sized one I used to work at, alas. And the RAID drives would always blow out while I was on vacation. Then before I got back, another RAID drive would blow, breaking the array. And in-house inventory wouldn't have any spares and the drive in question was no longer available from approved suppliers.
We weren't just paying for the 7-year warranty, however. We were also paying for the high-performance SCSI interfaces. These systems were doing mainframe-grade work. We even had mainframe tape readers.
There's a reason. Java wasn't designed to be unsafe.
If you need to call native code, JNI is even less safe than providing unsafe primitives in the Java language itself would be. That makes Java's design either poor, or it is a feeble attempt to discourage the use of unsafe modules by making them cumbersome or inefficient.
If these features are an impediment, Java isn't the best platform to be using.
Yes, and that makes Java a bad choice for lots of applications.
EVERYTHING is a bad choice for some application. Only a small child with a hammer - or a silver-bullet seeking PHB - thinks that one tool can solve all problems.
The last time I needed to talk outside the JVM was in the last century. That's because I'm not presently writing device drivers, Interrupt Service routines or other functions outside the scope of general web business apps.
I was one of the very first to field a C++ compiler product, but I haven't written any C++ in years, because I prefer working on a platform with a rich, if occasionally warty set of standardized pre-debugged classes. For quick-and-dirty I use Python or Perl (for regex-intensive stuff) on the command line and PHP on the web.
I have no illusions that there is a "perfect" language for all things, but I really do get annoyed when people make claims about alleged inefficiencies without numbers to back them up, anecdotes of obsolete platform implementations or gross misuse by people who would be equally incompetent in any language or on any platform.
When all's said and done, when you put power tools in the hands of the incompetent, you amplify their incompetence.
Most of the examples you listed weren't faults of Java, they're faults of the architects and people like that commit similar atrocities whether in Java, C, or VB. IBM mainframes were performing address-space hopscotch on CICS before Java was even born.
As for WebSphere, IBM isn't as ubiquitous as they used to be. Every few years I have to work with it. The rest of the time I have better tools at my disposal.
No, Java is not perfect. But it can be very effective when not wielded by clueless monkeys. The real problem isn't the language, it's the business attitude that all you need to develop complex systems is a handful of cheap monkeys.
Part of the problem is that Java refuses to provide unsafe primitives in the Java language itself, for no good reason.
There's a reason. Java wasn't designed to be unsafe. It exerts a lot of effort to avoid being unsafe, which is why things like buffer overflows are not routine exploits in Java code. It also takes the "write once/run anywhere" concept very, very seriously. Once you reach the JNI level, of course, all bets are off, but again, Java is primarily self-contained.
If these features are an impediment, Java isn't the best platform to be using.
One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.
I've heard that before and am seriously interested in 2 questions:
1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.
2. Any benchmarks, cites, whatever?
#2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas) and the standard rule for years has been to turn off exceptions. Many compilers for embedded work even do that by default. I'd love to be able to change that, since exceptions make error handling so much easier.
Just thought of something else: even if modern compilers have improved, it's far from a guarantee that ones for embedded use have. At least gcc should though, and that's used for some embedded work.
Your Mileage May Vary. I recommend doing performance tests. It doesn't matter how any other system handles exceptions. Only the ones that you use yourself.
Modern JVMs often out-perform even assembly language due to their ability to analyse and tune for the actual operating environment. Java routinely out-performs C - which like assembly produces static code that cannot automatically tune itself at run time. We're no longer doing interpreters with the old 10-to-1 performance differential that such environments were known for.
True, a small, trivial Java program will perform horribly relative to an equivalent non-VM language. The VM takes a lot of work to set up. But the primary employment for Java these days is in servers where the VM startup occurs maybe once a day or less and the initial massive performance hit is more than compensated for over the productive run time of the VM.
As much as I loathe guys like Mark Zuckerberg, I'll wager giving some of his script monkeys a few months to come up with a functional ACA website, and they'd probably do it, using largely open source tools to pull it off.
Mostly functioning.
And with security like a sieve.
Those two extras are what make the difference between overnight delivery and something that can stand up to real-world stresses.
That Porsche may have 600 hp, but in the hand of an excellent driver, it would be still a very safe car.
Maybe, maybe not.
I had a car that originally came with V-Series radials. On dry roads it would corner like anything. When it rained it could fishtail so bad you;d practically see your own tail lights. Finally decided to downgrade the tires a notch. What I lost in cornering was more than made up with in making rainy days less (ahem) exciting.
The way a vehicle handles on given road and weather conditions is as much due to how the car is built as the driver. A car that is optimal for the driving conditions in question shouldn't be a continual battle to operate.
That is incorrect. There was never a reason to ban an aid that allows a vehicle to go faster, it is racing after all, the point is to go faster.
No.
In racing the point is to win.
Case in point, there are motorsport leagues where they race Geo Metros and "classic" minivans. "Fast" doesn't even come into play, it's all about skill (and swappin' paint).
Even the Daytona 500, I think. IIRC, they have throttle plate restrictors that keep them down to just over 200MPH.
Digital is pretty much "all or nothing", with freezes, posterizing, etc.. if you've got a bad signal.
If you've got a bad analog signal, you'll get snow and static, but you'll still be able to see what's happening.
But digital goes further, so if you're on the fringe of an analogue signal, you'll get a decent digital signal (well, as long as they're being transmitted from the same approximate location).
In theory. I live probably less than 10 miles from a major transmitter farm, but since it went digital, I have to be a lot more careful about fiddling with the antenna or the whole thing blues out, audio and all. And hi-fi audio is usually the last thing to go.
Sadly, shortly before the digital switch I'd discovered an interesting analog channel from a distant metro area. It was just at that point where you could get a snowy-but-watchable image. All gone now.
Is it just me that thinks that, when aiming at kids, BASIC still probably is the easiest language to understand (if not the most rigorous)?
The first example is just HORRENDOUS anyway - boilerplater and ternary crap getting in the way. The second is simplified using specific language facilities and objects.
So what would have been wrong with a BASIC-like:
FOR EACH USER IN USERS
SENDMESSAGE(USER, "Happy Birthday") NEXT USER
As I get older, I believe more and more than the creators of BASIC knew what they were doing, and make something kids and beginners could understand quickly even if it wasn't perfect.
Historically, Kemeny and Kurtz had had little or no exposure to object-oriented design in 1964. I believe that the first serious attempts at Object-Oriented thinking didn't even begin until 1964.
They were basically attempting to create an interactive "FORTRAN Lite" language. Which they did, quite successfully. I love FORTRAN. But I am also quite aware the creation of the term "spaghetti code" probably owes more to FORTRAN than it does any other language except assembler, and even more, probably, than COBOL.
Structured Programming was an attempt to tame the spaghetti bowl, but it didn't begin to see wide use until the 1970s. OOP was just beginning to be a thing, as it broke out of the narrow specialty languages such as Simula and achieved widespread fame in SmallTalk, before it finally went mainstream in C++.
Sometimes things get more complex as time progresses, but sometimes with time we learn how to make complex things simpler. Procedural starts off simple, but then a procedure inside a basic class is simple. The difference is in how they grow and in how you think about what you are doing.
You have to put your address on the 1040 along with your SSN and swear under penalty of perjury that it is correct.
Which address? You don't put them all on if you've got multiple homes.
Give me a break. There's this concept known as the "legal address", which is usually the person's primary address. It's used not only for hunting down and persecuting people but also as the place to send refund checks (or penalty assessments) to.
However, the point is, the IRS has the resources of the Department of the Treasury at its beck and call if it has reason to want your tax records and you get snotty about it. You can use a dropoff mailbox on the return and hide that way, but if they want you, they can call in law enforcement officers to drag you in by your heels. Plus, since they of all people have your SSN and despite attempts to outlaw it as a form of identification, your SSN gets splattered all over the landscape, they can use that to track you down. This is just the everyday law enforcement stuff before we even begin start with the tinfoil-hat stuff. The IRS has earned, if not cultivated, a reputation for the one branch of the US Government that you don't joke around with.
You CAN disappear from the view and grasp of the IRS, but it's going to severely limit where you can go and what you can do. If you're into the John MacAfee lifestyle, for example. But if they get you, they'll come down on you like a drone strike.
But if you file taxes, trust me. They know where you live.
Maybe, maybe not. If he doesn't own his home, and it's an asset of a corporation to which he is affiliated, it might be lost in the noise.
You have to put your address on the 1040 along with your SSN and swear under penalty of perjury that it is correct. The IRS is good friends with the FBI (just ask Al Capone). The FBI chats with the NSA.
In many cases, it's because they don't want to pay to train you. And that includes paying for your time to get up to speed. There's a lot of time spent already understanding the deployment and development environment. If the company is working with a specific set of technology, then bringing someone in that has used related technology is often not good enough. There are specific design patterns that you use with different technologies, and specific ways of applying them for that technology. And they might not have people internally that have time to help you figure out the best way to do things, or maintain the garbage you build on your own because you don't have experience with these things. Love it or hate it, it's the way things go sometimes. And if you hate it, don't apply to these places. Of course, there are plenty of companies that see this stuff and think that's the way to do it - but don't need it. So, now you have an industry following "best practices" that don't apply to them... do you want to work at these companies?
This is a bit of a fallacy.
Most technologies I can become proficient with in under 3 months.
Learning how the company works, however, can take an entire year. Who does what, who needs what, how this or that is done and why, and so forth.
I disagree. A lot of job postings really are wishlists. If they have four out of five of the 'requirements' it can still be worth applying at least if you are established in your career and field and are listing some prior experience.
If you have most of what they claim to be looking for and a positive work history with good references its worth a shot anyway. The worst thing that happens to you is you spend half an hour tweaking your cover letter and uploading your CV, and then nobody calls you back. You are out pretty little if you either A need a job or B really think the position is something you like to do.
If you do get to the interview have a story to tell about how you approached something unfamiliar and got up to speed quickly. You'll use this as your answer when the question comes up, "your resume does not mention any experience with $X, what about that?"
This has worked for me in the past.
The problem is that a lot of screening is automated and I have little confidence that the automated screening has a "close enough" setting.
Plus, of course, it's worthless when the job requires 2 years of DB2 and the applicant has 5 years of Oracle.
Old idea. My financial records are all on paper. In an unheated storage space. When the IRS wants to audit me, they are welcome to sit in there and go through whatever they want.
When the IRS wants to audit you, you'll be ordered to gather up all those paper records and bring them in.
You don't want the IRS visiting your house. They have a reputation for doing so in very unsubtle ways.
Considering specials in the decision is important, people who shop from a list may spend more because they buy what's on their list instead of what's on sale.
Not me. I have to have a list, since otherwise it takes me 3 or 4 trips before I get everything. Leaky memory.
And if an item's on sale, I often grab it in addition to what's on the list. Plus, if I think of a specific use of something, that may require further purchases in order to use it as I wish.
C'mon RedHat/CentOS recommends you don't do an in-place upgrade.
What? I've done at least 4 in place Fedora Upgrades.
Yes, but I've also been nailed when the in-place upgrade didn't check to see if there was enough free disk space in the boot partition first.
CentOS policy on upgrade-in-place is generally "Yes, some people are doing this. You can too, if you're brave enough. But since we're the free version of Enterprise Linux and enterprises prefer solid guarantees, we're not brave enough to do that, since Red Hat doesn't want to risk it."
There have been 1 or 2 CentOS releases where I think that major-version upgrades were formally blessed, but not from v5 to v6. Minor version upgrade-in-place does work on CentOS 9 to 10. I don't think you even had to explicitly request it.
But I really feel the community drop-off in ubuntu, compared to a couple of years ago. And that's pretty important. They're going the way of Red Hat.
I'm betting Canonical wish they were going the way of Red Hat, with a billion plus of revenue.
While I'm OK with the revenue part (I own shares! See me SMILE!!!), this seems to be saying that Red Hat as a platform isn't doing too well. As far as I can tell, Fedora and CentOS are going Great Guns, and Red Hat itself can't be raking in all that cash without doing something right.
Am I missing something? Gnome 3 doesn't count. That particular curse affects more than just Red Hat.
Slashdot Mirror
Consumer drives have this thing called being half the price, keep one spare, what the heck if it breaks go out and buy a new one, in 1 a hour, still faster than 4 hours. What kind of enterprise organization wouldn't have a few hard drives spare just in case a few failed.
The Fortune-sized one I used to work at, alas. And the RAID drives would always blow out while I was on vacation. Then before I got back, another RAID drive would blow, breaking the array. And in-house inventory wouldn't have any spares and the drive in question was no longer available from approved suppliers.
We weren't just paying for the 7-year warranty, however. We were also paying for the high-performance SCSI interfaces. These systems were doing mainframe-grade work. We even had mainframe tape readers.
If you need to call native code, JNI is even less safe than providing unsafe primitives in the Java language itself would be. That makes Java's design either poor, or it is a feeble attempt to discourage the use of unsafe modules by making them cumbersome or inefficient.
Yes, and that makes Java a bad choice for lots of applications.
EVERYTHING is a bad choice for some application. Only a small child with a hammer - or a silver-bullet seeking PHB - thinks that one tool can solve all problems.
The last time I needed to talk outside the JVM was in the last century. That's because I'm not presently writing device drivers, Interrupt Service routines or other functions outside the scope of general web business apps.
I was one of the very first to field a C++ compiler product, but I haven't written any C++ in years, because I prefer working on a platform with a rich, if occasionally warty set of standardized pre-debugged classes. For quick-and-dirty I use Python or Perl (for regex-intensive stuff) on the command line and PHP on the web.
I have no illusions that there is a "perfect" language for all things, but I really do get annoyed when people make claims about alleged inefficiencies without numbers to back them up, anecdotes of obsolete platform implementations or gross misuse by people who would be equally incompetent in any language or on any platform.
When all's said and done, when you put power tools in the hands of the incompetent, you amplify their incompetence.
Most of the examples you listed weren't faults of Java, they're faults of the architects and people like that commit similar atrocities whether in Java, C, or VB. IBM mainframes were performing address-space hopscotch on CICS before Java was even born.
As for WebSphere, IBM isn't as ubiquitous as they used to be. Every few years I have to work with it. The rest of the time I have better tools at my disposal.
No, Java is not perfect. But it can be very effective when not wielded by clueless monkeys. The real problem isn't the language, it's the business attitude that all you need to develop complex systems is a handful of cheap monkeys.
Part of the problem is that Java refuses to provide unsafe primitives in the Java language itself, for no good reason.
There's a reason. Java wasn't designed to be unsafe. It exerts a lot of effort to avoid being unsafe, which is why things like buffer overflows are not routine exploits in Java code. It also takes the "write once/run anywhere" concept very, very seriously. Once you reach the JNI level, of course, all bets are off, but again, Java is primarily self-contained.
If these features are an impediment, Java isn't the best platform to be using.
One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.
I've heard that before and am seriously interested in 2 questions:
1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.
2. Any benchmarks, cites, whatever?
#2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas) and the standard rule for years has been to turn off exceptions. Many compilers for embedded work even do that by default. I'd love to be able to change that, since exceptions make error handling so much easier.
Just thought of something else: even if modern compilers have improved, it's far from a guarantee that ones for embedded use have. At least gcc should though, and that's used for some embedded work.
Your Mileage May Vary. I recommend doing performance tests. It doesn't matter how any other system handles exceptions. Only the ones that you use yourself.
Java is a bit of a nightmare for performance.
Citation needed.
Modern JVMs often out-perform even assembly language due to their ability to analyse and tune for the actual operating environment. Java routinely out-performs C - which like assembly produces static code that cannot automatically tune itself at run time. We're no longer doing interpreters with the old 10-to-1 performance differential that such environments were known for.
True, a small, trivial Java program will perform horribly relative to an equivalent non-VM language. The VM takes a lot of work to set up. But the primary employment for Java these days is in servers where the VM startup occurs maybe once a day or less and the initial massive performance hit is more than compensated for over the productive run time of the VM.
Yes,
You are forgetting that one of them (hint the German one), generally gets it right.
You mean the one that essential shut down the Hershey Corporation for about a week?
Actually, Oracle wouldn't even exist if it hadn't got its start on Federal projects.
The words that have doomed more IT projects than any other:
"All You Have To Do Is..."
As much as I loathe guys like Mark Zuckerberg, I'll wager giving some of his script monkeys a few months to come up with a functional ACA website, and they'd probably do it, using largely open source tools to pull it off.
Mostly functioning.
And with security like a sieve.
Those two extras are what make the difference between overnight delivery and something that can stand up to real-world stresses.
... even a tricycle can become deadly.
Stop blaming the car.
The problem is the driver.
That Porsche may have 600 hp, but in the hand of an excellent driver, it would be still a very safe car.
Maybe, maybe not.
I had a car that originally came with V-Series radials. On dry roads it would corner like anything. When it rained it could fishtail so bad you;d practically see your own tail lights. Finally decided to downgrade the tires a notch. What I lost in cornering was more than made up with in making rainy days less (ahem) exciting.
The way a vehicle handles on given road and weather conditions is as much due to how the car is built as the driver. A car that is optimal for the driving conditions in question shouldn't be a continual battle to operate.
That is incorrect. There was never a reason to ban an aid that allows a vehicle to go faster, it is racing after all, the point is to go faster.
No.
In racing the point is to win.
Case in point, there are motorsport leagues where they race Geo Metros and "classic" minivans. "Fast" doesn't even come into play, it's all about skill (and swappin' paint).
Even the Daytona 500, I think. IIRC, they have throttle plate restrictors that keep them down to just over 200MPH.
So, all the market needs are more bloated version of Operating Systems?
No. It needs more bloated versions of Office suites, too.
Analog degrades better if you're on the fringe.
Digital is pretty much "all or nothing", with freezes, posterizing, etc.. if you've got a bad signal.
If you've got a bad analog signal, you'll get snow and static, but you'll still be able to see what's happening.
But digital goes further, so if you're on the fringe of an analogue signal, you'll get a decent digital signal (well, as long as they're being transmitted from the same approximate location).
In theory. I live probably less than 10 miles from a major transmitter farm, but since it went digital, I have to be a lot more careful about fiddling with the antenna or the whole thing blues out, audio and all. And hi-fi audio is usually the last thing to go.
Sadly, shortly before the digital switch I'd discovered an interesting analog channel from a distant metro area. It was just at that point where you could get a snowy-but-watchable image. All gone now.
Is it just me that thinks that, when aiming at kids, BASIC still probably is the easiest language to understand (if not the most rigorous)?
The first example is just HORRENDOUS anyway - boilerplater and ternary crap getting in the way. The second is simplified using specific language facilities and objects.
So what would have been wrong with a BASIC-like:
FOR EACH USER IN USERS
SENDMESSAGE(USER, "Happy Birthday")
NEXT USER
As I get older, I believe more and more than the creators of BASIC knew what they were doing, and make something kids and beginners could understand quickly even if it wasn't perfect.
Historically, Kemeny and Kurtz had had little or no exposure to object-oriented design in 1964. I believe that the first serious attempts at Object-Oriented thinking didn't even begin until 1964.
They were basically attempting to create an interactive "FORTRAN Lite" language. Which they did, quite successfully. I love FORTRAN. But I am also quite aware the creation of the term "spaghetti code" probably owes more to FORTRAN than it does any other language except assembler, and even more, probably, than COBOL.
Structured Programming was an attempt to tame the spaghetti bowl, but it didn't begin to see wide use until the 1970s. OOP was just beginning to be a thing, as it broke out of the narrow specialty languages such as Simula and achieved widespread fame in SmallTalk, before it finally went mainstream in C++.
Sometimes things get more complex as time progresses, but sometimes with time we learn how to make complex things simpler. Procedural starts off simple, but then a procedure inside a basic class is simple. The difference is in how they grow and in how you think about what you are doing.
Alan Kay seemed to think that kids found the idea of playing with objects more intuitive than playing with loose code.
I'm not so sure I disagree with him, having seen what can come of loose code.
You have to put your address on the 1040 along with your SSN and swear under penalty of perjury that it is correct.
Which address? You don't put them all on if you've got multiple homes.
Give me a break. There's this concept known as the "legal address", which is usually the person's primary address. It's used not only for hunting down and persecuting people but also as the place to send refund checks (or penalty assessments) to.
However, the point is, the IRS has the resources of the Department of the Treasury at its beck and call if it has reason to want your tax records and you get snotty about it. You can use a dropoff mailbox on the return and hide that way, but if they want you, they can call in law enforcement officers to drag you in by your heels. Plus, since they of all people have your SSN and despite attempts to outlaw it as a form of identification, your SSN gets splattered all over the landscape, they can use that to track you down. This is just the everyday law enforcement stuff before we even begin start with the tinfoil-hat stuff. The IRS has earned, if not cultivated, a reputation for the one branch of the US Government that you don't joke around with.
You CAN disappear from the view and grasp of the IRS, but it's going to severely limit where you can go and what you can do. If you're into the John MacAfee lifestyle, for example. But if they get you, they'll come down on you like a drone strike.
But if you file taxes, trust me. They know where you live.
Maybe, maybe not. If he doesn't own his home, and it's an asset of a corporation to which he is affiliated, it might be lost in the noise.
You have to put your address on the 1040 along with your SSN and swear under penalty of perjury that it is correct. The IRS is good friends with the FBI (just ask Al Capone). The FBI chats with the NSA.
You're doomed.
Actually, you said unheated storage space. That could be a basement or a closet.
But if you file taxes, trust me. They know where you live.
In many cases, it's because they don't want to pay to train you. And that includes paying for your time to get up to speed. There's a lot of time spent already understanding the deployment and development environment. If the company is working with a specific set of technology, then bringing someone in that has used related technology is often not good enough. There are specific design patterns that you use with different technologies, and specific ways of applying them for that technology. And they might not have people internally that have time to help you figure out the best way to do things, or maintain the garbage you build on your own because you don't have experience with these things. Love it or hate it, it's the way things go sometimes. And if you hate it, don't apply to these places. Of course, there are plenty of companies that see this stuff and think that's the way to do it - but don't need it. So, now you have an industry following "best practices" that don't apply to them... do you want to work at these companies?
This is a bit of a fallacy.
Most technologies I can become proficient with in under 3 months.
Learning how the company works, however, can take an entire year. Who does what, who needs what, how this or that is done and why, and so forth.
I disagree. A lot of job postings really are wishlists. If they have four out of five of the 'requirements' it can still be worth applying at least if you are established in your career and field and are listing some prior experience.
If you have most of what they claim to be looking for and a positive work history with good references its worth a shot anyway. The worst thing that happens to you is you spend half an hour tweaking your cover letter and uploading your CV, and then nobody calls you back. You are out pretty little if you either A need a job or B really think the position is something you like to do.
If you do get to the interview have a story to tell about how you approached something unfamiliar and got up to speed quickly. You'll use this as your answer when the question comes up, "your resume does not mention any experience with $X, what about that?"
This has worked for me in the past.
The problem is that a lot of screening is automated and I have little confidence that the automated screening has a "close enough" setting.
Plus, of course, it's worthless when the job requires 2 years of DB2 and the applicant has 5 years of Oracle.
Old idea. My financial records are all on paper. In an unheated storage space. When the IRS wants to audit me, they are welcome to sit in there and go through whatever they want.
When the IRS wants to audit you, you'll be ordered to gather up all those paper records and bring them in.
You don't want the IRS visiting your house. They have a reputation for doing so in very unsubtle ways.
Considering specials in the decision is important, people who shop from a list may spend more because they buy what's on their list instead of what's on sale.
Not me. I have to have a list, since otherwise it takes me 3 or 4 trips before I get everything. Leaky memory.
And if an item's on sale, I often grab it in addition to what's on the list. Plus, if I think of a specific use of something, that may require further purchases in order to use it as I wish.
C'mon RedHat/CentOS recommends you don't do an in-place upgrade.
What? I've done at least 4 in place Fedora Upgrades.
Yes, but I've also been nailed when the in-place upgrade didn't check to see if there was enough free disk space in the boot partition first.
CentOS policy on upgrade-in-place is generally "Yes, some people are doing this. You can too, if you're brave enough. But since we're the free version of Enterprise Linux and enterprises prefer solid guarantees, we're not brave enough to do that, since Red Hat doesn't want to risk it."
There have been 1 or 2 CentOS releases where I think that major-version upgrades were formally blessed, but not from v5 to v6. Minor version upgrade-in-place does work on CentOS 9 to 10. I don't think you even had to explicitly request it.
But I really feel the community drop-off in ubuntu, compared to a couple of years ago. And that's pretty important. They're going the way of Red Hat.
I'm betting Canonical wish they were going the way of Red Hat, with a billion plus of revenue.
While I'm OK with the revenue part (I own shares! See me SMILE!!!), this seems to be saying that Red Hat as a platform isn't doing too well. As far as I can tell, Fedora and CentOS are going Great Guns, and Red Hat itself can't be raking in all that cash without doing something right.
Am I missing something? Gnome 3 doesn't count. That particular curse affects more than just Red Hat.