Hmm. I guess the fact that java* has been working just fine on mobile devices from a decade ago bears no relevance to discussion I guess? Can we please stop mixing up the java APIs (and some of them do contain horrible bloat), "libraries" (but nobody really forces you to build your app around that 30MB OpenGL/DirectX software renderer), and the language itself (that allows to implement memory-copy-less networking stacks, in example, and once you've cleaned your critical execution paths from needless memory allocations (just like you would do in C/ASM) runs like a charm)?
*J2ME - java w/o reflections and with a trimmed down API.
Unless you want to get down and digging into mallocs Java works just fine. And as long as your little tetris clone doesn't depend on spring webapp supplying the board representation each frame to canvas via CORBA on localhost (can be done, can actually be done...) will probably won't differ all that much from what can be done by writing the app in assembler.
And if you really are incapable writing code that doesn't feed off heap constantly - you can develop in C on android as well.
Well, perhaps he's a rational person who can objectively see that US is run by a highly belligerent, insurgency-supporting, terror-financing, arms-smuggling, mysoginistic, medieval-minded, brutally theocratic asshat of a regime willing to rig elections and kill its own protesting people in order to stay in power while it builds nuclear weapons and regularly thump its chest about wiping other countres off the map. Perhaps that's a good reason to tell people who sell sophisticated weapons manufacturing technology to not make life any easier for those clowns.
Well, on the other hand if they start dropping nukes on each other - sure, it'll be messy for a moment, but think of it - no more Israel, no more Iran, the rest of the region sufficiently scarred not to feel like messing around for a while...
I think that was exactly the parents point. Shuttle was initially sold as reusable platform that will be oh so cheap once you'll average the initial cost over the projected lifetime.
It is. It's just that there's too many valid and acceptable ways to do this and therefore there are way too many egos involved to actually agree on doing something.
LSE is NOT a real time system (in the definition of guaranteed execution time for given volume) therefore there is nothing that would prevent it from being run from wine indeed;) Even the record is the best case scenario, they were quoting approx 2x-3x that as a median.
(obviously that doesn't mean that the systems haven't been writen with care avoiding allocations in critical loops, probably using rolling buffers liberaly and running it on a modified kernel with BKL finally removed and yummy predictable O(1) scheduler developed in-house.)
Itanium was being phased out and isn't really well supported by latest centOS kernels*.
*Joking, joking. Regardless, whatever they had couple of years ago probably was overdue to be replaced anyway. And these kinds of latencies suggest that they are using something a bit more interesting than Client For Microsoft Networks over poorly terminated thinwire ethernet in their datacenter.
The trouble is that in server workloads you generally don't see ONE LARGE I/O operation - lots of small ones instead. There are very very few server workloads that involve transferring >100MB data at a time (even when it comes to DB snapshoting). On the desktop this is common (all your AVI files).
Scheduler has to find a balance between allocating large enough slices of CPU time so that system isn't slowed down to a crawl due to context switching/missed cache hits/spinning between actually idle tasks while keeping them short enough so that somebody using the system doesn't notice the latency when his process has a chance to draw pretty terminal texts/pictures.
It's a tricky balance for a large number of technical and psychological (ooh, a benchmark) reasons.
Don't blame java for that...
Hmm. I guess the fact that java* has been working just fine on mobile devices from a decade ago bears no relevance to discussion I guess?
Can we please stop mixing up the java APIs (and some of them do contain horrible bloat), "libraries" (but nobody really forces you to build your app around that 30MB OpenGL/DirectX software renderer), and the language itself (that allows to implement memory-copy-less networking stacks, in example, and once you've cleaned your critical execution paths from needless memory allocations (just like you would do in C/ASM) runs like a charm)?
*J2ME - java w/o reflections and with a trimmed down API.
As opposed to what? Python? Ruby? PHP?
Unless you want to get down and digging into mallocs Java works just fine. And as long as your little tetris clone doesn't depend on spring webapp supplying the board representation each frame to canvas via CORBA on localhost (can be done, can actually be done...) will probably won't differ all that much from what can be done by writing the app in assembler.
And if you really are incapable writing code that doesn't feed off heap constantly - you can develop in C on android as well.
you mean like rather just announced and released hardware risks to break compatibility with what - 18+ months old platform? Shocking!
and who cares? Remember PIII?
And they will reply to you describing their great value deals of the week.
And US has never supported 'worst regimes in the world' right?
Couldn't resist to FTFY:
Well, perhaps he's a rational person who can objectively see that US is run by a highly belligerent, insurgency-supporting, terror-financing, arms-smuggling, mysoginistic, medieval-minded, brutally theocratic asshat of a regime willing to rig elections and kill its own protesting people in order to stay in power while it builds nuclear weapons and regularly thump its chest about wiping other countres off the map. Perhaps that's a good reason to tell people who sell sophisticated weapons manufacturing technology to not make life any easier for those clowns.
Well, on the other hand if they start dropping nukes on each other - sure, it'll be messy for a moment, but think of it - no more Israel, no more Iran, the rest of the region sufficiently scarred not to feel like messing around for a while...
I think that was exactly the parents point. Shuttle was initially sold as reusable platform that will be oh so cheap once you'll average the initial cost over the projected lifetime.
Didn't turn out that way.
if classified, it would be CIA. FBI has nether mandate, nether authority to declare anything 'classified'.
100mph. It's actually 160kmh.
Anybody is actually hiring students these days?
It is. It's just that there's too many valid and acceptable ways to do this and therefore there are way too many egos involved to actually agree on doing something.
Hmm... Will 5G do?
Catchy, cool and best of all - perfectly fine to use*.
*Until somebody bothers to define it and we have to move on to more Gs' again.
United States are a superpower? Ghmm, somebody please tell China that the fatties are getting all worked up and ambitious again...
Oh yeah, I recall you from that chat. Keep up the good job!
LSE is NOT a real time system (in the definition of guaranteed execution time for given volume) therefore there is nothing that would prevent it from being run from wine indeed ;) Even the record is the best case scenario, they were quoting approx 2x-3x that as a median.
(obviously that doesn't mean that the systems haven't been writen with care avoiding allocations in critical loops, probably using rolling buffers liberaly and running it on a modified kernel with BKL finally removed and yummy predictable O(1) scheduler developed in-house.)
Ah, but do you demand payment upfront or extend credit?
Itanium was being phased out and isn't really well supported by latest centOS kernels*.
*Joking, joking. Regardless, whatever they had couple of years ago probably was overdue to be replaced anyway. And these kinds of latencies suggest that they are using something a bit more interesting than Client For Microsoft Networks over poorly terminated thinwire ethernet in their datacenter.
small writes to any kind of flash memory (especially the cheap kind used in flash drives) will be slow and crappy due to the flash memory design.
I use both. (And more) ...for their respective uses. Windows for GUI and day to day use, linux for getting number crunching work done.
If only X11 would be finally killed...
Not from command line. This is how a fair amount of serious 'no-data-loss allowed' software operates.
The trouble is that in server workloads you generally don't see ONE LARGE I/O operation - lots of small ones instead. There are very very few server workloads that involve transferring >100MB data at a time (even when it comes to DB snapshoting). On the desktop this is common (all your AVI files).
Scheduler has to find a balance between allocating large enough slices of CPU time so that system isn't slowed down to a crawl due to context switching/missed cache hits/spinning between actually idle tasks while keeping them short enough so that somebody using the system doesn't notice the latency when his process has a chance to draw pretty terminal texts/pictures.
It's a tricky balance for a large number of technical and psychological (ooh, a benchmark) reasons.
Eeehm... The war in Iraq has nothing to do with 9/11. Why are you trying to connect these two?