or Connect
AppleInsider › Forums › Software › Mac OS X › Apple bug report hints developers may receive near-final build of OS X 10.9 at WWDC
New Posts  All Forums:Forum Nav:

Apple bug report hints developers may receive near-final build of OS X 10.9 at WWDC - Page 2

post #41 of 75
Quote:
Originally Posted by asdasd View Post


No large project builds the entire project for every coders change or submission. You would get to 451 in half a day if that were the case.

So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.

post #42 of 75
Quote:
Originally Posted by Applelunatic View Post

4 people work on OS X? Builds would have taken a 100 days (are they building OS X on Pentium 1 machines)? You're joking, right?

I am pointing out the absurdity in your argument about "knowing" how integrated builds work.

If there are 451 builds of OS X it took 451 days. Minimum.

Nothing bugs me more than sneering statements from people who have no clue.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #43 of 75
Quote:
Originally Posted by Applelunatic View Post

So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.

Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple have thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it. Also think about the waste of building every time the passbook guy fixes a comment.

It's every night. The question is why it's 451.

I mean they may have moved to two builds a day. Not every submission. That seems pointless though.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #44 of 75
Quote:
Originally Posted by asdasd View Post


I am pointing out the absurdity in your argument about "knowing" how integrated builds work.

If there are 451 builds of OS X it took 451 days. Minimum.

Nothing bugs me more than sneering statements from people who have no clue.

And I should believe what you say, why? Because you personally work for Apple on OS X?

post #45 of 75
Quote:
Originally Posted by asdasd View Post


Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple gave thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it.

Yes. They do. From Google's documentation about their version numbers:

 

  • BRANCH_BUILD will be updated every time a new build is started on a branch.  This happens whenever a commit is made to the branch.

 

Mozilla uses Tinderbox (feel free to look it up) which is used to continuously build and test after each change checked in. You can even view this here: https://tbpl.mozilla.org/

 

So either Firefox and Chrome are not "large projects" or you were speaking out of your ass. I'm going with the latter.

post #46 of 75
Quote:
Originally Posted by Applelunatic View Post

So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.

 

 

Crome and Firefox are applications, this is an operating system... a much, much larger project.

 

Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.

 

More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.

Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
post #47 of 75
Quote:
Originally Posted by mjtomlin View Post

 

 

Crome and Firefox are applications, this is an operating system... a much, much larger project.

 

Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.

 

More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.

It is true. See my post right above yours.

post #48 of 75
Quote:
Originally Posted by Applelunatic View Post

  • BRANCH_BUILD will be updated every time a new build is started on a branch.  This happens whenever a commit is made to the branch.

 

 

Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.

 

 

Quote:
Originally Posted by Applelunatic View Post

It is true. See my post right above yours.

 

 

It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.

Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
post #49 of 75
Quote:
Originally Posted by mjtomlin View Post

 

Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.

Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.

post #50 of 75
Quote:
Originally Posted by Pooch View Post

i heard a rumour that the name for this release is Fahrenheit. And that this is the final build.

Fahrenheit 451: The temperature at which an operating system gets so f@cking cool that it catches fire with the masses!

(I like what you did there 1wink.gif )
If you value privacy you can now set DuckDuckGo as your default search engine in iOS and OS X.
Reply
If you value privacy you can now set DuckDuckGo as your default search engine in iOS and OS X.
Reply
post #51 of 75

That build was almost a month ago.  Search for 13A451 in:

 

https://trac.webkit.org/export/151283/trunk/Source/WebKit2/ChangeLog

post #52 of 75
Quote:
Originally Posted by gcom006 View Post

Ocelot. I would be endlessly amused.

I've never seen an ocelot!

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #53 of 75
Quote:
Originally Posted by Applelunatic View Post

Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.

 

Never said it wasn't a current development branch. Yes I did look at the link. Nothing to do with semantics...

 

From Mozilla pages...

 

"mozilla-inbound is an integration branch that merges to and from mozilla-central about once a day. It's a place where changes can land and be tested without risk of breaking the main mozilla-central trunk."

 

So, as I stated, the main trunk is not compiled with every commit from every developer. And again, the revision number of OS X reflects a recompile of the main trunk, which probably also happens about once a day.


Edited by mjtomlin - 6/6/13 at 12:20pm
Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
post #54 of 75
Quote:
Originally Posted by anonymouse View Post

 

mdriftmeyer is almost certainly correct, and probably knows what he's talking about. As for Gruber, even if he's under NDA, he can most likely publish info he receives from sources other than official Apple channels.

 

