Amongst *Working* Unix GUI coders, Motif usage probably exceeds that of all other toolkits combined. Can't prove it, but I'm fairly sure. From my experience with Unix commercial CAD/CAM systems: I've never seen one that used *anything* other than Motif.
Motif has flaws, but on technical grounds, is much more appropriate for "can't fail" applications than something like GTK+.
If you think that's dead, then you must be a little like the guy driving the dead wagon in the Holy Grail.
And to me, standard Motif doesn't look particularly bad. On top of that, some folks have been recently working on theming Motif. Check out http://www.motifzone.net .
So "it's ugly" isn't a very sound criticism of Motif anymore. Other criticisms, typically about run-time efficiency or difficulty of the API, are basically false. I found Motif easier to learn, a couple of years back, than GTK+. The API *is* very large, but fairly consistent. And any toolkit API will grow as it strives for more capabilities. This has happened and will happen more to GTK+ and Qt.
Please remember that *almost* *all* Unix commercial applications use Motif. And it works well for open-source apps too. My favorite: NEdit, can be safely described as So Good I Can Hardly Believe It.
Unfortunately, other sources don't agree with your (Rhodes'?) numbers. "U.S. Nuclear Weapons" by Chuck Hansen, and the Nuclear Weapons FAQ, at:
http://www.fas.org/nuke/hew/Nwfaq/Nfaq8.html
Show predicted yields of 5 Mt (1-10 possible) and 6 Mt (4-8 "possible") for Mike and Bravo respectively, versus 10.5 and 14.5 Mt actual. In other words, both achieved more than double predicted yield. Bravo is only unusual because it exceeded it's "possible" yield range. And Hansen's book documents many tests of that era falling far awry (often on the high side) of yield predictions.
BTW, the *real* reason that Bravo became so infamous was that the wind was blowing in an unexpected direction that day. It's inherent radiological hazards (10 Mt fission yield) are not significantly different from Mike's (8 Mt fission yield).
This is all still partially obscured by the cloak of secrecy, and the mistaken speculation that a cloak of secrecy always stimulates. So neither of us will ever know the answers with certainty.
But these are the reasons for my original guesses about reaction branches, and my memory seems to have failed me on this original point anyway.
My *real* points were *correct*, and relate to fusion fuel breeding only.
Nice work if you can get it:-)
I used to read alot about machines like the one you're working on - and liquid metal MHD used to *really* interest me.
And here I am working with computers all the time nowadays 8-/
Believe it or not, I'm actually going to kinda disagree with you. Molten alkali-metal systems are not *that* exotic - they've been in use for about 50 years. Granted that what you're doing *is* exotic! There's no containing wall between the Li and the plasma!
Note that I never said anything about Li "walls", only Li blankets, and I was not visualizing what you are doing at all. You can have an Li or Flibe blanket between double walls - i.e. completely separated from the plasma chamber by a wall of vanadium or niobium, or even stainless steel or something. This requires only "conventional" know-how and such systems could be designed today with little need for experimentation.
They just won't work as well as a bare Li wall. If I'm not mistaken, you're getting around "first wall" heat transfer limitations, right?
Many devices over-yielded, or under-yielded, by more than a factor of 2 in those days. I am fairly sure that Ivy Mike was only predicted to yield 4 or 5 Mt, not 10.5 (I can look it up somewhere, I'm sure).
To be clear: Much more energy came from fast fission of U-238 in both Mike and Bravo, than came from fusion. Most "fusion" bombs get half or more of their energy from fast fission in the tamper. So I'm not sure what:
"achieved exactly its theoretical yield for burning 1 cubic meter of liquid deuterium"
actually means. Mike clearly didn't "burn" *most* of the deuterium - never mind all of it - and it didn't get most of it's energy from deuterium *at* *all*.
BTW, to bad we haven't had as much success with fusion in power plants as we've had in weapons - all agreed?
I was not sure what the percentage was, so I can't say for sure. But I *do* know that the first H-bomb (Ivy Mike), which was liquid D2-fueled - the only one of it's kind - achieved *much* higher than predicted yield.
I had been told (*not* sure if this is correct) that the D + D -> He-4 + 20MeV gamma reaction proceeded much faster at the high temperatures (maybe a billion K?) which occurred in the device than was anticipated. And those 20 MeV gammas will fission U-238 just like fast (> 10 MeV) neutrons are prone to. This was purportedly the cause of the extreme yield.
But this source could have been *quite* wrong (as now seems likely to me). Perhaps the reaction in general just went faster than anticipated (denser than expected assembly?). But note that they *did* know about the 14 MeV (D-T origin) neutrons and had factored them into the yield estimates.
Oh well. Not relevant to practical power production anyway.
First of all, D-T fusion reactors will all breed their own Tritium. The reaction you mention:
D + T = H-2 + H-3 -> He-4 + n + E
Is accompanied by two reactions in a surrounding blanket where the tritium is bred:
Li-7 + n -> He-4 + H-3 + n'
Li-6 + n -> He-4 + H-3
The n' above denotes that the neutron has lost kinetic energy in an inelastic collision with the Li-7 nucleus (which later fissions into the He-4 and the H-3), or is a less energetic neutron ejected from either a Li-8 or He-5 compound nucleus. The blanket material is usually either molten Lithium or molten 'Flibe' (Lithium-Beryllium Fluoride), where the Lithium may be partially enriched in Li-6. A good design will produce as much Tritium in the blanket as it fuses in the plasma core.
Contrary to your statement, the primary reaction produces *no* gammas directly - 80% of energy yield is neutron kinetic energy, 20% is alpha (He-4) kinetic energy.
Furthermore, the reaction you showed for D-D fusion:
2D = 2H-2 -> He-4 + E
Has a low branch probability (several percent?). D-D fusion is dominated by the following reactions:
H-2 + H-2 -> H-3 + H-1 (all kinetic)
H-2 + H-2 -> He-3 + n (all kinetic)
H-2 + H-3 -> He-4 + n (same as in D-T fusion)
H-2 + He-3 -> He-4 + H-1
This is usually known as 'Cat-D' (catalyzed D-D fusion) Average overall reaction is:
3 H-2 -> He-4 + H-1 + n
Thus D-D reactors do deal with some Tritium, and produce *plenty* of neutrons (40%? of total energy, versus 80% for D-T).
I won't even begin to comment on your Protium (H-1) fusion reactions (like those that occur in the Sun). They are even more complex and run 10^20 too slow to ever be useful for power production. Whether Protium could be more rapidly fused by reactions that do not seem to occur naturally is yet another matter.
As a further aside, nuclear fission and fusion are the *only* sustainable, expandable, portable (like in a star drive!) energy sources in our future.
Handling users/groups/ownership/permissions seems much cleaner and more maintainable under Unix than NT, for instance. ACLs just seem like overkill. If Linux had them, I can't see them becoming the normal mechanism for this sort of thing.
Maybe I'm missing something. Anyone here want to try and convince me?
Even given the undeniable potency of vi/emacs/etc. (keystroke driven) text editors, NEdit is still the best text editor out there from many standpoints.
At where I work, in a small, Unix-based, CAD/CAM operation (HP/UX and Linux) it is tremendously empowering. It is approachable for non-Unix people, but nifty and potent enough for old hacks as well. It makes it possible to standardize on a single editor for all normal text editing operations, yet keep everyone reasonably happy.
And any damned fool knows that Motif is *still* the best available, standard GUI toolkit on any platform. Not to start a flamewar, but Qt is just passable, Tk is too slow for many purposes, and GTK+ is a throwback - substantially more rudimentary than Motif.
It's heat and oxidation resistance are pathetic - among the worst of all structural metals.
Titanium is *robust* - strong, tough, strong at higher temperatures, highly oxidation resistant. And it's fairly light.
Aluminum, Beryllium, Magnesium and *all* - repeat *all* - non-transition structural metals show either poor heat or poor oxidation resistance, or both.
As someone who *strongly* prefers Debian to all other distros, and even more strongly prefers KDE to GNOME, and who has jumped through numerous hoops (builds from source and unofficial packages) to keep KDE up to date - while everything else is updated *apt-get*automatically*, I have just one other thing to say:
> Well, it's *probable* that Apple has quite a bit of Cocoa ported to win32, > since that may have been their original plan. Obviously, they've shied > away from the win32/x86 crowd at the moment, at least for a full product, > probably because of lack of engineering hours to spend on the project, but > who knows what else that $150 million deal with Microsoft included.
Next had an OpenStep platform available *for*sale* which would run on WinNT, at the time that Apple bought them. Unless my memory is playing tricks on me, Next had ported the BSD/Mach version to HP/UX, Solaris and WinNT by that time.
If I am right in gathering that Cocoa is largely warmed-over OpenStep, then there's not much guessing to do - Cocoa on WinNT can, and perhaps will, be readily done. It also seems clear to me that if Apple had any business sense, they would release a Cocoa implementation on Linux - for a price - in order to drive volume adoption of the API. Have they learned from the closed-platform disaster which was the Mac? Do they understand why Windows first eclipsed MacOS, and why Linux is so hot now?
Not wishing to speak for RMS, but isn't this *exactly* why he created the GPL - because the MIT license allowed companies to try these stupid tricks.
MIT (as well as every other educational institution) should release all code under the GPL, or similar licenses with protection against proprietary extensions.
Can SRP shroud X connections?
on
SSH v. SRP
·
· Score: 2
SSH can protect connections to remote X clients. Can SRP do this too?
Period. I want my X resources, my command line parsing, and a standard framework of gui mechanisms.
It seems to me that Spencer Kimball and Peter Mattis were more interested in writing the whole nine yards, top to bottom, rather than reusing very fine, pre-existing, fully open-source (MIT license, folks) code like Xt. The only living, growing, open-source widget library which started from the right point is Lesstif. There could have, and *should* have been others. Maybe it's still not too late?
I can personally sympathize with the urge to re-invent the wheel. I have the urge myself, sometimes, because I want to dig through the entire problem, at all of it's layers. But it was a mistake for their little school project to be adopted as a standard library for countless apps. We will be paying the price for this stupidity for quite some time.
A buddy of mine had his service disconnected by @Home just a couple of weeks ago. He is running a crappy NT proxy server which handles lots of protocols. They said that vast quantities of SPAM were coming from his IP adress. Then they yanked his service!
I told him to use Linux. IP Masq wouldn't have got him in a pickle!
The article says that Lynx works (with SSL). Is the original submitor certain that his Netscape has been Fortified? Does ->Help ->About_Netscape show U.S. grade RSA?
How is it that *Lynx* works?
BTW, web banking at my bank (The TD Bank of Canada) works perfectly with Netscape/Linux, despite the fact that it's not officially supported. But you *must* Fortify it. TD's security standards will buzz you off if you try it with export-grade encryption.
> (recently found out that I want to say cystic > fibrosis in its recessive form protected against > the black plague.)
I believe the gene which causes cystic fibrosis (when it is homozygous) improves the resistance of lung tissue to tuberculosis infection (when it is heterozygous).
I was a little surprised and fascinated to learn and understand that authentication mechanisms can employ message digest algorithms ("hashes") instead of encryption algorithms.
I understand that this provides an opportunity for strong message authentication codes which are less restricted by cryptographic export controls. As I recall you covering such schemes as HMAC in your book, I was wondering how important you think these codes might become, given that they conceivably might see wider distribution.
The "icewm" window manager (configured with a "warp" theme) combined with the "dfm" file manager provide a reasonable look-a-like and a crude work-a-like to WPS. They were both written by people who liked OS/2 as well as *nix.
But my recommendation is that KDE will rule (GNOME is pale imitation), so we need to make sure every good idea in WPS gets implemented in KDE too. Then all we need is a "warp" theme. GNOME can then ape KDE and do the same;-)
I am struck by the fact that O'Reilly sells proprietary software (WebSite and friends) as well as books which are (mostly) about open-source software. I believe there will always be proprietary software, and that this is not necessarily a bad thing. But open source has worked so well for infrastructural projects, like tools and servers. And companies like Cygnus and Red Hat are certainly doing well financially with primarily open-source business models.
WebSite - a web server - obviously falls into the infrastructure category where open source projects have done so well. I'm wondering if you'd comment on why you decided to make it proprietary?
Slashdot Mirror
Amongst *Working* Unix GUI coders, Motif usage probably exceeds that of all other toolkits combined. Can't prove it, but I'm fairly sure. From my experience with Unix commercial CAD/CAM systems: I've never seen one that used *anything* other than Motif.
Motif has flaws, but on technical grounds, is much more appropriate for "can't fail" applications than something like GTK+.
If you think that's dead, then you must be a little like the guy driving the dead wagon in the Holy Grail.
And to me, standard Motif doesn't look particularly bad. On top of that, some folks have been recently working on theming Motif. Check out http://www.motifzone.net .
So "it's ugly" isn't a very sound criticism of Motif anymore. Other criticisms, typically about run-time efficiency or difficulty of the API, are basically false. I found Motif easier to learn, a couple of years back, than GTK+. The API *is* very large, but fairly consistent. And any toolkit API will grow as it strives for more capabilities. This has happened and will happen more to GTK+ and Qt.
Please remember that *almost* *all* Unix commercial applications use Motif. And it works well for open-source apps too. My favorite: NEdit, can be safely described as So Good I Can Hardly Believe It.
Unfortunately, other sources don't agree with your (Rhodes'?) numbers. "U.S. Nuclear Weapons" by Chuck Hansen, and the Nuclear Weapons FAQ, at:
http://www.fas.org/nuke/hew/Nwfaq/Nfaq8.html
Show predicted yields of 5 Mt (1-10 possible) and 6 Mt (4-8 "possible") for Mike and Bravo respectively, versus 10.5 and 14.5 Mt actual. In other words, both achieved more than double predicted yield. Bravo is only unusual because it exceeded it's "possible" yield range. And Hansen's book documents many tests of that era falling far awry (often on the high side) of yield predictions.
BTW, the *real* reason that Bravo became so infamous was that the wind was blowing in an unexpected direction that day. It's inherent radiological hazards (10 Mt fission yield) are not significantly different from Mike's (8 Mt fission yield).
This is all still partially obscured by the cloak of secrecy, and the mistaken speculation that a cloak of secrecy always stimulates. So neither of us will ever know the answers with certainty.
But these are the reasons for my original guesses about reaction branches, and my memory seems to have failed me on this original point anyway.
My *real* points were *correct*, and relate to fusion fuel breeding only.
Wow!
:-)
Nice work if you can get it
I used to read alot about machines like the one you're working on - and liquid metal MHD used to *really* interest me.
And here I am working with computers all the time nowadays 8-/
Believe it or not, I'm actually going to kinda disagree with you. Molten alkali-metal systems are not *that* exotic - they've been in use for about 50 years. Granted that what you're doing *is* exotic! There's no containing wall between the Li and the plasma!
Note that I never said anything about Li "walls", only Li blankets, and I was not visualizing what you are doing at all. You can have an Li or Flibe blanket between double walls - i.e. completely separated from the plasma chamber by a wall of vanadium or niobium, or even stainless steel or something. This requires only "conventional" know-how and such systems could be designed today with little need for experimentation.
They just won't work as well as a bare Li wall. If I'm not mistaken, you're getting around "first wall" heat transfer limitations, right?
Good luck in your work!
Many devices over-yielded, or under-yielded, by more than a factor of 2 in those days. I am fairly sure that Ivy Mike was only predicted to yield 4 or 5 Mt, not 10.5 (I can look it up somewhere, I'm sure).
To be clear: Much more energy came from fast fission of U-238 in both Mike and Bravo, than came from fusion. Most "fusion" bombs get half or more of their energy from fast fission in the tamper. So I'm not sure what:
"achieved exactly its theoretical yield for burning 1 cubic meter of liquid deuterium"
actually means. Mike clearly didn't "burn" *most* of the deuterium - never mind all of it - and it didn't get most of it's energy from deuterium *at* *all*.
BTW, to bad we haven't had as much success with fusion in power plants as we've had in weapons - all agreed?
I was not sure what the percentage was, so I can't say for sure. But I *do* know that the first H-bomb (Ivy Mike), which was liquid D2-fueled - the only one of it's kind - achieved *much* higher than predicted yield.
I had been told (*not* sure if this is correct) that the D + D -> He-4 + 20MeV gamma reaction proceeded much faster at the high temperatures (maybe a billion K?) which occurred in the device than was anticipated. And those 20 MeV gammas will fission U-238 just like fast (> 10 MeV) neutrons are prone to. This was purportedly the cause of the extreme yield.
But this source could have been *quite* wrong (as now seems likely to me). Perhaps the reaction in general just went faster than anticipated (denser than expected assembly?). But note that they *did* know about the 14 MeV (D-T origin) neutrons and had factored them into the yield estimates.
Oh well. Not relevant to practical power production anyway.
Where to start...
First of all, D-T fusion reactors will all breed their own Tritium. The reaction you mention:
D + T = H-2 + H-3 -> He-4 + n + E
Is accompanied by two reactions in a surrounding blanket where the tritium is bred:
Li-7 + n -> He-4 + H-3 + n'
Li-6 + n -> He-4 + H-3
The n' above denotes that the neutron has lost kinetic energy in an inelastic collision with the Li-7 nucleus (which later fissions into the He-4 and the H-3), or is a less energetic neutron ejected from either a Li-8 or He-5 compound nucleus. The blanket material is usually either molten Lithium or molten 'Flibe' (Lithium-Beryllium Fluoride), where the Lithium may be partially enriched in Li-6. A good design will produce as much Tritium in the blanket as it fuses in the plasma core.
Contrary to your statement, the primary reaction produces *no* gammas directly - 80% of energy yield is neutron kinetic energy, 20% is alpha (He-4) kinetic energy.
Furthermore, the reaction you showed for D-D fusion:
2D = 2H-2 -> He-4 + E
Has a low branch probability (several percent?). D-D fusion is dominated by the following reactions:
H-2 + H-2 -> H-3 + H-1 (all kinetic)
H-2 + H-2 -> He-3 + n (all kinetic)
H-2 + H-3 -> He-4 + n (same as in D-T fusion)
H-2 + He-3 -> He-4 + H-1
This is usually known as 'Cat-D' (catalyzed D-D fusion) Average overall reaction is:
3 H-2 -> He-4 + H-1 + n
Thus D-D reactors do deal with some Tritium, and produce *plenty* of neutrons (40%? of total energy, versus 80% for D-T).
I won't even begin to comment on your Protium (H-1) fusion reactions (like those that occur in the Sun). They are even more complex and run 10^20 too slow to ever be useful for power production. Whether Protium could be more rapidly fused by reactions that do not seem to occur naturally is yet another matter.
As a further aside, nuclear fission and fusion are the *only* sustainable, expandable, portable (like in a star drive!) energy sources in our future.
I'm not sure why anyone would want ACLs.
Handling users/groups/ownership/permissions seems much cleaner and more maintainable under Unix than NT, for instance. ACLs just seem like overkill. If Linux had them, I can't see them becoming the normal mechanism for this sort of thing.
Maybe I'm missing something. Anyone here want to try and convince me?
:-)
Even given the undeniable potency of vi/emacs/etc. (keystroke driven) text editors, NEdit is still the best text editor out there from many standpoints.
At where I work, in a small, Unix-based, CAD/CAM operation (HP/UX and Linux) it is tremendously empowering. It is approachable for non-Unix people, but nifty and potent enough for old hacks as well. It makes it possible to standardize on a single editor for all normal text editing operations, yet keep everyone reasonably happy.
And any damned fool knows that Motif is *still* the best available, standard GUI toolkit on any platform. Not to start a flamewar, but Qt is just passable, Tk is too slow for many purposes, and GTK+ is a throwback - substantially more rudimentary than Motif.
Hats off to Mark. We appreciate your work!
It's heat and oxidation resistance are pathetic - among the worst of all structural metals.
Titanium is *robust* - strong, tough, strong at higher temperatures, highly oxidation resistant. And it's fairly light.
Aluminum, Beryllium, Magnesium and *all* - repeat *all* - non-transition structural metals show either poor heat or poor oxidation resistance, or both.
In case the SCA people hadn't noticed, people don't fight with swords anymore ;-)
Titanium makes excellent armor for vehicles and people, including titanium helmets. Real soldiers and police currently use titanium armour.
Bullets have much more energy, but much less momentum than archaic weapons, so lghter metal *is* desirable in modern applications.
As someone who *strongly* prefers Debian to all other distros, and even more strongly prefers KDE to GNOME, and who has jumped through numerous hoops (builds from source and unofficial packages) to keep KDE up to date - while everything else is updated *apt-get*automatically*, I have just one other thing to say:
It's about @#$%^! time!!!
> Well, it's *probable* that Apple has quite a bit of Cocoa ported to win32,
> since that may have been their original plan. Obviously, they've shied
> away from the win32/x86 crowd at the moment, at least for a full product,
> probably because of lack of engineering hours to spend on the project, but
> who knows what else that $150 million deal with Microsoft included.
Next had an OpenStep platform available *for*sale* which would run on WinNT, at the time that Apple bought them. Unless my memory is playing tricks on me, Next had ported the BSD/Mach version to HP/UX, Solaris and WinNT by that time.
If I am right in gathering that Cocoa is largely warmed-over OpenStep, then there's not much guessing to do - Cocoa on WinNT can, and perhaps will, be readily done. It also seems clear to me that if Apple had any business sense, they would release a Cocoa implementation on Linux - for a price - in order to drive volume adoption of the API. Have they learned from the closed-platform disaster which was the Mac? Do they understand why Windows first eclipsed MacOS, and why Linux is so hot now?
Mike Greaves
Not wishing to speak for RMS, but isn't this *exactly* why he created the GPL - because the MIT license allowed companies to try these stupid tricks.
MIT (as well as every other educational institution) should release all code under the GPL, or similar licenses with protection against proprietary extensions.
SSH can protect connections to remote X clients. Can SRP do this too?
No X gui which shuns Xt is an acceptable X gui.
Period. I want my X resources, my command line parsing, and a standard framework of gui mechanisms.
It seems to me that Spencer Kimball and Peter Mattis were more interested in writing the whole nine yards, top to bottom, rather than reusing very fine, pre-existing, fully open-source (MIT license, folks) code like Xt. The only living, growing, open-source widget library which started from the right point is Lesstif. There could have, and *should* have been others. Maybe it's still not too late?
I can personally sympathize with the urge to re-invent the wheel. I have the urge myself, sometimes, because I want to dig through the entire problem, at all of it's layers. But it was a mistake for their little school project to be adopted as a standard library for countless apps. We will be paying the price for this stupidity for quite some time.
They should have used Xt, damnit!
A buddy of mine had his service disconnected by @Home just a couple of weeks ago. He is running a crappy NT proxy server which handles lots of protocols. They said that vast quantities of SPAM were coming from his IP adress. Then they yanked his service!
I told him to use Linux. IP Masq wouldn't have got him in a pickle!
The article says that Lynx works (with SSL). Is the original submitor certain that his Netscape has been Fortified? Does ->Help ->About_Netscape show U.S. grade RSA?
How is it that *Lynx* works?
BTW, web banking at my bank (The TD Bank of Canada) works perfectly with Netscape/Linux, despite the fact that it's not officially supported. But you *must* Fortify it. TD's security standards will buzz you off if you try it with export-grade encryption.
> (recently found out that I want to say cystic
:-)
> fibrosis in its recessive form protected against
> the black plague.)
I believe the gene which causes cystic fibrosis (when it is homozygous) improves the resistance of lung tissue to tuberculosis infection (when it is heterozygous).
Just in case you wanted to know
I was a little surprised and fascinated to learn and understand that authentication mechanisms can employ message digest algorithms ("hashes") instead of encryption algorithms.
I understand that this provides an opportunity for strong message authentication codes which are less restricted by cryptographic export controls. As I recall you covering such schemes as HMAC in your book, I was wondering how important you think these codes might become, given that they conceivably might see wider distribution.
Seriously. This is *not* a flame.
How do you recommend people generate dynamic web pages.
Seriously. This is *not* a flame.
How do you suggest people generate dynamic web pages?
The "icewm" window manager (configured with a "warp" theme) combined with the "dfm" file manager provide a reasonable look-a-like and a crude work-a-like to WPS. They were both written by people who liked OS/2 as well as *nix.
;-)
But my recommendation is that KDE will rule (GNOME is pale imitation), so we need to make sure every good idea in WPS gets implemented in KDE too. Then all we need is a "warp" theme. GNOME can then ape KDE and do the same
I am struck by the fact that O'Reilly sells proprietary software (WebSite and friends) as well as books which are (mostly) about open-source software. I believe there will always be proprietary software, and that this is not necessarily a bad thing. But open source has worked so well for infrastructural projects, like tools and servers. And companies like Cygnus and Red Hat are certainly doing well financially with primarily open-source business models.
WebSite - a web server - obviously falls into the infrastructure category where open source projects have done so well. I'm wondering if you'd comment on why you decided to make it proprietary?