I was under the impression that the first portal site was netscape.com who created it after realising they had so many page hits because their site was the default start page for their browser, and the first webmail was hotmail.com.
But yes, I generally agree with you about people under-rating Yahoo. They're by no means a bad company, and have shown the ability to do cool stuff many times. Their new online music store seems pretty nifty, at least, more customisable than iTunes Music Store is. Only downer is it doesn't work on Linux (but then unless you buy Crossover neither does iTunes).
The guy was almost certainly looking at the Debian installer, which at least traditionally had a habit of asking lots of questions like that. It was basically a text book case of how not to design an easy to use installer. I have no idea if the new one is better in this regard, I never tried it, but it's still textual.
To navigate to/cdrom you have to be exposed to the full legacy horror of the filing system heirarchy standard:/etc/usr/ opt//boot/sys/proc.... these names are even more meaningless than System or Program Files. And most distros don't put it in/cdrom. They put it in/mnt/cdrom, or maybe/media/cdrom, or maybe it's not actually in your fstab at all and you have to manually mount it somewhere by knowing its device node.
The reaction of computer scientists should be your guide. These people tend to know answers to questions, which you don't know enough to even ask.
How arrogant. I've done enough coding, and learned enough about usability, to know when somebody is making excuses about something that may have made sense 20 years ago but no longer does.
Now I'm not saying we should replace the unified heirarchy with driver letters on Linux, rather the way GNOME is going with showing multiple "roots" in the UI labelled by logical device names is a better approach. The UI is basically the same, in the new GTK+ file picker you have "Filesystem", "Home", "Desktop", "CD/DVD Drive" etc and they're mapped behind the scenes to wherever they're mounted.
Erm, I don't think his point was that "normal" users (whatever normal is) care about these features, but rather that Linuxs existing user base cases about them.
The question here is, will significant numbers of Linux users migrate to the Mac? More interestingly, will significant numbers of Linux users contributing useful work migrate? To some extent, given how much software is open source, the latter is far more important than the former. For Apple and Microsoft, users are everything because without a critical mass of users commercial/proprietary ISV companies won't develop or port software. For Linux - while the support of commercial ISVs is certainly nice to have - it's not so intertwined with its survival.
Apple have solved this problem so far partly by writing tons of software itself (I think they have over a thousand people in their software division alone!) and also by leveraging their history - Microsoft may well make a profit on Office for the Mac today, but would it have been profitable to develop from scratch if not for the lawsuit they were so keen to defend? Would Adobe have ported Photoshop to MacOS X if not for the original MacOS Classic version that was written way back in the mists of time? And I suspect this approach will work seeing as how they make lots of money from iPods they can use to subsidise their OS development with so the usual app-support hurdles can be overcome. Their unbelievably loyal customer base doesn't hurt either.
Now while it's certainly true that raw numbers matter to Linux in terms of getting application (and maybe hardware) support, a more likely path for it to follow is deployment on the corporate desktop. Being able to deploy to pre-existing hardware en-masse is a huge advantage there, as is apps like Sabayon and ZENworks which make network administration very easy. Attacking the corporate desktop is where Novell and Red Hat are currently focussed - whilst companies like Linspire might be in trouble, the major employers of Linux developers aren't really interested in competing directly for Apples individual/home market share just yet.
In much the same way that iPod sales and a huge interest cashpile bankrolled the Mac development effort, sales of high end servers and support are bankrolling corporate desktop Linux development. Two different directions, two different paths, probably they'll meet at some point but it won't make that much difference until then.
having to support legacy concepts (such as drive letters);
Whilst the UNIX style unified directory hierarchy is aesthetically pleasing to computer scientists, I've never been convinced that it's really more usable. On Windows, people can learn a few simple letter to concept mappings "A" is the floppy disk, "C" is the stuff inside the Computer, "D" is the cD-rom drive, "E" is their usbEE kEE. Obviously not all systems will be like that, but it's common enough. On UNIX systems the location of floppy disks, installed programs, mounted USB keys and so on tend to move around unpredictably.
Incidentally, talking of legacy concepts, what do you think "mounting" is? It dates from the time when you had to mount tapes onto their reels!
licensing concerns (like XP workstation allowing only one user at a time);
I don't see how this would affect a command shell designed for personal use. I also don't understand how it only allows one user at a time - in the copies of XP I've seen multiple users can log in at once, then you can rapidly switch between them. If you are thinking of X and terminal servers, well, you can have a command line without that. Look at MacOS.
wide-spread security concerns resulting in the feature being turned off by default on most installations;
There's no evidence I can see that suggests this would be off by default. Actually MSH could be a lot more secure than the UNIX shell as it can be fully controlled by.NET Code Access Security, which is more fine grained than traditional UNIX permissions.
wide-spread fears of accidental and intentional incompatability;
By adding a new end-user feature? That never stopped them adding themes, Media Player, MSN Messenger, etc. Compatibility concerns for something totally new are far less serious.
being only available as part of an expensive (and extensive!) upgrade;
In contrast to what? Microsoft backport far more stuff than Linux vendors do, and Apple basically doesn't backport anything at all. That's $120 per upgrade, thanks very much.
Seriously. The guys working on MSH have blogs, I read a few, and they seemed very sharp to me. The MSH API seems quite lightweight and I suspect you'll be able to create new commandlets very easily - far easier than you can create new command line tools on Linux. Some of the examples they showed would require thousands of lines of code to write on Linux once you take into account the build system, the fact that they're usually written in C, the text parsing with extra checks for buffer overflows etc. Yet using the MSH API they fitted onto a single screen of text.
I'm not too worried, I don't use Linux over Windows just because of bash (surprise), I use it because it's Free (and it has some other neat features I like). Actually, most UNIX shells suck ass. Their builtin programming languages are hideously primitive, unintuitive, and are easy to screw up. Getting basic information out of common tools requires a guru-level knowledge of sed, awk and Perl style regular expressions which are themselves primitive, backwards and unintuitive.
You'd have to work pretty hard to produce a command line worse than the UNIX one (and no, cmd.exe does not count as "working hard", I suspect it's had about a weeks worth of work in the last decade).
That would be hard, MSH leverages.NET quite extensively. You might see a Mono Shell, or a Python Shell using the same concepts though.
It's rather sad to see people dismissing this so quickly. I can guarantee if this was an Objective-C based shell from Apple people would be slobbering all over it by now, and saying how innovative Apple were, probably with some jabs at Linux too. I remember seeing an initial presentation about MSH a while back and the thinking behind it impressed me then, I'll be keen to try this when it's fully released.
That was with XP Home. It definitely barfed when it saw Linux, as unplugging the disk let it continue (so it wasn't a case of the MBR on that drive being funny either).
More to the point, the Windows installer can't cope with the idea that you may want to install more than Windows. It took me a while to figure out that even if you were installing Windows to a totally different hard disk, the setup program would give an ambiguous error and refuse to proceed if it saw Linux on a different hard disk.
The solution? Unplug the hard disks power supply, and Windows setup is now happy. I'll take a non-broken installer with a few more clicks (none of which are hard) over that any day.
I think you misunderstood me - by 2 years I meant "in 2 years most people will have hopefully migrated to systems where this all Just Works out of the box, and so most people won't have problems anymore". I didn't mean "2 years to a solution" - like I said, the solution starts the day FC4 is released.
Interesting. Mozilla and firefox do not see some fonts that gucharmap sees. Mine do have antialiasing, but not on all machines. I am not sure why.
The charmap tool shows you any font, even ones that don't have the glyphs needed to render what Firefox wants to render. I suspect that's the issue. At least, I don't have any problems like you described.
They do, but you have to configure it separately for GTK and for QT. If you are not running Gnome or KDE it can be quite an experience to figure out where those settings live.
Well, Linux isn't really able to compete with Windows or MacOS X if you take away KDE/GNOME - they exist to provide centralised GUIs to configure things, amongst other purposes. So I'm not sure this is a valid criticism from an absolutist usability perspective. Now, there is an app that lets you set GTK+ settings without GNOME, but I don't remember what it's called because I run GNOME. It's just easier that way.
For example do xset fp commands actually change anything? Where do I set the path directories? Do I need to run xfs when using X over the network?
If you want to add fonts to legacy apps like xterm, then yes it's complicated and involves lots of magic commands. For other systems there is a GUI where you can drop fonts in and once you restart the app they should appear.
ALSA has dmix which does pretty much this, and it's enabled out of the box for apps that need it in Fedora Core 4 which should be out tomorrow.
There's still some disagreement on whether dmix is the way forward, but hopefully within a year or two software sound mixing will be like fonts are now - pretty much a solved problem.
Weird, I use FC3 and that mouse combination works fine here.
It's also worth noting that in FC4 the sound mixing issue should be nearly fixed, at least for apps that understand ALSA. Apps that only use OSS need to be wrapped with the aoss program to redirect them to use ALSA - not great, I will freely admit, but most apps these days do support ALSA so it's a rare problem. Hopefully aoss can be improved to the point where it can be LD_PRELOADED for everything so it works transparently.
You're mixing up stability (as in, crash-free-ness) of the software with stability (as in dependencies) of the repositories.
All Debian "Stable" means is that the packages and their inter-relations are stable, and that you can install it and log in and do some useful stuff. But every released Linux distro guarantees that.
It doesn't mean "this thing will never, ever fail" especially as the older releases typically incorporate fewer bugfixes.
What kind of developers, Windows or otherwise, can't learn how to write PHP or Qt/GTKmm based C++? They're not exactly new development paradigms or anything.
I suspect the company quoted in the article had a lot of developers who knew what they liked and liked what they knew. The idea of learning a new OS and new APIs didn't really appeal to them, so they just said "we can't do it!" and went off to hire new people.
I dunno. The other theory sounds more likely - Linux is competing very well with older UNIX based installations but isn't attacking the low end server market as well as it could (ASP compatibility?). And desktop is still at the "we're starting to take this seriously" stage rather than "mass deployment every week" stage.
I read somewhere that this study was itself funded indirectly by Microsoft, but who knows. The survey data seems credible. That said a reduction in the number of groups who said they were planning to evaluate it dropping a bit doesn't necessarily mean growth is slowing. Maybe it just means a lot of them got around to it?;)
Judging from a conversation I had with an Apple toolchain engineer a few months ago it appears they're seriously looking at switching to ELF from Mach-O.
Is it a software publisher that is approachable? Would they be willing to consider doing a compile of the application using winelib? That is make a win32 exe that runs on linux natively.
This is definitely an option. In fact you don't even need vendor co-operation, CodeWeavers can make apps run without access to the source code.
I work for CodeWeavers and I'll say now that for 250 licenses we can put a few hours into making a custom app work for you. For exact details you'd need to contact jwhite@codeweavers.com. How much effort it'd take to get the app to Gold status depends on a lot of things. It may require no effort at all, in which case your problem is already solved. Congratulations. You have a zero cost way to deploy this app.
It may be that the app basically does work, but it's not reliable or it suffers visual glitches. This is the sort of app we can often make work in return for guaranteed sales of X licenses, even without the source code.
It may be that the app won't start or won't install so you can't tell, but we can coax it into working and give you an evaluation. We have 4 developers who specialise in installers (2 in MSI, 2 in InstallShield respectively), so this is definitely possible. We usually do "kick the tires" evaluations either cheaply or for free.
Basically, the best solution for your desktop users is going to be a Wine/CrossOver based solution. The app will run at native or nearly native speed, you won't need an app server, it will integrate nicely with their desktop and appear in the menus, copy and paste will work etc. And you don't need any Windows licenses. Seriously, drop us a line.
So, wait -- WebCore is supposedly useless to the KHTML devs because it's so different, and yet, you're saying that KHTML isn't so different that the WebCore team can't use it?
It's not a case of how different they are, it's a case of Apple using MacOSX specific APIs in their patches, not splitting them up so they can't be merged without triggering regressions, not documenting what changes fix and so on.
Did you miss the part where Konqueror's Acid2 compliance was largely merged from WebCore?
The patches were released only after the KDE team went public on what a mess the whole situation was. And even after huge pressure on Apple, only half the patches were even usable. The others had to be rewritten.
Apple doesn't have anything the KHTML guys want.
The KDE guys disagree. I think they'd know better than either of us.
Even though the two teams worked independently, they benefited from having access to the other's code.
The Konqueror team don't have access to the Safari code, at least not in a form they can use. Apple do have access to the KHTML code in a usable form though, the KDE guys make sure it's available in the right way for everybody.
Does it really matter what Apple's motivations were? The end result is that Open Source development has helped both products.
Clearly it does matter what their motivations are, this always matters. It means in future open source projects will know what's coming when Apple decide to get "involved".
As to whether it helped both products, well of that I'm sceptical. A key KDE developer has very publically burnt out on KHTML because of Apples actions and worse, because of the community of Apple fanboys who switched the blame around onto the KDE people. After starting out optimistic he's now bitter. I'd say that's a pretty huge loss.
Meanwhile, Apple got the code to a rendering engine for free and gave back little to nothing. It's like TransGaming all over again.
Stating that the argument is flawed doesn't make it so, no matter how much Latin you through around.
GCC exists for minority platforms and this is fine, what Ulrich has a problem with is people insisting that they be supported at the cost of other platforms with more users. In this case "support" means "a patch which breaks FoobarIx gets backed out". This clearly isn't so fine. And yes GCC drops support for architectures and older modes frequently (you can always use old versions after all).
I don't know what your second point is on about. Ulrich Drepper works on systems programming tools, not "userland apps" (whatever you define them to be). He never said the GIMP shouldn't compile on OpenBSD, he said that the pain of supporting complex low level code like glibc on PA-RISC wasn't worth it (and he is probably right). So talking about non-systems level code isn't relevant here.
Your third point is equally mystifying - you say it "disproves me" without saying exactly what I was trying to prove in the first place. I never said anything about BSD emulation layers (which usually emulate syscalls not C libraries, by the way...).
Wow, it's not often I find myself defending Ulrich Drepper of all people, but I do think there's a huge misconception here.
People seem to be repeating a lot of "folk wisdom" about portability. Oh it's just bugs. Make your damn software clean you damn coder. Etc.
I can guarantee you that anybody who says this has never actually read the sources to glibc, binutils or gcc. Hell, they probably never even read the mailing lists! I have, and when Ulrich says an enormous amount of effort goes on supporting minority platforms he is totally correct. Hello, binutils isn't the GIMP people! Other platforms have totally different architectures and often need huge amounts of platform specific code from these projects. This isn't a case of sloppy coding, it's a case of massive amounts of work being done to support edge cases. Go read the sources to bfd sometimes. Adding support for one platform that uses different assumptions about basic things like memory layout can require huge reworkings of the code.
Essentially there are a lot of people spouting off here based on their experiences of compiling FooApp on FreeBSD or whatever. Have you written a C library? A threading library? No... then you are probably not really qualified to judge how much work this generates for Ulrich.
Oh, and for the guy later on in this thread who says "AIX is not a minority platform, WTF?" - I say to him WTF. AIX most definitely is a minority platform. Maybe not in the world he lives in, but in the real world Windows is dominant, sometimes people think about Linux/Mac or even FreeBSD and everything else barely registers at all unless you administer high end servers or work on embedded software (most people do not).
I've been bitten by this mentality before. Back when exec-shield was first developed, it broke Wine (which I work on). So I set out developing a fix. Eventually, I wrote a GNU linker script that arranged virtual memory such that things would work correctly even when exec-shield was active. But it didn't work, because of a simple bug in the kernel. No problem, right? Just fix the bug, right? Well, actually, somebody did. A patch was written, submitted, got into Andrew Mortons tree... and it didn't compile on Itanium. The original author didn't have access to such a machine, neither did I, and the person who reported the failure (who worked for Intel, IIRC) was overloaded with other work and couldn't fix it. So the patch was dropped.
In the end, a few months later, we had a different solution that was about a million times more complicated. Largely because a simple bugfix patch didn't compile for unspecified reasons on a platform nobody uses and this was grounds for it to be dropped. That mentality of "all computers are born equal" is why Debian has become a laughing stock and it cuts both ways.
Slashdot Mirror
But yes, I generally agree with you about people under-rating Yahoo. They're by no means a bad company, and have shown the ability to do cool stuff many times. Their new online music store seems pretty nifty, at least, more customisable than iTunes Music Store is. Only downer is it doesn't work on Linux (but then unless you buy Crossover neither does iTunes).
The guy was almost certainly looking at the Debian installer, which at least traditionally had a habit of asking lots of questions like that. It was basically a text book case of how not to design an easy to use installer. I have no idea if the new one is better in this regard, I never tried it, but it's still textual.
The reaction of computer scientists should be your guide. These people tend to know answers to questions, which you don't know enough to even ask.
How arrogant. I've done enough coding, and learned enough about usability, to know when somebody is making excuses about something that may have made sense 20 years ago but no longer does.
Now I'm not saying we should replace the unified heirarchy with driver letters on Linux, rather the way GNOME is going with showing multiple "roots" in the UI labelled by logical device names is a better approach. The UI is basically the same, in the new GTK+ file picker you have "Filesystem", "Home", "Desktop", "CD/DVD Drive" etc and they're mapped behind the scenes to wherever they're mounted.
The question here is, will significant numbers of Linux users migrate to the Mac? More interestingly, will significant numbers of Linux users contributing useful work migrate? To some extent, given how much software is open source, the latter is far more important than the former. For Apple and Microsoft, users are everything because without a critical mass of users commercial/proprietary ISV companies won't develop or port software. For Linux - while the support of commercial ISVs is certainly nice to have - it's not so intertwined with its survival.
Apple have solved this problem so far partly by writing tons of software itself (I think they have over a thousand people in their software division alone!) and also by leveraging their history - Microsoft may well make a profit on Office for the Mac today, but would it have been profitable to develop from scratch if not for the lawsuit they were so keen to defend? Would Adobe have ported Photoshop to MacOS X if not for the original MacOS Classic version that was written way back in the mists of time? And I suspect this approach will work seeing as how they make lots of money from iPods they can use to subsidise their OS development with so the usual app-support hurdles can be overcome. Their unbelievably loyal customer base doesn't hurt either.
Now while it's certainly true that raw numbers matter to Linux in terms of getting application (and maybe hardware) support, a more likely path for it to follow is deployment on the corporate desktop. Being able to deploy to pre-existing hardware en-masse is a huge advantage there, as is apps like Sabayon and ZENworks which make network administration very easy. Attacking the corporate desktop is where Novell and Red Hat are currently focussed - whilst companies like Linspire might be in trouble, the major employers of Linux developers aren't really interested in competing directly for Apples individual/home market share just yet.
In much the same way that iPod sales and a huge interest cashpile bankrolled the Mac development effort, sales of high end servers and support are bankrolling corporate desktop Linux development. Two different directions, two different paths, probably they'll meet at some point but it won't make that much difference until then.
Whilst the UNIX style unified directory hierarchy is aesthetically pleasing to computer scientists, I've never been convinced that it's really more usable. On Windows, people can learn a few simple letter to concept mappings "A" is the floppy disk, "C" is the stuff inside the Computer, "D" is the cD-rom drive, "E" is their usbEE kEE. Obviously not all systems will be like that, but it's common enough. On UNIX systems the location of floppy disks, installed programs, mounted USB keys and so on tend to move around unpredictably.
Incidentally, talking of legacy concepts, what do you think "mounting" is? It dates from the time when you had to mount tapes onto their reels!
licensing concerns (like XP workstation allowing only one user at a time);
I don't see how this would affect a command shell designed for personal use. I also don't understand how it only allows one user at a time - in the copies of XP I've seen multiple users can log in at once, then you can rapidly switch between them. If you are thinking of X and terminal servers, well, you can have a command line without that. Look at MacOS.
wide-spread security concerns resulting in the feature being turned off by default on most installations;
There's no evidence I can see that suggests this would be off by default. Actually MSH could be a lot more secure than the UNIX shell as it can be fully controlled by .NET Code Access Security, which is more fine grained than traditional UNIX permissions.
wide-spread fears of accidental and intentional incompatability;
By adding a new end-user feature? That never stopped them adding themes, Media Player, MSN Messenger, etc. Compatibility concerns for something totally new are far less serious.
being only available as part of an expensive (and extensive!) upgrade;
In contrast to what? Microsoft backport far more stuff than Linux vendors do, and Apple basically doesn't backport anything at all. That's $120 per upgrade, thanks very much.
Seriously. The guys working on MSH have blogs, I read a few, and they seemed very sharp to me. The MSH API seems quite lightweight and I suspect you'll be able to create new commandlets very easily - far easier than you can create new command line tools on Linux. Some of the examples they showed would require thousands of lines of code to write on Linux once you take into account the build system, the fact that they're usually written in C, the text parsing with extra checks for buffer overflows etc. Yet using the MSH API they fitted onto a single screen of text.
I'm not too worried, I don't use Linux over Windows just because of bash (surprise), I use it because it's Free (and it has some other neat features I like). Actually, most UNIX shells suck ass. Their builtin programming languages are hideously primitive, unintuitive, and are easy to screw up. Getting basic information out of common tools requires a guru-level knowledge of sed, awk and Perl style regular expressions which are themselves primitive, backwards and unintuitive.
You'd have to work pretty hard to produce a command line worse than the UNIX one (and no, cmd.exe does not count as "working hard", I suspect it's had about a weeks worth of work in the last decade).
It's rather sad to see people dismissing this so quickly. I can guarantee if this was an Objective-C based shell from Apple people would be slobbering all over it by now, and saying how innovative Apple were, probably with some jabs at Linux too. I remember seeing an initial presentation about MSH a while back and the thinking behind it impressed me then, I'll be keen to try this when it's fully released.
Autopackages can install both as user and as root. You get the choice when you click on them. Fully graphical installs too.
That was with XP Home. It definitely barfed when it saw Linux, as unplugging the disk let it continue (so it wasn't a case of the MBR on that drive being funny either).
The solution? Unplug the hard disks power supply, and Windows setup is now happy. I'll take a non-broken installer with a few more clicks (none of which are hard) over that any day.
I think you misunderstood me - by 2 years I meant "in 2 years most people will have hopefully migrated to systems where this all Just Works out of the box, and so most people won't have problems anymore". I didn't mean "2 years to a solution" - like I said, the solution starts the day FC4 is released.
The charmap tool shows you any font, even ones that don't have the glyphs needed to render what Firefox wants to render. I suspect that's the issue. At least, I don't have any problems like you described.
They do, but you have to configure it separately for GTK and for QT. If you are not running Gnome or KDE it can be quite an experience to figure out where those settings live.
Well, Linux isn't really able to compete with Windows or MacOS X if you take away KDE/GNOME - they exist to provide centralised GUIs to configure things, amongst other purposes. So I'm not sure this is a valid criticism from an absolutist usability perspective. Now, there is an app that lets you set GTK+ settings without GNOME, but I don't remember what it's called because I run GNOME. It's just easier that way.
For example do xset fp commands actually change anything? Where do I set the path directories? Do I need to run xfs when using X over the network?
If you want to add fonts to legacy apps like xterm, then yes it's complicated and involves lots of magic commands. For other systems there is a GUI where you can drop fonts in and once you restart the app they should appear.
There's still some disagreement on whether dmix is the way forward, but hopefully within a year or two software sound mixing will be like fonts are now - pretty much a solved problem.
It's also worth noting that in FC4 the sound mixing issue should be nearly fixed, at least for apps that understand ALSA. Apps that only use OSS need to be wrapped with the aoss program to redirect them to use ALSA - not great, I will freely admit, but most apps these days do support ALSA so it's a rare problem. Hopefully aoss can be improved to the point where it can be LD_PRELOADED for everything so it works transparently.
So, I guess I should re-iterate the original question - what does Debian offer these days?
All Debian "Stable" means is that the packages and their inter-relations are stable, and that you can install it and log in and do some useful stuff. But every released Linux distro guarantees that.
It doesn't mean "this thing will never, ever fail" especially as the older releases typically incorporate fewer bugfixes.
I suspect the company quoted in the article had a lot of developers who knew what they liked and liked what they knew. The idea of learning a new OS and new APIs didn't really appeal to them, so they just said "we can't do it!" and went off to hire new people.
I dunno. The other theory sounds more likely - Linux is competing very well with older UNIX based installations but isn't attacking the low end server market as well as it could (ASP compatibility?). And desktop is still at the "we're starting to take this seriously" stage rather than "mass deployment every week" stage.
I read somewhere that this study was itself funded indirectly by Microsoft, but who knows. The survey data seems credible. That said a reduction in the number of groups who said they were planning to evaluate it dropping a bit doesn't necessarily mean growth is slowing. Maybe it just means a lot of them got around to it? ;)
Judging from a conversation I had with an Apple toolchain engineer a few months ago it appears they're seriously looking at switching to ELF from Mach-O.
You might want to re-evaluate Wine, it's become a lot better than it was 3 years ago. And of course CodeWeavers are available to help if you need us.
This is definitely an option. In fact you don't even need vendor co-operation, CodeWeavers can make apps run without access to the source code.
I work for CodeWeavers and I'll say now that for 250 licenses we can put a few hours into making a custom app work for you. For exact details you'd need to contact jwhite@codeweavers.com. How much effort it'd take to get the app to Gold status depends on a lot of things. It may require no effort at all, in which case your problem is already solved. Congratulations. You have a zero cost way to deploy this app.
It may be that the app basically does work, but it's not reliable or it suffers visual glitches. This is the sort of app we can often make work in return for guaranteed sales of X licenses, even without the source code.
It may be that the app won't start or won't install so you can't tell, but we can coax it into working and give you an evaluation. We have 4 developers who specialise in installers (2 in MSI, 2 in InstallShield respectively), so this is definitely possible. We usually do "kick the tires" evaluations either cheaply or for free.
Basically, the best solution for your desktop users is going to be a Wine/CrossOver based solution. The app will run at native or nearly native speed, you won't need an app server, it will integrate nicely with their desktop and appear in the menus, copy and paste will work etc. And you don't need any Windows licenses. Seriously, drop us a line.
It's not a case of how different they are, it's a case of Apple using MacOSX specific APIs in their patches, not splitting them up so they can't be merged without triggering regressions, not documenting what changes fix and so on.
Did you miss the part where Konqueror's Acid2 compliance was largely merged from WebCore?
The patches were released only after the KDE team went public on what a mess the whole situation was. And even after huge pressure on Apple, only half the patches were even usable. The others had to be rewritten.
Apple doesn't have anything the KHTML guys want.
The KDE guys disagree. I think they'd know better than either of us.
The Konqueror team don't have access to the Safari code, at least not in a form they can use. Apple do have access to the KHTML code in a usable form though, the KDE guys make sure it's available in the right way for everybody.
Does it really matter what Apple's motivations were? The end result is that Open Source development has helped both products.
Clearly it does matter what their motivations are, this always matters. It means in future open source projects will know what's coming when Apple decide to get "involved".
As to whether it helped both products, well of that I'm sceptical. A key KDE developer has very publically burnt out on KHTML because of Apples actions and worse, because of the community of Apple fanboys who switched the blame around onto the KDE people. After starting out optimistic he's now bitter. I'd say that's a pretty huge loss.
Meanwhile, Apple got the code to a rendering engine for free and gave back little to nothing. It's like TransGaming all over again.
That alone is reason enough for me.
GCC exists for minority platforms and this is fine, what Ulrich has a problem with is people insisting that they be supported at the cost of other platforms with more users. In this case "support" means "a patch which breaks FoobarIx gets backed out". This clearly isn't so fine. And yes GCC drops support for architectures and older modes frequently (you can always use old versions after all).
I don't know what your second point is on about. Ulrich Drepper works on systems programming tools, not "userland apps" (whatever you define them to be). He never said the GIMP shouldn't compile on OpenBSD, he said that the pain of supporting complex low level code like glibc on PA-RISC wasn't worth it (and he is probably right). So talking about non-systems level code isn't relevant here.
Your third point is equally mystifying - you say it "disproves me" without saying exactly what I was trying to prove in the first place. I never said anything about BSD emulation layers (which usually emulate syscalls not C libraries, by the way ...).
People seem to be repeating a lot of "folk wisdom" about portability. Oh it's just bugs. Make your damn software clean you damn coder. Etc.
I can guarantee you that anybody who says this has never actually read the sources to glibc, binutils or gcc. Hell, they probably never even read the mailing lists! I have, and when Ulrich says an enormous amount of effort goes on supporting minority platforms he is totally correct. Hello, binutils isn't the GIMP people! Other platforms have totally different architectures and often need huge amounts of platform specific code from these projects. This isn't a case of sloppy coding, it's a case of massive amounts of work being done to support edge cases. Go read the sources to bfd sometimes. Adding support for one platform that uses different assumptions about basic things like memory layout can require huge reworkings of the code.
Essentially there are a lot of people spouting off here based on their experiences of compiling FooApp on FreeBSD or whatever. Have you written a C library? A threading library? No ... then you are probably not really qualified to judge how much work this generates for Ulrich.
Oh, and for the guy later on in this thread who says "AIX is not a minority platform, WTF?" - I say to him WTF. AIX most definitely is a minority platform. Maybe not in the world he lives in, but in the real world Windows is dominant, sometimes people think about Linux/Mac or even FreeBSD and everything else barely registers at all unless you administer high end servers or work on embedded software (most people do not).
I've been bitten by this mentality before. Back when exec-shield was first developed, it broke Wine (which I work on). So I set out developing a fix. Eventually, I wrote a GNU linker script that arranged virtual memory such that things would work correctly even when exec-shield was active. But it didn't work, because of a simple bug in the kernel. No problem, right? Just fix the bug, right? Well, actually, somebody did. A patch was written, submitted, got into Andrew Mortons tree ... and it didn't compile on Itanium. The original author didn't have access to such a machine, neither did I, and the person who reported the failure (who worked for Intel, IIRC) was overloaded with other work and couldn't fix it. So the patch was dropped.
In the end, a few months later, we had a different solution that was about a million times more complicated. Largely because a simple bugfix patch didn't compile for unspecified reasons on a platform nobody uses and this was grounds for it to be dropped. That mentality of "all computers are born equal" is why Debian has become a laughing stock and it cuts both ways.
So you're happy to take over cleaning my families computers of spyware, then?
Fine job, my ass. They got where they were through corruption and criminal activity. It is obscene.