The website owner can concatenate all static files into a (maybe virtual) file that gets served by BT. Then clients can just download the parts they need, and don't waste bandwidth on other parts. Popular parts like the front page will get cached well.
I don't know much about the protocol beyond what the FAQ says, so I'm not sure it is possible. Anyway, even now you download different parts of a file simultaneously, so "seeking" doesn't seems to be that difficult.
However, overheads may become significant if the ratio between the average amount downloaded and the total size becomes too low.
Take PDF as an example. As we all know PDF does support some DRM-like features, but they aren't used much by documents intended for the general public --- at least for free-as-in-beer documents.
Just as most PDFs can be used freely, most webpages will, even if DRM is used.
On a linux system, if you want high performance, use getc_unlocked() instead of getc() (which does implicit locking on the stream), and do the locking explicitly if your program is multi-threaded. This is a glibc extension, so you must check its availablity before using it.
As for the mmap option... IMHO it is a little bit complicated, and glibc seems to use mmap on read-only streams anyway.
Mostly compatible, but...
on
GCC 3.3 Released
·
· Score: 4, Informative
According to this,
if your program is multi-threaded, uses spinlocks in libstdc++, and runs on x86, then you'll have to configure gcc-3.3 for a i486+ target (instead of i386) in order to make it binary compatible with gcc-3.2.x configured for a i386 target. Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)
I have lost data on ReiserFS partitions during power failures, too. As far as I know, since ReiserFS does metadata journaling only, it may update the metadata (such as block pointers) before updating the actual data blocks. If the power failure happens after writing the metadata changes to the journal (whether they are committed to the actual location of the metadata before the power failure, or during the journal recovery after that), but before writing the data blocks to disk, then after system restart and journal recovery, the filesystem will still be intact, but the updated data block pointers will point to stale data, so that's what you will see in your (probably newly-overwritten) file.
In contrast, for ext3 in "ordered" mode, although we also do metadata-only journaling, it is made sure that data blocks gets written before metadata pointing to them, so if a power failure happens when overwriting a file, you either see the new contents (if the metadata got updated) or the old contents (if not), no data will be lost.
So this does not seem to be a bug in reiserfs, but it does mean that you have lower data integrity gurantees than in ext3 ordered mode (actually it seems to be worse than ext2 --- maybe something needs tweaking). Alas, few users are aware of this before they got bitten.
Anyway, if you have some frequently overwritten and very important data (like your term paper), I think it is better to store them on ext3 (data=ordered/journal) partitions than reiserfs partitions, if you want to protect them from power failures. Also, it would be great if ReiserFS gets similar features as "data=ordered" in ext3.
(I'm not an expert on this subject. Please correct any errors I made.)
It just seems that the 64-bit ABI and the 32-bit one are incompatible (really not surprising... even pointer sizes are different).
Anyway, we already have C++ ABI problem, so this one isn't much worse. What's more, hopefully every 64-bit compiled C++ application will have the gcc-3.2 ABI (old gccs don't even support x86-64), so no more C++ problems in the 64-bit world, and as a bonus, companies have finally found some incentive to make the not-very-standards-compliant code compile with newer gcc, so 32-bit versions compiled with gcc-3.2 will hopefully be available sooner.
I remember that both Tom's and Ace's reviews of the Opteron used SuSE's distribution, which seems to be released earlier and (if I remember correctly) more near-production-ready.
The increased performance and removal of the 8192-threads limit have significant effects only for large machines. It is better POSIX conformance that really make developers of threaded programs using signals/fork/exec/wait/complex-IO more comfortable (at least when LinuxThreads becomes deprecated).
By the way, Sun Java 1.4.1_02 works with NPTL, but older versions may not.
X is like GDI in Windows and toolkits are like USER. X is all right (network transparency isn't that costly). The problem is just that there are many different USER libraries and APIs, and some people don't like that.
I hope toolkit developers can get together to use a common config file format for look-and-feel stuff, and provide sensible defaults (Windows-like, Vi-like, Emacs-like, Motif-like, etc.). This way, programmers can just choose the toolkit they like best, be it GTK, Qt, Motif or Swing (it is hard to bring together the latter two, though), and users will not mind which one is actually used.
And I really liked the LANGUAGE because of the simplicity. Yet the implementations are so diverse and incompatible, and it cannot do native things as well as Java (which I like almost as much). What's more, it is also slower.
I have a Pentium 166 that had been assembled from garbage parts. Linux 2.2 as in RH7.0 works, but Linux 2.4 as in RH7.3 doesn't find the D-Link ethernet card reliably, although exactly the same parameters for ne.o have been used and extensive isapnp tweaking had been done. So I just reverted to RH7.0's kernel.
I'm going to submit a bug report when I have time, but it is probably going to be difficult to write a helpful one.
My monitor (Samsung SyncMaster 500b) takes a whole second to switch modes, and most of it is spent by the hardware (some switch or relay, I guess), yet I don't feel too uncomfortable. So, if you switch VT's under X so often, what are you doing?
Sounds trollish
on
The Faded Sun
·
· Score: 5, Interesting
I know Sun is losing money, but this article sounds subjective and trollish all the same. Anyone care to confirm the facts mentioned?
Because no sensible programmer will write pow(-1.0,n) instead of (n&&1==0)?1:-1, especially if the code is time-critical. Programmers should never assume that the compiler can do some very specific types of optimizations, such as C tail-recursion removal, or (-1)^n stuff like this. These things can be optimized explicitly in the code, and by adding a comment describing the purpose of the code, clarity will not suffer.
Yet certain redundent things in compiled C code are simply (nearly) impossible to optimize away. One problem is aliasing, another is the need to reload global variables after calling a function (YOU know the puts(...) doesn't change img_width, but how can the compiler know? Unless you compile the source code for puts() together with your code, and turn on inter-file optimization, a tiring thing to do). Even if an extra load cost next to nothing, and the code isn't even time critical, code size has increased considerably with no return in speed.
So arch-independent optimizations can only do so much, and most modern compilers do this well enough, although some Intel CC features like IPO are also desirable. Arch-dependent things seem to be more important currently, and they are also the things that need constant development now, to keep pace with the introduction of new CPU generations.
Using the same configuration as yours (Redhat 8, postgresql 7.2.x/7.3,x, Oo 1.0/643c), I can connect to postgresql databases using either ODBC or JDBC and do some simple things, but random crashes are so frequent it is not really very usable.
Which ODBC driver are you using? The one from unixODBC or the one from PostgreSQL?
In China copyright of corporate works last for 50 years, so many classic movies like Casablanca are mostly in the public domain (except maybe for the Chinese translation, etc.), therefore they are cheaper (15 - 20 yuan, or $2 - $3).
Newer movies usually cost 30+yuan ($4), or even over 60 ($8).
Now loading 128MB of DLL's you probably will only need 2% of.
In fact, it should be "Now loading 11MB of DLL's, in which 5MB will be constantly used; however, it will take 10 seconds for your UDMA66 hard disk to load these things, because although unused parts of the DLLs aren't loaded into memory, they have to be seeked over anyway."
Although MPlayer is a great product and I like it much, I have to say that many parts of it are not well documented, and often it IS necessary to play with a lot of command-line switches to get things right. I find myself quite accustomed to command-line switches, but a few things are still troublesome to do in mplayer.
One thing is scaling. I have a old video card, so I have to do soft scaling. I resized the window --- no luck. Used -xy (or -x plus -y), the image size still doesn't change. Finally I found that -vop scale is needed to activate software scaling. Why don't they add a note about -vop scale in -x, -y?
Another is gamma correction. It turned out that mplayer CAN do software gamma correction, but the option "-vop eq2=2" is totally undocumented. (I dug that out by googling the mailing list)
Mplayer is hard enough, and Mencoder... When will it be as easy-to-use as oggenc or lame?
For now, if anyone wants to play video on linux, I recommend mplayer, but be sure to spend an hour to read the manual first.
As slow and bloated as mozilla? Probably not. Although the code does look a bit messy and bloated in some places, a bit like sendmail or gcc (i.e., code size and speed may be good, but there is still a lot of code that is not easy to maintain).
Mozilla uses C++ (and most methods are virtual) and component interfaces like XPCOM. Such things probably enhance developer's productivity, but they incur quite a bit of overhead in code size and (less so) in speed.
It is great that core developers actually care about code size and instruction-level speed (such as the recent syscall patch, or those highly optimized inline functions in headers), and there are many people sending patches to clean up code. Maybe linux won't get as bloated as mozilla after all...
Slashdot Mirror
I don't know much about the protocol beyond what the FAQ says, so I'm not sure it is possible. Anyway, even now you download different parts of a file simultaneously, so "seeking" doesn't seems to be that difficult.
However, overheads may become significant if the ratio between the average amount downloaded and the total size becomes too low.
Just as most PDFs can be used freely, most webpages will, even if DRM is used.
As for the mmap option... IMHO it is a little bit complicated, and glibc seems to use mmap on read-only streams anyway.
According to this, if your program is multi-threaded, uses spinlocks in libstdc++, and runs on x86, then you'll have to configure gcc-3.3 for a i486+ target (instead of i386) in order to make it binary compatible with gcc-3.2.x configured for a i386 target. Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)
I haven't read the standard. Is this really so?
In contrast, for ext3 in "ordered" mode, although we also do metadata-only journaling, it is made sure that data blocks gets written before metadata pointing to them, so if a power failure happens when overwriting a file, you either see the new contents (if the metadata got updated) or the old contents (if not), no data will be lost.
So this does not seem to be a bug in reiserfs, but it does mean that you have lower data integrity gurantees than in ext3 ordered mode (actually it seems to be worse than ext2 --- maybe something needs tweaking). Alas, few users are aware of this before they got bitten.
Anyway, if you have some frequently overwritten and very important data (like your term paper), I think it is better to store them on ext3 (data=ordered/journal) partitions than reiserfs partitions, if you want to protect them from power failures. Also, it would be great if ReiserFS gets similar features as "data=ordered" in ext3.
(I'm not an expert on this subject. Please correct any errors I made.)
Anyway, we already have C++ ABI problem, so this one isn't much worse. What's more, hopefully every 64-bit compiled C++ application will have the gcc-3.2 ABI (old gccs don't even support x86-64), so no more C++ problems in the 64-bit world, and as a bonus, companies have finally found some incentive to make the not-very-standards-compliant code compile with newer gcc, so 32-bit versions compiled with gcc-3.2 will hopefully be available sooner.
I remember that both Tom's and Ace's reviews of the Opteron used SuSE's distribution, which seems to be released earlier and (if I remember correctly) more near-production-ready.
IDE will probably not be THAT fast, maybe you need a expensive SCSI card.
By the way, Sun Java 1.4.1_02 works with NPTL, but older versions may not.
One more silly idea patented.
Anyway, I find this bad taste.
I hope toolkit developers can get together to use a common config file format for look-and-feel stuff, and provide sensible defaults (Windows-like, Vi-like, Emacs-like, Motif-like, etc.). This way, programmers can just choose the toolkit they like best, be it GTK, Qt, Motif or Swing (it is hard to bring together the latter two, though), and users will not mind which one is actually used.
And I really liked the LANGUAGE because of the simplicity. Yet the implementations are so diverse and incompatible, and it cannot do native things as well as Java (which I like almost as much). What's more, it is also slower.
I'm going to submit a bug report when I have time, but it is probably going to be difficult to write a helpful one.
My monitor (Samsung SyncMaster 500b) takes a whole second to switch modes, and most of it is spent by the hardware (some switch or relay, I guess), yet I don't feel too uncomfortable. So, if you switch VT's under X so often, what are you doing?
I know Sun is losing money, but this article sounds subjective and trollish all the same. Anyone care to confirm the facts mentioned?
Yet certain redundent things in compiled C code are simply (nearly) impossible to optimize away. One problem is aliasing, another is the need to reload global variables after calling a function (YOU know the puts(...) doesn't change img_width, but how can the compiler know? Unless you compile the source code for puts() together with your code, and turn on inter-file optimization, a tiring thing to do). Even if an extra load cost next to nothing, and the code isn't even time critical, code size has increased considerably with no return in speed.
So arch-independent optimizations can only do so much, and most modern compilers do this well enough, although some Intel CC features like IPO are also desirable. Arch-dependent things seem to be more important currently, and they are also the things that need constant development now, to keep pace with the introduction of new CPU generations.
Which ODBC driver are you using? The one from unixODBC or the one from PostgreSQL?
IANAL, so correct me for any errors.
In China copyright of corporate works last for 50 years, so many classic movies like Casablanca are mostly in the public domain (except maybe for the Chinese translation, etc.), therefore they are cheaper (15 - 20 yuan, or $2 - $3).
Newer movies usually cost 30+yuan ($4), or even over 60 ($8).
Now loading 128MB of DLL's you probably will only need 2% of.
In fact, it should be "Now loading 11MB of DLL's, in which 5MB will be constantly used; however, it will take 10 seconds for your UDMA66 hard disk to load these things, because although unused parts of the DLLs aren't loaded into memory, they have to be seeked over anyway."
300 decibels is 10^18 watts/m^2. Should be enough to frag everyone nearby, provided that his cellphone has a decent power supply.
I'm using them quite happily. Except that it doesn't support aalib or other toyish things, the rpm version works well and doesn't feel slow.
One thing is scaling. I have a old video card, so I have to do soft scaling. I resized the window --- no luck. Used -xy (or -x plus -y), the image size still doesn't change. Finally I found that -vop scale is needed to activate software scaling. Why don't they add a note about -vop scale in -x, -y?
Another is gamma correction. It turned out that mplayer CAN do software gamma correction, but the option "-vop eq2=2" is totally undocumented. (I dug that out by googling the mailing list)
Mplayer is hard enough, and Mencoder... When will it be as easy-to-use as oggenc or lame?
For now, if anyone wants to play video on linux, I recommend mplayer, but be sure to spend an hour to read the manual first.
Mozilla uses C++ (and most methods are virtual) and component interfaces like XPCOM. Such things probably enhance developer's productivity, but they incur quite a bit of overhead in code size and (less so) in speed.
It is great that core developers actually care about code size and instruction-level speed (such as the recent syscall patch, or those highly optimized inline functions in headers), and there are many people sending patches to clean up code. Maybe linux won't get as bloated as mozilla after all...