Sun has stated so on numerous occasions. It's actually been used as a "Java Technology" demo, in the past.
Re:Caught up with the speed, but still the ugliest
on
Java Faster Than C++?
·
· Score: 2, Insightful
Actually, you're wrong, at least in part. Due to lack of specificity, I'd say that invalidates your argument.
It's all about *where* and *how* Java is used.
As someone who has done application development with both Java and C++ (as well as C, and others), here is how it works (assuming equivalent levels of code quality regardless of language):
For a non-GUI application, Java can be made to run nearly as fast as C++, with a slight startup penalty, and while utilizing decidedly more RAM.
For a GUI applicaton, Java will run considerably slower than a C++ application, and use significantly more RAM.
What does this mean?
Java works great for back-end applications, for web applications, etc. Especially if you take into consideration it's startup penalty (time needed to start the JVM) and run your java program persistently, Java can definitely be fast enough for this.
As for GUI applications, Java is only an ideal choice if you absolutely need something that is fully cross-platform (without using multiple binaries for each), for small applications, or for situations where you can gaurantee that the client machine will have a LOT of RAM, and a fairly modern CPU.
Now, use which ever langauge makes the most sense for what you're doing, and let's get back to coding, okay?
If you're only seeing it as 20k, it's possible your distribution uses some kind of wrapper program that calls the "real" Python binary. I assure you, Python would not be nearly as useful as it is, if it were only a 20k binary.
And before anyone jumps in saying, "Those must be statically compiled and non-stripped binaries!", or something to that effect:
nexus:~$ file/usr/bin/python2.* /usr/bin/python2.1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/python2.2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/python2.3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
Python is a decent language, but it's definitely not lightweight, not when compared to languages like Scheme, Lua, etc.
There are dozens of available library implementations of reasonably well known languages. The trick is simply finding which one fits best for you. And, depending on the application, and how it's used, you might want to consider created a more generalized plug-in architecture, and allow for multiple scripting languages (possibly using something like CORBA).
One thing I would strongly urge, is to pick a "real" language that already exists. Ideally, something like those listed below. Even if it's a fairly uncommon language that you personally aren't familiar with, the fact that it's in use in the real world means that more people will be familiar with it, and that it will likely be a more stable and usable solution.
Creating a brand new language just for your application is a gauranteed way to annoy people because there is no chance that they will know the language before using your application.
Here are some possibilities, depending on what you're looking for:
Scheme/Lisp* based:
librep, used by Sawfish
Guile, the official GNU extension language
Elk, designed from the start as a small embeddable library
tinyscheme, another small implementation designed for embedded use
SIOD, a very small implementation that can be easily customized for your application
Kawa, a Scheme enivornment written in Java, that compiles Scheme code to java byte-codes, is an excellent choice for use in a Java application
Embeddable Common Lisp, while not as small or lightweight as most Scheme implementations, does a pretty decent job
For larger (and more common) languages, you can choose from:
JavaScript/ECMAScript, this is a great choice as it was designed to be used as an extension language, and there are at least a couple of free/open source implementations available. . . and it's use in web browsers/web pages has made it a very well known language
eperl, an embeddable form of Perl
Python, though not ideally setup for this, can be embedded in another program
tcl, tcl was designed parly for use as an embedded scripting language, and works fairly well in this regard
Some less well known, but still "real" languages that can make an excellent extension language include:
ficl, an implementation of Forth that's designed for embedded use
Lua, a language that was designed specifically to provide a small but powerful language for embedded use
S-Lang, a progammers library that provides a console GUI library and an extension language (used by jed, slrn, newt, mutt (optional), etc
cint, a C language style interpreter could probably be used easily enough
ch, another c interpreter
Bean Scripting Framework, BSF, is a great choice for java applications, as it provides a framework to use a numer of different languages, providing greater choice
Scriptix, an extension language with a C/C++ style syntax that evolved out of MUDix
ferite, an interpreter with "similiarities to perl, python, C, Java and pascal", and designed for embedded use
bsh, or BeanShell, is a small embeddable Java interpeter, written in Java, and has some extra "bonus" features of particular interest to scripters
* Scheme, due to it's small size and powerful, easily extendable syntax, seems to be quite common when it comes to extension langauges. A list of programs that use Scheme (or a similar lisp dialect) off the top of my head includes: SIAG Office, The Gimp, Emacs, TeXmacs, Gnumeric, AutoCAD, Sawfish, GnuCash, Snd Sound Editor, etc.
Actually, SourceForge is *not* Open Source any longer.
Check the URL you referenced, and you'll notice that the last release was made on 2001-11-04. And the code released there is actually even older than that, as the release date got updated when they moved it from the original Alexandria project.
SourceForge intentionally killed off public development of the SourceForge code, and then did an excellent job of convincing people that it was still an Open Source project. They kept promising and promising that the development code and CVS would be released, but it never was.
Take a good look at the URL you provided. . . where the's the web-accessible CVS repository? Heck, where's the CVS repository at all? Where's the development mailing lists?
It was all killed.
As another poster mentioned, GForge is a *much* better option.
You should do a little more research. . . there are a great number of truly amazing games available for GameCube. If you think the Resident Evil series is good, check out Eternal Darkness: Sanity's Requiem. It's what Resident Evil 0 should have been. Except that none of the Resident Evil games have actually been as good as Eternal Darkness.
Without knowing what kinds of games you like, it's hard to offer more specific suggestions, but you might be surprised at how many great GameCube games there are. Viewtiful Joe is one of the coolest things I've played in years, Ikaruga is still one of my favorites, although I've had it for almost a year now. Pac Man Vs. looks like an absolute blast for multiplayer (although the Mario Party games, and Super Smash Brothers currently rule that area). And let's not forget Final Fantasy: Chrystal Chronicles, which I'm hoping will live up to the hype, since FF: X2 has been rather disappointing.
And, you've also got available to you pretty much everything from EA, and most major cross-platform games, like Prince of Persia, Sphinx, etc.
[Information Disclsure: I currently own a PS2, GameCube, X-Box, Dreamcast, and PC. They all get played to some extent, but of the current consoles, the GameCube gets played the most, followed closely by PS2, and lastly (by a good bit) the X-Box.]
Erm. . . you do realize that Barnes & Noble did challenge Amazon's 1-Click patent, don't you?
It went to court, and was eventually settled. However, the settlement details were never disclosed, so we're not entirely sure how it turned out. As I recall, things weren't looking good for Barnes & Noble, though.
I'm carrying over double the load mentioned in the article on a single Pentium Pro 200 right now.
And, it runs other tasks than just the e-mail and web server.
Simple fact: E-mail and static web serving are very "cheap" tasks for today's CPU's. Even adding in a spam filter and a small (postgresql is my suggestion) database server will be handled fine by this machine. It's the Internet connection that will cost you. (Heck, a Pentium 200, serving static web pages, can easily saturate a T1 internet connection.)
If you spend more than $1000 on the machine in this scenario, you are wasting your money (and, yes, it could be done for a whole lot less than that).
My apologies. You are correct, and I should have been more clear.
When I said that the "only source code available" was two years old, I meant to say the "only official SourceForge source code available" was two years old.
The reason I didn't mention the Debian-SF fork (which I have used in the past, and consider a huge improvement over the stock SourceForge code available) is because I knew that most of it's excellent work had been folded into GForge, as you mention, and that the Debian-SF team's hard work is a chief reason for why GForge is improving as rapidly as it is.
As a very happy user of Debian-SF and GForge, thank you for your work there, and for pointing out my error here.
SourceForge is a Very Bad Idea (tm) at this point.
The only source code that is available is almost two years old, and the SourceForge.net people have intentionally killed further outside development of the official SourceForge project.
The current version of SourceForge is *not* available as source, at least, not without paying big bucks. In other words, it's no longer open source. Of course, SourceForge.net will squirm and twist things like there's no tomorrow to get away with not admitting that they closed SourceForge.
Additionally, the version of SourceForge that is available is unbelievably difficult to set up, doesn't run very well, and is very SourceForge.net specific. It's set up to run on PostgreSQL, and yet all the documentation (what (very) little there is) talks about MySQL.
If you want something like SourceForge, only more oriented towards a smaller, more private, organization, you should investigate GForge. GForge is a much reworked fork of SourceForge. The fork was started by Tim Purdue, one of the original, and primary, authors of SourceForge, and is now being actively developed by the community.
GForge has also had it's goals and orientation changed slightly from SourceForge's. SourceForge was designed to work as a huge farm, managing hundreds of thousands of users and programs. A huge portion of it's functionality is superfluous and overly complicated. GForge is a simplified and better organized application designed specifically for use by smaller groups and companies for their own projects.
Personally, for what it sounds like the original poster is looking for, I'd recommend GForge coupled with a good Wiki. That should cover almost everything he needs.
Hrm. Reading your comment here, I think there was a misunderstanding.
I misunderstood your comment as hinting that you couldn't find many of the more popular games on GameCube, when you were actually pointing out that instead of focusing on those, Nintendo was releasing many of the more innovative, if lesser-known, games.
All in all, I think we mostly agree, and now it's time for me to go back to playing my GameCube.;-)
I keep seeing this same type of comment, but it's actually quite misleading.
You are correct that the Nintendo Game Studios will not likely be producing any highly violent and sexual games any time soon. They do produce some absolutely amazing games without that, though, as Zelda, Mario, and others, show.
HOWEVER.
That does not mean that third-party developers aren't making them available. I'm currently playing Eternal Darkness: Sanity's Requiem, and I have BMX XXX sitting on the table next to my GameCube. Neither of these are "kiddie" games, and both earned a "Mature" rating. Both of them well deserve it, too. You also have the Resident Evil game series, and many others, available.
GameCube may be the system with the largest number of games for "younger gamers", but that doesn't mean that there is any shortage at all of "Adult" games. Quite the contrary, although many people don't realize it. And Nintendo has been working hard lately to increase cooperation between themselves and third-party developers, bringing more and more great games to the system.
As a final note, as someone else mentioned, Grand Theft Auto is in fact coming to GameCube towards the end of the year.;-)
I don't know that "almost everyone uses php+mysql+apache".
Personally, I much prefer php/perl+PostgreSQL+Apache. And I know I'm not the only one. Sometimes the most popular application isn't the best application (subject to your individual requirements, of course. . . but I've found PostgreSQL to be generally superior to MySQL for essentially all of my needs).
Oh, and subselects have been working great for me for years now.;-)
I have to agree, here. Photon MicroLight's work *really* well. Almost four years ago, I bought two of them (Red and Green). They both still work great, and I still haven't had to change the battery on the red one.
After getting them, a handful of friends of mine decided to purchase some, and I don't think any one of us has been at all disappointed. I now keep two in my pocket with me, as well as keeping one in my car, and a couple with my camping gear.
I would highly recommend these to anyone looking for a small (and *bright*) flashlight.
The GPL itself discriminates against commercial uses (i.e. a company MAY NOT distribute my software without the source.)
That's a load of crap.
The fact that a company bases it's business around the sale of software is a choice made by *that* company. That has nothing to do with discrimination.
The company is still free to sell the software (yes, they have to include source code with it), or sell support and services around it, or do a multitude of other things. In fact, the GPL explicitely grants permission to sell GPLed software.
All the GPL does is prevent a company from using something someone else wrote in a way that the original author doesn't approve of (under the terms of the GPL, which they've licensed their code under). If it wasn't under the GPL, you wouldn't (under copyright law) have a right to do much of anything with it.
The GPL is very uniform and non-discriminatory. Everyone has exactly the same rights of use under it, regardless of whether it is an individual, a corporation, or being used for non-profit, for profit, or for personal use.
You say, "a company MAY NOT distribute my software without the source". . . um, hello? If it's your software, then it's entirely up to you to determine the license it's released under. You don't have to GPL it. If you do, then yes, some other company has to release the source code if they distribute the software. . . that's the agreement they're accepting when they decide to distribute software that someone else has written.
Nice deliberate lie.
There was no lie.
I'm not sure whether your comments were deliberately misleading, in an attempt to discredit the GPL, or simply caused by ignorance and lack of understanding about the definition of 'discriminate'.
Socialism would permit the taking of (using the current example) the domain for use by the Government for the betterment of *everyone*, but it wouldn't condone the taking of property from one person and giving it to another simply because the latter person "had more to benefit".
If you're serious then I apologise in advance, because that has to be one of the biggest loads of BS I've ever seen.
I was going to write up a reply pointing out how utterly wrong your statement is, but I don't even know where to begin. One person owns something, but since someone else has more to gain from having that something, they should be entitled to it?
Attempting to find the logic in that would be enough to make someone's head explode.
Yeah. . . it can happen fairly easily. Especially if you track multiple releases, such as stable, testing, and unstable, utilizing the (somewhat) new "pinning" feature. Using pinning, you can install (say) a stable system, but easily install X Windows and Gnome from testing[1].
Follow all three, and add a few "extra" apt repositories, and you'll quickly hit the memory limit. I've heard that they're considering raising it in a future release, as this type of setup becomes more common.
Good luck!;-)
[1] You can find more information in the man page, apt_preferences(5).
My current install is b0rked tho. I can't get apt-get update / upgrade to work anymore (craps out with a memory error and can't parse some dpkg files) so I'll have to reinstall using the latest ISO and knx-hdinstall. So much for perfection...
Do you know offhand exactly what the error is?
Is it something about "dynamic memory map"?
If so, it's actually a semi-known error, and there's an easy fix. You see, what the problem is, is that you have too many thing listed in/etc/apt/sources.list, and too many packages being found. APT is attempting to load and compile information for the whole set, and the default memory cache size (6MB, as I recall) isn't enough to hold it all. What you need to do is change a setting in/etc/apt/apt.conf to make it larger, and then life will be good.
If the error I mentioned is what you're seeing, or something similar, try adding the following directive to/etc/apt/apt.conf:
APT {
Cache-Limit "12582915"; };
Note that what this does is double the size of the dynamic memory map that APT uses (specified in bytes).
If it's bombing out while trying to read an APT file, it's possible you have a corrupted packages file or something. Try clearing out the files in/var/lib/apt/lists/ and then rerunning apt-get update.
1. No simple equivalent of SHOW COLUMNS. Consequently, it's hard to find any high level language API that allows you to read the structure of a database. Python... nope. Tcl... nope. Perl... nope. (Or at least not the last time I checked).
Erm. . . doesn't "\d TABLENAME" give you the information that you want? Or perhaps I'm not understanding what you're looking for. It's been a little while since I've used MySQL, but I remember this being the equivalent syntax.
2. Proper keyboard support for the psql client is broken by default on many of the linux installs I work on (debian seems to be particularly bad). It's *very* frustrating trying when the arrow keys and tab completion doesn't work.
I've actually never had a problem with this, at least not on any of the Debian, Red Hat, or NetBSD machines that I regularly use PostgreSQL on. Arrow keys and tab completion seem to work perfectly for me on the Debian box I'm currently working from.
3. The documentation is tough reading. Very formal. Obviously done by comp-sci academics.
All of it? Have you tried the two PostgreSQL books that are online (full text, free)? Both are fairly good general purpose books, and I'd say they're quite accessible to average techies.
No matter how hard I try, I cannot grok the date-time functions, which I find to be extremely cryptic. For example, the simplest way I've found to calculate the number of days elapsed between today and a given date is:
I won't really comment here, as I've never had any real problems dealing with dates. I can't offer you a simpler form for that calculation off hand, but I'm pretty sure one must exist.
There should be no problem with that. . . I have my incoming mail presorted to different mailboxes, with basically anything that isn't going to a high-volume mailing list going to my Inbox (which is currently ~/Mailbox). Everything that hits my Inbox stays there, unless I explicitely delete it or move it.
My Inbox currently sports about 26,000 e-mails, and sits at around 112MB.;-)
I actually utilize it the same way as you, with a constant screen running so I don't have to parse my (huge) mailbox every time I start.
There is an option (I believe it's "set move=no") that you can set in.muttrc that will tell it to leave e-mail where it is (in your case/var/spool/mail/, and not move it to an alternate folder, if that's what you're wanting.
If you do give mutt a try, one thing I will say for it is that it's among the most configurable e-mail programs I've come across. I highly recommend browsing thorugh this file, which is a "complete" sample.muttrc, including essentially every available configuration directive. I started with the Pine.rc file and then went through the file linked above, and added/changed things as I wanted, until everything "worked" how I wanted it to.;-)
If you're a long time Pine fan, then it can actually be very easy to switch to Mutt. Mutt is generally distributed with a couple of sample.muttrc files (mutt config files). Generally one of them is called Pine.rc (/usr/share/doc/mutt/examples/Pine.rc on my Debian box).
Moving this file to ~/.muttrc will actually remap the mutt keys to very closely mimic pine. I did this when I first moved from pine to mutt, and within a day or so, I was using it comfortably. I then spent the next few weeks making minor tweaks to really make mutt work how I want it to.
Note that mutt uses vim much easier than Pine does (I'm a long time vim lover, too;-).
Would you to elaborate as to which 'UNIX systems' you might be refering to?
Particularly as this is contrary to common e-mail message standards (see RFC 822, among others).
I know I personally have not come across any non-broken SMTP servers that are case sensitive.
Sun has stated so on numerous occasions. It's actually been used as a "Java Technology" demo, in the past.
Actually, you're wrong, at least in part. Due to lack of specificity, I'd say that invalidates your argument.
It's all about *where* and *how* Java is used.
As someone who has done application development with both Java and C++ (as well as C, and others), here is how it works (assuming equivalent levels of code quality regardless of language):
For a non-GUI application, Java can be made to run nearly as fast as C++, with a slight startup penalty, and while utilizing decidedly more RAM.
For a GUI applicaton, Java will run considerably slower than a C++ application, and use significantly more RAM.
What does this mean?
Java works great for back-end applications, for web applications, etc. Especially if you take into consideration it's startup penalty (time needed to start the JVM) and run your java program persistently, Java can definitely be fast enough for this.
As for GUI applications, Java is only an ideal choice if you absolutely need something that is fully cross-platform (without using multiple binaries for each), for small applications, or for situations where you can gaurantee that the client machine will have a LOT of RAM, and a fairly modern CPU.
Now, use which ever langauge makes the most sense for what you're doing, and let's get back to coding, okay?
Erm. . . Python is a little bigger than that (and it's also getting bigger with each new release):
/usr/bin/python* /usr/bin/python2.1* /usr/bin/python2.2* /usr/bin/python2.3*
/usr/bin/python2.*
/usr/bin/python2.1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
/usr/bin/python2.2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
/usr/bin/python2.3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
nexus:~$ dir
-rwxr-xr-x 1 root root 511K Jul 4 2003
-rwxr-xr-x 1 root root 832K Nov 17 18:22
-rwxr-xr-x 1 root root 961K Jan 4 05:29
If you're only seeing it as 20k, it's possible your distribution uses some kind of wrapper program that calls the "real" Python binary. I assure you, Python would not be nearly as useful as it is, if it were only a 20k binary.
And before anyone jumps in saying, "Those must be statically compiled and non-stripped binaries!", or something to that effect:
nexus:~$ file
Python is a decent language, but it's definitely not lightweight, not when compared to languages like Scheme, Lua, etc.
One thing I would strongly urge, is to pick a "real" language that already exists. Ideally, something like those listed below. Even if it's a fairly uncommon language that you personally aren't familiar with, the fact that it's in use in the real world means that more people will be familiar with it, and that it will likely be a more stable and usable solution.
Creating a brand new language just for your application is a gauranteed way to annoy people because there is no chance that they will know the language before using your application.
Here are some possibilities, depending on what you're looking for:
Scheme/Lisp* based:
For larger (and more common) languages, you can choose from:
Some less well known, but still "real" languages that can make an excellent extension language include:
* Scheme, due to it's small size and powerful, easily extendable syntax, seems to be quite common when it comes to extension langauges. A list of programs that use Scheme (or a similar lisp dialect) off the top of my head includes: SIAG Office, The Gimp, Emacs, TeXmacs, Gnumeric, AutoCAD, Sawfish, GnuCash, Snd Sound Editor, etc.
Actually, SourceForge is *not* Open Source any longer.
Check the URL you referenced, and you'll notice that the last release was made on 2001-11-04. And the code released there is actually even older than that, as the release date got updated when they moved it from the original Alexandria project.
SourceForge intentionally killed off public development of the SourceForge code, and then did an excellent job of convincing people that it was still an Open Source project. They kept promising and promising that the development code and CVS would be released, but it never was.
Take a good look at the URL you provided. . . where the's the web-accessible CVS repository? Heck, where's the CVS repository at all? Where's the development mailing lists?
It was all killed.
As another poster mentioned, GForge is a *much* better option.
You should do a little more research. . . there are a great number of truly amazing games available for GameCube. If you think the Resident Evil series is good, check out Eternal Darkness: Sanity's Requiem. It's what Resident Evil 0 should have been. Except that none of the Resident Evil games have actually been as good as Eternal Darkness.
Without knowing what kinds of games you like, it's hard to offer more specific suggestions, but you might be surprised at how many great GameCube games there are. Viewtiful Joe is one of the coolest things I've played in years, Ikaruga is still one of my favorites, although I've had it for almost a year now. Pac Man Vs. looks like an absolute blast for multiplayer (although the Mario Party games, and Super Smash Brothers currently rule that area). And let's not forget Final Fantasy: Chrystal Chronicles, which I'm hoping will live up to the hype, since FF: X2 has been rather disappointing.
And, you've also got available to you pretty much everything from EA, and most major cross-platform games, like Prince of Persia, Sphinx, etc.
[Information Disclsure: I currently own a PS2, GameCube, X-Box, Dreamcast, and PC. They all get played to some extent, but of the current consoles, the GameCube gets played the most, followed closely by PS2, and lastly (by a good bit) the X-Box.]
Erm. . . you do realize that Barnes & Noble did challenge Amazon's 1-Click patent, don't you?
It went to court, and was eventually settled. However, the settlement details were never disclosed, so we're not entirely sure how it turned out. As I recall, things weren't looking good for Barnes & Noble, though.
Absolutely on the mark.
I'm carrying over double the load mentioned in the article on a single Pentium Pro 200 right now.
And, it runs other tasks than just the e-mail and web server.
Simple fact: E-mail and static web serving are very "cheap" tasks for today's CPU's. Even adding in a spam filter and a small (postgresql is my suggestion) database server will be handled fine by this machine. It's the Internet connection that will cost you. (Heck, a Pentium 200, serving static web pages, can easily saturate a T1 internet connection.)
If you spend more than $1000 on the machine in this scenario, you are wasting your money (and, yes, it could be done for a whole lot less than that).
My apologies. You are correct, and I should have been more clear.
When I said that the "only source code available" was two years old, I meant to say the "only official SourceForge source code available" was two years old.
The reason I didn't mention the Debian-SF fork (which I have used in the past, and consider a huge improvement over the stock SourceForge code available) is because I knew that most of it's excellent work had been folded into GForge, as you mention, and that the Debian-SF team's hard work is a chief reason for why GForge is improving as rapidly as it is.
As a very happy user of Debian-SF and GForge, thank you for your work there, and for pointing out my error here.
SourceForge is a Very Bad Idea (tm) at this point.
The only source code that is available is almost two years old, and the SourceForge.net people have intentionally killed further outside development of the official SourceForge project.
The current version of SourceForge is *not* available as source, at least, not without paying big bucks. In other words, it's no longer open source. Of course, SourceForge.net will squirm and twist things like there's no tomorrow to get away with not admitting that they closed SourceForge.
Additionally, the version of SourceForge that is available is unbelievably difficult to set up, doesn't run very well, and is very SourceForge.net specific. It's set up to run on PostgreSQL, and yet all the documentation (what (very) little there is) talks about MySQL.
If you want something like SourceForge, only more oriented towards a smaller, more private, organization, you should investigate GForge. GForge is a much reworked fork of SourceForge. The fork was started by Tim Purdue, one of the original, and primary, authors of SourceForge, and is now being actively developed by the community.
GForge has also had it's goals and orientation changed slightly from SourceForge's. SourceForge was designed to work as a huge farm, managing hundreds of thousands of users and programs. A huge portion of it's functionality is superfluous and overly complicated. GForge is a simplified and better organized application designed specifically for use by smaller groups and companies for their own projects.
Personally, for what it sounds like the original poster is looking for, I'd recommend GForge coupled with a good Wiki. That should cover almost everything he needs.
Hrm. Reading your comment here, I think there was a misunderstanding.
;-)
I misunderstood your comment as hinting that you couldn't find many of the more popular games on GameCube, when you were actually pointing out that instead of focusing on those, Nintendo was releasing many of the more innovative, if lesser-known, games.
All in all, I think we mostly agree, and now it's time for me to go back to playing my GameCube.
I keep seeing this same type of comment, but it's actually quite misleading.
;-)
You are correct that the Nintendo Game Studios will not likely be producing any highly violent and sexual games any time soon. They do produce some absolutely amazing games without that, though, as Zelda, Mario, and others, show.
HOWEVER.
That does not mean that third-party developers aren't making them available. I'm currently playing Eternal Darkness: Sanity's Requiem, and I have BMX XXX sitting on the table next to my GameCube. Neither of these are "kiddie" games, and both earned a "Mature" rating. Both of them well deserve it, too. You also have the Resident Evil game series, and many others, available.
GameCube may be the system with the largest number of games for "younger gamers", but that doesn't mean that there is any shortage at all of "Adult" games. Quite the contrary, although many people don't realize it. And Nintendo has been working hard lately to increase cooperation between themselves and third-party developers, bringing more and more great games to the system.
As a final note, as someone else mentioned, Grand Theft Auto is in fact coming to GameCube towards the end of the year.
I don't know that "almost everyone uses php+mysql+apache".
;-)
Personally, I much prefer php/perl+PostgreSQL+Apache. And I know I'm not the only one. Sometimes the most popular application isn't the best application (subject to your individual requirements, of course. . . but I've found PostgreSQL to be generally superior to MySQL for essentially all of my needs).
Oh, and subselects have been working great for me for years now.
I have to agree, here. Photon MicroLight's work *really* well. Almost four years ago, I bought two of them (Red and Green). They both still work great, and I still haven't had to change the battery on the red one.
After getting them, a handful of friends of mine decided to purchase some, and I don't think any one of us has been at all disappointed. I now keep two in my pocket with me, as well as keeping one in my car, and a couple with my camping gear.
I would highly recommend these to anyone looking for a small (and *bright*) flashlight.
The fact that a company bases it's business around the sale of software is a choice made by *that* company. That has nothing to do with discrimination.
The company is still free to sell the software (yes, they have to include source code with it), or sell support and services around it, or do a multitude of other things. In fact, the GPL explicitely grants permission to sell GPLed software.
All the GPL does is prevent a company from using something someone else wrote in a way that the original author doesn't approve of (under the terms of the GPL, which they've licensed their code under). If it wasn't under the GPL, you wouldn't (under copyright law) have a right to do much of anything with it.
The GPL is very uniform and non-discriminatory. Everyone has exactly the same rights of use under it, regardless of whether it is an individual, a corporation, or being used for non-profit, for profit, or for personal use.
You say, "a company MAY NOT distribute my software without the source". . . um, hello? If it's your software, then it's entirely up to you to determine the license it's released under. You don't have to GPL it. If you do, then yes, some other company has to release the source code if they distribute the software. . . that's the agreement they're accepting when they decide to distribute software that someone else has written.
There was no lie.
I'm not sure whether your comments were deliberately misleading, in an attempt to discredit the GPL, or simply caused by ignorance and lack of understanding about the definition of 'discriminate'.
The goal is to benefit everyone.
Either way, the problem is that I'm talking theory, and you're (cynically) talking about your perception of reality.
Even socialism wouldn't go this far.
Socialism would permit the taking of (using the current example) the domain for use by the Government for the betterment of *everyone*, but it wouldn't condone the taking of property from one person and giving it to another simply because the latter person "had more to benefit".
If you're serious then I apologise in advance, because that has to be one of the biggest loads of BS I've ever seen.
I was going to write up a reply pointing out how utterly wrong your statement is, but I don't even know where to begin. One person owns something, but since someone else has more to gain from having that something, they should be entitled to it?
Attempting to find the logic in that would be enough to make someone's head explode.
Yeah. . . it can happen fairly easily. Especially if you track multiple releases, such as stable, testing, and unstable, utilizing the (somewhat) new "pinning" feature. Using pinning, you can install (say) a stable system, but easily install X Windows and Gnome from testing[1].
;-)
Follow all three, and add a few "extra" apt repositories, and you'll quickly hit the memory limit. I've heard that they're considering raising it in a future release, as this type of setup becomes more common.
Good luck!
[1] You can find more information in the man page, apt_preferences(5).
Is it something about "dynamic memory map"?
If so, it's actually a semi-known error, and there's an easy fix. You see, what the problem is, is that you have too many thing listed in
If the error I mentioned is what you're seeing, or something similar, try adding the following directive to
APT {
Cache-Limit "12582915";
};
Note that what this does is double the size of the dynamic memory map that APT uses (specified in bytes).
If it's bombing out while trying to read an APT file, it's possible you have a corrupted packages file or something. Try clearing out the files in
Practical PostgreSQL
PostgreSQL: Introduction and Concepts I won't really comment here, as I've never had any real problems dealing with dates. I can't offer you a simpler form for that calculation off hand, but I'm pretty sure one must exist.
MySQL 4.0 is still officially considered "beta" software, though. You can't fairly count features unless they're found in the released stable version.
There should be no problem with that. . . I have my incoming mail presorted to different mailboxes, with basically anything that isn't going to a high-volume mailing list going to my Inbox (which is currently ~/Mailbox). Everything that hits my Inbox stays there, unless I explicitely delete it or move it.
;-)
.muttrc that will tell it to leave e-mail where it is (in your case /var/spool/mail/, and not move it to an alternate folder, if that's what you're wanting.
.muttrc, including essentially every available configuration directive. I started with the Pine.rc file and then went through the file linked above, and added/changed things as I wanted, until everything "worked" how I wanted it to. ;-)
My Inbox currently sports about 26,000 e-mails, and sits at around 112MB.
I actually utilize it the same way as you, with a constant screen running so I don't have to parse my (huge) mailbox every time I start.
There is an option (I believe it's "set move=no") that you can set in
If you do give mutt a try, one thing I will say for it is that it's among the most configurable e-mail programs I've come across. I highly recommend browsing thorugh this file, which is a "complete" sample
If you're a long time Pine fan, then it can actually be very easy to switch to Mutt. Mutt is generally distributed with a couple of sample .muttrc files (mutt config files). Generally one of them is called Pine.rc (/usr/share/doc/mutt/examples/Pine.rc on my Debian box).
Moving this file to ~/.muttrc will actually remap the mutt keys to very closely mimic pine. I did this when I first moved from pine to mutt, and within a day or so, I was using it comfortably. I then spent the next few weeks making minor tweaks to really make mutt work how I want it to.
Note that mutt uses vim much easier than Pine does (I'm a long time vim lover, too;-).