Looks like the industry is actually using the data from the p2p networks they are litigating against. For example, finding out where a certain band's downloads are hot, but radio time for their latest tune is low. I found this really ironic, but not entirely surprising.
One of the things that stuck with me after reading the article was the author's idea that splintering (forking) in open source prjects is a bad thing.
The open source process is inherently social and political. Group leaders spend as much time on organizational matters and conflict resolution as on technical issues. When members cannot agree, the groups sometimes split into different factions. This may result in potentially competitive projects with different approaches, and possibly redundant efforts in both groups.
I actually see this as a potentially good thing. In then end, the OS project that lives is the one that more people have agreed upon and supported. I think disagreements are a fact of life, and in a way Open Source provides its own judicial system through Freshmeat's reverse popularity search.
The only place I see it as not so good is in the incompatibilities between distros. While we all like to find the one that fits our personalities best, I think in some ways it has been both a stigma to outsiders. Still, most software included in distros can be found in source and made to work on your favorite flavor. Not something for the newbie or grandma, but at least its possible.
I'm curous how the rest of you view the potential of OS projects to fork... Positive, or negative?
Better yet, look at what's really needed to communicate. How many times have you rec'd a PowerPoint attachment at work which contained a useless graphic surrounded by words which could have easily been represnted in a text file?
Once someone gets the hang of writing in ASCII it's actually quite legible even without embedded graphics and italics. I would conjecture that 90% of emails would be fine without HTML text, and without attachments. General documents are probably a lower percentage, but for the most part are fine in text.
If formatting really needed, RTF will do the job nicely in most cases, and it guarentees compatibility no matter where you send it.
Just because features are there doesn't mean its always appropriate to use them. I completely agree with settgin expectations about document interchange standards. The first response will always be resistance because no onoe likes change. But in most cases people get the idea when you educate them.
While there are some differences between SO and OOO, they are pretty slight. I've been writing very technical documentation and manuals using SO for about a year now. The biggest hurdle was figuring out the use of OO's multiple style classes. Beyond that the documents have been reliable and never changed automagically. Can it do cross references, maybe not. But that's only one feature, and in my mind not a big enough one to justify the M$ monopoly. Not every company agrees that cross reference is paramount.
On the issue of forward readability, the OO suite uses XML in a compressed format. If you uncompress the doc (gzip I believe) you will have the underlying XML. Not the half-way M$ XML, but the real thing. An OO doc will be useful in the future.
I'm a power user as well, and have contributed many bug finds to the SO side of the house, and I can honestly say that I don't miss M$ word at all.
In a way I have to agree... While there is some kind of an assumption made when someone embarks on a kernel recompile, it shouldn't be an assumption that the individual is a professional developer. On the other hand, you shouldn't be asking what a makefile is if you're recompiling. There is, however, a happy medium.
Linus indicated that he wanted more people testing the kernel... Unfortunately, that means venturing out beyond the shadow of kernel developers. Even if you know how to program, the kernel is no simple playground. I tried to get 2.6test01 working for quite a while before giving up - in fact this was the first article which seemed to make it obvious what needed to be done. I admit to not being a hardcore, but it should have been easier.
Linux is a fantastic world to be in, but it could be a bit more friendly not only to newbies, but also power users. I would suggest that many power users would rather test functionality that their ability to locate obscure libraries. Haven't tried since then, but hopefully the build has become more stable.
All that being said, I'm thankful to have it in front of me, and will happily use my 2.4 kernel until I can figure out 2.6.
Philosophically I think rewriting in Ada *would* benefit the kernel. Unfortunately the social issues around Linux would outweigh the technical benefits.
Ada was designed for large scale distributed software engineering, and in this case would be a much better language for global Linux kernel development.
Most of the "PITA" associated with Ada is its strict typing. You simply can't accidently perform innapropriate type operations in Ada without compiler warnings. It's also more verbose than many languages, but the verbosity is all aimed at making the code more intuitive.
I realize that most people don't know Ada, and having a large body of developers under a common language is a key element, so in the case of Linux it's probably not practical. But in Ada's defense I wanted to point out that it's "pain" isn't by careless design; It's more of a language for software engineering than hacking. Everything has its niche.
I've said it before and I'll say it again. Complexity is very tightly tied to availability in a general sense. I stay with sendmail because I've got it working "good enough" and I don't have the time right now to rearchitect our mail system...
BUT I aboslutely hate the fact that the config language is so complicated that it needs a preparser. Just reading the sendmail book from O'Reilly can be painful because of its size.
I like flexibility, I agree that restricting yourself to M4 (vs. cf editing) makes sendmail MUCH more tasteful, but really - this is the best we can do as a default after all these years?
I'm temped to make use of RedHat's new MTA switcher and take something new for a spin if it saves headaches. I wonder how clean their setup is.
How about another angle... Without the corporate world Linux has no motivation to become wildly scalable because most kernel geeks don't have 24-way systems in their basements?
Reading a few other posts above it's pretty clear to me that every one (individual or business) that partakes in OSS in some way gives back.
It's really difficult to maintain a parsitic relationship with OSS, but very natural to gravitate towards a symbiotic one.
If company X adopts LAMP for their apps, then it's a sure bet someone will be using newsgroups/irc/etc for support. Their question becomes archived, and others using google benefit.
If company Y finds a bug and submits it it will probably get fixed. Others unknowingly benefit.
My point is that unless you are simply a gifted Linux architect (aren't we all!?!?) you will eventually need to stand on someone else's shoulders in some way. When you do, it is almost a given that you become the shoulders for someone else.
Let's not belittle companies who adopt OSS for it's benefits just because they haven't figured out the sociology of the movement. Let's welcome them and be glad their not using closed alternatives.
This is almost not worth responding to as it is dripping with more religion than comprehension. In your effort to inflate credibility you linked to two stories with almost verbatim text (must be based on the same news wire) as though they were separate statements of support. But that's not what ticked me off.
You claim Sun is spreading FUD. After reading the articles you link to I see only one concept which could be misconstrued as FUD:
Sun CEO Scott McNealy said: "I don't want to speculate [on the outcome of the lawsuit] but I'm thrilled to death SCO can't revoke our Unix licence."
This is not FUD. At the time this article was written (7/30 - nearly a month ago) the facts behind the SCO case were nearly zero. Other than a lot of speculation on geek sites (which was fun!) there was nothing concrete except a very real legal claim. In response to that Scott said he's glad it's not a problem Sun has to face. No FUD - that's reality, and you'd be glad too if you were the CEO of a UNIX company. It wastes time and money having to deal with the static SCO imposes on the world. I'm sure IBM would make a similar statement if they could.
Would Sun like to win over some AIX custmers? I bet they would. This approach may be distastefully taking advantage of the SCO case to shift custmers to Solaris, but it's not FUD.
You are also implying that Sun is benefitting from Open Source withuot giving back and citing MadHatter as an example. I'd suggest you do some fact checking before becoming too self-righteous. MS Office's only real competition (IMHO) right now is OpenOffice/StarOffice. Sun could charge a bundle for it, but instead donated to Open Source. Look at the mozilla site - the Solaris builds are supplied by Sun Microsystems. There's more, but I'll leave it as an excercise to you.
The Open Source community benefits from all who participate. There is no good reason to condemn Sun just because they were late to the party.
Although I have always been disgusted by the spamming practice, I have always maintained that it wasn't right to stoop to their level. Same reason I don't set up attack-back features on firewalls. Public psting of his ID isn't the same as a campeign to flood his email or intigate DoS on his boxes, but it's a subtle temptation.
Oddly, this article might have me switching sides... Given all of the animosity directed towards spammers I find it amazing that the number of phone calls this guy mentioned was *20*. I would have though we'd be seeing 200+. I'm no one to pass judgement, but 20 calls sure seems a small price to pay for his contribution to Internet pollution. And it is implied that he is stopping now, which seems to increase the merit of this response / pay back.
The cynic in me still wonders if he made those claims to the media in order to decrease his harassment levels while he finds a new prvider. Seems like the shady types always have a plan "B" and this kind of thing is like playing whack-a-mole. Does anyne else really buy-in to him ending his games?
While I do agree that there has been a lot of infiltration of people who "don't get it" in the *NIX space, I don't agree with you when this argument is applied to the desktop space.
I find that having a desktop that works in an intuitive way, unifies commonly used utilities, and makes common tasks (DnD) more efficient enhances my productivity and acts as a "blanket" around the normal activities I do.
I don't think any one philosophy dominates in ALL situations. CHOICE dominates in my opinion. In other words, on my GNOME linux box I can use a terminal to create a really efficient set of logins where I automate things and pipe lots of small tools together. BUT I can also run Evolution to read mail instead of using Perl scripts to parse my mail spool.
Of course, I can do nearly the same things on WindowMaker instead of GNOME/KDE, but I think the two are close enough in this context not to kill my point.
What's important in mastering an OS is learning its strengths and weaknesses. I think this is Linux's strength - it's like the OS Borg - assimilating the cool features of all platforms. From your statement I would suggest that you may have taken too much of an extremist stance to objectively review the pros/cons.
I may be predudiced, but I would think that/. readers are not representative of the aggregate Internet population. I think it can have that appearance simply because so many similar types come together at the same waterhole for passionate discussion of techno-social issues.
Most people on the Internet are still of the mind that they are 'entitiled' to high quality content by their ISP fees. I think the real problem is that the average user out there hasn't yet groked the spirit of community that breeds responsibility and "giving back".
In general I don't see the Internet users ready to subscribe to content. Perhaps with micropayments - but those may also breed a disdain for 'nickel and diming' that will turn off newcomers.
It will take time before the average user can view the 'net as another dimension where their actions effect others, and the overall quality of life. When the *average* user spends time thinking about their postings on sites other than bleeding edge tech portals, THEN we will be ready to see digital subscriptions become a viable business model.
I would argue that they don't have to take this route. When I installed linux on my workstation gimp was included. Had it not been I culd have obtained a fully working version of it as follows:
# up2date --install gimp
Done. Hmmm... I don't think I can do that with Windows XP.
The only time the compilation apprach is required is when you need a feature which hasn't made it into the mainstream releases yet. At which point you actually have an option. The option isn't for everyone, but at least it's there.
Paired with a reliable default, choice is always a good thing.
Just for the record I'd like to point out that Sun uses StarOffice (OO with a few tweaks) as their corporate standard office environment. Something that is "slow and buggy" wouldn't hang for long in that role.
I have used StarOffice for numerous large technical manuals as well as standard day to day office work, and overall find it to be reasonably fast and stable. Bottom line here is that modern software often requires modern HW whether you are on M$ Office or OO. Remember, OO isn't designed to beat wordpad, it's designed to go head to head with Word. As much as I don't like M$, they have a strong incumbant.
Regarding the learning curve, I'd ask the question: "How long have you used MS Office?" Most people who argue the learning curve are trying to use OO in the same way they have used M$ Office for *years*. I hardly see that as a fair evaluation. Try working with the manuals, asking questions in newsgroups, etc. In my experience, the only thing that required "learning curves" was understanding OO's implementation of page/chartacter styles. The rest was a breeze.
Why should you bother? Because innovation requires change. Because competition is good for everyone in the marketplace, and competition breeds innovation.
You also mention that M$ compatibility is lacking in KO... Keep in mind how significant that issue really is. In order to for an office program to be a viable option in the business world it needs to interoperate. Period. As much as I hate to say it, the office arena is still dominated my M$. I receive M$ files from customers all the time, and never have to call them back asking them to change the format. It's seamless.
I'm *not* making any statements here about the quality of KO - I'm sure it's excellent. My point is that in the scheme of things what matters is the ability to communicate outside of your workstation / house / etc. In the real world, M$ is the spoken language to this day.
I'm thankful that Sun paid good money for it, and thankful that Sun has contributed it to Open Source. This is the kind of competition that the industry needs to get prices competitive again. Sun invested a lot of cash to make this happen, and that kind of play shouldn't be taken for granted.
Re:reiserfs 3.6 is also very fast
on
Reiser4 Benchmarks
·
· Score: 2, Informative
This would be a much mre useful posting if you specified what command was behind that `time` output.
I've been doing similar testing and have seen significant differences in numbers based on the io load / pattern. Each FS has its own strengths + weaknesses.
Was it: random or sequential? big files or small files? consecutive io or single reader/writer?
This stuff makes a BIG difference in the relvance of those numbers. Yuo probably know that if yu're doing testing, but it'w worth psting for those wh may not.
I agree with you. When I made the transition from RH8 to RH9 I lved the look, but felt trapped by the lack of configurability.
It since hasbecome obvious to me that Metacity can do a lot more than the default options. Just load the Sun Gnome environment, and compare it to RH9. I wish Sun would adopt some of RH's tweaks!
Bottom line is that a little documentation (maybe I missed something?) would have gone a long way towards making power users more receptive to the change.
I think the bottom line here is where a sysadmin's time can spent with a return on investment. I agree that anyone claiming to be beyond junir level sysadmin ought to be able to handle this, but there's no value add (barring the case where a custom feature is req'd).
One of the things Linux, and UNIX in general seems to verlok is that one the Windows side of the world it's pretty easy to install software. On the UNIX side, Rh has historically done a great job of making stable RPMs easy to obtain.
The other scenario to consider is ease of reconstruction. If your system is dependant on multiple custom constructed / compiled packages you need to maintain an additional server as a source repository, and integrate those custom packages into the distribution yourself. This extra overhead is justified in some cases, but a pain in others.
Wherever possible, I prefer to use stock RPMs because they're easy to find, easy to replace, and have gone through someone ELSE's regressioon test plans. Availability has a very high correlation with simplicity.
I've had quite a bit of experience on the StarOffice side of things (which may as well be OO)... I think that while some things have changed signifcantly, the basic religion is similar enough that you culd still benefit from the book.
For a lot of people brought up on MS Office, there are some new ways of ding things in OO/SO that having a book could help with. Especially page/paragraph/section/character styles. If you do complex technical writing, a bok culd definitely help make the transition.
I don't necessarily feel as though this is correct. At the company I'm currently at, the outsourcers are bidding on everything from the project managers down. They're even offering to design the software that needs to be written. In other words, this company, just like Nike, becomes a big marketing firm.
Having watched a number of these outsourcing projects, and being married to someone who has managed States-Side aspects of the outsourcing, I think massive scale outsourcing is enjoying a brief lived panacea status. I completely agree with your perception about quality, although I'm sure there are exceptions here and there.
What I see in the long run is companies realizing that their IT oursourcing needs to be treated much like their servers. There are some things you can run on a cheap old Intel box, and there are others you want a Sun Enterprise 15k for. Likewise, there are some sommodity based projects which lend themselves to outsourcing, and others where the associated risk may be too high.
This would lead to segmentation in the software engineering community such that we retain high-end engineers for critical projects and senior project arhitects, but the masses of foo apps out there for business unit one-offs go overseas.
I'm famous for my blind optimism, but I believe companies will wake up and find a middle ground.
This is pretty much what I'm thinking as well. Because IT has become such a key part of most businesses, it seems only a matter of time before software development / eng becomes commoditized.
There will always be a local demand for Systems Integrators, project managers, etc. as a cultural interface. Besides that, you need to have local presence to properly manage these types of projects.
Even the need for local cultural interfaces will drift though as companies become more comfortable with distance collaberation. The team I work on literally doesn't have any members in the same time zone - it's definitely something that requires adjustment. Anyway, my point is that the only constant is change. Those who adapt survive. Those who can't adapt may find themselves laid off. It's harsh, but it's in our nature to some degree.
Slashdot Mirror
Did anyone see the latest issue of Wired's article on p2p data mining?
a re .html
http://www.wired.com/wired/archive/11.10/filesh
Looks like the industry is actually using the data from the p2p networks they are litigating against. For example, finding out where a certain band's downloads are hot, but radio time for their latest tune is low. I found this really ironic, but not entirely surprising.
The open source process is inherently social and political. Group leaders spend as much time on organizational matters and conflict resolution as on technical issues. When members cannot agree, the groups sometimes split into different factions. This may result in potentially competitive projects with different approaches, and possibly redundant efforts in both groups.
I actually see this as a potentially good thing. In then end, the OS project that lives is the one that more people have agreed upon and supported. I think disagreements are a fact of life, and in a way Open Source provides its own judicial system through Freshmeat's reverse popularity search.
The only place I see it as not so good is in the incompatibilities between distros. While we all like to find the one that fits our personalities best, I think in some ways it has been both a stigma to outsiders. Still, most software included in distros can be found in source and made to work on your favorite flavor. Not something for the newbie or grandma, but at least its possible.
I'm curous how the rest of you view the potential of OS projects to fork... Positive, or negative?
Better yet, look at what's really needed to communicate. How many times have you rec'd a PowerPoint attachment at work which contained a useless graphic surrounded by words which could have easily been represnted in a text file?
Once someone gets the hang of writing in ASCII it's actually quite legible even without embedded graphics and italics. I would conjecture that 90% of emails would be fine without HTML text, and without attachments. General documents are probably a lower percentage, but for the most part are fine in text.
If formatting really needed, RTF will do the job nicely in most cases, and it guarentees compatibility no matter where you send it.
Just because features are there doesn't mean its always appropriate to use them. I completely agree with settgin expectations about document interchange standards. The first response will always be resistance because no onoe likes change. But in most cases people get the idea when you educate them.
While there are some differences between SO and OOO, they are pretty slight. I've been writing very technical documentation and manuals using SO for about a year now. The biggest hurdle was figuring out the use of OO's multiple style classes. Beyond that the documents have been reliable and never changed automagically. Can it do cross references, maybe not. But that's only one feature, and in my mind not a big enough one to justify the M$ monopoly. Not every company agrees that cross reference is paramount.
On the issue of forward readability, the OO suite uses XML in a compressed format. If you uncompress the doc (gzip I believe) you will have the underlying XML. Not the half-way M$ XML, but the real thing. An OO doc will be useful in the future.
I'm a power user as well, and have contributed many bug finds to the SO side of the house, and I can honestly say that I don't miss M$ word at all.
In a way I have to agree... While there is some kind of an assumption made when someone embarks on a kernel recompile, it shouldn't be an assumption that the individual is a professional developer. On the other hand, you shouldn't be asking what a makefile is if you're recompiling. There is, however, a happy medium.
Linus indicated that he wanted more people testing the kernel... Unfortunately, that means venturing out beyond the shadow of kernel developers. Even if you know how to program, the kernel is no simple playground. I tried to get 2.6test01 working for quite a while before giving up - in fact this was the first article which seemed to make it obvious what needed to be done. I admit to not being a hardcore, but it should have been easier.
Linux is a fantastic world to be in, but it could be a bit more friendly not only to newbies, but also power users. I would suggest that many power users would rather test functionality that their ability to locate obscure libraries. Haven't tried since then, but hopefully the build has become more stable.
All that being said, I'm thankful to have it in front of me, and will happily use my 2.4 kernel until I can figure out 2.6.
Philosophically I think rewriting in Ada *would* benefit the kernel. Unfortunately the social issues around Linux would outweigh the technical benefits.
Ada was designed for large scale distributed software engineering, and in this case would be a much better language for global Linux kernel development.
Most of the "PITA" associated with Ada is its strict typing. You simply can't accidently perform innapropriate type operations in Ada without compiler warnings. It's also more verbose than many languages, but the verbosity is all aimed at making the code more intuitive.
I realize that most people don't know Ada, and having a large body of developers under a common language is a key element, so in the case of Linux it's probably not practical. But in Ada's defense I wanted to point out that it's "pain" isn't by careless design; It's more of a language for software engineering than hacking. Everything has its niche.
I've said it before and I'll say it again. Complexity is very tightly tied to availability in a general sense. I stay with sendmail because I've got it working "good enough" and I don't have the time right now to rearchitect our mail system...
BUT I aboslutely hate the fact that the config language is so complicated that it needs a preparser. Just reading the sendmail book from O'Reilly can be painful because of its size.
I like flexibility, I agree that restricting yourself to M4 (vs. cf editing) makes sendmail MUCH more tasteful, but really - this is the best we can do as a default after all these years?
I'm temped to make use of RedHat's new MTA switcher and take something new for a spin if it saves headaches. I wonder how clean their setup is.
How about another angle... Without the corporate world Linux has no motivation to become wildly scalable because most kernel geeks don't have 24-way systems in their basements?
Reading a few other posts above it's pretty clear to me that every one (individual or business) that partakes in OSS in some way gives back.
It's really difficult to maintain a parsitic relationship with OSS, but very natural to gravitate towards a symbiotic one.
If company X adopts LAMP for their apps, then it's a sure bet someone will be using newsgroups/irc/etc for support. Their question becomes archived, and others using google benefit.
If company Y finds a bug and submits it it will probably get fixed. Others unknowingly benefit.
My point is that unless you are simply a gifted Linux architect (aren't we all!?!?) you will eventually need to stand on someone else's shoulders in some way. When you do, it is almost a given that you become the shoulders for someone else.
Let's not belittle companies who adopt OSS for it's benefits just because they haven't figured out the sociology of the movement. Let's welcome them and be glad their not using closed alternatives.
You claim Sun is spreading FUD. After reading the articles you link to I see only one concept which could be misconstrued as FUD:
Sun CEO Scott McNealy said: "I don't want to speculate [on the outcome of the lawsuit] but I'm thrilled to death SCO can't revoke our Unix licence."
This is not FUD. At the time this article was written (7/30 - nearly a month ago) the facts behind the SCO case were nearly zero. Other than a lot of speculation on geek sites (which was fun!) there was nothing concrete except a very real legal claim. In response to that Scott said he's glad it's not a problem Sun has to face. No FUD - that's reality, and you'd be glad too if you were the CEO of a UNIX company. It wastes time and money having to deal with the static SCO imposes on the world. I'm sure IBM would make a similar statement if they could.
Would Sun like to win over some AIX custmers? I bet they would. This approach may be distastefully taking advantage of the SCO case to shift custmers to Solaris, but it's not FUD.
You are also implying that Sun is benefitting from Open Source withuot giving back and citing MadHatter as an example. I'd suggest you do some fact checking before becoming too self-righteous. MS Office's only real competition (IMHO) right now is OpenOffice/StarOffice. Sun could charge a bundle for it, but instead donated to Open Source. Look at the mozilla site - the Solaris builds are supplied by Sun Microsystems. There's more, but I'll leave it as an excercise to you.
The Open Source community benefits from all who participate. There is no good reason to condemn Sun just because they were late to the party.
Although I have always been disgusted by the spamming practice, I have always maintained that it wasn't right to stoop to their level. Same reason I don't set up attack-back features on firewalls. Public psting of his ID isn't the same as a campeign to flood his email or intigate DoS on his boxes, but it's a subtle temptation.
Oddly, this article might have me switching sides... Given all of the animosity directed towards spammers I find it amazing that the number of phone calls this guy mentioned was *20*. I would have though we'd be seeing 200+. I'm no one to pass judgement, but 20 calls sure seems a small price to pay for his contribution to Internet pollution. And it is implied that he is stopping now, which seems to increase the merit of this response / pay back.
The cynic in me still wonders if he made those claims to the media in order to decrease his harassment levels while he finds a new prvider. Seems like the shady types always have a plan "B" and this kind of thing is like playing whack-a-mole. Does anyne else really buy-in to him ending his games?
While I do agree that there has been a lot of infiltration of people who "don't get it" in the *NIX space, I don't agree with you when this argument is applied to the desktop space.
I find that having a desktop that works in an intuitive way, unifies commonly used utilities, and makes common tasks (DnD) more efficient enhances my productivity and acts as a "blanket" around the normal activities I do.
I don't think any one philosophy dominates in ALL situations. CHOICE dominates in my opinion. In other words, on my GNOME linux box I can use a terminal to create a really efficient set of logins where I automate things and pipe lots of small tools together. BUT I can also run Evolution to read mail instead of using Perl scripts to parse my mail spool.
Of course, I can do nearly the same things on WindowMaker instead of GNOME/KDE, but I think the two are close enough in this context not to kill my point.
What's important in mastering an OS is learning its strengths and weaknesses. I think this is Linux's strength - it's like the OS Borg - assimilating the cool features of all platforms. From your statement I would suggest that you may have taken too much of an extremist stance to objectively review the pros/cons.
I may be predudiced, but I would think that /. readers are not representative of the aggregate Internet population. I think it can have that appearance simply because so many similar types come together at the same waterhole for passionate discussion of techno-social issues.
Most people on the Internet are still of the mind that they are 'entitiled' to high quality content by their ISP fees. I think the real problem is that the average user out there hasn't yet groked the spirit of community that breeds responsibility and "giving back".
In general I don't see the Internet users ready to subscribe to content. Perhaps with micropayments - but those may also breed a disdain for 'nickel and diming' that will turn off newcomers.
It will take time before the average user can view the 'net as another dimension where their actions effect others, and the overall quality of life. When the *average* user spends time thinking about their postings on sites other than bleeding edge tech portals, THEN we will be ready to see digital subscriptions become a viable business model.
I would argue that they don't have to take this route. When I installed linux on my workstation gimp was included. Had it not been I culd have obtained a fully working version of it as follows: # up2date --install gimp Done. Hmmm... I don't think I can do that with Windows XP. The only time the compilation apprach is required is when you need a feature which hasn't made it into the mainstream releases yet. At which point you actually have an option. The option isn't for everyone, but at least it's there. Paired with a reliable default, choice is always a good thing.
Just for the record I'd like to point out that Sun uses StarOffice (OO with a few tweaks) as their corporate standard office environment. Something that is "slow and buggy" wouldn't hang for long in that role.
I have used StarOffice for numerous large technical manuals as well as standard day to day office work, and overall find it to be reasonably fast and stable. Bottom line here is that modern software often requires modern HW whether you are on M$ Office or OO. Remember, OO isn't designed to beat wordpad, it's designed to go head to head with Word. As much as I don't like M$, they have a strong incumbant.
Regarding the learning curve, I'd ask the question: "How long have you used MS Office?" Most people who argue the learning curve are trying to use OO in the same way they have used M$ Office for *years*. I hardly see that as a fair evaluation. Try working with the manuals, asking questions in newsgroups, etc. In my experience, the only thing that required "learning curves" was understanding OO's implementation of page/chartacter styles. The rest was a breeze.
Why should you bother? Because innovation requires change. Because competition is good for everyone in the marketplace, and competition breeds innovation.
You also mention that M$ compatibility is lacking in KO... Keep in mind how significant that issue really is. In order to for an office program to be a viable option in the business world it needs to interoperate. Period. As much as I hate to say it, the office arena is still dominated my M$. I receive M$ files from customers all the time, and never have to call them back asking them to change the format. It's seamless.
I'm *not* making any statements here about the quality of KO - I'm sure it's excellent. My point is that in the scheme of things what matters is the ability to communicate outside of your workstation / house / etc. In the real world, M$ is the spoken language to this day.
I'm thankful that Sun paid good money for it, and thankful that Sun has contributed it to Open Source. This is the kind of competition that the industry needs to get prices competitive again. Sun invested a lot of cash to make this happen, and that kind of play shouldn't be taken for granted.
This would be a much mre useful posting if you specified what command was behind that `time` output.
I've been doing similar testing and have seen significant differences in numbers based on the io load / pattern. Each FS has its own strengths + weaknesses.
Was it: random or sequential? big files or small files? consecutive io or single reader/writer?
This stuff makes a BIG difference in the relvance of those numbers. Yuo probably know that if yu're doing testing, but it'w worth psting for those wh may not.
I agree with you. When I made the transition from RH8 to RH9 I lved the look, but felt trapped by the lack of configurability.
It since hasbecome obvious to me that Metacity can do a lot more than the default options. Just load the Sun Gnome environment, and compare it to RH9. I wish Sun would adopt some of RH's tweaks!
Bottom line is that a little documentation (maybe I missed something?) would have gone a long way towards making power users more receptive to the change.
I think the bottom line here is where a sysadmin's time can spent with a return on investment. I agree that anyone claiming to be beyond junir level sysadmin ought to be able to handle this, but there's no value add (barring the case where a custom feature is req'd).
One of the things Linux, and UNIX in general seems to verlok is that one the Windows side of the world it's pretty easy to install software. On the UNIX side, Rh has historically done a great job of making stable RPMs easy to obtain.
The other scenario to consider is ease of reconstruction. If your system is dependant on multiple custom constructed / compiled packages you need to maintain an additional server as a source repository, and integrate those custom packages into the distribution yourself. This extra overhead is justified in some cases, but a pain in others.
Wherever possible, I prefer to use stock RPMs because they're easy to find, easy to replace, and have gone through someone ELSE's regressioon test plans. Availability has a very high correlation with simplicity.
I've had quite a bit of experience on the StarOffice side of things (which may as well be OO)... I think that while some things have changed signifcantly, the basic religion is similar enough that you culd still benefit from the book. For a lot of people brought up on MS Office, there are some new ways of ding things in OO/SO that having a book could help with. Especially page/paragraph/section/character styles. If you do complex technical writing, a bok culd definitely help make the transition.
I don't necessarily feel as though this is correct. At the company I'm currently at, the outsourcers are bidding on everything from the project managers down. They're even offering to design the software that needs to be written. In other words, this company, just like Nike, becomes a big marketing firm. Having watched a number of these outsourcing projects, and being married to someone who has managed States-Side aspects of the outsourcing, I think massive scale outsourcing is enjoying a brief lived panacea status. I completely agree with your perception about quality, although I'm sure there are exceptions here and there. What I see in the long run is companies realizing that their IT oursourcing needs to be treated much like their servers. There are some things you can run on a cheap old Intel box, and there are others you want a Sun Enterprise 15k for. Likewise, there are some sommodity based projects which lend themselves to outsourcing, and others where the associated risk may be too high. This would lead to segmentation in the software engineering community such that we retain high-end engineers for critical projects and senior project arhitects, but the masses of foo apps out there for business unit one-offs go overseas. I'm famous for my blind optimism, but I believe companies will wake up and find a middle ground.
This is pretty much what I'm thinking as well. Because IT has become such a key part of most businesses, it seems only a matter of time before software development / eng becomes commoditized.
There will always be a local demand for Systems Integrators, project managers, etc. as a cultural interface. Besides that, you need to have local presence to properly manage these types of projects.
Even the need for local cultural interfaces will drift though as companies become more comfortable with distance collaberation. The team I work on literally doesn't have any members in the same time zone - it's definitely something that requires adjustment. Anyway, my point is that the only constant is change. Those who adapt survive. Those who can't adapt may find themselves laid off. It's harsh, but it's in our nature to some degree.