Before moving into Professional Services at NeXT and later Apple my primary role in Software Quality Assurance was to manage, trouble ticket and escalate workarounds/code fixes to be staged in the build process by the build Engineers for Openstep/Openstep for Windows, EOF1.x/2.x, WOF 1.x-3.5., PDO, D'OLE. Myself and one other colleague who later joined the Interface Builder Team handpicked all third party devs under NDA who were given access from the earliest builds possible to let them beat on the products. Whether that be Merrill Lynch, ATT, CIA, Banc Suisse, you name it, we carried this process over to Apple.

Later I was focused on supporting the Enterprise NeXT legacy and then OS X transition. Select developers/developing houses are chosen for their high probability of adding value to the testing phases and finding showstoppers.

This is still true for all projects with strict NDA requirements. All the FOSS based projects that include LLVM/Clang/LLDB/Compiler-RT, WebKit, CUPS, and more have specific internal branches that roll out those changes after already being introduced into Apple specific projects ala XCode, OS X updates, etc.

post #55 of 75
Quote:
Originally Posted by asdasd View Post

That's a remarkable build number. It makes no sense to build twice a day or even most weekends.

This makes excellent sense. Build numbers may have started at 100 (triple digits). And check-ins are happening all the time, so multiple builds per day could be very helpful for developers wanting to test ASAP. Some build attempts may fail and have to be restarted, too, and still receive a unique build number of their own. I would hazard to guess virtually all Apple developers work nearly all weekends.

Just a few years ago, builds would take a day (if they succeeded), but the situation is likely much improved today.

post #56 of 75
Quote:
Originally Posted by mjtomlin View Post

 

Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.

 

 

 

It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.

 

Yes, we ran nightly builds of OS X with specific AppKit/Foundation Kit changes against other builds to ease targeted SQA testing and later merged changes back in to a main branch. Been that way since NeXTSTEP 1.0 to OS X present. Specific teams have custom builds made to test changes before they roll the update back into the mainline, etc., etc.

post #57 of 75
Quote:
Originally Posted by drblank View Post
MAPS was not a bug in the software, it was the data that was being displayed.  Apple can only do so much with third party data, especially when you are displaying the entire world.  Even Google has bugs in the data, even to this day.  Apple should have spent another 6 months to a year cleaning it up, but it's faster if they have customers submitting problems.

 

What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready.  The problem was that they real-world feedback from the users.  And time to work on that feedback.  Instead, they only had feedback from developers who happened to mostly share the same geographic areas.  I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.

post #58 of 75
While the build count really means nothing I'm surprised that so many people expect so little from 10.9. I actually see it having the potential to be a huge update. For example we could see support for heterogeneous computing in the memory manager, up to date OpenGL and OpenCL support, improved power management code to take advantage of Haswell, new networking code, general driver updates, UNIX subsystem improvements, maybe a fix to iCloud and a whole host of other improvements. I could go on for awhile but the idea is that there is huge potential for a major OS revision.


As a side note, for those of you that got the latest 10.8 update and iTunes update, have you noticed major improvements on low memory machines? Maybe it is me but my machine feels far less sluggish than it did befor the update running a bunch of programs all at once. Just a thought but maybe 10.9 will clean up a lot of memory management issues and other things leading to sluggish performance on old hardware.
post #59 of 75
You have no reason to say that at all. First; on modern hardware you can rebuild an entire OS rather quickly, they could hit the build button at lunch time for example. I wouldn't be the least bit surprised to find builds happening on a large cluster to cut build times even further. Beyond that if they are working on one component a rebuild might just be limited to code for what is being worked on.
Quote:
Originally Posted by asdasd View Post

I am pointing out the absurdity in your argument about "knowing" how integrated builds work.

If there are 451 builds of OS X it took 451 days. Minimum.

Nothing bugs me more than sneering statements from people who have no clue.

Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.
post #60 of 75
Quote:
Originally Posted by macslut View Post

 

What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready.  The problem was that they real-world feedback from the users.  And time to work on that feedback.  Instead, they only had feedback from developers who happened to mostly share the same geographic areas.  I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.

 

 

Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.

 

Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.

 

Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.

 

A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.

Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.
Reply
post #61 of 75
I live on the otherwise of the country and frankly maps has worked great every time I've used it. It often got skewered in the media due to data base errors that every GPS based mapping system has had or does have to this day. In the end much of the complaining about maps was either based own ignorance or a mischievous attempt to harm Apple. A rational look at Maps would have people seeing a well done version one app.
Quote:
Originally Posted by macslut View Post

What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready. 
Maps was ready from day one, it does precisely what a mapping program should do.
Quote:
The problem was that they real-world feedback from the users.  And time to work on that feedback. 
Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
Quote:
Instead, they only had feedback from developers who happened to mostly share the same geographic areas.  I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.

If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.

It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.
post #62 of 75
Quote:
Originally Posted by pedromartins View Post

This means nothing. Mountain Lion in 1000x better than Lion, but had fewer builds.

 

