I think it boils down to a bit more focus on the common use cases.
For example, look at Active Directory. In the most common usage scenario, it's super dead easy to set up. If you start needing to do advanced things, it's a royal pain in the ass. This is the pattern for much of MS software, super simplified most-common use case, hell on earth advanced usage. The open source ecosystem tends to be easier for advanced users, but frequently never sees the 90+% use case receive adequate special treatment/optimization.
When both MS and Linux require configuration, I'd give Linux the edge. For stability, I'd say the underlying platform is pretty much the same now. It's really about good defaults in various scenarios.
Note when a recruiter uses such weird vague language, just assume you know better than they do to get to interview the technical team. If the technical team speaks in the same way, run like hell and do not look back (unless you are interviewing to take over leadership of the group, then depends on your personality).
There used to be RH branded GUI utilities that have been phased out as they basically took over GNOME and free desktop project and injected everything they wanted into those instead, for better or for worse.
Scary thing is I've interviewed candidates who claimed to have some RH training as their linux background, yet could not answer some relatively simple command line stuff. I'm assuming/hoping this was some crappy 'Linux training' class rather than any official RH curriculum...
Of course it's a fine line to walk. When a manufacturer does do something atypical, it does deserve attention, when good or bad depending on what it was. LG has released a device catering to the desire for modularity, it deserves a bit of credit. On the other hand, the possibilities described are pretty uninteresting to me, apart from maybe the swappable battery, but with fast charging, large batteries, and external batteries, I haven't really felt that need so much anymore.
On the other hand, the tech media in general tends to be generally positive on everything, gamed extensively by the vendors. So it's hard to make sense of tech media.
This is strictly true, but it also adds complexity and requires understanding beyond bash and such. For example, the output of a command may offer different stuff through pipe than you see. You have to pipe into a command to dump *all* of the data before you can think of what you can access. There's fancy polymorphic behavior in play that makes it not 'what you see is what you get'. For a software developer sort of person, the power afforded by this model is appreciated. Those same developers could however use a better language like C#, or python, or perl, etc, that provide for capabilities lacking in powershell. For a lot of admins, they don't understand software development enough and just get frustrated. bash/sed/awk/cut to them work in a way that maps directly to what they see. Yes they are limited, but they don't care. This is also a pain to a developer making a CLI wanting to make a change for cosmetic reasons, but cannot, but that's life. The biggest danger is that scripts written along this philosophy tend to be lest robust (e.g. using cut to get values, but some data has a space in it unexpectedly), so I could see the argument that someone doing automation needs to grow up into a different environment, but I just don't think powershell is the ideal I'd strive for in that scenario.
It's security theater. Any context where you can execute a powershell script, you can execute a cmd script to disable the signing policy. Malicious software that for whatever reason wants to run in powershell (there's much better vectors to run), need only preface their script with a command to disable the signing policy first.
Made even more hilarious because a cmd script can disable the signing policy. I have seen quite a few powershell scripts bundled with a cmd script to wrangle the signing policy before launching the powershell script.
In otherwords, pretty useless in the face of an adversary, but a pain for legitimate use.
For another, there is a very large amount of *nix ecosystem work in utilities that Powershell hasn't caught up to. Thanks to not invented here.
It's hard to put to words, but a lot of the same syntax things that make perl frequently hard to maintain is present in Powershell.
It's awkwardly in between the simplicity of a shell language and the power of other scripting languages. For example, most sophisticated languages have syntax for object oriented usage. For powershell, you better be off to C# for that sort of power.,
Both throughput and latency, ram is crazy fast. 4 GB/s in *theory* max for NVMe versus approx 40 GB/s for a dual channel DDR4 nowadays. Orders of magnitude better latency. You still feel swapping going to an NVMe, though not nearly as fatal.
Of course, they still make those types of laptops (though with a slightly less awesome keyboard). The modern day W520 would be a P50, 64 GB of RAM, 3 drives, 3840 x 2160 screen. The keys are somewhat textured.
Shame it's hard to try out any of these, what with brick and mortar only carrying the cheaper Lenovos.
There continues to be a wide range of keyboards, and some are serviceable, but after using my X1 carbon for months and getting thoroughly used to it, was typing on a W510 and feeling how much better it was.
However I am outright repulsed by this keyboard on an Acer I have used occasionally. Absolutely flat, trivial key travel, super slick texture.
FWIW, I downloaded git for windows and have been using the bundled environment (under the mintty terminal they provide). I like it over cygwin and/or MobaXterm as those environments try to make an island of *nix rather than map well to the general filesystem.
VMware has already been down the path of starting to neglect/retire lower cost options, and raise prices on their core products. They already were eager to have high-margin, but now the pressure is *really* on to gouge their 'captive' customer base for more money.
For a 'smallish nonprofit', you'd nearly certainly be better off with either CentOS/RH or Hyper-V, depending on your inclinations. Actually this is the particular problem Dell faces. They seem very enthusiastic about VMware, but I see vmware's position as the most tenuous. When you administer vmware, it's either through linux or, most certainly, through Windows. Your applications do not 'run on vmware', they run on some platform that you are managing. Nowadays those platforms have their own virtualization capabilities. So you can have your 'vmware and platform' skillsets or just 'platform'... Seems vmware is at risk..
Though Dell is not the biggest of players in that space, that seems like the most 'clingy' sort of customers. If you truly have outsourced your IT, it's very challenging to change your vendor, since you by definition opted not to have the in-house skills needed to be able to do that.
Compare that to any hardware/software solution, where the client retains enough in-house to be able to say 'You know what, we can switch vendors and here's what the cost picture looks like'. This includes EMC gear.
Also interesting that Dell acquired this division in 2009 for 3.9B. They lost 900 million dollars on the effort.
have test that are automatically executed by cpan before being install (make test)
most, not all. Additionally, unit tests are not going to be perfect. Particularly since it is a self-test. If they are being used in some way they don't realize, the tests may miss something. Ditto for applying the 'STABLE' moniker. A developer can go nuts and call it 'STABLE'.
Things in CPAN are just as capable as anything else at screwing up downstream users, and I have seen it bite folks. Due to longevity, things in CPAN are a bit more likely to be utterly stagnant compared to npm, which is a pretty volatile set of stuff.
It continues to be good practice to provide your dependencies alongside your code, rather than letting the end user assemble 'latest and greatest', unless your dependency is known to be maintained by an appropriately conservative entity (e.g. CentOS/et al, apart from perhaps EPEL, which can be a bit more aggressive). Beware of arbitrary ppa/copr/obs repoes as the policy behind each may be different.
Oh, I personally have found 'this' to be quite useful as it works in a number of scenarios (in the original application of futzing about with the DOM, the value of this is highly relevant). It's just an interesting example of offering multiple behaviors in different contexts. If you use an arrow expression, then this is similar to the concept as found elsewhere. If you use bind(), then this is always whatever gets bound (which can be an entirely different thing altogether).
I still maintain that as a language for operating on things inside a web browser, it's adequate, but going Node.JS is a direction of which that I personally am not a fan.
The problem being: A) It's of limited comfort if you have to support a lot of browsers, with uneven support. Less dysfunctional than it used to be, but for example a KeyboardEvent to this day won't have a 'key' attribute in most *new* Webkit/Blink browsers, despite it being around for years.
B) A lot of the syntax for new things have to settle for approaches that are compatible with existing syntax. For example, requesting strict is a bare string 'use strict' string just hanging out. Arrow expression syntax is fine for a 'lambda', but it's also a suggested strategy for making 'this' behave more like programmers coming from other languages expect,at which point it looks really clunky.
In general, I appreciate what Javascript does, but it is a bit tiring to hear a lot of people making it sound more 'all better' than it really is.
What I like to do is offer two paths to download. One via a channel like CPAN or such, and as a package repository. If someone asks 'how to run the code' I say 'add this package repository (yum/apt) that we support and maintain', and there we are strict about the dependencies, mirroring, updating, and testing them. There's a dependency that sees a major release? Good for them, they aren't in the repository until they get tested. The users of the yum/apt get priority support-wise because it's much less variation to contend with and sort out.
If a developer wants to build something themselves and grabs it from the CPAN/PyPI/whathaveyou, I let them get the 'latest and greatest' knowing that they are better enabled to cope with the risk and sort through. The hope is that they would, in turn, do the appropriate effort to make a *supportable* distribution of their project, but if they don't, it's on them rather than me.
My primary gripe with Javascript is that it really shows it was a scripting language for light use to liven up browser content a little bit, and overused from there.
It's a serviceable language, obviously, but the same factors that have Perl tempting developers to make hard to maintain code are present in Javascript (a whole slew of syntaxes for the identical thing), though it's a bit more extreme in Javascript. Also a tendency for certain functionality to look almost like an accidental behavior (e.g. 'object oriented programming' done strictly through closures). E.g. it is good practice to put your entire script into a single function (because that's the only way to have script scoped variables). If you have a function written one way, 'this' refers to your calling context, you write it another way this is more typical, as well as having your closure bind 'this' to another name (commonly 'self') or calling.bind() on your function definition to bind this to something.... Though use arrow expressions and then have people complain because it won't work in their browser.... Of course you can do nice things with it and commonality trumps having to put up with a few oddities. For some it's even a bit fun to understand the myriad approaches, but if you are trying to find some functionality, there's so many patterns that might have been used it complicates such a search.
The problem being is that they use the other repositories in the same way. Sure you *can* download and go, but overwhelmingly, people use the automated install.
Meaning that if people 'pip install' a package of mine that has a dependency, the chances are that my dependencies are such that you'll get latest of 'whatever' without verification and potentially without any test.
Either more people or at least louder people are doing this more and more. This is a problematic strategy for the same reasons a rolling-release distro is a problem. It's good to minimize the time it takes to get new shiny things, but brings significant risks.
Note there also is an annoyingly vocal camp that believes once you get '100% coverage' in unit tests and CI, your users will never have a reason to refrain from an upgrade again, so they tend to be all for this new world. Ignoring the fact that '100% coverage', while having a concrete meaning, is not as comprehensive as it sounds, and that unit tests can be just as flawed as anything else.
Long story short, we have a lot of good practices, that people have a bit *too* much faith in.
The good news, is that based on my experience, the vast majority of folks are doing things the good old stable boring way, but there's not much point in going out and advocating for 'old and boring'.
CPAN, PyPI, RubyGems, et al all encourage this behavior in a manner that enables a particular language developer.
Similarly, prolifiretaion of other enabling technologies (e.g. copr, ppa, etc repositories or dockerhub hosted images) have similar implications at different levels.
The thing is once upon a time, this was all a pain in the ass, to be tolerated until you would do the packaging all nice and neat. These rather nice things all came about because people didn't want to tolerate the pain in the ass of tracking all these dependencies just to get started, and suddenly pulling in some arbitrary library from the internet is not much more complex than a single include/import/use/whatever statement.
So far so good, until people stop using it as something to get started and/or something to get their personal setup going, and started advocating fast and loose references as a way of life for production setups and delivering to third parties. There's an assumption baked into all these setups that code only ever gets better over time, and it's best to get 'latest' no matter what (even in the face of who knows what attempts to change things, with bugs and interface changes and all).
Hard to blame them, seeing as how the IP holders have burned them in the past, with unpredictable changes.
Netflix wants control over the experience and wants to fix the problem of inconsistent experience month to month. This means in the short term it will be worse. I also don't really like the Netflix originals, but the good news is I have access through other services popping up. The bad news is they all have 'apps' rather than letting me put all of it under Kodi with a unified interface.
Now there has long been a challenge of Computer *Science* not focusing particularly on the science of computing much, but this is really a whole new low....
International will be as comprehensive as US content withers away...
The real explanation is simple, Netflix was not taken very seriously as a potential channel to displace traditional revenue channels (was seen as free money for little threat), and as Netflix proved it would displace the usual revenue channels, the content holders began being far more demanding as renewal time came around.
Slashdot Mirror
I think it boils down to a bit more focus on the common use cases.
For example, look at Active Directory. In the most common usage scenario, it's super dead easy to set up. If you start needing to do advanced things, it's a royal pain in the ass. This is the pattern for much of MS software, super simplified most-common use case, hell on earth advanced usage. The open source ecosystem tends to be easier for advanced users, but frequently never sees the 90+% use case receive adequate special treatment/optimization.
When both MS and Linux require configuration, I'd give Linux the edge. For stability, I'd say the underlying platform is pretty much the same now. It's really about good defaults in various scenarios.
Note when a recruiter uses such weird vague language, just assume you know better than they do to get to interview the technical team. If the technical team speaks in the same way, run like hell and do not look back (unless you are interviewing to take over leadership of the group, then depends on your personality).
There used to be RH branded GUI utilities that have been phased out as they basically took over GNOME and free desktop project and injected everything they wanted into those instead, for better or for worse.
Scary thing is I've interviewed candidates who claimed to have some RH training as their linux background, yet could not answer some relatively simple command line stuff. I'm assuming/hoping this was some crappy 'Linux training' class rather than any official RH curriculum...
When talking about the 'linux compatibility' they described it as 'it feels like linux because it is Linux!'
So either the person writing didn't know specifically what Linux was, or Windows 10 is secretly a Linux distro. I assume the latter.
Of course it's a fine line to walk. When a manufacturer does do something atypical, it does deserve attention, when good or bad depending on what it was. LG has released a device catering to the desire for modularity, it deserves a bit of credit. On the other hand, the possibilities described are pretty uninteresting to me, apart from maybe the swappable battery, but with fast charging, large batteries, and external batteries, I haven't really felt that need so much anymore.
On the other hand, the tech media in general tends to be generally positive on everything, gamed extensively by the vendors. So it's hard to make sense of tech media.
This is strictly true, but it also adds complexity and requires understanding beyond bash and such. For example, the output of a command may offer different stuff through pipe than you see. You have to pipe into a command to dump *all* of the data before you can think of what you can access. There's fancy polymorphic behavior in play that makes it not 'what you see is what you get'. For a software developer sort of person, the power afforded by this model is appreciated. Those same developers could however use a better language like C#, or python, or perl, etc, that provide for capabilities lacking in powershell. For a lot of admins, they don't understand software development enough and just get frustrated. bash/sed/awk/cut to them work in a way that maps directly to what they see. Yes they are limited, but they don't care. This is also a pain to a developer making a CLI wanting to make a change for cosmetic reasons, but cannot, but that's life. The biggest danger is that scripts written along this philosophy tend to be lest robust (e.g. using cut to get values, but some data has a space in it unexpectedly), so I could see the argument that someone doing automation needs to grow up into a different environment, but I just don't think powershell is the ideal I'd strive for in that scenario.
It's security theater. Any context where you can execute a powershell script, you can execute a cmd script to disable the signing policy. Malicious software that for whatever reason wants to run in powershell (there's much better vectors to run), need only preface their script with a command to disable the signing policy first.
Made even more hilarious because a cmd script can disable the signing policy. I have seen quite a few powershell scripts bundled with a cmd script to wrangle the signing policy before launching the powershell script.
In otherwords, pretty useless in the face of an adversary, but a pain for legitimate use.
For some twisted version of reasonable....
For one, it tends on being very verbose.
For another, there is a very large amount of *nix ecosystem work in utilities that Powershell hasn't caught up to. Thanks to not invented here.
It's hard to put to words, but a lot of the same syntax things that make perl frequently hard to maintain is present in Powershell.
It's awkwardly in between the simplicity of a shell language and the power of other scripting languages. For example, most sophisticated languages have syntax for object oriented usage. For powershell, you better be off to C# for that sort of power.,
Both throughput and latency, ram is crazy fast. 4 GB/s in *theory* max for NVMe versus approx 40 GB/s for a dual channel DDR4 nowadays. Orders of magnitude better latency. You still feel swapping going to an NVMe, though not nearly as fatal.
Of course, they still make those types of laptops (though with a slightly less awesome keyboard). The modern day W520 would be a P50, 64 GB of RAM, 3 drives, 3840 x 2160 screen. The keys are somewhat textured.
Shame it's hard to try out any of these, what with brick and mortar only carrying the cheaper Lenovos.
There continues to be a wide range of keyboards, and some are serviceable, but after using my X1 carbon for months and getting thoroughly used to it, was typing on a W510 and feeling how much better it was.
However I am outright repulsed by this keyboard on an Acer I have used occasionally. Absolutely flat, trivial key travel, super slick texture.
The hell you say!
FWIW, I downloaded git for windows and have been using the bundled environment (under the mintty terminal they provide). I like it over cygwin and/or MobaXterm as those environments try to make an island of *nix rather than map well to the general filesystem.
Screw cmd.exe, I start bash in mintty straight.
VMware has already been down the path of starting to neglect/retire lower cost options, and raise prices on their core products. They already were eager to have high-margin, but now the pressure is *really* on to gouge their 'captive' customer base for more money.
For a 'smallish nonprofit', you'd nearly certainly be better off with either CentOS/RH or Hyper-V, depending on your inclinations. Actually this is the particular problem Dell faces. They seem very enthusiastic about VMware, but I see vmware's position as the most tenuous. When you administer vmware, it's either through linux or, most certainly, through Windows. Your applications do not 'run on vmware', they run on some platform that you are managing. Nowadays those platforms have their own virtualization capabilities. So you can have your 'vmware and platform' skillsets or just 'platform'... Seems vmware is at risk..
Though Dell is not the biggest of players in that space, that seems like the most 'clingy' sort of customers. If you truly have outsourced your IT, it's very challenging to change your vendor, since you by definition opted not to have the in-house skills needed to be able to do that.
Compare that to any hardware/software solution, where the client retains enough in-house to be able to say 'You know what, we can switch vendors and here's what the cost picture looks like'. This includes EMC gear.
Also interesting that Dell acquired this division in 2009 for 3.9B. They lost 900 million dollars on the effort.
have test that are automatically executed by cpan before being install (make test)
most, not all. Additionally, unit tests are not going to be perfect. Particularly since it is a self-test. If they are being used in some way they don't realize, the tests may miss something. Ditto for applying the 'STABLE' moniker. A developer can go nuts and call it 'STABLE'.
Things in CPAN are just as capable as anything else at screwing up downstream users, and I have seen it bite folks. Due to longevity, things in CPAN are a bit more likely to be utterly stagnant compared to npm, which is a pretty volatile set of stuff.
It continues to be good practice to provide your dependencies alongside your code, rather than letting the end user assemble 'latest and greatest', unless your dependency is known to be maintained by an appropriately conservative entity (e.g. CentOS/et al, apart from perhaps EPEL, which can be a bit more aggressive). Beware of arbitrary ppa/copr/obs repoes as the policy behind each may be different.
Oh, I personally have found 'this' to be quite useful as it works in a number of scenarios (in the original application of futzing about with the DOM, the value of this is highly relevant). It's just an interesting example of offering multiple behaviors in different contexts. If you use an arrow expression, then this is similar to the concept as found elsewhere. If you use bind(), then this is always whatever gets bound (which can be an entirely different thing altogether).
I still maintain that as a language for operating on things inside a web browser, it's adequate, but going Node.JS is a direction of which that I personally am not a fan.
The problem being:
A) It's of limited comfort if you have to support a lot of browsers, with uneven support. Less dysfunctional than it used to be, but for example a KeyboardEvent to this day won't have a 'key' attribute in most *new* Webkit/Blink browsers, despite it being around for years.
B) A lot of the syntax for new things have to settle for approaches that are compatible with existing syntax. For example, requesting strict is a bare string 'use strict' string just hanging out. Arrow expression syntax is fine for a 'lambda', but it's also a suggested strategy for making 'this' behave more like programmers coming from other languages expect,at which point it looks really clunky.
In general, I appreciate what Javascript does, but it is a bit tiring to hear a lot of people making it sound more 'all better' than it really is.
It really depends on the real audience.
What I like to do is offer two paths to download. One via a channel like CPAN or such, and as a package repository. If someone asks 'how to run the code' I say 'add this package repository (yum/apt) that we support and maintain', and there we are strict about the dependencies, mirroring, updating, and testing them. There's a dependency that sees a major release? Good for them, they aren't in the repository until they get tested. The users of the yum/apt get priority support-wise because it's much less variation to contend with and sort out.
If a developer wants to build something themselves and grabs it from the CPAN/PyPI/whathaveyou, I let them get the 'latest and greatest' knowing that they are better enabled to cope with the risk and sort through. The hope is that they would, in turn, do the appropriate effort to make a *supportable* distribution of their project, but if they don't, it's on them rather than me.
My primary gripe with Javascript is that it really shows it was a scripting language for light use to liven up browser content a little bit, and overused from there.
It's a serviceable language, obviously, but the same factors that have Perl tempting developers to make hard to maintain code are present in Javascript (a whole slew of syntaxes for the identical thing), though it's a bit more extreme in Javascript. Also a tendency for certain functionality to look almost like an accidental behavior (e.g. 'object oriented programming' done strictly through closures). E.g. it is good practice to put your entire script into a single function (because that's the only way to have script scoped variables). If you have a function written one way, 'this' refers to your calling context, you write it another way this is more typical, as well as having your closure bind 'this' to another name (commonly 'self') or calling .bind() on your function definition to bind this to something.... Though use arrow expressions and then have people complain because it won't work in their browser.... Of course you can do nice things with it and commonality trumps having to put up with a few oddities. For some it's even a bit fun to understand the myriad approaches, but if you are trying to find some functionality, there's so many patterns that might have been used it complicates such a search.
The problem being is that they use the other repositories in the same way. Sure you *can* download and go, but overwhelmingly, people use the automated install.
Meaning that if people 'pip install' a package of mine that has a dependency, the chances are that my dependencies are such that you'll get latest of 'whatever' without verification and potentially without any test.
Either more people or at least louder people are doing this more and more. This is a problematic strategy for the same reasons a rolling-release distro is a problem. It's good to minimize the time it takes to get new shiny things, but brings significant risks.
Note there also is an annoyingly vocal camp that believes once you get '100% coverage' in unit tests and CI, your users will never have a reason to refrain from an upgrade again, so they tend to be all for this new world. Ignoring the fact that '100% coverage', while having a concrete meaning, is not as comprehensive as it sounds, and that unit tests can be just as flawed as anything else.
Long story short, we have a lot of good practices, that people have a bit *too* much faith in.
The good news, is that based on my experience, the vast majority of folks are doing things the good old stable boring way, but there's not much point in going out and advocating for 'old and boring'.
CPAN, PyPI, RubyGems, et al all encourage this behavior in a manner that enables a particular language developer.
Similarly, prolifiretaion of other enabling technologies (e.g. copr, ppa, etc repositories or dockerhub hosted images) have similar implications at different levels.
The thing is once upon a time, this was all a pain in the ass, to be tolerated until you would do the packaging all nice and neat. These rather nice things all came about because people didn't want to tolerate the pain in the ass of tracking all these dependencies just to get started, and suddenly pulling in some arbitrary library from the internet is not much more complex than a single include/import/use/whatever statement.
So far so good, until people stop using it as something to get started and/or something to get their personal setup going, and started advocating fast and loose references as a way of life for production setups and delivering to third parties. There's an assumption baked into all these setups that code only ever gets better over time, and it's best to get 'latest' no matter what (even in the face of who knows what attempts to change things, with bugs and interface changes and all).
Hard to blame them, seeing as how the IP holders have burned them in the past, with unpredictable changes.
Netflix wants control over the experience and wants to fix the problem of inconsistent experience month to month. This means in the short term it will be worse. I also don't really like the Netflix originals, but the good news is I have access through other services popping up. The bad news is they all have 'apps' rather than letting me put all of it under Kodi with a unified interface.
Now there has long been a challenge of Computer *Science* not focusing particularly on the science of computing much, but this is really a whole new low....
International will be as comprehensive as US content withers away...
The real explanation is simple, Netflix was not taken very seriously as a potential channel to displace traditional revenue channels (was seen as free money for little threat), and as Netflix proved it would displace the usual revenue channels, the content holders began being far more demanding as renewal time came around.