DragonFly BSD
DragonFly users List (threaded) for 2006-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: What would you like in DF 1.8?

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Wed, 19 Jul 2006 02:27:07 +0800

Michel Talon,,,01 60 15 58 14 wrote:

Steve O'Hara-Smith wrote:

Well since all of that can be obtained elsewhere I would be very
happy to see it stacked behind the clustering behaviour that Matt has
already outlined as the primary goal because that *cannot* be obtained

Sure it can. Just with a different methodology and priority set.

And a higher price-tag.

Cost-no-object, I'd go with well-proven IBM S390, IBM AIX, either with HACMP on Power architecture, or Solaris on T1, in that order.

As system architecture consultants for large projects, we have done just that.

In one case, the only choices permitted were '(hardware) vendor supported Unix', leaving out *BSD by implication, and Linux by specific prohibition.

But for most projects, cost IS an object, so I am interested in DragonFly.

I must be dreaming, what are running all those high performance clusters which appear in the Top500, and are supposed to be based on Linux?

The top 500 research 'puters have as much bearing on volume computing as Formula One race cars do on the trucking industry. Now and then one gets a better brake-lining material, bearing design, or lubricant formulation out of it all, otherwise mostly publicity and excitement.

Perhaps something like

I could not swear it, but from memory it is more than 5 years and perhaps
much more than functional solutions exist for Linux, with all kernel hooks
and much more than  have been proposed here.

No need to rely on memory. Wikipedia has a reasonably accurate article.

But DragonFly appears to have its sights set a lot higher than *most* prior art, not just Linux or legacy 'big iron'.

Admirably, the DragonFly team is carrying both *BSD's legacy 'world' on their back, AND the 'C' language limitations and libs baggage.

I would bet that not one person in a hundred here - many developers included - recognize just how massive a *burden*, rather than advantage that is compared to a clean-slate effort. 'C' and its libs, the whole Unix 'world' can fall into the 'when the only tool you have is a hammer...' category.

Nor why it means that at each stage DragonFly has proved a far more attractive 'world' to a server admin that distro-of-the-day.

That 'baggage' has been very expertly carried.

> Not to mention older
distributed computing projects like amoeba by Tanenbaum. And by the way,
who has the money to run such clusters, besides big corporations and big academic labs?

'project's' in particular, and academia in general are learning tools, seldom production environments. Examples, not templates.

Thousands of SME, and at least as many departments/divisions/branch offices within larger enterprises, finance houses in particular, ran VAX/VMS, HP-MPE, Perkin-Elmer, Tandem, or Solaris clusters. Larger firms ran closely-coupled IBM Big Iron clustering.

Most of these clusters handled mundane tasks such as telecoms switching, utility grid management, *everybody's* billing, inventory, manufacturing, banking, brokerage, and POS systems.

WTH - Cable & Wireless used VAX/VMS clusters in the UK to manage private-network work-orders and trouble tickets, and Perkin-Elmer clusters in the US to manage network switching and billing. Telco networks and power grids are only allowed a few seconds *per year* of outage.

All in the 1980's, BTW.

NORAD had clustering and failover in the 60's before ARPAnet even started. Over 9,000 miles of hardened deep-underground private network. Resilient auto-route packet technology was developed so they didn't have to mortgage the entire planet to build *more* of that!

How much does cost Myrinet and other Infiniband hardware
necessary to ensure low enough latency so that distributed computing has
a small chance of being a realistic proposition?

That's all relative, and near-instantaneous b/w is a seldom needed special-case.

Research and 'modeling' establishments aside, in the business world, robust, high availability applications and reliable distributed storage have always been more important that moving CPU-cycles about. 80% I/O, 20% CPU is still the rule of thumb for biz apps.

Same-room clusters have had proprietary high-speed links for ages, and 10-Gig-E, Gig-E, and even 100 BT are more than adequate for most day-to-day needs.

> The present and foreseable
future of affordable computing is multiprocessor machines, with perhaps up
to 32 virtual processors (Sun machines). Being scalable on such hardware is
a realistic goal, Solaris does it, Linux does it, both using traditional
solutions. Maybe Dragonfly can do it with innovative solutions.

*Everybody* does it.

Don't confuse Linux 'projects' & PR with other folks actual deliveries over a quarter of a century.

It isn't 'clustering', nor even SMP or SMP/AMP hybrid MP (OS/2) that are 'new'.

What is 'new' is DragonFly's approach - as clean a break as can be had from legacy-bound thinking as to how a *BSD-style* kernel & resource set(s) can work best to support 'placeless', portable, hot-swappable goods in a near-as-dammit seamless manner.

If all goes well, DragonFly may prove to be *way* better than most F/OSS prior art - for both local and remote resources.

If not, 'Drag-On, Fly' will still represent a marvelous cleanup and improved understanding of code that can be utilized to some extent in the *BSD's in general - as with lessons learned from the 'trusted' and 'secure' *BSD efforts.

IOW - DragonFly has already gone far enough that it cannot 'fail' - just succeed to a greater or lesser degree.


Bill Hacker

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]