Re: Windows-like registry for Linux?
My cow-orker (from the Windows side of the company and maybe transitioning to Linux) thanks y'all for the feedback and is impressed with the GNHLUG. Same here. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Oracle buys Open Source vendors, was: Windows-like registry for Linux?
On Feb 15, 2006, at 11:35, Ted Roche wrote: Yeah, what's up with that? InnoDB last year and now Sleepycat. I've done a few development projects with Oracle 8 and 9, but I'm not well-informed on how they work. I understand Oracle buys a fair number of small software companies. Is this like CA, who absorbs and smothers? Oracle usually buys market segments and mindshare. So they bought PeopleSoft because it competed with Oracle's product. They've bought Clinical Trials companies because they were competitors. They bought Corporate Time because they didn't have an Exchange competitor. They exhibit the positive and negative aspects of The Borg in this regard. What do you think they are up to? I don't know. I don't think they do either. But people who say, "Why would I use Oracle when I can use MySQL with InnoDB?," or, "I don't need Oracle, I have BerkeleyDB," get to say they're Oracle customers now. Or vice-versa. Which is probably well worth the acquisition price of either company to Larry. I bet it's to shut up some Wall Street analyst. If I had to guess, their next acquisition will be Greenplum, which makes a commercial extension to PostgreSQL which competes favorably with Oracle RAC. Since it's not open source yet, now's a great time to keep it that way. Live by the BSD license, die by the BSD license. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Oracle buys Open Source vendors, was: Windows-like registry for Linux?
On Feb 15, 2006, at 11:15 AM, Bill McGonigle wrote: I do find it curious that Oracle is buying up the commercial DB backends that are used in F/LOSS. Yeah, what's up with that? InnoDB last year and now Sleepycat. I've done a few development projects with Oracle 8 and 9, but I'm not well- informed on how they work. I understand Oracle buys a fair number of small software companies. Is this like CA, who absorbs and smothers? What do you think they are up to? Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Incidently, if you're looking for a very fast way to prototype such use
of a DB (or even to deploy for real...), I recommend Perl, which has
always had good support for this type of thing:
#!/usr/bin/perl -w
use strict;
use DB_File;
my(%favorite_color);
tie(%favorite_color, "DB_File", "favcolordb")
|| die "tie problem: $!";
$favorite_color{"moe"} = "red";
$favorite_color{"larry"} = "green";
$favorite_color{"curly"} = "blue";
untie(%favorite_color)
|| die "untie problem: $!";
__END__
Regards,
--kevin
--
GnuPG ID: B280F24E
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Feb 15, 2006, at 08:05, Jerry Feldman wrote: But, I do think the GDBM or Berkeley DB are good choices. It's worth noting that the Berkeley DB evolves quickly and new versions are often not backwards compatible with old databases and I've been unable due to dependencies to compile old versions of BerkeleyDB on newer linux distros. I've been stung a few times by this, especially where BerkeleyDB was used in e.g. mail servers, during upgrades. If one is going for an embedded app never to be adminned by the world, that's fine. If the goal is to put out a product and gdbm is fast enough (it's slower than some of Berkeley's storage modes) then by all means look at that. I do find it curious that Oracle is buying up the commercial DB backends that are used in F/LOSS. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Wednesday 15 February 2006 09:11 am, Paul Lussier wrote: > > I guess I'm a little idealistic - I'd love to see LDAP more > > mainstream because it really does a lot of things really well, > > Like what? It's got a horrendous schema architecture, it's not easy > to configure, insert data, access data, etc. Like a listing of data that updates rarely but is needed for quick querying. Like any type of data like this that can be arranged/organized hierarchically. The schema architecture makes a lot of sense for directory purposes and while it's a little complicated at first, a good book and a good how-to online can clear up that hurdle. Configuring it really only requires a prerequisite knowledge of how you want to use it and inserting/accessing data has never struck me as the least bit confusing. > It does a lousy job of managing relational data. It's not a relational DBMS. It isn't meant to be. I thought this conversation was about a registry-type of storage mechanism and the registry is a perfect example a data store that is not relational in nature (whether or not it's a good idea is another question, but it really doesn't make sense for it to be relational). > In that case, it's really nothing more than a network accessible front > end for BDB. But it's not BDB that's the problem, it's the LDAP > architecture. That's what said about "network-accessible BDB" and exactly what I mean about re-inventing the wheel. Why program a new interface for a network accessible, hierarchical datastore based on BDB (or any other backend) when that's what LDAP was designed for? -Neil ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Neil Joseph Schelly <[EMAIL PROTECTED]> writes: > On Tuesday 14 February 2006 10:43 pm, Paul Lussier wrote: >> Neil Schelly <[EMAIL PROTECTED]> writes: >> > Just a thought, but how about an LDAP schema to support your options and >> > an LDAP server to do the backend. They were designed to be exactly: >> >> IMO, LDAP is almost never the right answer, regardless of the question :) > > > I guess I'm a little idealistic - I'd love to see LDAP more > mainstream because it really does a lot of things really well, Like what? It's got a horrendous schema architecture, it's not easy to configure, insert data, access data, etc. It does a lousy job of managing relational data. About the thing it's good for is connecting to with a client that already support it. In almost all cases, I think it would be better to have clients access a relational db, had they been designed to do so. LDAP was a paired down version of something already grown out of control. > if not for lack of support in some ways. That said, it's not much > different than BDB if you're using a BDB backend I suppose. In that case, it's really nothing more than a network accessible front end for BDB. But it's not BDB that's the problem, it's the LDAP architecture. > For this purpose though, it sounds like the request is for a > network-accessible BDB database. OpenLDAP can be that, with full > access control abilities already integrated, fun admin tools like > phpLDAPAdmin, etc. No need to reinvent the wheel I was > thinking... Not re-inventing the wheel is a good thing, using one with 4 corners is :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 10:46 pm, Paul Lussier wrote: > Think if BerkeleyDB more as an on-disk hash than a RDBMS like > PostgreSQL or Oracle. It's extremely flexible (the subversion project > has managed to coerce a file system into it :) and very fast. Check out: > > http://www.sleepycat.com - the makers of BerkelyDB. Both gdbm (GNU DBM) and Berkeley DB are available on some Linux distros. In any case, I think the issue comes down to: How much data is to be populated. What the organization is going to be. Both gdbm and Berkeley DB would probably work better than the Windows Registry, and with Berkeley you have a bit more flexibility. But, if we are talking about a relatively small amount of data that can be managed live in memory, then a shared memory approach is generally faster. But, I do think the GDBM or Berkeley DB are good choices. -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 10:43 pm, Paul Lussier wrote: > Neil Schelly <[EMAIL PROTECTED]> writes: > > Just a thought, but how about an LDAP schema to support your options and > > an LDAP server to do the backend. They were designed to be exactly: > > IMO, LDAP is almost never the right answer, regardless of the question :) I guess I'm a little idealistic - I'd love to see LDAP more mainstream because it really does a lot of things really well, if not for lack of support in some ways. That said, it's not much different than BDB if you're using a BDB backend I suppose. For this purpose though, it sounds like the request is for a network-accessible BDB database. OpenLDAP can be that, with full access control abilities already integrated, fun admin tools like phpLDAPAdmin, etc. No need to reinvent the wheel I was thinking... -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
"Michael ODonnell" <[EMAIL PROTECTED]> writes: >>I would suggest Berkeley DB. > > > Cool. Thanks. Not that I have actual knowledge of > the subject, but I picture a DB engine as a somewhat > ponderous thang. Think if BerkeleyDB more as an on-disk hash than a RDBMS like PostgreSQL or Oracle. It's extremely flexible (the subversion project has managed to coerce a file system into it :) and very fast. Check out: http://www.sleepycat.com - the makers of BerkelyDB. Which just informed me that they've been acquired by Oracle! :( -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Neil Schelly <[EMAIL PROTECTED]> writes: > Just a thought, but how about an LDAP schema to support your options and an > LDAP server to do the backend. They were designed to be exactly: IMO, LDAP is almost never the right answer, regardless of the question :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 3:50 pm, Steven W. Orr wrote: > > Right. socketpair is not the answer. It's just part of a proper > architectural approach. What I'm suggesting is that a single server gets > designed to access the data, maybe even using mmap or whatever else you > want to use. Then that server would accept connections from arbitrary > clients. The clients connect using the socketpair trick and then a > mini-language would be used to tell the server what it is that the client > wants. That way access is confined to one process (the server), runtime > overhead is confined to one process (the server), and the client ends up > stoopider and simpler. I would agree here as long as there is an approach in the client to do something if the server is not running. It really comes down to what data needs to be stored, how and where. The in-memory approach is generally much faster than the database approach. The advantage of a single server approach is that only it needs to know the storage method, so if you start with a simple linear search of some shared data (whether it is multiple threads sharing data within a process, or multiple processes sharing data allocated by the server), when you want to change from a linear to a better search algorithm, only the server code needs to change. The client needs only to know how to communicate with the server, and that depends a bit on what IPC method that is desired. The problem I have with socketpair() is that it assumes a parent-child relationship. In the case Michael described, my assumption is that the clients could be independent of eachother. But the use of sockets is probably a decent approach. -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday, Feb 14th 2006 at 15:18 -0500, quoth Jerry Feldman: =>On Tuesday 14 February 2006 2:46 pm, Steven W. Orr wrote: =>> Jerry, I'll disagree with you on this one. Use of System V ipc is highly =>> deprecated. I did a big project back in '90 that was a heavy user of =>> semaphores and msgqueues. It was the right thing to do back then but =>> today it's dead wrong. Today, if you are writing interprocess =>> communication within one machine, you should look at the socketpair call. =>> (Under SVR4 we used something called STREAMS pipes which provided =>> similiar =>> functionality.) The idea is to write one process to be the keeper of the =>> holy data and to make him a server process that people can connect to =>> using socketpair. It's sort of like a pipe that is allowed to be used to =>> connect two unrelated processes. One of the things about ipcs is the =>> error recovery needed to ensure they work properly. e.g., I have a msgq =>> that has a limit of X nr of messages. What are the clients supposed to do =>> if the enqueue fails? All of those class of problems go away if you use =>> the correct architecture. =>I have no qualms on this, but I also don't think that socketpair(2) is the =>answer per se., but the issue is more in the detail. If all that is needed =>is a common lookup table and a place to register a service, then possibly =>mmap(2) in combination with socketpair(2) and some of the other socket =>oriented calls would work fine. Possibly even fifos. I'm advocating more =>of an in-memory approach rather than a database approach. Right. socketpair is not the answer. It's just part of a proper architectural approach. What I'm suggesting is that a single server gets designed to access the data, maybe even using mmap or whatever else you want to use. Then that server would accept connections from arbitrary clients. The clients connect using the socketpair trick and then a mini-language would be used to tell the server what it is that the client wants. That way access is confined to one process (the server), runtime overhead is confined to one process (the server), and the client ends up stoopider and simpler. Fifos are almost to be avoided more than SVR4 ipcs just because of how problematic the rendezvous is. You almost need a socketpair based server to tell the two processes which fifo to use. ;-) -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 2:46 pm, Steven W. Orr wrote: > Jerry, I'll disagree with you on this one. Use of System V ipc is highly > deprecated. I did a big project back in '90 that was a heavy user of > semaphores and msgqueues. It was the right thing to do back then but > today it's dead wrong. Today, if you are writing interprocess > communication within one machine, you should look at the socketpair call. > (Under SVR4 we used something called STREAMS pipes which provided > similiar > functionality.) The idea is to write one process to be the keeper of the > holy data and to make him a server process that people can connect to > using socketpair. It's sort of like a pipe that is allowed to be used to > connect two unrelated processes. One of the things about ipcs is the > error recovery needed to ensure they work properly. e.g., I have a msgq > that has a limit of X nr of messages. What are the clients supposed to do > if the enqueue fails? All of those class of problems go away if you use > the correct architecture. I have no qualms on this, but I also don't think that socketpair(2) is the answer per se., but the issue is more in the detail. If all that is needed is a common lookup table and a place to register a service, then possibly mmap(2) in combination with socketpair(2) and some of the other socket oriented calls would work fine. Possibly even fifos. I'm advocating more of an in-memory approach rather than a database approach. -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 2:36 pm, Steven W. Orr wrote: > dbm is very fast up to 10s of millions of records. It's not sql so don't > expect more. You give a key you get a value. Period. It's teenyweeny so > all the different clients won't bloat from using them. Actually, Berkeley DataBase is dbm. I have not seen dbm on Linux in quite a while. But, it was always the fastest. In any case, much depends on the type of attributes that Michael's coworker is looking at and the persistance. For instance if the need is run-time coordination between processes and/or threads, the in memory tools, such as ipc(5) or simply the sharing of a common data structure using mutexes can work very nicely. Depending on the number of attributes, linear or tree-style lookups are still faster than a database. Additionally, if he needs to deal with independent processes in contrast to threads or even forked processes, the task is different. In the simple memory environment, you implement a simple protocol: A client runs, looks into a known place. If it does not exist, start the server who initializes it. If it does exist, register so other processes may communicate. It all comes down to (if I may repeat myself), the amount of data you want to store, the structure of the data, the nature of the lookup, and whether you need to store the data on disk. -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
This link somehow got left out of my previous message: http://as-is.net/hacks/2005/03/benchmark_importing_multiple_entries.html ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Random snapshot of a MySQL server I run, that I consider fairly low-volume. An order of magnitude less than you're talking about, but then this server does a lot of webserving of photos. Query statistics: Since its startup, 28,439,172 queries have been sent to the server. Total ø per hour ø per minuteø per second 28,439,172 255,621.524,260.36 71.01 Googled benchmark of several DB's (same base app, may be app's fault.) Time in seconds for lots of MySQL INSERTs: MySQL INSERT MyISAM 50003.006 14.967 150007.474 29.996 25000 12.524 3 15.034 35000 17.515 4 20.040 45000 21.586 5 23.980 Time in msec (milleseconds) for a select of the above inserted data: SELECT * FROM a; MySQL QUERY1 MyISAM 5000 45 1 157 15000 110 2 240 25000 288 3 352 35000 378 4 415 45000 479 5 525 Unfortunately I didn't find a good randomly-grabbed benchmark for selection of one record. --Drew ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday, Feb 14th 2006 at 14:33 -0500, quoth Jerry Feldman: =>On Tuesday 14 February 2006 1:24 pm, Michael ODonnell wrote: =>> A cow-orker is tasked with implementing a lean- =>> and-mean registry thingy that's maybe similar =>> to the Windows registry, or maybe not. The real =>> goal is for multiple processes/threads to be able =>> to perform attribute lookups cheaply and reliably =>> and possibly VERY frequently (many thousands/sec) =>> with updates possible but very infrequent. =>Actually, a Windows style registry is a very bad thing as it not only =>represents a single point of failure that could render a system unusable, =>but also is a tool that is used by hackers. => =>In addition to a database, like Berkeley DB, I have seen message queues and =>shared memory, or more generally ipc(5). Much depends on whether you want =>to maintain the data between boots, but since Linux systems tend to stay up =>for many (hundreds of) days, it is sometimes cheaper to reinitialize on a =>boot. Additionally, you may want to consider the possibility that the =>system may use more than one computer. In any case, ipc(5) contains most of =>the tools you need (shared memory, semaphores, messages). Also look at =>mmap(2). With mmap(2) you can open a file that can be shared between =>processes. What you are doing in the case of a file is simply mapping that =>file into virtual memory. =>On the other hand, if you need a very fast database, Berkeley is probably =>one of the fastest and most reliable. On the downside of Berkeley, I was =>working on a driver's license system where we had a home-grown database. I =>was asked to check out Berkeley, and it failed on my benchmark with was a =>simulation of data from all the drivers license offices based on an average =>transaction rate, but that was 5 years ago. Jerry, I'll disagree with you on this one. Use of System V ipc is highly deprecated. I did a big project back in '90 that was a heavy user of semaphores and msgqueues. It was the right thing to do back then but today it's dead wrong. Today, if you are writing interprocess communication within one machine, you should look at the socketpair call. (Under SVR4 we used something called STREAMS pipes which provided similiar functionality.) The idea is to write one process to be the keeper of the holy data and to make him a server process that people can connect to using socketpair. It's sort of like a pipe that is allowed to be used to connect two unrelated processes. One of the things about ipcs is the error recovery needed to ensure they work properly. e.g., I have a msgq that has a limit of X nr of messages. What are the clients supposed to do if the enqueue fails? All of those class of problems go away if you use the correct architecture. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 01:24 pm, Michael ODonnell wrote: > A cow-orker is tasked with implementing a lean- > and-mean registry thingy that's maybe similar > to the Windows registry, or maybe not. The real > goal is for multiple processes/threads to be able > to perform attribute lookups cheaply and reliably > and possibly VERY frequently (many thousands/sec) > with updates possible but very infrequent. > > Anybody know of such a beast?Maybe a library > that uses shared memory? Just a thought, but how about an LDAP schema to support your options and an LDAP server to do the backend. They were designed to be exactly: > goal is for multiple processes/threads to be able > to perform attribute lookups cheaply and reliably > and possibly VERY frequently (many thousands/sec) > with updates possible but very infrequent. -Neil ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday, Feb 14th 2006 at 14:16 -0500, quoth Michael ODonnell: => => =>>> A cow-orker is tasked with implementing a lean- =>>> and-mean registry thingy that's maybe similar =>>> to the Windows registry, or maybe not. The real =>>> goal is for multiple processes/threads to be able =>>> to perform attribute lookups cheaply and reliably =>>> and possibly VERY frequently (many thousands/sec) =>>> with updates possible but very infrequent. =>>> =>>> Anybody know of such a beast?Maybe a library =>>> that uses shared memory? =>> =>>I would suggest Berkeley DB. => => =>Cool. Thanks. Not that I have actual knowledge of =>the subject, but I picture a DB engine as a somewhat =>ponderous thang. Would this fit the lean-and-mean =>requirement? I think all that's required is that a =>bunch of cooperating processes be able to do these =>attribute lookups; will linking them with a DB lib =>bloat them unreasonably? If not, then this may be =>just what he's lookin for... dbm is very fast up to 10s of millions of records. It's not sql so don't expect more. You give a key you get a value. Period. It's teenyweeny so all the different clients won't bloat from using them. man 3 gdbm -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
On Tuesday 14 February 2006 1:24 pm, Michael ODonnell wrote: > A cow-orker is tasked with implementing a lean- > and-mean registry thingy that's maybe similar > to the Windows registry, or maybe not. The real > goal is for multiple processes/threads to be able > to perform attribute lookups cheaply and reliably > and possibly VERY frequently (many thousands/sec) > with updates possible but very infrequent. Actually, a Windows style registry is a very bad thing as it not only represents a single point of failure that could render a system unusable, but also is a tool that is used by hackers. In addition to a database, like Berkeley DB, I have seen message queues and shared memory, or more generally ipc(5). Much depends on whether you want to maintain the data between boots, but since Linux systems tend to stay up for many (hundreds of) days, it is sometimes cheaper to reinitialize on a boot. Additionally, you may want to consider the possibility that the system may use more than one computer. In any case, ipc(5) contains most of the tools you need (shared memory, semaphores, messages). Also look at mmap(2). With mmap(2) you can open a file that can be shared between processes. What you are doing in the case of a file is simply mapping that file into virtual memory. On the other hand, if you need a very fast database, Berkeley is probably one of the fastest and most reliable. On the downside of Berkeley, I was working on a driver's license system where we had a home-grown database. I was asked to check out Berkeley, and it failed on my benchmark with was a simulation of data from all the drivers license offices based on an average transaction rate, but that was 5 years ago. -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Michael ODonnell wrote: Cool. Thanks. Not that I have actual knowledge of the subject, but I picture a DB engine as a somewhat ponderous thang. Would this fit the lean-and-mean requirement? In my world, Berkeley DB is pretty lean-and-mean. I'll bet that you'll come to the same conclusion. > I think all that's required is that a bunch of cooperating processes be able to do these attribute lookups; will linking them with a DB lib bloat them unreasonably? If not, then this may be just what he's lookin for... Yeah, I think that Berkeley DB is just what he is looking for... Hope this helps, --kevin -- GnuPG ID: B280F24E ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
>> A cow-orker is tasked with implementing a lean- >> and-mean registry thingy that's maybe similar >> to the Windows registry, or maybe not. The real >> goal is for multiple processes/threads to be able >> to perform attribute lookups cheaply and reliably >> and possibly VERY frequently (many thousands/sec) >> with updates possible but very infrequent. >> >> Anybody know of such a beast?Maybe a library >> that uses shared memory? > >I would suggest Berkeley DB. Cool. Thanks. Not that I have actual knowledge of the subject, but I picture a DB engine as a somewhat ponderous thang. Would this fit the lean-and-mean requirement? I think all that's required is that a bunch of cooperating processes be able to do these attribute lookups; will linking them with a DB lib bloat them unreasonably? If not, then this may be just what he's lookin for... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Windows-like registry for Linux?
Michael ODonnell wrote: A cow-orker is tasked with implementing a lean- and-mean registry thingy that's maybe similar to the Windows registry, or maybe not. The real goal is for multiple processes/threads to be able to perform attribute lookups cheaply and reliably and possibly VERY frequently (many thousands/sec) with updates possible but very infrequent. Anybody know of such a beast?Maybe a library that uses shared memory? I would suggest Berkeley DB. Regards, --kevin -- GnuPG ID: B280F24E ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Windows-like registry for Linux?
A cow-orker is tasked with implementing a lean- and-mean registry thingy that's maybe similar to the Windows registry, or maybe not. The real goal is for multiple processes/threads to be able to perform attribute lookups cheaply and reliably and possibly VERY frequently (many thousands/sec) with updates possible but very infrequent. Anybody know of such a beast?Maybe a library that uses shared memory? Thanks, --M ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
