We're kind of straying off topic here, but NANDs are often preferred because the p-channel transistors are in parallel. N-channel transistors switch faster than p-channel ones, and thus don't suffer as much from being placed in series.
There's no space or cost benefit of a NAND over a NOR - they're both 2N transistors for N inputs.
Backing up an licensed audio CD is legal in Canada, AFAIK.
Backing up? Hell, most noncommercial copying is legal. If I go to a friend's house, hear a new CD he just bought, borrow it, burn a copy on my PC and then return it to him, that's perfectly legal due to the levy on blank media.
Ack! Colour me a fool for not having read the article. I had naturally assumed that the CDs would still work in CD-ROM drives in audio mode, and all CDs that didn't work would be doomed to failure.
...unless they can somehow disable the CD Digital out on my DVD-ROM. It's a bit more cumbersome to have to manually record it as.WAV, but there'll be no quality loss. Right now I'm in the process of ripping all of my CDs to Ogg Vorbis format. This kind of bullshit would only prevent me from buying those CDs.
Theoretically, yes, but the path length for each mode doesn't vary much, only by roughly 0.01% - 0.2% between successive modes. On the other hand, a difference of 0.015 between the indices of refraction of the core and cladding creates speed differences of around 2000km/sec between the two materials, or about 1% for standard glass. Higher modes have a longer path difference, but they also penetrate further into the cladding and get sped up more. The effect of the speedup in the cladding is more pronounced than the effect of path length, so higher modes reach the end faster.
I mean in the theory you have unlimited frequencies to transmit data with
Theoretically, yes. Practically, you have things like Rayleigh scattering and lattice absorption that seriously limit efficiency at most wavelengths. Most fibers are made out of glass, which has two wavelengths that are optimal for communication: 1.31um and 1.55um. Outside of these wavelengths, one of the two effects causes serious attenuation over distance.
In an optical fiber, light rays traveling through the core can bounce off of the outer boundary between the cladding (lower index of refraction) and the core via total internal reflection. However, interference only allows rays at certain angles with respect to the fiber propagate. Each of these valid ray directions represents a mode.
Single mode operation means only the axial mode, where the ray travels straight down the core, is valid. The reason single mode operation is desired is because the higher modes do penetrate into the lower-index cladding where the speed of light is higher when they reflect off of it, which causes the higher-index modes to propagate faster than lower modes. Basically, if you fire a very sharp pulse of light of all modes into an optical fiber, the modes will all reach the other end of the fiber at different times. Since your sharp impulse has been spread over time, there is a limit to how many different pulses can be resolved over a certain period of time. Single mode operation means that there are no higher modes and hence less spread and higher bandwidth. (There are other causes of spread, but not much can be done about most of them).
Hence gtk embedded, which I predict will take off. Then all of a sudden, suspicious thing happens. QT-embedded becomes dual licensed GPL and qt-proprietary
The CBC has it archived in RealAudio form (sorry, I haven't tried it, I'm between classes) on this page. Just scroll down to the Feb 18th show. There's also a bunch of listener mail and an archived discussion board.
Double Data Rate SDRAM. Instead of transferring data on only the positive edge of the clock cycle, DDR transfers data on both edges, doubling the theoretical data transfer rate. There also isn't much extra that has to be done to make DDR; only a little extra support circuitry is required, and for that the bandwidth doubles. It's been used in nVidia's GeForce series since the GeForce1, and it helps a lot when high resolution and high colour depth are being used.
Mispredicted branches also cause a significant performance drop with pipelining. The CPU doesn't know for sure whether or not it's going to branch until the branch reaches the end of the pipeline. Until then it has to more or less guess based on previously results (or in the simpler case, just always predict "taken" or "not taken") and, if the prediction is determined to be wrong, it must clear out all the partially executed instructions.
It is my understanding that IA-64 deals with this by having multiple pipelines so that multiple possible branches can be evaluated simultaneously. That way all that has to be done is to flush the 'incorrect' pipes once the needed data arrives. (This was in an old boot magazine column by Tom Halfhill).
It most certainly does, but who knows what platforms New.net will release plugins for? Will they go all the way and produce plugins for Linux, Solaris, BSD, and so on? Or will they just do minimal effort and do Win32 and Mac?
*Yawn* Call me when it's usable. Both 0.8 and a build from current CVS show gross stability problems. The OK button in the preferences stops working, it segfaults when I try to delete a folder from my bookmarks or sometimes when I close a window with another one running, etc. Sure, it has its good points, but I'll wait until it's more reliable.
The bottom line is that there's a fast, stable and feature-filled browser for *nix platforms out there NOW, and its name isn't Mozilla.
then that proves that open source is capable of writing a browser in four years.
I dunno exactly how long it took to write Konqueror, but since KDE2 is a complete rewrite from KDE1, then Konqueror has been in development for a lot less time then Mozilla, and in my opinion is far more usable.
Konqueror has nice, fast rendering, support for Netscape plugins, https using OpenSSL, Javascript support with the ability to disable window.open, fine-grained cookie management, the ability to fake a User Agent header if necessary, and so on and so on. To each their own, but I personally can't see any reason to use Mozilla over Konqueror.
I used to have that problem when using Konqueror with Junkbuster, but in 2.1, Konq and Junk buster play nice just like they should.
Re:Only count programs that require the desktop li
on
KDE 2.1 Is Out
·
· Score: 2
I'm not trying to count anything against anything. I'm just pointing out the difference between a GNOME app and a GTK app. Grip compiled and ran without GNOME on my Linux From Scratch install just fine, so it really can't be called a GNOME app. On the other hand, I had to compile a statically linked Pan binary on my Mandrake install to use in LFS, since Pan uses some stuff in gnome-libs.
A really good application would have the UI separated from the functionality, and be buildable for Qt (with/without KDE), Gtk (w/w Gnome), Motif (w/w CDE), and perhaps Xaw and tty from the same source.
I don't see much wrong with requiring a certain toolkit, but yeah, it would be best if the UI was separate from the functionality - at least from my perspective (I'm not a programmer). A good example is the aforementioned LICQ - it defaults to a QT-based GUI, but you can ditch that in favor of a GTK or console-based UI because its UI is handled by plugins.
Re:Optimizing the source build
on
KDE 2.1 Is Out
·
· Score: 2
With the -march=pentiumpro option, it's generating instructions that only i686 CPUs will understand. With -mpentiumpro, it simply arranges the instructions for optimal execution on a Ppro. As far as I'm aware, Red Hat compiles with -march=i386 -mpentiumpro so that it's optimized for Ppro, but still runs on a 386. Mandrake does -march=i586, I believe.
Simple. The only way Microsoft can try to embrace and extend Vorbis is by creating the tainted version and offering support for it - and not "free" Vorbis - in Windows Media Player. That won't do anything, since hardly anyone uses Windows Media Player for listening to music. The most important bases, those being Winamp and Sonique, are already covered by plugins for untainted Vorbis.
Some of those projects you mentioned, notably Grip, XMMS and XChat do not require GNOME. They just require GTK. Heck, I don't have any trace of GNOME on my computer and yet XMMS and Grip run great. If a program (LICQ is an example) uses QT, I would not call it a KDE program unless KDE has to be there. Sure, some of them can integrate into GNOME, but the same thing can go for KDE. Anyone can get either KMMS or XMMS-KDE and get an integrated XMMS control in their KDE panel.
Slashdot Mirror
Or maybe he just can't spell.
If it were "Slashdot moving to Windows/IIS", it might've been funny.
We're kind of straying off topic here, but NANDs are often preferred because the p-channel transistors are in parallel. N-channel transistors switch faster than p-channel ones, and thus don't suffer as much from being placed in series.
There's no space or cost benefit of a NAND over a NOR - they're both 2N transistors for N inputs.
However, the record companies want it both ways.
Ack! Colour me a fool for not having read the article. I had naturally assumed that the CDs would still work in CD-ROM drives in audio mode, and all CDs that didn't work would be doomed to failure.
Man, they're shooting themselves in the foot.
...unless they can somehow disable the CD Digital out on my DVD-ROM. It's a bit more cumbersome to have to manually record it as .WAV, but there'll be no quality loss. Right now I'm in the process of ripping all of my CDs to Ogg Vorbis format. This kind of bullshit would only prevent me from buying those CDs.
Theoretically, yes, but the path length for each mode doesn't vary much, only by roughly 0.01% - 0.2% between successive modes. On the other hand, a difference of 0.015 between the indices of refraction of the core and cladding creates speed differences of around 2000km/sec between the two materials, or about 1% for standard glass. Higher modes have a longer path difference, but they also penetrate further into the cladding and get sped up more. The effect of the speedup in the cladding is more pronounced than the effect of path length, so higher modes reach the end faster.
In an optical fiber, light rays traveling through the core can bounce off of the outer boundary between the cladding (lower index of refraction) and the core via total internal reflection. However, interference only allows rays at certain angles with respect to the fiber propagate. Each of these valid ray directions represents a mode.
Single mode operation means only the axial mode, where the ray travels straight down the core, is valid. The reason single mode operation is desired is because the higher modes do penetrate into the lower-index cladding where the speed of light is higher when they reflect off of it, which causes the higher-index modes to propagate faster than lower modes. Basically, if you fire a very sharp pulse of light of all modes into an optical fiber, the modes will all reach the other end of the fiber at different times. Since your sharp impulse has been spread over time, there is a limit to how many different pulses can be resolved over a certain period of time. Single mode operation means that there are no higher modes and hence less spread and higher bandwidth. (There are other causes of spread, but not much can be done about most of them).
Either we have a non-causal system here, or you're an idiot. My guess is the latter.
The CBC has it archived in RealAudio form (sorry, I haven't tried it, I'm between classes) on this page. Just scroll down to the Feb 18th show. There's also a bunch of listener mail and an archived discussion board.
Double Data Rate SDRAM. Instead of transferring data on only the positive edge of the clock cycle, DDR transfers data on both edges, doubling the theoretical data transfer rate. There also isn't much extra that has to be done to make DDR; only a little extra support circuitry is required, and for that the bandwidth doubles. It's been used in nVidia's GeForce series since the GeForce1, and it helps a lot when high resolution and high colour depth are being used.
Considering Grip uses FreeDB by default, it shouldn't affect too many people.
Yeah - you'll get dragged into it just like Jon Johansen.
It most certainly does, but who knows what platforms New.net will release plugins for? Will they go all the way and produce plugins for Linux, Solaris, BSD, and so on? Or will they just do minimal effort and do Win32 and Mac?
*Yawn* Call me when it's usable. Both 0.8 and a build from current CVS show gross stability problems. The OK button in the preferences stops working, it segfaults when I try to delete a folder from my bookmarks or sometimes when I close a window with another one running, etc. Sure, it has its good points, but I'll wait until it's more reliable.
The bottom line is that there's a fast, stable and feature-filled browser for *nix platforms out there NOW, and its name isn't Mozilla.
Konqueror has nice, fast rendering, support for Netscape plugins, https using OpenSSL, Javascript support with the ability to disable window.open, fine-grained cookie management, the ability to fake a User Agent header if necessary, and so on and so on. To each their own, but I personally can't see any reason to use Mozilla over Konqueror.
I used to have that problem when using Konqueror with Junkbuster, but in 2.1, Konq and Junk buster play nice just like they should.
With the -march=pentiumpro option, it's generating instructions that only i686 CPUs will understand. With -mpentiumpro, it simply arranges the instructions for optimal execution on a Ppro. As far as I'm aware, Red Hat compiles with -march=i386 -mpentiumpro so that it's optimized for Ppro, but still runs on a 386. Mandrake does -march=i586, I believe.
Simple. The only way Microsoft can try to embrace and extend Vorbis is by creating the tainted version and offering support for it - and not "free" Vorbis - in Windows Media Player. That won't do anything, since hardly anyone uses Windows Media Player for listening to music. The most important bases, those being Winamp and Sonique, are already covered by plugins for untainted Vorbis.
Some of those projects you mentioned, notably Grip, XMMS and XChat do not require GNOME. They just require GTK. Heck, I don't have any trace of GNOME on my computer and yet XMMS and Grip run great. If a program (LICQ is an example) uses QT, I would not call it a KDE program unless KDE has to be there. Sure, some of them can integrate into GNOME, but the same thing can go for KDE. Anyone can get either KMMS or XMMS-KDE and get an integrated XMMS control in their KDE panel.