A while ago I mentioned the our company that I work for, runs some
proprietary homegrown apps some of which are quite demanding on both
CPU and network.

They were running on windows.

At some point we started having big performance problems with them and
started running out of datacenter rack space also due to needing to
have a lot of computers.

We were lucky since we tried to keep our apps away from using
Microsoft specific libraries and so on. So we tried running these apps
on linux.

They ran much better.

We started moving this stuff to Linux and reorganized things by making
everything much more scriptable. In fact, these servers are set up b
yplopping in a custom disk and running the disk. Usually all that the
installer has to specify is the hostname. They all run the same
scripts, self update, etc. I manage them, but I never have to go to
all of them one after another and do some manual stuff like clicking
icons and **** like that. There is about 30+ servers, not really
taking much of my time any more.

The end result of improving performance was that we could combine
approximately 5 windows servers into one linux server. We started off
with about 100 Windows servers and ended with about 20 active linux
servers. (the remaining ones adding to 30+ are things like hot spares
and boxes waiting for their turn to be used etc).

We actually use those underutilized ones as compile servers.Thus,
libraries that would take 20 minutes to compile under Windows, would
take only under 2 minutes to compile with Linux. (windows is not
capable of parallel compiles due to issues with PDB files and so on)

So the end result is that all our server side stuff is running on
Linux, so some of our developers who were developing on Windows only,
are now slowly going into Linux also.

Because we reduced the number of servers, we are no longer running out
of rackpspace.

Due to much improved scripting, our production support people are also
able to do a lot less. I have extensive experience with Windows
scripting and it cannot compare due to various Windows nonsense.

Altogether, the efforts to maintain those linux boxes and their
software (including our software) are many times less than that
required for Windows, plus no performance issues. Changes can be
rolled out in minutes. Scripts make a lot less mistakes than humans,
etc.

So, as a final tally I think that everyone is very happy about this
move. The windows centered computer administrators were apprehensive
in the beginning, but now they see it as less work. Plus people with
Linux on resumes are paid 15-20% more, according to Microsoft, so they
like this aspect.
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
[url]http://improve-usenet.org/[/url]

10-31-2008, 09:45 PM

unix

Re: My employer completed migration of apps to Linux

Ignoramus27079 wrote:
[color=blue]
> A while ago I mentioned the our company that I work for, runs some
> proprietary homegrown apps some of which are quite demanding on both
> CPU and network.
>
> They were running on windows.
>
> At some point we started having big performance problems with them and
> started running out of datacenter rack space also due to needing to
> have a lot of computers.
>
> We were lucky since we tried to keep our apps away from using
> Microsoft specific libraries and so on. So we tried running these apps
> on linux.
>
> They ran much better.
>
> We started moving this stuff to Linux and reorganized things by making
> everything much more scriptable. In fact, these servers are set up b
> yplopping in a custom disk and running the disk. Usually all that the
> installer has to specify is the hostname. They all run the same
> scripts, self update, etc. I manage them, but I never have to go to
> all of them one after another and do some manual stuff like clicking
> icons and **** like that. There is about 30+ servers, not really
> taking much of my time any more.
>
> The end result of improving performance was that we could combine
> approximately 5 windows servers into one linux server. We started off
> with about 100 Windows servers and ended with about 20 active linux
> servers. (the remaining ones adding to 30+ are things like hot spares
> and boxes waiting for their turn to be used etc).
>
> We actually use those underutilized ones as compile servers.Thus,
> libraries that would take 20 minutes to compile under Windows, would
> take only under 2 minutes to compile with Linux. (windows is not
> capable of parallel compiles due to issues with PDB files and so on)
>
> So the end result is that all our server side stuff is running on
> Linux, so some of our developers who were developing on Windows only,
> are now slowly going into Linux also.
>
> Because we reduced the number of servers, we are no longer running out
> of rackpspace.
>
> Due to much improved scripting, our production support people are also
> able to do a lot less. I have extensive experience with Windows
> scripting and it cannot compare due to various Windows nonsense.
>
> Altogether, the efforts to maintain those linux boxes and their
> software (including our software) are many times less than that
> required for Windows, plus no performance issues. Changes can be
> rolled out in minutes. Scripts make a lot less mistakes than humans,
> etc.
>
> So, as a final tally I think that everyone is very happy about this
> move. The windows centered computer administrators were apprehensive
> in the beginning, but now they see it as less work. Plus people with
> Linux on resumes are paid 15-20% more, according to Microsoft, so they
> like this aspect.[/color]

