cassandravoiton

There is already a lot of mainframe offload. It seems that the middle range of mips is the sweet spot. Taking advantage of the services systems like JBOSS gives is, quite possibly, the last piece in the puzzel.

Ha! I use it all the time. Just the other day someone asked what this mixed windowing system was - I just explained and they say Doh!

Darn - commented in the wrong place - now I say Doh.

Ha! I use it all the time. Just the other day someone asked what this mixed windowing system was - I just explained and they say Doh!

Whilst I agree with the point that Linux UIs are not great - that has nothing what so ever to do with Linux. Linux knows nothing about the UI layer which is all X11. There is no need to replace the OS to get a better UI.

More to the point - who cares. All these languages are hopelessly slow. If performance matters do it in a performant language like C++, C or FORTRAN. If it does not matter - then it does not matter and so stop going on about it.

Sounds like a challenge. Should be do-able in managed COBOL using delegates.

Closures as continuations in C++, maybe Stroustrup was right when he said it looks like a completely new language.

You have not been looking at scientific computing. Matlab is more something people used for comp-sci of math. If it was not FORTRAN then it was not scientific computing.

You shoot down our own argument. The video suggest C# and Java as alternatives to interpreted languages. By picking C you are deliberately trying to make your argument sound stronger than it is. The video also mentions the economic cost.

From an economics point of view you are just wrong. Because of the vast numbers of computers used in 'scale out' architectures the impact of code efficiency is enormously bigger than the cost of developers. If a developer's code runs on 10 or 100 machines then you are correct. But modern software runs on hundreds or even hundreds of thousand machines.

If code runs faster then the user time is wasted less as well. That seems in alignment with the ideas behind the video.

Yes - HTML5 would be much much better - it will come soon I expect.

The page below shows the media peformance of Python (the fastest in these of PHP/Ruby/Python) as 49.73 times slower than the fastest compiled language. The seems pretty much between 10 and 100 to me.

http://shootout.alioth.debian.org/u64q/which-programming-lan...

 	compare 2	 |-	 |---	 25%	median	 75%	 ---|	 -|

There are plenty of bench marks showing 10 to 100 times is in the ball part. Computers use masses of power because there are so many of them. As they get more efficient, their numbers increase. The benefit of using faster languages is constant irrespective of the efficiency of the machine on which it is running. How can wasting energy be OK? Even if you don't think it has climate change effects, it has economic and energy security effects - non of them good.

But is that not the point of the post - that all the 'easy and cheep' comes at a huge cost to be planet and eventually to the company. Are C# and Java really that much harder to learn and use?

Can you fail to deliver something if there is no time in which the failure can occur? Not sure...

Actaully - they don't. I spent some time working with Oracle at a major installation where they could not come up with a good enough transactional fail secarios because a single mainframe was being replaced by a multiple DB node distributed system.

Oddly - the project failed...

Just because a large company says they do something - does not mean they actually do. Distributed Transcation as said by RDBMS companies actually is 'Distributed as long as nothing goes wrong'.

I see your point. However, if information transfer is actually infinitely fast then the to physical points become one point in information space and the two generals become one general.

Language gets in the here. But all 'distributed transaction' systems rely on the idea that once every party has agree to commit, it CAN commit. That might not be the case (I have seen it no be so often).

Yes, I did read it... "

In practice, it is not di±cult to construct an algorithm that, except dur- ing rare periods of network instability, selects a suitable unique leader among a majority of nonfaulty acceptors. Transient failure of the leader-selection algorithm is harmless, violating neither safety nor eventual progress. One algorithm for leader selection is presented by Aguilera et al. [1] "

" The algorithm satisfies Stability because once an RM receives a decision from a leader, it never changes its view of what value has been chosen "

Fundamentally, the idea is that the leader is the transactional arbitrator using the RM as the recorder of that transaction.

If it is so obvious, why do so may people no get it?

You, sorry to say, utterly incorrect. The Paxos algorithm offers a clever way to making the choise of a single transactional arbitrator dynamic. For each transaction, it might be different, but for a single transcation, Paxos is only stable if the transactional co-ordinator is stable. if the network fails then an unknow state can be achieved and the entire system will have to restabalize to the values held in the single co-ordinator for the broken transaction.

So the single server is the transactional arbitrator. Nice :)

Which is why I wrote the post. I go fed up with repeating myself as people demanded the same of me!

The two generals problem has the assumption of finite communication speed as its foundation. So, to fails if one does have infinite communication speed. This post shows how the assumption is indead correct.

You are way off the mark here. How do you propose to use a resource lock to solve the distribution problem?

Hiya, I went and looked this up for you:

" Intel segmented memory

This usage should not be confused with that of the x86 memory segmentation used by early Intel processors such as the Intel 8086 and Intel 8088, as they did not provide any protection. Any program could access any segment with no restrictions, and a segment consisted of only a starting location and a fixed length of 64 KiB. Segmentation in the Intel 80286 and later provided protection. "

I think Dr Turner's description of segments is a bit rough and ready; I guess he was just trying to make the post simple.

I am glad you have now learned something then :)

SEGV has nothing what so ever todo with Intel 8088 address management. The name 'segment' just got used twice.

I think it is a philosophy thing was well. Latency and network speed are key Unix heratige features which carry over to Linux. Windows has always considered this as something we should do, but not core.

So that is how they work. What else can se find out by looking at the byte output of javac?