Vista is cosmetic for the most part. No one needs to upgrade to Vista, point blank.
Actually, you've got it backwards. Vista is massively improved under the hood. It's a whole different beast inside. The update GUI is the least of it, and is just eye-candy.
I get tired of repeating all the major, massive internal improvements they made to Vista, so go look it up at wikipedia.
I'll leave it to you to read about them, but I'll list the bullet points that are significant:
Shadow Copy
Speech Recognition
ReadyBoost/ReadyDrive
New IP stack with native IPv6
SuperFetch
All new Windows Display Manager (WDDM), with much more in userspace
Kernel Transaction Manager (allows transactional NTFS and transactional registry)
UAC (I know, a mixed blessing to many, but it is better in many ways that RunAs and MakeMeAdmin, plus is possible for non-techies to use)
Protected Mode IE7
BitLocker whole disk encryption
Mandatory Access Controls on Services
Mandatory Integrity Control (integrity levels, cant move up them)
NAC/NAP client built in
x64-only: Kernel Patch Protection (this is overdue by 10 years)
Checksummed system files, tested on boot
ASLR and other buffer overflow protections
Very locked down ACLs by default
Improved Windows Firewall (bi-directional controls now)
Tons of drivers and driver layers moved to userspace
All new much higher precision audio layer (though some problems with existing apps out there, it is arguably vastly improved)
Vastly improved I/O scheduler (finally!!!!)
Finally has support for IPSec w/ AES (about damn time)
Tons of improvements to the network stack to auto-optimize for different network conditions (tcp scaling windows and such, but thats the last of it)
Imaging (this is huge in corporate-land), includes WIM, ImageX, Windows Deployment Services, WAIK, etc
Tons more group policy controls
TabletPC tech in all versions of Vista
Stealing some stuff right from wikipedia that I dont feel like re-typing:
The memory manager and processes scheduler have been improved. Many kernel data structures and algorithms have been rewritten. Lookup algorithms now run in constant time, instead of linear time as with previous versions.
Windows Vista includes support for condition variables and reader-writer locks.
Process creation overhead is reduced by significant improvements to DLL address-resolving schemes.
Windows Vista introduces a Protected Process [16], which differs from usual processes in the sense that other processes cannot manipulate the state of such a process, nor can threads from other processes be introduced in it. A Protected Process has enhanced access to DRM-functions of Windows Vista. However, currently, only the applications using Protected Video Path can create Protected Processes.
Thread Pools have been upgraded to support multiple pools per process, as well as to reduce performance overhead using thread recycling. It also includes Cleanup Groups that allow clean up of pending thread-pool requests on process shutdown.
Data Redirection: Also known as data virtualization, this virtualizes the registry and certain parts of the file system for applications running in the protected user context, enabling legacy applications to run in non-administrator accounts. It automatically creates private copies of files that an application can use when it does not have permission to access the original files. This facilitates stronger file security and helps applications not written with the least user access principle in mind to run under stronger restrictions. Registry virtualization isolates write operations that have a global impact to a per-user location. Reads and
Are these folks on one of Microsoft's licensing plans where they have to upgrade? There's no such thing, you've got it backwards.
Being on the licensing plan is one way to get guaranteed downgrade rights for long periods of time. This is as opposed to buying retail or OEM versions, which dont always give you downgrade rights, without buying the down-level software.
Usually, these plans basically say you're paying for an MS OS for every employee in the org, and MS doesnt particularly care which you run, so take your pick.
Now there's a downside to this.
MS can use this as a carrot/stick combination. I believe I know one org who was basically told by MS that if they didnt renew their enterprise subscription and include SA, then they would not get downgrade rights, which would force them to upgrade everywhere, as they would no longer be able to buy XP under their license (could always buy retail, but that doesnt work).
So in that situation, NOT buying into the enterprise license would force you to upgrade, but buying into the license/subscription lets you do whatever you want.
Take a look at this other Dell contribution on ZDNet , and you'll understand what I'm talking about. What is it that you find so offensive with this page? The bulk of the page is around helping organizations stop doing manual 'built-from-a-CD-by-a-tech' deployments, which is so common, and is so horrifically expensive.
Many, many organizations have a very specific need for help in that area. It will save them a ton of money over the long haul. I've been there and done that, and it really is huge.
So given that there are a ton of companies that are throwing their money away by using highly inefficient processes, why shouldnt Dell try to show them how to do it better and cheaper, and maybe make a new business partner?
No self-respecting CIO would turn to Dell for any advice. Maybe so, but that doesnt mean there aren't a ton of CIOs that are doing a poor job and could use some help. If the message and content is right, then what's the problem if its coming from Dell?
Even dumb people deserve someone out there helping them. If both sides profit in the exchange, then it sounds like a good thing. The only argument you are making that I can see is that (for some perspectives) there may be superior advice to be made by those pushing FOSS solutions.
I think what you may be missing is that the vast majority of the market is looking for a Windows solution. This stuff fills that need.
... there should be a market force pushing the business towards lower cost, such as GNU/Linux. You're making the unfounded assumption that a Linux solution will be materially cheaper than a Windows one, from a holistic perspective (ie, total IT costs over the lifetime).
This is not something you can just declare true and make it so across all situations. There are situations where a FOSS solution will do well, but its usually in a simple desktop environment, where processors of some sort work with LOB apps all day long and dont really need a general purpose computer.
But there are alot of situations where this is not going to be cheaper over the long haul. At least that's my perspective.
The bottom line is that it's not a simple 'Linux is cheaper, so why arent you using it?'. It's usually not that simple.
The cost of adding a powerful terminal server is similar to the cost of adding RAM to a bunch of clients and the labour of going around to each machine may be saved Thats questionable.
Let's say its a simple computing environment (which is ideal for a TS situation), and the desktops cost ~$600 a piece. A highly available clustered TS server is going to run at least $30,000, probably closer to $50,000.
So if your TS can handle significantly more than 75 desktops simultaneously, then it might be economically feasible. But thats a contrived situation, and not all are like that. There are plenty where the numbers just dont work.
I have actually provided a solid basis for my claims as well as solid logic which you have failed to refute. You know you really didnt though. You basically said, "avoiding vendor lockin is critical, and if you haven't figured that out, then you're incompetent." But you never actually explained where any of these costs come in.
The most concrete thing I saw was an issue of being 'forced to upgrade'. Yet by my view, there's no substantial difference between the two.
2.2 kernel linux boxes arent supported anymore by any of the distro's, and you'll have trouble getting much software to work with them, because of library dependencies. So yes, its possible to run that old of a FOSS platform, but there's really not much of a benefit in it. It's more of a pain in the butt than its worth.
The same is true of Windows. If you want to deal with some inconvenience, you can continue to use Win98 today. There will be some pain and inconvenience.
In either case, a well managed network will stay reasonably up to date, and never be too far behind the major versions. It's just not worth the pain.
I work in education where PHBs boast about being Wintel shops and there are classrooms with 0 or 1 PC in a classroom running that obsolete OS. It is all they can do to maintain a few labs where kids are scheduled to visit. If they used FLOSS, they could have twice as many PCs in schools and more peripherals for the same or less money. How do you figure not paying MS would result in 'twice as many PCs' in schools?
A typical corporate box runs $600-1000.
A Vista Business license costs $53. Win2003 Server Standard costs $87. Server CALs run ~$5 per user or device. Office 2007 Enterprise costs $70.
So a fully decked out windows desktop will cost the University ~$130 on top of hardware for Vista Business, Server CALs and Office 2007 Enterprise.
Thats not bad, and saving that $130 wont buy you another $600-1000 machine.
Now most schools that I know of that use things like RedHat or SLED pay those companies to use the products, and you know what? It's about the same price as to MS.
Some people have said that the "sweet spot" for Vista performance is FOUR gigs of RAM. Then you should stop listening to 'some people', as Vista 32-bit has the same 3-GB addressing space limitations as XP did. And plus its a nonsensical statement at face value.
Let's say that Vista's kernel is twice the size (in-memory) of XP, which on my box runs under 200MB. Now Vista will consume all available (unused) memory for a disk cache, but any memory pressure causes it to release memory for apps.
And this is correct behavior. Unused memory is wasted memory.
Numerous people have complained that it is dog slow on recent machines with 1-2GB of RAM, depending on applications mix, even a minimal applications mix. Again, you should be careful who you listen to. Office 2007 running on Vista wont use any more memory than it does running on XP. So if you've got some 2GB machines running great, and some 2GB machines running slowly, then its probably not a memory constraint.
So a 2GB machine that runs 'dog slow' on Vista has got other problems, like faulty drivers, faulty or misconfigured anti-virus, or other issues.
It may take another ten years, but sooner or later corporations are going to get seriously sick of this nonsense - and the backlash will put quite a few large IT companies out of business abd provide a major boost to OSS. Corps dont deal with this at all.
Most medium or larger corps, the process goes like this.
1. Buy new machine. 2. Receive new machine. 3. Before ever booting machine with factory image, drop it on the build lan, and image your corporate deployment of XP to it, using your VL media and keys. 4. Deploy machine.
Takes about 2 hours total, with about 15 minutes of low-level techie time.
Then every year, they 're-up' their headcount with MS for licensing costs....
So, unfortunately, the only people this kind of nonsense hurts is the home users who dont know any better. Which is a real shame.
Why didn't they use ODF? Or, failing that, why didn't they create a better standard, or fully spec out the one they've got? They didnt use ODF because ODF and OOXML are not isomorphic. You cannot do a lossless translation of one to another. Each contains features that the other does not (though this is mostly true on the OOXML side).
In addition, what if MS wants to add a new feature to Office (ie, word, excel, etc) that is not supported in ODF. If they only use ODF, then all of a sudden they are limited to what new innovations they can create around the office apps. They're forced into a lowest-common denominator situation. Makes it hard to differentiate your product.
If you ask them, they did create a better standard. And thats supportable from some perspectives (ie, number of features).
They did fully spec out what they've got. In the backwards compatibility cases, you're explicitly instructed in the spec to do what they do, and upconvert it to something else.
Well, partially because I wrote an ODS->CSV converter, and it was 216 lines long - in C++:) I know just how simple the OpenOffice formats are - they're really, really simple. Did you implement 100% of the ODF spec? Can it convert any arbitrarily complex document that meets the spec into CSV? How does it convert graphics to CSV?
I'm not trying to be an ass here, but that seems to be the standard that OOXML is being held to, so I'm looking for some consistency.
Everything I've heard about the format says that it's technically an open format... So wait, you're involved in an argument about the fitness of a standard spec that you've never even looked at?
... ODF is an open standard which means that anyone can generate their own ODF reader and writer. In fact, every computer on the market right now can basically read ODF (in a primitive way), since any modern OS can extract a zip archive and read the plaintext that is inside. Yes, ODF is really that open! You can read it and work with it with very simple tools. This is exactly the case with OOXML as well. It's the same setup. Open standard, stored as XML file(s) then zipped up.
The point with ODF is that you are not locked in. It is so open that it is very easy to convert your data, using a wide variety of tools (many of them freely available). The same cannot be said for MS's offering... which is why it cannot be legitimately called "open"... What is it about OOXML that is not open here? The only part of the spec that doesnt have enough details to implement are bug-preserving corner-cases from old versions. And MS SPECIFICALLY says in the spec that you should not implement these, they're only there as a marker, so you can convert to something else. You're very specifically instructed NOT to implement those tags, because they shouldnt be preserved.
And if you've read the spec, it seems doubtful anything but MS Office can implement it fully. This is a very important point that everyone seems to be missing.
Very few implementations (other than the impl of those who created the standard) ever 'fully' implement a spec. Google docs dont fully implement ODF, only a subset. In fact, I think you'll find that the bulk of those you listed dont fully implement the spec. They just implement the parts that they think are relevant to their target audience.
And as long as its a proper subset, it doesnt matter, because it will still be interoperable.
Yet, we have the same situation with OOXML, where there are sections that no one (except MS) will probably ever implement. But we also have the important subset of the spec that most people care about, and anyone is welcome to implement that. You dont have to implement every single bug-preserving corner-case of a spec in order to have 'implemented' it.
Heck, look at PDF. The third party implementations only do a tiny subset of the spec (and usually just of PDF-X, which is in itself a tiny subset of PDF), but that seems to work out okay.
Electricity is largely fungible once its in your house. You can power a lamp, a TV, a refrigerator, etc. Whether the standard is 110v or 132v doesnt fundamentally change what you can do with it, as long as you get it in the standard way.
There are fundamental things different about OOXML and ODF however. OOXML contains features and functionality that ODF does not (both bad and good). So you can fundamentally do things with OOXML that you cannot in ODF, because its part of one standard and not part of another.
The analogy would only work if 110v worked on lamps and tvs, but 132v only worked on lamps.
TPM doesnt take away control from you, it gives you (as the machine owner/manager) much more power over what happens.
For example, it gives you, as the company who owns/manages the box, a stable and trusted piece of hardware to do encryption/decryption/signing, along with a key such as a USB drive or a smart-card.
Without something like this, its hard to trust, as the OS could be compromised, but (at least in theory) its much harder (nearly impossible) to crack the TPM hardware.
Of course, if these guys have the real thing, then the current gen of TPM may be blown out of the water.
Actually, at least by my read of your own statement, that makes this not a matter of fundamental science, but one of engineering & economics.
Now it may not be economically practical to make one now, or in the future, but it seems based on these 'back of the cocktail napkin' numbers that its possible. It's just not practical.
And hell, deciding to do something when not all the fundamental research pieces were there has been done. The inital space race to the moon required (as I understand it at least, cant cite a source off the top of my head) the invention of a number of things from whole cloth that had not existed before.
Now clearly, that made the race to the moon an 'engineering & economics' problem as well.
But I havent seen anything yet that makes a space elevator fundamentally impossible. It may or may not be impractical today (because of engineering & economic limitations) but it appears to be possible.
And its not like they're tricking anyone into investing in them. And its not like they acquired more than a paltry seed fund of investment anyway, other than from the founders themselves.
If your in a position to MITM, you can often force the clients down to using LM auth unless that's been explicitely disabled... Agreed, which is why you've got to disable the older methods via group policy or local policy. Unfortunately, a surprisingly small number of shops do this.
Arent the windows "ipsec" policies just filtering rules? Or do they actually encrypt/authenticate the traffic in some way? Either way, i've hardly ever seen anyone bother. You can use them as a poor-man's firewall as you describe, but thats mostly a side effect of its normal usage. When used as intended, you can very easily configure a machine to only respond via network traffic to any other machine who can create an encrypted tunnel (you can also do just authentication if you want). It's a full blown ipsec implementation.
We've used it in the past a number of times, for example, to restrict who can talk to a sensitive database server to only some select machines. Just a nice added layer of protection. Pretty easy to implement as well.
As for the hashing, it's relatively weak and fast to crack compared to other comparable authentication methods, it's unsalted for instance which is why rainbow tables work. Unsalted, yes. Weak hashing, no. It's not computationally possible (with any publicly known math at least, who knows what the NSA or such has up their sleeve) to reverse NTLMv2 hashes. Rainbow tables dont reverse the hash, they just repeat the known implementation of the hash to pre-compute all possible hash results within a keyspace.
At least that is my understanding. If you're aware of any way to reverse the NTLMv2 hash, I'd love to know.
The salting issues is an interesting one. It's what lets cross-domain (or cross-machine in a non-domain situation) user/pass combos work if the user/pass is the same on both sides. So a nice usability thing, but probably not the best solution in this day.
There are techniques such as using syskey to deal with an offline recovery attack (encrypts the sam), but there is not, to my knowledge, any way to use a unique salt in the hash. Which is a shame.
Security is just a matter of configuration. Oh, my. You've never actually run an MS based externally facing server, have you? Yes. Been doing Windows consulting, systems administration, development, what have you, for about 10 years. Have at various times supported medium (small to low thousands, havent done so in an org larger than a few thousand) sized windows installations. So not huge, but plenty of bigger than small business.
My expertise (up until ~2 years ago, which has been almost exclusively development) was IIS & SQL, with some hefty Exchange admin experience thrown in. All of these (except SQL and the DCs) were publicly available to some extent, ie the required minimum ports available to the world. So 25 inbound on Exchange MTAs, 80/443 on the OWA servers, and 80/443 on the IIS boxen. Sometimes DNS on the DCs in the olden days, but thats dangerous too nowadays, with most orgs doing split-brained dns on bind external, windows internal.
All OS management is formulaic. You do the research, create the most secure configuration you can that satisfies your needs. Identify risk vectors, develop a mitigation and monitoring plan to deal with it. Then you put together operational procedures to manage (ie, patch, deploy, upgrade) and audit (did patches apply, is the configuration in expected state, who logged in when, other log monitoring, etc). It's only complicated if its your first time and you have no mentors. Otherwise, you just take your proven best practices, and repeat them, with the occasional revamp/improvement as the platforms change or the environment changes.
Basic Exchange Server 5.0 couldn't handle simultaneous incoming port 25 connections. Period, end of sentence, it wasn't fixed properly until about 5.5. Well, that may be true, but you're reaching pretty far into the past there. That version only existed between May and November of 1997. Since then have been 5.5 (the first version that was doable for Small and Mid-sized orgs) in 1997-200, Exchange 2000 from 2000-2003, Exchange 2003 from 2003-2007, and Exchange 2007 currently. Given that since Exchange 2000, Exchange has been one of the most commonly seen collaboration (ie, mail & calendar) setups in big business, I think issues like you mention can be considered 'very old history'.
(Mind you, all big installations separate out the store servers, mta servers, and client connectivity servers (IIS & MAPI), as this provides effectively infinite scalability at only the needed layer. Some use unix-based mta's for that layer, some dont.)
Then I had to explain about rewriting the envelopes of the messages correctly, so that the external and internal mail servers were distinguishable for debugging reasons but the user still saw their mail to the correct "From:" line I believe this is only an issue if you're using non-exchange systems for your external MTAs. If its all Exchange, then the Message Tracking system shows clearly the progression through servers and layers. Same if your external email address isnt necessarily the same as your username@domain.name, if you're on a full exchange stack, this 'just works'. Not sure of the behavior if you have non-exchange MTAs re-writing the envelopes. But this is a commonly enough done thing, that I'm sure its well documented through google.:)
That was a long, painful week the last time I did this. They finally gave up and bought some Linux based external spam filters, which did the job very nicely. In my experience, we've always preferred to use SpamAssassin on our exchange environments, combined with rules in Outlook itself (and SpamBayes for those with some technical ability plus extra anti-spam needs). SpamAssassin on Exchange is interesting to setup, but works quite well. The only real problem is scalability, with Perl's lovely one perl.exe process per email. This would only scale in large organizations on dedicated boxes acting as mta's.
In the home user environment, I agree with you completely. MS does a bad job with the defaults. UAC in Vista is their (very belated) attempt to fix this in all environments (including the home).
But in the corporate environment (what we're talking about here), defaults are meaningless. You're right in that users should not (and do not) have to know about the details of computer security. Thats why you have an IT staff. Their job is to give the users the tools to do their jobs, and keep them secure and available. For an IT professional in this capacity, doing this on windows is a straightforward task.
But my argument is how your corporate environment is configured and deployed. In that scenario, there is no excuse for running as root for daily usage. Regardless of whether you're on Unix, Linux, BSD, OSX, or Windows.
... is close to fed up with Outlook/Exchange. By my read of the article, he clearly likes and finds invaluable Outlook+Exchange. What he hates is not having Outlook+Exchange on other platforms.
If he didnt like Outlook+Exchange (or any of the fancy features therein), he would just be able to trivially switch to Thunderbird on IMAP, and his problems go away. The fact that this is not even on the table tells me that for him, Outlook+Exchange is compelling.
Of course, we're all just speculating here, but it seems clear to me that he wasnt interested in giving up the functionality of Outlook+Exchange, just wanted it on a different platform.
I wouldnt exactly called NTLM a secure form of authentication What about it do you not find to be secure? It's a relatively straightforward challenge-response, that doesnt ever pass actual passwords (or anything convertible to a password) across the networks, and uses a strong hash implementation.
The modern version of NTLM (NTLMv2) is quite robust, and does not have any trivial attacks, other than massive brute-force approaches (of either the time-based dictionary attacks type, or the storage based rainbow-tables approach).
Mind you, if you still have all the legacy protocols turned on, then you may have problems (ie, LM, NTMLv1, etc).
Plus that means you need to expose all the overly complex rpc and netbios services to the network, and there really is a whole mess of code implementing those functions. Plenty of scope for more security vulnerabilities to be found in those thousands of lines of code.
On the other hand, SSH is relatively small, it's authentication and encryption is tried and tested, so you only expose a relatively small footprint to the network. Anything else can be piped over it, and done in the same way it would have been done locally. If you're concerned about this in a Windows environment, you just create some IPSec policies, and only allow this traffic. Then you use the ipsec policy to only allow your trusted, known, 'admin' workstations or subnets access to the servers or other desktops.
A firewall-based ipsec vpn tunnel is effectively the same thing, just moves the tunnel endpoint to the firewall, rather than the servers.
probably something along the lines of a shell script that sits on the server that I can change when I want. Including doing things like logging in to the client installing software as root and other such niceties You can do that on windows if you want. In an AD environment, there are simpler, more 'declarative' ways of doing most (though not all) of these things through AD, but falling back to scripting is always there.
On Linux and OSX you can write a script that runs when connected to the Internet accesses a password protected encrypted web page, revealing a copy of a script to run locally, then run that script locally. That's pretty straightforward to do on Windows as well. Scripting is scripting. The flavors are different, but on all the major OSs you can do any arbitrarily complex or ugly thing via scripting. Some things are simpler on some platforms than others, etc, but its really not that big of a deal.
They're very expensive, they take expensive hardware to make physically robust, maintaining security for them is dreadful, they can't take much standard SMTP load, and they blue screen of death frequently (though less frequently than they used to, I admit). Well that I find hard to respond to. I would build out exactly the same hardware, whether I was going to run sendmail or exchange as an mta. Probably lightweight 2-socket, 2-gb, 2-drive w/ raid 1, in a 1U box. Those are only a couple thousand each, and then you stack as many as you need to handle load.
Security is security, its no different than any other box on your data center. You should already know how to lock it down by this point, so you just do it. What's the big deal? It's just a matter of configuration.
As far as BSOD.... I cant even fathom what you're doing. In my experience, running actual server hardware and managed professionally, you'll see ~1 BSOD for every ~20 server-years. Based purely on my experience mind you, but its pretty darned rare.
Are you, by any chance, basing your experience on Exchange 5.5 or earlier?
Also note: there is no such thing as "no store" MTA's. You *MUST* have storage, to deal with temporary bounces when downstream MTA's go down. Sorry, I thought since you had experience with managing Exchange, that you would recognize the lingo. Exchange MTAs do not have an Exchange 'Store'. Only the mailbox servers have those.
Exchange MTAs cache incoming mail in the file-system (havent migrated over to 2007, so dont know if this changed there or not yet). So yes, there is a mail data 'store', but not an Exchange 'Store' on MTAs.
So what you're saying is that Windows XP is stable as long as you don't use it. No, windows is stable as long as you use it correctly.
On your Linux box, do you run as root, browse the web (as root) with Firefox unpatched carrying known drive-by vulns, download arbitrary software off bittorrent and run it as root?
I'll tell you, 95% of the windows security and reliability problems go away if you run as non-admin. No drive-by owning of the box. No auto-loading of rootkits from pen-drives and CD-roms. No auto-owning of the box when you're using a 10-year old vulnerable version of office, and passing macro-laden files around. No more installing of rootkits when someone tries (and fails) to install that crappy rootkit of a screensaver program.
All you need to do is to run the windows box THE SAME WAY AS YOU WOULD RUN ANY OTHER OS. You dont do your daily usage in root, you use su/sudo (runas/makemeadmin in windows) when you need to do administrative tasks. (Yes, runas and makemeadmin are a bit less elegant than su/sudo, but they work, and regular users wont need them anyway, on a properly managed box.)
You keep up on patches.
And then, about the only difference on windows, is that for many users its smart to use an A/V program, just avoid Symantec/Norton and McAfee. They're basically rootkits that root your box first in order to block other rootkits. But the side-effect is massive system instability. So just use something simple and effective like kaspersky, sophos, trend-micro, etc.
Slashdot Mirror
There are tons of reasons, huge, significant improvements under the hood.
7 62059
I'm sick of re-typing it all, but there's a pretty large list in a previous post today, take a look.
http://slashdot.org/comments.pl?sid=245695&cid=19
Vista is cosmetic for the most part. No one needs to upgrade to Vista, point blank.
Actually, you've got it backwards. Vista is massively improved under the hood. It's a whole different beast inside. The update GUI is the least of it, and is just eye-candy.
I get tired of repeating all the major, massive internal improvements they made to Vista, so go look it up at wikipedia.
I'll leave it to you to read about them, but I'll list the bullet points that are significant:
Stealing some stuff right from wikipedia that I dont feel like re-typing:
Being on the licensing plan is one way to get guaranteed downgrade rights for long periods of time. This is as opposed to buying retail or OEM versions, which dont always give you downgrade rights, without buying the down-level software.
Usually, these plans basically say you're paying for an MS OS for every employee in the org, and MS doesnt particularly care which you run, so take your pick.
Now there's a downside to this.
MS can use this as a carrot/stick combination. I believe I know one org who was basically told by MS that if they didnt renew their enterprise subscription and include SA, then they would not get downgrade rights, which would force them to upgrade everywhere, as they would no longer be able to buy XP under their license (could always buy retail, but that doesnt work).
So in that situation, NOT buying into the enterprise license would force you to upgrade, but buying into the license/subscription lets you do whatever you want.
Many, many organizations have a very specific need for help in that area. It will save them a ton of money over the long haul. I've been there and done that, and it really is huge.
So given that there are a ton of companies that are throwing their money away by using highly inefficient processes, why shouldnt Dell try to show them how to do it better and cheaper, and maybe make a new business partner? No self-respecting CIO would turn to Dell for any advice. Maybe so, but that doesnt mean there aren't a ton of CIOs that are doing a poor job and could use some help. If the message and content is right, then what's the problem if its coming from Dell?
Even dumb people deserve someone out there helping them. If both sides profit in the exchange, then it sounds like a good thing. The only argument you are making that I can see is that (for some perspectives) there may be superior advice to be made by those pushing FOSS solutions.
I think what you may be missing is that the vast majority of the market is looking for a Windows solution. This stuff fills that need.
... there should be a market force pushing the business towards lower cost, such as GNU/Linux. You're making the unfounded assumption that a Linux solution will be materially cheaper than a Windows one, from a holistic perspective (ie, total IT costs over the lifetime).This is not something you can just declare true and make it so across all situations. There are situations where a FOSS solution will do well, but its usually in a simple desktop environment, where processors of some sort work with LOB apps all day long and dont really need a general purpose computer.
But there are alot of situations where this is not going to be cheaper over the long haul. At least that's my perspective.
The bottom line is that it's not a simple 'Linux is cheaper, so why arent you using it?'. It's usually not that simple. The cost of adding a powerful terminal server is similar to the cost of adding RAM to a bunch of clients and the labour of going around to each machine may be saved Thats questionable.
Let's say its a simple computing environment (which is ideal for a TS situation), and the desktops cost ~$600 a piece. A highly available clustered TS server is going to run at least $30,000, probably closer to $50,000.
So if your TS can handle significantly more than 75 desktops simultaneously, then it might be economically feasible. But thats a contrived situation, and not all are like that. There are plenty where the numbers just dont work.
The most concrete thing I saw was an issue of being 'forced to upgrade'. Yet by my view, there's no substantial difference between the two.
2.2 kernel linux boxes arent supported anymore by any of the distro's, and you'll have trouble getting much software to work with them, because of library dependencies. So yes, its possible to run that old of a FOSS platform, but there's really not much of a benefit in it. It's more of a pain in the butt than its worth.
The same is true of Windows. If you want to deal with some inconvenience, you can continue to use Win98 today. There will be some pain and inconvenience.
In either case, a well managed network will stay reasonably up to date, and never be too far behind the major versions. It's just not worth the pain.
A typical corporate box runs $600-1000.
A Vista Business license costs $53. Win2003 Server Standard costs $87. Server CALs run ~$5 per user or device. Office 2007 Enterprise costs $70.
So a fully decked out windows desktop will cost the University ~$130 on top of hardware for Vista Business, Server CALs and Office 2007 Enterprise.
Thats not bad, and saving that $130 wont buy you another $600-1000 machine.
Now most schools that I know of that use things like RedHat or SLED pay those companies to use the products, and you know what? It's about the same price as to MS.
Let's say that Vista's kernel is twice the size (in-memory) of XP, which on my box runs under 200MB. Now Vista will consume all available (unused) memory for a disk cache, but any memory pressure causes it to release memory for apps.
And this is correct behavior. Unused memory is wasted memory. Numerous people have complained that it is dog slow on recent machines with 1-2GB of RAM, depending on applications mix, even a minimal applications mix. Again, you should be careful who you listen to. Office 2007 running on Vista wont use any more memory than it does running on XP. So if you've got some 2GB machines running great, and some 2GB machines running slowly, then its probably not a memory constraint.
So a 2GB machine that runs 'dog slow' on Vista has got other problems, like faulty drivers, faulty or misconfigured anti-virus, or other issues.
Most medium or larger corps, the process goes like this.
1. Buy new machine.
2. Receive new machine.
3. Before ever booting machine with factory image, drop it on the build lan, and image your corporate deployment of XP to it, using your VL media and keys.
4. Deploy machine.
Takes about 2 hours total, with about 15 minutes of low-level techie time.
Then every year, they 're-up' their headcount with MS for licensing costs.
So, unfortunately, the only people this kind of nonsense hurts is the home users who dont know any better. Which is a real shame.
In addition, what if MS wants to add a new feature to Office (ie, word, excel, etc) that is not supported in ODF. If they only use ODF, then all of a sudden they are limited to what new innovations they can create around the office apps. They're forced into a lowest-common denominator situation. Makes it hard to differentiate your product.
If you ask them, they did create a better standard. And thats supportable from some perspectives (ie, number of features).
They did fully spec out what they've got. In the backwards compatibility cases, you're explicitly instructed in the spec to do what they do, and upconvert it to something else.
I'm not trying to be an ass here, but that seems to be the standard that OOXML is being held to, so I'm looking for some consistency. Everything I've heard about the format says that it's technically an open format
... ODF is an open standard which means that anyone can generate their own ODF reader and writer. In fact, every computer on the market right now can basically read ODF (in a primitive way), since any modern OS can extract a zip archive and read the plaintext that is inside. Yes, ODF is really that open! You can read it and work with it with very simple tools. This is exactly the case with OOXML as well. It's the same setup. Open standard, stored as XML file(s) then zipped up. The point with ODF is that you are not locked in. It is so open that it is very easy to convert your data, using a wide variety of tools (many of them freely available). The same cannot be said for MS's offering... which is why it cannot be legitimately called "open"Very few implementations (other than the impl of those who created the standard) ever 'fully' implement a spec. Google docs dont fully implement ODF, only a subset. In fact, I think you'll find that the bulk of those you listed dont fully implement the spec. They just implement the parts that they think are relevant to their target audience.
And as long as its a proper subset, it doesnt matter, because it will still be interoperable.
Yet, we have the same situation with OOXML, where there are sections that no one (except MS) will probably ever implement. But we also have the important subset of the spec that most people care about, and anyone is welcome to implement that. You dont have to implement every single bug-preserving corner-case of a spec in order to have 'implemented' it.
Heck, look at PDF. The third party implementations only do a tiny subset of the spec (and usually just of PDF-X, which is in itself a tiny subset of PDF), but that seems to work out okay.
Thats a terrible analogy.
Electricity is largely fungible once its in your house. You can power a lamp, a TV, a refrigerator, etc. Whether the standard is 110v or 132v doesnt fundamentally change what you can do with it, as long as you get it in the standard way.
There are fundamental things different about OOXML and ODF however. OOXML contains features and functionality that ODF does not (both bad and good). So you can fundamentally do things with OOXML that you cannot in ODF, because its part of one standard and not part of another.
The analogy would only work if 110v worked on lamps and tvs, but 132v only worked on lamps.
TPM doesnt take away control from you, it gives you (as the machine owner/manager) much more power over what happens.
For example, it gives you, as the company who owns/manages the box, a stable and trusted piece of hardware to do encryption/decryption/signing, along with a key such as a USB drive or a smart-card.
Without something like this, its hard to trust, as the OS could be compromised, but (at least in theory) its much harder (nearly impossible) to crack the TPM hardware.
Of course, if these guys have the real thing, then the current gen of TPM may be blown out of the water.
I'm assuming here that in your words, 'Full disk encryption' is the same as 'Whole disk encryption'.
Wikipedia also shows that Seagate has a product as well. But I'm not aware of a single open-source 'full disk encryption' implementation out there.
Note that software like TrueCrypt, while amazing, and useful pieces of software, do not do whole disk encryption.
Actually, at least by my read of your own statement, that makes this not a matter of fundamental science, but one of engineering & economics.
Now it may not be economically practical to make one now, or in the future, but it seems based on these 'back of the cocktail napkin' numbers that its possible. It's just not practical.
And hell, deciding to do something when not all the fundamental research pieces were there has been done. The inital space race to the moon required (as I understand it at least, cant cite a source off the top of my head) the invention of a number of things from whole cloth that had not existed before.
Now clearly, that made the race to the moon an 'engineering & economics' problem as well.
But I havent seen anything yet that makes a space elevator fundamentally impossible. It may or may not be impractical today (because of engineering & economic limitations) but it appears to be possible.
And its not like they're tricking anyone into investing in them. And its not like they acquired more than a paltry seed fund of investment anyway, other than from the founders themselves.
We've used it in the past a number of times, for example, to restrict who can talk to a sensitive database server to only some select machines. Just a nice added layer of protection. Pretty easy to implement as well. As for the hashing, it's relatively weak and fast to crack compared to other comparable authentication methods, it's unsalted for instance which is why rainbow tables work. Unsalted, yes. Weak hashing, no. It's not computationally possible (with any publicly known math at least, who knows what the NSA or such has up their sleeve) to reverse NTLMv2 hashes. Rainbow tables dont reverse the hash, they just repeat the known implementation of the hash to pre-compute all possible hash results within a keyspace.
At least that is my understanding. If you're aware of any way to reverse the NTLMv2 hash, I'd love to know.
The salting issues is an interesting one. It's what lets cross-domain (or cross-machine in a non-domain situation) user/pass combos work if the user/pass is the same on both sides. So a nice usability thing, but probably not the best solution in this day.
There are techniques such as using syskey to deal with an offline recovery attack (encrypts the sam), but there is not, to my knowledge, any way to use a unique salt in the hash. Which is a shame.
My expertise (up until ~2 years ago, which has been almost exclusively development) was IIS & SQL, with some hefty Exchange admin experience thrown in. All of these (except SQL and the DCs) were publicly available to some extent, ie the required minimum ports available to the world. So 25 inbound on Exchange MTAs, 80/443 on the OWA servers, and 80/443 on the IIS boxen. Sometimes DNS on the DCs in the olden days, but thats dangerous too nowadays, with most orgs doing split-brained dns on bind external, windows internal.
All OS management is formulaic. You do the research, create the most secure configuration you can that satisfies your needs. Identify risk vectors, develop a mitigation and monitoring plan to deal with it. Then you put together operational procedures to manage (ie, patch, deploy, upgrade) and audit (did patches apply, is the configuration in expected state, who logged in when, other log monitoring, etc). It's only complicated if its your first time and you have no mentors. Otherwise, you just take your proven best practices, and repeat them, with the occasional revamp/improvement as the platforms change or the environment changes. Basic Exchange Server 5.0 couldn't handle simultaneous incoming port 25 connections. Period, end of sentence, it wasn't fixed properly until about 5.5. Well, that may be true, but you're reaching pretty far into the past there. That version only existed between May and November of 1997. Since then have been 5.5 (the first version that was doable for Small and Mid-sized orgs) in 1997-200, Exchange 2000 from 2000-2003, Exchange 2003 from 2003-2007, and Exchange 2007 currently. Given that since Exchange 2000, Exchange has been one of the most commonly seen collaboration (ie, mail & calendar) setups in big business, I think issues like you mention can be considered 'very old history'.
(Mind you, all big installations separate out the store servers, mta servers, and client connectivity servers (IIS & MAPI), as this provides effectively infinite scalability at only the needed layer. Some use unix-based mta's for that layer, some dont.) Then I had to explain about rewriting the envelopes of the messages correctly, so that the external and internal mail servers were distinguishable for debugging reasons but the user still saw their mail to the correct "From:" line I believe this is only an issue if you're using non-exchange systems for your external MTAs. If its all Exchange, then the Message Tracking system shows clearly the progression through servers and layers. Same if your external email address isnt necessarily the same as your username@domain.name, if you're on a full exchange stack, this 'just works'. Not sure of the behavior if you have non-exchange MTAs re-writing the envelopes. But this is a commonly enough done thing, that I'm sure its well documented through google.
In the home user environment, I agree with you completely. MS does a bad job with the defaults. UAC in Vista is their (very belated) attempt to fix this in all environments (including the home).
But in the corporate environment (what we're talking about here), defaults are meaningless. You're right in that users should not (and do not) have to know about the details of computer security. Thats why you have an IT staff. Their job is to give the users the tools to do their jobs, and keep them secure and available. For an IT professional in this capacity, doing this on windows is a straightforward task.
But my argument is how your corporate environment is configured and deployed. In that scenario, there is no excuse for running as root for daily usage. Regardless of whether you're on Unix, Linux, BSD, OSX, or Windows.
... is close to fed up with Outlook/Exchange. By my read of the article, he clearly likes and finds invaluable Outlook+Exchange. What he hates is not having Outlook+Exchange on other platforms.If he didnt like Outlook+Exchange (or any of the fancy features therein), he would just be able to trivially switch to Thunderbird on IMAP, and his problems go away. The fact that this is not even on the table tells me that for him, Outlook+Exchange is compelling.
Of course, we're all just speculating here, but it seems clear to me that he wasnt interested in giving up the functionality of Outlook+Exchange, just wanted it on a different platform.
The modern version of NTLM (NTLMv2) is quite robust, and does not have any trivial attacks, other than massive brute-force approaches (of either the time-based dictionary attacks type, or the storage based rainbow-tables approach).
Mind you, if you still have all the legacy protocols turned on, then you may have problems (ie, LM, NTMLv1, etc). Plus that means you need to expose all the overly complex rpc and netbios services to the network, and there really is a whole mess of code implementing those functions. Plenty of scope for more security vulnerabilities to be found in those thousands of lines of code.
On the other hand, SSH is relatively small, it's authentication and encryption is tried and tested, so you only expose a relatively small footprint to the network. Anything else can be piped over it, and done in the same way it would have been done locally. If you're concerned about this in a Windows environment, you just create some IPSec policies, and only allow this traffic. Then you use the ipsec policy to only allow your trusted, known, 'admin' workstations or subnets access to the servers or other desktops.
A firewall-based ipsec vpn tunnel is effectively the same thing, just moves the tunnel endpoint to the firewall, rather than the servers.
Security is security, its no different than any other box on your data center. You should already know how to lock it down by this point, so you just do it. What's the big deal? It's just a matter of configuration.
As far as BSOD
Are you, by any chance, basing your experience on Exchange 5.5 or earlier? Also note: there is no such thing as "no store" MTA's. You *MUST* have storage, to deal with temporary bounces when downstream MTA's go down. Sorry, I thought since you had experience with managing Exchange, that you would recognize the lingo. Exchange MTAs do not have an Exchange 'Store'. Only the mailbox servers have those.
Exchange MTAs cache incoming mail in the file-system (havent migrated over to 2007, so dont know if this changed there or not yet). So yes, there is a mail data 'store', but not an Exchange 'Store' on MTAs.
On your Linux box, do you run as root, browse the web (as root) with Firefox unpatched carrying known drive-by vulns, download arbitrary software off bittorrent and run it as root?
I'll tell you, 95% of the windows security and reliability problems go away if you run as non-admin. No drive-by owning of the box. No auto-loading of rootkits from pen-drives and CD-roms. No auto-owning of the box when you're using a 10-year old vulnerable version of office, and passing macro-laden files around. No more installing of rootkits when someone tries (and fails) to install that crappy rootkit of a screensaver program.
All you need to do is to run the windows box THE SAME WAY AS YOU WOULD RUN ANY OTHER OS. You dont do your daily usage in root, you use su/sudo (runas/makemeadmin in windows) when you need to do administrative tasks. (Yes, runas and makemeadmin are a bit less elegant than su/sudo, but they work, and regular users wont need them anyway, on a properly managed box.)
You keep up on patches.
And then, about the only difference on windows, is that for many users its smart to use an A/V program, just avoid Symantec/Norton and McAfee. They're basically rootkits that root your box first in order to block other rootkits. But the side-effect is massive system instability. So just use something simple and effective like kaspersky, sophos, trend-micro, etc.