Sounds like a good success story. Congratulations!

Now, if you virtualized all those Linux servers you could reduce your
hardware to two (2) physical servers and retain the same performance
levels.

Thank you.
[color=blue]
> Now, if you virtualized all those Linux servers you could reduce your
> hardware to two (2) physical servers and retain the same performance
> levels.[/color]

I would like to respectfully disagree. In our case, I see no reason
for virtualization. Our apps coexist very well without
virtualization. (they used not to, but we fixed it) They use quite a
bit of CPU and cannot be possibly moved to two physical servers as
there would not be enough CPU.

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
[url]http://improve-usenet.org/[/url]

11-01-2008, 08:53 AM

unix

Re: My employer completed migration of apps to Linux

On Fri, 31 Oct 2008 23:03:52 -0500
Ignoramus27079 <ignoramus27079@NOSPAM.27079.invalid> wrote:
[color=blue]
> I would like to respectfully disagree. In our case, I see no reason
> for virtualization. Our apps coexist very well without
> virtualization. (they used not to, but we fixed it) They use quite a
> bit of CPU and cannot be possibly moved to two physical servers as
> there would not be enough CPU.[/color]

Well, that depends... if you're on a dual processor 32-core system
with several tens or hundreds of GB of RAM, virtualization might be
possible and efficient... <g>

--- Mike

--
My sigfile ran away and is on hiatus.
[url]http://www.trausch.us/[/url]

11-01-2008, 08:05 PM

unix

Re: My employer completed migration of apps to Linux

On Fri, 31 Oct 2008 16:30:49 -0500, Ignoramus27079 wrote:

Interesting. You seem to live up to your name. See below:
[color=blue]
> We were lucky since we tried to keep our apps away from using
> Microsoft specific libraries and so on. So we tried running these apps
> on linux.
>
> They ran much better.[/color]

Wow, that's real ambiguous.
[color=blue]
> We actually use those underutilized ones as compile servers.Thus,
> libraries that would take 20 minutes to compile under Windows, would
> take only under 2 minutes to compile with Linux. (windows is not
> capable of parallel compiles due to issues with PDB files and so on)[/color]

This is patently false. Windows has had parallel compiling for years. The
Command line has had options for it, but as of Visual Studio 2005 so does
MSBuild.

etc.. etc..
[color=blue]
> Because we reduced the number of servers, we are no longer running out
> of rackpspace.[/color]

I highly doubt this vague, nebulous "runs better" comment. Esepcially
since you don't even bother to mention what environments you're using, what
tools you're using, what the apps do, etc..
[color=blue]
> Due to much improved scripting, our production support people are also
> able to do a lot less. I have extensive experience with Windows
> scripting and it cannot compare due to various Windows nonsense.[/color]

Also utter BS. The single most advanced scripting environment available
for general purpose computers is PowerShell. It blows the doors of any
other scripting environment out there.

Sounds more like you're either ignorant (thus your name) or lying or maybe
both.
[color=blue]
> Altogether, the efforts to maintain those linux boxes and their
> software (including our software) are many times less than that
> required for Windows, plus no performance issues. Changes can be
> rolled out in minutes. Scripts make a lot less mistakes than humans,
> etc.[/color]

And somehow you managed to retrain all your developers without any loss of
productivity or migration issues. Yeah, right. If what you say is true,
you have the single most amazing development staff on the planet.
[color=blue]
> So, as a final tally I think that everyone is very happy about this
> move. The windows centered computer administrators were apprehensive
> in the beginning, but now they see it as less work. Plus people with
> Linux on resumes are paid 15-20% more, according to Microsoft, so they
> like this aspect.[/color]

Wow, not only are the amazing, they're also entirely even headed without
any prejudices or predisposions. They don't care that their entire
skillsets are suddenly being dumped and they have to relearn everything.

I've never met a group of developers like that. You have quite a
(ficticious) team there.

11-01-2008, 10:10 PM

unix

Re: My employer completed migration of apps to Linux

