It removes some of the overhead of android and gives access to truckloads of applications that don't require much work to port (in comparison to other platforms).
Yep, that's it. Google's obsession with Java and crappy interpreters not to mention weirdo roll yer own application framework leaving out things like standard application exit is inexplicable.
Quote Invesigator (where you likely got your material from) makes a pretty good case that the modern quote actually originated from composer Roger Sessions in 1950, and may have been inspired by something Einstein had to say specifically about theories.
...because regardless of your desire to know what's on there, they're under no obligation to do so and may consider it a competitive or business advantage to not do so...
In short, you maintain that Sony has the right to conceal from me the code that is running on the device that I purchased from them, and own, and in theory should have complete control over. That is a disgusting, indefensible position to take.
More likely the exact opposite. As a corporate entity, you avoid the reliance on GPL licensed code at the core of your product if you're not 100% sure you're not going to need to hack the software up.
The BSD choice, I'd hazard a guess, is explicitly because they needed to. or believe they'll need to, hack up the OS and didn't want the IP baggage that comes from needing to do that with a GPL-based system.
What kind of nonsense are you spouting? Copyleft vs permissive has nothing whatsoever with your right to hack up the OS, only with Sony's obligation to provide the changes on request to whoever receives the binaries. IOW, this has nothing to do with Sony's needs, and everything to do with Sony's desire to conceal from users exactly what code they are running on the device they thought they owned.
Sony grows up and decides not to hack up their own crappy OS any more, finally entering the 21st century. However in a nod back the PHB nest that traditionally comes up with their PHB strategies, they decide to go with the second best free kernel out there because it allows more scope for doing evil. Nice one Sony.
Oh well, it could be worse. The other guys have to use Windows.
A naive observer might conclude that blanketing the entire market like falling snow would be an effective way to get complete coverage.
BTW, you Apple astrofurfers are special little snowflakes, yes you are. Just please don't melt all in one place when melting time comes. (Pre-emptive commentary to the usual horde of astroturd Apple cultmods.)
Oh, it seems we flushed out a special little Apple self righteous snowflake or two. You make me sick, and your morally bankrupt company makes me sick. Nice to watch you go down.
A naive observer might conclude that blanketing the entire market like falling snow would be an effective way to get complete coverage.
BTW, you Apple astrofurfers are special little snowflakes, yes you are. Just please don't melt all in one place when melting time comes. (Pre-emptive commentary to the usual horde of astroturd Apple cultmods.)
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
Git is full of appalling bad usability decisions. Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified. Warts like this are strictly a geek endurance test, to learn where your pain threshold is. If it is sufficiently high then you are cut out to be a Git nerd forever.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
Mercurial matches Git in functionality and performance, but completely blows it away in terms of usability and elegant design. Without the Linus factor, everybody would be using Mercurial, not Git. I tend to use Mercurial a lot anyway. One weird and useful thing I do with Mercurial is make a Mercurial repository inside a Git repository, to track files I don't want in the Git repo but still want to track and keep in the same directory.
Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.
I didn't bother with the fourth terminator after being thoroughly underwhelmed by the third. I will pass on this one too, I won't pay money to see a wrinkly flabby terminator.
Best commentary on the financial trade in geek minds ever. One further thing to aded: those assholes feed on each other. Good luck finding a happy one. Closest you will find is manic.
You got that one wrong. Netburst was about deepening the pipeline to ridiculous extremes in order to ramp the clock. The new AMD story is pure clock ramp via process technology and power management. Big difference there.
Take a look at what your local Department of Motor Vehicles uses for their computer system and I wouldn't be surprised if it's still dumb terminals running on an AS400 mini computer!
Additionally, they serve some crappy broken ASP pages.
It removes some of the overhead of android and gives access to truckloads of applications that don't require much work to port (in comparison to other platforms).
Yep, that's it. Google's obsession with Java and crappy interpreters not to mention weirdo roll yer own application framework leaving out things like standard application exit is inexplicable.
Similarly, it is a good idea to wall off some parts of a city that is infested with bubonic plague.
It's a rather nice formulation of it.
Quote Invesigator (where you likely got your material from) makes a pretty good case that the modern quote actually originated from composer Roger Sessions in 1950, and may have been inspired by something Einstein had to say specifically about theories.
Black is White. Freedom is slavery. Simplicity is bad. Complexity is good. Binstock is +1 Funny.
...because regardless of your desire to know what's on there, they're under no obligation to do so and may consider it a competitive or business advantage to not do so...
In short, you maintain that Sony has the right to conceal from me the code that is running on the device that I purchased from them, and own, and in theory should have complete control over. That is a disgusting, indefensible position to take.
If you understand the title of this story, I'm pretty sure you've never had sex.
I understand the title and I am quite sure that I get more sex than you do.
More likely the exact opposite. As a corporate entity, you avoid the reliance on GPL licensed code at the core of your product if you're not 100% sure you're not going to need to hack the software up.
The BSD choice, I'd hazard a guess, is explicitly because they needed to. or believe they'll need to, hack up the OS and didn't want the IP baggage that comes from needing to do that with a GPL-based system.
What kind of nonsense are you spouting? Copyleft vs permissive has nothing whatsoever with your right to hack up the OS, only with Sony's obligation to provide the changes on request to whoever receives the binaries. IOW, this has nothing to do with Sony's needs, and everything to do with Sony's desire to conceal from users exactly what code they are running on the device they thought they owned.
Sony grows up and decides not to hack up their own crappy OS any more, finally entering the 21st century. However in a nod back the PHB nest that traditionally comes up with their PHB strategies, they decide to go with the second best free kernel out there because it allows more scope for doing evil. Nice one Sony.
Oh well, it could be worse. The other guys have to use Windows.
A naive observer might conclude that blanketing the entire market like falling snow would be an effective way to get complete coverage.
BTW, you Apple astrofurfers are special little snowflakes, yes you are. Just please don't melt all in one place when melting time comes. (Pre-emptive commentary to the usual horde of astroturd Apple cultmods.)
Oh, it seems we flushed out a special little Apple self righteous snowflake or two. You make me sick, and your morally bankrupt company makes me sick. Nice to watch you go down.
A naive observer might conclude that blanketing the entire market like falling snow would be an effective way to get complete coverage.
BTW, you Apple astrofurfers are special little snowflakes, yes you are. Just please don't melt all in one place when melting time comes. (Pre-emptive commentary to the usual horde of astroturd Apple cultmods.)
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
Stop using waterfall and working in silos and your problems will go away.
+1 Funny. Spoken well and truly as someone who only knows SVN and its ilk.
Git is full of appalling bad usability decisions. Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified. Warts like this are strictly a geek endurance test, to learn where your pain threshold is. If it is sufficiently high then you are cut out to be a Git nerd forever.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
What about Mercurial?
Mercurial matches Git in functionality and performance, but completely blows it away in terms of usability and elegant design. Without the Linus factor, everybody would be using Mercurial, not Git. I tend to use Mercurial a lot anyway. One weird and useful thing I do with Mercurial is make a Mercurial repository inside a Git repository, to track files I don't want in the Git repo but still want to track and keep in the same directory.
...Having to rebase is tiresome...
Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.
Modern anti-trust is mainly based on "market power". Apple qualifies easily.
Ooh gotcha, despicable Apple astromod.
I like Microsoft the way it is, slowly choking on its own bile.
Modern anti-trust is mainly based on "market power". Apple qualifies easily.
I didn't bother with the fourth terminator after being thoroughly underwhelmed by the third. I will pass on this one too, I won't pay money to see a wrinkly flabby terminator.
Best commentary on the financial trade in geek minds ever. One further thing to aded: those assholes feed on each other. Good luck finding a happy one. Closest you will find is manic.
Heh, you of all people are complaining about dicks.
No it's not analogous to anything. It is about observing that AMD did not deepen the pipeline, therefore this story is not like the Netburst debacle.
You got that one wrong. Netburst was about deepening the pipeline to ridiculous extremes in order to ramp the clock. The new AMD story is pure clock ramp via process technology and power management. Big difference there.
Take a look at what your local Department of Motor Vehicles uses for their computer system and I wouldn't be surprised if it's still dumb terminals running on an AS400 mini computer!
Additionally, they serve some crappy broken ASP pages.