Slashdot Mirror
Open Group Releases DCE 1.2.2 as Free Software
lkcl writes "The Open Group announced 12th January 2005 that they are releasing DCE/RPC 1.2.2 as a Free Software Project - under the LGPL. This is a major coup for Free Software: the Distributed Computing Environment is known to be involved in some major projects. There is a mirror at opendce.hands.com which runs rsync,
ftp, and there is also a dce122.tar.bz2.torrent bittorrent running as well."
This is one _monster_ big deal for Free Software.
This is the code that allows big companies such as IBM, Fujitsu, Entegrity etc. to bid for £500m contracts.
We have FreeDCE already, which is the DCE 1.1 Reference implementation autoconf'd and updated...
This isn't nearly as important as claimed here; other technologies supercede it.
In precisely the same way you can call your product Kool Aid, when it helps nobody, and is in no way affiliated with Kool and the Gang.
Or in the same way that you drive on a parkway, and park in a driveway.
I don't need no instructions to know how to rock!!!!
But, I figured I'd be socially productive, RTFA and post an explanation myself.
OK, now can I say "WTF?"What I'm listening to now on Pandora...
The Open Group was formed by the merger of X/Open and the Open Software Foundation. The use of "open" in all those names predates the phrase "open source." The term it relates to is "open systems," which refers to standardized Unix systems, as opposed to mainframes.
Gosh, first Motif, now DCE? What other package that I haven't used in 10 years will be next?
The Distributed Computing Environment (DCE) is a software system developed in the early 1990s by a consortium that included Apollo Computer (later part of Hewlett-Packard), IBM, Digital Equipment Corporation, and others. The DCE supplies a framework and toolkit for developing client/server applications. The framework includes a remote procedure call (RPC) mechanism, a naming (directory) service, an authentication service, and a distributed file system (DFS). DCE RPC was derived from an earlier RPC system called the Network Computing System (NCS) created at Apollo Computer. The naming service was derived from work done at DEC. DCE DFS was based on the Andrew file system (AFS), originally developed at Carnegie-Mellon University, and later extended by Transarc Corporation (which was later merged into IBM)
Link here
This is a disturbing trend I've seen cropping up a few times lately, but it seems like all of their useful introductory documentation (at least what they refer to on their website) is available in book format that you have to pay money for. Is the code really open and free if you have to pay money to learn how to use it?
In '93, I was making the big bucks at a defense contractor because I could tell them how/where to use DCE.
It is interesting to see the difference between the openess of the OSF and the openess of the open source movement [all that gnu software!] begin to blur.
I hope that exposure of the security code buried in DCE, especially where it uses kerberos, will help polinate other open source projects with improved security features.
You call that a troll? I have a whole beltway full of trolls better than that!
the code's _crawling_ out the woodwork today. thirteen _years_. bittorrent too although it's a lot smaller than 90mbytes...
It's been a while since I've looked at it, but wasn't DCE hijacked by Evil Empire? It was put together by OSF, now called the Open Group, and it seems bittersweet to have it released as free software now. If only they had the foresight to open it from the start.
The EOSDIS/ECS project. http://eospso.gsfc.nasa.gov/ is a good place to start looking at the project I was on. It's currently the largest satellite data processing and science data repository on the face of the planet. :) (toot toot... there goes my own horn ;))
Anyway... DCE was used to tie several servers together which are the core of the system. I found it very reliable and solid (and that was several years ago).
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
yep!
Since the introduction of DCE, Microsoft have felt the need to use an RPC mechanism, though they didn't want to write their own from scratch so it was suggested they use the best in the industry (already chosen by the OSF) - legend has it that they approached the OSF for DCE RPC but didn't want to pay the licence fees. What Microsoft _did_ do was to take the Application Environment Specification and a network sniffer and reverse engineer the DCE RPC. MS RPC is based upon, and, with a little application (Like OEC Enterra) will work with DCE RPC.
"Microsoft have felt the need to use an RPC mechanism, though they didn't want to write their own from scratch so it was suggested they use the best in the industry (already chosen by the OSF) - legend has it that they approached the OSF for DCE RPC but didn't want to pay the licence fees. What Microsoft _did_ do was to take the Application Environment Specification and a network sniffer and reverse engineer the DCE RPC. MS RPC is based upon, and, with a little application (Like OEC Enterra) will work with DCE RPC."
I used Motif yesterday in fact. While certainly ugly and headache prone, it does have some significant advantages. It's ubiquitous and available everywhere. It's fully documented. It has stable API (unheard of with other high level X11 toolkits). And it's much much much easier than using bare Xlib.
I wouldn't recommend it to most people, as it's still low level enough to bog you down in the UI instead of the backend. But it's hardly "abandonware".
Don't blame me, I didn't vote for either of them!
yes they are!! DCE 1.1 - the RPC runtime and development environment reference implementation, only 250,000 lines of code, has been available for nearly a decade under the OSF BSD-like license.
this is _really_ different: 3.5 _MILLION_ lines of code, including CDS and DFS, under the LGPL.
Microsoft's COM (also known as DCOM) sits on top of this RPC layer to implement a distributed component object model -- one of Microsoft's finest and most underrated inventions. It's also one of their most copied technologies -- KDE, GNOME, OpenOffice (UNO) and Mozilla (XPCOM) all implement very similar object models.
Of course, DCE RPC is also famous for the UUID (aka GUID) algorithm -- 128-bit identifiers whose uniqueness is mathematically guaranteed as long as the generator can access a network card with a unique MAC address.
DCE is the core middleware at PSU and has been for years. Your access account you use for everything is a DCE principle (Which ends up being KerberosV + some stuff).
:) It really was/is a cool and powerful system. Its one major failing it the complexity and effort needed to set it up.
The PASS filespace is DFS which is the distributed filesystem componant of DCE. Webmail and the Portal (wehmail.psu.edu portal.psu.edu) are built on top of the filesystem.
eLion is a client server application that uses Smalltalk on the web front end and Natural/Adabas for the backend (running on an IBM zSeries mainframe). A custom in house developed DCE RCP middleware mechanism is used to get them to talk to each other. This lets us do dynamic load balancing without special hardware, adding and removeing backend servers and automatically have them put into the locally managed "server pool" on each web server front end, and validating the calls on the backend via the kerberos credentials of both the web server and the user making the call. (can you guess what I did for the last 3 years?)
Now, IBM has end of lifed DCE, which screws us (and several National Labs, Merck, Cal Poly Tech, Buffalo U, Pain Webber, a handful of other universities, etc). PSU is migrating off of it to MIT KerberosV, LDAP, a "yet to be determined filesystem" (probably OpenAFS, which is a 10 year step backward), and I have absolutely NO idea how we will replace the RPC.
Anyway, PSU people have been using DCE heavily for about a decade and many didn't even know it
Finkployd
are you kidding? I'm sitting here watching my firewall snuff out barbarians who know how to use the DCOM "DCE BIND" against my Win2K box...why on earth would you want to pollute unix with a f**ked up microsoft version of an old and long since open protocol for distributing applications?
You call that a troll? I have a whole beltway full of trolls better than that!
It's already been done! Also see this for details of TOG meetings etc.
....It uses DES for encryption! Yuck!!!!! Big time! At the very least, they could have hacked it so you could use AES instead, if you wanted.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
yes, dammit. it still is, but in different ways: companies like IBM and Fujitsu and Entegrity still make hundreds of millions of dollars out of it.
DCE/RPC is to DCOM as
Corba's RPC mechanism is to CORBA.
i mention a bit about it in my advogato article: it's _very_ stupid that TOG didn't release DCE/RPC (and DCOM) a _lot_ earlier than this.
never mind....
Enjoy
D CE.shtml#osf122
http://support.entegrity.com/private/doclib/index
i.e. Let's outsource support for this sucker! I mean, how excited am I supposed to get, in 2005, about a techmology that allows me to marshall/unmarshall data and call remote procedures over the 'net? Isn't that already being done (a lot) by the various CORBA and RPC stuff already running on my Linux box?
Everybody's a libertarian 'till their neighbour's becomes a crack house.
Using Accentures implementation as an example doesn't say much about DCE/RPCs robustness. It has been plagued by problems as Computer Weekly reports.
Given what a good filesystem DFS is this will be nice to have access to all the features of DCE/DFS and give OpenAFS a run for its money.
But seriously DFS has a lot of core features that can even cause problems for DFS vendor Entegrity.
I smell a new project called OpenDFS
that's since been sorted out. FreeDCE now basically is wire-compatible and IDL-compatible with MSRPC.
it's been a long time (like almost a decade) but it's there.
i'm sorry you didn't have my email address when you needed it, i could have done with the extra work.
i fear that you are right.
:)
if IBM hadn't stalled the release for four years, but, they're interested in making money: if there were major contracts they were still pulling in, there was no reason for them to hand it all over on a plate.
remember, they would have _just_ finished adding LDAP to their DCE 3.0 internal proprietary version.
now, of course, this code is end-of-lifecycle as far as they are concerned, and a large number of companies and universities are in deep doodoo unless the open source community can pull together.
also, remember, code doesn't decay or rust, it just _looks_ old...
This is completely wrong.
This days you can consider a mainframe open, because not only it can ran GNU/Linux but also it has a facility to run open systems programs, protocols etc. Other non-Unix systems do so, like Digital VMS.
Open systems are systems that implement open standards, that is, standards agreed upon by representative bodies like ISO specifying interfaces, protocols, file formats etc.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Apart from the press release, where does it actually
say that it's licensed under LGPL? The press release does not even make it clear that it really is the GNU LGPL, nor exactly what version of DCE the "Open" Group is supposed to release. But, if they really do release the stuff (although it's probably 10 years late), better now than never.
About 8 (?) years ago I was working on an architecture for a client server system - we had a mix of Unix and Microsoft servers and we wanted something that would tie them together so we could use the best that each had to offer.
I faced the same problem, but about 5 years ago. My solution was to use ONC (Sun) RPC instead of DCE. ONC RPC has been supported on Linux / Unix forever, and I found a port to Windows (from the original Sun code) that worked nicely.
Since then however, it looks like that port of ONC RPC to Windows has disappeared off the 'Net... I'm not sure what that's all about. But I can definitely say that RPC between Windows and Linux works, at least using Sun RPC.
// TODO: Insert Cool Sig
Try this -- MS
Try this -- Solaris
Preview exists for a reason, doh!
Tandy Corporation is rumored to have just made TRS-80 firmware open source. With the competitive race to open source things, several dead vendors are trying to ride on the OSS coat tails.
Rumor has it that SwiM Motif may up the ante. Not to be outdone, the Transmeta Linux distribution is being resurrected. OS/2 Warp may follow. Stay tuned...
Yep, exactly the same thing came to my mind when I saw the parent :) Nevertheless I would like to cite a more formal definition, too:
An Open System is a system consisting of cooperating a) SW b) HW and c) people, which
- serves the desired service,
- its interface specifications are 1) fully and well defined, 2) publicly accessible and 3) maintained on ground of common agreement and
- its implementation conforms the specification.
Now, because this thingy above has been translated by me, speaker of a tiny little language from that tiny little language into English, there's a defintion by the glorious DoD, too, which is actually in proper English (all citations taken from course material in my mother tongue, so sorry, no links):
"A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability."
You all know what Open Source is about - as it can be seen Open Systems is a very different (in terms of actual software used in the system surely overlapping) area. Buzzwords like Enterprise Application Integration (EAI), ebXML, the Web Services and WS-* mess have all strong roots in this initiative (well, better philosophy, or even better natural need) pushed by tiny companies as the Big Blue itself (or herself? Ehh, a proper language has explicit genders for nouns :))
Anyway, one more comment. There are comments about about DCE being a dead technology and opening it up too late. Let's name the market leader distributed object technology (as the technology most fitting producing middle-sized, complicated, semi-loosely coupled systems) - it's DCOM. (If anybody mentions Java RMI... please, just don't mention it, I'm fed up with that.) CORBA is dead, as... dead. (insert obligatory comment about asbesthos suit here) The other integration middleware environments are for other design cases. DCOM is built on DCE. So it is still nice to see this move.
Luke,
Indeed, this is a very interesting development. With an LGPL license for DFS, it's time to give the DCE descendent of AFS another look.
But we have AFS, too, and although OpenAFS is not GPL-compatible, its free software in a real sense, and more important, it has a living community of developers who've worked on the code stretching back into the 1980s.
I'm not as convinced now as I might have been 3 years ago that DCE is a better mousetrap than Rxgk is shaping up to be.
There will probably be crossover between OpenAFS and DFS ideas--I just hope that working with DCE people doesn't turn out to be a Samba/Active Directory driven experience. It would be easier and more pleasant to fork.
Matt
DCOM is still in heavy use and AFAIK it's using DCE.
we already have KDE and gnome.
You've obviously never tried to take the Don Valley Parkway in Toronto, Ontario, Canada during rush hour.
No offense, I don't think you understand what's going on here.
First, I'm not much of a fan of DCOM, even though I did spend 2-1/2 years at Microsoft. While DCOM and DCE RPCs are conceptually the same, the problem here is DCOM laden Windows (many entry points).
I have a different opinion of just plain COM (no crossing network wires). MS has done a good job defining many interfaces and like it or not, OLE Containers allow for the building of larger UIs from components. MS had this right YEARS ago. Never mind JavaBeans et al.
As far as this somehow polluting *NIX, what you have observed is an implementation issue. That and MS doesn't have enough code reviews.
There is nothing wrong with the concept of Remote Procedure Calls. The whole idea of calling into remote code was pioneered by Sun with their Network File System (NFS) except that because they were the vanguard, DCE RPCs which came later were incompatible not to mention there were the old *NIX turf wars and RPCs were another schism (outside of System V vs. BSD).
Like any network service (NFS being no exception) if you can connect to a network socket and send the "right" set of bytes, you can potentially elicit undesirable effects (from the perspective of the owner of the computer system of course).
Anwyay, MS simply went "DCOM happy" and exposed many more services than a typical *NIX box might expose... serving as entry points... and without a firewall, they were asking for trouble.
The other problem with DCOM and DCE RPCs is that:
1) Most C++ developers who think they're good can't code for sh*t in that language.
2) The old adage of "When you have a hammer, everything looks like a nail" applies. The propensity to decompose everything to C++ interfaces with the DCOM/RPC crowd went overboard.
3) C++ is just too low level for many things that need to be done nowadays. The argument of "C++ is fast" has been consistently assaulted by Moore's Law giving that notion about as much relevance as the idea of coding contemporary applications in assembly language. With the computing power afforded nowadays, it is simply not worth dealing with memory management and the memory leaks that are bound to happen and cause system hiccups (or outright failures). Yes there are some applications that demand it, but those are the exception, not the rule. And just like the guy who write graphics drivers for me, I will leave those tasks to someone else.
4) Lastly, the Net and the high interconnectivity called for in mixed environments (which may not be DCE-RPC enabled) it is not worth architecting large systems with around DCE-RPCs.
In my experiences I found #1 to be a biggest issue.
I remember I would ask people to rank themselves on a scale from 1 to 10 with C++. I would qualify the upper tiers noting that "If you say you're an 8 you should be able to tell me in what situations you want to write a copy constructor... off the top of your head." Many people would respond with "8" - guess what was my first question? And most were clueless to answer it.
Some clarification.
It's not just the DCE RPC that has been released, it's the whole schebang, including:
* The build environment (ODE)
* The vast documentation with specs
* Threads (Ugh!, Please don't use)
* RPC
* Directory services
* Security services
* Time sync
* File service (DFS) including the Episode file system.
* Test procedures
* The various administration tools
* The tools needed to make DCE applications.
The code is old, however and building this is not for the faint of heart, but there's lots of good stuff in there.
Nuf said!
As a matter of fact, I'm from Toronto.
Only a fucking moron would take the DVP during rushhour.
I don't need no instructions to know how to rock!!!!
I don't mean to sound like a troll, but what does DCE/DFS buy me now?
With kerberos, pam, ldap and NFSv4 it seems like alternatives are available. And the 90% of computer users in the enterprise needing authentication, directory service on Windows users are getting embraced by AD.
Plus, last time I remember using DCE/DFS about 7 or 8 years ago it was sloooooow.
"Provided by the management for your protection."