Mono staff laid off and Logos
With Attachmate laying off its Mono staff, what does that mean for Logos on the Mac if anything?
Mono has been a concern of mine from the inception of the Logos for Mac. In addition to its slowness, if major development ceases, does that mean Logos for Mac becomes an orphan product?
Comments
-
The report that Attachmate is laying off Mono staff, so far as I know, remains unconfirmed and traces its roots to an article on Internetnews that is very sparse on details. However, even in the event of a layoff of all Mono staff, it is doubtful that "major development" would cease, as there is still an active community around the product—even in the very worst case, the source remains open, and we can do what we need to with it.
0 -
I think it's pretty safe to say that Mono as a significant, or relevant, platform moving forward is dead.
http://www.phoronix.com/scan.php?page=news_item&px=OTQwMQ
It was never really a typical open source project, it was always backfunded by Novell (who were most likely being backfunded by Microsoft) the Mono guys just haven't realised it's over yet — looking at their website http://www.mono-project.com/Main_Page which still has Novell plastered all over it.
There hasn't been a peep out of Miguel de Icaza since May 4, he most likely got the chop from Novell, along with every single Mono developer, when Attachmate bought it.
Do you really believe that a weakly supported technology like Mono is a strong enough platform to bet Logos for Mac on moving forward? Logos should really consider this and perhaps think of a mid-to-long term strategy to migrate to native OS X technologies — which could only help improve it performance wise.
"I want to know all God's thoughts; the rest are just details." - Albert Einstein
0 -
Patrick S. said:
I think it's pretty safe to say that Mono as a significant, or relevant, platform moving forward is dead.
I wouldn't be so quick to make such a declaration. While it does appear that the Mono team has been laid off, they've also secured funding to start a new company (http://tirania.org/blog/archive/2011/May-16.html). I expect that their independence from Attachmate/Novell/SuSE/Ximian will accelerate the pace of the project.
As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it [;)].
David Mitchell
Development Lead
Faithlife0 -
David Mitchell said:Patrick S. said:
I think it's pretty safe to say that Mono as a significant, or relevant, platform moving forward is dead.
I wouldn't be so quick to make such a declaration. While it does appear that the Mono team has been laid off, they've also secured funding to start a new company (http://tirania.org/blog/archive/2011/May-16.html). I expect that their independence from Attachmate/Novell/SuSE/Ximian will accelerate the pace of the project.
Well good luck to them (he must have posted that blog posting one minute after I posted here) — I hope the execution matches the intention. As the saying goes "time will tell".
David Mitchell said:As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it
.Tsk, tsk — you're getting tichy again, I seem to bring that out in you [:P]
David Mitchell said:As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code.
Now that admission can be interpreted in two ways... anyhow I'm pleased (truly) that the team has been able to identify areas to improve L4. It can't be easy reading many of the forum postings about performance, I'm still hanging in there and buying new titles from Logos!
"I want to know all God's thoughts; the rest are just details." - Albert Einstein
0 -
David Mitchell said:
As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it
.How many of us can profile your code? and of those how many can flag Mono-related hotspots? [but there do seem to be many software people on the forum]
0 -
Patrick S. said:David Mitchell said:
As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it
.Tsk, tsk — you're getting tichy again, I seem to bring that out in you
Yes, indeed. My apologies if I've crossed a line.
David Mitchell
Development Lead
Faithlife0 -
David Ames said:David Mitchell said:
As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it
.How many of us can profile your code? and of those how many can flag Mono-related hotspots? [but there do seem to be many software people on the forum]
The comment was less of a practical suggestion and more of a reminder that it is difficult to make an accurate assessment of what causes performance problems without hard data. If you search the forums, you'll find that this is not the first time Patrick and I have had such a discussion [:)].
David Mitchell
Development Lead
Faithlife0 -
David Ames said:David Mitchell said:
As far as your performance concerns, we've actually found that the most fruitful areas for improvement have been in our native code. However, if you've profiled our app and can show me where the Mono-related hotspots are, I'll get right on it
.How many of us can profile your code? and of those how many can flag Mono-related hotspots? [but there do seem to be many software people on the forum]
While many Logos 4 users lack code profiling skills, being able to describe repeatable slowness items, which can include screen shot(s) and video showing slowness allows other Logos users to confirm slowness repeatable (e.g. scrolling resources).
With repeatable case(s), those with profiling skills can analyze where time being spent to locate performance/thru-put bottleneck(s). Like manufacturing, improving performance for one bottleneck then exposes bottleneck(s) elsewhere. Eliyahu M Goldratt and Jeef Cox wrote "The Goal: A Process of Ongoing Improvement" => http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271781/ref=sr_1_1 as a novel about the theory of constraints.
Simple math: Response Time = Service Time + Wait Time
Performance challenge is reducing response time.
Keep Smiling [:)]
0 -
{To Patrick} Tuning [SQL] database software is an ART. One [what looks like a] minor change and run times change from seconds to minutes. AND identical code does NOT run the same on different versions of SQL – Change compilers or database management programs [and sometimes running the same query on what seems to be identical database structures] and sometimes you have to retune every query – FUN!
{To David} Did not know of the David / Patrick [hopefully friendly] “”feud””.0 -
Some good news:
0
