Why is the entire file necessary for the interview? A relevant excerpt, only what the applicant claims with respect to Joe, can be walked back across that air gap and sent to the regional office. The interview results then get walked past the air gap and merged/appended to the file. Naturally what really gets walked across is a large number of excerpts and data to merge/append.
Whether it's all of the file or part of the file is irrelevant, since the transmission time via USPS or UPS or FedEx is the same (per company obviously) whether you're sending a single page or a whole stack of pages. Your point about malware is well-taken though.
Apologies for being not being clear but the fragment of a single file would be sent electronically via a network. The point is that the entire database does not need to be exposed and vulnerable to a single breach.
The SF-86 is an online form. How are you going to airgap that?
Entry occurs on the public side of the gap. An applicant's data gets transferred to electronic media and walked across the gap. The applicant's data then get merged into the air gapped database that holds *everyone's* data.
Remember, before cat-5 cables we had station wagons loaded with tapes and it worked quite well.:-)
If you air-gap that system you have to hire someone to either run OCR scans or enter all that data by hand into the database.
Or someone does a malware scan of electronic media and if all clear they walk the media past the air gap.
Let's say your character witness is Joe Schmuckatelly who lives in California and you live in Nebraska. It's easier and less expensive for the regional office in Nebraska to put the file on the network and request the regional office in California to interview Joe.
Why is the entire file necessary for the interview? A relevant excerpt, only what the applicant claims with respect to Joe, can be walked back across that air gap and sent to the regional office. The interview results then get walked past the air gap and merged/appended to the file. Naturally what really gets walked across is a large number of excerpts and data to merge/append.
In short air gaps allow for electronic data input and output, just in a very controlled and monitored manner.
If Congress again passes a requirement for departments to do something but refuses to fund it then the executive branch can't do anything.
Not true. The agency can cut spending elsewhere to implement the requirement. Which is what Congress wants the IRS to do, while the IRS want to use the excuse of no new funding to maintain things as they are. It all just theatre.
nadaou was quite clearly referring to the AC's use of a specific cliche... In any event, refuting the claim "using cliches is stupid" isn't the same thing as rufuting "using cliches weakens an argument" or "cliches contain no truth".
Actually my criticism included that specific cliche, and my later examples referred to that specific cliche, and demonstrating a kernel of truth in that specific cliche refutes the assertion that the cliche is stupid. Its merely unimaginative.
an expression, idea, or element of an artistic work which has become overused to the point of losing its original meaning or effect, even to the point of being trite or irritating, especially when at some earlier time it was considered meaningful or novel.
I never said one definition is superior to another, I merely pointed out that *some* definitions indicate that the use of cliches could be meaningless and therefore detrimental to a coherent argument.
Actually it seems a quite rare definition, possibly erroneous, buy hey its wiki. The wiki references include several dictionaries and they agree with the loss of impact. The wiki editor apparently lifted the definition from a literary device website. So we can go with dictionary, after dictionary, after dictionary, after dictionary, or some guy's literary device website.
Yeah, I really did check 4 dictionaries, I thought maybe I got lucky with the first but all 4 agreed.
When I look at your original response, what I see is you refuting an argument that nadaou didn't make. Nowhere in nadaou's post does he claim that cliches weaken an argument or that cliches don't contain a nugget of truth.
He was implying cliches shouldn't be used because they are stupid. I responded pointing out that though overused cliches can convey a truth, refuting the notion that cliches are inherently stupid.
No, I expect that it would be more accurate to say that cliches lose their impact from overuse.
Re-wording a definition to better fit your position doesn't really convince me of anything. But hey, I've obviously been mistaken about a lot of things, so maybe I'm wrong about this as well.
From http://dictionary.reference.co....
"1. a trite, stereotyped expression; a sentence or phrase, usually expressing a popular or common thought or idea, that has lost originality, ingenuity, and impact by long overuse"
Nevertheless half of a real GUI heavy application is GUI code. No idea how you come to the idea that your chemical bonding app uses significantly less than 50% in the GUI.
Perhaps I am not being clear. When I am referring to GUI code I am referring to the platform specific GUI API (iOS, Android, Mac OS, Windows, etc). Actually I am referring to all the platforms specific code be it graphical or not. I am contrasting that with portable c/c++ code that implements functionality. This functionality includes graphics, interpreting user events, translating this into desired actions in the program, etc. The platform specific code generally takes the platform specific events, coordinate systems, etc and converts that to internal normalized portable counterparts that the core code uses. The core code is doing "event" and "graphics" work. The handling of platform specific events and translating to the internal events is a minor portion of the overall work. A minor portion to replicate per platform.
My line for GUI code is the platform specific API, not what code deals with events or graphics. Perhaps I would have been clearer if I had said that if 50% of your code is platform specific you are doing it wrong.
Where some people get the wrong impression is when an app is written with only one target in mind. For example MS Windows. In such cases it is common to see much core functionality implemented directly in the code interfacing with the Windows API. Similar story if something like QT is being used. What appears to be GUI code gets bloated with
core functionality.
Your idea that portable GUI code is not possible is minimum 35 years outdated.
You are confused, no one said it is not possible. What is being said is that it puts a modern app at a competitive disadvantage in the market. In particular the modern app market where first impressions and word of mouth is critical. An absolutely native look and feel is essential today, as is the expected platform specific functionality. Things have changed radically with the move to iOS and Android. And the desktop specific app stores are helping to replicate such consumer expectations for Windows and Mac desktop apps.
No, not at all. The reason you are in the trees is that you are failing to distinguish between defending the original AC and rejecting the notion that use of a cliche implies falsehood. Those are different things. I'm not engaging in the former, only the later, but you are failing to see that. Hence the trees.
What I was arguing against was that cliche use somehow devalues an argument. It does not.
I tend to agree, but if you look at the post in question
"You're goddamn right we are the good guys. If you love China so much, then go live there."
Yes, please look at the post in question, but its not the one you think. The relevant one would actually be my original response where I did *not* include that first sentence, only the second. Can you imagine the reason? I'll offer a hint, I wasn't interested in the debate around the first. I was only interested in the cliche aspect of your response. Something tangential.
Generally, using tired language doesn't weaken an argument. In this specific case however, the AC made a two sentence post with the last sentence composed entirely of a cliche typically employed by obstinate adolescents.
Actually, no. The "love it or leave it" meme was employed by a much older demographic historically.
There's no argument made, there's nothing that amounts to "figurative language", and there's nothing even remotely close to "truth".
But by all means, continue to imbibe AC's two sentence post with a much depth of thought and "truth" as you like.
Again, you have deluded yourself. I was only interested in the later of the two sentences and your apparent reaction to suggest a cliche lacks a kernel of truth. Trees.
ps - you should take note that many definitions of "cliche" describe them as phrases that are overused to the point of losing their original meaning.
No, I expect that it would be more accurate to say that cliches lose their impact from overuse. The point, the kernels of truth, are not changed by overuse.
A Large government (with virtually unlimited funding) will crack any commodity encryption scheme.
That claim goes against all public analysis of the ciphers in play - what extraordinary evidence do you have to support it? Hollywood doesn't count.
Recall that physical access to the hardware trumps most security. In the crypto world physical access to the person who has the cipher keys would be the equivalent. Ignoring coercion, the CIA and KGB performed many amazing technical surveillance feats back in the day. Some of it damn near unbelievable, beyond what hollywood dreams up (ex 1945-52 a listening device with no power supply or active electronics, https://en.wikipedia.org/wiki/.... There is no reason to believe comparable technical feats no longer occur.
Um...
There is no reason to believe comparable technical feats no longer occur.
Cracking the 1945 government grade equivalent of a cereal box (mechanical) decoder ring is a LOT easier than than decrypting a modern one.
You really should read the link regarding the 1945 hack. Its not at all what you are assuming. It is truly amazing even by todays standards.
Computers have gotten faster, which works on both sides of the equation, but codes have gotten bigger which only helps the encrypter, not the decryption team.
Which is irrelevant. The technical feats being discussed are not those that would break encryption, rather they are those that would hack or otherwise defeat the humans doing decryption. Snowden's data is only secure if no one accesses it. Once accessed, if the machine used for decryption is somehow insecure (like the US Embassy in 1945) then the data is "leaked".
The plausibility of the idea that Russia or China has access to Snowden's data has little to do with NSA statements. Having physical access to Snowden increases that plausibility. Having Snowden's data in the hands of journalists greatly increases that plausibility.
Many commenters are acting as if breaking the crypto would be necessary. That is severely misguided. Hacking and technical espionage are all that is required. It is quite plausible for Snowden's data to have "leaked".
The reliability of the NSA statement has far more to do with this plausibility than the NSA's track record. Its plausible that the facts are coincidentally on the NSA's side.
Still lost in the trees I see. What I was arguing against was that cliche use somehow devalues an argument. It does not. Whether a person is creative in their language or not is only relevant to the the "selling" of an idea, not the actual facts behind an idea. And your "judgement" does not alter the fact that those critical of the US often prefer to live in the US. The figurative language you dismiss is not a literal invite to leave, it points out a hypocrisy of harsh critics who think the US is so evil yet they choose to remain. Suggesting that their actions expose the exaggeration of their words. In contrast to many of our ancestors who lived somewhere they thought was bad and decided to actually leave.
Well, you seem not even able to use a cross platform library correctly.
You mean working around the library and writing native code for platforms specific functionality?
Even for functionality that is common compromises sometimes have to be made and it does effect apps. I've ran more than one QT based app on a Windows box where my first impression was "why does this look like something from a Linux desktop?". For some apps that is OK, for others it is not.
Basically shortcuts involve tradeoffs, tradeoff have both upsides and downsides. And in the world of apps where word-of-mouth and first impressions are *everything* those downsides can be significant.
Then you come with a trivial example for GUI/core interaction. Using a "pocket calculator" is extremely brain dead as it has nothing which a GUI on it. The calculator would look and feel exactly the same with ANSI Text "GUI"s calling a bunch of buttons and a single text field a GUI is joke at best and idiotic at worse.
Simple examples often convey an idea more simply. The fact remains that in this core c/c++ code links to an iOS GUI, an Android GUI, and Linux console apps for regression testing and fuzzing. From the core code's perspective it has no idea whether a human user is driving it from a GUI or it is being driven from a script and is running on a headless Linux box in the closet for automated testing.
Plus this simple example also illustrates that even for a simple app if your UI code is more than half the program you may be doing something terribly wrong.
I suggest to port a CAD or CASE application or at least a simple drawing application from Windows to a Mac...
Actually I once led a team doing chemical diagraming and molecular modeling and visualization software. We used the same technique of minimizing the UI code and creating a c/c++ api representing primitive user interactions. Mouse up/down/move, button up/down, keyboard key up/down, etc. This again allowed scripting from a Linux console app. For example the selection of a chemical bond drawing tool followed by a series of mouse down/move/up actions that create a carbon ring. Such automation is very helpful to testing. It also allows the code to be easily run on various hardware targets. The core code, the actual functionality behind diagram and molecular model creation based on user actions, could be tested and debugged in parallel to the development of a GUI for a new platform.
... and then do the same with QT. Nothing to port in the later case, and nothing to notice any difference from your manual port before. Only the most keen eyes might spot a different pixel somewhere when you use a special GUI element to show case a portability issue.
Actually when going between iOS and Android it does not take a keen eye. There is often a user expectation of platform specific functionality. Least common denominator designs often suffer in user evaluations. Its a fact of life for apps that depend on word of mouth and first impressions rather than a marketing department selling to corporate clients.
That's such a classically stupid cliche of a line, you should be embarrassed to use it.
Cliches are overused lines. Overuse does not imply falsehood. In fact cliches often express a truth, they just express the truth in a tired unoriginal unartistic manner. Yet, a truth is a truth.
LOL, How is there any truth to the statement "If you love China so much, then go live there"? Such a statement is on the same intellectual level as "if you love China so much, why don't you marry it?" No truth there either.
Your statement is on the same intellectual level of creationists who take the biblical genesis to mean the world is 6,000 years old. The cliche, like the biblical story, is to be taken as figurative language not a literal truth. The figurative language in this case illustrating the truth that very few critics of the US would want to live anywhere else.
That said, you are also having a forest and trees moment. In my post I was simply pointing out that cliches, like myths, old sayings, etc sometimes have a kernel of truth in them.
They'd statistically be more Iikely to be correct assuming the NSA is lying.
Actually that is debatable. Successful lying usually involves a lot of truth telling too. Plus why would the truth be statistically unfavorable to the NSA? The truth is the truth regardless of the character of the person or organization sharing it. Its an extreme example but consider NSA claims about some ISIS member doing bad things.
Now Snowden is certainly quite different than an ISIS member but the fact that he has accessed his encrypted data while in China and Russia leaves the door open to technical surveillance, hacking or some other manner of inadvertent sharing of his cypher keys. As I mentioned in another post they have physical access to him and his laptop and that physical access can make security breaches far easier. People who are assuming a brute force attack or a flaw in an encryption algorithm are being quite narrow minded.
And then there are journalists who have access to his data.
Critical intelligent people think otherwise, but they are lost and this propaganda is not for them.
Critical intelligent people are open minded. They are quite aware of the fact that a professional liar will tell the truth when the truth coincidentally serves the liar's interests.
A person that automatically believes the NSA is lying is really not much different than a person that automatically believes the NSA is telling the truth.
That's such a classically stupid cliche of a line, you should be embarrassed to use it.
Cliches are overused lines. Overuse does not imply falsehood. In fact cliches often express a truth, they just express the truth in a tired unoriginal unartistic manner. Yet, a truth is a truth.
A Large government (with virtually unlimited funding) will crack any commodity encryption scheme.
That claim goes against all public analysis of the ciphers in play - what extraordinary evidence do you have to support it? Hollywood doesn't count.
Recall that physical access to the hardware trumps most security. In the crypto world physical access to the person who has the cipher keys would be the equivalent. Ignoring coercion, the CIA and KGB performed many amazing technical surveillance feats back in the day. Some of it damn near unbelievable, beyond what hollywood dreams up (ex 1945-52 a listening device with no power supply or active electronics, https://en.wikipedia.org/wiki/.... There is no reason to believe comparable technical feats no longer occur.
All modern farming is "overfarming" compared to primitive naturalistic techniques. Going beyond such techniques is how we avoid a Malthusian catastrophe. Its not unique to the central valley.
Or use Qt for the frontend. Honestly: it makes no sense at all to rewrite GUI code.
No, it absolutely makes sense to use the native api of a platform to create the user interface. Otherwise your app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all least-common-denominator solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.
50% or more of the code for an app is GUI...
That must be a fairly trivial app. Or your design and implementation is wrong. Lets use a scientific/statistical/business/hex/bill/tip calculator app that I wrote as an example. All the math is naturally in the core. So is an api that the user interface will call. This api basically includes a function for each button possible press.
The platforms specific side of the code does nothing more than call the appropriate button press C api function (ex button_1() button_plus() button_2() button_equals()). The core code does all the real work. I can re-use the core on Android or on a desktop OS. I even build this core code against a Linux console front end. Two actually, one for a scripted regression test that simulates user button presses and another that generates random values and operations for fuzzing. Note that these tests are not using a special api, they are using the exact same api that the user interface code is using. Things like that are important.
Honestly: it makes no sense at all to rewrite GUI code.
50% or more of the code for an app is GUI...
No, it absolutely make sense to use the native api of a platform to create the user interface. Otherwise you app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.
... the Android market share is much greater than the Apple market share...
And app revenue is 1/4 to 1/5 on Android compared to iOS. Its actually still more profitable on the iOS side due to its users spending more per app.
Plus it doesn't take much for a Java dev to turn his/her skills to Android, and C is the only language more popular than Java. In reality I doubt either platform will have issue finding developers.
And C/C++ is probably what the core of your app should be written in so its portable to iOS, Android, Linux, Mac OS X and MS Windows. Only the user interface code needs to use java, swift, or objective-c. And its often best to just rewrite the UI in the language of the API for each platform.
Well its now available for Linux and it has been open sourced.
But more importantly its compatibility is largely irrelevant. Keep the UI and core code separate. The core of an app/game should usually be written in C/C++ for compatibility. Its not all that difficult to keep core code in C/C++ compatible for iOS, Android, Mac OS X, Linux, and MS Windows. Been there done that plenty of times. And its often best to just go with the language that is native for the platform with respect to the UI code.
Slashdot Mirror
To be fair, low power embedded CPUs can be quite capable these days and are likely to only get more capable.
Is there a big advantage to going 8-bit 8051 over ultra-low-power 32-bit ARM these days?
Why is the entire file necessary for the interview? A relevant excerpt, only what the applicant claims with respect to Joe, can be walked back across that air gap and sent to the regional office. The interview results then get walked past the air gap and merged/appended to the file. Naturally what really gets walked across is a large number of excerpts and data to merge/append.
Whether it's all of the file or part of the file is irrelevant, since the transmission time via USPS or UPS or FedEx is the same (per company obviously) whether you're sending a single page or a whole stack of pages. Your point about malware is well-taken though.
Apologies for being not being clear but the fragment of a single file would be sent electronically via a network. The point is that the entire database does not need to be exposed and vulnerable to a single breach.
The SF-86 is an online form. How are you going to airgap that?
Entry occurs on the public side of the gap. An applicant's data gets transferred to electronic media and walked across the gap. The applicant's data then get merged into the air gapped database that holds *everyone's* data.
:-)
Remember, before cat-5 cables we had station wagons loaded with tapes and it worked quite well.
If you air-gap that system you have to hire someone to either run OCR scans or enter all that data by hand into the database.
Or someone does a malware scan of electronic media and if all clear they walk the media past the air gap.
Let's say your character witness is Joe Schmuckatelly who lives in California and you live in Nebraska. It's easier and less expensive for the regional office in Nebraska to put the file on the network and request the regional office in California to interview Joe.
Why is the entire file necessary for the interview? A relevant excerpt, only what the applicant claims with respect to Joe, can be walked back across that air gap and sent to the regional office. The interview results then get walked past the air gap and merged/appended to the file. Naturally what really gets walked across is a large number of excerpts and data to merge/append.
In short air gaps allow for electronic data input and output, just in a very controlled and monitored manner.
If Congress again passes a requirement for departments to do something but refuses to fund it then the executive branch can't do anything.
Not true. The agency can cut spending elsewhere to implement the requirement. Which is what Congress wants the IRS to do, while the IRS want to use the excuse of no new funding to maintain things as they are. It all just theatre.
nadaou was quite clearly referring to the AC's use of a specific cliche ... In any event, refuting the claim "using cliches is stupid" isn't the same thing as rufuting "using cliches weakens an argument" or "cliches contain no truth".
Actually my criticism included that specific cliche, and my later examples referred to that specific cliche, and demonstrating a kernel of truth in that specific cliche refutes the assertion that the cliche is stupid. Its merely unimaginative.
From http://dictionary.reference.com/browse/cliche
So what? From Wikipedia
an expression, idea, or element of an artistic work which has become overused to the point of losing its original meaning or effect, even to the point of being trite or irritating, especially when at some earlier time it was considered meaningful or novel.
I never said one definition is superior to another, I merely pointed out that *some* definitions indicate that the use of cliches could be meaningless and therefore detrimental to a coherent argument.
Actually it seems a quite rare definition, possibly erroneous, buy hey its wiki. The wiki references include several dictionaries and they agree with the loss of impact. The wiki editor apparently lifted the definition from a literary device website. So we can go with dictionary, after dictionary, after dictionary, after dictionary, or some guy's literary device website.
Yeah, I really did check 4 dictionaries, I thought maybe I got lucky with the first but all 4 agreed.
When I look at your original response, what I see is you refuting an argument that nadaou didn't make. Nowhere in nadaou's post does he claim that cliches weaken an argument or that cliches don't contain a nugget of truth.
He was implying cliches shouldn't be used because they are stupid. I responded pointing out that though overused cliches can convey a truth, refuting the notion that cliches are inherently stupid.
No, I expect that it would be more accurate to say that cliches lose their impact from overuse.
Re-wording a definition to better fit your position doesn't really convince me of anything. But hey, I've obviously been mistaken about a lot of things, so maybe I'm wrong about this as well.
From http://dictionary.reference.co....
"1. a trite, stereotyped expression; a sentence or phrase, usually expressing a popular or common thought or idea, that has lost originality, ingenuity, and impact by long overuse"
Nevertheless half of a real GUI heavy application is GUI code. No idea how you come to the idea that your chemical bonding app uses significantly less than 50% in the GUI.
Perhaps I am not being clear. When I am referring to GUI code I am referring to the platform specific GUI API (iOS, Android, Mac OS, Windows, etc). Actually I am referring to all the platforms specific code be it graphical or not. I am contrasting that with portable c/c++ code that implements functionality. This functionality includes graphics, interpreting user events, translating this into desired actions in the program, etc. The platform specific code generally takes the platform specific events, coordinate systems, etc and converts that to internal normalized portable counterparts that the core code uses. The core code is doing "event" and "graphics" work. The handling of platform specific events and translating to the internal events is a minor portion of the overall work. A minor portion to replicate per platform.
My line for GUI code is the platform specific API, not what code deals with events or graphics. Perhaps I would have been clearer if I had said that if 50% of your code is platform specific you are doing it wrong.
Where some people get the wrong impression is when an app is written with only one target in mind. For example MS Windows. In such cases it is common to see much core functionality implemented directly in the code interfacing with the Windows API. Similar story if something like QT is being used. What appears to be GUI code gets bloated with core functionality.
Your idea that portable GUI code is not possible is minimum 35 years outdated.
You are confused, no one said it is not possible. What is being said is that it puts a modern app at a competitive disadvantage in the market. In particular the modern app market where first impressions and word of mouth is critical. An absolutely native look and feel is essential today, as is the expected platform specific functionality. Things have changed radically with the move to iOS and Android. And the desktop specific app stores are helping to replicate such consumer expectations for Windows and Mac desktop apps.
Still lost in the trees I see.
Still trolling I see.
No, not at all. The reason you are in the trees is that you are failing to distinguish between defending the original AC and rejecting the notion that use of a cliche implies falsehood. Those are different things. I'm not engaging in the former, only the later, but you are failing to see that. Hence the trees.
What I was arguing against was that cliche use somehow devalues an argument. It does not.
I tend to agree, but if you look at the post in question
"You're goddamn right we are the good guys. If you love China so much, then go live there."
Yes, please look at the post in question, but its not the one you think. The relevant one would actually be my original response where I did *not* include that first sentence, only the second. Can you imagine the reason? I'll offer a hint, I wasn't interested in the debate around the first. I was only interested in the cliche aspect of your response. Something tangential.
Generally, using tired language doesn't weaken an argument. In this specific case however, the AC made a two sentence post with the last sentence composed entirely of a cliche typically employed by obstinate adolescents.
Actually, no. The "love it or leave it" meme was employed by a much older demographic historically.
There's no argument made, there's nothing that amounts to "figurative language", and there's nothing even remotely close to "truth". But by all means, continue to imbibe AC's two sentence post with a much depth of thought and "truth" as you like.
Again, you have deluded yourself. I was only interested in the later of the two sentences and your apparent reaction to suggest a cliche lacks a kernel of truth. Trees.
ps - you should take note that many definitions of "cliche" describe them as phrases that are overused to the point of losing their original meaning.
No, I expect that it would be more accurate to say that cliches lose their impact from overuse. The point, the kernels of truth, are not changed by overuse.
A Large government (with virtually unlimited funding) will crack any commodity encryption scheme.
That claim goes against all public analysis of the ciphers in play - what extraordinary evidence do you have to support it? Hollywood doesn't count.
Recall that physical access to the hardware trumps most security. In the crypto world physical access to the person who has the cipher keys would be the equivalent. Ignoring coercion, the CIA and KGB performed many amazing technical surveillance feats back in the day. Some of it damn near unbelievable, beyond what hollywood dreams up (ex 1945-52 a listening device with no power supply or active electronics, https://en.wikipedia.org/wiki/.... There is no reason to believe comparable technical feats no longer occur.
Um...
There is no reason to believe comparable technical feats no longer occur.
Cracking the 1945 government grade equivalent of a cereal box (mechanical) decoder ring is a LOT easier than than decrypting a modern one.
You really should read the link regarding the 1945 hack. Its not at all what you are assuming. It is truly amazing even by todays standards.
Computers have gotten faster, which works on both sides of the equation, but codes have gotten bigger which only helps the encrypter, not the decryption team.
Which is irrelevant. The technical feats being discussed are not those that would break encryption, rather they are those that would hack or otherwise defeat the humans doing decryption. Snowden's data is only secure if no one accesses it. Once accessed, if the machine used for decryption is somehow insecure (like the US Embassy in 1945) then the data is "leaked".
The plausibility of the idea that Russia or China has access to Snowden's data has little to do with NSA statements. Having physical access to Snowden increases that plausibility. Having Snowden's data in the hands of journalists greatly increases that plausibility.
Many commenters are acting as if breaking the crypto would be necessary. That is severely misguided. Hacking and technical espionage are all that is required. It is quite plausible for Snowden's data to have "leaked".
The reliability of the NSA statement has far more to do with this plausibility than the NSA's track record. Its plausible that the facts are coincidentally on the NSA's side.
Still lost in the trees I see. What I was arguing against was that cliche use somehow devalues an argument. It does not. Whether a person is creative in their language or not is only relevant to the the "selling" of an idea, not the actual facts behind an idea. And your "judgement" does not alter the fact that those critical of the US often prefer to live in the US. The figurative language you dismiss is not a literal invite to leave, it points out a hypocrisy of harsh critics who think the US is so evil yet they choose to remain. Suggesting that their actions expose the exaggeration of their words. In contrast to many of our ancestors who lived somewhere they thought was bad and decided to actually leave.
Well, you seem not even able to use a cross platform library correctly.
You mean working around the library and writing native code for platforms specific functionality?
Even for functionality that is common compromises sometimes have to be made and it does effect apps. I've ran more than one QT based app on a Windows box where my first impression was "why does this look like something from a Linux desktop?". For some apps that is OK, for others it is not.
Basically shortcuts involve tradeoffs, tradeoff have both upsides and downsides. And in the world of apps where word-of-mouth and first impressions are *everything* those downsides can be significant.
Then you come with a trivial example for GUI/core interaction. Using a "pocket calculator" is extremely brain dead as it has nothing which a GUI on it. The calculator would look and feel exactly the same with ANSI Text "GUI"s calling a bunch of buttons and a single text field a GUI is joke at best and idiotic at worse.
Simple examples often convey an idea more simply. The fact remains that in this core c/c++ code links to an iOS GUI, an Android GUI, and Linux console apps for regression testing and fuzzing. From the core code's perspective it has no idea whether a human user is driving it from a GUI or it is being driven from a script and is running on a headless Linux box in the closet for automated testing.
Plus this simple example also illustrates that even for a simple app if your UI code is more than half the program you may be doing something terribly wrong.
I suggest to port a CAD or CASE application or at least a simple drawing application from Windows to a Mac ...
Actually I once led a team doing chemical diagraming and molecular modeling and visualization software. We used the same technique of minimizing the UI code and creating a c/c++ api representing primitive user interactions. Mouse up/down/move, button up/down, keyboard key up/down, etc. This again allowed scripting from a Linux console app. For example the selection of a chemical bond drawing tool followed by a series of mouse down/move/up actions that create a carbon ring. Such automation is very helpful to testing. It also allows the code to be easily run on various hardware targets. The core code, the actual functionality behind diagram and molecular model creation based on user actions, could be tested and debugged in parallel to the development of a GUI for a new platform.
... and then do the same with QT. Nothing to port in the later case, and nothing to notice any difference from your manual port before. Only the most keen eyes might spot a different pixel somewhere when you use a special GUI element to show case a portability issue.
Actually when going between iOS and Android it does not take a keen eye. There is often a user expectation of platform specific functionality. Least common denominator designs often suffer in user evaluations. Its a fact of life for apps that depend on word of mouth and first impressions rather than a marketing department selling to corporate clients.
> If you love China so much, then go live there.
That's such a classically stupid cliche of a line, you should be embarrassed to use it.
Cliches are overused lines. Overuse does not imply falsehood. In fact cliches often express a truth, they just express the truth in a tired unoriginal unartistic manner. Yet, a truth is a truth.
LOL, How is there any truth to the statement "If you love China so much, then go live there"? Such a statement is on the same intellectual level as "if you love China so much, why don't you marry it?" No truth there either.
Your statement is on the same intellectual level of creationists who take the biblical genesis to mean the world is 6,000 years old. The cliche, like the biblical story, is to be taken as figurative language not a literal truth. The figurative language in this case illustrating the truth that very few critics of the US would want to live anywhere else.
That said, you are also having a forest and trees moment. In my post I was simply pointing out that cliches, like myths, old sayings, etc sometimes have a kernel of truth in them.
They'd statistically be more Iikely to be correct assuming the NSA is lying.
Actually that is debatable. Successful lying usually involves a lot of truth telling too. Plus why would the truth be statistically unfavorable to the NSA? The truth is the truth regardless of the character of the person or organization sharing it. Its an extreme example but consider NSA claims about some ISIS member doing bad things.
Now Snowden is certainly quite different than an ISIS member but the fact that he has accessed his encrypted data while in China and Russia leaves the door open to technical surveillance, hacking or some other manner of inadvertent sharing of his cypher keys. As I mentioned in another post they have physical access to him and his laptop and that physical access can make security breaches far easier. People who are assuming a brute force attack or a flaw in an encryption algorithm are being quite narrow minded.
And then there are journalists who have access to his data.
Critical intelligent people think otherwise, but they are lost and this propaganda is not for them.
Critical intelligent people are open minded. They are quite aware of the fact that a professional liar will tell the truth when the truth coincidentally serves the liar's interests.
A person that automatically believes the NSA is lying is really not much different than a person that automatically believes the NSA is telling the truth.
> If you love China so much, then go live there.
That's such a classically stupid cliche of a line, you should be embarrassed to use it.
Cliches are overused lines. Overuse does not imply falsehood. In fact cliches often express a truth, they just express the truth in a tired unoriginal unartistic manner. Yet, a truth is a truth.
And- all hostile governments are allies!
But the Enemy of My Enemy is my Friend. Right?
Do you tell your friends your deepest darkest secrets? Especially the new friends, the friends of convenience?
A Large government (with virtually unlimited funding) will crack any commodity encryption scheme.
That claim goes against all public analysis of the ciphers in play - what extraordinary evidence do you have to support it? Hollywood doesn't count.
Recall that physical access to the hardware trumps most security. In the crypto world physical access to the person who has the cipher keys would be the equivalent. Ignoring coercion, the CIA and KGB performed many amazing technical surveillance feats back in the day. Some of it damn near unbelievable, beyond what hollywood dreams up (ex 1945-52 a listening device with no power supply or active electronics, https://en.wikipedia.org/wiki/.... There is no reason to believe comparable technical feats no longer occur.
All modern farming is "overfarming" compared to primitive naturalistic techniques. Going beyond such techniques is how we avoid a Malthusian catastrophe. Its not unique to the central valley.
Apologies, I hits the submit button prematurely. Please read my response to my other post, its the full response, the first was a work in progress.
Or use Qt for the frontend. Honestly: it makes no sense at all to rewrite GUI code.
No, it absolutely makes sense to use the native api of a platform to create the user interface. Otherwise your app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all least-common-denominator solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.
50% or more of the code for an app is GUI ...
That must be a fairly trivial app. Or your design and implementation is wrong. Lets use a scientific/statistical/business/hex/bill/tip calculator app that I wrote as an example. All the math is naturally in the core. So is an api that the user interface will call. This api basically includes a function for each button possible press.
The platforms specific side of the code does nothing more than call the appropriate button press C api function (ex button_1() button_plus() button_2() button_equals()). The core code does all the real work. I can re-use the core on Android or on a desktop OS. I even build this core code against a Linux console front end. Two actually, one for a scripted regression test that simulates user button presses and another that generates random values and operations for fuzzing. Note that these tests are not using a special api, they are using the exact same api that the user interface code is using. Things like that are important.
Or use Qt for the frontend.
Honestly: it makes no sense at all to rewrite GUI code.
50% or more of the code for an app is GUI ...
No, it absolutely make sense to use the native api of a platform to create the user interface. Otherwise you app does not look or behave as expected and that has been shown to be harmful to an app's success. So if its an internal enterprise app that people will be told to use, fine, take that shortcut. However if your app's success depends on being embraced by the public absolutely beware of these one-size-fits-all solutions. Your app must look native, it must look current, it must support all the built-in shortcuts, etc.
... the Android market share is much greater than the Apple market share ...
And app revenue is 1/4 to 1/5 on Android compared to iOS. Its actually still more profitable on the iOS side due to its users spending more per app.
Plus it doesn't take much for a Java dev to turn his/her skills to Android, and C is the only language more popular than Java. In reality I doubt either platform will have issue finding developers.
And C/C++ is probably what the core of your app should be written in so its portable to iOS, Android, Linux, Mac OS X and MS Windows. Only the user interface code needs to use java, swift, or objective-c. And its often best to just rewrite the UI in the language of the API for each platform.
How's Swift's cross-platform suitability?
Well its now available for Linux and it has been open sourced.
But more importantly its compatibility is largely irrelevant. Keep the UI and core code separate. The core of an app/game should usually be written in C/C++ for compatibility. Its not all that difficult to keep core code in C/C++ compatible for iOS, Android, Mac OS X, Linux, and MS Windows. Been there done that plenty of times. And its often best to just go with the language that is native for the platform with respect to the UI code.