Contributed by Dengue on from the now-supporting dept.
Warning: these binaries don't follow the ports(7) rules, they are packaged like on other operating systems.
Please give them a try!"
(Comments are closed)
OpenBSD Journal
Contributed by Dengue on from the now-supporting dept.
Warning: these binaries don't follow the ports(7) rules, they are packaged like on other operating systems.
Please give them a try!"
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By butthead () on
Comments
By djm () on
MySQL has run the portable OpenSSH bugzilla on OpenBSD for a couple of years without any problem whatsoever, but I'd switch to Postgres as soon as bugzilla supports it (so I don't have to run two DB daemons).
By chill () on
Postgres is BSD licensed (http://www.postgres.org/licence.html), MySQL is GPL if your app is GPL or you never modify/redistribute any code. If not, you must get a commercial license.
http://www.mysql.com/products/licensing.html
Postgres seems to be a bit more ANSI SQL compliant. It also has a nice set of GIS extensions if you do a lot geographic/mapping stuff.
Comments
By Jedi/Sector One () j@pureftpd.org on http://www.skymobile.com/
By Anonymous Coward () on
Now, this isn't to say that MySQL doesn't have it's uses. It's good for simple apps with simple queries. IMO, your database should be picked based on its merit rather than how well it's supported on your platform. Of course, if you can't justify moving to a platform that supports the database you need, then you're database needs are really simple, and MySQL will work.
BTW, Postgres support under OpenBSD is great. MySQL support is getting there, apparently.
Comments
By gk () on http://gk.se/~gk
So I just wanted to say that MySQL has started to earn a better reputation though I agree that postgresql is on another level functionality-wise and licence-wise.
By Martin Foster () martin@ethereal-realms.org on http://www.erealms.org
MySQL is a joy to work with for rapid development and/or if you have little time to play with the nitty gritty of the DBMS in order to get going. Essentially, it's more of a install fire and forget style of program.
The documentation is great, there are examples of how to configure your database beyond the basic needs and the command line utils are straight forward. All of this allows someone new to databases, the opportunity to get their feet wet or just have something run.
Client site tools are far ahead of anything that PostgresSQL has available for free. Even the default MySQL tools are available for Windows and Unix, giving you the opportunity to work on your database without forking money to do so no matter where you are.
PostgreSQL has advanced features that you will not find in MySQL, which in turn will allow for a reduced code base. The use of sub-queries when absolutely necessary can cut down client site processing quiet a bit but draw more resources from the server. Functions and stored proceedures can also automate many of the tasks, and referential integrity alone will cut down on a lot of script site complexity.
The crux of PostgreSQL, I believe is related to a complete lack of tangible documentation to make use of. The documentation available on their page does little but give you a dictionary description of certain features while not providing you any real life examples to draw from. This makes configuring the database itself some sort of black magic, unless you find third party documentation that will help. Here's a link:
http://www.varlena.com/GeneralBits/Tidbits/perf.html
The use of Postgres is also more complex as it will generally require the Kernel to be compiled with higher values in order to support more then 64 connections, or add in more buffer space for read and writes. This to a new user, is far from obvious and makes it harder to deploy when the formula is hard from being one-to-one.
The database also requires you to maintain it. Unlike MySQL which pretty much runs itself until the ends of time, Postgres will not remove rows when they are deleted from the database. This will increase overall speed, but sooner or later you will need to VACUUM the database in order to maintain it.
If you don't VACUUM often enough, you will have to do a less agreeable variant of it that locks the database. However, mix this with transactions and the use of a persistent database connection, then you may cause a complete halt to your site for a while waiting for Postgres to sort itself out. So steps need to be taken to boot everyone off before it begins.
You also can't forget to occasionally re-index, because indexes are handled the same as rows and need to be cleaned to speed things up.
Would I go back to MySQL? Honestly no, but that is because I invested the time and effort needed to port the system over to Postgres and now that it's stable it's mostly as good or better then MySQL. At times it can be slower and at times faster.
The code base and maintenance alone will save me more time then the migration took. Not to mention that a 15% cut in scripting code required to run the same site is not something to look down upon.
Would I recommend Postgres for a new user? Honestly no, as it will do nothing by cause frustration overall for them unless they are very advanced from the start.
By mirabile () mirabile@bsdcow.net on http://MirBSD.BSDadvocacy.org/
look at their software, they'd at least create a
package to install. I assume GNU/Linux users get
RPM or DEB, and not simple .tgz either.
And they would give away the source for said
package, i.e. the port, so the maintainer can
have a look at that, too.
Just my 0.02 EUR
Comments
By chill () on
look at their software, they'd at least create a
package to install. I assume GNU/Linux users get
RPM or DEB, and not simple .tgz either.
And they would give away the source for said
package, i.e. the port, so the maintainer can
have a look at that, too.
The binary files are distributed in .tar.gz and .rpm for Linux, and .tar.gz for everything else except Windows and Novell where it is .zip. Last I checked .tar.gz is the same as .tgz.
It is GPL software, so the source is all there. There is only one source, not specific versions for each binary they distribute. It is available in .tar.gz, .srpm and .zip for Windows people.
I'm not sure what OpenBSD-specific config files/flags are in the source -- it is still downloading.
Comments
By Jedi/Sector One () j@pureftpd.org on http://www.pureftpd.org/
By Anonymous Coward () on
By kko () on http://sanchezalderete.net
By MeAStoopidNewbie () richard-burns@shaw.ca on mailto:richard-burns@shaw.ca
Install of the os went great, setting up ssl, sendmail went ok.
Then i had the misfortune to read about the mysql binaries for mysql 4.whatever on this board. So I went and installed the mysql 4.whatever using the mysql binary instructions. Which in themselves were fine until I couldn't start the daemon.
So this led to a bit of googling for pages that provided some intersection of the worlds of openBSD and mysql. There are lots.
Somewhere along the way I became aware that the CD had an older but very likely to work just fine via pkg_add version. After the problems I had been having I decided "get what works, working first" and decided to use the cd version.
The problem with this path to openBSd/mysql enlightenment is that pkg_add installs assuming a user of "_mysql" all the mysql binary ( AND RELATED DOCS ) install assumes a user of "mysql" (note absence of lead underscore).
Add to the mix the chroot ing of apache, and the need for the ln of the /var/mysql/mysql.sock on /var/www/yadda/yadda and this can rapidly become a nightmare of privileges confusion.
As a heads up to any one reliving this, let me just say that in rc.local you do want
"--user=_mysql"
despite the advice of
"--user=mysql"
that abounds in the mysql.org and numerous other web pages, assuming you go the pkg_add route. I hope this saves some time wasting by others.
Also the "chgrp -R mysql.mysql /var/mysql" and similar instructions need similar caution ("chgrp -R _mysql._mysql /var/mysql" happens by default in the pkg_add as the permissions come from the pkg).
In retrospect, the original 4.whatever mysql install probably went off the rails on me because of ignorance about the need to relocate the mysql.sock reference in my.cnf, and the link that was needed down the /var/www tree. However to learn about that you need to actually do a
pkg-add deployment of the code (and use refs like
http://nomoa.com/bsd/mysql.htm which is wrong about "mysql" v "_mysql")
There is one other painful gotcha, the /etc/my.cnf installed by mysql 4.whatever is not compatible with the one from the package in openBSD. ("invalid options" in the hostname.err file is your first clue.) You can find a good one to use in the share/mysql/my-small.cnf (also are "medium" and "large" variants) file if you untar and unzip the package locally, rename, and cp to /etc/.
As my final 2 cents, the "rtfm" advice that seems to permeate the openbsd pages on the web, can only be bad for openBSD if it wants to thrive.
OpenBSD does do things differently (for very good reasons), but in so doing the community needs some elasticity in its tolerance and attitude of those walking into it this space new.