That is not a live tile. When you clicked xeyes, it didn't launch a program. xeyes didn't tell you anything (the weather, sports scores, etc.), other than the direction the mouse pointer was relative to the xeyes.
First of all, widgets are not live tiles. Widgets are interactive components, Live Tiles are passive.
Secondly, Windows Phone explicity avoided any sort of skeumophism in its design, a complete differentiator from Apple and those who have copied them.
Thirdly, not only did Windows Phone avoid skeumorphism, it embraced being a digital, mobile experience, meaning it didn't use any stale metaphors to base their user experience on -- meaning on 3D UIs or book pages that look like book pages, etc. Much of the Metro experience came out of the underappreciated ZUNE experience, which pre-dated Android.
Finally, the critics agree -- the Windows Phone experience is original and refreshing. Woz spilled some crazy love all over the Windows Phone design, practically saying that the ghost of Jobs must have been reincarnated at Microsoft.
That's not the issue. The issue is that Google Maps works perfectly fine on desktop IE, and mobile IE uses the same rendering engine / works the same. You would be correct if Google had blocked desktop IE too, BUT THEY DIDN'T. This was Google exercising their power to try to damage the Windows Phone experience.
I think that they are just jealous that Microsoft came up with an original mobile experience and all they could do is copy what Apple had going on. If Google didn't see Microsoft as a threat, they wouldn't be doing these antics, so I see this as validation of the Windows Phone platform.
It's so refreshing having a Secretary of Energy that actually knows something about energy and physics, rather than somebody who just knows how to dig carbon out of the ground.
This is a horrible idea. This will encourage people to focus more attention on texting if they choose to text and drive.
If people did not think they could text and drive safely, they wouldn't. The people who believe this will simply spend more of their attention on the texting and less on the driving.
The funny thing about all of this is that I've configured my Chrome to have the tabs on the LEFT, and it's far superior to either of the options people are bickering about!
By your reasoning, Linux systems have no business in Windows networks. That's not how the world works though.
I don't know any business that has all of their internal software systems running in one API. In a world of infinite time and infinite resources, going for a "pure" linux environment is a noble one, but the real world has constraints, and learning curves, and existing skills, and business requirements that span multiple APIs and multiple systems.
Let's say you have an entire backoffice system running on Linux. Your newest and largest customer that you just landed requires you to connect to their.NET invoicing system in order to submit and invoice and get paid. Would you stand your moral high ground saying "that's just dumb" and simply not do it? Would you fire your best client because they aren't on the FOSS bandwagon? Instead of running a simple.NET connector provided by your client, would you spend the time, money and resources re-implementing the connector and explain to your client why you need to "test" the connection?
This whole FOSS purity is a tired argument left for the Stallmans of an outdated vision of the future. In a "perfect" world it is something to aspire to, but in the real world you must pick your battles one at a time, and not everybody uses FOSS. The world runs in a happy balance of proprietary and free software.
Suggesting that Windows interoperability is what killed OS/2 is sorely incomplete. Everything around the OS/2 joint venture between IBM and Microsoft was complicated. If you recall, it was supposed to be a jointly owned platform, but then Microsoft went their own separate way and called their version Windows NT. It was the largely the same code base, which is why the interoperability existed. IBM and Microsoft are two very different companies, even more different at the time. Microsoft's business was the PC. IBM's bread-and-butter was the mainframe. How does OS/2 become successful in a company (at the time) dominated by 1970s era technology mainframe sales and maintenance contracts?
If you know.NET and want to deploy to a device, why have a steep learning curve when you can just use the tools you know?.NET runs on phones, servers, desktop PCs, microcontrollers (.NET Micro Edition), extending this to other operating environments is a logical choice. If Mono runs on a Mac, then the designer who insists on running a Mac doesn't need 2 computers at work (Mac for design, PC to run a required app). Interoperability is key, zealots that just stand in the way of this are impractical purists who don't care about users.
It is not a "good thing" to have Mono or.NET interoperability taken out of reach of Linux users. Interoperability layers such as Mono allow Linux systems to participate in networks that are dominated by Windows and other commercial systems. If it weren't for software like this, Linux systems may not be invited into some corporate networks, and would not get a seat at the table.
The idea of a "pure" linux or no linux is going to continue having linux sitting out in the cold all by itself. Interoperability is crucial.
If anything, we need more software like Mono, not less.
You have only complained about a perceived problem so far, you need to isolate and identify your bottleneck(s). The best way to do this is through performance metrics:
Identify your problem with...
I suggest using Microsoft's "Performance Monitor", which gives you access to dozens of OS, IIS,.NET, Web Service, MSMQ and SQL Server performance metrics, from the simple CPU utilization and memory usage to the detailed such as.NET CLR Threads, SQL Server Cache Misses, IIS File Cache Hits. You can display performance metrics for multiple machines on the same real-time graph, so you could show database machine CPU, web server CPU, IIS Requests/Sec and SQL Server CPU on the same chart. This would give you a good start.
There is a.NET API to plug into "Performance Monitor"! Build your own metrics to be displayed with the ones provided by the system...your code may not be as efficient as you once though after you see your own metrics.
SHOW PLAN sql statement for SQL Server. It is build into Query Analyzer. It will tell you what indexes your queries use, and how long each step of your query takes so that you may optimize your queries/updates
SQL Server Profiler - This will show you ever statement that SQL Server is currently running, or you can filter based on a number of criteria and give you a look at their execution performance.
If your problem is that SOAP is too fat...
Use XML-RPC it is what SOAP used to be BEFORE it got FAT.
If your problem is Web Application...
Web Services are supposed to be STATELESS. If you are using any sort of state mechanism, it is going to make an impact on your performance. Be sure to turn off user sessions if you don't need them.
Is IIS configured properly? There are scaling settings in there to modify, this changes IIS's caching behavior (look under the "Performance" tab)
Have you set the Application Protection (under "Home Directory" tab), you can execute your site within the IIS process (Low Protection - high speed but if your app crashes it takes down IIS -- never seen this happen personally), within a thread pool (Medium Protection - crash won't affect IIS, but all your sites may have limited availability), or within its own process (High Protection - slowest, but if it fails, IIS and every other site keeps on operating)
Use Stored Procedures wherever possible - this keeps the database from having to parse your query, develop a new execution plan, then get your data. Stored Procedures use a cached execution plan, and the only thing to parse are your arguments -- faster, and more secure (no SQL Injection
Trim back your real-time synchronous processing tasks if possible. if you are doing complex inserts into multiple tables, devise a scheme to insert your data into only 1 or 2 processing tables, then schedule a service to go in every X minutes/hours/days to then take the data from the processing tables and do the fancy processing to it and insert it into the "real" tables. Especially good to schedule during off-peak hours if they exist.
Slashdot Mirror
Yes, I used xeyes.
That is not a live tile. When you clicked xeyes, it didn't launch a program. xeyes didn't tell you anything (the weather, sports scores, etc.), other than the direction the mouse pointer was relative to the xeyes.
First of all, widgets are not live tiles. Widgets are interactive components, Live Tiles are passive.
Secondly, Windows Phone explicity avoided any sort of skeumophism in its design, a complete differentiator from Apple and those who have copied them.
Thirdly, not only did Windows Phone avoid skeumorphism, it embraced being a digital, mobile experience, meaning it didn't use any stale metaphors to base their user experience on -- meaning on 3D UIs or book pages that look like book pages, etc. Much of the Metro experience came out of the underappreciated ZUNE experience, which pre-dated Android.
Finally, the critics agree -- the Windows Phone experience is original and refreshing. Woz spilled some crazy love all over the Windows Phone design, practically saying that the ghost of Jobs must have been reincarnated at Microsoft.
...you do realize RIM has copied the live tile look for their new OS?
http://wmpoweruser.com/rim-please-stop-flattering-windows-phone/
That's not the issue. The issue is that Google Maps works perfectly fine on desktop IE, and mobile IE uses the same rendering engine / works the same. You would be correct if Google had blocked desktop IE too, BUT THEY DIDN'T. This was Google exercising their power to try to damage the Windows Phone experience.
I think that they are just jealous that Microsoft came up with an original mobile experience and all they could do is copy what Apple had going on. If Google didn't see Microsoft as a threat, they wouldn't be doing these antics, so I see this as validation of the Windows Phone platform.
It's so refreshing having a Secretary of Energy that actually knows something about energy and physics, rather than somebody who just knows how to dig carbon out of the ground.
This is a horrible idea. This will encourage people to focus more attention on texting if they choose to text and drive.
If people did not think they could text and drive safely, they wouldn't. The people who believe this will simply spend more of their attention on the texting and less on the driving.
The funny thing about all of this is that I've configured my Chrome to have the tabs on the LEFT, and it's far superior to either of the options people are bickering about!
Logo logo logo!
Logo was everywhere back in 1986, but it's nowhere now...what's the deal with that?
Awesome way to start.
By your reasoning, Linux systems have no business in Windows networks. That's not how the world works though.
I don't know any business that has all of their internal software systems running in one API. In a world of infinite time and infinite resources, going for a "pure" linux environment is a noble one, but the real world has constraints, and learning curves, and existing skills, and business requirements that span multiple APIs and multiple systems.
Let's say you have an entire backoffice system running on Linux. Your newest and largest customer that you just landed requires you to connect to their .NET invoicing system in order to submit and invoice and get paid. Would you stand your moral high ground saying "that's just dumb" and simply not do it? Would you fire your best client because they aren't on the FOSS bandwagon? Instead of running a simple .NET connector provided by your client, would you spend the time, money and resources re-implementing the connector and explain to your client why you need to "test" the connection?
This whole FOSS purity is a tired argument left for the Stallmans of an outdated vision of the future. In a "perfect" world it is something to aspire to, but in the real world you must pick your battles one at a time, and not everybody uses FOSS. The world runs in a happy balance of proprietary and free software.
Suggesting that Windows interoperability is what killed OS/2 is sorely incomplete. Everything around the OS/2 joint venture between IBM and Microsoft was complicated. If you recall, it was supposed to be a jointly owned platform, but then Microsoft went their own separate way and called their version Windows NT. It was the largely the same code base, which is why the interoperability existed. IBM and Microsoft are two very different companies, even more different at the time. Microsoft's business was the PC. IBM's bread-and-butter was the mainframe. How does OS/2 become successful in a company (at the time) dominated by 1970s era technology mainframe sales and maintenance contracts?
If you know .NET and want to deploy to a device, why have a steep learning curve when you can just use the tools you know? .NET runs on phones, servers, desktop PCs, microcontrollers (.NET Micro Edition), extending this to other operating environments is a logical choice. If Mono runs on a Mac, then the designer who insists on running a Mac doesn't need 2 computers at work (Mac for design, PC to run a required app). Interoperability is key, zealots that just stand in the way of this are impractical purists who don't care about users.
It is not a "good thing" to have Mono or .NET interoperability taken out of reach of Linux users. Interoperability layers such as Mono allow Linux systems to participate in networks that are dominated by Windows and other commercial systems. If it weren't for software like this, Linux systems may not be invited into some corporate networks, and would not get a seat at the table.
The idea of a "pure" linux or no linux is going to continue having linux sitting out in the cold all by itself. Interoperability is crucial.
If anything, we need more software like Mono, not less.
You have only complained about a perceived problem so far, you need to isolate and identify your bottleneck(s). The best way to do this is through performance metrics:
Identify your problem with...
If your problem is that SOAP is too fat...
Use XML-RPC it is what SOAP used to be BEFORE it got FAT.
If your problem is Web Application...
Web Services are supposed to be STATELESS. If you are using any sort of state mechanism, it is going to make an impact on your performance. Be sure to turn off user sessions if you don't need them.
Is IIS configured properly? There are scaling settings in there to modify, this changes IIS's caching behavior (look under the "Performance" tab)
Have you set the Application Protection (under "Home Directory" tab), you can execute your site within the IIS process (Low Protection - high speed but if your app crashes it takes down IIS -- never seen this happen personally), within a thread pool (Medium Protection - crash won't affect IIS, but all your sites may have limited availability), or within its own process (High Protection - slowest, but if it fails, IIS and every other site keeps on operating)
Have you turned off logging if you don't need it?
Optimize the IIS Metabase, adjust settings you can't get to through the UI. Never heard of it? Learn about it. In Win2k and NT, it is similar to the registry (you need a special tool), in Win2003, they made it an XML document for easy editing.
If your problem is Database...
Optimize your database access in your code
Use Stored Procedures wherever possible - this keeps the database from having to parse your query, develop a new execution plan, then get your data. Stored Procedures use a cached execution plan, and the only thing to parse are your arguments -- faster, and more secure (no SQL Injection
Trim back your real-time synchronous processing tasks if possible. if you are doing complex inserts into multiple tables, devise a scheme to insert your data into only 1 or 2 processing tables, then schedule a service to go in every X minutes/hours/days to then take the data from the processing tables and do the fancy processing to it and insert it into the "real" tables. Especially good to schedule during off-peak hours if they exist.
Partition your data with multiple SQL Servers this is also known as "Shared-Nothing Clustering"