Of course you can define the methods in-line in this fashion although you are now mixing interface and implementation which is not the best thing to do unless you have a really good reason for doing so. Then again if you use templates you (mostly) have to do this anyways.
Where possible, I always keep my interface separate from implementation. Yes, it's a bit more verbose but unless you really need something inlined you are almost always better off keeping them separate.
Anyways, my real point is that Objective-C is not really more verbose than other major languages. I'm sure there are cases where some concept or another is shorter/easier in one language than the others but overall they all get the job done.
That's really what is happening behind the scenes in C++, it is generating two entirely different methods at compile time, nothing is done at run time. They just appear to have the same name to the programmer. The same sort of thing occurs with templates. You can do it in Objective-C too:
In fact, in Objective-C you can even do it at run time.
Sure, the C++ compiler is doing some of the work for you. Personally, I'd rather just do it by hand and be sure that everything is implemented as I intended. There are quite a few gotchas with C++ overloading and templates that can bite you in the butt when you least expect it.
As far as operator overloading goes, it's a hugely controversial subject and most people agree that although it can be convenient it also can cause a huge mess. Does that overloaded operator+ mean you should add the values or append them? Is an entirely new object returned or do one or more of the involved objets get changed? If we are talking about complicated objects should operator+ merge them or sum up all their elements? You are usually better off defining regular methods such as add and merge which a programmer needs to explicitly read and understand than overloading operators.
Thanks for the tips, because win32 APIs feel like a real paradise now.
Dig into the underlying implementation of a language and it's bound to get a little complicated. Stuff like objc_msgSend is not meant to be used often, it's there to enable you to do odd things that the simple and easy to use APIs don't allow. You use it carefully and build a decent set of methods around that, then use those instead of calling objc_msgSend a ton.
There's quite a bit of crusty win32 API running around that is way more complex than the internals of Cocoa.
If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs).
Of course it's all Unix so you could just use stat instead and get everything as more direct types.
The KVC and KVO components are there as a convenience for generic programming, such as UI programing, not as a replacement for more direct methods.
I also ported my string library (the Cocoa NSString is about the worst string library you will ever encounter), linked lists, hash tables, small blocks sub-allocator... and avoid NSStrings, NSDictionary, NSArray... for anything other than Cocoa APIs requiring them.
How so? What, specifically, didn't you like about these Cocoa frameworks?
I will admit that they are quite different philosophically than what you might find in the C++ STL or Java libraries but once you grok the thinking behind them they are quite useful. Perhaps you just needed some further understanding of how they work and how to best use them before you implemented your own solutions?
Objective-c message passing is quite fast, only 4x the cost of a virtual table call in C++
Not to mention you could use a method implementation pointer (another good site) to skip all of the behind-the-scenes dynamic dispatch and then you are right around the speed of a normal C function call. Objective-C lets you have the ease of message passing when you want it and the speed of C function calls when you need it.
For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing.
Looks pretty simple to me:
@interface Employee : NSObject {
@private
int securityLevel; }
Counting just the relevant lines, that takes care of the variable declaration, its properties, and its getter and setter in 3 lines (approximately 82 characters).
Here's the equivalent in C++:
class Employee {
public:
void setSecurityLevel (int newLevel);
int getSecurityLevel ();
private:
int securityLevel; }
int Employee::getSecurityLevel (){
return securityLevel; }
That's a grand total of 9 relevant lines (approximately 217 characters).
Java:
class Employee{
private int securityLevel;
public int getSecurityLevel(){
return securityLevel;
}
public void setSecurityLevel(int newLevel){
securityLevel = newLevel;
} }
7 relevant ines (approximately 153 characters).
So, in this circumstance Objective-C is about 1/3 of the characters or lines than the equivalent C++ code and about 1/2 of the characters or lines than the equivalent Java code. Objective-C is hardly a complicated or verbose language. I'm sure you could dig around and find languages that could do the equivalent in less code but this is by no means unreasonable.
I spoke to a customer today who wanted to know if we carried Bloomerang Lilacs. I have heard about them (they are an ever blooming hybridized lilac) from others but hadn't read much about them until today. These plants are certainly being modified in ways that make them very different than what nature intended.
Don't anthropomorphize Nature, she hates when you do that.
Hybridization occurs all the time in nature. It's a completely natural process that bees and other creatures long ago developed means to deal with. There certainly is a chance that some odd combination of plants can result in something damaging to bees but it's extremely unlikely to happen and it certainly wouldn't have a widespread, worldwide effect on bee population.
We should definitely research all angles of this problem but, in the end, it may just come down to natural variation in the bee population or due to a number of small, natural effects. One thing we should do is develop other pollinators so that we aren't relying on a bee monoculture. There are many other types of bees and other critters that can supplement the pollination role of the honeybee.
The level of security on an iPhone that has the enterprise deployment features enabled is much higher than the security on a non-enterprise iPhone. I'd be interested to see if this trick works on an enterprise iPhone or if it only works on a non-enterprise one. I'm betting that page you linked is completely accurate when we are talking about enterprise deployment
Protecting data stored on iPhone is important for any environment with a high level of sensitive corporate or customer information. In addition to encrypting data in trans-mission, iPhone 3GS provides hardware encryption for data stored on the device.
Encryption:
iPhone 3GS offers hardware-based encryption. iPhone 3GS hardware encryption uses AES 256 bit encoding to protect all data on the device. Encryption is always enabled, and cannot be disabled by users.
You'll see that this specifically refers to iPhones set up using the Enterprise Deployment features. A non-enterprise user does not have these protections enabled by default. If you want these protections you need to see this PDF: iPhone OS Enterprise Deployment Guide
I read through both linked articles and it comes down to only this data is exposed:
This data protection flaw exposes music, photos, videos, podcasts, voice recordings, Google safe browsing database, game contents
Certainly not all of the data on the phone. Your e-mails, notes, application-specific data, address book, password keychain, and so on are still safely encrypted. Yes, this isn't a perfect situation but it's not as dire as it sounds. Most data that people expect to be secure is still secure.
The linked article (from the Free Software Foundation itself) specifically says the violation is a GPL v2 section 6 violation. Maybe they made a mistake but I'm just going on their information. Yeah, if it is GPL v3 you are required to open up a lot more stuff like the signing keys.
Anyways, it's all kinda moot. The Apple Developer Agreement specifically says that an author isn't supposed to submit anything that violates the GPL or any other license. The simple solution is to remove the app and be done with it.
Apple would just have to remove the clause that says if you create an app with their SDK you can't distribute that same version elsewhere
I don't see this clause anywhere in the developer agreement. It does say that you can't redistribute the SDK and that you can't distribute the application once you have contracted with Apple to distribute the application but nothing is ever said of the source code itself. It seems to me that you could freely distribute the source code under the developer agreement, you just couldn't distribute the binaries other than on Apple's App store.
I believe the problem with section 6 of the GPL v2 is that once you get the app you should be able to copy, distribute, or modify it. This is prohibited under the App store, each download is code signed to only work for one account. Thus it is a prohibition on the user, not the developer.
So, you keep going around with your bs studies and your links just make sure you keep that McAfee updated... Oh, my bad. Too soon?
Ahh, you assume. I never touch any of that anti-malware stuff, I have no need for it. It's a worse virus than the actual ones. As for crowing about flaws, I couldn't care less. All software has flaws, open or closed. You take sane steps to protect yourself and prepare for when that's not enough.
I use both open and closed software when they suit my needs. There are advantages and disadvantages to both sides. I'm not for or against any of them. I dunno why you have a chip on your shoulder but it's causing you to make bad assumptions and clouding your vision. And remember, all those ad hominems that you pile on your arguments don't mean squat. They only serve to weaken your position.
No, I didn't read the article you linked to. I'm already well versed on what the bystander effect is so I don't have a particular need for an about.com re-hash of the wikipedia article on it.
I linked to other articles in my original post, one of which had numbers showing that open source, even core stuff that SOMEONE should have hardened, was just as vulnerable and in some cases more, some cases less) as closed source. You obviously didn't read it, even though you posted a reply to it.
As for Linux users, a number of serious vulnerabilities were reported in 2006, most of them related directly to the Linux kernel. Some of these allow DoS attacks against a vulnerable system, while the others allow elevation of privileges.
Obviously the Linux kernel is an open source effort that a LOT of eyeballs stare at and it still has vulnerabilities. I'm not saying that Linux is bad, just that open source is not immune to security problems by the very virtue of being open.
Eh, never mind my explanation here. Parts of it are correct but some of it is muddled and misleading. I blame it on the head cold I'm suffering through today! I should know better than to have a nasty headache and stuffed-up head and trying to explain quantum theory...
Is an ultraviolet catastrophe a math term, or a physics one?
It's a physics term, but math and physics are pretty intertwined at that point.
The basic idea is that random populations of things tend to follow a normal distribution, or bell curve. If you have a bunch of molecules bouncing about then some will be moving fast, some slow, but most will be at a moderate speed. All things being equal the percentage of slow vs fast should be roughly similar, producing a graph that looks like a bell - round peak in the middle, the sides falling off and leveling out.
According to classical physics a "black body" (an ideal object at a certain temperature) should emit some photons of higher energy, and some photons of lower energy, with most photons of a moderate energy. The graph of these should follow a bell curve, if everything else was equal. At lower temperatures the curve was approximately a bell curve, centered around the infrared wavelengths. However, as the temperature is raised there is a shortfall of higher energy photons. The graph starts to develop a "lean", it looks like it has a fat tail on the lower energy photon side and a long, thin tail on the higher energy photon side. Because many of those high energy photons are in the ultraviolet range it was called the "ultraviolet catastrophe" - it was a highly unexpected result which turned the physics community on its head.
Ultimately quantum theory explained the reason for this. Quantum energy levels for the electrons in atoms results in the lower energy transitions being more likely than higher energy transitions, thus tending to produce a higher amount lower energy photons and a lower amount of higher energy photons than classical physics predicted.
Again, if the software is important enough, somebody has. If you have proof otherwise, I'd like to see it, else it's just my opinion versus yours.
Which, of course, is why I linked an article with some hard numbers. Did you read it? Now, even numbers can be haggled over but it at least lends credence to my argument: open source is not intrinsically secure. Sure, it CAN be secured if you spend your time going through the source or paying someone to do so but you can't just assume "it's important so someone must have secured it". Everyone before you might have said something similar so it's turtles all the way down, there's a good chance that no one did a proper job at security.
Closed source might not be any better but if you are buying from a company that has a reputation and a monetary stake in the matter then you at least have some leverage and some recourse if something goes wrong. You don't have that kind of hold on open source developers. Again, I'm not saying that one is automatically better or worse than the other, just that there are security issues with both kinds of software and no amount of "someone will take care of that" can get rid of those concerns.
Your summation doesn't make sense. We have 1/0.01 = 100 = 10000%, so the total energy is 10000% of what it started as?
I did make a bit of a mistake in writing it down. The actual equation should be:
0.01 x 0.99^0 + 0.01 x 0.99^1 + 0.01 x 0.99^2 +...
which simplifies to:
0.01 x (0.99^0 + 0.99^1 + 0.99^2 +...)
or:
0.01 x 1/(1 - 0.99) = 0.01 x 100 = 1 = 100%
At every step you have so much energy left, this is the 0.99 term. Since you have 99% energy left of the previous step's energy after every iteration you end up with the geometric series. You have to take the energy of each step and multiply it by 1% to get how much matter is left at every step, that is the 0.01 term that you see in the equation. I mistakenly left out out and just assumed it was there.
You can see this is correct by doing the math manually (or through a spreadsheet):
step 1: 100% energy x 1% matter = 1% total matter step 2: 99% energy x 1% matter + step 1 = 1.99% total matter step 3: 98.01% energy x 1% matter + step 2 = 2.9701% total matter step 4: 97.0299% energy x 1% matter + step 3 = 3.940399% total matter
Compute that to a couple of hundred steps and you see that the curve appears to approach an asymptote of 100%, just as the math predicts.
It doesn't matter if I do it; if it's an important enough piece of software, somebody has. And if it's really important, more than a few somebodies. And if it's really really important, I can pay somebody to do it.
I'd like to introduce you to an important, relevant psychological effect known as the bystander effect. The more important that something public is, the GREATER the chance that no one will take care of it because they all just assume "It's so important that someone must have taken care of it."
I'm not saying that open source is insecure, just that you can't automatically assume that it IS secure. Unless you personally look at the code or pay someone trusted to do so, you have to assume that it isn't secure.
The "noob" here is the person that blindly trusts other people to make sure everything is secure.
So presumably 99% of the mass-energy in the universe is currently energy, much of which must be potential and kinetic energy.
Not necessarily, it depends on how many iterations of annihilation-recombination took place.
For example, say we have 100% matter and antimatter, it interacts and annihilates leaving 1% matter. The remaining energy recombines back into matter and antimatter (through processes like vacuum fluctuation and virtual particles), now 99% of that annihilates, leaving lasts iteration's 1% plus this iteration's 99% x 1% = 0.99% for a total of 1.99%. Next will be 98.01% x 1% = 0.9801%, and so on.
Thus the formula is: 0.99^0+0.99^1+0.99^2+...
This is a geometric series and since r is 0.99 the limit is 1/(1-r) or 1/0.01 = 100%
So, theoretically, 100% of the energy could end up as matter. Of course in the real world not all of the energy combines into matter-antimatter pairs and not all of the matter and antimatter annihilate each other. This means that we end up with a universe where a good chunk of the original energy is matter, a tiny bit is antimatter, and the rest of it is energy of some sort. It's almost definitely not 99% energy, and it's almost definitely not 100% matter.
It comes down to if you cannot see the source don't trust it.
And when is the last time you looked at every single line of code for a major open-source application and made sure that it was totally and completely safe? Do you just use them, assuming that someone elsedid it for you?
The fact is that we all trust the developers at some point, it doesn't matter if it is open or closed source. At least with a major author they have a physical presence, buildings, investors, publicly traded, cash in the bank. If they do something underhanded you have stuff you can go after. In open source yeah you have code that people can look at but you also have the possibility of some anonymous person who works a sneaky backdoor into the code. Then when it all goes kablooey there's no one whose feet can be held to the fire.
I'm not saying that either closed or open source is better than the other, just that both have many good and bad points. You can't automatically assume that open source is better. Either way it helps to have safeguards in place, like an app review process and the ability to quickly remove malware from devices.
Yeah, there has been some poaching of the bit of info that apps can tap into. I know Apple tightened up on that though and there's a lot less that an app can get at.
There's no doubt that the App Store gatekeepers are a necessary evil. Hopefully they do just enough and not a bit more in keeping bad apps out and still allowing good apps in.
I poked around the internets a bit and only found a mention or two for iPhone trojans. These trojans were ONLY on jailbroken iPhones, not un-jailbroken ones that are using the iPhone App Store. As far as I know there have never been any "banker" trojans in the iPhone App Store.
This article seems to be riding the coattails of the iPhone's popularity by throwing it in the mix with other platforms that have had "banker" trojans. If they have evidence of an iPhone App Store trojan I'd love for them to directly mention it rather than being vague and doing a lot of hand-waving.
Slashdot Mirror
Of course you can define the methods in-line in this fashion although you are now mixing interface and implementation which is not the best thing to do unless you have a really good reason for doing so. Then again if you use templates you (mostly) have to do this anyways.
Where possible, I always keep my interface separate from implementation. Yes, it's a bit more verbose but unless you really need something inlined you are almost always better off keeping them separate.
Anyways, my real point is that Objective-C is not really more verbose than other major languages. I'm sure there are cases where some concept or another is shorter/easier in one language than the others but overall they all get the job done.
How can you implement overloading when the compiler can never truely know what type of object is being passed?
For that matter, what's the real difference between:
and
That's really what is happening behind the scenes in C++, it is generating two entirely different methods at compile time, nothing is done at run time. They just appear to have the same name to the programmer. The same sort of thing occurs with templates. You can do it in Objective-C too:
In fact, in Objective-C you can even do it at run time.
Sure, the C++ compiler is doing some of the work for you. Personally, I'd rather just do it by hand and be sure that everything is implemented as I intended. There are quite a few gotchas with C++ overloading and templates that can bite you in the butt when you least expect it.
As far as operator overloading goes, it's a hugely controversial subject and most people agree that although it can be convenient it also can cause a huge mess. Does that overloaded operator+ mean you should add the values or append them? Is an entirely new object returned or do one or more of the involved objets get changed? If we are talking about complicated objects should operator+ merge them or sum up all their elements? You are usually better off defining regular methods such as add and merge which a programmer needs to explicitly read and understand than overloading operators.
Thanks for the tips, because win32 APIs feel like a real paradise now.
Dig into the underlying implementation of a language and it's bound to get a little complicated. Stuff like objc_msgSend is not meant to be used often, it's there to enable you to do odd things that the simple and easy to use APIs don't allow. You use it carefully and build a decent set of methods around that, then use those instead of calling objc_msgSend a ton.
There's quite a bit of crusty win32 API running around that is way more complex than the internals of Cocoa.
If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs).
Of course it's all Unix so you could just use stat instead and get everything as more direct types.
The KVC and KVO components are there as a convenience for generic programming, such as UI programing, not as a replacement for more direct methods.
I also ported my string library (the Cocoa NSString is about the worst string library you will ever encounter), linked lists, hash tables, small blocks sub-allocator... and avoid NSStrings, NSDictionary, NSArray... for anything other than Cocoa APIs requiring them.
How so? What, specifically, didn't you like about these Cocoa frameworks?
I will admit that they are quite different philosophically than what you might find in the C++ STL or Java libraries but once you grok the thinking behind them they are quite useful. Perhaps you just needed some further understanding of how they work and how to best use them before you implemented your own solutions?
If the libraries you need to use are interfaced through Obj-C, like OSX's GUI APIs, can you use pure C code to call those APIs?
Sure thing, using objc_msgSend and similar functions found in the Objective-C Runtime Reference.
Objective-c message passing is quite fast, only 4x the cost of a virtual table call in C++
Not to mention you could use a method implementation pointer (another good site) to skip all of the behind-the-scenes dynamic dispatch and then you are right around the speed of a normal C function call. Objective-C lets you have the ease of message passing when you want it and the speed of C function calls when you need it.
For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing.
Looks pretty simple to me:
Counting just the relevant lines, that takes care of the variable declaration, its properties, and its getter and setter in 3 lines (approximately 82 characters).
Here's the equivalent in C++:
That's a grand total of 9 relevant lines (approximately 217 characters).
Java:
7 relevant ines (approximately 153 characters).
So, in this circumstance Objective-C is about 1/3 of the characters or lines than the equivalent C++ code and about 1/2 of the characters or lines than the equivalent Java code. Objective-C is hardly a complicated or verbose language. I'm sure you could dig around and find languages that could do the equivalent in less code but this is by no means unreasonable.
I spoke to a customer today who wanted to know if we carried Bloomerang Lilacs. I have heard about them (they are an ever blooming hybridized lilac) from others but hadn't read much about them until today. These plants are certainly being modified in ways that make them very different than what nature intended.
Don't anthropomorphize Nature, she hates when you do that.
Hybridization occurs all the time in nature. It's a completely natural process that bees and other creatures long ago developed means to deal with. There certainly is a chance that some odd combination of plants can result in something damaging to bees but it's extremely unlikely to happen and it certainly wouldn't have a widespread, worldwide effect on bee population.
We should definitely research all angles of this problem but, in the end, it may just come down to natural variation in the bee population or due to a number of small, natural effects. One thing we should do is develop other pollinators so that we aren't relying on a bee monoculture. There are many other types of bees and other critters that can supplement the pollination role of the honeybee.
But that's exactly how Apple is advertising the 3GS: http://www.apple.com/iphone/business/integration/#securing
The level of security on an iPhone that has the enterprise deployment features enabled is much higher than the security on a non-enterprise iPhone. I'd be interested to see if this trick works on an enterprise iPhone or if it only works on a non-enterprise one. I'm betting that page you linked is completely accurate when we are talking about enterprise deployment
Data Protection:
Protecting data stored on iPhone is important for any environment with a high level of sensitive corporate or customer information. In addition to encrypting data in trans-mission, iPhone 3GS provides hardware encryption for data stored on the device.
Encryption:
iPhone 3GS offers hardware-based encryption. iPhone 3GS hardware encryption uses AES 256 bit encoding to protect all data on the device. Encryption is always enabled, and cannot be disabled by users.
Actually if you go directly to Apple's PDF that the quote came from:
iPhone in Business Security Overview
You'll see that this specifically refers to iPhones set up using the Enterprise Deployment features. A non-enterprise user does not have these protections enabled by default. If you want these protections you need to see this PDF:
iPhone OS Enterprise Deployment Guide
I read through both linked articles and it comes down to only this data is exposed:
This data protection flaw exposes music, photos, videos, podcasts, voice recordings, Google safe browsing database, game contents
Certainly not all of the data on the phone. Your e-mails, notes, application-specific data, address book, password keychain, and so on are still safely encrypted. Yes, this isn't a perfect situation but it's not as dire as it sounds. Most data that people expect to be secure is still secure.
The linked article (from the Free Software Foundation itself) specifically says the violation is a GPL v2 section 6 violation. Maybe they made a mistake but I'm just going on their information. Yeah, if it is GPL v3 you are required to open up a lot more stuff like the signing keys.
Anyways, it's all kinda moot. The Apple Developer Agreement specifically says that an author isn't supposed to submit anything that violates the GPL or any other license. The simple solution is to remove the app and be done with it.
Apple would just have to remove the clause that says if you create an app with their SDK you can't distribute that same version elsewhere
I don't see this clause anywhere in the developer agreement. It does say that you can't redistribute the SDK and that you can't distribute the application once you have contracted with Apple to distribute the application but nothing is ever said of the source code itself. It seems to me that you could freely distribute the source code under the developer agreement, you just couldn't distribute the binaries other than on Apple's App store.
I believe the problem with section 6 of the GPL v2 is that once you get the app you should be able to copy, distribute, or modify it. This is prohibited under the App store, each download is code signed to only work for one account. Thus it is a prohibition on the user, not the developer.
So, you keep going around with your bs studies and your links just make sure you keep that McAfee updated... Oh, my bad. Too soon?
Ahh, you assume. I never touch any of that anti-malware stuff, I have no need for it. It's a worse virus than the actual ones. As for crowing about flaws, I couldn't care less. All software has flaws, open or closed. You take sane steps to protect yourself and prepare for when that's not enough.
I use both open and closed software when they suit my needs. There are advantages and disadvantages to both sides. I'm not for or against any of them. I dunno why you have a chip on your shoulder but it's causing you to make bad assumptions and clouding your vision. And remember, all those ad hominems that you pile on your arguments don't mean squat. They only serve to weaken your position.
No, I didn't read the article you linked to. I'm already well versed on what the bystander effect is so I don't have a particular need for an about.com re-hash of the wikipedia article on it.
I linked to other articles in my original post, one of which had numbers showing that open source, even core stuff that SOMEONE should have hardened, was just as vulnerable and in some cases more, some cases less) as closed source. You obviously didn't read it, even though you posted a reply to it.
There are other articles to be found, such as this Kaspersky Security Bulletin which had this to say:
As for Linux users, a number of serious vulnerabilities were reported in 2006, most of them related directly to the Linux kernel. Some of these allow DoS attacks against a vulnerable system, while the others allow elevation of privileges.
Obviously the Linux kernel is an open source effort that a LOT of eyeballs stare at and it still has vulnerabilities. I'm not saying that Linux is bad, just that open source is not immune to security problems by the very virtue of being open.
Eh, never mind my explanation here. Parts of it are correct but some of it is muddled and misleading. I blame it on the head cold I'm suffering through today! I should know better than to have a nasty headache and stuffed-up head and trying to explain quantum theory...
Is an ultraviolet catastrophe a math term, or a physics one?
It's a physics term, but math and physics are pretty intertwined at that point.
The basic idea is that random populations of things tend to follow a normal distribution, or bell curve. If you have a bunch of molecules bouncing about then some will be moving fast, some slow, but most will be at a moderate speed. All things being equal the percentage of slow vs fast should be roughly similar, producing a graph that looks like a bell - round peak in the middle, the sides falling off and leveling out.
According to classical physics a "black body" (an ideal object at a certain temperature) should emit some photons of higher energy, and some photons of lower energy, with most photons of a moderate energy. The graph of these should follow a bell curve, if everything else was equal. At lower temperatures the curve was approximately a bell curve, centered around the infrared wavelengths. However, as the temperature is raised there is a shortfall of higher energy photons. The graph starts to develop a "lean", it looks like it has a fat tail on the lower energy photon side and a long, thin tail on the higher energy photon side. Because many of those high energy photons are in the ultraviolet range it was called the "ultraviolet catastrophe" - it was a highly unexpected result which turned the physics community on its head.
Ultimately quantum theory explained the reason for this. Quantum energy levels for the electrons in atoms results in the lower energy transitions being more likely than higher energy transitions, thus tending to produce a higher amount lower energy photons and a lower amount of higher energy photons than classical physics predicted.
Again, if the software is important enough, somebody has. If you have proof otherwise, I'd like to see it, else it's just my opinion versus yours.
Which, of course, is why I linked an article with some hard numbers. Did you read it? Now, even numbers can be haggled over but it at least lends credence to my argument: open source is not intrinsically secure. Sure, it CAN be secured if you spend your time going through the source or paying someone to do so but you can't just assume "it's important so someone must have secured it". Everyone before you might have said something similar so it's turtles all the way down, there's a good chance that no one did a proper job at security.
Closed source might not be any better but if you are buying from a company that has a reputation and a monetary stake in the matter then you at least have some leverage and some recourse if something goes wrong. You don't have that kind of hold on open source developers. Again, I'm not saying that one is automatically better or worse than the other, just that there are security issues with both kinds of software and no amount of "someone will take care of that" can get rid of those concerns.
Your summation doesn't make sense. We have 1/0.01 = 100 = 10000%, so the total energy is 10000% of what it started as?
I did make a bit of a mistake in writing it down. The actual equation should be:
0.01 x 0.99^0 + 0.01 x 0.99^1 + 0.01 x 0.99^2 + ...
which simplifies to:
0.01 x (0.99^0 + 0.99^1 + 0.99^2 + ...)
or:
0.01 x 1/(1 - 0.99) = 0.01 x 100 = 1 = 100%
At every step you have so much energy left, this is the 0.99 term. Since you have 99% energy left of the previous step's energy after every iteration you end up with the geometric series. You have to take the energy of each step and multiply it by 1% to get how much matter is left at every step, that is the 0.01 term that you see in the equation. I mistakenly left out out and just assumed it was there.
You can see this is correct by doing the math manually (or through a spreadsheet):
step 1: 100% energy x 1% matter = 1% total matter
step 2: 99% energy x 1% matter + step 1 = 1.99% total matter
step 3: 98.01% energy x 1% matter + step 2 = 2.9701% total matter
step 4: 97.0299% energy x 1% matter + step 3 = 3.940399% total matter
Compute that to a couple of hundred steps and you see that the curve appears to approach an asymptote of 100%, just as the math predicts.
It doesn't matter if I do it; if it's an important enough piece of software, somebody has. And if it's really important, more than a few somebodies. And if it's really really important, I can pay somebody to do it.
I'd like to introduce you to an important, relevant psychological effect known as the bystander effect. The more important that something public is, the GREATER the chance that no one will take care of it because they all just assume "It's so important that someone must have taken care of it."
I'm not saying that open source is insecure, just that you can't automatically assume that it IS secure. Unless you personally look at the code or pay someone trusted to do so, you have to assume that it isn't secure.
The "noob" here is the person that blindly trusts other people to make sure everything is secure.
So presumably 99% of the mass-energy in the universe is currently energy, much of which must be potential and kinetic energy.
Not necessarily, it depends on how many iterations of annihilation-recombination took place.
For example, say we have 100% matter and antimatter, it interacts and annihilates leaving 1% matter. The remaining energy recombines back into matter and antimatter (through processes like vacuum fluctuation and virtual particles), now 99% of that annihilates, leaving lasts iteration's 1% plus this iteration's 99% x 1% = 0.99% for a total of 1.99%. Next will be 98.01% x 1% = 0.9801%, and so on.
Thus the formula is:
0.99^0+0.99^1+0.99^2+...
This is a geometric series and since r is 0.99 the limit is 1/(1-r) or 1/0.01 = 100%
So, theoretically, 100% of the energy could end up as matter. Of course in the real world not all of the energy combines into matter-antimatter pairs and not all of the matter and antimatter annihilate each other. This means that we end up with a universe where a good chunk of the original energy is matter, a tiny bit is antimatter, and the rest of it is energy of some sort. It's almost definitely not 99% energy, and it's almost definitely not 100% matter.
It comes down to if you cannot see the source don't trust it.
And when is the last time you looked at every single line of code for a major open-source application and made sure that it was totally and completely safe? Do you just use them, assuming that someone else did it for you?
The fact is that we all trust the developers at some point, it doesn't matter if it is open or closed source. At least with a major author they have a physical presence, buildings, investors, publicly traded, cash in the bank. If they do something underhanded you have stuff you can go after. In open source yeah you have code that people can look at but you also have the possibility of some anonymous person who works a sneaky backdoor into the code. Then when it all goes kablooey there's no one whose feet can be held to the fire.
I'm not saying that either closed or open source is better than the other, just that both have many good and bad points. You can't automatically assume that open source is better. Either way it helps to have safeguards in place, like an app review process and the ability to quickly remove malware from devices.
Yeah, there has been some poaching of the bit of info that apps can tap into. I know Apple tightened up on that though and there's a lot less that an app can get at.
There's no doubt that the App Store gatekeepers are a necessary evil. Hopefully they do just enough and not a bit more in keeping bad apps out and still allowing good apps in.
From the article:
Banker Trojans targeting platforms such as the iPhone
[citation needed]
I poked around the internets a bit and only found a mention or two for iPhone trojans. These trojans were ONLY on jailbroken iPhones, not un-jailbroken ones that are using the iPhone App Store. As far as I know there have never been any "banker" trojans in the iPhone App Store.
This article seems to be riding the coattails of the iPhone's popularity by throwing it in the mix with other platforms that have had "banker" trojans. If they have evidence of an iPhone App Store trojan I'd love for them to directly mention it rather than being vague and doing a lot of hand-waving.