I think the point this has is that it will automatically do the reconnect for you. What I'm not sold on is that this now requires an arbitrary port to be open on the server side in order to connect to the mosh server, and how irritated are the security guys who control the edge firewalls on your corporate network going to get?
If the library isn't exceptionally stable (e.g. libc, libm), then you ship all the.so dependencies with your program, or statically link.
Careful, if you're doing a commercial offering, many of the libraries that you may be linking to are LGPL, and thus you cannot statically link to them. And having to ship the.so's with your executable strikes me as wrong. They're shared objects because they're supposed to be shared.
Because you've immediately forgotten the concept of redundant power supplies? In a rack of 48 1U computers, that could be 96 AC-DC converters. Or replace those 96 with 2 (or 3, or 4, depending on risk tolerance) big, high-efficiency AC-DC converters. Better efficiency, easier to cool.
I find this somewhat offensive. Were these people wearing their seatbelts or not? Were they appropriately licensed or not? "Make them prove it in court!" in many cases sounds exactly like "Yeah, I broke the law, but if I take it to court and waste taxpayers money to pay the cop double time to show up, hope that he doesn't so that I can avoid the responsibility for my actions.".
They're the ones supplying the test server. They hopefully control all hops between the two. If their network topology doesn't support it, then they've failed in their topology design. Or their test server is in the wrong place to measure the latency.
Tried to find where AT&T actually says what speed their LTE is (their website only says "4x faster than our existing!"). So let's assume the slowest LTE speed, 100 MBit. 5 GB is roughly 50 GBit or 50000 MBit, the slowest LTE is 100 MBit (http://en.wikipedia.org/wiki/4G). 50000 / 100 = 50. So you can go at the really fast LTE speed for 1 minute total in a month before being throttled. Oh boy.
Hmm.. replacing all of those extra functor objects that you had to pass to algorithms with lambdas will drastically reduce those pieces of code. Not sure about 50% overall...
You do realize that the splash screen is showing you something useful, namely that the computer has heard and understood your request. Even Adobe's. It is better that the program throws up a splash screen and that rapidly changing status bar, instead of doing _nothing_ until the application springs forth fully formed. And in the meantime, you've launched three more copies, because the computer didn't acknowledge your first attempt. Also provides diagnostic information as to progress too (even if the splash screen only flashes by...)
No, that's security through secrecy, not obscurity. That's the difference between "This piece of text is encrypted with a mechanism, I don't know what algorithm.", and "This piece of text is encrypted with the old Ceasar Cipher.", and "This piece of text is encrypted with IDEA.". Statement 1 is using security through obscurity. You don't even know how to proceed. Statements 2 and 3 are using security through secrecy. You know what algorithm they're using so you know _how_ to decode it, if you know the secret key. How is this different than statement 1? The difference is that you happen to know that the Ceasar Cipher is trivial to brute-force, IDEA not so much. (Of course this doesn't mean that "security through secrecy" is guaranteed better than obscurity, just that obscurity is simply hoping that someone doesn't discover your vulnerable spot.)
Look up a product called the FrogPad. One-handed keyboard (comes in left and right-handed versions). Does punctuation and backspace (and arrows, and other special keys).
Pointing at the wrong failure. CRLs aren't the problem here. The CA that's publishing the CRL is. If the user is validating certs, and the cert cannot be validated, then they cannot know that they are dealing with Bob's Computer Bits, or Dewey Screwem and Howe.
So you're misusing the system, and complaining. When you revoke the old cert, you are stating that it is no longer to be trusted. And now you complain when it says "don't trust this"? I guess a car analogy: (Where I live, you are required to have proof of insurance stickers on your license plate.) You give a properly insured car to your buddy. 2 days later you go and remove the insurance stickers from the car. A week later, your friend is pissed off because the cops gave him a ticket for being uninsured. "But it was insured when I gave it to him."
Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.
And this is the problem with security. People want the security/safety.... unless it's inconvenient. And yes, there is something "wrong" with the certificate. It is unverifiable as to whether it is still valid. Which you asked it to do.
Note the "lets say OmniGraffle". Pick an app which is only distributed via the App Store. Say, the Blink SIP soft phone. Both the Lite and Pro versions are only available through the App Store.
But you have not said anything about how this applies to IT shops. How do I buy 30 licenses for (lets say OmniGraffle). How does one then assign those licenses to the 30 people that need them? Then later I fire #14 and hire a new person? So far the options are:
1) Buy the app under the employee's own Apple ID. But then #14 takes a copy of the software when he leaves.
2) Buy the app under the employee's corporate Apple ID. But then #14's Apple ID isn't in the company anymore, and nobody has that license.
3) Buy the app under some anonymous corporate Apple ID. (emp14@example.com). When I replace #14, the replacement gets _all_ of the Apps that #14 had.
And #3 has another problem that IT would have to retain (and manage) the passwords to all of the emp## accounts as the App literally has to be bought under that account, so IT would need to change the password, attach a credit card, buy the app, detach the credit card, change the password back.
Previously, one would buy 30 licenses of OmniGraffle, download the.dmg file, install on the appropriate 30 machines.
The objection that I see is that the platform supports the capability of loading arbitrary OSes, but if the manufacturer wants to run Windows on it, they must go out of their way to make it more difficult for the end user to run other OSes. As opposed to declaring that the device must be shipped in the way that enforces signed bootloaders, but the end-user may turn that enforcement off to load their own arbitrary OSes.
Slashdot Mirror
now that C++ will get move semantics
Not will, _has_ move semantics. As of last August.
C++11 (and C11) were voted on and passed last year. C++ in August and C in December.
Nope.. C++ is from last year... (C++11....) (Yeah, I know there are previous versions of C++...)
I think the point this has is that it will automatically do the reconnect for you. What I'm not sold on is that this now requires an arbitrary port to be open on the server side in order to connect to the mosh server, and how irritated are the security guys who control the edge firewalls on your corporate network going to get?
If the library isn't exceptionally stable (e.g. libc, libm), then you ship all the .so dependencies with your program, or statically link.
Careful, if you're doing a commercial offering, many of the libraries that you may be linking to are LGPL, and thus you cannot statically link to them. And having to ship the .so's with your executable strikes me as wrong. They're shared objects because they're supposed to be shared.
Because you've immediately forgotten the concept of redundant power supplies? In a rack of 48 1U computers, that could be 96 AC-DC converters. Or replace those 96 with 2 (or 3, or 4, depending on risk tolerance) big, high-efficiency AC-DC converters. Better efficiency, easier to cool.
I find this somewhat offensive. Were these people wearing their seatbelts or not? Were they appropriately licensed or not? "Make them prove it in court!" in many cases sounds exactly like "Yeah, I broke the law, but if I take it to court and waste taxpayers money to pay the cop double time to show up, hope that he doesn't so that I can avoid the responsibility for my actions.".
They're the ones supplying the test server. They hopefully control all hops between the two. If their network topology doesn't support it, then they've failed in their topology design. Or their test server is in the wrong place to measure the latency.
Augh! These failing eyes! Yep, 50,000 / 100 = 500. You get up to a little under 8 and a half minutes of speed.
Tried to find where AT&T actually says what speed their LTE is (their website only says "4x faster than our existing!"). So let's assume the slowest LTE speed, 100 MBit. 5 GB is roughly 50 GBit or 50000 MBit, the slowest LTE is 100 MBit (http://en.wikipedia.org/wiki/4G). 50000 / 100 = 50. So you can go at the really fast LTE speed for 1 minute total in a month before being throttled. Oh boy.
Hmm.. replacing all of those extra functor objects that you had to pass to algorithms with lambdas will drastically reduce those pieces of code. Not sure about 50% overall...
That should be spelled: for (auto & kitten : kittens)
Don't leave garbage lying around. Clean up after yourself.
Until you try to use it in a virtualized environment. Which of the hundreds of VM hosts is the application running on today?
You do realize that the splash screen is showing you something useful, namely that the computer has heard and understood your request. Even Adobe's. It is better that the program throws up a splash screen and that rapidly changing status bar, instead of doing _nothing_ until the application springs forth fully formed. And in the meantime, you've launched three more copies, because the computer didn't acknowledge your first attempt. Also provides diagnostic information as to progress too (even if the splash screen only flashes by...)
No, that's security through secrecy, not obscurity. That's the difference between "This piece of text is encrypted with a mechanism, I don't know what algorithm.", and "This piece of text is encrypted with the old Ceasar Cipher.", and "This piece of text is encrypted with IDEA.". Statement 1 is using security through obscurity. You don't even know how to proceed. Statements 2 and 3 are using security through secrecy. You know what algorithm they're using so you know _how_ to decode it, if you know the secret key. How is this different than statement 1? The difference is that you happen to know that the Ceasar Cipher is trivial to brute-force, IDEA not so much. (Of course this doesn't mean that "security through secrecy" is guaranteed better than obscurity, just that obscurity is simply hoping that someone doesn't discover your vulnerable spot.)
It does. Tried to change the "sleep time" and kaboom. Not even something weird, just changing a normal setting.
Look up a product called the FrogPad. One-handed keyboard (comes in left and right-handed versions). Does punctuation and backspace (and arrows, and other special keys).
Pointing at the wrong failure. CRLs aren't the problem here. The CA that's publishing the CRL is. If the user is validating certs, and the cert cannot be validated, then they cannot know that they are dealing with Bob's Computer Bits, or Dewey Screwem and Howe.
So you're misusing the system, and complaining. When you revoke the old cert, you are stating that it is no longer to be trusted. And now you complain when it says "don't trust this"? I guess a car analogy: (Where I live, you are required to have proof of insurance stickers on your license plate.) You give a properly insured car to your buddy. 2 days later you go and remove the insurance stickers from the car. A week later, your friend is pissed off because the cops gave him a ticket for being uninsured. "But it was insured when I gave it to him."
Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.
And this is the problem with security. People want the security/safety.... unless it's inconvenient. And yes, there is something "wrong" with the certificate. It is unverifiable as to whether it is still valid. Which you asked it to do.
Note the "lets say OmniGraffle". Pick an app which is only distributed via the App Store. Say, the Blink SIP soft phone. Both the Lite and Pro versions are only available through the App Store.
But you have not said anything about how this applies to IT shops. How do I buy 30 licenses for (lets say OmniGraffle). How does one then assign those licenses to the 30 people that need them? Then later I fire #14 and hire a new person? So far the options are: 1) Buy the app under the employee's own Apple ID. But then #14 takes a copy of the software when he leaves. 2) Buy the app under the employee's corporate Apple ID. But then #14's Apple ID isn't in the company anymore, and nobody has that license. 3) Buy the app under some anonymous corporate Apple ID. (emp14@example.com). When I replace #14, the replacement gets _all_ of the Apps that #14 had. And #3 has another problem that IT would have to retain (and manage) the passwords to all of the emp## accounts as the App literally has to be bought under that account, so IT would need to change the password, attach a credit card, buy the app, detach the credit card, change the password back. Previously, one would buy 30 licenses of OmniGraffle, download the .dmg file, install on the appropriate 30 machines.
Don't do that either.
The objection that I see is that the platform supports the capability of loading arbitrary OSes, but if the manufacturer wants to run Windows on it, they must go out of their way to make it more difficult for the end user to run other OSes. As opposed to declaring that the device must be shipped in the way that enforces signed bootloaders, but the end-user may turn that enforcement off to load their own arbitrary OSes.