< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 7 of 76 ]
From: Walt Mankowski Date: 23:16 on 30 Dec 2007 Subject: My own personal perl I hate macports. I know lots of people love it, but it seems like no matter what I try to do with it, I end up wanting to tear out my hair. I hate macports, and it hates me right back. Everyone's been telling me how great git is (I suspect it's as hateful as any other vc software, but I won't know until I try it on a real project), so I decided to give it a try. On debian this is easy -- "apt-get install git-core". But installing it on my macs wasn't so easy. Git sadly isn't in fink, so I tried installing it from macports. As you'd expect, before it could build git-core it had to download and install some dependencies, things like expat and libiconv. I figured it was going to take a while so I went back to what I was doing. A few minutes later I checked to see how it was doing. To my surprise, it was building perl! WTF! Oh, and since according to the macports installation instructions. /opt/local/bin was at the front of my PATH, their perl was now my default perl! I'd just been using the default Tiger perl (5.8.6, I think) so none of the CPAN modules I'd installed were visible to this perl. According to the macports people, this is a Feature. Everything's supposed to be self-contained, so since git-core comes with a few auxiliary perl scripts it needs its own copy of perl as well. I suppose that makes some sort of sense. But it seems to me that if you can't figure out how to install a few perl scripts ON A SYSTEM THAT SHIPS WITH PERL without essentially breaking the system perl, then something's very, very wrong. Sigh. And don't get me started on the hateful way they handle package dependencies... Walt
From: Michael G Schwern Date: 23:24 on 29 Dec 2007 Subject: COPY_EXTENDED_ATTRIBUTES_DISABLE Oh god, how many things are wrong here. Macs have long had extra file meta-data integrated right into the file separate from the data, which is a great idea. Means you don't wedge meaning into things like file extensions and magic #! lines and magic binary bits. You can have an editor store the last point you were editing at right in the file without screwing up the plain text data. The problem is, nobody else does it this way so there's some trouble when shipping files around. This has created all sorts of hatred from the old binhex .hqx file formats to Macs pooping little .DS_Store files all over remote filesystems. As I understand it, a lot of filesystems support forks, just nobody uses them. Anyhow, there's all good fun reading about that here: http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unified_Model.txt But we're not here to have fun, we're here to have hate. And wear tiny little ironic birthday hats and eat bitter, bitter cake. Apple has finally gotten around to making it's Unix utilities resource fork aware. So things like cp and mv and rsync all that can move files while retaining the resource fork without having to use bizarre OS X specific things like ditto. This is great and all, but they have a tendency to not document it. And cp and mv tend to operate on just the local filesystem so you're probably copying from Mac to Mac. Finally it's tar's turn. A utility which is generally used to move files *between machines* and thus you lose the happy assumption that you're going to send it to another Mac. Of course you're going to just turn it on without warning. And in true Apple style they did not document the change in the man page, it's just a fun surprise. And how do you turn it off? Easy, just set COPY_EXTENDED_ATTRIBUTES_DISABLE to true. Yay, negative flags! Is there a corresponding switch? No. But that's not good enough. It's not enough to have a long winded, oddly worded, magic flag to turn off broken default behavior. Oh no. You should REPLACE IT in the next version, again quietly and undocumented, with the even more inspired COPYFILE_DISABLE. Still retaining the negative naming scheme, good, nice and hateful. But making up for it's shorter length with a totally misleading name! It's not file copying we're disabling, it's copying those resource forks we're disabling. Bravo, Apple. Bravo. And now I need to break out an OS X specific subclass for MakeMaker.
From: David Cantrell Date: 17:00 on 27 Dec 2007 Subject: Reasons to hate Module::Build CPAN: File::HomeDir loaded ok (v0.64) CPAN: Storable loaded ok (v2.18) Going to read /home/david/cpantesting/perl-5.6.2/.cpan/Metadata Database was generated on Thu, 27 Dec 2007 10:37:53 GMT CPAN is up to date (1.9205). Module::Build is up to date (0.2808). This module require Module::Build to install itself. Install Module::Build from CPAN [y] CPAN: File::HomeDir loaded ok (v0.64) CPAN: Storable loaded ok (v2.18) Going to read /home/david/cpantesting/perl-5.6.2/.cpan/Metadata Database was generated on Thu, 27 Dec 2007 10:37:53 GMT CPAN is up to date (1.9205). Module::Build is up to date (0.2808). This module require Module::Build to install itself. Install Module::Build from CPAN [y] CPAN: File::HomeDir loaded ok (v0.64) CPAN: Storable loaded ok (v2.18) Going to read /home/david/cpantesting/perl-5.6.2/.cpan/Metadata Database was generated on Thu, 27 Dec 2007 10:37:53 GMT CPAN is up to date (1.9205). Module::Build is up to date (0.2808). This module require Module::Build to install itself. Install Module::Build from CPAN [y]
From: A. Pagaltzis Date: 04:24 on 25 Dec 2007 Subject: Mailman admin Dear Mailman, you keep mailing me about this mail that was held in the moderation queue because it came from a non-subscribed address. Unlike other such notifications, though, the quarantined mail is not attached, nor is your standard "reply to this to delete the mail" message. You just tell me to look at the admin interface. So I do, only to find that that part of your schizophrenic brain tells me there's nothing pending that I need to take action on. Which is probably because I told you to delete this very message when you first saw it, you scatterbrained piece of massive fail. And now you see fit to send me one of those pointless bloody reminders every single day. Kindly make up your worthless mind and let me delete whatever remnants of the message still give you indigestion or get bloody lost. With plentiful bile,
From: Yossi Kreinin Date: 09:57 on 22 Dec 2007 Subject: Fun with Content Management Systems I normally don't do web programming. What follows is a newbie's experience with what appears to be very popular content management systems, more specifically, their piles of PHP/CSS crud that are called "themes" in the related jargon. The hate is fresh and immature and thus could easily be misattributed (in particular, I don't know which version of what I used; all I know is that I installed WordPress and Gallery2 by a bunch of clicks into the DreamHost "one click installation" web interface). About every second WordPress theme from the "official" theme list is broken out of the box, in one or several of the following ways: * It has links pointing to nowhere * It lists PHP errors in parts of the page * It lists MySQL errors in parts of the page I also tried a theme by "professional web designers". Wasn't broken out of the box in the sense that once you "activated" the required plugins, it worked. However, its way to complain about missing plugins was, of course, listing PHP errors in parts of the page. Gallery2 defaults to the image size of 640x480 (to see full resolution, you have to click further). Fine with me, except that the bloody "themes" (together with Firefox's menubars, toolbars and other such shitbars) /don't leave enough space/ to see the 640x480 images. And the hateful configuration web forms (with different submit buttons for different parts of the settings, losing your settings if you click the wrong button) of the dreaded themes don't seem to have a way to configure the amount of pixels eaten by the useless parts of the layout. After poking around for lots of time, my solution for WordPress was to take what appeared to be the least disgusting theme with the most things already sort of working and change the code to remove broken links and such. I think Gallery2 is next; its PHP crud seems less comprehensible, but I see no choice. What this seems to mean is, if you want to have a blog or a gallery, go to Blogger or Picasa or any other free space to store similarly looking files, but don't even think about actually paying for web hosting and rolling your own pile of files. Especially if you're not really into PHP.
From: Sean Conner
Date: 02:06 on 19 Dec 2007
Subject: Web based applications wedded to MySQL (SugarCRM, I'm looking at you!)
I'm working on an internal project and for reasons that get into business
type logic of which I'm not privy to, SugarCRM [1] seems to fit the bill
perfectly.
Well, almost perfectly. For other reasons that at the time I fully agreed
with but now am having a difficult time remembering, we decided against
using MySQL [2] and felt that PostgreSQL [3] was the better database engine
to use. But SugarCRM wasn't written to use PostgreSQL, but MySQL.
"Oh, it can't be *that* hard to port," says I. "SQL is SQL, right?" says
I. "PHP has been around long enough to support database engine
abstractions, right?" says I.
Nope.
It seems that to use MySQL, you use a bunch of specific MySQL calls, all
prefixed with "mysql_" to do your SQL queries. You open a connection using
mysql_connection(), then mysql_select_db(), then mysql_query() to make the
actual queries. Using PostgreSQL, it's pg_connect(), which handles both
connecting to the actual database engine *and* the database you want to
query, then you call pg_query(). The same mess exists for all other
database engines that PHP laughingly "supports."
Oh sure, PHP does have a database abstraction layer, but if you read up on
it [4]:
PDO provides a data-access abstraction layer, which means that,
regardless of which database you're using, you use the same
functions to issue queries and fetch data. PDO does not provide a
database abstraction; it doesn't rewrite SQL or emulate missing
features. You should use a full-blown abstraction layer if you need
that facility.
PDO ships with PHP 5.1, and is available as a PECL extension for PHP
5.0; PDO requires the new OO features in the core of PHP 5, and so
will not run with earlier versions of PHP.
Sad to think it took *five @#$!@#$@ major revisions" to get this
functionality. Even sadder to think that PHP, being the "scripting language
du jour" that it is, means that applications are pretty much targetted
towards a particular version of PHP, and a program that worked under PHP
X.Y.Z will typically break in some mysterious way under X.Y.Z+1. So even if
I *wanted* to use PDO, I can't becuase SugarCRM was written for PHP 4.x, not
5.y.
"Okay," says I. "Just change calls to mysql_* to pg_*, with some munging,
and it'll be all okay, right?" Well, not really, because any work I do with
SugarCRM 4.x will be tossed right out when SugarCRM 4.x+1 is released.
Sure, I searched [5] for any work done on porting SugarCRM to PostgreSQL,
but it seems that all the work was last done in 2005, with some done in 2006
if you search hard enough [6]. The guys working on SugarCRM pay lipservice
to the notion of supporting other database engines than MySQL [7], but as
you read up on this crap, it's clear they don't want to even think about
this issue [8].
But I find a version of SugarCRM that has been ported to PostgreSQL. It's
not the latest version, but it's *a* version and it appears to even work.
Until the other day [9].
Apparently, there's a 3k character SQL query generated by SugarCRM that
PostgreSQL doesn't like, which disabuses me of any notion that SQL is SQL is
SQL. Apparently, PostgreSQL requires the use of AS, whereas such a little
detail is optional, and some parts of the codebase add it, and some don't.
And I apparently hit some less tested parts of the codebase. And the line
of PHP causing the error?
$result = pg_query($sql);
in a function, where $sql is a paramter.
I'll spare even more details of what I did because this is getting long,
but I will say that the *easiest* fix for this mess, the one thing that I
could do to get back on track, was this horrible gross hack of a fix
[10][11]:
$sql = preg_replace("/\s+\'\s+\'\s+([a-z]+)/"," ' ' AS \\1",$sql);
$result = pg_query($sql);
And at this point, I don't know where to direct my hate of software---is
it PHP and it's serious lack of database abstraction? It's encouragement of
shoddily written software with no pretentions of being portable? Is it the
SQL parsing of MySQL for making some parts optional? Is it PostgreSQL for
not supporting optional parts of SQL? Is it SugarCRM itself for ignoring
other databases?
-spc (Me? I'm willing to place this purely on PHP's hands, but than
again, I'm a programming language snob ... )
[1] http://www.sugarcrm.com/
[2] http://www.mysql.com/
[3] http://www.postgresql.org/
[4] http://www.php.net/manual/en/ref.pdo.php
[5] http://www.google.com/search?q=SugarCRM+PostgreSQL
[6] http://www.sugarcrm.com/forums/showthread.php?t=20138
yeah, it's dated 2007, but it's JANUARY, 2007.
[7] http://www.sugarcrm.com/forums/showpost.php?p=4641&postcount=10
[8] http://www.sugarcrm.com/forums/showpost.php?p=86781&postcount=3
[9] http://boston.conman.org/2007/12/17.1
[10] http://boston.conman.org/2007/12/17.2
[11] http://boston.conman.org/2007/12/18.1
From: Zach White Date: 01:57 on 14 Dec 2007 Subject: When is a POST not a POST? When it's a GET, of course! So, I don't know who is to blame, or what they were thinking, but someone on the Apache team needs to spend some quality time with Bubba and his lart. It seems that if you POST to url which maps to a file, Apache2 (on redhat and ubuntu, at least) serves that file as if you had issued a GET. Apache 1 as shipped with OpenBSD (properly) throws a 405 error. HATE, TOPPED WITH BILE, WITH A GOOD SPRINKLING OF SCORN ON TOP -Zach
From: Nicholas Clark
Date: 11:42 on 13 Dec 2007
Subject: emerge
Right. So I have "emerge"d something that I realise doesn't do what I want.
So I want to undo that.
Easy? No.
There is no simple option to do it. By simple, I mean simple for the user
--unmerge (-C)
WARNING: This action can remove important packages! Removes all
matching packages. This does no checking of dependencies, so it
may remove packages necessary for the proper operation of your
system. Its arguments can be atoms or ebuilds. For a dependency
aware version of --unmerge, use --depclean or --prune.
nope. Having warnings that big doesn't qualify as simple.
--prune (-P)
WARNING: This action can remove important packages! Removes all
but the highest installed version of a package from your system.
This action doesn't verify the possible binary compatibility
between versions and can thus remove essential dependencies from
your system. Use --prune together with --verbose to show reverse
dependencies or with --nodeps to ignore all dependencies.
nope. Again warnings that big *and* it isn't going to remove all versions of
something I don't need
--depclean
Cleans the system by removing packages that are not associated
with explicitly merged packages. Depclean works by creating the
full dependency tree from the system list and the world file,
then comparing it to installed packages. Packages installed, but
not associated with an explicit merge are listed as candidates
for unmerging. Inexperienced users are advised to use --pretend
nope. Removes everything, not just the one thing I'm interested in.
Why is this so hard? It is a simple task, that I can't have been the first
person needing to do it. It's almost as if the Gentoo developers don't
actually use Gentoo themselves.
Nicholas Clark
From: Earle Martin Date: 10:53 on 13 Dec 2007 Subject: Metadot Metadot is a vast heap of shit disguised as a CMS. Someone I used to work with, who still has to deal with it, hates it so much that his hate could not be contained in a mailing list post, thus he has made an entire website for it: http://www.ihatemetadot.co.uk/
< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 7 of 76 ]
Generated at 10:28 on 16 Apr 2008 by mariachi