Re: [tlug] google ditching windows and going for open source software

["Stephen J. Turnbull" <stephen@example.com>]

Attila Kinali writes:

 > > The point is, you don't need to know Unix to do a better job of
 > > automation, on at least one of the dimensions of quality and quantity.
 > > Any of shell, Python (preferred, of course), Ruby, or (in a pinch)
 > > Perl is plenty.  (Sadly enough, Emacs Lisp no longer qualifies on
 > > performance-when-working or robustness. *sigh*)
 > 
 > IMHO this view is not true. One needs an understanding of Unix to
 > successfully create automations. Yes, you can write scripts that
 > somehow work without knowing anything. Yes, they will work in your
 > current case. No, they will fail as soon as the tiniest thing changes
 > and may it be just that the last run of the script failed and left
 > a few temporary files lying around.

Sure but you're taking an extreme point of view, that the programmer
in question is a total turkey.  I'm saying that if the programmer
knows a little about Python[1], at least, they can write programs that
basically can ignore the Unix environment because Python is a
*platform* that hides Unix (but is much simpler and more regular).

As a platform, of course it's not as capable as Unix -- but for the
great majority of purposes it's just fine.

And of course there are tasks that require understanding the OS, but
hey, they require understanding the OS -- and in that case you're
talking real $$$ to get somebody with sufficient Windows-fu.

 > > Much of this could be done by web services, but they have to be much
 > > more robust than script-installed-on-workstation services.
 > 
 > I dont really see how general automations can be done with webservices.
 > Could you elaborate that a bit, please?

Huh?  I'm talking about office workflow, much of which is done *on
paper* but originates in a wordprocessor.

I'm not talking about the specialized mission-critical foo you're
talking about.

 > Yes. That's true. Though, i've seen a few SMBs here in Switzerland
 > over the last year, and each of them had one or two mission critical
 > apps for which no replacement on unix/linux was available. Most of
 > those were semi custom apps written by other SMBs.

And how many people in your company actually use those mission-
critical apps?  If it's over 50%, you're in a very small minority of
businesses.

 > Unfortunately yes. The biggest hurdle to switch to anything else
 > is the EDA tool chain.

Yes, but *Nguyen* *doesn't use the EDA toolchain*.  We're talking
about business in general (including the generally applicable business
processes that your company needs to do, too).

 > > A smart, ruthless manager would just raise wages all around (by
 > > about 25% of the productivity improvement expected ;-), and then
 > > enforce the unfamiliar but more productive environment.  "Cold
 > > turkey" works. ;-)
 > 
 > I dont get what you want to say here.

I'm talking about how to keep whats-her-name quiet, the one who said
she'd raise hell if they took her MS Office away.  See below.

 > You have the possibility to [kaizen], under the condition that you
 > have someone who understands the code.

Not necessary.  You're thinking the wrong code being kaizenned.  I'm
talking about kaizenning the *script* that talks to Open Orifice but
needs to use an API rather than a UI, so is documented not at all.
The person who wrote the script understands it.

 > This only works if you have people who are conscious enough
 > about what they do to know what can be automated and bold enough
 > to ask someone else to do it for them. IMHO the boldnes problem
 > can be solved by an approriate company culture (if you know how
 > to build one), but the real problem is the consciousnes of the
 > work at hand.

Nope.  *Both* are solved problems, at the medium to large level.
Small businesses often don't have the leisure to educate their people
in these things, but understanding business process is not rocket
science.  Any decent MBA school teaches this stuff, you can hire those
folks for less than a top software engineer (I'm not talking about
Wharton or ENA, Ohio State or London Biz will do).

 > Outside of academia and engineering, most people
 > are happy if they just have a check list how to do their work
 > and dont want to think too much about it. Any change will be
 > resisted, unless it is obvious that it will bring visible advantages
 > _and_ is easy to adapt to. 

Yes.  That's exactly why said "ruthless manager" raises wages first,
making clear what the expectations are. :-)

 > >  > But the funny thing is, that we are using Eclipse + gcc + OpenOCD for
 > >  > our cross compiling toolchain and struggle with a lot of issues because
 > >  > windows isnt a unix ^^;
 > > 
 > > See?  In the end you come back to my position.
 > 
 > This is more a question of money and availability.

So what?

 > Beside, the toolchain we use (packaged by a german guy for free)
 > is one of the best i've seen sofar.

I am not surprised.

 > > This is an interesting rather abstract point of view:
 > > 
 > > http://www.sdtimes.com/content/article.aspx?ArticleID=34351&page=4
 > 
 > What do you think is interesting about this article?

It's articulate, and it was posted years after your point of view
became joshiki.

 > IMHO this is the far better approach than any "big changes" like replacing
 > office or forcing everyone to switch to linux from one day to the next.

It's hard to make small changes in the general business area, where
people (asa you point out) know a lot less about what they're doing.

Footnotes: 
[1]  Shell is quite Unix-specific, while I don't know squat about Perl
(any more) or Ruby.  The latter two are probably fine.