Adding to your argument, one thing I absolutely *hate* is when I'm told 'well, just log out and log back in and see if it gets better'. It's a step shy of 'reboot and see if it gets better'. This sort of change is encouraging that behavior. Applications that go off the rails are a problem before they log out. If an application manages to start itself multiple times rather than reuse the existing instance, is a bug. Applications need to be *fixed*, not worked around in an inconvenient manner to the user.
I see no evidence that this does anything to aid security. Users are still allowed to do what they could do before, and they are still prevented from doing things they were prevented from doing before. I would have to see citations for security issues that actually pertained to this phenomenon.
With telnet, there were widespread incidents of folks doing a network sniff and misbehaving. Even then the move from telnet to ssh was by and large pretty leisurely and not forced.
Note that for one, telnet represented a very real and serious security problem that was actively breaking people.
Note also, that for over a decade, most things that ran sshd *also* ran telnetd, just in case. The community was allowed to embrace this change at their own pace, and if it had been rejected, telnetd would still be running by and large today (there are actually a fair number of scenarios where it's still common to run telnetd). It was a change that allowed choice, not a change that forced itself by changing things.
there's hardly anyone left with the energy to fight the cabal any more.
You could have stopped at just 'there's hardly anyone left'. Fedora userbase at this point are people happy to be RedHat's unpaid beta testers. If they don't like systemd, they've already retreated to other distros, even if systemd has come to those distros in the interim.
The problem being that after years of struggling with unsupported OSes, RedHat managed to represent a hardware vendor friendly option that did pretty much what we wanted. Fork and move on is not something the hardware vendors (and by extension, large IT organizations) will go along with you on. This is beyond open source. RedHat managed to sway Debian and by extension Ubuntu didn't have the will nor even did SuSE. So there are zero supportable new Linux distros that provide the non-systemd experience. This is a big problem in and of itself, but also an indicator that there really isn't meaningful choice in distributions as they all just copy RedHat's moves now (even though Ubuntu, by install count far outnumbers them, RedHat still has the muscle by virtue of revenue).
So RedHat now starts moving on to chase markets currently out of reach for them, with an effectively captive audience of their original market, telling them to shut the hell up and deal with it. It's a lot like Windows 8 throwing their traditional desktop users under the bus for the sake of trying to get them into the tablet/phone game. Just like windows 8, I see a *lot* more customers running RHEL6 than I saw running RHEL5 this far into the next-gen's life. I've also had to work around all sorts of breakage with systemd (there was an upgrade process that did a yum update as a service. One day a systemd update landed, and the upgrade process got killed when it tried to update systemd because old-systemd would kill off the update procedure in the process of the systemd update being applied).
The thing is that there are already facilities to do this in *nix land that have existed for a very long time (why else do things like nohup exist). This new tech means now processes have to do *yet another thing*. Imagine 10 years down the line with processes abusing systemd-run, and someone deciding to standardize a new behavior that requires wrapping systemd-run, since it was so abused. That's the absurdity, software is abusing the facilities available today, so they put in another block that invites software to abuse more facilities to overcome that, rather than pushing back on the software to *STOP ABUSING FEATURES TO KEEP RUNNING THAT SHOULDN'T*
Systemd developers then say that tmux, screen, nohup, etc are all broken
This is the phenomenon that pisses me off the most. They know these well-known applications exist, and precisely how they work and how *nix systems conventions work, and then have the gall to say that *everyone* else has a 'bug' because systemd decided to throw all that out. They don't say that it would be ideal if these other applications would add features, they say 'oh, they are buggy' to make users go away. It's an insane amount of hubris.
One, no one has credibly stated that screen/tmux are left alive. There are people reporting that screen/tmux sessions are killed.
For another, do the firefox sessions that you describe survive a logout today? In order to survive a logout (exit of gnome-session or whatever), the process has to setsid to establish itself as a session leader, I have seen firefox misbehave and run with no GUI active, but I've never seen it survive a logout given current scenarios.
There's process accounting and cgroups to manage the resources used by users, which enable administrators to manage directly the true worry: resource consumption. Tying resource consumption to a connected 'session' still allows the misbehavior you imagine, it just takes even more hoops to keep that session alive.
there is room for argument that allowing a USER , not admin level process to run in absence of the user is bad practice.
See, I think this is an example of focusing on the wrong thing. The general argument being presented is that this is somehow perceived as a back door, or a resource hog. It's somehow scary.
On the backdoor part, there's really nothing that process should be allowed to do, by being allowed to continue running. It's still constrained by the privileges of that user. If there *were* something nefarious, backdoor wise, then your problem is with a failure of privilege, and preventing processes from running in the background will do nothing to really close the problem, that the user has the ability to take actions that they should not.
On the resource hog, again, the focus would be about how many resources they are allowed to consume, the fact of whether they are currently logged in or not is a red herring. If you don't want to allow a user to consume too many resources, you limit them, regardless of whether they are 'logged in' or not. That is why process accounting happened in the first place. CGroups add more sophisticated controls that are justified, but the 'session logout' part is superfluous.
Now I could see someone saying providing an option for anal sysadmins to block this thing and be peculiar about it having some value... but having the default behavior of the ecosystem change to match this really silly strategy, that is bonkers.
PHP is a case of accidental 'language'. It's ambitions were just SSI on steroids, and things went insane from there. Of course, the original view of a webbrowser being a relatively dumb renderer of HTML and well structured hypermedia enabled texts is out the window, so the whole SSI strategy is justifiable a whole lot less now than it was then (now you do your best to push the work of generating the page to code in the client browser, and any server side processing dumps data in a data structure rather than a presentable view...).
I can actually read the stuff (and reflexively reimplement it in Perl
So readable code is a bug to fix then?;) Actually I know Perl *can* be readable, but for whatever reason it draws a lot of people who actually relish creating indecipherable code, as if every day was an obfuscated coding contest...
The same story can be told of Fortran: hated by die-hard CS folks who see anything that isn't a general purpose sort of language as bad. Fortran serves a certain userbase well to this day. Admittedly since Fortran's peak, a lot of folks formerly resorting to developing programs can now use something even more tailored to those needs (e.g. Matlab, R, Spreadsheets, and so on) and python has taken a place as a viable alternative (thanks to scipy, numpy, and ipython), Fortran continues to be good for what it is named for: Formula Translation. Particularly on the front of parallelism, Fortran has *much* easier syntax than other languages. You write a fortran program that looks pretty reasonable/unassuming and run it on a laptop, it will also run on gigantic SMPs and Clusters and take full advantage of the additional resources.
However, along with COBOL, people tend to snicker when it is mentioned, because it would be a terrible language for a lot of tasks, despite it being very good at what it was designed for.
I would say that schools should make it accessible, but not require it. When I went through elementary school in the 80s, there was a computer lab. We were taken to it and said here's some edutainment games, and if you boot it without a disk you'll get this weird prompt. Also, here's a place where you can make a turtle draw some things. And there's some books over there. Do with these resources whatever you feel like, there is no grading or anything (because there was no real curriculum, just an abstract sense that these computer things were important and people needed to get comfortable with them).
So some folks would be learning about geography, chemistry, whatever based on the edutainment games they picked, and those so inclined could see what they could make the computer do in a more open ended way. As a consequence, the only people who learned coding were those with an inherent passion and inclination for the right way of thinking (well, back then a software developer wasn't seen as a super-profitable career to be pursued over most any other job either, and in fact there was a stigma associated with that sort of behavior so you got only the folks who were *really* interested)
Having more guidance available would have been great as elective type stuff, but at the end of the day, people have to recognize that coding is a vocational sort of thing and should not be a requirement any more than an auto mechanic course should be required for everyone. The result of more and more *forced* coding exposure is a dilution of the talent pool. I would say that the state of software development in general is in a pretty sorry state, but largely because of the fact the career is seen as an accessible cash cow, drawing a lot of people who are not really inclined to do the work to do it anyway. Adding more people indiscriminately to the equation only makes things worse.
So first of all, there isn't anything wrong with COBOL at a fundamental level. It was designed for helping people with a certain sort of problem solving.
So if that's the case, why is it the case that anytime COBOL is mentioned, people will mock it? Why do people associate it with horribly unmaintainable code? The primary answer is that it was a victim of its own success. As COBOL programmers realized they could solve complex solutions without changing languages, they went ahead and wrote a lot of stuff in COBOL that COBOL wasn't really designed to handle. At the end they would frequently have something that would somehow manage to work, despite being horribly convoluted and unmaintainable. As such COBOL earned a bad reputation, though the language itself bears relatively little of the blame. The language that really should take note of this history is Javascript. As people start writing more and more ugly code in Javascript, it actually worsens the language reputation, despite it being relatively serviceable for the intended problem domain. Contrast with something like LISP which most people won't bat an eye at being used, as it never came to be popular outside of the sorts of problems it works well to solve.
Everyone knows the only webscale language is javascript, and the only webscale way to store data is MongoDB. There is no other approach. This is why, for example, Facebook is not webscale.
I'll add a third option, they found 'something' but feared that 'something' wouldn't stand up to scrutiny and/or would require investigation, which isn't worth the cost given there's other suppliers at the exact same price, so they just denied approval and someone involved directly or indirectly wanted to highlight their fear to the wider public.
For example, I have heard that some will test by taking a laptop at factory preload (even though it won't actually *run* the factory preload in practice), run wireshark on a gateway, do the work to go through 'out of box' and connect to network, but not use a browser or anything. They would then examine the pcap for network connections and basically fail if there were any attempts, without trying to characterize the traffic.
If, hypothetically, the laptop had a driver update checker run, that would fail the test. Frankly best practice is for software to do those connections encrypted anyway, so nowadays such a test would have no way of distinguishing between an earnest update attempt and nefarious activity as a 'black box' sort of test. Now one could rightfully say such a check should prompt for consent before even checking, but that also does not mean the thing was a 'backdoor', just someone taking 'convenience' too far.
" Australia Department of Defence available on their web site that says “This reporting is factually incorrect. There is no Department of Defence ban on the Lenovo Company or their products; either for classified or unclassified systems.”"
Also, 'apparently' and 'allegedly'. No agency has actually come out and said anything. This means that either they *did* find something and they are keeping it secret, counter to their mission of safeguarding the security of their citizens, or they *didn't* find anything, but someone wanted to spread some FUD, either because they have something to gain or they want to push an anti-China agenda (which is understandable, but unsubstantiated claims do not exactly help their cause).
they found backdoors in the BIOS that linked back to China.
Citation? There have been: -Superfish - an ill-advised US-sourced adware using a horribly insecure Isreali TLS proxy implementation -'ShareIT' - a stupid wireless sharing thing that used a stupid password -Lenovo updater - the utility that offers up a payload for Windows to use in a manner that Windows supports. Intended to be a software update utility, particularly problematic in that it would use http without TLS to download updates. Ill-advised in that it does *anything* to a clean retail copy (but MS gets to take some of the blame for even *having* such a harebrained scheme implemented).
There have been no backdoors, albeit a lot of stupid security decisions that put Lenovo users at risk from people. No sign of malicious intent, though incompetence is a fair accusation to make. Also not cleverness disguised as incompetence, the failings were not useful enough as a malicious tool to suggest that.
Well, I was speaking to the common use case of no porting, no using it in a new context, just wanting to make the implementation 'more clean' but otherwise maintain roughly the same behavior in the same context. I did not mean the list of example valid reasons to be comprehensive. Porting and all sorts of other valid use cases exist.
Now one could make an argument that raw assembly by most eyes will never be as readable as a higher level language, but that's a pretty rare circumstance and there are frequently a lot more reasons to be wary of pulling the trigger on a rewrite of such a case just for cleanness sake.
Bottom line, if you want to rewrite an existing program, it better be for more reasons than making it cleaner, 99.99% of the time.
I don't know if aspiring to PHP levels of maintainability/readability is a high ambition. Also, when the question is 'should I migrate from php', a sentiment that suggests 'about as good as php' doesn't seem to be a ringing endorsement.
It's really interesting because if you look at PyPI, you'll see a lot of this too, but not universally. Some projects exercise some degree of release management discipline and multiple supported branches and such. Others are managed like you describe, just a constant stream of whimsical updates.
Across the industry there is a very *vocal* sentiment, particularly among newcomers, that stable branches and release management in general is for the birds. We have unit tests and continuous integration now, so why expend energy catering to the the 'old ways'. Veterans tend to be more reserved and careful and reluctant to chime in on a technology change, so the dialog is largely dominated by the enthusiastic 'change everything weekly' crowd.
I think there is often a desire, rational or not, among programmers to want to redo things and make them "clean" (whatever that means) and more efficient. It's a laudable notion,
Also, it is all too common the programmer overestimates what the quality of the redo would look like, *especially* if they are looking at redoing someone else's code. They think 'ok, this is way more convoluted than it has to be', and then realize way too late they were wrong.
Even more so when they think part of making it 'clean' *requires* reimplementation in another language. Now there may be valid reasons to reimplement in another language (better matching your available talent pool, better performance, you would just prefer it), but if it's just to 'make it clean', that can pretty much always be accomplished within the existing language choice.
The call to have horribly nested callbacks is mitigated to some degree, but it's still ugly compared to approaches in other languages. It's still a callback driven paradigm, just allowing a somewhat less painful way to manage complex scenarios.
It's a lot like the other improvements in Javascript, significantly crippled by being worked to fit into the existing language.
Slashdot Mirror
Adding to your argument, one thing I absolutely *hate* is when I'm told 'well, just log out and log back in and see if it gets better'. It's a step shy of 'reboot and see if it gets better'. This sort of change is encouraging that behavior. Applications that go off the rails are a problem before they log out. If an application manages to start itself multiple times rather than reuse the existing instance, is a bug. Applications need to be *fixed*, not worked around in an inconvenient manner to the user.
that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.
That was between the admins and the users, *not* between the OS vendors and their customers.
Denying that is like denying that ssh is better than telnet.
I don't see it. Those calling 'security' are crying wolf here.
I see no evidence that this does anything to aid security. Users are still allowed to do what they could do before, and they are still prevented from doing things they were prevented from doing before. I would have to see citations for security issues that actually pertained to this phenomenon.
With telnet, there were widespread incidents of folks doing a network sniff and misbehaving. Even then the move from telnet to ssh was by and large pretty leisurely and not forced.
Note that for one, telnet represented a very real and serious security problem that was actively breaking people.
Note also, that for over a decade, most things that ran sshd *also* ran telnetd, just in case. The community was allowed to embrace this change at their own pace, and if it had been rejected, telnetd would still be running by and large today (there are actually a fair number of scenarios where it's still common to run telnetd). It was a change that allowed choice, not a change that forced itself by changing things.
there's hardly anyone left with the energy to fight the cabal any more.
You could have stopped at just 'there's hardly anyone left'. Fedora userbase at this point are people happy to be RedHat's unpaid beta testers. If they don't like systemd, they've already retreated to other distros, even if systemd has come to those distros in the interim.
The problem being that after years of struggling with unsupported OSes, RedHat managed to represent a hardware vendor friendly option that did pretty much what we wanted. Fork and move on is not something the hardware vendors (and by extension, large IT organizations) will go along with you on. This is beyond open source. RedHat managed to sway Debian and by extension Ubuntu didn't have the will nor even did SuSE. So there are zero supportable new Linux distros that provide the non-systemd experience. This is a big problem in and of itself, but also an indicator that there really isn't meaningful choice in distributions as they all just copy RedHat's moves now (even though Ubuntu, by install count far outnumbers them, RedHat still has the muscle by virtue of revenue).
So RedHat now starts moving on to chase markets currently out of reach for them, with an effectively captive audience of their original market, telling them to shut the hell up and deal with it. It's a lot like Windows 8 throwing their traditional desktop users under the bus for the sake of trying to get them into the tablet/phone game. Just like windows 8, I see a *lot* more customers running RHEL6 than I saw running RHEL5 this far into the next-gen's life. I've also had to work around all sorts of breakage with systemd (there was an upgrade process that did a yum update as a service. One day a systemd update landed, and the upgrade process got killed when it tried to update systemd because old-systemd would kill off the update procedure in the process of the systemd update being applied).
The thing is that there are already facilities to do this in *nix land that have existed for a very long time (why else do things like nohup exist). This new tech means now processes have to do *yet another thing*. Imagine 10 years down the line with processes abusing systemd-run, and someone deciding to standardize a new behavior that requires wrapping systemd-run, since it was so abused. That's the absurdity, software is abusing the facilities available today, so they put in another block that invites software to abuse more facilities to overcome that, rather than pushing back on the software to *STOP ABUSING FEATURES TO KEEP RUNNING THAT SHOULDN'T*
Systemd developers then say that tmux, screen, nohup, etc are all broken
This is the phenomenon that pisses me off the most. They know these well-known applications exist, and precisely how they work and how *nix systems conventions work, and then have the gall to say that *everyone* else has a 'bug' because systemd decided to throw all that out. They don't say that it would be ideal if these other applications would add features, they say 'oh, they are buggy' to make users go away. It's an insane amount of hubris.
One, no one has credibly stated that screen/tmux are left alive. There are people reporting that screen/tmux sessions are killed.
For another, do the firefox sessions that you describe survive a logout today? In order to survive a logout (exit of gnome-session or whatever), the process has to setsid to establish itself as a session leader, I have seen firefox misbehave and run with no GUI active, but I've never seen it survive a logout given current scenarios.
There's process accounting and cgroups to manage the resources used by users, which enable administrators to manage directly the true worry: resource consumption. Tying resource consumption to a connected 'session' still allows the misbehavior you imagine, it just takes even more hoops to keep that session alive.
there is room for argument that allowing a USER , not admin level process to run in absence of the user is bad practice.
See, I think this is an example of focusing on the wrong thing. The general argument being presented is that this is somehow perceived as a back door, or a resource hog. It's somehow scary.
On the backdoor part, there's really nothing that process should be allowed to do, by being allowed to continue running. It's still constrained by the privileges of that user. If there *were* something nefarious, backdoor wise, then your problem is with a failure of privilege, and preventing processes from running in the background will do nothing to really close the problem, that the user has the ability to take actions that they should not.
On the resource hog, again, the focus would be about how many resources they are allowed to consume, the fact of whether they are currently logged in or not is a red herring. If you don't want to allow a user to consume too many resources, you limit them, regardless of whether they are 'logged in' or not. That is why process accounting happened in the first place. CGroups add more sophisticated controls that are justified, but the 'session logout' part is superfluous.
Now I could see someone saying providing an option for anal sysadmins to block this thing and be peculiar about it having some value... but having the default behavior of the ecosystem change to match this really silly strategy, that is bonkers.
PHP is a case of accidental 'language'. It's ambitions were just SSI on steroids, and things went insane from there. Of course, the original view of a webbrowser being a relatively dumb renderer of HTML and well structured hypermedia enabled texts is out the window, so the whole SSI strategy is justifiable a whole lot less now than it was then (now you do your best to push the work of generating the page to code in the client browser, and any server side processing dumps data in a data structure rather than a presentable view...).
I can actually read the stuff (and reflexively reimplement it in Perl
So readable code is a bug to fix then? ;) Actually I know Perl *can* be readable, but for whatever reason it draws a lot of people who actually relish creating indecipherable code, as if every day was an obfuscated coding contest...
The same story can be told of Fortran: hated by die-hard CS folks who see anything that isn't a general purpose sort of language as bad. Fortran serves a certain userbase well to this day. Admittedly since Fortran's peak, a lot of folks formerly resorting to developing programs can now use something even more tailored to those needs (e.g. Matlab, R, Spreadsheets, and so on) and python has taken a place as a viable alternative (thanks to scipy, numpy, and ipython), Fortran continues to be good for what it is named for: Formula Translation. Particularly on the front of parallelism, Fortran has *much* easier syntax than other languages. You write a fortran program that looks pretty reasonable/unassuming and run it on a laptop, it will also run on gigantic SMPs and Clusters and take full advantage of the additional resources.
However, along with COBOL, people tend to snicker when it is mentioned, because it would be a terrible language for a lot of tasks, despite it being very good at what it was designed for.
I would say that schools should make it accessible, but not require it. When I went through elementary school in the 80s, there was a computer lab. We were taken to it and said here's some edutainment games, and if you boot it without a disk you'll get this weird prompt. Also, here's a place where you can make a turtle draw some things. And there's some books over there. Do with these resources whatever you feel like, there is no grading or anything (because there was no real curriculum, just an abstract sense that these computer things were important and people needed to get comfortable with them).
So some folks would be learning about geography, chemistry, whatever based on the edutainment games they picked, and those so inclined could see what they could make the computer do in a more open ended way. As a consequence, the only people who learned coding were those with an inherent passion and inclination for the right way of thinking (well, back then a software developer wasn't seen as a super-profitable career to be pursued over most any other job either, and in fact there was a stigma associated with that sort of behavior so you got only the folks who were *really* interested)
Having more guidance available would have been great as elective type stuff, but at the end of the day, people have to recognize that coding is a vocational sort of thing and should not be a requirement any more than an auto mechanic course should be required for everyone. The result of more and more *forced* coding exposure is a dilution of the talent pool. I would say that the state of software development in general is in a pretty sorry state, but largely because of the fact the career is seen as an accessible cash cow, drawing a lot of people who are not really inclined to do the work to do it anyway. Adding more people indiscriminately to the equation only makes things worse.
So first of all, there isn't anything wrong with COBOL at a fundamental level. It was designed for helping people with a certain sort of problem solving.
So if that's the case, why is it the case that anytime COBOL is mentioned, people will mock it? Why do people associate it with horribly unmaintainable code? The primary answer is that it was a victim of its own success. As COBOL programmers realized they could solve complex solutions without changing languages, they went ahead and wrote a lot of stuff in COBOL that COBOL wasn't really designed to handle. At the end they would frequently have something that would somehow manage to work, despite being horribly convoluted and unmaintainable. As such COBOL earned a bad reputation, though the language itself bears relatively little of the blame.
The language that really should take note of this history is Javascript. As people start writing more and more ugly code in Javascript, it actually worsens the language reputation, despite it being relatively serviceable for the intended problem domain. Contrast with something like LISP which most people won't bat an eye at being used, as it never came to be popular outside of the sorts of problems it works well to solve.
Everyone knows the only webscale language is javascript, and the only webscale way to store data is MongoDB. There is no other approach. This is why, for example, Facebook is not webscale.
I'll add a third option, they found 'something' but feared that 'something' wouldn't stand up to scrutiny and/or would require investigation, which isn't worth the cost given there's other suppliers at the exact same price, so they just denied approval and someone involved directly or indirectly wanted to highlight their fear to the wider public.
For example, I have heard that some will test by taking a laptop at factory preload (even though it won't actually *run* the factory preload in practice), run wireshark on a gateway, do the work to go through 'out of box' and connect to network, but not use a browser or anything. They would then examine the pcap for network connections and basically fail if there were any attempts, without trying to characterize the traffic.
If, hypothetically, the laptop had a driver update checker run, that would fail the test. Frankly best practice is for software to do those connections encrypted anyway, so nowadays such a test would have no way of distinguishing between an earnest update attempt and nefarious activity as a 'black box' sort of test. Now one could rightfully say such a check should prompt for consent before even checking, but that also does not mean the thing was a 'backdoor', just someone taking 'convenience' too far.
" Australia Department of Defence available on their web site that says “This reporting is factually incorrect. There is no Department of Defence ban on the Lenovo Company or their products; either for classified or unclassified systems.”"
Also, 'apparently' and 'allegedly'. No agency has actually come out and said anything. This means that either they *did* find something and they are keeping it secret, counter to their mission of safeguarding the security of their citizens, or they *didn't* find anything, but someone wanted to spread some FUD, either because they have something to gain or they want to push an anti-China agenda (which is understandable, but unsubstantiated claims do not exactly help their cause).
they found backdoors in the BIOS that linked back to China.
Citation? There have been:
-Superfish - an ill-advised US-sourced adware using a horribly insecure Isreali TLS proxy implementation
-'ShareIT' - a stupid wireless sharing thing that used a stupid password
-Lenovo updater - the utility that offers up a payload for Windows to use in a manner that Windows supports. Intended to be a software update utility, particularly problematic in that it would use http without TLS to download updates. Ill-advised in that it does *anything* to a clean retail copy (but MS gets to take some of the blame for even *having* such a harebrained scheme implemented).
There have been no backdoors, albeit a lot of stupid security decisions that put Lenovo users at risk from people. No sign of malicious intent, though incompetence is a fair accusation to make. Also not cleverness disguised as incompetence, the failings were not useful enough as a malicious tool to suggest that.
Well, I was speaking to the common use case of no porting, no using it in a new context, just wanting to make the implementation 'more clean' but otherwise maintain roughly the same behavior in the same context. I did not mean the list of example valid reasons to be comprehensive. Porting and all sorts of other valid use cases exist.
Now one could make an argument that raw assembly by most eyes will never be as readable as a higher level language, but that's a pretty rare circumstance and there are frequently a lot more reasons to be wary of pulling the trigger on a rewrite of such a case just for cleanness sake.
Bottom line, if you want to rewrite an existing program, it better be for more reasons than making it cleaner, 99.99% of the time.
I don't know if aspiring to PHP levels of maintainability/readability is a high ambition. Also, when the question is 'should I migrate from php', a sentiment that suggests 'about as good as php' doesn't seem to be a ringing endorsement.
Yeah, that stuff is ancient and annoying, lacking severely in useful features. Everyone worth their salt is using vim.
It's really interesting because if you look at PyPI, you'll see a lot of this too, but not universally. Some projects exercise some degree of release management discipline and multiple supported branches and such. Others are managed like you describe, just a constant stream of whimsical updates.
Across the industry there is a very *vocal* sentiment, particularly among newcomers, that stable branches and release management in general is for the birds. We have unit tests and continuous integration now, so why expend energy catering to the the 'old ways'. Veterans tend to be more reserved and careful and reluctant to chime in on a technology change, so the dialog is largely dominated by the enthusiastic 'change everything weekly' crowd.
I think there is often a desire, rational or not, among programmers to want to redo things and make them "clean" (whatever that means) and more efficient. It's a laudable notion,
Also, it is all too common the programmer overestimates what the quality of the redo would look like, *especially* if they are looking at redoing someone else's code. They think 'ok, this is way more convoluted than it has to be', and then realize way too late they were wrong.
Even more so when they think part of making it 'clean' *requires* reimplementation in another language. Now there may be valid reasons to reimplement in another language (better matching your available talent pool, better performance, you would just prefer it), but if it's just to 'make it clean', that can pretty much always be accomplished within the existing language choice.
The call to have horribly nested callbacks is mitigated to some degree, but it's still ugly compared to approaches in other languages. It's still a callback driven paradigm, just allowing a somewhat less painful way to manage complex scenarios.
It's a lot like the other improvements in Javascript, significantly crippled by being worked to fit into the existing language.