Only the US, United Kingdom and Russia continue to inventory gelled fuel bombs.
The chemical used differs from napalm of the Vietnam War era in that it is based on kerosene and a polystyrene-like gel and reportedly contains an oxidizing agent. This will make it even more difficult to put out once ignited. The official designation of Vietnam-era napalm bombs is the Mark 47. Mk-77s are commonly referred to as napalm in US Military slang.
The US Military has issued denials against articles claiming the use of napalm in cases where it seems that Mk-77s had actually been deployed (see referenced articles). The Pentagon has claimed that the Mk-77 has less impact on the environment.
Neptune happens to be made from compound similar to natural gas. Would it be viable to have automated spaceflights to gather for "free energy" pas the cost of the rockets used?
I'll save you billions on space research right here: The answer is *NO*. Do you have any inkling of an idea what would be involved with lifting gigatons of material out of Neptune's huge gravity well, transferring it across billions of miles of space (a trip that would take over a decade and much more velocity change energy than the payload contains), then delivering it to earth? And you want to do this for a material that currently retails for about $1/kg?
You'll probably need to expend at least 100 joules of energy on rocket thrust for every joule of energy delivered from Neptune. But to get that energy, assuming you have no better energy source than methane in the first place (otherwise, why would you be attempting to get it from deep space), you'll presumably need to bring oxygen from somewhere like earth to operate your rockets. But to get the oxygen to Neptune, you'll need huge amounts of rocket fuel; many times more than you're going to end up delivering back to earth.
Re:DVORAK for real world, SysAdmin/Programming use
on
Advocating Dvorak
·
· Score: 1
That's exactly the problem when programming. In fact, with any good text editor, a programmer rarely even types entire words because of context-sensitive shortcuts. The majority of keystrokes are cursor movement, editing actions, punctuation symbols, and shortcut codes.
I've noticed that a disproportionate amount of those (most of the punctuation, Enter, arrow keys, backspace, home/end/pgup/pgdn, right-ctl) involve reaching with the weak fingers of the right hand. This constant bending and reaching is what bothers me the most. I can type English text all day long without any problems, but a few hours of heavy coding can start to bug me. (Vim does help with this by eliminating the need to use arrow and other dedicated movement keys)
To combat this, I've made dozens of key mappings in vim to take care of the most common punctuation sequences, such as ", ", " + " and inserting balanced brackets, parentheses and quotes. Since vim leaves all Alt-* combos available by default, I map these to keys under stronger fingers. I've also remapped many frequently used commands that use weak fingers to stronger fingers (like moving the find-previous-match command from ^P to ^K, and mapping Escape to Alt+G). This seems to help me much more than remapping the letters on the keyboard.
Exacly. And it will be improved by removing the heavy, useless wings; by eliminating the unneeded large payload capacity; by greatly reducing the heat shield size and complexity; by adding a viable escape system; by getting rid of uncontrollable solid boosters; and by dropping the high-strung engines that need a total rebuild after every flight that costs more than new engines.
In other words, it will be replaced by a much more reasonable capsule-like spacecraft on a simple single-use booster.
Funny article. My favorite part was the scheme that was even more stupid than the CueCat:
And anyway, what the heck happened to last month's dumb Wired idea?
About two months ago, Wired magazine had a different technology for going to a URL automatically from an ad. It was some kind of weird thing where you held up the page to your digital camera, took a digital picture, and ran this wacked out software that navigated your browser to the Altoids home page. So now instead of typing 7 letters I have to find my digital camera, turn it on, wait for it to boot up, take a picture of the page, turn off the camera, wait for it to flush its memory to flash, remove the flash card from the camera, take the network card out of the PCMCIA slot, put the compact flash into it's holder, plug it into the PCMCIA slot, find the picture, run the software which I previously installed, oh, don't get me started. It would be a half-hour trauma just to go to the damn Altoids web site, where you can't even buy an Altoids, for heaven's sake. Curious.
Over the years I've tried dedicated programs, spreadsheets, pencil & paper, PDAs, etc.
For TODO list, I've found that the best is a flat text file, 3 columns x ~80 lines, edited with vim, stored under subversion source control. It fits around 200 items (more than I'm likely to ever actually get around to), and I can see it all at one glance. Left/right/middle column = short/medium/long term. Broken horizontally into major categories like "to get", "house", "work", etc. One or two *s go before high-priority items. The whole thing can be dumped onto a single sheet of paper for pocket portability. The source control system preserves a complete history of my progress over time or lack thereof.
The PA-RISC, Alpha, and Mips chip families were all way out in front of the x86 before they were put into maintenance mode by HP and SGI in anticipation of the IA-64 architecture, which never did deliver on it's price/performance promises.
That was before the x86 decoupled the inner workings from the instruction set. That's ancient history.
IBM's POWER is way out in front of the performance sweepstakes, and unlikely to be axed any time soon on the P and R series servers. Ditto the Z-series "SuperCISC" mainframe processors.
All of that is due to insane cache sizes, heavy I/O bus technology, and the hugely expensive packaging that goes with them. Cram all of that around an x86 core and you'd get similar results.
The "skin" required to make the instruction set work with bleeding edge designs like Cell just isn't worth the hassle or performance overhead.
The Cell isn't just one processor; it's a processor plus a bunch of DSPs. Nothing is stopping you from adding a bunch of DSPs to an x86 die.
The x86 instruction set is bloated and crippled
The subset of instructions that modern compilers actually issue aren't bloated, and they use up fewer bytes than space-hogging RISC opcodes. The "bloated" instructions of old are handled by a little bit of microcode if they are encountered. The x86-32 was somewhat crippled, but that was mostly worked around with tricks like renaming. The x86-64 isn't crippled.
and making the Itanium interoperable with it nearly sunk the chip entirely.
It was sunk because they thought that they could get away with shoving most of the branch prediction logic up to the compiler, which doesn't know anything about the actual runtime conditions. While the idea seemed appealing, it didn't work. An other example of how "advanced" instruction set architectures don't really buy you anything in the real world.
Allan Kay was dead right in that hardware needs to accommodate the programmer, not the other way around.
That's right, it needs to do the job as good as any alternative without making the programmers rewrite all of the software in existence.
The point here is that the worst of all the CPU designs out there is the Intel one.
As I explained, it just doesn't matter which one is "worst". Most modern CPUs have a user-visible "skin" slapped over some exotic out-of-order set of execution units. Your view of what's better or worse is just a superficial impression of what the skin looks like.
If all of those designs truly had more potential than a design with an x86 skin, then at some point one of them would have permanently pulled ahead in performance - even if only in the server arena. This just hasn't happened.
The PPC in consoles probably has more to do with IBM's scheme to conveniently include a few DSPs on the die than with any deep architectural differences in the main Power core. It's a just packaging optimization targeted at the embedded media appliance market.
This "mass extinction" of competing hardware architectures is not good for innovation.
The user-visible instruction set doesn't matter anymore. There's a wide variety of different architectures under the hood of the various x86-compatible implementations, and these will continue to evolve and improve. The real CPU architecture looks nothing at all like the interface presented to the programmer; this is even true for most recent RISC chips.
If non x86-compatible instruction sets provided a significant benefit, then CPUs using them would have been able to hold a substantial and lasting performance lead over the x86-compatible CPUs. But they haven't. When somebody claims that an alternative CPU architecture is beating the top-end x86 chips, it's usually just because they've slapped a massive cache next to the core. It has little if anything to do with the instruction architecture itself. The x86 instruction format is just a standardized compact bytecode that is translated to the latest features by each generation of x86-compatible microprocessor.
If you can make essentially the same progress without breaking compatibility with a huge body of software which has received so much massive investment, what good does it do to break compatibility?
Re:the code of conduct for free software distribut
on
Drafting GPL3
·
· Score: 1
could you please explain how the GPL rewards the original author when you take their work?
If you add improvements to his work and distribute them, then the original author is entitled to use and/or distribute the improvements too. The original author gets free additional development resources.
The term "monad" is also the name for the feature used by purely functional languages like Haskell to do I/O operations (which would otherwise be impossible in a "stateless" language with no side effects).
I'm guessing that's where they got the word from, since this shell will be a kind of textual I/O adapter that also handles non-text data.
I wasn't going to be an ass until I received the snide "I know, you probably were looking for a setting in/etc/XF86Config to change, but on the Mac you generally use the GUI to change things." line. (BTW, the GUI is used to change font settings in Linux too.)
At any rate, I had originally found the control, and it didn't seem to do anything. Now that I've tried the login/logout suggestion from below, I can detect a subtle change between the settings, but none of them are using any significant sub-pixel rendering to give me fonts as crisp as Linux or Windows. (Now to be a real ass, I'll point out that KDE helpfully tells me that the changes will only happen on new windows after I change settings. And I'll point out that the other adjustments, such as color scheme, in the same Apple dialog take effect instantly, which would lead one to expect that the fonts will do the same.)
That's exactly what I tried first. I'm not as as stupid as the condescending black-turtleneck-wearing AC would assume. On this box, the setting has no effect whatsoever.
I've tried all the settings: Standard, light, medium, strong. All of them == the exact same fuzzy grayscale-only antialiasing. Maybe the settings on this machine somehow got hosed before I got it, but that's not supposed to happen on a Mac, right?
I recently picked up a used G3 box running Panther so I could have a big-endian machine to test some cross-platform code on.
As a total Apple n00b, I haven't been able to figure out how to turn on sub-pixel font rendering for my LCD monitor. I get the impression that the OS is supposed to be smart enough to turn it on by itself, but nothing happens. The totally stripped-down control panel dialogs in OSX don't give me anything to work with to try to fix it.
Bottom line: for me, the Linux fonts look beautiful, the Apple fonts look like ass. Oh well.
It's not hard to hide your email information leaks from snoops, like so:
2004 Request for temperature compensation aggregate mixtures:
Aggregate mixtures are 3% above nominal for the first period,
requiring a 8% reduction in admix composition between junction
intervals. All temperature compensation is within target limits
for the period ending 3/7. Urgent sell all your stock asap; the SouthEast
deal has totally fallen through, we've lost all licensing rights
and we're going to post a huge loss and massive layoffs next
quarter, when this goes public on Thursday our price is going to fall off a cliff. Secondary filtering activity has increased by 27% this period,
followed by tertiary filtering increases of 5%. Verification requested.
On the Intel x86 architecture, as long as the data pages are allocated from data segments, and code pages are allocated from code segments, the processor will enforce the inability of programs to exploit buffer overflows. This protection will fail if the two segments overlap.
Since most software written over the past 30 years was designed under assumptions that break if code and data segments don't exactly overlap (for example, the assumption that you can freely cast both data and function pointers to void* and back), AMD finally introduced the NX bit into the page tables, which provides the same protection at the per-page level. Intel copied this and called it the XD bit. This approach is just like that which is already used by essentially every other CPU MMU architecture on the market.
Now on the x86 you can leave segmentation mapped to a no-op, which makes software much easier to write and maintain, and you can prevent writes to code sections. There's no reason for anybody to turn the segmentation mumbo-jumbo back on.
You have not explained where segmentation provides any features or benefits that properly designed page tables don't. Modern page tables also don't have the "executable data problem", and they do this while providing a totally uniform flat memory model to the applications.
If segmented memory is so great, then why has no other CPU manufacturer seen fit to introduce it since the days of the 80386? Maybe it's because paged memory attributes do accomplish everything important that segments do.
Segmented memory works by separating the data, stack, and code sections into their own segments. No one can overwrite the code segment, and the data heap can't ever touch the program stack segment.
The no-execute page bit accomplishes the first part, and the second part isn't important. If you have stack-allocated data, you can use a buffer overrun in that data to overwrite stack return addresses. Separating the heap accesses doesn't solve anything.
To the running programs, this is transparent.
Only if every pointer in the system is a far pointer (which makes all pointers in your 32-bit CPU 48 bits long). Otherwise, how would you keep heap-allocated data and stack-allocated data distinct? The problem with segment selectors is that they aren't transparent to the programs unless they're all set exactly the same. Maybe you could avoid the problem by outlawing C, C++ and any other language that allows application-visible pointer arithmetic. But then you probably wouldn't have to worry about buffer overruns in the first place.
It just so happens that today's "Modern OSes" (right load of bull that is) map only two memory segments, then completely ignore the GDT, LDT, and TSS after that?
Do you know why? It's because segmented memory models SUCKED. Have you ever tried to program for a 80286? It was an incomprehensible nightmare. Few if any programming languages provide appropriate models for the non-uniform memory space introduced with segments. You're on your own handling the details of ugly, klunky pointer models. The paging features introduced with the 80386 made the segmented model unnecessary, and programmers woldwide dropped segments in a heartbeat.
All you need to do achieve the same security goal is make data pages non-executable. That's what's been done with the latest x86 CPUs (sure it should have been done back in 1986, but unfortunately we can't change the past). You don't need complex kludges like segmented memory.
Quite often you get only a manpage with tens of pages of minute technical settings that are outdated and have no bearing in the current implementation. Just give me a few pages of HTML documentation that are up to date.
In the Konqueror web browser, just type man:foo or #foo into the address bar. Within milliseconds you get your man page as very readable nicely formatted HTML. IMHO, it beats digging through 14 levels of tree control in the MSDN help viewer, or searching in it and coming up with 17 slightly different versions of the same topic for obscure editions of Windows.
I don't recall any of the man pages I've looked at recently as being out of date.
I see that they are willing to support "new Fedora" with engineering and financial assistance, but I wonder how long they will continue to help if the disto takes a turn that they do not support.
They've said in the past that Fedora was supposed to be a "test bed" for stuff that will end up in RHEL. It seems like that will become hard to accomplish if they give up control over Fedora's direction. They might have to create a new internal test bed that more directly matches their plans for RHEL, and Fedora might eventually become no more useful for that purpose than most any other distro out there. If that happens, it's hard to see why they would continue to invest resources in it.
Maybe having the public test bed wasn't providing that much benefit, and now they think that grabbing more mindshare from individual developers is a more important goal. Maybe Fedora isn't working out as they planned at all, and this is their way to get rid of it without looking bad. Maybe it's something else altogether. It's hard to say.
Slashdot Mirror
What's in a name?
I'll save you billions on space research right here: The answer is *NO*. Do you have any inkling of an idea what would be involved with lifting gigatons of material out of Neptune's huge gravity well, transferring it across billions of miles of space (a trip that would take over a decade and much more velocity change energy than the payload contains), then delivering it to earth? And you want to do this for a material that currently retails for about $1/kg?
You'll probably need to expend at least 100 joules of energy on rocket thrust for every joule of energy delivered from Neptune. But to get that energy, assuming you have no better energy source than methane in the first place (otherwise, why would you be attempting to get it from deep space), you'll presumably need to bring oxygen from somewhere like earth to operate your rockets. But to get the oxygen to Neptune, you'll need huge amounts of rocket fuel; many times more than you're going to end up delivering back to earth.
I've noticed that a disproportionate amount of those (most of the punctuation, Enter, arrow keys, backspace, home/end/pgup/pgdn, right-ctl) involve reaching with the weak fingers of the right hand. This constant bending and reaching is what bothers me the most. I can type English text all day long without any problems, but a few hours of heavy coding can start to bug me. (Vim does help with this by eliminating the need to use arrow and other dedicated movement keys)
To combat this, I've made dozens of key mappings in vim to take care of the most common punctuation sequences, such as ", ", " + " and inserting balanced brackets, parentheses and quotes. Since vim leaves all Alt-* combos available by default, I map these to keys under stronger fingers. I've also remapped many frequently used commands that use weak fingers to stronger fingers (like moving the find-previous-match command from ^P to ^K, and mapping Escape to Alt+G). This seems to help me much more than remapping the letters on the keyboard.
Exacly. And it will be improved by removing the heavy, useless wings; by eliminating the unneeded large payload capacity; by greatly reducing the heat shield size and complexity; by adding a viable escape system; by getting rid of uncontrollable solid boosters; and by dropping the high-strung engines that need a total rebuild after every flight that costs more than new engines.
In other words, it will be replaced by a much more reasonable capsule-like spacecraft on a simple single-use booster.
Well, at least it's not another report about the latest status of the 3 suspects in Aruba.
For TODO list, I've found that the best is a flat text file, 3 columns x ~80 lines, edited with vim, stored under subversion source control. It fits around 200 items (more than I'm likely to ever actually get around to), and I can see it all at one glance. Left/right/middle column = short/medium/long term. Broken horizontally into major categories like "to get", "house", "work", etc. One or two *s go before high-priority items. The whole thing can be dumped onto a single sheet of paper for pocket portability. The source control system preserves a complete history of my progress over time or lack thereof.
That was before the x86 decoupled the inner workings from the instruction set. That's ancient history.
IBM's POWER is way out in front of the performance sweepstakes, and unlikely to be axed any time soon on the P and R series servers. Ditto the Z-series "SuperCISC" mainframe processors.
All of that is due to insane cache sizes, heavy I/O bus technology, and the hugely expensive packaging that goes with them. Cram all of that around an x86 core and you'd get similar results.
The "skin" required to make the instruction set work with bleeding edge designs like Cell just isn't worth the hassle or performance overhead.
The Cell isn't just one processor; it's a processor plus a bunch of DSPs. Nothing is stopping you from adding a bunch of DSPs to an x86 die.
The x86 instruction set is bloated and crippled
The subset of instructions that modern compilers actually issue aren't bloated, and they use up fewer bytes than space-hogging RISC opcodes. The "bloated" instructions of old are handled by a little bit of microcode if they are encountered. The x86-32 was somewhat crippled, but that was mostly worked around with tricks like renaming. The x86-64 isn't crippled.
and making the Itanium interoperable with it nearly sunk the chip entirely.
It was sunk because they thought that they could get away with shoving most of the branch prediction logic up to the compiler, which doesn't know anything about the actual runtime conditions. While the idea seemed appealing, it didn't work. An other example of how "advanced" instruction set architectures don't really buy you anything in the real world.
Allan Kay was dead right in that hardware needs to accommodate the programmer, not the other way around.
That's right, it needs to do the job as good as any alternative without making the programmers rewrite all of the software in existence.
As I explained, it just doesn't matter which one is "worst". Most modern CPUs have a user-visible "skin" slapped over some exotic out-of-order set of execution units. Your view of what's better or worse is just a superficial impression of what the skin looks like.
If all of those designs truly had more potential than a design with an x86 skin, then at some point one of them would have permanently pulled ahead in performance - even if only in the server arena. This just hasn't happened.
The PPC in consoles probably has more to do with IBM's scheme to conveniently include a few DSPs on the die than with any deep architectural differences in the main Power core. It's a just packaging optimization targeted at the embedded media appliance market.
The user-visible instruction set doesn't matter anymore. There's a wide variety of different architectures under the hood of the various x86-compatible implementations, and these will continue to evolve and improve. The real CPU architecture looks nothing at all like the interface presented to the programmer; this is even true for most recent RISC chips.
If non x86-compatible instruction sets provided a significant benefit, then CPUs using them would have been able to hold a substantial and lasting performance lead over the x86-compatible CPUs. But they haven't. When somebody claims that an alternative CPU architecture is beating the top-end x86 chips, it's usually just because they've slapped a massive cache next to the core. It has little if anything to do with the instruction architecture itself. The x86 instruction format is just a standardized compact bytecode that is translated to the latest features by each generation of x86-compatible microprocessor.
If you can make essentially the same progress without breaking compatibility with a huge body of software which has received so much massive investment, what good does it do to break compatibility?
If you add improvements to his work and distribute them, then the original author is entitled to use and/or distribute the improvements too. The original author gets free additional development resources.
I'm guessing that's where they got the word from, since this shell will be a kind of textual I/O adapter that also handles non-text data.
At any rate, I had originally found the control, and it didn't seem to do anything. Now that I've tried the login/logout suggestion from below, I can detect a subtle change between the settings, but none of them are using any significant sub-pixel rendering to give me fonts as crisp as Linux or Windows. (Now to be a real ass, I'll point out that KDE helpfully tells me that the changes will only happen on new windows after I change settings. And I'll point out that the other adjustments, such as color scheme, in the same Apple dialog take effect instantly, which would lead one to expect that the fonts will do the same.)
I've tried all the settings: Standard, light, medium, strong. All of them == the exact same fuzzy grayscale-only antialiasing. Maybe the settings on this machine somehow got hosed before I got it, but that's not supposed to happen on a Mac, right?
As a total Apple n00b, I haven't been able to figure out how to turn on sub-pixel font rendering for my LCD monitor. I get the impression that the OS is supposed to be smart enough to turn it on by itself, but nothing happens. The totally stripped-down control panel dialogs in OSX don't give me anything to work with to try to fix it.
Bottom line: for me, the Linux fonts look beautiful, the Apple fonts look like ass. Oh well.
Since most software written over the past 30 years was designed under assumptions that break if code and data segments don't exactly overlap (for example, the assumption that you can freely cast both data and function pointers to void* and back), AMD finally introduced the NX bit into the page tables, which provides the same protection at the per-page level. Intel copied this and called it the XD bit. This approach is just like that which is already used by essentially every other CPU MMU architecture on the market.
Now on the x86 you can leave segmentation mapped to a no-op, which makes software much easier to write and maintain, and you can prevent writes to code sections. There's no reason for anybody to turn the segmentation mumbo-jumbo back on.
You have not explained where segmentation provides any features or benefits that properly designed page tables don't. Modern page tables also don't have the "executable data problem", and they do this while providing a totally uniform flat memory model to the applications.
Segmented memory works by separating the data, stack, and code sections into their own segments. No one can overwrite the code segment, and the data heap can't ever touch the program stack segment.
The no-execute page bit accomplishes the first part, and the second part isn't important. If you have stack-allocated data, you can use a buffer overrun in that data to overwrite stack return addresses. Separating the heap accesses doesn't solve anything.
To the running programs, this is transparent.
Only if every pointer in the system is a far pointer (which makes all pointers in your 32-bit CPU 48 bits long). Otherwise, how would you keep heap-allocated data and stack-allocated data distinct? The problem with segment selectors is that they aren't transparent to the programs unless they're all set exactly the same. Maybe you could avoid the problem by outlawing C, C++ and any other language that allows application-visible pointer arithmetic. But then you probably wouldn't have to worry about buffer overruns in the first place.
Do you know why? It's because segmented memory models SUCKED. Have you ever tried to program for a 80286? It was an incomprehensible nightmare. Few if any programming languages provide appropriate models for the non-uniform memory space introduced with segments. You're on your own handling the details of ugly, klunky pointer models. The paging features introduced with the 80386 made the segmented model unnecessary, and programmers woldwide dropped segments in a heartbeat.
All you need to do achieve the same security goal is make data pages non-executable. That's what's been done with the latest x86 CPUs (sure it should have been done back in 1986, but unfortunately we can't change the past). You don't need complex kludges like segmented memory.
In the Konqueror web browser, just type man:foo or #foo into the address bar. Within milliseconds you get your man page as very readable nicely formatted HTML. IMHO, it beats digging through 14 levels of tree control in the MSDN help viewer, or searching in it and coming up with 17 slightly different versions of the same topic for obscure editions of Windows. I don't recall any of the man pages I've looked at recently as being out of date.
I can't wait to see a fuzzy 15-inch tall "Intel Inside/Pentium 4-HT" logo visible through the translucent sides of the box.
It's just like the clock radio in your bedroom, except the up and down arrow buttons only nudge the time by 1 femtosecond per click.
Apple to ditch IBM, switch to Intel chips
They've said in the past that Fedora was supposed to be a "test bed" for stuff that will end up in RHEL. It seems like that will become hard to accomplish if they give up control over Fedora's direction. They might have to create a new internal test bed that more directly matches their plans for RHEL, and Fedora might eventually become no more useful for that purpose than most any other distro out there. If that happens, it's hard to see why they would continue to invest resources in it.
Maybe having the public test bed wasn't providing that much benefit, and now they think that grabbing more mindshare from individual developers is a more important goal. Maybe Fedora isn't working out as they planned at all, and this is their way to get rid of it without looking bad. Maybe it's something else altogether. It's hard to say.