Slashdot Mirror
Why Vista Took So Long
twofish writes, "Following on from Joel Spolsky's blog on the Windows Vista shutdown menu, Moishe Lettvin, a former member of the Windows Vista team (now at Google) who spent a year working on the menu, gives an insight into the process, and some indication as to what the approximately 24 people who worked on the shutdown menu actually did. Joel has responded in typically forthright fashion." From the last posting: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991–2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product."
So, Microsoft has finally adopted the Linux development model?
The owls are not what they seem
Every single organization seems to follow this exact same path. Lean and mean at first, to fast and nimble second, to large but feature, to slow and bloated. The next step after this tends to be, jump at any and all projects to see if anything will stick progressing slowly down a spiral with a large change either acquisition by another company or dramatic slashing of middle-management workers and projects to focus on their core. Unfortunately I have yet to see a large organization that doesn't seem to go down something similar to this path.
Because it had to move through the digestive tract and on through the large intestine.
Doesn't "the approximately 24 people who worked on the shutdown menu" already tell you everything you need to know?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Sleep basically saves the machine state and leaves the RAM powered up... which uses very little energy (but can be important like on a laptop where you don't want to keep your RAM powered if you aren't going to be using your computer for say 12-24 hours...
Hibernate writes the RAM contents to disk, then when it starts back up it writes back from the disk to the RAM, and brings up similar to sleep mode.
Sleep is faster, hibernate takes it down farther and shuts power off completely.
...uninstalled Vista instead? Now that would be a simple way to solve the matter.
People would want Vista if it were revolutionary. But you can't just sit down and say 'let's make something revolutionary' and then set up a timeline and claim to be able to create a revolution within that timeframe. Revolutions happen by accident if at all, not on purpose.
So why hurry? For money? In my experience hurrying to make money never works out.
TLF
I do not respond to cowards. Especially anonymous ones.
Congratulations, you just described the default power functionality in XP.
I've read other blogs in regards to Windows Vista, and from what I am gathering the primary reason why Windows Vista took so long to complete was because of management. Philip Su argued how the gargantuan amount of code included in Vista slowed it development dramatically, however I think that this strengthens my point and the point made in this article.
However, I'm not terribly surprised that this occurred for Vista. The higher execs at the company wanted Vista to be a revolution and had a clear and concise goal that they wanted this operating system to achieve. In order to do this, from what I've read, they needed to form many more separate divisions inside of the Windows division to concentrate on small parts of the operating system. This probably sounded like a good idea, but the problem was that none of their work was in sync with each other. Some had more work completed than others. Furthermore, rifts within divisions such as the one present here spurred disagreement after disagreement, that including the decision to switch the codebase of the OS to the one present in Server 2003 (something that from what I understand should have been decided from the beginning). With all of this, it was only inevitable that confusion and miscommunication would occur.
All in all, while I think Windows Vista is definitely more capable than Windows XP and warrants itself a much needed upgrade, I feel that the actual improvements of the operating system do not warrant a five-year delay. Okay, so the compositing manager, networking stack, and audio stack may have needed some time to complete, but five-years? I am not a programmer, so my impression may not carry a lot of weight, but being that Linux and UNIX based systems have already included some of these "future technologies," it becomes naive to deem this delay as acceptable.
cumputer
I bet I know what you use your PC for.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
1. As a monopoly, they define how much they charge.
/. waiting for next week's meeting?
2. Sales/Marketing's job is to force this product down OEM's throats. Good, bad, whatever, just buy it.
3. There is no accept or reject market mechanism. You WILL be buying Vista if you choose to buy a new PC later. It will be the very rare individual who switches to a mac or just slaps linux on their current box.
4. There is no incentive to establish a more productive developer environment.
Therefore, chaos and mismanagement won't ever harm the beast.
Joel's comments are fun to read, but the scale at which MS develops their OS makes it too easy to criticize from Joel's relatively tiny company.
Finally, How many hours did the developer spend/waste reading
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
To Joe User, they are both the same, so why not just put a little 2 or 4 gig flash drive in the machine, and roll both functions into one? Practically, it would be as fast as sleeping, but would have the complete power down benefits of hibernating.
When our name is on the back of your car, we're behind you all the way!
It's not quite that simple.
When you get beyond a certain stage of complexity, you need to change the mode of operation. You can't just have everyone submitting random changes.
You have a subgroup of people that work with each other. When something is stable, it gets submitted to the integration branch. Periodically the integration branch is tested and verified that all the various things feeding into it interwork with each other. That stable version is then propagated into the other teams for them to work with.
Linux uses a variation of this. People work off the mainline tree. Riskier stuff is in the -mm patchset, so if you want to play with it you need to sync from multiple places.
The real problem with the scenario as described is the repository organization, likely not in the repository tool. There should have been a way to manually make a child stream that started with the stable version, then pulled in the latest changes from the kernel group, the tabletPC group, and the shell team. That would have allowed them to all work together and see what each group was doing.
It runs perfectly fine on my 5 year old...
:P
You run Windows Vista on your kid?! Not even Linux users would do that!
Ok. I've been running vista on one machine or another for a while.. since early beta.. and am now running the release version on my main machine. There are quite a few headscratchers in here. I often tell my colleagues I'm like the little kid from the 6th sense.. except instead of dead people I see bugs. Things that annoy the crap out of me that have been there at least one maybe two versions of windows ago.
In the past days of clicking through endless options and dialogs to configure things such as encryption certificates, etc I often wondered if this was really better than editing a single line in an easy-to-find text file.
Start menu? Hardly ever used the damn thing. Shortcut keys with and I put the quicklaunch bar off to one side with the 40 or so frequently used programs I use.
Vista doesn't support dragging the quicklaunch bar off of the stat menu and off to one side because it was "confusing to end users." No one seems to have found a registry override as yet.
Vista doesn't handle symlinks properly. It used to be "c:\documents and settings" but now in vista it is c:\users. I see a clever little "C:\documents and settings" shortcut on my C drive. OOOOoo is this a symlink? No? I get Access Denied when trying to double-click. Opening the path via an API however works fine. Go figure.
BUGS. Features? Half-Features? Call them what you want. I think most technical folks that have to work on this know these problems exist but architecturally or bureaucratically they are hard or impossible to fix.
Often on XP, 2000, NT and 95 I would hit control-esc then R for run and type frequently used programs into run. I would say this is just an odd quirk about me and how I think menus take too long and too much work to do something, but now the run area has been replaced with a little place you type in stuff and through the magic of windows desktop search it finds whatever you type in the area above that normally occupied by program icons. The bug? You have to let it search. No matter what. Yeah, WTF? This works great on a home PC where you maybe have maybe 10,000 files. Network drives? Oh no. You can't just type n:\ then hit enter. You have to physically wait a sec for it to pull up n:\ in the list of programs above the start menu THEN hit enter. WOW, WHAT A GREAT FEATURE. No more control-esc n:\ enter for me. It is nowctrl+esc n:\ wait..wait..wait.. enter. Otherwise I get some random program like Notepad. Or Flash. Or Firefox.
On the one hand I can see how the start menu splaying itself all over your screen as you "drill down" to whatever the hell obscure program you need might be unappealing. On the other hand confining the entirety of all programs available to you to a 400x600 pixel window doesn't seem like a good fix.
This is just the start menu. Don't even get me started on the new file explorer, which is the least half-baked area of Vista in my opinion. Does Slashdot have an option for submitting a rant and getting comments? I'm sure I could go on all day.
I take all this as evidence that a lot of new features in vista are based on good ideas.. new paradigms in UI design.. it just seems that the vast majority are implemented poorly at best and implemented recklessly at worst. I would not expect this in 2006 when others are able to produce such polished and solid OSs. I would have to agree this seems like code-rot from the inside out probably due to the megalithic internal structure at MS
Not to most people. Certainly not past a *few*,*salient* choices. Past this point, more choices just add confusion. You do not need 255 different ways to tell a laptop to "close up for later use". A true geek would want to be questioned for each process about whether it needed to be persisted or killed. This is a problematic mindset.
That is all.
A bunch of reasons: :)
1. I like having my computers available instantly when I want to use them.
2. Turning a machine on and off many times can be harmful, so it is said. Others say it's a myth. I don't know who to believe, but it seems feasible that this could be so.
3. I run back-ups and virus checks during the night.
4. The computers work on protein-folding during their idle time.
5. My machines are in my bedroom, and they keep me nice and warm at night. Besides, there's nothing like the low purr of case fans so send you off to sleep
Well with a Desktop you can suspend to disk and then come back rather quickly, with a power off in between. This way you get the power savings, but you also get the fast "boot" time.
But let's look at me. I had a Dell laptop at school. I'd use it at home. Turn it off. Take it to school. Turn it on for class. Use it. Turn it off. Take it to next class/home and repeat. Suspend was very iffy (and didn't help much in the battery life department).
Then I got a Powerbook G4 (which I still use today). Run it at home. Close the lid. Take it to school. Open the lid. IT WAS READY. Within 3 seconds I could start working. When I'm done? No "Start->This->that" to be sure it worked. Just close the lid. I know some PCs worked that way, mine never did (reliably) that I remember. Next class/home? Open the lid. If it got low on power, I'd plug it in. My little laptop has had up to 3 months of uptime (mostly due to major security updates that require restarts). I NEVER need to turn it off. The last time I did was when I was going on an airplane (didn't know if they'd like it suspended during takeoff/landing). It boots relatively fast, but nothing compared to waking up and going to sleep.
If you're a desktop user, I understand your comment. But as a laptop user who has had the pleasure of a Mac, a fast reliable suspend is a HUGE time saver.
Now I'll note that some other people at my school had newer laptops that could suspend/resume just fine. But they took much longer. Some of them approached boot time length, some could do it in 20-30 seconds. No PC there matched my Mac (note: I never asked the few Linux users if they had it working on their laptops). I could suspend/resume my Mac 3 times with ease in the time it took the fastest XP users (and I'll ignore the "Click here to sign on" screen most of them didn't disable).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Yes, clearly you should be running NetBSD on that kid instead.
I read the internet for the articles.
IBM is terminating the final remnants of their OS/2 staff at the end of December, 2006 as OS/2 takes its last few agonized dying breaths. What's interesting, though, is that over the last 5 years, there has been a skeleton crew of OS/2 people at IBM to support the last few OS/2 customers and this tiny crew was able to accomplish a lot of stuff to keep OS/2 updated and running on current hardware that a much larger crew probably could not have. They were even able to add a lot of stuff that was never even included in the last 'official' Warp 4 release such as the logical volume manager, journaling file system, updated kernel for multicore AMD, USB 2.0 support, UDF DVD support, etc. In this case, a small crew could do a lot more than a large staff and the final dying remnants of the OS/2 business at IBM became more like the original tiny Windows group at Microsoft.
The UI isn't all that terrible. Joel Spolsky is making a mountain out of a molehill. Look at the screenshot he gives in his article. Here's what I notice:
1) There's a power button. That shuts things down fully. ("I am going away from my computer now, but I'd like the power to be really off.")
2) There's a lock button. That leave it running, but keeps others out of your stuff. ("I am going away from my computer now.")
3) There's a menu of choices if you care to look at it, and the button is much smaller than the other two and has a nondescript arrow icon on it which makes it much less attractive to non-techie users.
Yes, his suggestions for combining lock with switch user and sleep with hibernate are good, but I don't think what they actually implemented is all that difficult to understand. His problem is that he's "one of us" and went looking for all the extra options. Most people will never click that arrow to make that menu appear. Ever. It's kind of unfair, even to Microsoft, to rag on something for being unfriendly to non-techies when non-techies are never going to even see it. Usually Joel Spolsky's observations are spot-on, but this time I'm going to have to give him an F for eFfort.
Good God you have no sense of humor. Oooh oooh! Somebody insulted Linux!!!! Alert the authorities! Won't somebody PLEASE mod the GP???? Think of the children!
They can't afford that Steve.
They're stuck with the other one
the more they over-think the plumbing the easier it is to stop up the pipe
I work on a different project (not windows) and use the same repository system. (not the same actual repository, of course)
The branching / merging etc in the tool set (which btw we didn't invent, we source licensed from someone else and then have been continually improving) are quite good actually.
I don't know for a fact that the systems you mention arne't "up to the job", but how many multi-TB bitkeeper repositories are there? How many concurrent developers do any of these support? How many branches? How often are RI/FI done? How often do developers sync? What is the churn rate?
I think you also don't understand the problem. The SCCS can RI and FI (reverse integrate, forward integrate, respectively.. those are the terms we use for moving changes from a descendante branch upstream or moving fixes in a parent branch downstream) quickly and efficiently but there are reasons not to. The 99 USENIX paper on the MS internal SCCS talks about some of these issues. For isntance - what good is there in propogating a fix to every sub-tree or branch in a matter of minutes when it subtly breaks 80% of them?
The issue with lots of branching isn't the SCCS. It is the gating that you say "should be possible". Not only is it possible - its standard procedeure. And as your code gets closer to the root of the tree, the quality gates get harder to pass through. The latency involved in turning the crank on a regression test in Windows is very high, and if you got it wrong, the latency of a build is high, etc etc.
So it's not the underlying SCCS, it's the processes built on top of it. Everyone hates process when it slows them down and everyone wants more process when someone else breaks them. "We should put a process in place to prevent that guy from breaking me, but uh, i should be exempt".
As an aside, there are "fast track" branches/processes that let critical changes move through the tree very quickly.. on the order of a day or two from developers workstation to something that shows up in the next main-line build that an admin assistant could install.
When I work with our repository, which is on the order of 10GB and a few hundred thousand files, a new branch create takes a few minutes. Pulling down the repository takes hours. Our churn rate is such that with a handful of developers, ~5 days worth of changes can take 30mins to sync down.
When I RI or FI, it happens only in my client view. This gives me a chance to do merge resolution, and then to build and run our regression tests before "infecting" the target branch with potentially bad code. If building takes on the order of hours (not minutes), you've got latency of hours above the actual RI/FI time. If running tests takes hours (not minutes), you've got more latency. If after a build + test cycle, you see an integration problem, now you've blown a day before you've even found the problem.
I don't mean to say that there aren't problems, i'm just pointing out that like most process problems, this is death by 1000 cuts. The SCCM isn't a key limitation - even for the windows project (at least, not to my knowledge).
What you read was that the SCCm sucks. What I'm hoping to illustrate is that the process is unweildy at times, not due to any particular technology limitation.
My opinions are my own, and do not necessarily represent those of my employer.
Now I'm not a Microsoft employee, but even as an outsider I've seen some hints that it might be the "promiscuous dependency taking" that has delayed Vista.
1) Integration of Internet Explorer.
Microsoft claims that IE and Windows are inextricably linked together, and at least for Windows 2000 and newer this seems to be true. For instance, if you type a URL into the address bar of the Windows Explorer, it will show you web pages. IMHO a stupid design, the web browser should be an application, not a fixed part of the GUI.
2) The RPC service being responsible for things a "remote procedure call service" has no business handling.
In August 2003, a worm called MSBlast spread by exploiting a buffer overflow in the DCOM RPC service (see Wikipedia, http://en.wikipedia.org/wiki/MSBlast). At that time me, trying to be clever, thought:
"I don't want anyone remotely executing stuff on my PC anyway. I'll just switch the service off and be fine".
Lo and behold:
After turning off the RPC service, various local functions were dead as well. Including the Services menu in the control panel. I was lucky that I could reactivate the RPC service by manually editing the registry, else I would have spent a day reinstalling.
So it seems quite believable that Microsoft is choking itself by lack of discipline in designing Windows
C - the footgun of programming languages
In order for competition to have its benefic effects (on prices and innovation), all is necessary is that MS be afraid that, should it do some wrong move, it would loose market share to competitors.
"In an almost spooky series of events, Microsoft has shadowed Apple's brush with death, making the exact same set of moves exactly ten years after Apple:
- In the mid 90s, Microsoft rapidly built upon its past success with MS-DOS to establish Windows as a vast empire
...just as Apple used the success of the Apple II as a stepping stone to launch the Mac in the mid 80s.
- From 1995 to 2001, Microsoft rapidly delivered advancements to its desktop Windows product
...just as Apple rapidly advanced the Mac System Software from 1985-1991.
- In 2001, Microsoft began announcing technologies that would be released as part of Longhorn and later Blackcomb
...just as Apple described new technologies intended for Copland and Gershwin a decade prior.
- From 2002-2006, Microsoft dropped features, changed plans, and started over several times in protracted efforts to ship Longhorn
...just as Apple had fumbled around with Copland ten years earlier.
- By 2006, it was obvious that Microsoft's Longhorn was not going to live up to the hype, and would really be just a refresh of the existing Windows XP
...just as Copland had been gutted in 1996 and its salvaged remains delivered as the optimistically named Mac OS 8.
- Microsoft outed Blackcomb as vaporware
...just as Apple admitted that Gershwin had never been anything but a list of deferred goals ten years earlier.
What's Next? The only difference between Apple and Microsoft is that today, in the final days of 2006, there is no equivalent to a 1996 NeXT waiting in the wings to swoop down and fix Microsoft's mess. Leopard vs Vista 5: Development ChallengesHow about, "I like preserving a particular state my machine is in?"
If I'm working on code, I've several editor windows, compiler and terminals open. And usually, if I have to shut down my computer, that would imply I would need to close all those windows and all those applications. Why should I do that when I could just have my computer hibernate or sleep?
I mean, if I am on Linux, I have four active desktops with several browser windows, code and other things.
Shutting down my system implies closing down everything and starting afresh. Why should I, when I can put my system to sleep and restart it with my windows and state preserved?
I used to work at Apple, in the OS and frameworks groups.
There is a master "train" for a release; projects that don't change are "forwarded" to that train, meaning no source changes are required. When a project needs to be submitted for a change for the new release, a new "view" is created for its specific changes. Every few days, a build is produced, sometimes using previously compiled bits from the old "train", sometimes its a full world build (which can take several days) but otherwise building all the latest submissions.
Then there's a fairly labor intensive "integration" phase where the built bits are all put on a box and booted. If a "quicklook" QA process shows that the build is hoarked, the integrator goes and pesters the submitters of the latest project that was submitted and gets them to fix it. (Some percentage of the time, the new code has exposed a bug elsewhere, regardless, the project that is the proximal cause of the failure is rolled back to the previous revision, it anticipation that all the projects that need to rev be submitted at once.)
The whole thing is set up through symlinks via NFS, so if you want to see the latest version of any piece of code in the system (modulus those projects that are "locked down" for security issues) you can just get your release name, append the build number, and you've got the source code, symbol'd binaries and build log *for any release* at your fingertips.
When a new build comes out, you just do a clean install. It takes about two hours on the internal network, so typically you pull the disk image and slam it to a firewire drive, (usually, you can bum a disk with the image already grabbed from a teammate) and do a full install in 15 minutes. I can't imagine having to spend a day (as some other posted mentioned) setting up a machine...
Most projects have 3 or 4 contributors. In many cases, and entire framework is the responsibility of a single person (and he or she may actually own several small frameworks.) Lots of small projects produce cleaner interfaces that lead to fewer dependencies. (Of course there are dependencies, and circular ones, but these are kept to a minimum.) Projects are encouraged to use public API from other projects, rather than SPI or other project internals. If there's something useful enough for some other project to use, its first made into SPI for internal consumption, with the goal that developers will eventually be able to use it through a public API.
Most groups don't have dedicated QA by the way - the engineers are responsible for their code, and everyone is generally just very smart about what they're doing.
As to this start menu problem: the entire UI team is about 5 individuals, plus Steve Jobs and Scott Forstall - and they're likely to say "Thats fucking stupid, just do this" and boom(tm), the decision has been made the product ships, and life goes on.
Ever try explaining the benefits of virtual desktops to a person who doesn't even think a tabbed browser is needed?
That's one of the previous Unix admins I worked with.
He was so clueless about his boxes that every week he'd say "I just wish I had windows servers instead."
If you don't know what AltaVista is (was), get off my lawn.