[FoRK] Quarters needed for Apple to put Microsoft out of our misery?

Stephen D. Williams sdw at lig.net
Sat Jan 31 11:59:56 PST 2015


On 1/31/15 6:18 AM, Bill Kearney wrote:
> Clearly you've never utilized the tools MS has had available for more than a decade for anything other than cursory use.

Only a bit here and there, the rest was observation in corporate environments.  Almost universally, I saw people spending a lot of 
time tinkering with guis.  I have repeatedly experienced the exasperation of wanting to solve a problem, only to find that finding 
solutions was difficult, tedious, and mostly resulted in finding others who had the same exasperation.  MSDN is often terribly slow 
and irritating.  I constantly want to install Unix tools that make solving many practical problems easy.  The average time to 
solution for Unix for things I don't know how to do or forgot is measured in a small number of seconds.  Only by investing in the 
whole Microsoft ecosystem, especially the Enterprise-level tool sets as far as I could tell, do you seem to get access to all of the 
automation bits.  Or at least that's what Microsoft's literature inducing me to buy expensive enterprise management packs led me to 
believe.

>
> Because if you had you're recognize they're a damn sight more powerful and flexible than anything remotely available elsewhere.

Perhaps, but not as concise, widely available, flexible, modifiable, etc.  I doubt that they are effectively more powerful, just 
with a lot of verbose options.  The trend is toward automated, resilient software that can be tweaked but doesn't usually need to.  
Install the OS, database, web server, run this program, scaling to n nodes as needed with budget y.  We're just a few steps away 
from being able to say: Start a CompanyX-like instance in AWS (or locally on VMs on a cluster) for this domain name with this key, 
having a dozen services pop into existence in a few seconds that completely solves the scaling, routing, managing, provisioning, and 
monitoring problems in proven and standard ways.  Then you can concentrate on just writing the logic you want, having everything 
else managed and optimized mostly automatically.  Persistent legacy apps will be packaged up or provided as managed services so that 
they are simply specified as a requirement, hiding all of their complexity.  We are rapidly getting to this result.  In this world, 
operating systems have to be free, lean, totally flexible, and the most efficient to use, evolve, and maintain.  There's not even a 
hint that the Microsoft stack can handle this in a competitive way anytime soon. We're in the middle of an epic phase change, it's 
just not evenly distributed.

>
> But hey, it's more fashionable to bash MS instead of actually USING the tools.

My original point was that A) using MS stuff, Windows in particular, is more painful than it should be and B) it seems that, 
financially, Apple could buy Microsoft, and C) that would eventually improve the experience of users.  (Yes, it is very unlikely to 
happen.)  The rest of this is just debating the existence of, depth of, and a few of the reasons for the pain.  I suppose you are 
debating whether A and maybe debating whether C are true.

First, do you know Linux well?  Have you written apps, installed / maintained / customized systems?  Can you solve, in a couple 
minutes, arbitrarily complex problems with bash and at least a dozen tools plus at least one of perl/python/node?  Can you solve 
arbitrary system level problems in Windows in a few minutes?

In my experience, actually using MS tools is an inferior experience to using alternatives.  There is far more work, angst, and 
irritation at an unacceptable level just running the operating system.  There is a constant feeling of being a powerless user, a big 
contrast to using other systems.  Any tools running on top would have to be significantly better, easier, and cheaper than 
alternatives to make up for this large baseline deficit.  While there are some bright spots, the MS stack consistently fails this 
test for me, and, as far as I can tell, for everyone else too.  I don't know of any accomplished Linux/Unix admins/developers who 
prefer Windows.  I would have asked them to train me if I had.

I want to be able to do equivalent things easily on Windows, but I often want to throw up after a few minutes.  If I want to work in 
a retro environment, I'll go get my Atari 1200xl out of storage. Sometimes I need to use Windows, but I know better than to make 
that a constant thing.  More likely, I'll hire someone who doesn't experience it that way, although I generally wouldn't want to 
hire someone not Linux savvy, and I would wonder about their depth if they didn't experience angst with the Windows ecosystem.  Is 
my ideal cross-platform candidate a Linux savvy Microsoft masochist?

