Here, I'll explain it to you: Novell used to have this flagship product called NetWare Directory Services [NDS]. Then Novell Marketing renamed it to Novell Directory Services [still NDS]. Then Novell Marketing renamed it to eDirectory [no longer "NDS," and with no apparent acronym]. Then they renamed the whole shebang to "Ngage, exteNd, Nsure, and Nterprise". No one has a clue what any of those things mean. By the way, this is the home page for Ngage.
So here's the joke: Novell, proud new owners of Ximian and SuSE, and brave, stalwart defenders of the System V trademark against the diabolical Santa Cruz Operation, is the object of Linux fanboy passion [albeit fleeting] the world over, and, as above, their flagship product has been renamed "Ngage" [in a move that nobody understands]. The great-grandparent post was about a product called "N-Gage," but of course none of the/. Linux fanboys thought of Novell when they heard the term "N-Gage" - instead they thought immediately of Nokia.
Well, like I said, that's the joke. I guess you'd have to be an old MCNE/MCNI like me to have gotten it, but that's okay: Goodness knows there aren't many of us left any more, so you young whippersnappers are forgiven. Enjoy your blissful ignorance while you can, and then watch Novell Marketing drive yet another industry leading product into utter oblivion and irrelevance.
Let me guess: you're in the US Army and you are just trying to start this rumor in the hopes that you get relocated out of Iraq to the beautiful beaches of Spain, right?
Those would be the beautiful beaches of Andalusia, infidel swine!
Innovators Rule - Provided they can outlast the drain on their development dollars and recoup the investment. I think Iridium was a good test for that. The people that bought them out for 10 cents on the dollar are making a killing now.
I know this ain't the politically correct thing to say on/., but:
Innovators Rule - Provided
there is a system of patent law, copyright law, and trade secrets law to protect their innovations.
Without those legal protections, the intellectual property of innovators is essentially worthless.
Group Policy allows you to override permissions onto NTFS objects, registry keys, and even Active Directory objects. GPOs are stored in Active Directory.
Yikes! When did that come out? Is it stable?
I know that Novell has always resisted the temptation to move file permissions out of the NetWare file system and into Novell Directory Services simply because the file system permission structure is so massive and would bog down the directory tremendously. [You usually get just a single file system volume object in the NDS tree, but I've never seen NDS overrides of local file system permissions.]
And Novell has dynamic inheritance of both file system permissions and directory permissions; I can only imagine what a ghastly mess this would be in the Microsoft world where both NTFS and Active Directory are crippled by static permisssions.
Hibernate is years ahead of ObjectSpaces. Even some beta.NET ORM's are way ahead of ObjectSpaces. For examples, Thona's Entity Broker is already more robust. ObjectSpaces will only work with SQLServer at first (that's what MS says - they never say when it will work with other DBMS's). Spring is really powerful. It's a little complex at first, but once you understand the concepts behind it, it's really cool to use. Add Tapestry for the web tier and you can easily write powerful web apps that are easy to maintain, modify and extend, without getting into the ugly J2EE stuff like (yuk!) entity beans.
Please go easy on me even if these questions seem a little too neophyte-ish:
1) Are any of these products fully 64-bit, i.e. don't require 32-bit middleware, like Java, or 32-bit backends, like SQL BLOBs?
2) Are any of these products ready for primetime, i.e. in addition to being stable and secure, also offer, at a bare minimum:
a) master/slave failsafe mirroring of all data [if not peer-to-peer mirroring of data],
b) seamless support for a security infrastructure, such as Microsoft Active Directory, or Novell Directory Services, and
c) stable integration with a backup product, such as Veritas [Seagate] Backup Exec, or Computer Associates [Cheyenne] ArcServe?
At this point, I'm looking for ANY advice I can get my greedy little paws on.
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!?
Why implement this at the hardware level, besides "making windows more secure"?
Everyone and his brother has heard of the old Motorola 68000 series [it powered the old Macs, and Jobs used the 68040 to power his NeXTSTATIONs and NeXTCUBEs], but Motorola had a very obscure successor to the 68000-series, called the 88000-series, which had a non-von Neumannian Harvard architecture, i.e. it separated the machine code and the data code into two separate physical locations.
Data General built some old multi-processing AViiONs on 88000-series hardware in the late eighties/early nineties time frame; every so often you'll see one for sale on eBay.
Just goes to show that technological leadership is never any guarantee of marketplace leadership - x86 hardware is only now getting some of the features that Data General and Motorola were peddling [without much success] about fifteen years ago.
PS: A number of the guys at Data General who had worked on the gcc 88000-series port ended up over at Red Hat & Cygwin.
The ["scientific"] data we're generating is very large, and much more binary/object-ish than ASCII/SQL/RDBM-ish in nature.
CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
public class SixtyFourBit
{
public static void main (String args[])
{
long theLong = 1;
theLong <<= 32;
theLong += 1;
System.out.println("theLong = " + theLong);
double [] theDoubleArray = new double[theLong];
}
}
SixtyFourBit.java:11: possible loss of precision
found : long
required: int
Any advice as to 64-bit object-oriented databases would be MOST appreciated.
Thanks!
You're right: (May 5, 2005) = (May 5, 2004);
on
Google IPO Swami
·
· Score: 1
Sorry about that.
The un-PC point of view in re: Google IPO
on
Google IPO Swami
·
· Score: 5, Funny
I submitted this a while back, and it was predictably rejected, but if you really care about the Google IPO, take a gander at this article:
The Bear's Lair: The Google gross-out
Martin Hutchinson
UNITED PRESS INTERNATIONAL
May 5, 2005
...This is all just an everyday story of tech company greed, of course -- it makes you pity the poor fools who buy the issue on a $25 billion valuation (unless they're lucky enough to sell out fast to even greater -- and soon poorer -- fools.) Of course, their chances of selling out for a quick profit, usually pretty good in a tech sector IPO, are negated in this one because Google has chosen to throw out nearly 300 years of equity market wisdom (the South Sea Bubble share issues in 1720 were done the Wall Street way, and not Google's way) and offer shares by means of a "Dutch auction"...
Indeed, there's something uniquely unpleasant in the hippie rhetoric with which Google surrounds its activities. "We aspire to make Google an institution that makes the world a better place" we are told in the early part of the S-1 statement (the only part that many journalists appear to have read!) "Google is not a conventional company"... and, in an inspired moment of Bill-and-Ted-speak "Don't be evil.."
"Don't try to create new algorithms. We know how to do that already. What we have is secure. What you need to work on is the implementation. Just because something uses encryption, it is by no means secure."
I hope you've misquoted him.
Personally, I know of no provably secure means of encryption and decryption [de-encryption]. I know that it is widely believed [although I don't know whether an infrastructure is in place within which it could be proved] that one time pads are secure, but I don't know of anyone who's proposed a way secure means for the distribution of one-time pads, and, for that matter, there's a rather old and rather contentious controversy as to whether one-time pads can even exist in the first place [Google on God does not play dice with the universe].
As for the standard encryption and authentication techniques, to the best of my knowledge, it is still an open question as to whether there are holes in Rivest-Shamir-Adleman; specifically, to the best of my knowledge, it is an open question as to whether third-party decryption of Rivest-Shamir-Adleman is as hard as the factorization problem itself.
So anyone who says "What we have is secure" is either incompetent to practice in the field [which, I suppose, does not necessarily determine the competency to teach about the field] or has been misquoted.
To the contrary, anyone who is honest about the state of affairs within the community of encryption artists will tell you, "We have a collection of algorithms that are widely believed to be secure, but I can no more prove to you that they are secure than I can, for instance, offer you a proof of The Existence*."
[*FYI: It is a little-known fact that Kurt Gödel believed he was in the possession of a proof of The Existence towards the end of his career...]
What I was basically getting at was the fact LDAP and/or Kerberos were the technologies that would overcome his problems, regardless of who the vendor of said technologies are.
But again, "LDAP and/or Kerberos" are just ideas. Microsoft has an implementation of these ideas, called "Active Directory." Sun has an older implementation of these ideas, called "Yellow Pages," and a newer implementation, called "iPlanet." A now defunct company, called "Banyon," had an implementation of these ideas, called "Vines."
Point is, sooner or later, you've got to choose an implementation, and, once you go to look at the various implementations that are on the market, you'll quickly find that the implementation that's the oldest, the most stable, the most secure, and the most flexible, with the best support in the industry, is probably gonna be Novell's.
I'm open to suggestions that somebody else has an older, more stable, more secure, more flexible implementation, with better support than Novell's, but you're gonna hafta offer a heckuva lotta evidence in support of that thesis before I become a believer.
Novell Directory Services is an implementation of these sorts of ideas which has about a 15 year track record [used to be called 'NetWare Naming Services' back in the NetWare 3.x days], and for easily the last ten of those years, it's been a stable, rock-solid, enterprise platform in mission-critical environments [not to mention the fact that it's withstood pretty much every attempt to crack it].
Now you could certainly roll your own home-brew implementation of Kerberos & LDAP, but I'm willing to bet that by the time you've got ol' homebrew stable and resistant to cracking [remember, we're talking THREE HUNDRED servers here, and gosh only knows how many clients], you would have saved a small fortune by purchasing the pre-packaged product that Novell has spent the last 15 years perfecting.
Oops, that's three words. Try "eDirectory" instead.
No, wait a second - I seem to recall that Novell marketing renamed it yet again - now it's called either Ngage, exteNd, Nsure, or Nterprise - not sure which.
Frankly, I'm not even sure the people at Novell know what it's called anymore.
Maybe we should moderate Redmond "+1 Has a Clue" simply for fielding a marketing team that knows its ass from a hole in the ground...
Relational database theory in no way prevents you from having any types you like in the database (current maintainers of the academic theory would point out that "object/relational" databases are just relational databases working the way they should.)
Except for one thing: SQL [like Java] is a 32-bit language!!!
SQL BLOBs are 32-bit entities!
Java arrays are 32-bit entities!
WE NEED 64-BIT DATA TYPES AND 64-BIT PROGRAMMING LANGUAGES!!!
Personally, I think databases are going to wind up absorbing application servers like J2EE containers and will eventually look like a relational/object hybrid with interfaces to various protocols and container environments.
Does anyone have any experience with Microsoft's new ObjectSpaces persistent object initiative for.NET? Some overview here:
The ["scientific"] data we're generating is very large, and much more binary/object-ish than ASCII/SQL/RDBM-ish in nature.
CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
public class SixtyFourBit
{
public static void main (String args[])
{
long theLong = 1;
theLong <<= 32;
theLong += 1;
System.out.println("theLong = " + theLong);
double [] theDoubleArray = new double[theLong];
}
}
SixtyFourBit.java:11: possible loss of precision
found : long
required: int
the white wire and the bare wire are connected to the same mount in your circuit breaker box
A few years ago, there was a change in the code, which now requires white and ground to be anchored to two different mounts, but in almost all existing construction, that won't be the case.
Actually, among people who care about these sorts of things [and there are precious few in this business who give a damn], lightning rods, and, more generally, good grounding, are enormously controversial.
Classically, the thinking was that a well grounded lightning rod served to divert voltage surges away from the interior of your structure and down to the groundwater, or, more specifically, to the ionized particles suspended in moist soil. [Oh, and, by the way, once the surge makes it to "groundwater," there's no guarantee it'll stay there; it's entirely possible that it'll decide it doesn't like groundwater and find an alternate route back into your structure. These phenomena generally fall under the title of "grounding loops."]
However, there's a new school of thought which holds that a well-grounded lightning rod serves to ATTRACT voltage surges, and could cause a voltage surge to get nearer to your structure than would otherwise be the case. If you follow that approach, you want safety in numbers: You hope that there are enough targets out there that are well enough grounded that the voltage surge will be diverted towards them, rather than towards you.
If you're interested in residential and light-commercial products, I can highly recommend the surge protectors of Panamax; in particulary, we've had a lot of luck with their Max 8 Coax product shielding broadband over coaxial cable:
The Panamax products tend to work interior to a building. [By the way, as far as interior wiring is concerned, did you know that in three-color wiring, the white wire and the bare wire are connected to the same mount in your circuit breaker box? I.e., once you get inside a building, white and ground are one & the same.] For products exterior to a building, I'd take a look at Citel, of Miami, FL [especially their P8AX series for coaxial cable lines, although they have myriad products for POTS and CAT5, as well]:
Slashdot Mirror
Dude, N-Gage is Nokia [nokia.com] not Novell.
Dude, it was a joke.
Here, I'll explain it to you: Novell used to have this flagship product called NetWare Directory Services [NDS]. Then Novell Marketing renamed it to Novell Directory Services [still NDS]. Then Novell Marketing renamed it to eDirectory [no longer "NDS," and with no apparent acronym]. Then they renamed the whole shebang to "Ngage, exteNd, Nsure, and Nterprise". No one has a clue what any of those things mean. By the way, this is the home page for Ngage.
So here's the joke: Novell, proud new owners of Ximian and SuSE, and brave, stalwart defenders of the System V trademark against the diabolical Santa Cruz Operation, is the object of Linux fanboy passion [albeit fleeting] the world over, and, as above, their flagship product has been renamed "Ngage" [in a move that nobody understands]. The great-grandparent post was about a product called "N-Gage," but of course none of the /. Linux fanboys thought of Novell when they heard the term "N-Gage" - instead they thought immediately of Nokia.
Well, like I said, that's the joke. I guess you'd have to be an old MCNE/MCNI like me to have gotten it, but that's okay: Goodness knows there aren't many of us left any more, so you young whippersnappers are forgiven. Enjoy your blissful ignorance while you can, and then watch Novell Marketing drive yet another industry leading product into utter oblivion and irrelevance.
I mean, geez, there are still N-Gage commercials on TV.
Sometimes you just get the feeling that Novell marketing couldn't market their way out of a paper bag if you gave them a pair of scissors.
de Raadt might just be fanatacizing himself out of existence.
When I use a public, non-WEP hotspot, all I ever do is SSL to my command-line account and run pine or some such.
Let's just say that Pine doesn't have the most stellar security record:
Let me guess: you're in the US Army and you are just trying to start this rumor in the hopes that you get relocated out of Iraq to the beautiful beaches of Spain, right?
Those would be the beautiful beaches of Andalusia, infidel swine!
Innovators Rule - Provided they can outlast the drain on their development dollars and recoup the investment. I think Iridium was a good test for that. The people that bought them out for 10 cents on the dollar are making a killing now.
I know this ain't the politically correct thing to say on /., but:
Without those legal protections, the intellectual property of innovators is essentially worthless.Fred is looking pretty hot as the blue chick.
Shame it's been cancelled.
And what's up with this Stargate Atlantis?
Group Policy allows you to override permissions onto NTFS objects, registry keys, and even Active Directory objects. GPOs are stored in Active Directory.
Yikes! When did that come out? Is it stable?
I know that Novell has always resisted the temptation to move file permissions out of the NetWare file system and into Novell Directory Services simply because the file system permission structure is so massive and would bog down the directory tremendously. [You usually get just a single file system volume object in the NDS tree, but I've never seen NDS overrides of local file system permissions.]
And Novell has dynamic inheritance of both file system permissions and directory permissions; I can only imagine what a ghastly mess this would be in the Microsoft world where both NTFS and Active Directory are crippled by static permisssions.
Anybody have any experience with this stuff?
Hibernate is years ahead of ObjectSpaces. Even some beta
Please go easy on me even if these questions seem a little too neophyte-ish:
At this point, I'm looking for ANY advice I can get my greedy little paws on.Thanks again!
Upon rebooting, file permissions would be reset from the Active Directory database- and I'd expect exactly this kind of behavior.
Uhh, just exactly when did Microsoft move file system rights out of NTFS and into Active Directory?
If that's true, then boy, do I feel like Rip Van Winkle...
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!? Why implement this at the hardware level, besides "making windows more secure"?
Everyone and his brother has heard of the old Motorola 68000 series [it powered the old Macs, and Jobs used the 68040 to power his NeXTSTATIONs and NeXTCUBEs], but Motorola had a very obscure successor to the 68000-series, called the 88000-series, which had a non-von Neumannian Harvard architecture, i.e. it separated the machine code and the data code into two separate physical locations.
Data General built some old multi-processing AViiONs on 88000-series hardware in the late eighties/early nineties time frame; every so often you'll see one for sale on eBay.
Just goes to show that technological leadership is never any guarantee of marketplace leadership - x86 hardware is only now getting some of the features that Data General and Motorola were peddling [without much success] about fifteen years ago.
PS: A number of the guys at Data General who had worked on the gcc 88000-series port ended up over at Red Hat & Cygwin.
CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
} Any advice as to 64-bit object-oriented databases would be MOST appreciated.Thanks!
Sorry about that.
I submitted this a while back, and it was predictably rejected, but if you really care about the Google IPO, take a gander at this article:
Sorry, I seem to have a mild case Fourier analysis on the brain.
"Don't try to create new algorithms. We know how to do that already. What we have is secure. What you need to work on is the implementation. Just because something uses encryption, it is by no means secure."
I hope you've misquoted him.
Personally, I know of no provably secure means of encryption and decryption [de-encryption]. I know that it is widely believed [although I don't know whether an infrastructure is in place within which it could be proved] that one time pads are secure, but I don't know of anyone who's proposed a way secure means for the distribution of one-time pads, and, for that matter, there's a rather old and rather contentious controversy as to whether one-time pads can even exist in the first place [Google on God does not play dice with the universe].
As for the standard encryption and authentication techniques, to the best of my knowledge, it is still an open question as to whether there are holes in Rivest-Shamir-Adleman; specifically, to the best of my knowledge, it is an open question as to whether third-party decryption of Rivest-Shamir-Adleman is as hard as the factorization problem itself.
And even if you assume that third-party decryption of Rivest-Shamir-Adleman is as hard as factorization, it is still, to the best of my knowledge, an open question as to whether factorization is a hard problem, at least on classical Tukey/von Neumann machines. [It is known that factorization is not necessarily a hard problem on a class of theoretical machines which do not yet exist in practice.]
So anyone who says "What we have is secure" is either incompetent to practice in the field [which, I suppose, does not necessarily determine the competency to teach about the field] or has been misquoted.
To the contrary, anyone who is honest about the state of affairs within the community of encryption artists will tell you, "We have a collection of algorithms that are widely believed to be secure, but I can no more prove to you that they are secure than I can, for instance, offer you a proof of The Existence*."
[*FYI: It is a little-known fact that Kurt Gödel believed he was in the possession of a proof of The Existence towards the end of his career...]
What I was basically getting at was the fact LDAP and/or Kerberos were the technologies that would overcome his problems, regardless of who the vendor of said technologies are.
But again, "LDAP and/or Kerberos" are just ideas. Microsoft has an implementation of these ideas, called "Active Directory." Sun has an older implementation of these ideas, called "Yellow Pages," and a newer implementation, called "iPlanet." A now defunct company, called "Banyon," had an implementation of these ideas, called "Vines."
Point is, sooner or later, you've got to choose an implementation, and, once you go to look at the various implementations that are on the market, you'll quickly find that the implementation that's the oldest, the most stable, the most secure, and the most flexible, with the best support in the industry, is probably gonna be Novell's.
I'm open to suggestions that somebody else has an older, more stable, more secure, more flexible implementation, with better support than Novell's, but you're gonna hafta offer a heckuva lotta evidence in support of that thesis before I become a believer.
Novell Directory Services is an implementation of these sorts of ideas which has about a 15 year track record [used to be called 'NetWare Naming Services' back in the NetWare 3.x days], and for easily the last ten of those years, it's been a stable, rock-solid, enterprise platform in mission-critical environments [not to mention the fact that it's withstood pretty much every attempt to crack it].
Now you could certainly roll your own home-brew implementation of Kerberos & LDAP, but I'm willing to bet that by the time you've got ol' homebrew stable and resistant to cracking [remember, we're talking THREE HUNDRED servers here, and gosh only knows how many clients], you would have saved a small fortune by purchasing the pre-packaged product that Novell has spent the last 15 years perfecting.
Novell Directory Service.
Oops, that's three words. Try "eDirectory" instead.
No, wait a second - I seem to recall that Novell marketing renamed it yet again - now it's called either Ngage, exteNd, Nsure, or Nterprise - not sure which.
Frankly, I'm not even sure the people at Novell know what it's called anymore.
Maybe we should moderate Redmond "+1 Has a Clue" simply for fielding a marketing team that knows its ass from a hole in the ground...
I mean, be for real - who gives a damn about the article?
Relational database theory in no way prevents you from having any types you like in the database (current maintainers of the academic theory would point out that "object/relational" databases are just relational databases working the way they should.)
Except for one thing: SQL [like Java] is a 32-bit language!!!
SQL BLOBs are 32-bit entities!
Java arrays are 32-bit entities!
WE NEED 64-BIT DATA TYPES AND 64-BIT PROGRAMMING LANGUAGES!!!
Personally, I think databases are going to wind up absorbing application servers like J2EE containers and will eventually look like a relational/object hybrid with interfaces to various protocols and container environments.
Does anyone have any experience with Microsoft's new ObjectSpaces persistent object initiative for .NET? Some overview here:
The ["scientific"] data we're generating is very large, and much more binary/object-ish than ASCII/SQL/RDBM-ish in nature.CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
}the white wire and the bare wire are connected to the same mount in your circuit breaker box
A few years ago, there was a change in the code, which now requires white and ground to be anchored to two different mounts, but in almost all existing construction, that won't be the case.
Two words, lightning rod.
Actually, among people who care about these sorts of things [and there are precious few in this business who give a damn], lightning rods, and, more generally, good grounding, are enormously controversial.
Classically, the thinking was that a well grounded lightning rod served to divert voltage surges away from the interior of your structure and down to the groundwater, or, more specifically, to the ionized particles suspended in moist soil. [Oh, and, by the way, once the surge makes it to "groundwater," there's no guarantee it'll stay there; it's entirely possible that it'll decide it doesn't like groundwater and find an alternate route back into your structure. These phenomena generally fall under the title of "grounding loops."]
However, there's a new school of thought which holds that a well-grounded lightning rod serves to ATTRACT voltage surges, and could cause a voltage surge to get nearer to your structure than would otherwise be the case. If you follow that approach, you want safety in numbers: You hope that there are enough targets out there that are well enough grounded that the voltage surge will be diverted towards them, rather than towards you.
If you're interested in residential and light-commercial products, I can highly recommend the surge protectors of Panamax; in particulary, we've had a lot of luck with their Max 8 Coax product shielding broadband over coaxial cable:
The Panamax products tend to work interior to a building. [By the way, as far as interior wiring is concerned, did you know that in three-color wiring, the white wire and the bare wire are connected to the same mount in your circuit breaker box? I.e., once you get inside a building, white and ground are one & the same.] For products exterior to a building, I'd take a look at Citel, of Miami, FL [especially their P8AX series for coaxial cable lines, although they have myriad products for POTS and CAT5, as well]:All of the material at that site credits one Zoë Wood as a co-authoress.
images.google.com served up this:
and this: Yowza!!! Somebody needs to introduce me to that chick.