"Erik Funkenbusch" <erik@despam-funkenbusch.com> wrote in message
news:1er766k0amq90$.dlg@funkenbusch.com...
[color=blue]
> Also utter BS. The single most advanced scripting environment available
> for general purpose computers is PowerShell. It blows the doors of any
> other scripting environment out there.[/color]

When I hit this I knew your post was BS.

God, it took Microsoft this long to figure out the power of a shell after
how many years? And it is better than anything else?

Hahahaha.... You also must be a MVP, Microsoft Vista Pusher too. Go an play
in the vista group or something, it is more your speed.

---------
MS Windows for boys
X Windows for men

11-01-2008, 11:24 PM

unix

Re: My employer completed migration of apps to Linux

On Sat, 1 Nov 2008 16:10:32 -0600, Canuck57 wrote:
[color=blue]
> "Erik Funkenbusch" <erik@despam-funkenbusch.com> wrote in message
> news:1er766k0amq90$.dlg@funkenbusch.com...
>[color=green]
>> Also utter BS. The single most advanced scripting environment available
>> for general purpose computers is PowerShell. It blows the doors of any
>> other scripting environment out there.[/color]
>
> When I hit this I knew your post was BS.
>
> God, it took Microsoft this long to figure out the power of a shell after
> how many years? And it is better than anything else?
>
> Hahahaha.... You also must be a MVP, Microsoft Vista Pusher too. Go an play
> in the vista group or something, it is more your speed.[/color]

After takin' a swig o' grog, Erik Funkenbusch belched out
this bit o' wisdom:
[color=blue]
> Also utter BS. The single most advanced scripting environment available
> for general purpose computers is PowerShell. It blows the doors of any
> other scripting environment out there.[/color]

You crack me up. It might be able to fill in a greater number of feature
check-boxes, *on Windows only*.

So tell us, Erik, what Powershell has the Perl, Python, Ruby, bash, and zsh
don't have?

An extension repository such as CPAN? Numerical libraries like Python?

Looking at this feature matrix, it looks comparable to zsh, Python and Ruby.

Blows the doors off of any other scripting environment out there? Sounds
like you're drooling again. It's a Windows-only tool.

--
I'm successful because I'm lucky. The harder I work, the luckier I get.

11-02-2008, 01:32 AM

unix

Re: My employer completed migration of apps to Linux

On Sat, 1 Nov 2008 20:45:55 -0400, Chris Ahlstrom wrote:
[color=blue]
> After takin' a swig o' grog, Erik Funkenbusch belched out
> this bit o' wisdom:
>[color=green]
>> Also utter BS. The single most advanced scripting environment available
>> for general purpose computers is PowerShell. It blows the doors of any
>> other scripting environment out there.[/color]
>
> You crack me up. It might be able to fill in a greater number of feature
> check-boxes, *on Windows only*.[/color]

Actually, you are mixing shells with scripting languages. They're two
different things, though shells do have scripting languages in them (often
quite capable, but limited.. which is why full blown scripting languages
exist)

Also, you can use Perl, Python, Ruby, C#, VB, Eiffel, or any of the dozens
of other .NET languages with Powershell as well.

The thing that makes Powershell so.. well.. powerful is it's universal
binding system (comparable at a certain level to the old Amiga ARexx
system) as well as it's object oriented nature. Powershell can use objects
from any .NET compiled library.

While the actual shell window itself is pretty crude, there are several
replacements such as:

[url]http://sourceforge.net/projects/console/[/url]

Here's a quick example of something I don't think you can do with bash.
You can set your prompt to a function call. So, suppose you want your
prompt to reflect the status of a server. You can have your prompt call a
function that determines this in real-time.

Certianly, there are ways you could achieve that under bash, such as having
your server set a global environt variable or file, but that would not be a
real-time interactive facility.

Another example, Powershell understands XML, and since it can use the .NET
framework natively, i can do something like get all the headlines from the
slashdot RSS feed with one line of code.

You can use all of them.
[color=blue]
> Looking at this feature matrix, it looks comparable to zsh, Python and Ruby.
>
> Blows the doors off of any other scripting environment out there? Sounds
> like you're drooling again. It's a Windows-only tool.[/color]

If your only requirement is cross platform capability, then maybe you've
got a point. Personally, I don't care, i'd rather use the best tool for
the job on any given platform.

