BeOS had is_computer_on() and is_computer_on_fire() APIs:
int32 is_computer_on(void)
Returns 1 if the computer is on. If the computer isn't on, the value returned
by this function is undefined.
double is_computer_on_fire(void)
Returns the temperature of the motherboard if the computer is currently on
fire. If the computer isn't on fire, the function returns some other value.
2012-08-31 00:26:19.773 App[1676:907] * -[__NSCFCalendar
components:fromDate:toDate:options:]: fromDate cannot be nil
I mean really, what do you think that operation is supposed to mean with a nil fromDate?
An exception has been avoided for now.
A few of these errors are going to be reported with this complaint,
then further violations will simply silently do whatever random thing
results from the nil.
Here is the backtrace where this occurred this time
(some frames may be missing due to compiler optimizations):
Without getting into the IT-sexism-blah-blah, 'your mother wears combat boots' isn't just a folksy turn of phrase: it's a fifties-era impugnment of lesbianism. So unless you want to sound a lot more Republican than you were probably intending, you should probably stop wondering why you don't have more female friends, coworkers, and partners. And by the way, a foot in the mouth is so gay.
Here's another easter egg - it's a sarcastic warning if you try to perform date operations on a nil date:
" -[__NSCFCalendar components:fromDate:]: date cannot be nil
I mean really, what do you think that operation is supposed to mean with a nil date?
An exception has been avoided for now.
A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil. Here is the backtrace where this occurred this time (some frames may be missing due to compiler optimizations):"
Apple ships iOS beta builds before announcing new hardware. They obviously don't want to leak information about new functionality like HDR support too early. So they use a special string "YoMamaWears..." meaning of which is known only to people in the appropriate team. Then, when iPhone 5s is finally released, they easily find-and-replace the obfuscated methods with proper identifiers.
It's funny because "Fig" was supposed to be replaced by CM or CoreMedia at some point but it was so integrated into the code that it never happened. So here we have a rare case of double export obsfucation.
It's a feature flag, but it's one that user's don't have easy access to. Pretty much every big software company does this, because it's a very effective way of testing new code. I know MS, Amazon, and Google all have tooling designed to facilitate just this sort of thing.
Let's say you've rewritten core parts of some system, but you've also added new features that didn't exist before. Often times such changes are inextricably bound together. On the one hand you may want some users to test out the new code to make sure it works correctly, but on the other hand the new features you've added may not be fully "baked" so you want to restrict their use. That's where secret feature flags come in.
I wonder whether Apple will decide to change their strategy of aggressively guarding upcoming products before they are launched, under Cook's leadership.
I was following a couple of 'rumor' blogs prior to the iPhone launches earlier this week and I believe they had managed to 'leak' and publish details on the iPhone 5C and 5S pretty spot on.
EDIT: rather than referring to the variable names in the OP, I'm referring to the more overarching strategy of guarding the features of their to-be-launched products.
I doubt it, that's more of a cultural thing instilled by Jobs, it's sort of entrenched as the "Apple way" of doing things. Big Cultural changes in an org typically come about when things are going badly.
The leaking is going to be hard to stop because Apple largely outsources its manufacturing and is now closely watched (compared to pre-ipod and iphone days). It's hard to enforce secrecy along the entire process when the process is run by third parties and spread around the world.
if you ever investigate the call stacks when there is a crash in their stuff from wrong parameters you can find all kinds of weird names. I'm still wondering what the purple coloured port is :)
There's been balmy little bits of stuff like this all the way through OSX and iOS for ages, though maybe not quite as flippant.
Every Mac has the kernel extension "Dont Steal Mac OS X.kext" for example, which loads into RAM a short poem.
There once was was a user that whined
his existing OS was so blind,
he'd do better to pirate
an OS that ran great
but found his hardware declined.
Please don't steal Mac OS!
Really, that's way uncool.
This used to be the case, but no longer is; Apple stopped using the TPM in Intel macs shortly after they launched[1] and have not brought it back since.
DSMOS.kext has another function, however; it is involved in Apple's binary protection scheme[2] for certain OSX binaries. Essentially, OSX ships with certain important binaries (such as loginwindow, SystemUIServer, Finder, and Dock) that have certain vm pages encrypted. Decrypting these pages for use requires DSMOS.kext.
Yea, they eschew the DRM-only TPM part to store the keys in the SMC, which does a whole host of things and doesn't protect the keys. I suppose you were sufficiently vague ;)
There's just an outstanding myth that Macs still use TPM...
The idea is that this poem is copyrighted as a creative work, and therefore Apple can control its distribution. The actual key contains a copyright message after the poem.
If I recall correctly, they added a watermark to the ROM. The concern was that as adversary could modify the code to make it difficult to prove that it was actually a copy. The watermark was a hidden section of the code which could be executed to demonstrate that the code did in fact originate from Apple.
I can definitely understand that, having pulled and Android app from the store because of piracy recently. (in app purchase is really hard to circumvent by pirates, but apps where you pay upfront are pirated like crazy)
I already had an IAP version in the store all the time and additionally the paid one (I honestly do not know why I thought that this was a good idea) - all I actually did was to pull to paid one.
It seems to have increased the sales for less than 10% in my case, but since I did this only a few days ago, I cannot say with confidence that it had anything to do with the switch.
But it did reduce confusion about the product itself and therefore support emails. (just the fact that there were 2 ways to get the full featured app was confusing to many - but this pro only exists because my own stupidity)
Long term I hope (it may never happen) that less people upload and therefore download pirated apks, because those versions are often very outdated, and some downloads out there are even broken because of that, causing additional support requests and bad reviews. (I rely heavily on Facebooks APIs, which change quite frequently)
If someone asked me if it was a good idea to pull an app that has been out there for a year or longer (with 100.000+ downloads) and resubmit it again I would definitely say no, because that also means that you basically start from zero again - from 1000+ downloads per day down to 10.
I don't know how the rankings in the Google Play store are created, but it seems to me that being around for a long time favors your ranking and downloads heavily.
As for this "poem", I've seen better from kids in elementary school. This speaks to the creative aptitude of Apple's kernel engineers. Certainly not the strongpoint of their workforce.
What sort of royalties or up-front payments did CMU get for letting Apple use their kernel?
It's actually very nifty - if you use a "secret"(obscure) key or checksum to check authenticity of hardware, then it still could be legally duplicated as nothing before DMCA was passed would prohibit that. If you use a scrappy poem as that key/token... then it's clearly copyrightable, and its duplication by some other manufacturer can be restricted with ages-old laws.
Do you have a citation for the cases where Apple has successfully argued used this in court against some other party who was pirating OSX?
It's only "nifty" until it's put to the test and fails in court. It's "effective" as a way to protect software only in the minds of some Apple engineers; but a judge might not see it that way. There's no precedent to assure anyone that it would work. If there were, I suspect we'd see it in widespread use. Or maybe Apple has tried to patent it?
Perhaps the DMCA exists because "nifty" gimmicks like this one cannot be relied on?
Every Maccard on the planet seems to think pirating OS X is an oh so terrible thing to do (to the point that parent post is bringing up poems about it like its a cute, non-weird thing). At the same time pirating everything else on the planet seemingly is OK.
I've never understood the rationale behind this.
Keep in mind I'm a software developer myself and run strictly non-pirated software, and open-source as much as possible. You could never make me replace a Linux desktop with a limited OS X experience, and I see no reason what so ever to put in the effort to pirate it.
But why is it worse to pirate a OS with bad hardware-support out of the box than pirating... say Microsoft Office? I'm just curious what's up with that.
>Every Maccard on the planet seems to think pirating OS X is an oh so terrible thing to do
First, who are those "Maccards" you are reffering to? Perhaps you meant to say "OS X user" or "persons who likes Apple stuff".
Second, a lot of us OS X user could not care less if you pirated OS X or not. Matter of fact, I know several people with genuine Macs that also run a Hackintosh (and I experimented with one a while ago).
>(to the point that parent post is bringing up poems about it like its a cute, non-weird thing).
The poem is placed by Apple developers, inside the OS X internels. IIRC, it's loaded in a .kext (a kernel extension). That's cute, especially it being a flippant poem and not some 20 page long legal text. In essense, it's a small easter egg.
It's not like random Apple users write poems about not pirating OS X, which seems to be your impression.
>At the same time pirating everything else on the planet seemingly is OK.
"Maccards think pirating OS X is very bad" (wrong)
"At the same time pirating everything else on the planet seemingly is OK" (wrong again).
Even if "Maccards" (sic) thought that pirating OS X is bad, who told you it's the same persons that think pirating everything else is OK?
>I've never understood the rationale behind this.
The problem might be that what you believe goes on is not happening in the first place.
With OS X there's no license key you need to enter, they have a poem instead asking you not to steal it. That's a nice thing, rather than assuming you're going to steal it they have a poem to jokingly ask you otherwise.
I don't get why people are still whining about this in 2013. Is it really that unreasonable for an OS manufacturer to restrict the devices on which it can be installed? I write firmware for a specific known hardware platform; do I really want the pain of people using it on an Arduino? The appeal of OSX is that it just works, and works beautifully most of the time. Opening it up to all the devices dilutes the main thing it has going for it.
> Is it really that unreasonable for an OS manufacturer to restrict the devices on which it can be installed?
Yes, it is. If I pay for a product, it's my prerogative to use it in any way I please. Copyright grants a monopoly on distribution, not on controlling post-purchase usage of the product.
It's one thing to say "we only officially support installation of this product on this list of devices, and can't guarantee it will work on other devices", but inserting artificial restrictions into the product that prevent people from even trying to do officially unsupported things with the product, at their own initiative and at their own risk, is something there really isn't any justification for.
> do I really want the pain of people using it on an Arduino?
What pain? How does it even concern you if people are installing your firmware onto an Arduino, provided that they have legitimate copies of it?
> Opening it up to all the devices dilutes the main thing it has going for it.
Obviously, not installing OSX on other devices is what dilutes the "main thing it has going for it" for those people who have chosen to install OSX on other devices. Are you seriously trying to tell people that their personal preferences are objectively wrong?
I don't get the whining either; I was just dispelling a myth.
That said, I don't find your arguments compelling; there's a difference between supporting and just not artificially preventing the software from running, and I don't see how doing the latter would make OSX stop "just working" on officially supported machines.
In fact, it's not like they don't anyway, and I don't see how have Hackintoshes diluted the experience of OSX on an Apple machine.
If Apple sold it as an operating system, they'd have to deal with a nightmare of drivers. As it stands one disk can cover almost every Mac ever made, and they're content with that.
Sure, but they wouldn't have to sell it as an operating system just to remove the artificial restrictions. They could still support only their machines, and just not encrypt the binaries and all that nonsense.
But I'm not saying they should, as I said, I don't really care. I'm just saying that just because they don't want to support other machines, that doesn't mean they have to purposely block them.
I mean, Asus doesn't support Linux on their motherboards either, but they don't have BIOS checks verifying that the OS is supported and refusing to boot if it isn't; they just tell you "you're on your own".
> they don't have BIOS checks verifying that the OS is supported and refusing to boot if it isn't
In fact the machines they're selling now almost certainly do have precisely this. It's called 'secure boot', and caused a lot of controversy. The major Linux distributions work because they've managed to get themselves signed with the appropriate key so the BIOS accepts them, but if you want to put a more niche distribution on there, you probably have to disable that check in the BIOS.
No, Secure Boot doesn't check if the OS is supported, it just checks if it's digitally signed, and that the signature is valid.
And you don't even have to disable the check if you want to use an unsigned distribution: most (all?) implementations allow the user to load her/his own public key to verify the signature against.
While we should worry about its impact - particularly in certain implementations - it's really not even close.
What are protected binaries? This is something I've not heard of OSX having.
As far as I know, as long as all the hardware is stuff OSX has drivers for (and you generate a DSDT to describe that hardware) then you don't need any special "authorization." You just put in the OSX installer USB/DVD and it works.
> A Mac OS X system which is missing this extension, or a system where the extension has determined it's not running on Apple hardware, will be missing this decryption capability, and as a result will not be able to run the Apple-restricted binaries Dock, Finder, loginwindow, SystemUIServer, mds, ATSServer, backupd, fontd, translate, or translated.
OSX does have 'protected binaries', which refers to binaries that use encrypted pages[1] that require decryption via an anti-piracy kernel extension (Don't Steal Mac OS.kext). This extension can check that you're running on Apple hardware by checking with the System Management Controller(SMC), which is Mac-specific[2].
In the old days (10.4), hackintosh systems would patch the protected binaries to remove the page encryption/decryption. Over time kernel extensions were developed to replace the functionality of Don't Steal Mac OS.kext (dsmos.kext or AppleDecrypt.kext) without the hardware checks.
The reason you no longer need either of these extensions is because a kernel extension called FakeSMC.kext was developed, which emulates as much of the functionality of the SMC as possible. This includes thermal and fan monitoring as well as the decryption key storage.
In a modern hackintosh setup, you make use of EFI emulation (inc. DSDT support) included in the bootloader (a boot-132 derivative, most likely Chameleon) and the pre-boot loading of emulator kernel extensions like FakeSMC.kext.
Certain apps, such as the Finder and the SystemUIServer, are encrypted and this kernel extension will only decrypt the executable pages if it considers your Mac to be genuine (consulting the TPM, I believe).
The TPM was used briefly at the beginning of the Intel mac days, but hasn't been used since. The decryption is now done through dsmos.kext in software.
And the attitude I've seen (especially in the OSX 86 community) is that general piracy is completely OK, but you have to buy OS X from Apple, otherwise you are doing something super-duper wrong. Then they move on to pirate Photoshop.
It's a mind-bending sort of ethics, and I was curious about what the reasoning behind it was.
I've never once come across this. I've come across Mac people that pirate stuff, and Mac people who don't and think that's wrong. That's fine, different people are entitled to their own opinions. But never once I have a come across anyone suggest that pirating other stuff is OK, but not Apple software.
That's not the mac using community as a whole then, is it. It's exactly the same a saying that all user of open source software are cheap because they don't want to pay for software. An entirely ridiculous statement that I'm sure you'll find abhorrent for many different reasons.
If so, Hackintoshes are, from Apple's point of view, piracy anyway. Apple makes no money on the OS (which they sell for a few dollars) and all their money from the hardware the Hackintosh user is avoiding buying. So whatever ethics are involved are already in a dubious state.
If you mean general Mac users, then, as I and others have said, there isn't a prevalent attitude of condoning piracy (everyone I know who uses Photoshop/Illustrator/InDesign has paid for it).
I wonder if they seriously discussed internally that gravity constants for other planets were needed in case Android devices would be used in space travel.
These are not the same, as these are left in production. The code names in the iOS binaries were later replaced by their real functionality as it no longer needed to be secret.
12 hours is a good battery life is it not? Admittedly, the iOS7 BETAs have cut my own down to the point where I have to make sure my phone is on 100% before a 4-5 hour night out so I know I'll have battery to use it by the end of the night.
My Nexus 4 lasts about 4 hours of usage, about 10 hours of standby time. I really wish it had a replaceable battery. Phones these days just don't last very long.
12 hours would be pretty bad for me. My 4S purchased on launch day (so nearly two years old now) gets unplugged at about 8AM, stays unplugged all day, and usually gets plugged in at 11PM with ~50% battery remaining.
I was just talking about BETAs in general. The one I have at the moment is a bit better but I tend to charge my phone at work so I don't usually notice
Fair enough, the early ones were awful for battery. B1 turned my iPhone 5 into a hand warmer and meant I couldn't be away from a plug for more than 4 hours.
It means you can trash your phone. It's worthless. The iTemple will welcome you for your next iPhone purchase - if you accept not to indulge in any iBlasphemy.
The 12 hours are in stand-by (no screen/wifi/bluetooth/phone usage/message usage whatsoever).
And I had 3-4 days before the "upgrade".
In my case I just "upgraded" the OS on my 3GS to the current state: v. 3.1.6 (after having refrained from doing so for a very very long time - precisely because I had read about the drastic battery drainage at the time). So no beta software was involved.
EDIT:
Here's an example of a thread in the "support" forum: https://discussions.apple.com/thread/4325659?start=15&tstart...
(I have tried every "solution" I could find on the net - nothing has fixed this. Which means we must assume this is strategy, not temporary bugs.)
It's called a BETA for a reason :-) The 3GS was released in 2009 which is quite a long time ago in technology terms so to expect it to be able to handle a more CPU-intensive update easily is a bit silly.
> The 3GS was released in 2009 which is quite a long time ago in technology terms so to expect it to be able to handle a more CPU-intensive update easily is a bit silly.
It worked perfectly BEFORE the "upgrade" (batter life: 3-4 days!), why would it not AFTER the "upgrade"? I mean, the "upgrade" was SPECIFICALLY coded for the 3GS. If it's "bricked" after the "upgrade", that says it all.
You have to be a sheep if you accept Apple "bricking" your device just like that.
EDIT: Ok, seems like I have enraged the iGods with some critical thinking.
No offence, but what does that have to do with iOS7's battery life? It seems you just wanted to start screaming about how everyone that buys Apple is a 'sheep' and use some terrible puns. You do tend to get downvoted if you don't contribute anything to the conversation.
You said my 'phone is useless now' which is completely incorrect. I wouldn't expect it to have perfect battery life in a BETA...
> what does that have to do with iOS7's battery life?
It has to do with Apple's apparent general battery strategy. The devaluing of devices sold as "upgrade" was done a few years back, and as I've mentioned above, it's still done today.
> You do tend to get downvoted if you don't contribute anything to the conversation.
The contribution here is: DO NOT "UPGRADE", UNLESS you are ok with being forced to buy a new phone BEFORE your "old" phone ceases to fulfill your actual/real needs! I hope this is now clear enough.
If this warning is NOT valuable, then I'm clearly on the wrong site here.
> You said my 'phone is useless now' which is completely incorrect.
Of course it is useless as a mobile phone. It's supposed to be a mobile phone (for travel etc.). So, if I have to keep it plugged in just to do calls, WiFi and bluetooth, then it's called a landline phone and I have to buy a new mobile phone.
> I wouldn't expect it to have perfect battery life in a BETA...
Why do you keep talking about "beta". As I've said in the downvoted posts already (twice): It was a NORMAL UPGRADE downloaded because iTunes kept bugging me with it. NO BETA HERE.
I've said it once and I'll say it again: This has nothing to do with the original topic. I posted about iOS7s battery life in the BETA and you started getting agitated about an iPhone 3gs upgrade (not iOS7...)
The phone is 4 years old. That's quite a long lifespan for a phone and if you're angry because the battery life has depleted, you obviously don't have an idea about how batteries work. Of course a new update is going to have an impact on the battery. Since it requires more CPU/Memory (which the iPhone 3gs is severely lacking in) the battery takes a hit.
>Why do you keep talking about "beta". As I've said in the downvoted posts already (twice): It was a NORMAL UPGRADE downloaded because iTunes kept bugging me with it. NO BETA HERE.
Then why are you talking about it? We are talking about the iOS7 BETA. Not iOS3.
>Of course it is useless as a mobile phone. It's supposed to be a mobile phone (for travel etc.). So, if I have to keep it plugged in just to do calls, WiFi and bluetooth, then it's called a landline phone and I have to buy a new mobile phone.
You said my phone. Not yours. My phone acts perfectly as a mobile device :)
>The contribution here is: DO NOT "UPGRADE", UNLESS you are ok with being forced to buy a new phone BEFORE your "old" phone ceases to fulfill your actual/real needs! I hope this is now clear enough.
Don't upgrade if you don't want to. Nobody is forcing you to buddy. I wouldn't expect an old computer to handle all the new games perfectly at full resolution
>It has to do with Apple's apparent general battery strategy. The devaluing of devices sold as "upgrade" was done a few years back, and as I've mentioned above, it's still done today.
Blame it on the "iGods" if you want, but your ridiculous all-caps whinging is what earned this a down-vote from me.
Did your device get bricked? That sucks, it's never fun. Did you take it in to get it unbricked? Everyone I know that's had hardware trouble like that has had their phone either fixed or, surprisingly, replaced. If the OS is designed to run on your phone and it doesn't, that's a defect, and you're entitled to a fix.
Why? Sometimes functionality has to be exposed, even when a company would prefer an alternative. Microsoft has named functions similarly on occasion [1].
Reading posts like this, you really can't deny that Microsoft is sometimes seriously underappreciated for their technical efforts at keeping everything running as smoothly as they can:
Things got even worse in Windows 95, when all our window procedures were converted to 32-bit versions. The problem is that the old window procedures were only 16-bit. So we couldn't even simply export the 32-bit window procedure under the name BOZOSLIVEHERE. We had to write a conversion function that took an illegal 16-bit function call and converted it to the corresponding illegal 32-bit function call.
Apple just says "that's obsolete in a year" and lets everything break (or have it removed from its marked).
Granted, you can clearly see what approach gives you the best long-term agility, but still: there are few companies which has historically supported applications and ensuring compatibility like Microsoft did.
As far as I've understood it, iOS apps are under constant pressure to remain compatible with the latest APIs. When Apple did the architecture shift from PowerPC it "was get over or get out".
That sort of attitude is very different from the one highlighted in the linked MSDN blog where they are building compatibility bridges for illegal, abandoned APIs which were never meant to be public in the first place, to ensure that the application people care about keep working.
Ofcourse, in a pre-internet time, where applications couldn't deliver timely updates, and definitely not automatically nor over-the-wire (since there was no wire), this was a much more pressing concern than now, but that still doesn't detract from the fact that Microsoft deserves some credit for their efforts.
Apple switched to Intel processors in 2006, but maintained support for running PowerPC apps on Intel processors up until OS X Lion shipped, in 2011. Apple kept compatibility with a completely different processor architecture for half a decade. When I got my first Intel Mac, I just copied over all my PowerPC binaries, and they ran fine. It was unbelievable.
And this wasn't even the first time. Recall the 68k emulator that shipped in all classic PowerPC Macs.
Both Microsoft and Apple deserve enormous credit for their compatibility work. But Apple deserves special mention for shepherding the Mac through three completely different architectures (68k->PPC->x86) while maintaining excellent compatibility at each transition. Windows has also gone through significant transitions, but within the same x86 processor family.
Remember Windows NT which ran on PowerPC, MIPS and Alpha. They even ran x86 binaries on Alpha which were not only emulated but also translated for later runs [1].
Admittedly, all the other architectures Windows supported apart from x86 were added and later dropped again, so it were more sidesteps instead of transitions.
iOS apps are encouraged to use the latest APIs to keep things moving forward so the hardware is used to it's fullest.
When Apple did the architecture shift from PowerPC to Intel they provided the Rosetta bridge that allowed PowerPC code to be ran under Intel architectures. They introduced that in 2005 and removed in in 2011. Developers had a pretty long time to get over it.
I've got an app on my iPhone 4S w/iOS 6 that hasn't been updated since late 2008 (pre-iOS 3.0). It hasn't even been in the app store for years. Still works fine. Hopefully it'll work on iOS 7, too, but I haven't tried it.
