2,742 karma · joined February 18, 2008
One of the things that she can do to motivate her teams is to take an interest in what they are doing - a weekend retreat for the design of the logo? Great! Marissa cares about what I'm doing, I'm important to the company!
On the other hand, having your CEO show an interest in what you are doing is generally speaking a huge motivator for people. It's cold indifference to anything you do that will drive people away.
I'm willing to bet that the actual target for the logo redesign story was internal. Mayer is sending a very clear signal to all Yahoos that yes, they are good enough, and no, she isn't going to get external help to do the things that are core to Yahoo's business.
Nintendo has to compete against that, and it is not easy. On the other hand, Nintendo could make an absolute killing by selling a gamepad accessory for the iPhone - extra battery life plus a decent d-pad/thumbsticks would be an easy sell for gamers. You could probably even price it at a pretty steep mark-up and make nearly as much profit as they must be making on the DS. Make all Nintendo games compatible with it, and run a licensing scheme so that other game companies can list themselves as compatible with the hardware.
This strategy allows Nintendo to continue innovating where they have successfully done so in the past - specifically with clever input devices. It's been a long time since Nintendo could claim to rule the roost for things like raw processing power, so leave Apple to do the heavy lifting there.
losethos: Smart American kids my age had C64s and Apple IIs. We all entered 6502 machine code into DATA statements in BASIC programs. Everyone did it. It seems so fantastical and primitive to a monkey, doesn't it. Generally, we used monitor program to disassemble and assemblers, though you had to buy an assembler. Every store had magazines with BASIC programs full of DATA statements with graphic and machine code data. People typed it in. We had xsum bytes on blocks.
To a certain extent, this has been true for more than two decades. I used to work as a radar engineer for the RAAF, and every time we went on exercises against US forces (both teams flying F 18s, but with different missile payloads, we had AIM9s, the Americans had AMRAAM), we would see our aircraft swatted from the sky before we could even get the bogeys on weapons-system radar. Talk about dog-fighting maneuverability and visibility is just ridiculous - if you're using those characteristics, you've already lost the battle. In the control room we used to joke that the USN could have sent P51s equipped with AMRAAMs and AWACS support and they would still win.
Modern fighter aircraft need to:
a) not be seen b) be fast (time to target is still important!) c) carry a decent payload of weapons.
Ideally target selection should be provided by AWACS, and missile-sensors provide the final kill guidance, allowing the fighter (AKA missile-launch platform) to remain stealthy. In the absence of AWACS, the fighter will need to carry it's own sensor suite.
Modern air warfare is all about sensors, ECM and stealth. The airframe is almost inconsequential.
I'm sure it must be similar to the feeling I get when I'm working on a new code base that I'm not familiar with, and I need to make a modification in a function so that it calls another module correctly for some new functionality. But I can't tell if that change isn't going to break something somewhere else, so making that change becomes quite scary.
In the software development world, we handle this by creating suites of automatic tests that we can run after the change to make sure that what we just did doesn't break things. We also use config managent software so that we can back out any erroneous changes. These things aren't available to nontechnical users - they can't verify that they haven't broken anything, and if they have broken something, they may not be able to put things back the way they were. This pretty much guarantees that people won't experiment with their computer.
For my personal use, crossover is good enough that I no longer install a windows vm for my occasional windows app usage.
Also, which goal posts do you think were being moved exactly?
Watching the police in action is the one negative experience that I have had in the US. You guys really need to calm your (oversized) police force down - they're thugs in uniform.
There was no mechanism for the rank and file to state their resistance in a timely fashion in a way that the leadership could hear, and of course the membership itself was deeply divided on the issue - once again, there was no mechanism for dissension amongst the membership to be dissipated. The result was that the party blew up in spectacular fashion at the next elections, unable to get the membership enthusiastic enough to put boots on the ground to run election activities, with a consequent massive drop in the polls, leading to a drop in funding, leading to extinction.
I was in the NSW branch and as a result of this mess became policy manager and tried to put in place what we would call a crowd-sourced policy creation system. But this was in the early 2000s, the Internet was still not entirely ubiquitous, and management in NSW decided that we had to do this thing on paper, not on the Web. It was slow, painful, and I moved countries before getting to the end (and anyway, it was too little too late, the writing was on the wall).
All of that to say that I don't think we can use the Australian Democrats as a counterexample for direct democracy. They never really had the processes in place to give such a system a chance. Today the story might very well be different if a direct democracy party was tried with a correct set up of tools to allow the rank and file a chance to meaningfully participate in policy creation. I've often thought about trying to set one up on that basis, but since I live in a country now where I'm not even a citizen, I've never tried.
The only real way to avoid that is for a project to include a bunch of compliance tests, that validate that an underlying library correctly performs the operations the project needs it to do. But this is actually a lot of work, so in reality it will almost never be done. Which leads us back to the discussion about the wisdom of packagers changing libs without understanding the on downstream projects.
Regardless, we can be relatively sure that that graph is there to help developers when deciding which versions of iOS they should support. It would not be surprising if Apple decided simply to include only active App Store shoppers, because this is the number that actually interests developers.
(i) I'm not actually sure if this is true if you have never installed an app from the App Store - there is maybe an exception where these phones don't check for updates in this case.