I didn't claim 4G/LTE. I claimed it worked fine. No worse than in the US which is supposed to offer 4G, but forgets to actually attach it to the internet by anything faster than a damp piece of string.
>Nexus 4 is great. Except the battery thermal sensor dies in all of them in the end, causing the phone to randomly power off. 2 out of 2 Nexus 4s in my household went this way. The internet is full of people in the same boat.
Python is super handy if you need to solve problems with a quick program you only run a few times. The time spent writing it is longer than the time spent running it.
If you're writing code to be run billions of times, then using a compiled language that is slower to develop in would be a better choice.
I've written code in many languages on many environments over the past 37 years.
But I've written Objective-C for 4 days, since getting myself a macbook last week. I found it's syntax compared to other languages to be quite non-intuitive and harder to pick up. So I'm no expert in Objective-C, but I've got lots of experience in picking up new languages. Objective-C seems to want lots of boilerplate. I appreciate it doesn't have some of the ludicrous complexity of C++, but the syntax is just ugly. I didn't like Smalltalk either for the same reason and they seem to share some idioms.
So today Apple dangled Swift in front of us and I thought it would be nicer to use that to develop applications in.
For general purpose programming, I usually use Python for it's cross platform goodness and it's nice language.
>are too caught up in tiny syntax shit Tiny syntax shit matters as much as macroscopic language semantics. Good languages get both right.
>Too bad they didn't just invest their energy into compiling Python to their runtime.
Agreed. But there is a performance trade off. They should have both. Python for a super good language and swift for a faster runtime. Objective-C is just horrible and needs to be put to sleep.
>A bigger news is Swift, a new, safe programming language with type inference.
I just took a quick look through the swift language manual on iBooks. I like it. It seems to lose some of the annoying features of objective-c and bring in some of the nice features of python.
E.G. for i in 0..3 { stuff }; or: for i in list_of_things { stuff }; like python. and tuples allowing multiple return values, like in python and it gets rid of the annoying square bracket method call syntax of objective C, replacing it with normal dot notation. classinstance.methodname() and passing functions as arguments like fancy languages and getting rid of the need for semicolons, like python and type inference from literals in variable declarations.
Not after the test probe explodes, scattering burning, toxic, radioactive, heavy metal detritus all over the the island burning the whole place to a barren toxic wasteland.
If your back end RADIUS server is running EAP and EAPoL on some unixy box, then Apple get no say in what version of OpenSSL may be used. The device is just the conduit. That's the point of RADIUS+EAP+EAPoL.
So get an unlocked phone and install CM. They're readily available. That's not an Android problem. That's a carrier problem. At least with Android you can do something about it.
They already thought of this. "Network access" and "internet access" aren't the same thing, and having access to "a network" doesn't imply access to the "the internet"
This level of dickishness presupposes that residents are residing there for the internet access. They are not. They want a roof over their head and access to basic services.
In doing this, the board is saying "Now we have to signed up and locked in for a year, we're going to use you as profit fodder at your own expense". That is not what they signed up for.
With FIPS140-2 4.9.2, SP800-90 10.3, Limiting the block size of AES to 128 bits, limiting the rounds of AES to 10, while misdirecting people to think key size was the important thing, along with effectively blocking progress on DNS security, IP security and other security tracks, the NSA has shown itself able to limit security and put backdoors out there which persist in the wild for many years before discovery.
We should not think they couldn't slip a back door into Truecrypt without being caught. It just requires some crypto knowledge they have which we don't and they employ more cryptographers than the private sector and universities do.
The recent string of results against DLP in prime power fields is an example of knowledge they may well have known before we did. what else is there that they are leaving the public at risk by keeping it a secret?
It's a bit odd. A good warrant canary involves inaction. So you don't need to do anything to trigger it. You do need to do something to keep it untriggered.
Having a warrant canary where you have to put signals in the open leaves you at risk when the canary is confirmed.
If you work in delivering real world crypto that it used by people, do arrange warrant canaries with your friends and base them on inaction.
I saw Prof, Franz give his talk last year and got a few minutes to pick his brain on this. The details were quite clear. Given the audience he wasn't holding back on details. The delivered software is unchanged. You can randomize at install time or (maybe) at load time. So your hashes are fine. You local file integrity is a local problem.
The shortcoming that I see is shared libraries. Shared libraries are evil from a security context and in the current invocation they don't get randomized (because they are shared). A good improvement would be to address shared libraries, which would necessarily require messing with the way shared libraries work. I'd be happy with eliminating shared libraries.
The difference with recompiling yourself is that you don't need the source code. You can randomize a binary and it will execute the same.
Slashdot Mirror
I didn't claim 4G/LTE. I claimed it worked fine. No worse than in the US which is supposed to offer 4G, but forgets to actually attach it to the internet by anything faster than a damp piece of string.
>Nexus 4 is great.
Except the battery thermal sensor dies in all of them in the end, causing the phone to randomly power off.
2 out of 2 Nexus 4s in my household went this way. The internet is full of people in the same boat.
My U.S. Nexus 5 worked fine in Europe on a local PAYG sim.
It's not only kilts and haggis up there.
They have cell phone shops too. She should buy herself a cell phone in Scotland.
Payment in Oxen used to be popular.
Don't buy your phone from your carrier. It's that simple.
Python is super handy if you need to solve problems with a quick program you only run a few times. The time spent writing it is longer than the time spent running it.
If you're writing code to be run billions of times, then using a compiled language that is slower to develop in would be a better choice.
Now you're just trolling.
Go build straw men somewhere else or read the postings you're responding to.
I've written code in many languages on many environments over the past 37 years.
But I've written Objective-C for 4 days, since getting myself a macbook last week. I found it's syntax compared to other languages to be quite non-intuitive and harder to pick up. So I'm no expert in Objective-C, but I've got lots of experience in picking up new languages. Objective-C seems to want lots of boilerplate. I appreciate it doesn't have some of the ludicrous complexity of C++, but the syntax is just ugly. I didn't like Smalltalk either for the same reason and they seem to share some idioms.
So today Apple dangled Swift in front of us and I thought it would be nicer to use that to develop applications in.
For general purpose programming, I usually use Python for it's cross platform goodness and it's nice language.
>are too caught up in tiny syntax shit
Tiny syntax shit matters as much as macroscopic language semantics. Good languages get both right.
>Too bad they didn't just invest their energy into compiling Python to their runtime.
Agreed. But there is a performance trade off.
They should have both. Python for a super good language and swift for a faster runtime.
Objective-C is just horrible and needs to be put to sleep.
>A bigger news is Swift, a new, safe programming language with type inference.
I just took a quick look through the swift language manual on iBooks.
I like it. It seems to lose some of the annoying features of objective-c and bring in some of the nice features of python.
E.G. for i in 0..3 { stuff }; or: for i in list_of_things { stuff }; like python.
and tuples allowing multiple return values, like in python
and it gets rid of the annoying square bracket method call syntax of objective C, replacing it with normal dot notation. classinstance.methodname()
and passing functions as arguments like fancy languages
and getting rid of the need for semicolons, like python
and type inference from literals in variable declarations.
Yes. Classic shell is better than the start menu that came with any version of windows.
If Microsoft reintroduce the start menu it's likely to mess with classic shell and make things worse.
>Kauai is very pretty,
Not after the test probe explodes, scattering burning, toxic, radioactive, heavy metal detritus all over the the island burning the whole place to a barren toxic wasteland.
If your back end RADIUS server is running EAP and EAPoL on some unixy box, then Apple get no say in what version of OpenSSL may be used. The device is just the conduit. That's the point of RADIUS+EAP+EAPoL.
So get an unlocked phone and install CM. They're readily available.
That's not an Android problem. That's a carrier problem. At least with Android you can do something about it.
>I'd say that instead of limiting access your company should create a portal marketplace that features additional presence
Are you saying Portal 3 is going to come out soon?
They already thought of this. "Network access" and "internet access" aren't the same thing, and having access to "a network" doesn't imply access to the "the internet"
This level of dickishness presupposes that residents are residing there for the internet access. They are not. They want a roof over their head and access to basic services.
In doing this, the board is saying "Now we have to signed up and locked in for a year, we're going to use you as profit fodder at your own expense". That is not what they signed up for.
With FIPS140-2 4.9.2, SP800-90 10.3, Limiting the block size of AES to 128 bits, limiting the rounds of AES to 10, while misdirecting people to think key size was the important thing, along with effectively blocking progress on DNS security, IP security and other security tracks, the NSA has shown itself able to limit security and put backdoors out there which persist in the wild for many years before discovery.
We should not think they couldn't slip a back door into Truecrypt without being caught. It just requires some crypto knowledge they have which we don't and they employ more cryptographers than the private sector and universities do.
The recent string of results against DLP in prime power fields is an example of knowledge they may well have known before we did. what else is there that they are leaving the public at risk by keeping it a secret?
It's a bit odd. A good warrant canary involves inaction. So you don't need to do anything to trigger it. You do need to do something to keep it untriggered.
Having a warrant canary where you have to put signals in the open leaves you at risk when the canary is confirmed.
If you work in delivering real world crypto that it used by people, do arrange warrant canaries with your friends and base them on inaction.
The signing keys you dolt.
His indentation is wrong. Whitespace matters.
What PERL looks like to Python programmers..
http://www.google.com/imgres?i...
Perl is monochrome.
Because lawyers were involved. That's how big corps work.
I saw Prof, Franz give his talk last year and got a few minutes to pick his brain on this. The details were quite clear. Given the audience he wasn't holding back on details. The delivered software is unchanged. You can randomize at install time or (maybe) at load time. So your hashes are fine. You local file integrity is a local problem.
The shortcoming that I see is shared libraries. Shared libraries are evil from a security context and in the current invocation they don't get randomized (because they are shared). A good improvement would be to address shared libraries, which would necessarily require messing with the way shared libraries work. I'd be happy with eliminating shared libraries.
The difference with recompiling yourself is that you don't need the source code. You can randomize a binary and it will execute the same.