SLES9 vs. Windows Server 2003 In A Windows Network
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.)
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.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
For those who want to go straight to the charts.
SuSE vs Windows 2003 Performance
At 60 users SuSE has 2.5 time the performance
of Windows 2003 server.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
There are many reasons why Wikipedia is great. 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 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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
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.
.NET functionality, Distributed File Systems, Event Services, you name it.
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,
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.
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.