11-02-2008, 03:12 AM

unix

Re: My employer completed migration of apps to Linux

On Sat, 1 Nov 2008 19:24:17 -0400, Erik Funkenbusch wrote:
[color=blue]
> On Sat, 1 Nov 2008 16:10:32 -0600, Canuck57 wrote:
>[color=green]
>> "Erik Funkenbusch" <erik@despam-funkenbusch.com> wrote in message
>> news:1er766k0amq90$.dlg@funkenbusch.com...
>>[color=darkred]
>>> Also utter BS. The single most advanced scripting environment available
>>> for general purpose computers is PowerShell. It blows the doors of any
>>> other scripting environment out there.[/color]
>>
>> When I hit this I knew your post was BS.
>>
>> God, it took Microsoft this long to figure out the power of a shell after
>> how many years? And it is better than anything else?
>>
>> Hahahaha.... You also must be a MVP, Microsoft Vista Pusher too. Go an play
>> in the vista group or something, it is more your speed.[/color]
>
> I notice you have absolutely zero technical arguments to dispute me.
>
> And powershell is not new, it's been around for a few years now.[/color]

Hahah!
You took him apart and it's obvious from the lack of specific, technical
comments that the others, like Terry "Telnet" Porter posted.

Good job!

--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
[url]http://linuxidiots.blogspot.com/[/url]

11-02-2008, 05:46 AM

unix

Re: My employer completed migration of apps to Linux

On 2008-11-01, Erik Funkenbusch <erik@despam-funkenbusch.com> wrote:[color=blue]
> On Fri, 31 Oct 2008 16:30:49 -0500, Ignoramus27079 wrote:
>
> Interesting. You seem to live up to your name. See below:
>[color=green]
>> We were lucky since we tried to keep our apps away from using
>> Microsoft specific libraries and so on. So we tried running these apps
>> on linux.
>>
>> They ran much better.[/color]
>
> Wow, that's real ambiguous.[/color]

I can try to clarify. I may be missing some things because I am drunk
at the moment. In any case, the problems we had were with apps that
would talk a lot on the network and/or write to a lot of files. The
windows computer would be busy in kernel (say 60% busy) and not able
to do that much, have timeouts etc. If we move same app to Linux, it
would coolly run with the machine 95% idle. (as it should).

[color=blue][color=green]
>> We actually use those underutilized ones as compile servers.Thus,
>> libraries that would take 20 minutes to compile under Windows, would
>> take only under 2 minutes to compile with Linux. (windows is not
>> capable of parallel compiles due to issues with PDB files and so on)[/color]
>
> This is patently false. Windows has had parallel compiling for years. The
> Command line has had options for it, but as of Visual Studio 2005 so does
> MSBuild.[/color]

What we had was that all CL.EXE needed to access the same .PDB file,
so we could not run more than one at a time.

The parallel compile feature that I am referring to, goes beyond
paralleling compile on one machine. It is called "distcc" (look up its
man page if you would like) and it lets you distribute compiles across
many machines. Since we usually have plenty of machines doing nothing,
it is helpful.

So, a compile of a big library that would take 20 minutes under
Windows, would take 1.5 minutes under parallel compile in Linux.

This is a big productivity improvement.

[color=blue]
> [url]http://blogs.msdn.com/windows_installer_team/archive/2005/07/18/442753.aspx[/url]
> [url]http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx[/url]
> [url]http://vagus.wordpress.com/2008/02/15/source-level-parallel-build-in-visual-studio-2005/[/url]
>
> etc.. etc..
>[color=green]
>> Because we reduced the number of servers, we are no longer running out
>> of rackpspace.[/color]
>
> I highly doubt this vague, nebulous "runs better" comment. Esepcially
> since you don't even bother to mention what environments you're using, what
> tools you're using, what the apps do, etc..[/color]

Windows XP and Windows Server 2003, vs. Fedora and Ubuntu. I described
performance issues in a previous paragraph.
[color=blue][color=green]
>> Due to much improved scripting, our production support people are also
>> able to do a lot less. I have extensive experience with Windows
>> scripting and it cannot compare due to various Windows nonsense.[/color]
>
> Also utter BS. The single most advanced scripting environment available
> for general purpose computers is PowerShell. It blows the doors of any
> other scripting environment out there.
>
> Sounds more like you're either ignorant (thus your name) or lying or maybe
> both.[/color]

