A canvas, to be useful, needs a whole lot of supporting code. If you go the whole nine yards, you end up with an application development toolkit like Qt. Suppose you have some text that needs editing on the canvas. Do you really want to implement text editing GUI yourself? While this may be simple for a fixed width font, things get tricky with kerning and multiple formattings, and you start getting sidetracked a lot when your right-to-left locale customers complain that nothing works.
Qt's QGraphicsView is the canvas widget you're looking for; your items would derive from QGraphicsItem. About the only shortcoming of that subsystem is that there's no built-in support for interaction-independent views of the same scene. You can have multiple views of the same scene, but all they differ with is the viewport transformation. Thus you can't have, for example, different objects selected in different views of (windows into) the same scene, and you can't edit something in one view, stop, edit something else in another view, then come back to the first view -- both selection and focus is per-scene, not per-view like needed in such scenario.
I don't know offhand of any generic 2D canvas system that would come anywhere close to implementing a per-view interaction context -- the latter consisting at least of the selection, focus, and user-interaction elements (such as handles, pop-up menus, whatnot). Qt's canvas is perhaps the most feature-laden canvas of them all anyway, in spite of the above limitation.
Kinect doesn't do body tracking. It only provides an image with depth information, a tracking library on XBox does the model fitting and provides the estimated body configuration via an API.
I know about it being sterile when it's just about to leave the urinary tract, but pissing cows, especially females, don't exactly keep the urine stream from contacting dirty stuff. Never mind that urine is fodder for some microorganisms -- try peeing in your toilet every evening, and flush in the morning. A week of that and you'll get nice growth of something there.
Unfortunately, Kasich, in all of his miguided non-wisdom, just happens to be -- by chance -- right about the CCC rail as proposed. It's doomed to failure. CCC has several problems, the most glaring IMHO are:
1. Poor connectivity -- the rail should be tightly integrated into the non-existent local transit. In the absence of the latter, it needs to provide the local-level transit segment as well.
2. Speed: I'd certainly pay $75-$100 one way just to go to Cinci or Cleveland for, say, a concert, but the trip should take 2 hours tops each way.
3. Reuse of insufficient infrastructure: a new project like that can't just be based on freight tracks that were designed and originally laid 50-75 years ago IIRC.
4. Inefficient construction methods: there needs to be prefabrication of everything. Think some sort of a precast elevated monorail segment with infrastructure, modular station and support buildings, pylons with supports for varying soil types, etc. It's horribly inefficient to move all that soil just so that a track can be laid or replaced. This also addresses 1: we can get the track right into downtowns when it's elevated.
5. Park-and-ride needs to be on both ends of the trip: the rail company needs to provide a Zipcar-style service so that people won't be stranded at the destination. This can be done more efficiently than simply offloading this onto rental car companies. One should be able to have a single, reloadable, identifying smart card that allows boarding the train and renting the car -- ideally with as much hassle as it takes to walk from a mall store back to the parked car.
Such a project, with proper funding, could become a pilot with multiple nationwide deployments, and could be successful. But it can't be just a short-funded reuse of existing crap. Rail has to evolve, reusing the century old way of engineering it is a horrible misuse of resources. Current technology allows us to do way more and way better. CCC would need a complete from-scratch re-engineering of every aspect of the infrastructure and operations. Otherwise it's just too little, too late.
Tried that in Swiss Alps when we, um, under-budgeted the water for the hike. We were lucky there were no cows pissing upstream, or that the cows were healthy;)
I think that the time is ripe to have full authentication of each network node in corporate/campus environments. 802.1X FTW. This of course raises the bar for spoofing only somewhat: if you have physical access to someone else's machine (think helping out a 'friend'), then you can copy the certificates and private keys. Then the spoofee is in even more trouble: it'd be so much harder to convince a jury that the spoofing took place.
Oh boy. Look, all generators that are tied into the grid have to be spinning and synchronized unless they feed a DC transmission line. Synchronization in a legacy powerplant may take say half a day, so you can't just stop the machinery and restart it when you want to -- true.
When a generator is running and synchronized, the rotational speed is pretty much constant. Then the torque at the shaft between the turbine and the generator is proportional to the load power. As the load power goes down, you decrease the steam pressure, and the torque goes down to match that. The voltage on the output can be kept quite constant as long as you have proper control systems -- it used to be hard when things were adjusted manually or with simple PID controls, but nowadays you can have an optimal controller that will fully exploit the operational envelope of the plant. An additional factor is load balancing between powerplants.
A generator is typically followed by a step-up transformer system, and those have switchable taps that are used to do additional voltage regulation.
In nuclear-powered plants, I presume it's easy to dump full rated power into the cooling system. While it's inefficient, you should be able to idle the generators while the reactor is at 100% thermal power output. In normal operation you have to dissipate 30-50% of heat output anyway, so it's not like doubling or tripling the cooling demand is a big deal, IIRC.
This is ridiculous. A 3D printer is like a good CNC machining center, just cheaper. A modern multiaxis machining center is just like a 3D printer, but with better resolution, and with limits as to how weird the shapes it can make -- a 3D printer can make a bunch of concentric spherical shells (each with a hole in it to drain the unfused material), a CNC can't. So whatever court verdict outlaws 3D printers, it will automatically make all of U.S. manufacturing grind to a halt (whatever is left of it). Do the U.S. patent holders really want to rid us of whatever manufacturing capability remains?
For those who haven't experienced a CNC machining center: those are nothing like a hobbyist CNC lathe or mill. They are huge (room+ sized) multiaxis machines, sometimes with dozens axes when you combine the stock positioning, stock clamping, tool positioning, tool exchange, etc. The typical process to make a keepsake figurine on a CNC machining center goes like:
- convert 3D model to whatever format your CAM software digs, - select a couple of tools (usually with progressively smaller radii), - have the CAM software generate tool paths from the model, check for interferences, etc. - install stock & tools in the machining center, upload the file, hit the RUN button on the control panel
Something must be broken then in your setup somewhere, because I use a Time Capsule, recently upgraded from 500GB to WD Green 2TB, and never had a single data loss/corruption issue. I'm using it with a MBP and an iMac, and have used it with OS X 10.5, and now 10.6. Not a single problem, apart from running out of room on the 500GB drive and having to upgrade.
It all begins in target classification. If the anti-missile system was programmed to ignore outbound targets launched at close range, then you'd get exactly what we saw.
Simple. Use some intermediate representation that's JIT-compiled by a trusted compiler. The whole thing can be set up so that it's mathematically provable to be safe -- as in one process not being able to corrupt other processes, nor access resources it's not authorized to. No need for MMU for process isolation. MMU would still be of advantage if you needed to implement some VM features -- think mmapped files.
IMHO Java needed to have been spun off long time ago into a small company whose core focus would be just Java. Pretty much duplicating Trolltech's focus, dedication and agility. Not only would it be self-funding, I'd be quite happy to pay for Java: I'd get my money's worth, just like I used to pay for Qt. Sun had entirely too much overhead to let Java flourish. Java can support a small company: say 100-200 people, focused only on one product. Something the size of Sun? Not so much. Java could be monetized, just not by a big corporation. There is room for small, focused businesses doing what they do best. I somewhat dislike that Nokia took over Trolltech: sure the original owners/investors got their money's worth, but IMHO Qt lost out on it.
The difference is that with Qt you at least used to get your money's worth -- there was way to get bugs mostly fixed, features got implemented, you could get real help. You pretty much knew what you were paying for. And they have this clause that any code developed under GPL cannot be transferred over to commercial license; some argue that it's unenforceable but that's what you have.
Good luck getting any of that from a behemoth the size of Oracle. Paying for Java is merely a way of corporate CYA, it's useless otherwise.
The major deal I see is that the gap between library availability for Ocaml and that of F# is only widening. Reversing that would need lots more resources thrown at Ocaml. As long as Ocaml is used in a niche where you don't care much for the libraries, that's OK. But it won't come into widestream use without libraries. And I won't even start about Ocaml's standard library -- it's kind of a joke. Sure, I know there are replacements, but with.NET you don't have to worry about it.
I think you are entirely misdiagnosing the problem.
The motors generate a back-EMF simply because they are turning. You don't need to have anything attached them at all. If the intra-winding insulation on the motors were to fail due to overvoltage, you'd achieve that without anything attached to the motors -- spin them fast enough, insulation breaks down, windings short together and start dissipating mucho power, flames shoot out. Try it out: disconnect the motors, hook the output to a voltmeter (via a fuse!, you don't want a short in the voltmeter to blow in your face), run down the hill (assuming there's a separate brake system available).
Since, as you claim, you have to "kick it [the drive electronics] in" at about 30MPH for the flames to shoot, it's not due to overvoltage *in the motors*. Likely there is an overvoltage crowbar in the drive electronics that shorts the motors temporarily when the voltage is too high. This causes huge power dissipation and self destruction of the motors. Any insulation breakdown is a secondary effect from overheating, not the primary cause IMHO.
I reiterate that a typical electrical motor's insulation system should withstand 2-3x overvoltage with no adverse effects. The way you test it is by applying a test voltage from a hipot tester between the windings and the case.
Even if you get insulation breakdowns, the common thing that would break down in a properly designed and manufactured motor is the winding-to-case insulation. Any drive system worth its salt should detect such a condition and disconnect itself from the motor -- thus no damage done. In a brushed motor, the commutator or sliprings may well break down first -- that's pole-to-pole and not pole-to-case
The only way an overvoltage-due-to-overspeed on an electric motor will damage *insulation* is when you have very poorly designed windings. Perhaps the motors were rewound by someone without a clue?
I'd expect most electric motors to get mechanical damage from overrevving way before there's any electrical damage in the motor itself. Perhaps a dirty commutator or dirty sliprings will break down and catch fire, maybe, but I'd think that's rare if the motor works well at rated voltage. Now if the drive system decides to fry the motor, like what you're telling me implies, that's another story -- just don't blame winding insulation for that.
While true, you're disingenuous. The static code verification tools developed by MS are hardly crap. They are on the forefront of what's available for static analysis of C/C++ code.
I'd say that for all practical purposes, at least in my limited testing, the performance you get from the code running on CLR is not appreciably worse from what you get with OCaml's native code, so I don't see any real benefit of OCaml's native code over code running on CLR. I've found plenty of cases where CLR outperforms OCaml by an order of magnitud -- basically as soon as you use OCaml to the fullest, plenty of POD stays boxed, and everything goes downhill from there.
I read caml-devel like you do, so the only thing I can make out of your post is that ocaml's issues are not all that important to your use of it at Redhat. And I'm fine with that, but again -- it's a niche use. As for important areas: sure, I agree, after all F# came up from MS's own use of Ocaml!
It's not like the layers of abstraction change over time. The latency one experiences is random: it depends on what pages are in memory at the instant you try to do something, and perhaps to some extent on the locks held by code currently paged out due to memory pressure (if there's such a thing).
Basically, whatever is due to abstraction is the best case. If you can see that menus switch in 10ms, that's the best case, and to improve that you need to make the code more CPU-efficient. Everything else implies that you're I/O bound.
I have been seen tests with DDR2-based ramdisks and running systems that don't use anything else: guess what -- CPU utilization bursts always reach 95%, and there's no latency to speak of.
An acquaintance has a Mac Pro with 6G of ram, that he runs off a 64 GB DDR2 ramdisk dedicated to the OS and Applications, data files are stored on a separate RAID. The machine feels unreal. Running a purpose-made memory hogging process, that would cause it to swap for 1-2 hours until OOM handler kicks in when run off a spinning platter drive, merely causes a noticeable slowdown that feels like the CPU's clock was throttled back by a factor of 5, say. Zero beachballs, in OS X parlance.
SSD could help somewhat, but since writes can be long and they do rob the read bandwidth, the SSD doesn't offer the benefits of a dedicated ramdisk.
I don't think that there is a big problem with the fact that each app manages its own display, the problem is that the memory used for the pretty much critical-path UI experience code is mingled with memory used for stuff that could wait. Fixing it would require paying careful attention to having a UI thread (one or more), that accesses permanently wired memory only, and other threads that survive disk latencies without affecting the UI. It'd also require the core display system and all the libraries to be in permanently wired memory, too.
I don't think that most language runtime libraries are ready to handle that: you really need to have communication done with a mechanism that ensures that the UI thread doesn't touch the unwired memory used by other threads. Messages sitting in wired memory queues are one way to enforce that, but not the only way, of course.
IOW, it's a design challenge, and existing libraries and development environments are simply not supporting such a model.
Slashdot Mirror
Try 12V via needle electrodes directly into the muscle :) BTDT, no thanks.
A canvas, to be useful, needs a whole lot of supporting code. If you go the whole nine yards, you end up with an application development toolkit like Qt. Suppose you have some text that needs editing on the canvas. Do you really want to implement text editing GUI yourself? While this may be simple for a fixed width font, things get tricky with kerning and multiple formattings, and you start getting sidetracked a lot when your right-to-left locale customers complain that nothing works.
Qt's QGraphicsView is the canvas widget you're looking for; your items would derive from
QGraphicsItem. About the only shortcoming of that subsystem is that there's no built-in support for interaction-independent views of the same scene. You can have multiple views of the same scene, but all they differ with is the viewport transformation. Thus you can't have, for example, different objects selected in different views of (windows into) the same scene, and you can't edit something in one view, stop, edit something else in another view, then come back to the first view -- both selection and focus is per-scene, not per-view like needed in such scenario.
I don't know offhand of any generic 2D canvas system that would come anywhere close to implementing a per-view interaction context -- the latter consisting at least of the selection, focus, and user-interaction elements (such as handles, pop-up menus, whatnot). Qt's canvas is perhaps the most feature-laden canvas of them all anyway, in spite of the above limitation.
Re 2: I meant going from Cinci to Cleve or other way round. From Columbus it should be an hour and a change.
Kinect doesn't do body tracking. It only provides an image with depth information, a tracking library on XBox does the model fitting and provides the estimated body configuration via an API.
I know about it being sterile when it's just about to leave the urinary tract, but pissing cows, especially females, don't exactly keep the urine stream from contacting dirty stuff. Never mind that urine is fodder for some microorganisms -- try peeing in your toilet every evening, and flush in the morning. A week of that and you'll get nice growth of something there.
Unfortunately, Kasich, in all of his miguided non-wisdom, just happens to be -- by chance -- right about the CCC rail as proposed. It's doomed to failure. CCC has several problems, the most glaring IMHO are:
1. Poor connectivity -- the rail should be tightly integrated into the non-existent local transit. In the absence of the latter, it needs to provide the local-level transit segment as well.
2. Speed: I'd certainly pay $75-$100 one way just to go to Cinci or Cleveland for, say, a concert, but the trip should take 2 hours tops each way.
3. Reuse of insufficient infrastructure: a new project like that can't just be based on freight tracks that were designed and originally laid 50-75 years ago IIRC.
4. Inefficient construction methods: there needs to be prefabrication of everything. Think some sort of a precast elevated monorail segment with infrastructure, modular station and support buildings, pylons with supports for varying soil types, etc. It's horribly inefficient to move all that soil just so that a track can be laid or replaced. This also addresses 1: we can get the track right into downtowns when it's elevated.
5. Park-and-ride needs to be on both ends of the trip: the rail company needs to provide a Zipcar-style service so that people won't be stranded at the destination. This can be done more efficiently than simply offloading this onto rental car companies. One should be able to have a single, reloadable, identifying smart card that allows boarding the train and renting the car -- ideally with as much hassle as it takes to walk from a mall store back to the parked car.
Such a project, with proper funding, could become a pilot with multiple nationwide deployments, and could be successful. But it can't be just a short-funded reuse of existing crap. Rail has to evolve, reusing the century old way of engineering it is a horrible misuse of resources. Current technology allows us to do way more and way better. CCC would need a complete from-scratch re-engineering of every aspect of the infrastructure and operations. Otherwise it's just too little, too late.
Tried that in Swiss Alps when we, um, under-budgeted the water for the hike. We were lucky there were no cows pissing upstream, or that the cows were healthy ;)
I think that the time is ripe to have full authentication of each network node in corporate/campus environments. 802.1X FTW. This of course raises the bar for spoofing only somewhat: if you have physical access to someone else's machine (think helping out a 'friend'), then you can copy the certificates and private keys. Then the spoofee is in even more trouble: it'd be so much harder to convince a jury that the spoofing took place.
AFAIK they are packaged with every major linux distro out there, and I can't but presume that Windows ships with microcode patches as well.
Oh boy. Look, all generators that are tied into the grid have to be spinning and synchronized unless they feed a DC transmission line. Synchronization in a legacy powerplant may take say half a day, so you can't just stop the machinery and restart it when you want to -- true.
When a generator is running and synchronized, the rotational speed is pretty much constant. Then the torque at the shaft between the turbine and the generator is proportional to the load power. As the load power goes down, you decrease the steam pressure, and the torque goes down to match that. The voltage on the output can be kept quite constant as long as you have proper control systems -- it used to be hard when things were adjusted manually or with simple PID controls, but nowadays you can have an optimal controller that will fully exploit the operational envelope of the plant. An additional factor is load balancing between powerplants.
A generator is typically followed by a step-up transformer system, and those have switchable taps that are used to do additional voltage regulation.
In nuclear-powered plants, I presume it's easy to dump full rated power into the cooling system. While it's inefficient, you should be able to idle the generators while the reactor is at 100% thermal power output. In normal operation you have to dissipate 30-50% of heat output anyway, so it's not like doubling or tripling the cooling demand is a big deal, IIRC.
In other words: they bullshitted you, and you ate their bullshit and didn't even wink. Kudos.
This is ridiculous. A 3D printer is like a good CNC machining center, just cheaper. A modern multiaxis machining center is just like a 3D printer, but with better resolution, and with limits as to how weird the shapes it can make -- a 3D printer can make a bunch of concentric spherical shells (each with a hole in it to drain the unfused material), a CNC can't. So whatever court verdict outlaws 3D printers, it will automatically make all of U.S. manufacturing grind to a halt (whatever is left of it). Do the U.S. patent holders really want to rid us of whatever manufacturing capability remains?
For those who haven't experienced a CNC machining center: those are nothing like a hobbyist CNC lathe or mill. They are huge (room+ sized) multiaxis machines, sometimes with dozens axes when you combine the stock positioning, stock clamping, tool positioning, tool exchange, etc. The typical process to make a keepsake figurine on a CNC machining center goes like:
- convert 3D model to whatever format your CAM software digs,
- select a couple of tools (usually with progressively smaller radii),
- have the CAM software generate tool paths from the model, check for interferences, etc.
- install stock & tools in the machining center, upload the file, hit the RUN button on the control panel
I didn't. Simply reinitialized the time machines on the new drive.
Transferring data would have been trivial. All you need is SATA-USB or SATA-Firewire adapter. Procedure I'd use:
1. Format the new drive with same format as the one in time capsule (remove it, check whether it's HFS+ journaled or not, put it back).
2. Hook up time capsule via gigabit ethernet, hook up new drive via USB/Firewire.
3. Disable time machine.
4. Mount both drives.
5. Copy all files over using a *recent* rsync, with xattrs/acls and whatnot enabled so that metadata stays intact.
6. Unmount, power off, move new drive into the time capsule.
I'd think that would do it.
Something must be broken then in your setup somewhere, because I use a Time Capsule, recently upgraded from 500GB to WD Green 2TB, and never had a single data loss/corruption issue. I'm using it with a MBP and an iMac, and have used it with OS X 10.5, and now 10.6. Not a single problem, apart from running out of room on the 500GB drive and having to upgrade.
It all begins in target classification. If the anti-missile system was programmed to ignore outbound targets launched at close range, then you'd get exactly what we saw.
Simple. Use some intermediate representation that's JIT-compiled by a trusted compiler. The whole thing can be set up so that it's mathematically provable to be safe -- as in one process not being able to corrupt other processes, nor access resources it's not authorized to. No need for MMU for process isolation. MMU would still be of advantage if you needed to implement some VM features -- think mmapped files.
IMHO Java needed to have been spun off long time ago into a small company whose core focus would be just Java. Pretty much duplicating Trolltech's focus, dedication and agility. Not only would it be self-funding, I'd be quite happy to pay for Java: I'd get my money's worth, just like I used to pay for Qt. Sun had entirely too much overhead to let Java flourish. Java can support a small company: say 100-200 people, focused only on one product. Something the size of Sun? Not so much. Java could be monetized, just not by a big corporation. There is room for small, focused businesses doing what they do best. I somewhat dislike that Nokia took over Trolltech: sure the original owners/investors got their money's worth, but IMHO Qt lost out on it.
The difference is that with Qt you at least used to get your money's worth -- there was way to get bugs mostly fixed, features got implemented, you could get real help. You pretty much knew what you were paying for. And they have this clause that any code developed under GPL cannot be transferred over to commercial license; some argue that it's unenforceable but that's what you have.
Good luck getting any of that from a behemoth the size of Oracle. Paying for Java is merely a way of corporate CYA, it's useless otherwise.
The major deal I see is that the gap between library availability for Ocaml and that of F# is only widening. Reversing that would need lots more resources thrown at Ocaml. As long as Ocaml is used in a niche where you don't care much for the libraries, that's OK. But it won't come into widestream use without libraries. And I won't even start about Ocaml's standard library -- it's kind of a joke. Sure, I know there are replacements, but with .NET you don't have to worry about it.
I think you are entirely misdiagnosing the problem.
The motors generate a back-EMF simply because they are turning. You don't need to have anything attached them at all. If the intra-winding insulation on the motors were to fail due to overvoltage, you'd achieve that without anything attached to the motors -- spin them fast enough, insulation breaks down, windings short together and start dissipating mucho power, flames shoot out. Try it out: disconnect the motors, hook the output to a voltmeter (via a fuse!, you don't want a short in the voltmeter to blow in your face), run down the hill (assuming there's a separate brake system available).
Since, as you claim, you have to "kick it [the drive electronics] in" at about 30MPH for the flames to shoot, it's not due to overvoltage *in the motors*. Likely there is an overvoltage crowbar in the drive electronics that shorts the motors temporarily when the voltage is too high. This causes huge power dissipation and self destruction of the motors. Any insulation breakdown is a secondary effect from overheating, not the primary cause IMHO.
I reiterate that a typical electrical motor's insulation system should withstand 2-3x overvoltage with no adverse effects. The way you test it is by applying a test voltage from a hipot tester between the windings and the case.
Even if you get insulation breakdowns, the common thing that would break down in a properly designed and manufactured motor is the winding-to-case insulation. Any drive system worth its salt should detect such a condition and disconnect itself from the motor -- thus no damage done. In a brushed motor, the commutator or sliprings may well break down first -- that's pole-to-pole and not pole-to-case
The only way an overvoltage-due-to-overspeed on an electric motor will damage *insulation* is when you have very poorly designed windings. Perhaps the motors were rewound by someone without a clue?
I'd expect most electric motors to get mechanical damage from overrevving way before there's any electrical damage in the motor itself. Perhaps a dirty commutator or dirty sliprings will break down and catch fire, maybe, but I'd think that's rare if the motor works well at rated voltage. Now if the drive system decides to fry the motor, like what you're telling me implies, that's another story -- just don't blame winding insulation for that.
While true, you're disingenuous. The static code verification tools developed by MS are hardly crap. They are on the forefront of what's available for static analysis of C/C++ code.
I'd say that for all practical purposes, at least in my limited testing, the performance you get from the code running on CLR is not appreciably worse from what you get with OCaml's native code, so I don't see any real benefit of OCaml's native code over code running on CLR. I've found plenty of cases where CLR outperforms OCaml by an order of magnitud -- basically as soon as you use OCaml to the fullest, plenty of POD stays boxed, and everything goes downhill from there.
I read caml-devel like you do, so the only thing I can make out of your post is that ocaml's issues are not all that important to your use of it at Redhat. And I'm fine with that, but again -- it's a niche use. As for important areas: sure, I agree, after all F# came up from MS's own use of Ocaml!
It's not like the layers of abstraction change over time. The latency one experiences is random: it depends on what pages are in memory at the instant you try to do something, and perhaps to some extent on the locks held by code currently paged out due to memory pressure (if there's such a thing).
Basically, whatever is due to abstraction is the best case. If you can see that menus switch in 10ms, that's the best case, and to improve that you need to make the code more CPU-efficient. Everything else implies that you're I/O bound.
I have been seen tests with DDR2-based ramdisks and running systems that don't use anything else: guess what -- CPU utilization bursts always reach 95%, and there's no latency to speak of.
An acquaintance has a Mac Pro with 6G of ram, that he runs off a 64 GB DDR2 ramdisk dedicated to the OS and Applications, data files are stored on a separate RAID. The machine feels unreal. Running a purpose-made memory hogging process, that would cause it to swap for 1-2 hours until OOM handler kicks in when run off a spinning platter drive, merely causes a noticeable slowdown that feels like the CPU's clock was throttled back by a factor of 5, say. Zero beachballs, in OS X parlance.
SSD could help somewhat, but since writes can be long and they do rob the read bandwidth, the SSD doesn't offer the benefits of a dedicated ramdisk.
I don't think that there is a big problem with the fact that each app manages its own display, the problem is that the memory used for the pretty much critical-path UI experience code is mingled with memory used for stuff that could wait. Fixing it would require paying careful attention to having a UI thread (one or more), that accesses permanently wired memory only, and other threads that survive disk latencies without affecting the UI. It'd also require the core display system and all the libraries to be in permanently wired memory, too.
I don't think that most language runtime libraries are ready to handle that: you really need to have communication done with a mechanism that ensures that the UI thread doesn't touch the unwired memory used by other threads. Messages sitting in wired memory queues are one way to enforce that, but not the only way, of course.
IOW, it's a design challenge, and existing libraries and development environments are simply not supporting such a model.