BSD is fine for your dual-CPU mail-server-in-a-closet. That's what was designed for. However, the world does not end with you. Scientific applications, like weather prediction, etc. need something different (perhaps i should say "something more") than a mail server in a closet. That's what Irix was designed for. That's why some people buy 1024 CPU machines, running Irix. That's why some will buy 64 CPU machines running Linux.
Not foregone, by any means. Irix is still offered to customers. It's only logical, since Irix is the _only_ Unix variant that can run on a 1024 CPU single-image system. Yes, i am aware of the IBM and HP systems with a similar number of CPUs, but those are not single-image, those are partitioned into many separated smaller systems each one running it's own kernel. Irix can run a single kernel on 1024 CPUs simultaneously. It's the only one, until now. Linux can do only 64.
The proposal is way too much biased towards "academic credentials = talented people". There are many people who are extremely skilled, and yet they sometimes don't even have a BS. At most, if any, the requirement should say "must have a college degree", but don't limit it to "if you work in IT, you must have a degree in computer science".
...if you're on an H1B and you want to switch jobs, you basically have to get another H1B. That kind of visa cannot be transferred from one company to another. Go to a different company, and you loose your current H1B, so you must apply for another one. If approved, this proposal will increase enormously the pressure on the H1B holders. In a nutshell, it's going to make them slaves to their current employer. The cap, if any, should be put on H1B visas offered to people who are not already H1B owners.
I think many people could do themselves a great service by simply studying the vsftpd security libraries. Those are generic enough to be used by almost any other application, and provide a solid foundation to write applications that do not fall apart under classic C exploits: buffer overflows, etc.
Re:works great for you, but that's all
on
SDSC Secure Syslog
·
· Score: 3, Informative
Well, msyslog works fine with SQL, provided that you don't miss these steps: - create the appropriate table structure - configure msyslog to use the tables you created - configure SQL to let msyslog have enough permissions to write to the tables The first two are in the man pages (om_mysql and the conf file format), the latter in the SQL server documentation. Works like a charm.
Well, not exactly. The traditional syslog is old, broken and dying. It doesn't count. syslog-ng is cute and has TCP and clever message filtering. But that's all. msyslog goes beyond that and adds true and reliable SQL logging (SQL in syslog-ng is a joke), PEO message protection (tamper-evident) and a somewhat more extensible implementation. But it stops there. sdscsyslog is the first attempt to solve all the problems with all the other implementations, and also adds long-awaited features. However, it does not overlap with my proposal, because mine is just... heh, just a proposal, while they already have a running application.
But i agree with you. There is some fragmentation in the Open Source / Free Software world.
Another problem with DNS is that your logs can be "poisoned". DoS attack is a smaller problem when compare to poisoning.
works great for you, but that's all
on
SDSC Secure Syslog
·
· Score: 3, Interesting
syslog-ng is nice, it has the advantages of TCP and a smart filtering scheme, but that's all. For example, logging to SQL is very weak, it's more like a hack. For example, a syslog version that does everything syslog-ng does, and more, and has decent SQL logging, and a sound security mechanism (PEO) is msyslog However, even msyslog is quite simplistic when compared to sdscsyslog. IMO, sdscsyslog has an extremely intelligent architecture, that allows for easy expansion, and easy implementation of features that neither syslog-ng nor msyslog can dream of.
O3K is a single-image system. Go back to reading the theory please, or stop posting nonsense.
Your intuition is somewhat correct regarding latency penalties for access to "remote" memory versus "local" memory in a NUMA system. However, while a Sun *Fire has a latency penalty of 10:1 for such cases, an SGI O3K has a 1.5:1 "penalty"; hardly a penalty at all. Most people do not bother at all about latency; in those rare cases when people try to optimise for NUMA "remote" memory access, they do that for reasons of bandwidth, not latency (like, backing up 1TB in one hour:-D dumb example, i know, but it's the only real one that comes to mind). Please read this article for more info:
Also remember that Mosix has latency penalties many orders of magnitude worse than NUMA. Difficult to overcome that. Not to mention that many problems are "almost parallel" - that means there's a need for heavy data exchange between nodes all the time (many weather prediction algorithms, etc.); with those, no matter how smart your programmers are, you just can't workaround a bad latency in a typical cheap network cluster (Beowulf, Mosix) - you simply need a true single image NUMA system like an SGI O3K.
Sorry, my bad. Of course non-parallel problems cannot be solved on multi-CPU systems, single-image or not. What i wanted to say is, only perfect parallel problems can be solved easily on clusters. If there's any need for a signifficant exchange of information between nodes ("almost-parallel" problems) then clusters are useless, you need a single-image supercomputer. Unfortunately, many difficult problems (weather prediction, etc.) are almost parallel, hence the need for powerful single-image supercomputers, like the ones SGI makes.
Quote: SGI's "NUMAflex" (TM) modular design approach builds computer families with unusual scalability and evolvability characteristics. It partitions CPU, I/O, and other functions into small, 19" rackmount computing "bricks", then combines them via efficient, high-speed cache-coherent cabled interconnects, rather than large backplanes.
SGI hardware is utter crap when it comes to reliability.
Just how much experience exactly do you have with SGI hardware? I routinely work with tens of SGI machines of many different types, as well as Linux on Intel (Dell hardware), Sun, etc. And if i were to make a relibility comparison, SGI is the most reliable. Far more reliable than the Wintel/Dell crap anyway.
That's a cluster, not a single-image supercomputer. Read again the coments to this article on Slashdot, there are many explanations why a cluster, no matter how many CPUs you throw at it, will never be able to solve entire classes of problems fast enough; to do that, you need a single-image computer, like the SGI stuff.
...the single-system image... is only really advantageous for lazy programmers...
There are entire classes of problems which cannot be solved fast enough on clusters, but only on single-image systems. Anything that cannot be made into a parallel algorithm falls into that category.
...let's say that Mosix and 10Gig ethernet advances to the point...
With networked clusters you're always going to have latencies, orders of magnitude higher than with single-image supercomputers. Sure, perhaps in 10 or 15 years, we're going to have network latencies as small as those of a PCI bus, but i'm not really talking about future that far. Until then, clusters will be slow for certain problems. Deal with it.:-P
You compare apples and mudpies. An SGI supercomputer is a single-image system, where all 500...1000 CPUs sit on the same bus (therefore talk extremely fast to each other) and share the same memory. A cluster is different: the CPUs are effectively like islands, without a good visibility into each other's data, with huge latencies when talking to each other. Yes, i'm aware of Mosix, but that does not solve the latency problem.
Nope. SGI does not do graphics workstations anymore. People saw it dissapearing from that arena, and this is how all these ridiculous "SGI is dying" stories appeared. Nowadays SGI is doing precisely the type of systems described in this Slashdot article: supercomputers. Of course, that has not so much visibility in the home computers market;-)
That's a misconception due to the ridiculous amounts of power usually required by Intel and AMD processors. The MIPS cpus need only 17 watts or so. That's almost 10x lower than Intel/AMD.
Slashdot Mirror
BSD is fine for your dual-CPU mail-server-in-a-closet. That's what was designed for.
However, the world does not end with you. Scientific applications, like weather prediction, etc. need something different (perhaps i should say "something more") than a mail server in a closet. That's what Irix was designed for. That's why some people buy 1024 CPU machines, running Irix. That's why some will buy 64 CPU machines running Linux.
You're not a troll, you're just ignorant.
BSD can do... what?
On how many CPUs can BSD scale? Irix can scale up to 1024. It's the only Unix that goes that far up. Where's BSD now?
Not foregone, by any means. Irix is still offered to customers. It's only logical, since Irix is the _only_ Unix variant that can run on a 1024 CPU single-image system. Yes, i am aware of the IBM and HP systems with a similar number of CPUs, but those are not single-image, those are partitioned into many separated smaller systems each one running it's own kernel.
Irix can run a single kernel on 1024 CPUs simultaneously. It's the only one, until now. Linux can do only 64.
The proposal is way too much biased towards "academic credentials = talented people".
There are many people who are extremely skilled, and yet they sometimes don't even have a BS.
At most, if any, the requirement should say "must have a college degree", but don't limit it to "if you work in IT, you must have a degree in computer science".
...if you're on an H1B and you want to switch jobs, you basically have to get another H1B.
That kind of visa cannot be transferred from one company to another. Go to a different company, and you loose your current H1B, so you must apply for another one.
If approved, this proposal will increase enormously the pressure on the H1B holders. In a nutshell, it's going to make them slaves to their current employer.
The cap, if any, should be put on H1B visas offered to people who are not already H1B owners.
I think many people could do themselves a great service by simply studying the vsftpd security libraries. Those are generic enough to be used by almost any other application, and provide a solid foundation to write applications that do not fall apart under classic C exploits: buffer overflows, etc.
Check here the vsftpd website.
That was UDP, not DNS.
Silly braintypo...
Well, msyslog works fine with SQL, provided that you don't miss these steps:
- create the appropriate table structure
- configure msyslog to use the tables you created
- configure SQL to let msyslog have enough permissions to write to the tables
The first two are in the man pages (om_mysql and the conf file format), the latter in the SQL server documentation.
Works like a charm.
Well, not exactly.
The traditional syslog is old, broken and dying. It doesn't count.
syslog-ng is cute and has TCP and clever message filtering. But that's all.
msyslog goes beyond that and adds true and reliable SQL logging (SQL in syslog-ng is a joke), PEO message protection (tamper-evident) and a somewhat more extensible implementation. But it stops there.
sdscsyslog is the first attempt to solve all the problems with all the other implementations, and also adds long-awaited features. However, it does not overlap with my proposal, because mine is just... heh, just a proposal, while they already have a running application.
But i agree with you. There is some fragmentation in the Open Source / Free Software world.
It's very funny, only yesterday i published on a mailing list my proposal for a new syslog daemon architecture:
:-)
Syslog Daemon Architecture
I wrote this document for the msyslog project.
And then, today, i noticed the sdscsyslog announcement on Slashdot!
There are many similarities between their architecture and my proposal:
- modularity
- extensibility
- scalability, etc.
Another problem with DNS is that your logs can be "poisoned". DoS attack is a smaller problem when compare to poisoning.
syslog-ng is nice, it has the advantages of TCP and a smart filtering scheme, but that's all. For example, logging to SQL is very weak, it's more like a hack.
For example, a syslog version that does everything syslog-ng does, and more, and has decent SQL logging, and a sound security mechanism (PEO) is msyslog
However, even msyslog is quite simplistic when compared to sdscsyslog. IMO, sdscsyslog has an extremely intelligent architecture, that allows for easy expansion, and easy implementation of features that neither syslog-ng nor msyslog can dream of.
O3K is a single-image system. Go back to reading the theory please, or stop posting nonsense.
Your intuition is somewhat correct regarding latency penalties for access to "remote" memory versus "local" memory in a NUMA system. However, while a Sun *Fire has a latency penalty of 10:1 for such cases, an SGI O3K has a 1.5:1 "penalty"; hardly a penalty at all. Most people do not bother at all about latency; in those rare cases when people try to optimise for NUMA "remote" memory access, they do that for reasons of bandwidth, not latency (like, backing up 1TB in one hour
Please read this article for more info:
NUMAflex Modular Design Approach
Also remember that Mosix has latency penalties many orders of magnitude worse than NUMA. Difficult to overcome that.
Not to mention that many problems are "almost parallel" - that means there's a need for heavy data exchange between nodes all the time (many weather prediction algorithms, etc.); with those, no matter how smart your programmers are, you just can't workaround a bad latency in a typical cheap network cluster (Beowulf, Mosix) - you simply need a true single image NUMA system like an SGI O3K.
Sorry, my bad.
Of course non-parallel problems cannot be solved on multi-CPU systems, single-image or not.
What i wanted to say is, only perfect parallel problems can be solved easily on clusters. If there's any need for a signifficant exchange of information between nodes ("almost-parallel" problems) then clusters are useless, you need a single-image supercomputer.
Unfortunately, many difficult problems (weather prediction, etc.) are almost parallel, hence the need for powerful single-image supercomputers, like the ones SGI makes.
NUMAflex Modular Design Approach
Quote:
SGI's "NUMAflex" (TM) modular design approach builds computer families
with unusual scalability and evolvability characteristics. It partitions
CPU, I/O, and other functions into small, 19" rackmount computing "bricks",
then combines them via efficient, high-speed cache-coherent cabled interconnects,
rather than large backplanes.
Just how much experience exactly do you have with SGI hardware?
I routinely work with tens of SGI machines of many different types, as well as Linux on Intel (Dell hardware), Sun, etc. And if i were to make a relibility comparison, SGI is the most reliable. Far more reliable than the Wintel/Dell crap anyway.
You need higher density if you want to put it on a ship. If you think no one wants that, think again (homeland security and all that). ;-)
That's a cluster, not a single-image supercomputer. Read again the coments to this article on Slashdot, there are many explanations why a cluster, no matter how many CPUs you throw at it, will never be able to solve entire classes of problems fast enough; to do that, you need a single-image computer, like the SGI stuff.
There are entire classes of problems which cannot be solved fast enough on clusters, but only on single-image systems. Anything that cannot be made into a parallel algorithm falls into that category.
With networked clusters you're always going to have latencies, orders of magnitude higher than with single-image supercomputers.
Sure, perhaps in 10 or 15 years, we're going to have network latencies as small as those of a PCI bus, but i'm not really talking about future that far. Until then, clusters will be slow for certain problems. Deal with it.
Don't worry, when the economy is in the shitter, there's always your regular three-letter agency to buy those supercomputers. ;-)
You compare apples and mudpies. An SGI supercomputer is a single-image system, where all 500...1000 CPUs sit on the same bus (therefore talk extremely fast to each other) and share the same memory.
A cluster is different: the CPUs are effectively like islands, without a good visibility into each other's data, with huge latencies when talking to each other.
Yes, i'm aware of Mosix, but that does not solve the latency problem.
Nope. ;-)
SGI does not do graphics workstations anymore. People saw it dissapearing from that arena, and this is how all these ridiculous "SGI is dying" stories appeared.
Nowadays SGI is doing precisely the type of systems described in this Slashdot article: supercomputers. Of course, that has not so much visibility in the home computers market
Its CPUs need 10x less power than Intel or AMD. ;-)
That's a misconception due to the ridiculous amounts of power usually required by Intel and AMD processors.
The MIPS cpus need only 17 watts or so. That's almost 10x lower than Intel/AMD.
The MIPS cpu takes only 17 watts to run. That's 10 times lower than your average Intel or AMD.