The problem with LDAP is that adding the 'L' (lightweight) to the 'DAP' (directory access protocol) removed many features including, most noticably, proper distribution of data over multiple servers and proper chaining of requests.
The reason the university of Michigan created a standalone LDAP server was because 96 or 98% of their requests (I can't remember what the number was exactly) were coming through their LDAP to DAP gateway.
LDAP removed many features including, most noticably, proper distribution of data over multiple servers...It also sets the operational limits of the system to an enterprise/employee rather than a global/customer scale solution.
How is LDAP directory partitioning improper? Subsection of the directory can live on localized sites. Does what I want. Works enough to fit, say, France inside an LDAP dir (France, by the way,. is larger than a single enterprise - it's a country, in Europe - sorry, but there's lots of Americans on this web site). What am I missing?
Proper distribution and request chaining protools would allow Linux systems and MS systems to share a perceived common user data store
Like what I can do now with pam_ldap authenticating against AD, making it a common store for Linux and Windows (even though pam_krb5 is a better way of doing things)?
Or what I can do with PGINA on Windows, or the Novell GINA, against any directory server / NDS?
I don't dispute that DAP may do things that LDAP can't. But you haven't definied what you mean by 'proper distribution of data' means, you're just saying LDAP doesn't do something the way you want. Linux and Windows and OS X and Solaris can share LDAP servers. There are massive global LDAP directories that work very well. More detail, please.
But I digress. My point is that installing and configuring NDS is not hard, but nothing like "soo but soo easy" either (e.g., a far, far cry from "apt-get install slapd").
Enabling SSL is a PITA if you don't have the Netscape Certificate Server (which I didn't). I involves all manner of funky maneuvering with OpenSSL and some tools that you have to fetch from some obscure page at mozilla.org.
It sounds like most of your problems were to do with install and configuration. The install will consist of:
up2date redhat-directory
I'd be surprised if the configuration wasn't either a GTK2 app called 'system-config-directory' or a web based tool (to get an idea of the quality of a Red Hat web based config tool, check out Red Hat Network Satellite).
Asides from Multi master replication (OPenLDAP onyl allows a single master), Netscape directory server solves the 'OpenLDAP being fucking retarded, and holding ACLs to objects in the directory OUTSIDE the directory, therefore replicating objects before their access controls' issue.
How long can it take for package maintainers to update the source and run the package-assembly scripts.
I mean, it is automated, isn't it?
Yea, it's real quick. Within 24 hours, as stated by Chril Ailon.
Mozilla guys are not obligated to wait until the slowest of the crowd gets its job done.
No, but it would be nice if they waited until packages were available before announcing an exploit that be used to break the machines. Its entire possible Red hat could produce a binary (and announce a problem and fix) before Moz does, but they don't - out of courtesy.
The last time Red Hat had notification of a bug at the same time as the Mozilla folks, the packages were updated within 20 minutes (RHEL) to 24 hours (Rawhide).
Actually, Ben Goodger, the Firefox lead, works for Google. And it was developed by both of them. And there's a whole lot of 'work more closely with Google' bugs already in BZ.
(Ignore the above, I used a greater than symbol and/. read it as HTML)
For EVERY distribution?
For most of the popular ones, which would be more than 90% of all Linux users. Probably more - eg, Opera 8 for Debian on PPC has packages.
it's a pain having to decompress an rpm to install it on a non redhat system for instance.
Er, why would you need to decompress it? RPM is the LSB method of installing software on Linux. If you want Debs, though, or unpackaged tarballs, Opera produce that.
So yes, the point remains: Opera give to the ability to install the software properly. Firefox rely on other people do do that.
For most of the popular ones, which would be it's a pain having to decompress an rpm to install it on a non redhat system for instance.
Er, why would you need to decompress it? RPM is the LSB method of installing software on Linux. If you want Debs, though, or unpackaged tarballs, Opera produce that.
So yes, the point remains: Opera give to the ability to install the software properly. Firefox rely on other people do do that.
IE and Firefox merely resize the text on a page, so you've got a tiuny CSS box containing enormous oversize letters that overfill it. The design of the page, and often a lot of the contnt, is lost if you 'zoom' in to much.
Opera has a proper zoom function. You know, like every word processor, spreadsheet, PDF viewer and pretty much every kind of document viewer apart from web browsers have had since the year dot.
I don't use a high res display anymore (I'm back to 1280 x 720 on a projector) so I'm sticking with FF.
But should I ever go back to a high res screen, the only way I'd be be able to properly use the web would be with Opera.
The interesting thing in this case is that it wasn't paid for by "THE PEOPLE" it was paid for by another country.
That's correct. Not many folks from the US are aware of this, but the 'people' who paid for the research are actually holograms, as all Australians are.
Thanks for your insightful post. Mental note: send more troops.
Nice examples. You might want to add mp3, which owes it popularity to source code without a license attached uploaded to the ISO.
Between about 1995 and 1998 a massive user community emerged. Then Fraunhofer Gesselschaft emerged after the silence and wanted $10,000 US per codec-using program (even the OSS ones).
Or Mandrake package repository, or yum server, or a dir full or packages (which up2date can use) or so on. I've done that before, and it works pretty well.
Problem is, the logic about what's going to be installed happens on the clients (fine, you'll have a meta package opn the server descriving client config). And if a change pisses you off, you've got to have a rollback method (okay, you'll code that yourself). A profiling (you'll do that yourself too). And a auto deployment system to create custom kickstart files so you can deploy new machines quickly (yeah, this is starting to look like serious work).
Management Satellite is a centralized web based config and deployment system. Add a few hundred machines to a group, work with a set of groups (ANDed and ORed and so on), create a config profile (perhaps from an existing machine), then change what's in that package/config profile and watch from the web based GUI as the couple of hundred machines make the change happen (using the Jabber protocol). Revert the change.
Boot a clean machine from the network and watch as the distro, all third party software, your custom configuration, and attaching to the Management Satellite server for future config/package changes happen for you. See a new machine on the server added to the group, with it's IBM or Dell or HP asset tag and a bunch of hardware info included so you can use it for asset tracking (there's room for arbitrary notes about each box).
Works with Red Hat Enterprise Linux and Solaris clients.
Slashdot Mirror
The problem with LDAP is that adding the 'L' (lightweight) to the 'DAP' (directory access protocol) removed many features including, most noticably, proper distribution of data over multiple servers and proper chaining of requests.
The reason the university of Michigan created a standalone LDAP server was because 96 or 98% of their requests (I can't remember what the number was exactly) were coming through their LDAP to DAP gateway.
LDAP removed many features including, most noticably, proper distribution of data over multiple servers...It also sets the operational limits of the system to an enterprise/employee rather than a global/customer scale solution.
How is LDAP directory partitioning improper? Subsection of the directory can live on localized sites. Does what I want. Works enough to fit, say, France inside an LDAP dir (France, by the way,. is larger than a single enterprise - it's a country, in Europe - sorry, but there's lots of Americans on this web site). What am I missing?
Proper distribution and request chaining protools would allow Linux systems and MS systems to share a perceived common user data store
Like what I can do now with pam_ldap authenticating against AD, making it a common store for Linux and Windows (even though pam_krb5 is a better way of doing things)?
Or what I can do with PGINA on Windows, or the Novell GINA, against any directory server / NDS?
I don't dispute that DAP may do things that LDAP can't. But you haven't definied what you mean by 'proper distribution of data' means, you're just saying LDAP doesn't do something the way you want. Linux and Windows and OS X and Solaris can share LDAP servers. There are massive global LDAP directories that work very well. More detail, please.
But I digress. My point is that installing and configuring NDS is not hard, but nothing like "soo but soo easy" either (e.g., a far, far cry from "apt-get install slapd").
Enabling SSL is a PITA if you don't have the Netscape Certificate Server (which I didn't). I involves all manner of funky maneuvering with OpenSSL and some tools that you have to fetch from some obscure page at mozilla.org.
It sounds like most of your problems were to do with install and configuration. The install will consist of:
up2date redhat-directory
I'd be surprised if the configuration wasn't either a GTK2 app called 'system-config-directory' or a web based tool (to get an idea of the quality of a Red Hat web based config tool, check out Red Hat Network Satellite).
Red hat paid $20.5 million for this LDAP.
Actually, Red Hat paid 20.5 million for this implementation of LDAP. It's actually the same protocol as everyone else.
Asides from Multi master replication (OPenLDAP onyl allows a single master), Netscape directory server solves the 'OpenLDAP being fucking retarded, and holding ACLs to objects in the directory OUTSIDE the directory, therefore replicating objects before their access controls' issue.
But why would you want to use 20 different languages, when one good one will suffice?
.net as a middleware platform.
Because you need to integrate apps that already exist - hence MS promoting
I'm indeed aware of that. But two or three languages doesn't consititue a wide range of support for the JRE.
Except with about twenty times than languages you cna compile to it's VM, and use functions from.
has full internet access via satellite. His latest project: setting up Skype for phone service
Combining a high latency connection with an app that demands low latency? Good luck.
How long can it take for package maintainers to update the source and run the package-assembly scripts.
I mean, it is automated, isn't it?
Yea, it's real quick. Within 24 hours, as stated by Chril Ailon.
Mozilla guys are not obligated to wait until the slowest of the crowd gets its job done.
No, but it would be nice if they waited until packages were available before announcing an exploit that be used to break the machines. Its entire possible Red hat could produce a binary (and announce a problem and fix) before Moz does, but they don't - out of courtesy.
If they hold on to fixes until all the distros are ready
Which is normally within 24 hours - and even be before moz.org has a tarball out if the distro chose to (and they know about the vuln).
If they release immediately, they get beat up by the distros for not coordinating with them.
And by the users, for making the world aware of an exploit they don't have up2dated packages for yet.
BTW, both sides of this argument are on Mozilla Core, one happens to also work for Red Hat.
If you don't release a fix ASAP then you're knowingly risking the security of peoples computers.
More people used packaged distro software than tarballs. If you don't notify the vendor ASAP you're risking security of people's computers.
The last time Red Hat had notification of a bug at the same time as the Mozilla folks, the packages were updated within 20 minutes (RHEL) to 24 hours (Rawhide).
That ain't a delay in anyone's definition.
Actually, Ben Goodger, the Firefox lead, works for Google. And it was developed by both of them. And there's a whole lot of 'work more closely with Google' bugs already in BZ.
Some idiot on Slashdot thinks otherwise tho.
...the nice user interface with proper tabs for Firefox clients.
Seriously, it's so much nicer than having the page reload when you click another tab. Why doesn't the FF start page use this?
(Ignore the above, I used a greater than symbol and /. read it as HTML)
For EVERY distribution?
For most of the popular ones, which would be more than 90% of all Linux users. Probably more - eg, Opera 8 for Debian on PPC has packages.
it's a pain having to decompress an rpm to install it on a non redhat system for instance.
Er, why would you need to decompress it? RPM is the LSB method of installing software on Linux. If you want Debs, though, or unpackaged tarballs, Opera produce that.
So yes, the point remains: Opera give to the ability to install the software properly. Firefox rely on other people do do that.
For most of the popular ones, which would be it's a pain having to decompress an rpm to install it on a non redhat system for instance.
Er, why would you need to decompress it? RPM is the LSB method of installing software on Linux. If you want Debs, though, or unpackaged tarballs, Opera produce that.
So yes, the point remains: Opera give to the ability to install the software properly. Firefox rely on other people do do that.
It's actually a cinch for any browser to replace IE. Just make an ActiveX component with the same API as MSHTML.
Mozilla already did it with the Mozilla ActiveX control.
IE is available for many other common desktop platforms too, like Solaris on Sparc, and HPUX.
Also Opera announce a release when they have proper packages available for each distribution, rather than just a tarball like Firefox does.
Waiting, or packaging FF yourself, gets a little old after a while.
IE and Firefox merely resize the text on a page, so you've got a tiuny CSS box containing enormous oversize letters that overfill it. The design of the page, and often a lot of the contnt, is lost if you 'zoom' in to much.
Opera has a proper zoom function. You know, like every word processor, spreadsheet, PDF viewer and pretty much every kind of document viewer apart from web browsers have had since the year dot.
I don't use a high res display anymore (I'm back to 1280 x 720 on a projector) so I'm sticking with FF.
But should I ever go back to a high res screen, the only way I'd be be able to properly use the web would be with Opera.
The interesting thing in this case is that it wasn't paid for by "THE PEOPLE" it was paid for by another country.
That's correct. Not many folks from the US are aware of this, but the 'people' who paid for the research are actually holograms, as all Australians are.
Thanks for your insightful post. Mental note: send more troops.
I wrote:
Then Fraunhofer Gesselschaft emerged after the silence and wanted $10,000 US per codec-using program (even the OSS ones).
Then you wrote:
frauhofer has never, ever, EVER charged for software decoders.
So you agree they've charged for encoders, but not decoders?
How the fuck is that 'flat out untrue'? Sounds a little more like 'not quite correct' you antosocial moron.
Nice examples. You might want to add mp3, which owes it popularity to source code without a license attached uploaded to the ISO.
Between about 1995 and 1998 a massive user community emerged. Then Fraunhofer Gesselschaft emerged after the silence and wanted $10,000 US per codec-using program (even the OSS ones).
Or Mandrake package repository, or yum server, or a dir full or packages (which up2date can use) or so on. I've done that before, and it works pretty well.
Problem is, the logic about what's going to be installed happens on the clients (fine, you'll have a meta package opn the server descriving client config). And if a change pisses you off, you've got to have a rollback method (okay, you'll code that yourself). A profiling (you'll do that yourself too). And a auto deployment system to create custom kickstart files so you can deploy new machines quickly (yeah, this is starting to look like serious work).
Management Satellite is a centralized web based config and deployment system. Add a few hundred machines to a group, work with a set of groups (ANDed and ORed and so on), create a config profile (perhaps from an existing machine), then change what's in that package/config profile and watch from the web based GUI as the couple of hundred machines make the change happen (using the Jabber protocol). Revert the change.
Boot a clean machine from the network and watch as the distro, all third party software, your custom configuration, and attaching to the Management Satellite server for future config/package changes happen for you. See a new machine on the server added to the group, with it's IBM or Dell or HP asset tag and a bunch of hardware info included so you can use it for asset tracking (there's room for arbitrary notes about each box).
Works with Red Hat Enterprise Linux and Solaris clients.
http://www.redhat.com/software/rhn/provisioning/
So when did you stop beating your wife?