not quite.
Lotus Notes does sync unread marks, the algorithm is quite interesting, here is a description of the process from the Lotus Knowledge Base
Where are unread marks stored, anyway?
In three places, actually. The unread list itself is a special, named object (whose name is the canonical user name) in the database itself. The unread list is a compressed list of unread note IDs. In order to gain compression efficiency, the note IDs chosen are specific to a given database replica, and not applicable to other database replicas. A cached copy of this unread list is kept at the Notes Client in DESKTOP.DSK, mainly for performance optimizations. Finally, a log of client-initiated operations to mark notes read or unread is kept at the Notes Client in CACHE.DSK - this log is called the Unread Journal. This journal stores UNIDs, which are applicable to all of a database's replicas. The proper conversions are done to convert note IDs to and from UNIDs when processing the journal.
Do unread marks replicate?
Unread marks do not replicate in the standard way that documents replicate in Notes. Attempting to replicate database unread lists this way would often lead to replication conflicts that an end user could not resolve. To avoid confusion, we say that unread lists are synchronized, not replicated. The major way that unread marks are synched is via the Unread Journal. Additionally, there is a NOTES.INI setting which tells the Replicator to sync unread marks during a client to server replication. There is no way to sync unread marks during server to server replication. The reason for this is that server to server replication does not run with the identity of a user or users for which to sync unread marks. Since many Notes databases have a large number of users who access them, synching unread lists for all users' unread lists in the database would be a serious drain on Replicator performance.
So when do unread marks work flawlessly?
Well, we have all learned not to say "flawless" when it comes to computer software. But we believe that all cases of a user using one Notes client system to access multiple replicas of a database works correctly in R5. We also believe that all cases of a user using multiple Notes client systems to access a single database (with no replicas) works correctly in R5. In the single client to multiple replica case, the Unread Journal assures that mark operations that were done in one replica are kept outstanding for the other replica until that replica is accessed, at which time all of the outstanding operations are "replayed" to that replica, thus synching the unread marks. In the multiple client to single replica case, the R5 redesign, coupled with the fact that the definitive unread lists lives in the database itself, keeps the unread list correct.
When do unread marks potentially not work, and what can I do about it?
When the same user uses two different clients to access two different replicas of a database and does mark operations in each, without intervening steps, inconsistencies in unread lists can arise. If the user were to subsequently access both replicas from both clients, then both unread journals would replay their outstanding entries to the respective replica, and the unread marks would then be consistent. If one of the replicas is a local replica on one of the clients, using the REPLICATOR_SYNC_UNREAD=-1 NOTES.INI setting on the client will force unread marks to be synched between the client and server replicas on each replication. Both of these mechanisms are workarounds to the problem.
If REPLICATOR_SYNC_UNREAD is set to a non-negative number, unread mark synching may not be done on each and every replication. The value of this variable is the minimum number of half hours between database replications which will synchronize the unread lists between local and server replicas. If you have scheduled the Replicator to run more often than the interval specified by this variable, interim replications will not sync unread marks. Use this if you don't want the performance hit of synching on every single replication. By setting REPLICATOR_SYNC_UNREAD to -1 (negative 1), you assure that each and every replication will sync unread marks.
The Unread Journal is a Notes Client mechanism only. Other components or API programs doing mark operations will not get the benefit of synching unread marks that the Unread Journal provides. They will certainly work correctly on the particular replica (or single database) on which they operate, but will not get the automatic replay of their mark operations to other replicas. The Unread Journal is also finite in size, though it does hold a large number of entries, around 20,000 entries to be used for all databases accessed by the client. If you go a real long time without accessing a replica, some of its outstanding marks can get overwritten as the journal wraps around with newer entries. As a result, the recently added or modified documents in the database will be marked correctly, but the older ones may not be.
Another factor is that a "Mark All" operation is one that affects a specific set of documents based on exactly when it is performed, so for complete accuracy it can not be journalled as a simple "mark all" indicator, but rather must be journalled as a set of mark operations. Because of the finiteness of the journal and the possible negative effects of wrap-around, Notes imposes a limit of 1,000 on the number of individual journal entries for a "Mark All" operation. A "Mark All" when there are more than 1,000 documents affected is still journalled, but slightly less accurately. It is journalled as a "mark all before this time" operation, which occupies just a single journal entry. This won't work quite right when the time of the servers hosting other replicas is off, nor will it work properly if operations performed on a partial replica are journalled and later replayed against a fuller replica.
Problems relating to the fact that the Unread Journal is not exposed outside the Notes Client can be worked around by using REPLICATOR_SYNC_UNREAD=-1 if one of the replicas is a local replica. Problems relating to the finiteness of the journal can be addressed by encouraging users to access all of their replicas occasionally, or to repeat mark operations on the other replica when it becomes necessary. At any one time the journal contains at most 20,000 entries which are the most recent mark operations across all databases accessed by the client. There is no per-database limit on the number of journal entries. Generally speaking, it takes a lot of Notes usage to cause the journal to wrap around, in part because of the limit of 1,000 imposed on "Mark All" operations.
The following feature may be obsoleted in a future version of Notes, and should be used only as a last resort for attempting to fix unread mark problems. The R5 Notes Client currently still supports the R4-style desktop user interface via the "Workspace" page. On the Workspace page, you can unstack replica icons, select two of the replicas, and select Edit - Unread Marks - Exchange Unread Marks. This forces the equivalent of REPLICATOR_SYNC_UNREAD, but it is more powerful in that it allows you to exchange unread marks at any time, and it allows you to do it between two server-based replicas.
There is no recording by Notes of the time at which a document was marked read or unread. Thus, the synching mechanism enabled by REPLICATOR_SYNC_UNREAD has no way of knowing how to resolve a read/unread conflict. Since notes are initially marked unread for a user when they are created, it is more common for a note to go from unread to read than vice versa. Thus, REPLICATOR_SYNC_UNREAD always resolves a conflict by making the note read in both replicas. Occasionally, this may not be what the user expected. The Unread Journal does not have this problem because, although it does not have precise times when mark operations were done, it does know the order in which they happened.
We should all learn a lesson from this, an error message which is polite, friendly and offers a suggestion. If a typical programmer wrote this the error message would read "Error 8975132 Bad request overflow at line 78223"
There are companies who have useability labs which are made available to partner organisations, I am sure that Lotus or IBM would be quite happy to entertain the prospect of hosting a session for Linux testing. Probably best coming from RedHat as they have already been through the formal certification process with Lotus.
Lotus certifies that Red Hat Linux 6 is a certified platform for running Lotus Domino. several other distributions are 'supported' but only redhat is 'certified'. This shows a vendor support commitment and specifies the distribution that it definitly works with. It is hard for an application or product to be certified to work with Linux as a whole, Specific distributions could certify products as working with them,(runs on RedHat etc.)
Pass Voyager? that implies that they are both going in the same direction. Is there one direction that is more interesting to go than any other from earth? here are my options
towards galaxy centre
away from galaxy centre
normal to the plane of the galaxy
towards 2nd nearest star (nearest is 8 light minutes away)
This vb script file had visible source, would it have been compatible with the GPL? would that make it easier or harder to prosecute the author? what if the copywrite was signed over to the FSF?
Lotus Domino has the excellent Domino Global Workbench, it allows you to manage mulitlingual web sites and workflow applications using browsers or Notes clients. It can be coupled with a machine translation engine to do the actual translation or you can farm out the translation strings to an agency, or different agencies for each language.
So it is not strictly open source in that it is not under an open licence however most of the source is visible, and you can change it for your own requirements.
With the recent spate of high Lotus execs resigning Lotus is likely to fall more under IBM's wing which means a strenghend commitment to Linux and Open source in future.
This may outperform the crusoe chips released so far but the point is that the clock speed is pretty immaterial when judging processor performance, much less system performance. We need to see a benchmark figure for processor performance. I expect I could design a processor that does almost nothing but has a clock speed of 2Ghz, we need to establish how much work this thing can accomplish in a given time.
Lotus 123 was not the original spreadsheet but M$ certainly had more than a quick glance at it prior to knocking up Excel, same goes for WordPerfect and Harvard Graphics, as for Access . . .
The only product of significance that they have not been able to rip off is Lotus Domino. (they have tried but their efforts are laughable)
Lotus came up with this idea at least 4 years ago with the single copy object store in Lotus Notes. Not everyone likes it as if you loose or corrupt your object store you are in deep do dos. This is nothing like symbolic links in *nix as this is a background operation. M$ turned symbolic links into 'shortcuts' and implemented them very poorly.
the 2GB limit is a bit of a pain for advocates of Lotus Domino on Linux. Every other Domino platform can have databases with no practical size limit and many enterprise scale knowledge management applications with multimedia content make use of the large database sizes. Domino on Linux is as stable and powerful as the AS/400 and Unix platforms (no daily or weekly reboots as NT requires) but if it can't support substantial databases you can't always perform a trivial migration process from a legacy operating system.
to be fair to CERN this is not a term mentioned anywhere but in the/. article. Seems like they are doing some seriously high energy physics though, they talk about a fireball expanding at c/2, now that counts as quick in my book.
Primordial Soup is the accepted term for the unknown collection of ingredients supposedly slopping about at the correct temperature etc for life to spontaniously form. This experiment is nothing to do with that state, it is more cosmological and seems to create the conditions shortly following an event, not the conditions required for it to spontaniously trigger.
and everyone thought that the DOJ was putting the boot in, now MS is on the wrong end of the EU! This is v. bad for Bill, you can argue with the DOJ but how can you argue with an organisation that has objected to bananas of excessive curvature?
As a pro Euro Brit, it is great to see the EU providing a service that all can benefit from.
The only scary thing kicking about is bucket loads of virtual money being assigned to stock values. I can't see any conflict of interests worth noting in the merger, plenty of content providors in other media are owned by big companies. Slashdot will retain its editorial independance for 2 main reasons: 1) VA won't influence it. 2) bugger all of the editorial content is written by the editors. I skim the articles and read the comments, VA does not own me, nobody owns me!(although Lotus may have a part share) Alan.
we all have our own definitions of our requirements, and there are degrees of openness. Domino does have a number of well documented APIs the c API allowing full access to the internal data structures, the other APIs protect you a bit more from doing yourself an injury. All software is layered, some layers are sometimes open source. My databases on domino are always released with source (although most are not free or freely copyable outside of the client I sell them to). If you are using Apache on Linux then you have your web sites(open) on top of Apache(open) on Linux(open) on an x86 processor which is closed. I am using my databases(open) on domino(closed) on Linux(open) on an Intel chip (closed)
Slashdot Mirror
Where are unread marks stored, anyway?
In three places, actually. The unread list itself is a special, named object (whose name is the canonical user name) in the database itself. The unread list is a compressed list of unread note IDs. In order to gain compression efficiency, the note IDs chosen are specific to a given database replica, and not applicable to other database replicas. A cached copy of this unread list is kept at the Notes Client in DESKTOP.DSK, mainly for performance optimizations. Finally, a log of client-initiated operations to mark notes read or unread is kept at the Notes Client in CACHE.DSK - this log is called the Unread Journal. This journal stores UNIDs, which are applicable to all of a database's replicas. The proper conversions are done to convert note IDs to and from UNIDs when processing the journal.
Do unread marks replicate?
Unread marks do not replicate in the standard way that documents replicate in Notes. Attempting to replicate database unread lists this way would often lead to replication conflicts that an end user could not resolve. To avoid confusion, we say that unread lists are synchronized, not replicated. The major way that unread marks are synched is via the Unread Journal. Additionally, there is a NOTES.INI setting which tells the Replicator to sync unread marks during a client to server replication. There is no way to sync unread marks during server to server replication. The reason for this is that server to server replication does not run with the identity of a user or users for which to sync unread marks. Since many Notes databases have a large number of users who access them, synching unread lists for all users' unread lists in the database would be a serious drain on Replicator performance.
So when do unread marks work flawlessly?
Well, we have all learned not to say "flawless" when it comes to computer software. But we believe that all cases of a user using one Notes client system to access multiple replicas of a database works correctly in R5. We also believe that all cases of a user using multiple Notes client systems to access a single database (with no replicas) works correctly in R5. In the single client to multiple replica case, the Unread Journal assures that mark operations that were done in one replica are kept outstanding for the other replica until that replica is accessed, at which time all of the outstanding operations are "replayed" to that replica, thus synching the unread marks. In the multiple client to single replica case, the R5 redesign, coupled with the fact that the definitive unread lists lives in the database itself, keeps the unread list correct.
When do unread marks potentially not work, and what can I do about it?
When the same user uses two different clients to access two different replicas of a database and does mark operations in each, without intervening steps, inconsistencies in unread lists can arise. If the user were to subsequently access both replicas from both clients, then both unread journals would replay their outstanding entries to the respective replica, and the unread marks would then be consistent. If one of the replicas is a local replica on one of the clients, using the REPLICATOR_SYNC_UNREAD=-1 NOTES.INI setting on the client will force unread marks to be synched between the client and server replicas on each replication. Both of these mechanisms are workarounds to the problem.
If REPLICATOR_SYNC_UNREAD is set to a non-negative number, unread mark synching may not be done on each and every replication. The value of this variable is the minimum number of half hours between database replications which will synchronize the unread lists between local and server replicas. If you have scheduled the Replicator to run more often than the interval specified by this variable, interim replications will not sync unread marks. Use this if you don't want the performance hit of synching on every single replication. By setting REPLICATOR_SYNC_UNREAD to -1 (negative 1), you assure that each and every replication will sync unread marks.
The Unread Journal is a Notes Client mechanism only. Other components or API programs doing mark operations will not get the benefit of synching unread marks that the Unread Journal provides. They will certainly work correctly on the particular replica (or single database) on which they operate, but will not get the automatic replay of their mark operations to other replicas. The Unread Journal is also finite in size, though it does hold a large number of entries, around 20,000 entries to be used for all databases accessed by the client. If you go a real long time without accessing a replica, some of its outstanding marks can get overwritten as the journal wraps around with newer entries. As a result, the recently added or modified documents in the database will be marked correctly, but the older ones may not be.
Another factor is that a "Mark All" operation is one that affects a specific set of documents based on exactly when it is performed, so for complete accuracy it can not be journalled as a simple "mark all" indicator, but rather must be journalled as a set of mark operations. Because of the finiteness of the journal and the possible negative effects of wrap-around, Notes imposes a limit of 1,000 on the number of individual journal entries for a "Mark All" operation. A "Mark All" when there are more than 1,000 documents affected is still journalled, but slightly less accurately. It is journalled as a "mark all before this time" operation, which occupies just a single journal entry. This won't work quite right when the time of the servers hosting other replicas is off, nor will it work properly if operations performed on a partial replica are journalled and later replayed against a fuller replica.
Problems relating to the fact that the Unread Journal is not exposed outside the Notes Client can be worked around by using REPLICATOR_SYNC_UNREAD=-1 if one of the replicas is a local replica. Problems relating to the finiteness of the journal can be addressed by encouraging users to access all of their replicas occasionally, or to repeat mark operations on the other replica when it becomes necessary. At any one time the journal contains at most 20,000 entries which are the most recent mark operations across all databases accessed by the client. There is no per-database limit on the number of journal entries. Generally speaking, it takes a lot of Notes usage to cause the journal to wrap around, in part because of the limit of 1,000 imposed on "Mark All" operations.
The following feature may be obsoleted in a future version of Notes, and should be used only as a last resort for attempting to fix unread mark problems. The R5 Notes Client currently still supports the R4-style desktop user interface via the "Workspace" page. On the Workspace page, you can unstack replica icons, select two of the replicas, and select Edit - Unread Marks - Exchange Unread Marks. This forces the equivalent of REPLICATOR_SYNC_UNREAD, but it is more powerful in that it allows you to exchange unread marks at any time, and it allows you to do it between two server-based replicas.
There is no recording by Notes of the time at which a document was marked read or unread. Thus, the synching mechanism enabled by REPLICATOR_SYNC_UNREAD has no way of knowing how to resolve a read/unread conflict. Since notes are initially marked unread for a user when they are created, it is more common for a note to go from unread to read than vice versa. Thus, REPLICATOR_SYNC_UNREAD always resolves a conflict by making the note read in both replicas. Occasionally, this may not be what the user expected. The Unread Journal does not have this problem because, although it does not have precise times when mark operations were done, it does know the order in which they happened.
We should all learn a lesson from this, an error message which is polite, friendly and offers a suggestion. If a typical programmer wrote this the error message would read "Error 8975132 Bad request overflow at line 78223"
{/. should put a time of day filter, I'm sure that 90% of the crap posted wouldn't be if posts weren't done at 4 AM} 4AM in what time zone exactly?
There are companies who have useability labs which are made available to partner organisations, I am sure that Lotus or IBM would be quite happy to entertain the prospect of hosting a session for Linux testing. Probably best coming from RedHat as they have already been through the formal certification process with Lotus.
Lotus certifies that Red Hat Linux 6 is a certified platform for running Lotus Domino. several other distributions are 'supported' but only redhat is 'certified'. This shows a vendor support commitment and specifies the distribution that it definitly works with. It is hard for an application or product to be certified to work with Linux as a whole, Specific distributions could certify products as working with them ,(runs on RedHat etc.)
This vb script file had visible source, would it have been compatible with the GPL? would that make it easier or harder to prosecute the author? what if the copywrite was signed over to the FSF?
Lotus Domino Global Workbench
Lotus Domino has the excellent Domino Global Workbench, it allows you to manage mulitlingual web sites and workflow applications using browsers or Notes clients. It can be coupled with a machine translation engine to do the actual translation or you can farm out the translation strings to an agency, or different agencies for each language.
So it is not strictly open source in that it is not under an open licence however most of the source is visible, and you can change it for your own requirements.
With the recent spate of high Lotus execs resigning Lotus is likely to fall more under IBM's wing which means a strenghend commitment to Linux and Open source in future.
This may outperform the crusoe chips released so far but the point is that the clock speed is pretty immaterial when judging processor performance, much less system performance. We need to see a benchmark figure for processor performance. I expect I could design a processor that does almost nothing but has a clock speed of 2Ghz, we need to establish how much work this thing can accomplish in a given time.
The only product of significance that they have not been able to rip off is Lotus Domino. (they have tried but their efforts are laughable)
Lotus came up with this idea at least 4 years ago with the single copy object store in Lotus Notes. Not everyone likes it as if you loose or corrupt your object store you are in deep do dos. This is nothing like symbolic links in *nix as this is a background operation. M$ turned symbolic links into 'shortcuts' and implemented them very poorly.
the 2GB limit is a bit of a pain for advocates of Lotus Domino on Linux. Every other Domino platform can have databases with no practical size limit and many enterprise scale knowledge management applications with multimedia content make use of the large database sizes. Domino on Linux is as stable and powerful as the AS/400 and Unix platforms (no daily or weekly reboots as NT requires) but if it can't support substantial databases you can't always perform a trivial migration process from a legacy operating system.
to be fair to CERN this is not a term mentioned anywhere but in the /. article. Seems like they are doing some seriously high energy physics though, they talk about a fireball expanding at c/2, now that counts as quick in my book.
Primordial Soup is the accepted term for the unknown collection of ingredients supposedly slopping about at the correct temperature etc for life to spontaniously form. This experiment is nothing to do with that state, it is more cosmological and seems to create the conditions shortly following an event, not the conditions required for it to spontaniously trigger.
As a pro Euro Brit, it is great to see the EU providing a service that all can benefit from.
The only scary thing kicking about is bucket loads of virtual money being assigned to stock values. I can't see any conflict of interests worth noting in the merger, plenty of content providors in other media are owned by big companies. Slashdot will retain its editorial independance for 2 main reasons: 1) VA won't influence it. 2) bugger all of the editorial content is written by the editors. I skim the articles and read the comments, VA does not own me, nobody owns me!(although Lotus may have a part share) Alan.
we all have our own definitions of our requirements, and there are degrees of openness. Domino does have a number of well documented APIs the c API allowing full access to the internal data structures, the other APIs protect you a bit more from doing yourself an injury. All software is layered, some layers are sometimes open source. My databases on domino are always released with source (although most are not free or freely copyable outside of the client I sell them to). If you are using Apache on Linux then you have your web sites(open) on top of Apache(open) on Linux(open) on an x86 processor which is closed. I am using my databases(open) on domino(closed) on Linux(open) on an Intel chip (closed)
Crusoe 1 and 2 are the babies, the range is set to go up and up. The point is that the Crusoe code morphing invalidates comparisons of clock speeds.