In my company, god forbid I try to stop some vp from installing barney's latest adventure for their five year old, next thing you know the ceo's asking my boss why I hate america so much.
The thing is, I hear what you are saying. One thing I think that helped was the company had a very technically saavy CEO. As a privately held company, the company had started with a very minor IT position for its employees; terminal based computing running off an IBM mainframe. It was a great system, but finally, too much was required of it. They spent about $20M on their first 25 years of IT; so when business requirements finally forced a major upgrade in the way they operated it was a $50M dollar investment. That's so much money, nothing was left to chance. The rollout happened after 36 months of intense planning. Of that budget, 3% (2.5M) was laid out for pre-deployment testing and planning. They did a dry run in an offsite facility two weeks in a row before the deployment.
I know. It was the best IT environment I've had the pleasure to work in. Everyone was onboard. So much so we had MS bigwigs touring our facility 6 months after a deployment. We were featured on their website as a case study for a while, until they refuesed to upgrade to XP on MS's schedule, that is:-)
We provided Internet access and e-mail. Users were allowed by policy to use the e-mail for personal purposes. We even provided webmail for outside the company access!
The desktops were completely locked down. Each one was one of three templates software wise. Weekly automated re-imaging (Saturday mornings, 2:00 am, machines in 250 count waves would begin reloading, taking about 6-7 minutes a piece to complete; all would be done in about 20 hrs).
Every user could run only pre-approved binaries enforced by group policy. No one, and absolutely no one, ran as administrator of anything (PC, domain, whatever).
It was a tight ship. All web content went through a proxy server and was aggressively filtered for nasty bits.
1. No users ran with admin privelages, ever. That is huge, huge, huge. Even when I was logged in to a dev box, I was was not an administrator of anything. We heavily used RunAs techniques for slightly privelaged operations.
2. We used group policies to specify exactly which binaries a specific user or group of users could run. This is also huge.
3. ActiveX completely disabled.
4. All web content went through our web proxy, which aggresively filtered out potential problems.
5. Aggressive use of known good machine images. Each machine was literally one of 3 templates. We could log a user off remotely, reboot the box from the network RIS server, reload his/her machine image template, boot back up, log the user back in, and they'd never know that their entire hard drive had been erased, the OS and apps recopied, and reset. That process was an extreme measure, but it took about 6 minutes, start to finish. It was like a slightly longer version of a reboot to users.
Finally, it's worth noting, we never had an anti-virus package on the workstations, only on the mail server to scan incoming and outgoing mail. We used no anti-spyware packages! We ran two eight-hour shifts (big servicing center for a major worldwide insurance company) each with about 50K users. The users had "unrestricted" in a technical sense internet access - outgoing ports were watched but not restricted (we let them have an IM package installed, for those lulls in the action), and everything went through a proxy server, but otherwise, there was nothing stopping them from trying to visit any old dark corner.
Seriously: good IT policy uniformly set across the network (no exceptions for VIPs, the CEO, or the CIO), quality standard hardware, the best software products, and a liberal amount of scripting, testing, and process management. That's all it takes.
I HAVE actually managed a huge Windows-only network (50K Win2k machines, 100K users, 80 servers), and I tend to agree with the original poster.
I was at the "helm" as a consultant turned IT manager/overseer while a full nationwide exec search was conducted to permantely fill the position for just about 11 months. The previous exec literally dropped dead a few days before an entire network upgrade: all new workstations, servers, cabling, routing equipment, and software packages went into effect. Four full timers on IT, 5 half-timers (24 hrs a week) on help-desk, and me.
In my time, we never had (1) any problems with patching, (2) a single piece of spyware found on any machine, (3) a single virus or worm or other such outbreak of unauthorized software, (4) any data loss or corruption and (5) a single BSOD. I had a core group of 12 servers that were "mission critical", whose uptime from the day I started to the day my replacement came aboard was perfect.
The point being, that your mileage may vary. With everything in this industry, YMMV. It should be stamped. We did BIOS upgrades, we had hordes of clueless users, we had clueless employees - the same problems as anyone else had. But we never let MS or Dell or anyone be our scapegoats, and we ended up really really meeting our goals and exceeding what anyone thought was possible.
Excepting that everything you say there is conjecture, based on what any random judge will do with any random example set of circumstances.
The fact is and remains you have no idea what cases and tactics the MPAA will draw on, and have no clue what decisions and legalities a judge could rely upon.
A judge very well could shut the thing down. Just as easy as I write this sentence. He or she may or may not, but claiming that "a judge will no more condemn it than he would condemn the entire Internet" is a foolhardy statement. Given the opportunity, I'd wager there are judges who would shut down the entire Internet!
Obviously you have to match your distro to your needs, but clearly there are other choices you could make that have different update infrastructures and release policies.
Obviously there. But, remember, in 1999 there was Win2k and what else for Linux distros? RedHat was linux in 1999, or, practically was.
Patching open source is always easy and does not need to be done as often.
Sorry, I disagree. My opinion on the matter based on many hard experiences is that patching open source is very often time consuming and tedious.
It is still easier to do than the MS part where you can't even patch the product, and so, lose time and money everytime, because of lack of functionality or bug.
Customizing OSS applications is often done because the project in question is not very extensible. Therefore, to customize the project requires soure hacking. In the cases where a module or bit of code I have customized is changed or moved or refactored in the main tree, I have to then work on my patch. Over time the trees can get more and more out sync. Especially if the main tree is updated before I am done testing and applying my patch. I've had this problem many times before, notably on PHP. There is no analog in the closed source world. Yes, customizing PHP is handy, but what would be better is not having to customize PHP. At the time the interfaces for add-ons was very much nascent, undocumented, and unstable. (It is somewhat better now). As an analog, I've had the same ISAPI modules running under IIS since version 3 without a single binary change. That goes back 6+ years.
2. You are NOT obliged to apply the patches when they come. You describe the patching coming willy nilly like it is a flaw, are you a MS shill ? You can plan to apply the patches every second tuesday of every month if you want. With MS, you have no choice, you have to adapt to their planning. With OSS, you have choice to do your planning like you want.
No you dont have to install when they come, but it is recommended that you do. I can hold any patch for as long as I want. The point being that all Windows patches come on the same schedule. I know, if there are patches, they are coming on said day, which allows me to plan people, resources, timing, etc. For my Windows networks I know I will have to schedule resources once a month. In the OSS world for many projects it could be 5 patches one week, and nothing for 6 more weeks, and then one patch a day for the next week. I have no way to plan for that! I can schedule my team to look once or twice a month, but the sparodic release schedule makes it hard. All the major closed source vendors keep a schedule, it's very convient. Release critical patches as soon as possible, all others can wait for the scheduled day, and if I want to schedule my guys for later than that, fine! Calling me a MS shill does not mean that OSS's sparodic release patterns goes away. Pointing out problems with OSS's IT theories doesn't mean I am shill for anyone, thanks.
3. Same stupid thing than in 2. "Product in heavy development" : and you use that in production ? Please !
Yes, many situations require this, especailly for performance problems. It's fact of the OSS world. The packages used are often in heavy development, and the developers would rather work on new features than cutting off development and creating a planned release. That's fine, it's not my business to tell them how to handle their hobby. It's just a bit difficult to manage at times.
You talk about your Win2k servers still on the same OS install like it is a prowess (no SP installed ?!!).
Of course SP's are installed, all 4 of them. However, the total time for me to intall any of those SPs even with heavy testing was minimal compared to what it took for me to install new version of RedHat.
Of course they have, patching and upgrading are far easier on OSS distro, and cost far less, so why would you stay on RH 5 ?
That is your opinion, and I find it to be false. Upgrading those RH boxes from 5 to 6 to 7 to FC1 to FC3 has been a big, huge, gigantic mess of time, and it was not fun. There were many, many, many compatibility issues, hardware compatability issues, and variations to deal with.
Well, yes, you can't really expect anyone else to patch your custom software, can you? At least when you're modifying GPLed code you can very easily backport most security fixes to your in house version. It's not as if your custom VB database front-end is going to be patched my Microsoft.
I am not claiming MS is going to patch your VB program, I am saying, that there are no custom Windows kernels, though, with source trees, to be managed. Closed source software requires that, to be extensible at all, the maker has to create an architecture for it that is stable across revisions of the base product. Many OSS products don't do that, because, they are open source. So you people hack the source and maintain their own tree for customizations. This is fine, however, it's a lot of work to maintain patches if that software is heavily customized. For the OS, it's a huge amount of work. If you hacked in support for something custom into the linux kernel or other major package, it's going to be a bit of work to keep your kernel up to date. You have to test the patches against your changes. This is never a problem with closed source since it's impossible.
A real world example I've dealt with is custom changes to MySQL. A client hired some people to put in some features that made it possible for them to save big bucks aginst going with DB2. They are highly industry specific, and so, only used by them. When they want to get the major benefits of a new MySQL upgrade, they have to get a new source tree, apply custom patches, test and make sure nothing is broken. A big effort. This of course isn't possible for say, MS-SQL or Oracle, since closed source. However, when a service pack or bugfix for those products is released the burden is much less heavy than for the MySQL client. It's a tradeoff!
It's called "get the security patch out as soon as possible so users aren't left running vulnerable systems". I can't believe you tried to make quick patch releases look *bad* when it's one of the most important benefits of running Linux. Planning? Does MS plan when a security hole will be found? No, so how can they plan when the patch will be released? They can't really do it, so instead they make you wait longer than you should have to.
Your thinking is flawed, and it shows, and it's very common in the OSS world. Not all patches are equal. Not all holes are equal. Not all patches are security related. The fact is that in many situations having a vulnerability exposed for a month is an acceptable risk. MS releases patches for severe remotely exploitable holes as quickly as possible for them. For other less severe problems, they wait. Not usually for remote vulnerabilities, but let me give you a concrete example.
"Vulnerability in the Microsoft Jet Database Engine Could Allow Code Execution (837001)"
MS rated this low. It took 3 weeks to get the patch out, in a schedule manner.
For OpenOffice, a security bug was discovered April 12th. On April 14th they recommended all users upgrade to a new version, or if they have a fairly current version, download the patch, or download a beta of the 2.0 product, which was already patched. That fact is the bug maybe would have allowed arbritrary code execution provided the user opened a specially created DOC file.
The two cases illustrate my point. OpenOffice recommened *all users* IMMEDIATELY upgrade. Microsoft recommended that *all users* patch as part of their normal policy of patching software. For 95% of IT people, MS's policy makes more sense. If you listen to OpenOffice, you're running around installing a patch or upgrading immediately, if you listen to MS, the problem is handled as part of your monthly patches. It's nice to have the choice, granted, but it's also nice to have MS's much more reasonable approach to the problem. Give you ways to mitigate the risk, and follow normal procedures.
There is no forced upgrade. You could have upgraded Windows 2000 to 200
1. If you are using a modified source tree then you can't compare with closed source software. That isn't an option in the first place.
Yes, and that's often a feature. For example, in many applications that I support that are closed there is a stable API that plugins are developed against, where as in some OSS apps you have to hack the source. Closed source usually means that developes have to work harder to create a good plugin architecture that requires no source hacking (because it's not possible!).
2. You can plan to install any patches on the second Tuesday of every month even if they are released throughout the month.
Very true! There are ups and downs to both approaches, and you can choose to ignore OSS patches released all the time, and bundle them up into bigger packages one day a month, or week, or whatever. I think in reality the practice is not so smooth and OSS admins install them as they come.
3. See 1. You don't get the option to closely track the beeding edge with Microsoft software.
And again, that's often a benefit! At the same time I installed an all Win2k network, I installed a RedHat network. Whereas MS still actively supports Win2k and it's still a big bit of their product base, RedHat 5.x has been long, long off the radar. It has been a big treadmill to get to the point where the RedHat network isn't a major hassle for me: major OS upgrades with associated hassles every 6-9 months. The Windows network has been much more stable with similair size, employees, and hardware.
4. So? As you said, it applies to both types of system, so it doesn't provide an advantage to Microsoft.
The original post talked about Linux patches being more stable, and that's what I am reffering to here. Patches are either stable, or not. It's atomic: you can't have a kinda stable patch, it's against the definition of stable. So, if there is a chance it's not stable you have to test, Windows or Linux or anything. If you have to test every patch, there is no advantage to saying Linux patches are "more stable", since you have to test them anyways! The net is that even though the poster claimed Linux patches are "more stable" you still have to test them, since they are not "100% stable". It's a fine point, but realistic.
Linux hasn't cornered the market on good patching. It's often much, much more work to patch a Linux box, and it's customized, it's practically a full-time job.
Patching open source is easy and does not need to be done as often
This isn't always true!
1. If you are actually using the fact that some package is open source and run a modified source tree you need someone to maintain that tree for you. You may have to fuss with patches, especially if large or if they affect areas you have customized.
2. Depending on your package patches come willy nilly, with no co-ordination. MS releases patches the second Tuesday of every month. This actually allows some type of planning.
3. Depending on your package patches may come in series: three patches in three days, for example. I have never figured this out, but its almost like the attitude is, "well, while we are here". Additionally, you have products that are in "heavy development" with pretty serious point releases weekly or monthly. This really sucks if you are working against product. Do you wait and just upgrade once a year or every two years, or do you keep on the treadmill? MS has one good thing going for it, in that for example I installed some Win2k Servers in mid 1999 that are still on the same OS install almost 6 years later. I installed some RedHat servers at the same time, and well needless to say, I've upgraded from RedHat 5.x a number of times since:)
4. Patches for Linux, like Windows, still need to be tested in a production environment. Especially if you are running from a largely source built system. I admin a heavily customized web server that was built almost entirely from source, and I can very rarely do a simple "make && make install", let alone install a binary RPM. As long as there is that uncertainity, it has to be tested if you are running real IT shop.
MS is really starting to get its act together on some things, and patching is one of them. The balance with patching is the overhead versus the urgency. The OSS crowd generally see's every patch as urgent, and it reflects in the release schedule. MS generally sees few patches as urgent, and it also shows.
I have had this argument with people before. There is no place in the country where Wal-Mart is the only place you buy DVDs. Find me a place. Give me a name. I've been looking because I used to have the same opinion as you, until I started to try to find the name of place that fit the bill!
Too many sources would refuse to provide information if they knew it would be on the record like that, completely traceable back to them.
And generally, these are not reliable sources. Untraceable sources have nothing to lose: by lying, by telling the truth, etc. I agree that in a very rare circumstance it may be necessary to hide the identity of the source. Fine. Use a double blind method, and use various obscfication techniques to hide the sources identity: scramble the voice on tapes, remove e-mail headers, etc.
I already generally refuse to speak to the media after some bad experiences. If in addition I knew that all their readers would have my email address ("I want copies of e-mails with headers"), that would become an inflexible rule.
That's fine, but if you are not accountable for what you say, you are not a good source.
A good source is: telling the truth, able to prove it, and willing to be accountable.
SO many stories quote "top officals", "well placed sources", "offical knowledgeable of the details", etc. And I am supposed to believe these people?
I used to work for a newspaper. They handle things the way they do for some very good reasons.
Because it's easy, and it's always been done that way. Well it's time for a change. Open source your articles. This is what my idea of a great article is like: one paragraph/200 words or less factual description of an event or circumstance or happening or newsworth event. Each and every word should be linked back to a real person, source, document, or primary reference. No more of the "Some leading experts believe that BLAH" teasers. After that paragraph, put a header "MORE INFORMATION", which contains some of the typical prose of a newspaper. A few more paragraphs to a few pages, depending on the topic. Back story, history, bios of relevant people, etc. All must be sourced, but not on a a word-by-word basis.
Under that give me a new heading "ANALYSIS", with a few columnists/analysts points of view, offical government reaction, international reactioins, etc. These are sourced to the author.
And all of the references, of course, go back to real stuff that can be examined by others.
I may not be interested except maybe once a day, or a week, or a month, or never. But for it to be there when I want it, it's priceless.
Combined with the large number of people someone with an interest in each article would very likely go over each of the sources, resources, notes, etc.
One person will never use all of the source material, but virtually every article would be deeply examined.
The point really is that where a typical blogger will update his/her post 2, 3, 5 or as many times as necessary, most print or online-print'ish new sources will never make any corrections to errors, will only do so after a hugely embarrasing gaffe, and continue to use uncredited, unsourced, untraceable sources.
Seriously. All I want in a news source is a complete biolography of every piece. It's the year 2005. I want MP3's of phone calls, I want everything on the record. I want copies of e-mails with headers. I want notes from meetings, high-quality scans of primary/original documents, I want it all. I would pay the NYT $1000/year for a real source. I mean it. Give us the article, the reporting, the "5 minute" version of any story. Then give me some analysis, possibly more than one point of view, and then give me full access to all the information gathered.
The newspapers and print media exist because hey, we can't all take in all the information and be everywhere and understand it all. Okay. Agreed. So fine. I'll pay for their resources to go out and dig, and research, and write. But I want what I am expected to provide: I want to see the sources. I want to know the details if I need them. I can't trust them, even the most trusted sources are often mislead, misguided, dead wrong or sloppy.
I write code for a living. I have to provide my code for inspection: to my team, to my higher-ups, to my customers, to my vendors. It's how it works. I don't get paid just for the raw output: it must validate, it must be verifiable, it must be right.
Technology today means that the NYT could offer this. But they refuse! So, I refuse to pay them.
People like Friedman et all largely use the NYT as a source of personal publicity, to gain a larger "mind share" for their opinions. This is usually towards the end of publishing, TV apperances, or other ambition.
The NYT charging will eliminate much of the influence that the the op-ed page once held with the people who consider themselves influential. People with a good deal of economic and intellectual psuedo-might to drop around.
In the end, the columnists at the NYT will not be able to set the agenda like they are used to doing. Previously, it was the newcasts - national and local - that took the queues from the NYT, and this put whatever they were saying "into circulation". Now, people like Druge, the Daily Kos folks, Instapundit, LGF, Powerline, TNR, Townhall, Freerepublic, and all of them have a big sway into moving things into the mainstream.
Basically, circulation or readership equals influence. And this is going to cut circulation drastically, which will affect influence nearly identically.
You are, in fact, entirely false. Firefox is Free in all senses. You do not pay for Firefox, at all, in any sense. Linux users literally can use it without spending one dime on software from the boot process up.
IE is also free, as in free to upgrade. Windows 95, for example, has no copy of IE with it. And yet, you can load IE on it for no cost. Other versions of Windows get free upgrades to IE, indicating again that it is free.
Additionally, IE was a standalone product on UNIX and Mac until discontinued, and they were also free.
Browsers are now entirely free (open source), gratis free (IE, Opera in some flavors), or virtually free/low cost (Opera in some flavors, Netscape in some flavors, etc).
Before MS's bundling and the increased competition and innovation that this action sparked, browsers were expensive for the average user.
1. It would be seen as an admission that the Windows Server technology is not what it is cracked up to be, and be read by the market as such. The immediate impact to the server business would be significant, and it is the only segment at Microsoft that is growing.
I dont see that happening. It would be a sign to MS's many customers that are a mixed shop that they dont have to choose all MS or no MS, which is a common perception. Windows Server is what it is. Other large vendors have multiple platforms: Ms is really the only vendor where it is likely you'd have the same core platform (Windows) across all product groups.
So OSS is not a viable business? You heard it here, on Slashdot first.
You are speculating. Good businesses with good products go out of business every day.
What is fact is that before the DOJ case the DOJ said that no competition could develop due to MS's lock on the market. The fact is that today, consumers pay less for browsers, have more choices, and the entire slate of products is substantially better.
The DOJ claimed then that it would be impossible for any OS or browser to get into the market.
Yet we have more OS's and more browsers than before the DOJ case. And the are all better. Since then, we've had Linux come into it's own, Opera and Firefox get real, and Mac OSX develop into a powerhouse. There is KHTML and Safarii going strong as well.
Define flourishing such that 7% of the market share fits the definition.
That 7% has come entirely or nearly entirely in the last 12 months, since Firefox 1.0 was released. They are adding users every day by the buckets load. Really.
Firefox is growing, IE is tanking. Get it? That's competition. The DOJ said that it would never happen, and they are proven wrong. PROVEN. Firefox is a better product and are adding 1M-2M downloads a week.
The fact is that in monopoly cases there is no set percentage of the market that means you have a monopoly or not. You can not be a monopoly and have 98% of the market cornered. You can hold only 60% of the market and be a monopoly. The raw numbers do not matter. What matters is whether or not you can manipulate the market.
MS has proven that it cannot manipulate the market. In fact, they had to recently re-conveiene the IE team which had been disbanded. Due to competition. Due to fear of Firefox.
The facts have been proven. The DOJ was wrong, MS was right.
The argument from the DOJ was that no competition could develop unless MS unbundled IE. MS did not unbundle IE. It's always been there, since the first time it was bundled.
Therefore the DOJ was wrong. Firefox is a superior product, and a great competitor, and it has developed even though MS has a huge market share. This proves that the DOJ was wrong. No substantial action was taken against MS and yet competition is thriving, and Firefox has gone from 0% to 7% in a very short amount of time.
So think about it. The DOJ claimed only a breakup of MS could restore competition, yet, 5+ years since MS was not broken up competition is flourishing!
I think, though, that as Linux takes hold on the "user desktop" market, they'll just integrate that if they havent already into whatever GUI shell is used by the masses. If someone downloads a binary, it should run if double clicked: that's what users expect. So if the user double clicks, the system will attempt to execute it. And we'll be right back where Windows is now.
Microsoft is actually thinking Unix-like, and seperating binaries from data on a pretty consistent basis now. Especially with less use of OLE and more use of XML.
Slashdot Mirror
In my company, god forbid I try to stop some vp from installing barney's latest adventure for their five year old, next thing you know the ceo's asking my boss why I hate america so much.
:-)
The thing is, I hear what you are saying. One thing I think that helped was the company had a very technically saavy CEO. As a privately held company, the company had started with a very minor IT position for its employees; terminal based computing running off an IBM mainframe. It was a great system, but finally, too much was required of it. They spent about $20M on their first 25 years of IT; so when business requirements finally forced a major upgrade in the way they operated it was a $50M dollar investment. That's so much money, nothing was left to chance. The rollout happened after 36 months of intense planning. Of that budget, 3% (2.5M) was laid out for pre-deployment testing and planning. They did a dry run in an offsite facility two weeks in a row before the deployment.
I know. It was the best IT environment I've had the pleasure to work in. Everyone was onboard. So much so we had MS bigwigs touring our facility 6 months after a deployment. We were featured on their website as a case study for a while, until they refuesed to upgrade to XP on MS's schedule, that is
We provided Internet access and e-mail. Users were allowed by policy to use the e-mail for personal purposes. We even provided webmail for outside the company access!
The desktops were completely locked down. Each one was one of three templates software wise. Weekly automated re-imaging (Saturday mornings, 2:00 am, machines in 250 count waves would begin reloading, taking about 6-7 minutes a piece to complete; all would be done in about 20 hrs).
Every user could run only pre-approved binaries enforced by group policy. No one, and absolutely no one, ran as administrator of anything (PC, domain, whatever).
It was a tight ship. All web content went through a proxy server and was aggressively filtered for nasty bits.
1. No users ran with admin privelages, ever. That is huge, huge, huge. Even when I was logged in to a dev box, I was was not an administrator of anything. We heavily used RunAs techniques for slightly privelaged operations.
2. We used group policies to specify exactly which binaries a specific user or group of users could run. This is also huge.
3. ActiveX completely disabled.
4. All web content went through our web proxy, which aggresively filtered out potential problems.
5. Aggressive use of known good machine images. Each machine was literally one of 3 templates. We could log a user off remotely, reboot the box from the network RIS server, reload his/her machine image template, boot back up, log the user back in, and they'd never know that their entire hard drive had been erased, the OS and apps recopied, and reset. That process was an extreme measure, but it took about 6 minutes, start to finish. It was like a slightly longer version of a reboot to users.
Finally, it's worth noting, we never had an anti-virus package on the workstations, only on the mail server to scan incoming and outgoing mail. We used no anti-spyware packages! We ran two eight-hour shifts (big servicing center for a major worldwide insurance company) each with about 50K users. The users had "unrestricted" in a technical sense internet access - outgoing ports were watched but not restricted (we let them have an IM package installed, for those lulls in the action), and everything went through a proxy server, but otherwise, there was nothing stopping them from trying to visit any old dark corner.
Seriously: good IT policy uniformly set across the network (no exceptions for VIPs, the CEO, or the CIO), quality standard hardware, the best software products, and a liberal amount of scripting, testing, and process management. That's all it takes.
I HAVE actually managed a huge Windows-only network (50K Win2k machines, 100K users, 80 servers), and I tend to agree with the original poster.
I was at the "helm" as a consultant turned IT manager/overseer while a full nationwide exec search was conducted to permantely fill the position for just about 11 months. The previous exec literally dropped dead a few days before an entire network upgrade: all new workstations, servers, cabling, routing equipment, and software packages went into effect. Four full timers on IT, 5 half-timers (24 hrs a week) on help-desk, and me.
In my time, we never had (1) any problems with patching, (2) a single piece of spyware found on any machine, (3) a single virus or worm or other such outbreak of unauthorized software, (4) any data loss or corruption and (5) a single BSOD. I had a core group of 12 servers that were "mission critical", whose uptime from the day I started to the day my replacement came aboard was perfect.
The point being, that your mileage may vary. With everything in this industry, YMMV. It should be stamped. We did BIOS upgrades, we had hordes of clueless users, we had clueless employees - the same problems as anyone else had. But we never let MS or Dell or anyone be our scapegoats, and we ended up really really meeting our goals and exceeding what anyone thought was possible.
Eweek writes hundreds of articles about products and technologies a month.
They can't run them all...
Excepting that everything you say there is conjecture, based on what any random judge will do with any random example set of circumstances.
The fact is and remains you have no idea what cases and tactics the MPAA will draw on, and have no clue what decisions and legalities a judge could rely upon.
A judge very well could shut the thing down. Just as easy as I write this sentence. He or she may or may not, but claiming that "a judge will no more condemn it than he would condemn the entire Internet" is a foolhardy statement. Given the opportunity, I'd wager there are judges who would shut down the entire Internet!
Obviously you have to match your distro to your needs, but clearly there are other choices you could make that have different update infrastructures and release policies.
Obviously there. But, remember, in 1999 there was Win2k and what else for Linux distros? RedHat was linux in 1999, or, practically was.
Patching open source is always easy and does not need to be done as often.
Sorry, I disagree. My opinion on the matter based on many hard experiences is that patching open source is very often time consuming and tedious.
It is still easier to do than the MS part where you can't even patch the product, and so, lose time and money everytime, because of lack of functionality or bug.
Customizing OSS applications is often done because the project in question is not very extensible. Therefore, to customize the project requires soure hacking. In the cases where a module or bit of code I have customized is changed or moved or refactored in the main tree, I have to then work on my patch. Over time the trees can get more and more out sync. Especially if the main tree is updated before I am done testing and applying my patch. I've had this problem many times before, notably on PHP. There is no analog in the closed source world. Yes, customizing PHP is handy, but what would be better is not having to customize PHP. At the time the interfaces for add-ons was very much nascent, undocumented, and unstable. (It is somewhat better now). As an analog, I've had the same ISAPI modules running under IIS since version 3 without a single binary change. That goes back 6+ years.
2. You are NOT obliged to apply the patches when they come. You describe the patching coming willy nilly like it is a flaw, are you a MS shill ? You can plan to apply the patches every second tuesday of every month if you want. With MS, you have no choice, you have to adapt to their planning. With OSS, you have choice to do your planning like you want.
No you dont have to install when they come, but it is recommended that you do. I can hold any patch for as long as I want. The point being that all Windows patches come on the same schedule. I know, if there are patches, they are coming on said day, which allows me to plan people, resources, timing, etc. For my Windows networks I know I will have to schedule resources once a month. In the OSS world for many projects it could be 5 patches one week, and nothing for 6 more weeks, and then one patch a day for the next week. I have no way to plan for that! I can schedule my team to look once or twice a month, but the sparodic release schedule makes it hard. All the major closed source vendors keep a schedule, it's very convient. Release critical patches as soon as possible, all others can wait for the scheduled day, and if I want to schedule my guys for later than that, fine! Calling me a MS shill does not mean that OSS's sparodic release patterns goes away. Pointing out problems with OSS's IT theories doesn't mean I am shill for anyone, thanks.
3. Same stupid thing than in 2. "Product in heavy development" : and you use that in production ? Please !
Yes, many situations require this, especailly for performance problems. It's fact of the OSS world. The packages used are often in heavy development, and the developers would rather work on new features than cutting off development and creating a planned release. That's fine, it's not my business to tell them how to handle their hobby. It's just a bit difficult to manage at times.
You talk about your Win2k servers still on the same OS install like it is a prowess (no SP installed ?!!).
Of course SP's are installed, all 4 of them. However, the total time for me to intall any of those SPs even with heavy testing was minimal compared to what it took for me to install new version of RedHat.
Of course they have, patching and upgrading are far easier on OSS distro, and cost far less, so why would you stay on RH 5 ?
That is your opinion, and I find it to be false. Upgrading those RH boxes from 5 to 6 to 7 to FC1 to FC3 has been a big, huge, gigantic mess of time, and it was not fun. There were many, many, many compatibility issues, hardware compatability issues, and variations to deal with.
Now, why haven't you gone to Win2003
Well, yes, you can't really expect anyone else to patch your custom software, can you? At least when you're modifying GPLed code you can very easily backport most security fixes to your in house version. It's not as if your custom VB database front-end is going to be patched my Microsoft.
I am not claiming MS is going to patch your VB program, I am saying, that there are no custom Windows kernels, though, with source trees, to be managed. Closed source software requires that, to be extensible at all, the maker has to create an architecture for it that is stable across revisions of the base product. Many OSS products don't do that, because, they are open source. So you people hack the source and maintain their own tree for customizations. This is fine, however, it's a lot of work to maintain patches if that software is heavily customized. For the OS, it's a huge amount of work. If you hacked in support for something custom into the linux kernel or other major package, it's going to be a bit of work to keep your kernel up to date. You have to test the patches against your changes. This is never a problem with closed source since it's impossible.
A real world example I've dealt with is custom changes to MySQL. A client hired some people to put in some features that made it possible for them to save big bucks aginst going with DB2. They are highly industry specific, and so, only used by them. When they want to get the major benefits of a new MySQL upgrade, they have to get a new source tree, apply custom patches, test and make sure nothing is broken. A big effort. This of course isn't possible for say, MS-SQL or Oracle, since closed source. However, when a service pack or bugfix for those products is released the burden is much less heavy than for the MySQL client. It's a tradeoff!
It's called "get the security patch out as soon as possible so users aren't left running vulnerable systems". I can't believe you tried to make quick patch releases look *bad* when it's one of the most important benefits of running Linux. Planning? Does MS plan when a security hole will be found? No, so how can they plan when the patch will be released? They can't really do it, so instead they make you wait longer than you should have to.
Your thinking is flawed, and it shows, and it's very common in the OSS world. Not all patches are equal. Not all holes are equal. Not all patches are security related. The fact is that in many situations having a vulnerability exposed for a month is an acceptable risk. MS releases patches for severe remotely exploitable holes as quickly as possible for them. For other less severe problems, they wait. Not usually for remote vulnerabilities, but let me give you a concrete example.
"Vulnerability in the Microsoft Jet Database Engine Could Allow Code Execution (837001)"
MS rated this low. It took 3 weeks to get the patch out, in a schedule manner.
For OpenOffice, a security bug was discovered April 12th. On April 14th they recommended all users upgrade to a new version, or if they have a fairly current version, download the patch, or download a beta of the 2.0 product, which was already patched. That fact is the bug maybe would have allowed arbritrary code execution provided the user opened a specially created DOC file.
The two cases illustrate my point. OpenOffice recommened *all users* IMMEDIATELY upgrade. Microsoft recommended that *all users* patch as part of their normal policy of patching software. For 95% of IT people, MS's policy makes more sense. If you listen to OpenOffice, you're running around installing a patch or upgrading immediately, if you listen to MS, the problem is handled as part of your monthly patches. It's nice to have the choice, granted, but it's also nice to have MS's much more reasonable approach to the problem. Give you ways to mitigate the risk, and follow normal procedures.
There is no forced upgrade. You could have upgraded Windows 2000 to 200
1. If you are using a modified source tree then you can't compare with closed source software. That isn't an option in the first place.
Yes, and that's often a feature. For example, in many applications that I support that are closed there is a stable API that plugins are developed against, where as in some OSS apps you have to hack the source. Closed source usually means that developes have to work harder to create a good plugin architecture that requires no source hacking (because it's not possible!).
2. You can plan to install any patches on the second Tuesday of every month even if they are released throughout the month.
Very true! There are ups and downs to both approaches, and you can choose to ignore OSS patches released all the time, and bundle them up into bigger packages one day a month, or week, or whatever. I think in reality the practice is not so smooth and OSS admins install them as they come.
3. See 1. You don't get the option to closely track the beeding edge with Microsoft software.
And again, that's often a benefit! At the same time I installed an all Win2k network, I installed a RedHat network. Whereas MS still actively supports Win2k and it's still a big bit of their product base, RedHat 5.x has been long, long off the radar. It has been a big treadmill to get to the point where the RedHat network isn't a major hassle for me: major OS upgrades with associated hassles every 6-9 months. The Windows network has been much more stable with similair size, employees, and hardware.
4. So? As you said, it applies to both types of system, so it doesn't provide an advantage to Microsoft.
The original post talked about Linux patches being more stable, and that's what I am reffering to here. Patches are either stable, or not. It's atomic: you can't have a kinda stable patch, it's against the definition of stable. So, if there is a chance it's not stable you have to test, Windows or Linux or anything. If you have to test every patch, there is no advantage to saying Linux patches are "more stable", since you have to test them anyways! The net is that even though the poster claimed Linux patches are "more stable" you still have to test them, since they are not "100% stable". It's a fine point, but realistic.
Linux hasn't cornered the market on good patching. It's often much, much more work to patch a Linux box, and it's customized, it's practically a full-time job.
Patching open source is easy and does not need to be done as often
:)
This isn't always true!
1. If you are actually using the fact that some package is open source and run a modified source tree you need someone to maintain that tree for you. You may have to fuss with patches, especially if large or if they affect areas you have customized.
2. Depending on your package patches come willy nilly, with no co-ordination. MS releases patches the second Tuesday of every month. This actually allows some type of planning.
3. Depending on your package patches may come in series: three patches in three days, for example. I have never figured this out, but its almost like the attitude is, "well, while we are here". Additionally, you have products that are in "heavy development" with pretty serious point releases weekly or monthly. This really sucks if you are working against product. Do you wait and just upgrade once a year or every two years, or do you keep on the treadmill? MS has one good thing going for it, in that for example I installed some Win2k Servers in mid 1999 that are still on the same OS install almost 6 years later. I installed some RedHat servers at the same time, and well needless to say, I've upgraded from RedHat 5.x a number of times since
4. Patches for Linux, like Windows, still need to be tested in a production environment. Especially if you are running from a largely source built system. I admin a heavily customized web server that was built almost entirely from source, and I can very rarely do a simple "make && make install", let alone install a binary RPM. As long as there is that uncertainity, it has to be tested if you are running real IT shop.
MS is really starting to get its act together on some things, and patching is one of them. The balance with patching is the overhead versus the urgency. The OSS crowd generally see's every patch as urgent, and it reflects in the release schedule. MS generally sees few patches as urgent, and it also shows.
I have had this argument with people before. There is no place in the country where Wal-Mart is the only place you buy DVDs. Find me a place. Give me a name. I've been looking because I used to have the same opinion as you, until I started to try to find the name of place that fit the bill!
Too many sources would refuse to provide information if they knew it would be on the record like that, completely traceable back to them.
And generally, these are not reliable sources. Untraceable sources have nothing to lose: by lying, by telling the truth, etc. I agree that in a very rare circumstance it may be necessary to hide the identity of the source. Fine. Use a double blind method, and use various obscfication techniques to hide the sources identity: scramble the voice on tapes, remove e-mail headers, etc.
I already generally refuse to speak to the media after some bad experiences. If in addition I knew that all their readers would have my email address ("I want copies of e-mails with headers"), that would become an inflexible rule.
That's fine, but if you are not accountable for what you say, you are not a good source.
A good source is: telling the truth, able to prove it, and willing to be accountable.
SO many stories quote "top officals", "well placed sources", "offical knowledgeable of the details", etc. And I am supposed to believe these people?
I used to work for a newspaper. They handle things the way they do for some very good reasons.
Because it's easy, and it's always been done that way. Well it's time for a change. Open source your articles. This is what my idea of a great article is like: one paragraph/200 words or less factual description of an event or circumstance or happening or newsworth event. Each and every word should be linked back to a real person, source, document, or primary reference. No more of the "Some leading experts believe that BLAH" teasers. After that paragraph, put a header "MORE INFORMATION", which contains some of the typical prose of a newspaper. A few more paragraphs to a few pages, depending on the topic. Back story, history, bios of relevant people, etc. All must be sourced, but not on a a word-by-word basis.
Under that give me a new heading "ANALYSIS", with a few columnists/analysts points of view, offical government reaction, international reactioins, etc. These are sourced to the author.
And all of the references, of course, go back to real stuff that can be examined by others.
I may not be interested except maybe once a day, or a week, or a month, or never. But for it to be there when I want it, it's priceless.
Combined with the large number of people someone with an interest in each article would very likely go over each of the sources, resources, notes, etc.
One person will never use all of the source material, but virtually every article would be deeply examined.
So while you're casting aspersions on Thomas L Friedman,
I am not casting asperisions on anyone. Re-read what I wrote!
A true grammar nazi posting as a coward? Surprise.
The point really is that where a typical blogger will update his/her post 2, 3, 5 or as many times as necessary, most print or online-print'ish new sources will never make any corrections to errors, will only do so after a hugely embarrasing gaffe, and continue to use uncredited, unsourced, untraceable sources.
Seriously. All I want in a news source is a complete biolography of every piece. It's the year 2005. I want MP3's of phone calls, I want everything on the record. I want copies of e-mails with headers. I want notes from meetings, high-quality scans of primary/original documents, I want it all. I would pay the NYT $1000/year for a real source. I mean it. Give us the article, the reporting, the "5 minute" version of any story. Then give me some analysis, possibly more than one point of view, and then give me full access to all the information gathered.
The newspapers and print media exist because hey, we can't all take in all the information and be everywhere and understand it all. Okay. Agreed. So fine. I'll pay for their resources to go out and dig, and research, and write. But I want what I am expected to provide: I want to see the sources. I want to know the details if I need them. I can't trust them, even the most trusted sources are often mislead, misguided, dead wrong or sloppy.
I write code for a living. I have to provide my code for inspection: to my team, to my higher-ups, to my customers, to my vendors. It's how it works. I don't get paid just for the raw output: it must validate, it must be verifiable, it must be right.
Technology today means that the NYT could offer this. But they refuse! So, I refuse to pay them.
People like Friedman et all largely use the NYT as a source of personal publicity, to gain a larger "mind share" for their opinions. This is usually towards the end of publishing, TV apperances, or other ambition.
The NYT charging will eliminate much of the influence that the the op-ed page once held with the people who consider themselves influential. People with a good deal of economic and intellectual psuedo-might to drop around.
In the end, the columnists at the NYT will not be able to set the agenda like they are used to doing. Previously, it was the newcasts - national and local - that took the queues from the NYT, and this put whatever they were saying "into circulation". Now, people like Druge, the Daily Kos folks, Instapundit, LGF, Powerline, TNR, Townhall, Freerepublic, and all of them have a big sway into moving things into the mainstream.
Basically, circulation or readership equals influence. And this is going to cut circulation drastically, which will affect influence nearly identically.
You are, in fact, entirely false. Firefox is Free in all senses. You do not pay for Firefox, at all, in any sense. Linux users literally can use it without spending one dime on software from the boot process up.
IE is also free, as in free to upgrade. Windows 95, for example, has no copy of IE with it. And yet, you can load IE on it for no cost. Other versions of Windows get free upgrades to IE, indicating again that it is free.
Additionally, IE was a standalone product on UNIX and Mac until discontinued, and they were also free.
Browsers are now entirely free (open source), gratis free (IE, Opera in some flavors), or virtually free/low cost (Opera in some flavors, Netscape in some flavors, etc).
Before MS's bundling and the increased competition and innovation that this action sparked, browsers were expensive for the average user.
1. It would be seen as an admission that the Windows Server technology is not what it is cracked up to be, and be read by the market as such. The immediate impact to the server business would be significant, and it is the only segment at Microsoft that is growing.
I dont see that happening. It would be a sign to MS's many customers that are a mixed shop that they dont have to choose all MS or no MS, which is a common perception. Windows Server is what it is. Other large vendors have multiple platforms: Ms is really the only vendor where it is likely you'd have the same core platform (Windows) across all product groups.
So OSS is not a viable business? You heard it here, on Slashdot first.
You are speculating. Good businesses with good products go out of business every day.
What is fact is that before the DOJ case the DOJ said that no competition could develop due to MS's lock on the market. The fact is that today, consumers pay less for browsers, have more choices, and the entire slate of products is substantially better.
The DOJ Was wrong.
The DOJ claimed then that it would be impossible for any OS or browser to get into the market.
Yet we have more OS's and more browsers than before the DOJ case. And the are all better. Since then, we've had Linux come into it's own, Opera and Firefox get real, and Mac OSX develop into a powerhouse. There is KHTML and Safarii going strong as well.
The DOJ was wrong. It's proven fact.
Define flourishing such that 7% of the market share fits the definition.
That 7% has come entirely or nearly entirely in the last 12 months, since Firefox 1.0 was released. They are adding users every day by the buckets load. Really.
Firefox is growing, IE is tanking. Get it? That's competition. The DOJ said that it would never happen, and they are proven wrong. PROVEN. Firefox is a better product and are adding 1M-2M downloads a week.
The fact is that in monopoly cases there is no set percentage of the market that means you have a monopoly or not. You can not be a monopoly and have 98% of the market cornered. You can hold only 60% of the market and be a monopoly. The raw numbers do not matter. What matters is whether or not you can manipulate the market.
MS has proven that it cannot manipulate the market. In fact, they had to recently re-conveiene the IE team which had been disbanded. Due to competition. Due to fear of Firefox.
The facts have been proven. The DOJ was wrong, MS was right.
The argument from the DOJ was that no competition could develop unless MS unbundled IE. MS did not unbundle IE. It's always been there, since the first time it was bundled.
Therefore the DOJ was wrong. Firefox is a superior product, and a great competitor, and it has developed even though MS has a huge market share. This proves that the DOJ was wrong. No substantial action was taken against MS and yet competition is thriving, and Firefox has gone from 0% to 7% in a very short amount of time.
So think about it. The DOJ claimed only a breakup of MS could restore competition, yet, 5+ years since MS was not broken up competition is flourishing!
The thing of it is though, that Sherman does not specify what percentage means you have a monopoly.
A monopoly occurs when one organization controls the marketplace: able to raise or lower prices at will without reprecussion from the market.
Can MS raise the price at will on IE? Umm.. hardly.. the price for browsers now is zero.
Let's look at it like this:
Before MS bundled IE, browsers cost $30-$99.
After MS bundled IE, browsers cost $0.
Those fuckers!
I think, though, that as Linux takes hold on the "user desktop" market, they'll just integrate that if they havent already into whatever GUI shell is used by the masses. If someone downloads a binary, it should run if double clicked: that's what users expect. So if the user double clicks, the system will attempt to execute it. And we'll be right back where Windows is now.
Microsoft is actually thinking Unix-like, and seperating binaries from data on a pretty consistent basis now. Especially with less use of OLE and more use of XML.