>
> As for scripting vs GUI, most GUI tools that emit scripts do so mainly because they lack the ability to actually do the complex 
> things needed. 

A properly architected system will use a concise, stable language or protocol of some sort to isolate the GUI from the logic of 
accomplishing key actions.  This makes sure that the gui and scripting stays in sync, directly supports auditing, allows good 
testing, etc.  Additionally, it can mean that the gui can be replaced.  This is an important architectural principle.  Any important 
system that doesn't do this is flawed.

> That last mile of user interface continues to elude a great many products. That and a great many admin tasks for which MS targets 
> their UI are not done on a repetitive nor frequent basis.  Scripts left cold tend to be problematic, mainly for being hard-coded 
> in ways opposing the growth of the systems they're targeted toward.  A GUI, on the other hand, typically bases all activities on 
> the live configuration of the systems presently in use. Better, perhaps, to have a GUI hand-holding you through something 
> less-frequently performed than a crusty, old script no longer properly configured.  There's room for both, of course, but in the 
> real world of customers that MS targets it's great to have BOTH.
>
> Yes, if you're hips-deep in the same drudgery day-in-day-out there's a kind of solace to be found in the cryptic pretense of job 
> security through obfuscated scripts.

Or knowing your way through sometimes unintuitive and almost arbitrarily deep GUI actions.

There is a way of finding your way through both guis and scripting systems.  You can have poorly designed versions of each.  At 
least with scripting, you can often make your situation better through a little programming, libraries, layering languages, etc.  A 
major part of the MS pain felt by Unix-savvy developers is that this kind of rich, powerful environment seems to be missing, 
stunted, and/or arbitrarily deviant.

