> Trust me I have a friend who loves breaking into my personal server.
Sterling work establishing your own competence there.
153 karma · joined April 17, 2009
Sterling work establishing your own competence there.
It's peculiar that Google claims that it is utterly impotent to persuade developers to use Pointer Events, and so it is going to give up even trying, and yet it continues to develop Dart and make vague noises about integrating it into the browser.
My view is that you can't develop effective general purpose application software without an internal customer, because until you have that internal customer, you can't meaningfully dogfood it, and you can't get the feedback loop tight enough.
Take, for example, WPF. WPF addressed a real need, I think; developers wanted a decent GUI stack (which Win32/WinForms/MFC/whatever just ain't), and long term, Microsoft wanted something amenable to 3D acceleration and DPI increases. Great.
Except that for the longest time, WPF was deeply problematic for any major application. Problems around text handling and performance were the biggies. Microsoft had no real internal customer for WPF. Some of the Blend apps used it, but they (now discontinued) were never a critical part of Microsoft's day-to-day operation.
When did WPF get good? When an important application (Visual Studio 2010) started using it, and made clear that hey, something needs to be done about that text rendering and performance.
I think there are quite a few little corners of Microsoft's software in a similar boat. The new-to-Vista sound card/audio APIs were plainly not fit for purpose in their original form, but nobody in Microsoft noticed, because nobody in Microsoft was actually using them. Late in the development cycle the APIs were updated (adding notifications when a buffer was nearly empty) to make them usable, but it created a troublesome driver situation for a year or more post-release.
With the internal customer, the feedback becomes much more immediate. Microsoft's customers don't get to see every 3 week cycle. Internal customers do.
When the developers are using the very product they're developing, this becomes better still; there's an implicit understanding of what the thing should do, and how it needs to be better. This becomes institutional knowledge, and it likely never even manifests as an explicit request. It doesn't have to. The implicit understanding of how customers are using the software and not just what they want but _why_ they want it is sufficient to ensure proper and effective implementation of their requests.
You know, I should have written about that a bit more. It makes sense in retrospect, I didn't even think about it at the time, even after leading off with the problems of the VS2010 cycle.
But, yes. If one looks at how VS and TFS have evolved, it's been very clear that there must have been some internal customer who really wanted to use them for scrum (no external customer would ever be that influential). The last few releases, not to mention the VS2012/2013 quarterly(ish) updates have all had an emphasis on improving this aspect of the products.
Accordingly, they seem to have become pretty decent, and this has no doubt helped teams change how they work.
Windows Phone 8 was intended, first and foremost, to bring the kernels into alignment. It did this. It is a shame that it does not provide the full WinRT API, but Microsoft never said that it would, so I'm not sure why you're saying that it was "supposed" to.
2) Either the browser demands an unlock password every single time it queries the password store--which is probably not an acceptable experience for most users--or the browser can arbitrarily read the password store when left unattended. There's no meaningful middle ground here. An option to demand a credential before unlocking the store might be nice for nerds, but nerds don't need it anyway, because they can use 1Password (or similar) to do this for them. It's simply not tenable for normals. Good grief, just look at the wailing and moaning that the UAC prompts in Windows Vista generated. Those prompts by default didn't even demand credentials, just a click through.
I agree, it's totally reasonable, which why I say in the article, "Removing the JavaScript layer is one thing; this was a piece of code that existed only to support Google's use of V8, and with JavaScriptCore now the sole WebKit engine, streamlining the code makes sense. Google, after all, is doing the same thing in Blink. "
It may make things harder for some out-of-tree branches, so it's probably bad news for them, which is why it also suggests that, depending on their priorities, some forks might find it better to switch to Blink.
> Apple is talking about removing a feature that no one is stepping up to maintain.
Apple is also the richest technology company in the world. I would never pretend that this means that it can simply add new WebKit developers overnight. But equally, I have a hard time accepting that there will apparently be a _long-term_ developer deficit, such that the best option is to simply cull features now, rather than retain them for a couple of months while staffing is being increased.
It's possible that features culled now will be restorable from version history in the future, but that rather depends on how many changes are made in the interim. If they're significant (integrating JSC more completely, ripping out things that Google added such as threaded HTML) then it's not clear that reinstating them from old versions will be trivial.
I acknowledge that Google had an advantage here. By making the decision to fork, Google was in a position to make sure that it had the right people in the right places to maintain the codebase. Opera's involvement in Blink is probably helpful in this regard too. But come on. If Google can maintain this range of standards track features, is it really reasonable that Apple can't at least match it?
What they don't realize is that in aggregate, their willingness to do it for free jeopardizes their ability to do it for money in the future. It's a nice little game theory problem. A single defector from the "only work for money" strategy probably benefits; the rookie journalist gets his foot in the door, gets the "exposure" and the industry connections, and so yields an advantage over his peers.
But once all his peers defect from the paid strategy, the whole thing comes crashing down. None of them achieve any advantage over any other. They just drive the median compensation down towards zero.
The claim that there's an abundance of high quality journalism is hogwash. There isn't. There's a glut of no-talent regurgitators. Most of them have poor knowledge of the subject matter, don't bother checking facts, don't do any original research, and generally offer little of value.
First, marginal tax rates are taxed on marginal income, not gross income. The $250K bracket only kicks in for dollars earned over $250K.
Second... there are, in fact, points on the income ladder with a marginal rate that is greater than 100%. But they're not a problem for the rich. They're a problem for the poor. At certain points, the removal of things like food stamps and tax credits can result in a marginal tax rate of greater than 100%, which is to say, you are literally better off making less gross income, because you will have more spending power.
I hope it's deep enough that programmers who haven't been tracking Microsoft's efforts religiously will find it educational, but not so deep that someone who's merely interested in what makes the operating system tick is scared off.
Saying "we'll provide the tools and insist that developers use them safely and securely" is a bullshit answer, and always has been.
You're either secure by default, or not at all. In this case, not at all.
Sadly I lost that battle. I didn't want to include it, but sometimes we writers do not get to make those decisions.
Power consumption was mentioned at a number of points in the article. It's just there's not a whole lot to say about it--it's not exactly a strength of the architecture.
Rendering is more or less equivalent to HPC. Different markets, but similar problem sets (lots of computation, minimal communication or dependencies between threads).
None of those are particularly relevant to typical server workloads; servers are doing things like querying databases, spitting out Web pages, running Java VMs, running virtualization software, that kind of thing.
a) I agree it remains unclear how much difference the SSD makes. That's why I don't think it's a useful demonstration of Bulldozer's performance _even though AMD is citing it as such_. b) Yes, I do. That 1/3 more cores gives 1/3 more performance in a test that scales almost perfectly means that the per-core performance has stood still. A 32 nm K10.5 chip with 1/3 more cores would perform just as well, cost less to build, use less power, and eliminate the performance regressions. So what is the point of Bulldozer? c) No, it reinforces the "Bulldozer performs no better than a scaled up K10.5 system would and hence is pointless" narrative. d) @_@ e) No. I don't have a half million dollars of equipment just lying around so that I can run TPC-C (etc.) myself.
Cheers!
> While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations)
A few things? No, it shares a lot of things. The entire floating point and SIMD unit. The entire front-end. The branch predictor is, I believe, a weird hybrid of shared and non-shared. The I-cache, and the L2 cache, also both shared.
The front-end is particularly troublesome. The entire decoder can either service one thread or the other. If both threads need instructions, the best it can do is round robin between them. This averages to allow just two instructions per cycle: less decode bandwidth than K10.
Likewise the integer units: there are fewer ALUs and AGUs per thread than in K10. Likewise the floating point unit. There's lots of sharing, and even the private, non-shared parts are resource-starved.
> But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit).
SSE contention will occur if a thread can issue more than two SSE operations per cycle, or one AVX operation per cycle.
> Bulldozer is pretty cool, but sadly the tech press decides to shit on the underdog in a market that multiple companies have successfully sued the monopolist for anti-competitive behavior. :(
I don't care about "the underdog" or which is "cool" or which multi-billion dollar corporation you might prefer. I care about which works better. It ain't Bulldozer.
I don't dispute that it works. But it does rather detract from, well, the aesthetic elegance of the machine. Apple has these fancy backlit keyboards--it's a great shame to make the keycaps wrong.
Plus, it also causes big problems when I let others use my machine. Hunt-and-peckers don't stand a chance when your keys are mismatched. Though they probably struggle even with the regular Apple layout--good luck finding # on the keyboard, since Apple doesn't deign to print it. Sure, once you know it's option-3 it's not so bad, but I don't know how you're meant to just figure that out for yourself.
And the thing is, it's all just gratuitous. Apple's layout isn't in any meaningful sense better. It's just... different.
It also explains, I think, why WP7 is such an un-Microsoft product in so many ways, and why I love using it. It's focused in a way that other products from the company just _aren't_, and it's much better for it.