Re: Microsoft 10 years ago and now
Let's correct your stupidity.
1) Yes, "command line" in the sense of "DOS" or "command prompt" options in later windows releases (not the same thing), is outdated, and is crap. We'll get to why shortly...
2) That's right, they came up with Powershell. A more modern way of doing CLI based interaction - which supports many many more features than the based-on-DOS legacy of Command Prompt. Personally the ability to nest a whole set of tasks with ease and then run them over and over with ease or tweak them for the next task makes a lot of sense if you have to do the same old tasks over and over.
It's [Powershell] clearly a piece of expletive if you're clueless or lack any basic IT skillsets and can only cope with the wizards doing it all for you, as if often the case with "IT" people who aren't really properly skilled administrators (sadly the vast majority in small business IT are of this ilk), often becoming "admin" because you knew a bit more than the last person and did know something basic once and then oversold your capability. In that category generally also fall all the chimps who have no idea why a £20 switch is not the same as one costing many hundreds in suitable scenarios. However, if you adminster large systems, Powershell is a very good thing, and light years away from the command prompt or nothing options of the past. Having the same basic scripting environment to tweak windows, exchange, hyper-v, dpm, and so on is absolutely a good thing [examples picked because I work with them daily]
Your assessment that all Powershell has done is "made the the wheel square" shows how little you understand it.
3) Your next rant is also pretty broken. ACL's are in no way "broken" - and again if you know about the extended options and/or have adequate clue, you can configure a perfectly secured series of ACLs that can take advantage of the trusts, groups, policies and such making it powerful. Yes complicated potentially, but sometimes a complex scenario may be a legitimate requirement for all kinds of reasons. But it's not complex if you know what you're doing and document properly. If you just set "everyone" on everything because it's "too hard/you hate it refusing access/etc/etc/etc then I guess "security" is broken. Users ran "XP" as root because of the legacy of versions of Windows before it fundamentally where there was limited security consideration (no different to many other older non-network systems), and because developers are often lazy, or the business they work for lazy or cannot see why they should spend money writing apps to properly utilise security rules, so as a result don't work if the OS refuses to let them just write files any old place any time without question. I STILL see apps today that don't work in non-admin contexts. You're blaming the people who make the operating system, for a problem which was really down to developers. It has sadly taken a long time to educate developers and so on to do it properly. A well written application, that follows the guidelines doesn't have an issue, runs without admin rights (unless it needs such rights when it requests it).
UAC is really there as a Microsoft effort to try and help improve security because a reasonably high number of apps STILL "need" admin rights because they're STILL poorly written (and/or not updated and/or the person using the app won't get/buy/obtain an upgrade etc etc), and thus UAC attempts to boost security. I admit is is not a pretty solution and has it's own flaws, but the alternatives were worse.
Microsoft have always been "too generous" in my view in allowing old stuff to run and providing layers of compatibility that the clueless then deem "bloat" and so on - and which has sadly contributed to security issues themselves, but they've made a lot of progress. It's really about time people stopped assessing Windows XP and Server 2000/2003 (or even NT 4) as the baseline, and looked at what's happening now (you know with that 10-20 years of progress).
Biting the hand that feeds IT
