A car is a big experience, enveloping the whole body. There is a whole lot of room for differentiation in the experience in everything from suspension to steering to transmission, to the weight and insulation and materials.
For a slab of touchscreen, there's only so much it can really do to provide a different experience from the cheaper slab of touchscreen running the same software. While functional differences do exist, so far the major draw is to make people notice the notch and recognize you must have spent money on the fancier model. It's like a Rolex watch, a status symbol without practical justification of the cost, at least considering the availability of lower end IOS devices.
That is peculiar, as in many *more* interview situations, the interviewer can be put off if you are too interested in talking about benefits and salary before things are settled.
I recall once we had an entry position and one guy *really* put off the manager by asking about flexible hours and vacation too early. The kicker is the answers in practice would have been pretty good for the candidate, but the hiring manager made it sound rougher, largely because they were a bit frustrated by the asking. It was an exceedingly dumb thing and petty for the manager, but it's sadly the practical reality.
Well, one I don't know if that recruiter was for the company or a third party headhunter.
One time I was pulled in by a third party recruiter and the interviewer starts talking about skills from my resume I didn't recall. I asked to see their copy of my resume and the recruiter had *changed* it to say things to get me in the door,and I mentioned that and presented my actual resume. This was something the parent mentioned, that the recruiter can modify the CV on its way through.
Now on the face of it, this would seem pretty underhanded, but I got that job and the manager said that he would have probably not have even gotten to see my resume as I had typed up, for lack of actual direct experience in the field.
Eventually in that position I got to interview people. We would ask about certain things even if omitted by a resume, because about 25% of the time, the answer turns out to be yes, but they didn't prioritize it in their resume. Many keep their resume/CV "to the point" and try to filter out what they would guess as irrelevant to the position. Often times we would mention something not expressly listed in the opening, because during the course of an interview we discern there might be valuable, albeit not directly relevant experience. For example, we had the converse of your situation, a graduate who's school curriculum was basically 100% microsoft funded and we needed a linux developer. He could talk all day long about C# and the.Net framework. None of this was directly relevant, but we asked questions and evaluated his C# experience and how adaptable he seemed to be and his general attitude when faced with the prospect of something outside his experience and Linux centric. We decided he was the second best candidate of many despite complete lack of direct experience. The best did have more direct experience and it certainly was a concern, but if not for that better candidate, he would have gotten the job, even though he had none of the direct experience we requested in the position.
The commands are way too verbose to type, and the tab-completion is helpful, but the verb-noun arrangement is exactly opposite of helpful tab completion (noun-verb would have been better). There is inconsistency about what you can do when you pipe (if you pipe with an exe, you have to do text manipulation, others you must do format- cmdlets instead). If you have something with spaces that is executable you have to quote it, and because powershell assumes a string value without a command is a return, needs to be prefaced with & to say "I really mean to execute this", which wouldn't come up so often if not for the fact than windows likes to standardize on directories with spaces in them. It also is another weird inconsitency, the first word is generally an action to do, except hen it looks like a vlue then it isn't an action to do. It takes a relatively long time for the powershell runtime to load up. bash is barely measureable, but even then dash was popularized by wanting an even faster runtime, a.psh incurs a rather heavy startup cost. It inherits a lot of the things in terms of readability that people rightfully criticize perl and javascript for, though admittedly not as bad as javascript when it comes to complex server interactions. Ultimately, the powershell terminal in windows is still pretty bad, compared to terminals on other platforms, despite improvements.
Ultimately there is an upside (function based rather than process based makes for more efficient execution), but the supporting ecosystem is still rather weak for powershell, as windows developers generally either ignore it or put a token effort in to mark the 'supports powershell' marketing tickbox, but not grasping what would really make their cmdlets useful. The concept is however interesting, since on the bash side you might fork three or so processes to do a simple command and very simple text processing, which when put into automation makes for slow stuff.
I will say that my exposure to.net was heavy on the TLS part. It was also prior to interacting with OpenSSL, but OpenSSL was a huge relief after dealing with.Net TLS. The windows concept of how to manage certificates is maddeningly convoluted, particularly. Note I've seen hints of Java and it also looks pretty maddening, and seems to resemble.Net, but I have thus far avoided more in depth Java development to really make that determination.
I just don't see this trend accelerating becoming more dominant than it already has. People still use their desktop applications all the time. My work has *repeatedly* tried to make people use brwoser hosted apps and time and time again they find whatever contortion required to open in a desktop app. Some people won't go and not all applications work out well that way.
Yeah, after dealing extensively with powershell.. I really don't think the linux world has anything to gain by jumping on powershell.
This extends to the.net stuff, I'd much rather have the leading open non-.net api to any of the horrendous.net apis I've had the displeasure of dealing with.
Powershell may be better than cmd, but as a scripting language it is far more headache inducing than python, and as a commandline it has some nice tricks, but those nice tricks create some weird syntax to contend with as well.
I suppose the goal is 'can linux desktop become the universal application platform' and the answer is theoretically yes, practically, no.
For OSX apps, there hasn't even been much of an interest in theory. GNUstep had an injection of liveliness for people wanting to make at least code compile for OSX and Linux, but that enthusiasm died out. It never ever began to think about binary compatibility.
For Windows apps, sure, wine has been doing it's job admirably, but it's chasing a moving target that has much more resources than it does.
Now the phenomenon you mention speaks to another possibility: kernel system call emulation and just use the Windows/OSX system as-is. This is of limited utility as there isn't a supported/licensed way to do this. It's one thing to borrow the userspace of a free operatiing system, but doesn't really work for closed-source applications.
RHEL doesn't exactly inspire 'enthusiasm'. It's whole raison d'etre is to provide solid environment without threat of unexpected disruptive technology. For example, the most recent RHEL is still producing an environment that resembles state of the art 4 years ago.
The sort of people who are enthusiastic enough to be so proactive about it are going to be more impatient with the cadence than appreciative of the stability.
The question is the reachable audience for the poll. How many Linux users go to Linux Journal regularly? I know I don't and never have, and I've been using linux since kernel 1.2.x.
Something about the audience correlates highly to the results they got. Which is intersting, but not particularly telling about the wider market.
Objectively, the most prolific linux distribution is nearly certainly android, but doubt many people in that userbase care at all.
Other distros may have more enthusiasm, but perhaps directed at a different community, one more aligned to given distributions or something like that.
If the results are truly representative of their market, it would vindicate their business strategy.
Sure, most prefer the multi-vendor Android ecosystem.
If however 47% are happy to buy into lock-in, then Xiaomi's investment in the platform is well justified for a future of cranking up the margin without seeing all their customers jump ship.
The ambiguity is whether those two words are both qualifying the packing action or distinctly enumerating shipment as distinct from the packing.
With a comma, the latter would be the case. As it stands, it contains one of two errors, either a missing comma before the conjunction or a missing conjunction before the word 'packing'. Technically, one cannot assume which error was the error that was made, though omitting the comma seems a more likely sort of mistake. The tendency to use complex sentence construction in laws adds to the potential for confusion.
Sure, people can identify technical flaws/merits of different cryptocurrency, but when all is said and done, the fate of all of them is tied together.
If Bitcoin ultimately fails, it'll bring the whole decentralized cryptocurrency concept with it. The non-technical aspects are more relevant to a currency and all the cryptocurrencies are approximately the same on that front: not vaguely representative of anything concrete nor backed by any organization. Sadly, the consensus of the people is fickle and lacks the stability to base a currency on.
I recall an article a while back proclaiming that programmer jobs would go away because AI 'is here'. Written obviously by people who have no understanding of the current things being labeled 'AI'.
It's obvious to those deeply engaged in the technology, but it is not at all obvious to the wider public, which includes a lot of decision makers who can create big problems if they just have the marketed hype to go on.
The key is a balance, describing things that it can do well on (taking image data and extrapolating discrete actionable components, measuring how 'close' one item in one picture is to another, etc) but without making people think it can do other things (engage in a conversation, have any inkling of how to deal with a situation not contained in training, etc).
We saw roughly how heavier-than-air flight would work, but we didn't have the pieces to put it together. We understood the airborne part enough to carry humans dating back at *least* to the sixth century (earliest recorded 'paragliding'). We couldn't make a practical aircraft, but we could see how the pieces would play a role in such a marvel if we solved other pieces.
Here, the current 'AI' craze doesn't even in theory extrapolate to higher-order displays of intelligence. It is a highly practical field to advance and is certainly useful, but *if* we want to go to more 'intelligent' systems, it's going to be based on a different methodology, or at least no one who understands the field can see a hypothetical extrapolation of this approach that leads to those results.
The problem people have is that a useful, albeit narrow discipline is conflated with the entirety of human intelligence. I have seen many in the field understandably trying to discourage the phrase 'AI' to head off very annoying irrelevant conversations and concerns.
Even before wikipedia, and way earlier than college, I remember in middle school getting drilled into our heads that you do not cite or reference a compilation like an encyclopedia directly, but use it to find material to reference.
The malleability of wikipedia is a new dimension, but even without that you do not want errors to propogate by re-interpreting a re-interpretation of a re-interpretation.
To the extent that they play a role, it is expected to drill down to the citations provided by the article, and chase down the citations provided by those sources, and so on until you get to the original works and internalize them for yourself.
The idea is to avoid a telephone game where material gets cited and slightly 'refined' repeatedly and get distorted.
However it is expected to use those resources to help identify relevant source material.
The ratio of how much the funding is used for capital versus other expenditures doesn't change the fact that fundraising through going public can be appealing.
One thing the ratio did in the past, however, was to mitigate the looting the shareholders could do to the company. Capital assets are not trivially liquidated and as such contribute to a company having a hard time financially evolving themselves if they have a lot of money tied up in assets. A lot of companies getting rolling love and pay a premium to have flexibility and so they have perhaps more money being spent, but they can change their minds easily.
However, that flexibility also includes the ability to throw liquidity at the shareholders, and investment firms can get very pushy if they see liquidity and demand stock buybacks and large dividends for short term benefits even if the company's well being is better server through longer term investments. Being a public company attracts investment firms that don't give a damn about your business, and statistically speaking they are better off sucking the blood out of the company than letting it ride, so they will limit a companies ability to make long range bets.
This cuts both ways, for positions and candidates.
When a phrase becomes a buzz word, it means whatever whoever wants it to mean, but they have to have it in resumes/job postings to look hip.
If you put one of them in criteria, congratulations, every resume on the planet is applicable. Not becuase people have relevant skills, but because people will find any way they can to justify putting it on. The diluted meaning means there's probably some way people can work it in to their resumes.
It's also a warning sign to see in a job posting. If a company is seeking a buzzed skillset, it is more likely than not they have no idea what they are doing and have no good reason to even be poking about in the area, but some management person read enough articles saying that a business *must* do this to stay relevant.
It is a very confusing time. The norm is pretty much to misrepresent yourself to get some position or to look impressive, or in some cases just to get a vendor to connect a customer to someone vaguely knowledgeable.
I have to be sympathetic though, as the vast majority of the time when I encounter someone making their experience/day-to-day job sound more complex than it is, there work is actually being done well as it stands and would not be served by 'legitiamtely' chasing the buzz. They have to appease a management team that reads tech articles telling them that they have to disrupt how they manage their work and that pass down mandates along those lines without understanding. The best way forward for a business is sometimes exaggerating how hip and modern they are, even to themselves.
Of course there are clearly downsides, phrases that achieve buzz word status have their meaning diluted as to mean next to nothing at all (DevOps), when you describe yourself in these ways to others and ask questions, you'll get slapped with answers that make no sense to you, or are much much harder to accommodate than another answer would be (getting a 300 line code sample in a language you don't use instead of a more helpful illustrative 1 liner to demonstrate the meat of the point). You can also induce your vendors to run around like a chicken with it's head cut off trying to cobble something together for you that you don't want anyway.
I'll also add look up a few of your favorite projects on github and look carefully at the "insights" chart on the contributors. Many of them will clearly have one significant contributor, or maybe a small team, and hunderds of one-line contributors (putting your brand on big projects is good for resumes).
I'd take a team of 4 or 5 solid people over dozens of developers. I resisted 'investmnet' in my team at a former employer as I had never seen a project survive such an expansion with quality intact under their management.
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
As a technical lead, this phenomenon has been a source of great frustration in getting candidates. I'm only allowed to even know about a prospective candidate after 2 or three layers of non-technical folks have "helped" me by making an assessment of the candidate's technical chops. Similarly they "help" in the requirements by padding things out so that a candidate will have everything needed to "hit the ground running", because of course there would be no ramp up needed if they *just* have the right resume...
No recognition that there is always going to be a ramp up period, that you want flexibility more so than existing directly relevant experience.
The last several decades or so of software ecosystem shows that yes, indeed bugfix and security updates to libraries happen all the time without requiring dependent applications to rebuilt.
At least for mainstays of C and C++ application development. People breaking any semblance of compatibility is generally not tolerated in C/C++ (though there are exceptions) and even in the broader software market, people *tend* to be mindful of compatibility (though in the worlds of gems, pypi, npm, et al, yes there are a larger proportion of broken libraries. If you stick to your distro and pick a distro that cares, you can have a solid 8 years of updates that won't break existing applications.
Slashdot Mirror
You don't have to make this a wholly anti-apple thing, you could think 'iPhone 9' is pretty much everything most people would want out of an iPhone.
Here a car analogy falls short.
A car is a big experience, enveloping the whole body. There is a whole lot of room for differentiation in the experience in everything from suspension to steering to transmission, to the weight and insulation and materials.
For a slab of touchscreen, there's only so much it can really do to provide a different experience from the cheaper slab of touchscreen running the same software. While functional differences do exist, so far the major draw is to make people notice the notch and recognize you must have spent money on the fancier model. It's like a Rolex watch, a status symbol without practical justification of the cost, at least considering the availability of lower end IOS devices.
That is peculiar, as in many *more* interview situations, the interviewer can be put off if you are too interested in talking about benefits and salary before things are settled.
I recall once we had an entry position and one guy *really* put off the manager by asking about flexible hours and vacation too early. The kicker is the answers in practice would have been pretty good for the candidate, but the hiring manager made it sound rougher, largely because they were a bit frustrated by the asking. It was an exceedingly dumb thing and petty for the manager, but it's sadly the practical reality.
Well, one I don't know if that recruiter was for the company or a third party headhunter.
One time I was pulled in by a third party recruiter and the interviewer starts talking about skills from my resume I didn't recall. I asked to see their copy of my resume and the recruiter had *changed* it to say things to get me in the door,and I mentioned that and presented my actual resume. This was something the parent mentioned, that the recruiter can modify the CV on its way through.
Now on the face of it, this would seem pretty underhanded, but I got that job and the manager said that he would have probably not have even gotten to see my resume as I had typed up, for lack of actual direct experience in the field.
Eventually in that position I got to interview people. We would ask about certain things even if omitted by a resume, because about 25% of the time, the answer turns out to be yes, but they didn't prioritize it in their resume. Many keep their resume/CV "to the point" and try to filter out what they would guess as irrelevant to the position. Often times we would mention something not expressly listed in the opening, because during the course of an interview we discern there might be valuable, albeit not directly relevant experience. For example, we had the converse of your situation, a graduate who's school curriculum was basically 100% microsoft funded and we needed a linux developer. He could talk all day long about C# and the .Net framework. None of this was directly relevant, but we asked questions and evaluated his C# experience and how adaptable he seemed to be and his general attitude when faced with the prospect of something outside his experience and Linux centric. We decided he was the second best candidate of many despite complete lack of direct experience. The best did have more direct experience and it certainly was a concern, but if not for that better candidate, he would have gotten the job, even though he had none of the direct experience we requested in the position.
The commands are way too verbose to type, and the tab-completion is helpful, but the verb-noun arrangement is exactly opposite of helpful tab completion (noun-verb would have been better). There is inconsistency about what you can do when you pipe (if you pipe with an exe, you have to do text manipulation, others you must do format- cmdlets instead). If you have something with spaces that is executable you have to quote it, and because powershell assumes a string value without a command is a return, needs to be prefaced with & to say "I really mean to execute this", which wouldn't come up so often if not for the fact than windows likes to standardize on directories with spaces in them. It also is another weird inconsitency, the first word is generally an action to do, except hen it looks like a vlue then it isn't an action to do. It takes a relatively long time for the powershell runtime to load up. bash is barely measureable, but even then dash was popularized by wanting an even faster runtime, a .psh incurs a rather heavy startup cost. It inherits a lot of the things in terms of readability that people rightfully criticize perl and javascript for, though admittedly not as bad as javascript when it comes to complex server interactions. Ultimately, the powershell terminal in windows is still pretty bad, compared to terminals on other platforms, despite improvements.
Ultimately there is an upside (function based rather than process based makes for more efficient execution), but the supporting ecosystem is still rather weak for powershell, as windows developers generally either ignore it or put a token effort in to mark the 'supports powershell' marketing tickbox, but not grasping what would really make their cmdlets useful. The concept is however interesting, since on the bash side you might fork three or so processes to do a simple command and very simple text processing, which when put into automation makes for slow stuff.
I will say that my exposure to .net was heavy on the TLS part. It was also prior to interacting with OpenSSL, but OpenSSL was a huge relief after dealing with .Net TLS. The windows concept of how to manage certificates is maddeningly convoluted, particularly. Note I've seen hints of Java and it also looks pretty maddening, and seems to resemble .Net, but I have thus far avoided more in depth Java development to really make that determination.
I just don't see this trend accelerating becoming more dominant than it already has. People still use their desktop applications all the time. My work has *repeatedly* tried to make people use brwoser hosted apps and time and time again they find whatever contortion required to open in a desktop app. Some people won't go and not all applications work out well that way.
Yeah, after dealing extensively with powershell.. I really don't think the linux world has anything to gain by jumping on powershell.
This extends to the .net stuff, I'd much rather have the leading open non-.net api to any of the horrendous .net apis I've had the displeasure of dealing with.
Powershell may be better than cmd, but as a scripting language it is far more headache inducing than python, and as a commandline it has some nice tricks, but those nice tricks create some weird syntax to contend with as well.
I suppose the goal is 'can linux desktop become the universal application platform' and the answer is theoretically yes, practically, no.
For OSX apps, there hasn't even been much of an interest in theory. GNUstep had an injection of liveliness for people wanting to make at least code compile for OSX and Linux, but that enthusiasm died out. It never ever began to think about binary compatibility.
For Windows apps, sure, wine has been doing it's job admirably, but it's chasing a moving target that has much more resources than it does.
Now the phenomenon you mention speaks to another possibility: kernel system call emulation and just use the Windows/OSX system as-is. This is of limited utility as there isn't a supported/licensed way to do this. It's one thing to borrow the userspace of a free operatiing system, but doesn't really work for closed-source applications.
While having many more carbon sinks is good and all, it can be bad if high albedo areas become forest, as that will contribute to warming.
RHEL doesn't exactly inspire 'enthusiasm'. It's whole raison d'etre is to provide solid environment without threat of unexpected disruptive technology. For example, the most recent RHEL is still producing an environment that resembles state of the art 4 years ago.
The sort of people who are enthusiastic enough to be so proactive about it are going to be more impatient with the cadence than appreciative of the stability.
The question is the reachable audience for the poll. How many Linux users go to Linux Journal regularly? I know I don't and never have, and I've been using linux since kernel 1.2.x.
Something about the audience correlates highly to the results they got. Which is intersting, but not particularly telling about the wider market.
Objectively, the most prolific linux distribution is nearly certainly android, but doubt many people in that userbase care at all.
Other distros may have more enthusiasm, but perhaps directed at a different community, one more aligned to given distributions or something like that.
If the results are truly representative of their market, it would vindicate their business strategy.
Sure, most prefer the multi-vendor Android ecosystem.
If however 47% are happy to buy into lock-in, then Xiaomi's investment in the platform is well justified for a future of cranking up the margin without seeing all their customers jump ship.
The ambiguity is whether those two words are both qualifying the packing action or distinctly enumerating shipment as distinct from the packing.
With a comma, the latter would be the case. As it stands, it contains one of two errors, either a missing comma before the conjunction or a missing conjunction before the word 'packing'. Technically, one cannot assume which error was the error that was made, though omitting the comma seems a more likely sort of mistake. The tendency to use complex sentence construction in laws adds to the potential for confusion.
Sure, people can identify technical flaws/merits of different cryptocurrency, but when all is said and done, the fate of all of them is tied together.
If Bitcoin ultimately fails, it'll bring the whole decentralized cryptocurrency concept with it. The non-technical aspects are more relevant to a currency and all the cryptocurrencies are approximately the same on that front: not vaguely representative of anything concrete nor backed by any organization. Sadly, the consensus of the people is fickle and lacks the stability to base a currency on.
Counter acting hype is valuable.
I recall an article a while back proclaiming that programmer jobs would go away because AI 'is here'. Written obviously by people who have no understanding of the current things being labeled 'AI'.
It's obvious to those deeply engaged in the technology, but it is not at all obvious to the wider public, which includes a lot of decision makers who can create big problems if they just have the marketed hype to go on.
The key is a balance, describing things that it can do well on (taking image data and extrapolating discrete actionable components, measuring how 'close' one item in one picture is to another, etc) but without making people think it can do other things (engage in a conversation, have any inkling of how to deal with a situation not contained in training, etc).
We saw roughly how heavier-than-air flight would work, but we didn't have the pieces to put it together. We understood the airborne part enough to carry humans dating back at *least* to the sixth century (earliest recorded 'paragliding'). We couldn't make a practical aircraft, but we could see how the pieces would play a role in such a marvel if we solved other pieces.
Here, the current 'AI' craze doesn't even in theory extrapolate to higher-order displays of intelligence. It is a highly practical field to advance and is certainly useful, but *if* we want to go to more 'intelligent' systems, it's going to be based on a different methodology, or at least no one who understands the field can see a hypothetical extrapolation of this approach that leads to those results.
The problem people have is that a useful, albeit narrow discipline is conflated with the entirety of human intelligence. I have seen many in the field understandably trying to discourage the phrase 'AI' to head off very annoying irrelevant conversations and concerns.
Even before wikipedia, and way earlier than college, I remember in middle school getting drilled into our heads that you do not cite or reference a compilation like an encyclopedia directly, but use it to find material to reference.
The malleability of wikipedia is a new dimension, but even without that you do not want errors to propogate by re-interpreting a re-interpretation of a re-interpretation.
To the extent that they play a role, it is expected to drill down to the citations provided by the article, and chase down the citations provided by those sources, and so on until you get to the original works and internalize them for yourself.
The idea is to avoid a telephone game where material gets cited and slightly 'refined' repeatedly and get distorted.
However it is expected to use those resources to help identify relevant source material.
"Welcome!
You are not a human
like these: "
I tried once, have 100% success rate. Maybe there's something I don't know about myself.
The ratio of how much the funding is used for capital versus other expenditures doesn't change the fact that fundraising through going public can be appealing.
One thing the ratio did in the past, however, was to mitigate the looting the shareholders could do to the company. Capital assets are not trivially liquidated and as such contribute to a company having a hard time financially evolving themselves if they have a lot of money tied up in assets. A lot of companies getting rolling love and pay a premium to have flexibility and so they have perhaps more money being spent, but they can change their minds easily.
However, that flexibility also includes the ability to throw liquidity at the shareholders, and investment firms can get very pushy if they see liquidity and demand stock buybacks and large dividends for short term benefits even if the company's well being is better server through longer term investments. Being a public company attracts investment firms that don't give a damn about your business, and statistically speaking they are better off sucking the blood out of the company than letting it ride, so they will limit a companies ability to make long range bets.
This cuts both ways, for positions and candidates.
When a phrase becomes a buzz word, it means whatever whoever wants it to mean, but they have to have it in resumes/job postings to look hip.
If you put one of them in criteria, congratulations, every resume on the planet is applicable. Not becuase people have relevant skills, but because people will find any way they can to justify putting it on. The diluted meaning means there's probably some way people can work it in to their resumes.
It's also a warning sign to see in a job posting. If a company is seeking a buzzed skillset, it is more likely than not they have no idea what they are doing and have no good reason to even be poking about in the area, but some management person read enough articles saying that a business *must* do this to stay relevant.
It is a very confusing time. The norm is pretty much to misrepresent yourself to get some position or to look impressive, or in some cases just to get a vendor to connect a customer to someone vaguely knowledgeable.
I have to be sympathetic though, as the vast majority of the time when I encounter someone making their experience/day-to-day job sound more complex than it is, there work is actually being done well as it stands and would not be served by 'legitiamtely' chasing the buzz. They have to appease a management team that reads tech articles telling them that they have to disrupt how they manage their work and that pass down mandates along those lines without understanding. The best way forward for a business is sometimes exaggerating how hip and modern they are, even to themselves.
Of course there are clearly downsides, phrases that achieve buzz word status have their meaning diluted as to mean next to nothing at all (DevOps), when you describe yourself in these ways to others and ask questions, you'll get slapped with answers that make no sense to you, or are much much harder to accommodate than another answer would be (getting a 300 line code sample in a language you don't use instead of a more helpful illustrative 1 liner to demonstrate the meat of the point). You can also induce your vendors to run around like a chicken with it's head cut off trying to cobble something together for you that you don't want anyway.
I'll also add look up a few of your favorite projects on github and look carefully at the "insights" chart on the contributors. Many of them will clearly have one significant contributor, or maybe a small team, and hunderds of one-line contributors (putting your brand on big projects is good for resumes).
I'd take a team of 4 or 5 solid people over dozens of developers. I resisted 'investmnet' in my team at a former employer as I had never seen a project survive such an expansion with quality intact under their management.
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
As a technical lead, this phenomenon has been a source of great frustration in getting candidates. I'm only allowed to even know about a prospective candidate after 2 or three layers of non-technical folks have "helped" me by making an assessment of the candidate's technical chops. Similarly they "help" in the requirements by padding things out so that a candidate will have everything needed to "hit the ground running", because of course there would be no ramp up needed if they *just* have the right resume...
No recognition that there is always going to be a ramp up period, that you want flexibility more so than existing directly relevant experience.
The last several decades or so of software ecosystem shows that yes, indeed bugfix and security updates to libraries happen all the time without requiring dependent applications to rebuilt.
At least for mainstays of C and C++ application development. People breaking any semblance of compatibility is generally not tolerated in C/C++ (though there are exceptions) and even in the broader software market, people *tend* to be mindful of compatibility (though in the worlds of gems, pypi, npm, et al, yes there are a larger proportion of broken libraries. If you stick to your distro and pick a distro that cares, you can have a solid 8 years of updates that won't break existing applications.