<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Another CIty Switching to LibreOffice</title>
	<atom:link href="http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/feed/" rel="self" type="application/rss+xml" />
	<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/</link>
	<description>One man. Closing, all the windows.</description>
	<lastBuildDate>Mon, 20 May 2013 06:35:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Yonah</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-94068</link>
		<dc:creator>Yonah</dc:creator>
		<pubDate>Sun, 19 Aug 2012 01:30:06 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-94068</guid>
		<description><![CDATA[Oiaohm: &quot;You lose because you have just proven you don’t read.&quot;

On the contrary, my linguistically challenged friend.  My reading and writing skills far exceed your own.  SERIOUSLY, I read your garbage then simply ignored it because, once again, the source is YOU and only YOU.  I love winning!]]></description>
		<content:encoded><![CDATA[<p>Oiaohm: &#8220;You lose because you have just proven you don’t read.&#8221;</p>
<p>On the contrary, my linguistically challenged friend.  My reading and writing skills far exceed your own.  SERIOUSLY, I read your garbage then simply ignored it because, once again, the source is YOU and only YOU.  I love winning!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: oiaohm</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92538</link>
		<dc:creator>oiaohm</dc:creator>
		<pubDate>Sat, 28 Jul 2012 03:21:46 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92538</guid>
		<description><![CDATA[Phenom
&quot;The second statement is correct, but the first is just plain wrong. Have you heard of cache misses? Of branch mispredictions? Heck, forget these, let talk even of very basic stuff like waiting for IO operations to complete.&quot;

Yes to all those.  Its not completely wrong it correct only for 1 case other than I missed a word should have had the word virtual before cores.  If you had run multi process like software builds and documentation conversion.  You find out there is a ideal number of threads any system can handle.

Branch mispredictions this is what hyperthreading was designed to limit processing effect of.  Double the number of threads to number of physical cores.  It also limits the effects of cache misses.

This is a multi-thread statement when dealing with something like a complier or something like a spreadsheet where you must at the end merge the data back into one piece.  Both have a related IO pattern.  Read at start.  Spend time processing if threaded merge then Write at end.   So if you have a lot of excel documents to process a single threaded multi process attack is going to beat a multi threaded multi process attack.  Why because multi threaded requires a merge of data processed on each thread.

The big word you missed that is critical why on a 1000 core system multi-thread falls apart doing spreadsheets is NUMA.

Non Unified Memory Architecture where cpus have to sync to transfer data between each other because you threaded.  This is slow.

Yet on a NUMA a multi process does not hurt as bad.  Why no cpu to cpu memory controller transferring of data.  Yes fully IO related.

If you had build from source using gnumake -j number of processes you would understand what is going on.

Multi process and multi thread don&#039;t magically scale unlimited in a complier or spreadsheet case.  They are the case that you can over thread.  You cannot over break into processes.

Something like excel is a different beast to a http server running multi thread.  Http multi threading is not merging data from many threads in most cases.

I was referring to multi-threading for the case of a spreadsheet.  Single threaded in multi process works out better for massive spreadsheet processing.  Load shape is predictable and you will not end up with the case that the first document you opened staving the second document you are opening from getting cpu time.  Then you will in a excel case waste a lot of cycles merging data back.

To a spreadsheet style workload more threads don&#039;t equal better all the time on large systems it equals hindrance due to running into NUMA.  And in fact if you watch excel carefully Phenom is avoiding threading.  How its avoiding threading is the result cache.

Processing system has is not referring to the full motherboard You have a 4 physical cpu chip system.  You are running threads on all of them.  Each cpu chip is a physicial processing system.  Once you have the case that you job is extending over many CPU crossing NUMA boarders you are in ouch if you are planing to merge that data back into on piece.

Yes I should not be using mosix cluster terms but NUMA terms.  I still think NUMA in terms of mosix clusters.  Behaviour is very similar just clusters hurt worse for thread to thread syncing.
http://www.mosix.cs.huji.ac.il/

Yes when you have more thread on a Numa system than what a section of it can handle the OS normally moves load around.  Resulting it bad case of Numa memory syncing.

Phenom yes you have every right to tell me off for using clustering term instead of NUMA term so misleading you slightly.  Problem is there is not a official Numa term for a Numa segment that I remember.  My brain has used the next best thing.   Equal term from cluster computers.

Yes I should have started that section for spreadsheet/complier style workloads.  Not written it appearing generic an presuming it to be read with the context of problem at hand.

Basically you need to cap the spreadsheet so its processing does not cause sync problems between NUMA sections when you need to process vast amounts of spreadsheets.  ccNUMA hurts.

So make Calc multi threaded without a results cache its still going to be slow.  Make Calc open up too many threads when batch processing on a NUMA system it will be slow too.  Single threaded per program is the safest on a NUMA system without tweaking.  Since 1 thread cannot not by mistake end up in two NUMA segments trying to sync data with each other.

Threading has a scale problem.  Very big system threading can equal slow.  NUMA segments is problem desktop users forget.  But when you have a large Linux thin client server NUMA segments do become a problem.

Linux costs about the same to start a new thread as start a new process.  New process is neater on NUMA stuff as long as what you are doing can operate that way.

So in some cases calc being able to fire off more than 1 process would be a god send(linux and os x users).  Ok when running on windows you would not want to do this.  Because windows is slow to start processes fast to start threads.]]></description>
		<content:encoded><![CDATA[<p>Phenom<br />
&#8220;The second statement is correct, but the first is just plain wrong. Have you heard of cache misses? Of branch mispredictions? Heck, forget these, let talk even of very basic stuff like waiting for IO operations to complete.&#8221;</p>
<p>Yes to all those.  Its not completely wrong it correct only for 1 case other than I missed a word should have had the word virtual before cores.  If you had run multi process like software builds and documentation conversion.  You find out there is a ideal number of threads any system can handle.</p>
<p>Branch mispredictions this is what hyperthreading was designed to limit processing effect of.  Double the number of threads to number of physical cores.  It also limits the effects of cache misses.</p>
<p>This is a multi-thread statement when dealing with something like a complier or something like a spreadsheet where you must at the end merge the data back into one piece.  Both have a related IO pattern.  Read at start.  Spend time processing if threaded merge then Write at end.   So if you have a lot of excel documents to process a single threaded multi process attack is going to beat a multi threaded multi process attack.  Why because multi threaded requires a merge of data processed on each thread.</p>
<p>The big word you missed that is critical why on a 1000 core system multi-thread falls apart doing spreadsheets is NUMA.</p>
<p>Non Unified Memory Architecture where cpus have to sync to transfer data between each other because you threaded.  This is slow.</p>
<p>Yet on a NUMA a multi process does not hurt as bad.  Why no cpu to cpu memory controller transferring of data.  Yes fully IO related.</p>
<p>If you had build from source using gnumake -j number of processes you would understand what is going on.</p>
<p>Multi process and multi thread don&#8217;t magically scale unlimited in a complier or spreadsheet case.  They are the case that you can over thread.  You cannot over break into processes.</p>
<p>Something like excel is a different beast to a http server running multi thread.  Http multi threading is not merging data from many threads in most cases.</p>
<p>I was referring to multi-threading for the case of a spreadsheet.  Single threaded in multi process works out better for massive spreadsheet processing.  Load shape is predictable and you will not end up with the case that the first document you opened staving the second document you are opening from getting cpu time.  Then you will in a excel case waste a lot of cycles merging data back.</p>
<p>To a spreadsheet style workload more threads don&#8217;t equal better all the time on large systems it equals hindrance due to running into NUMA.  And in fact if you watch excel carefully Phenom is avoiding threading.  How its avoiding threading is the result cache.</p>
<p>Processing system has is not referring to the full motherboard You have a 4 physical cpu chip system.  You are running threads on all of them.  Each cpu chip is a physicial processing system.  Once you have the case that you job is extending over many CPU crossing NUMA boarders you are in ouch if you are planing to merge that data back into on piece.</p>
<p>Yes I should not be using mosix cluster terms but NUMA terms.  I still think NUMA in terms of mosix clusters.  Behaviour is very similar just clusters hurt worse for thread to thread syncing.<br />
<a href="http://www.mosix.cs.huji.ac.il/" rel="nofollow">http://www.mosix.cs.huji.ac.il/</a></p>
<p>Yes when you have more thread on a Numa system than what a section of it can handle the OS normally moves load around.  Resulting it bad case of Numa memory syncing.</p>
<p>Phenom yes you have every right to tell me off for using clustering term instead of NUMA term so misleading you slightly.  Problem is there is not a official Numa term for a Numa segment that I remember.  My brain has used the next best thing.   Equal term from cluster computers.</p>
<p>Yes I should have started that section for spreadsheet/complier style workloads.  Not written it appearing generic an presuming it to be read with the context of problem at hand.</p>
<p>Basically you need to cap the spreadsheet so its processing does not cause sync problems between NUMA sections when you need to process vast amounts of spreadsheets.  ccNUMA hurts.</p>
<p>So make Calc multi threaded without a results cache its still going to be slow.  Make Calc open up too many threads when batch processing on a NUMA system it will be slow too.  Single threaded per program is the safest on a NUMA system without tweaking.  Since 1 thread cannot not by mistake end up in two NUMA segments trying to sync data with each other.</p>
<p>Threading has a scale problem.  Very big system threading can equal slow.  NUMA segments is problem desktop users forget.  But when you have a large Linux thin client server NUMA segments do become a problem.</p>
<p>Linux costs about the same to start a new thread as start a new process.  New process is neater on NUMA stuff as long as what you are doing can operate that way.</p>
<p>So in some cases calc being able to fire off more than 1 process would be a god send(linux and os x users).  Ok when running on windows you would not want to do this.  Because windows is slow to start processes fast to start threads.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phenom</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92403</link>
		<dc:creator>Phenom</dc:creator>
		<pubDate>Wed, 25 Jul 2012 09:03:13 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92403</guid>
		<description><![CDATA[Ohio, I am in a particularly good mood today, so I read the first two paragraphs of you wall of text.  Unfortunately, the very first one is absolute crap.
 
&lt;i&gt;&quot;Multi threading is only useful faster if you don’t end up with more threads than the number of cores the processing system has and if the threads are not locking with each other attempting todo stuff. Switching between threads is not free.&quot;&lt;/i&gt;
The second statement is correct, but the first is just plain wrong.  Have you heard of cache misses?  Of branch mispredictions?  Heck, forget these, let talk even of very basic stuff like waiting for IO operations to complete.

Ohio, do you actually know anything of anything at all?  I start to doubt that you&#039;re truly aware of the exact whereabouts of your kitchen.

And please do not bother worrying about what I do understand and what I don&#039;t.  You are far from being the one to judge me. :-)]]></description>
		<content:encoded><![CDATA[<p>Ohio, I am in a particularly good mood today, so I read the first two paragraphs of you wall of text.  Unfortunately, the very first one is absolute crap.</p>
<p><i>&#8220;Multi threading is only useful faster if you don’t end up with more threads than the number of cores the processing system has and if the threads are not locking with each other attempting todo stuff. Switching between threads is not free.&#8221;</i><br />
The second statement is correct, but the first is just plain wrong.  Have you heard of cache misses?  Of branch mispredictions?  Heck, forget these, let talk even of very basic stuff like waiting for IO operations to complete.</p>
<p>Ohio, do you actually know anything of anything at all?  I start to doubt that you&#8217;re truly aware of the exact whereabouts of your kitchen.</p>
<p>And please do not bother worrying about what I do understand and what I don&#8217;t.  You are far from being the one to judge me. <img src='http://mrpogson.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phenom</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92402</link>
		<dc:creator>Phenom</dc:creator>
		<pubDate>Wed, 25 Jul 2012 08:57:09 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92402</guid>
		<description><![CDATA[Pogson, language features have nothing to do with instruction sets and versioning.  C# and Java have a handful of features which Pascal lacks - closures, lambdas, asyncronous constructions, just to name a few.  Other features, such as generics, came a bit too late.  Pascal was a fine language (in its Delphi incarnation) until 2000, after which it fell sadly behind.  Again, I speak of language features, which have nothing to do with instruction sets and versioning.]]></description>
		<content:encoded><![CDATA[<p>Pogson, language features have nothing to do with instruction sets and versioning.  C# and Java have a handful of features which Pascal lacks &#8211; closures, lambdas, asyncronous constructions, just to name a few.  Other features, such as generics, came a bit too late.  Pascal was a fine language (in its Delphi incarnation) until 2000, after which it fell sadly behind.  Again, I speak of language features, which have nothing to do with instruction sets and versioning.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: oiaohm</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92396</link>
		<dc:creator>oiaohm</dc:creator>
		<pubDate>Tue, 24 Jul 2012 23:15:15 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92396</guid>
		<description><![CDATA[Phenom
&quot;1) Excel scales better on multiple cores than Calc. Period. You may try to degrade this advantage as much as you can, but reality is that people need it.
2) Buying Excel is cheaper than developing a custom-tailored solution.&quot;

Your number 1 is not always true.  If you are processing many spreadsheets automated.  Calc wins.  Excel only wins if it being used by a human even then not in all cases.

Multi threading is only useful faster if you don&#039;t end up with more threads than the number of cores the processing system has and if the threads are not locking with each other attempting todo stuff.  Switching between threads is not free.

Phenom this is why I said performance gain talk about multi threaded is bogus.   Multi thread in the application has to be compared to multi process.  Depending on what you are doing depends if multi thread is any advantage at all or if multi thread is hindering.  So ideal is a spreadsheet program you can tell to be single threaded for particular usages and multi threaded for others.  single threaded when in multi process usage.  So process management can keep the number of threads to cpus aligned simpler so achieving higher overall performance in that case.

Phenom This is the problem threading is a double sided sword.  Helps in some cases hurts in others.

Result cache helps is almost all cases.

Phenom really you don&#039;t understand performance optimisation.  Anyone who does know that threading is not a magical save all in fact threading in application being wrong for how you need to use it will hinder performance.

The issue here is neither Excel or Calc in threading is ideal for all cases because neither has the means to change how they thread to suit the cases of use.

This is the problem Phenom you don&#039;t know this.  So you would be a person that would attempt to put Excel as a square peg in a round hole and wonder why it does not work right.

Your number 2 there is not always true and particularly for somewhere with 1000+ users.  If you are needing multi user access to the same set of results in real-time for best effectiveness.  Excel is dead in the water and you should have the same stuff done in either Oracle or Postgresql.

Total Cost of Ownership Phenom.  You need to understand when a Excel stops and something like Postgresql and Oracle starts.  Remember both of those can do every operation Excel does triggered as data enters them.  This is why its important to know that those two databases can do everything Excel can ok harder need more skilled stuff but can do it.  You will have usage cases where you should not be using Excel but should be using one of the highly powerful databases.

Any cost you save using Excel compared to custom-tailered solution can be offset by the fact the all users cannot access the information very quickly and each user is needing to either wait or recalculate themselves.  Individual recalculating can be processing time used of other more productive business operations.

The most common maths programming language used today is python.  Its not that slow.  The code produced is clean.

Phenom also how many copies of Excel do you need 100 dollar a pop by 200 users is quite a bit of money.  These governments are 1000 users+ at 100 dollars a pop.  Excel costing gets worse as you get larger.  Starts off small and cheep but you do reach a point where paying someone to write custom is cheaper than paying for MS Office to have Excel.

Also there is another problem when you have a 20 users all opening a excel document it only takes 1 to stuff it up.  Custom solution is also more data safe since you have better control over who modifies how to works.  Again this is a large business thing.

Phenom reality we are talking somewhere with a 1000+ users in a lot of cases at that scale Excel should be replaced with database solutions.  Up to about 500 users Excel is questionable but there might be a cost saving by using it.  Max for sure its right is about 10 users.  So somewhere between 10-500 users you should migrate to a database solution.

Phenom maybe you have never worked with 500+ or considered how much time is being cost because others cannot access the information in real-time you just entered into the spreadsheet.]]></description>
		<content:encoded><![CDATA[<p>Phenom<br />
&#8220;1) Excel scales better on multiple cores than Calc. Period. You may try to degrade this advantage as much as you can, but reality is that people need it.<br />
2) Buying Excel is cheaper than developing a custom-tailored solution.&#8221;</p>
<p>Your number 1 is not always true.  If you are processing many spreadsheets automated.  Calc wins.  Excel only wins if it being used by a human even then not in all cases.</p>
<p>Multi threading is only useful faster if you don&#8217;t end up with more threads than the number of cores the processing system has and if the threads are not locking with each other attempting todo stuff.  Switching between threads is not free.</p>
<p>Phenom this is why I said performance gain talk about multi threaded is bogus.   Multi thread in the application has to be compared to multi process.  Depending on what you are doing depends if multi thread is any advantage at all or if multi thread is hindering.  So ideal is a spreadsheet program you can tell to be single threaded for particular usages and multi threaded for others.  single threaded when in multi process usage.  So process management can keep the number of threads to cpus aligned simpler so achieving higher overall performance in that case.</p>
<p>Phenom This is the problem threading is a double sided sword.  Helps in some cases hurts in others.</p>
<p>Result cache helps is almost all cases.</p>
<p>Phenom really you don&#8217;t understand performance optimisation.  Anyone who does know that threading is not a magical save all in fact threading in application being wrong for how you need to use it will hinder performance.</p>
<p>The issue here is neither Excel or Calc in threading is ideal for all cases because neither has the means to change how they thread to suit the cases of use.</p>
<p>This is the problem Phenom you don&#8217;t know this.  So you would be a person that would attempt to put Excel as a square peg in a round hole and wonder why it does not work right.</p>
<p>Your number 2 there is not always true and particularly for somewhere with 1000+ users.  If you are needing multi user access to the same set of results in real-time for best effectiveness.  Excel is dead in the water and you should have the same stuff done in either Oracle or Postgresql.</p>
<p>Total Cost of Ownership Phenom.  You need to understand when a Excel stops and something like Postgresql and Oracle starts.  Remember both of those can do every operation Excel does triggered as data enters them.  This is why its important to know that those two databases can do everything Excel can ok harder need more skilled stuff but can do it.  You will have usage cases where you should not be using Excel but should be using one of the highly powerful databases.</p>
<p>Any cost you save using Excel compared to custom-tailered solution can be offset by the fact the all users cannot access the information very quickly and each user is needing to either wait or recalculate themselves.  Individual recalculating can be processing time used of other more productive business operations.</p>
<p>The most common maths programming language used today is python.  Its not that slow.  The code produced is clean.</p>
<p>Phenom also how many copies of Excel do you need 100 dollar a pop by 200 users is quite a bit of money.  These governments are 1000 users+ at 100 dollars a pop.  Excel costing gets worse as you get larger.  Starts off small and cheep but you do reach a point where paying someone to write custom is cheaper than paying for MS Office to have Excel.</p>
<p>Also there is another problem when you have a 20 users all opening a excel document it only takes 1 to stuff it up.  Custom solution is also more data safe since you have better control over who modifies how to works.  Again this is a large business thing.</p>
<p>Phenom reality we are talking somewhere with a 1000+ users in a lot of cases at that scale Excel should be replaced with database solutions.  Up to about 500 users Excel is questionable but there might be a cost saving by using it.  Max for sure its right is about 10 users.  So somewhere between 10-500 users you should migrate to a database solution.</p>
<p>Phenom maybe you have never worked with 500+ or considered how much time is being cost because others cannot access the information in real-time you just entered into the spreadsheet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Pogson</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92384</link>
		<dc:creator>Robert Pogson</dc:creator>
		<pubDate>Tue, 24 Jul 2012 15:00:52 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92384</guid>
		<description><![CDATA[Phenom wrote of PASCAL, &lt;em&gt;&lt;font color=&quot;green&quot;&gt;&quot;it is already far behing Java and C# in terms of functonality&quot;&lt;/font&gt;&lt;/em&gt;.

Just as ARMed CPUs don&#039;t need huge instruction sets to do everything, PASCAL does not need a huge repertoire to do everything. PASCAL is a general-purpose language designed to be almost minimal so that students could learn it rapidly. I taught the basics in 3 lessons. It has all the basic concepts: data types, variables, constants, assignments, looping and sub-programmes. I particularly like the strong type-checking which makes coding much easier when going from concept to implementation. The Free Pascal Compiler which I use also uses separate compilation of modules with strong type-checking so a programme of arbitrary complexity can be built. Compare that with the struggles over differing versions of Java or C compilers. I think it&#039;s silly that programmes need to be rewritten when a new version of a compiler comes out.]]></description>
		<content:encoded><![CDATA[<p>Phenom wrote of PASCAL, <em><font color="green">&#8220;it is already far behing Java and C# in terms of functonality&#8221;</font></em>.</p>
<p>Just as ARMed CPUs don&#8217;t need huge instruction sets to do everything, PASCAL does not need a huge repertoire to do everything. PASCAL is a general-purpose language designed to be almost minimal so that students could learn it rapidly. I taught the basics in 3 lessons. It has all the basic concepts: data types, variables, constants, assignments, looping and sub-programmes. I particularly like the strong type-checking which makes coding much easier when going from concept to implementation. The Free Pascal Compiler which I use also uses separate compilation of modules with strong type-checking so a programme of arbitrary complexity can be built. Compare that with the struggles over differing versions of Java or C compilers. I think it&#8217;s silly that programmes need to be rewritten when a new version of a compiler comes out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phenom</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92382</link>
		<dc:creator>Phenom</dc:creator>
		<pubDate>Tue, 24 Jul 2012 14:14:56 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92382</guid>
		<description><![CDATA[Pogson, I am worried.  Is having Ohio around in a forum contagious for the forum host?  Seems you have caught the eloquency from him.

You love for Pascal is charming, as it is a beautiful language, but it is already far behing Java and C# in terms of functonality.  Anyway, Pascal is head, shoulders, body and feet better than PHP, so you have my congratulations here.

Back to our topic.  
1) Excel scales better on multiple cores than Calc.  Period.  You may try to degrade this advantage as much as you can, but reality is that people need it.
2) Buying Excel is cheaper than developing a custom-tailored solution.]]></description>
		<content:encoded><![CDATA[<p>Pogson, I am worried.  Is having Ohio around in a forum contagious for the forum host?  Seems you have caught the eloquency from him.</p>
<p>You love for Pascal is charming, as it is a beautiful language, but it is already far behing Java and C# in terms of functonality.  Anyway, Pascal is head, shoulders, body and feet better than PHP, so you have my congratulations here.</p>
<p>Back to our topic.<br />
1) Excel scales better on multiple cores than Calc.  Period.  You may try to degrade this advantage as much as you can, but reality is that people need it.<br />
2) Buying Excel is cheaper than developing a custom-tailored solution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Pogson</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92378</link>
		<dc:creator>Robert Pogson</dc:creator>
		<pubDate>Tue, 24 Jul 2012 13:24:08 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92378</guid>
		<description><![CDATA[Phenom wrote, &lt;em&gt;&lt;font color=&quot;green&quot;&gt;&quot;Since when does it cost $0 to hire a programmer to write your custom-tailored application?&quot;&lt;/font&gt;&lt;/em&gt;

It does not cost $0 to hire a programmer. Neither does it cost $0 to hire a spreadsheet programmer. There are a lot of bad spreadsheets out there because ordinary users are tempted to create spreadsheets and they have no idea about scalability. I was once involved in a school system where a teacher had contributed a spreadsheet to replace the paper register of attendance. The PHB thought it was wonderful and ordered it to be used system-wide. He wanted a master spreadsheet at HQ that could be copied and pasted from every teacher&#039;s stack. It was an unmitigated disaster because the original was deeply flawed in scalability. For example, it assumed 20 students maximum per class when that was the average class-size in the organization. Teachers scurried to add rows whereupon all kinds of linked cell-references failed. So, instead of using a convenient new tool, every teacher was put to work debugging this thing and producing a local version which could not be merged nicely at HQ... That was the end of that. It probably cost tens of $thousands because no one had the correct vision. I talked to the originator who later moved into my position when I left. He had offered it as a proof-of-concept rather than a working copy but the PHB cast it to the wind. Now compare that experience with what would have happened with the database riding on a server at HQ from the beginning. We all had a fine and redundant WAN. For one tenth the effort a good system could have resulted. Instead they reverted to paper.

PHP is only one layer in the stack. The big bottleneck with spreadsheets is not the storage access or speed of computing it is the scrolling and click-time of the GUI. Rembrandt did not paint masterpieces peeking through a keyhole. PHP is far faster than a human. I would use PASCAL however.]]></description>
		<content:encoded><![CDATA[<p>Phenom wrote, <em><font color="green">&#8220;Since when does it cost $0 to hire a programmer to write your custom-tailored application?&#8221;</font></em></p>
<p>It does not cost $0 to hire a programmer. Neither does it cost $0 to hire a spreadsheet programmer. There are a lot of bad spreadsheets out there because ordinary users are tempted to create spreadsheets and they have no idea about scalability. I was once involved in a school system where a teacher had contributed a spreadsheet to replace the paper register of attendance. The PHB thought it was wonderful and ordered it to be used system-wide. He wanted a master spreadsheet at HQ that could be copied and pasted from every teacher&#8217;s stack. It was an unmitigated disaster because the original was deeply flawed in scalability. For example, it assumed 20 students maximum per class when that was the average class-size in the organization. Teachers scurried to add rows whereupon all kinds of linked cell-references failed. So, instead of using a convenient new tool, every teacher was put to work debugging this thing and producing a local version which could not be merged nicely at HQ&#8230; That was the end of that. It probably cost tens of $thousands because no one had the correct vision. I talked to the originator who later moved into my position when I left. He had offered it as a proof-of-concept rather than a working copy but the PHB cast it to the wind. Now compare that experience with what would have happened with the database riding on a server at HQ from the beginning. We all had a fine and redundant WAN. For one tenth the effort a good system could have resulted. Instead they reverted to paper.</p>
<p>PHP is only one layer in the stack. The big bottleneck with spreadsheets is not the storage access or speed of computing it is the scrolling and click-time of the GUI. Rembrandt did not paint masterpieces peeking through a keyhole. PHP is far faster than a human. I would use PASCAL however.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kozmcrae</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92376</link>
		<dc:creator>kozmcrae</dc:creator>
		<pubDate>Tue, 24 Jul 2012 13:18:08 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92376</guid>
		<description><![CDATA[Phenom wrote:

&quot;And since when is programmer’s work free?&quot;

Do you mean programming a spreadsheet?

The problem with spreadsheets is that they are so versatile.  It&#039;s okay to apply that versatility to small to medium sized spreadsheets.  But when those spreadsheets grow into monsters they become an unmanageable mess.  That&#039;s when the spreadsheet should be broken down into manageable pieces.  

Unfortunately the person or group that created the monster spreadsheet is often unwilling to let go of their creation.  The spreadsheet is their baby that no one else knows how to manage because it&#039;s so complex.  That helps to keep their job safe.  They hold the keys to the data with their monster spreadsheet.  I&#039;ve seen this situation with my own eyes.]]></description>
		<content:encoded><![CDATA[<p>Phenom wrote:</p>
<p>&#8220;And since when is programmer’s work free?&#8221;</p>
<p>Do you mean programming a spreadsheet?</p>
<p>The problem with spreadsheets is that they are so versatile.  It&#8217;s okay to apply that versatility to small to medium sized spreadsheets.  But when those spreadsheets grow into monsters they become an unmanageable mess.  That&#8217;s when the spreadsheet should be broken down into manageable pieces.  </p>
<p>Unfortunately the person or group that created the monster spreadsheet is often unwilling to let go of their creation.  The spreadsheet is their baby that no one else knows how to manage because it&#8217;s so complex.  That helps to keep their job safe.  They hold the keys to the data with their monster spreadsheet.  I&#8217;ve seen this situation with my own eyes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: oiaohm</title>
		<link>http://mrpogson.com/2012/07/20/another-city-switching-to-libreoffice/#comment-92372</link>
		<dc:creator>oiaohm</dc:creator>
		<pubDate>Tue, 24 Jul 2012 12:48:20 +0000</pubDate>
		<guid isPermaLink="false">http://mrpogson.com/?p=13306#comment-92372</guid>
		<description><![CDATA[Phenom sorry PHP and ASP.Net depends on setup.  Hiphop php used by facebook runs rings around Asp.Net.

PHP is only slow when used particular ways.  PHP after the compliers of it is one of the fastest languages you can use for server-side.  Also hiphop will not build some of the more suspect php in existence.

My other comment is still missing about postgresql and pl/python and its addons for nice powerful maths processing.

Phenom
&quot;And since when is programmer’s work free?&quot;
When the programmer is on staff doing it in time between jobs.

Yes that IT officer you have in some businesses manning the helpdesk.  He can be coding as well.

Lot of businesses pay people to sit places doing nothing when jobs like doing us something to improve overall effectiveness should be going on.]]></description>
		<content:encoded><![CDATA[<p>Phenom sorry PHP and ASP.Net depends on setup.  Hiphop php used by facebook runs rings around Asp.Net.</p>
<p>PHP is only slow when used particular ways.  PHP after the compliers of it is one of the fastest languages you can use for server-side.  Also hiphop will not build some of the more suspect php in existence.</p>
<p>My other comment is still missing about postgresql and pl/python and its addons for nice powerful maths processing.</p>
<p>Phenom<br />
&#8220;And since when is programmer’s work free?&#8221;<br />
When the programmer is on staff doing it in time between jobs.</p>
<p>Yes that IT officer you have in some businesses manning the helpdesk.  He can be coding as well.</p>
<p>Lot of businesses pay people to sit places doing nothing when jobs like doing us something to improve overall effectiveness should be going on.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