Another way to look at it: Bugs, bugs everywhere. Take your time Apple, make it as stable as possible.

They don't have nearly the amount of bugs as Windows.  Look up the various versions of OS X and the various versions of Windows on Wikipedia, they list the release date and the stable release date.  It's interesting to see how long it takes for Windows to become "stable".

post #63 of 75
Quote:
Originally Posted by Applelunatic View Post

It only makes no sense if you've never used continuous integration and automated unit/regression testing after each commit.  On the other hand, this is quite a common thing to use for software groups that work on complex pieces of software, such as an OS, do.

 

If they are incrementing that build number after every commit that strikes me as a fairly low number even if staging from a subsystem repo to master.  CI implies a lot of commits.  451 strikes me as a nightly build + extras when desired.

post #64 of 75
Quote:
Originally Posted by mjtomlin View Post

 

 

Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.

 

Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.

 

Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.

 

A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.

 

The issue with Maps wasn't the mere presence of errors.  There is likely not a database in the world without errors.  It was the number of errors or missing POIs coupled with the forced change from a database with far fewer errors or missing POIs.

post #65 of 75
Quote:
Originally Posted by Tallest Skil View Post

 

Ha! Nonsense. A final build given to devs? 

 

It's a joke.

post #66 of 75
Quote:
Originally Posted by wizard69 View Post

I live on the otherwise of the country and frankly maps has worked great every time I've used it. It often got skewered in the media due to data base errors that every GPS based mapping system has had or does have to this day. In the end much of the complaining about maps was either based own ignorance or a mischievous attempt to harm Apple. A rational look at Maps would have people seeing a well done version one app.
Maps was ready from day one, it does precisely what a mapping program should do.
Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.

It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.

 

I don't think anybody would argue that the application was a fine application from a UI perspective, but the purpose of a mapping application IS the database.  It was not unreasonable in the least to expect Apple to allow users to keep as default a mapping database with much more complete information.

post #67 of 75
Quote:
Originally Posted by wizard69 View Post

You have no reason to say that at all. First; on modern hardware you can rebuild an entire OS rather quickly, they could hit the build button at lunch time for example. I wouldn't be the least bit surprised to find builds happening on a large cluster to cut build times even further. Beyond that if they are working on one component a rebuild might just be limited to code for what is being worked on.
Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.

 

Sure.  You have a build farm that can build quickly and then regression test which usually takes longer.  With a large build farm you can generate a new build after every commit.  I just don't believe that 451 is the kind of build number you end up with in those scenarios.  For that you usually see something like date+build number.  In other words you end up with build 2013060645 (45th build on June 6, 2013).

 

For a nightly build I'd assume they'd run their regression tests on every supported architecture/configuration in their test farm.

 

451 builds for an OS release sounds pretty danged good even at once per day.

post #68 of 75
Quote:
Originally Posted by mjtomlin View Post

 

More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.

 

Thats what most CI shops do.  There's not much need to do it more than once a day unless there's some critical bug being stomped.

 

Many systems you check into a staging repo and the CI system builds, regression tests and then checks it into the trunk for you.  You never get to commit to the mainline manually.

post #69 of 75
Quote:
Originally Posted by asdasd View Post


Unless Apple run their large OS on shifts - which I doubt - they build overnight. 

 

which, if the number is correct, might mean that they have been working on this version for a while. before Lion launched. 

A non tech's thoughts on Apple stuff 

(She's family so I'm a little biased)

Reply

A non tech's thoughts on Apple stuff 

(She's family so I'm a little biased)

Reply
post #70 of 75
Quote:
Originally Posted by asdasd View Post


I am pointing out the absurdity in your argument about "knowing" how integrated builds work.

If there are 451 builds of OS X it took 451 days. Minimum.

Nothing bugs me more than sneering statements from people who have no clue.

 

 

One could also point out there is an absurdity in your argument about 'knowing' how Apple works. Yes it seems most logical for them to build overnight but perhaps they don't. perhaps they don't build every 24 hours but rather sometimes every 12 even every 2. and sometimes not for a whole week. 

 

unless you are an Apple engineer you don't know

A non tech's thoughts on Apple stuff 

(She's family so I'm a little biased)

Reply

A non tech's thoughts on Apple stuff 

(She's family so I'm a little biased)

Reply
post #71 of 75
Quote:
Originally Posted by drblank View Post

It's impossible to release a bug free OS of this level.  Because in order to actually test and OS, you have to put it on every computer/third party hardware and software and test it.  It's IMPOSSIBLE to do that.   But, releasing it to the developers ahead of time gives them the chance to update their software, test it as best as they can so the third party developers have their updates within a couple of months after the OS is released to the customer.    Haven't you noticed that Apple is having less updates per major release?  They just released 10.8.4. in about 9 months.  I'm sure when 10.9 comes out, they might have or need 10.8.5, but they also might not need to update it.  10.7 had 5 builds.  10.6 had 8 builds.  10.5 had 8 builds.  10.4 had 11 builds.  10.3 had 9 builds.  10.2 had 8 builds.  10.1 had 5 builds. 10.0 had 4 builds.

 

