Facebook was effectively invite only for a while until anyone over 13 could join up and that only seemed to increase the excitement. You want to be a part of what you can't have.
If I was Facebook I would be worried. Zuckerberg merely came up with a few chance ideas that made social networks......social. Relationship status and all that. Apart from that it's merely a fairly clean looking, unspectacular PHP application. Facebook's lead as the premier social networking site is everything. If they have to start competing on technology then the future doesn't look bright.
Unfortunately the article doesn't explain how they arrived at that conclusion other than it being their own opinion and possibly their own wish. That whole Longhorn WinFX finally coming to reality thing is another opinion piece. We heard many similar stories for Cairo many moons ago and that whole object oriented operating system rubbish around Windows 2000.
No, it isn't. Anyone saying that has zero credibility right off the bat. Seriously. The built-in migrations tools are a joke, bridging.Net and COM components is insanely unreliable not to mention a million other corner cases and few are going to buy in any kind of specialised migration tools to rewrite code in another technology that does the same thing. A requirement of a development tools is that you take your existing code, upgrade and are able to work with it straight away. VB.Net fails.
I have taken code from such developers and ported it to.net in days. More complex software may take a couple of weeks. I actually learned.net doing a very successful port.
Personal anecdotes (sound more like a wish to be honest) count for little I'm afraid. The VB world just has not moved along with VB.Net and that should tell you something. It's a waste of time, and I can guarantee you more complex software takes more than a couple of weeks. Then there are the inevitable problems once it's out in production. Most businesses have other ideas of how to use that time productively. Why do people constantly wonder why COBOL is still around?
That is very different from the fear of Microsoft entirely killing Silverlight, in that case you can be fear Silverlight may not even run in Win8 machines
It's not at all. While no one doubts that Silverlight will still run, as VB does, what developers are worried about is having to write new code in a new technology and possibly have to rewrite what they already have to take advantage of new features. That's something that Microsoft has done to screw developers over right back to the VB/VB.Net split.
Sigh........... There have been umpteen different frameworks over the past two years. For anyone starting off they have to decide what alphabet soup to use and for those who've been daft to actually write code they then have to decide whether to re-write in something new for reasons of support and wanting to use new features.
No one who uses that "Oh, but you can still use...." argument has the faintest idea what developers require from a framework. Take a look at why there is such a furore about Microsoft's future plans for Silverlight. Yes, I'm sure it will still run perfectly fine but developers do not want to have to rewrite code to get access to new features.
No it's not completely useless at all. You could still write apps in VB even now - no one was forcing you to move and indeed there may be no point unless you need.NET features.
What do you mean, it's not completely useless? In one fell swoop VB.Net became an inferior language to C# with no benefits. I tend to view a comment like that about the whole sorry situation as either being apologist or simply not understanding how software and development tools continue to be supported. Yes, I'm sure you can still crack open a copy of VB6 every now and again but if you want to write with something that's supported and has support for new features and use your old code it's going to be excruciatingly painful. No two ways about it.
And Microsoft and 3rd parties have always provide reasonable migration tools if you did choose to move. MS still provide migration tools and advice even now. It's certainly not a hands-off migration and it requires substantial effort but it is possible and unless VB programmers were complete morons, the differences between the two environments are not insurmountable to figure out.
Yes, everyone knows about those 'migration' tools. They're crap and completely unnecessary. Why anyone should need to go through some arduous migration process and 'get advice' because they've invested in a product and in their code for many years I have absolutely no idea. Note that we're not talking about some minor incompatibilities and some porting here. It's a total break. Any vendor who gets you to do that needs to be dropped.
It wasn't sane at all. VB was a shoddy language with some pseudo OO aspects, a handful of not especially powerful helper methods and functions.
I'm afraid you can pontificate all you want but Visual Basic became popular for many business applications because it was specifically a rapid application development language and people were happy with the pseudo OO aspects because many people simply didn't need or want to be dragged into the whole pointless OO development brain damage life cycle. People who don't know that and tow the party line.......I doubt whether they've even used VB. That was a big reason why people used it.
It should have been no surprise to anyone that MS concluded it was so broken that it was better to implement a VB dialect over.NET and supply migration tools rather than continue polishing a turd.
I'm sure that's how you'd like things to be but history views it differently. A 'VB dialect over.Net' was not what anyone wanted. What people wanted was for their code to work with minimal effort. What happened was that a whole installed base of apps were cut off from future development overnight, few if any VB apps were re-written, no one was going to completely migrate and re-write millions of lines of code and as such VB.Net is nowhere near as popular as it's original incarnation. In fact, I don't even know why they called it VB.
You are on the wrong track. Ask VB or web developers about their track records with MS.
Indeed. The same things have also been going on with.Net for about ten years as Microsoft seems to expect you to rewrite your code in some new.Net technology every couple of years. Witness the debacle with Winforms, WPF, XAML, Silverlight and whatever other alphabet soup Microsoft has had going on.
VB developers had an extremely long and successful run of it and even now you can still developm in VB.net.
Not a very great way of putting it. What it meant was that countless billions of lines of existing code were useless overnight in Microsoft's new development environment. That was the first time something like that had happened and the warning signs should have been there for everyone involved as the same thing happened with.Net over the years - Winforms, WPF, XAML, Silverlight........ Microsoft could never decide what it was doing and seemed to expect everyone to rewrite their code every couple of years. Some people just haven't learned.
And given that VB.net is basically a CLR compatible dialect it means you can work, reuse & integrate with every other.NET language and technology.
Great. Completely useless to the existing code already written in VB, but nevermind. It also became clear to everyone that VB.Net was totally useless. C# is the primary language to develop with in.Net and if you can do the same thing in all.Net languages and they only differ via syntax then why not just use C#? Witness how ActivePerl and Python sank like bricks.
That isn't to say developing in VB / VB.net was ever a rational or sane thing to do but I don't understand why anyone should complain about Microsoft's support over the years.
VB was completely sane to develop with, once it got somewhere near good enough around version 5/6. I know it's not fashionable amongst many, but a massive number of business applications were written with it and you didn't have to deal with a lot of time consuming stuff like memory management as you did with C++ or full blown object oriented concepts that you just didn't need most of the time. It was a very sensible thing to develop with for many applications. What Microsoft should have done was implemented and improved classic VB but implemented it on top of.Net so all you needed was a recompile as with previous versions.
It's nice of HP to tell us what government policy is...... I would imagine HP were a little scared that the government would get off the hardware upgrade treadmill a little too much if did too much cloud computing.
Eventually yes, I think the MPEG-LA will start getting increasingly desperate. However, if it's one thing we've learned from Android it's that no one wants to attack Google directly so it might get a little difficult.
Is it superior? By virtue of WebM and VP8 development being less well advanced you would hope that h.264 would be superior, but is that the case now? Hard to tell. There's certainly a lot of development happening with them so that's highly unlikely to continue to be the case if it is now.
I think we will see some action eventually if the MPEG-LA gets desperate and sees their 'license' fees seriously under threat. That might well happen sooner rather than later because with one fell swoop Google has critical mass with WebM with YouTube (Google just couldn't take the risk with moving goalposts and h.264) and there are already companies coming in with hardware acceleration and support for it - something that h.264 proponents like to tell us that it has and WebM and VP8 don't. The arguments for h.264 over WebM and VP8 are very quickly being knocked down.
It's tricky though, because judging from the whole Android nonsense no one wants to attack Google directly and if the MPEG-LA went after WebM and started demanding royalties from YouTube, as they inevitably will, Google will end up getting involved.
How did you architect the data storage for your applications? Is the data kept with the servers? How much data are you working with?
Because he hasn't actually done what he says he has. Note that he says he got this running by moving to another availability zone when it was multiple availability zones in one region that were affected.
You're stuck in a non-vm mentality it seems so I'm not sure why you're talking about things you don't understand.
I do understand it sweetheart because I do it for a fucking living. Give me a break with these Slashdot weenies.
How so? Why do you need that many more servers, you're either splitting traffic (so roughly the same number of servers) or simply having enough servers to pick up backups. Now data storage of duplicate backups may add some costs but that's neither servers nor complexity.
Understanding how EC2 works might be a good start for you. You need to replicate your machine images across different regions as well as incur traffic costs for backup and/or replication depending on how much data you can afford to lose. It's excessive complexity.
And as I said before and you seem to not understand, this is a cloud. If you main servers go down you don't need to have an identical copy of those servers running somewhere else 24/7. You simply create those copies on the fly. They cost you nothing until they're needed and when they are you're not paying for your main servers anyway.
That's because you have no idea what you're talking about and simply don't know the practicalities of what's involved.
You're assuming they can restore from backup, often companies don't want to lose the data since the last backup unless there is no choice. They also need to get a new server, image it, test it and actually put it in the data center. Sure they can automate it all but that, to quote your own words, that negates cost effectiveness.
What does this meaningless claptrap mean? You can have virtual machines in your own data centre you know?
It's also nothing that you can't do even more easily with amazon. My server was down at amazon for maybe 12 hours, that's when I noticed and simply reloaded it from backup in a different working availability zone. Took a few minutes.
No you didn't because this affected multiple availability zones in the same region. If you managed to do that you were simply lucky. RTFA.
Had I cared enough to keep backups in a different region then I could have simply reloaded it instantly over there.
As I've said already, that costs money in terms of replication and incurred bandwidth costs between regions. It simply isn't that easy and I doubt whether you use EC2 at all to be honest.
Hmmmm, yer. The whole apology is just not working for me.
Yes, you could architect much easier with cloud platforms to failover in different regions of the world, and Reese is simply plugging his own company's stuff on that one. However, that just makes things more expensive and negates the cost effectiveness of using cloud services in terms of more servers and increased complexity. Will most businesses really need to do that given that they could afford to put their stuff in a single data centre somewhere and when a sever fails simply restore from a backup and not be down for two days?
I just don't get the apologist's view of this at all. If you need and can afford to build that kind of infrastructure then that's great, but for the vast majority of businesses using cloud platforms their applications just don't warrant it.
Ha, ha. I love it when people write stuff like 'clearly not RTFA'.
Stating that Freedesktop is a broken standards body doesn't help anyone or anything, and is the usual classic excuse - as I'd stated. Guess who one of the main partes are who has made Freedesktop 'broken'? The blog doesn't address that. Using the Freedesktop disclaimer is just an excuse basically. It won't cover the fact that certain things were being agreed, and then simply reneged on and left to stagnate.
It's the usual wishy washy nonsense you get to cover up what the real issues are.
Exactly what you've described in your post, that's what. The 'Freedesktop isn't really a standards body' is the usual excuse that has always been wheeled countless times to justify decisions that have made things more difficult for free desktop developers and users. It doesn't answer or solve anything.
Unfirtunately, you haven't shown anything. You've simply repeated Dave Neary's blog post.
Well, it is his business considering that he and lots of other people within KDE have contributed greatly to Freedesktop and it has meant that those of us trying to use desktops with applications with differing toolkits that can actually work reasonably together. For some Gnome people to then wander along and say 'Freedesktop is broken and doesn't work' is simply not helpful in the slightest, nor does it cover them in any glory.
Oh, and Aaron has consistently been critical of Canonical over a long period of time over a lot of what they've done. That hasn't changed, although they share a little common ground here.
Which is kind of what you'd expect from Gnome - claim that Freedesktop doesn't work and that no ne understand how Gnome works, it's all just a big misunderstanding and everyone is equally to blame.
As far as user interfaces go, it is Havoc Pennington's way or the highway. Havoc has this crazy "usability comes from crippling" approach that dumbs down GNOME for entry-level users but makes it wholly unusable for power users.
It doesn't have to be like that. Windows and even the Mac present most things in a coherent and usable with way with a vast number of powerful options available if you need them. I've never got this mental disease from Gnome when it comes to usability. Entry-level users become more powerful users quite quickly, and most people are going to be severaly confused with the lack of functionality in Gnome coming from Windows or Mac.
That's why I used to be a staunch GNOME supporter and fairly anti-KDE (I'm still not a fan of how they handled the Qt/GPL license incompatibilities, the issue didn't get resolved until Qt was effectively forced to change their license.
The license wasn't a problem. Look at how far Qt has come on with the dual licensing approach versus the problems in manpower and resources that GTK now faces as it tries to catch up with features in other development platforms. Eventually LGPLing made things simpler, but no one is going to use a LGPLed toolkit if it's just not good enough. Besides, I didn't see a ton of non-GPL licensed applications being developed for Qt, GTK, KDE or Gnome that would have necessitated anything different.
Indeed. There have been other problems when it comes to getting a meaningful dialogue over the years, but Jeff Waugh has been a massive dagger in everyone's back. The guy is a control freak, amongst having other possible disorders.
They should have done what Google did - get a solid, working Linux phone OS built with a way of attracting developers and building apps. They had all the ingredients.
Re:They sort of didn't have to
on
Nokia Sells Qt
·
· Score: 2
Well, they didn't. They new about this arrangement when they bought Trolltech and I'd hardly call it a 'poison pill'. For all the work and testing that open source developers put into Qt it was always there to ensure that Trolltech played fair whilst still keeping their ability to create separately licensed versions on the commercial side. The arrangement has always worked very well.
I have no idea what Nokia expected to do with Qt to be honest.
Slashdot Mirror
Facebook was effectively invite only for a while until anyone over 13 could join up and that only seemed to increase the excitement. You want to be a part of what you can't have.
If I was Facebook I would be worried. Zuckerberg merely came up with a few chance ideas that made social networks......social. Relationship status and all that. Apart from that it's merely a fairly clean looking, unspectacular PHP application. Facebook's lead as the premier social networking site is everything. If they have to start competing on technology then the future doesn't look bright.
Unfortunately the article doesn't explain how they arrived at that conclusion other than it being their own opinion and possibly their own wish. That whole Longhorn WinFX finally coming to reality thing is another opinion piece. We heard many similar stories for Cairo many moons ago and that whole object oriented operating system rubbish around Windows 2000.
Porting from VB to VB.net is insanely easy.
No, it isn't. Anyone saying that has zero credibility right off the bat. Seriously. The built-in migrations tools are a joke, bridging .Net and COM components is insanely unreliable not to mention a million other corner cases and few are going to buy in any kind of specialised migration tools to rewrite code in another technology that does the same thing. A requirement of a development tools is that you take your existing code, upgrade and are able to work with it straight away. VB.Net fails.
I have taken code from such developers and ported it to .net in days. More complex software may take a couple of weeks. I actually learned .net doing a very successful port.
Personal anecdotes (sound more like a wish to be honest) count for little I'm afraid. The VB world just has not moved along with VB.Net and that should tell you something. It's a waste of time, and I can guarantee you more complex software takes more than a couple of weeks. Then there are the inevitable problems once it's out in production. Most businesses have other ideas of how to use that time productively. Why do people constantly wonder why COBOL is still around?
That is very different from the fear of Microsoft entirely killing Silverlight, in that case you can be fear Silverlight may not even run in Win8 machines
It's not at all. While no one doubts that Silverlight will still run, as VB does, what developers are worried about is having to write new code in a new technology and possibly have to rewrite what they already have to take advantage of new features. That's something that Microsoft has done to screw developers over right back to the VB/VB.Net split.
Sigh........... There have been umpteen different frameworks over the past two years. For anyone starting off they have to decide what alphabet soup to use and for those who've been daft to actually write code they then have to decide whether to re-write in something new for reasons of support and wanting to use new features.
No one who uses that "Oh, but you can still use...." argument has the faintest idea what developers require from a framework. Take a look at why there is such a furore about Microsoft's future plans for Silverlight. Yes, I'm sure it will still run perfectly fine but developers do not want to have to rewrite code to get access to new features.
Any differences are entirely superficial and pointless. In the end it all compiles to the same IL and they both have the same type system.
No it's not completely useless at all. You could still write apps in VB even now - no one was forcing you to move and indeed there may be no point unless you need .NET features.
What do you mean, it's not completely useless? In one fell swoop VB.Net became an inferior language to C# with no benefits. I tend to view a comment like that about the whole sorry situation as either being apologist or simply not understanding how software and development tools continue to be supported. Yes, I'm sure you can still crack open a copy of VB6 every now and again but if you want to write with something that's supported and has support for new features and use your old code it's going to be excruciatingly painful. No two ways about it.
And Microsoft and 3rd parties have always provide reasonable migration tools if you did choose to move. MS still provide migration tools and advice even now. It's certainly not a hands-off migration and it requires substantial effort but it is possible and unless VB programmers were complete morons, the differences between the two environments are not insurmountable to figure out.
Yes, everyone knows about those 'migration' tools. They're crap and completely unnecessary. Why anyone should need to go through some arduous migration process and 'get advice' because they've invested in a product and in their code for many years I have absolutely no idea. Note that we're not talking about some minor incompatibilities and some porting here. It's a total break. Any vendor who gets you to do that needs to be dropped.
It wasn't sane at all. VB was a shoddy language with some pseudo OO aspects, a handful of not especially powerful helper methods and functions.
I'm afraid you can pontificate all you want but Visual Basic became popular for many business applications because it was specifically a rapid application development language and people were happy with the pseudo OO aspects because many people simply didn't need or want to be dragged into the whole pointless OO development brain damage life cycle. People who don't know that and tow the party line.......I doubt whether they've even used VB. That was a big reason why people used it.
It should have been no surprise to anyone that MS concluded it was so broken that it was better to implement a VB dialect over .NET and supply migration tools rather than continue polishing a turd.
I'm sure that's how you'd like things to be but history views it differently. A 'VB dialect over .Net' was not what anyone wanted. What people wanted was for their code to work with minimal effort. What happened was that a whole installed base of apps were cut off from future development overnight, few if any VB apps were re-written, no one was going to completely migrate and re-write millions of lines of code and as such VB.Net is nowhere near as popular as it's original incarnation. In fact, I don't even know why they called it VB.
You are on the wrong track. Ask VB or web developers about their track records with MS.
Indeed. The same things have also been going on with .Net for about ten years as Microsoft seems to expect you to rewrite your code in some new .Net technology every couple of years. Witness the debacle with Winforms, WPF, XAML, Silverlight and whatever other alphabet soup Microsoft has had going on.
VB developers had an extremely long and successful run of it and even now you can still developm in VB.net.
Not a very great way of putting it. What it meant was that countless billions of lines of existing code were useless overnight in Microsoft's new development environment. That was the first time something like that had happened and the warning signs should have been there for everyone involved as the same thing happened with .Net over the years - Winforms, WPF, XAML, Silverlight........ Microsoft could never decide what it was doing and seemed to expect everyone to rewrite their code every couple of years. Some people just haven't learned.
And given that VB.net is basically a CLR compatible dialect it means you can work, reuse & integrate with every other .NET language and technology.
Great. Completely useless to the existing code already written in VB, but nevermind. It also became clear to everyone that VB.Net was totally useless. C# is the primary language to develop with in .Net and if you can do the same thing in all .Net languages and they only differ via syntax then why not just use C#? Witness how ActivePerl and Python sank like bricks.
That isn't to say developing in VB / VB.net was ever a rational or sane thing to do but I don't understand why anyone should complain about Microsoft's support over the years.
VB was completely sane to develop with, once it got somewhere near good enough around version 5/6. I know it's not fashionable amongst many, but a massive number of business applications were written with it and you didn't have to deal with a lot of time consuming stuff like memory management as you did with C++ or full blown object oriented concepts that you just didn't need most of the time. It was a very sensible thing to develop with for many applications. What Microsoft should have done was implemented and improved classic VB but implemented it on top of .Net so all you needed was a recompile as with previous versions.
It's nice of HP to tell us what government policy is...... I would imagine HP were a little scared that the government would get off the hardware upgrade treadmill a little too much if did too much cloud computing.
Eventually yes, I think the MPEG-LA will start getting increasingly desperate. However, if it's one thing we've learned from Android it's that no one wants to attack Google directly so it might get a little difficult.
Is it superior? By virtue of WebM and VP8 development being less well advanced you would hope that h.264 would be superior, but is that the case now? Hard to tell. There's certainly a lot of development happening with them so that's highly unlikely to continue to be the case if it is now.
I think we will see some action eventually if the MPEG-LA gets desperate and sees their 'license' fees seriously under threat. That might well happen sooner rather than later because with one fell swoop Google has critical mass with WebM with YouTube (Google just couldn't take the risk with moving goalposts and h.264) and there are already companies coming in with hardware acceleration and support for it - something that h.264 proponents like to tell us that it has and WebM and VP8 don't. The arguments for h.264 over WebM and VP8 are very quickly being knocked down.
It's tricky though, because judging from the whole Android nonsense no one wants to attack Google directly and if the MPEG-LA went after WebM and started demanding royalties from YouTube, as they inevitably will, Google will end up getting involved.
How did you architect the data storage for your applications? Is the data kept with the servers? How much data are you working with?
Because he hasn't actually done what he says he has. Note that he says he got this running by moving to another availability zone when it was multiple availability zones in one region that were affected.
You're stuck in a non-vm mentality it seems so I'm not sure why you're talking about things you don't understand.
I do understand it sweetheart because I do it for a fucking living. Give me a break with these Slashdot weenies.
How so? Why do you need that many more servers, you're either splitting traffic (so roughly the same number of servers) or simply having enough servers to pick up backups. Now data storage of duplicate backups may add some costs but that's neither servers nor complexity.
Understanding how EC2 works might be a good start for you. You need to replicate your machine images across different regions as well as incur traffic costs for backup and/or replication depending on how much data you can afford to lose. It's excessive complexity.
And as I said before and you seem to not understand, this is a cloud. If you main servers go down you don't need to have an identical copy of those servers running somewhere else 24/7. You simply create those copies on the fly. They cost you nothing until they're needed and when they are you're not paying for your main servers anyway.
That's because you have no idea what you're talking about and simply don't know the practicalities of what's involved.
You're assuming they can restore from backup, often companies don't want to lose the data since the last backup unless there is no choice. They also need to get a new server, image it, test it and actually put it in the data center. Sure they can automate it all but that, to quote your own words, that negates cost effectiveness.
What does this meaningless claptrap mean? You can have virtual machines in your own data centre you know?
It's also nothing that you can't do even more easily with amazon. My server was down at amazon for maybe 12 hours, that's when I noticed and simply reloaded it from backup in a different working availability zone. Took a few minutes.
No you didn't because this affected multiple availability zones in the same region. If you managed to do that you were simply lucky. RTFA.
Had I cared enough to keep backups in a different region then I could have simply reloaded it instantly over there.
As I've said already, that costs money in terms of replication and incurred bandwidth costs between regions. It simply isn't that easy and I doubt whether you use EC2 at all to be honest.
Hmmmm, yer. The whole apology is just not working for me.
Yes, you could architect much easier with cloud platforms to failover in different regions of the world, and Reese is simply plugging his own company's stuff on that one. However, that just makes things more expensive and negates the cost effectiveness of using cloud services in terms of more servers and increased complexity. Will most businesses really need to do that given that they could afford to put their stuff in a single data centre somewhere and when a sever fails simply restore from a backup and not be down for two days?
I just don't get the apologist's view of this at all. If you need and can afford to build that kind of infrastructure then that's great, but for the vast majority of businesses using cloud platforms their applications just don't warrant it.
Ha, ha. I love it when people write stuff like 'clearly not RTFA'.
Stating that Freedesktop is a broken standards body doesn't help anyone or anything, and is the usual classic excuse - as I'd stated. Guess who one of the main partes are who has made Freedesktop 'broken'? The blog doesn't address that. Using the Freedesktop disclaimer is just an excuse basically. It won't cover the fact that certain things were being agreed, and then simply reneged on and left to stagnate.
It's the usual wishy washy nonsense you get to cover up what the real issues are.
Exactly what you've described in your post, that's what. The 'Freedesktop isn't really a standards body' is the usual excuse that has always been wheeled countless times to justify decisions that have made things more difficult for free desktop developers and users. It doesn't answer or solve anything.
Unfirtunately, you haven't shown anything. You've simply repeated Dave Neary's blog post.
Well, it is his business considering that he and lots of other people within KDE have contributed greatly to Freedesktop and it has meant that those of us trying to use desktops with applications with differing toolkits that can actually work reasonably together. For some Gnome people to then wander along and say 'Freedesktop is broken and doesn't work' is simply not helpful in the slightest, nor does it cover them in any glory.
Oh, and Aaron has consistently been critical of Canonical over a long period of time over a lot of what they've done. That hasn't changed, although they share a little common ground here.
Which is kind of what you'd expect from Gnome - claim that Freedesktop doesn't work and that no ne understand how Gnome works, it's all just a big misunderstanding and everyone is equally to blame.
Bullshit.
As far as user interfaces go, it is Havoc Pennington's way or the highway. Havoc has this crazy "usability comes from crippling" approach that dumbs down GNOME for entry-level users but makes it wholly unusable for power users.
It doesn't have to be like that. Windows and even the Mac present most things in a coherent and usable with way with a vast number of powerful options available if you need them. I've never got this mental disease from Gnome when it comes to usability. Entry-level users become more powerful users quite quickly, and most people are going to be severaly confused with the lack of functionality in Gnome coming from Windows or Mac.
That's why I used to be a staunch GNOME supporter and fairly anti-KDE (I'm still not a fan of how they handled the Qt/GPL license incompatibilities, the issue didn't get resolved until Qt was effectively forced to change their license.
The license wasn't a problem. Look at how far Qt has come on with the dual licensing approach versus the problems in manpower and resources that GTK now faces as it tries to catch up with features in other development platforms. Eventually LGPLing made things simpler, but no one is going to use a LGPLed toolkit if it's just not good enough. Besides, I didn't see a ton of non-GPL licensed applications being developed for Qt, GTK, KDE or Gnome that would have necessitated anything different.
That's your opinion.
Indeed. There have been other problems when it comes to getting a meaningful dialogue over the years, but Jeff Waugh has been a massive dagger in everyone's back. The guy is a control freak, amongst having other possible disorders.
They should have done what Google did - get a solid, working Linux phone OS built with a way of attracting developers and building apps. They had all the ingredients.
Well, they didn't. They new about this arrangement when they bought Trolltech and I'd hardly call it a 'poison pill'. For all the work and testing that open source developers put into Qt it was always there to ensure that Trolltech played fair whilst still keeping their ability to create separately licensed versions on the commercial side. The arrangement has always worked very well.
I have no idea what Nokia expected to do with Qt to be honest.
I wasn't aware they had their own platforms that they rely on for their current market share like Nokia do.
Well, obviously not.