Of course, depending on your perspective of *marker*, this is suspect.
From a "market to sell services to", certainly IBM is doing some stuff to India, but by and large it's using India workforce to support companies in other countries. While this can serve well when expertise happens to be in an inconvenient place to the customer, what IBM is doing is seeking lowest possible pay to even vaguely appear to be able to support their clients. Note this is *not* an indictment of India, wherever IBM went it would be seeking the cheapest, not the best that job market has to offer. So while very good India tech skill does exist, it's also beyond IBM's willingness to pay. When they do by luck get a good employee, they will lose them in a few months to a company willing to pay local talent what they are worth. Combining it with Offshoring is a way to smokescreen things so the client is either unable to tell what is happening, or would be accused of being racist at suggesting the reality.
If the situation were reversed and IBM were sourcing talent from the US to non-US customers, IBM would be pursuing 20 year olds barely able to get degree-mill credentials in the US. They can't do so now because that would just be *too* obvious to american companies without the distance and culture gap to obscure things.
Time in the industry and open source I think are two factors.
Folks here have fatigue from a parade of 'silver bullets'. In the last 20 years, we've seen Java, C#, Perl, Python, Ruby, Javascript, and Rust all held up as 'the' way to do things.
So one people will jump to conclusions. For one, *most* of the fads have brought with them yet another managed runtime, meaning our operating systems are littered with at least one of each, if not multiple versions of each runtime. Which is ugly and also at times a security risk as applications bundle runtimes. So one gut reaction is 'oh look, yet another runtime', which may be inaccurate for a given language. The languages frequently get opinionated about distribution of software, sending users off to pypi, anaconda, cpan, gems, npm in addition to the OS packages, which is a pain to use and also a pain to support as a vendor as you encounter user after user influenced by their favorite language.
For another, each fad fragments various segments. You start seeing multiple projects roughly doing the same thing, and each having very good features that the other does not get because of language choice.
Also when a fad passes, a lot of projects that are very promising stall out because the language they chose went out of favor.
So there's a reluctance by now to even learn. Even after overcoming that reluctance and finding 'actually, this isn't so different in ecosystem from C/c++ like go, then the world moves on to Rust, another language that is admirably close to the c/c++ ecosystem in terms of the user experience (not as much the developer experience).
I wasn't questioning that, just that the 'javascript versus rust' is a bit silly on the 'security' side, since javascript as a language has those protections (one can again make arguments about deficiencies in the permissions architectures of the environment, but that's not really fundamental to either language.
The proposed value of Rust as an easier to secure language is a statement relative to C/C++. Comparing to other similarly protected languages, it does so without an intrusive or limited runtime or performance downsides.
A better translation is that he bemoans the convergence of the browsers to all be the same experience. What's the point of there being different browsers if they all settle on being identical?
I assume this is a troll, but biting for the sake of anyone who might remotely take this seriously...
The issues pointed out are running code deliberately trying to do things people didn't expect, which is a problem because the software has no *idea* whether you really want to do what the software developer is doing. Finer grained permissions do a lot, but things like burning up too much cpu usage is really hard to do. The privacy issues can be addressed through more robust permission structure, but again that has nothing to do with the language in use.
When people advocate for Rust for security reasons, it's compared to C/C++. C/C++ requires the developer to keep track of what memory addresses are or are not fair game and correctly indicate that to functions and/or avoid creating functions that are purely sentinel based (e.g. strcpy). Rust is more like languages like Javascript where the memory addresses that are fair game are baked into the variable.
While there are good practices in there, it's not exactly a good thing to say 'it's ok if things are more likely to go to reinstall than before because best practices means low risk'. The even better thing is 'still as unlikely to need reinstall, but even if you do it's no big deal'.
The major problem being a race condition can pass an initial test, and then bite you later. So a screwed up implicit dependency that failed 100%, not so bad, but the nature of the beast has been looks good at a glance, fails later.
The problem being that the benefit (faster boot) is generally limited in benefit, but the risk of another vector for common boot time failures is made higher.
I will confess my biggest gripe is journald's binary-only format for log data (yes, I know journalctl will do nifty things, but nifty things could have been done with plaintext logging and binary metadata to the side). Also udev has gotten a bit more wonky as of late, and frankly it's beyond my understanding to quite understand why. systemd can go nuts and spazz out with a service restarting sometimes (again, I'm not sure why..0, but the prinicple of being able to externalize the daemonization, building in watchdoging a service, and using cgroups to keep hold of the services isn't too bad an idea.
I will confirm that on my end, I'm still having to support a *lot* of new deployments on EL6. By the time EL6 was this old, *new* deployments of EL5 were pretty much unheard of.
I will say I have not questioned them as to why. systemd certainly stands tall as one difference, though it could be a more 'el6 was good enough', and generally the upgrade treadmill has been slowing down as the industry has 'grown up' with linux (same curse as microsoft, who faced more and more uphill battles upgrading their customers as time went on).
I honestly wouldn't be surprised if EL7 ends up as the Windows Vista of the Enterprise community... Skipped by anyone who has any option to do so.
If the assumption is that EL8 will change away from systemd, I'm pretty sure that's not in the cards. Of course systemd had atrocious bugs and the ecosystem wasn't ready when 7.0 happened, so it might be fair to say that systemd will be better by 8.0. Just like networkmanager in EL6 is a horrible mess that must be disabled, but in EL7 networkmanager can be lived with a lot of times, except systemd can't be disabled when it breaks you. Of course the majority of users I deal with still disable networkmanager even in EL7, so even if it is livable, it might still be unwelcome. systemd might have a harder battle as the team seems a bit more militant about their vision and less open to criticism compared to networkmanager, which despite screwing up horribly actually reacted well to criticism and improved.
Basically MS' IM product has been terrible all along, and MS kept thinking it was a marketing problem rather than a technical one.
The result is the same basic project being paraded under new name after new name. Going from OCS to Lync wasn't such a bad brand move, it was less of a mouthful. Going from Lync to 'Skype for business' was terrible, since it was clearly just Lync renamed to look like Skype, but no technical relationship between the two.
I would not count on MS suddenly 'getting it' and producing good product instead of branding exercise.
I would say they should have named it 'Lync' again. Skype for business has been the most confusing thing to talk about, because it has *zero* to do with Skype, except in the minds of MS marketing people.
As a result you can't just say 'Skype' because people won't do the right thing, you always had to say 'Skype for Business' which is a misleading mouthful.
I would say systemd could be called many things, but not that. The boot process is far less deterministic, by design. If one service takes a variable amount of time to execute, no longer does it block another so boot performance is improved as you no longer serialize a bunch of long-running service startups.. On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.
This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.
It's one thing to do software collections to yourself for the sake of getting your pet python project to work.
It's another thing to *require* a customer to do it. Software collections aren't an utterly trivial thing like 'use the python that comes with the base repo'
We have some internal use of software collections and it's not for the faint of heart. The nature of the beast is that the 'normal' python working is priority #1 for the os, and software collections have to inevitably work around that. Software collections for any httpd related stuff is even worse.
'read me the output of systemctl status httpd' is much easier than trying to get them to grep through/var/log/httpd/ file.
In general, the move away from free-form text config and log files enables a huge number of these commands to rattle off. Commands that aren't any more capable than use of sed/grep/etc, but much much easier to tell people what to do.
Knowing use of the text utils combined with plain text things enables the text based strategies to be more discoverable and knowledge to be more generally applicable, but hard to convey that to others. Also doing things with the text strategies can lead an admin to do less robust things that will fail, so it's not entirely without justification apart from support.
I will also say that this isn't a horrible thing for those using Ubuntu or Debian. It's just that it's best to live with efforts to support RHEL being close enough to support Ubuntu for free, and some self support to bridge the gap.
Particularly from the perspective of having to support devs from *entirely different companies*, supporting folks is a pain. Over a half-dozen iterations of Ubuntu are likely, and beyond that a myriad of random ppas and random install-from-tarball or gems or pypi...
Supporting customers on CentOS/RHEL is so much easier because we generally only have to support two camps for new software: RHEL6 and RHEL7. Of course some of my python devs *hate* having to continue to be compatible with python 2.6 for the sake of our RHEL6 users, but I'd much rather have that problem than supporting the sea of direct from upstream or rapidly churning distro cut off at random arbitrary points per customer.
Note this isn't about CentOS/RHEL making the customers easier to support, but the customers that *choose* that model are a mindset that's easier to support and also more willing to spend money on getting support. If folks wonder why vendors are not as enthusiastically supporting Ubuntu and similar, this is the reason.
I think the point is pure-play open source companies. IBM nor Microsoft are anywhere near pure-play open source. Open source is largely incidental to their value proposition when it comes up.
Churn is the enemy of the enterprise. A comfortable feeling that their staff will only need to retrain every 5 years or so, and even then it's not going to be particularly severe is important.
The businesses that are ready to push the envelope and get the latest and greatest technologies at a breakneck pace do exist. The problem being that such companies aren't interested in paying an external company like RedHat for support, they want the talent in-house. Even in theory, efforts to support such customers are expensive, each one can settle into their own cadence sticking you with the nightmare of many confusing iterations to support. Ubuntu is the current darling of this audience due to the 6 month release cycle, and one of Canonical's frustrations is that despite this strong position, they haven't been able to turn it to profit because that audience doesn't need the paid support services.
Actually, relatively speaking they pay more open source developers than other 'open source' companies.
Now there are companies that pay for more open source developers, but of the ones seeking to use Open Source as the basis of their business model rather than incidental to their mission, RHAT is ahead.
This is one of the reasons why when RHAT declares a move, the other business oriented distributions have little choice but to follow, as they lack the resources to do much.
Gnome 3: At some point RHAT realized that the desktop just doesn't matter to their business, so the engineers are pretty much free to do what they wish. That's why in RHEL7 the desktop packages are no longer so conservative as they were previously. All RHAT's revenue is on the server side, which brings us to...
systemd: Here's an example of a design that alienated a fair amount of the linux population. However, that population is folks who were interested in self supporting. Not RHAT's revenue stream. However, for those really knowing systemd inside and out, there's things in there that are easier to help support staff support *someone else*, particularly if the only convenient communication path is voice over a phone line. Sure, systemd can go off the rails and be inscrutable even to support staff, but that's when they break out 'just reinstall the thing', and honestly speaking if things are that bad and you need RHAT's support, it was going to be that bad anyway.
anyone who prefers Bash as a scripting language has brain damage.
Ehh.. that really depends...
If you replace 'have a config file' with 'just source a bash script', yeah, that's not so good and one could fairly argue that the majority of init scripts were effectively this.
If you have a bash script that is hundreds of lines longs with many functions and such, then I would agree there is brain damage.
But for quick and dirty script to run a few binaries, it's much simpler than other methods. One just needs to be mindful they don't stay with bash if whatever it is promotes beyond 'quick and dirty'.
Which is funny, since GPL means it's harder for a competitor to take your work and commercialize it without ability to enable you to compete back, and as long you you do copyright assignment, you are still free to close source if you *really* want, because the copyright holder is the only one with the right to sue for GPL violation.
So the GPL family is perfect for producing things that you don't want *other* companies to close up. Copryright assignment can be a red flag, but corporations and organizations do worse all the time.
Frankly, people that think closed source is the path to IP protection are missing out. In practice, open source doesn't inspire competition. I challenge folks to look for a single example of a company's open sourced product being turned against them into the market...
Now I wouldn't go *that* far, though no particularly new problems granted.
Of course, since MS is intentionally trying to blur the line between 'Outlook the app' and 'Outlook the microsoft hosted mail service', they are asking for any negative implications.
Of course the most blatantly misguided Microsoft branding confusion award goes to 'Skype' versus 'Skype for Business' which have *zero* to do with each other.
While GPL protects the kernel form a code perspective, the practical reality and ecosystem is another matter.
If they *just* did the kernels and people by and large still sourced from distributions, then in practice a move that is bad for the community *might* result in fork and Microsoft's fork dying on the vine due to distribution disinterest.
Of course they have cozied up to RedHat, and recent history has shown that RedHat gets to call the shots in practice for every distro. So in a theoretical fork of kernel for MS versus 'traditional' Linux, there is a chance that RedHat now could throw in with a hypothetical MS fork for true technical belief or profit, though as you say GPL would mitigate the risk, though the value of a legal fork is reduced if none of the popular distributions would take them up on it because no one except RedHat will confidently step up and say "we can support a kernel".
Of course, lets consider the bigger picture. Having big influence in the kernel could hypothetically be part of a bigger strategy. Let's say that MS made a pure linux distro, and that was to start a fully compatible platform with RedHat (a la CentOS), which is free but with very credible path to full support (evidence of credible support being visibly employing core kernel developers). They also release same day with RedHat, because they have technical resources to do so, more than CentOS has. For a great deal of the business world, this could easily become *the* dominant distribution, with objections being more political and future looking than techincal ("it's the same stuff, can do the same thing, and they have developers and so they can deliver the support we need, stop saying that 'EEE' FUD crap, you're paranoid and even if it were true, we are businesses and we don't care").
After being established, they can do things that most businesses would roll with. They could replace Samba with a MS originated project (some BSD-style license, for example), which would quickly take over, because who knows SMB and AD better than Microsoft right? Samba is another troublesome GPL portion, but one they could easily replace given their position in the market.
Of course this replacement along the way could highlight their own LDAP or use OpenLDAP (BSD style license) as a base rather than 389 and whatever Kerberos they see fit. Suddenly MS 'owns' identity management for enterprise use of Linux.
If they felt particularly about GUI side, they could very likely forge a desktop offering alternative to KDE and Gnome, and successfully hide away the vast majority of user facing GPL licensed software.
Once their popular and now technically distinct product is well established, they can start skipped providing source for much of the distro (after all, the ecosystem consists of a *lot* of BSD style licensed software), providing source only for the GPL portions. Ultimately, they could even replace the kernel if they felt like it (WSL is a closed source implementation of kernel interfaces, which could double as a test run of a path to make a Linux distro with a closed source kernel).
I don't particularly think their chances in embedded are high, but I could easily believe a future where they have become *the* professional Unix-like vendor though shenanigans.
Slashdot Mirror
Of course, depending on your perspective of *marker*, this is suspect.
From a "market to sell services to", certainly IBM is doing some stuff to India, but by and large it's using India workforce to support companies in other countries. While this can serve well when expertise happens to be in an inconvenient place to the customer, what IBM is doing is seeking lowest possible pay to even vaguely appear to be able to support their clients. Note this is *not* an indictment of India, wherever IBM went it would be seeking the cheapest, not the best that job market has to offer. So while very good India tech skill does exist, it's also beyond IBM's willingness to pay. When they do by luck get a good employee, they will lose them in a few months to a company willing to pay local talent what they are worth. Combining it with Offshoring is a way to smokescreen things so the client is either unable to tell what is happening, or would be accused of being racist at suggesting the reality.
If the situation were reversed and IBM were sourcing talent from the US to non-US customers, IBM would be pursuing 20 year olds barely able to get degree-mill credentials in the US. They can't do so now because that would just be *too* obvious to american companies without the distance and culture gap to obscure things.
Time in the industry and open source I think are two factors.
Folks here have fatigue from a parade of 'silver bullets'. In the last 20 years, we've seen Java, C#, Perl, Python, Ruby, Javascript, and Rust all held up as 'the' way to do things.
So one people will jump to conclusions. For one, *most* of the fads have brought with them yet another managed runtime, meaning our operating systems are littered with at least one of each, if not multiple versions of each runtime. Which is ugly and also at times a security risk as applications bundle runtimes. So one gut reaction is 'oh look, yet another runtime', which may be inaccurate for a given language. The languages frequently get opinionated about distribution of software, sending users off to pypi, anaconda, cpan, gems, npm in addition to the OS packages, which is a pain to use and also a pain to support as a vendor as you encounter user after user influenced by their favorite language.
For another, each fad fragments various segments. You start seeing multiple projects roughly doing the same thing, and each having very good features that the other does not get because of language choice.
Also when a fad passes, a lot of projects that are very promising stall out because the language they chose went out of favor.
So there's a reluctance by now to even learn. Even after overcoming that reluctance and finding 'actually, this isn't so different in ecosystem from C/c++ like go, then the world moves on to Rust, another language that is admirably close to the c/c++ ecosystem in terms of the user experience (not as much the developer experience).
I wasn't questioning that, just that the 'javascript versus rust' is a bit silly on the 'security' side, since javascript as a language has those protections (one can again make arguments about deficiencies in the permissions architectures of the environment, but that's not really fundamental to either language.
The proposed value of Rust as an easier to secure language is a statement relative to C/C++. Comparing to other similarly protected languages, it does so without an intrusive or limited runtime or performance downsides.
At least in theory.
A better translation is that he bemoans the convergence of the browsers to all be the same experience. What's the point of there being different browsers if they all settle on being identical?
I assume this is a troll, but biting for the sake of anyone who might remotely take this seriously...
The issues pointed out are running code deliberately trying to do things people didn't expect, which is a problem because the software has no *idea* whether you really want to do what the software developer is doing. Finer grained permissions do a lot, but things like burning up too much cpu usage is really hard to do. The privacy issues can be addressed through more robust permission structure, but again that has nothing to do with the language in use.
When people advocate for Rust for security reasons, it's compared to C/C++. C/C++ requires the developer to keep track of what memory addresses are or are not fair game and correctly indicate that to functions and/or avoid creating functions that are purely sentinel based (e.g. strcpy). Rust is more like languages like Javascript where the memory addresses that are fair game are baked into the variable.
While there are good practices in there, it's not exactly a good thing to say 'it's ok if things are more likely to go to reinstall than before because best practices means low risk'. The even better thing is 'still as unlikely to need reinstall, but even if you do it's no big deal'.
The major problem being a race condition can pass an initial test, and then bite you later. So a screwed up implicit dependency that failed 100%, not so bad, but the nature of the beast has been looks good at a glance, fails later.
The problem being that the benefit (faster boot) is generally limited in benefit, but the risk of another vector for common boot time failures is made higher.
I will confess my biggest gripe is journald's binary-only format for log data (yes, I know journalctl will do nifty things, but nifty things could have been done with plaintext logging and binary metadata to the side). Also udev has gotten a bit more wonky as of late, and frankly it's beyond my understanding to quite understand why. systemd can go nuts and spazz out with a service restarting sometimes (again, I'm not sure why..0, but the prinicple of being able to externalize the daemonization, building in watchdoging a service, and using cgroups to keep hold of the services isn't too bad an idea.
I will confirm that on my end, I'm still having to support a *lot* of new deployments on EL6. By the time EL6 was this old, *new* deployments of EL5 were pretty much unheard of.
I will say I have not questioned them as to why. systemd certainly stands tall as one difference, though it could be a more 'el6 was good enough', and generally the upgrade treadmill has been slowing down as the industry has 'grown up' with linux (same curse as microsoft, who faced more and more uphill battles upgrading their customers as time went on).
I honestly wouldn't be surprised if EL7 ends up as the Windows Vista of the Enterprise community... Skipped by anyone who has any option to do so.
If the assumption is that EL8 will change away from systemd, I'm pretty sure that's not in the cards. Of course systemd had atrocious bugs and the ecosystem wasn't ready when 7.0 happened, so it might be fair to say that systemd will be better by 8.0. Just like networkmanager in EL6 is a horrible mess that must be disabled, but in EL7 networkmanager can be lived with a lot of times, except systemd can't be disabled when it breaks you. Of course the majority of users I deal with still disable networkmanager even in EL7, so even if it is livable, it might still be unwelcome. systemd might have a harder battle as the team seems a bit more militant about their vision and less open to criticism compared to networkmanager, which despite screwing up horribly actually reacted well to criticism and improved.
Basically MS' IM product has been terrible all along, and MS kept thinking it was a marketing problem rather than a technical one.
The result is the same basic project being paraded under new name after new name. Going from OCS to Lync wasn't such a bad brand move, it was less of a mouthful. Going from Lync to 'Skype for business' was terrible, since it was clearly just Lync renamed to look like Skype, but no technical relationship between the two.
I would not count on MS suddenly 'getting it' and producing good product instead of branding exercise.
I would say they should have named it 'Lync' again. Skype for business has been the most confusing thing to talk about, because it has *zero* to do with Skype, except in the minds of MS marketing people.
As a result you can't just say 'Skype' because people won't do the right thing, you always had to say 'Skype for Business' which is a misleading mouthful.
predictability
I would say systemd could be called many things, but not that. The boot process is far less deterministic, by design. If one service takes a variable amount of time to execute, no longer does it block another so boot performance is improved as you no longer serialize a bunch of long-running service startups.. On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.
This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.
It's one thing to do software collections to yourself for the sake of getting your pet python project to work.
It's another thing to *require* a customer to do it. Software collections aren't an utterly trivial thing like 'use the python that comes with the base repo'
We have some internal use of software collections and it's not for the faint of heart. The nature of the beast is that the 'normal' python working is priority #1 for the os, and software collections have to inevitably work around that. Software collections for any httpd related stuff is even worse.
It's a simple reality:
'read me the output of systemctl status httpd' is much easier than trying to get them to grep through /var/log/httpd/ file.
In general, the move away from free-form text config and log files enables a huge number of these commands to rattle off. Commands that aren't any more capable than use of sed/grep/etc, but much much easier to tell people what to do.
Knowing use of the text utils combined with plain text things enables the text based strategies to be more discoverable and knowledge to be more generally applicable, but hard to convey that to others. Also doing things with the text strategies can lead an admin to do less robust things that will fail, so it's not entirely without justification apart from support.
I will also say that this isn't a horrible thing for those using Ubuntu or Debian. It's just that it's best to live with efforts to support RHEL being close enough to support Ubuntu for free, and some self support to bridge the gap.
Particularly from the perspective of having to support devs from *entirely different companies*, supporting folks is a pain. Over a half-dozen iterations of Ubuntu are likely, and beyond that a myriad of random ppas and random install-from-tarball or gems or pypi...
Supporting customers on CentOS/RHEL is so much easier because we generally only have to support two camps for new software: RHEL6 and RHEL7. Of course some of my python devs *hate* having to continue to be compatible with python 2.6 for the sake of our RHEL6 users, but I'd much rather have that problem than supporting the sea of direct from upstream or rapidly churning distro cut off at random arbitrary points per customer.
Note this isn't about CentOS/RHEL making the customers easier to support, but the customers that *choose* that model are a mindset that's easier to support and also more willing to spend money on getting support. If folks wonder why vendors are not as enthusiastically supporting Ubuntu and similar, this is the reason.
I think the point is pure-play open source companies. IBM nor Microsoft are anywhere near pure-play open source. Open source is largely incidental to their value proposition when it comes up.
I'd say it's both.
Churn is the enemy of the enterprise. A comfortable feeling that their staff will only need to retrain every 5 years or so, and even then it's not going to be particularly severe is important.
The businesses that are ready to push the envelope and get the latest and greatest technologies at a breakneck pace do exist. The problem being that such companies aren't interested in paying an external company like RedHat for support, they want the talent in-house. Even in theory, efforts to support such customers are expensive, each one can settle into their own cadence sticking you with the nightmare of many confusing iterations to support. Ubuntu is the current darling of this audience due to the 6 month release cycle, and one of Canonical's frustrations is that despite this strong position, they haven't been able to turn it to profit because that audience doesn't need the paid support services.
Actually, relatively speaking they pay more open source developers than other 'open source' companies.
Now there are companies that pay for more open source developers, but of the ones seeking to use Open Source as the basis of their business model rather than incidental to their mission, RHAT is ahead.
This is one of the reasons why when RHAT declares a move, the other business oriented distributions have little choice but to follow, as they lack the resources to do much.
Gnome 3: At some point RHAT realized that the desktop just doesn't matter to their business, so the engineers are pretty much free to do what they wish. That's why in RHEL7 the desktop packages are no longer so conservative as they were previously. All RHAT's revenue is on the server side, which brings us to...
systemd: Here's an example of a design that alienated a fair amount of the linux population. However, that population is folks who were interested in self supporting. Not RHAT's revenue stream. However, for those really knowing systemd inside and out, there's things in there that are easier to help support staff support *someone else*, particularly if the only convenient communication path is voice over a phone line. Sure, systemd can go off the rails and be inscrutable even to support staff, but that's when they break out 'just reinstall the thing', and honestly speaking if things are that bad and you need RHAT's support, it was going to be that bad anyway.
Brand strength, and a big customer set to start auditing and suing, as is Oracle's way.
anyone who prefers Bash as a scripting language has brain damage.
Ehh.. that really depends...
If you replace 'have a config file' with 'just source a bash script', yeah, that's not so good and one could fairly argue that the majority of init scripts were effectively this.
If you have a bash script that is hundreds of lines longs with many functions and such, then I would agree there is brain damage.
But for quick and dirty script to run a few binaries, it's much simpler than other methods. One just needs to be mindful they don't stay with bash if whatever it is promotes beyond 'quick and dirty'.
https://xkcd.com/1827/
Which is funny, since GPL means it's harder for a competitor to take your work and commercialize it without ability to enable you to compete back, and as long you you do copyright assignment, you are still free to close source if you *really* want, because the copyright holder is the only one with the right to sue for GPL violation.
So the GPL family is perfect for producing things that you don't want *other* companies to close up. Copryright assignment can be a red flag, but corporations and organizations do worse all the time.
Frankly, people that think closed source is the path to IP protection are missing out. In practice, open source doesn't inspire competition. I challenge folks to look for a single example of a company's open sourced product being turned against them into the market...
Outlook is not having problems.
Now I wouldn't go *that* far, though no particularly new problems granted.
Of course, since MS is intentionally trying to blur the line between 'Outlook the app' and 'Outlook the microsoft hosted mail service', they are asking for any negative implications.
Of course the most blatantly misguided Microsoft branding confusion award goes to 'Skype' versus 'Skype for Business' which have *zero* to do with each other.
While GPL protects the kernel form a code perspective, the practical reality and ecosystem is another matter.
If they *just* did the kernels and people by and large still sourced from distributions, then in practice a move that is bad for the community *might* result in fork and Microsoft's fork dying on the vine due to distribution disinterest.
Of course they have cozied up to RedHat, and recent history has shown that RedHat gets to call the shots in practice for every distro. So in a theoretical fork of kernel for MS versus 'traditional' Linux, there is a chance that RedHat now could throw in with a hypothetical MS fork for true technical belief or profit, though as you say GPL would mitigate the risk, though the value of a legal fork is reduced if none of the popular distributions would take them up on it because no one except RedHat will confidently step up and say "we can support a kernel".
Of course, lets consider the bigger picture. Having big influence in the kernel could hypothetically be part of a bigger strategy. Let's say that MS made a pure linux distro, and that was to start a fully compatible platform with RedHat (a la CentOS), which is free but with very credible path to full support (evidence of credible support being visibly employing core kernel developers). They also release same day with RedHat, because they have technical resources to do so, more than CentOS has. For a great deal of the business world, this could easily become *the* dominant distribution, with objections being more political and future looking than techincal ("it's the same stuff, can do the same thing, and they have developers and so they can deliver the support we need, stop saying that 'EEE' FUD crap, you're paranoid and even if it were true, we are businesses and we don't care").
After being established, they can do things that most businesses would roll with. They could replace Samba with a MS originated project (some BSD-style license, for example), which would quickly take over, because who knows SMB and AD better than Microsoft right? Samba is another troublesome GPL portion, but one they could easily replace given their position in the market.
Of course this replacement along the way could highlight their own LDAP or use OpenLDAP (BSD style license) as a base rather than 389 and whatever Kerberos they see fit. Suddenly MS 'owns' identity management for enterprise use of Linux.
If they felt particularly about GUI side, they could very likely forge a desktop offering alternative to KDE and Gnome, and successfully hide away the vast majority of user facing GPL licensed software.
Once their popular and now technically distinct product is well established, they can start skipped providing source for much of the distro (after all, the ecosystem consists of a *lot* of BSD style licensed software), providing source only for the GPL portions. Ultimately, they could even replace the kernel if they felt like it (WSL is a closed source implementation of kernel interfaces, which could double as a test run of a path to make a Linux distro with a closed source kernel).
I don't particularly think their chances in embedded are high, but I could easily believe a future where they have become *the* professional Unix-like vendor though shenanigans.