The KDE 4.0 release was a total management cock up from start to finish.../blockquote>
Hmmmm, it wasn't from KDE's perspective. It's the way things have always worked. The KDE developers set themselves some goals for KDE 4.0 and they achieved them - mainly API and ABI stability. What happened was that distributors then blindly started compiling and packaging it and then whinging when they found out that their users weren't too happy with it. Virtually all distributors are braindead when it comes to putting together a whole system and looking intelligently at the software they want to use. It's why we have PulseAudio being thrown into desktop systems today. That thing isn't stable at all, let alone feature complete.
Just because you don't understand it, don't think that the people who are talking about it don't either.
No, it's because you have an extremely narrow definition of what 'usable' is for an end user, probably as a result of reading far too many sets of HIGs. You're not alone. It's a mental disease.
Usability != functionality. Usability is an aspect of functionality.
No it isn't. It's the other way on. Being functional makes a system usable. I'm sure we can all aspire to some user interface idea of zen where we create a desktop with one button in the middle of the screen, but that's 'simplicity' and not usability. Usability is about what you can actually 'do' with a system. As such, functionality is a large aspect of usability because usability is a far wider topic than just the human computer interface.
The Mac is a system where a lot of effort has been put into improving usability. To a lesser extent, Windows also has had effort put into usability--consider the changes to the task bar in Windows 7. On Linux, usability is generally an afterthought
Windows has the most applications. Mac OS X comes next with less applications. Linux has far less applications and functionality, which is why you see Rails developers using Mac OS to develop and deploying to Linux because they have stuff like Textmate. The beauty and 'usability' of Mac OS with respect to its interface comes a distant second to how 'usable' it is from a functional perspective and what you can actually do with it.
like you stated, "a cherry on top".
Maybe I didn't make myself clear. Usability with respect to interfaces is getting obsessed with the cherry before you've actually baked the cake or even got the ingredients. You need to look at how usable your system is with respect to what people want to do first and foremost, and that means applications and functionality.
No, usability is not about functionality, it's about how that functionality works.
When you are trying to sell a desktop to people that has less functionality than where they've come from on Mac and Windows then yer, usability has everything to do with functionality. How can you talk about how functionality works when you don't have it?
This focus on human-computer interaction is something the Mac excels at. People don't point to it as inspiration because it's pretty. They point to it because it's more usable. Its prettiness is just one aspect of its usability.
That's one of the most meaningless statements ever and pretty much validates what I said. People throw the term 'usability' around with respect to Macs as some ideal without really any clue what they're talking about. It's almost as if they've heard that Macs are usable and therefore that's what they need to be like. A right-to-left button ordering doesn't make a Mac more usable. Neither does one-click mouse presses. Windows still has more applications available than Macs and for most it is still more usable as a result because.......you can use it to perform a wider variety of tasks. Usability with respect to human computer interaction, meaning the interface for most people, is a cherry on top of a very large cake. That's not desktop Linux's problem right now.
To be clear, functionality is important, but it's not the same as usability. To be usable, a system needs functions, but merely having the functions doesn't make a system terribly usable.
To be clear, without functionality then you can never make a system usable. It's all about what software does for people. It's all about the applications. If it doesn't do what people in the world want and are doing with their computers then it doesn't make any difference whatsoever how 'usable' you make your current, limited system. Anything else is just hot air.
This is basically just a gigantic band aid, and is unlikely to be successful. Most of what needs doing is to fill in glaring gaps of functionality in software that is now ten years old or more. Much of what people will put in there will already have bugs in an upstream Bugzilla somewhere - years old with no resolution other than WONTFIX. I fail to see how that will change.
I really hate that term 'usability' that a lot of people never define and expect to be the answer to their troubles. It gets thrown around by many in the open source desktop world mainly as a response to mask the internal troubles in the software that they're using and if someone starts talking about 'usability' and 'Mac OS' as benchmarks then maybe people will think 'Hey, they're going to be as cool as Macs!' and that they're doing something about the issues and it will all go away. Usability is about far more than making some sad Mac clone. It's about developers, developers, developers, developers - creating the useful applications and functionality that people want, making it easy for developers to create it and getting that functionality to users. Windows has that. Mac OS has that (albeit with a few speed bumps), and can run the open source software most open source developers use, so it's what you're going to see most of them use.
The Linux desktop is not the answer. It doesn't have to be that way but it's going to take a distributor to really grab hold of the situation, make sensible software choices on behalf of developers and users and identify just what system it is they're putting together. Given that we have desktops in the open source world that have limited functionality in the name of 'simplicity' (read JoelSpolsky on 80/20 method of software development - http://www.joelonsoftware.com/articles/fog0000000020.html) and we have brain damage such as PulseAudio that distributors readily lap up without any thought then I really cannot see who's going to do it. 'Just Works' is so far away it's just stopped being funny.
That's a pretty accurate description of what Ares is. What Apollo 13 taught us is that getting to and from the moon and other bodies, regularly and safely, is damn difficult. You need a lot of unseen infrastructure in place to start making that happen. You're not going to do it with Apollo + 40 years.
Might be true if you use a slipstick or pen and paper to do your arithmetic. If, like most everyone, you use a calculator or computer, the ease of use argument vanishes.
Nope, it doesn't. Someone has to program that arithmetic, and as we've seen it can go spectacularly wrong.
It's not a question of what you are used to, it's a question of picking the right units for a complex project. Ten millimetres to the centimetre, one hundred centimetres to the metre and one thousand metres to the kilometre. It's easy to understand and far less easy to screw up when you're doing arithmetic on them. Not using newtons to measure force is absolute sacrilege in this day and age. Using newtons to measure force, one newton per metre of work is equal to one joule in energy terms. Easily convertible units that are far less prone to stupid errors when you work with them.
Culturally people will always pick the units they feel are best for what they're doing which is why the EU is having so much trouble mandating units of measure, but not to use easily convertible SI units for a project like this with a lot of interconnecting paths is just incredibly backward.
I care so little that I still cannot spell BluRay as Blu-ray, even when it's in front of me. Maybe the 'Blu-ray' people need a three letter acronym for the format that is easily remembered and spelt;-).
That's because no one cares about HD formats. I actually know what the formats mean, unlike most people, and I am interested in better picture and sound quality but I simply have no desire whatsoever or the budget to replace my huge collection of DVDs and buy a newer, more expensive player to go with my HDTV. DVDs are really cheap now so why bother? Given the fact that most people have no clue at all how to set up surround sound, and it takes a while for most of us techies to get right, then I fail to see how on Earth a better sounding audio format is going to help BluRay over DVDs, Dolby Digital and DTS (which virtually no one uses for the same reasons) either. Most surround sound is downmixed to two channels. As an interesting aside, I wonder how many have just thought that BluRay was compatible with their existing DVD player, put it in, discovered it wouldn't play and then returned it?
Even HD generally is DoA for me. BluRay was completely stillborne. The only thing I bought a HDTV for was to get a bigger screen. I wasn't interested in its resolution. Seriously, save your money on extra money for HD broadcasts and just spend the money you save on a Pioneer that has an excellent SD picture or a new tuner box that has the best deinterlacer money can buy. I got a far better picture than my TV alone simply by using a MythTV box and using the Yadif (2x) deinterlacer. There'll be lots of commercially available stuff you can buy that will do the job and save you money.
Yes, I know HD looks better and its been really impressive on the systems I've seen, but like most I suspect, when push comes to shove I just cannot be bothered to pay for the privilege or jump through all of the pointlessly annoying technical hoops. I did it once. I tried to get a BluRay player connected to a TV through a receiver and HDCP refused to play ball at all. Now I just use HDMI where I know HDCP won't be involved, and that means no BluRay. Hey, at least I get a picture on the screen.
Having read this more this just strikes me as incredibly stupid. Did they publish this? Surely we're just talking about a timeout implementation here where the web server will say "Ahhhh, well you didn't complete that header, bye, bye"?
Could you potentially get around this if you're proxying to another web server, say lighttpd or Mongrel, or will this just blanketly affected Apache if you have it in front? I'm gathering the latter from the article:
At the moment I'm not sure what can be done in Apache's configuration to prevent this attack - increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.
Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server. I wonder how that fares?
Yes, it is. Unless MS has filed patents, they can't go and retroactively request patents on material they've already published.
It's all speculation, smoke and mirrors as to what might happen and is simply not borne out by what's happened with the abuse of the patent system over the past few years. An explicit and publicly available patent waiver like those made available by Google and even Sun so everyone knows the score could solve this in seconds. Anything else is just outright speculation that merits no discussion because there can be no resolution.
You keep saying that, and yet you're still wrong, no matter how many times you repeat it.
That patent doesn't just apply to.NET. They use.NET as an example of an API
YES, it is. They are providing a background as to what their claims apply to. That amount of detail is not given as an example or merely as window dressing. Web services amongst other essential APIs in.Net IS what they are describing.
a) the claims section makes no reference to.NET and it's the claims that outline the coverage of the patent...
It doesn't matter. The detail section expands on what they mean regarding their claims, and they describe the API and namespaces in detail there. You only have to look at the abstract to see what it means:
An application program interface (API) provides a set of functions for application developers who build Web applications on Microsoft Corporation's.NET.TM. platform.
Meanwhile, you Mono/patent trolls have yet to cite single additional patent over and above this one...
Running around shouting "Show me a patent!" isn't good enough. We should have learned it isn't good enough by now. An explicit patent waiver made public is all that is required, and yet the Mono proponent trolls still want to cover this up for Microsoft with non-existent letters and smoke and mirrors postings on mailing lists.
Feel free to mod the parent up more, because that, sadly, is a true reflection of the way things have been for most of the past ten years - not just now. I worked somewhere eight years ago where someone realised that a desktop 1.4GHz Athlon had several times the performance of an expensive UltraSPARC III whilst troubleshotting some Python and Zope performance issues. It was justified because it was an 'enterprise' piece of kit and no one wanted to believe that they wasted their money on something so expensive.
To get close to an off-the-shelf AMD or Intel system performance-wise your SPARC systems need to be running hell-for-leather at 100%, drawing maximum power permanently. The Xeon or Opteron systems will be able to scale up and down far more comfortably, so when comparing these systems you are never comparing apples with apples because the performance is just not comparable. Unless you have thousands of *completely independent* requests to handle per second then a SPARC system is useless to you and the writing has been on the wall on that for the past ten years.
You realize that the cheapest SPARC can handle more threads per cycle than a dual-quad Xeon, and do it while using less electricity, right?
The problem is that a Xeon will complete each thread [task] in far less time than the SPARC and be on to the next one, and the workloads that most organisations have are entirely dependant on completing ever increasing single tasks in the shortest amount of time possible.
As soon as a group of people got into Sun, looked at the costs of maintaining and pumping research and development into their hardware, looked at the relative performance from SPARC versus competitors using x86 and ultimately looked at the bottom line objectively without being stupidly protectionist, then the next step was going to be shutting down Sun's production of Rock and SPARC and moving it to Fujitsu as a supplier to save money. However, even that probably won't be enough as I'm not sure Fujitsu will be able to keep SPARC viable themselves. SPARC has had two, possibly three, options written on the wall for the past ten years:
1. Catch up to x86 platforms in terms of raw performance as most SPARC systems have tended to overlap with workloads x86 systems have taken over. Papering over cracks by promoting 'CoolThreads' and parallel processing as a way around this performance gap was never going to work. I can remember almost ten years ago working somewhere where a person discovered that their Athlon 1.4GHz desktop system had several times the performance of their UltraSPARC III server and could complete tasks several times sooner. Cue lots of panic as UltraSPARC was justified because it was 'enterprise' reliable.
2. Accept the inevitable and throw the towel in.
3. The third way: Do what IBM has done with Power and push it into a high-end and high premium niche. This is difficult because IBM itself can only cover Power by selling mainframe packages and a whole bunch of add-ons to make it pay. Sun have had difficulty with this because their hardware division has always relied on hardware sales themselves.
Option 2 has clearly become the only way out once Sun's difficulties resulted in a takeover and as poor as Oracle might be at some things they are extremely successful at judging bottom lines.
Read the detail at the bottom behind the claims they're making. It becomes clear that they are ring-fencing certain APIs in any CLR compatible implementation mainly to do with web services but also APIs that seem to be essential to get a working CLR, but are not in the ECMA specifications. Implement ECMA and you basically have something akin to Rotor, which does pretty much nothing.
You failed to grasp the point of TFA. The point here is that using an encumbered format when we already live in a heavily proprietary and encumbered world with regards to the web and multimedia already, be it Flash or Windows Media, when it goes against the spirit of what the video tag was supposed to promote is not a particularly great idea. The relative quality of H.264 and Ogg Theora is just a red herring next to that, especially with respect to the inferior video quality we have through Flash and YouTube today. I think Chris DiBona knows it's a red herring as well, but they have to try and explain away their use of an encumbered format in some way.
Even then though, you fail on understanding TFA completely anyway because the issue Chris raised was not about quality but about the increased bandwidth requirements. That definitely is a red herring and the linked article pointed that out. So the text of the Slashdot article is a bit off-base in what the article was trying to say? Tell me something new. It wouldn't hurt to just read it.
With all that said; is there any reason they can't add Theora support later?
They could, but the format they support first has implications. Picking a far less free and encumbered format is not a great start.
On another related note, I was going to say that if BluRay and AACS do end up getting reliably cracked and 'free' copies of films can be made then the bizarre twisted thing is that it might just end up making BluRay ubiquitously popular and give it the critical mass it needs to pull DVD back.
Presumably, this it the 'analogue hole' that they have talked about 'fixing' for a number of years now with a number of DRM companies coming out of the woodwork to say they can do it, ripping off some money and then disappearing with their directors retiring to some island somewhere with naked women?
Any techology that relies on a device sold and physically owned by a consumer denying access to said consumer is doomed to failure. Rinse and repeat.
It's one of the reasons, but certanly not the main one, why I am totally non-plussed by so-called 'High Definition' and BluRay. I did try setting up a theatre system once for someone with a receiver box relaying video through HDMI to a TV. HDCP refused to play ball because the BluRay player didn't like the arrangement. Hmmmmm. Not only do I get to not watch something because of a DRM system, I also have to buy completely new content that is currently a lot more expensive. Bound to be a success.
For a UI, writing the code just isn't the hard part. The hard part is designing the UI specification so that you know exactly how you want it to behave in every situation. Once you have that, coding to spec is a matter of man hours and testing...
Anybody who has written code for a UI, user facing, system knows how stupid that statement is. When you're replicating large parts of UI functionality on different platforms that is doubly so.
Keep in mind that no one's talking about rewriting the engine for each OS.
Firefox didn't either. It hasn't helped their cross-platform ambitions. Most of their issues are UI tie-ins and working out how to do certain UI things on different platforms.
Also, people don't expect exactly the same behavior from the UI cross platform; quite the opposite in fact.
In this case that's wrong. Chrome is a unique application that doesn't look like many other apps that you'll run natively. As I'd said though, if you want an application to run well cross-platform then you need to minimise bugs and replication between ports. No one cares if your app looks native if it is crap.
Qt may be a cross platform toolkit, but the reality is that you don't get the same level of responsiveness out of it on all platforms as you can get using platform specific tools.
Oh please. Qt applications aren't Java ones, they're natively compiled and you're going to need to back that up with something for it to mean anything. I doubt whether you can get less responsive than Firefox on Linux which is built with a similar approach.
Besides, if you're creating cross-platform apps then you trade off certain things to make sure that your ports to different platforms actually work properly. Going for some mythical responsiveness isn't going to matter if your port is just plain inferior and people don't care about the bugs or features for it.
Chrome, it's definitely the right choice to use the best tools available on each platform even if it means rewriting a lot of code.
If you believe that's acceptable for any application, especially one that people expect to work in the same way on each platform, then you're nuts.
Google have decided to write a new GUI for every platform, and I think they are probably correct to do this.
Hmmmm. Writing an application that you expect to work in the same way across all platforms, minus slight GUI changes, whilst making sure that needless and difficult to reproduce bugs on different platforms are minimised, or at least known about? I doubt many sensible application developers would agree with you.
Besides, it's quite easy to write a cross-platform core with something like Qt and then make specific platform changes where needed, so I never understood where the Chrome devs' arguments were going with that one.
Once that choice is made, all you are doing is picking a toolkit for Linux. GTK+ has the advantages of being familiar to the chrome devs
Well, no you're not because the Chrome devs have already been bitching about how poor GTK+ is from the back of their hands. It's very, very difficult to reuse and extend the toolkit for the kinds of GUI effects they want to achieve and given that extending GTK+ has historically been done by using brain damage like libsexy, libegg and even copying and pasting code into an application (Chrome on Linux is currently a 500 meg executable that draws a window) then the choice about what toolkit is suitable is pretty damn clear. You even have an implementation of WebKit directly available in Qt. It's virtually impossible to justify GTK+ rationally given the type of application they are developing.
being the most widely-used toolkit (and therefore appearing native for the largest number of users)
Qt ties into GTK's look and feel and has done for some time. You need not alienate anyone.
and being "good enough".
Heh.
It's crystal clear what's going to happen - a piss poor Linux port with bugs that can't be reproduced on Mac OS and particularly Windows and where no one can be bothered and there isn't the time, resources or motivation to actually fix them. It's why Firefox is so poor on Linux when compared to the Windows port.
Slashdot Mirror
Have they bred them with frickin' laser beams though?
No, it's because you have an extremely narrow definition of what 'usable' is for an end user, probably as a result of reading far too many sets of HIGs. You're not alone. It's a mental disease.
No it isn't. It's the other way on. Being functional makes a system usable. I'm sure we can all aspire to some user interface idea of zen where we create a desktop with one button in the middle of the screen, but that's 'simplicity' and not usability. Usability is about what you can actually 'do' with a system. As such, functionality is a large aspect of usability because usability is a far wider topic than just the human computer interface.
Windows has the most applications. Mac OS X comes next with less applications. Linux has far less applications and functionality, which is why you see Rails developers using Mac OS to develop and deploying to Linux because they have stuff like Textmate. The beauty and 'usability' of Mac OS with respect to its interface comes a distant second to how 'usable' it is from a functional perspective and what you can actually do with it.
Maybe I didn't make myself clear. Usability with respect to interfaces is getting obsessed with the cherry before you've actually baked the cake or even got the ingredients. You need to look at how usable your system is with respect to what people want to do first and foremost, and that means applications and functionality.
When you are trying to sell a desktop to people that has less functionality than where they've come from on Mac and Windows then yer, usability has everything to do with functionality. How can you talk about how functionality works when you don't have it?
That's one of the most meaningless statements ever and pretty much validates what I said. People throw the term 'usability' around with respect to Macs as some ideal without really any clue what they're talking about. It's almost as if they've heard that Macs are usable and therefore that's what they need to be like. A right-to-left button ordering doesn't make a Mac more usable. Neither does one-click mouse presses. Windows still has more applications available than Macs and for most it is still more usable as a result because.......you can use it to perform a wider variety of tasks. Usability with respect to human computer interaction, meaning the interface for most people, is a cherry on top of a very large cake. That's not desktop Linux's problem right now.
To be clear, without functionality then you can never make a system usable. It's all about what software does for people. It's all about the applications. If it doesn't do what people in the world want and are doing with their computers then it doesn't make any difference whatsoever how 'usable' you make your current, limited system. Anything else is just hot air.
This is basically just a gigantic band aid, and is unlikely to be successful. Most of what needs doing is to fill in glaring gaps of functionality in software that is now ten years old or more. Much of what people will put in there will already have bugs in an upstream Bugzilla somewhere - years old with no resolution other than WONTFIX. I fail to see how that will change.
I really hate that term 'usability' that a lot of people never define and expect to be the answer to their troubles. It gets thrown around by many in the open source desktop world mainly as a response to mask the internal troubles in the software that they're using and if someone starts talking about 'usability' and 'Mac OS' as benchmarks then maybe people will think 'Hey, they're going to be as cool as Macs!' and that they're doing something about the issues and it will all go away. Usability is about far more than making some sad Mac clone. It's about developers, developers, developers, developers - creating the useful applications and functionality that people want, making it easy for developers to create it and getting that functionality to users. Windows has that. Mac OS has that (albeit with a few speed bumps), and can run the open source software most open source developers use, so it's what you're going to see most of them use.
The Linux desktop is not the answer. It doesn't have to be that way but it's going to take a distributor to really grab hold of the situation, make sensible software choices on behalf of developers and users and identify just what system it is they're putting together. Given that we have desktops in the open source world that have limited functionality in the name of 'simplicity' (read JoelSpolsky on 80/20 method of software development - http://www.joelonsoftware.com/articles/fog0000000020.html) and we have brain damage such as PulseAudio that distributors readily lap up without any thought then I really cannot see who's going to do it. 'Just Works' is so far away it's just stopped being funny.
That's a pretty accurate description of what Ares is. What Apollo 13 taught us is that getting to and from the moon and other bodies, regularly and safely, is damn difficult. You need a lot of unseen infrastructure in place to start making that happen. You're not going to do it with Apollo + 40 years.
Nope, it doesn't. Someone has to program that arithmetic, and as we've seen it can go spectacularly wrong.
It's not a question of what you are used to, it's a question of picking the right units for a complex project. Ten millimetres to the centimetre, one hundred centimetres to the metre and one thousand metres to the kilometre. It's easy to understand and far less easy to screw up when you're doing arithmetic on them. Not using newtons to measure force is absolute sacrilege in this day and age. Using newtons to measure force, one newton per metre of work is equal to one joule in energy terms. Easily convertible units that are far less prone to stupid errors when you work with them.
Culturally people will always pick the units they feel are best for what they're doing which is why the EU is having so much trouble mandating units of measure, but not to use easily convertible SI units for a project like this with a lot of interconnecting paths is just incredibly backward.
I care so little that I still cannot spell BluRay as Blu-ray, even when it's in front of me. Maybe the 'Blu-ray' people need a three letter acronym for the format that is easily remembered and spelt ;-).
That's because no one cares about HD formats. I actually know what the formats mean, unlike most people, and I am interested in better picture and sound quality but I simply have no desire whatsoever or the budget to replace my huge collection of DVDs and buy a newer, more expensive player to go with my HDTV. DVDs are really cheap now so why bother? Given the fact that most people have no clue at all how to set up surround sound, and it takes a while for most of us techies to get right, then I fail to see how on Earth a better sounding audio format is going to help BluRay over DVDs, Dolby Digital and DTS (which virtually no one uses for the same reasons) either. Most surround sound is downmixed to two channels. As an interesting aside, I wonder how many have just thought that BluRay was compatible with their existing DVD player, put it in, discovered it wouldn't play and then returned it?
Even HD generally is DoA for me. BluRay was completely stillborne. The only thing I bought a HDTV for was to get a bigger screen. I wasn't interested in its resolution. Seriously, save your money on extra money for HD broadcasts and just spend the money you save on a Pioneer that has an excellent SD picture or a new tuner box that has the best deinterlacer money can buy. I got a far better picture than my TV alone simply by using a MythTV box and using the Yadif (2x) deinterlacer. There'll be lots of commercially available stuff you can buy that will do the job and save you money.
Yes, I know HD looks better and its been really impressive on the systems I've seen, but like most I suspect, when push comes to shove I just cannot be bothered to pay for the privilege or jump through all of the pointlessly annoying technical hoops. I did it once. I tried to get a BluRay player connected to a TV through a receiver and HDCP refused to play ball at all. Now I just use HDMI where I know HDCP won't be involved, and that means no BluRay. Hey, at least I get a picture on the screen.
Having read this more this just strikes me as incredibly stupid. Did they publish this? Surely we're just talking about a timeout implementation here where the web server will say "Ahhhh, well you didn't complete that header, bye, bye"?
Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server. I wonder how that fares?
IIS is not vulnerable, as confirmed in TFAs and the summary. Seems as though a DoS attack has affected some peoples' eyes.
It's all speculation, smoke and mirrors as to what might happen and is simply not borne out by what's happened with the abuse of the patent system over the past few years. An explicit and publicly available patent waiver like those made available by Google and even Sun so everyone knows the score could solve this in seconds. Anything else is just outright speculation that merits no discussion because there can be no resolution.
YES, it is. They are providing a background as to what their claims apply to. That amount of detail is not given as an example or merely as window dressing. Web services amongst other essential APIs in .Net IS what they are describing.
It doesn't matter. The detail section expands on what they mean regarding their claims, and they describe the API and namespaces in detail there. You only have to look at the abstract to see what it means:
Running around shouting "Show me a patent!" isn't good enough. We should have learned it isn't good enough by now. An explicit patent waiver made public is all that is required, and yet the Mono proponent trolls still want to cover this up for Microsoft with non-existent letters and smoke and mirrors postings on mailing lists.
Feel free to mod the parent up more, because that, sadly, is a true reflection of the way things have been for most of the past ten years - not just now. I worked somewhere eight years ago where someone realised that a desktop 1.4GHz Athlon had several times the performance of an expensive UltraSPARC III whilst troubleshotting some Python and Zope performance issues. It was justified because it was an 'enterprise' piece of kit and no one wanted to believe that they wasted their money on something so expensive.
To get close to an off-the-shelf AMD or Intel system performance-wise your SPARC systems need to be running hell-for-leather at 100%, drawing maximum power permanently. The Xeon or Opteron systems will be able to scale up and down far more comfortably, so when comparing these systems you are never comparing apples with apples because the performance is just not comparable. Unless you have thousands of *completely independent* requests to handle per second then a SPARC system is useless to you and the writing has been on the wall on that for the past ten years.
The problem is that a Xeon will complete each thread [task] in far less time than the SPARC and be on to the next one, and the workloads that most organisations have are entirely dependant on completing ever increasing single tasks in the shortest amount of time possible.
As soon as a group of people got into Sun, looked at the costs of maintaining and pumping research and development into their hardware, looked at the relative performance from SPARC versus competitors using x86 and ultimately looked at the bottom line objectively without being stupidly protectionist, then the next step was going to be shutting down Sun's production of Rock and SPARC and moving it to Fujitsu as a supplier to save money. However, even that probably won't be enough as I'm not sure Fujitsu will be able to keep SPARC viable themselves. SPARC has had two, possibly three, options written on the wall for the past ten years:
1. Catch up to x86 platforms in terms of raw performance as most SPARC systems have tended to overlap with workloads x86 systems have taken over. Papering over cracks by promoting 'CoolThreads' and parallel processing as a way around this performance gap was never going to work. I can remember almost ten years ago working somewhere where a person discovered that their Athlon 1.4GHz desktop system had several times the performance of their UltraSPARC III server and could complete tasks several times sooner. Cue lots of panic as UltraSPARC was justified because it was 'enterprise' reliable.
2. Accept the inevitable and throw the towel in.
3. The third way: Do what IBM has done with Power and push it into a high-end and high premium niche. This is difficult because IBM itself can only cover Power by selling mainframe packages and a whole bunch of add-ons to make it pay. Sun have had difficulty with this because their hardware division has always relied on hardware sales themselves.
Option 2 has clearly become the only way out once Sun's difficulties resulted in a takeover and as poor as Oracle might be at some things they are extremely successful at judging bottom lines.
Read the detail at the bottom behind the claims they're making. It becomes clear that they are ring-fencing certain APIs in any CLR compatible implementation mainly to do with web services but also APIs that seem to be essential to get a working CLR, but are not in the ECMA specifications. Implement ECMA and you basically have something akin to Rotor, which does pretty much nothing.
You failed to grasp the point of TFA. The point here is that using an encumbered format when we already live in a heavily proprietary and encumbered world with regards to the web and multimedia already, be it Flash or Windows Media, when it goes against the spirit of what the video tag was supposed to promote is not a particularly great idea. The relative quality of H.264 and Ogg Theora is just a red herring next to that, especially with respect to the inferior video quality we have through Flash and YouTube today. I think Chris DiBona knows it's a red herring as well, but they have to try and explain away their use of an encumbered format in some way.
Even then though, you fail on understanding TFA completely anyway because the issue Chris raised was not about quality but about the increased bandwidth requirements. That definitely is a red herring and the linked article pointed that out. So the text of the Slashdot article is a bit off-base in what the article was trying to say? Tell me something new. It wouldn't hurt to just read it.
They could, but the format they support first has implications. Picking a far less free and encumbered format is not a great start.
On another related note, I was going to say that if BluRay and AACS do end up getting reliably cracked and 'free' copies of films can be made then the bizarre twisted thing is that it might just end up making BluRay ubiquitously popular and give it the critical mass it needs to pull DVD back.
Presumably, this it the 'analogue hole' that they have talked about 'fixing' for a number of years now with a number of DRM companies coming out of the woodwork to say they can do it, ripping off some money and then disappearing with their directors retiring to some island somewhere with naked women?
Any techology that relies on a device sold and physically owned by a consumer denying access to said consumer is doomed to failure. Rinse and repeat.
It's one of the reasons, but certanly not the main one, why I am totally non-plussed by so-called 'High Definition' and BluRay. I did try setting up a theatre system once for someone with a receiver box relaying video through HDMI to a TV. HDCP refused to play ball because the BluRay player didn't like the arrangement. Hmmmmm. Not only do I get to not watch something because of a DRM system, I also have to buy completely new content that is currently a lot more expensive. Bound to be a success.
Anybody who has written code for a UI, user facing, system knows how stupid that statement is. When you're replicating large parts of UI functionality on different platforms that is doubly so.
Firefox didn't either. It hasn't helped their cross-platform ambitions. Most of their issues are UI tie-ins and working out how to do certain UI things on different platforms.
In this case that's wrong. Chrome is a unique application that doesn't look like many other apps that you'll run natively. As I'd said though, if you want an application to run well cross-platform then you need to minimise bugs and replication between ports. No one cares if your app looks native if it is crap.
Oh please. Qt applications aren't Java ones, they're natively compiled and you're going to need to back that up with something for it to mean anything. I doubt whether you can get less responsive than Firefox on Linux which is built with a similar approach.
Besides, if you're creating cross-platform apps then you trade off certain things to make sure that your ports to different platforms actually work properly. Going for some mythical responsiveness isn't going to matter if your port is just plain inferior and people don't care about the bugs or features for it.
If you believe that's acceptable for any application, especially one that people expect to work in the same way on each platform, then you're nuts.
Hmmmm. Writing an application that you expect to work in the same way across all platforms, minus slight GUI changes, whilst making sure that needless and difficult to reproduce bugs on different platforms are minimised, or at least known about? I doubt many sensible application developers would agree with you.
Besides, it's quite easy to write a cross-platform core with something like Qt and then make specific platform changes where needed, so I never understood where the Chrome devs' arguments were going with that one.
Well, no you're not because the Chrome devs have already been bitching about how poor GTK+ is from the back of their hands. It's very, very difficult to reuse and extend the toolkit for the kinds of GUI effects they want to achieve and given that extending GTK+ has historically been done by using brain damage like libsexy, libegg and even copying and pasting code into an application (Chrome on Linux is currently a 500 meg executable that draws a window) then the choice about what toolkit is suitable is pretty damn clear. You even have an implementation of WebKit directly available in Qt. It's virtually impossible to justify GTK+ rationally given the type of application they are developing.
Qt ties into GTK's look and feel and has done for some time. You need not alienate anyone.
Heh.
It's crystal clear what's going to happen - a piss poor Linux port with bugs that can't be reproduced on Mac OS and particularly Windows and where no one can be bothered and there isn't the time, resources or motivation to actually fix them. It's why Firefox is so poor on Linux when compared to the Windows port.