The hack you posted is not an exploit of the phone - it was a hack against one of the services provided by iCloud. The phone, itself, was not compromised.
There was a report of spyware that could be installed on an iPhone - it required a jailbreak to install. It could not be done OTA and without physical access to the device.
Replacing a ROM chip is both a software and hardware modification. It is not stock, is it? So, out of the box, which platform is more secure at this time?
Now, once you modify the device as you have indicated, it's possible to make the Android more secure. But, as a stock device, it still lags, doesn't it?
And, you are right...you can't insert a custom ROM in an iOS device - best you can do is jailbreak - something I would never do because of the inherent risks.
Why do I refer to you as a "Fandroid"? You attacked the original poster's arguments where they stated that all but one of the items they listed were iPhone only. You said the features were available on Android as well. They aren't without custom, hardware and software modifications as you noted. You ignored their original point and called them a "fanbois". I called you on it.
Exactly how does that custom ROM get installed??? Does it require modification of a device? Hardware modifications are not stock, are they? Are these devices readily available from a major supplier or must they be custom ordered?
There has been no reported successful hack of iOS devices to install malware where the device wasn't jailbroken. If you know otherwise, please provide relevant links? This can not be said of Android.
Now, what happens on the backend is open to interpretation and subject to debate.
You called the other poster a fanboi. He might be, but you are clearly a FAndroid with a chip on his shoulder and something to prove.
for the offshore workers who displaced American workers to know that their value is now being measured by whether it can now be done by a TI-84 calculator or a resurrected TRS-80 if a human is still required in some capacity. They will now know how it feels to have to compete for jobs managing their automated overlords for even less meager earnings than before.
And, one has to wonder how far the shockwave will go. Will engineering and middle-management type jobs now be offshored (something that, historically, has not worked well) further compounding the problem in the company's home country or will a job "firewall" protect those jobs while driving the economies of the offshore workforce into the dumper? Or, will it encourage the need for the countries with the offshore workforce to adjust and create strong, viable companies that directly complete with their former overseas employers?
I foresee that we will see companies opening new offices overseas to directly compete with local companies as a result of the new global economy that this level of automation will usher in.
I would mod you up. Unfortunately, the directproject.org site and wiki aren't exactly well organized. I may take another stab at trying to read it later today.
No, doctors don't care what a SOAP note looks like. Nor should they care - that's the EHR/EMR provider's responsibility. But, the LE / Public Safety sector was able to figure it out how to represent all the various entities (and, trust me, there are LOTS). It really should be all that hard to figure out how to represent patients, addresses, phone number, vitals, progress notes, medications, procedures, insurance providers, etc. Then, those entities are combined in manners that make sense to accomplish specific goals.
In the NIEM world, not every provider gave the same information when they exchanged with others and not every system could handle all the various NIEM object. However, the data they did exchange( incidents, persons, subject,,charge, arrests, vehicle info, etc) were in a common format that could be interpreted by NIEM compliant systems.
A bigger issue, since Congress won't allow for a national medical ID, is how to ensure that the correct information is exchanged, how to safely store it and how to protect it against unauthorized access and fraudulent usage.
There is a common believe that Macs don't get viruses or could, possible, be susceptible to malware. This week, we have seen several issues that first threaten the *nix community (which, OSX is built upon). The first was the bash bug. The second is a worm that is capable of infecting a Mac system. A few months ago, we had Heartbleed that again, was cross platform.
Yes...the Bash Bug - affects *nix machines including Macs. That means the Linux user is just as exposed. It does mean, in this particular instance, that Windows users get a break.
The Mac, link linux, has proven relatively immune to computer viruses. How many people do you know run anti-virus and/or anti-malware software on the linux desktops or servers? Exactly. The Mac is built on top of an *nix core, but is far more usable by the average user. However, when the built in safeguards are disabled, it's possible to install malware. And, it's very possible that the attack vector is an exploit of the bash bug. We don't know the method or attack vector used to infect those machines (in either of the two articles on Dr. Web). Likely, users downloaded and installed an unsigned OSX application which, unlike having to jailbreak your phone, is easy to do. That unsigned app carried and installed the worm. I say" likely", because we just don't know enough yet.
For those who aren't aware, Apple has a app store for OSX apps in addition to the iOS app store. Like it's counterpart, apps are checked by Apple and are digitally signed. A developer must belong to the Macintosh Developer network to sign their apps and have them sold through the app store. You always have the option to install apps from other sources, but they are unchecked and unsigned. And, you take your chances, just as on other platforms, if you download and install unknown code.
Apple has taken a beating these past couple of weeks on multiple fronts. The Apple haters are in full force. But, in this case, we don't know how the malware/worm was installed. So, is it fair to bust Apple's chops over it without knowing the root cause?
I have read a fair number of the comments posted here. And, the prevailing consensus is that there really isn't a standard when it comes to sharing health data and medical records between EMR systems.
Somebody mentioned HIPAA EDI in a previous post - those standards, however, are for passing information between entities for claims and not medical records. Why are the records themselves not specified in a publicly published format?
When I worked in the public safety software business, we were involved in many data sharing initiatives across the country. Many states had established their own platforms (Ohio and Wisconsin were pretty far along). But, on the federal level, they introduced GJXDM followed by the more comprehensive NIEM (National Information Exchange Model). The states moved towards this standard. While fairly big and deep, it make it fairly easy for NIEM compliant system to share data with one another. And, while the states built their own "free" records management systems, LE wanted their preferred vendors and the platforms with all the bells and whistles to support NIEM. So, we did.
Outside of this arena, we have HR-XML (for use by Human resources and NOT free). But, if you want to play in that game, you join the group and write systems compliant with it. At least there IS a standard.
What is criminal, in my mind, is that health care systems do not have a standard for describing this information. Nor, do they have a secure infrastructure for passing EMR data even if they did. It should have explicitly detailed as a provision in the ACA (aka Obamacare) so that healthcare providers and insurance carriers to interoperate. EMR vendors and insurance carriers should be REQUIRED and their software certified to comply with data interchange standards (which, may need to be formulated).
EPIC is in a position to set the standard. But, they won't because it means other vendors can get in the pool. So, somebody with really deep pockets and altruistic mindset needs to fund the development of a public standard, set the certification standards, and make it happen.
Yes, read the analysis offered in another poster's comments.
So, the question begging to be asked is whether jailbreaking phones in China by the owner is a common occurrence or if the phones are sold "pre-jailbroken" by a larger agency and able to download and install these hacks at will?
The Android attack vector is pretty clear. Oddly, they don't know how it spreads to iOS devices. If it's not spread as an malicious, sandboxed app, then how does it get on an iPhone?
How about: a) Phone was jailbroken. b) Phone had a modified iOS installed. c) Some vulnerability exists in one of the built in apps that allows malicious software to be installed outside of the confines of the sandbox.
Given it's happening in China during the protests and with a large iOS device blackmarket, I'm betting on (b) followed by (a) with a very slight chance of (c) and that this malware won't be seen in the rest of world anytime soon.
The number of trips to populate is likely to be somewhat smaller if you send men and women who can reproduce. Those offspring can reproduce (assuming there are both m/f offspring) after 18-20 years. And, of course, people will die of natural and unnatural causes. What will the average lifespan be? Average breeding span?
It would be an interesting equation to figure out as to how many trips it would actually take to make a genetically diverse community that also has other society needs met in order to function.
Still, it will be a massive undertaking to build a colony of that size without significant advances in propulsion technology paring the flight times from months to days or hours.
I, too, would beg to differ. As someone who has used the language / IDE since Delphi 1.0, I have to think you are probably a Microsoft/VB fan.
I worked for several companies whose products were written in Delphi. One application was a leading records management system for law enforcement and comprised over 1 million lines of code. Another was a commodities trading application that used JNI to communicate with a large collection of Java files. Another managed slot machines at a very large casino and interfaced with the AS/400.
Today, at version Delphi XE7, the tool can still develop native Windows apps. But, it can also cross compile to produce native OSX, iOS and Android apps (via the NDK). The language has evolved as well. Granted, the verbose syntax of Pascal still exists. It should be said, however, that.Net and C# were created by Delphi's creator (Anders Heidelberg) after he defected away from Borland.
The tool ran into some hard times due to some shakeups at Borland. Borland became Inprise (yeah, stupid name). People screamed but the damage was done even though they chose to rename themselves again from Inprise back to Borland. Borland spun off it's application tools division to concentrate on application lifecycle management tools. The spin off became CodeGear and operated on a small budget. Eventually, Codegear was acquired by Embarcadero which has had it's share of issues. Today, Borland is a shell. Biggest issue with the sell to Embarcadero was the concentration of release a product that was buggy and at a high price. They locked people into a costy upgrade path. They learned and have fixed a lot of issues. But, the high cost forced many shops and developers away from the product. Microsoft became the standard.
XE7 is an amazing tool if you want to develop Windows, OSX, IOS and Android apps. Database support is fantastic (I have the Enterprise version). It has UML modelling and code generation capabilities. And, now it supports tethering between mobile apps and the desktop over WiFi and Bluetooth (including LE) among many other cool features.
Before you knock the tool and language, you should actually try to use it. The only downsides are still the price and the fact that you still need a Mac to compile for OSX and iOS. This is more a limitation of Apple requiring the apps to be signed and the XCode tools are needed for this purpose. And, it doesn't develop web apps. If you want to be in that market, you need to select another tool. They used to include the FreePascal compiler for its ARM support. They now have their own native ARM compiler.
They have a 30 day trial for download. They also have another product, called AppCode, that is very similar to Delphi/RadStudio. That product is offered on a monthly subscription basis vs outright purchase. Not sure of it's other limitations.
The 3rd Party ecosystem took a hit for a while with many of the vendors moving towards.Net during the shakeup at Borland and haven't returned. Some of those vendors also felt shafted by both Borland and Embarcadero when they decided to offer products in those 3rd parties spaces and cut them out of the deal. Recently, there has been a lot of new release of components (old and new) on sites such as Torry.net.
While I still code in other languages when necessary, I still prefer to code in Delphi for my personal work. Sadly, it's personal as few enterprise IT shops will consider it these days because of the shakeups.
NOT in my house and NOT with the expected life expectancy listed on the packing! Of course, due to power fluctuations (we still have a 100A feed vs 200A and overhead wires), we constantly have bulbs burning out. Yes, major portions of the house wiring have been redone.
If they had surge protection in the bulbs, they would probably last a lot longer and I would get my money's worth due to the cost vs power savings (7W equivalent to 75W incandescent). My kids leave lights on all day...so it makes a big difference over time.
We just put in a "sunlight" white LED bulb in the kitchen to replace a CFL. Holy crap is that bright yet energy efficient!
Of those that changed their tune, they commented about trying to operate the larger device with one hand. Apple moved some things around to make easier. And, it's lighter and thinner than it's 2012 predecessors - a benefit of time and manufacturing processes. Machined metal vs plastic makes a difference as well in terms of how rigid the device is and how that feels in one's hands. Again, the benefit of time to review existing products and improved manufacturing processes.
So, I didn't hear any particular fan-dom responses because of Apple vs Android. I heard that Apple's take on it was a little more refined. One would expect that over the course of two years. Samsung will do the same on their next iteration.
Being said, I am a big guy (6' 1") with large hands. The 6+ still feels awkward to me. If I opt for one of the newer models, I would, likely, go with the straight 6 over the 6+. But, I am not due for an upgrade for another year. I can wait.
Of the best new features I would like to see? Improved battery life.
Good points. During the hiring process, it's fair to ask about training and conferences policies. And, if there is one you care about attending (one or regularly), you should negotiate it prior to accepting the hiring agreement.
Generally, if the training or conference is more for your benefit than the company's, they will resist sending you on their dime. If they are expecting you to attend, then they are responsible for all costs. If, as you suggest, the benefits of attending through PR or exposure is of value to them, then you can usually negotiate a compromise even when it doesn't directly benefit the company.
I managed to pull off having a developer's conference that I enjoyed attending added to my hiring agreement. They sent me for five years (regardless of location (continental US) until they restructured and forced us all to accept to new agreements or seek employment elsewhere when they incorporated. My conference benefit was terminated. Needless to say, I became willing to entertain offers for new employment as I saw it as a cheesy move.
Or, are they responding the premise that this simply can't be secure?
I haven't fully digested it, but it sounds interesting at the very least for me to at least try to understand it. It does not appear to be a crackpot article as one might assume. And, it sounds like it's being posted for true peer review as most security papers should,
and give it a new name. That seems to be the pattern these days, isn't it. The techniques and concepts described in this "Manifesto" are really nothing more than the tenet of systems design since the dawn of the computer age. Yet, he touts it like its some sort of new idea. Same goes for programming languages, frameworks and paradigms - most are rehashes of what came before.
I have been a proponent of using message queues to build asynchronous and distributed system that make building such "responsive" system. We developed a location based system that leveraged ApacheMQ with JMS to facilitate the processing of millions of messages while keeping the response time predictable. That was seven (7) years ago.
Bandwidth and computing resources are finite. We can move processing off to the cloud or to other dedicated processors. But, ultimately, you will have a bottleneck of one or more of the two, bandwidth and computing resources (cores, processors, nodes, whatever). To make a response, large scale system, you need to understand the limitations and, more specifically, queuing theory so that you can build a system that meets the goals of the "manifesto".
If one is looking at programming "responsive" systems in terms of languages (which is not the intent, I think, of the manifesto), you can easily go back to the 1980's and 1990's. There were probably other such environments before then. However, around 1992/3, there was a language for the Macintosh called Prograph (and, Progragh CPX). It was a visual language that was based on "cases" with inputs and outputs. Outputs became available when all the inputs were satisfied - it was very asynchronous. Yes, you still had procedural elements. But, it was designed for parallel processing. Another, so called, "responsive" system is the spreadsheet where cells change based on the values in other cells in a very asynchronous fashion.
I won't state that some of today's "modern" languages don't solve specific problem of earlier languages or have something to offer. But, much of what that is claimed to be modern constructs have been around for years - maybe not as eloquently expressed, but were there nevertheless. This is where a CS degree comes in hand and why people pursue CS at colleges. Wish some people would get that through their heads. The other day, there was a story about how older IT professionals seem to have lost their fire while the "younger" generation is full of it and it's learning something new that makes them better than the old guard. No, older professionals simply say "ho-hum" to the "new" views as it's just a rehash of what they already know. When something revolutionary comes along, the wake up long enough to figure it out and whether it's something that's worth considering vs what HR thinks is the hopping buzzword of the day.
"Visa and Mastercard might have signed on, but that's not important. Retailer support is the critical factor. "
Having Visa and Mastercard sign on is a VERY BIG deal in obtaining retailer support. In order to use their services, you have to use approved terminals which they often provide or dictate the requirements of said terminals. If they providing or requiring Apple Pay capable terminals, the technology will penetrate the retail market quickly. Retailers will have little recourse if people demand mobile payments. With larger stores chains in the mix, the tech will be ubiquitous fairly quickly. I expect we will see vendors like Square adopt this tech pretty quickly so they can stay relevant. The Square device, for example, was free (or was it $10) for those that signed up with their service for those that wanted to accept cards.
Whether Google Wallet or PayPal can get in the mix, we'll see. Choice would be nice. However, I think we will see Apple Pay be the dominant tech in this industry. What is unclear is if the special chip Apple developed is a requirement or a nice-to-have and other vendors are free to implement in software or their own custom chip.
The entire argument is simply stupid. Just don't think that because you're a droid fan that it makes you immune to "enthralled fanatic syndrome". Look at how everyone want the next Nexus or Galaxy or S5 or Alpha or whatever. It goes both ways.
For me, the day that Apple devices don't get the job done for me, I will look at an Android device. But, my last experience was with an Incredible. It was anything but. That could be simply because HTC nor Verizon fixed issues that resulted in it rebooting or crashing at really inopportune times. But, it turned me away from the platform. As a developer, I prefer iOS (in the form of the iPad) as that's where the money is. When Android devices become mainstay in my client's enterprises, I will reexamine my development and business model at that time. So far, Android tablets don't meet their needs - primarily because they are too configurable and the innards accessible. Open is not always a good thing.
Just like the Gold iPhone and the new Gold Samsung S5(?)...when the other has it, it's stupid. But, damn, everybody wants it just the same don't they?
You aren't going to reason with a Fanboi or FANdroid - they both are set in their ways.
If people want to critize your Android phone for having a camera lens and are trolls, does it make sense to act the same way? Take the high road.
These are merely phones...nothing more. You pick what you like. If you want a camera that looks like the main weapon on a Dalek, that's your prerogative. Maybe, you can make it work and dispose of those who don't like your choice.
Yes, the "bulge" is clearly photoshopped out. I can only suspect the reason is that they want to show that the rest of the phone...the 95+% of the surface area is the stated thickness. During the keynote, the "bulge" was discussed. They could have shown the whole side view and position arrows or other marks to indicate the thickness. But, frankly, that would have been ugly, wouldn't it? Certainly, not Apple's way.
Now, iPhone / Apple fans aren't going to care that Apple marketers took this liberty with the images - they are going to buy it regardless.
Only those who want to find fault with Apple, for whatever reason, give a rat's ass that Apple might engage as something so underhanded as to photoshop out the "bulge" to clarify their marketing point.
What IS more interesting is how much attention Android fans are giving to something which they claim no interest in owning.
Now, I will digress.
Nobody (except true Fanbois) on the Apple side argues that Android phones might have had some features that found their way into Samsung and other Android phones first (i.e NFC, Google Wallet, etc). But, it took a company, like Apple, with the marketing clout and financial resources to get buy-in for actually using those features (such as NFC through Apple Pay). Apple only introduces features into their products for which they believe there to be a market or to remain relevant in a market. And, if a market doesn't yet exist, they know how to create it and they make it appear easy to use - as only Apple can.
The addition of NFC, for example, was probably done because they could now make it useful (vs "bumping" phones to transfer video..big whoop) by tackling mobile payments. Apple Pay addresses the process by never sharing credit card data, having unique, one-time, transaction number, and the ability to use a fingerprint to authenticate in a fraction of second. Well, those are the claims, anyway. They managed to get the major banks and store brands to jump on the bandwagon. And, in doing so, it appears Apple may have succeeded where Google and Samsung could not even with their more "technologically" advanced hardware and software solutions. Usability is the key to public acceptance - not technology. And, they seized upon the opportunity posed by "hackers" breaking in and stealing credit card data from major outlets to gain appeal for their solution.
Now, what remains to be seen is whether Apple allows others to play in the Apple Pay sandbox or not. If they don't, they might successfully corner the phone market for the average person with Apple Pay and an iPhone 6C provided the POS vendors elect not to integrate other mobile payment schemes into their terminals.
Click Remove Album to confirm you'd like to remove the album from your account
Sign in with the Apple ID and password you use to buy from the iTunes Store
Apple warned that, once the album has been removed from a user's account, it will no longer be available for them to redownload as a previous purchase.
If they later decide they want the album, they will need to get it again.
The album is free to everyone until 13 October 2014, and will be available for purchase after that date.
(Not to mention that, on Apple platforms, you'd have to use Apple's language; forks have no bearing on that.)
Incorrect. Your code has to compile using their APIs. There are multiple tools out there for writing iOS and OSX code (Embarcadero RADStudio, Titanium, FreePascal, MonoTouch, etc.) . All code must be signed before it can be accepted into the AppStore. And, the code undergoes basic checks to such things as unauthorized API calls, missing images, etc. The signing requirement still has to be done using XCode. The alternative tools are able to call it to facilitate the signing process.
Swift and Objective-C through XCode are the PREFERRED tools that Apple supports. Outside of this realm, you are pretty much on your own with support being supplied by the alternative tool vendors.
Slashdot Mirror
The hack you posted is not an exploit of the phone - it was a hack against one of the services provided by iCloud. The phone, itself, was not compromised.
There was a report of spyware that could be installed on an iPhone - it required a jailbreak to install. It could not be done OTA and without physical access to the device.
Replacing a ROM chip is both a software and hardware modification. It is not stock, is it? So, out of the box, which platform is more secure at this time?
Now, once you modify the device as you have indicated, it's possible to make the Android more secure. But, as a stock device, it still lags, doesn't it?
And, you are right...you can't insert a custom ROM in an iOS device - best you can do is jailbreak - something I would never do because of the inherent risks.
Why do I refer to you as a "Fandroid"? You attacked the original poster's arguments where they stated that all but one of the items they listed were iPhone only. You said the features were available on Android as well. They aren't without custom, hardware and software modifications as you noted. You ignored their original point and called them a "fanbois". I called you on it.
Exactly how does that custom ROM get installed??? Does it require modification of a device? Hardware modifications are not stock, are they? Are these devices readily available from a major supplier or must they be custom ordered?
There has been no reported successful hack of iOS devices to install malware where the device wasn't jailbroken. If you know otherwise, please provide relevant links? This can not be said of Android.
Now, what happens on the backend is open to interpretation and subject to debate.
You called the other poster a fanboi. He might be, but you are clearly a FAndroid with a chip on his shoulder and something to prove.
for the offshore workers who displaced American workers to know that their value is now being measured by whether it can now be done by a TI-84 calculator or a resurrected TRS-80 if a human is still required in some capacity. They will now know how it feels to have to compete for jobs managing their automated overlords for even less meager earnings than before.
And, one has to wonder how far the shockwave will go. Will engineering and middle-management type jobs now be offshored (something that, historically, has not worked well) further compounding the problem in the company's home country or will a job "firewall" protect those jobs while driving the economies of the offshore workforce into the dumper? Or, will it encourage the need for the countries with the offshore workforce to adjust and create strong, viable companies that directly complete with their former overseas employers?
I foresee that we will see companies opening new offices overseas to directly compete with local companies as a result of the new global economy that this level of automation will usher in.
It's going to be interesting.
Can we just grow and insert more humans into the power grid?
I would mod you up. Unfortunately, the directproject.org site and wiki aren't exactly well organized. I may take another stab at trying to read it later today.
No, doctors don't care what a SOAP note looks like. Nor should they care - that's the EHR/EMR provider's responsibility. But, the LE / Public Safety sector was able to figure it out how to represent all the various entities (and, trust me, there are LOTS). It really should be all that hard to figure out how to represent patients, addresses, phone number, vitals, progress notes, medications, procedures, insurance providers, etc. Then, those entities are combined in manners that make sense to accomplish specific goals.
In the NIEM world, not every provider gave the same information when they exchanged with others and not every system could handle all the various NIEM object. However, the data they did exchange( incidents, persons, subject, ,charge, arrests, vehicle info, etc) were in a common format that could be interpreted by NIEM compliant systems.
A bigger issue, since Congress won't allow for a national medical ID, is how to ensure that the correct information is exchanged, how to safely store it and how to protect it against unauthorized access and fraudulent usage.
There is a common believe that Macs don't get viruses or could, possible, be susceptible to malware. This week, we have seen several issues that first threaten the *nix community (which, OSX is built upon). The first was the bash bug. The second is a worm that is capable of infecting a Mac system. A few months ago, we had Heartbleed that again, was cross platform.
Yes...the Bash Bug - affects *nix machines including Macs. That means the Linux user is just as exposed. It does mean, in this particular instance, that Windows users get a break.
The Mac, link linux, has proven relatively immune to computer viruses. How many people do you know run anti-virus and/or anti-malware software on the linux desktops or servers? Exactly. The Mac is built on top of an *nix core, but is far more usable by the average user. However, when the built in safeguards are disabled, it's possible to install malware. And, it's very possible that the attack vector is an exploit of the bash bug. We don't know the method or attack vector used to infect those machines (in either of the two articles on Dr. Web). Likely, users downloaded and installed an unsigned OSX application which, unlike having to jailbreak your phone, is easy to do. That unsigned app carried and installed the worm. I say" likely", because we just don't know enough yet.
For those who aren't aware, Apple has a app store for OSX apps in addition to the iOS app store. Like it's counterpart, apps are checked by Apple and are digitally signed. A developer must belong to the Macintosh Developer network to sign their apps and have them sold through the app store. You always have the option to install apps from other sources, but they are unchecked and unsigned. And, you take your chances, just as on other platforms, if you download and install unknown code.
Apple has taken a beating these past couple of weeks on multiple fronts. The Apple haters are in full force. But, in this case, we don't know how the malware/worm was installed. So, is it fair to bust Apple's chops over it without knowing the root cause?
Who remembers the failed Clipper chip pushed during the Clinton administration and advocated by VP Gore?
Who remembers why it failed?
Those who fail to understand history are doomed to repeat it....even if they have to force it down our throats.
I have read a fair number of the comments posted here. And, the prevailing consensus is that there really isn't a standard when it comes to sharing health data and medical records between EMR systems.
Somebody mentioned HIPAA EDI in a previous post - those standards, however, are for passing information between entities for claims and not medical records. Why are the records themselves not specified in a publicly published format?
When I worked in the public safety software business, we were involved in many data sharing initiatives across the country. Many states had established their own platforms (Ohio and Wisconsin were pretty far along). But, on the federal level, they introduced GJXDM followed by the more comprehensive NIEM (National Information Exchange Model). The states moved towards this standard. While fairly big and deep, it make it fairly easy for NIEM compliant system to share data with one another. And, while the states built their own "free" records management systems, LE wanted their preferred vendors and the platforms with all the bells and whistles to support NIEM. So, we did.
Outside of this arena, we have HR-XML (for use by Human resources and NOT free). But, if you want to play in that game, you join the group and write systems compliant with it. At least there IS a standard.
What is criminal, in my mind, is that health care systems do not have a standard for describing this information. Nor, do they have a secure infrastructure for passing EMR data even if they did. It should have explicitly detailed as a provision in the ACA (aka Obamacare) so that healthcare providers and insurance carriers to interoperate. EMR vendors and insurance carriers should be REQUIRED and their software certified to comply with data interchange standards (which, may need to be formulated).
EPIC is in a position to set the standard. But, they won't because it means other vendors can get in the pool. So, somebody with really deep pockets and altruistic mindset needs to fund the development of a public standard, set the certification standards, and make it happen.
Yes, read the analysis offered in another poster's comments.
So, the question begging to be asked is whether jailbreaking phones in China by the owner is a common occurrence or if the phones are sold "pre-jailbroken" by a larger agency and able to download and install these hacks at will?
The Android attack vector is pretty clear. Oddly, they don't know how it spreads to iOS devices. If it's not spread as an malicious, sandboxed app, then how does it get on an iPhone?
How about:
a) Phone was jailbroken.
b) Phone had a modified iOS installed.
c) Some vulnerability exists in one of the built in apps that allows malicious software to be installed outside of the confines of the sandbox.
Given it's happening in China during the protests and with a large iOS device blackmarket, I'm betting on (b) followed by (a) with a very slight chance of (c) and that this malware won't be seen in the rest of world anytime soon.
The number of trips to populate is likely to be somewhat smaller if you send men and women who can reproduce. Those offspring can reproduce (assuming there are both m/f offspring) after 18-20 years. And, of course, people will die of natural and unnatural causes. What will the average lifespan be? Average breeding span?
It would be an interesting equation to figure out as to how many trips it would actually take to make a genetically diverse community that also has other society needs met in order to function.
Still, it will be a massive undertaking to build a colony of that size without significant advances in propulsion technology paring the flight times from months to days or hours.
I, too, would beg to differ. As someone who has used the language / IDE since Delphi 1.0, I have to think you are probably a Microsoft/VB fan.
I worked for several companies whose products were written in Delphi. One application was a leading records management system for law enforcement and comprised over 1 million lines of code. Another was a commodities trading application that used JNI to communicate with a large collection of Java files. Another managed slot machines at a very large casino and interfaced with the AS/400.
Today, at version Delphi XE7, the tool can still develop native Windows apps. But, it can also cross compile to produce native OSX, iOS and Android apps (via the NDK). The language has evolved as well. Granted, the verbose syntax of Pascal still exists. It should be said, however, that .Net and C# were created by Delphi's creator (Anders Heidelberg) after he defected away from Borland.
The tool ran into some hard times due to some shakeups at Borland. Borland became Inprise (yeah, stupid name). People screamed but the damage was done even though they chose to rename themselves again from Inprise back to Borland. Borland spun off it's application tools division to concentrate on application lifecycle management tools. The spin off became CodeGear and operated on a small budget. Eventually, Codegear was acquired by Embarcadero which has had it's share of issues. Today, Borland is a shell. Biggest issue with the sell to Embarcadero was the concentration of release a product that was buggy and at a high price. They locked people into a costy upgrade path. They learned and have fixed a lot of issues. But, the high cost forced many shops and developers away from the product. Microsoft became the standard.
XE7 is an amazing tool if you want to develop Windows, OSX, IOS and Android apps. Database support is fantastic (I have the Enterprise version). It has UML modelling and code generation capabilities. And, now it supports tethering between mobile apps and the desktop over WiFi and Bluetooth (including LE) among many other cool features.
Before you knock the tool and language, you should actually try to use it. The only downsides are still the price and the fact that you still need a Mac to compile for OSX and iOS. This is more a limitation of Apple requiring the apps to be signed and the XCode tools are needed for this purpose. And, it doesn't develop web apps. If you want to be in that market, you need to select another tool. They used to include the FreePascal compiler for its ARM support. They now have their own native ARM compiler.
They have a 30 day trial for download. They also have another product, called AppCode, that is very similar to Delphi/RadStudio. That product is offered on a monthly subscription basis vs outright purchase. Not sure of it's other limitations.
The 3rd Party ecosystem took a hit for a while with many of the vendors moving towards .Net during the shakeup at Borland and haven't returned. Some of those vendors also felt shafted by both Borland and Embarcadero when they decided to offer products in those 3rd parties spaces and cut them out of the deal. Recently, there has been a lot of new release of components (old and new) on sites such as Torry.net.
While I still code in other languages when necessary, I still prefer to code in Delphi for my personal work. Sadly, it's personal as few enterprise IT shops will consider it these days because of the shakeups.
NOT in my house and NOT with the expected life expectancy listed on the packing! Of course, due to power fluctuations (we still have a 100A feed vs 200A and overhead wires), we constantly have bulbs burning out. Yes, major portions of the house wiring have been redone.
If they had surge protection in the bulbs, they would probably last a lot longer and I would get my money's worth due to the cost vs power savings (7W equivalent to 75W incandescent). My kids leave lights on all day...so it makes a big difference over time.
We just put in a "sunlight" white LED bulb in the kitchen to replace a CFL. Holy crap is that bright yet energy efficient!
Of those that changed their tune, they commented about trying to operate the larger device with one hand. Apple moved some things around to make easier. And, it's lighter and thinner than it's 2012 predecessors - a benefit of time and manufacturing processes. Machined metal vs plastic makes a difference as well in terms of how rigid the device is and how that feels in one's hands. Again, the benefit of time to review existing products and improved manufacturing processes.
So, I didn't hear any particular fan-dom responses because of Apple vs Android. I heard that Apple's take on it was a little more refined. One would expect that over the course of two years. Samsung will do the same on their next iteration.
Being said, I am a big guy (6' 1") with large hands. The 6+ still feels awkward to me. If I opt for one of the newer models, I would, likely, go with the straight 6 over the 6+. But, I am not due for an upgrade for another year. I can wait.
Of the best new features I would like to see? Improved battery life.
Good points. During the hiring process, it's fair to ask about training and conferences policies. And, if there is one you care about attending (one or regularly), you should negotiate it prior to accepting the hiring agreement.
Generally, if the training or conference is more for your benefit than the company's, they will resist sending you on their dime. If they are expecting you to attend, then they are responsible for all costs. If, as you suggest, the benefits of attending through PR or exposure is of value to them, then you can usually negotiate a compromise even when it doesn't directly benefit the company.
I managed to pull off having a developer's conference that I enjoyed attending added to my hiring agreement. They sent me for five years (regardless of location (continental US) until they restructured and forced us all to accept to new agreements or seek employment elsewhere when they incorporated. My conference benefit was terminated. Needless to say, I became willing to entertain offers for new employment as I saw it as a cheesy move.
It's an older code, sir...but, it checks out. Shall I hold them?
No...I will DEEEAAAALLL with them myself.
Or, are they responding the premise that this simply can't be secure?
I haven't fully digested it, but it sounds interesting at the very least for me to at least try to understand it. It does not appear to be a crackpot article as one might assume. And, it sounds like it's being posted for true peer review as most security papers should,
and give it a new name. That seems to be the pattern these days, isn't it. The techniques and concepts described in this "Manifesto" are really nothing more than the tenet of systems design since the dawn of the computer age. Yet, he touts it like its some sort of new idea. Same goes for programming languages, frameworks and paradigms - most are rehashes of what came before.
I have been a proponent of using message queues to build asynchronous and distributed system that make building such "responsive" system. We developed a location based system that leveraged ApacheMQ with JMS to facilitate the processing of millions of messages while keeping the response time predictable. That was seven (7) years ago.
Bandwidth and computing resources are finite. We can move processing off to the cloud or to other dedicated processors. But, ultimately, you will have a bottleneck of one or more of the two, bandwidth and computing resources (cores, processors, nodes, whatever). To make a response, large scale system, you need to understand the limitations and, more specifically, queuing theory so that you can build a system that meets the goals of the "manifesto".
If one is looking at programming "responsive" systems in terms of languages (which is not the intent, I think, of the manifesto), you can easily go back to the 1980's and 1990's. There were probably other such environments before then. However, around 1992/3, there was a language for the Macintosh called Prograph (and, Progragh CPX). It was a visual language that was based on "cases" with inputs and outputs. Outputs became available when all the inputs were satisfied - it was very asynchronous. Yes, you still had procedural elements. But, it was designed for parallel processing. Another, so called, "responsive" system is the spreadsheet where cells change based on the values in other cells in a very asynchronous fashion.
I won't state that some of today's "modern" languages don't solve specific problem of earlier languages or have something to offer. But, much of what that is claimed to be modern constructs have been around for years - maybe not as eloquently expressed, but were there nevertheless. This is where a CS degree comes in hand and why people pursue CS at colleges. Wish some people would get that through their heads. The other day, there was a story about how older IT professionals seem to have lost their fire while the "younger" generation is full of it and it's learning something new that makes them better than the old guard. No, older professionals simply say "ho-hum" to the "new" views as it's just a rehash of what they already know. When something revolutionary comes along, the wake up long enough to figure it out and whether it's something that's worth considering vs what HR thinks is the hopping buzzword of the day.
to quarantine them for weeks, like the early astronauts, before letting them come into town for supplies.
Yup, and we are worried about ebola when a bigger danger is lurking right in our very noses.
"Visa and Mastercard might have signed on, but that's not important. Retailer support is the critical factor. "
Having Visa and Mastercard sign on is a VERY BIG deal in obtaining retailer support. In order to use their services, you have to use approved terminals which they often provide or dictate the requirements of said terminals. If they providing or requiring Apple Pay capable terminals, the technology will penetrate the retail market quickly. Retailers will have little recourse if people demand mobile payments. With larger stores chains in the mix, the tech will be ubiquitous fairly quickly. I expect we will see vendors like Square adopt this tech pretty quickly so they can stay relevant. The Square device, for example, was free (or was it $10) for those that signed up with their service for those that wanted to accept cards.
Whether Google Wallet or PayPal can get in the mix, we'll see. Choice would be nice. However, I think we will see Apple Pay be the dominant tech in this industry. What is unclear is if the special chip Apple developed is a requirement or a nice-to-have and other vendors are free to implement in software or their own custom chip.
The entire argument is simply stupid. Just don't think that because you're a droid fan that it makes you immune to "enthralled fanatic syndrome". Look at how everyone want the next Nexus or Galaxy or S5 or Alpha or whatever. It goes both ways.
For me, the day that Apple devices don't get the job done for me, I will look at an Android device. But, my last experience was with an Incredible. It was anything but. That could be simply because HTC nor Verizon fixed issues that resulted in it rebooting or crashing at really inopportune times. But, it turned me away from the platform. As a developer, I prefer iOS (in the form of the iPad) as that's where the money is. When Android devices become mainstay in my client's enterprises, I will reexamine my development and business model at that time. So far, Android tablets don't meet their needs - primarily because they are too configurable and the innards accessible. Open is not always a good thing.
Just like the Gold iPhone and the new Gold Samsung S5(?)...when the other has it, it's stupid. But, damn, everybody wants it just the same don't they?
You aren't going to reason with a Fanboi or FANdroid - they both are set in their ways.
If people want to critize your Android phone for having a camera lens and are trolls, does it make sense to act the same way? Take the high road.
These are merely phones...nothing more. You pick what you like. If you want a camera that looks like the main weapon on a Dalek, that's your prerogative. Maybe, you can make it work and dispose of those who don't like your choice.
Yes, the "bulge" is clearly photoshopped out. I can only suspect the reason is that they want to show that the rest of the phone...the 95+% of the surface area is the stated thickness. During the keynote, the "bulge" was discussed. They could have shown the whole side view and position arrows or other marks to indicate the thickness. But, frankly, that would have been ugly, wouldn't it? Certainly, not Apple's way.
Now, iPhone / Apple fans aren't going to care that Apple marketers took this liberty with the images - they are going to buy it regardless.
Only those who want to find fault with Apple, for whatever reason, give a rat's ass that Apple might engage as something so underhanded as to photoshop out the "bulge" to clarify their marketing point.
What IS more interesting is how much attention Android fans are giving to something which they claim no interest in owning.
Now, I will digress.
Nobody (except true Fanbois) on the Apple side argues that Android phones might have had some features that found their way into Samsung and other Android phones first (i.e NFC, Google Wallet, etc). But, it took a company, like Apple, with the marketing clout and financial resources to get buy-in for actually using those features (such as NFC through Apple Pay). Apple only introduces features into their products for which they believe there to be a market or to remain relevant in a market. And, if a market doesn't yet exist, they know how to create it and they make it appear easy to use - as only Apple can.
The addition of NFC, for example, was probably done because they could now make it useful (vs "bumping" phones to transfer video..big whoop) by tackling mobile payments. Apple Pay addresses the process by never sharing credit card data, having unique, one-time, transaction number, and the ability to use a fingerprint to authenticate in a fraction of second. Well, those are the claims, anyway. They managed to get the major banks and store brands to jump on the bandwagon. And, in doing so, it appears Apple may have succeeded where Google and Samsung could not even with their more "technologically" advanced hardware and software solutions. Usability is the key to public acceptance - not technology. And, they seized upon the opportunity posed by "hackers" breaking in and stealing credit card data from major outlets to gain appeal for their solution.
Now, what remains to be seen is whether Apple allows others to play in the Apple Pay sandbox or not. If they don't, they might successfully corner the phone market for the average person with Apple Pay and an iPhone 6C provided the POS vendors elect not to integrate other mobile payment schemes into their terminals.
To remove the album, users need to:
Apple warned that, once the album has been removed from a user's account, it will no longer be available for them to redownload as a previous purchase. If they later decide they want the album, they will need to get it again.
The album is free to everyone until 13 October 2014, and will be available for purchase after that date.
(Not to mention that, on Apple platforms, you'd have to use Apple's language; forks have no bearing on that.)
Incorrect. Your code has to compile using their APIs. There are multiple tools out there for writing iOS and OSX code (Embarcadero RADStudio, Titanium, FreePascal, MonoTouch, etc.) . All code must be signed before it can be accepted into the AppStore. And, the code undergoes basic checks to such things as unauthorized API calls, missing images, etc. The signing requirement still has to be done using XCode. The alternative tools are able to call it to facilitate the signing process.
Swift and Objective-C through XCode are the PREFERRED tools that Apple supports. Outside of this realm, you are pretty much on your own with support being supplied by the alternative tool vendors.