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

[Attila Kinali <attila@example.com>]

Moin,

On Mon, 07 Jun 2010 12:03:08 +0900
"Stephen J. Turnbull" <stephen@example.com> wrote:

> Attila Kinali writes:
>  > On Fri, 04 Jun 2010 01:18:00 +0900
>  > "Stephen J. Turnbull" <stephen@example.com> wrote:
> 
>  > > Well, aside from the legal liability, *if* you have moderately skilled
>  > > people, it's much easier, cheaper, and more reliable to automate
>  > > common tasks with *nix systems.
>  > 
>  > Yes it is, and no it isnt.
>  > Yes, if you know Unix, then it's quite easy and fast to automate
>  > things.
> 
> True.
> 
>  > No, it isn't 
> 
> False.
> 
>  >because hardly anyone knows Unix,
> 
> True.
> 
> 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.

This whole thing can be summerized by "even a blind hen sometimes
finds a grain of corn". The hen might survive with finding a corn
every now and then, but it will not be very successfull.

> 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?


>  > they know Unix don't know it. And if that wouldnt be enough, you'll
>  > still have the "We dont have that software available on Unix/Linux"
>  > problem.
> 
> That's the biggest advantage, though.  Mostly *that software* is not
> mission critical.

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.

>  (Your case is different, obviously.  I feel sorry
> for you, but you can't argue that a "small electronics engineering
> company" is a typical victim of Windows addiction.)

Unfortunately yes. The biggest hurdle to switch to anything else
is the EDA tool chain. If there would be a replacement that runs
on linux that doesnt cost an arm and a leg (ie that an SMB can afford)
then we could at least partially switch.

>  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.

> The real advantage of open source in this context is that you can
> kaizen it without selling your company to pay for the source license
> to Office or whatever.

You have the possibility to do that, under the condition that you
have someone who understands the code. This is not even the
case in a lot of software companies. Even in electronics companies
where you've a lot of people who do software, this is a task you
don't want to get to, because changing third party software has a
huge cost. Depending on the change needed and the quality of the
code, it can take you anything between one man-day to a man-month
for a one line change.

For example. I was once hunting for a bug in subversion a while back.
after trying to figure out how the code works for two days straight
i gave up. I just reported the error as is and hope that one of the
developers finds the bug interesting enough to fix it. And no, it is
still not fixed.
 
>  > Not to talk about the issue, that the general office worker does
>  > not know anything about Unix.
> 
> They don't need to.  You only need one toolsmith per 20 office workers
> or so.  (You can probably stretch that quite a bit if their jobs are
> pretty much identical, such as in a research university where about
> half of the clerical work is related to grant applications and
> reports, and about half of that is as standard as a U.S. tax form --
> except lacking the required "paperwork burden" notice ;-).

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. 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. 


>  > 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.
There are very few toolchains that work in the embedded
marked. And those that are comercially availbable suck
as much as the one that is available for free. At least
with the OSS one you a tad be more than what you pay for ;-)

Beside, the toolchain we use (packaged by a german guy for free)
is one of the best i've seen sofar. It works in 90% of all
cases, has a documentation that is on par with comercial products
and if i have questions, i can find people to answer them.

> Note that I'm not saying the strategy I allude to will always work.
> Just that it can be implemented, but it takes a lot of care.

certainly.

> Aside from in-company adjustments, it's also possible in many cases to
> do external adjustments.  Ie, target a market niche where tuning your
> internal processes to open source/open standards is a non-issue or
> even an advantage.

We actually do that to some extend. Everything we do is first
evaluated, whether we have already tools available for it,
if not whether there are OSS tools available. And only in
the third step, comercial tools are checked.
But software (in every sense) is not our key competence.
We are an electronics company and software is just a tool
for us to be able to sell our expertise in electronics.

> 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?
For me it reads like one of those endless repetitions of
what OSS companies are and how they can be successfull.
All with about the same arguments, repeated ever since
i entered the OSS field.

> I took a devil's advocate position (very similar to yours, that not
> everybody can do things Fremantle's way) in a discussion on the FSB
> list, but the basic thrust of his essay is correct, I think.

Well, i might sound often quite negative on what is possible in
companies with OSS, but nevertheless i'm the one pushing OSS
in the companies i work. I wouldnt be a true believer in OSS
otherwise, would i? :-)

Hmm.. maybe i should explain here a bit more how i work.
My work involves mostly doing electronics. A growing part
of that is also writing the software for the devices we build.
Where as software is mostly the one embedded in those devices
(bare metal, no OS) and very little software for the PC (ie
applications running on windows to control the device).

In our daily work, we've lots of task that can be automated to some
extend, or need small scripts to do some data processing.
Eg visualization of USB packet data and its timing for debugging
of a new device that doesnt behave as it should. I usualy do
these tasks on a linux box that i've under my desk (beside the
servers we have, the only linux machine in the whole company),
as i have all the tools i need there ready at hand w/o any 
tedious and fragile installations (like on windows).
I often end up writing shell one liners for my collegues for
their tasks. Sometimes it goes so far that i tell them to log
into my linux box and work from there, as they can use the shell
scripts directly and edit them if they need to.

This way i build a small, but steadily growing "good feeling" about
working on linux and also a kind of dependency. "i have already
a script that works on linux, i dont want to rewrite it on windows"
kind of thing.

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.

			Attila Kinali
-- 
If you want to walk fast, walk alone.
If you want to walk far, walk together.
		-- African proverb