So, it looks like Apple is doing much better in getting to a bug free release. 

 

The numbers don't back up your hypothesis. If you ignore the fact that Snow Leopard, Lion and Mountain Lion have all had one or more OS release bearing the same number as the one that preceded it, the pace of OS releases today is the same as it was during the Tiger/Leopard years. If you count the supplemental releases, as I've done, the lifespan of a recent OS X version looks more like Jaguar/Panther.

 

Apple has done 72 OS X releases in a span of 4458 days. Each release has remained current for an average of 62 days. The variation by major version number can be seen in the table below.

 

10.0: 5 releases - 186 days     One per 37 days

10.1: 6 releases - 334 days     One per 56 days

10.2: 8 releases - 427 days     One per 53 days

10.3: 10 releases - 554 days   One per 53 days

10.4: 12 releases - 911 days   One per 76 days

10.5: 9 releases - 673 days     One per 75 days

10.6: 11 releases - 692 days   One per 63 days (I've counted 10.6.3 v1.1 and 10.6.8 v1.1 in the total)

10.7: 6 releases - 372 days     One per 53 days (I've counted 10.7.5 supplemental)

10.8: 5 releases - 317 days     One per 63 days (I've counted 10.8.2 supplemental)

 

Finally I would say that the pace of maintenance releases is most likely an indication of the amount of time Apple assigns to developing and testing a new version of the OS. The 62 day average is probably the combination of well planned 3 month schedules and 3 week emergency fixes.

post #72 of 75
Quote:
Originally Posted by ghostface147 View Post

That would be a rather short time to test. Even more so since they've pulled devs off of OS X to work on iOS 7.

Maybe the *reason* they pulled devs off OS X to help with iOS was that OS X was nearly finished anyway.

post #73 of 75
Quote:
Originally Posted by Applelunatic View Post

Apple builds its own machines, it does not build all the hardware within those machines. Ever seen the errata list for, say, an Intel CPU? They can sometimes be massive. Also, not all hardware bugs will plainly manifest themselves when doing development work and sometimes do not manifest until the software is in the wild and being used by regular users. So it's perfectly reasonable and easy to attribute certain issues in the OS with hardware bugs especially when they only manifest during weird edges cases (as many do).

I agree with what you said, but the poster I was replying to made it sound like Apple had to test their OS on the near infinite number of hardware combinations that windows or linux have to accomodate. While Apple does not control the construction of the internal components, its OS only has to work on its own pre-selected combinations of components (peripheral devices notwithstanding). So the scale of its third-party hardware problem is much smaller. 

post #74 of 75

All the speculation on how Apple does builds is meaningless... you do not know how they do it.

 

I work on large projects and we have builds set to go off automatically every 15 minutes 24/7 if anyone has committed a change to the code.  If a problem comes back from the build, testing, or whatever... it informs everyone including the people that checked in the code, and it needs to be fixed ASAP, no matter the time of day.

 

The more often you make builds and have them tested, the easier it is to narrow down on what may have caused a new problem.... when you have a huge server farm with plenty of power, its not that difficult to do, multiple builds of the same stuff going at the same time even.

 

We do NOT know how Apple does build numbers.  I've seen shops use multiple build number systems... where internal 50 builds in a day use a different number scheme, and 1 main build each day (or more often as needed) gets a "build number" that is shared more publicly, using a simpler numbering scheme.

 

This is all wild speculation on our parts on how Apple does it, and what numbers they start with.  Even if we are to guess correctly... its just build numbers, it tells us very little.  If they are daily builds and its number 451.... whats to say 20 of those builds had no changes at all...?

post #75 of 75
Quote:
Originally Posted by wakefinance View Post

I want 10.9 to be all optimization like Snow Leopard was. The only feature request I have is to let us customize our notifications. Basso does not please me. I also don't want birthdays from Facebook to pop up as notifications.

Quote:
Originally Posted by Ireland View Post

My kind of guy.

Same here. Especially when I'm submerged into Full Screen. I cannot believe they actually thought that was something people wouldn't want and had an option to turn off. So I turned off Notifications off altogether. Also on my iPad, as I have my iPhone with me all the time.
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
How to enter the Apple logo  on iOS:
/Settings/Keyboard/Shortcut and paste in  which you copied from an email draft or a note. Screendump
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Apple bug report hints developers may receive near-final build of OS X 10.9 at WWDC