There are also similar methods in the Android SDK:
link: http://developer.android.com/reference/android/util/Log.html..., java.lang.Throwable)
It stands for Web Template Framework, but it's funny it appears all the time in crash reports:
Thread 2 name: WebThread
Thread 2 Crashed:
4 WebCore 0x31bade0c WebCore::AtomicHTMLToken::initializeAttributes(WTF::Vector<WebCore::HTMLToken::Attribute, 10ul> const&) + 232
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.
DSMOS.kext has another function, however; it is involved in Apple's binary protection scheme 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.
There's just an outstanding myth that Macs still use TPM...
I remember some issues with the Apple II rom being copied and that they had to add a "Copyright Apple" or something similar to the binary data.
If anyone can confirm/deny this, please do.
You can't change a paid app to free on the Google Play store. All you can do is to pull it, and submit it again.
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.
Users who are artists must heed these wise words.
All Hail the Cult Leader.
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 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?
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.
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.
Note that I don't have any pirated software on my machine. Running Debian here.
There is a license "key", it's the whole computer.
Sometimes there is freedom in restriction.
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?
> Sometimes there is freedom in restriction.
Straight out of Orwell.
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.
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".
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.
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.
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.
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.
Maccard = a word for a mac-user person thingie. There's nothing derogative about that.
If people read it as you did though, that might explain the downvotes.
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.
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).
Returns 1 if the computer is on. If the computer isn't on, the value returned
by this function is undefined.
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):
" -[__NSCFCalendar components:fromDate:]: date cannot be nil
I mean really, what do you think that operation is supposed to mean with a nil date?
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):"
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 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.
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.
I've seen PurpleEventCallback show up in different stacks.
Although I suspect that'll be fixed post-beta
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.
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
My "upgrade" was NOT BETA.
> 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.
You said my 'phone is useless now' which is completely incorrect. I wouldn't expect it to have perfect battery life in a BETA...
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.
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.
Which is nothing to do with iOS7
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.
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.
That does deserve a bit of respect.
Carbon is now _15 years old_, you know...
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.
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.
Admittedly, all the other architectures Windows supported apart from x86 were added and later dropped again, so it were more sidesteps instead of transitions.
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.
Not really. Applications sometimes break from version to version, but usually due to use of undocumented behaviour etc; APIs are rarely deprecated.
> When Apple did the architecture shift from PowerPC it "was get over or get out".
PPC was supported for five years after the shift...
(some may not get the reference :P)