I know almost nothing about powershell and not about to embark on
learning it, but I would not use a Windows only solution in any
case. Bash, at least, is available anywhere, and though Windows gives
it challenges, at least it works and has years of development behind
it. Same applies to perl.

What I have seen about powershell is that it is some sort of a gimmick
that looks nice but has not been used for anything.
[color=blue][color=green]
>> Altogether, the efforts to maintain those linux boxes and their
>> software (including our software) are many times less than that
>> required for Windows, plus no performance issues. Changes can be
>> rolled out in minutes. Scripts make a lot less mistakes than humans,
>> etc.[/color]
>
> And somehow you managed to retrain all your developers without any
> loss of productivity or migration issues. Yeah, right. If what you
> say is true, you have the single most amazing development staff on
> the planet.[/color]

We generally do make a conscious effort not to hire stupid people.

However, we did not retrain developers, as much as we tried to stay
posix compliant in our programming. If a program says fopen, connect,
select etc, it can usually run well under both platforms without too
much effort. It is when you start using proprietary "features" like
that powershell, or MFC, then you are stuck with a platform.

We are not stuck with Linux either and our programs can run on
Windows, and could probably be ported to FreeBSD without too much
trouble.

[color=blue][color=green]
>> So, as a final tally I think that everyone is very happy about this
>> move. The windows centered computer administrators were apprehensive
>> in the beginning, but now they see it as less work. Plus people with
>> Linux on resumes are paid 15-20% more, according to Microsoft, so they
>> like this aspect.[/color]
>
> Wow, not only are the amazing, they're also entirely even headed
> without any prejudices or predisposions. They don't care that their
> entire skillsets are suddenly being dumped and they have to relearn
> everything.[/color]

Depends on what you mean by a skillset. An app is an app. If it has
to, say, read a file and ask some server about something, and then
send a few messages, a developer's "skillset" lets them do it under
any OS.

In the end, I think, it will come to people learning something new,
such as how to write scripts that do their work instead of mouse
clicking.
[color=blue]
> I've never met a group of developers like that. You have quite a
> (ficticious) team there.[/color]

Just some real life. If you were in Chicago area, you could stop by my
house and I would show you how this stuff running, remotely, without
disclosing anything propetary or giving you physical access to work
etc.

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
[url]http://improve-usenet.org/[/url]

Why does he have to defend his choice as Linux is obviously
working for him? Is it a crime not to use windows?

It looks to me like you are trying to say that...

Seems to me like you are a arrogant (and maybe paid?)
windows user trying to bash a Linux user for his (also in my
opinion) good choice. Now - go home to your beloved Richmond
an go play with the other brainless guys over there...

11-02-2008, 08:08 AM

unix

Re: My employer completed migration of apps to Linux

On Sun, 02 Nov 2008 00:46:36 -0500, Ignoramus10571 wrote:
[color=blue]
> I can try to clarify. I may be missing some things because I am drunk
> at the moment. In any case, the problems we had were with apps that
> would talk a lot on the network and/or write to a lot of files. The
> windows computer would be busy in kernel (say 60% busy) and not able
> to do that much, have timeouts etc. If we move same app to Linux, it
> would coolly run with the machine 95% idle. (as it should).[/color]

I think i understand your problem. You chose to use portable code to write
your apps, which is fine, but not very performant on Windows. If you're
doing heavy duty network and file I/O you're much better off using
threading and async I/O rather than standard C functions.

The problem is that standard C functions do not map well to the Windows
Async API's. The same is true of using Async API's under Linux or Mac. If
you want the best performance on any platform, you have to ditch portable
API's and use the platform specific stuff.

Linux, as it so happens, is much more oriented around standard C file I/O,
so this maps well, and works a lot better (although you'd get better
performance by using platform specific AIO functions). Under Windows, the
standard C functions are wrappers and have a lot of intermediate bloat to
massage them into something that Windows can understand.

