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.
So the big news is, an alpha version of an operating system from an OS family known to eat lots of memory, actually eats lots of memory?
"They must be running IIS on Longhorn!" or something. I heard that if nobody says something like that in a Slashdot thread, the universe implodes.
They're just waiting for the hardware needed to run it to become available...
Chances are the alpha is built in debug mode. Those seem to be rather bulkier, both on disk and in memory.
"[A] high IQ is like a Jeep; you will still get stuck, just farther from help!" --Just d' FAQs, c.g.a
Obviously, the final release or even the beta releases will not consume this much of the system resources.
No actually, they have the all important Brushed... I mean Slate look in place, so thats development pretty much wrapped up on this version.
Jonathanjk.com
Am I the only person who thinks improvements should come in the simplification of code rather than adding new features? I would much rather have another version of Windows 2000 that runs more efficiently than whatever may come from Longhorn. It's beginning to sound less like an application launching layer and more like a 3-ring circus stuffed into a shoebox.
Is this Gate's law once again counter-manding Moore's Law?
Joe
Intel: Hey Microsoft why don't you slow down windows a bit? Microsoft: Why? Intel: That way home users will actually have a reason to buy a 3Ghz processor
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.
What'd they do? Replace the Windows GUI with Gnome?
ducks
FreeSpeech.org
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)
Why is this flamebait?
Why is it obvious that an OS in two years won't consume 400mb of ram?
What will the base system Microsoft target contain, in terms of memory?
Right now 512mb of ram is $100.
In a year then it might be $50 or $60. Or it might mean a base system will contain 1gb of ram, and everyone will have 64bit CPUs capable of addressing 16gb, or 32gb of ram. We already have desktops today that can address 8gb, and we're only waiting on ram sticks to increase in density.
GPL Deconstructed
Bill gates has called a meeting with the memory chip manufacturers...
GATES: "Gentlemen, I'm here to offer you a proposition. With my evil, resource bloating operating system, you can join with Microsoft and we will band together and control all the memory on the planet."
JAPANESE BUSINESSMAN: "I am not comfortable with this."
GATES: "I understand."
(He presses a red button on his arm rest)
(A trap door opens up from the ceiling and 10,000 copies of WordPerfect, Borland C++, Lotus, and Quattro Pro, bludgeon the Japanese semiconductor CEO to death. His lifeless body slumps over.)
GATES: "Anyone else have any problems with my plan?"
Geez and I thought Gentoo had a lot of builds...
Nah, just feels that way cause they take so long to compile.
Well, NT4 is build 1372 (I think), and I believe that Win2k is in the build number 2000-something... It seems to be the build number for the NT kernel itself.
There are only 10 kinds of people in this world... those who understand binary and those who don't
Of course it's a resource hog, they probably have every debugging feature turned on in it. Is there a point to "reviewing" this build?
I found a handy page on Google with some torrents and other doodads. You may want to check how much RAM you have first ;-)
People get a grip... Microsofts customer is *NOT* you and me. It is Dell, Gateway, HP and the like.
They goal is help their customers sell more product. That means give to their customer's customers pretty bright beads and *CAN NOT* work on existing (well slowly at least). This leads to the people buying BIG compters from MS Customers allowing for MS to sell the product twice!!
Can you say "More profit!"
It will consume more...
Posted by Team Flexbeta on 05 March 2004 (34135 views) Rating: 4.64
Even though the next generation Windows product is not due until late 2005 or even 2006, we wanted to take a look at what Microsoft has in store for us. We take a quick look at the recently leaked Longhorn Build 4053.
For those of you that are lucky enough to have snagged a copy, remember this, Build 4053 is still a baby, not even in Beta stage yet, so we will not go in depth into subjects such as the theme, sidebar, etc.
The installation wizard has improved greatly from past installers that Windows 2000 and XP had. No more will we see the plain DOS like setup screen, its all graphical now with minimal questions during the installation process, which, has its good and its bad. For a home user upgrading to Longhorn, the installation is a breeze, start the setup, enter the key and go take a nap, by the time you wake up it will be done. If the setup continues on this path towards final release, then the use of an answer file will be necessary to alleviate any post installation changes, especially for a network administrator implementing a company wide roll out, but Microsoft has always provided excellent administrator tools for this very reason. The installation did take an awfully long time, especially during the "Hardware Detection" phase, but I'm sure that this will be improved upon in the months to come.
Even though the initial startup is extremely fast, once logged in the system crawls along, taking a seemingly endless amount of time to get everything up and running. This too will definitely improve over development time.
The layout is clean and clutter free. Minimal icons are presented on the desktop, which is one of my pet peeves; I go to great lengths to maintain an icon-less desktop. The sidebar is definitely going to have its share of protestors, me being one of them. To me, no matter what is docked on the sidebar in the final release, it is a huge waste of space and system resources that a vast majority of users will just turn off. There will be more applets applied to it in the end, search bars, link bars, etc, so as the sidebar comes of age, we will examine it once again.
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. My test system is an Intel Pentium 4 2.4Ghz with 512 MB of RAM, so it is still running at a good pace, but anything less than this makes the system crawl along at an insanely annoying pace. When the final build is released, the recommended system requirements will be roughly the same as Windows XP, but as anyone that has tried to run XP with multiple users will testify, simply having the recommended requirements is just not enough.
At this point in time, build 4053 is basically Windows XP with a different theme, even though some new technologies are being created and there are dribs and drabs of them in this build. Build 4053 is still a lot different from previous builds where some of the new technologies Microsoft is working on were clearly integrated, such as the Hardware Carousel, WinFS, etc, in this build like Build 4051 (PDC) they are absent or implemented at a minimum.
There are very visible bugs at this stage, but it seems that some of the major pains that plagued previous builds have been worked on or corrected. The infamous Internet Explorer memory leak seems to have disappeared, and that was a huge memory leak, but as I sit here writing this, the commit charge is growing and growing, so there are still memory leaks in some processes and/or services that are running.
Some features previewed in previous builds have been developed to a greater extent such as Contacts, Photos and Videos. The layout and orientation of the windows has been vastly improved. All links and graphical elements have been fine tuned
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 .
That build number is the build of the overall NT kernel and code branch, not just of Longhorn. For example:
Windows NT 3.1 = build 511
Windows NT 3.5 = build 887
Windows NT 3.51 = build 1057
Windows NT 4.0 = build 1381
Windows 2000 = build 2195
Windows XP = build 2600
Windows Server 2003 = build 3790
(FYI, those are for the original release versions. Betas have earlier build numbers.)
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.
Its a product that won't hit the shelves for 2 years. It was compiled in debug mode - of course its going to be a resource hog.
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"
So, first he calles it micro - soft, and now he's calling it long - horn?
micro. soft.
long. horn.
I think that makes my phallic implications painfully obvious. My work here is done.
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.
Longhorn 4053 Tweak Guide ...
...
Found this over at Neowin
a fully-loaded 2003 server running dreamweaver
That could be the most appropriate use of a server I've ever seen.
Slashdot - where whining about luck is the new way to make the world you want.
Obviously, the final release or even the beta releases will not consume this much of the system resources
What is the point of showing these numbers then?
In other news:
Apple is working on a ultra-mini iPod. The pre-beta-alpha version we got our hands on weighted 20 pounds and was bigger than my G5. Of course, the final version will be smaller and lighter. One could still wonder where Apple is heading at with such a bulky product.
Foreword: If you have nothing relevant to say, don't say anything!
Write boring code, not shiny code!
What will the base system Microsoft target contain, in terms of memory?
Bill Gates himself answered this question years ago.
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.
I don't really know how modern Windows versions stack up in terms of stability. Win98 and earlier releases were horrible, and some people seem determined to pretend it's still like that five years after the fact, but it's been my experience (with a lot of installations) that Windows XP/2k really don't crash much, except for hardware/power problems, and weirdness with third party programs.
Defending Windows on Slashdot is probably asking for bad karma...
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.)
OS X will use as much RAM as it can - it caches apps and data you use a lot to cut down on time accessing the disk. I have a gig in my machine and OS X is using 892.8 megs, with 12 days of uptime and ten apps currently running. However, I bet that bits of apps I don't have launched right now, like Photoshop and Preview and Acquisition, are cached, because I tend to launch them a lot.
I'm not saying that modern OSes don't use a lot of RAM, cause they do. But the fact that the OS is using almost a gig of RAM on my machine is not a sign of inefficiency.
I am a believer of momentum and curves.
Hey, I found out today you can buy computers pre-loaded with the alpha version of Longhorn - the store was all white with wood floors, and they were selling these cool MP3 players too.
My laptop came in this cool aluminum case, and it's running pretty well. Searches were really fast and the new browser (I think they are calling it Jungle or something like that) was really great. Plus I had no viruses even when I connected it to the internet for a minute without thinking!! And in this version they made that huge bar on the side of the screen you could see in the article screenshots resizable. So I think Longhorn will do just fine.
Is that meant to spoof the old "more Windows viruses because it's more popular" myth?
If a company has to write 2 drivers, which one are they more likely to spend time writing and testing properly: the one that will be used on 95% of desktops or the one that will be used on 5% of desktops? Even the large companies that can write decent drivers often write their Linux drivers in a rush, usually after some big customer asks for it and they're facing the loss of a big sale.
Of course, one could argue that a company that doesn't have the resources to make a decent driver won't even bother with the Linux market. But such no-name companies mostly just use common chipsets anyway, most of which have good drivers.
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.
Longhorn is a patch over XP.
.NET framework for managed code.
Not really. Windows XP was over 2000 though. There are some huge underlying changes -- not a 100% rewrite -- but some major rewrites anyway. For example is the Windows programming API switched from Win32 to WinFX, and a whole lot retrofitted for the
In total, I'd expect Longhorn to bring about as many rewrites as there was from Windows 3.11 to Windows 95.
Beware: In C++, your friends can see your privates!