Obsolete C for you and me
Obsolete C for you and me
Posted Dec 9, 2023 19:13 UTC (Sat) by pizza (subscriber, #46)In reply to: Obsolete C for you and me by mb
Parent article: Modern C for Fedora (and the world)
Are you volunteering to pay me to do this work?
Or is this just yet another example of someone demanding that I perform unpaid work on their behalf?
Posted Dec 9, 2023 19:43 UTC (Sat)
by mb (subscriber, #50428)
[Link] (14 responses)
Nope. It's your project.
> Or is this just yet another example of someone demanding that I perform unpaid work on their behalf?
No. Not at all. I am not demanding anything.
But please don't complain, if it explodes.
Posted Dec 9, 2023 22:56 UTC (Sat)
by pizza (subscriber, #46)
[Link] (13 responses)
What you call "piling up technical debt" everyone else calls "priorities"
> But please don't complain, if it explodes.
Um, I'm not. Once again, you presume something not in evidence.
None of this stuff "explodes" on its own. Indeed, it works just fine in the environments it's been used in for (as you put it) "decades". However, the article, and this discussion, is about how a _new_ environment has come along that causes (usually trivially-fixed) compilation failures on code that's not needed significant maintenance for "decades". How is that property not a _good_ thing? What is this modern fascination with constantly reinventing the wheel just to stay in place?
Posted Dec 10, 2023 0:59 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (12 responses)
While that fascination is real, it's absolutely not what this article and discussion is about. You're angry and not listening.
Posted Dec 10, 2023 2:39 UTC (Sun)
by pizza (subscriber, #46)
[Link] (11 responses)
Seriously?
I'm being scolded for using ancient software that does exactly what I need it to do, solely because it's just a matter of time before it "explodes" causing me all manners of problems. Instead, I should switch to something actively developed.
That presumes that there is (1) an alternative with the necessary functionality, and (2) the transition cost is low to nonexistent. It also over exaggerates the scope and effect of the actual problem (ie a compile-time problem that is, most of the time, pretty trivial to resolve).
I've also pointed out, multiple times, that this article shows that "not actively developed" does not mean "not actively used", and the right-now cost of incrementally fixing this old software is far less than replacing it entirely.
(Anectdotally, those calling for wholesale replacements/rewrites/etc or otherwise telling F/OSS authors/maintainers/distributors/users/etc what they "should" be doing never seem to be the ones doing the actual work or helping cover its cost. I won't apologize for calling out that abusive, entitled behaviour)
Posted Dec 10, 2023 5:17 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Dec 10, 2023 15:43 UTC (Sun)
by pizza (subscriber, #46)
[Link]
....You injected yourself into the tail end of a sub-thread that was about just that.
(Meanwhile, I agree that the article _wasn't_ about that, a point I've repeatedly made)
Posted Dec 10, 2023 15:58 UTC (Sun)
by mb (subscriber, #50428)
[Link] (8 responses)
That's not true. It's your choice and I respect that choice.
>for using ancient software that does exactly what I need it to do, solely because it's just a matter of time >before it "explodes" causing me all manners of problems.
Yes. It's called bit-rot.
>Instead, I should switch to something actively developed.
That is *one* of the possible options that have been pointed out here.
>"not actively developed" does not mean "not actively used"
Yes. But nobody claimed that it would mean that.
>telling F/OSS authors/maintainers/distributors/users/etc what they "should" be doing
Nobody is telling you what you should do. That's a misinterpretation on your side.
But I'm not fine with it, if you want to prevent certain developments of the C language itself, just to keep your ancient and trivially fixable code working.
Posted Dec 10, 2023 18:03 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
I'm willing to bet that, on a daily basis, you trust your physical safety (if not your life) to "unmaintained software".
For example, the _newer_ of my two vehicles was manufactured 22 years ago. Any support/warranty/part supply/recall obligations its manufacturer had completely ceased seven years ago. If the software running in its ECU, ABS, and safety/airbag modules doesn't qualify as "unmaintained" then nothing else possibly could.
Meanwhile, *every* computer I have Linux installed upon is running completely unmaintained firmware -- The newest one fell out of support about a year ago. Does this mean I should just scrap the lot?
My point? "unmaintained" doesn't mean that it's automatically bad, untrustable, or incapable of fulfilling its purpose. Secondly, "maintained" in of itself tells you very little. Indeed, the Fedora folks' efforts with these old packages is itself a form of maintenance!
Going back a few posts, the "unmaintained production" software I mentioned earlier that you chided me for relying upon? It's a glorified data logger in a closed environment. It's been in production for approximately two decades, and it's "unmaintained" because *it hasn't needed any maintenance* in the past three years. It does what's needed, so what is to be gained by messing with it? What exactly is supposed to "explode" in this context? This particular bit of ancient software is actually the most reliable portion of the entire system!
Posted Dec 10, 2023 18:45 UTC (Sun)
by mb (subscriber, #50428)
[Link] (1 responses)
Well, yes. I know. In my day job I write this software.
Probably the majority of the software in such a thing is "frozen". It will not be developed any further to add new features.
>Meanwhile, *every* computer I have Linux installed upon is running completely unmaintained firmware
Nope. You completely missed my point again.
I am not at all talking about binary firmware sitting in devices. It's completely fine to keep using the same binary firmware for an infinite amount of time. It will not become worse with time.
I am talking about the legacy source code that is used in new compilations with modern compilers today.
> What exactly is supposed to "explode" in this context?
If you try to recompile it with a modern compiler many things will happen.
Posted Dec 10, 2023 19:35 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Only if it's really "airtight" (cause new attack techniques appear constantly) and use cases never ever change.
Even in such a case the company will likely want to re-use and evolve that source in some newer product. Then as you wrote, the binary is fine but the source is not.
"Zero maintenance" software can exist for sure but in many cases people who wish they don't have to pay for maintenance are just burying their head in the sand not to see technical debt.
Software maintenance has absolutely nothing to do with the fascination for shiny new things. It's actually the exact opposite. Confusing the two is not far from insulting the people performing ungrateful maintenance work. Unlike pseudo-"inventors"[*], they're never in the spotlight. Kudos to LWN for this article.
[*] search the Internet for "myth of the lone inventor"
Posted Dec 11, 2023 10:51 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (3 responses)
A twenty-year old binary built with Diab 5.0 either works or it doesn't; that's not going to change just because GCC 13.2 has a more thorough understanding of the C standard than GCC 3.1 (roughly contemporary to Diab 5.0). If you rebuild from the same sources today with Diab 5.0, you'll still get a working binary - nothing has changed, so nothing new fails.
Further, you can do your changes (if any are needed) with Diab 5.0 as the compiler, and it will interpret the code the same way it did 20 years ago. What you face trouble with is code that assumed that some underspecified behaviour would always be implemented the way the compiler of the day implemented it, and even then, only if you change the compiler. If you don't change the binary, it doesn't matter; if you change the source, but reuse the same compiler, it's (usually) fine.
The problem comes in when you change two things at once; both the compiler in use (maybe even as small a change as switching from PowerPC 440 to Arm Cortex-M7 backend in the same compiler binary) and the source code. At that point, you have the risk of a problem that could be anywhere, since most languages don't (arguably can't) tell you if the behaviour of the compiler has changed in a way the last programmer to touch the code would be surprised by. This applies to Rust, too; for example, integer overflow is underspecified in Rust by this standard (two possible outcomes, panic or 2s complement wrapping), and if the last programmer to touch the code didn't think about this, then you have room for a problem where only panic is acceptable behaviour, but instead you get silent wrapping.
Posted Dec 11, 2023 17:02 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
...I'd argue a switch from a (usually) BE CPU to a (nearly always) LE CPU is a pretty significant change, to say nothing of subtleties like the memory ordering model and how unaligned accesses are handled.
But yes, change out a major portion of the compile or runtime environment (and/or other fundamental requirements) and the code may need updating. Change multiple things at once... you're likely in for a world of pain.
Posted Dec 11, 2023 17:33 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
But then we come back round to the beginning - why are you rebuilding code with a new compiler if no requirements have changed, and expecting it to behave exactly as it did when built with the old compiler? This goes double if your code depends on specifics of how the old compiler interpreted the code, rather than being code whose meaning is unambiguous.
And that, of course, leads to the big problem with legacy code - much of it (in all languages) is written "knowing" that if it passes tests when built with a single compiler, then it's good enough. But change anything (compiler, inputs, other bits and pieces), and it stops working.
Posted Dec 11, 2023 19:48 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Well, if nothing changes, then.. you don't need to do anything. (That was kinda my point with respect to my using "unmaintained" software in a production environment)
But more typically, requirements do change... eventually. You rarely know what those will be in advance, or what effort will be needed to handle it.
Posted Dec 10, 2023 19:20 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Small digression sorry.
Obsolete C for you and me
Feel free to keep piling up as much technical debt as you like.
It's your decision.
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
But you have to live with the consequences of your own decisions.
It was your decision to use C features that have been deprecated and throwing warnings for decades.
Environments change and perfectly good software becomes an ancient mess.
Feel free to keep depending on unmaintained software. That is your choice and I am fine with that.
Obsolete C for you and me
Obsolete C for you and me
> then nothing else possibly could.
But it's not at all "unmaintained", because if problems do come up, they will get fixed.
This is enforced by law.
>Does this mean I should just scrap the lot?
That is a completely different thing.
That is what this discussion is about.
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me