[Interest] Apologies on the "bloat" thread (a.k.a yes Windows is still important)

Justin Ferguson jnferguson at gmail.com
Thu Apr 11 01:28:10 CEST 2013


On Apr 10, 2013 5:50 PM, "Thiago Macieira" <thiago.macieira at intel.com>
> First of all, let me apologise for my behaviour in the thread on
> bloat". I've re-read my first reply and it was clearly out of line. And
> number of off-ML messages I got also indicates that.


> So, my deepest apologies for letting my personal feelings and frustrations
> with Windows get in the way of being professional. So let's sort things

its been a rough patch for me and I sometimes cause collateral damage when
the right spark hits.

>         * Qt and Windows:
>         (this is supposed to be objective)
> Windows has been and continues to be the biggest addressable market for
> even after years of Nokia strongly pushing mobile. There are many users
> choose Qt for their Windows-only applications, with no intention of ever
> cross-platform development.

a really nice aspect is that when done 'right' proper c++/boost and qt,
then one barely even needs to care about cross platforn dev because its
already cross platform. this is the largest appeal of all of the above to

> They do that because the Qt API is good and the
> documentation is well-written.

good documentation++.

> And, I now realise, also because it's easy to build. I feel dumb for not
> realising this before, especially when a month or two ago I tried to build
> some other Unix-originated libraries on Windows and thought
> Rest assured that the Qt Project remains attentive to Windows. Windows
> one of the reference platforms for the project, which means all new
> that make sense on Windows must be implemented on Windows before they are
> accepted. Any changes made >anywhere must not break the build >on Windows

please accept this criticism as earnest, heartfelt and with the best
intentions: whomever(s) QAs the wibdows build process needs a kick in the
rear. when I built 5.0 it became quite obcious many of the configuration
options hadnt been tested or tested in some time.

>    That's why we're now going to >ship an MSVC2012 64-bit build, a
>    build,

♡♡♡♡♡ tyvm.

>and we've worked with the MinGW >community to come up with a decent
>    distribution of theirs that can >produce good-performance code.

thats awesome to hear, I would greatly encourage the mingw team to review
the differences in terms of security that msvc provides, theres just no
comparison.  (id est does anyone have even a first gen safeseh for c++
exception handling? nm sehop and so on).

its a volunteer project, IMHFO thats the best kind,  but we do ourselves a
disservice if we ever believe that can rwally compete with the millions of
dollars and hours that microsoft research has put into their products, is
there even an oss/fs set of static analysis tools that compete with prefix
et al?

for Windows, for me,  anythjng other than MSVC feels like im taking
liberties with my users machines.

> We assumed that requiring Perl was acceptable. It was already required on
> Windows if you decided to do an out-of-source build, which most people

totally not me complaining there.

> We assumed that Perl, being such an industry old-timer, would be an easy
> requirement, unlike other tools we have to ship, like GNU flex.

id probably ship it akin to flex et al. I dont know thw license reqs and
how much of a pain that is but apparently adding perl makes it over the top
for many.

> And by the way, also remember that Linux distributors often hate us for
> things the Windows way, like bundling libpng, libjpeg, zlib, sqlite, not
> autoconf, not using gettext. We're trying to be a great cross-platform
> which unfortunately means compromising here and there.

excellent point... I've sorta shunned myself from the geek world the last
few years, horrible culture in areas I dont need encouragement in, and tend
to forget how zealotted it can be.

>         * Feelings about Windows and bias:
>         (this is subjective!)
> I get extremely frustrated every time I have to develop using Windows.
> Compared to the ease of development I have when using my Linux machine,
> nowhere near as efficient. Tools that I take for granted, like shell
> AWK, Perl, sed, strace, valgrind, as well as SQLite, ICU, libpng, libjpeg,
> zlib are missing.

I remember and empathize with that, generally speaking ive found when I
just started using the msft way when on msft,  that I didnt need most of
those tools.. I dont ship complete products often enough to worry much
about the build process which is where most of that comes in. im pretty
simple there a nmake file suffices but im finding more and more I hate
basically al build processes so take my sentiments there with a grain of

> And as I said to summarise in one word: valgrind. It's one of the most
> tools a developer could hope to have, to the point that I recommend people
> have a Linux VM just in case they need it (note: there are commercial
> alternatives for Windows; if you can't use Linux, make sure you get one of
> those).

I actually keep a specific older laptop around just for linux  I owe
everything I know abour computers to OSS/FS;  self taught, so dont get me
wrong there. for lack of better phrasing and very much a personal
subjective viewpoint,  programming on the unices feels like painting with
crayons. CreateRemoteThread is a favorite example there.

> So my biased conclusion is that no developer with half a mind would
> choose to use Windows. I said that in one of my emails.

we are all entitled to our opinions,  even the wrong ones /ducks )

> And that is clearly biased. It is so because it's the environment in
which I
> am the most efficient. When I first started dabbling with development, in
1995, I
> did use Windows, but no compilers were freely available. The one freely-
> available compiler of that era for Windows was the Java one -- and some
of you
> may remember what Java 1.0 was like. Soon after, I discovered Linux, with
> source code available and a decent (albeit much to be improved) compiler
> available with just the flick of a switch -- that was GCC 2.7.2.

I started inversely and was on linux about 6 months into using computers
because I heard its what  real hackers used and more of my professional
career than not is super linux-centric.

> So I've "grown up" as a developer on the Unix world, with the tools
> with that world.

its a big paradigm shift, but I cant fathom going back fulltime now. I
sometimes sit in vi for a moment having typed "re" waiting for the "ad "
and prototype to pop up. hardly the best of explanations or rationales, but
yeah windows spoiled me.

> Objectively speaking, I have to say that there are many advantages with
> environment I use: having readily accessible tools to look into low-level
> events, system-wide debugging, access to the source code of the libraries
> I use, rapid script development, etc. But if I speak objectively, I have
> also recognise that Microsoft Visual Studio is an awesome tool, as long
as you
> don't have to go beyond its boundaries.

what boubdaries? if we wanted to break it down the debugging apis in
windows is generally waaay better, windbg is awesome for both userland and
ring0 and doesnt blow up on threads and I end up losing so much time
remembering the nuances of the scripting language in question that I can
generally pump out c++ way faster, especially with the new standard and/or
boost. I sometimes refer to it as being what I imagined shell scripting in
tcsh to have been like before I tried it.
> And therein lies the big difference: the philosophy of those two worlds.
In the
> Windows / MSVC world, developers are expecting their tools to be self-
> contained. They use Visual Studio and everything is inside there. They
> have to go poking for third-party software. That's why the Qt Visual
> Add-in exists and that's actually the type of experience that Qt Creator
> trying to duplicate.

without argument, just when in Rome its painful to speak Greek.

> It's just not how I work

and IMHFO it doesn't have to be, nor mine vice versa.

> So, apologies for being out of line.

my sincerest apologies for the red hot private emails.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130410/acd5bd04/attachment.html>

More information about the Interest mailing list