Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Software IT

Free Software, Get What You Pay For? 52

An anonymous reader writes "The Xooglers blog is running an interesting article on how big businesses may start out running free software but there is always the continued question of 'Should we go with something "real"?' at some point in their evolution. How often are technologies like PHP, Perl, and MySQL being pushed out once startups get managers who know nothing about the technology and only worry about name brands?"
This discussion has been archived. No new comments can be posted.

Free Software, Get What You Pay For?

Comments Filter:
  • by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Tuesday December 13, 2005 @03:13AM (#14244786) Journal

    I think it's unfortunate but in the IT world it is generally true there is no relationship between quality of software and cost . Some of the best software I've ever used has been free, some of the worst software I've ever used has been expensive.

    IT and technology and particularly software can be (is) difficult to understand on many levels: functionality; efficiency; ergonomics; stability; etc. In a book (and God, I wish I could remember the title of this book -- one of my faves) talking about manipulating perceptions one of the discussions centered on the fact that when all other criteria are indeterminate or unavailable, it is human nature to assign credibility and worth based on price or cost. This is rife in the world of software.

    Unfortunately, I see this as something taken advantage of rather that properly addressed.... sigh.

  • I don't know about the rest of the people here but, when my company talks about "going with something real", they're asking whether we should stay with Fedora or go to Red Hat Enterprise Linux.
    • by GuyWithLag ( 621929 ) on Tuesday December 13, 2005 @05:06AM (#14245056)
      That simply illustrates the articles point: RHEL is expensive therefore it's considered real and not a toy.

      • RHEL has a life of longer than six months, therefore it's real.
        • I have to chime in with a "me to" post. There is a lot of flak given to Red Hat over RHEL, but to be honest I'm glad this option is out there. This, and possibly Suse enterprise, is the one of the bigger reasons that I'm seeing wide-spread Linux adoption with the customers I deal with. It basically comes down to that management wants the "warm fuzzys" with the software that runs their business. And I'm quiet satisfied with how Red Hat handles their update policy (minimally invasive patches against basel
        • "RHEL has a life of longer than six months, therefore it's real."

          So has Debian, but I bet those people wouldn't consider it really "real". It is not corporate-backed, hence expensive, so it can't be "real".

          And that's exactly this story's point.
  • by Anonymous Coward
    Since data management has a complete, underlying theory, as well as several decades of best-practices, it's pretty easy to assess quality. Just look at the list of what's possible, and see if product X or Y correctly implements more of the items. If both products are free/open and are equally reliable and secure, what's the point in using the product with the smaller number of features?

    Some of the comments here are pretty scary. I'd expect to hear this from a summer hire working on a content mangement syste
    • rofl, you got my 5 cents.

      are these people for real ?


      People who push the "no transactions" FUD also forget that transaction support often reduces the reliability of applications


      this really threw me off the chair. come on people, if you mess up 10 rows in different tables along in 1 transaction, you can fix it all with 1 blink of the eye (rollback) if 1 insert/update/delete/whatever fails ... where did that reliability just go ? it's the other way around, transactions create reliability, when errors happen, data should not be committed because it disrupts the whole system. imagine that a bank wouldn't have transactions and you transfer 100$ to your mom's account. after it has been discounted from your account, the disk is full and it can't be added to your mom's account. you will lose 100$ and the bank will show you the finger.


      The truth is that it's not the end of the world if you mess up a row or two in most databases


      Google AdWords definitely is not "most databases", if you create zillion dollar bills for microsoft for advertising excel, you can't mix up this row. actually you can, but microsoft will sue your brains out.

      Mysql people that think that messing up some database tables are not a big thing oftect excuse themselves with "to err is human". I'd like to see if you think the same way if your car building factory thought that "to err is human", and forgot to add brakes to your car.

      You really don't need to expierence loss caused by ignoring transactions more than once in your life to get your fingers permanently burned.

      ---
        I hate it when users of superior databases fud over mysql. But even more do i hate that mysql zombies don't realize how mindless and incompetent their own comments on the issue are.

      Sweet tiny mysql has kindof added the features but i have seen no sign "stable" anywhere just yet, so using the latest mysql versions and it's fresh transaction is a bit better than no transactions but it still isnt "it", and you shouldn't trust millions of dollars into it's tables.

      If i need performance and can avoid transactions without causing dataloss, i choose mysql for speed, otherwise i choose postgresql which still is superior in it's features but a bit slower in speed.

      • MySQL 5.0 was released for production use in October. Some of the less well-known additions in version 5.0 include increased standards compliance in joins and an INFORMATION_SCHEMA database for accessing DB and schema metadata.

        MySQL has supported transactions via InnoDB and BDB for several years. Further additions scheduled for 5.1 and 5.2 will make it even easier to use storage engine supporting transactions or whatever other features you care about.

        BTW, MySQL now employs several Software Architects (and o
        • 4.1.13 was also released officially and was pretty obviously a production release.

          But surprisingly it had completely broken the charset matching in the database. so the queries that mixed utf8/local character sets (that worked before and worked again in 4.1.15) were completely broken, and along with them a nice bunch of applications. I was quite pissed to get a bunch of errors from restoring my database from dumps of the previous version. If they had planned this, they should have added tools to overcome th
        • If you read the fscking article, you'd know that Google wasn't able to implement Adwords without support for real transactions -- they wrote their own transaction layer instead.

          The problem with doing things like that is that it is expensive to maintain (do you really want to dedicate programmer time to a transaction layer) and is bound to get crufty and harder to support as time passes. And when you're writing your custom transaction layer, you're tempted to add extra features that add some value, but creat
        • Sure MySQL has supported transactions for years, but tell me what is the best way to load 20GB of data into innodb tables?

          I tried a fair number of recommended ways, but still got stuck with the disk writing at 2MB/sec even at the _start_ (which is not even the actual rate data is flowing into the DB). Not even got to the "slow down due to big index" part. Yes I did set the sync thing to 0 (sync max of once a second, instead of on every commit).

          I was seriously considering putting the innodb log files on a ra
      • by neillewis ( 137544 ) on Tuesday December 13, 2005 @08:14AM (#14245467)
        Transactions make applications *fail* reliably, they don't make them *work* reliably. They simplify things at one level by bundling them up and abstracting them, so when they do fail it's hard to know exactly why they failed. The dreaded 'we can't do what you want at this time, try later' horribly vague error message is the result. Transactions are no replacement for serious fault analysis.
        • Are you still in high school? That's about how I thought when I was in 10th grade, learning some PHP. Real applications are a lot more complicated than that. I'm sure you would love it if, say, Amazon charged your credit card, but failed to actually add your order to the database (which is exactly what would happen if you didn't have transactions and some error occurred). This is actually a fairly mild scenario.

          Seriously, read a database book someday. MySQL is a toy database which is great for things y
    • Block quoth the poster:
      People who push the "no transactions" FUD also forget that transaction support often reduces the reliability of applications

      I think I can explain this howler. One common attribute I have found inexperienced programmers -- even the bright ones -- is failure to handle error conditions properly. Two things it seems to take experience to grasp are: (1) The problem isn't error messages, it's error conditions, therefore error messages are your friend. (2) Prominent and obvious problems ar
  • by Lendrick ( 314723 ) on Tuesday December 13, 2005 @03:41AM (#14244879) Homepage Journal
    Time is money.

    Free and/or open source software such as Linux, the GNU tools, Mozilla, Open Office, GNOME, KDE, MySQL, Apache, Postgres, and many other wildly successful tools have been worked on for countless hours by skilled programmers and designers. Whether out of the kindness of their own hearts, desire for recognition, or a business investment, people have spent millions of hours designing, developing, testing, and documenting Free Software. Consider for a moment how much it woud have cost to pay each and every one of those people for their time. That's the amount of money that hass been put into Free Software.

    If someone gives you a mansion, you don't assume it's worthless because you didn't pay for it. The worth is still there; someone else already paid for it.
  • by Vo0k ( 760020 ) on Tuesday December 13, 2005 @03:53AM (#14244908) Journal
    The nice example given in the article clearly shows clueless managers and not convincing enough developers.
    In small startups you may pick it because it's free. In giants like Google you pretty much disregard costs of software purchase and just compare features. "Does it do all we need, well?" is the first and ultimately relevant question. All the others are secondary once the only competitors in the field have been estabilished. In case of databases there is no competition here, and all discussions should have ended at that first question. Does it do all we need, well? Yes, NOW it does, all we needed was added, it works fine. Does anything else do all we need, well? HELL NO! MySQL is an absolute master in the field of speed, when properly optimized beats everything and everyone (at costs of all the quirks we had to fight in the meantime). Everything else is much slower, and most choices will be simply way too slow for the expected workload.
    Free (Gratis) or not, doesn't matter here at all. Open Source matters, if it doesn't do what we need, we can get it to do it, but that's not essential.

    Managers who don't get it, won't work long. Simply because they will keep failing delivering working projects on time.
    • Nonsense. Where I work we have a DB2 cluster that runs over 6 billion transactions / day I doubt you can even do that with MySQL. We've setup dev environments with Postgre and MySQL, and Postgre generally blows away MySQL, unless you are using MyISAM.

      And if need more performance and ISAM is acceptable, I'll cut out the overhead of the MySQL engine and just use Berkely.
  • And how often... (Score:1, Insightful)

    by ArwynH ( 883499 )

    are PHP, Perl and MySQL push out because they lack scalability and are hard to maintain?

    I mean they are fine for small buisnesses, but when the buisness grows, so do their IT assests (databases, website, in-house software, etc). Large amounts of PHP & Perl code can be hard to maintain when compared to other languages like say Java. And as for MySQL... I'll let the other comments deal with that as I'm sure they will.

    I should also be quick to point out that this doesn't mean OSS is bad, just that some o

    • by Vo0k ( 760020 ) on Tuesday December 13, 2005 @04:54AM (#14245033) Journal
      Perl is definitely a prototyping language. Rolling out anything serious in Perl is, let me put it that way, unwise. Performance about 10 times worse than C/C++, bug-prone syntax, source=executable approach, all great for quick and dirty fixes, not for serious projects.
      PHP is good for making DHTML and that's all. If you want something serious, get a backend in a mature lower-level language, launch it through PHP to get things done, post results to pages generated through PHP. Anything more in PHP is definitely dangerous, and always a hack.
      MySQL - Wrong, wrong, wrong. It's not a toy/prototyping/testing database. Sure it's easy to use and gratis, so integrating it with quick&dirty hacks in PHP or Perl feels natural. But it's like recreational riding a thoroughbred horse, a smooth, easy fun ride. And if you try to put the thoroughbred to a cart, the effects are definitely poor. Jumps? Okay, not impressive though. Cross-terrain, endurance, dressage? Sucks. It's not a versatile horse, and MySQL is not a versatile database. Just put the thoroughbred to gallop and you'll be far first in the means of speed, same about MySQL. Give it a highly specific, simple task where speed is essential. Not synchronizing sales over the whole corporation, not optimizing routes for train schedule, not managing an air traffic tower, where the complexity requires really sophisticated solutions. You put it to pull a single random ad that matches a keyword from a database of ten millions and increase display counter on associated field by one. And do it ten times a second. That's the kind of work which MySQL is made for, and that's where all the alternatives suck.
      • But [MySQL is] like recreational riding a thoroughbred horse, a smooth, easy fun ride.

        Heaven forbid we actually get to use technology that is fun, Fun, FUN! Now get back to maintaining that Fortran app, you insensitive clod!
      • Perl is definitely a prototyping language. Rolling out anything serious in Perl is, let me put it that way, unwise.

        I assume you are writing this statement on a computer that contains a CPU. You'd be amazed if you saw the tooling used to build said CPU and all the other extremely complex, expensive and risky chips that make up your computer. A few very expensive CAD tools bought from one of the three/four established vendors for top $$$/year, and masses and masses and masses of Perl (or *hack spew* TCL)
        • Do you call that -wise- though?
          • Let me put it this way: most of the work of a chip designer, today, is analysis of GB and GB of information that is generated by complex tools such as 3D field solvers, simulators, etc - all of that is done in Perl. I can't think of a comparably ductile programming language for people with a non-CS degree. You could surely teach an EE to write those programs in C++ using Boost's regexp package to achieve the same goal, but show them a 70-line-long g++ error message and their head would explode.

            Perl allows

    • by mangu ( 126918 )
      Large amounts of PHP & Perl code can be hard to maintain when compared to other languages like say Java.

      I often seen this "Java is easy to maintain" meme being spread, but with little to corroborate it.

      I guess the real reason is that Java is so difficult to use that companies must have big teams organized before they start doing anything with it. With Perl you can easily write a ten-lines script that eventually grows into a huge system that no one seems to be able to maintain. Java is so clumsy that, i

      • by moro_666 ( 414422 ) <kulminaator@gCOB ... m minus language> on Tuesday December 13, 2005 @06:08AM (#14245198) Homepage

        Java is so clumsy that, if you are doing something with it, you always start by doing a lot of design before you code.


        Come again? You code without software design ? Tell me exactly how do you write C or C++ code without designing, or python code ? (and who let you near a computer in the first place ...)

        Yeah you can definitely write a 5-line perl hack without designing, but if you write just about anything that is worth a dime, you better plan first and dont fix/patch/alter the stuff afterwards for years. Maybe it's just that i have not had 1-day or 1-week projects for a while, but i usually don't write one line of code on the first day at all. I prefer brainstorming, research and analyzing that will save me a headache and hopefully give me a few extra days at the end of the project to polish stuff.

        Java is not slow when code goes into millions of lines, it's the coders who mess it up. I have seen working huge java code, i have written huge working java code which is fast. You are still being fooled around the fact that the swing gui used by java is slow and that java is often used along with oracle that is slow. Don't let this fool you. Java is as fast as C++ in pure arithmetics. If you really need some freaky speed boost, you can write the speedwhore code in C and JNI to it. You can also have your pointer tribble there if you need it, but Java is designed so that it would avoid the need pointers in the first place (all the regular objects in java are actually pointers). Besides, Java is the only thing that will work on almost any platform. And this is what counts in year 2005.

        C and C++ are not platform independant and that is what you rarely want to use nowadays. You can never know if your stupid management wants to run this on windows or linux or even sun tomorrow. And once you get your code compatible with all major os's , the source is so #define'd that it's nearly impossible to manage. I won't even start about the library dependancies.

        Just use every language where it belongs and don't go around bashing java or anyone else with accusations that can't take 1 mm of water.


        Oh well, ok, you can bash php, i have nothing against that.
        • Come again? You code without software design ? ... Maybe it's just that i have not had 1-day or 1-week projects for a while, but i usually don't write one line of code on the first day at all. I prefer brainstorming, research and analyzing ...

          Then you aren't a very efficient programmer in an enterprise environment. A large proportion of programming projects today are related to some data mining / data recovery situations where you need to get some result quickly. You need to recover something from a set o

      • I agree with your fundamental point, that the language chosen should depend upon the objective. However, I strongly disagree with some of your points.
        C/C++ for really large programs - this gave us wonderful bugfree things like Windows, and Office. The power of the languages break down after a few hundred thousand lines of code as they turn into maintenance nightmares. Data dictionaries anyone?
        Java hard to use? - This is the first time I've ever seen anybody say that. Java has its issues but, if you think Ja
    • I mean they are fine for small buisnesses, but when the buisness grows, so do their IT assests (databases, website, in-house software, etc). Large amounts of PHP & Perl code can be hard to maintain when compared to other languages like say Java. And as for MySQL... I'll let the other comments deal with that as I'm sure they will.

      I worked for one of the largest financial companies on the planet and one of the biggest Perl shops around and I can say without fear of equivocation that properly written, ma

      • I'm in complete agreement with you. I've too had experience with well-maintained perl code. I've also had experience with poorly maintained perl code and java code. Out of the 2, the perl code was far harder to understand. The reason for this was due to perl's free-formness. That's not to say free-formness is bad, just if misused it can cause nightmares for later maintainers of the code.

        What I meant in my original statement was that while it's possible to have easily maintainable code in any language, it's

  • by Nice2Cats ( 557310 ) on Tuesday December 13, 2005 @04:53AM (#14245032)
    How often are technologies like PHP, Perl, and MySQL being pushed out once startups get managers who know nothing about the technology and only worry about name brands?

    That is when they die. Seriously. Look at these guys, what was their name again, ah, yes, Google -- kinda silly but you know these computer types -- anyway, where would they be if they had dumped their Linux and stuff for Windows XP or even OS X (the Unix of the great GUI but crappy thread performance)? Not trading at about $400, that is for sure.

    Don't worry. This is evolution in action: The clever ones, the more efficient ones survive. Those who pay $400 for Microsoft Office instead of using OpenOffice for free are not efficient. If Open Source can keep the legal playing field level, the rest will take care of itself.

  • brand name? (Score:1, Redundant)

    by EngMedic ( 604629 )
    perl /is/ a brand name, pretty much.
  • that the question of when and why to migrate to and from free software to commercial alternatives is being asked, that it can be asked.

    It means there are alternatives, that everyone can make a freer decision with more options, that free software provides a baseline commodity level that benefits everyone, and that commercial providers can compete on providing genuine value added on top of this baseline offering.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...