Programmers have to take more responsibility and think holistically about what they are building - and integrate testing to validate their assumptions against the hard light of the real world. To be a great programmer, you should know how to test and build tests and test rigs as needed. To be a great tester, you should know how to code - so you can automate what you're testing. I think the lines have to blur - a firewall between the two only leads to silos, and limits what can be done if they were to work seamlessly (the quote attributed to Aristotle applies here, "the whole is greater than the sum of its parts").
Of course, in many development shops the 'just a programmer' mentality is baked into the whole process - so as a developer you might feel that you are stuck. That being said, if you know better, then it is in the interests of your business if not yourself to champion the issue and effect change.
It would all depend on your definition of 'significant rewrite/technology/architectural changes'. There is a lot of room in there for interpretation - particularly if a project was changing constantly.
At the same token, if a project has stablilized to the point of little or no changes, then have a long-lived 'W' wouldn't necessarily be a bad thing either.
Human beings create these numbering schemes for human consumption - and therefore can reasonably adjust them to avoid confusion as necessary.
There are no stupid date formats - just stupid people.
Symbols, and words, phrases, and sentences created with those symbols are neither right or wrong in and of themselves. In a given context (e.g. spoken words, computer file name, database representation, printed document etc) each and every method has its place.
That being said, I do agree, and use myself ISO date/time formats when dealing with data, file names, and other things that I want to conveniently order by date/time. (yyyymmddhhmmss). That does not preclude me from using other methods in different contexts.
We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.
Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version numbers matter.
The fix for the human factors problem is to automate the generation of the bug report on the user's system such that it captures the version information for things critical to your app (e.g. kernel version, libraries versions, your application's version etc...). Have the application itself do this upon failure, and/or provide a tool to capture the requisite information after the fact.
Then, make it a policy not to accept bug reports without the appropriate error log data accompanying it (with clear instructions about how to generate the information, and where to get the output file for sending etc). You can then easily filter out any non-compliant reports to make your life a lot easier.
That's how I would do it anyway. I've been burned/wasted my limited time too often by people raising 'bugs' without any backup evidence that then turned out to be user error - or some other component of the system unrelated to the application upon closer inspection. I no longer accept unsubstantiated bug reports.
I would argue for adding an extra decimal point: W.X.Y.Z
'W' - Major Release - reserved for significant rewrite/technology/architectural changes
'X' - New Feature Release - significant changes to existing architecture/technology
'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.
'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system.
Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.
Excellent points. I think all of the angst that is coming out of the systemd debacle is really the result of a long time defacto state where most distros - because of their common POSIX-ish modular implementations could work with just about any software out there - so even if your distro didn't support something (like a very small X11 compliant text based window manager - which I managed to shoehorn onto an old AST 486 laptop with 20 MB harddrive and 1 Mb ram running a stripped down version of Slackware 10) it could be made to work on the distro you were most happy with. People had their cake and because of interoperability could generally eat it too relatively easily - with some exceptions (e.g. device drivers).
Systemd, Dbus, et al created a situation where the choices that were once 'AND' choices, now became 'OR' choices - at first for the developers of key system components - but with enough momentum this trickled down to the end user. Developers who were once maintainers of alternative versions of various key applications are finding that the code they once depended on for porting no longer supports the old interfaces, and so they are faced with a hard choice - either spend their time working on the most widely distributed version of their software (for systemd based distros - abandoning general support across BSD and non-systemd Linuxes), or focus their energy on back-porting the code in external interfaces to work across non-systemd distros. A Hobson's choice for both developers and users who value interoperability/portability of their systems.
Frankly, I am surprised that Linux, BSD, and the shared GNU POSIX tool set was able to maintain this benign portability for as long as it has across such an eclectic assortment of distributions. I would argue that this gave Linux time to incubate, and grow up in a stable environment. With the systemd gauntlet thrown down it is now time for other alternatives to be put out there - the more the merrier! Maybe one new distro would be enough to address the complaints. Maybe 10 or a hundred. Who knows? The more of these there are, the more likely someone complaining about lack of options today will find something they like tomorrow without having to try to move a boulder up hill with a straw.
I think you're missing the point. Linux is the kernel - and it is very stable, and while it has modern extensions, it still keeps the POSIX interfaces consistent to allow inter-operation as desired. The issue here is not that forks and new versions of Linux distros are an aberration, but how the major distributions have changed and the article is a symptom of those changes towards homogeneity.
The Linux kernel is by definition identically complex on any distro using a given version of the kernel (the variances created by compilation switches notwithstanding). The real variance is in the distros - and I don't think variety is a bad thing, particularly in this day and age when we are having to focus more and more on security, and small applications on different types of devices - from small ARM processor systems, to virtual cluster systems in data centers.
Variety creates a strong ecosystem that is more resilient to security exploitation as a whole; variety is needed now more than ever given the security threats we are seeing. If you look at the history of Linux distributions over time - you'll see that from the very beginning it was a vibrant field with many distros - some that bombed out - some that were forked and then died, and forks and forks of forks that continued on - keeping the parts that seemed to work for those users. Today - I think people perceive what is happening with the major distros as a reduction in choice (if Redhat is essentially identical to Debian, Ubuntu, et al - why bother having different distros?) - a bottleneck in variability; from a security perspective, I think people are worried that a monoculture is emerging that will present a very large and crystallized attack surface after the honeymoon period is over.
If people don't like what is available, if they are concerned about the security implications, then they or their friends need to do something about it. Fork an existing distro, roll your own distro, or if you are really clever - build your own operating system from scratch to provide an answer, and hopefully something better/different in the long run. Progress isn't a bad thing; sitting around doing nothing and complaining about it is.
Before a system will build said code, have the build system verify the code not only by the public key/code hash, but as a secondary method - the code fingerprint of the author in question.
This turns a creepy idea into something worthwhile.
I have yet to meet a really competent programmer. I don't consider myself much beyond capable - but I have too many flaws in my output to be considered really brilliant.
I have worked with or dealt with the output of other programmers who's performance was egregious - most egregious was the contractor who's naive use of a commercial java framework managed to produce the effect of a memory leak in java (e.g. hamstrung java's built-in garbage collection mechanism).
Experience has taught me practical measures of quality programmers in no particular order:
1. They must know how to program at the most simple level (e.g. competency in structured programming in C would be a good starting point - a basic understanding of LISP programming a plus) before tackling more complex programming tasks. I get the sense there are a lot of cut-and-paste programmers out there who really don't understand what the underlying code they are creating is actually doing.
2. Have an innate ability to focus on simple solutions, rather than being clever. KISS principle must be understood and brought into every design decision from the start. That is not to say there are no complexities, but understanding what is simple given the problem at hand - some simple things are complex when compared to other systems - and having the ability to avoid needless complexity.
3. Literate - must be able to not only communicate effectively externally - but also their comments in code should illuminate the subject matter in a clear, concise manner. Ideally should be able to get workable technical documentation straight from their comments - via doxygen or the like (perldoc, pydoc etc).
4. Their code must be maintainable and extendable. If an average programmer cannot maintain the code, and is required to rewrite the system from scratch - then you have failed as a quality programmer. Change is inevitable - how resilient your system is to change is a measure of your ability as a programmer.
5. They must understand a lot about technology outside of the world of their application. Their application will live in a world of networks, machines (physical and virtual), storage systems, communication protocols, and APIs - they must understand the implications of software design choices given a set of environmental requirements. The best programmers not only know how to code up systems, but also how to give advice about what their systems will be capable of doing given the environment, or lack thereof - and act upon that if it is possible to adjust via changes to software alone (e.g. choosing multithreading/multiprogramming design over single thread of execution).
6. They must be able to create secure code. If the company they work for doesn't produce a guide to that, then they should develop that on their own - and live by it - and consistently improve it. If they are using frameworks/libraries written by someone else, they should audit or test it to be sure the underlying implementation is secure.
7. Must be able to get along with others and work as part of a team; ideally if they are really a quality programmer, I would expect them to also mentor and share their ideals and capabilities with their peers to bring everyone up as much as possible. Quality programmers are not primadonnas.
Define 'Application'.
Technically the blackberry operating system is an application - so based upon his own statement, blackberry OS should be made to run on any other operating system.
In the annals of dumb-assedness, this is one for the record books!
I'm running Windows 8.1 Pro on the few gaming machines in my home - and happy as a clam.
I have one Win7 machine left in the network that is getting ready to get the treatment (new video card, power supply, and Windows 8.1 Pro).
P.S. I would have thought your statements more appropriate to Perl than Python:
I came to python after using perl for over 10 years - and have never looked back. Hands down it can do everything perl can do - while providing clear, readable code that is consistent from one developer to the next...you have to really dig down into the bowls of python to create anything that would make me scratch my head - whereas that is trivial to accomplish with perl - and was the cause of many headaches over the years when needing to work with multiple developers' code. I debugged my last hanging curly brace/missing semicolon long ago.
What versions are you using, and what features are broken between them that you are complaining about?
3.0 was clearly a departure from the 2.X versions - and that is well known; if you have code that needs 2.X, you can stick with that until it makes sense to transition/migrate your code to 3.0.
Right now I'm using 2.6/2.7 - and it is solid as a rock, so I'm not sure what you're complaining about; no one is forcing you to upgrade versions if you don't want/need to, right?
A: We need your widget X to be modified to produce wingnut Y by March.
B: I can't commit to that now; I need to work up the design and give you a good estimate.
A: Never mind. We'll go with Team C and their widget Z - they assure us they can have it done well before March (the implication being they are more responsive/better than us - never mind that the new widget isn't integrated with our network or systems - and they are going to need us to do the integration work anyway because they know nothing about the systems etc..)
At this point the PMs and Program Managers break into song:
I want a feast
I want a bean feast
Cream buns and doughnuts and fruitcake with no nuts so good you could go nuts.
No, now!
I want a ball
I want a party
Pink macaroons and a million balloons and performing baboons and
Give it to me now.
I want the world,
I want the whole world.
I want to lock it all up in my pocket
It's my bar of chocolate
Give it to me now!
I want today
I want tomorrow
I want to wear them like braids in my hair and I don't want to share them
I want a party with roomfuls of laughter
Ten thousand ton of ice cream
And if I don't get the things I am after
I'm going to scream!
I want the works,
I want the whole works!
Presents and prizes and sweets and surprises in all shapes and sizes,
And now!
Don't care how I want it now!
Don't care how I want it now!
From what I've learned in the last three companies I worked for that used agile, agile means that an ungodly amount of time is spent in meetings and constant, meaningless record-keeping. God, I hate agile. It gets in the way of doing good, timely work.
They should probably start off by reading the Agile Manifesto...where it talks about the values of agile development - one of which is to value Working software over comprehensive documentation. Sounds like they have the wrong focus.
Mediocrity is not uncommon, and there are way too many people in the development end of things that shouldn't be. I've been dealing with these clowns for almost 20 years now - and this very topic is what is driving me to retire early and do something else with my time, instead of the endless death marches to nowhere.
But fleeing from Linux to BSD doesn't solve the problem, that's just running away from it. If the major BSD distros decided to incorporate a systemd-like system then what?
Then it will be time to fork Linus...
J/K
However, maybe someone should give the Linux POSIX APIs some loving - and implement a new improved non-systemd distro, and add good support for features/apps that were lost in the 'Great Systemd Landrush of 2014' (basically fork projects that decide only to support systemd - if they are something we gotta have on BSD and Linux).
The one thing I think we can depend upon is the Linux Kernel itself...everything else is questionable given limited resources; if you care about having a given feature that is threatened - put your money/sweat where your mouth is - and support it.
I would like to know what kind of administration you are doing through a 'flash web gui'? Isn't command line sufficient for admin work? Or am I missing the point in some (not so) subtle way?
Interestingly enough, as I wrote the above, the flash player in Chrome decided to die...heh.
It is a royal pain in the arse. I prefer recognizing the seasons, rather than trying to hide them. It also mucks with our normal sleep pattern during the switch over.
Who is going to pay for all of that fiber - and associated changes to the network to allow it to go the last mile (so far, the only fiber we've seen to the home is in very small enclaves of people who can afford premium services anyway)?
If you believe that should reside in the corporate realm, then how do you as a corporation turn a profit while also investing in a universal fiber network?
If you believe it should be in the government realm - how do you get politicians to support fund allocations for it - and who does the money go to (municipalities, the aforementioned corporations, someone else)?
For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional.
So nobody is forced to use systemd if they don't want to.
If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.
Not trivial. Not easy. Not freedom of choice.
It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.
While, in principle I agree with you (I learned at a university that had several MIT PHDs in the computer science department - one of which was the head of the department - and later in my career when interviewing new candidates, and working with people from what I will call 'sub standard' programs - I saw first hand that all
CS degrees were not equal) - I also realize that the people coming from the top university are going to gravitate to where the money is - meaning if you are a small company, or in a company that can't attract the top talent you will be stuck with what you can get.
This situation isn't bound to change, so how do we deal with this? I think the solution should be multifold and systematic to have possibility of success:
1. Every programmer shouldn't have to be a system developer; partition your developers into two camps: a very small group of system developers (for OS, building development tools, and embedded work as needed), and a very large group of what I will call 'application' developers (for applications end users will touch).
2. Limit the tools your Application Developers have available to them. They shouldn't be able to shoot themselves, or their users, in the foot.
3. Focus your System Developers on building tools and libraries for selected application class languages that do not allow Application Developers to reinvent the wheel for things that they shouldn't be - such as memory management and security (the aforementioned 'loaded guns'). Enforce standards for access to and use of the tools by the Application Developer group.
4. To avoid having developers working on software that will only benefit one user - provide safe tools to allow end users to build their own simple applications (e.g. Hypercard - or other paradigms that are appropriate, above and beyond spreadsheets and word processing software). Once an application created in this way becomes popular enough - you have to option of translating it through your application developer team...or leave it as is. If you were smart when you built your (hypercard-like) tool - you allowed it be integrated with, or translated to other systems in safe ways - so that it can be shared with minimal impact/workload.
If we don't find a way to something like what I describe, we will continue to suffer as we keep expecting all CS graduates/programmers to be equal. HR and Execs don't like this because they want all developers to be interchangeable widgets...but reality does not bend to policy.
Slashdot Mirror
Programmers have to take more responsibility and think holistically about what they are building - and integrate testing to validate their assumptions against the hard light of the real world. To be a great programmer, you should know how to test and build tests and test rigs as needed. To be a great tester, you should know how to code - so you can automate what you're testing. I think the lines have to blur - a firewall between the two only leads to silos, and limits what can be done if they were to work seamlessly (the quote attributed to Aristotle applies here, "the whole is greater than the sum of its parts").
Of course, in many development shops the 'just a programmer' mentality is baked into the whole process - so as a developer you might feel that you are stuck. That being said, if you know better, then it is in the interests of your business if not yourself to champion the issue and effect change.
It would all depend on your definition of 'significant rewrite/technology/architectural changes'. There is a lot of room in there for interpretation - particularly if a project was changing constantly.
At the same token, if a project has stablilized to the point of little or no changes, then have a long-lived 'W' wouldn't necessarily be a bad thing either.
Human beings create these numbering schemes for human consumption - and therefore can reasonably adjust them to avoid confusion as necessary.
There are no stupid date formats - just stupid people.
Symbols, and words, phrases, and sentences created with those symbols are neither right or wrong in and of themselves. In a given context (e.g. spoken words, computer file name, database representation, printed document etc) each and every method has its place.
That being said, I do agree, and use myself ISO date/time formats when dealing with data, file names, and other things that I want to conveniently order by date/time. (yyyymmddhhmmss). That does not preclude me from using other methods in different contexts.
We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.
Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version numbers matter.
The fix for the human factors problem is to automate the generation of the bug report on the user's system such that it captures the version information for things critical to your app (e.g. kernel version, libraries versions, your application's version etc...). Have the application itself do this upon failure, and/or provide a tool to capture the requisite information after the fact.
Then, make it a policy not to accept bug reports without the appropriate error log data accompanying it (with clear instructions about how to generate the information, and where to get the output file for sending etc). You can then easily filter out any non-compliant reports to make your life a lot easier.
That's how I would do it anyway. I've been burned/wasted my limited time too often by people raising 'bugs' without any backup evidence that then turned out to be user error - or some other component of the system unrelated to the application upon closer inspection. I no longer accept unsubstantiated bug reports.
I would argue for adding an extra decimal point: W.X.Y.Z
'W' - Major Release - reserved for significant rewrite/technology/architectural changes
'X' - New Feature Release - significant changes to existing architecture/technology
'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.
'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system. Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.
Excellent points. I think all of the angst that is coming out of the systemd debacle is really the result of a long time defacto state where most distros - because of their common POSIX-ish modular implementations could work with just about any software out there - so even if your distro didn't support something (like a very small X11 compliant text based window manager - which I managed to shoehorn onto an old AST 486 laptop with 20 MB harddrive and 1 Mb ram running a stripped down version of Slackware 10) it could be made to work on the distro you were most happy with. People had their cake and because of interoperability could generally eat it too relatively easily - with some exceptions (e.g. device drivers).
Systemd, Dbus, et al created a situation where the choices that were once 'AND' choices, now became 'OR' choices - at first for the developers of key system components - but with enough momentum this trickled down to the end user. Developers who were once maintainers of alternative versions of various key applications are finding that the code they once depended on for porting no longer supports the old interfaces, and so they are faced with a hard choice - either spend their time working on the most widely distributed version of their software (for systemd based distros - abandoning general support across BSD and non-systemd Linuxes), or focus their energy on back-porting the code in external interfaces to work across non-systemd distros. A Hobson's choice for both developers and users who value interoperability/portability of their systems.
Frankly, I am surprised that Linux, BSD, and the shared GNU POSIX tool set was able to maintain this benign portability for as long as it has across such an eclectic assortment of distributions. I would argue that this gave Linux time to incubate, and grow up in a stable environment. With the systemd gauntlet thrown down it is now time for other alternatives to be put out there - the more the merrier! Maybe one new distro would be enough to address the complaints. Maybe 10 or a hundred. Who knows? The more of these there are, the more likely someone complaining about lack of options today will find something they like tomorrow without having to try to move a boulder up hill with a straw.
I think you're missing the point. Linux is the kernel - and it is very stable, and while it has modern extensions, it still keeps the POSIX interfaces consistent to allow inter-operation as desired. The issue here is not that forks and new versions of Linux distros are an aberration, but how the major distributions have changed and the article is a symptom of those changes towards homogeneity.
The Linux kernel is by definition identically complex on any distro using a given version of the kernel (the variances created by compilation switches notwithstanding). The real variance is in the distros - and I don't think variety is a bad thing, particularly in this day and age when we are having to focus more and more on security, and small applications on different types of devices - from small ARM processor systems, to virtual cluster systems in data centers.
Variety creates a strong ecosystem that is more resilient to security exploitation as a whole; variety is needed now more than ever given the security threats we are seeing. If you look at the history of Linux distributions over time - you'll see that from the very beginning it was a vibrant field with many distros - some that bombed out - some that were forked and then died, and forks and forks of forks that continued on - keeping the parts that seemed to work for those users. Today - I think people perceive what is happening with the major distros as a reduction in choice (if Redhat is essentially identical to Debian, Ubuntu, et al - why bother having different distros?) - a bottleneck in variability; from a security perspective, I think people are worried that a monoculture is emerging that will present a very large and crystallized attack surface after the honeymoon period is over.
If people don't like what is available, if they are concerned about the security implications, then they or their friends need to do something about it. Fork an existing distro, roll your own distro, or if you are really clever - build your own operating system from scratch to provide an answer, and hopefully something better/different in the long run. Progress isn't a bad thing; sitting around doing nothing and complaining about it is.
You can have/use this idea for free:
Before a system will build said code, have the build system verify the code not only by the public key/code hash, but as a secondary method - the code fingerprint of the author in question.
This turns a creepy idea into something worthwhile.
I have yet to meet a really competent programmer. I don't consider myself much beyond capable - but I have too many flaws in my output to be considered really brilliant.
I have worked with or dealt with the output of other programmers who's performance was egregious - most egregious was the contractor who's naive use of a commercial java framework managed to produce the effect of a memory leak in java (e.g. hamstrung java's built-in garbage collection mechanism).
Experience has taught me practical measures of quality programmers in no particular order:
1. They must know how to program at the most simple level (e.g. competency in structured programming in C would be a good starting point - a basic understanding of LISP programming a plus) before tackling more complex programming tasks. I get the sense there are a lot of cut-and-paste programmers out there who really don't understand what the underlying code they are creating is actually doing.
2. Have an innate ability to focus on simple solutions, rather than being clever. KISS principle must be understood and brought into every design decision from the start. That is not to say there are no complexities, but understanding what is simple given the problem at hand - some simple things are complex when compared to other systems - and having the ability to avoid needless complexity.
3. Literate - must be able to not only communicate effectively externally - but also their comments in code should illuminate the subject matter in a clear, concise manner. Ideally should be able to get workable technical documentation straight from their comments - via doxygen or the like (perldoc, pydoc etc).
4. Their code must be maintainable and extendable. If an average programmer cannot maintain the code, and is required to rewrite the system from scratch - then you have failed as a quality programmer. Change is inevitable - how resilient your system is to change is a measure of your ability as a programmer.
5. They must understand a lot about technology outside of the world of their application. Their application will live in a world of networks, machines (physical and virtual), storage systems, communication protocols, and APIs - they must understand the implications of software design choices given a set of environmental requirements. The best programmers not only know how to code up systems, but also how to give advice about what their systems will be capable of doing given the environment, or lack thereof - and act upon that if it is possible to adjust via changes to software alone (e.g. choosing multithreading/multiprogramming design over single thread of execution).
6. They must be able to create secure code. If the company they work for doesn't produce a guide to that, then they should develop that on their own - and live by it - and consistently improve it. If they are using frameworks/libraries written by someone else, they should audit or test it to be sure the underlying implementation is secure.
7. Must be able to get along with others and work as part of a team; ideally if they are really a quality programmer, I would expect them to also mentor and share their ideals and capabilities with their peers to bring everyone up as much as possible. Quality programmers are not primadonnas.
That's it from my standpoint.
Define 'Application'. Technically the blackberry operating system is an application - so based upon his own statement, blackberry OS should be made to run on any other operating system. In the annals of dumb-assedness, this is one for the record books!
I'm running Windows 8.1 Pro on the few gaming machines in my home - and happy as a clam. I have one Win7 machine left in the network that is getting ready to get the treatment (new video card, power supply, and Windows 8.1 Pro).
I agree.
P.S. I would have thought your statements more appropriate to Perl than Python:
I came to python after using perl for over 10 years - and have never looked back. Hands down it can do everything perl can do - while providing clear, readable code that is consistent from one developer to the next...you have to really dig down into the bowls of python to create anything that would make me scratch my head - whereas that is trivial to accomplish with perl - and was the cause of many headaches over the years when needing to work with multiple developers' code. I debugged my last hanging curly brace/missing semicolon long ago.
What versions are you using, and what features are broken between them that you are complaining about? 3.0 was clearly a departure from the 2.X versions - and that is well known; if you have code that needs 2.X, you can stick with that until it makes sense to transition/migrate your code to 3.0. Right now I'm using 2.6/2.7 - and it is solid as a rock, so I'm not sure what you're complaining about; no one is forcing you to upgrade versions if you don't want/need to, right?
Or worse: they simply bypass you:
A: We need your widget X to be modified to produce wingnut Y by March.
B: I can't commit to that now; I need to work up the design and give you a good estimate.
A: Never mind. We'll go with Team C and their widget Z - they assure us they can have it done well before March (the implication being they are more responsive/better than us - never mind that the new widget isn't integrated with our network or systems - and they are going to need us to do the integration work anyway because they know nothing about the systems etc..)
At this point the PMs and Program Managers break into song:
I want a feast I want a bean feast Cream buns and doughnuts and fruitcake with no nuts so good you could go nuts. No, now! I want a ball I want a party Pink macaroons and a million balloons and performing baboons and Give it to me now. I want the world, I want the whole world. I want to lock it all up in my pocket It's my bar of chocolate Give it to me now! I want today I want tomorrow I want to wear them like braids in my hair and I don't want to share them I want a party with roomfuls of laughter Ten thousand ton of ice cream And if I don't get the things I am after I'm going to scream! I want the works, I want the whole works! Presents and prizes and sweets and surprises in all shapes and sizes, And now! Don't care how I want it now! Don't care how I want it now!
From what I've learned in the last three companies I worked for that used agile, agile means that an ungodly amount of time is spent in meetings and constant, meaningless record-keeping. God, I hate agile. It gets in the way of doing good, timely work.
They should probably start off by reading the Agile Manifesto...where it talks about the values of agile development - one of which is to value Working software over comprehensive documentation. Sounds like they have the wrong focus.
Mediocrity is not uncommon, and there are way too many people in the development end of things that shouldn't be. I've been dealing with these clowns for almost 20 years now - and this very topic is what is driving me to retire early and do something else with my time, instead of the endless death marches to nowhere.
But fleeing from Linux to BSD doesn't solve the problem, that's just running away from it. If the major BSD distros decided to incorporate a systemd-like system then what?
Then it will be time to fork Linus...
J/K
However, maybe someone should give the Linux POSIX APIs some loving - and implement a new improved non-systemd distro, and add good support for features/apps that were lost in the 'Great Systemd Landrush of 2014' (basically fork projects that decide only to support systemd - if they are something we gotta have on BSD and Linux).
The one thing I think we can depend upon is the Linux Kernel itself...everything else is questionable given limited resources; if you care about having a given feature that is threatened - put your money/sweat where your mouth is - and support it.
I would like to know what kind of administration you are doing through a 'flash web gui'? Isn't command line sufficient for admin work? Or am I missing the point in some (not so) subtle way?
Interestingly enough, as I wrote the above, the flash player in Chrome decided to die...heh.
There are people who think that advising citizens to devolve into consumers is a dubious proposition.
Devolve? I'm still waiting for them to evolve into citizens.
It is a royal pain in the arse. I prefer recognizing the seasons, rather than trying to hide them. It also mucks with our normal sleep pattern during the switch over.
Who is going to pay for all of that fiber - and associated changes to the network to allow it to go the last mile (so far, the only fiber we've seen to the home is in very small enclaves of people who can afford premium services anyway)?
If you believe that should reside in the corporate realm, then how do you as a corporation turn a profit while also investing in a universal fiber network?
If you believe it should be in the government realm - how do you get politicians to support fund allocations for it - and who does the money go to (municipalities, the aforementioned corporations, someone else)?
For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional. So nobody is forced to use systemd if they don't want to.
Until some key functionality used by people is no longer available in that distro due to decisions made upstream to no longer support the code base, or other dependencies.
If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.
Not trivial. Not easy. Not freedom of choice.
That is simply a lie.
... Keeping SysV init is an easy choice for a distro that does care about the needs of sysadmins. ...
There; fixed that for you. Your statement made a very big assumption - not borne out by statements I've read here by system admins.
I thought that was a given?
While, in principle I agree with you (I learned at a university that had several MIT PHDs in the computer science department - one of which was the head of the department - and later in my career when interviewing new candidates, and working with people from what I will call 'sub standard' programs - I saw first hand that all CS degrees were not equal) - I also realize that the people coming from the top university are going to gravitate to where the money is - meaning if you are a small company, or in a company that can't attract the top talent you will be stuck with what you can get.
This situation isn't bound to change, so how do we deal with this? I think the solution should be multifold and systematic to have possibility of success:
If we don't find a way to something like what I describe, we will continue to suffer as we keep expecting all CS graduates/programmers to be equal. HR and Execs don't like this because they want all developers to be interchangeable widgets...but reality does not bend to policy.