This is kinda offtopic, but I've found bfilter to be a more effective ad-blocking solution. Since it's a proxy server, it works with any browser.
Disclaimer: I'm not associated with bfilter's development in any way, I'm just a happy user.
PostgreSQL's database size isn't limited by the file size limit of the underlying operating system -- it always splits the database into multiple files. The size limit comes (I think, don't have an URL handy) from a 64 bit integer overflowing.
I have a VoIP blaster and after testing the quality (on PC2PC conversations) I decided to pay for the PC2Phone service. However, InnoMedia decided that they don't want my money. The reason? They didn't like my email address, saying that they don't accept an email address in your own domain.
Well, screw that. I wonder how they managed to keep the product alive so long with such crappy service.
Being a romanian myself, I feel obliged to add the fact that this is a generic issue with telecommuting: there are certain kinds of work which simply don't fit in, no matter if the team is romanian or indian or chinese or whatever.
On the other hand, if you have good management, outsourcing can be a godsend, for a couple reasons:
It can be cheaper
It allows easier access to otherwise rare or expensive talent or expertise
If there's a time zone difference, you can turn that to your advantage and literally work around the clock
The culture difference can be an advantage too: different ways of thinking lead to a bigger pool of ideas, and generally results in tighter code/design discipline.
(none of the above depend on each other).
In conclusion, I think there's a general misconception about outsourcing, caused by the false assumption that cheaper always means worse. Sure, you get what you deserve if you hire a-dime-a-dozen {romanians,indians,chinese,whatever}, but there are also good people out there, and they are way cheaper than the US counterparts. You can have a top romanian programmers for around $1000-1500 and I can assure you they'll be sharp even by the most demanding standards.
There's a nice surprise in WindowMaker, but you can only see it on the Christmas eve. Take your system date back to December 24, then run wmaker, right click on the desktop then pick "Info Panel" from the "Info" menu to see the egg.
I only tested this with version 0.70 but I think it works with 0.80 too.
I'm using Evolution and Mutt as my primary mail clients now (I used to only use Mutt, but I forced myself into Evo so I could help with testing and bug reports). Evo is a very impressive application and I hope people who need such a tool will like it.
However, I don't need or want such a tool. I just want a mail client that logs into my IMAP server, reads and sends mail. That's it. Integrated {contact manager,calendar,task manager,whatever} is cool, but I don't want it. I need something that does a thing, and it does it well, and I hope that other mail(-only) clients will raise to the standard set by Evolution (so far only Mulberry was good enough but it's neither free or open source, and there are a couple things I don't like about it either).
While it's true that not all the un*x-based apps have been ported, most of them are there. Examples:
Oracle -- which is rock solid, and you can get support contracts from Oracle for the Linux platform (the company I work for uses Oracle/Linux in a mission critical environment and it works just fine).
All the other big databases (IBM DB2, Clustra, Informix, Sybase, etc)
Lots and lots of movie and animation production tools (Maya, Entropy, etc). Linux is really popular now amongst graphics and movie professionals.
The list could go on, but you get my point. What's more important are the advantages of Linux: superb development tools, open architecture, world-wide support, and so on.
On the performance front, it seems that you're not aware of the fact that Solaris (and other unices) scale up so well to high-end boxes at the expense of low-end performance. In case you didn't know it, the Linux kernel smokes away Solaris (in terms of syscall latency, throughput, response time, network performance and a couple other points) on servers with up to 4-8 CPUs.
Here's an article on the subject, written by Uwe Ohse (you can read the original article here. Many of the problems were fixed in the mean time, but it makes an interesting read nevertheless.
autoconf
config.guess, config.sub
There was no source from which one could get up-to-date version of
these scripts, which are used to determine the operating system type.
This often caused pain: asked the openbsd port maintainers about it.
(btw: there is now a canonical source for them, "ftp.gnu.org/gnu/config")
autoconf takes the wrong approach
The autoconf approach is, in short:
check for headers and define some preprocessor variables based
on the result.
check for functions and define some preprocessor variables.
replace functions not already found in the installed libraries.
Yes, it works, albeit some details are discouraging, to but it mildly.
No, it doesn't work good enough. This approach has lead to an
incredible amount of badly code around the world.
Studying the autoconf documentation one learns what kind of
incompatibilities exists. Using autoconf one can work around them.
But autoconf doesn't provide a known working solution of such
problems. Examples:
AC_REPLACE_FUNCS, a macro to replace a function not in the
systems libraries, leads to the inclusion of rarely used
code in the package - which is a recipe for disaster.
On the developers system the function unportable() is available,
on another system it isn't? Oh well, just compile unportable.c
there and link it into the programs...
Yes, this solves a problem. But it's overused, it's dangerous.
In many cases unportable.c doesn't work on the developers
system, so she can't test it. On other cases unportable.c only
works correctly on _one_ kind of system, but will be used on
others, too.
Yes, the often used packages _have_ been tested almost everywhere.
But what about the lesser often used?
Keep in mind that there is no central repository of replacement
functions anywhere...
The same is true for AC_CHECK_FUNC(S). In this case there isn't
a replacement source file, but even worse, there's an #ifdef
inside the main sources, unless the programmers are careful
to use wrappers, which they often aren't, because compatibility
problems are often discovered very late in the testing process
(or even after release) and people are usually trying to make
the smallest possible changes.
This is surely nothing which can be avoided completely, but
it's something which has to be avoided whereever possible.
In both cases you end up with rarely, if ever, used code in your
programs. It's not dead code, it's zombie code - one day, somewhere,
it will get alive again.
There's a solution to this problem, but it is completely different
from what's used now: Instead of providing bare workaround autoconf
(or a wrapper around it) ought to provide an abstraction layer
above it, and a central repository for such things.
That way a programmer wouldn't use opendir, readdir, closedir
directly but call they through the wrap_opendir, wrap_readdir
and wrap_closedir functions (i'm aware of the fact that the
GNU C library is this kind of wrapper, but it hasn't been
ported to lots of systems, and you can't rip only a few
functions out of it).
autoconf macros are inconsistent.
For example: AC_FUNC_FNMATCH
checks whether fnmatch is available and usable, and defines
HAVE_FNMATCH in this case. AC_FUNC_MEMCMP checks for availability
and usability of memcmp, and adds memcmp.o to LIBOBJS if that's
not the case. Other examples exist.
autoconf is not namespace-clean.
autoconf doesn't stick to a small set of prefixes for macro names.
For example it defines CLOSEDIR_VOID, STDC_HEADERS,
MAJOR_IN_MKDEV, WORDS_BIGENDIAN, in addition to a number of
HAVE_somethings.
I really dislike that, and it seems to get worse with every
new release.
My absolutely best-loved macro in this regard is
AC_FUNC_GETLOADAVG, which might define the following symbols:
SVR4, DGUX, UMAX, UMAX4_3, NLIST_STRUCT, NLIST_NAME_UNION,
GETLOADAVG_PRIVILEGED.
autoconf is large
I'm feeling uneasy about the sheer size of autoconf. I'm not
impressed: autoconf-2.13.tar.gz has a size of 440 KB. Add automake
to that (350 KB for version 1.4). Does it _really_ have to be
that large? I don't think so.
The size has a meaning - for me it means autoconf is very complicated.
It didn't use to be so, back in the "good old days". And it accomplished
it's task. I really don't see that it can do so much more today (i don't
mean "so much more for me").
configure is large
Even trivial configure scripts amount to 70 KB of size. Not much?
Compressed with gzip it's still 16 KB. Multiply that by millions of
copies and millions of downloads.
No, i don't object to the size. It's perfectly ok if you get something
for it. But you don't, about one half or more of each configure script
can be thrown away without any lossage.
Large parts of it just deal
with caching, which wouldn't be needed if configure wasn't so slow.
Other parts of it are the --help output, which looks so good...
but doesn't help usually (try it and find out what to do, without
reading README or INSTALL).
Then there is the most bloated
command line argument parser i've ever seen in any shell script.
Then there are many, many comments, but they aren't meant to
help you seeing what's going on inside configure, they are the
documentation for the macro maintainers (some might actually
prove to be useful, but the vast majority doesn't).
The configure scripts are the utter horror to read. There's a
reason for this: configure doesn't use any "advanced" feature
of the shell. But i wonder - are shell functions really
unportable? And if the answer is yes: Do you really expect
anything to work on that system? The problem is that a shell
that old is unlikely to handle almost anything, for example
large here documents.
The configure scripts are the utter horror to debug. Please just
try _once_ to debug 4000 lines of automatically generated shell
scripts.
Note the autoconf maintainers: The road you're on is going
to end soon.
autoconf is badly maintained
Let me clarify this first: I don't think bad about the developement.
I'm missing maintainance of the already released versions.
Now, at the end of 2000, almost two years have passed without
a maintainance release of autoconf. 9 months have passed since
a security problem has been found (in the handling of temporary files).
There have more bugs been found, of course.
I know that nobody likes to dig in old code, but 2 years are
a little bit much.
automake
My primary objection to automake is that automake forces me to use
the same version of autoconf everywhere. Autoconf has a large number
of inter-version conflicts anyway, but automake makes that situation
worse, much worse.
I'd need the same version of both tools on all machines i happen to
touch the Makefile.am or configure.in or any other autoconf input
file on. There are a number of reasons for that, one of them is that
automake used to provide some autoconf-macros during the years autoconf
wasn't developed at all, and these macros are now moved to autoconf,
where they belong to. But if you happen to use, say, AM_PROG_INSTALL,
and later versions declare that macro obsolete...
That doesn't sound too bad? Ok, but suppose
update all those machines regulary (i'm not going to really do
that, i'd rather stick to what's installed, but anyway)
i didn't touch a project for, say, 2 years, and then i need to
change something and release a new version. This involves changing
the version number in configure.in.
In more cases than not this will need considerable changes to
configure.in. Some major, most minor - but even the minor ones
need attention.
I found that hard to deal with. Things were even worse since every
CVS checkout tends to change time stamps, which can mean that
autoreconf is run even if there's no chance been done to any
autconf input file.
Don't misunderstand me: i don't attribute that to automake. I attribute
it to the internal instability of autoconf. Unfortunately you can't
have automake without autoconf.
libtool
Libtool adds an additional layer of complexity. I never had any reason
to look at the insides of libtool (which proves that it worked for me).
But having one project which used autoconf, automake and libtool
together was enough - never again. I got exactly the same problems
as i got with automake, described above, but they were worse and
happened more often.
One problem with libtool is that releases don't happen very often.
Libtool rarely is up to date with regards to changes on some
operating systems. Which makes it difficult to use in packages
meant to be really portable (to put it mildly).
A libtool script and a number of support files are distributed with
every package making use of libtool, which ensures that any user
can compile the package without having to install libtool before.
Sounds good? But it isn't.
This approach means that you can't
replace all old libtool stuff on your system easiely.
It also means that every package you try to compile can have a
different version of libtool. And since alpha versions of libtool
are often used it's not unlikely that you happen to meet
one of these versions.
Another problem is the size of the libtool script. 4200 lines...
summary
Autoconf is the weak link of the three tools, without any doubt.
Version 1 wasn't really designed, version 2 made a half-hearted
attempt of dealing with design problems. I'm not sure about the
next version.
Sheesh, after all the work of brainwashing people on buying me Dreamcasts for Christmas, now I need to do it again for something else (since the darn thing won't run Linux).
XML is a format. Using it just because you can (which unfortunately represents most of its current usage) is stupid. Examples:
XML databases. Excuse me? What sane person would store a massive amount of data with the on-disk format being XML? What's the point?
Configuration files (especially the Java stuff is plagued by this). Why on earth would you want to replace "theparameter = thevalue" by "<theparameter value="thevalue">" ? I've seen software embedding an XML parser for the sole purpose of parsing the config file... I don't know about you, but that seems just plain wrong to me.
Messaging protocols designed to be lightweight and/or very low overhead. Now don't get me wrong, I think that XML-RPC is very nice and everything, but to use it (for example) for in-cluster message passing of a distributed database would add so much overhead (with exactly zero benefits) that only a marketing guy could take such a decision.
The list could go on and on and on. Just remember: use each tool when it's needed. Don't just put XML in there because it's a nice buzzword, mkay?
PS: on the subject of the article... Again, I fail to see where XML comes in. Hierarchical DBs have been around for a long while, and even if they've been shadowed by the RDBMS' it doesn't mean they're dead (I'm working on a project which uses a hierarchical database simulated on top of BerkeleyDB. Works wonderful, and there's no need for SQL. Or XML, for that matter).
I too have a knee-jerk reaction to advertising, however I think I would love to have such a service done right, and delivered into my car. I don't know about you, but I think that being in an unknown area and getting notified of nearby restaurants/shops/whatever is kinda neat.
Don't forget advertising's original goal: to get the word out about products.
The very existence of ext3, and it's complete forward and backward compatibility with ext2, shows that ext2 was extremely well designed by it's authors. Kudos to Remy Card, Ted Tso, and the rest of the ext2 team!
Also, based on the same extensibility of ext2, Daniel Phillips is working on a directory indexing patch which speeds up ext2 by a huge factor when working with lots of files in a directory. You can get the preliminary patches here and see a graph of a simple file creation benchmark here. Amazing!
For those who asked: as I said in the previous post, I don't know what Austin's plans are, but I believe that it will be the same as with the current Mac and Win32 versions: if you have the CD, you can play on any platform.
Thus, people who already bought the CD can simply download and run the Linux version with no extra money to pay.
PS: (the shameless plug part) I'd love it if I got a job working on flight sims, I'm sick and tired of web development:)
I'm the guy doing the port. I'm not sure whether Austin had plans for this but I guess he gave up after the repeated requests he got to give me the source to port on it. Some details:
1. It won't be open source.
2. It won't be free (I don't know what Austin's plans are but I guess the price will be the same as the Win/Mac version).
3. I'm not getting any money for doing the port -- as I told Austin, I'm doing it for the sake of having a good flight sim for Linux.
4. The file format, network data and outputs will be compatible with the Win/Mac version.
5. The port uses libSDL (before you scream bloody murder about license violation, have a look and note that it's dynamically linked).
6. Since it's SDL-based, a FreeBSD port should be easy enough to do once the general *nix porting issues are solved. I don't know what's the status of OpenGL on FreeBSD; X-Plane *requires* OpenGL and you probably don't want to run it in software emulation. Until a native FreeBSD version will exist, the Linux binaries should run just fine using the Linux compatibility mode (but see the OpenGL notes above).
If you want to see the full app happening, here's how you can help:
1. Download the beta, test it, and send me feedback.
2. Email austin@x-plane.com and tell him that you think a Linux version of X-Plane is great. This is needed because I only got the subprograms source so far, and he doesn't seem 100% convinced yet to send me the main source too.
Have a look at the RLX System 324. It's basically a 3U chassis holding 24 independent servers. The chassis provides power (so you only need 14 power cables to power all the machines) and network (3 networks, public, private and management). The power requirements are quite low too (they're based on Crusoe).
I had pretty good luck with a Kinesis contoured keyboard. After the initial (about one week) adaptation period I regained my original typing speed, and after a couple more weeks I'm typing much faster than before (and wrist pain is gone!). They also provide some very handy training/adaptation exercises.
The problem is that the prices start at $200+:(
PS: I'm not affiliated in any way with Kinesis... just being a happy user:)
Roxen Web Server (former Roxen Challenger) is a quite good choice (amongst many others it has native servlet/Java modules support and speaks WML natively (also knows to generate WBM)). Plus, it's GPL'd.
Slashdot Mirror
This is kinda offtopic, but I've found bfilter to be a more effective ad-blocking solution. Since it's a proxy server, it works with any browser.
Disclaimer: I'm not associated with bfilter's development in any way, I'm just a happy user.
PostgreSQL's database size isn't limited by the file size limit of the underlying operating system -- it always splits the database into multiple files. The size limit comes (I think, don't have an URL handy) from a 64 bit integer overflowing.
I have a VoIP blaster and after testing the quality (on PC2PC conversations) I decided to pay for the PC2Phone service. However, InnoMedia decided that they don't want my money. The reason? They didn't like my email address, saying that they don't accept an email address in your own domain.
Well, screw that. I wonder how they managed to keep the product alive so long with such crappy service.
Yes, try the Open Web Application Security Project. They released a very informative paper on building secure webapps, and it's free.
(I'm not affiliated with them in any way)
vi or emacs?
Dude, where's my finger?!??
freespechcentersucks.org?
:)
Being a romanian myself, I feel obliged to add the fact that this is a generic issue with telecommuting: there are certain kinds of work which simply don't fit in, no matter if the team is romanian or indian or chinese or whatever.
On the other hand, if you have good management, outsourcing can be a godsend, for a couple reasons:
- It can be cheaper
- It allows easier access to otherwise rare or expensive talent or expertise
- If there's a time zone difference, you can turn that to your advantage and literally work around the clock
- The culture difference can be an advantage too: different ways of thinking lead to a bigger pool of ideas, and generally results in tighter code/design discipline.
(none of the above depend on each other).In conclusion, I think there's a general misconception about outsourcing, caused by the false assumption that cheaper always means worse. Sure, you get what you deserve if you hire a-dime-a-dozen {romanians,indians,chinese,whatever}, but there are also good people out there, and they are way cheaper than the US counterparts. You can have a top romanian programmers for around $1000-1500 and I can assure you they'll be sharp even by the most demanding standards.
There's a nice surprise in WindowMaker, but you can only see it on the Christmas eve. Take your system date back to December 24, then run wmaker, right click on the desktop then pick "Info Panel" from the "Info" menu to see the egg.
I only tested this with version 0.70 but I think it works with 0.80 too.
(mandatory comment)
Can you imagine a Beowulf cluster of those things?
I'm using Evolution and Mutt as my primary mail clients now (I used to only use Mutt, but I forced myself into Evo so I could help with testing and bug reports). Evo is a very impressive application and I hope people who need such a tool will like it.
However, I don't need or want such a tool. I just want a mail client that logs into my IMAP server, reads and sends mail. That's it. Integrated {contact manager,calendar,task manager,whatever} is cool, but I don't want it. I need something that does a thing, and it does it well, and I hope that other mail(-only) clients will raise to the standard set by Evolution (so far only Mulberry was good enough but it's neither free or open source, and there are a couple things I don't like about it either).
While it's true that not all the un*x-based apps have been ported, most of them are there. Examples:
The list could go on, but you get my point. What's more important are the advantages of Linux: superb development tools, open architecture, world-wide support, and so on.
On the performance front, it seems that you're not aware of the fact that Solaris (and other unices) scale up so well to high-end boxes at the expense of low-end performance. In case you didn't know it, the Linux kernel smokes away Solaris (in terms of syscall latency, throughput, response time, network performance and a couple other points) on servers with up to 4-8 CPUs.
Here's an article on the subject, written by Uwe Ohse (you can read the original article here. Many of the problems were fixed in the mean time, but it makes an interesting read nevertheless.
autoconf config.guess, config.sub There was no source from which one could get up-to-date version of these scripts, which are used to determine the operating system type. This often caused pain: asked the openbsd port maintainers about it. (btw: there is now a canonical source for them, "ftp.gnu.org/gnu/config") autoconf takes the wrong approach The autoconf approach is, in short:
- check for headers and define some preprocessor variables based
on the result.
- check for functions and define some preprocessor variables.
- replace functions not already found in the installed libraries.
Yes, it works, albeit some details are discouraging, to but it mildly.No, it doesn't work good enough. This approach has lead to an incredible amount of badly code around the world.
Studying the autoconf documentation one learns what kind of incompatibilities exists. Using autoconf one can work around them. But autoconf doesn't provide a known working solution of such problems. Examples:
- AC_REPLACE_FUNCS, a macro to replace a function not in the
systems libraries, leads to the inclusion of rarely used
code in the package - which is a recipe for disaster.
On the developers system the function unportable() is available,
on another system it isn't? Oh well, just compile unportable.c
there and link it into the programs
...
- The same is true for AC_CHECK_FUNC(S). In this case there isn't
a replacement source file, but even worse, there's an #ifdef
inside the main sources, unless the programmers are careful
to use wrappers, which they often aren't, because compatibility
problems are often discovered very late in the testing process
(or even after release) and people are usually trying to make
the smallest possible changes.
In both cases you end up with rarely, if ever, used code in your programs. It's not dead code, it's zombie code - one day, somewhere, it will get alive again.Yes, this solves a problem. But it's overused, it's dangerous. In many cases unportable.c doesn't work on the developers system, so she can't test it. On other cases unportable.c only works correctly on _one_ kind of system, but will be used on others, too.
Yes, the often used packages _have_ been tested almost everywhere. But what about the lesser often used? ...
Keep in mind that there is no central repository of replacement functions anywhere
This is surely nothing which can be avoided completely, but it's something which has to be avoided whereever possible.
There's a solution to this problem, but it is completely different from what's used now: Instead of providing bare workaround autoconf (or a wrapper around it) ought to provide an abstraction layer above it, and a central repository for such things.
That way a programmer wouldn't use opendir, readdir, closedir directly but call they through the wrap_opendir, wrap_readdir and wrap_closedir functions (i'm aware of the fact that the GNU C library is this kind of wrapper, but it hasn't been ported to lots of systems, and you can't rip only a few functions out of it).
autoconf macros are inconsistent. For example: AC_FUNC_FNMATCH checks whether fnmatch is available and usable, and defines HAVE_FNMATCH in this case. AC_FUNC_MEMCMP checks for availability and usability of memcmp, and adds memcmp.o to LIBOBJS if that's not the case. Other examples exist. autoconf is not namespace-clean. autoconf doesn't stick to a small set of prefixes for macro names. For example it defines CLOSEDIR_VOID, STDC_HEADERS, MAJOR_IN_MKDEV, WORDS_BIGENDIAN, in addition to a number of HAVE_somethings. I really dislike that, and it seems to get worse with every new release.
My absolutely best-loved macro in this regard is AC_FUNC_GETLOADAVG, which might define the following symbols: SVR4, DGUX, UMAX, UMAX4_3, NLIST_STRUCT, NLIST_NAME_UNION, GETLOADAVG_PRIVILEGED. autoconf is large I'm feeling uneasy about the sheer size of autoconf. I'm not impressed: autoconf-2.13.tar.gz has a size of 440 KB. Add automake to that (350 KB for version 1.4). Does it _really_ have to be that large? I don't think so.
The size has a meaning - for me it means autoconf is very complicated. It didn't use to be so, back in the "good old days". And it accomplished it's task. I really don't see that it can do so much more today (i don't mean "so much more for me"). configure is large Even trivial configure scripts amount to 70 KB of size. Not much?
Compressed with gzip it's still 16 KB. Multiply that by millions of copies and millions of downloads.
No, i don't object to the size. It's perfectly ok if you get something for it. But you don't, about one half or more of each configure script can be thrown away without any lossage.
- Large parts of it just deal
with caching, which wouldn't be needed if configure wasn't so slow.
- Other parts of it are the --help output, which looks so good
...
but doesn't help usually (try it and find out what to do, without
reading README or INSTALL).
- Then there is the most bloated
command line argument parser i've ever seen in any shell script.
- Then there are many, many comments, but they aren't meant to
help you seeing what's going on inside configure, they are the
documentation for the macro maintainers (some might actually
prove to be useful, but the vast majority doesn't).
The configure scripts are the utter horror to read. There's a reason for this: configure doesn't use any "advanced" feature of the shell. But i wonder - are shell functions really unportable? And if the answer is yes: Do you really expect anything to work on that system? The problem is that a shell that old is unlikely to handle almost anything, for example large here documents.The configure scripts are the utter horror to debug. Please just try _once_ to debug 4000 lines of automatically generated shell scripts.
Note the autoconf maintainers: The road you're on is going to end soon. autoconf is badly maintained Let me clarify this first: I don't think bad about the developement. I'm missing maintainance of the already released versions. Now, at the end of 2000, almost two years have passed without a maintainance release of autoconf. 9 months have passed since a security problem has been found (in the handling of temporary files). There have more bugs been found, of course. ...
I know that nobody likes to dig in old code, but 2 years are a little bit much. automake My primary objection to automake is that automake forces me to use the same version of autoconf everywhere. Autoconf has a large number of inter-version conflicts anyway, but automake makes that situation worse, much worse.
I'd need the same version of both tools on all machines i happen to touch the Makefile.am or configure.in or any other autoconf input file on. There are a number of reasons for that, one of them is that automake used to provide some autoconf-macros during the years autoconf wasn't developed at all, and these macros are now moved to autoconf, where they belong to. But if you happen to use, say, AM_PROG_INSTALL, and later versions declare that macro obsolete
That doesn't sound too bad? Ok, but suppose
- update all those machines regulary (i'm not going to really do
that, i'd rather stick to what's installed, but anyway)
- i didn't touch a project for, say, 2 years, and then i need to
change something and release a new version. This involves changing
the version number in configure.in.
In more cases than not this will need considerable changes to configure.in. Some major, most minor - but even the minor ones need attention.I found that hard to deal with. Things were even worse since every CVS checkout tends to change time stamps, which can mean that autoreconf is run even if there's no chance been done to any autconf input file.
Don't misunderstand me: i don't attribute that to automake. I attribute it to the internal instability of autoconf. Unfortunately you can't have automake without autoconf. libtool Libtool adds an additional layer of complexity. I never had any reason to look at the insides of libtool (which proves that it worked for me). But having one project which used autoconf, automake and libtool together was enough - never again. I got exactly the same problems as i got with automake, described above, but they were worse and happened more often.
One problem with libtool is that releases don't happen very often. Libtool rarely is up to date with regards to changes on some operating systems. Which makes it difficult to use in packages meant to be really portable (to put it mildly).
A libtool script and a number of support files are distributed with every package making use of libtool, which ensures that any user can compile the package without having to install libtool before. Sounds good? But it isn't.
Another problem is the size of the libtool script. 4200 lines ...
summary
Autoconf is the weak link of the three tools, without any doubt.
Version 1 wasn't really designed, version 2 made a half-hearted
attempt of dealing with design problems. I'm not sure about the
next version.
Sheesh, after all the work of brainwashing people on buying me Dreamcasts for Christmas, now I need to do it again for something else (since the darn thing won't run Linux).
Ah well...
XML is a format. Using it just because you can (which unfortunately represents most of its current usage) is stupid. Examples:
The list could go on and on and on. Just remember: use each tool when it's needed. Don't just put XML in there because it's a nice buzzword, mkay?
PS: on the subject of the article... Again, I fail to see where XML comes in. Hierarchical DBs have been around for a long while, and even if they've been shadowed by the RDBMS' it doesn't mean they're dead (I'm working on a project which uses a hierarchical database simulated on top of BerkeleyDB. Works wonderful, and there's no need for SQL. Or XML, for that matter).
Wow, there's a new PDA out! Let's hack it and put Linux on it!
:)
... oh, wait, it already runs Linux. Move on geeks, nothing to hack here
I too have a knee-jerk reaction to advertising, however I think I would love to have such a service done right, and delivered into my car. I don't know about you, but I think that being in an unknown area and getting notified of nearby restaurants/shops/whatever is kinda neat.
Don't forget advertising's original goal: to get the word out about products.
The very existence of ext3, and it's complete forward and backward compatibility with ext2, shows that ext2 was extremely well designed by it's authors. Kudos to Remy Card, Ted Tso, and the rest of the ext2 team!
Also, based on the same extensibility of ext2, Daniel Phillips is working on a directory indexing patch which speeds up ext2 by a huge factor when working with lots of files in a directory. You can get the preliminary patches here and see a graph of a simple file creation benchmark here. Amazing!
For those who asked: as I said in the previous post, I don't know what Austin's plans are, but I believe that it will be the same as with the current Mac and Win32 versions: if you have the CD, you can play on any platform.
:)
Thus, people who already bought the CD can simply download and run the Linux version with no extra money to pay.
PS: (the shameless plug part) I'd love it if I got a job working on flight sims, I'm sick and tired of web development
I'm the guy doing the port. I'm not sure whether Austin had plans for this but I guess he gave up after the repeated requests he got to give me the source to port on it. Some details:
1. It won't be open source.
2. It won't be free (I don't know what Austin's plans are but I guess the price will be the same as the Win/Mac version).
3. I'm not getting any money for doing the port -- as I told Austin, I'm doing it for the sake of having a good flight sim for Linux.
4. The file format, network data and outputs will be compatible with the Win/Mac version.
5. The port uses libSDL (before you scream bloody murder about license violation, have a look and note that it's dynamically linked).
6. Since it's SDL-based, a FreeBSD port should be easy enough to do once the general *nix porting issues are solved. I don't know what's the status of OpenGL on FreeBSD; X-Plane *requires* OpenGL and you probably don't want to run it in software emulation. Until a native FreeBSD version will exist, the Linux binaries should run just fine using the Linux compatibility mode (but see the OpenGL notes above).
If you want to see the full app happening, here's how you can help:
1. Download the beta, test it, and send me feedback.
2. Email austin@x-plane.com and tell him that you think a Linux version of X-Plane is great. This is needed because I only got the subprograms source so far, and he doesn't seem 100% convinced yet to send me the main source too.
"Boss, there's a guy in here. He's Serious."
Have a look at the RLX System 324. It's basically a 3U chassis holding 24 independent servers. The chassis provides power (so you only need 14 power cables to power all the machines) and network (3 networks, public, private and management). The power requirements are quite low too (they're based on Crusoe).
I had pretty good luck with a Kinesis contoured keyboard. After the initial (about one week) adaptation period I regained my original typing speed, and after a couple more weeks I'm typing much faster than before (and wrist pain is gone!). They also provide some very handy training/adaptation exercises.
The problem is that the prices start at $200+ :(
PS: I'm not affiliated in any way with Kinesis... just being a happy user :)
This means that you are one of those lucky guys who didn't had to spend a couple a nights with isamchk, unwedging corrupted mysql tables.
There's no silver bullet: I've seen MySQL, Postgres and Oracle eating my data. Be afraid, and backup often.
Roxen Web Server (former Roxen Challenger) is a quite good choice (amongst many others it has native servlet/Java modules support and speaks WML natively (also knows to generate WBM)). Plus, it's GPL'd.