It seems like there are far more developers who, in some sense, develop and develop on Unix flavors at the system level than 
Microsoft developers who develop at the system level of Windows. Every Linux admin can understand and modify things as needed that 
cannot be modified in Windows.  Microsoft seems to feel that market share, protecting revenue, or whatever means that they can and 
should invent things according to taste (or random intern whim, I can't tell sometimes) that purposefully strive to be opposite from 
widely known and accepted methods.  For instance, when thinking of what should come after CMD batch files, choosing to create 
PowerShell was a bad move for the market.  It does have some cool concepts, like structured data piping, that should be done more 
widely, but fails to come close to having a reasonable baseline. See below. [1][2]  In some ways, this seems like even more of a 
continuation of the VMS vs. Unix wars.

Properly built scripts, in a rich and stable scripting environment, are the opposite of obfuscation unless you've studiously avoided 
learning the language.  I can look at most of the machinery that runs most versions of Unix written any time in the last 30 years to 
find, understand, and modify a great many things.  Almost all of what I have learned about every Unix system I've worked on, 
starting with Version 7 in 1984, is still valid and useful daily.  The patterns are obvious, logical, and in some sense very 
stable.  It is the English of the computing world.  Recently, the whole operating system startup mechanism for Linux was replaced.  
Some people didn't like it even though it supports booting in a few seconds, but it only takes a few minutes to learn what's 
different and adapt.

That's not to say that there aren't plenty of areas for innovation, which happens at different levels all the time.  I've been 
kicking around some ideas beyond text-based pipelining for instance.  But it would fit easily into the ecosystem.

Microsoft's systems, including the operating system services, are a mishmash of mostly hidden mechanism that require mountains of 
shifting knowledge to understand in detail, let alone influence in the ways anticipated by the authors.  The philosophies are quite 
different, leading to wide differences in flexibility and efficiency.  Is it much better now?  Has Windows 10 cleaned things up like 
registry hell and apps hooking each other abusively?

Interesting links and comments because I was curious to get an update:
[1] Modern, practical, and funny take on Windows scripting:
https://macyves.wordpress.com/2014/09/18/hipsterising-windows-cygwin-vs-babun-vs-git-bash-vs-powershell-the-onion-scale/
>
> It is clear with Azure that Microsoft is adopting a tool chaining strategy based on Git and other useful terminal tools. Gone are 
> the days of drawing pretty boxes in a CASE tool and expect the stuff you cooked up in thin air to be high performance, scalable 
> and easily provisioned through cloud providers. The first step is get yourself tools that can actually help your everyday devops 
> life. Hark! let us hipsterise Windows and bring on the terminals!
>
> So if you take pride in your .dotfiles <https://macyves.wordpress.com/2014/04/01/dotfiles-and-java-ninjutsu/>, git-foo and devops 
> craftsmanship, but got stuck navigating the treacherous GUI waters of Redmond county, then this is for you. This blog post aims to 
> be an opinionated and cynical evaluation of 4 major terminal options available in Windows for running Git and other common 
> everyday *NIX tools. The scale are in unit of Onions, because you will be weeping when you start working on these abominations. 
> Command Prompt did not make the list. It died with DOS 6.22.
>
>
>       tl;dr
>
> Use Mac or Linux. Save yourself while you can. If you absolutely cannot avoid using Windows as the main platform, or unable to run 
> it through Virtualbox, then install Babun <https://github.com/babun/babun>; though the experience is no where near the level of 
> “epic unicorns riding waves of candy rainbow”, it is still very solid. Be prepared to deal with stuff like BLODA 
> <https://cygwin.com/faq/faq.html#faq.using.bloda> (Big List of Dodgy Apps), you’ll question the existence of antivirus as a 
> marketing and vendor lock-in strategy, and really get some hands-on practicing copious amounts of “let me reboot my laptop to see 
> if it fixes the problems. Oh it did.” Start rubbing your ears and say “Wooooosa”, and remember the fault is not with Babun, but 
> with Windows.
>

[2] Dated, but interesting comparisons of PowerShell and bash et al:
https://news.ycombinator.com/item?id=4238696
>
> bash is easier to use; writing ad-hoc pipes etc. in PowerShell has never seemed pleasant to me, the commands are verbose and the 
> contractions non-obvious; getting help is tedious, and options are often very long.
>
> * Object orientation works well when you're dealing with meaningful objects. But often you just want to deal with a singular list 
> of items, and it can make things more awkward. It's a bit like the OO - relational dichotomy.
>
> * Interaction between PowerShell and Unix utilities is very clunky, because by default PowerShell will include column headers and 
> formatting characters as part of the output. Something else that's unpleasant: PowerShell doesn't have a simple mode that can work 
> well inside a terminal. I mean, just running PowerShell inside Cygwin mintty results in a copyright notice and an apparantly hung 
> program. That's because it's using ReadConsole rather than ReadFile for I/O, but ReadConsole only works in Windows' horrible 
> console windows. You can work around it with 'powershell -', but then you don't get a prompt. Similarly, running a PowerShell 
> script requires echoing a return character to the PowerShell process to get it to exit! Literally: "echo | powershell -file 
> <script file>". It's a bit ridiculous.
>
> Powershell doesn't really feel like a shell to me. It's more like a SQL query command line and scripting language REPL hybrid. For 
> example, something as basic as job control is almost non-existent. Forget about carefree application of '&' and 'wait'; that style 
> of working, doesn't.

> ajross 932 days ago | link
>
> I think this is basically right. PowerShell is what you'd get if you started writing "the perfect shell" from scratch. But 
> comparing to bash in isolation is sort of missing the point. Everything in unix is designed to work in the shell, and that's not 
> true in windows.
>
> So you have tools like ssh and nc and curl at hand, designed to feed each other via pipes and do one thing well. Want to push a 
> file to a server behind a VPN when all I have is ssh access to a host on the network? Trivial. On windows? No clue. It's not a 
> shell problem.
>
> -----
>
>
> davidacoder 932 days ago | link
>
> Copying files is an excellent issue: at some point I suggested either on the PowerShell blog or their feedback site that 
> PowerShell should have the ability to copy files via remoting (essentially what you mention, you can remote into a box via 
> powershell and need to copy a file from your local machine onto the remote box).
>
> The response I got from someone at MS was quite telling, it went something like "please tell me more why you would ever want to do 
> this, when we have existing folder sharing technology in windows". I gave up, if they seriously don't understand why that is NOT 
> the answer to situation, gee...


sdw



More information about the FoRK mailing list