Jump to content


Just Joined
  • Content count

  • Joined

  • Last visited

About DannySmurf

  • Rank
    InsanelyMac Protégé
  1. I'm not really sure. I know it took a year between the two sets, but that doesn't necessarily mean they spent all that time moving the kernel over. And honestly, if it took them that long to do that, I'd be shocked. The two kernels, while radically different on the inside, are designed to look and act almost identically to outside code ("outside" code including parts of the OS outside of the kernel). If Microsoft's legions of programmers struggled with a move like that for a year, I'd be VERY hesitant about running this next version of Windows. Neither have I. But Microsoft's statements STRONGLY imply that. And I believe Jim Allchin used a very similar phrase not all that long ago (I might be mistaken). People pick up the implication and repeat it, without realizing what they're actually saying. You're right about all of that, of course. But I think you may not quite understand how software development on a modern operating system works. Developers need something definite to rely on, yes. We call that the "public interface." Basically, you call into the operating system at a certain point and you get some sort of response. The entry point and the response should be consistent. However, what the operating system does behind the scenes to generate that response does CAN be changed without changing the developer's/user's view of the system. For example, the network stack in Windows XP is quite different from that in Windows NT4. They don't work the same way at all. But a developer only has to write a single piece of code to work on both systems. The interface is the same. But there are six years of changes under the covers that make the XP stack work better, faster, etc. Sure they can. But as I said, the user experience does not determine whether a product is "alpha" or "beta," or vice versa. Those words just don't mean what you think they do (in fact, what most people think they do). They have nothing whatsoever to do with the quality of a product. The quality generally falls in line with where the product is in development. But not always. And the fact that a product is in the "alpha" stage does not mean that the quality is poor. For example, ICQ 98 (99?) Alpha. It was an "alpha" release, but it was a MUCH more stable, usable and finished product than its "gold" competition at the time (Powwow, if you're interested). "Alpha" means that the product is still in active development: new features are still being added, and lots of new code is being checked into the project. That CAN (and a lot of the time does) mean that the product is unstable or rough around the edges, but it doesn't have to. "Beta" means that the product is feature complete, or very nearly so, very little new code is being checked in, and the main focus has switched to debugging. Microsoft has confused that a bit over the years, and of course all of the amateur developers and OSS developers that make up meaningless version numbers for their apps like "Version 0.7 Beta 2 Release Candidate 1" don't exactly help. (that's an actual version number, BTW; it was for a calculator)
  2. That's what Microsoft calls it, and for some reason people actually believe that that's what they've done. It's not. In reality, rebuilding an operating system as complex as Windows "from the ground up" would take a decade, at least. What they ACTUALLY did was swap out the XP core that they were using pre-2004, and plug in the Windows 2003 core. It was certainly a good move. But considering 1) the two systems are designed to be compatible right down to the binary level (even kernel-mode -- WDM -- drivers are swappable between the two) and 2) the sheer number of developers working on Windows, this swap was also a very trivial move from a development perspective. Anyway, that's very off topic and you don't really have to reply to it. It just irritates me when people spread the Microsoft line about "rebuilding from the ground up" and other associated garbage. He did. But I wasn't replying to his post (or even saying that he was right). I was replying to the fact that you said that OSX for Intel is pretty much complete. My point (which you ignored in your reply) is that OSX for Intel is not complete, and is likely nowhere near complete, and -- most importantly -- you are not in a position to make that judgement; neither am I, neither is MrBond, because none of us work for Apple. It will be complete when Apple says it is. Whether you or I think it's an "alpha" or a "beta" is also irrelevant. That's a label that developers assign to their software, not users. I realize that users like to try, but since user experience (the only thing that users can judge) is NOT the determining factor in assigning development-stage labels, what any user thinks about the matter is not relevant.
  3. Actually, it'll be about a full year by the time it's actually released with the Intel Macs in mid-2006. But yes, that's basically what's happening, and it's not unimaginable or even uncommon. Longhorn has been in development since 2001. We've seen (almost) four years of alpha builds, and the beta test that started a few weeks ago will conclude after about a year, and the product will be released. XP/Whistler had a similar (though shorter -- it was a much less ambitious project) development schedule. This is the way that software development generally goes. You don't spend six months in development and three years beta testing. When you do that, you get things like Windows Me. I don't know how complete OSX for Intel actually is. I'm not an Apple developer -- neither are you. How sophisticated it is is certainly debateable (and if you're a long-time Windows user I certainly can't blame you for thinking that it IS sophisticated). However, until Apple says otherwise, it's incomplete, regardless of how well it works for you. Reply to the original question: If it didn't boot, I guess you'd just stop using it, wouldn't you? But of course, by that time the actual OSX for Intel would be available, and you could use that instead.