I'm trying to reinforce the idea that this kind of work is inherently dangerous, and that the men who serve on these vessels accept a lot of risk to do their jobs. Please consider this before launching an overly heated reply. Thank you.
Yeah, it was annoying being at Trident Training Facility and seeing the story come on the news, and after everything was reported the *very* first question out of the reporter's mouth was: "How could this possibly happen?" as if submarining were as easy as throwing a pitch across a room.
Who has the primary duty to avoid such a collision?
The submarine, especially given it was submerged at the time.
Would it be expected that many sailors aboard the sub will hear 100,000 HP diesels of a surface ship a couple of hundred feet away?
Yes*
[*] But that's not the end of the story
IAAS, and I think the grandparent poster was trying to make the point that it is a difficult job for the submarine, not that it was the surface ship's responsibility. With sonar for instance, you just have bearings, you don't have range to a guy without performing target motion analysis. Beyond that, the acoustic environment in the Strait of Hormuz doesn't always lend itself to long-range detection of a target.
The LPD was a U.S. warship and therefore would be designed to avoid putting tons of sound into the water (diesels or no), for the very sound reason that it makes it that much more vulnerable to being attacked by enemy submarines. An even worse scenario (for avoiding collision) would be if the LPD were in the line of bearing to a contact past it that was loud, and therefore the submarine wouldn't be able to hear the LPD until it was so close that it started to have a high rate of bearing change. (Think of how hard it would be to see a bicyclist's light if a very bright spotlight was behind the bicyclist shining directly at you).
The Hartford was apparently at periscope depth and should have been able to see the New Orleans coming close, except that at night it is very difficult to tell the range to a surface contact based just on lighting configuration (and the New Orleans may have been masked by background lighting from shore anyways).
Either way the hammer will fall (again) on the Hartford, there will undoubtedly be tons of "lessons learned" and the sub force as a whole will get to do yet another round of training on submarine collisions and how to avoid them. I am surprised this happened though, a Strait of Hormuz transit is a *very* *big* *deal* for a submarine, so it's not like this would have been just the Officer of the Deck getting distracted, I'm sure a large portion of the navigation team was in Control throughout the transit.
Yeah, my father was in the Navy and had this kind of thing happen all the time. Once even the other way around, where DFAS paid much less than normal and "caught up" with next month's payment while my parents were scrambling around going WTF.
I hear of this kind of thing much less frequently nowadays though. I joined myself and haven't had problems, although our Chief of the Boat managed to run afoul of a DFAS screwup.
Officers are fond of reminding the enlisted that their jobs are so similar. Which only makes the difference in standards of living all the more insulting. Pricks.
Fair enough. I've heard enlisted crewmembers tell me they'd like to get a commission but most also say they only want that if they come back as a Supply Officer. The prior enlisted officers in our wardroom don't seem to think it's a cakewalk and I've never been told by an enlisted crewmember that they'd rather have my job.
In my experience a lot of the officer/enlisted relationship is controlled by the chain of command though. Our other crew had a CO when I rode them that was a stickler for strict separation of supervisor/worker. Our CO is much different in that regard (the crew's inputs are not ignored and junior officers caught helping with cleaning during field day don't get flamesprayed).
The rest depends on the person in question. Our ENG had a fellow JO on his last boat who was too full of himself who had to be fixed via "malicious compliance" and some of our Academy guys don't rate highly with the crew but at least on our boat we all get along pretty well together.
And just as an aside, at least on SSBN the enlisted get the best meal service IMO, so that's something at least (especially if you're oncoming and actually want to eat).
Get 4 hours of sleep, wake up, prewatch tour, eat, stand 6 hours of watch, try to fit all of your divisional and collateral responsibilities into 4-5 hours (and fail), attend training, work on qualifications, etc. for another couple of hours, and repeat the 18-hour cycle.
As an added bonus, the senior chain of command works on a 24-hour a day schedule instead of the normal 18-hour a day schedule, which means that the frequent morning and/or afternoon all-hands drills may occur during the time you're supposed to be sleeping. Oh well.:P
Basically we stand watch and train continuously, catching breaks when we can. I'm an officer, the routine is a bit different for enlisted crew (more cleaning and other assorted BS but then they don't have to attend EVERY SINGLE TRAINING SESSION known to man;).
What are the odds that two advanced SSBN submarines would collide in a vast ocean accidentally?
The odds are apparently pretty low given that to my knowledge this is the first time a British SSBN has collided with a French SSBN in 30-40 years of strategic deterrent patrols.
Keep in mind the "vast ocean" you speak of is limited to the area that the British and French would choose to have their SSBNs patrolling in. It's not like the Capt. just steers a random course for a couple of days and then hunkers down. Given the proximity of France to Britain I wouldn't be surprised if the two nations had patrol areas close to or even intersecting with each other.
Unless one of these two subs has swapped out the nuclear propulsion for Douglas Adams' Infinite Improbability Drive, something smells a tad fishy.
If they really actived the Infinite Improbability Drive then they should double-check the status of the nuclear missiles...
But anyways, submarines have collided before, though normally in Cold War scenarios. For instance, USS Tautog while tracking a Soviet submarine.
Although the "Big Ocean, Little Ship" theory is more than 99% effective at preventing collision it isn't perfect. Submarines will avoid things they can hear, it's hard to steer around something just as undetectable as yourself though.
This is why real submariners hate Crimson Tide and The Hunt for Red October... they give people the wrong impression as to what actually goes on underway.
I am a (US) Submariner and although I can't speak to what sensor technology we have I can say that at least US SSBNs would never be fitted with "mine avoidance" sensors unless they expected to be transiting through mine fields. Which is stupid. At least in the US fleet, SSNs get the cool technology, SSBNs then get the castoffs.
For two SSBNs to involved in such a bump, either one or the other had to be involved in SSN-like games, or pretty astronomical odds were just surmounted in a random collision
A more mundane possibility is that both submarines were transiting to or from their patrol areas and managed to collide on the way. Given the sensitive nature of SSBN operations I'm pretty sure the British and French Naval commands don't exactly tell their counterparts where their SSBNs will be operating.
I don't think you can use Qt Designer for plasmoids, no.
However you couldn't have any kinds of widgets with kdesktop. kicker you could, but when you're talking about something that goes on the panel you're talking about a widget that should be simple enough to generate the UI for in 10 lines of code anyways. If someone is making a panel applet that is so large that it can benefit from GUI layouting and such there's probably other issues.:)
Qt doesn't have themes, Qt has widget styles, which are used in Plasma just like they're used everywhere else in KDE. Where that support ended we got to innovate, so Plasma provides a common appearance API so that widgets will look and feel the same across the whole desktop.
KDE 4.0 supported desktop icons even without the Folder View plasmoid. (The catch being that the desktop must be unlocked first to drag-drop new ones on). The same mechanism still works to this day.
All Folder View allows over that is it will pull the icons from a specific folder, which allowed us to remove the 4.0 feature that caused all the files in your ~/Desktop to have an icon created automatically on the desktop. Or in other words, you've always been able to use ~/Desktop for your desktop.
--the KDE guys were trying to redefine against the face of what we all wanted
You seem to have a mighty expansive definition of "all". Especially in light of the fact that pretty much every major desktop environment has widgets on the desktop in one form or another now.
Although 4.2 is a year away from 4.0, delaying 4.0 until it was 4.2 would have taken much longer than a year, since people only test releases
I understand. Your solution was to tell people that something was a release when it wasn't. In extreme circumstances, I suppose a case can be made for misleading people to achieve an intended result. However, you should not then be surprised if you take a big hit to your credibility.
*sigh*
4.0 was a release. It was a release that was not even up to 3.5 in terms of feature set but it was definitely the solid base of the KDE 4 platform.
My point was not that we should simply rush out releases no matter how bad they were. (In fact, 4.0 was delayed from its original release date for bugfixing). My point is that getting 4.0 into a 4.2 shape with just the testing and use we could provide internally would have taken much longer than the year it took between 4.0 and 4.2. Pretty much any large project will ship a release that even has known bugs. We fixed the large ones that we would thought would block release before we shipped 4.0.
Obviously some got by us but really 4.0 was more of a letdown in features IMHO than in bugs. Some experienced more bugs than others (for instance this is when the issues with the nVidia driver at the time really became apparent).
Some devs get paid by Linux-related companies but not to work on KDE necessarily.
Lots of KDE devs get paid... to work on Qt.
There are a few sponsored devs though, including Aaron Seigo (who is a core dev and KDE e.V. President of the Board but is not "project leader")
But all in all, the vast majority of developer time seems to me to come from volunteers. Perhaps someone should chart it someday a la the LWN.net tracking of Linux kernel contributors.
You would have to make the taskbar fonts way smaller but I just did it and it doesn't look completely atrocious. Except for it being on the top of the screen, wtf man!;)
Of COURSE it's their fault. They were FORCED to explain that time and time again because they deliberately chose version numbers that say the exact opposite.
At the end of the day what 4.0 means is that the kdelibs it ships will not run KDE 3 applications. It's a major incompatible release.
What we could have done instead is to forgo releasing until it was at 4.2 quality or so, pushing back the betas and RCs to that point.
Although 4.2 is a year away from 4.0, delaying 4.0 until it was 4.2 would have taken much longer than a year, since people only test releases.
We at KDE did not communicate effectively enough that 4.0 would be in many ways a step down from 3.5, but we didn't force distros to shift to it, and people able to grab theirs from source are certainly more than capable of going back to their distro's 3.5 packages.
So could we have done better? Of course. But I disagree with the notion that you can't make a release just because it's not suitable for 95% of the user population.
Besides, IMHO, 4.0 wasn't fit for developers either. Even in 4.2, they're STILL calling some of the APIs experimental.
Even if that's the case (and I'll admit I'm not sure as to what libraries you're referring to), are you really trying to claim that an entire desktop release should be held back because there is a library that may change? (Let's assume that we clearly announced in the API docs and such that the interface was subject to change)
Even if the library changes, it's not likely to change that much, which gives developers a leg up in getting started. And if 98% of the library API is frozen and you only use 25% that's in the frozen set, what's the issue?
This is the kind of stuff I'm talking about. Just because a release is not suitable for 100 developers doesn't mean that the other 99900 developers who want a release should have to wait.
Yes, because they did away with the well-established themeable, accelerated, accessible, translatable, Qt GUI Widgets, and based made up a new "plasmoid" system that's almost entirely incompatible with all that. It's pretty, but most of the features have been sacrificed for that, and it'll take AGES to get those features on a parallel, if they ever can.
?
Plasma is if anything more themeable than kicker and kdesktop were.
Plasma (especially in its KDE 4.0 and 4.1 incarnations) was short of the old kicker in features (although much better than the old kdesktop, even including SuperKaramba) I know there are still things that kicker did that Plasma can't (multiple panels stacking on an edge springs to mind) but featurewise it's mostly there now.
As far as widgets go, Plasma does use subclasses of Qt widgets, just like the rest of KDE. I wasn't aware that this is considered weird or out of place however. (To be pedantic, the widgets are subclasses of a QGraphicsView proxy widget and not direct QWidget subclasses e.g. Plasma::PushButton).
The translation system is KDE's not Qt's so that works fine in Plasma. To be honest accessibility support was never KDE's strong point so it could hardly be worse now.:(
GNOME uses DBUS as well (and therefore dbus-server). KDE no longer uses DCOP but uses the same thing GNOME uses.
KIO Slaves are launched on demand as needed, not just because kdeinit loads up.
On the other hand there is usually at the very least a kbuildsycoca step involved when running your first KDE app in a session. I'm sure GNOME has something similar (gconf?) although it may be faster, no doubt.
Really a lot of the startup time concern in my experience has been related more towards C++ symbol bloating (which is significantly reduced nowadays between prelinking and symbol visibility support). The kdeinit you talk about was actually a hack designed to work around that problem, by turning KDE applications into shared libraries (that would startup up much faster as a result).
I will say that I also am cheering on the adoption of more plain Qt apps, for the same reason that I have quite a few GTK+ utilities but no GNOME ones. Less startup time is always a good thing. Unlike the grandparent though I'm not hoping that one DE ends up winning out, I'd actually prefer there be choice available (as long as it interoperates).
Keyboard shortcuts have worked the whole time (at least for me). Working global keyboard shortcuts, not so much (at least if we're talking about multimedia keys in my case). Somehow KWin's global shortcuts work so in the end I don't notice but Alt-F2 has worked since KDE 4.0 so maybe I'm just not experiencing some long standing bug which you're hitting.:(
I was referring to the broken khotkeys which I believe is supposed to be fixed in 4.2 (I haven't tried it myself). It was impossible using KDE settings to create a keyboard shortcut to a terminal, which for a linux desktop I consider absolutely essential (the settings dialogs were in place, they just didn't work, and no error message). But perhaps that is mostly my personal pet peeve. The other big feature regression that irks me is the lack of video thumbnails in dolphin/konqueror.
Ah, ok
As far as the alpha/beta thing, there's plenty of room for argument there, but nevertheless there should have been some sort of warning to users (and maybe to distributions) that it was not intended for use by the general public, but only for developers.
Well, we wanted the general public to use it, or at least the members of the general public who we figured would be able to install it (i.e. build from source, run bleeding-edge distros, etc.)
I don't think we really anticipated that distributions would switch so quickly on the other hand and expand the user population even more.
Slashdot Mirror
I'm trying to reinforce the idea that this kind of work is inherently dangerous, and that the men who serve on these vessels accept a lot of risk to do their jobs. Please consider this before launching an overly heated reply. Thank you.
Yeah, it was annoying being at Trident Training Facility and seeing the story come on the news, and after everything was reported the *very* first question out of the reporter's mouth was: "How could this possibly happen?" as if submarining were as easy as throwing a pitch across a room.
Who has the primary duty to avoid such a collision?
The submarine, especially given it was submerged at the time.
Would it be expected that many sailors aboard the sub will hear 100,000 HP diesels of a surface ship a couple of hundred feet away?
Yes*
[*] But that's not the end of the story
IAAS, and I think the grandparent poster was trying to make the point that it is a difficult job for the submarine, not that it was the surface ship's responsibility. With sonar for instance, you just have bearings, you don't have range to a guy without performing target motion analysis. Beyond that, the acoustic environment in the Strait of Hormuz doesn't always lend itself to long-range detection of a target.
The LPD was a U.S. warship and therefore would be designed to avoid putting tons of sound into the water (diesels or no), for the very sound reason that it makes it that much more vulnerable to being attacked by enemy submarines. An even worse scenario (for avoiding collision) would be if the LPD were in the line of bearing to a contact past it that was loud, and therefore the submarine wouldn't be able to hear the LPD until it was so close that it started to have a high rate of bearing change. (Think of how hard it would be to see a bicyclist's light if a very bright spotlight was behind the bicyclist shining directly at you).
The Hartford was apparently at periscope depth and should have been able to see the New Orleans coming close, except that at night it is very difficult to tell the range to a surface contact based just on lighting configuration (and the New Orleans may have been masked by background lighting from shore anyways).
Either way the hammer will fall (again) on the Hartford, there will undoubtedly be tons of "lessons learned" and the sub force as a whole will get to do yet another round of training on submarine collisions and how to avoid them. I am surprised this happened though, a Strait of Hormuz transit is a *very* *big* *deal* for a submarine, so it's not like this would have been just the Officer of the Deck getting distracted, I'm sure a large portion of the navigation team was in Control throughout the transit.
I worked for several years for a Navy contractor in their submarine combat systems department.
You didn't have anything to do with CCS Mk 2 Block 1C did you? Because if so, as a submarine junior officer, I think I hate you. ;)
Generally it was an x-Gold crew DK; cause the gold crew busted it and the blue crew fixed it.
Good to know that some things never change. ;)
Yeah, my father was in the Navy and had this kind of thing happen all the time. Once even the other way around, where DFAS paid much less than normal and "caught up" with next month's payment while my parents were scrambling around going WTF.
I hear of this kind of thing much less frequently nowadays though. I joined myself and haven't had problems, although our Chief of the Boat managed to run afoul of a DFAS screwup.
Officers are fond of reminding the enlisted that their jobs are so similar. Which only makes the difference in standards of living all the more insulting. Pricks.
Fair enough. I've heard enlisted crewmembers tell me they'd like to get a commission but most also say they only want that if they come back as a Supply Officer. The prior enlisted officers in our wardroom don't seem to think it's a cakewalk and I've never been told by an enlisted crewmember that they'd rather have my job.
In my experience a lot of the officer/enlisted relationship is controlled by the chain of command though. Our other crew had a CO when I rode them that was a stickler for strict separation of supervisor/worker. Our CO is much different in that regard (the crew's inputs are not ignored and junior officers caught helping with cleaning during field day don't get flamesprayed).
The rest depends on the person in question. Our ENG had a fellow JO on his last boat who was too full of himself who had to be fixed via "malicious compliance" and some of our Academy guys don't rate highly with the crew but at least on our boat we all get along pretty well together.
And just as an aside, at least on SSBN the enlisted get the best meal service IMO, so that's something at least (especially if you're oncoming and actually want to eat).
Well the living area *is* much nicer. MT rating, how did you get assigned a SSN? I've heard of MTs on SSGN but not on fast attacks.
Get 4 hours of sleep, wake up, prewatch tour, eat, stand 6 hours of watch, try to fit all of your divisional and collateral responsibilities into 4-5 hours (and fail), attend training, work on qualifications, etc. for another couple of hours, and repeat the 18-hour cycle.
As an added bonus, the senior chain of command works on a 24-hour a day schedule instead of the normal 18-hour a day schedule, which means that the frequent morning and/or afternoon all-hands drills may occur during the time you're supposed to be sleeping. Oh well. :P
Basically we stand watch and train continuously, catching breaks when we can. I'm an officer, the routine is a bit different for enlisted crew (more cleaning and other assorted BS but then they don't have to attend EVERY SINGLE TRAINING SESSION known to man ;).
What are the odds that two advanced SSBN submarines would collide in a vast ocean accidentally?
The odds are apparently pretty low given that to my knowledge this is the first time a British SSBN has collided with a French SSBN in 30-40 years of strategic deterrent patrols.
Keep in mind the "vast ocean" you speak of is limited to the area that the British and French would choose to have their SSBNs patrolling in. It's not like the Capt. just steers a random course for a couple of days and then hunkers down. Given the proximity of France to Britain I wouldn't be surprised if the two nations had patrol areas close to or even intersecting with each other.
Unless one of these two subs has swapped out the nuclear propulsion for Douglas Adams' Infinite Improbability Drive, something smells a tad fishy.
If they really actived the Infinite Improbability Drive then they should double-check the status of the nuclear missiles...
But anyways, submarines have collided before, though normally in Cold War scenarios. For instance, USS Tautog while tracking a Soviet submarine.
Although the "Big Ocean, Little Ship" theory is more than 99% effective at preventing collision it isn't perfect. Submarines will avoid things they can hear, it's hard to steer around something just as undetectable as yourself though.
Conn Sonar - Crazy Ivan!!
This is why real submariners hate Crimson Tide and The Hunt for Red October... they give people the wrong impression as to what actually goes on underway.
I am a (US) Submariner and although I can't speak to what sensor technology we have I can say that at least US SSBNs would never be fitted with "mine avoidance" sensors unless they expected to be transiting through mine fields. Which is stupid. At least in the US fleet, SSNs get the cool technology, SSBNs then get the castoffs.
For two SSBNs to involved in such a bump, either one or the other had to be involved in SSN-like games, or pretty astronomical odds were just surmounted in a random collision
A more mundane possibility is that both submarines were transiting to or from their patrol areas and managed to collide on the way. Given the sensitive nature of SSBN operations I'm pretty sure the British and French Naval commands don't exactly tell their counterparts where their SSBNs will be operating.
I'm still waiting for a Debian security update to break anything.
OpenSSL?
The Debian OpenSSL bug was not introduced in a security update, so this example doesn't work either.
That the later series of security updates after the hole was discovered didn't break anything is actually quite impressive IMO.
I don't think you can use Qt Designer for plasmoids, no.
However you couldn't have any kinds of widgets with kdesktop. kicker you could, but when you're talking about something that goes on the panel you're talking about a widget that should be simple enough to generate the UI for in 10 lines of code anyways. If someone is making a panel applet that is so large that it can benefit from GUI layouting and such there's probably other issues. :)
Do you have even the slightest clue about how "the themed stuff in Qt even works?
Qt doesn't have themes, Qt has widget styles, which are used in Plasma just like they're used everywhere else in KDE. Where that support ended we got to innovate, so Plasma provides a common appearance API so that widgets will look and feel the same across the whole desktop.
KDE 4.0 supported desktop icons even without the Folder View plasmoid. (The catch being that the desktop must be unlocked first to drag-drop new ones on). The same mechanism still works to this day.
All Folder View allows over that is it will pull the icons from a specific folder, which allowed us to remove the 4.0 feature that caused all the files in your ~/Desktop to have an icon created automatically on the desktop. Or in other words, you've always been able to use ~/Desktop for your desktop.
--the KDE guys were trying to redefine against the face of what we all wanted
You seem to have a mighty expansive definition of "all". Especially in light of the fact that pretty much every major desktop environment has widgets on the desktop in one form or another now.
I understand. Your solution was to tell people that something was a release when it wasn't. In extreme circumstances, I suppose a case can be made for misleading people to achieve an intended result. However, you should not then be surprised if you take a big hit to your credibility.
*sigh*
4.0 was a release. It was a release that was not even up to 3.5 in terms of feature set but it was definitely the solid base of the KDE 4 platform.
My point was not that we should simply rush out releases no matter how bad they were. (In fact, 4.0 was delayed from its original release date for bugfixing). My point is that getting 4.0 into a 4.2 shape with just the testing and use we could provide internally would have taken much longer than the year it took between 4.0 and 4.2. Pretty much any large project will ship a release that even has known bugs. We fixed the large ones that we would thought would block release before we shipped 4.0.
Obviously some got by us but really 4.0 was more of a letdown in features IMHO than in bugs. Some experienced more bugs than others (for instance this is when the issues with the nVidia driver at the time really became apparent).
I don't get paid. :P
Some devs get paid by Linux-related companies but not to work on KDE necessarily.
Lots of KDE devs get paid... to work on Qt.
There are a few sponsored devs though, including Aaron Seigo (who is a core dev and KDE e.V. President of the Board but is not "project leader")
But all in all, the vast majority of developer time seems to me to come from volunteers. Perhaps someone should chart it someday a la the LWN.net tracking of Linux kernel contributors.
You would have to make the taskbar fonts way smaller but I just did it and it doesn't look completely atrocious. Except for it being on the top of the screen, wtf man! ;)
Of COURSE it's their fault. They were FORCED to explain that time and time again because they deliberately chose version numbers that say the exact opposite.
At the end of the day what 4.0 means is that the kdelibs it ships will not run KDE 3 applications. It's a major incompatible release.
What we could have done instead is to forgo releasing until it was at 4.2 quality or so, pushing back the betas and RCs to that point.
Although 4.2 is a year away from 4.0, delaying 4.0 until it was 4.2 would have taken much longer than a year, since people only test releases.
We at KDE did not communicate effectively enough that 4.0 would be in many ways a step down from 3.5, but we didn't force distros to shift to it, and people able to grab theirs from source are certainly more than capable of going back to their distro's 3.5 packages.
So could we have done better? Of course. But I disagree with the notion that you can't make a release just because it's not suitable for 95% of the user population.
Besides, IMHO, 4.0 wasn't fit for developers either. Even in 4.2, they're STILL calling some of the APIs experimental.
Even if that's the case (and I'll admit I'm not sure as to what libraries you're referring to), are you really trying to claim that an entire desktop release should be held back because there is a library that may change? (Let's assume that we clearly announced in the API docs and such that the interface was subject to change)
Even if the library changes, it's not likely to change that much, which gives developers a leg up in getting started. And if 98% of the library API is frozen and you only use 25% that's in the frozen set, what's the issue?
This is the kind of stuff I'm talking about. Just because a release is not suitable for 100 developers doesn't mean that the other 99900 developers who want a release should have to wait.
I wish the KDE fanboys (and the KDE developers themselves) would stop trying to rewrite recent history and just admit there were mistakes made.
There were mistakes made.
Yes, because they did away with the well-established themeable, accelerated, accessible, translatable, Qt GUI Widgets, and based made up a new "plasmoid" system that's almost entirely incompatible with all that. It's pretty, but most of the features have been sacrificed for that, and it'll take AGES to get those features on a parallel, if they ever can.
?
Plasma is if anything more themeable than kicker and kdesktop were.
Plasma (especially in its KDE 4.0 and 4.1 incarnations) was short of the old kicker in features (although much better than the old kdesktop, even including SuperKaramba) I know there are still things that kicker did that Plasma can't (multiple panels stacking on an edge springs to mind) but featurewise it's mostly there now.
As far as widgets go, Plasma does use subclasses of Qt widgets, just like the rest of KDE. I wasn't aware that this is considered weird or out of place however. (To be pedantic, the widgets are subclasses of a QGraphicsView proxy widget and not direct QWidget subclasses e.g. Plasma::PushButton).
The translation system is KDE's not Qt's so that works fine in Plasma. To be honest accessibility support was never KDE's strong point so it could hardly be worse now. :(
GNOME uses DBUS as well (and therefore dbus-server). KDE no longer uses DCOP but uses the same thing GNOME uses.
KIO Slaves are launched on demand as needed, not just because kdeinit loads up.
On the other hand there is usually at the very least a kbuildsycoca step involved when running your first KDE app in a session. I'm sure GNOME has something similar (gconf?) although it may be faster, no doubt.
Really a lot of the startup time concern in my experience has been related more towards C++ symbol bloating (which is significantly reduced nowadays between prelinking and symbol visibility support). The kdeinit you talk about was actually a hack designed to work around that problem, by turning KDE applications into shared libraries (that would startup up much faster as a result).
I will say that I also am cheering on the adoption of more plain Qt apps, for the same reason that I have quite a few GTK+ utilities but no GNOME ones. Less startup time is always a good thing. Unlike the grandparent though I'm not hoping that one DE ends up winning out, I'd actually prefer there be choice available (as long as it interoperates).
Keyboard shortcuts have worked the whole time (at least for me). Working global keyboard shortcuts, not so much (at least if we're talking about multimedia keys in my case). Somehow KWin's global shortcuts work so in the end I don't notice but Alt-F2 has worked since KDE 4.0 so maybe I'm just not experiencing some long standing bug which you're hitting. :(
I was referring to the broken khotkeys which I believe is supposed to be fixed in 4.2 (I haven't tried it myself). It was impossible using KDE settings to create a keyboard shortcut to a terminal, which for a linux desktop I consider absolutely essential (the settings dialogs were in place, they just didn't work, and no error message). But perhaps that is mostly my personal pet peeve. The other big feature regression that irks me is the lack of video thumbnails in dolphin/konqueror.
Ah, ok
As far as the alpha/beta thing, there's plenty of room for argument there, but nevertheless there should have been some sort of warning to users (and maybe to distributions) that it was not intended for use by the general public, but only for developers.
Well, we wanted the general public to use it, or at least the members of the general public who we figured would be able to install it (i.e. build from source, run bleeding-edge distros, etc.)
I don't think we really anticipated that distributions would switch so quickly on the other hand and expand the user population even more.