Those are DHTML popups and are limited to the browser content frame. Unfortunately it's perfectly possible to spoof a Windows-like window frame using only DHTML making an almost perfect replica of IE dialog boxes (not sure why you'd want to, but you can). This isn't an IE only problem though. It's actually easier to do this in firefox.
Yes, ActiveX is being integrated into Firefox (I think it'll default to off however). It's an absolute hard requirement for web site compatibility, especially for internal intranets.
So don't go around telling people Firefox is "better" because it doesn't support ActiveX. That won't be true for long.
An OS written in Java is the coolest thing, mostly because being safe you can do away with things like processes and IPC - huge swathes of infrastructure can be removed because there's no way a Java class can randomly puke over memory used by another app. Therefore, all you need are threads: the performance cost of switching address spaces, communicating using IPC and so on all just disappears.
It gets cooler. You can have very flexible and fine grained security - the Java type system has been mathematically proven sound, meaning that there's no way to subvert it (short of waiting for cosmic rays to flip bits, hah). That means you can limit the relationships between classes very easily: sorta like SELinux except more fine grained.
Basically an OS written entirely in a safe, managed language would be an awesome thing, the only problem being that it'll never happen as the huge quantities of code needed to make a good OS is all written in C! You could port it, but that'd be a lot of effort that isn't worth the gain.
That doesn't make the concept uncool though. A pure Java OS done right would be very cool indeed.
I've written code that IBM are using to sell software - they use CrossOver (and I am a Wine developer) in their documentation for how to administer a Linux Domino server, believe it or not.
So I guess they're making money out of what I did for free. These days I get paid to do it, I did the support for IBM Lotus Notes 6.5.1 on Wine.
But, the money and code IBM has given to the Linux community and that I benefit from far, far outstrips what I've done for them. While I did get paid to do Notes, that money wasn't from IBM, yet I don't feel cheated: they give such vast quantities back under true open source licenses that really I have the last laugh.
Even if they hadn't given back, I try and license my code under copyleft licenses. That ensures that any improvements made in the course of being sold comes back to me in the form of software.
Not all remunerations come in the form of dollars, you know.
Last time I checked, the Windows API wasn't (legally) open source;)
You can get it of course, if you pay lots or are a univerisity (or the Chinese government) and sign up for lots of odd licensing restrictions. Nothing usable as true open source though.
Open source means the source is open. We can all see it. This means we would be able to see the code which creates the.doc file from start to finish. This also means we would be able to write our own library to read and write.doc files completely with our own code on any platform because we can see exactly how the original works.
Hahaha, I guess you've never read the DOC specs. I read a very old version of them that was distributed/leaked one time on MSDN many years ago - you can get it from the WvWare homepage.
Basically the Word specifications are nearly incomprehensible to human beings, let alone the code. Given that the specs actually partly consist of copy/pasted code I think even if Word were open sourced we'd only be a bit further in having OpenOffice and the like able to read them.
The Word developers use structures with members names like fcPlcffldHdrTxbx. It's hungarian taken to the logical extreme. Here's a line from one of the struct definitions:
FTC rgftcStandardChpStsh[3];// ftc used by StandardChpStsh for this document
Helpful, isn't it? I'm convinced the Word team are actually robots from the 23rd century, no people could have produced this.
Mind that the specs appear to be internal documentation yet are still incomplete!
Basically it would not surprise me if the internals of Word are like the internals of Windows: the people who truly understood them left or retired years ago leaving a mess of interlocking systems and hacks that nobody can fully comprehend.
Yeah, i'd have to echo this sentiment. Tar is a legacy hangover, not something to be treasured and preserved. Technically the ZIP format used on Windows is far better, and to be frank I'd much rather see the Linux community move to using a simplified filing system that supports all the features we want mounted via the loopback device.
ie, rather than "extract a tar.gz, edit the files, possibly recreate" you'd "mount the.box file, edit the files, unmount". GNOME and KDE could provide easy access to this so you could box/unbox anything. Meanwhile the on-disk format would be extensible.
MacOS already does something similar with DMG files, it might be worth moving in a similar direction.
Emulating things like texture blitting in software isn't really that slow. 3D games have very different performance characteristics to 2D compositing engines.
That's (iirc) FindFast and is entirely optional. It indexes files in the background a bit like updatedb does in Linux. I don't think it preloads parts of Office, it certainly doesn't need to do that.
Basically Office starts really fast because it makes heavy use of lazy loading (only loads code just-in-time), and because Microsoft do things like reordering code and functions in the source to ensure that frequently used code resides in the same pages in memory.
OK, I can see from the replies to my first post some people are still sceptical.
Startup time in most desktop apps has multiple components:
Disk IO. This is by far the slowest. Modern CPUs and memory are so fast relative to the disk that loading anything from disk kills your performance. Obviously you can't actually remove this bottleneck entirely but it turns out that you can significantly reduce the amount needed in order to load your app into RAM.
Code is split into pages. When the OS (this is true of all modern operating systems, Linux and Windows alike) starts your app it doesn't read each byte from disk into memory then jump to the entry point. It maps it into memory, so when the processor accesses a piece of the code it will be faulted in from disk. This is a good optimization because it means code that is never used is never loaded. However, pages are fairly coarse grained: 4k on standard IA32 setups (you can run it in 4mb mode as well but I don't know anybody who does this). Page faults hurt performance: each time your app faults, it's suspended while the hard disk seeks to the right place on disk then you have worst case a rotation of the disk platter before you can start reading. Therefore it's possible to speed up starting time significantly by packing all the code you need to start the app and bring it to the main screen into the same pages. This can often be as trivial as moving functions around in the file (hence the comment by an ex-'softie about code maintainability and such) but more advanced tools exist to do the same sort of thing in a systematic fashion.
You can also use code compression. This is counter-intuitive (decompressing stuff is slow right?) but some simple algorithms can be very fast and CPUs are sooooo much faster than disks are that it can actually be worth doing.
OS housekeeping overhead. On Linux+OpenOffice this is the biggest bottleneck. Due to the way OO.org [ab]uses shared libraries the bulk of the time is spent inside the dynamic linker joining the bazillions of C++ shared libraries it consists of together.
This is fairly pathological behaviour for all C++ apps on Linux. Lots of string comparisons and such. OO startup was analyzed and it was performing over 1.8 million strcmps inside the linker alone.
Prelink was developed to address this case for "normal" C++ apps like KDE things, but OO unfortunately dlopens much of its code so making prelink ineffective.
A good solution to this problem for us would be to implement DT_1_GROUP support in glibc, but this involves hacking on glibc which is a nightmarish task that nobody wants to do. But this is what kills OO in the OO vs MS Word on Linux (via Wine) test.
Context switches. If you have to sync to external programs during startup this can slow you down as IPC is expensive (much cheaper on linux than most operating systems but still expensive). For instance most GNOME apps sync with the X server, session manager, gconf, and some with bonobo-activation-server. That's a lot more than zero, which is how many servers (afaik) MS Word syncs with. Actually Word may talk to the RPC switch service to register in the ROT for automation purposes BUT this isn't critical to startup and can be done by a thread started after the main screen has been brought up.
You get the idea. You don't have to "cheat" to start fast, you just have to know what you're doing and make it a priority when coding. Unfortunately most developers aren't aware of these issues and ignore them until it's too late and you have something like OpenOffice or Eclipse....
I was talking about Wine. I can't "show" anything about Wine to somebody who doesn't have a good understanding of C by definition, and those who do would not ask these questions. So we're kind of stuck there. Suffice it to say that Wine is a reimplementation of the Windows API and is not integrated with the boot sequence of Linux. So, it has no opportunity to preload anything.
As to speed vs the illusion of speed - if the app starts and is usable within 3 seconds, who cares if it's still loading stuff behind the scenes? Not me. Not if it's usable.
As to how I can be sure MS Office doesn't use undocumented APIs, I never said it didn't. In fact you can find out exactly what APIs it uses very easily by running it in Wine, or using depends.exe etc - lots of ways. None of the undocumented MS APIs can magically make you go faster though, sorry. Most of them are very boring indeed.
I have reinstalled Windows on top of Office, and it loaded in exactly the same amount of time. Maybe they do preload on some systems but they certainly never have on any of mine, and they still start within 1-2 seconds at most.
Well, what did you expect? Of course they "blatantly" charge (how else do you do it?) for their services. If you don't want them to be producing signed updates and such for your systems and don't need them to be able to take care of your systems, then don't use it! That doesn't make Red Hat "dark" or "evil".
There's way too much nonsense spouted about Red Hat. Some people see that they're making money (that usually means, performing a valuable service to society) and think that's somehow impure.
I guess the messages about accessibility escaped your notice. Last time I checked, gnome-terminal also had far more features than xterm did: eye candy, a modern configuration UI, unicode support, accessibility support, etc etc - it's hardly fair to compare two such totally different programs.
X is already entirely reliant upon video card manufacturers releasing specs. NVidia doesn't really have an open source driver - I'm afraid the code you're thinking of is obfuscated, undocumented and utterly unhackable. It's basically a binary driver but written in C.
So not much changes if you flip everything on top of OpenGL. We're still dependent on video card manufacturers and will be until either they return to the culture of open specs, or people write "open hardware" video chips.
Gosling basically described DirectFB so if you like this sort of idea, go hack on that.
However, I'd suggest talking to various people in the industry first - people tend to get lots of misinformation that sounds correct but actually isn't by reading random stuff on the web (and slashdot). See the remarks about Office preloading above - doesn't happen.
So the design of X it turns out isn't actually a serious bottleneck on performance. If you do profiling runs and such, you find that having everything co-ordinated by the X server isn't a serious speed problem and that much larger issues are things like having to read from the fb to do XRENDER blending (or was last time I checked).
Basically, before going "wow yeah, right on!" I suggest you do a lot of research into the design of past and present windowing systems - what sounds intuitively right often isn't.
I thought this urban myth had been dispelled years ago. If they're really preloaded at boot smart guy, how comes Word still starts in under 3 seconds when running on Windows emulation on Linux? How comes IE still starts faster than Firefox again, on Linux?
No dude. They start fast because Microsoft really, really know how to optimize their software to start fast, and because that's always been a corporate priority for them. Research has shown that given two roughly equivalent apps, most people will decide on the basis of which one starts faster.
That doesn't mean they're using dirty tricks. Look into working set optimizers some time.
If that setting is named correctly it can't be what I want - I haven't even been using this machine for 60 days and it's already bugged me about it 3 or 4 times.
That's nothing compared to the "desktop tidy wizard". Is somebody at Microsoft obsessive compulsive about a tidy desktop or something?:)
Seriously, this has to be one of the most annoying features of XP, but I bet I can guess why they did it. I would expect they did a usability study which found that users ended up with a million and one icons they never used on their desktop, placed there by helpful installers whose authors just *couldn't* believe their app wasn't important enough to go on the desktop. So users end up not being able to find stuff easily. I'll bet that's why it does it.
I think that's an overly broad generalization. At least in England characters like Richard Branson are respected by most, however if you look at the "rich lists" which are published by the weekend broadsheets periodically they almost all come from one of a few sources:
- Inherited wealth (ie royalty)
- Financial people, stock traders, bankers etc who nobody ever hears about
- High-level executives (often same as the 2nd category)
- Rare individuals like Branson who are entirely self made through business
Most are the sort of business people who get labelled as "fat cats" by the tabloids, ie those who are perceived as being paid fabulous amounts to (often) ruin some of the nations biggest companies and organizations. This is especially true of privatized industries like gas, water, rail etc. When they inevitably get kicked out for being incompetent, greedy and generally sucking ass, they get "golden goodbye" agreements where they are paid huge amounts simply to leave. In other words financially they can't lose.
Those kind of rich guys don't get much respect. There are a few who fall into that category who really do know what they're doing, really do turn big companies around and who probably deserve the respect - it's no easy job - but from reading the papers if often seems like they are the minority (yeah yeah, media bias i know).
While Apple's track record on security isn't perfect
.... you mean like how they went months with an unpatched drive-by-download vulnerability so simple an 8 year old could understand it that could only be "fixed" by crippling the help system?
I think it's (sorta) patched now. But please. Apples track record on security from this incident alone makes it just as bad as Microsoft - the severity is at least the same.
That it's a choice is debateable, given MSFT's documented predatory practices.
If you think Apple are not "predatary" you need to review their history. Their legal department has a far worse history of targetting people than Microsofts does.
If she buys an Apple Mac computer next time, she will have a computer that functions better, works better, and breaks much more rarely than her current Windows computer. It's simple, really.
This isn't a scalable solution. It works as long as only a few people recommend/get Macs. As soon as Macs become sufficiently popular they'll be targetted by scumware authors too, and all the evidence is that they'd have a field day.
Me, I use Debian GNU/Linux because I value the freedom that is in Debian's goals. I recognize that Apple shares to some degree these goals, looking at its KHTML-based Safari goals
Apple used KHTML because the resources required to write a rendering engine from scratch are immense, and while they have a lot of manpower, they don't have enough to write and maintain a (good) engine themselves. Hyatt himself basically said this was the reasoning. It has nothing to do with a love of free software.
Sorry, I was rather imprecise - for ELF PIC code each internal function call is a few instructions once relocation processing has been done. For non-PIC code or jumps between static/hidden symbols it's 1 instruction.
Dude, I can't agree. Dialog units are an awful hack Microsoft added to cover up for the lack of design they put into the dialog manager originally. Anchoring is not superior to constraint-based layout once you take into account things like translations which can radically modify the size of strings at runtime. I think you equate anchoring with "flexible" because you are used to dropping controls at arbitrary points. This sort of flexibility just shoots you in the foot later though. Taking the time to learn constraint-based layout - wierd though it is at first - will not be wasted.
Well, the problem is that you have all these messages which are internal to an app being passed back and forth and each one requires a cross module call which in the Mach-O ABI is very inefficient. In standard compiled code an internal function call is 1 instruction - for crossing DSO boundaries you have to dereference the GOT so it's maybe 2 instructions. It's not much. Crossing into the ObjC runtime on Mach-O is very slow due to the way it wasn't designed for PowerPC, then you have to transition *back* again, and objc_msgSend() isn't exactly a 5 opcode call, so you have all the overhead of this: remember this is taking place for *all* internal method calls.
Basically it stacks up. But that's not the primary disadvantage of Objective-C. The primary disadvantage is that it's not kept pace with the times and nobody knows it. Why would you go for a C variant with wierd syntax that isn't fully garbage collected, when you can go for something very familiar, that is fully garbage collected?
Obj-C went nowhere for the same reason that Lisp and SmallTalk didn't : familiarity was more important to people than theoretical elegance. Next to that the badly designed ABI is peanuts.
First of all, there is no magic bullet to write quality desktop software and have it run anywhere. These days, if you want to write a program once and have it feel native on each platform, you need to be either using native widgets on each platform, or to have a big investment in custom code and tweaks in your toolkit for each platform.
GTK# runs on multiple platforms. Unsurprisingly it works best on the platform most people use it on. It does not run well on Windows or MacOS X, but that's simply because few people have worked on it/been interested in it. That can be fixed, with time.
When Miguel said "GTK# is the path to independence" he was talking about API independence not platform independence. They are different.
wxWidgets does not give platform independence. Sorry, but it just doesn't cut it for quality software. Abstractions work best when the things they abstract are semantically very similar (or identical) - widget toolkits are not similar, they often work in very different ways and have radically different capabilities. I've yet to run a wxWidgets app which didn't feel piss poor on every platform : much like Swing apps not feeling native everywhere, wxWidgets apps never fit in. This doesn't cut it for writing good software for the free desktop.
Or: With all these XML GUIs under.NET (like XAML) Ximian could've used Mozilla's XUL toolkit and have better multi platform integration than GTK.
GTK is a proven platform used by many, many applications. XUL is really only used by the Mozilla suite of apps: it lacks such basic things as the still theoretically xulrunner. That's why it was chosen.
Also - from what I've read on the mailing list archives - Mono only works sometimes on BSD systems. What kind of independence is this? You are only focused on x86-Linux running GNOME.
So what? Wine doesn't work on BSD systems currently either, but this is the fault of BSD not Wine (and I believe the same is true of Mono). Both Wine and Mono do very complex things with threading, address space management and low level OS calls that BSD either doesn't support or nobody with the relevant expertise has shown up to write the support. The vast majority of people use Linux, so this gets the best support. This is the open source meritocracy : write the code and the support will come, yes?
Slashdot Mirror
Those are DHTML popups and are limited to the browser content frame. Unfortunately it's perfectly possible to spoof a Windows-like window frame using only DHTML making an almost perfect replica of IE dialog boxes (not sure why you'd want to, but you can). This isn't an IE only problem though. It's actually easier to do this in firefox.
Cool! Glad to hear you like it :-)
So don't go around telling people Firefox is "better" because it doesn't support ActiveX. That won't be true for long.
It gets cooler. You can have very flexible and fine grained security - the Java type system has been mathematically proven sound, meaning that there's no way to subvert it (short of waiting for cosmic rays to flip bits, hah). That means you can limit the relationships between classes very easily: sorta like SELinux except more fine grained.
Basically an OS written entirely in a safe, managed language would be an awesome thing, the only problem being that it'll never happen as the huge quantities of code needed to make a good OS is all written in C! You could port it, but that'd be a lot of effort that isn't worth the gain.
That doesn't make the concept uncool though. A pure Java OS done right would be very cool indeed.
So I guess they're making money out of what I did for free. These days I get paid to do it, I did the support for IBM Lotus Notes 6.5.1 on Wine.
But, the money and code IBM has given to the Linux community and that I benefit from far, far outstrips what I've done for them. While I did get paid to do Notes, that money wasn't from IBM, yet I don't feel cheated: they give such vast quantities back under true open source licenses that really I have the last laugh.
Even if they hadn't given back, I try and license my code under copyleft licenses. That ensures that any improvements made in the course of being sold comes back to me in the form of software.
Not all remunerations come in the form of dollars, you know.
You can get it of course, if you pay lots or are a univerisity (or the Chinese government) and sign up for lots of odd licensing restrictions. Nothing usable as true open source though.
Hahaha, I guess you've never read the DOC specs. I read a very old version of them that was distributed/leaked one time on MSDN many years ago - you can get it from the WvWare homepage.
Basically the Word specifications are nearly incomprehensible to human beings, let alone the code. Given that the specs actually partly consist of copy/pasted code I think even if Word were open sourced we'd only be a bit further in having OpenOffice and the like able to read them.
The Word developers use structures with members names like fcPlcffldHdrTxbx. It's hungarian taken to the logical extreme. Here's a line from one of the struct definitions:
FTC rgftcStandardChpStsh[3]; // ftc used by StandardChpStsh for this document
Helpful, isn't it? I'm convinced the Word team are actually robots from the 23rd century, no people could have produced this.
Mind that the specs appear to be internal documentation yet are still incomplete!
Basically it would not surprise me if the internals of Word are like the internals of Windows: the people who truly understood them left or retired years ago leaving a mess of interlocking systems and hacks that nobody can fully comprehend.
MacOS already does something similar with DMG files, it might be worth moving in a similar direction.
But yes this is an issue.
Basically Office starts really fast because it makes heavy use of lazy loading (only loads code just-in-time), and because Microsoft do things like reordering code and functions in the source to ensure that frequently used code resides in the same pages in memory.
OK, I can see from the replies to my first post some people are still sceptical.
Startup time in most desktop apps has multiple components:
Code is split into pages. When the OS (this is true of all modern operating systems, Linux and Windows alike) starts your app it doesn't read each byte from disk into memory then jump to the entry point. It maps it into memory, so when the processor accesses a piece of the code it will be faulted in from disk. This is a good optimization because it means code that is never used is never loaded. However, pages are fairly coarse grained: 4k on standard IA32 setups (you can run it in 4mb mode as well but I don't know anybody who does this). Page faults hurt performance: each time your app faults, it's suspended while the hard disk seeks to the right place on disk then you have worst case a rotation of the disk platter before you can start reading. Therefore it's possible to speed up starting time significantly by packing all the code you need to start the app and bring it to the main screen into the same pages. This can often be as trivial as moving functions around in the file (hence the comment by an ex-'softie about code maintainability and such) but more advanced tools exist to do the same sort of thing in a systematic fashion.
You can also use code compression. This is counter-intuitive (decompressing stuff is slow right?) but some simple algorithms can be very fast and CPUs are sooooo much faster than disks are that it can actually be worth doing.
This is fairly pathological behaviour for all C++ apps on Linux. Lots of string comparisons and such. OO startup was analyzed and it was performing over 1.8 million strcmps inside the linker alone.
Prelink was developed to address this case for "normal" C++ apps like KDE things, but OO unfortunately dlopens much of its code so making prelink ineffective.
A good solution to this problem for us would be to implement DT_1_GROUP support in glibc, but this involves hacking on glibc which is a nightmarish task that nobody wants to do. But this is what kills OO in the OO vs MS Word on Linux (via Wine) test.
You get the idea. You don't have to "cheat" to start fast, you just have to know what you're doing and make it a priority when coding. Unfortunately most developers aren't aware of these issues and ignore them until it's too late and you have something like OpenOffice or Eclipse ....
As to speed vs the illusion of speed - if the app starts and is usable within 3 seconds, who cares if it's still loading stuff behind the scenes? Not me. Not if it's usable.
As to how I can be sure MS Office doesn't use undocumented APIs, I never said it didn't. In fact you can find out exactly what APIs it uses very easily by running it in Wine, or using depends.exe etc - lots of ways. None of the undocumented MS APIs can magically make you go faster though, sorry. Most of them are very boring indeed.
I have reinstalled Windows on top of Office, and it loaded in exactly the same amount of time. Maybe they do preload on some systems but they certainly never have on any of mine, and they still start within 1-2 seconds at most.
There's way too much nonsense spouted about Red Hat. Some people see that they're making money (that usually means, performing a valuable service to society) and think that's somehow impure.
I guess the messages about accessibility escaped your notice. Last time I checked, gnome-terminal also had far more features than xterm did: eye candy, a modern configuration UI, unicode support, accessibility support, etc etc - it's hardly fair to compare two such totally different programs.
So not much changes if you flip everything on top of OpenGL. We're still dependent on video card manufacturers and will be until either they return to the culture of open specs, or people write "open hardware" video chips.
However, I'd suggest talking to various people in the industry first - people tend to get lots of misinformation that sounds correct but actually isn't by reading random stuff on the web (and slashdot). See the remarks about Office preloading above - doesn't happen.
So the design of X it turns out isn't actually a serious bottleneck on performance. If you do profiling runs and such, you find that having everything co-ordinated by the X server isn't a serious speed problem and that much larger issues are things like having to read from the fb to do XRENDER blending (or was last time I checked).
Basically, before going "wow yeah, right on!" I suggest you do a lot of research into the design of past and present windowing systems - what sounds intuitively right often isn't.
No dude. They start fast because Microsoft really, really know how to optimize their software to start fast, and because that's always been a corporate priority for them. Research has shown that given two roughly equivalent apps, most people will decide on the basis of which one starts faster.
That doesn't mean they're using dirty tricks. Look into working set optimizers some time.
If that setting is named correctly it can't be what I want - I haven't even been using this machine for 60 days and it's already bugged me about it 3 or 4 times.
Seriously, this has to be one of the most annoying features of XP, but I bet I can guess why they did it. I would expect they did a usability study which found that users ended up with a million and one icons they never used on their desktop, placed there by helpful installers whose authors just *couldn't* believe their app wasn't important enough to go on the desktop. So users end up not being able to find stuff easily. I'll bet that's why it does it.
Doesn't make it any less annoying of course.
- Inherited wealth (ie royalty)
- Financial people, stock traders, bankers etc who nobody ever hears about
- High-level executives (often same as the 2nd category)
- Rare individuals like Branson who are entirely self made through business
Most are the sort of business people who get labelled as "fat cats" by the tabloids, ie those who are perceived as being paid fabulous amounts to (often) ruin some of the nations biggest companies and organizations. This is especially true of privatized industries like gas, water, rail etc. When they inevitably get kicked out for being incompetent, greedy and generally sucking ass, they get "golden goodbye" agreements where they are paid huge amounts simply to leave. In other words financially they can't lose.
Those kind of rich guys don't get much respect. There are a few who fall into that category who really do know what they're doing, really do turn big companies around and who probably deserve the respect - it's no easy job - but from reading the papers if often seems like they are the minority (yeah yeah, media bias i know).
So now you know. Just my 2 pennies.
I think it's (sorta) patched now. But please. Apples track record on security from this incident alone makes it just as bad as Microsoft - the severity is at least the same.
That it's a choice is debateable, given MSFT's documented predatory practices.
If you think Apple are not "predatary" you need to review their history. Their legal department has a far worse history of targetting people than Microsofts does.
If she buys an Apple Mac computer next time, she will have a computer that functions better, works better, and breaks much more rarely than her current Windows computer. It's simple, really.
This isn't a scalable solution. It works as long as only a few people recommend/get Macs. As soon as Macs become sufficiently popular they'll be targetted by scumware authors too, and all the evidence is that they'd have a field day.
Me, I use Debian GNU/Linux because I value the freedom that is in Debian's goals. I recognize that Apple shares to some degree these goals, looking at its KHTML-based Safari goals
Apple used KHTML because the resources required to write a rendering engine from scratch are immense, and while they have a lot of manpower, they don't have enough to write and maintain a (good) engine themselves. Hyatt himself basically said this was the reasoning. It has nothing to do with a love of free software.
Sorry, I was rather imprecise - for ELF PIC code each internal function call is a few instructions once relocation processing has been done. For non-PIC code or jumps between static/hidden symbols it's 1 instruction.
Dude, I can't agree. Dialog units are an awful hack Microsoft added to cover up for the lack of design they put into the dialog manager originally. Anchoring is not superior to constraint-based layout once you take into account things like translations which can radically modify the size of strings at runtime. I think you equate anchoring with "flexible" because you are used to dropping controls at arbitrary points. This sort of flexibility just shoots you in the foot later though. Taking the time to learn constraint-based layout - wierd though it is at first - will not be wasted.
Basically it stacks up. But that's not the primary disadvantage of Objective-C. The primary disadvantage is that it's not kept pace with the times and nobody knows it. Why would you go for a C variant with wierd syntax that isn't fully garbage collected, when you can go for something very familiar, that is fully garbage collected?
Obj-C went nowhere for the same reason that Lisp and SmallTalk didn't : familiarity was more important to people than theoretical elegance. Next to that the badly designed ABI is peanuts.
GTK# runs on multiple platforms. Unsurprisingly it works best on the platform most people use it on. It does not run well on Windows or MacOS X, but that's simply because few people have worked on it/been interested in it. That can be fixed, with time.
When Miguel said "GTK# is the path to independence" he was talking about API independence not platform independence. They are different.
wxWidgets does not give platform independence. Sorry, but it just doesn't cut it for quality software. Abstractions work best when the things they abstract are semantically very similar (or identical) - widget toolkits are not similar, they often work in very different ways and have radically different capabilities. I've yet to run a wxWidgets app which didn't feel piss poor on every platform : much like Swing apps not feeling native everywhere, wxWidgets apps never fit in. This doesn't cut it for writing good software for the free desktop.
Or: With all these XML GUIs under .NET (like XAML) Ximian could've used Mozilla's XUL toolkit and have better multi platform integration than GTK.
GTK is a proven platform used by many, many applications. XUL is really only used by the Mozilla suite of apps: it lacks such basic things as the still theoretically xulrunner. That's why it was chosen.
Also - from what I've read on the mailing list archives - Mono only works sometimes on BSD systems. What kind of independence is this? You are only focused on x86-Linux running GNOME.
So what? Wine doesn't work on BSD systems currently either, but this is the fault of BSD not Wine (and I believe the same is true of Mono). Both Wine and Mono do very complex things with threading, address space management and low level OS calls that BSD either doesn't support or nobody with the relevant expertise has shown up to write the support. The vast majority of people use Linux, so this gets the best support. This is the open source meritocracy : write the code and the support will come, yes?