I wish I could convince the phone manufacturers that I don't need the facebook app. I don't have a facebook account and have no use for the app, yet my phone will not let me uninstall it. In fact my phone keeps telling me that I need to update this large app that I never use.
Assuming your phone is on 4.0 or above (which it likely is; less than 8% of devices are on older versions), you can go into Settings -> Apps -> Facebook and disable the app. That will prevent the update requests. It won't actually remove the app because it's installed on a read-only file system, but it will get it out of your face.
Be nice if I could uninstall some of that crap. I just bought a Samsung and a Motorola mobile phone. Can't believe how little extra stuff is installed on the Motorola - it's wonderful. But both of them have a lot of Google apps I just don't want. Love Gmail and calendar, but news? books? Do not want. It would be wonderful if Google would let us remove these apps via the Play store. If they could do something about all the extra Samsung junk that would be great too.
Others have pointed out that you can uninstall by rooting. I just want to provide some technical background.
Android device storage is partitioned into multiple file systems. Exactly how many file systems and what they are, what they're called and for what purposes they're used varies a bit, but fundamentally there are one or more read-only partitions which I'll call/system and one read-write partition which I'll call/data.
/system contains all of the system binaries and libraries. It's mounted read-only as a security precaution and so that factory reset of the device will actually restore the device to its original condition. It's only modified during system updates (unless you root the device and modify it yourself).
/data contains all user data, including all of the apps you install. As I said above, it's the only partition on the device that is mounted read/write. Factory resetting the device simply wipes/data.
So, any apps that are supposed to be present on a factory-default configured device have to be installed on the read-only/system partition. Putting them on/data would mean they disappear during factory reset, unless there were also copies stored elsewhere which could be reinstalled, but that would just double the space they consume. And since they're on a read-only partition they can't be removed, and even if they were deleted from the read-only partition you wouldn't actually gain use of the space unless you re-partitioned the device and reallocated the freed space to/data.
Google has done a couple of things to try to address this issue.
In Ice Cream Sandwich, Google added the "disable" feature (and added a compliance requirement that disallowed OEMs and carriers from disabling the disable feature) which allows you to disable pre-installed apps. They're still present on/system, but aren't allowed to run on the device, so you can functionally get rid of them but not free up the space (which would require re-partitioning).
In Lollipop, Google introduced the notion of "virtual pre-installs". A virtually-preinstalled app isn't installed in/system, but instead placed on/data at the factory. The user can then delete it, and it will be gone and the space it consumed will be available for use. When the user factory-resets the device it will be gone... but the first time the device is connected to Wifi, all virtually-preinstalled apps will be downloaded and installed, getting it back to that "fresh-from-the-factory" state. And the user can then delete them.
The virtual pre-installation feature is particularly attractive to carriers, because Google also allows virtual pre-installs to be specified by the carrier. So if Verizon (for example) decides that they want to virtually pre-install the Verizon app then when a user with a generic phone inserts a Verizon SIM into it, the Verizon app will get installed -- to/data where the user can delete it.
But virtual pre-installation only enables user deletion of OEM/carrier bloatware if the OEM/carrier decides to use it rather than "real" pre-installation. I don't know how many OEMs and carriers have opted to use it, but my impression is that not many have.
Nonsense. The Elastic Clause, is by its very nature, elastic. Its whole purpose was to ensure that Congress wasn't excessively restricted. I might agree that the courts have stretched it a bit further than they should, but claiming that they've inverted its meaning or ignored it is ridiculous.
As a former LDS missionary, I'd have no problem with that question. I'd probably just quote the text of the hymn, "O My Father". Why, what answers did you get?
Also, poking around your web site, I notice that you claim you couldn't buy into Mormon beliefs because you can't imagine a father damning his children to eternal torment... which is odd because Mormons do not believe God does that, which is a rather major difference between LDS theology and that of mainstream Christianity. I've also never seen any LDS congregation who would throw anyone out, unless they were being actively disruptive.
I know a couple of people who were involved in the development of OnHub and, FWIW, they say that the motivation was that there's a need for a Wifi router that performs better and is more secure. Not a strategic bet, just a perceived market opportunity which they thought Google was well-equipped to fill.
With regard to performance, the antenna design of the OnHub is supposed to be dramatically better than anything else on the market, and the device incorporates ideas from the Software Defined Networking stacks Google developed internally for its data centers, to optimize data flow. I wouldn't have thought there was much you could do to make Wifi work better, since the ISP connection is generally the bottleneck, but apparently there is. With respect to security, it adopts a number of ideas from ChromeOS, plus fully-automated updates. Probably the biggest security benefit compared to the competition is that security is actually a primary design goal, which isn't the impression I get from makers of home routers.
We'll see if OnHub actually is enough better than the competition to justify its premium price. Based on what I know of the people working on it I expect that it will. I ordered one.
If Interstate Commerce was redefined, it was done a long time ago, during the New Deal. And then there's Lopez v Gonzalez. But that's not a redefinition of the sort FranTaylor was claiming, just a stretching.
With respect to the ACA, I'm not sure what you're talking about, though. SCOTUS ruled that the ACA could not be justified under the Commerce Clause. They upheld it as a legitimate exercise of Congress' power to tax.
the supreme court could rule tomorrow that "well regulated" means "with mustard and mayonaisse"
Bah. Can you cite a single example of the Supreme Court doing anything remotely like redefining common words to mean something completely different from what they mean? Note that the GP's claim about the Court's definition of "well-regulated" is false. The Court said no such thing (there is historical justification for a similar argument, but the Court didn't go there).
Their primary rationale was that the words "the people" must be given the same meaning they're given in the other amendments of the Bill of Rights, notably the first and fourth. Just as we have an individual right to freedom of speech, freedom of religion and protection from unwarranted search and seizure we have an individual right to keep and bear arms. The Court ruled that the militia clause was merely motivational and prefatory and that while it might have given the framers' primary motivation for the second amendment, it does not restrict the operative clause.
You may wish they'd found differently, but their decision was clearly not capricious, as you're trying to imply.
But even there-- how much regulation is "well regulated" without shading into the "abridging" region?
"Well regulated" means "trained" or "skilled" in that context at that time. The SCOTUS has already ruled on that.
I don't think that's correct. It's been a few years since I read the DC v Heller opinions, but I don't recall any of them going into the meaning of well-regulated.
What they did hold, though, was that the militia clause was prefatory only, merely announcing a purpose, and did not restrict or limit the meaning of the operative clause. In addition, the court found that when the second amendment says "the people", it means the same thing as when the first and fourth amendments say "the people", and therefore the same people who are guaranteed freedom of speech and freedom from unwarranted search and seizure are guaranteed the right to keep and bear arms, meaning it's an individual right.
As an aside, the definitional arguments I've read claim that "well-regulated" referred more to "well-equipped". The term allegedly derives from British practices of verifying the proper equipping and manning of regiments, which weren't managed by the Crown but by wealthy individuals (generally nobles). The Crown paid the regimental commanders for maintaining their regiments, though, and required them to present their regiments for inspection to prove that they were "well-regulated", meaning they had the requisite number of soldiers and all were equipped and uniformed per the regulation standard. Thus, the phrase "well-regulated" really referred to complying with Crown regulations for a regiment, and using it to mean "well-equipped" in general terms was an abuse of the term, since there were no relevant regulations, but it was a common abuse in the period.
But SCOTUS didn't delve into the details of word usage, they just dismissed the militia clause as prefatory and not impacting the meaning of the operative clause, which provides for an individual right.
I was on LinkedIn for a while, and it was worthless, IMO. I only got two kinds of contacts: From people who wanted me to follow their vanity blog, and from employment agents who seemed unable to read the parts of my CV
I think LinkedIn is useful as a self-maintaining Rolodex, not as a social network. It's not about who contacts you, it's about having a way to contact the guy you worked with last year fifteen years from now when you're looking for a job.
That said, my current job came about from a recruiter searching LinkedIn.
It's a bit OT but this effectively dispels the myth that hiring is a meritocracy. It's often more about who you know, and who you are known to.
What you say is true in some cases, but the fact that knowing people makes it easier to get a job in no way implies that hiring isn't a meritocracy. There's another obvious explanation for this phenomenon: Merit is all but impossible to accurately evaluate in an interview.
If I care only about the ability to do the job, nothing else, and I'm faced with two candidates, one of whom I worked with for a year doing a similar job and one I know only through an interview, I'm not going to be comparing them when making my hiring decision. Instead, I'll make two separate decisions: First, is the person I worked with able to do the job? I know the answer to this question with a high degree of accuracy, because I saw his or her work over an extended period of time. If the answer is yes I'll extend an offer without giving the other candidate any serious consideration.
If the candidate I know can't do the job, then I'll consider the other candidate, but only then.
My current employer has a hiring process that attempts to even this out and remove personal relationships from the hiring decision, but the effect remains. Individuals don't make hiring decisions, committees do, and as I understand it anyone on the committee who knows the candidate personally is supposed to recuse themselves. However, the process does accept and even solicit feedback from individuals who know the candidate personally, and the committee places great weight on the content of that feedback (which must be detailed and specific, and I'm sure is evaluated in the context of the employee's own work), because it's hugely more reliable than feedback from interviewers who talked to the candidate for an hour. Even with this process in place it's easier to get hired if you are respected by some current employee. Not because "it's about who you are known to" but because of the quality of the information available to the hiring process.
That is just crazy. These are not high-risk/return investments funds. Just load up on a diversified bluechip portfolio, and make sure you follow all the other sheep so that you can't be singled out for getting something wrong.
Will that strategy net you a 20% return on your investment? Because that's what Yale's fund managers achieved.
Also 6% seems a very high price to manage money. Where they getting a return on investment of 12%?
They didn't get 12% ROI, they got more than 20%. And it was that success that got them their big payday.
According to the article, the fee for the investment managers is 2% plus 20% of the growth. The 2% amounted to $137M and 20% of the growth was $343M, which means that the managers' efforts increased the size of the endowment by $1.7B. That's phenomenal. The bankers made a lot of money, yes. Too much? I don't know; I'd be happy to let them manage my investments under those terms with those sorts of returns. As for the university, they were able to spend $1B of their endowment while increasing its size by over $200M, net.
That's exactly what an endowment should be doing: Generating a health return and spending most of it, but retaining a modest increase to keep up with inflation.
"Though GC actually does eliminate dangling pointer bugs... by turning them into memory leaks."
Give us an example of a dangling pointer being turned into a leak in Java. In other words show me a pointer that points to deallocated memory and some memory that's allocated but cannot be pointed to any more (because I don't know where it is).
A dangling pointer in a non-GC'd language is one which the programmer thinks will no longer be used and therefore deallocates, but which actually does get referenced later. Boom.
In a GC'd language, the same scenario results in the object not being deallocated, so it's still around when it gets referenced later. No boom, which is good. However, this is arguably a form of memory leak because the programmer believes it should have been deallocated, and is assuming that the memory is available for other uses.
I believe that is already fixed, and that the fix will be released in the next update of the Play services app. However, I work on the core Android OS not on Play Services, so I don't follow that stuff closely.
Tell that to console applications. I want to send PgDn to the program or server, not scroll the window.
That's an issue with the terminal emulator, not the keyboard. You'd have the same problem if you did have PgUp and PgDn buttons. Your issue is how the key is interpreted, not how to type it.
Torvalds is a Swedish speaking Finn. That's why he says "planning 10 years ahead is not sane". The Swedish word is "klok" which can be translated as "sane" or, more reasonably.... "sensible."
Linus Torvalds has pretty thoroughly mastered English. I'm sure he said "sane" and meant "sane", with full appreciation of the meaning and overtones of the word and of the alternatives he could have chosen.
I bought an Android One phone to get regular updates. It took more than 6 months for Google to roll it out to my device. I was expecting an update within 2 weeks of the announcement at Google I/O.
(I'm an Android engineer.)
The announcement at Google I/O isn't the release. As of today, Android M still has not been released. i think the third and final(?) preview went out early this week, but it's still a preview, not a release.
This is a pretty common misunderstanding of the Android release process. The announcement of a new version and its features comes when the feature set is demonstrably finalized, long before it's actually done and debugged. That means that our code is "feature complete", meaning we can demonstrate all of the features, but in many cases there are still a lot of bugs to fix. In some cases the bugs are of the form "three of the four use cases for this feature aren't implemented yet." (I actually did that this year; I'm responsible for the hardware-backed crypto and when preview1 went out I had completely broken asymmetric crypto. Hardware-backed AES and HMAC worked, but RSA and EC did not. And that was just the big stuff; there were lots of minor features that were broken, too. It's all working now.)
The reason for announcing features and publishing APIs well before the actual release is to give all of the partners and app developers plenty of time to start getting ready for the release.
Unless you're a glutton for punishment, you really don't want the version released at I/O. I know... I've been running M on my Nexus 6 since about February and it has been rather bad at times. Bad, as in the phone app crashing continually, or Google Play Services not running (which takes out pretty much all of the Google apps, plus some), etc. At a couple of points I almost had to abandon Marshmallow and go back to Lollipop because my phone didn't work. It's getting close these days, but it's still not done. I haven't personally run into any problems for a while.
If you really *do* want Marshmallow now, you can always unlock your device and install the third preview. I don't recommend it, but I don't recommend against it, either. Like I said, it's actually working pretty well on my device. But don't be shocked if you find stuff that doesn't work. That's why it's a preview.
So Google broke their promise big time.
Nope, you just misunderstood the promise:-)
The promise is within two weeks of release, not two weeks of first public alpha. And you are happy about that, really you are.
No, no, no, no, no! The concept of garbage collecting is a reaction to poor coding practices and reliance on it is laziness. Software engineers responsible for real-time, public safety software should be capable of managing memory in their code!
Garbage collection is a red herring. The notion that "real" software engineers must use manual deallocation is just as silly as the idea that garbage collection eliminates memory leaks. Though GC actually does eliminate dangling pointer bugs... by turning them into memory leaks.
Garbage collection is a viable and reasonable strategy for handling deallocation -- in fact it can be significantly more efficient than manual deallocation, in terms of cycles spent on deallocation -- but it's not a panacea. It doesn't eliminate the need to think about object lifetimes or memory consumption. It reduces the amount of development effort focused on those issues, trading it instead for management of GC times. Whether that tradeoff is a net benefit depends on the context and system requirements.
And that is what real software engineers do. They don't choose their tools based on which is the manliest and best for proving their coding prowess. They choose based on the nature of the problem and the resources available. Where GC interruptions can be tolerated, or safely scheduled, GC is a tool that automates away significant engineering effort. That's a good thing. Hard real-time systems generally don't tolerate GC very well, but virtually anything that interacts with people does tolerate brief (50 ms or less) GC pauses, and that's actually quite easy to achieve.
Slashdot Mirror
I wish I could convince the phone manufacturers that I don't need the facebook app. I don't have a facebook account and have no use for the app, yet my phone will not let me uninstall it. In fact my phone keeps telling me that I need to update this large app that I never use.
Assuming your phone is on 4.0 or above (which it likely is; less than 8% of devices are on older versions), you can go into Settings -> Apps -> Facebook and disable the app. That will prevent the update requests. It won't actually remove the app because it's installed on a read-only file system, but it will get it out of your face.
Be nice if I could uninstall some of that crap. I just bought a Samsung and a Motorola mobile phone. Can't believe how little extra stuff is installed on the Motorola - it's wonderful. But both of them have a lot of Google apps I just don't want. Love Gmail and calendar, but news? books? Do not want. It would be wonderful if Google would let us remove these apps via the Play store. If they could do something about all the extra Samsung junk that would be great too.
Others have pointed out that you can uninstall by rooting. I just want to provide some technical background.
Android device storage is partitioned into multiple file systems. Exactly how many file systems and what they are, what they're called and for what purposes they're used varies a bit, but fundamentally there are one or more read-only partitions which I'll call /system and one read-write partition which I'll call /data.
/system contains all of the system binaries and libraries. It's mounted read-only as a security precaution and so that factory reset of the device will actually restore the device to its original condition. It's only modified during system updates (unless you root the device and modify it yourself).
/data contains all user data, including all of the apps you install. As I said above, it's the only partition on the device that is mounted read/write. Factory resetting the device simply wipes /data.
So, any apps that are supposed to be present on a factory-default configured device have to be installed on the read-only /system partition. Putting them on /data would mean they disappear during factory reset, unless there were also copies stored elsewhere which could be reinstalled, but that would just double the space they consume. And since they're on a read-only partition they can't be removed, and even if they were deleted from the read-only partition you wouldn't actually gain use of the space unless you re-partitioned the device and reallocated the freed space to /data.
Google has done a couple of things to try to address this issue.
In Ice Cream Sandwich, Google added the "disable" feature (and added a compliance requirement that disallowed OEMs and carriers from disabling the disable feature) which allows you to disable pre-installed apps. They're still present on /system, but aren't allowed to run on the device, so you can functionally get rid of them but not free up the space (which would require re-partitioning).
In Lollipop, Google introduced the notion of "virtual pre-installs". A virtually-preinstalled app isn't installed in /system, but instead placed on /data at the factory. The user can then delete it, and it will be gone and the space it consumed will be available for use. When the user factory-resets the device it will be gone... but the first time the device is connected to Wifi, all virtually-preinstalled apps will be downloaded and installed, getting it back to that "fresh-from-the-factory" state. And the user can then delete them.
The virtual pre-installation feature is particularly attractive to carriers, because Google also allows virtual pre-installs to be specified by the carrier. So if Verizon (for example) decides that they want to virtually pre-install the Verizon app then when a user with a generic phone inserts a Verizon SIM into it, the Verizon app will get installed -- to /data where the user can delete it.
But virtual pre-installation only enables user deletion of OEM/carrier bloatware if the OEM/carrier decides to use it rather than "real" pre-installation. I don't know how many OEMs and carriers have opted to use it, but my impression is that not many have.
Nonsense. The Elastic Clause, is by its very nature, elastic. Its whole purpose was to ensure that Congress wasn't excessively restricted. I might agree that the courts have stretched it a bit further than they should, but claiming that they've inverted its meaning or ignored it is ridiculous.
As a former LDS missionary, I'd have no problem with that question. I'd probably just quote the text of the hymn, "O My Father". Why, what answers did you get?
Here is a decent summary of LDS belief about our Heavenly Mother: http://eom.byu.edu/index.php/M...
Also, poking around your web site, I notice that you claim you couldn't buy into Mormon beliefs because you can't imagine a father damning his children to eternal torment... which is odd because Mormons do not believe God does that, which is a rather major difference between LDS theology and that of mainstream Christianity. I've also never seen any LDS congregation who would throw anyone out, unless they were being actively disruptive.
Something doesn't add up here.
I know a couple of people who were involved in the development of OnHub and, FWIW, they say that the motivation was that there's a need for a Wifi router that performs better and is more secure. Not a strategic bet, just a perceived market opportunity which they thought Google was well-equipped to fill.
With regard to performance, the antenna design of the OnHub is supposed to be dramatically better than anything else on the market, and the device incorporates ideas from the Software Defined Networking stacks Google developed internally for its data centers, to optimize data flow. I wouldn't have thought there was much you could do to make Wifi work better, since the ISP connection is generally the bottleneck, but apparently there is. With respect to security, it adopts a number of ideas from ChromeOS, plus fully-automated updates. Probably the biggest security benefit compared to the competition is that security is actually a primary design goal, which isn't the impression I get from makers of home routers.
We'll see if OnHub actually is enough better than the competition to justify its premium price. Based on what I know of the people working on it I expect that it will. I ordered one.
You didn't read my post, apparently.
Not black, female, or poor?
Until the 13th and 14th amendments.
If Interstate Commerce was redefined, it was done a long time ago, during the New Deal. And then there's Lopez v Gonzalez. But that's not a redefinition of the sort FranTaylor was claiming, just a stretching.
With respect to the ACA, I'm not sure what you're talking about, though. SCOTUS ruled that the ACA could not be justified under the Commerce Clause. They upheld it as a legitimate exercise of Congress' power to tax.
In 1789 "arms" meant a musket or a flint lock pistol that fired a miniball
What's a miniball?
Do you mean, perhaps, Minié ball? No, you couldn't because those weren't invented until the 1850s.
I'd address the meat of your argument, but Orgasmatron already did it, excellently.
the supreme court could rule tomorrow that "well regulated" means "with mustard and mayonaisse"
Bah. Can you cite a single example of the Supreme Court doing anything remotely like redefining common words to mean something completely different from what they mean? Note that the GP's claim about the Court's definition of "well-regulated" is false. The Court said no such thing (there is historical justification for a similar argument, but the Court didn't go there).
Their primary rationale was that the words "the people" must be given the same meaning they're given in the other amendments of the Bill of Rights, notably the first and fourth. Just as we have an individual right to freedom of speech, freedom of religion and protection from unwarranted search and seizure we have an individual right to keep and bear arms. The Court ruled that the militia clause was merely motivational and prefatory and that while it might have given the framers' primary motivation for the second amendment, it does not restrict the operative clause.
You may wish they'd found differently, but their decision was clearly not capricious, as you're trying to imply.
You're on the wrong point.
"Well regulated" means "trained" or "skilled" in that context at that time. The SCOTUS has already ruled on that.
I don't think that's correct. It's been a few years since I read the DC v Heller opinions, but I don't recall any of them going into the meaning of well-regulated.
What they did hold, though, was that the militia clause was prefatory only, merely announcing a purpose, and did not restrict or limit the meaning of the operative clause. In addition, the court found that when the second amendment says "the people", it means the same thing as when the first and fourth amendments say "the people", and therefore the same people who are guaranteed freedom of speech and freedom from unwarranted search and seizure are guaranteed the right to keep and bear arms, meaning it's an individual right.
As an aside, the definitional arguments I've read claim that "well-regulated" referred more to "well-equipped". The term allegedly derives from British practices of verifying the proper equipping and manning of regiments, which weren't managed by the Crown but by wealthy individuals (generally nobles). The Crown paid the regimental commanders for maintaining their regiments, though, and required them to present their regiments for inspection to prove that they were "well-regulated", meaning they had the requisite number of soldiers and all were equipped and uniformed per the regulation standard. Thus, the phrase "well-regulated" really referred to complying with Crown regulations for a regiment, and using it to mean "well-equipped" in general terms was an abuse of the term, since there were no relevant regulations, but it was a common abuse in the period.
But SCOTUS didn't delve into the details of word usage, they just dismissed the militia clause as prefatory and not impacting the meaning of the operative clause, which provides for an individual right.
That may be true, but how well would she be able to use it without someone like you to smooth out the rough edges?
And what clueless Windows or OS X user doesn't have someone smoothing out their rough edges?
The wives and kids and I used to take up an entire row at the Mormon church.
You should be a little less transparent with your sarcasm. Or know a little more about Mormons.
I was on LinkedIn for a while, and it was worthless, IMO. I only got two kinds of contacts: From people who wanted me to follow their vanity blog, and from employment agents who seemed unable to read the parts of my CV
I think LinkedIn is useful as a self-maintaining Rolodex, not as a social network. It's not about who contacts you, it's about having a way to contact the guy you worked with last year fifteen years from now when you're looking for a job.
That said, my current job came about from a recruiter searching LinkedIn.
It's a bit OT but this effectively dispels the myth that hiring is a meritocracy. It's often more about who you know, and who you are known to.
What you say is true in some cases, but the fact that knowing people makes it easier to get a job in no way implies that hiring isn't a meritocracy. There's another obvious explanation for this phenomenon: Merit is all but impossible to accurately evaluate in an interview.
If I care only about the ability to do the job, nothing else, and I'm faced with two candidates, one of whom I worked with for a year doing a similar job and one I know only through an interview, I'm not going to be comparing them when making my hiring decision. Instead, I'll make two separate decisions: First, is the person I worked with able to do the job? I know the answer to this question with a high degree of accuracy, because I saw his or her work over an extended period of time. If the answer is yes I'll extend an offer without giving the other candidate any serious consideration.
If the candidate I know can't do the job, then I'll consider the other candidate, but only then.
My current employer has a hiring process that attempts to even this out and remove personal relationships from the hiring decision, but the effect remains. Individuals don't make hiring decisions, committees do, and as I understand it anyone on the committee who knows the candidate personally is supposed to recuse themselves. However, the process does accept and even solicit feedback from individuals who know the candidate personally, and the committee places great weight on the content of that feedback (which must be detailed and specific, and I'm sure is evaluated in the context of the employee's own work), because it's hugely more reliable than feedback from interviewers who talked to the candidate for an hour. Even with this process in place it's easier to get hired if you are respected by some current employee. Not because "it's about who you are known to" but because of the quality of the information available to the hiring process.
That is just crazy. These are not high-risk/return investments funds. Just load up on a diversified bluechip portfolio, and make sure you follow all the other sheep so that you can't be singled out for getting something wrong.
Will that strategy net you a 20% return on your investment? Because that's what Yale's fund managers achieved.
Also 6% seems a very high price to manage money. Where they getting a return on investment of 12%?
They didn't get 12% ROI, they got more than 20%. And it was that success that got them their big payday.
According to the article, the fee for the investment managers is 2% plus 20% of the growth. The 2% amounted to $137M and 20% of the growth was $343M, which means that the managers' efforts increased the size of the endowment by $1.7B. That's phenomenal. The bankers made a lot of money, yes. Too much? I don't know; I'd be happy to let them manage my investments under those terms with those sorts of returns. As for the university, they were able to spend $1B of their endowment while increasing its size by over $200M, net.
That's exactly what an endowment should be doing: Generating a health return and spending most of it, but retaining a modest increase to keep up with inflation.
I really don't see the problem here.
"Though GC actually does eliminate dangling pointer bugs... by turning them into memory leaks."
Give us an example of a dangling pointer being turned into a leak in Java. In other words show me a pointer that points to deallocated memory and some memory that's allocated but cannot be pointed to any more (because I don't know where it is).
A dangling pointer in a non-GC'd language is one which the programmer thinks will no longer be used and therefore deallocates, but which actually does get referenced later. Boom.
In a GC'd language, the same scenario results in the object not being deallocated, so it's still around when it gets referenced later. No boom, which is good. However, this is arguably a form of memory leak because the programmer believes it should have been deallocated, and is assuming that the memory is available for other uses.
I believe that is already fixed, and that the fix will be released in the next update of the Play services app. However, I work on the core Android OS not on Play Services, so I don't follow that stuff closely.
Have you ever considered learning how to test stuff?
LOL.
You have absolutely no idea what you're talking about.
Tell that to console applications. I want to send PgDn to the program or server, not scroll the window.
That's an issue with the terminal emulator, not the keyboard. You'd have the same problem if you did have PgUp and PgDn buttons. Your issue is how the key is interpreted, not how to type it.
Torvalds is a Swedish speaking Finn. That's why he says "planning 10 years ahead is not sane". The Swedish word is "klok" which can be translated as "sane" or, more reasonably.... "sensible."
Linus Torvalds has pretty thoroughly mastered English. I'm sure he said "sane" and meant "sane", with full appreciation of the meaning and overtones of the word and of the alternatives he could have chosen.
I bought an Android One phone to get regular updates. It took more than 6 months for Google to roll it out to my device. I was expecting an update within 2 weeks of the announcement at Google I/O.
(I'm an Android engineer.)
The announcement at Google I/O isn't the release. As of today, Android M still has not been released. i think the third and final(?) preview went out early this week, but it's still a preview, not a release.
This is a pretty common misunderstanding of the Android release process. The announcement of a new version and its features comes when the feature set is demonstrably finalized, long before it's actually done and debugged. That means that our code is "feature complete", meaning we can demonstrate all of the features, but in many cases there are still a lot of bugs to fix. In some cases the bugs are of the form "three of the four use cases for this feature aren't implemented yet." (I actually did that this year; I'm responsible for the hardware-backed crypto and when preview1 went out I had completely broken asymmetric crypto. Hardware-backed AES and HMAC worked, but RSA and EC did not. And that was just the big stuff; there were lots of minor features that were broken, too. It's all working now.)
The reason for announcing features and publishing APIs well before the actual release is to give all of the partners and app developers plenty of time to start getting ready for the release.
Unless you're a glutton for punishment, you really don't want the version released at I/O. I know... I've been running M on my Nexus 6 since about February and it has been rather bad at times. Bad, as in the phone app crashing continually, or Google Play Services not running (which takes out pretty much all of the Google apps, plus some), etc. At a couple of points I almost had to abandon Marshmallow and go back to Lollipop because my phone didn't work. It's getting close these days, but it's still not done. I haven't personally run into any problems for a while.
If you really *do* want Marshmallow now, you can always unlock your device and install the third preview. I don't recommend it, but I don't recommend against it, either. Like I said, it's actually working pretty well on my device. But don't be shocked if you find stuff that doesn't work. That's why it's a preview.
So Google broke their promise big time.
Nope, you just misunderstood the promise :-)
The promise is within two weeks of release, not two weeks of first public alpha. And you are happy about that, really you are.
3) absolutely no use of of malloc or free. it could lead to stack overflows.
You mean heap exhaustion. Use of malloc and free cannot cause stack overflows.
No, no, no, no, no! The concept of garbage collecting is a reaction to poor coding practices and reliance on it is laziness. Software engineers responsible for real-time, public safety software should be capable of managing memory in their code!
Garbage collection is a red herring. The notion that "real" software engineers must use manual deallocation is just as silly as the idea that garbage collection eliminates memory leaks. Though GC actually does eliminate dangling pointer bugs... by turning them into memory leaks.
Garbage collection is a viable and reasonable strategy for handling deallocation -- in fact it can be significantly more efficient than manual deallocation, in terms of cycles spent on deallocation -- but it's not a panacea. It doesn't eliminate the need to think about object lifetimes or memory consumption. It reduces the amount of development effort focused on those issues, trading it instead for management of GC times. Whether that tradeoff is a net benefit depends on the context and system requirements.
And that is what real software engineers do. They don't choose their tools based on which is the manliest and best for proving their coding prowess. They choose based on the nature of the problem and the resources available. Where GC interruptions can be tolerated, or safely scheduled, GC is a tool that automates away significant engineering effort. That's a good thing. Hard real-time systems generally don't tolerate GC very well, but virtually anything that interacts with people does tolerate brief (50 ms or less) GC pauses, and that's actually quite easy to achieve.