Sure, the comparison isn't total, but is similar in terms of the "bare metal" layer nature of it...
Switching to the oft-used RMS car analogy, Android phones are like having the shop manuals for the engine, but the hood is still intentionally welded shut...
My sincerest apologies... I thought I had verified...
s/your/the/
Personally I doubt that either iOS nor "core Android" (that is to say, what Google releases) has anything truly close to actual, nefarious, spyware. However once Android is turned over to the carriers....
I built my own kernels in '95, and have contributed to open source projects years earlier, and yes, I would consider building (which you conveniently ignored) and deploying Android significantly more difficult than building and deploying the Linux kernel was in '95.
Prove Android is free of spyware first. Just because you get to see the source code doesn't mean it doesn't exist. So go head over to Mountain View to sign up Google's board...
Just how are they "inefficient"? Tesla's website has plenty of "scientific-like" data showing that they are *much* more efficient users of source energy...
I disagree. The very real risk (result!) is from the carriers putting crapware/spyware/etc. that you can't remove. I don't fear Google or Apple in this respect. Consider that yesterday it was revealed that Japan's largest carrier doesn't sell the iPhone precisely because Apple won't allow them to install such things.
Secondly, I don't consider it truly open source, unless I can reasonably make changes, which you can't do with Android phones currently on the market.
I have a fatal personality flaw in that I treat people exactly at the same level they treat me.
I'm not even talking about quicksort vs. bubble sort. That's still a nuance. I'm talking about taking a step back to even *recognize* that sorting will be required and that sorting efficiency matters...
If they were "implementing optimisations no one will ever notice", howcome I did? In reality they came to me and asked for help because they knew they couldn't turn in what they'd coughed up...
"Windows has to support a lot of hardware" -- no it doesn't -- it mostly leaves this up to hardware manufacturers to write their own device drivers. Bad design. cf. Linux--same hardware (more actually) significantly more efficient.
"Optimization guru" -- never claimed to be. To me it's idiotic. Performance needs to be considered at the design stage, not as "tuning" at the end of the process. It's funny that you depict things this way--it clearly shows you fail grasp the basic concept of what I'm saying...
"rose tinted view of an era" utter crap. The "good ol' days" sucked--most programmers backed into the career because of a skills shortage. But they couldn't get away with the crap people do today due to the slower hardware of the era.
I don't respond to the other false statements you're making up and attributing to me...
Classic computing urban legends... The Knuth quote he attributes to Tony Hoare is denied by Hoare himself, and still itself doesn't contradict my claim. "We should forget about small efficiencies..."
I am NOT talking about small efficiencies (saving 2 bytes on the stack by reusing a variable in another context). I am talking about the MAJOR ones. Knuth et al is saying "don't lose sight of the big picture by focusing on minor things at the design stage". I am saying "don't screw up the big picture by ignoring performance considerations at the design stage (and assuming they can be corrected by 'tuning' at the end".
Well me too, but as I wrote in a follow-up post, they are not setting out the code up sorting. And even if they had the 0.001% case where they knew they needed a special case sorting algorithm, they could most probably do it right quite easily.
The problem is in not recognizing that sorting (or whatever) is at play, they are over-modularizing pieces building bottom-up and ignoring top-down etc.
Case in point, colleague codes something that looks kind of like a spreadsheet--two-dimensional matrix of text cells. It takes 12 minutes to render 20 columns Ã-- 80 rows. Design was based on generic cells--"you're a cell at column i, row j; go figure out what you need to do". This resulted, among other things, in >4 million calls to get the text of a cell (more complex than just reading a string). Yet there was no obvious inefficient code--no 5-level nested loops, etc. Colleague's response was to implement a cell-text cache to speed up the reading of the cells' texts--not to fix the obvious error in design that you shouldn't need to ask >4 million times for 1,600 cells...
Where can I find this PC that is able to get through the BIOS bullshit in under 10 seconds? Note that my clocking of start up time goes from the moment you press the power button, until that time *after* you've logged in, that the system has stabilized such that it is ready for use.
Funny thing is, the best hardware I've ever used that gets the OS actually starting faster is the MacBook Air. There's no obnoxious net boot delay that can't be switched off, etc...
Cute, but I would argue that the concept of optimizing slow code after the fact is a prima facie thought crime. The biggest performance gains come from choosing the right algorithms in the design stage.
They don't set out to implement a sort algorithm, they do it unknowingly. They don't recognize that the problem they are working on involves sort, but yes, generally any library/framework sorting call they could otherwise have made would have sufficed--and saved them a lot of time...
If you call "installing Win7 by choosing the default options and attaching to a local domain" screwing it up, I guess I screwed up by choosing M$ products...
Slashdot Mirror
Sure, the comparison isn't total, but is similar in terms of the "bare metal" layer nature of it...
Switching to the oft-used RMS car analogy, Android phones are like having the shop manuals for the engine, but the hood is still intentionally welded shut...
And I repeat, "Impressive!"
arghh... s/either/neither/ ...oh wait, now I'm into double-negative territory...
s/doubt/believe/
My sincerest apologies... I thought I had verified...
s/your/the/
Personally I doubt that either iOS nor "core Android" (that is to say, what Google releases) has anything truly close to actual, nefarious, spyware. However once Android is turned over to the carriers....
Wow, impressive argument!
You essentially nullify your own statement and then proceed to insult with vulgarities...
Impressive!
I built my own kernels in '95, and have contributed to open source projects years earlier, and yes, I would consider building (which you conveniently ignored) and deploying Android significantly more difficult than building and deploying the Linux kernel was in '95.
No, I'm just ridiculing the stupidity of your comment.
Prove Android is free of spyware first. Just because you get to see the source code doesn't mean it doesn't exist. So go head over to Mountain View to sign up Google's board...
CynaogenMod? Seriously?
Here's sample instructions on deploying: http://wiki.cyanogenmod.com/wiki/HTC_Aria:_Full_Update_Guide
And that's just deploying a supplied image, not building. Cf. building & deploying a GNU desktop/server app, or even the Linux kernel...
> (I will respond to further replies in the branch immediately preceding this one)
Are you trying to turn the comment tree into a DAG?
Just how are they "inefficient"? Tesla's website has plenty of "scientific-like" data showing that they are *much* more efficient users of source energy...
I disagree. The very real risk (result!) is from the carriers putting crapware/spyware/etc. that you can't remove. I don't fear Google or Apple in this respect. Consider that yesterday it was revealed that Japan's largest carrier doesn't sell the iPhone precisely because Apple won't allow them to install such things.
Secondly, I don't consider it truly open source, unless I can reasonably make changes, which you can't do with Android phones currently on the market.
It appears to me that this whole thing is just another attempt to get you all riled up about big bad Goliath...
TFA is incredibly weak, lacking any sort of details...
Consider that the restaurant may have been using a different logo earlier?
Maybe a billiard?
I have a fatal personality flaw in that I treat people exactly at the same level they treat me.
I'm not even talking about quicksort vs. bubble sort. That's still a nuance. I'm talking about taking a step back to even *recognize* that sorting will be required and that sorting efficiency matters...
Could be... I've never experienced that... If it's true, then Apple's got some crappy code too...
Bzzt... Wrong. And obviously so...
If they were "implementing optimisations no one will ever notice", howcome I did? In reality they came to me and asked for help because they knew they couldn't turn in what they'd coughed up...
"Windows has to support a lot of hardware" -- no it doesn't -- it mostly leaves this up to hardware manufacturers to write their own device drivers. Bad design. cf. Linux--same hardware (more actually) significantly more efficient.
"Optimization guru" -- never claimed to be. To me it's idiotic. Performance needs to be considered at the design stage, not as "tuning" at the end of the process. It's funny that you depict things this way--it clearly shows you fail grasp the basic concept of what I'm saying...
"rose tinted view of an era" utter crap. The "good ol' days" sucked--most programmers backed into the career because of a skills shortage. But they couldn't get away with the crap people do today due to the slower hardware of the era.
I don't respond to the other false statements you're making up and attributing to me...
It may very well be a configuration issue, but it is Microsoft's issue, not mine! (Yes, domain...)
Classic computing urban legends... The Knuth quote he attributes to Tony Hoare is denied by Hoare himself, and still itself doesn't contradict my claim. "We should forget about small efficiencies ..."
I am NOT talking about small efficiencies (saving 2 bytes on the stack by reusing a variable in another context). I am talking about the MAJOR ones. Knuth et al is saying "don't lose sight of the big picture by focusing on minor things at the design stage". I am saying "don't screw up the big picture by ignoring performance considerations at the design stage (and assuming they can be corrected by 'tuning' at the end".
Well me too, but as I wrote in a follow-up post, they are not setting out the code up sorting. And even if they had the 0.001% case where they knew they needed a special case sorting algorithm, they could most probably do it right quite easily.
The problem is in not recognizing that sorting (or whatever) is at play, they are over-modularizing pieces building bottom-up and ignoring top-down etc.
Case in point, colleague codes something that looks kind of like a spreadsheet--two-dimensional matrix of text cells. It takes 12 minutes to render 20 columns Ã-- 80 rows. Design was based on generic cells--"you're a cell at column i, row j; go figure out what you need to do". This resulted, among other things, in >4 million calls to get the text of a cell (more complex than just reading a string). Yet there was no obvious inefficient code--no 5-level nested loops, etc. Colleague's response was to implement a cell-text cache to speed up the reading of the cells' texts--not to fix the obvious error in design that you shouldn't need to ask >4 million times for 1,600 cells...
Where can I find this PC that is able to get through the BIOS bullshit in under 10 seconds? Note that my clocking of start up time goes from the moment you press the power button, until that time *after* you've logged in, that the system has stabilized such that it is ready for use.
Funny thing is, the best hardware I've ever used that gets the OS actually starting faster is the MacBook Air. There's no obnoxious net boot delay that can't be switched off, etc...
Cute, but I would argue that the concept of optimizing slow code after the fact is a prima facie thought crime. The biggest performance gains come from choosing the right algorithms in the design stage.
They don't set out to implement a sort algorithm, they do it unknowingly. They don't recognize that the problem they are working on involves sort, but yes, generally any library/framework sorting call they could otherwise have made would have sufficed--and saved them a lot of time...
Wrong. Valid, licensed, genuine, blah blah blah. Google "black screen blinking cursor"...
If you call "installing Win7 by choosing the default options and attaching to a local domain" screwing it up, I guess I screwed up by choosing M$ products...