Slashdot Mirror
A Quick Look at Longhorn Build 4053
An anonymous reader writes "Even though the next generation Windows product is not due until late 2005 or even 2006, here is a look at what Microsoft has in store for it's future operating system. 'Without a vast amount of tweaking, this build is a resource hog. At idle, with no applications running, the commit charge is at a whopping 483 MB!! Obviously, the final release or even the beta releases will not consume this much of the system resources.'"
Are you so sure it wouldn't, Microsoft was never one for making a small package, and Longhorn is meant to be run on machines of 2006, where there is much more RAM in the the system.
Remember the days when the PC magazines all used to review pre-release software, find some bug or other, and say this will be fixed in time for the final release? Except the bugs never were fixed come the final version?
I see Longhorn ain't going to play nice with even XP-class machines. Oh well, not like I wanted my rights digitally managed anyway.
/b
|f(x)dx = F(b) - F(a)
ah but bill gates doens see it that way. He believes the future of computers is in the software. Pack it full of "features".
Here read up on what he said at MIT on computers.
30% Troll, 50% Underrated, 10% Interesting
Score:5, Troll
"Premature optimization is the root of all evil". DK.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Sources working at the Redmond campus say that it is common knowledge on campus that Longhorn will not ship until mid 2007. With current technical problems mounting, the same sources say that 2008 is starting to look likely, if not optimistic.
Those who have to use the current build say that it is not stable at all. Apparently, there are new failure modes in the DRM and file systems that are "very difficult to analyze and very non-intuitive to troubleshoot or even understand." The failure modes are reported to totally freeze the computer, prevent rebooting and resist reformatting.
If true, the words "difficult and non-intuitive" are not encouraging, particularly when used by very experienced users at Microsoft .
Well you might trying to be sarcastic but um yeah.
Sorry hate to break it to ya but 8MB of ram is shit for a compiler [that is meant to handle a program of any respectable size]. 80MB of disk space is little space to hold source+builds, etc...
The trick [which most miss] is an acceptable rate of growth.
I imagine 100 years from now a PDA will have a baseline of 1TB of memory [anything less will just be inhuman]. The point is right now that would be insane.
Similarly sure 20 years ago 8MB of ram was godly [cuz quite frankly the average program was of limited appeal and functionality]. You can pick up a 512MB of ram for relatively cheap [~110$ CDN for PC2700].
So it isn't unreasonable to assume a desktop user would have 512MB or even 1GB of ram [it's much I agree but not overly excessive]. If windows required 512MB of ram 10 years ago they would have gone out of business. Right now though it's not asking too much.
That being said I agree with the sentiment against bloat. I run icewm for the sole reason that it takes 10MB of ram. Combined with X my entire "desktop" takes less than 30MB of ram. It would be nice if the next version of windows didn't take 200MB of ram when idle but alas it wouldn't be cool enough if you didn't have a million little things going on all at once.
Tom
Someday, I'll have a real sig.
Every Microsoft operating system during development does! The OS is not designed to run on systems that we use now, it is designed to run on systems that we will be using in 3 years time.
Historically, when Windows NT received heaps of exactly the same flack about it running extraordinarily slowly from reviewers quite simply because they weren't smart enough to work that basic fact out.
Last Friday, I had to fire up an old, tired PC running Windows 98. Gosh, a real dinosaur - 166Mhz, 256Mb RAM, MS Office.
It was weird. It booted quickly, and the whole thing felt snappy. Menus actually popped up on screen immediately. Explorer did things, instead of hanging about "thinking" all the time.
Windows XP doesn't feel like that, even with my brand new 3Ghz, 1Gb RAM machine.
Why is this so? Why are the menus so slow - and what have they done to Windows Explorer to make it so snail-like?
"Cats like plain crisps"
It's called debug code. Just look at FreeBSD:
/boot/kernel/kernel /boot/kernel/kernel /usr/obj/usr/src/sys/GENERIC/kernel.debugx r-x 1 root wheel 30170033 Mar 7 21:31 /usr/obj/usr/src/sys/GENERIC/kernel.debug
fafnir# ls -l
-r-xr-xr-x 1 root wheel 5940286 Feb 26 00:52
fafnir# ls -l
-rwxr-
Enabling debugging options makes the FreeBSD kernel five times as large; if anything, I'd expect Microsoft to have even more debugging code in their pre-release builds.
Tarsnap: Online backups for the truly paranoid
How is mine *anti* Microsoft?
It's a legitimate point, I asked why it was obvious the final release will take less memory?
I would fully expect all OSes in 2005 to take more than 256mb; possibly even 512mb. Microsoft would just happen to be one of many. If this were a Linux article, I would have asked the same question. I use a Mac, and I *know* how much memory OS X likes, and am under no illusions that 10.5 won't take as much!
GPL Deconstructed
I would say that Microsoft has a lot larger userbase... so they draw their release schedule out.
Upgrading 1,000,000 customers vs. 80,000,000 - your support and documentation has to be that much better.
Believe it or not, I think Windows 2000 / Windows XP is as stable as linux / Freebsd. I didn't say better, I didn't say more secure... but I think the stablish issue is mute. considering how much more crappy hardware and hardware drivers windows supports - of course more people are going ot have crashes. But on the 10,000 combinations of _good hardware and drivers_ it works fine.
Remember kids, only takes one driver to lockup the PCI bus (IRQ / DMA / etc). I've seen bad USB drivers bring down Linux/FreeBSD/OpenBSD/windows XP - all latest versions with patches.
"At idle, with no applications running, the commit charge is at a whopping 483 MB!! Obviously, the final release or even the beta releases will not consume this much of the system resources."
MS typically aims at having the OS consume, or fit into, about a quarter of whatever amount of memory is considered standard at the time.
Now, by the time Longhorn rolls out in 2007 or so, it's likely that 2 GB of RAM, if not 4, will be standard on most new systems. So I'd say MS is probably aiming at a 512 MB base for Longhorn. Maybe 256 or 384, but there's nothing in MS's history to indicate that they would have a problem releasing an OS that consumes 512MB.
I am not surprised. They probably used .NET to build it all. That means a few things:
.NET style SOAP XML messaging)
.NET does essentially the same, but it will have the same drawbacks as Java - slower execution and larger memory footprint.
- they are now using components (with
- they use bounds checking all over
- more meta information on objects is stored
- libraries are probably more extensive - makes reuse better
- more things are service-driven, so more is in memory all the time
This all comes down to more memory use. Look at Java. It's fast enough nowadays, but it still uses a lot of memory resources. You get more runtime functionality (reflection etc) in return.
This is a good thing though, it's a one time performance penalty returning huge benefits. It won't favour small/old machines though.
The future is runtime.
I have to agree with RoundSparrow. I own an HP Pavilion 420n. It crashed on me like nothing has ever before. It was a shit machine... A 2GHz shit machine. I bought a nice, new, large case with 3 fans and a 320 V power-supply. Never crashed on me again. I run Windows XP.
I've come to the conclusion it's crappy hardware that renders, otherwise good PCs, into something a wee better than cardboard boxes.
People discover the meaning of life between getting piss drunk and the following hangover.
As a developer under windows, I can definitely say that XP is pretty pathetic in terms of stability. If the machine doesn't crash on me at least once every two weeks, I've witnessed a miracle. Alas, the miracle is empty, since the system slowly bogs itself down as time goes on, and I end up having to reboot anyway.
To be sure, they've done WONDERS with the stability. When I was using XP as my home operating system, it wasn't too bad. The problem that I've found with XP is that as load ramps up, it's ability to stay stable and usable trends downward increasingly quickly.
Oh, and its dual-processor support is pretty pathetic. The load balancing seems incredibly naive. (And, this may not be an OS problem, but I find that I have problems scrolling text in VS.NET in a timely fashion. Not all the time, but sometimes it'll just stall when trying to do something that I consider a simplistic task.)
Let me preface everything by saying I used to be a UNIX administrator.
Now, I work for a company with sysadmins, and they do a good job of taking care of my machine. We make sure it's patched, that we've got the latest drivers, and that the hardware is all running well.
I have no bizarre third party applications running, besides the usual things that should have nothing to to with stability. I use Emacs, Opera, VS.NET, iTunes and PuTTY throughout the day.
Some days, I have no problems. Other days, the problems just stack up. I occasionally have the machine lock up on shut down. I used to have the machine crash 2 or 3 times a week, but I stopped playing Diablo II so much. For whatever reason, XP REALLY doesn't like me playing Diablo II. Blaming things on Diablo II won't work, though - XP should be more than robust enough to handle something like that.
A while back, it would have been more likely that I would have agreed with you. I was running a shell and desktop replacement, but I've switched back to the ordinary base shell now. Nothing I run should be an issue.
As for Linux, I only had it crash a couple of times. Once, when I was playing around with experimental drivers, and a couple times when I was playing with beta kernels. I also had the windowing system crash a few times, but another networked machine always found the box up and running. (I also had some lockups related to heat when my Celeron 300A was starting to go.)
Considering the amount of work I do, I don't really find there to be much excuse for XP dying on me. I think I'm most willing to blame it on VS.NET which is incredibly unstable on its own, crashing and coredumping and giving me internal compiler errors several times a week. I wouldn't be suprised if it were running wild and occasionally kicking the system out from underneath me.
Like I said, as a home system, XP worked GREAT for me. I was running Dual-Head on an ATI, playing lots of games, etc. As a development system, it's been brutal. I have pretty standard high-end hardware (getting older, so not quite as high-end now, but still, a Ti4400 is not exactly bottom of the barrel) and I run standard XBox dev tools. Most of my colleagues have similar problems, though perhaps a little less often than I do.
I'm not really trying to rag on XP particularily much, merely trying to point out that from a stability point of view, I don't think it holds a candle to any UNIX that I've ever worked with. OpenBSD, FreeBSD, Solaris, IRIX, AIX, Linux, OS X and even HP-UX (ick, BTW) seem to be more solid.