

Switching to Linux: A Windows developer’s view - edw519
http://anteru.net/2009/09/14/604/

======
justindz
This was interesting inside view. One thing that I did notice is the statement
that the level of changes on the MSFT side was causing him grief. I'd be
curious, as a follow-up, to see if he continues to develop on Linux. It seems
like he has generalized the ease of the port into other perceived benefits on
Linux (e.g. rate of change, lower need to adapt code) that might not be true
in practice, or at least as true as he feels they will be based on the porting
experience.

Sounded a little bit like some kind of initial success euphoria bias. Yes, I
just made that up. I remember it with Rails too. This isn't a knock on Rails--
just using it as an example--but a lot of people had such a blast porting code
(me included) that they assumed everything was peaches and cream until they
realized that the big, dirty things in web apps like scaling, localization and
the impact of poor planning didn't magically disappear.

~~~
Periodic
I think there's a honeymoon period with just about any new technology. It
generally starts once you've switched to solve a problem and the new
technology solves it well. At this point any faults or frustrations are
generally just because you don't know the technology well enough to do it
right. It isn't until you become more familiar and try to expand what you're
doing that you start to find and explore the limits of the new technology.

All technology has limitations and frustrations. The question is which works
best for each person. I think this might work well for him, as it sounds like
he is doing some things that do port very easily.

