Date: Mon, 22 Jan 2018 23:07:32 +0100 From: Polytropon <freebsd@edvax.de> To: Valeri Galtsev <galtsev@kicp.uchicago.edu> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Document/collaboration server advise needed Message-ID: <20180122230732.71a007bb.freebsd@edvax.de> In-Reply-To: <da157768-7566-994f-c377-66d6c3f961bc@kicp.uchicago.edu> References: <da157768-7566-994f-c377-66d6c3f961bc@kicp.uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jan 2018 14:52:17 -0600, Valeri Galtsev wrote: > Three groups of scientists need to write documents collaboratively. They > are going to use MS PowerPoint, Word, also store PDF files. They want to > be able to add external people from other groups they collaborate with > and give them access to some areas or "projects". In other words, they > want some collaborative work environment, mostly to work on documents. That's a really sad story... > In the past scientists were using TeX, and one of version control > systems (CVS, subversion,...). And all was great, as TeX files (pretty > much like programs software developers write) are ASCII text files, and > diff of two version is rather small... I've been supporting such environments in the past, and users were generally happy with it, especially because they could use the operating systems they wanted (most Linux, some a BSD, a few ones Solaris). With every generation of computers (servers and "endpoints"), the system ran better and faster, something today's users probably cannot even imagine. > Unlike the past scientists I work for plan to use MS PowerPoint, Word, > also store PDF files. All these are effectively binary files for version > control systems, then versions will not be stored as a small diff, but > each version ends up being the whole document. That is correct. Binary diffs are possible, but probably not very efficient. Additionally, MICROS~1 "document" files sometimes keep their own history, which you can observe by altering the file (add "a", save, remove "a", save, "add "b", save, remove "b", save, and always check the file size). Access to this "versioning information" is often not trivial. One single "quick save" can render a file unusable or even unaccessible, and it needs to be opened and re-exported using OpenOffice or LibreOffice. Of course you probably won't convince them to use (Open/Libre)Office because those aren't made by MICROS~1 and don't come with a support contract. Sure, those formats are fully documented (!) compressed archives containing XML and blobs, so in worst case, document recovery is possible with standard means, but who cares... we don't need a backup, we have RAID. :-) > One obvious solution may be: just buy office365.com service, or set up > MS server on our own machine. And these are the two things I am trying > to avoid. This is possible, and nobody got fired for buying ^W licensing MICROS~1 products. Vendor lock-in is such a good thing, it's the fundamental power of the free market and blah blah blah... > Could someone recommend open source software? Some collaborative suite > focused mostly on working on documents, with web based interface. Maybe this list can provide some inspiration? https://en.wikipedia.org/wiki/List_of_collaborative_software In worst case, create a big pile of mud: Databases with binary blobs, lots of servers (but make them virtual, because that's cool and also DevOps), make the CxOs believe that they need to license lots of stuff, and then watch them suffer. In case of complaints, like, "This is soooo slow!" or "Why can't I do {placeholder}?" and especially "It doesn't work on my latest-gen smartphone!", just refer them to the support of the software they approved. If there is no such support, well... NB: Those who decide about the software to use won't be the ones who have to use that software. And whatever you suggest, it will be "insufficient", "lacking essential features" and "not conform to specification", which of course will be noticed after the contracts have been signed and the money has been transfered. So always be sure to document everything in a written form (for your safety) - I'm sure you know why, but I thought it would be useful for future readers who find this comment in the mailing list archive. Sorry to be not more helful than a syringe of acid... ;-) Sidenote: I'm more than lucky _not_ to have to work in such environments anymore. I hope you will find a solution, though, as nobody deserves this kind of bullshit-driven punishment. But I know it _can_ be possible to provide users with what users _need_ (not neccessarily what their managers _want_). With training (and don't tell me it's possible to survive in collaboration environments without training and tested procedures!), everything can be fine. Again, sorry I couldn't provide more help. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180122230732.71a007bb.freebsd>