I'd argue they have. They are back to the situation they had prior to Gnome's surge where they are seen as coequal. They aren't equal to the old situation where they were ahead. People think of KDE and Gnome as peers.
Arch now leans KDE. Suse is back to being a KDE distribution that supports Gnome rather than coequal. Many of the BSDs are incidentally dropping Gnome support since Gnome is becoming too Linux dependent.
They are going after new markets. For example part of Gnome 3's genesis was when Gnome's (GTK really) inability to handle touchscreen meant they lost Maemo and instead MeeGo was based on Qt. They believed, and they were right, that there is a huge market of ARM based systems coming that overwhelm desktops and create room for a Linux GUIs.
Right now we have: Tizen (based on Enlightenment), Android, MeeGo / Sailfish (Qt), Blackberry 10 (QNX sort of Linuxy), iOS (FreeBSD cousin)... They would like to play in that space.
Compounding the problem by rebuilding applications so they share the same broken interface characteristics makes the situation worse.
You are begging the question here. Obviously if you disagree with the hybrid approach you should leave Gnome.
This isn't about "ideology" it is about design. Gnome 3 is a transitional GUI designed to help people transition away from traditional desktops towards hybrid systems.
I'm not sure what you are specifically disagreeing with in my comment.
I agree that moving beyond a 1990s style desktop is a good thing. I agree the move to a modern desktop it was the right thing to do. Though I think that there needed to be better education about the objectives and perhaps something like Mate could have been semi official.
I don't agree with the way Gnome handled their blowout with Canonical, I think that was a disaster. Having Canonical essentially fork Gnome and go in their own direction:
a) Undermines Gnome with the majority of their user base who use Gnome through Ubuntu b) Undermines the most important Gnome desktop as Ubuntu does a bad job c) Creates a great deal of confusion
As far as the old stuff going quickly. Maybe, maybe not. I't might end up being a very long time still capacitive touchscreen, for example, is standard enough that it can be seen as mandatory. Microsoft is pushing hard and still the OEMs are resisting. If they were to stop pushing hard....
Could run it in the sense of the code executed doesn't mean much. Could run it optimally was capacitive touchscreen with applications designed for dual usage. And those mostly don't exist yet.
Unity is different than Gnome 3. That's an additional complication.
It's going to be hard for them to maintain a critical mass in the long term.
Gnome is no worse off today that KDE was after KDE 4. United Linux with the big pro KDE players was dead, KDE was a disaster or most distributions and even long term supporters like Mandrake were becoming supportive of Gnome. Gnome was the standard and KDE was grouped with XFCE and later LXDE as one of the 2nd string GUIs. They recovered.
Should that not be evidence enough that it was a bad damned UI decision?!
No. The existing Gnome 2 userbase on existing hardware was not really the intended audience for Gnome 3. It was possible a bad naming decision in taking the product in a direction likely to alienate existing customers rather than release a new product name. It was very likely a bad political decision to get into a fight with Novell, Canonical and their existing user base all at more or less the same. But no it was not a bad UI decision.
On the right hardware, Gnome 3 is likely a huge step forward. But like Windows 8 there is a chicken and egg problem that the order must go:
OS -> hardware -> applications for the new interface which means the OSes don't fit existing hardware and existing applications well for a few years.
Groovy isn't bad like most dynamic languages. Generally though for a DSL you want custom primitives on top of some sort of complex primitives hiding them. Ease of constructing the compiler, and the apply/eval loop, i.e. a Scheme. is more important than almost anything else.
I believe the debate was whether Java was faster than C++. In some areas Java is faster than C++.
The original claim was more broad. If you want to limit to C++ then the issue comes down to speed of libraries. C++ libraries can emulate the efficiencies of Java libraries but the reverse isn't always true.
Sorry man, I don't grok the intent of the last sentence. Could you please clarify?
The intent was that the term "faster language" or "better performance" applies only to runtime performance. That doesn't mean that only runtime performance is important, but the meaning of language is specific.
For enterprise work the speed to develop is usually more important than the runtime performance (although that can't suck too much).
I agree. For enterprise work most of the time the system is I/O constrained and runtime performance may not matter much at all. Further hardware costs are low relative to development and maintenance costs. Java is no question a better choice than C++ all other things being equal. Though I'd go much higher level than either one for enterprise applications.
I'm saying that it is a good-enough language for any domain that makes it sensible as a first 'go to' choice.
I would agree with that if you replace "any domain" with most domains. I think the lack of abstraction and isolation of state in Java is a serious problem for things like big data work or massive parallelism. It is far too difficult in Java in practice to see which operations are by nature associative. I think the lack of void pointers is a serious problem for low level hardware code, as I mentioned in the last post. I think the complexity of writing a Java compiler makes it a terrible choice for constructing DSLs.
The Oracle HPC paper put the overhead at 1-1.5 (i.e. Java at 40-50% of the gcc Fortran version). They used Fortran as a benchmark for Java. There were no areas of outperformance and that was with a rather mediocre Fortran compiler. Your own paper doesn't support your theory. Choose a benchmark favorable to Java and in many areas it does well.
If your development time is so long the project stakeholders may cancel it.
I'm not arguing development time isn't important. I'm arguing what the word "fast language" is not about development time. Cars are important, refrigerators are important. The fact that a fridge is important does not make it a car.
The runtime performance of higher-level language blows. eg, Groovy, Ruby, Python are not in the same league as C++/C/Java/C# etc.
Of course not. But this is you conflating measures again. Your point was about development speed. If you are saying that Java is a good compromise: you get development speed faster than C++ without taking order of magnitude performance hits and pick up mostly cross platform; I'd agree with you. If you claim that Java code is as fast as C++ then I disagree. If you claim that Java is fast to develop in compared to most languages I'd disagree.
if you are doing the problem they were designed to solve, and then they suck.
Now that being said all languages are stronger in some areas than others. Languages to survive have to find niches where they are particularly well suited, which means such niches exist. The things that make Java safer than C/C++ for commercial development are the things that knock it out of the game for systems programming. The things that give Java performance within an order of magnitude of C/C++ are the lack of abstractions that can kick development times up by almost an order of magnitude over high level languages.
Just to pick a simple example where Java is a problem... C++ is far better at dealing casually with data structures at the bit level where the packing / unpacking needs to happen fast. I wouldn't want to try and write a router in Java.
With the exception of pretty good cross platform, Java is a compromise. There is a lot of advantage in the standard language being pretty good at a lot of things and not fantastic at any of them. But let's not pretend this tradeoffs aren't happening.
Sun lost the battle well before Oracle IMHO. 64 bit sparcs came out in 1994. You could do things on a Sun you simply couldn't do on a PC. Sparc 3 is a cool chip Intel doesn't sell a 16 core 128 thread CPU even today. I'd assume they won't till about 2020 at the earliest so a 10 year lag. The problem is the chip is so expensive that you are better off just buying a more expensive motherboard and multiple CPUs.
I guess the big question is whether ARM is going to do to x86 what x86 did to MIPS, SPARC, Power (mostly)...
When people talk about benchmarks in terms of faster they mean performance not development. In terms of development time, Java gets crushed by much higher level languages. As for projects that aren't CPU constrained but constrained by something else, you are just saying you don't care about performance. That's wholly different than Java having C like performance.
As for multithreaded, C++ is obviously faster. If you want non tricky multithreaded languages like Haskell or Eiffel crush both of them.
And no on a single thread Java is not comparable. It generally is in the range of 1.5-5x slower. Which ain't bad at all, but I have yet to see any situation in which it is faster.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
Based on what? Java is rather fast but I have to see any other area of performance where it exceeds C/C++ and quite a few it is well slower than C/C++. The way it handles code is too similar. So by what metric is it "just as fast"?
And no it doesn't get compiled down to the same machine code. Abstraction adds complexity in machine code. That's why Fortran, C and Assembly consistently outperform higher level languages.
I'd argue that the entire move to Linux is mainly people leaving SPARC because of performance concerns. In the mid 1990s through early 2000s Linux/x86 was a low end system and Solaris/SPARC was the big brother. The lack of performance is what made Linux thrive. If Sun workstations were still say 20-100x faster than x86 workstations and in the $10k range I'd be they would still be selling. If a $40-200k Sun server would crush a rack of x86 boxes they would still be selling.
I'm not sure what SPARC hardware does today comparatively. But Oracle database vs. Postgres. Yes there are huge differences.
Materialized views are a must for views + performance. Flashback queries and flashback archives are a must for any kind of rollback. The ability to divide queries across CPUs is vital for complex data warehouse etc...
How did Suse fuck the community? Microsoft has never once gone after a free distribution. Novell signed a patent protection act because they had complex rights that's fairly standard FRAND trading. What else did they do?
First off yes less to democratically elected. There is a difference between less and never. As far as whether it is a good idea, yeah. Their are governments and leaders that threaten the United States and attack US interests. I don't think we should act against them always but that doesn't mean if a good opportunity arises we shouldn't take advantage.
Slashdot Mirror
Unity is not Gnome 3 that's Canonical's code. Try something like Fedora to get a clean Gnome 3.
As to one reason it is better. Integrated notifications.
I'd argue they have. They are back to the situation they had prior to Gnome's surge where they are seen as coequal. They aren't equal to the old situation where they were ahead. People think of KDE and Gnome as peers.
Arch now leans KDE. Suse is back to being a KDE distribution that supports Gnome rather than coequal. Many of the BSDs are incidentally dropping Gnome support since Gnome is becoming too Linux dependent.
They are going after new markets. For example part of Gnome 3's genesis was when Gnome's (GTK really) inability to handle touchscreen meant they lost Maemo and instead MeeGo was based on Qt. They believed, and they were right, that there is a huge market of ARM based systems coming that overwhelm desktops and create room for a Linux GUIs.
Right now we have: Tizen (based on Enlightenment), Android, MeeGo / Sailfish (Qt), Blackberry 10 (QNX sort of Linuxy), iOS (FreeBSD cousin)... They would like to play in that space.
What hardware? Tablets?
Tablet / laptops. Dual use. Like the Lenova Yoga or HP Envy.
Tablet interfaces are innovations that work great for tablets and tablet workflows. Desktop workflows are different.
Both Gnome and Microsoft are of the opinion that the best is a hybrid mixed environment. http://www.youtube.com/watch?v=a6cNdhOKwi0
Compounding the problem by rebuilding applications so they share the same broken interface characteristics makes the situation worse.
You are begging the question here. Obviously if you disagree with the hybrid approach you should leave Gnome.
This isn't about "ideology" it is about design. Gnome 3 is a transitional GUI designed to help people transition away from traditional desktops towards hybrid systems.
I'm not sure what you are specifically disagreeing with in my comment.
I agree that moving beyond a 1990s style desktop is a good thing. I agree the move to a modern desktop it was the right thing to do. Though I think that there needed to be better education about the objectives and perhaps something like Mate could have been semi official.
I don't agree with the way Gnome handled their blowout with Canonical, I think that was a disaster. Having Canonical essentially fork Gnome and go in their own direction:
a) Undermines Gnome with the majority of their user base who use Gnome through Ubuntu
b) Undermines the most important Gnome desktop as Ubuntu does a bad job
c) Creates a great deal of confusion
As far as the old stuff going quickly. Maybe, maybe not. I't might end up being a very long time still capacitive touchscreen, for example, is standard enough that it can be seen as mandatory. Microsoft is pushing hard and still the OEMs are resisting. If they were to stop pushing hard....
Could run it in the sense of the code executed doesn't mean much. Could run it optimally was capacitive touchscreen with applications designed for dual usage. And those mostly don't exist yet.
Unity is different than Gnome 3. That's an additional complication.
It's going to be hard for them to maintain a critical mass in the long term.
Gnome is no worse off today that KDE was after KDE 4. United Linux with the big pro KDE players was dead, KDE was a disaster or most distributions and even long term supporters like Mandrake were becoming supportive of Gnome. Gnome was the standard and KDE was grouped with XFCE and later LXDE as one of the 2nd string GUIs. They recovered.
Should that not be evidence enough that it was a bad damned UI decision?!
No. The existing Gnome 2 userbase on existing hardware was not really the intended audience for Gnome 3. It was possible a bad naming decision in taking the product in a direction likely to alienate existing customers rather than release a new product name. It was very likely a bad political decision to get into a fight with Novell, Canonical and their existing user base all at more or less the same. But no it was not a bad UI decision.
On the right hardware, Gnome 3 is likely a huge step forward. But like Windows 8 there is a chicken and egg problem that the order must go:
OS -> hardware -> applications
for the new interface which means the OSes don't fit existing hardware and existing applications well for a few years.
Groovy isn't bad like most dynamic languages. Generally though for a DSL you want custom primitives on top of some sort of complex primitives hiding them. Ease of constructing the compiler, and the apply/eval loop, i.e. a Scheme. is more important than almost anything else.
Any database worth $50k / hr or even $5k / hr should be on Oracle or DB2. MySQL is for databases at the $500 / hr or less.
I believe the debate was whether Java was faster than C++. In some areas Java is faster than C++.
The original claim was more broad. If you want to limit to C++ then the issue comes down to speed of libraries. C++ libraries can emulate the efficiencies of Java libraries but the reverse isn't always true.
Sorry man, I don't grok the intent of the last sentence. Could you please clarify?
The intent was that the term "faster language" or "better performance" applies only to runtime performance. That doesn't mean that only runtime performance is important, but the meaning of language is specific.
For enterprise work the speed to develop is usually more important than the runtime performance (although that can't suck too much).
I agree. For enterprise work most of the time the system is I/O constrained and runtime performance may not matter much at all. Further hardware costs are low relative to development and maintenance costs. Java is no question a better choice than C++ all other things being equal. Though I'd go much higher level than either one for enterprise applications.
I'm saying that it is a good-enough language for any domain that makes it sensible as a first 'go to' choice.
I would agree with that if you replace "any domain" with most domains. I think the lack of abstraction and isolation of state in Java is a serious problem for things like big data work or massive parallelism. It is far too difficult in Java in practice to see which operations are by nature associative. I think the lack of void pointers is a serious problem for low level hardware code, as I mentioned in the last post. I think the complexity of writing a Java compiler makes it a terrible choice for constructing DSLs.
etc...
The Oracle HPC paper put the overhead at 1-1.5 (i.e. Java at 40-50% of the gcc Fortran version). They used Fortran as a benchmark for Java. There were no areas of outperformance and that was with a rather mediocre Fortran compiler. Your own paper doesn't support your theory. Choose a benchmark favorable to Java and in many areas it does well.
If your development time is so long the project stakeholders may cancel it.
I'm not arguing development time isn't important. I'm arguing what the word "fast language" is not about development time. Cars are important, refrigerators are important. The fact that a fridge is important does not make it a car.
The runtime performance of higher-level language blows. eg, Groovy, Ruby, Python are not in the same league as C++/C/Java/C# etc.
Of course not. But this is you conflating measures again. Your point was about development speed. If you are saying that Java is a good compromise: you get development speed faster than C++ without taking order of magnitude performance hits and pick up mostly cross platform; I'd agree with you. If you claim that Java code is as fast as C++ then I disagree. If you claim that Java is fast to develop in compared to most languages I'd disagree.
if you are doing the problem they were designed to solve, and then they suck.
Now that being said all languages are stronger in some areas than others. Languages to survive have to find niches where they are particularly well suited, which means such niches exist. The things that make Java safer than C/C++ for commercial development are the things that knock it out of the game for systems programming. The things that give Java performance within an order of magnitude of C/C++ are the lack of abstractions that can kick development times up by almost an order of magnitude over high level languages.
Just to pick a simple example where Java is a problem... C++ is far better at dealing casually with data structures at the bit level where the packing / unpacking needs to happen fast. I wouldn't want to try and write a router in Java.
With the exception of pretty good cross platform, Java is a compromise. There is a lot of advantage in the standard language being pretty good at a lot of things and not fantastic at any of them. But let's not pretend this tradeoffs aren't happening.
Sun lost the battle well before Oracle IMHO. 64 bit sparcs came out in 1994. You could do things on a Sun you simply couldn't do on a PC. Sparc 3 is a cool chip Intel doesn't sell a 16 core 128 thread CPU even today. I'd assume they won't till about 2020 at the earliest so a 10 year lag. The problem is the chip is so expensive that you are better off just buying a more expensive motherboard and multiple CPUs.
I guess the big question is whether ARM is going to do to x86 what x86 did to MIPS, SPARC, Power (mostly)...
When people talk about benchmarks in terms of faster they mean performance not development. In terms of development time, Java gets crushed by much higher level languages. As for projects that aren't CPU constrained but constrained by something else, you are just saying you don't care about performance. That's wholly different than Java having C like performance.
As for multithreaded, C++ is obviously faster. If you want non tricky multithreaded languages like Haskell or Eiffel crush both of them.
And no on a single thread Java is not comparable. It generally is in the range of 1.5-5x slower. Which ain't bad at all, but I have yet to see any situation in which it is faster.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
Based on what? Java is rather fast but I have to see any other area of performance where it exceeds C/C++ and quite a few it is well slower than C/C++. The way it handles code is too similar. So by what metric is it "just as fast"?
And no it doesn't get compiled down to the same machine code. Abstraction adds complexity in machine code. That's why Fortran, C and Assembly consistently outperform higher level languages.
I'd argue that the entire move to Linux is mainly people leaving SPARC because of performance concerns. In the mid 1990s through early 2000s Linux/x86 was a low end system and Solaris/SPARC was the big brother. The lack of performance is what made Linux thrive. If Sun workstations were still say 20-100x faster than x86 workstations and in the $10k range I'd be they would still be selling. If a $40-200k Sun server would crush a rack of x86 boxes they would still be selling.
I'm not sure what SPARC hardware does today comparatively. But Oracle database vs. Postgres. Yes there are huge differences.
Materialized views are a must for views + performance.
Flashback queries and flashback archives are a must for any kind of rollback.
The ability to divide queries across CPUs is vital for complex data warehouse
etc...
They aren't really in the same league.
How did Suse fuck the community? Microsoft has never once gone after a free distribution. Novell signed a patent protection act because they had complex rights that's fairly standard FRAND trading. What else did they do?
No it isn't. SCO was suing IBM for things they never did and if any did them Caldera (SCO) did them. Their filings were filled with lies.
Nokia at least invented the stuff they are suing for. Bad yes, but they are not in SCO's league.
That's what I was saying above. Backup is a non issue. There are lots of other issues however.
Sure the backup can be distributed. And when applied to an unauthorized device it is worthless.
I'd be a bit cautious in calling me an idiot when you apparently have no idea what DRM even is.
Yes, but it doesn't need to be able to be distributed. That doesn't present a problem for DRM.
I understand it is a copy. But with a DRM mechanism the copy is generally unusable except on authorized players. The copy is harmless.
A good DRM standard would include a system of backup. Preventing copies on the other hand is the whole point.
First off yes less to democratically elected. There is a difference between less and never. As far as whether it is a good idea, yeah. Their are governments and leaders that threaten the United States and attack US interests. I don't think we should act against them always but that doesn't mean if a good opportunity arises we shouldn't take advantage.