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.'"
Actually the amount of RAM put in consumer-level machines hasn't increased that much. It is quite common to see a P4 with 2.4Ghz and only 256MB RAM in the stores. And this amount has been quite stable (more or less) over the past few years.
So the 2006 consumer-machines might habe 512MB of RAM. But if 483 are needed just for Windows not much is left..
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
I found a handy page on Google with some torrents and other doodads. You may want to check how much RAM you have first ;-)
Hey, if you're extremely worried about the RAM resources, are too cheap to shell out that extra $40 for 256 MB of memory, or expect to run the whole thing on TI-83 calculator, then maybe next Windows is not for you.
If you want functionality, you have to dedicate resources, if you don't want much functionality, stick to Linux on a floppy with pre-installed vi and life would be great.
Mozilla Firefox 0.8 is currently taking up 63 MB of RAM, and that's just a browser with no media players, mail clients, task schedulers, etc.
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
You must factor in the amount of cached used. Linux likes to store as much in cache as possible, but will quickly give it up for an application that needs it. Also, sometimes top inaccurately reports memory usage concerning shared libs - several apps may be using the same lib which might take 10MB, and they all will be reported as using up at least 10MB.
Linux does NOT take that much RAM. Not even close. I'm guessing you're looking at the total memory usage, including cache. Linux aggressively uses free RAM as disk cache, so it will usually appear that most of your RAM is in use.
I have run Kernel 2.6.2 on a 486 with 16MB RAM. It wasn't doing a lot, mind you, but it had a few megs free. (It was NOT running X.)
Its not always a bad thing to have memory in use. In fact, Linux aggressively tries to make use of every piece of memory it can. If you haven't used an application for awhile it will page it into swap and reclaim some RAM for the file cache or other programs.
The other thing to be careful of is top and other memory reporting utilities report X as taking up far more RAM than it actually uses. This is because X mmaps your video card memory. So if you had 128 megs of video RAM, your X would look pretty huge.
The more you know, the less you understand.
here is a look at what Microsoft has in store for it's future operating system.
I wonder if it'll educate its users on apostrophe usage. This is third-grade stuff, dickhead. Maybe you should KNOW IT BY NOW.
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.)
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.
A Quick Look at Longhorn Build 4053 - Page 2
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 tune
Do you have a lot of mapped drives on other machines on your LAN? I find that to be the #1 cause of IE/Explorer sluggishness on Win2K, even when you're not doing anything that involves the mapped drives.
Longhorn 4053 Tweak Guide ...
...
Found this over at Neowin
no. why ?
with windows, you are stuck with the kernel it comes with.
with linux, you can pare it down to the bare essentials when you compile it yourself.
sure, Lindows may be a little bloated for usability, or Xandros.
but Debian or Gentoo ? hardly.
can you tailor you WinXX kernel to your hardware while removing extraneous crapola ?
Yeah, but most of the stuff in the kernel.debug binary is just debug symbols -- they live in the file but aren't loaded into memory. If you compare the two with the 'size' command you'll probably find they're much closer. But this Windows thing apparently (article site is down just now) has 483 meg resident -- which is gigantic, and debug symbols would have no effect on this.
Actually, the NT kernel itself _is_ lean, and contrary to popular Linux fandom theory, the Linux kernel is _not_ lean. The NT kernel supports a bare minimum of functions for interfacing modules, then everything else is written in modules around it, while Linux is monolithic(put a lot of functionality in the kernel itself) and pretty bloated.
This is a myth. NT is not a microkernel, at least not anymore. It was around 3.x (whatever the version number was), but not anymore. IIRC, even the window management functionality is in the kernel now.
And it's not just the kernel - the win32 API is a monster, containing a lot of GUI functionality and whatnot.
Oh well, I guess you should expect nothing less from morons who thought CR/LF, backslash dir seperator and drive letters are good ideas.
Save your wrists today - switch to Dvorak
You seem to have skipped NT4 and 2k. You should have 3.1 --> 4MB, '95 --> 16MB, NT4 --> 64MB, '98 --> 32MB, 2k --> 128MB.
THE NERD IS THE COMPUTER.
I have a dual 350Mhz Pentium II w/ 256mb RAM running XP Pro and it's very snappy. For starters, go to Control Panel, System, Advanced, Performance, Settings and set it to "Adjust for best performance" on Visual Effects.
XP is tolerable with 128
What, if you're running one application? I've got 512MB in my XP machine at work, and I've turned off all the snazzy effects and play-skool skins, and there are still times that my machine just suddenly decides to be completely unresponsive. This on a recent model Sony VAIO. I do tend to run back and forth between a lot of applications (Photoshop, Fireworks, Word, Excel, Thunderbird, Mozilla, IE, text editor, and when I'm feeling brave, Illustrator), but after a few days of uptime, even if I'm running only 2-3 of those, funny little things (like, selecting a drop-down menu) just start to crawl.
I'm suspecting it's something to do with disk performance, rather than memory, of course, but if I had 1-2 GB, maybe I wouldn't have to swap out so often.
Tweet, tweet.
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...
Actually, the OS XPublic Beta first had a 128MB requirement. I've gotten it to run with 64MB, but it's awfully slow that way.
You can try starting regedit, going to HKEY_CURRENT_USER\Control Panel\Desktop and setting MenuShowDelay to 0.
System Properties -> Advanced -> Startup and Recovery -> untick "Automatically Reboot" ?
"Cattle Prods solve most of life's little problems."
It seems to obvious the better solution is to implement real POSIX threading. Not only would it make it easier to scale Sql Server, .NET and transactions, but it would provide the ability to switch modes for dedicated servers. The feeling I get is now MS will have multiple components that by pass the default system threading and implement their own POSIX like threading to get around existing scalability issues. One on hand, it will be nice to get reliable transaction management, but having a kernel level TM just feels wrong. LongHorn's WinFS is also suppose to provide full ACID capabilities, but I don't think that will really solve anything in terms of implementing shared memory for Sql Server. I'm no expert, but that's not how Oracle implements shared memory architecture to achieve dynamic table distribution at runtime within a cluster. I'm sure some of my assumptions are wrong, since I'm guessing based on what I can find.
(i work at microsoft)
what you say is correct, the build numbers for the most part go +1 each day. but for releases and such, they have jumped numbers for convenience's sake (e.g. xp gold wasn't actually 2600, it was something like 25xx, but they made it 2600 b/c this is convenient.) also, they branched out the longhorn build while the xp build was still being finalized, so they made these start at 3000 (iirc) to keep them separately identifiable. so, 4053 doesn't nec. mean 1053 days after 3000.
"but not 2000. It will restart for no reason."
I know it may seem like magic to you but there really is always a reason. Computers are deterministic; everything they do has a cause.
My bet would be faulty memory. Just a guess though.
Now that the link is slashdotted, I'll post another review / info page about this alpha build from PDC:
. asp
http://www.winsupersite.com/reviews/longhorn_4051
There are no apparent differences between that reviewed build (4051) and the one in this article.
Beware: In C++, your friends can see your privates!
Which OS version are you using? The latest got a lot faster.
10.3 Panther is pretty snappy, even on a 500MHz iBook with 192 MB RAM
As someone who beta tested 98/2k/and XP I can say that that is not the trend, but I would probably add that 98 was never unstable for me. I was most impressed with an early beta of 98 because of that fact. 98 didn't start using more resources until they upgraded IE, if you don't do that then it will run the same resources as it did about a year before its release. 2k and XP definitely improved themselves also XP wasn't beta for that long. Memory management is one area Microsoft managed to improve dramatically which is why I was able to install Longhorn on a thinkpad with 256 megs of ram. It ran okay for a few minutes just paging, then it started to slow down as explorer ramped up to operating capacity.
The PowerMac G5. Technically it should be able to support more than 8GB, but only 8GB is supported by Apple.
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!
That's almost all debug symbols.
Actual code and memory usage for debug programs I have seen be anywhere from 1.5x larger, to smaller (apparently due to loop optimizations that bloat the code).
SOAP and XML are not the only options in .NET, those are just used for high compatability with other OSs. Most likely over 99% of function calls in .NET are traditional old Binary calls.
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.
That's an Intellisense issue, not a dual CPU issue. I've seen Intellisense block my text editing for a good 15-20 seconds before.
DrPascal: Not the language, the mathematician.
Control Panel
-> System
-> Advanced (it's a tab)
-> Performance "Settings" button
-> Adjust for best performance
You can also get "TweakUI" from Microsoft (google for it), and adjust the time delay before windows come up.
XP is fast with these changes (and is only slow when something locks up for a while).
--
Yow
Such as?
Pretty much every game ever made, except for the Unreal series, Quake 3, and a relative handful of other titles. A quick eyeball of the listings in the Macintosh section at www.gamefaqs.com suggests probably a couple hundred titles available, with most being fairly old. Compared with the amount of games available as Windows-only, Mac support is only a drop in the bucket. *nix support is even worse...Even with WINE, I think the last time I tried to do a count, there was something like twice the amount of non-working titles as those that were.
As for non-gaming software, I agree that I may have less of a case there, but my original post was centered on gaming, and there I stay. Just from my personal knowledge though, the Mac is pretty strong in the area of office and design software, but beyond that I don't really know. *nix is less sure, relying more on stuff like WINE/Crossover. Feel free to fill me in on specifics if you like, but i'm not going to hunt down a complete list for you.
As I stated before, anyway, many people use their systems for entertainment, and switching to a platform that doesn't support many options for that entertainment will severely limit things.
Microsoft has only made 2 operating systems - DOS and NT.
Everything from the first release of MS-DOS all the way through Windows ME was one codebase, and everthing from NT 3.1 to XP to this Longhorn alpha was the second codebase (called New Technology).
At idle, with no applications running, the commit charge is at a whopping 483 MB
This is crap...
Testing both 4051 and 4053, even with all the 'extra features' turned on, the commit charge is around 240mb.
Additionally, there are about 50-100mb of Services for Microsoft reporting that is running and is used ONLY for reporting to internal servers at Microsoft for the developers at Microsoft. And thse services can and should be turned off, since outside testers are NOT using these services.
Some of our developers are running Longhorn in VMWare and VirtualPC with it set to 196mb and 256mb of RAM for the guest OS. And it runs better than expected for a pre-beta.
Let's dog on Longhorn when it gets to RC1, the current Alphas are so far away from the shipping product it isn't even close.
This reminds me of Windows 2000 when it was Beta 1 back in 1997, it was a TOTALLY different OS than even Beta 2 or RC1. Beta 1 of Windows 2000 had very few features working properly and was slow as hell compared to the release version.
Considering the time table of Longhorn, 2 years is a lot of time for a lot optimization and it already has a solid NT core that the redesigned Windows Subsystem will run on.
If all else fails, I would bet money that when longhorn releases it will run as fast as WindowsXP, even on comperable hardware, although you may have to turn off many of the 'resource intense' features of Longhorn to make it run well on lower end hardware.
TheNetAvenger
It's XP. XP's VM is total shit. The moment you minimize a window, the VM will page it out to the swap space. When I was doing Windows development for 3 months, the trick I found was to use a third-party tool which allowed window shading, and then I just shaded windows which didn't require my immediate attention.
512mb of RAM was thus able to sustain VS.net, Mozilla, Firebird, WinAmp, and a couple of extra windows all at once without choking like a 5$ hooker.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
1) Again, most corporations these days use linux for their professional design needs, server needs and efficient desktop usage. 2) By KDE integration I mean you can integrate any piece of software directly into any part of KDE, like you can run openoffice from within konqueror, or vim from kwrite. 3) As for your redhat remark, SERVES YOU RIGHT!, dont use redhat until fedora is finished, try something designed as a windows replacement desktop use like the commercial Xandros 2, and I bet it works OUT OF THE BOX just like it did on the 15 machines I tested it on. 3) As to openoffice, I have shown it to all my friends, and once you use the preloading software (oooqs), it also starts in 1,1/2 second time, so la di da. And I've become more productive with it in seconds, I can do better looking documents, all the menus are better organized, and all my projects look way superior and now I can directly export to pdf. And news to you, you CANNOT turn off the preloading of explorer and MS office components. 4) As for running linux on anything that has a power chord, that just shows its functionality, and its mornally for just a learning experience rather than real usage, the OQO however is a COMPELTE PC!, it has a hard drive, ram, screen, cpu, and runs on the transmata based motherboard with complete linux support, how exactly is your comment relevent? 5) Windows will fail, and it is obvious, there is too much proof that it will fail, 1) investing into hardware, 2) investing into digital management 3) investing into sco 4) postponing release of their new product 5) being sued by just abount anyone and having to take off functionality of their OS.. Its just obvious this OS will not work, it is clearly NOT designed for home usage, and will only appeal to some companies that want the standarized, closed source control of information so there are no potential leaks, but that wont work either. And as for the software being away 3 years, that is NOT relevent, I don't give a crap about it being 3 years away, I've looked at the list of potential new features, and it all exists in linux already, why wait for something I can do now?