------
modeless
Choosing Linux for stable APIs would be rather silly. X11 is evolving rapidly
nowadays and audio APIs are in a state of constant flux, where the different
APIs often interfere with each other and there's no obvious best solution.
Linux changes ABIs all the time and is notorious for C library
incompatibilities. This recent mess with filesystem write semantics
(<http://lwn.net/Articles/322823/> ) has proven you can't even rely on POSIX.

Meanwhile, Win32 has been far more stable over the years and Microsoft has put
a ton of effort into backwards compatibility. Don't get me wrong; I like Linux
but API stability is not the reason to choose it over Windows.

~~~
jmillikin
The X11 protocol was standardized in 1987. Any X application which worked then
would work now. There are extensions and new capabilities being added, but
every one is backwards-compatible.

Ditto with audio APIs -- the last major change was the changeover from OSS to
ALSA, in 2002, and to this day there's an OSS compatibility layer.

I've used Linux since early 2001, and in all that time I've never encountered
an incompatibility with libc.

The filesystem semantics issue is due to idiot application developers trying
to squeeze out a few msec of performance, at the risk of their user's data.
The issue exists on every modern filesystem, no matter which OS is used.
Anybody who relies on POSIX -- ie, uses fsync() -- doesn't have to worry about
that problem.

~~~
modeless
Yes, X11 is backwards compatible and that's been really great for the Linux
desktop. But the article bashes Windows for rapidly introducing new APIs even
though the old ones remain compatible; I'm just pointing out that Linux does
that too.

As for the audio situation, the problem is sharing between multiple apps. ALSA
sucks at it so "sound servers" were invented but they caused more problems
than they solved. Now it seems like every distro has a different sound
solution, and meanwhile OSS was never removed from the kernel so you can't
even rely on ALSA always being there.

The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO the
problem really lies in POSIX which doesn't specify a way to achieve what app
developers need in a way that can also be easily implemented in the kernel
with good performance. I would argue that the behaviors app developers were
using became a de facto part of POSIX and the way kernel devs broke them was
irresponsible even if it didn't break the letter of the standard. Contrast
with Microsoft which goes far, far out of its way to avoid breaking apps even
when they flagrantly violate good practices (there are some great examples on
The Old New Thing: <http://blogs.msdn.com/oldnewthing/> ).

~~~
jmillikin
_Yes, X11 is backwards compatible and that's been really great for the Linux
desktop. But the article bashes Windows for rapidly introducing new APIs even
though the old ones remain compatible; I'm just pointing out that Linux does
that too._

Linux's graphics APIs have remained largely static: they are GTK+ and Qt.
Nobody writes their own implementations of X11.

Your audio paragraph is completely divorced from reality. Sound servers were
originally created to implement software mixing, which is not supported by
OSS. When ALSA was imported into the mainline kernel, software mixing became
possible without servers and they largely died out.

Now, ALSA is the dominant standard for Linux audio. Recently, the sound server
PulseAudio was created, but apps use it through the standard ALSA API. To my
knowledge, there is no distribution using a sound server other than Pulse.

You can't rely on sound being enabled, true. But every mainline distribution
ships with sound enabled, and that means they support ALSA. If a user disables
their sound subsystem and then complains they can no longer hear music, that's
their problem.

 _The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO
the problem really lies in POSIX which doesn't specify a way to achieve what
app developers need in a way that can also be easily implemented in the kernel
with good performance._

Sure it does -- fsync(). To my knowledge, the only filesystem which has poor
performance when using fsync() is ext3 in data=ordered mode (which is not the
default).

~~~
modeless
_When ALSA was imported into the mainline kernel, software mixing became
possible without servers and they largely died out._

My experience was completely different. A few years ago, ALSA software mixing
was not enabled by default and didn't work well when enabled. When not
enabled, apps couldn't share the audio device at all. KDE created aRts to
allow sharing at the app level, but aRts sucked, plus it hogged the audio
device so non-aRts apps wouldn't work at all. Later aRts added a timeout after
which it would release the device but this obviously wasn't a good solution.
Gnome had ESD which I didn't use but it conflicted with aRts. JACK came along
but was only ever used by high-end audio programs.

ALSA finally did get decent software mixing support, but now people are used
to running sound servers. PulseAudio is the newest thing but last I heard a
lot of people are still unsatisfied with it (e.g.
[http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-
solut...](http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solution-in-
search-of.html) ). Furthermore, people who know what they're talking about are
recommending a move away from PulseAudio and ALSA and _back_ toward OSS!
Personally, I think the case is quite convincing:
[http://insanecoding.blogspot.com/2009/06/state-of-sound-
in-l...](http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-
so-sorry.html)

 _To my knowledge, the only filesystem which has poor performance when using
fsync() is ext3 in data=ordered mode (which is not the default)._

Not according to <http://lwn.net/Articles/351422/>

~~~
jmillikin
_A few years ago, ALSA software mixing was not enabled by default and didn't
work well when enabled. When not enabled, apps couldn't share the audio device
at all._

Yes, disabling sound mixing will prevent multiple applications from using the
sound card at once, in much the same way as disabling graphics drivers will
prevent X11 from working.

 _KDE created aRts to allow sharing at the app level, but aRts sucked, plus it
hogged the audio device so non-aRts apps wouldn't work at all._

aRts is for pre-ALSA (ie OSS) applications. It doesn't belong on an ALSA-based
system, and will obviously not get along well with a modern stack. I'm not
denying there are lots of distributions which are configured poorly, but any
decent distribution such as Red Hat or Debian worked well.

I disagree that glitch-free playback and per-application volumes are
"solutions in search of problems", but that's personal taste. If somebody
wants to run without PulseAudio, they can. Reading the blog post, it seems he
was surprised when upgrading to a bleeding-edge development version caused
problems.

The last link is written by an OSSv4 developer. OSSv4 is unlikely to ever gain
mainstream acceptance because it contains insanity such as performing
floating-point math in the kernel. Aside from people are _literally_ hired
from the company developing OSSv4, I have heard no good news about it, and
there do not appear to be any movements back to an OSS-based stack.

~~~
modeless
_Yes, disabling sound mixing will prevent multiple applications from using the
sound card at once, in much the same way as disabling graphics drivers will
prevent X11 from working._

X11 never came with graphics drivers disabled by default.

 _aRts is for pre-ALSA (ie OSS) applications._

aRts isn't "for" ALSA or OSS applications; in fact it doesn't play nice with
either. aRts is for aRts applications. aRts has backends for both OSS and
ALSA.

There's no reason glitch-free playback and per-application volume control
can't be done in the kernel. The only feature that makes sense to do in user
space is network transparency, which is of limited utility.

------
demallien
Maybe I'm missing something, but who develops on Windows for applications that
aren't using the Windows APIs anyway? I mean, the whole point of Windows is
it's APIs. If you aren't going to use them, then sure, go and move to a unix
system - indeed you should have done so years ago.

On the other hand, if your product is designed for Windows, then you can't
really switch, can you? (that's a real question by the way, not rhetorical).

~~~
blub
The whole point of Windows is that it's an operating system. Depending on your
market/skills you either develop for it or not. I prefer to develop for it
because when it comes to C++ programming, it's the best out there.

This story made porting look easy, but rest assured it is hard, and he won't
be so thrilled when the problems start cropping up.

------
sandGorgon
<http://braid-game.com/news/?p=364>

Jonathan Blow, the developer of Braid, has had a thread on his blog (made from
last year, when he gave up trying to port Braid on linux, till July of this
year) about the (sorry?) state of developer tools on Linux.

An interesting read - given that his primary editor was emacs and he has been
using *nixes for 20 years.

Long story short - sorry state of sound on Linux, sorry state of debugging
tools on linux, OpenAL+SDL dont cut it.

------
Keyframe
I still use windows mostly because of my primary tools (Maya, Photoshop and
Fusion - occasional game), however I have a VM with linux in it and just run a
fullscreen putty on a second monitor. For django dev, for example, I have a
vertically split screen where bottom is a :resize of 10 lines and running
manage.py runserver_plus and top one I run bash or cycle through several
(whatever I need). Similar stuff happens when I dev in D or C++.

I edit files via tramp on that VM dev server. Neat combination is that I move
VM from workstation to laptop and vice versa, basically having a portable dev
server all the time with me. It would be nice though if I could find a binary
diff copy for files, since copying VM over network can take some time (luckily
I don't do that all the time).

------
joe_the_user
I think QT is real gem as far as application frameworks go. It's the easiest
C++ framework I've ever worked with.

------
scorpion032
It's not for nothing Google took 8 months to port Chrome to Linux. Porting
can't be this simple.

~~~
pyre
Didn't it also take that long to port the OS X version as well? (I seem to
remember the 'developer' builds of Chrome for Linux and Chrome for Mac coming
out at the same time)

Keep in mind that he seems to be mostly using Python and doing mostly number
crunching (which would seem to be rather OS independent) from what I could
glean.

------
phugoid
Smacks of poor engineering to me; switching to another platform instead of
finding the cause of the problem.

"I was hitting some issues with either the scheduler or the memory subsystem,
as my code didn’t have any I/O in it."

~~~
ajross
Developers are responsible for debugging their platform then? He states that
he had a significant speedup in Vista too, which is pretty good evidence that
he'd isolated the problem to something in XP. So he needs to decide on what to
do, and fixing XP retroactively doesn't seem to be an option.

And in any case, the thread scalability of the allocator some of MS's older C
runtimes is a known performance issue. I'm not surprised by this at all.

~~~
blub
What happened to: first check your code, then your compiler and as a last
resort your OS? The problem was most likely in his hand-crafted threading
code.

------
steverb
Looking at what he was doing (Python + C++) it seems that switching was a no
brainer. Hell, I'm a MS fanboy (seriously love .NET) and I use Linux for some
projects (Java/Tomcat and investigating Mono).

------
GrandMasterBirt
I always been a windows developer. 3 mo ago my co-worker suggested I give
linux a shot. Fuck it why not.

I realized the following:

1) Linux is more stable. (NEVER have to reboot it, unless I chose to conserve
energy at night).

2) Linux boots faster. By the time linux boots, auto launches firefox and
eclipse, windows is only reaching the desktop at which point its still 1-2
minutes before it becomes usable.

3) I still use the same tools in linux and windows (I still need a VM to run
Toad). (Eclipse, grep, firefox, a linux command prompt (god cygwin is not as
good as the real thing). Which is great since toad makes windows 95 appear
stable. Putting toad in a vm is the best way to make it work well :). Also I
get to test IE6,7,8 without any problems because I already have vms set up.

