It's quite surprising that such a difficult system is so common on a major consumer product. Given the cut-throat competition in the smart phone market, you would think a company at the heart of this competition would offer bullet-proof phone system that was ultra user friendly.
I occasionally get text messages telling me that I need to upgrade my phone software and so far it seems that they all come from some kind of hackers outside the US. So I never update my phone software by doing anything those folks ask me to do. Thus, I avoid a whole lot of grief.
Bob from Maine, you raise a great point about customers calling after their patience has been exhausted. I've been there. And I would not want to be one of those customer support people. Can you imagine what it must be like dealing with frustrated customers who've been on hold for 45 minutes, and doing it all day long?
Yes, Java is inelegant. They started by issuing a new JVM every two months because they couldn't get it right. Every 2000 byte Java program installed its own 2MB JVM because the programmer couldn't figure out how to make his program run under any other version. Many apps (even TurboTax) are still doing this.
Then there was the huge battle over the UI. Should JVMs provide their own widgets or use the ones in the native OS. So we struggled with tiny, blurry, unreadable fonts for years. There are still Java apps I run which are difficult to use or don't respond to the mouse's scroll wheel or don't honor the OS's conventions, e.g., tabbing between menu itemss, opening a dropdown list with alt-down-arrow, or jumping to successive dropdown menu items when their initial letter is repeatedly struck. It's about as confortable as e.g., running a Windows app in a VM in Linux or MacOS.
How about security? The original notion was to have the JVM provide a sandbox, so apps couldn't possibly affect other apps or the OS. How well has that workd for you? They've made Java so ornate and roccoco that they can't catch all of the holes and we seem to get security fixes every quarter. That doesn't seem to be workiing too well, does it?
Since you wished to compare CVs... I have 44 years of industry experience. I've done logic design for a few decades but also shipped code and written plenty of test code and driver-level stuff. My preferred language is assembly but I am also comfortable in C, Fortran, BASIC, VB, REXX, JCL, CMS command language, and have worked in FORTH, Ada, Eiffel, Smalltalk, LOGO, dBase II, VBA, JCL, TSO command language, and others.
I'm not sure why you thought the jet engine test fixture was relevant here, but I might point out that computer hardware bugs are pretty rare. The last major one I remember was the Pentium floating point math bug. I see software bugs every day.
I have a good friend who recently returned from a one year tour of duty for his law firm in Bancock. One of his great surprises was excellent telephone service as compared to the United States. I'm not saying it was flawless just much better. Apparently dropped calls are basically non-existant and the range of coverage is superior. "Patches", when necessasry, were easy to download and worked with used. The problem mentioned in this posting is rediculous.
JAVA is designed by monkeys? JAVA was designed by a SUN Microsystems engineer - and he was not from some third-world country. Just because the app is poorly written, do not blame the language. I have seen thousands of VB programs written by so-called 'senior' programmers that make even the worst JAVA program look like the best program ever written. The same goes for 'engineers' and their FORTRAN programs. Let's not forget that the programs for the Mars rover were not written in JAVA, but in C, a mature programming language, and were written by people who knew what they were doing. The specs, however, called out by engineers, were vague and incomplete, resulting in one end of the program using feet and inches and the other end using centimeters and meters. The result? NASA wrecked their billion-dollar RC-Car!
Its not just Samsung Kies. A lot of software running on AT&T's wireless network seems to be clunky and not even beta stable. For example, I have no cell service at home from any carrier. So I got AT&T to subsidize the cost of their Cisco microcell device that connects to AT&T servers via any home broadband network. Installation was not straight forward, took several hours and required a user to log into an AT&T website to consumate the deal. Much of the time the microcell would not recognize my handset unless I rebooted my cell phone upon arrival home. And after two weeks of this nonsense the Cisco crashed. I had to uninstall it on the AT&T website and start afresh to get it back up. After the third time I gave up and switched to Verizon! Too many hours spent trying to keep a poorly conceived service up and running.
One of the requirements of these picocells is location verification (E911) and timing based upon a GPS reference. The AT&T supplied microcell had a built in patch antenna with GPS module. My home has a metal roof. Thus GPS reception was a bit tenuous even with the Cisco perched on a windowsill. That may have contributed to the instability of the AT&T microcell.
With my new Verizon handset (iPhone) in hand and new Samsung microcell I proceeded to set it up. The Samsung comes with a patch antenna connected to a long coaxial cable such that it can be placed in a location away from the picocell hardware. I was thus able to get a more secure GPS lock. But more important, installation did not require the user to log into a Verizon server. Just placing the cellular handset within ten feet of the picocell and waiting 20 minutes was all that was required. Simple self registering! And unlike the AT&T/Cisco unit, my cell phone never fails to connect to it when I drive up to my house.
This speaks volumes about hardware, software and system design, how to do it wrong.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.