The fact of the matter is, if you want to write apps in a Unix way, you're
better off running them on Linux. It's no surprise they 'work better'
because you're trying to make a square peg fit into a round hole.
[color=blue][color=green]
>> This is patently false. Windows has had parallel compiling for years. The
>> Command line has had options for it, but as of Visual Studio 2005 so does
>> MSBuild.[/color]
>
> What we had was that all CL.EXE needed to access the same .PDB file,
> so we could not run more than one at a time.
>
> The parallel compile feature that I am referring to, goes beyond
> paralleling compile on one machine. It is called "distcc" (look up its
> man page if you would like) and it lets you distribute compiles across
> many machines. Since we usually have plenty of machines doing nothing,
> it is helpful.
>
> So, a compile of a big library that would take 20 minutes under
> Windows, would take 1.5 minutes under parallel compile in Linux.
>
> This is a big productivity improvement.[/color]

That doesn't make a lot of sense. I don't have any experience with
distributed builds, but a quick search finds some tools that handle it,
even with Visual Studio. For instance KJam and Incredibuild.

In particular, the Incredibuld faq talks about how seperate PDB files are
generated on each distributed build server, etc.. There are some settings
which can conflict with this, but it seems to indicate that this isn't
generally a problem.
[color=blue]
> I know almost nothing about powershell and not about to embark on
> learning it[/color]

Instead you decided to learn bash and python and perl and a number of other
technologies (or forced your developers to do so). In either case you're
going to have a learning curve, so you can't use learning curve as an
excuse.
[color=blue]
> but I would not use a Windows only solution in any case.[/color]

Of course, because that would conflict with your prejudices.
[color=blue]
> Bash, at least, is available anywhere, and though Windows gives
> it challenges, at least it works and has years of development behind
> it. Same applies to perl.[/color]

The point remains, if you want the best performance, you might have to step
outside generic functionality.
[color=blue]
> What I have seen about powershell is that it is some sort of a gimmick
> that looks nice but has not been used for anything.[/color]

It's no gimmick. And it's already used for a lot, for instance, Exchange
2007 requires it for maintenance and provides it's own Exchange sub-shell.
[color=blue]
> However, we did not retrain developers, as much as we tried to stay
> posix compliant in our programming. If a program says fopen, connect,
> select etc, it can usually run well under both platforms without too
> much effort. It is when you start using proprietary "features" like
> that powershell, or MFC, then you are stuck with a platform.[/color]

And thus your problem. You did not use Windows in the way it's designed to
be used, and instead decided to do high volume high intensive tasks with
generic API's. Yes, Posix stuff will work on Windows, but you're going to
lose performance. You would have been better off running it under Services
for Unix, i think you would have gotten far better performance.
[color=blue]
> We are not stuck with Linux either and our programs can run on
> Windows, and could probably be ported to FreeBSD without too much
> trouble.[/color]

As I said, since you want to write Unix programs for Windows, you might as
well just run them on Unix.

I think the thickness is on yours. You've just succinctly stated my point.

He had a pre existing prejudice against Windows, and he seemed to
deliberately engineer his solutions in ways that would make them perform
worse on Windows.
[color=blue]
> Why does he have to defend his choice as Linux is obviously
> working for him? Is it a crime not to use windows?[/color]

Of course not, but don't claim Linux is "better" when you didn't use
Windows in the way it was designed to be used. It's like someone claiming
they tried to use Linux for their apps (running under Wine) and that things
just work better under Windows.

That's not the fault of Linux (though it may be partially the fault of
Wine).
[color=blue]
> It looks to me like you are trying to say that...[/color]

That's because you can't seem to understand the point.
[color=blue]
> Seems to me like you are a arrogant (and maybe paid?)
> windows user trying to bash a Linux user for his (also in my
> opinion) good choice. Now - go home to your beloved Richmond
> an go play with the other brainless guys over there...[/color]

Yes, of course. Why is it whenever peoples conceptions are challenged,
they immediately start calling people paid shills? Talk about "arrogance"
to believe that you matter so much to a company like Microsoft that they
would pay people to argue with you.

You can "doubt" all you like. Without exception, /all/ /our/ hardware runs
better /without/ the overhead, instability and insecurity of Windoze.
[color=blue]
> Esepcially since you don't even bother to mention what environments you're
> using, what tools you're using, what the apps do, etc..[/color]

