Hippoplayer was my favourite. The funny thing is that it had all the basic stuff that Winamp later claimed their fame upon, such as plugin-based music-playing, player list etc.
The Assign feature in AmigaOS is probably one of the features that I truly, truly miss from Windows, Linux, MacOS X, Irix etc. There's nothing that is as flexible and powerful, yet so simple:/
I can't remember if there was ever any tracker program for the Amiga that could do that trick, but the players that could handle it used the CPU for the mixing, bypassing the audio hardware, just streaming it to the outputs
A4000 with an accelerator card, both a 68060@50 and a PPC 604@233 MHz mounted on it.
SCSI disks, BVision. Haven't upgraded the audio stuff yet, but due to the nature of the Amiga, I can still play 16-bit sound etc(That was one nice way to get PC users to shut up, playing their 24 channel 16-bit XM music on a bog-standard A500....)
Never mind that reinventing the wheel is also a good thing.
Point in case, without reinventing it, our cars would still use ancient wooden wheels stuck together into an almost solid form.
By reinventing it, we have come up with far better wheels.
The whole view-point of "We shouldn't reinvent the wheel" is dangerous. Those interested in history, archeology and similar studies know about the dangers posed by people who don't bother doing their _own_ research anymore, but just reading others research and referencing that. The same problem is becoming visible in computer related fields, where people who want to try something entirely new are disparaged, not the least on sites like this one. Comments like "It's not the UNIX way", "Why waste time on that when you can contribute to " etc aren't exactly rare. The whole viewpoint leads to copycats, rather than thinkers.
To innovate, you occasionally have to reinvent something or you risk (To use the word that is so trendy among so many here on Slashdot) monoculture, only following a limited path due to peer pressure. Without reinventing the wheels(and other aspects), we'd never have progressed to where we are now, technologically
I'm running two U160 disks from 1999 on this computer, as well as a Raptor on a Sil 3114. The U160 disks beat the crap out of the Raptor in real situations, such as handling around 10k different text files, or working with a 45MB image, or a large video stream.
The only situations where the Raptor wins is in benchmark programs, and only if write-caching is enabled. Disable the write-cache, and the Raptors performance sinks like a stone.
Ever since they started using the Giga prefix. Giga is explicitly defined as 10^9 base-10, ever since 1873 when the kilo, Mega, Giga etc prefixes were standardized.
Ergo, 1 GigaByte=1 000 000 000 Bytes.
Anything else is a result of comp sci people fucking up their standards compliance.
I definitely see no reason to not believe that. I've done arctic survival training, as well as living in sub-arctic regions for a while during winters. Want to know what the next biggest cause of death is, next to direct damage from exposure to cold? It's dehydration.
Actually, 3000 calories sounds pretty normal for very fit people in somewhat difficult conditions. Remember, the average male(on a global scale, not just the industrialized, lazy parts of the world) requires around 2300 kcal just to get by without the body deteriorating. Taking only myself into comparison, when I'm fully active with my normal training and stuff, I burn around 4000 kcal/day, just to keep up with the energy need, and I can go higher when pushing myself. Worst off are elite cyclists, elite soldiers in the field etc, who can require up to 12000 kcal/day if they want to avoid bodily deterioration.
So, basically, all you want to be able to do is to rip them off instead of thinking and working yourself?
Glad to know that one open source "developer" openly admits it. Albeit you're not the first. The whole GNU thing is plagiarization at its finest.
Re:Opterons and PowerPC together
on
Cray XT-3 Ships
·
· Score: 2, Informative
No. The biggest competitor to the XT3 will be machines like the NEC SX-8, their own X1 family or the IBM p690's. They are all shared memory systems, while the Blue Gene family is not. And therein lies a whole world of difference.
SUNET is having problems with 10GigE when they reach around 50-60%, while IB easily reaches around 85-90%. And doesn't need multiplexing to add links together.
Also, 12x isn't really vapourware, it is available, it just costs a lot. There's also talk of setting a new mid-end spec out, 8x.
The problem is, 90MB/s sustained isn't all that impressive. IB is dual-channel by nature, so a 4x HCA has 8Gb/10Gb in each direction. And 4x is just middle of the pack as far as IB is concerned.
Gig-E can't do half of what IB can in the segment that IB targets, and 10GigE can barely do half of what IB can do. First of all: GigE/10GigE is only practically useful together with TCP/IP. Congratulations, you just killed latency, there's no way you can come down to the 12-40 microseconds latency that IB achieves with real workloads. Second, the IB protocol handles traffic priorization directly in the low-level protocols, same thing with the self-healing aspects, routing data around failures. Third, and this is the most neglected part among those who haven't worked with it: RDMA. Direct in hardware and low-level protocols. It lets your process announce memory space out to the node that is sending it data, so that node can write directly into the memory for example. Allows you to build a system with fake shared memory, and still retain 12-40 microsecond latencies, unlike slow and fugly hacks run on top of TCP/IP that try to achieve the same thing with latencies of up to 10ms.
One example of fake shared memory that I've seen is a cluster with an unusual design: Two IBM P5 570's with a total of 32 cores and 128GB RAM, linked together via IBM's NUMA interconnect. They also had a total of 36 Infiniband HCA's. The slave nodes are Xserve G5's with 2GB RAM and Infiniband, and a Xilinx FPGA-card that has its own memory banks. What the slave nodes do is essentially that they work straight against the RAM on the two 570's, with the local RAM only as a form of cache. The project runs as a multi-threaded app on the 570's, and are slaved out to the nodes. The project was originally meant to be used with some p690's.
We ban clients with idiotic features such as tag masking/removing/faking, bandwidth limiting etc because we want everyone to share, and share as much as possible, since that is the purpose. In the hubs I usually visit, leechers are banned. If you want to be a leecher, there's eDonkey etc. We have enough of you bastards polluting DC. Btw, many hubs ban the 1.0 version of NMDC, because it lacks tags, so many have tried to pass themselves off as NMDC.
As for TTH sums? It can be done with any client. If the client doesn't include bandwidth limiting, fake sharing etc, many hubs will most likely allow it. Besides, you want TTH anyway, since files are now TTH-checksummed in your shares, and a lot of searching is done that way, giving more precise search results.
Oh, and DC++ works absolutely perfect running under Wine.
No, you can expect to be banned for using a client that supports bandwidth limiting, fake tags etc. Only allowing DC++/oDC/fulDC and a limited set of other DC++ derivates was because of that reason. Things have gotten better now with TTH(Tiger Tree Hashing), where you can allow or disallow based on the client TTH sum.
However, multiple multi-gigabit/s capable backbones covering all the major cities and towns of Sweden negates that argument. Hell, SUNET(Swedish University Network) has upgraded its backbone to 10Gb/s capacity, from Kiruna in the far north to Malmö in the south. Look here for a map of the various routes and router placements. The equivalent in the US would be all the universities, colleges and other higher academic/research sites in California, from south to north, linked with a 10Gb/s multi-path redundant network. And that's just SUNET. Then there are the metropolitan and regional grids, there are the commercial backbones(Skanova, Tele 2, Banverket and a couple of others).
NX actually uses RDP to achieve the low-bandwidth solution that is still capable of displaying a whole desktop and still retaining responsiveness. And Microsoft put a huge amount of research into RDP, and it's what they've been using for their Terminal Server and Remote Desktop applications for a _long_ time now.
My personal experience is that Remote Desktop from my home box is more responsive displaying the entire desktop and all apps(fuldc++, Ultraedit, Miranda, Virc, CodeWarrior) than X11 is with just one app(Codewarrior for Linux) from the same machine to the same machine via the same connection.
Actually, Kilo, Mega, Giga, Tera, Peta etc aren't metric prefixes. Those prefixes are part of the SI system, of which the metric system is just a subsystem.
Actually, 1 true standards-compliant Gigabyte is 1000 Megabyte. It's just that the computer industry ignored the standards. And somehow, it seems that so many Open Source weenies who clamor for adherence to accepted standards are keen on ignoring accepted, open standards they don't like.
To reiterate, the whole mess is the fault of the computer scientists etc who broke the adherence to standardized definitions of what Mega, Giga etc signify.
But, the bigger the cluster becomes, the more nodes and interconnect fabric you need just to keep up with the degradation of performance in the cluster for tasks that are not easily made parallell. As it is, for non-trivial tasks, a supercomputer is considered to have a good performance if they get 60-70% of the theoretical peak performance. With clusters, you're lucky if you come anywhere near close to that. And note that I said non-trivial tasks. The task of simulating gas flow or particle physics are non-trivial problems for example, while tasks such as SETI@Home and RC5-72 are quite trivial, they just require CPU power but can easily be split into separate chunks, and the only communication needed is between the individual notes and the master node handing out and receiving the chunks.
I'll use an example from my experience again: I sometimes freelance doing architectural visualizations, air flow simulations in buildings due to heating etc. I had the opportunity to try out my own code on both a Athlon cluster running on Myrinet and on a SGI Origin 3800. On both, I used 16 CPU's. Despite the superior FP performance of the Athlon CPU's, the Origin finished the work in less than half the time the clustered Athlons needed, despite me making specific changes that would allow the code to work better on the cluster.
Slashdot Mirror
Hippoplayer was my favourite. The funny thing is that it had all the basic stuff that Winamp later claimed their fame upon, such as plugin-based music-playing, player list etc.
And the ability to have for example music all sorted under MUSIC: despite the songs in various formats being on different HD's etc
The Assign feature in AmigaOS is probably one of the features that I truly, truly miss from Windows, Linux, MacOS X, Irix etc. There's nothing that is as flexible and powerful, yet so simple :/
I can't remember if there was ever any tracker program for the Amiga that could do that trick, but the players that could handle it used the CPU for the mixing, bypassing the audio hardware, just streaming it to the outputs
A4000 with an accelerator card, both a 68060@50 and a PPC 604@233 MHz mounted on it.
SCSI disks, BVision. Haven't upgraded the audio stuff yet, but due to the nature of the Amiga, I can still play 16-bit sound etc(That was one nice way to get PC users to shut up, playing their 24 channel 16-bit XM music on a bog-standard A500....)
Ah, so many fond memories....
And you call yourself a geek....
Assembling IKEA furniture is no harder than building something out of LEGO.
Hand in your geek card now.
Never mind that reinventing the wheel is also a good thing.
Point in case, without reinventing it, our cars would still use ancient wooden wheels stuck together into an almost solid form.
By reinventing it, we have come up with far better wheels.
The whole view-point of "We shouldn't reinvent the wheel" is dangerous. Those interested in history, archeology and similar studies know about the dangers posed by people who don't bother doing their _own_ research anymore, but just reading others research and referencing that. The same problem is becoming visible in computer related fields, where people who want to try something entirely new are disparaged, not the least on sites like this one. Comments like "It's not the UNIX way", "Why waste time on that when you can contribute to " etc aren't exactly rare. The whole viewpoint leads to copycats, rather than thinkers.
To innovate, you occasionally have to reinvent something or you risk (To use the word that is so trendy among so many here on Slashdot) monoculture, only following a limited path due to peer pressure. Without reinventing the wheels(and other aspects), we'd never have progressed to where we are now, technologically
I'm running two U160 disks from 1999 on this computer, as well as a Raptor on a Sil 3114. The U160 disks beat the crap out of the Raptor in real situations, such as handling around 10k different text files, or working with a 45MB image, or a large video stream.
The only situations where the Raptor wins is in benchmark programs, and only if write-caching is enabled. Disable the write-cache, and the Raptors performance sinks like a stone.
Ever since they started using the Giga prefix. Giga is explicitly defined as 10^9 base-10, ever since 1873 when the kilo, Mega, Giga etc prefixes were standardized.
Ergo, 1 GigaByte=1 000 000 000 Bytes.
Anything else is a result of comp sci people fucking up their standards compliance.
I definitely see no reason to not believe that. I've done arctic survival training, as well as living in sub-arctic regions for a while during winters. Want to know what the next biggest cause of death is, next to direct damage from exposure to cold? It's dehydration.
Actually, 3000 calories sounds pretty normal for very fit people in somewhat difficult conditions. Remember, the average male(on a global scale, not just the industrialized, lazy parts of the world) requires around 2300 kcal just to get by without the body deteriorating. Taking only myself into comparison, when I'm fully active with my normal training and stuff, I burn around 4000 kcal/day, just to keep up with the energy need, and I can go higher when pushing myself. Worst off are elite cyclists, elite soldiers in the field etc, who can require up to 12000 kcal/day if they want to avoid bodily deterioration.
So, basically, all you want to be able to do is to rip them off instead of thinking and working yourself?
Glad to know that one open source "developer" openly admits it. Albeit you're not the first. The whole GNU thing is plagiarization at its finest.
No. The biggest competitor to the XT3 will be machines like the NEC SX-8, their own X1 family or the IBM p690's. They are all shared memory systems, while the Blue Gene family is not. And therein lies a whole world of difference.
SUNET is having problems with 10GigE when they reach around 50-60%, while IB easily reaches around 85-90%. And doesn't need multiplexing to add links together.
Also, 12x isn't really vapourware, it is available, it just costs a lot. There's also talk of setting a new mid-end spec out, 8x.
The problem is, 90MB/s sustained isn't all that impressive. IB is dual-channel by nature, so a 4x HCA has 8Gb/10Gb in each direction. And 4x is just middle of the pack as far as IB is concerned.
Gig-E can't do half of what IB can in the segment that IB targets, and 10GigE can barely do half of what IB can do. First of all: GigE/10GigE is only practically useful together with TCP/IP. Congratulations, you just killed latency, there's no way you can come down to the 12-40 microseconds latency that IB achieves with real workloads. Second, the IB protocol handles traffic priorization directly in the low-level protocols, same thing with the self-healing aspects, routing data around failures. Third, and this is the most neglected part among those who haven't worked with it: RDMA. Direct in hardware and low-level protocols. It lets your process announce memory space out to the node that is sending it data, so that node can write directly into the memory for example. Allows you to build a system with fake shared memory, and still retain 12-40 microsecond latencies, unlike slow and fugly hacks run on top of TCP/IP that try to achieve the same thing with latencies of up to 10ms.
One example of fake shared memory that I've seen is a cluster with an unusual design: Two IBM P5 570's with a total of 32 cores and 128GB RAM, linked together via IBM's NUMA interconnect. They also had a total of 36 Infiniband HCA's. The slave nodes are Xserve G5's with 2GB RAM and Infiniband, and a Xilinx FPGA-card that has its own memory banks. What the slave nodes do is essentially that they work straight against the RAM on the two 570's, with the local RAM only as a form of cache. The project runs as a multi-threaded app on the 570's, and are slaved out to the nodes. The project was originally meant to be used with some p690's.
We ban clients with idiotic features such as tag masking/removing/faking, bandwidth limiting etc because we want everyone to share, and share as much as possible, since that is the purpose. In the hubs I usually visit, leechers are banned. If you want to be a leecher, there's eDonkey etc. We have enough of you bastards polluting DC. Btw, many hubs ban the 1.0 version of NMDC, because it lacks tags, so many have tried to pass themselves off as NMDC.
As for TTH sums? It can be done with any client. If the client doesn't include bandwidth limiting, fake sharing etc, many hubs will most likely allow it. Besides, you want TTH anyway, since files are now TTH-checksummed in your shares, and a lot of searching is done that way, giving more precise search results.
Oh, and DC++ works absolutely perfect running under Wine.
No, you can expect to be banned for using a client that supports bandwidth limiting, fake tags etc. Only allowing DC++/oDC/fulDC and a limited set of other DC++ derivates was because of that reason. Things have gotten better now with TTH(Tiger Tree Hashing), where you can allow or disallow based on the client TTH sum.
However, multiple multi-gigabit/s capable backbones covering all the major cities and towns of Sweden negates that argument. Hell, SUNET(Swedish University Network) has upgraded its backbone to 10Gb/s capacity, from Kiruna in the far north to Malmö in the south. Look here for a map of the various routes and router placements. The equivalent in the US would be all the universities, colleges and other higher academic/research sites in California, from south to north, linked with a 10Gb/s multi-path redundant network. And that's just SUNET. Then there are the metropolitan and regional grids, there are the commercial backbones(Skanova, Tele 2, Banverket and a couple of others).
More to the point than you might think.
NX actually uses RDP to achieve the low-bandwidth solution that is still capable of displaying a whole desktop and still retaining responsiveness.
And Microsoft put a huge amount of research into RDP, and it's what they've been using for their Terminal Server and Remote Desktop applications for a _long_ time now.
My personal experience is that Remote Desktop from my home box is more responsive displaying the entire desktop and all apps(fuldc++, Ultraedit, Miranda, Virc, CodeWarrior) than X11 is with just one app(Codewarrior for Linux) from the same machine to the same machine via the same connection.
Actually, the SI prefixes were defined in 1874, well before the computer science people fucked up and broke the standards compliance.
Actually, Kilo, Mega, Giga, Tera, Peta etc aren't metric prefixes. Those prefixes are part of the SI system, of which the metric system is just a subsystem.
Actually, 1 true standards-compliant Gigabyte is 1000 Megabyte. It's just that the computer industry ignored the standards. And somehow, it seems that so many Open Source weenies who clamor for adherence to accepted standards are keen on ignoring accepted, open standards they don't like.
To reiterate, the whole mess is the fault of the computer scientists etc who broke the adherence to standardized definitions of what Mega, Giga etc signify.
Otoh, those figures are for a task that is very trivial and easily parallellizable, i.e they fit well on clusters.
But, the bigger the cluster becomes, the more nodes and interconnect fabric you need just to keep up with the degradation of performance in the cluster for tasks that are not easily made parallell. As it is, for non-trivial tasks, a supercomputer is considered to have a good performance if they get 60-70% of the theoretical peak performance. With clusters, you're lucky if you come anywhere near close to that. And note that I said non-trivial tasks. The task of simulating gas flow or particle physics are non-trivial problems for example, while tasks such as SETI@Home and RC5-72 are quite trivial, they just require CPU power but can easily be split into separate chunks, and the only communication needed is between the individual notes and the master node handing out and receiving the chunks.
I'll use an example from my experience again: I sometimes freelance doing architectural visualizations, air flow simulations in buildings due to heating etc. I had the opportunity to try out my own code on both a Athlon cluster running on Myrinet and on a SGI Origin 3800. On both, I used 16 CPU's. Despite the superior FP performance of the Athlon CPU's, the Origin finished the work in less than half the time the clustered Athlons needed, despite me making specific changes that would allow the code to work better on the cluster.