Every major Linux distribution now offering a 64-bit version does not count as mainstream? Besides, the x86_64 port can now safely be called stable. The remaining kinks, if you want to call that, concern mostly applications that do not work natively in 64-bit mode, but that is why distributions provide the 32-bit backward compatibility libraries.
Of course, using assertions heavily can incur a significant performance hit, which may or may not be acceptable in your particular application. [...]
Interestingly, the performance hit seems to be almost negiglible on an AMD Opteron in 64-bit mode with gcc 3.4, as long as the assertions themselves are trivial. AMD must have done some really nice things with the branch prediction unit. Way to go.
And yes, I do agree that assertions belong into production code. I cannot count the number of times when they have saved our butts and exposed design or coding flaws. The "impossible" can and does happen more quickly than people would make you believe in general.
If it is just you working on the project, you do not need to run a CVS server at all. Just having the cvs command available on your system is enough. Likewise, this means that you do not have to worry about patching your CVS installation to defend against attacks on the 'Net. Of course, it still makes sense to keep your software up to date against local exploits, but that is just plain common sense.
To back up data, you just back up the directory that contains the CVS repository. There are no special files, databases, etc. Everything is a plain, simple, old text file. That also means that you will not encounter compatibility problems between clients on different platforms. The CVS file format has been stable for countless years.
The benefits are many:
- You keep a complete history of the changes you made to your software, along with a changelog.
- You can go back to any intermediate version, even between changes you made on a single day. You say that you do this very rarely, but it is still good to have it, just in case.
- You can fork the code if you want to do something experimental, and merge the changes back later.
- You keep a clean separation between your source code and th files that are generated during a build. For instance, if you want to compile with different compiler options, such as debug vs release, you can just check out the source into two different directories and build each to taste. Similarly, when you want to distribute or release the source code, just do a fresh checkout into a new directory, and tar that up - without any worries that there might be superfluous intermediate files in the tarball.
- and more...
Why don't you just try it? Setting up cvs with your project is as simple as installing an rpm/deb/ebuild, cvs -d/path/to/repository init, cvs -d/path/to/repository import, followed by a fresh checkout.
No, the point of Gentoo is not optimization, although it is certainly possible to use the distribution in this fashion. The main point is that Gentoo is a meta-distribution that lets you customize the setup every which way. Other distributions make package configuration decisions for you, whereas Gentoo allows you to make them yourself.
Want ALSA support in everything? No problem. Want to disable KDE or Gnome for every package? No problem. Want to add IMAP and LDAP support to everything? No problem. All that is necessary is to set the USE flags.
Since Gentoo is more or less a bleeding-edge distribution, packages get updated frequently. Under these circumstances, compiler speed is far more important than every last bit of optimization, unless you are one of those power-user-masochists.:)
I've played around with an Alpha version of the SDK in October, and it was pretty nice. It is hard to get your head around some concepts, because the whole SDK is kind of baroque, just like OOo itself, but from my limited experience, it is very powerful.
I built a bridge for the Lua scripting language on top of the Java UNO bridge and used it to script 2D animations for a movie that I had to create for my research. I used OOo Draw to specify the animated elements, and traced out their paths via other elements and object prperties.
The scripts inspected the objects and their properties, animated them accordingly in an OOo Draw canvas, and saved the frames to the disk. All in all, it took me about a week to get this to work; time that I consider well-invested.
Where do you get the idea that xine is stagnant? >430 CVS commits in the past 4 weeks paint a different picture. Granted, the release cycle between 0.9.8 and 0.9.9 was pretty long, but that was because of a major reworking of the video engine.
Actually, critical sections are fast only if there is low contention for them. As soon as threads start contending for them, performance goes out the window. They also don't scale well with the number of threads, and they exhibit horrible performance degradations if the priority of the contending threads is not at a maximum.
There is a great summary of the issues at
http://world.std.com/~jmhart/csmutx.htm.
Just because the compiler is from Intel, it does not mean that it always generates better x86 code than gcc. Quite the contrary, there is a lot of real-world C++ code, for which g++ 2.95 and g++ 3.02 generate significantly better code on Pentium IIIs and Pentium IVs than the Intel compiler. I am talking about factors anywhere between 1.5 and 4 times slower.
Surprisingly that includes floating-point heavy applications, even with SSE2 instructions enabled. You'd expect that the Intel compiler should do particularly well at these, but this is not always the case.
We did some benchmarking and measuring as a consequence of these results. It turned out that Intel's compiler is rather bad at handling typical C++ data and procedural abstractions. g++ is much better at these, and it shows. I don't understand how people can keep harping on how lousy the code that gcc generates is supposed to be. In my experience, it has been quite respectable, especially with gcc 3.02.
The bottom line is, as so often: Measure the performance of your C++ programs before deciding whether to compile it with g++ or Intel's compiler.
It lets you specify accept/reject policies on a site-by-site basis. You can also configure it such that it will ask for a policy every time a cookie is being sent by a site that you have not covered yet.
As for learning and blacklists, wouldn't that make a great coding project?:-)
The J visa category is for exchange visitors and their families. More specifically, J-1 is for the participant in the exchange program, and J-2 is for his or her dependents. What does that have to do with a work permit?
If you enter an academic program, a J-1 visa has a great advantage over an F-1 visa: You are eligible for up to a total of 18 or 36 months of academic training, depending on your degree. You can take advantage of this, as long as the job you are doing is tied to your studies or your research in some way. This is much harder to do withan F-1 visa, and it is also limited to at most 12 months.
Aside from this, the home country residency requirement is only two years, and only if you got government (U.S. or foreign) funding for any part of the exchange program.
Overall I don't know what is better if your plan is permanent residency in the USA, but if you plan to return to your home country after you complete your academic program, consider choosing a J-1 visa instead of F-1.
I've found egcs to be unusable for some of the more advanced template stuff. In particular, implementations of the standard C++ library - as opposed to the stone-age libstdc++ that comes with g++ - simply crash the compiler. My team had to move to g++ 2.95.2 for this reason.
On the other hand, version 2.95.2 chokes on some perfectly legal constructs that egcs could compile just fine. The crucial difference is that we could work around the new bugs, whereas we could not work around the old ones in egcs. So, switching to 2.95.2 was a win overall.
The way kppp tested whether the kernel supports PPP, unwittingly took advantage of a security hole that was fixed in the kernel versions 2.2.13 and 2.3.x. See Bug 2164 on the KDE web site. Nothing serious. According to the bug report, you can simply ignore the error message or remove the test for the ppp0 device from the kppp source code.
I have a nice, medium-sized C++ project with around 15 KLOC. This project does not use any kind of GUI, but it does have to include all the windows.h bloat on NT. Using the WIN32_LEAN_AND_MEAN switch helps a little, but not much.
I don't know how representative this is, but egcs 1.1.2 on Linux compiles and links this project almost twice as fast as MSVC++ 5.0 on NT 4.0. In general, I was surprised how fast egcs can be, because I used to think of gcc as a nice compiler, but slow as molasses.
Also, precompiled headers and incremental linking don't always seem to buy a speedup. There's one particular project on Borland C++ Builder 3 where incremental linking slowed down build times by a factor of 2.
Slashdot Mirror
Every major Linux distribution now offering a 64-bit version does not count as mainstream? Besides, the x86_64 port can now safely be called stable. The remaining kinks, if you want to call that, concern mostly applications that do not work natively in 64-bit mode, but that is why distributions provide the 32-bit backward compatibility libraries.
Of course, using assertions heavily can incur a significant performance hit, which may or may not be acceptable in your particular application. [...]
Interestingly, the performance hit seems to be almost negiglible on an AMD Opteron in 64-bit mode with gcc 3.4, as long as the assertions themselves are trivial. AMD must have done some really nice things with the branch prediction unit. Way to go.
And yes, I do agree that assertions belong into production code. I cannot count the number of times when they have saved our butts and exposed design or coding flaws. The "impossible" can and does happen more quickly than people would make you believe in general.
If it is just you working on the project, you do not need to run a CVS server at all. Just having the cvs command available on your system is enough. Likewise, this means that you do not have to worry about patching your CVS installation to defend against attacks on the 'Net. Of course, it still makes sense to keep your software up to date against local exploits, but that is just plain common sense.
...
/path/to/repository init, cvs -d /path/to/repository import, followed by a fresh checkout.
To back up data, you just back up the directory that contains the CVS repository. There are no special files, databases, etc. Everything is a plain, simple, old text file. That also means that you will not encounter compatibility problems between clients on different platforms. The CVS file format has been stable for countless years.
The benefits are many:
- You keep a complete history of the changes you made to your software, along with a changelog.
- You can go back to any intermediate version, even between changes you made on a single day. You say that you do this very rarely, but it is still good to have it, just in case.
- You can fork the code if you want to do something experimental, and merge the changes back later.
- You keep a clean separation between your source code and th files that are generated during a build. For instance, if you want to compile with different compiler options, such as debug vs release, you can just check out the source into two different directories and build each to taste. Similarly, when you want to distribute or release the source code, just do a fresh checkout into a new directory, and tar that up - without any worries that there might be superfluous intermediate files in the tarball.
- and more
Why don't you just try it? Setting up cvs with your project is as simple as installing an rpm/deb/ebuild, cvs -d
No, the point of Gentoo is not optimization, although it is certainly possible to use the distribution in this fashion. The main point is that Gentoo is a meta-distribution that lets you customize the setup every which way. Other distributions make package configuration decisions for you, whereas Gentoo allows you to make them yourself.
:)
Want ALSA support in everything? No problem. Want to disable KDE or Gnome for every package? No problem. Want to add IMAP and LDAP support to everything? No problem. All that is necessary is to set the USE flags.
Since Gentoo is more or less a bleeding-edge distribution, packages get updated frequently. Under these circumstances, compiler speed is far more important than every last bit of optimization, unless you are one of those power-user-masochists.
I've played around with an Alpha version of the SDK in October, and it was pretty nice. It is hard to get your head around some concepts, because the whole SDK is kind of baroque, just like OOo itself, but from my limited experience, it is very powerful.
I built a bridge for the Lua scripting language on top of the Java UNO bridge and used it to script 2D animations for a movie that I had to create for my research. I used OOo Draw to specify the animated elements, and traced out their paths via other elements and object prperties.
The scripts inspected the objects and their properties, animated them accordingly in an OOo Draw canvas, and saved the frames to the disk. All in all, it took me about a week to get this to work; time that I consider well-invested.
Where do you get the idea that xine is stagnant? >430 CVS commits in the past 4 weeks paint a different picture. Granted, the release cycle between 0.9.8 and 0.9.9 was pretty long, but that was because of a major reworking of the video engine.
Actually, critical sections are fast only if there is low contention for them. As soon as threads start contending for them, performance goes out the window. They also don't scale well with the number of threads, and they exhibit horrible performance degradations if the priority of the contending threads is not at a maximum. There is a great summary of the issues at http://world.std.com/~jmhart/csmutx.htm.
Just because the compiler is from Intel, it does not mean that it always generates better x86 code than gcc. Quite the contrary, there is a lot of real-world C++ code, for which g++ 2.95 and g++ 3.02 generate significantly better code on Pentium IIIs and Pentium IVs than the Intel compiler. I am talking about factors anywhere between 1.5 and 4 times slower.
Surprisingly that includes floating-point heavy applications, even with SSE2 instructions enabled. You'd expect that the Intel compiler should do particularly well at these, but this is not always the case.
We did some benchmarking and measuring as a consequence of these results. It turned out that Intel's compiler is rather bad at handling typical C++ data and procedural abstractions. g++ is much better at these, and it shows. I don't understand how people can keep harping on how lousy the code that gcc generates is supposed to be. In my experience, it has been quite respectable, especially with gcc 3.02.
The bottom line is, as so often: Measure the performance of your C++ programs before deciding whether to compile it with g++ or Intel's compiler.
- Krischi
Install the Windows TTF fonts if you have them. With them Konqueror looks fine. Also, take a look at the Font Deuglification mini HOWTO at http://www.linuxdoc.org/HOWTO/mini/FDU/index.html.
If you configure Konqueror with OpenSSL support (happens automatically if you have it installed), it supports SSL just fine.
It lets you specify accept/reject policies on a site-by-site basis. You can also configure it such that it will ask for a policy every time a cookie is being sent by a site that you have not covered yet.
:-)
As for learning and blacklists, wouldn't that make a great coding project?
The J visa category is for exchange visitors and their families. More specifically, J-1 is for the participant in the exchange program, and J-2 is for his or her dependents. What does that have to do with a work permit?
If you enter an academic program, a J-1 visa has a great advantage over an F-1 visa: You are eligible for up to a total of 18 or 36 months of academic training, depending on your degree. You can take advantage of this, as long as the job you are doing is tied to your studies or your research in some way. This is much harder to do withan F-1 visa, and it is also limited to at most 12 months.
Aside from this, the home country residency requirement is only two years, and only if you got government (U.S. or foreign) funding for any part of the exchange program.
Overall I don't know what is better if your plan is permanent residency in the USA, but if you plan to return to your home country after you complete your academic program, consider choosing a J-1 visa instead of F-1.
I've found egcs to be unusable for some of the more advanced template stuff. In particular, implementations of the standard C++ library - as opposed to the stone-age libstdc++ that comes with g++ - simply crash the compiler. My team had to move to g++ 2.95.2 for this reason.
On the other hand, version 2.95.2 chokes on some perfectly legal constructs that egcs could compile just fine. The crucial difference is that we could work around the new bugs, whereas we could not work around the old ones in egcs. So, switching to 2.95.2 was a win overall.
$30.95 - Bookpool.com
See the FAQ.
The way kppp tested whether the kernel supports PPP, unwittingly took advantage of a security hole that was fixed in the kernel versions 2.2.13 and 2.3.x. See Bug 2164 on the KDE web site. Nothing serious.
According to the bug report, you can simply ignore the error message or remove the test for the ppp0 device from the kppp source code.
According to the change log, a question and another question on the egcs mailing list, exceptions are thread-safe.
Oh well, I'll soon find out for myself.
I have a nice, medium-sized C++ project with around 15 KLOC. This project does not use any kind of GUI, but it does have to include all the windows.h bloat on NT. Using the WIN32_LEAN_AND_MEAN switch helps a little, but not much.
I don't know how representative this is, but egcs 1.1.2 on Linux compiles and links this project almost twice as fast as MSVC++ 5.0 on NT 4.0. In general, I was surprised how fast egcs can be, because I used to think of gcc as a nice compiler, but slow as molasses.
Also, precompiled headers and incremental linking don't always seem to buy a speedup. There's one particular project on Borland C++ Builder 3 where incremental linking slowed down build times by a factor of 2.