×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SLES9 vs. Windows Server 2003 In A Windows Network

timothy posted more than 9 years ago | from the up-against-it dept.

Operating Systems 21

Gsurface writes "Can SLES9 be a viable server solution as an answer to using a Windows 2003 Server? This article compares these two server products in a small to medium sized Windows network environment. The comparison covers areas such as reconfigurability, basic administration tasks, server tasks, file system performance, overall cost and user/computer management. These are basic functionalities that every network server needs to provide. Overall, makes for a good Saturday read." (That's "Suse Linux Enterprise Server," if you're not up on your acronym soup.)

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

21 comments

Emulating Windows Server is the wrong approach. (5, Informative)

Ogerman (136333) | more than 9 years ago | (#10610366)

I've set up Samba + LDAP to serve Windows clients using Debian. Unfortunately, in this case, it takes a whole lot longer because nobody thus far has seemed interested in writing a good Open Source tool to aid in making this work out of the box and to ongoing Samba administration less of a hastle. Setting up a small enterprise server with Debian feels a whole lot like building a microprocessor given a pile of sand. As a result, we have the market for SLES, RHE, and others. While there's nothing inherently wrong with this, it would be better to have one popular open source solution that everyone is familiar with instead of dozens of proprietary GUI tools packaged with the commercial distros. "Widget frosting" is not a sustainable OSS business model.

A major issue not mentioned in this article is the prevelence of Windows-only server-side software. Besides easier administration using AD, this is another significant reason why people stick with Windows Server in real life. They absolutely need their custom departmental business apps, so the choice of operating system becomes secondary. NOTE: This is why we need a strong focus on real-world F/OSS database applications. This is without question the killer app of Open Source in the enterprise. (Hint: big money here, and think Java)

One last thing not mentioned is the fact that the Windows server environment is not just about sharing files. Group policies, MSI, etc. are powerful tools for administering a Windows network that Samba does not provide. After all, Samba is only one piece of the puzzle. That's not to say that these solutions are ideal, but if you're stuck with a Windows environment, they become a valid factor to consider.

All things considered, we as the Open Source community should not be focusing on emulating Windows Server as the key to the enterprise. This is an endless game of catch up to unstable, proprietary standards. We need to aim higher. We should be innovating and re-thinking the current office computing paradigm. We need to make it attractive not only to replace Windows on the server but also on the desktop as a direct result of the benefits of a purely non-Windows environment. Those benefits can only materialize if we create our *own* enterprise solutions instead of trying to just become compatible with the status quo.

Re:Emulating Windows Server is the wrong approach. (2, Informative)

MBCook (132727) | more than 9 years ago | (#10610507)

And this is a problem that will be hard to solve untill Linux gets MUCH more popular or MS embraces (true defintion, not theirs) heterogenous environments (don't hold your breath). The fact is MS will always have some advantages (especially in ease of use) when you use Windows clients. Linux might give you advantages if you use it to serve files or mail and use Windows servers for profiles and AD. If you had Linux clients and were deciding between Windows and Linux for the server, would there even be much of a contest? I doubt it.

Why not make their own unix (I know they had one, Xenix right?) and position Windows Server as a managment tool for their unix servers or a server for small businesses (sort of like many people might use OS X machines). Given MS's nice tools, if they made it so that it could manage Linux machines with it's tools and wizards and such they would have a great product.

But they won't do that becuase it would let people use Linux. That's why they could do it with their own Unux.

But they won't do that becuase it would make Windows server look bad and could be confusing.

The solution: GET YOUR CUSTOM STUFF CROSS-PLATFORM. That's the true solution.

Re:Emulating Windows Server is the wrong approach. (1)

einhverfr (238914) | more than 8 years ago | (#10615297)

First let me say that I think that it is important to provide an emulation option for Windows servers in order to decrease the cost of migration.

That being said-- Linux allows you do to things with your network that you couldn't even dream of doing on Windows. For a place to start, look up Project Athena..... And Linux allows you to mix and match these ideas to your heart's content. For example---

Microsoft's complaint with the Athena approach is "how do you read your email when you are not in the office?" Simple, on your laptop use CodaFS and have a reasonable GUI environment and an email client. But other programs can be run over the network and integrated seamlessly. Use a VPN over broadband and you might get workable performance from a remote location.

So the tools already exist to do things better than Microsoft, but you need to have a reasonably skilled set of network administrators and engineers to really make use of this technology to its greatest potential.

Re:Emulating Windows Server is the wrong approach. (1)

Ogerman (136333) | more than 9 years ago | (#10618486)

First let me say that I think that it is important to provide an emulation option for Windows servers in order to decrease the cost of migration.
That being said-- Linux allows you do to things with your network that you couldn't even dream of doing on Windows.


Yeah, I wasn't discounting the need for emulation as an aid in migration. What concerns me is that too often the focus seems to only be on emulation when there is so much more possible.

Re:Emulating Windows Server is the wrong approach. (1)

einhverfr (238914) | more than 9 years ago | (#10635304)

What concerns me is that too often the focus seems to only be on emulation when there is so much more possible.

You have a point. The issue is that Microsoft really pushed this server/workstation model and now everyone feels compelled to fit into it. If you are going to make Linux appeal to PHB-types, you are going to have to use this model, unfortunately. This is worrysome and troubling. But there is hope.

As Linux continues to gain marketshare, we will hope to continue to see people really start to use it in ways which make PBH-types say "Wow, I wish we could do that...." And guess what, they can :-)

Lack of decent LDAP single sign on UI is a mystery (5, Insightful)

hey! (33014) | more than 9 years ago | (#10610399)

Why doesn't some Linux distro ship with LDAP configured with everythign it needs including the appropriate schema and a decent front end for setting up Unix and Samba logins?

I've gone through the trouble of getting everything I needed to get LDAP sign ons working in Linux, samba and Zope, but in the end the process was ugly as sin. It turned out to be waste of time because I couldn't delegate managing this system to non-technical people without giving them a course in things like Unix UIDs, LDIF, and LDAP schema.

With all the tremendous work being done on the Linux desktop, the lack of a cross machine/cross application sign on front end, when a robust and scalable back end already exists, is utterly mystifying to me.

Novell is LDAP. (2, Insightful)

mosel-saar-ruwer (732341) | more than 9 years ago | (#10610820)


Why doesn't some Linux distro ship with LDAP configured with everythign it needs including the appropriate schema and a decent front end for setting up Unix and Samba logins?

Dude, if Novell can't do Directory Services, then no one can.

Performance Charts (1)

cyber_rigger (527103) | more than 9 years ago | (#10610857)

For those who want to go straight to the charts.


SuSE vs Windows 2003 Performance [flexbeta.net]

At 60 users SuSE has 2.5 time the performance
of Windows 2003 server.

Not to sound like an M$FT apologist, but... (1)

mosel-saar-ruwer (732341) | more than 9 years ago | (#10610918)


That diagram is for NetBIOS/NetBEUI/NetBT/NetWhatever file sharing, which is maybe one one-hundredth of one one-hundredth of one one-hundredth of the possible things that a Windows 2003 server can do.

Re:Not to sound like an M$FT apologist, but... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10610977)

Not to sound like an M$FT apologist

You sound like an M$FT apologist.

Re:Not to sound like an M$FT apologist, but... (1)

M1FCJ (586251) | more than 9 years ago | (#10612993)

Like....???

Let's see what SLES9 will do for you if you want to replace your MS2kServer box:

Running Oracle? Check.

Running Toy SQL Server? If you can live with upgrading to MySQL, Check.

Running web server? Check.

Running Apache/Tomcaet or IBM Websphere for Java Enterprise apps? Check

Storing your roaming profiles? Check.

Unless you are talking about some obsolete cline-tserver arch application, I can't think anything that an SLES box can't do.

Re:Not to sound like an M$FT apologist, but... (0)

Anonymous Coward | more than 9 years ago | (#10618795)

But you do sound like an "M$FT" apologist. And a moron too. Moreso when one has a look at your uninformed posting history.

In defense of M$FT - have to disagree on one item [slashdot.org]

Java is a 32-bit language; C# is a 64-bit language [slashdot.org]

What, do you say M$FT to try to sound more credible (like an MS skeptic?) when you come to Bill's aid?

Oh, also one more thing: Ha ha, SUSE whips NT's anus on their home turf, on one of their flagship server capacities - SMB/CIFS file sharing. Samba basically has to reverse engineer the entire (massive) protocol, and do a decent amount of hard work to convert UNIX permissions and names to NT ones. I'd like to see how badly NT gets shat on when Linux isn't so hamstrung.

Kudos to SuSE & Samba, but that's not my point (1)

mosel-saar-ruwer (732341) | more than 9 years ago | (#10620152)


Oh, also one more thing: Ha ha, SUSE whips NT's anus on their home turf, on one of their flagship server capacities - SMB/CIFS file sharing. Samba basically has to reverse engineer the entire (massive) protocol, and do a decent amount of hard work to convert UNIX permissions and names to NT ones. I'd like to see how badly NT gets shat on when Linux isn't so hamstrung.

Look, if a properly configured SuSE Server beats a properly configured Windows Server at NetBIOS/NetBEUI/NetBT/NetWHATEVER file sharing, then kudos to Novell/SuSE & the Samba team.

But that's not my point: The Windows Server is doing about a gazillion other things in the background, like cross-correlating all that NetBIOS/NetBEUI/NetBT/NetWHATEVER traffic with NTFS File Permissions, finely-grained NT Policies, Active Directory Permissions, COM & DCOM functionality, .NET functionality, Distributed File Systems, Event Services, you name it.

In other words, NetBIOS/NetBEUI/NetBT/NetWHATEVER doesn't exist in a vacuum anymore - it's just a tiny, miniscule fraction of the services that a Windows Server is offering - almost an afterthought, if you will.

Re:Kudos to SuSE & Samba, but that's not my po (0)

Anonymous Coward | more than 9 years ago | (#10620708)

Look, if a properly configured SuSE Server beats a properly configured Windows Server at NetBIOS/NetBEUI/NetBT/NetWHATEVER file sharing, then kudos to Novell/SuSE & the Samba team.

Yep. And the Linux kernel team.

But that's not my point: The Windows Server is doing about a gazillion other things in the background, like cross-correlating all that NetBIOS/NetBEUI/NetBT/NetWHATEVER traffic with NTFS File Permissions, finely-grained NT Policies, Active Directory Permissions, COM & DCOM functionality, .NET functionality, Distributed File Systems, Event Services, you name it.

You're being fairly vague and basically don't say anything. Apart from the fact that it isn't "doing distributed filesystems" in the background, for this test in question, Linux is providing the same functionality as NT. What do you mean by COM & DCOM functionality? You're just pulling shit out your ass.

In other words, NetBIOS/NetBEUI/NetBT/NetWHATEVER doesn't exist in a vacuum anymore - it's just a tiny, miniscule fraction of the services that a Windows Server is offering - almost an afterthought, if you will.

Oops, better tell microsoft that. They happen to think filesharing is a pretty important market.

Gee, what do I know? (1)

mosel-saar-ruwer (732341) | more than 9 years ago | (#10621763)


What do you mean by COM & DCOM functionality? You're just pulling shit out your ass.

My bad - I was wrong: There's no such thing as "DCOM functionality" in the greater sphere of applied computer science, and you certainly wouldn't find such a thing wandering around in the bowels of a Microsoft product.

Re:Gee, what do I know? (0)

Anonymous Coward | more than 9 years ago | (#10626757)

But what's it got to do with SMB fileserving??

Why would "providing DCOM functionality" slow down fileserving so much? The Linux server may quite as well be "providing CORBA functionality", but that wouldn't slow it down in the slightest if that functionality is not actually being used.

Re:Performance Charts (1)

macz (797860) | more than 9 years ago | (#10610963)

The article was a little wonky on testing methods, but overall they seemed geared towards trying to HELP microsoft's poor showing. The article makes the point, and I reiterate it here:
"If anyone knows how to really increase the performance of Windows 2003, let me know and I will create an addendum to this. Apparently there has to be some magic voodoo you can do to gain performance on Windows 2003 Server since Microsoft continually states that Windows 2003 outperforms Samba."

If his experiment is repeatable, then why is Microsoft so cocky about Win2k3 Server? Is there some hidden registry entry like HKEY_LOCALMACHINE/Software/Microsoft/Windows/Curen tVersion/Parameters/REG_SZ Suck="disabled"

Of course the default is "enabled"

Linux + Samba twice as fast as Windows 2003 (1)

1010011010 (53039) | more than 9 years ago | (#10611231)

From the article:
As you can see from the graphs, Novell's SLES9 pretty much more than doubles the performance of Microsoft's Windows 2003 Server on the exact same hardware in both categories. This is very, very impressive, and shows the strengths of both Samba and the Linux kernel, as well as the attention to detail Novell/Suse employees had when implementing the default settings.


With this hardware Windows 2003 Server seems to max out on performance at approximately 30 Clients with a throughput of about 135Mbps, where SLES seems to max out on performance at approximately 60 Clients with a throughput of about 255Mbps. The response time is also about twice as fast on SLES9 than on Win2k3 on the same hardware. So, in theory, you can handle twice as many clients on the same hardware using SLES9 compared to using Windows 2003 Server.
Linux+Samba still beat Windows Server on its home turf (file/print services), on the same hardware, by a lot. And Linux can do a whole lot more than just serve files and share printers.

Citations in the article (1)

SgtChaireBourne (457691) | more than 9 years ago | (#10618911)

One of the sources cited in the article is Wikipedia. It is cool and dynamic, but may not be the best thing to be citing in a published article which then remains unchanged. Afterall, some of the viewpoints or arguments put forth in the article are dependent on the content of what they point to. If that content changes too much, it can pull the rug out from under the article. With a static source it is nonetheless possible to link forward from the old citation to the new one. But having the content of the old citation change makes finding out who said what and when very difficult.

There are many reasons why Wikipedia is great [wikipedia.org] . Among those the content is constantly being added and changed (sometimes hundreds of times an hour) and that is one of its biggest weaknesses.

It's easy to undo [wikipedia.org] trolls, cranks, and obvious nonsense. However, more subtle nonsense, misinformation or omission of fact can be just as troublesome, maybe more so.

As very useful as Wikipedia is, a published (i.e. no further changes) article needs to point to a source thatl, right or wrong, remains the same. Not a slam on Wikipedia, rather a call for the right tool for the job.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...