361–370 of 387 posts
Earlier quoted context omitted.
If our collaboration tools can't handle a mere 15 collaborators, we need better tools.
Can 15 people sitting in the same room with a single editor effectively collaborate on a single document?
Earlier quoted context omitted.
What are your issues with Exchange? Actually, it was Exchange (at least since 2007SP1) that made me start thinking that it was actually possible for Microsoft to produce extremely reliable software.
My issues with Exchange? Let's see: - it's an overblown, over-engineered piece of shit designed to give "IT managers" and their secretaties a boner and suck them into Microsoft's vendor lock-in hellish groupware who still thinks we're in the 90s (fuck sharepoint, too while we're at it!) - requires big resources to work faster than a snail (fuck sharepoint again!) - to deploy it you need to also deploy more microsoft…
Earlier quoted context omitted.
Actually, that's what I was trying to say. Word's review functions appear as pretty colored bubbles and a bunch of icons on the Ribbon. It's easy enough even for Humanities professors to use on a daily basis, despite the fact that as a VCS, it's strictly inferior to something like git. Actually, I think it's popular precisely because it ain't git. Most professors who are fluent in Word's review functions would be hop…
I think you're absurdly underestimating people. A diff is a bunch of lines removed, and lines added. That's a pretty damn natural representation. As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
Earlier quoted context omitted.
I tried doing that in Word once, it's nowhere near the solid foundation that actual style sheets provide (thinking of CSS/HTML here). I only needed to style H1, H2, P, EM and possibly A (they don't have those names in Word, but you get the point). That's probably the simplest document structures you can have for a task that reasonably makes use of styles. The biggest problem was, those styles are like liquid, slippin…
This post begs the question - can Word be replaced with HTML/CSS? What if there were a WYSIWYG HTML/CSS editor? HTML would provide the intechangable document format; the ubiquity of browsers means everyone already has a document viewer; it would allow those with a desire for greater control to edit text directly in a text editor, separate from the presentation layer; and documents could be formatted for different pre…
Although, a few years ago, a couple of friends of mine were working on their masters theses in non-computer related fields (literature and biology), they complained about Word and its tendency to get somewhat "wonky" when working with very large documents (I am glad I have never had to experience such a task). I talked to them about the basic ideas behind the LaTeX workflow, that writing the text and doing layout/styling are straight from the start intended to be two separate concepts--you're either working on one or the other. And how the text content is also just that: a plain text file with a few document structure-related codes in it. A plain text file doesn't lose whole sections or mangles up chapters for no apparent reason.
I was surprised to hear their reaction, they were very intrigued and would have been readily prepared to learn the basics of LaTeX, if it meant getting that peace-of-mind: that writing a large chunk of text means that it is there, without a program doing behind-the-scenes modifications on it if you decide to move parts around, or so. I say "would have been" because they were already quite far in their theses so it would've made little sense to make the switch still.
Because that's really the point, isn't it? That's what annoys me about Word (and a lot of other word processing software btw), it just won't keep its fingers off my document, and all sorts of things happen under-the-hood. With LaTeX (and similar solutions, perhaps Markdown) the whole workflow is different: first you write the content, with some minimal markup and structuring codes, and that's a text file. It's yours and nobody, no software is going to touch it. It's source code. And only then you apply a program to it, in order to compile it to a display format. But that program will not touch your source.
I really like it that way. I understand it's not for everyone on the consumer market, but it's interesting to consider how different that paradigm is.
> Microsoft Word is a tyrant of the imagination, a petty, unimaginative, inconsistent dictator that is ill-suited to any creative writer's use. Microsoft Word was never designed to be an ideal tool for creative writing, programming, or any such thing. It was designed to help office workers produce business documents (a) quickly, (b) in a format that integrates with all the other programs in the Office suite, and (b)…
> Type a few word, hit "Save", and automatically get reasonable default fonts and margins? Check. Type a few more words, make some typos, have them fixed automatically? Check. Certain words need to be italicized or underlined? Check. Certain words need to be in a different font? Check. Who cares if it's consistent, the boss wants it bold so just make it bold. Indent the first line by X inches, double-space here, sing…
LOL seriously? Look everybody, v2 even has footnotes and -gasp- tables! And they are 'very powerful' tables, too, because you can even merge cells (in a 'non-modal dialog', no less!)
(oh, and last release version - 2009).
Earlier quoted context omitted.
Desktop application software for collaborative editing? No way. Confluence? Twiki? Or equal such centralised documentaiotn and revision service, be it SaaS or locally hosted, Yes.
Wait. What? Have you tried collaboration with a Word before saying this? I make my living collaborating on documents in Word. Which part of it did you have a problem with? I have found only OneNote to be any better than Word but alas it lacks a bunch of Word features.
Earlier quoted context omitted.
That's very disingenuous. The libreoffice code base is big and complex and hard enough to ramp up on that fixing your personal problems with it would quickly become a full time job, even if you already know all there is to know about programming enterprise software in c++
That depends on what you're trying to fix. Add a nonlinear solver to calc? Sure. Add a fill function into draw? _Maybe_ a two-month after-hours project.
So, I have this project in which I need to fill an area in a drawing in a proposal for a client. So my options are:
a) Spend $200 (about an hours worth of billable time, or 2 hours during dry spells) on MS Office.
b) Spend 2 x 4 x 10 = 80 hours (which is no where near enough, but let's go with your number) on this feature, then spend again that on finding and convincing the right people to include my patch, on a half-assed implementation which does just enough what I need, and tell my client 'yeah get back to me in 2 months when I have patched my word processor to deliver the functionality I need'.
Choices choices, which one should I choose?
Just that time alone on a single tiny feature would pay for a lifetime worth of MS Office software!
The truly irreplaceable product is Excel. It is fraught with quirky bugs and limitations and odd conventions (how many people actually end up storing dates before the magic February 29 1900?), yet no alternative can hold a candle to Excel. On the other hand, there are solid alternatives to the other products in the office suite
How much would it take to replace Excel with an open source alternative? $100K? $1MM? There has to be a dollar amount where you can buy enough developer time to replace it.
That is one full time developer for a year, not counting any project management etc. If we say that so far, there has been spend 1000 man years on Open/Libre Office (I'm just making that number up, it has been under development for decades and probably with more than 20 devs working on it, so it's probably more, but let's say 1000, and not even count all the project management / user feedback / documentation work etc); then still you're saying that bringing Libre Office to the level of MS Office is within 0.1 resp 1 % of completion. I hope I don't need to argue how that is prima facie nonsense.
Earlier quoted context omitted.
I think you're absurdly underestimating people. A diff is a bunch of lines removed, and lines added. That's a pretty damn natural representation. As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
FWIW, I don't often encounter diff output in my day-to-day computer usage, but when I do, I do not find them very intuitive to understand. A bit of UI magic would help here, it's not the concept that is hard (for me) to grasp, just all those lines with +'s and -'s and figuring out the contexts in which they apply. It's always a bit of a puzzle, especially if, for some reason, it's not highlighted with colours.
Earlier quoted context omitted.
What? The result would be exactly the same, right? You don't have your unpushed commit if your laptop is broken, neither with svn nor with git. The only difference is that you still can use your local git repository if your server burns down, but you can't do that with svn.
With SVN a commit is a push. You can't forget to push after you've committed.