All of which are probably commercially sensitive - I certainly wouldn't tell
the world at large about what my company does with its computers.
[color=blue][color=green]
>> Due to much improved scripting, our production support people are also
>> able to do a lot less.[/color]
>
> Also utter BS. The single most advanced scripting environment available
> for general purpose computers is PowerShell. It blows the doors of any
> other scripting environment out there.[/color]

*Wrong*
[color=blue][color=green]
>> Altogether, the efforts to maintain those linux boxes and their
>> software (including our software) are many times less than that
>> required for Windows, plus no performance issues. Changes can be
>> rolled out in minutes. Scripts make a lot less mistakes than humans,
>> etc.[/color]
>
> And somehow you managed to retrain all your developers without any loss of
> productivity or migration issues. Yeah, right. If what you say is true,
> you have the single most amazing development staff on the planet.[/color]

My company was in a similar situation a few years ago. The developers were
given the opportunity before the migration to retrain. Those who did
continued in employment with us, those who refused (and there were a few)
were "let go" because their skills were no longer appropriate for our working
environment.
[color=blue]
> Wow, not only are the amazing, they're also entirely even headed without
> any prejudices or predisposions. They don't care that their entire
> skillsets are suddenly being dumped and they have to relearn everything.[/color]

Anybody with real programming ability can relearn their "skillsets" quite
quickly. Our better developers and system administrators were entirely happy
to relearn "everything", because they recognised the advantages and the
improvements that came with the migration. The ones who weren't interested
were not of any use so no longer had jobs. It's a simple HR problem to
resolve, particularly if their contracts include a clause that /demands/
continual training updates.
[color=blue]
> I've never met a group of developers like that.[/color]

You're obviously working amongst a bunch of useless "Microsoft Certified"
morons. Microsoft "qualifications" are entirely worthless today, and we
don't bother to hire anyone who brandishes such bogus crap at interview.

C.

11-02-2008, 09:13 AM

unix

Re: My employer completed migration of apps to Linux

Erik Funkenbusch <erik@despam-funkenbusch.com> writes:
[color=blue]
> On Sat, 1 Nov 2008 16:10:32 -0600, Canuck57 wrote:
>[color=green]
>> "Erik Funkenbusch" <erik@despam-funkenbusch.com> wrote in message
>> news:1er766k0amq90$.dlg@funkenbusch.com...
>>[color=darkred]
>>> Also utter BS. The single most advanced scripting environment available
>>> for general purpose computers is PowerShell. It blows the doors of any
>>> other scripting environment out there.[/color]
>>
>> When I hit this I knew your post was BS.
>>
>> God, it took Microsoft this long to figure out the power of a shell after
>> how many years? And it is better than anything else?
>>
>> Hahahaha.... You also must be a MVP, Microsoft Vista Pusher too. Go an play
>> in the vista group or something, it is more your speed.[/color]
>
> I notice you have absolutely zero technical arguments to dispute me.
>[/color]
Well, since you brought no arguments to begin with, it's rather hard
to dispute you with arguments, right?

He who states a thing has to prove it, so why don't *you* produce
arguments as to why PowerShell is the most advavnced scripting
environment out there?

On Sun, 02 Nov 2008 08:58:28 +0000
Christopher Hunter <cehunter@invalid.inv> wrote:
[color=blue][color=green]
> > It's like someone claiming they tried to use Linux for their apps
> > (running under Wine) and that things just work better under
> > Windows.[/color]
>
> Bizarrely, a recent Windows port of an app that I wrote ran /much/
> better under Wine than it did on Windows XP![/color]

Indeed, on my system, I can play Guild Wars on Ubuntu and it runs
better under Wine than XP. Note that it depends on the version of Wine
and the exact configuration---some tweaking is necessary here and
there---but GW tends to be more responsive. I am going to wager that
at least _part_ of it is due to more efficient caching of disks, since
GW is so I/O intensive.

--- Mike

--
My sigfile ran away and is on hiatus.
[url]http://www.trausch.us/[/url]

Christopher Hunter wrote:
[color=blue]
> Bizarrely, a recent Windows port of an app that I wrote ran /much/ better
> under Wine than it did on Windows XP![/color]

I've seen this with many applications. I assume it's because my screen
isn't full of pointless effects, and my page file isn't being hammered
every time I open a file, change an application, breathe and so on.