Thank you for making a complete fool of yourself. Real blue notes fall in between the major and minor thirds and sevenths, and are not anywhere near approximated by the 12-tone equal tempered scale.
While I am relieved to hear Transmeta is still kicking despite the relative failure of their Crusoe line of products, I am saddened to see them abandon the very technology that made them famous. The Astro chips abandon the software "Code Morphing" strategy of the Crusoe chips and instead interpret x86 bytecode in hardware, like traditional microprocessors. While this apparently has great performance benefits for their chips, it essentially makes them little more than second-rate Athlon imitators which incidentally happen to consume a little less power.
Of course, I realise this is due to market pressures and that Transmeta just like AMD and Intel has to keep pushing their chips faster and faster to keep up with Moore's law, but nonetheless I lament that Code Morphing's full potential was never realised. Performance considerations aside, a processor that performed instruction decoding in software would have many more benefits. Support for new instruction set extensions like SSE or MMX could be added with a simple firmware upgrade. A new code-morphing frontend could turn the Crusoe from an x86-compatible chip to a PowerPC, MIPS, or SPARC-compatible chip in seconds (which would be a huge boon to embedded developers). A Code-Morphing core could be used as a testbed for new ideas in CPU and instruction set designs. The populations could have been endless. But alas, with Transmeta abandoning the technology, it's doomed to become "just another neat idea", like LISP machines and the Amiga before it.
Don't use old tools
on
Antique Distros?
·
· Score: 5, Informative
By forcing yourself to downgrade to older system software, you are foolishly limiting yourself from running the hundreds of new and useful apps that have been released for Linux lately, most of which depend on the latest versions of the kernel and libc (or binary-compatible substitutes). Not to mention there are hundreds of security holes in old Linux distros that have only been patched in the latest versions of the included software.
I too faced this dilemma when trying to make use of a batch of 486 machines donated to our computer lab. My solution required a bit of elbow grease, but ensured that my machines both ran acceptably and had the latest and most secure versions of software available to them:
I built a Gentoo Linux system on the Athlon XP 2000+ machine in the lab, targetting all the software for 486 (gcc -O3 -m486 -march=486 -fomit-frame-pointer -s) and building a very stripped-down 2.4 kernel with only the bare necessities. I also replaced the standard GNU shell tools with BusyBox and GNU libc with uC-libc. On this fast machine, the compilation cycle didn't take long, and I was able to build and install everything into a temporary/install directory in less than four hours.
Once that was done, i tarred up the/install directory I had built and burned it onto an ISO along with a bootimage from tomsrtbt mini-Linux distro.
I then booted each 486 machine in turn from the CD, and used a shellscript I had written which created an ext2 partition, formatted it, and untarred the contents of my custom gentoo setup onto the disk, and set up grub to boot into it.
With all this done, I was able to quickly and easily convert these seemingly worthless 486 machines into reasonable X terminals. Gentoo's e-merge infrastructure ensures that maintenance is easy, and that I have full control over the compilation process. This way, I can tailor every app to get maximum performance out of the limited but still substantial power of the 486 chip.
This is This is the exact opposite of my findings.
on
New Linux 2.5 Benchmarks
·
· Score: 1, Troll
When I first heard about some of the things going on in the 2.5 branch,
such as the newly tuned VM system, improved filesystem code, and especially
Ingo Moyar's O(1) scheduler project, I was ecstatic. The
promise of an average workstation computer handling 100,000 threads with as
much grace as it handles 100 sounded too good to be true. And alas, it was.
There are a number of serious problems with Linux 2.5's scalability pushes,
trading performance for normal tasks in order to run better at more esoteric
tasks, and many of these can be traced back to the new O(1) scheduler.
A month ago, I downloaded the 2.5.44 kernel, and have been benchmarking it
extensively on one of the Pentium 4 2GHz workstations in the computer lab. For
a control, I ran a stock 2.4.19 kernel on the Athlon XP 2000+ machine next to
it. My test consisted of running an increasing number of parallel processes
each executing a for(;;) loop repeatedly nanosleep(2)ing for 10ms, thus
yielding the scheduler every time they awake. This made sure that the scheduler
was more or less the only thing running on the system, and that I could get an
accurate count of the average task-switching time.
By gradually increasing the number of threads on each machine in parallel, I
was able to graph the comparative performance of the two schedulers. The results
do not bode well for the new scheduler: (forgive my somewhat clumsy approximation, text is not the best medium for graphic content)
S |
c | . O(n) scheduler (2.4.19)
h |.
e |.
d |-----.------- O(1) scheduler (2.5.44)
T | . |
i | |
m | |p
e |_______|_______
No. of Threads
As you can see, the new scheduler is in fact O(1), but it adds so much initial
overhead that task switching is slower than under the old scheduler until you
have a certain number of threads, labeled p above. My benchmarking
experiments put p at around 740 threads.
Now, this is obviously good
for high-end applications that run thousands of processes concurrently, but
the average Linux user rarely has more than 100 processes on his machine at a
time. The vast majority of servers rarely exceed more than 250 concurrent
processes. In these cases, the O(1) scheduler is cutting their computer's
performance almost in half.
What we're seeing here is the likes of IBM and Sun
putting their needs before those of the hobbyist hackers and users who make
up the majority of the Linux user base. While the O(1) scheduler project is
a noble cause and should certainly be made available as an option for
those few applications that benefit from it, outright replacing the old
scheduler at this point is a folly.
While it may be more secure in the sense that infrared rays are much easier to absorb and block out than 2.xGHz radiation, this comes at a cost. The high amount of background noise in the infrared spectrum (both man-made from TV remotes, wireless keyboard and the like, and natural, since just about everything emits some level of infrared energy as heat), in addition to the same easy absorption of infrared particles which this article touts as a feature, ensures that you'll never get anywhere near the quality signal you get with traditional 802.11 wireless signals. Early "wireless" attempts struggled to get more than 9600bps out of the infrared spectrum, and while technology has no doubt improved since the mid-90s, I still can't fathom anyone getting more than an ISDN line's worth of bandwidth out of ISDN.
So, yes, it may indeed be more secure, but is the enormous leap backward in available bandwidth really worth it? I for one would much rather use stronger encryption than weaker signals.
The Big Bang is still very much theoretical; after all, nobody was around at the beginning of the Universe, and we can only speculate from our current state what may have happened then. The Big Bang story just happens to be more accepted at the current time, but nonetheless there is nothing to say it is anything more than just that.
Likewise, black holes are just an educated guess at what might be at the centre of galaxies or left behind in the wake of supernovae. For all we know, the absence of light in these areas may well be merely extremely dense clouds of cosmic dust rather than pinpoints of near-infinite gravitational power.
In this light, it's preposterous to say Poe or anyone else has "discovered" these constructs, though it's not all that surprising an imaginative artist such as Poe may have dreamt them up. After all, pretty much all cosmology and astronomy at this point has no more substance to back it up than The Cask of Amontillado.
One of the great paradoxes of computer science is that perceived performance and actual performance almost always come at a tradeoff. By raising the frequency of the timer interrupt, individual timeslices are shorter and the processor needs to make more context switches, resulting in less overall processing being performed. However, because these context switches occur more frequently, it appears to the user that apps are more responsive and fluid.
To make a long story short, for number crunching machines, servers, and other applications which don't need much user interaction, larger timeslices are preferable because it doesn't matter how responsive the user interface is. For desktop systems, the timeslice can be decreased to improve the responsiveness of the user interface and give a better "feel" to the system at the expense of a minor performance loss. Being able to tune these parameters to meet your needs is one of Linux's great strengths.
I cannot imagine anyone using a Windows machine without the magnificent PuTTY ssh, telnet, and rlogin client. It is probably the best ssh programme I have ever had the pleasure of using, and its terminal emulator is superior to most xterms in many ways. Your CD collection would be incomplete without it.
I've been studying psychoacoustics in my spare time, and have discovered some rather nasty limitations of the Vorbis format in my experimentations. It sacrifices a lot to "sound better" than MP3, and while some of their tradeoffs do manage to improve sound quality, some of Xiph's decisions are questionable:
First off, Vorbis concentrates its encoding in the more audible midrange, completely cutting out higher overtones. While MP3 works similarly, it manages to keep enough of the high range to maintain the "feel" of the original music. While you may not consciously notice this lack, there is an easy way to demonstrate it. Try singing along with a Vorbis track. You'll find that it's much more difficult to keep in tune, because the brain unconsciously uses inaudible overtones as a guide to determine the tone of the music when singing along. To put it bluntly, don't encode your karaoke tracks in Vorbis.
Vorbis claims to support more than two channel audio, but this is misleading. MP3 encodes stereo using a "joint-stereo" method, which couples both tracks together into a mono track, giving each frame a different balance to simulate stereo on a mono track. This is equivalent to playing a mono tape and turning the balance knob! Obviously, this is less than optimal. While Vorbis supports true stereo encoding, it fakes 5.1-channel audio using a "joint-joint-stereo" method, where the left-back/left-front and right-back/right-front channels and joined together into the two stereo tracks in a similar fashion. Not very good at all.
The way that Vorbis compresses its audio accelerates speaker degradation. It breaks sound up into an evenly-spaced array of harmonics which approximate the original waveform. "Big deal", you say, "that's how all lossy encoding schemes work!" But the way that Vorbis does it causes a noticeable amount of harmonic resonance in speaker systems, stressing their driver system and accelerating the rate at which they decay. If you know the story of the first Tacoma Narrows bridge, this is the same principle, working at a smaller and more gradual pace.
Given Xiph's poor track record with Vorbis, I'm not so sure their video encoding technology will make any serious inroads. It's not even really necessary; high-quality, open video standards such as MPEG-4 are already available and being adopted by all major players. If I were on Xiph's board of directors, I would suggest they spend more time improving Vorbis then creating yet another unnecessary standard.
There's still a lot to hate about MySQL.
on
IBM, MS Critique MySQL
·
· Score: 5, Insightful
It's been two years since it was written, but this document still does a good job of running down a lot of things that make MySQL fall short of other DBMSes. Even with InnoDB, it still has no provisions for stored procedures, sub-selects or even foreign key constraints.
I would not fault MySQL for this, though, since after all it was designed and still mainly used as an SQL wrapper for flat file data, and this is why it's usually much faster than full-featured RDBMSes. The problem is with mindless open-source advocates who try to pump up MySQL as the be-all, end-all database solution. For a personal website or small business, MySQL is more than adequate, but its lack of higher-end SQL features make it a poor fit for large, distributed, mission-critical corporate or university data storage.
IBM and Microsoft's customers are generally in this higher end of the database spectrum, where Oracle or DB2 makes much more sense. It's no surprise that they would want to put MySQL in its place as an entry-level database system, where it belongs, and I fail to see how this story qualifies as news.
It baffles me why Slashdot continues to post links to the NY Times with nary a mention of the NY Times random login generator. It makes my perusal of the news so much nicer.
Embedded languages - pah
on
Get Your Moto On
·
· Score: 5, Insightful
I'm sad to see the curse of ASP and its copycats continue on like this. Embedding script inside a document file makes it quick and easy for non-programmers to write messy, unmaintainable code:
They violate Model-View-Controller (MVC) separation. While it is possible to write your controller code as one long block of PHP and call its functions from your view scripts, that totally obviates the purported advantages of an embedded language.
The embedded languages themselves are generally horrible. Visual Basic needs no run-down of its deficiencies. PHP is an overgrown SSI replacement which has ended up looking like a bad parody of Perl. Moto looks to be little more than a light wrapper around C. None of these languages have a proper object model, consistent database integration, or a good extension mechanism.
They slow down maintenance of code. While the initial development phase may be expediated by the ability to embed code inside HTML, the web of markup and programme logic quickly becomes entangled in itself, and only gets worse over time. Starting with a proper top-down design phase may slow down development at first, but will be greatly rewarding in the long run.
The idea of Moto as both a compiled and interpreted language is noble (although not original; most Common LISP and Smalltalk implementations have both interpreted and compiled environments), but I urge them to reconsider their misguided language design strategy. They don't even need to come up with their own language; building a native code compiler for an established language like Python or Ruby would be a much greater boon to the open-source community at large.
With the recent news of the Antarctic melting at an extreme rate, I must agree with my esteemed colleagues in the fields of meteorology and ecological sciences that something must be done to prevent the nation of Tuvalu from being completely submerged by melted polar ice cap. My ecological chemist counterparts have been predicting these events with exact science for close to a decade. From the looks of this article, it would appear that they've been taken seriously. Look at the facts: CFC concentration is down. With the lack of CFC molecules present to bond with errant ozone molecules, the hole will have to repair itself with said ozone. We're entering a new era of global intellectual foresight with the assistance of my fellow academics.
And having a population of approximately 5.3 million persons, this goal should not be a difficult one to achieve in coming years. The energy demands of such a tiny nation are not large, aside from their few major learning institutions.
While residential fuel cell power plants and the benefits of grid-feeding are only in their fledgeling years, it surprises me that you're all THIS imatient about laptop computer battery fuel cells. When did we first hear about these notebook fuel-cells? A year ago? Two tops? I hope you're all a bit more patient with small children, jeeezus!
Any plain-Jane kit you can buy at your local Radio Shack or Fry's. There's really no need for an extravagant repair kit. You just need: various screwdrivers, a grapler to get out-of-reach screws, and possibly an IC remover. Not much else to say about repair 'kits.'
I have many collegues overseas. For starters, the [overwhelming] percentage of Japanese and Korean weathy enough to acquire broadband is highly suspect and inflated. Secondly, the degree of this "saturation" you speak of is much easier to attain in a relatively small country such as Japan or South Korea, south Korea being about the same size as Indiana and the total sum of Japanese islands being comperable in area to California. Got the smaller land mass? Build the infrastructure quicker and "saturate" it. If this is how "advanced" a country's 'broadband' (ugh) situation is, then Liechtenstein or Luxembourg might as well be the technological capital of the world.
Slashdot Mirror
Thank you for making a complete fool of yourself. Real blue notes fall in between the major and minor thirds and sevenths, and are not anywhere near approximated by the 12-tone equal tempered scale.
Of course, I realise this is due to market pressures and that Transmeta just like AMD and Intel has to keep pushing their chips faster and faster to keep up with Moore's law, but nonetheless I lament that Code Morphing's full potential was never realised. Performance considerations aside, a processor that performed instruction decoding in software would have many more benefits. Support for new instruction set extensions like SSE or MMX could be added with a simple firmware upgrade. A new code-morphing frontend could turn the Crusoe from an x86-compatible chip to a PowerPC, MIPS, or SPARC-compatible chip in seconds (which would be a huge boon to embedded developers). A Code-Morphing core could be used as a testbed for new ideas in CPU and instruction set designs. The populations could have been endless. But alas, with Transmeta abandoning the technology, it's doomed to become "just another neat idea", like LISP machines and the Amiga before it.
I too faced this dilemma when trying to make use of a batch of 486 machines donated to our computer lab. My solution required a bit of elbow grease, but ensured that my machines both ran acceptably and had the latest and most secure versions of software available to them:
- I built a Gentoo Linux system on the Athlon XP 2000+ machine in the lab, targetting all the software for 486 (gcc -O3 -m486 -march=486 -fomit-frame-pointer -s) and building a very stripped-down 2.4 kernel with only the bare necessities. I also replaced the standard GNU shell tools with BusyBox and GNU libc with uC-libc. On this fast machine, the compilation cycle didn't take long, and I was able to build and install everything into a temporary
/install directory in less than four hours.
- Once that was done, i tarred up the
/install directory I had built and burned it onto an ISO along with a bootimage from tomsrtbt mini-Linux distro.
- I then booted each 486 machine in turn from the CD, and used a shellscript I had written which created an ext2 partition, formatted it, and untarred the contents of my custom gentoo setup onto the disk, and set up grub to boot into it.
With all this done, I was able to quickly and easily convert these seemingly worthless 486 machines into reasonable X terminals. Gentoo's e-merge infrastructure ensures that maintenance is easy, and that I have full control over the compilation process. This way, I can tailor every app to get maximum performance out of the limited but still substantial power of the 486 chip.A month ago, I downloaded the 2.5.44 kernel, and have been benchmarking it extensively on one of the Pentium 4 2GHz workstations in the computer lab. For a control, I ran a stock 2.4.19 kernel on the Athlon XP 2000+ machine next to it. My test consisted of running an increasing number of parallel processes each executing a for(;;) loop repeatedly nanosleep(2)ing for 10ms, thus yielding the scheduler every time they awake. This made sure that the scheduler was more or less the only thing running on the system, and that I could get an accurate count of the average task-switching time.
By gradually increasing the number of threads on each machine in parallel, I was able to graph the comparative performance of the two schedulers. The results do not bode well for the new scheduler: (forgive my somewhat clumsy approximation, text is not the best medium for graphic content)
As you can see, the new scheduler is in fact O(1), but it adds so much initial overhead that task switching is slower than under the old scheduler until you have a certain number of threads, labeled p above. My benchmarking experiments put p at around 740 threads.Now, this is obviously good for high-end applications that run thousands of processes concurrently, but the average Linux user rarely has more than 100 processes on his machine at a time. The vast majority of servers rarely exceed more than 250 concurrent processes. In these cases, the O(1) scheduler is cutting their computer's performance almost in half.
What we're seeing here is the likes of IBM and Sun putting their needs before those of the hobbyist hackers and users who make up the majority of the Linux user base. While the O(1) scheduler project is a noble cause and should certainly be made available as an option for those few applications that benefit from it, outright replacing the old scheduler at this point is a folly.
So, yes, it may indeed be more secure, but is the enormous leap backward in available bandwidth really worth it? I for one would much rather use stronger encryption than weaker signals.
Likewise, black holes are just an educated guess at what might be at the centre of galaxies or left behind in the wake of supernovae. For all we know, the absence of light in these areas may well be merely extremely dense clouds of cosmic dust rather than pinpoints of near-infinite gravitational power.
In this light, it's preposterous to say Poe or anyone else has "discovered" these constructs, though it's not all that surprising an imaginative artist such as Poe may have dreamt them up. After all, pretty much all cosmology and astronomy at this point has no more substance to back it up than The Cask of Amontillado.
To make a long story short, for number crunching machines, servers, and other applications which don't need much user interaction, larger timeslices are preferable because it doesn't matter how responsive the user interface is. For desktop systems, the timeslice can be decreased to improve the responsiveness of the user interface and give a better "feel" to the system at the expense of a minor performance loss. Being able to tune these parameters to meet your needs is one of Linux's great strengths.
I cannot imagine anyone using a Windows machine without the magnificent PuTTY ssh, telnet, and rlogin client. It is probably the best ssh programme I have ever had the pleasure of using, and its terminal emulator is superior to most xterms in many ways. Your CD collection would be incomplete without it.
- First off, Vorbis concentrates its encoding in the more audible midrange, completely cutting out higher overtones. While MP3 works similarly, it manages to keep enough of the high range to maintain the "feel" of the original music. While you may not consciously notice this lack, there is an easy way to demonstrate it. Try singing along with a Vorbis track. You'll find that it's much more difficult to keep in tune, because the brain unconsciously uses inaudible overtones as a guide to determine the tone of the music when singing along. To put it bluntly, don't encode your karaoke tracks in Vorbis.
- Vorbis claims to support more than two channel audio, but this is misleading. MP3 encodes stereo using a "joint-stereo" method, which couples both tracks together into a mono track, giving each frame a different balance to simulate stereo on a mono track. This is equivalent to playing a mono tape and turning the balance knob! Obviously, this is less than optimal. While Vorbis supports true stereo encoding, it fakes 5.1-channel audio using a "joint-joint-stereo" method, where the left-back/left-front and right-back/right-front channels and joined together into the two stereo tracks in a similar fashion. Not very good at all.
- The way that Vorbis compresses its audio accelerates speaker degradation. It breaks sound up into an evenly-spaced array of harmonics which approximate the original waveform. "Big deal", you say, "that's how all lossy encoding schemes work!" But the way that Vorbis does it causes a noticeable amount of harmonic resonance in speaker systems, stressing their driver system and accelerating the rate at which they decay. If you know the story of the first Tacoma Narrows bridge, this is the same principle, working at a smaller and more gradual pace.
Given Xiph's poor track record with Vorbis, I'm not so sure their video encoding technology will make any serious inroads. It's not even really necessary; high-quality, open video standards such as MPEG-4 are already available and being adopted by all major players. If I were on Xiph's board of directors, I would suggest they spend more time improving Vorbis then creating yet another unnecessary standard.I would not fault MySQL for this, though, since after all it was designed and still mainly used as an SQL wrapper for flat file data, and this is why it's usually much faster than full-featured RDBMSes. The problem is with mindless open-source advocates who try to pump up MySQL as the be-all, end-all database solution. For a personal website or small business, MySQL is more than adequate, but its lack of higher-end SQL features make it a poor fit for large, distributed, mission-critical corporate or university data storage.
IBM and Microsoft's customers are generally in this higher end of the database spectrum, where Oracle or DB2 makes much more sense. It's no surprise that they would want to put MySQL in its place as an entry-level database system, where it belongs, and I fail to see how this story qualifies as news.
Save the page to your local machine and run it from there. It still works perfectly, just not from the site that hosts it.
It baffles me why Slashdot continues to post links to the NY Times with nary a mention of the NY Times random login generator. It makes my perusal of the news so much nicer.
The idea of Moto as both a compiled and interpreted language is noble (although not original; most Common LISP and Smalltalk implementations have both interpreted and compiled environments), but I urge them to reconsider their misguided language design strategy. They don't even need to come up with their own language; building a native code compiler for an established language like Python or Ruby would be a much greater boon to the open-source community at large.
With the recent news of the Antarctic melting at an extreme rate, I must agree with my esteemed colleagues in the fields of meteorology and ecological sciences that something must be done to prevent the nation of Tuvalu from being completely submerged by melted polar ice cap. My ecological chemist counterparts have been predicting these events with exact science for close to a decade. From the looks of this article, it would appear that they've been taken seriously. Look at the facts: CFC concentration is down. With the lack of CFC molecules present to bond with errant ozone molecules, the hole will have to repair itself with said ozone. We're entering a new era of global intellectual foresight with the assistance of my fellow academics.
And having a population of approximately 5.3 million persons, this goal should not be a difficult one to achieve in coming years. The energy demands of such a tiny nation are not large, aside from their few major learning institutions.
While residential fuel cell power plants and the benefits of grid-feeding are only in their fledgeling years, it surprises me that you're all THIS imatient about laptop computer battery fuel cells. When did we first hear about these notebook fuel-cells? A year ago? Two tops? I hope you're all a bit more patient with small children, jeeezus!
Any plain-Jane kit you can buy at your local Radio Shack or Fry's. There's really no need for an extravagant repair kit. You just need: various screwdrivers, a grapler to get out-of-reach screws, and possibly an IC remover. Not much else to say about repair 'kits.'
No pictures?
I have many collegues overseas. For starters, the [overwhelming] percentage of Japanese and Korean weathy enough to acquire broadband is highly suspect and inflated. Secondly, the degree of this "saturation" you speak of is much easier to attain in a relatively small country such as Japan or South Korea, south Korea being about the same size as Indiana and the total sum of Japanese islands being comperable in area to California. Got the smaller land mass? Build the infrastructure quicker and "saturate" it. If this is how "advanced" a country's 'broadband' (ugh) situation is, then Liechtenstein or Luxembourg might as well be the technological capital of the world.