No what has caused MSFT to go off the rails and what any CEO with a brain, hell what ANY person with a brain should do in that situation is simple....LISTEN TO YOUR CUSTOMERS!
You first have to figure out who your customers are. Microsoft's customers have generally not been the end-user - let alone the consumer end-user, but the Enterprise. Win8 breaks that as they tried to put the consumer end-user first over the Enterprise.
Get your customer right, and listen to them and things will generally work out. Failing that, declare bankruptcy after your rape the investors SCO Style.
Which is why the preponderance of the US budget is earmarked for the war machine.
The entire "war machine" is but a mere 4-10% of the entire budget. Entitlements (Welfare, Social Security, Medicare, Medicaide) are what make up the vast majority of the budget, and are what make up the rapidly growing portion of the budget as well.
Shit, I saw screenshots of longhorn back in 2004 man!
FYI - Longhorn is just the code name for the next generation of Windows at Microsoft. Nothing more.
When they re-started the development in 2005 for what became Vista, the new development was still called Longhorn.
Confusing? Yes, but it's just an internal name - that because (very) visible during the post XP development.
MS told OEMs and developers it was years away and no really 2005 we will ship it just wait until 2005!... ok No 2006. Beware Longhorn is coming and here is another preview as in 2006 will the year of longhorn... oh and here is yet another API and driver thing you need to start over in etc.
Yeah, they did that pre-Vista development. Then they clammed up for a while (due to Ray Ozzie) for the Vista Development then started releasing Alphas and Betas and RCs. Betas and RCs were widely distributed - I ran two of them - and didn't required MSDN subscription. They even had bug bounties (report a bug, and you could get a free copy if you were the first or something - but you had to register to report, you couldn't just use the built-in reporting tools).
The big issue was the change in the drivers between RC2 and RTM versions of Vista - where driver APIs changed with ZERO notice to the driver developers.
And per the repeated delays - they were finding that the complexity of the codebase was making changes harder and harder to make. That is why with the restart for the Vista development that started going a major refactor of the codebase - eliminating dependencies, removing kernel dependencies on userspace, cleaning up headers, etc. That is also why Win7 and Win8 came out a lot quicker.
Oh well, we will throw some pieces together and call it Vista. Yeah, Vista here is the release but trust us it will really be here in January 2007 (june 2006).
Vista was not really thrown together at all. It was a major effort. Memory requirements sucked because it was largely un-optimized, but it was actually a very good release. A PITA to users b/c of UAC due to developers not heading a long advised change (since Win2000) that they should not be using APIs that require admin rights unless the absolutely have to, but otherwise a very very good release.
UAC isn't really any different for Win7 or Win8 than it was for Vista. Developers just fixed the issues that required the admin access so it went away - the real purpose for UAC.
Developers: LOL yeah right like you said the 3 other times. Go away MS we all know you wont give a release of Longhorn anytime soon.... comes August (2006) and Balmer hands out the RTM of Visa.
PHB: ok programmers you have 8 weeks to do 3 years worth of work to port your shitty XP program to vista?!
In essence it was rushed and forced combined with the boy who cried wolf. MS did not commit fully until 6 weeks before RTM rushing Vista and removing Longhorn bits. A terrible terrible untested OS it was and no programs were ready yet.
Not really.
I used the Vista Betas and RCs, and was very surprised by the reports of the RTM version having issues with drivers until I learned they changed the driver APIs between RC2 and RTM. I had pulled drivers from several sources (Creative for my SB Audigy) and they worked great. But if you make a change like that they should also issue another RC to give people time to test and fix the bugs - but Microsoft didn't; probably because they were trying to make the christmas sales season at the behest of the PC manufacturers. They should have waited another month.
Needless to say, aside from the device driver developers, everyone had more than sufficient notice about what Vista was going to be.
Don't get me wrong, I do like a lot of the things Google did and does; not all of it, but quite a lot. Same goes for MS & Apple btw. But assuming either of these 3 would do something that hurts their own chart of accounts is simply fooling himself. I'm sure all three companies have plenty of talent around that would love to break/build/tweak and bring out stuff that might be world-changing; but in the end it's the bean-counters that decide what needs to be focused on.
True. It's the bean-counters (and upper management like Ballmer) that decide what finally gets delivered. I'm sure they have versions of.NET that run natively on Linux; they probably have versions of MS Office too. But they won't see the light outside of dev team until the bean-counters give the okay; and the bean-counters are very MS world-view centric - that is, all Microsoft and nothing but Microsoft with few exceptions namely for Apple.
Because virtual keyboards on touch screens outright suck to a degree even higher than really bad laptop keyboards.
Maybe half a decade ago, but slide-style keyboards like Swype and Google Keyboard are almost as fast as physical keys. And if you're using them to add field work to office documents, which is a core use-case for a lot of handheld devices in businesses, they win hands-down.
The virtual keyboards do suck compared to a physical keyboard - and they always will simply due to the lack of tactile feedback.
Sure, if you hunt-and-peck, you'll probably do just as well on either one.
But once you enter into touch-typing, you really need that tactile feed back in order to know where you are on the keyboard, and the virtual keyboards just don't have it.
And yes, I've used the virtual keyboard on both my Nexus One (with stock Android and CM7) and on my ASUS Transformer Infinity (TF700) tablet. I much prefer the keyboard dock for my tablet; even with the little quirks due to some different keys in their (Home Key, Back Key, no Alt key, search key, etc) it's still magnificently better than the virtual keyboard.
I don't know what my typing speed is any more - but I know on a regular computer keyboard (QWERTY) its well over 100 wpm; Windows computers have a hard time keeping up with me; Linux computers do better as I only rarely get a delay between typing something and seeing it on screen; in either case I have at times fixed stuff before it arrives on screen - stuff even dozens of words behind where the cursor is when I started backing up to fix it. On the tablet, I'd have to guess it could be between 50 and 100 wpm (at present) on the keyboard dock, but may be higher than that. For the virtual keyboard, I'd be hard pressed to do 30 wpm.
And before you start going off about how to count wpm - remember, it's not simply how much you can type, it also how many errors you have to correct. So I may be able to actually type 50-100 wpm on the virtual, but all the errors (and automated fixes) drive it down significantly.
Apple and Google rule the smart phone world now, but before the iPhone you wanted WinCE devices like the XDA and iPaq.
I don't know about you, but I always tried to avoid any WinCE devices.
I first played with a WinCE device in 1998 - a Liberty netbook (don't rember who made it). The thing was horribly cramped, too damn small, and the screen was just a desktop on a smaller screen. It sucked. I haven't seen anything in the WinCE device line that has made me want to try it again - they all look to have the same qualities as that device in 1998.
And much of their old dominance was founded on their monopoly of the OS through windows, and they were not shy about (ab)using it.
True. And they figured they could just copy the Desktop model onto smaller devices. Just like with Win8 they are trying to push the (failed) mobile interface onto the Desktop, resulting in (you guessed it) equal failure.
Novell had accused the company of crippling WordPerfect, by deliberately removing Application Programming Interfaces (APIs) which it used from windows 95, even though they were present in the beta version of the operating system.
Actually the court case was put on hold while the U.S DoJ pursued the Anti-trust. It has since been resumed, and is now actively in the court system, at least in the U.S Courts.
To kill off Netscape, they not only bundled IE with every copy of Windows but also allegedly altered or manipulated its application programming interfaces (APIs) in the OS to favor Internet Explorer over third party web browsers. This led directly to the anti-trust lawsuit by the government against MS.
It was one of many things that brought about the Anti-trust lawsuits by the U.S DoJ, another being Novell's anti-trust suit, another being SaMBa's suit, and more. Of course, the demise of Netscape brought us Thunderbird and Firefox. The results of the anti-trust trial brought official documentation for the CIFS/SMB/AD protocols used by Windows for the SaMBa team (which they paid $14k for) so they now have 100% compatibility, and more.
Now that the fight is over mobile and tablet space, MS is still sticking to its game plan by trying to leverage its old dominance into these new markets. Hence you only get the full product (in this case, Office) if you use Winph8 for mobile or Surface Pro for tablets. Their hand is weaker though since they do not control the underlying OS (iOS and Android) so they are relying on attachment to Office to drive the numbers.
They could very easily make equivalent version on all platforms that are just as capable as what is on the Windows Desktop, or offered by Office 365 subscriptions. The fact is they are choosing not to in (vain) hopes of trying to drive people to the Windows platform.
You must be using some new branch of mathematics that I wasn't previously aware of.
Or Excel for Android.
Well, Excel does contain a number of broken mathematical functions - like floor() - that don't produce the mathematical definitions under certain conditions (like floor() with negative numbers).
Their position must therefore be so bad it's hitting those cases in their Excel spreadsheets which makes them believe its a lot better than it really is.
So....
* if Google publishes something 'decent but much better on android' then it's Apple's fault.
* if MS publishes something decent but much better on WP8' then it's MS's fault.
What's with all the MS hate here anyway... if you don't like it don't buy it and just walk on. Do people get some kind of ego-boost out of bad-mouthing every single MS-product or decision ? Sjeezsss...
And you're completely missing the point. Microsoft is not even trying to put forward an equivalent on the Android AND iOS platforms of what is has on its Windows platforms. They're deliberately making inferior products on other platforms to try to steer customers to their preferred platform - Windows. So yes, it's 100% MS's fault.
This would be like Google making an app that used their services on Android, but used a degraded experience (Apple Maps, Bing, etc) on iOS and Windows.
Look around at pop music and what's being created today. Taylor Swift, Katy Perry and Justin Bieber style music is all that anyone can make money doing nowadays. Tower Records and all of its bricks and mortar competitors went out of business long ago. So did Borders.
Well, I think people like The Piano Guys (on YouTube) and Tiffany Alvord(on YouTube) and numerous others that have followed suit would beg to differ. They all do quite well - and probably better than they would through RIAA.
And in the case of the two mentioned above - both do versions of existing music (thus existing artists/authors get paid), as well as their own original music; and quite honestly, their stuff is usually a lot better than the Taylor Swift, Katy Perry, and Justin Bieber stuffs out there.
MS propogated a culture of developers using Administrative Rights for nearly every application. It didn't help that many of their own APIs were broken so badly that you had to have those rights to do many things. However, they also warned developer for years that the change was coming, and developers had the opportunity to test on Vista before its release to make sure that wouldn't be an issue - yet most chose to ignore it. Thus the whole UAC debacle which is primarily a 3rd party issue.
I would say this is mostly right. I don't totally agree that MS propagated that culture, but it was prevalent, especially in bad programmers who really didn't know what they were doing. It forced some to actually realize they didn't need to do some of the crazy things they were doing, but they just didn't know better at the time.
I say MS propagated that culture because many APIs that didn't actually need admin rights required admin rights to access, in part because of the convoluted and circular kernel-user space dependencies in the APIs themselves - something MS fixed for Vista and has kept refining since.
Even MS's own programs - MS Office - required admin rights for things it shouldn't have (again fixed around the time of Vista); however, it is noteable that MS fixed those programs as it started to trumpet the horn saying that those things should not be done. My guess is a lot of those changes were due to Ray Ozzie's influence as he was brought in to lead the restart in development that led to Vista.
Primarily yes, though Microsoft didn't help things by changing the driver API between the last RC (RC2) and manufacturer (RTM) releases, thereby breaking most all the drivers that manufacturers had tested.
MS created many of the problems themselves; they didn't need help.
MS propogated a culture of developers using Administrative Rights for nearly every application. It didn't help that many of their own APIs were broken so badly that you had to have those rights to do many things. However, they also warned developer for years that the change was coming, and developers had the opportunity to test on Vista before its release to make sure that wouldn't be an issue - yet most chose to ignore it. Thus the whole UAC debacle which is primarily a 3rd party issue.
Many 3rd party developers weren't ready for Vista but they like everyone else didn't think MS would actually release Vista in that level of incompleteness.
Vista was quite complete when it was released. That was not the issue. Win8 was less polished than Vista upon release (considerably so); but fairing better because it builds off of Vista (as Win7 did).
They thought they had more time.
No. Anyone that tracked the releases - and you didn't have to be in some secret group - knew the release was coming. The betas for Vista were very public and didn't require an MSDN license to obtain either. The only thing that really caught people off guard was the change in the driver APIs that MS did at the last second which only affected those writing device drivers.
Those developers didn't create the Vista Compatible/Ready fiasco. They didn't make UAC so damn annoying.
Their failure to modify their applications to not require APIs that needed Admin Rights was what caused the UAC fiasco and made it so damn annoying.
They didn't cause MS to throw out everything after years of development and start from scratch using a different kernel.
You obviously know very little about the Vista codebase and its evolution and history.
Vista is based on the same kernel series as WinXP - the NT Kernel. It was just the next major version (6.0).
Yes, Microsoft had developed a version of Windows that it had scrapped - 3 years before Vista was released - and restarted the development cycle to produce Vista. But that restart was not a wholesale rewrite. It restarted from the WinXP codebase, refactored the APIs for better modularity, and added new features.
The kernel that got scrapped was never released outside of a couple limited distribution alphas and betas. It never really entered the release cycle - other than demos that Microsoft did of WinFS and other stuff. It was too damn slow to be usable.
The main areas of incompatibility between the NT5 (WinXP) and NT6 (Vista/7/8) kernels were that the sound and video drivers were moved from kernel space to user space to help improve stability. Most all other drivers were still compatible or only had minor changes required.
Meesa most upset that my mooie mooie Gungan network engineering certification not gonna be good enough for a job in America. Meesa be thinking that I be back to working in Gungan call center taking orders for cheap shit coming soon.
I would love to see (literally) what happens if an American-born citizen wants to escape bad things in this good ol' USA and immigrates into India. What jobs could they find? How fast? How much pay? LOL
From what I understand, they won't be able to find much if any due to job laws in India. They'd have to first declare residency before being able to get a job at the very least. Catch-22 may be?
The Secret Service exists to protect the president and his family.
Well, only partially right. The main job of the Security Service is related to the various tasks of the Treasury Department and money handling - counterfeit money, etc. (Yeah, FBI does some investigative work; but the job is primarily one for the Treasury Department and the Secret Service. Apparently the law creating DHS also moved the SS to DHS.) It was just convient that it didn't report to the Executive Branch and therefore they also got the job of protection of the high level Executive Officials (POTUS, VP, etc) when it was deemed necessary.
And yes - the POTUS cannot tell the Secret Service what to do, and that is by design - so that the POTUS cannot overrule the Secret Service and therefore put himself in harms way.
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied.class files is beyond me.
Any data center app that works as a server. You would certainly be sandboxing stuff there too, for security purposes; just like you would want to sandbox Bind, Apache2, etc. The APIs listed as being vulnerable were not APIs limited to Browser Usage, though they were most likely most commonly used there.
Why anyone would allow a user defined (end-user system defined).class file to run on it is beyond me too...but that is part of the design of Java.
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
FYI - in the last year the Java JRE was pulled from all major platforms for at least a while. Quickest story I could find on-line is this one. It was reported on Slashdot back when it happened, and it wasn't simply the browser-plugins, but full JRE. Data centers would have been the most affected; they didn't necessarily pull it but they were under a lot of pressure due to the impact of the JRE vulnerabilities.
The issues in play affected all versions of the JRE going back quite a while, up to and including the latest version at the time. In the last couple months there's been enough patches released to restore JRE functionality, but you have to be using the latest versions. Even then, Java's security perception has been shattered as a result.
Also as a note, there were several rounds of major security issues for the JRE in the last year. They thought they got one fixed and another popped up.
For applets in a web-browser. Running a Java server is a different beast with different concerns.
The issue wasn't simply related to "applets for a web-browser". The reasons the Java RTE/VMs were pulled was due to how much it affected nearly every enterprise level use of Java in the data center - affecting entire classes of Java programs instead of having program specific attack vectors.
Well, let's think about the equivalent of pulling the Java run-time environment for C/C++. That's right, you'd have to pull your operating system. Do you see how that's not even close to a reasonable comparison?
True, you'd have to pull the OS for C/C++ when it is providing it dynamically. C/C++ programs (and any native code program) could be using the RTE statically - updating the version in the OS has zero impact on the actual program as it still uses the old version. That said, the C/C++ RTE does not in itself introduce security flaws into the programs that use it, which was why the Java RTE was pulled.
Not only that, but you're not even talking about related types of safety. The Java runtime keeps getting in trouble for poorly handling malicious third party code. If you are writing a java program yourself, it is immensely safer for the reasons GP listed, and you probably aren't in the business of attacking yourself with malware.
Yes, Java keeps getting in trouble for allowing additional code to interface with a program and extend the program in ways the author did not intend. Not possible with C/C++ without some major program specific cracking, and even then it's a program specific attack.
Once in an extremely rare case does a bug in a C/C++ program translate in usuable ways to entire classes of C/C++ programs.
Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
Yet it is Java that has had its run-time environments pulled for security concerns.
In perspective, the RTEs have been pulled because they had flaws that enabled exploit code to be run. In C, the RTE lets ANY code be run, including exploits, so what's really happening is that Java is falling back to something closer to C levels of runtime security.
The Java Run-Times were pulled because they were allowing exploits that were not necessarily related to the program being run.
Comparatively, C/C++ programs are generally only susceptible to the flaws in the actual programs, and flaws in their support libraries are only exposed as much as the program allows it to be.
The reason for the concern about Java exploitability is that while most sane people have long since given up on download-and-run C code (ActiveX), Java applets (while comparatively rare) have not had exploit concerns until fairly recently. Because until recently, Java's sandbox was considered trustworthy. C/C++ doesn't have a sandbox.
C/C++ doesn't have a native, built-in sandboxing mechanism. But they can most certainly be sandboxed whether via hardware or software mechanisms.
You do know that Java is compiled to native, don't you?
Yes, Java can be compiled. It can also be run interpretted. Either way, it runs in a Virtual Machine, which in and of itself adds another layer in the stack and slows the software down, however small the difference may be it will be there.
The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.
Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.
And yet in embedded environments the advise when using Java is do to write in software in such a way that the GC is never invoked because it causes major performance penalties at unexpected times.
Slashdot Mirror
Windows Mobile the best option? Eeep!
Yeah, when its only competitor was the Apple Netwon.
I'd say that they at least deserved credit for Kinect.
Why? They acquired the technology, not R&D'd it.
No what has caused MSFT to go off the rails and what any CEO with a brain, hell what ANY person with a brain should do in that situation is simple....LISTEN TO YOUR CUSTOMERS!
You first have to figure out who your customers are. Microsoft's customers have generally not been the end-user - let alone the consumer end-user, but the Enterprise. Win8 breaks that as they tried to put the consumer end-user first over the Enterprise.
Get your customer right, and listen to them and things will generally work out. Failing that, declare bankruptcy after your rape the investors SCO Style.
Splitting Microsoft along business/consumer lines:
MicrosoftBusiness: *WindowsDesktop (Profitable)
Profits for Windows Desktop are declining.
*WindowsServer (Profitable) *WindowsServerApplications (Profitable) *WindowsCloud (Profitable) *WindowsMouseAndKeyboardWhatnots (Profitable)
MicorsoftConsumer: *Bing (Lossy) *Xbox (BreakEvens) *WindowsPhone (Lossy) *WindowsTablets (Lossy)
I predict that MicrosoftConsumer would quickly cease trading in the wake of this split, leaving only Microsoft standing.
You missed a new profit center - Android Racketeering.
Which is why the preponderance of the US budget is earmarked for the war machine.
The entire "war machine" is but a mere 4-10% of the entire budget. Entitlements (Welfare, Social Security, Medicare, Medicaide) are what make up the vast majority of the budget, and are what make up the rapidly growing portion of the budget as well.
Shit, I saw screenshots of longhorn back in 2004 man!
FYI - Longhorn is just the code name for the next generation of Windows at Microsoft. Nothing more.
When they re-started the development in 2005 for what became Vista, the new development was still called Longhorn.
Confusing? Yes, but it's just an internal name - that because (very) visible during the post XP development.
MS told OEMs and developers it was years away and no really 2005 we will ship it just wait until 2005! ... ok No 2006. Beware Longhorn is coming and here is another preview as in 2006 will the year of longhorn ... oh and here is yet another API and driver thing you need to start over in etc.
Yeah, they did that pre-Vista development. Then they clammed up for a while (due to Ray Ozzie) for the Vista Development then started releasing Alphas and Betas and RCs. Betas and RCs were widely distributed - I ran two of them - and didn't required MSDN subscription. They even had bug bounties (report a bug, and you could get a free copy if you were the first or something - but you had to register to report, you couldn't just use the built-in reporting tools).
The big issue was the change in the drivers between RC2 and RTM versions of Vista - where driver APIs changed with ZERO notice to the driver developers.
And per the repeated delays - they were finding that the complexity of the codebase was making changes harder and harder to make. That is why with the restart for the Vista development that started going a major refactor of the codebase - eliminating dependencies, removing kernel dependencies on userspace, cleaning up headers, etc. That is also why Win7 and Win8 came out a lot quicker.
Oh well, we will throw some pieces together and call it Vista. Yeah, Vista here is the release but trust us it will really be here in January 2007 (june 2006).
Vista was not really thrown together at all. It was a major effort. Memory requirements sucked because it was largely un-optimized, but it was actually a very good release. A PITA to users b/c of UAC due to developers not heading a long advised change (since Win2000) that they should not be using APIs that require admin rights unless the absolutely have to, but otherwise a very very good release.
UAC isn't really any different for Win7 or Win8 than it was for Vista. Developers just fixed the issues that required the admin access so it went away - the real purpose for UAC.
Developers: LOL yeah right like you said the 3 other times. Go away MS we all know you wont give a release of Longhorn anytime soon. ... comes August (2006) and Balmer hands out the RTM of Visa.
PHB: ok programmers you have 8 weeks to do 3 years worth of work to port your shitty XP program to vista?!
In essence it was rushed and forced combined with the boy who cried wolf. MS did not commit fully until 6 weeks before RTM rushing Vista and removing Longhorn bits. A terrible terrible untested OS it was and no programs were ready yet.
Not really.
I used the Vista Betas and RCs, and was very surprised by the reports of the RTM version having issues with drivers until I learned they changed the driver APIs between RC2 and RTM. I had pulled drivers from several sources (Creative for my SB Audigy) and they worked great. But if you make a change like that they should also issue another RC to give people time to test and fix the bugs - but Microsoft didn't; probably because they were trying to make the christmas sales season at the behest of the PC manufacturers. They should have waited another month.
Needless to say, aside from the device driver developers, everyone had more than sufficient notice about what Vista was going to be.
Who's to say they don't ?
Don't get me wrong, I do like a lot of the things Google did and does; not all of it, but quite a lot. Same goes for MS & Apple btw. But assuming either of these 3 would do something that hurts their own chart of accounts is simply fooling himself. I'm sure all three companies have plenty of talent around that would love to break/build/tweak and bring out stuff that might be world-changing; but in the end it's the bean-counters that decide what needs to be focused on.
True. It's the bean-counters (and upper management like Ballmer) that decide what finally gets delivered. I'm sure they have versions of .NET that run natively on Linux; they probably have versions of MS Office too. But they won't see the light outside of dev team until the bean-counters give the okay; and the bean-counters are very MS world-view centric - that is, all Microsoft and nothing but Microsoft with few exceptions namely for Apple.
Because virtual keyboards on touch screens outright suck to a degree even higher than really bad laptop keyboards.
Maybe half a decade ago, but slide-style keyboards like Swype and Google Keyboard are almost as fast as physical keys. And if you're using them to add field work to office documents, which is a core use-case for a lot of handheld devices in businesses, they win hands-down.
The virtual keyboards do suck compared to a physical keyboard - and they always will simply due to the lack of tactile feedback. Sure, if you hunt-and-peck, you'll probably do just as well on either one.
But once you enter into touch-typing, you really need that tactile feed back in order to know where you are on the keyboard, and the virtual keyboards just don't have it.
And yes, I've used the virtual keyboard on both my Nexus One (with stock Android and CM7) and on my ASUS Transformer Infinity (TF700) tablet. I much prefer the keyboard dock for my tablet; even with the little quirks due to some different keys in their (Home Key, Back Key, no Alt key, search key, etc) it's still magnificently better than the virtual keyboard.
I don't know what my typing speed is any more - but I know on a regular computer keyboard (QWERTY) its well over 100 wpm; Windows computers have a hard time keeping up with me; Linux computers do better as I only rarely get a delay between typing something and seeing it on screen; in either case I have at times fixed stuff before it arrives on screen - stuff even dozens of words behind where the cursor is when I started backing up to fix it. On the tablet, I'd have to guess it could be between 50 and 100 wpm (at present) on the keyboard dock, but may be higher than that. For the virtual keyboard, I'd be hard pressed to do 30 wpm.
And before you start going off about how to count wpm - remember, it's not simply how much you can type, it also how many errors you have to correct. So I may be able to actually type 50-100 wpm on the virtual, but all the errors (and automated fixes) drive it down significantly.
Apple and Google rule the smart phone world now, but before the iPhone you wanted WinCE devices like the XDA and iPaq.
I don't know about you, but I always tried to avoid any WinCE devices.
I first played with a WinCE device in 1998 - a Liberty netbook (don't rember who made it). The thing was horribly cramped, too damn small, and the screen was just a desktop on a smaller screen. It sucked. I haven't seen anything in the WinCE device line that has made me want to try it again - they all look to have the same qualities as that device in 1998.
And much of their old dominance was founded on their monopoly of the OS through windows, and they were not shy about (ab)using it.
True. And they figured they could just copy the Desktop model onto smaller devices. Just like with Win8 they are trying to push the (failed) mobile interface onto the Desktop, resulting in (you guessed it) equal failure.
For example, they allegedly tweaked Win95 to kill WordPerfect. Novell sued but lost the court case.
Actually the court case was put on hold while the U.S DoJ pursued the Anti-trust. It has since been resumed, and is now actively in the court system, at least in the U.S Courts.
To kill off Netscape, they not only bundled IE with every copy of Windows but also allegedly altered or manipulated its application programming interfaces (APIs) in the OS to favor Internet Explorer over third party web browsers. This led directly to the anti-trust lawsuit by the government against MS.
It was one of many things that brought about the Anti-trust lawsuits by the U.S DoJ, another being Novell's anti-trust suit, another being SaMBa's suit, and more. Of course, the demise of Netscape brought us Thunderbird and Firefox. The results of the anti-trust trial brought official documentation for the CIFS/SMB/AD protocols used by Windows for the SaMBa team (which they paid $14k for) so they now have 100% compatibility, and more.
Now that the fight is over mobile and tablet space, MS is still sticking to its game plan by trying to leverage its old dominance into these new markets. Hence you only get the full product (in this case, Office) if you use Winph8 for mobile or Surface Pro for tablets. Their hand is weaker though since they do not control the underlying OS (iOS and Android) so they are relying on attachment to Office to drive the numbers.
They could very easily make equivalent version on all platforms that are just as capable as what is on the Windows Desktop, or offered by Office 365 subscriptions. The fact is they are choosing not to in (vain) hopes of trying to drive people to the Windows platform.
You must be using some new branch of mathematics that I wasn't previously aware of.
Or Excel for Android.
Well, Excel does contain a number of broken mathematical functions - like floor() - that don't produce the mathematical definitions under certain conditions (like floor() with negative numbers).
Their position must therefore be so bad it's hitting those cases in their Excel spreadsheets which makes them believe its a lot better than it really is.
So.... * if Google publishes something 'decent but much better on android' then it's Apple's fault. * if MS publishes something decent but much better on WP8' then it's MS's fault.
What's with all the MS hate here anyway... if you don't like it don't buy it and just walk on. Do people get some kind of ego-boost out of bad-mouthing every single MS-product or decision ? Sjeezsss...
And you're completely missing the point. Microsoft is not even trying to put forward an equivalent on the Android AND iOS platforms of what is has on its Windows platforms. They're deliberately making inferior products on other platforms to try to steer customers to their preferred platform - Windows. So yes, it's 100% MS's fault.
This would be like Google making an app that used their services on Android, but used a degraded experience (Apple Maps, Bing, etc) on iOS and Windows.
Well, I think people like The Piano Guys (on YouTube) and Tiffany Alvord(on YouTube) and numerous others that have followed suit would beg to differ. They all do quite well - and probably better than they would through RIAA.
And in the case of the two mentioned above - both do versions of existing music (thus existing artists/authors get paid), as well as their own original music; and quite honestly, their stuff is usually a lot better than the Taylor Swift, Katy Perry, and Justin Bieber stuffs out there.
MS propogated a culture of developers using Administrative Rights for nearly every application. It didn't help that many of their own APIs were broken so badly that you had to have those rights to do many things. However, they also warned developer for years that the change was coming, and developers had the opportunity to test on Vista before its release to make sure that wouldn't be an issue - yet most chose to ignore it. Thus the whole UAC debacle which is primarily a 3rd party issue.
I would say this is mostly right. I don't totally agree that MS propagated that culture, but it was prevalent, especially in bad programmers who really didn't know what they were doing. It forced some to actually realize they didn't need to do some of the crazy things they were doing, but they just didn't know better at the time.
I say MS propagated that culture because many APIs that didn't actually need admin rights required admin rights to access, in part because of the convoluted and circular kernel-user space dependencies in the APIs themselves - something MS fixed for Vista and has kept refining since.
Even MS's own programs - MS Office - required admin rights for things it shouldn't have (again fixed around the time of Vista); however, it is noteable that MS fixed those programs as it started to trumpet the horn saying that those things should not be done. My guess is a lot of those changes were due to Ray Ozzie's influence as he was brought in to lead the restart in development that led to Vista.
3rd Party developers were all to blame?
Primarily yes, though Microsoft didn't help things by changing the driver API between the last RC (RC2) and manufacturer (RTM) releases, thereby breaking most all the drivers that manufacturers had tested.
MS created many of the problems themselves; they didn't need help.
MS propogated a culture of developers using Administrative Rights for nearly every application. It didn't help that many of their own APIs were broken so badly that you had to have those rights to do many things. However, they also warned developer for years that the change was coming, and developers had the opportunity to test on Vista before its release to make sure that wouldn't be an issue - yet most chose to ignore it. Thus the whole UAC debacle which is primarily a 3rd party issue.
Many 3rd party developers weren't ready for Vista but they like everyone else didn't think MS would actually release Vista in that level of incompleteness.
Vista was quite complete when it was released. That was not the issue. Win8 was less polished than Vista upon release (considerably so); but fairing better because it builds off of Vista (as Win7 did).
They thought they had more time.
No. Anyone that tracked the releases - and you didn't have to be in some secret group - knew the release was coming. The betas for Vista were very public and didn't require an MSDN license to obtain either. The only thing that really caught people off guard was the change in the driver APIs that MS did at the last second which only affected those writing device drivers. Those developers didn't create the Vista Compatible/Ready fiasco. They didn't make UAC so damn annoying.
Their failure to modify their applications to not require APIs that needed Admin Rights was what caused the UAC fiasco and made it so damn annoying.
They didn't cause MS to throw out everything after years of development and start from scratch using a different kernel.
You obviously know very little about the Vista codebase and its evolution and history.
Vista is based on the same kernel series as WinXP - the NT Kernel. It was just the next major version (6.0).
Yes, Microsoft had developed a version of Windows that it had scrapped - 3 years before Vista was released - and restarted the development cycle to produce Vista. But that restart was not a wholesale rewrite. It restarted from the WinXP codebase, refactored the APIs for better modularity, and added new features.
The kernel that got scrapped was never released outside of a couple limited distribution alphas and betas. It never really entered the release cycle - other than demos that Microsoft did of WinFS and other stuff. It was too damn slow to be usable.
The main areas of incompatibility between the NT5 (WinXP) and NT6 (Vista/7/8) kernels were that the sound and video drivers were moved from kernel space to user space to help improve stability. Most all other drivers were still compatible or only had minor changes required.
So who would anyone that might be interesetd contact you? Your e-mail isn't public, and /. doesn't have a chat feature.
Meesa most upset that my mooie mooie Gungan network engineering certification not gonna be good enough for a job in America. Meesa be thinking that I be back to working in Gungan call center taking orders for cheap shit coming soon.
I would love to see (literally) what happens if an American-born citizen wants to escape bad things in this good ol' USA and immigrates into India. What jobs could they find? How fast? How much pay? LOL
From what I understand, they won't be able to find much if any due to job laws in India. They'd have to first declare residency before being able to get a job at the very least. Catch-22 may be?
Number of attacks on humans by Orcas not in captivity: 1 documented, but primarily UNKNOWN.
Number of attacks on humans by Orcas in captivity: > 27 documented (3 fatal).
Killer whale attacks on humans
FTFY
The Secret Service exists to protect the president and his family.
Well, only partially right. The main job of the Security Service is related to the various tasks of the Treasury Department and money handling - counterfeit money, etc. (Yeah, FBI does some investigative work; but the job is primarily one for the Treasury Department and the Secret Service. Apparently the law creating DHS also moved the SS to DHS.) It was just convient that it didn't report to the Executive Branch and therefore they also got the job of protection of the high level Executive Officials (POTUS, VP, etc) when it was deemed necessary.
And yes - the POTUS cannot tell the Secret Service what to do, and that is by design - so that the POTUS cannot overrule the Secret Service and therefore put himself in harms way.
Secret Service on Wikipedia
Secret Service's History
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied .class files is beyond me.
Any data center app that works as a server. You would certainly be sandboxing stuff there too, for security purposes; just like you would want to sandbox Bind, Apache2, etc. The APIs listed as being vulnerable were not APIs limited to Browser Usage, though they were most likely most commonly used there.
.class file to run on it is beyond me too...but that is part of the design of Java.
Why anyone would allow a user defined (end-user system defined)
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
FYI - in the last year the Java JRE was pulled from all major platforms for at least a while. Quickest story I could find on-line is this one. It was reported on Slashdot back when it happened, and it wasn't simply the browser-plugins, but full JRE. Data centers would have been the most affected; they didn't necessarily pull it but they were under a lot of pressure due to the impact of the JRE vulnerabilities.
The issues in play affected all versions of the JRE going back quite a while, up to and including the latest version at the time. In the last couple months there's been enough patches released to restore JRE functionality, but you have to be using the latest versions. Even then, Java's security perception has been shattered as a result.
Also as a note, there were several rounds of major security issues for the JRE in the last year. They thought they got one fixed and another popped up.
For applets in a web-browser. Running a Java server is a different beast with different concerns.
The issue wasn't simply related to "applets for a web-browser". The reasons the Java RTE/VMs were pulled was due to how much it affected nearly every enterprise level use of Java in the data center - affecting entire classes of Java programs instead of having program specific attack vectors.
Well, let's think about the equivalent of pulling the Java run-time environment for C/C++. That's right, you'd have to pull your operating system. Do you see how that's not even close to a reasonable comparison?
True, you'd have to pull the OS for C/C++ when it is providing it dynamically. C/C++ programs (and any native code program) could be using the RTE statically - updating the version in the OS has zero impact on the actual program as it still uses the old version. That said, the C/C++ RTE does not in itself introduce security flaws into the programs that use it, which was why the Java RTE was pulled.
Not only that, but you're not even talking about related types of safety. The Java runtime keeps getting in trouble for poorly handling malicious third party code. If you are writing a java program yourself, it is immensely safer for the reasons GP listed, and you probably aren't in the business of attacking yourself with malware.
Yes, Java keeps getting in trouble for allowing additional code to interface with a program and extend the program in ways the author did not intend. Not possible with C/C++ without some major program specific cracking, and even then it's a program specific attack.
Once in an extremely rare case does a bug in a C/C++ program translate in usuable ways to entire classes of C/C++ programs.
Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
Yet it is Java that has had its run-time environments pulled for security concerns.
In perspective, the RTEs have been pulled because they had flaws that enabled exploit code to be run. In C, the RTE lets ANY code be run, including exploits, so what's really happening is that Java is falling back to something closer to C levels of runtime security.
The Java Run-Times were pulled because they were allowing exploits that were not necessarily related to the program being run.
Comparatively, C/C++ programs are generally only susceptible to the flaws in the actual programs, and flaws in their support libraries are only exposed as much as the program allows it to be.
The reason for the concern about Java exploitability is that while most sane people have long since given up on download-and-run C code (ActiveX), Java applets (while comparatively rare) have not had exploit concerns until fairly recently. Because until recently, Java's sandbox was considered trustworthy. C/C++ doesn't have a sandbox.
C/C++ doesn't have a native, built-in sandboxing mechanism. But they can most certainly be sandboxed whether via hardware or software mechanisms.
You do know that Java is compiled to native, don't you?
Yes, Java can be compiled. It can also be run interpretted. Either way, it runs in a Virtual Machine, which in and of itself adds another layer in the stack and slows the software down, however small the difference may be it will be there.
The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.
Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.
And yet in embedded environments the advise when using Java is do to write in software in such a way that the GC is never invoked because it causes major performance penalties at unexpected times.