You can also get replacement mirrors that have wide-angle views and race cars based on production chassis often have multi-element rear view mirrors that let them see everything by only looking in one spot.
The point being, you have no business looking over your shoulder in daily driving.
Look over your shoulder for as long as it takes you to determine it's safe to make a lane change. Count how long that was. 1 second ?.5s ? 2 seconds ?
Remember that value.
Now, driving along in traffic with a speed and following distance you'd normally have, close your eyes for that amount of time.
Can you? Does it feel safe? Why not?
If you need to look over your shoulder, your mirrors are not properly adjusted. I have most of my cars with the mirrors set to just the maximum of their adjustable range, but the upside is that i am not looking over my shoulder.
Most people adjust their mirrors so they have a beautiful view of the side of their car. While your car is very pretty, there's no reason to be looking at it while you drive - you'll know if it falls off or disappears, even without the help of your mirror. So, you can liberate those side mirrors towards something more useful, like having them pointed all the way out so that you can see into the "blind spot" and the other lane.
On all the cars i drive the mirrors are adjusted so that i can see a person either via mirrors, peripheral vision, or line of sight at all times in a circle around me.
Incidentally, you dont see race car drivers looking over their shoulders - they cant, since they're in a harness and wearing a helmet that cuts side visbility. The magic is in the mirrors.
The best thing you can do to not get into accidents is take a proper driving school, where you learn about mirror adjustment, vehicle dynamics, threshhold braking, looking through and ahead of objects properly, and how to relax and concentrate on your driving.
You also forget to mention that your accelerator is also a good accident avoidance tool. In non-optimal road surface conditions (rain, ice, gravel), acceleration is the _least_ decreased of your tires capabilities, with steering being the most. If i was in a traction limited scenario and had to do an evasive manuever that would challenge the level of grip available, i might opt to accelerate as the tires would deliver acceleratino better than braking or steering.
there's nothing to suggest that Linus et al would be able to improve the security of windows while ensuring that it meets its requirements. Linus has enough problem with is own operating system (but can conveniently choose to say all of userland isn't his fault when thats where the vulns are)
In any case, it's funny that you chose linux - arguably the least secure of the modern unixes. I'd have entertained a suggestion of Theo, but he'd fail because im sure his approach would be "the requirements don't matter, this is how i think it should be done", and then half of the crap customers expect would be broken.
I'm not sure how you read my statement about raw socket support being a bad thing for home users, but the point i was making is that they're not using it, so it doesn't help them, and because of the other factors i outlined, it makes thier machines more attractive and more potent for botnet membership.
If its not helping them, and its a risk, then removing it is a good thing, right ?
I don't understand some of your accusations as "bullshit". Are you telling me i'm lying to you? Do you have informatoin that I don't?
I remember the announcement internally that XP home would run with users= admin and being irate about it. Lot's of us were hoping that we'd get it right for xp but the people upstairs couldn't stomach the amount of appcompat breakage it would cause. As it is the amount of custom code in the various versions of windows for 3rd party app support is pretty outlandish. Read raymond chen's blog for a glmipse of what he was doing back in the windows 95 days to help appcompat. Things like this matter when you have 1) an installed base 2) a bunch of 3rd parties making money off your platform 3) binary compat as a requirement. Note that linux has none of these 3 aggrivating factors to deal with. (not anywhere within an order of magnitude of where MS is, at least)
For what it's worth, I agree that our testing, design, and management are all inadequate. We're just human. As an aside, we're hiring. Are you qualified to help, or just to bitch?
Most of what people do in "IT" doesn't require a college degree at all, but real world experience and specialization.
I'd consider being a Solaris admin, a CCIE, or even a helpdesk person an IT job. Obviously at vastly different expertise and salary levels.
But fundamentally, university schooling won't help you with any of them. To be a good UNIX admin you just have to do it. I can't say what's required to be a CCIE as i am not one nor have i been one. To do helpdesk work you must be a computer junkie that hasn't yet been promoted to more challenging work.
These are all different things than what you'll get from a computer science program. Computer science is the study of using computers to solve problems. Many people think this means "programming". It doesn't, and plenty of computer science graduates cant design software or program to save their lives.
If you want a job writing, designing, or testing software, look for a degree in Software Engineering. Real engineers snicker at the notion of "software engineering" since software is an immature art that is fumbling towards legitimacy, but there are almost no professional engineer type exams for software people and no real concept of liability or regulation of those practicing software engineering.
The last thing you've talked about is hardware.
This again depends on what you want to do. A friend of mine in college majored in Computer Engineering; I majored in Computer Science. I work at Microsoft on software, he works at Intel on the cache system for the Itanium series (or he did last we spoke)
The goal of that program was to turn out people that were competant to work on microprocessor as well as system design, i.e. a senior project might have been to build a PCI card that did foo. That involved knowing the circuits, knowing the pre-made parts to use, routing, and most of all, coding the processors involved. Modern hardware is not a separate entity from software - and the hardware is often generated from code.
Repairing stereos is also "hardware", but not something you go to college for.
You should decide what kind of career you want, and what you want to learn about while you're at college. The kind of career you want will partially dicate what peice of paper you leave college with (perhaps).
IT is a crap shoot. Someday, servers and routers will fix themselves, and the guild of machine babysitters that we have today will be looking for work. I wouldn't count on a career in system administration.
Software and hardware will eventually get good enough that electricians are setting up data centers.
Have you seen what kind of money electricians make, by the way?
Raw sockets have a use when you want to implement your own IGMP/ICMP packet.
Sure. Average home users do nothing but write their own protocols using raw sockets.
If i suggested or said that nobody has a use for raw sockets, i misspoke or you misunderstood. The _average_ user only suffers from raw socket support, because it makes thier machine a more desirable target for 0wnage.
for the people that legimately need raw sockets, they're smart enough to figure out how to get them.
"we don't want to admit we were wrong because then those 200 million people would know what really crappy software we sell". If Microsoft made a mistake then fix it.
Well, pick your argument. Should raw sockets be in or out? Was it a mistake to ship it with them in or not?
Our "mistake" was shipping an operating system that suffered from remote root exploits. This mistake, compounded with the need to keep home users running as admin, and also with us shipping a fully functional TCP/IP stack, allows for an unpatched xp machine to easily be turned into a botnet member. That was a big problem for us, our customers, and the internet at large. We can't ship an operating system that does what it needs to do yet has _zero_ security bugs ever discovered over its lifecycle. We don't know how. If you do, or you know somebody that does, we'll hire them. For whatever money they want.
One of the core tenets of security is defense in depth. We know that eventually someone will break into a windows machine. When they get there, we want it to be harder for them to turn it into a botnet drone/zombie. In the future we'll hopefully get away from running-as-admin which will further raise the bar.
Put some of that ill gotten gain to use and fix the problem the "Right Way"
I said we were working on doing just that, and that running as non-admin almost made it into WinXP. Unfortuneately, all those people out there with badly written software (some of it by us, probably) running on windows expect it to still work. We couldn't get everything sorted out in the Windows XP time frame. It's been a source of non-stop work and the story for longhorn will be better but i dont know to what degree (i.e. it may not be all the way fixed).
A kernel that can be patched and have its own hooks intercepted by malicious software is the problem.
Show me a kernel in use on home computers that doesn't suffer from this.
Which department are you in, Public Relations or Marketing?
Testing, actually:) As many defects as you find in MS software, beleive me, there are plenty that never make it to you.
to make it harder for 0wned PC's to effectively mount DDoS / scanning attacks against the inernet.
You cannot argue that this does not make it more difficult - at a minimum existing payloads need to be re-engineered to somehow re-enable sock_raw.. perhaps by dragging along libpcap or something.
When any of the UNIX's mentioned have over 200 million machines connected to the internet, _and_ some sizeable percentage of those are participating in botnets as 0wned machines, we'll see what the UNIX vendors do.
You're right - the best answer is to make windows impervious to being remotely 0wned. That is being worked on. Another good idea would be to keep home users from running as admin. That is being worked on as well.
Until Windows reaches the happy panacea of no security problems, measures that raise the bar but cant eliminate the problem will need to be deployed to help curb widely exploited issues.
This _does_ benefit the average user, infact, it benefits everyone except people wanting to run raw packet construction tools on the windows platform, who now have to install libpcap or something.
The reality of the situation is that botnets make use of SOCK_RAW (or whatever it is in winsock) to spoof source addresses and all kinds of other stuff. Botnet drones are normal people's windows machines. The "normal" customer will never have a legitimate use for raw sockets, but if they get an RK or some other malware on their machine that wants to enlist in a botnet or be used for remote scanning, now those attacks are more difficult, becuse the malware payload now also has to get libpcap installed.
the point here is to raise the bar for what malware has to do to turn a given windows machine into an effective botnet/ddos client member.
Note that the raw socket support _is_ in the server skus. Fyodor and others assert that its because microsoft wants to bilk money out of people. (which is a pretty lame scheme since you'd just install libpcacp to run any good capture tool _anyway_, and you can do that on xp without trouble). The difference is that the majority of botnet members out there aren't server 2003 boxes - they're XP Home.
fwiw, the issue of pulling raw sockets out of the home user sku's has been violently debated internally at MS. It does not _fix_ the issue of machines sending spoofed packets, since if you've got admin rights on the box it's yours. However, it makes it _harder_. We're at the point with Windows XP that we're willing to consider low-hanging fruit that raise the bar for an attack to be successful even if they dont completely eliminate it. With basically all home users running as admin, "fixing it right" isn't possible with the 200+ million machines _already out there_.
We've got enough problems that a multi-pronged approach is the only thing feasible. Yes, we've got people working on making people run as non-admin. That was one of the original goals in Windows XP and it wasn't until reasonably late in the cycle that the call was made that the non-admin story just wasn't there yet for the home user scenarios (too many appcompat problems).
Until the run-as-non-admin story gets worked out, we're in a situation where we have to deploy fixes that are still defeatable, but address the currently existing problem and make future attacks of the same type more difficult to pull off, even though we cant make them impossible.
Microsoft isn't acting unilaterally to screw customers on this issue. As pointed out elsewhere, Gibson and others have been slamming us for a long time for leaving raw sockets turned on. Opinions are divided on the outside just like they are on the inside. Ultimately, i think we've made the right choice. The people that actually want to run nmap or other tools will be smart enough to figure out how to get them working and get the burden of work. The people that aren't smart enough to keep their machines from turning into zombies don't have to do anything - they get a better experience with no effort.... And the entire internet is better off if we can keep more machines from becoming zombies.
i do a lot of code reviews at work and nothing makes me happier than good comments.
but just putting a bunch of blocks of comments that are like "get customer", "build record", etc are basically useless. If you use programming by intent then its more or less obvious that the code
GetCustomerFromDatabase(foo)
is going to do something with a database and get a customer. a comment telling me that is useless.
what i like to do is write a few paragraphs of text at the top of a function. it explains my general approach, why im doing certain things the way i am, why im not doing other things, and why the function even exists.
essentially the comments should be enough that anyone that knew the problem space ought to be able to read them and come up with more or less a similar implementation.
then, in the body of the method anytime i do something that i feel isn't completely obvious, i put a 1 or 2 liner infront of, i.e. "we have to do this because zergs are sensitive"
the end result of all of this is that code reviews can see what you were thinking at the time the code was written.. and you're documenting assumptions about the problem, the apis, your understanding of the language, etc, all right in the code. it makes finding errors pretty easy.. someone that can't even read source code can read the comments and get an idea of the correctness of your approach.
I watched the 1hr45min keynote from WinHec that included a number of longhorn demos. I haven't personally been playing with LH builds so seeing the stuff demoed was new to me. I thought it was nice. The desktop search capabilities that will be in LH client inspite of not having a real WinFS underneath are surprising.
I'm not interested in getting in a comparative argument with some other eye-candy oeprating system that apparently ships this month; i'm only speaking about longhorn in terms of what i saw demoed and comparing it to what windows xp does today.
One interesting thing i noticed is that i thought some of the demos would be a bit.. "cooler". The underlying possibilities with the new frameworks that are going in should really have some growing room in them that the demos really didn't convey.. or so i'd think.
The Metro format was a surprise to me as well. I'd be curious to see some sort of technical analysis of it. Note also that from a cursory glance it seems like a royalty free format that wouldn't necessarily shut out F/OSS implementations.
there are mechanisms now for getting bugs back to MS - the "upload dump" stuff from more or less all of our apps actually goes somewhere. real people look at it, investigate the crashes, etc.
Also, w.r.t. MS not releasing source - you can install the Windows Debugging tools and get the symbols for windows. you can run whatever copy of windows you have now under a kernel debugger and single step through instructions. You dont see source code, but you see fully decorated information in stack frames, etc. It's enough to get a pretty good idea of where a problem is, even though there's no source code available. Case in point - i've found debugging the windows kernel with only symbols to be easier than trying to debug the linux kernel even though full source is available. My unix kernel debugging is more about dropping printk()'s or wahtever in places i think the bug is and then converging on it with recompile/reruns. The windows kernel debugger(s) are actually pretty slick comparatively.
In any event, my point wasn't about people not being able to file bugs or nail them down - it's about reliably finding them. Undirected, Ad-Hoc testing just isn't a cost effective approach.
As far as some of the hole poking stuff - unless you can suggest that the behavior has security implications, that's not as valuable. Deleting random files in %system32% and then saying "look, notepad doesn't run! ha ha!" aren't really the kind of bugs that we'd be interested in fixing, because that just isn't a real customer scenario (especially since System File Protection will try and keep you from doing such things). If you go deleting or changing stuff you shouldn't and stuff starts breaking, unless this is a customer scenario, or unless it's easy for an attacker to utilize this to acheive some aim, the response will be akin to a doctor saying "if it hurts, stop doing it!"
I am not a tester in the windows division, but based on what i understand to be accurate, windows appcompat testing is a HUGE time / resource sink.
A good person on this subject is Raymond Chen, a reasonably famous MS blogger. He's written a number of times on all the crap he personally did in Windows 95 to make certain apps run _at all_. Yeah, there was code in Win95 for the sole purpose of letting certain pre-Win95 games run properly - when those games had bugs in them that we couldn't have counted on the develoeprs to fix. We took the hit of fixing our OS to maintain runtime compat with the games, because when the customer sees "crap win95 broke my games" it doesn't matter that the game author had bugs or was using things incorrectly; what they see is that windows 95 broke * for them.
Raymond is a prolific writer. try looking at http://blogs.msdn.com/oldnewthing/
you're right on the money w.r.t. 3rd party stuff being a big source of hangs. Obviously the resilience to 3rd party apps taking down the OS has gotten better with the NT family, but we've got data internally about where the customer-reported crashes come from (i.e. via support and people clicking the "send crash dump to MS" stuff) and by and large it comes from non-WHQL video drivers, anti-virus software, and other installable filesystem peices. Basically, where we've let 3rd parties plug into kernel space (drivers / FS integration points), which is what you'd expect.
I don't see many user space apps taking down the OS these days- do you have any in particular that seem to do it reliably?
Where did you hear or get the impression that that was the MS "approach" to QA ?
I've written test suites for the following Microsoft Products - Visual Basic Compiler, 7.0 - Microsoft Business Framework 1.0 (unreleased)
None of them involved just using the compiler or the business framework over and over in day to day work to find bugs.
We have a variety of test approaches, including a few that _might_ be construed as what you describe - There are a few ways that we get test coverage via product usage
- stress - bug bashes - app weeks
Stress is funnier than it sounds. Did you know we're not allowed to ship windows until the exact build of windows under ship consideration has been running on hundreds (thousands, usually) of machines continuously with no problems while enlisted in a distributed "stress" client... where they're pounded and pounded with automated tests that do things like starve memory whilst performing other work, etc? Same with ASP.NET and the CLR - they have to _survive_ for a pre-determined time period before the build can be considered shippable. We dont think there are any show-stopper bugs at this point - but we just want to be reasonably sure. Note that if we find a bug (even an unrelated one, like the documentation has a typo) and take a fix for it, the stress cycle resets because the bits have changed. Better safe than sorry. In the end game of a product release it can literally be the case that taking a bug fix means delaying ship for another week or more.
- bug bashes this is probably most like what you're describing. Everyone on the team sits down for a couple of days and really just beats on a specific area of the product. Security Bug Bashes have become popular int he last couple years (wonder why;) These really dont happen that often during the product cycle, because ad-hoc testing doesn't catch that much stuff if you've got well developed automation suites. However, it's still very worthwhile because it is a good feedback mechanism to explain why your other testing missed something, and it's the best way to notice the odd "that's funny..." sort of issues that are not functinoally incorrect but are still user annoyance type issues.
- app week
For developer tool products (like Microsoft Business Framework) we like to do an app week with each milestone, where everyone on the team builds some sort of end to end application, using as much of the toolchain as possible. This sort of testing really makes the employees better (we're usually pretty compartmentalized on our areas of functionality ownership). It also lets unreleated parties take a look at peices of the product they don't own (so don't have preconceived notinos about). Finally, it lets us simulate the end-to-end customer experience on our product stack. If we can build the sort of apps a customer might build with our tools, then the tools are probably alright. Where we run into problems, we know the tools need help.
bug bashes and app weeeks happen perhaps 1-2 weeks per milestone (which is on the order of 2 months). It is a small part of our testing, time, effort, and results wise. It's still important to do, but it is not the _focus_ of QA at microsoft.
Software testing (usually) isn't monkeys pounding on keyboards until the box BSOD's.
It is difficult to test software without adequately understanding what it is supposed to do. Varying the underlying machine type is almost irrelevant for binary distributed software unless you're testing an operating system kernel or looking for race conditions in software (which is really just a stab in the dark)
How are you going to have 3rd party people debug software they know nothing about?
Where users help find bugs is by using the software. It honestly takes a certain mentality to be an effective software breaker, and it's not very common. It takes something else entirely to be a software tester; you've got to be a good developer (because software testing is about automation these days unless you're insane) but you've got to not get sucked into the developers way of thinking.
I assure you - letting normal users play with software doesn't clean it up. we can show that this is true in the following way:
- more users use Microsoft software for more hours a day than any other software in the world - slashdotters say Microsoft software is the buggest software made
clearly if users using software was sufficient to find all the bugs, MS stuff would be bug free, based on its frequency of use alone. I know this isn't the case, because im a software tester at Microsoft.
(The appropriate response is "well then, stop posting and get back to work; you're clearly not done yet!":)
W.r.t. linux kernel testing: this is something that's always amazed me - linux works surprisingly well for something with so little formal testing. On the other hand, when there are edge case problems my experience has been that nobody is much interested in fixing them. One example i had was at a consulting gig. the client was looking to move his web hosting business onto linux boxes if he could get more sites per box then he could on windows. He had a problem where his linux server would start dying after a few days. I started to look into it and the box would basically panic() in low memory situations. I asked Alan Cox about it (via irc) and the response was "buy more memory". Nice.
Another sore point with me growing up was xserver crashes. The Xserver was 99% reliable, but then you'd get some random crash and lose everything you were doing, and you knew there was no real way of getting it fixed or investigating it.. you just had to hope it magically got better somehow.. maybe when you switched hardware or something.
Then there's the just plain lack of testing of some F/OSS projects in general. When i was in college i had NeXT, Sun, and SGI boxes in my dorm room (but no linux:). I remember dling the Gaim tarball (this was loooong ago) and seeing about getting it built on my SGI machine. IIRC, there were some makefile / #include problems getting it to even build, and once it was built there were some other issues with its runtime. Ultimately i submitted a patch to the gaim folks that more or less "enabled" gaim on IRIX. There is no way anybody had ever used Gaim on an SGI without making these fixes, so it seems reasonable to suggest the authors had never tried it before. This lack of a platform test matrix is pretty common amongst smaller F/OSS apps, even when they say "works on *nix" they mean "works on the distribution of linux i run at home".
Another baby patch i submitted was for the openBSD kernel.. this time for the wdc driver. Back when UDMA 100 was newish, i bought 2 UDMA 100 disks a month or so apart.. so they were different sizes and different vendors, but on the same bus. The UDMA rollback code in openBSD would drop the DMA level from 5 (UDMA100) to 2 (something much slower, i dont remember what) after a certain number of DMA errors. This obviously sucked since you can run UDMA devices at different speeds on the same bus, and you can also fallback to UDMA66 and UDMA33, both of which are better than mode 2.
Shiping the wrong thing is worse than not shipping anything.
Everything we ship has to live for at least n years, where n changes depending on what it is. We have to patch it, we have to run regressions against it _forever_. When we come up with something else better, we have to convince developers why this is bad and why they should switch. We never, ever get to remove it without upsetting everyone.
Just throwing out something that kind of solves a few Photos/PIM scenarios means we're introducing new concepts and APIs that we cant unload.. even though we want it to do more and to do it better.
My team for instance is way far out from shipping its product. We've been letting key customers work with our unreleased internal milestone bits. Parts of it are utterly broken. It doesn't do anywhere near what it needs to do. We're just getting feedback to make sure we're on the right track and to get people thinking about what's coming and how it may help what they're trying to acheive.
Even so, the overwhelming feeedback is "just give it to us now". I suppose we could, but it'd be unfinished crap (even more so than some other things we _did_ release;) and we'd be adding support baggage. And for what?
As someone on a team who has no idea when their work will see the light of day - i am at least as frustrated as you are about MS stuff not shipping.
But ultimately, it comes down to shipping the right thing even if it takes longer. The risk you take is that you miss your opportunity - it's obviously a tradeoff. I cannot make those sorts of "soft" decisions, and especially not about the WinFS project as a whole. Guys down in the trenches (even very smart NT kernel guys) don't always see the picture the same way the people at the top do.. or even as their trenchmates do. I don't have (or need to have) undying faith in the abilities of the management above me, but the arguments i've heard for doing things the way they're being done are generally not objectinable. Again - the course of action is not obvious, so you dont have unilateral approval:)
Incidentally, developers dont like 1 billion APIs per year. They dont like it when we "get something out there" and then abandon it. We've done that in the past and we'll probably do it in the future, but it really sucks and lots of people hate doing it, up and down the chain.
As an aside, one appealing thing about.NET is we can start to leave Win32 behind. Surely you dont want us to release CreateFile only to later come up with CreateFileEx a while later.. or Foo() followed by Foo2() and Foo3()...this is the kind of crap that happened with Win32 as it evolved.
Normally I'd figure we'd get a warmer response for trying to do the right thing in the first version:)
where do you figure that i dont know what spotlight is? I'm certainly not an expert on the matter, but that's more due to lack of interest as opposed to not being allowed to read public documents.
So far you've assumed things about who i am, what i know, what microsoft is doing, what WinFS is, what the rules regarding my employment are, and again what i know.
Based on what you've written publicly, on all accounts you've been incorrect.
I appreciate it when people tell me what microsoft needs to do better. It's always so obvious to everyone but us, it seems:)
Let me explain: if it were _that_ obvious, we'd be doing it that way. Perhaps there's some factor (even a few factors!) you're not aware of, not considering, or not weighing the same way that the people that run MS are.
My standard advice when people have an axe to pick with microsoft, and a know it all attitude: if you can fix our problems to the satisfaction of the relevant parties: you're hired. Name your salary and nobody will blink about writing you the check. Do you beleive that MS is an organization of tens of thousands of highly paid, highly stupid people? If so, we'd love to have the help of an expert.
In any case, your criticisms about project scope are not news to anybody. The things you suggest are all good ideas, and MS certainly could be better at all of them.
Sometimes scope creep is acceptable, because with commercial software the key point is to deliver the right product at the right time. Staying in requirements deadlock before a line of code is ever written has a few drawbacks in light of the following realities:
1) the problem changes 2) the requirements change (this is inevitable, because you're smarter tomorrow then you are today) 3) the marketplace changes 4) your dependanices change [you cant begin to imagine what a problem this is at MS:/]
As far as what you've seen: we've already been over this. You don't know everything about WinFS or its future, so claims of what competing technologies might be able to do the same work are kind of meaningless. Essentially i've told you that i know some people who are making a car, and you've told me that yours is just as fast. What an assinine remark!
On a simplistic level, you're fundamentally correct - WinFS is not making light exceed c, nor is it making zero-resistivity p/n junctions. It's not doing anything revolutionary from a technology perspective.
Unfortuneately, even the non-revoultionary software doesn't yet write itself. And no matter how good the developers and testers are, when somebody up high says "this is good, but its not done" that means there's more work to do.
Getting WinFS right the first time matters, because it's got its fingers in more pies than Google Search or even *gasp* Spotlight.
well since i work for Microsoft its hard not to sound that way at times, but i do make an attempt:)
The lack of specific information was intentional on my part - i've read documents and seen presentations that presumably you don't have access to, and i'm basing my comments on knowledge i have which you presumably do not, and which i am not at liberty to share with people not under NDA.
The product team i work on has a huge interest in WinFS and it's been a pain point for us to try and nail down exactly what WinFS will do when, as its _architecturally_ relevant for us. i can assure you that we're not looking to WinFS to index documents. Speculate to your hearts content.
The point was - people making the WinFS+Spotlight comparisons don't have a full understanding of what WinFS is trying to accomplish. I'm not blaming them for that because MS isn't necessarily being clear about what will be delivered when. I'm just letting you know that there's more to the entire WinFS picture than desktop text indexing.
WinFS was originally going to be like, the next version of "Organize your Photos Wizard". It grew into something so scope-out-of-control that it had to be cut from LH client (at least, the full WinFS vision). The ship vehicle seems to change daily.
That said, what WinFS is trying to tackle currently is considerably more ambitious than what Spotlight, MSN Desktop, or Google Desktop Search do. The "someday" WinFS is not a background process that indexes text documents. Not even close. What Apple is delivering is a "search thing". That is _one application_ of WinFS, but by no means the point of doing it.
The comparison of Spotlight to WinFS indicates (understandable) misconceptinos about what WinFS does. That's reasonable since the WinFS story isn't universally clear within MS, much less outside it:)
Oh - about NTFS fragmentation. I've been trying to fight this good fight internally for a couple weeks (it was bugging me). The NTFS people claim that defragmentation on NTFS isn't strictly necessary, but it can make certain disks MUCH better and makes most disks "somewhat" better. There are some people on the NTFS team that would be happy to tell customers not to bother with defragmenters but old habits die hard. In any case, i presented the case for ffs cylinder groups and made sure the NTFS developers i talked to understood it. It's not news to them, and they dont feel there is a significant difference in the observed fragmentation levels in normal NTFS volumes and normal ffs volumes.
Personally, i never run a defragger on my NTFS volumes so in that sense, its no different than ffs derivatives (i dont worry about fragmentation)
In any case, there is no current WinFS plan in which NTFS goes away - WinFS's filesystem component attacks a different problem space than NTFS, and WinFS (currently, and, afaik) needs NTFS under it anyhow.
Re: Indexing a 4GB Movie - you might be surprised what WinFS does when it finally gets all the way cooked. Whenever that is:/
they're selling starter edition at a huge loss in one market that they otherwise wouldn't be able to sell in at all, apart from that activity being subsidized by other markets.
the slashdot socialists should like it, fundamentally. those that can afford to, pay more, which lets MS offer software to those that cant afford it at a loss.
i could make the argument that for the average computer user, XP starter is a heck of a lot better than any linux distro, and if XPS is something MS is taking a loss on, it's down right charitable of them to try and target lower income situations (and making the higher income portions of the market place pay for it)
naturally i'm just a bit too cynical to buy that completely, but it probably bears consideration. set aside any fanboy hatred of MS for a moment, and consider what will get people in developing countries on the computer/internet wave with the least effort... XP starter edition, or gentoo ?
sony invented and cornered with the playstation 1.
i loved FF7 as a game. imagine my horror when i realized that _those_ people played it also.
everybody in this generation grew up with video game machines at home. The PS1 came out right about the time that the 8 bit generation was going off to college.
consoles are no longer the domain of the nerdy game wizard at home. they're mainstream.
Microsoft is going after sony where sony already is. MS didn't invent the concept of the video-game-experience-for-mouth-breathers,but seeing how affluent and indiscrete mouth breathers are, they sure want a peice of the action.
i'm a red state resident (and by intention) and i voted to the right of the current administration (by european standards)
i just spent a month in germany and iceland, including 2 weeks of schooling in the german language.
I for the life of me cannot understand where the radical left, and those who foam at the mouth with their hatred of the US / the current admnistration come from.. i've yet to hear of a perfect politician but man, i just dont get the fuss. With this in mind, i figured i'd hear it from the horses mouth and come back to the states with some kind of new perspective on life.
Instead what i learned is that at least from the people i spoke with, the violently anti-US and anti-bush fever is fed and spun basically everywhere, and its almost more of a beleif/perspective than anything objective.
After being badgered about it for a while, I tried asking some relatives in iceland why they felt the need to tell me that they hated GWB (i never brought up poltiics, but plenty of people, upon finding i was american, told me they hated Bush, are hoping hillary clinton wins in 08, and that the US government sucks.. all totaly out of context of whatever the conversation was)
What i got was: europeans generally dislike bush for 3 reasons
1) iraq invasion 2) "he's too right wing" 3) "he's too religious"
skipping point 1, i asked about the other two.
regarding point #2, i asked if being "right wing" was intrinsically bad. it apparently isn't. then i pointed out that, compared to europe, the US _is_ right wing, and furthermore, the US was founded by people that either couldn't stand, couldn't survive, or couldn't legally continue to, put up with the bullshit of the governments of europe, so if we dont have the same exact world view, there's a reason for that. I also assured him that some in the US are vastly more "right wing" than GWB, who has really let down some of the red state voters on some issues..
on point 3, well, i asked what the objection was. apparently the president should never use "God" in a speech. Nevermind that our money has "In god we trust" written on it. Nevermind also that in Iceland, the president's house has its own private church on the grounds, and the president is expected to enter that building to pray for the country in times of danger. Or that in Germany, you've got the Christian Democratic party with a huge percentage of power. Yet the US/GWB is seen as beeing "too religious". Riiiiiiight.
I also had a very interesting discussion on the iraq war issue with them, and i wouldn't say that they had a compelling argument, although thats too much flamebait even for slashdot:)
In any case, I really liked some of the things big government and overregulation gets you (like the munich public transit system, and unrestricted autobahns... only possible with the ridiculous TUV and licensing process in germany).. but after talking with people and finding a lot more heat than light, i was glad to be returning to the US. My wife is exicted about purchasing our first family firearm, since the students we met from dublin told us over and over that they were mortified that someone in the US could have a gun in their home, and that such a person would be insane, and that they'd never even enter a _building_ with resident-owned firearms inside.. fearing for their safety.
Finally, i told the people that were frothy at the mouth about how awful the US government was, that, unlike their countries, if they disliked how the US did things, they could move here, learn english (which most europeans under the age of 40 know quite well anyhow), pay their $75 or whatever it is, vote, and do something to change it.
In any case, I look forward to going back to Germany as often as possible, if for no other reason than the Nurburgring and the unrestricted zones, but one reason i suspect i'll never live there is that getting residency/citizenship in germany is a he
you'll find VW's new phaeton factory, which is a work of art in and of itself. They've also made good progress on restoring the bombed out buildings/churches in the altstadt.
I have pictures of Caterpillar machines moving dirt infront of a gorgeous church in the heart of Leipzig. Mercedes-Benz owns Caterpillar; it's an interesting justaxposition (sp?) to see american built and servied construction equipment owned by a west german company rebuilding ruins of east german buildings destroyed by american weapons, all being financed by a unified european currency.
The staggering thing to me was how basically anything pretty in germany has been bombed and rebuilt twice. We saw the worlds largest mechanical pipe organ, one that JS Bach personally played and evaluated for the city of Lubeck... and a few 1000 year old churches, and the Koln Dom is too staggering for words or pictures to describe...
The amazing beauty and uniqueness of these places makes it even more shameful that they weren't even touched during the soviet years.. and that the german politicians and people could fathom engaging in a second world war after the damage of the first...
For all of the complaining europeans do about the US government and the US military.. its hard to stay quiet and not remind them that the US bailed europe out of two world wars of its own making.. and that both times we were attacked inspite of our more or less isolationist policies..... and when you see what war ravaged europe still looks like after 60 years.. i find it hard to argue with taking prevenative and pre-emptive measures to keep conflicts away from US soil as much as possible...
I however find it hard to fault the US for requiring documents that everyone else requires for entrance into their nations.
If requiring a passport for entrance in the US is inconvenient because its hard for some people to get passports from their current governments, is it fair to lay all of the blame on the US?
Slashdot Mirror
that's pretty much spot-on.
You can also get replacement mirrors that have wide-angle views and race cars based on production chassis often have multi-element rear view mirrors that let them see everything by only looking in one spot.
The point being, you have no business looking over your shoulder in daily driving.
Here's a fun experiment for #8.
.5s ? 2 seconds ?
Look over your shoulder for as long as it takes you to determine it's safe to make a lane change. Count how long that was. 1 second ?
Remember that value.
Now, driving along in traffic with a speed and following distance you'd normally have, close your eyes for that amount of time.
Can you? Does it feel safe? Why not?
If you need to look over your shoulder, your mirrors are not properly adjusted. I have most of my cars with the mirrors set to just the maximum of their adjustable range, but the upside is that i am not looking over my shoulder.
Most people adjust their mirrors so they have a beautiful view of the side of their car. While your car is very pretty, there's no reason to be looking at it while you drive - you'll know if it falls off or disappears, even without the help of your mirror. So, you can liberate those side mirrors towards something more useful, like having them pointed all the way out so that you can see into the "blind spot" and the other lane.
On all the cars i drive the mirrors are adjusted so that i can see a person either via mirrors, peripheral vision, or line of sight at all times in a circle around me.
Incidentally, you dont see race car drivers looking over their shoulders - they cant, since they're in a harness and wearing a helmet that cuts side visbility. The magic is in the mirrors.
The best thing you can do to not get into accidents is take a proper driving school, where you learn about mirror adjustment, vehicle dynamics, threshhold braking, looking through and ahead of objects properly, and how to relax and concentrate on your driving.
You also forget to mention that your accelerator is also a good accident avoidance tool. In non-optimal road surface conditions (rain, ice, gravel), acceleration is the _least_ decreased of your tires capabilities, with steering being the most. If i was in a traction limited scenario and had to do an evasive manuever that would challenge the level of grip available, i might opt to accelerate as the tires would deliver acceleratino better than braking or steering.
there's nothing to suggest that Linus et al would be able to improve the security of windows while ensuring that it meets its requirements. Linus has enough problem with is own operating system (but can conveniently choose to say all of userland isn't his fault when thats where the vulns are)
In any case, it's funny that you chose linux - arguably the least secure of the modern unixes. I'd have entertained a suggestion of Theo, but he'd fail because im sure his approach would be "the requirements don't matter, this is how i think it should be done", and then half of the crap customers expect would be broken.
I'm not sure how you read my statement about raw socket support being a bad thing for home users, but the point i was making is that they're not using it, so it doesn't help them, and because of the other factors i outlined, it makes thier machines more attractive and more potent for botnet membership.
If its not helping them, and its a risk, then removing it is a good thing, right ?
I don't understand some of your accusations as "bullshit". Are you telling me i'm lying to you? Do you have informatoin that I don't?
I remember the announcement internally that XP home would run with users= admin and being irate about it. Lot's of us were hoping that we'd get it right for xp but the people upstairs couldn't stomach the amount of appcompat breakage it would cause. As it is the amount of custom code in the various versions of windows for 3rd party app support is pretty outlandish. Read raymond chen's blog for a glmipse of what he was doing back in the windows 95 days to help appcompat. Things like this matter when you have 1) an installed base 2) a bunch of 3rd parties making money off your platform 3) binary compat as a requirement. Note that linux has none of these 3 aggrivating factors to deal with. (not anywhere within an order of magnitude of where MS is, at least)
For what it's worth, I agree that our testing, design, and management are all inadequate. We're just human. As an aside, we're hiring. Are you qualified to help, or just to bitch?
Most of what people do in "IT" doesn't require a college degree at all, but real world experience and specialization.
I'd consider being a Solaris admin, a CCIE, or even a helpdesk person an IT job. Obviously at vastly different expertise and salary levels.
But fundamentally, university schooling won't help you with any of them. To be a good UNIX admin you just have to do it. I can't say what's required to be a CCIE as i am not one nor have i been one. To do helpdesk work you must be a computer junkie that hasn't yet been promoted to more challenging work.
These are all different things than what you'll get from a computer science program. Computer science is the study of using computers to solve problems. Many people think this means "programming". It doesn't, and plenty of computer science graduates cant design software or program to save their lives.
If you want a job writing, designing, or testing software, look for a degree in Software Engineering. Real engineers snicker at the notion of "software engineering" since software is an immature art that is fumbling towards legitimacy, but there are almost no professional engineer type exams for software people and no real concept of liability or regulation of those practicing software engineering.
The last thing you've talked about is hardware.
This again depends on what you want to do. A friend of mine in college majored in Computer Engineering; I majored in Computer Science. I work at Microsoft on software, he works at Intel on the cache system for the Itanium series (or he did last we spoke)
The goal of that program was to turn out people that were competant to work on microprocessor as well as system design, i.e. a senior project might have been to build a PCI card that did foo. That involved knowing the circuits, knowing the pre-made parts to use, routing, and most of all, coding the processors involved. Modern hardware is not a separate entity from software - and the hardware is often generated from code.
Repairing stereos is also "hardware", but not something you go to college for.
You should decide what kind of career you want, and what you want to learn about while you're at college. The kind of career you want will partially dicate what peice of paper you leave college with (perhaps).
IT is a crap shoot. Someday, servers and routers will fix themselves, and the guild of machine babysitters that we have today will be looking for work. I wouldn't count on a career in system administration.
Software and hardware will eventually get good enough that electricians are setting up data centers.
Have you seen what kind of money electricians make, by the way?
Sure. Average home users do nothing but write their own protocols using raw sockets.
If i suggested or said that nobody has a use for raw sockets, i misspoke or you misunderstood. The _average_ user only suffers from raw socket support, because it makes thier machine a more desirable target for 0wnage.
for the people that legimately need raw sockets, they're smart enough to figure out how to get them.
"we don't want to admit we were wrong because then those 200 million people would know what really crappy software we sell". If Microsoft made a mistake then fix it.
Well, pick your argument. Should raw sockets be in or out? Was it a mistake to ship it with them in or not?
Our "mistake" was shipping an operating system that suffered from remote root exploits. This mistake, compounded with the need to keep home users running as admin, and also with us shipping a fully functional TCP/IP stack, allows for an unpatched xp machine to easily be turned into a botnet member. That was a big problem for us, our customers, and the internet at large. We can't ship an operating system that does what it needs to do yet has _zero_ security bugs ever discovered over its lifecycle. We don't know how. If you do, or you know somebody that does, we'll hire them. For whatever money they want.
One of the core tenets of security is defense in depth. We know that eventually someone will break into a windows machine. When they get there, we want it to be harder for them to turn it into a botnet drone/zombie. In the future we'll hopefully get away from running-as-admin which will further raise the bar.
Put some of that ill gotten gain to use and fix the problem the "Right Way"
I said we were working on doing just that, and that running as non-admin almost made it into WinXP. Unfortuneately, all those people out there with badly written software (some of it by us, probably) running on windows expect it to still work. We couldn't get everything sorted out in the Windows XP time frame. It's been a source of non-stop work and the story for longhorn will be better but i dont know to what degree (i.e. it may not be all the way fixed).
A kernel that can be patched and have its own hooks intercepted by malicious software is the problem.
Show me a kernel in use on home computers that doesn't suffer from this.
Which department are you in, Public Relations or Marketing?
Testing, actually :) As many defects as you find in MS software, beleive me, there are plenty that never make it to you.
malware has traditionally attacked whatever had a large installed base and provided some benefit to the attacker.
long before the internet was dominated by windows machines on residential broadband, there were still hacks and 0wned machines.
Surely you're familiar with the Morris worm. There were no windows payloads or transmission vectors. It still, as they say, "got around".
The last time UNIX derivatives made up the majority of internet connected hosts, unix machines were the ones getting remotely 0wned.
If unix derivatives someday make up the majority of internet connected hosts in the future, why do you assume that this wont be the case again?
this was done for one reason only:
to make it harder for 0wned PC's to effectively mount DDoS / scanning attacks against the inernet.
You cannot argue that this does not make it more difficult - at a minimum existing payloads need to be re-engineered to somehow re-enable sock_raw.. perhaps by dragging along libpcap or something.
When any of the UNIX's mentioned have over 200 million machines connected to the internet, _and_ some sizeable percentage of those are participating in botnets as 0wned machines, we'll see what the UNIX vendors do.
You're right - the best answer is to make windows impervious to being remotely 0wned. That is being worked on. Another good idea would be to keep home users from running as admin. That is being worked on as well.
Until Windows reaches the happy panacea of no security problems, measures that raise the bar but cant eliminate the problem will need to be deployed to help curb widely exploited issues.
That's what's going on here.
This _does_ benefit the average user, infact, it benefits everyone except people wanting to run raw packet construction tools on the windows platform, who now have to install libpcap or something.
The reality of the situation is that botnets make use of SOCK_RAW (or whatever it is in winsock) to spoof source addresses and all kinds of other stuff. Botnet drones are normal people's windows machines. The "normal" customer will never have a legitimate use for raw sockets, but if they get an RK or some other malware on their machine that wants to enlist in a botnet or be used for remote scanning, now those attacks are more difficult, becuse the malware payload now also has to get libpcap installed.
the point here is to raise the bar for what malware has to do to turn a given windows machine into an effective botnet/ddos client member.
Note that the raw socket support _is_ in the server skus. Fyodor and others assert that its because microsoft wants to bilk money out of people. (which is a pretty lame scheme since you'd just install libpcacp to run any good capture tool _anyway_, and you can do that on xp without trouble). The difference is that the majority of botnet members out there aren't server 2003 boxes - they're XP Home.
fwiw, the issue of pulling raw sockets out of the home user sku's has been violently debated internally at MS. It does not _fix_ the issue of machines sending spoofed packets, since if you've got admin rights on the box it's yours. However, it makes it _harder_. We're at the point with Windows XP that we're willing to consider low-hanging fruit that raise the bar for an attack to be successful even if they dont completely eliminate it. With basically all home users running as admin, "fixing it right" isn't possible with the 200+ million machines _already out there_.
We've got enough problems that a multi-pronged approach is the only thing feasible. Yes, we've got people working on making people run as non-admin. That was one of the original goals in Windows XP and it wasn't until reasonably late in the cycle that the call was made that the non-admin story just wasn't there yet for the home user scenarios (too many appcompat problems).
Until the run-as-non-admin story gets worked out, we're in a situation where we have to deploy fixes that are still defeatable, but address the currently existing problem and make future attacks of the same type more difficult to pull off, even though we cant make them impossible.
Microsoft isn't acting unilaterally to screw customers on this issue. As pointed out elsewhere, Gibson and others have been slamming us for a long time for leaving raw sockets turned on. Opinions are divided on the outside just like they are on the inside. Ultimately, i think we've made the right choice. The people that actually want to run nmap or other tools will be smart enough to figure out how to get them working and get the burden of work. The people that aren't smart enough to keep their machines from turning into zombies don't have to do anything - they get a better experience with no effort.... And the entire internet is better off if we can keep more machines from becoming zombies.
i do a lot of code reviews at work and nothing makes me happier than good comments.
but just putting a bunch of blocks of comments that are like "get customer", "build record", etc are basically useless. If you use programming by intent then its more or less obvious that the code
GetCustomerFromDatabase(foo)
is going to do something with a database and get a customer. a comment telling me that is useless.
what i like to do is write a few paragraphs of text at the top of a function. it explains my general approach, why im doing certain things the way i am, why im not doing other things, and why the function even exists.
essentially the comments should be enough that anyone that knew the problem space ought to be able to read them and come up with more or less a similar implementation.
then, in the body of the method anytime i do something that i feel isn't completely obvious, i put a 1 or 2 liner infront of, i.e. "we have to do this because zergs are sensitive"
the end result of all of this is that code reviews can see what you were thinking at the time the code was written.. and you're documenting assumptions about the problem, the apis, your understanding of the language, etc, all right in the code. it makes finding errors pretty easy.. someone that can't even read source code can read the comments and get an idea of the correctness of your approach.
http://www.microsoft.com/events/executives/billgat es.mspx
I watched the 1hr45min keynote from WinHec that included a number of longhorn demos. I haven't personally been playing with LH builds so seeing the stuff demoed was new to me. I thought it was nice. The desktop search capabilities that will be in LH client inspite of not having a real WinFS underneath are surprising.
I'm not interested in getting in a comparative argument with some other eye-candy oeprating system that apparently ships this month; i'm only speaking about longhorn in terms of what i saw demoed and comparing it to what windows xp does today.
One interesting thing i noticed is that i thought some of the demos would be a bit.. "cooler". The underlying possibilities with the new frameworks that are going in should really have some growing room in them that the demos really didn't convey.. or so i'd think.
The Metro format was a surprise to me as well. I'd be curious to see some sort of technical analysis of it. Note also that from a cursory glance it seems like a royalty free format that wouldn't necessarily shut out F/OSS implementations.
there are mechanisms now for getting bugs back to MS - the "upload dump" stuff from more or less all of our apps actually goes somewhere. real people look at it, investigate the crashes, etc.
Also, w.r.t. MS not releasing source - you can install the Windows Debugging tools and get the symbols for windows. you can run whatever copy of windows you have now under a kernel debugger and single step through instructions. You dont see source code, but you see fully decorated information in stack frames, etc. It's enough to get a pretty good idea of where a problem is, even though there's no source code available. Case in point - i've found debugging the windows kernel with only symbols to be easier than trying to debug the linux kernel even though full source is available. My unix kernel debugging is more about dropping printk()'s or wahtever in places i think the bug is and then converging on it with recompile/reruns. The windows kernel debugger(s) are actually pretty slick comparatively.
In any event, my point wasn't about people not being able to file bugs or nail them down - it's about reliably finding them. Undirected, Ad-Hoc testing just isn't a cost effective approach.
As far as some of the hole poking stuff - unless you can suggest that the behavior has security implications, that's not as valuable. Deleting random files in %system32% and then saying "look, notepad doesn't run! ha ha!" aren't really the kind of bugs that we'd be interested in fixing, because that just isn't a real customer scenario (especially since System File Protection will try and keep you from doing such things). If you go deleting or changing stuff you shouldn't and stuff starts breaking, unless this is a customer scenario, or unless it's easy for an attacker to utilize this to acheive some aim, the response will be akin to a doctor saying "if it hurts, stop doing it!"
I am not a tester in the windows division, but based on what i understand to be accurate, windows appcompat testing is a HUGE time / resource sink.
A good person on this subject is Raymond Chen, a reasonably famous MS blogger. He's written a number of times on all the crap he personally did in Windows 95 to make certain apps run _at all_. Yeah, there was code in Win95 for the sole purpose of letting certain pre-Win95 games run properly - when those games had bugs in them that we couldn't have counted on the develoeprs to fix. We took the hit of fixing our OS to maintain runtime compat with the games, because when the customer sees "crap win95 broke my games" it doesn't matter that the game author had bugs or was using things incorrectly; what they see is that windows 95 broke * for them.
Raymond is a prolific writer. try looking at http://blogs.msdn.com/oldnewthing/
you're right on the money w.r.t. 3rd party stuff being a big source of hangs. Obviously the resilience to 3rd party apps taking down the OS has gotten better with the NT family, but we've got data internally about where the customer-reported crashes come from (i.e. via support and people clicking the "send crash dump to MS" stuff) and by and large it comes from non-WHQL video drivers, anti-virus software, and other installable filesystem peices. Basically, where we've let 3rd parties plug into kernel space (drivers / FS integration points), which is what you'd expect.
I don't see many user space apps taking down the OS these days- do you have any in particular that seem to do it reliably?
that is NOT Microsoft's approach to testing.
;) These really dont happen that often during the product cycle, because ad-hoc testing doesn't catch that much stuff if you've got well developed automation suites. However, it's still very worthwhile because it is a good feedback mechanism to explain why your other testing missed something, and it's the best way to notice the odd "that's funny..." sort of issues that are not functinoally incorrect but are still user annoyance type issues.
Where did you hear or get the impression that that was the MS "approach" to QA ?
I've written test suites for the following Microsoft Products
- Visual Basic Compiler, 7.0
- Microsoft Business Framework 1.0 (unreleased)
None of them involved just using the compiler or the business framework over and over in day to day work to find bugs.
We have a variety of test approaches, including a few that _might_ be construed as what you describe - There are a few ways that we get test coverage via product usage
- stress
- bug bashes
- app weeks
Stress is funnier than it sounds. Did you know we're not allowed to ship windows until the exact build of windows under ship consideration has been running on hundreds (thousands, usually) of machines continuously with no problems while enlisted in a distributed "stress" client... where they're pounded and pounded with automated tests that do things like starve memory whilst performing other work, etc? Same with ASP.NET and the CLR - they have to _survive_ for a pre-determined time period before the build can be considered shippable. We dont think there are any show-stopper bugs at this point - but we just want to be reasonably sure. Note that if we find a bug (even an unrelated one, like the documentation has a typo) and take a fix for it, the stress cycle resets because the bits have changed. Better safe than sorry. In the end game of a product release it can literally be the case that taking a bug fix means delaying ship for another week or more.
- bug bashes
this is probably most like what you're describing. Everyone on the team sits down for a couple of days and really just beats on a specific area of the product. Security Bug Bashes have become popular int he last couple years (wonder why
- app week
For developer tool products (like Microsoft Business Framework) we like to do an app week with each milestone, where everyone on the team builds some sort of end to end application, using as much of the toolchain as possible. This sort of testing really makes the employees better (we're usually pretty compartmentalized on our areas of functionality ownership). It also lets unreleated parties take a look at peices of the product they don't own (so don't have preconceived notinos about). Finally, it lets us simulate the end-to-end customer experience on our product stack. If we can build the sort of apps a customer might build with our tools, then the tools are probably alright. Where we run into problems, we know the tools need help.
bug bashes and app weeeks happen perhaps 1-2 weeks per milestone (which is on the order of 2 months). It is a small part of our testing, time, effort, and results wise. It's still important to do, but it is not the _focus_ of QA at microsoft.
Software testing (usually) isn't monkeys pounding on keyboards until the box BSOD's.
:)
:). I remember dling the Gaim tarball (this was loooong ago) and seeing about getting it built on my SGI machine. IIRC, there were some makefile / #include problems getting it to even build, and once it was built there were some other issues with its runtime. Ultimately i submitted a patch to the gaim folks that more or less "enabled" gaim on IRIX. There is no way anybody had ever used Gaim on an SGI without making these fixes, so it seems reasonable to suggest the authors had never tried it before. This lack of a platform test matrix is pretty common amongst smaller F/OSS apps, even when they say "works on *nix" they mean "works on the distribution of linux i run at home".
It is difficult to test software without adequately understanding what it is supposed to do. Varying the underlying machine type is almost irrelevant for binary distributed software unless you're testing an operating system kernel or looking for race conditions in software (which is really just a stab in the dark)
How are you going to have 3rd party people debug software they know nothing about?
Where users help find bugs is by using the software. It honestly takes a certain mentality to be an effective software breaker, and it's not very common. It takes something else entirely to be a software tester; you've got to be a good developer (because software testing is about automation these days unless you're insane) but you've got to not get sucked into the developers way of thinking.
I assure you - letting normal users play with software doesn't clean it up. we can show that this is true in the following way:
- more users use Microsoft software for more hours a day than any other software in the world
- slashdotters say Microsoft software is the buggest software made
clearly if users using software was sufficient to find all the bugs, MS stuff would be bug free, based on its frequency of use alone. I know this isn't the case, because im a software tester at Microsoft.
(The appropriate response is "well then, stop posting and get back to work; you're clearly not done yet!"
W.r.t. linux kernel testing: this is something that's always amazed me - linux works surprisingly well for something with so little formal testing. On the other hand, when there are edge case problems my experience has been that nobody is much interested in fixing them. One example i had was at a consulting gig. the client was looking to move his web hosting business onto linux boxes if he could get more sites per box then he could on windows. He had a problem where his linux server would start dying after a few days. I started to look into it and the box would basically panic() in low memory situations. I asked Alan Cox about it (via irc) and the response was "buy more memory". Nice.
Another sore point with me growing up was xserver crashes. The Xserver was 99% reliable, but then you'd get some random crash and lose everything you were doing, and you knew there was no real way of getting it fixed or investigating it.. you just had to hope it magically got better somehow.. maybe when you switched hardware or something.
Then there's the just plain lack of testing of some F/OSS projects in general. When i was in college i had NeXT, Sun, and SGI boxes in my dorm room (but no linux
Another baby patch i submitted was for the openBSD kernel.. this time for the wdc driver. Back when UDMA 100 was newish, i bought 2 UDMA 100 disks a month or so apart.. so they were different sizes and different vendors, but on the same bus. The UDMA rollback code in openBSD would drop the DMA level from 5 (UDMA100) to 2 (something much slower, i dont remember what) after a certain number of DMA errors. This obviously sucked since you can run UDMA devices at different speeds on the same bus, and you can also fallback to UDMA66 and UDMA33, both of which are better than mode 2.
Shiping the wrong thing is worse than not shipping anything.
;) and we'd be adding support baggage. And for what?
:)
.NET is we can start to leave Win32 behind. Surely you dont want us to release CreateFile only to later come up with CreateFileEx a while later.. or Foo() followed by Foo2() and Foo3()...this is the kind of crap that happened with Win32 as it evolved.
:)
Everything we ship has to live for at least n years, where n changes depending on what it is. We have to patch it, we have to run regressions against it _forever_. When we come up with something else better, we have to convince developers why this is bad and why they should switch. We never, ever get to remove it without upsetting everyone.
Just throwing out something that kind of solves a few Photos/PIM scenarios means we're introducing new concepts and APIs that we cant unload.. even though we want it to do more and to do it better.
My team for instance is way far out from shipping its product. We've been letting key customers work with our unreleased internal milestone bits. Parts of it are utterly broken. It doesn't do anywhere near what it needs to do. We're just getting feedback to make sure we're on the right track and to get people thinking about what's coming and how it may help what they're trying to acheive.
Even so, the overwhelming feeedback is "just give it to us now". I suppose we could, but it'd be unfinished crap (even more so than some other things we _did_ release
As someone on a team who has no idea when their work will see the light of day - i am at least as frustrated as you are about MS stuff not shipping.
But ultimately, it comes down to shipping the right thing even if it takes longer. The risk you take is that you miss your opportunity - it's obviously a tradeoff. I cannot make those sorts of "soft" decisions, and especially not about the WinFS project as a whole. Guys down in the trenches (even very smart NT kernel guys) don't always see the picture the same way the people at the top do.. or even as their trenchmates do. I don't have (or need to have) undying faith in the abilities of the management above me, but the arguments i've heard for doing things the way they're being done are generally not objectinable. Again - the course of action is not obvious, so you dont have unilateral approval
Incidentally, developers dont like 1 billion APIs per year. They dont like it when we "get something out there" and then abandon it.
We've done that in the past and we'll probably do it in the future, but it really sucks and lots of people hate doing it, up and down the chain.
As an aside, one appealing thing about
Normally I'd figure we'd get a warmer response for trying to do the right thing in the first version
where do you figure that i dont know what spotlight is? I'm certainly not an expert on the matter, but that's more due to lack of interest as opposed to not being allowed to read public documents.
:)
:/]
So far you've assumed things about who i am, what i know, what microsoft is doing, what WinFS is, what the rules regarding my employment are, and again what i know.
Based on what you've written publicly, on all accounts you've been incorrect.
I appreciate it when people tell me what microsoft needs to do better. It's always so obvious to everyone but us, it seems
Let me explain: if it were _that_ obvious, we'd be doing it that way. Perhaps there's some factor (even a few factors!) you're not aware of, not considering, or not weighing the same way that the people that run MS are.
My standard advice when people have an axe to pick with microsoft, and a know it all attitude: if you can fix our problems to the satisfaction of the relevant parties: you're hired. Name your salary and nobody will blink about writing you the check. Do you beleive that MS is an organization of tens of thousands of highly paid, highly stupid people? If so, we'd love to have the help of an expert.
In any case, your criticisms about project scope are not news to anybody. The things you suggest are all good ideas, and MS certainly could be better at all of them.
Sometimes scope creep is acceptable, because with commercial software the key point is to deliver the right product at the right time. Staying in requirements deadlock before a line of code is ever written has a few drawbacks in light of the following realities:
1) the problem changes
2) the requirements change (this is inevitable, because you're smarter tomorrow then you are today)
3) the marketplace changes
4) your dependanices change [you cant begin to imagine what a problem this is at MS
As far as what you've seen: we've already been over this. You don't know everything about WinFS or its future, so claims of what competing technologies might be able to do the same work are kind of meaningless. Essentially i've told you that i know some people who are making a car, and you've told me that yours is just as fast. What an assinine remark!
On a simplistic level, you're fundamentally correct - WinFS is not making light exceed c, nor is it making zero-resistivity p/n junctions. It's not doing anything revolutionary from a technology perspective.
Unfortuneately, even the non-revoultionary software doesn't yet write itself. And no matter how good the developers and testers are, when somebody up high says "this is good, but its not done" that means there's more work to do.
Getting WinFS right the first time matters, because it's got its fingers in more pies than Google Search or even *gasp* Spotlight.
well since i work for Microsoft its hard not to sound that way at times, but i do make an attempt :)
The lack of specific information was intentional on my part - i've read documents and seen presentations that presumably you don't have access to, and i'm basing my comments on knowledge i have which you presumably do not, and which i am not at liberty to share with people not under NDA.
The product team i work on has a huge interest in WinFS and it's been a pain point for us to try and nail down exactly what WinFS will do when, as its _architecturally_ relevant for us. i can assure you that we're not looking to WinFS to index documents. Speculate to your hearts content.
The point was - people making the WinFS+Spotlight comparisons don't have a full understanding of what WinFS is trying to accomplish. I'm not blaming them for that because MS isn't necessarily being clear about what will be delivered when. I'm just letting you know that there's more to the entire WinFS picture than desktop text indexing.
Much more.
WinFS was originally going to be like, the next version of "Organize your Photos Wizard". It grew into something so scope-out-of-control that it had to be cut from LH client (at least, the full WinFS vision). The ship vehicle seems to change daily.
:)
:/
That said, what WinFS is trying to tackle currently is considerably more ambitious than what Spotlight, MSN Desktop, or Google Desktop Search do. The "someday" WinFS is not a background process that indexes text documents. Not even close. What Apple is delivering is a "search thing". That is _one application_ of WinFS, but by no means the point of doing it.
The comparison of Spotlight to WinFS indicates (understandable) misconceptinos about what WinFS does. That's reasonable since the WinFS story isn't universally clear within MS, much less outside it
Oh - about NTFS fragmentation. I've been trying to fight this good fight internally for a couple weeks (it was bugging me). The NTFS people claim that defragmentation on NTFS isn't strictly necessary, but it can make certain disks MUCH better and makes most disks "somewhat" better. There are some people on the NTFS team that would be happy to tell customers not to bother with defragmenters but old habits die hard. In any case, i presented the case for ffs cylinder groups and made sure the NTFS developers i talked to understood it. It's not news to them, and they dont feel there is a significant difference in the observed fragmentation levels in normal NTFS volumes and normal ffs volumes.
Personally, i never run a defragger on my NTFS volumes so in that sense, its no different than ffs derivatives (i dont worry about fragmentation)
In any case, there is no current WinFS plan in which NTFS goes away - WinFS's filesystem component attacks a different problem space than NTFS, and WinFS (currently, and, afaik) needs NTFS under it anyhow.
Re: Indexing a 4GB Movie - you might be surprised what WinFS does when it finally gets all the way cooked. Whenever that is
they're selling starter edition at a huge loss in one market that they otherwise wouldn't be able to sell in at all, apart from that activity being subsidized by other markets.
the slashdot socialists should like it, fundamentally. those that can afford to, pay more, which lets MS offer software to those that cant afford it at a loss.
i could make the argument that for the average computer user, XP starter is a heck of a lot better than any linux distro, and if XPS is something MS is taking a loss on, it's down right charitable of them to try and target lower income situations (and making the higher income portions of the market place pay for it)
naturally i'm just a bit too cynical to buy that completely, but it probably bears consideration. set aside any fanboy hatred of MS for a moment, and consider what will get people in developing countries on the computer/internet wave with the least effort... XP starter edition, or gentoo ?
sony invented and cornered with the playstation 1.
i loved FF7 as a game. imagine my horror when i realized that _those_ people played it also.
everybody in this generation grew up with video game machines at home. The PS1 came out right about the time that the 8 bit generation was going off to college.
consoles are no longer the domain of the nerdy game wizard at home. they're mainstream.
Microsoft is going after sony where sony already is. MS didn't invent the concept of the video-game-experience-for-mouth-breathers,but seeing how affluent and indiscrete mouth breathers are, they sure want a peice of the action.
thats a funny theory...
:)
i'm a red state resident (and by intention) and i voted to the right of the current administration (by european standards)
i just spent a month in germany and iceland, including 2 weeks of schooling in the german language.
I for the life of me cannot understand where the radical left, and those who foam at the mouth with their hatred of the US / the current admnistration come from.. i've yet to hear of a perfect politician but man, i just dont get the fuss. With this in mind, i figured i'd hear it from the horses mouth and come back to the states with some kind of new perspective on life.
Instead what i learned is that at least from the people i spoke with, the violently anti-US and anti-bush fever is fed and spun basically everywhere, and its almost more of a beleif/perspective than anything objective.
After being badgered about it for a while, I tried asking some relatives in iceland why they felt the need to tell me that they hated GWB (i never brought up poltiics, but plenty of people, upon finding i was american, told me they hated Bush, are hoping hillary clinton wins in 08, and that the US government sucks.. all totaly out of context of whatever the conversation was)
What i got was: europeans generally dislike bush for 3 reasons
1) iraq invasion
2) "he's too right wing"
3) "he's too religious"
skipping point 1, i asked about the other two.
regarding point #2, i asked if being "right wing" was intrinsically bad. it apparently isn't. then i pointed out that, compared to europe, the US _is_ right wing, and furthermore, the US was founded by people that either couldn't stand, couldn't survive, or couldn't legally continue to, put up with the bullshit of the governments of europe, so if we dont have the same exact world view, there's a reason for that. I also assured him that some in the US are vastly more "right wing" than GWB, who has really let down some of the red state voters on some issues..
on point 3, well, i asked what the objection was. apparently the president should never use "God" in a speech. Nevermind that our money has "In god we trust" written on it. Nevermind also that in Iceland, the president's house has its own private church on the grounds, and the president is expected to enter that building to pray for the country in times of danger. Or that in Germany, you've got the Christian Democratic party with a huge percentage of power. Yet the US/GWB is seen as beeing "too religious". Riiiiiiight.
I also had a very interesting discussion on the iraq war issue with them, and i wouldn't say that they had a compelling argument, although thats too much flamebait even for slashdot
In any case, I really liked some of the things big government and overregulation gets you (like the munich public transit system, and unrestricted autobahns... only possible with the ridiculous TUV and licensing process in germany).. but after talking with people and finding a lot more heat than light, i was glad to be returning to the US. My wife is exicted about purchasing our first family firearm, since the students we met from dublin told us over and over that they were mortified that someone in the US could have a gun in their home, and that such a person would be insane, and that they'd never even enter a _building_ with resident-owned firearms inside.. fearing for their safety.
Finally, i told the people that were frothy at the mouth about how awful the US government was, that, unlike their countries, if they disliked how the US did things, they could move here, learn english (which most europeans under the age of 40 know quite well anyhow), pay their $75 or whatever it is, vote, and do something to change it.
In any case, I look forward to going back to Germany as often as possible, if for no other reason than the Nurburgring and the unrestricted zones, but one reason i suspect i'll never live there is that getting residency/citizenship in germany is a he
the lusitania is a minor point in my mind.. the XYZ note being much, much more significant.
you'll find VW's new phaeton factory, which is a work of art in and of itself. They've also made good progress on restoring the bombed out buildings/churches in the altstadt.
..
I have pictures of Caterpillar machines moving dirt infront of a gorgeous church in the heart of Leipzig. Mercedes-Benz owns Caterpillar; it's an interesting justaxposition (sp?) to see american built and servied construction equipment owned by a west german company rebuilding ruins of east german buildings destroyed by american weapons, all being financed by a unified european currency.
The staggering thing to me was how basically anything pretty in germany has been bombed and rebuilt twice. We saw the worlds largest mechanical pipe organ, one that JS Bach personally played and evaluated for the city of Lubeck... and a few 1000 year old churches, and the Koln Dom is too staggering for words or pictures to describe.
The amazing beauty and uniqueness of these places makes it even more shameful that they weren't even touched during the soviet years.. and that the german politicians and people could fathom engaging in a second world war after the damage of the first...
For all of the complaining europeans do about the US government and the US military.. its hard to stay quiet and not remind them that the US bailed europe out of two world wars of its own making.. and that both times we were attacked inspite of our more or less isolationist policies..... and when you see what war ravaged europe still looks like after 60 years.. i find it hard to argue with taking prevenative and pre-emptive measures to keep conflicts away from US soil as much as possible...
I however find it hard to fault the US for requiring documents that everyone else requires for entrance into their nations.
If requiring a passport for entrance in the US is inconvenient because its hard for some people to get passports from their current governments, is it fair to lay all of the blame on the US?