4) Multiple desktops = easier at times.

5) Windows made me need tools for mounting like sftp -> drive. Linux comes
with sftpfs (ok fine u need to apt-get it). Its all free too so cost savings.

Switching to linux only raised one question: Why didn't I do it earlier.

The only problem is KDE fonts suck! Gnome ones are good out-of-the-box. Also
KDE apps (like plasma) crashes like a wasted, doped-up, narcoleptic. Sooooo
ubuntu, not kubuntu wins for me.

~~~
halo
If you have to reboot Windows for anything other than updates you should be
looking into problems with your hardware and drivers. The "Windows is
unstable" meme should really be dead and buried by now.

I can believe Ubuntu is faster than Windows at booting, especially considering
they focused on it in their last release, but for me the much bigger issue was
flaky Sleep/Suspend-to-RAM and Hibernate/Suspend-to-Disk support. I suspend my
laptop several times a day but only reboot on updates.

~~~
jacquesm
> If you have to reboot Windows for anything other than updates you should be
> looking into problems with your hardware and drivers. The "Windows is
> unstable" meme should really be dead and buried by now.

It it should be 'dead and buried' by now then why does it persist ?

It seems that there are enough people that share these experiences (not
necessarily your own) to stop that from happening.

My own take is that it is getting better, but it isn't there yet.

One thing that I personally don't understand at all is why the industry did
not long ago standardize on ECC RAM, the cost would have been marginal (due to
the increase in volume) and the potential benefits in perceived stability
would be huge.

Servers have it pretty much as a standard, any bit flipped in critical RAM can
cause an OS crash (both for Linux and for Windows, RAM failures are OS
agnostic).

~~~
arohner
Maybe _Microsoft's_ code doesn't cause crashes any more, but 3rd party drivers
and shoddy OEM hardware are definitely still to blame. Users don't care why
their stuff crashes, only that it does. And first hand, I see XP-era machines
crash less after converting them to Ubuntu. I haven't tested a Vista machine,
I've never seen anyone run one.

Re: ECC ram, my non-server, "consumer" linux boxes typically have uptimes of
100,200,300 days. They only go down for hard drive failures and OS upgrades.

~~~
jamesbritt
My copies of XP and Vista were fairly peppy booters when first installed, but
adding in assorted services (databases, Web server, VNC) slowed things down,
plus I had to install antivirus software, which makes things even slower.

Of more concern to me is shutdown time, as in "eternity", and when I have to
just hold the button button to force a machine off. Each time there is a real
risk of corrupted drives (I'm recovering data right now from a drive corrupted
because something hung Vista and I had to power off the box).

Each time it refuses to cleanly shutdown there is nothing displayed to tell me
why.

Is there even an option to have windows show what it's doing when it shuts
down instead of the often untruthful 'Windows is shutting down' message?

