The URL looks legit, but there are a number of practical problems with the robots as described:
2mm/sec?
At that rate, they'd move 7.2 metres (23.4 feet) per hour. Power plants and industrial facilities are *big*. Unless you saturate one with bugs, your robots will take days to reach their destinations.
Lithium or NiCad?
What's powering these suckers, if they take days to go anywhere? Either one of several unlikely broadcast power schemes is being used, or they're tethered, or they can't go more than a few tens of metres before their batteries run out.
What exactly are these supposed to do?
The robots as described would have an interesting time actually fixing anything. Especially on battery power. The most useful application that I can think of would be to use them as remote cameras to see what's going wrong, but there are easier/more practical ways of doing this (put a motorized video camera on a ceiling track, for instance, and use faster tethered robots or just something like a proctoscope for getting into the pipes).
This is an incomplete list, but you get the idea. IMO, this is either a hoax or else the article has significantly munged many of the details.
...I hate pressing "tab" when trying to indent in a text input field...
To continue: The K7 also supports an L3 cache on the motherboard. IIRC this was slow, but I don't remember the exact specs.
As AMD is the one putting together the modules for the K7, the design burden for providing a full-speed L2 cache is in their court. IIRC they were planning to sell half-core-speed systems initially, and offer full-core-speed systems as higher end later (presumably when yields on full-core-speed parts went up).
It will be interesting to see what happens when they move to 0.18 micron. They could fit a fairly large L2 cache on-die, but size would still be less than the maximum that the off-die version supports (up to 8 megabytes IIRC).
I'm not that happy to read, that the K7 will have a slow cache as well... (I really hope I misread that!).
If I understand correctly, the K7's L1 cache is fast but small (64/64), and the L2 cache can run at variable speeds. Some of the earlier systems tested had it running at 1/3 core clock IIRC, while the systems that AMD released benchmarks for had it at 1/2 core clock (again IIRC). The chip supports an L2 cache running at full core speed, so it will be up to the module and RAM makers to provide the infrastructure for that (running an off-chip cache at 500+ MHz isn't trivial).
It has an LCD screen. AFAIK, those still aren't cheap. Not that that makes this thing worth the price, but that would explain where at least some of the price comes from.
How about a web site where one email can be formed and culled from the cream of all arguments and distilled down to what a majority would like to send?
While this makes the most sense from the point of view of conveying the most relevant information and eliminating redundancy, in practice all this would accomplish in the short-term is to make the signal-to-noise ratio that much worse. Instead of 100 polite emails and 10,000 flames, the authour gets 1 polite email and 10,000 flames.
The loophole is that if the 1 email is from a well-respected entity whose opinions carry weight, it would be useful. Open Sense, if implemented, could eventually gain such weight. However, it won't have such weight when first implemented - this would be a medium-term effect at best, long-term at worst.
OTOH, those of us who write sensible letters could always post to both. That would give the best of both worlds.
As a side idea - it might be a good idea for someone who _does_ carry weight - for instance, Linus - to write a letter to the publisher that both states that the flamers do not represent his views (possibly apologizing), and then politely taking issue with the inaccurate points presented in the article. This might actually accomplish something.
Going to the publisher helps in that the article's authour is probably just ignoring all Linux-related emails. Coming from Linus or another noteworthy and level-headed developer/advocate would give it the credibility to get read.
In any event, if you do get Open Sense off the ground, please let me know. I'd be happy to contribute.
The fact is that if they wanted to, they could support G3 macs, there is no question about that. The fact is also that once they support the current generation of g3s they will always support the current generation of g3s, they may not support G4s or future G3s but they will support current G3s.
How could they do this without using reverse-engineered specs? They need specs from _Apple_ to guarantee compatibility, and as other posters have pointed out, they aren't getting them.
It's not different than being on Intel in that respect, in fact you are guaranteed that if you want to support newer Intel chips you will probably end up writing some code.
Um, no. Or at least, you don't have to. You could dig out an old copy of Windows 3.1 and it would run on your brand new Pentium III, because the architecture is completely backwards-compatible (which is both a blessing and a curse, but that's another story). Now, any _application_ that, say, used SSE would be in trouble (because of data lost during context switches), and you could certainly increase efficiency by modifying code for the new processor, but the OS wouldn't _break_. Such is not the case, I am told, with G3-based systems.
"however, without meaning to offend, I think that many Linux advocates _do_ want Linux to be the only OS. This is a Bad Thing IMO."
No Linux advocate that I have dealt with (me included) want Linux to be the only OS. What many of us want is for Linux to be able to do everything. There is a big difference, but because this would put it in competition with every OS, some people think we want them all to go away.
Um, take a look at some of the other posts in this thread. And in the threads attached to the MacOS X post. Many of the posters here, who would certainly call themselves Linux advocates (whether or not they fit the definition that you use), have a strong knee-jerk reaction that says that any non-Open operating system is intrinsically evil and should be abolished. They then proceed to loudly make this opinion known.
They also generally don't mention *BSD. When it comes up, the reaction is along the lines of "Huh? Oh, well, since it's Open, it's ok.". And then they go back to bashing non-Open OSs.
This seems to indicate that many of these "advocates" _do_ want to actively destroy non-Open OSs regardless of whatever merits they may have. And for many of them, Linux == Open == Linux.
I'm not saying that _all_ Linux advocates are like this by any means - but a substantial and very vocal minority are.
I have done a quick and dirty driver and I have added a little extra to the proc FS. I suppose I should submit the proc thing, but the driver is just something I needed short term and isnt up to any standard of quality.
As stated in my previous post, you don't need to recompile the kernel to add drivers to Be, or need access to the kernel source to write drivers. Most drivers are kernel modules loaded at boot-time, analogous to "modules" under Linux.
I have already said that I recognize that sometimes things _do_ need to be tweaked in the kernel - but I think that for the vast majority of _users_ who don't do kernel tweaking, BeOS is fine. Linux isn't going away any time soon, don't worry.
Better, each time I need (or want) just about any piece of software, I can just grab it no fuss, and no shareware bullshit. BeOS might be nice, but it doesn't give people this kind of thing in such quantity.
The people to take that up with are the BeOS users, not Be itself. Be makes an active effort to publish all of its API and document as much of it as possible. If you want to release an open application under BeOS, there's nothing stopping you. Porting isn't that hard either, because the guts of BeOS are Unixoid.
Usually I dont touch source except my own. However, when a need a little tidbit I want to be able to implement it now, not wait for my suggestion to turn into a patch (or never happen). For example, I wanted to generate gifs from xfigs through a script, fig2dev didnt have it yet but xfig could output gifs, so i added 10 lines to xfig and got my feature. Fvwm2 was missing a nuance I wanted. 50-60 lines and I am done. Easier than figuring out where to submit a request, and much faster.
Bear in mind that these are applications. There's nothing to prevent apps under BeOS from being Open or Free. It is only the kernel that's closed. Now, you could make the same arguments about the kernel as you do applications, but in practice I see fewer kernel bugs that need fixing.
And if I want to tweak kernels, I can still use Linux. BeOS doesn't have to be the *only* OS; however, without meaning to offend, I think that many Linux advocates _do_ want Linux to be the only OS. This is a Bad Thing IMO.
Re. drivers, I'm happily doing driver development under BeOS with no more access to the kernel source than any other user. The headers are all that's needed.
He's saying that some (most, 99%?) of those users should be using Beos? Why? They chose on some set of criteria that for them made Linux the best choice.
Um, no, by straight numbers most users seem to think that Windows is the best choice. You're trying to convince them that Linux is. He's trying to convince them that BeOS is.
How many computer users - out of the total number of computer users - even program? How many, given the opportunity and the tools, _would_ mess with the kernel? Very few.
Linux is nice. I just plain _like_ *nix variants. But the most that I've done under Linux is look in the/arch directory and say "gee that's neat, maybe in a decade when I have free time I'll try porting Linux to a custom processor".
I've recompiled _applications_, but the kernel header files are all you need for that, and Be gives you those.
However, I'm getting sidetracked. While I enjoy Linux for programming, most users aren't programmers. In terms of installation and ease-of-use, IMO BeOS wins (though Linux is catching up).
Programmers would love Linux. Many of them already do. IMO, the users that *don't* program would love BeOS. They are who use most of the desktop machines.
Am I wrong? I thought I read that BeOS comes w/ gcc.
Yes, it does. I have a BeOS machine sitting next to me right now.
While the OS is closed, you still get all of the header files and semi-complete documentation (what isn't there is being written). Applications can be closed or open as the applications programmer wishes; AFAICT, Be doesn't care. More applications are good regardless of the license they're released under, and Be is too small to write applications itself. It loses nothing from open apps, and loses nothing from making the entry points to the OS visible.
Don't get me wrong, I'm a nerd too (in my own little ways), but am I the only one who didn't understand this? Then again, i'm only 14 and my college classes don't go into that type of science.
Not a problem. Here, if you're interested, is a description of the "magic island" idea and an explanation of why this article is significant.
Some elements are more stable than others. Lead will remain Lead no matter how long you leave it, but Plutonium will decay over a few thousand years into lighter elements. In addition, there are many types - isotopes - of each element. These all have the same number of protons but have different numbers of neutrons. Some are more stable than others; for instance, Carbon-12 is stable, but Carbon-14 is not. (The "12" and "14" are the total number of particles - protons and neutrons - in the atom's nucleus).
If you draw a chart of all of the isotopes of all of the elements, a pattern emerges. The chart has element number ("atomic number", the number of protons) as one axis, and "atomic weight" (the total number of particles - protons and neutrons) as the other axis. The stable isotopes form a band running up this chart diagonally, slightly curved.
Further irregularities are observed. In places, there are large blotches of mostly-stable elements, and in other places there are gaps where the elements are mostly unstable. These blotches are sometimes called "islands of stability".
Islands of stability happen when the number of protons or the number of neutrons in an atom's nucleus is a "magic number", or close to a "magic number". As you add protons or neutrons to a nucleus, they stack up in "shells" at different energy levels, much as electrons do in an atom. A completely full shell - a "closed shell" - is very stable. The "magic numbers" are the numbers of protons or neutrons required to have the outermost shell of the nucleus "closed" - exactly full. Iron is in the middle of one island of stability, and lead is in the middle of another.
One problem that scientists have had when trying to produce "superheavy" elements - elements with more protons than any element that we've found in nature - is that elements are less stable the more protons they have. This is why many of the "heavy" elements (elements with many protons) are radioactive. As they climb into the range of elements that have more than 100 protons, the elements get very unstable, so that you barely have enough time to detect them before they decay (or sometimes are left only looking at the decay products).
However, many scientists hope that there will be another island of stability around elements 116-118. These elements would have "magic" numbers of protons and neutrons, and might live much longer than the other "superheavy" elements produced so far. Some isotopes of them might even be stable. This "island" is called the "magic island of stability", because it's a group of stable or almost-stable elements in the middle of a sea of very unstable elements and isotopes. For many years, scientists have been trying to produce elements that were in this "magic island" to see if they actually are stable.
This article describes one of these experiments, that has succeeded in producing one of the elements in the "island". Whether it's as stable as hoped remains to be seen. In fact, each of the isotopes of this element will have to be produced to see whether or not the island really is stable.
Very exciting, for people who follow the quest for "superheavy" elements regularly:). I hope that this gives you a better idea of what the posts here are talking about.
This is an interesting take on the issue, and the proposed model has advantages (letting the programmers act creatively being one of them). However, there are problems with this approach too.
The main problem that I see is that there will be great pressure on the programmers to come up with projects that sponsors will like. This will be a market controlled by the buyers - projects that sponsors aren't interested in won't get funded, no matter how interesting or innovative they are. While the same is true in the bounty system described, this new approach doesn't alleviate it. IMO, neat but unprofitable work will continue to be done on spare time or by blue-sky development teams.
Secondly, I'd like to address the point re. bounty systems encouraging closed development. This can indeed happen - but it depends on how the bounty system is implemented. If I understand correctly, the newer schemes that have been proposed allow teams to bid on the jobs and sponsors to pick the teams that they like. Then the contract is finalized. If most work is done after the contract is in place, there isn't the duplication of effort that you get with the original bounty approach (six people writing something independently and only the first getting paid). You also don't have to get closed development - once the contract is in place, it doesn't matter if others can copy the work, because only the original group will get paid for it. The original group loses nothing by sharing. Finally, programmers would still have to work in groups under this system. A really large project just can't be handled by an individual. Smaller projects might be handled, but the sponsor may want it in a shorter length of time (though there are hard limits to how much a project can be shortened by adding developers). In short, I don't see a well-implemented bounty system hurting openness.
The one point which remains valid is that the software projects offered may not be very interesting or innovative. IMO, this is a tolerable tradeoff. Nothing prevents the programmers from doing something more useful in their free time; this is just a good way of arranging contract work so that the programmers can get paid.
There will also be pressures on sponsors to _make_ their projects interesting. If they present a project that nobody is interested in, they'll either have no takers, low quality takers, or have to jack up the price to unreasonably high levels. Employers presenting interesting, innovative projects will have the advantage in this regard, which is a Good Thing.
IMO, there's actually a place for both systems, but I feel that the modified bounty/work order system would be most practical in the near term.
Now what would happen if we terraformed Mars? There'd be liquid oceans again. And again the same problem would arise. CO2 would be absorbed into those oceans, carbonates would settle on the ocean floor, and eventually Mars would again freeze up. Sure, then you could terraform again, or you could introduce other greenhouse gasses to keep Mars' temperature elevated, but eventually you wouldn't be able to keep up.
There's always the Brute Force and Ignorance approach: Mine the limestone back off the ocean floor and break it down into calcium oxide and carbon dioxide again. This would take a fair amount of industry, but if we have the wherewithal to terraform a _planet_, this should be do-able (if we want to).
The last is a big caveat. Terraforming will be horriffically expensive. Either we'd need an extremely good reason to terraform, or the cost would have to drop a *lot* before we would do so.
Re:This would be GREAT for armor piercing shells.
on
Element 118 detected
·
· Score: 3
Depleted uranium is already used in armor piercing shells because their high density per unit volume enables shells to carry far more momentum than standard shells (and therefore makes them harder to stop). Element 118 would work even better.
I'm not sure that it would. The atomic weight of an element isn't the only influence on its density. The density is determined by the atomic weight, the crystal structure of the element in solid form, and the distance between atoms. The last item (and the middle item, to an extent) is a result of the structure of the electron shells around the atom.
IIRC, the second row of transition elements had a peculiar property that made atoms in that row very compact. Similar pecularities may exist elsewhere, but IIRC the actinides and following elements weren't particularly dense.
Osmium is still the densest element IIRC. I'm not sure exactly why uranium is used in shells as opposed to something denser, but it still works. It's dense, stronger than lead, and they have a lot of it left over when they produce enriched uranium (depleted uranium is uranium with less than the usual amount of U235; enriched has more).
Superheavy elements would be very difficult to produce in significant quantities with known techniques. Shells will probably continue to be uranium for quite a while.
Well, the frequency of visible light is about 6x10^14 Hz. Unless we can make ultraviolet fibres, that is an upper bound.
Not quite. Your sampling rate is limited to 6.0e14 Hz, but you can have many signal levels that can be detected. The problem is that for n levels, you need n*n photons to compensate for measurement uncertainty, which means that for b bits per sample you need 2^(2b) photons per sample. The energy requirements for this get nasty very fast, but for a small number of levels it's practical.
You run into analogous problems with frequency-domain schemes (this was a time-domain scheme). You can increase the data rate by increasing power, but the power cost is ugly.
Great. It will be interesting to see what the half-lifes of elements in the "Island of Stability" end up being. Half-lives of some of the intermediate elements have been milliseconds or longer, but it remains to be seen whether elements in the island will be stable enough to synthesize in macroscopic quantities (not that there's a good reason to do so yet).
I went to a talk about 3 months ago where the guy was talking about increasing bandwidth. Basically, to sum up a two hour talk in a few words, it boils down to "Getting fiber optics to move information faster isn't a challange, it's getting the information into and out of the optic that's the problem." He went on about details of nanofabrication, and new synthetic structures can bump up the transfer rate and frequency regulation of light (*NOT the frequency of the light, but the rate that they can change the frequency*).
This used a different approach to packing more information into the fiber - the use of many carriers, each modulated at a relatively low frequency, and spaced far enough apart that there wasn't cross-talk between them. The professor you refer to seems to be looking at ways of more quickly modulating a single carrier. This is certainly very useful, but there are other ways of increasing bandwidth. Frequency-domain schemes of the kind that I described are the ones that have been generating the recent news (though there are limits to how far it is practical to push this).
Does anyone know the theoretical maximum bitrate of fiber?
This was covered in a thread a couple of months back. A few limits apply.
Firstly, you are limited by the bandwidth of your optical carrier. For visible light and assuming reasonable power constraints, you won't be able to get more than about 1.0e15 bps. You could push this by pumping in a _lot_ more power or by using a higher frequency, but these have very serious problems. IMO, a better solution would just be to use bundles of fibers (or multiple lasers or what-have-you).
DWDM and other frequency domain techniques won't help here - as you modulate data onto a carrier, its frequency spreads out, limiting how densely you can do WDM, or how much data you can transmit per channel using a given density of carriers. 1.0e15 bps or thereabouts is as far as you can go without producing/using frequencies higher that the visible light range.
The other, more immediate limit is in the physical medium that is carrying your optical signal. In this case, fiber. Fiber is mainly limited by the operating frequency range of the amplifiers used to boost the signal (usually erbium-doped fiber lasers). I'm told that this is in the 1.0e11 to 1.0e14 Hz range (I honestly don't remember where within those bounds it fell). Other readers can probably give you more accurate information.
One of the points mentioned in the article was that they hoped to develop better amplifiers - that could process a wider range of frequencies and let them use another frequency range for transmitting data. This was a topic for future research, not an announcement of something they'd accomplished, though.
SOMEPLACE -- Some company invented something today that increases the capacity of something or another by ten trillion times. "This thing we came up with is so incredible" said the company's CEO. Consumers are never expected to use or see this coveted thing, but we thought we'd tell you about it in detail anyway.
Actually, the article is describing practical application of known experimental technologies - exactly what is needed to bring it into real use in the backbone and (later) downstream. We've heard about multi-terabit transmission with DWDM before, but this is looking closer to an actual product.
Like the title says, what about Helium 3 fusion? It isn't supposed to produce any neutrons, just charged particles.
Fusion reactions of any kind would still produce gamma rays, as this is one of the ways that nuclei shed excess energy after fusion. These should be easily detected, as the original poster stated.
The fact that we can't do it now doesn't mean we can't do it with a new technology soon. Also, didn't you see that story a while back that Siemens or some comapany got 1 Terabit/sec over a single strand of fibre?
Fiber has the wonderful advantage of being extremely easy to shield. It's a lot harder to do that to electrical cables. Also, the ultimate bandwidth available on fiber and other optical carriers is huge. Electrical systems are much more limited (shielding is difficult, parasitic capacitance and inductance are big problems, and the electrical characteristics of the wire itself get ugly at very high frequencies).
And this isn't about transmitting over something like cable, which is shielded and optimized for data transfer - it's about transmitting over household wiring. Household wiring is unshielded and has very messy geometry. It also has a huge number of devices with wildly varying electrical characteristics hanging off of it. Unless you're working under ideal conditions, trying doing serious data transfer over it would produce a garbled mess.
Phone lines within a house are a bit better, as there's less crud hanging off of them. Shielding still isn't great. 10 megabit has been achieved in commercial products, here.
As far as transmitting high frequency data over a city's power grid, good luck. Reflections, interference, and cross-talk will be nightmares.
We'll need a fiber infrastructure at some point anyways. I say just push for it instead of trying to use existing copper networks.
1. Warp 1000 light years away, simultaneous with the frame of reference of the solar system.
2. Accelerate to near light speed.
3. Warp back to earth, but 999 years before it left.
You could indeed do this with a faster-than-light drive. Where's the problem:)?
The question then becomes, what are the physical consequences of time travel, and does this always result in contradictions? This will either rule out or severely limit what can be done with time travel, and by extension FTL drives.
Slashdot Mirror
At that rate, they'd move 7.2 metres (23.4 feet) per hour. Power plants and industrial facilities are *big*. Unless you saturate one with bugs, your robots will take days to reach their destinations.
What's powering these suckers, if they take days to go anywhere? Either one of several unlikely broadcast power schemes is being used, or they're tethered, or they can't go more than a few tens of metres before their batteries run out.
The robots as described would have an interesting time actually fixing anything. Especially on battery power. The most useful application that I can think of would be to use them as remote cameras to see what's going wrong, but there are easier/more practical ways of doing this (put a motorized video camera on a ceiling track, for instance, and use faster tethered robots or just something like a proctoscope for getting into the pipes).
This is an incomplete list, but you get the idea. IMO, this is either a hoax or else the article has significantly munged many of the details.
To continue: The K7 also supports an L3 cache on the motherboard. IIRC this was slow, but I don't remember the exact specs.
As AMD is the one putting together the modules for the K7, the design burden for providing a full-speed L2 cache is in their court. IIRC they were planning to sell half-core-speed systems initially, and offer full-core-speed systems as higher end later (presumably when yields on full-core-speed parts went up).
It will be interesting to see what happens when they move to 0.18 micron. They could fit a fairly large L2 cache on-die, but size would still be less than the maximum that the off-die version supports (up to 8 megabytes IIRC).
If I understand correctly, the K7's L1 cache is fast but small (64/64), and the L2 cache can run at variable speeds. Some of the earlier systems tested had it running at 1/3 core clock IIRC, while the systems that AMD released benchmarks for had it at 1/2 core clock (again IIRC). The chip supports an L2 cache running at full core speed, so it will be up to the module and RAM makers to provide the infrastructure for that (running an off-chip cache at 500+ MHz isn't trivial).
It has an LCD screen. AFAIK, those still aren't cheap. Not that that makes this thing worth the price, but that would explain where at least some of the price comes from.
While this makes the most sense from the point of view of conveying the most relevant information and eliminating redundancy, in practice all this would accomplish in the short-term is to make the signal-to-noise ratio that much worse. Instead of 100 polite emails and 10,000 flames, the authour gets 1 polite email and 10,000 flames.
The loophole is that if the 1 email is from a well-respected entity whose opinions carry weight, it would be useful. Open Sense, if implemented, could eventually gain such weight. However, it won't have such weight when first implemented - this would be a medium-term effect at best, long-term at worst.
OTOH, those of us who write sensible letters could always post to both. That would give the best of both worlds.
As a side idea - it might be a good idea for someone who _does_ carry weight - for instance, Linus - to write a letter to the publisher that both states that the flamers do not represent his views (possibly apologizing), and then politely taking issue with the inaccurate points presented in the article. This might actually accomplish something.
Going to the publisher helps in that the article's authour is probably just ignoring all Linux-related emails. Coming from Linus or another noteworthy and level-headed developer/advocate would give it the credibility to get read.
In any event, if you do get Open Sense off the ground, please let me know. I'd be happy to contribute.
How could they do this without using reverse-engineered specs? They need specs from _Apple_ to guarantee compatibility, and as other posters have pointed out, they aren't getting them.
It's not different than being on Intel in that respect, in fact you are guaranteed that if you want to support newer Intel chips you will probably end up writing some code.
Um, no. Or at least, you don't have to. You could dig out an old copy of Windows 3.1 and it would run on your brand new Pentium III, because the architecture is completely backwards-compatible (which is both a blessing and a curse, but that's another story). Now, any _application_ that, say, used SSE would be in trouble (because of data lost during context switches), and you could certainly increase efficiency by modifying code for the new processor, but the OS wouldn't _break_. Such is not the case, I am told, with G3-based systems.
No Linux advocate that I have dealt with (me included) want Linux to be the only OS. What many of us want is for Linux to be able to do everything. There is a big difference, but because this would put it in competition with every OS, some people think we want them all to go away.
Um, take a look at some of the other posts in this thread. And in the threads attached to the MacOS X post. Many of the posters here, who would certainly call themselves Linux advocates (whether or not they fit the definition that you use), have a strong knee-jerk reaction that says that any non-Open operating system is intrinsically evil and should be abolished. They then proceed to loudly make this opinion known.
They also generally don't mention *BSD. When it comes up, the reaction is along the lines of "Huh? Oh, well, since it's Open, it's ok.". And then they go back to bashing non-Open OSs.
This seems to indicate that many of these "advocates" _do_ want to actively destroy non-Open OSs regardless of whatever merits they may have. And for many of them, Linux == Open == Linux.
I'm not saying that _all_ Linux advocates are like this by any means - but a substantial and very vocal minority are.
As stated in my previous post, you don't need to recompile the kernel to add drivers to Be, or need access to the kernel source to write drivers. Most drivers are kernel modules loaded at boot-time, analogous to "modules" under Linux.
I have already said that I recognize that sometimes things _do_ need to be tweaked in the kernel - but I think that for the vast majority of _users_ who don't do kernel tweaking, BeOS is fine. Linux isn't going away any time soon, don't worry.
The people to take that up with are the BeOS users, not Be itself. Be makes an active effort to publish all of its API and document as much of it as possible. If you want to release an open application under BeOS, there's nothing stopping you. Porting isn't that hard either, because the guts of BeOS are Unixoid.
Bear in mind that these are applications. There's nothing to prevent apps under BeOS from being Open or Free. It is only the kernel that's closed. Now, you could make the same arguments about the kernel as you do applications, but in practice I see fewer kernel bugs that need fixing.
And if I want to tweak kernels, I can still use Linux. BeOS doesn't have to be the *only* OS; however, without meaning to offend, I think that many Linux advocates _do_ want Linux to be the only OS. This is a Bad Thing IMO.
Re. drivers, I'm happily doing driver development under BeOS with no more access to the kernel source than any other user. The headers are all that's needed.
Um, no, by straight numbers most users seem to think that Windows is the best choice. You're trying to convince them that Linux is. He's trying to convince them that BeOS is.
How many computer users - out of the total number of computer users - even program? How many, given the opportunity and the tools, _would_ mess with the kernel? Very few.
Linux is nice. I just plain _like_ *nix variants. But the most that I've done under Linux is look in the
I've recompiled _applications_, but the kernel header files are all you need for that, and Be gives you those.
However, I'm getting sidetracked. While I enjoy Linux for programming, most users aren't programmers. In terms of installation and ease-of-use, IMO BeOS wins (though Linux is catching up).
Programmers would love Linux. Many of them already do. IMO, the users that *don't* program would love BeOS. They are who use most of the desktop machines.
Yes, it does. I have a BeOS machine sitting next to me right now.
While the OS is closed, you still get all of the header files and semi-complete documentation (what isn't there is being written). Applications can be closed or open as the applications programmer wishes; AFAICT, Be doesn't care. More applications are good regardless of the license they're released under, and Be is too small to write applications itself. It loses nothing from open apps, and loses nothing from making the entry points to the OS visible.
Not a problem. Here, if you're interested, is a description of the "magic island" idea and an explanation of why this article is significant.
Some elements are more stable than others. Lead will remain Lead no matter how long you leave it, but Plutonium will decay over a few thousand years into lighter elements. In addition, there are many types - isotopes - of each element. These all have the same number of protons but have different numbers of neutrons. Some are more stable than others; for instance, Carbon-12 is stable, but Carbon-14 is not. (The "12" and "14" are the total number of particles - protons and neutrons - in the atom's nucleus).
If you draw a chart of all of the isotopes of all of the elements, a pattern emerges. The chart has element number ("atomic number", the number of protons) as one axis, and "atomic weight" (the total number of particles - protons and neutrons) as the other axis. The stable isotopes form a band running up this chart diagonally, slightly curved.
Further irregularities are observed. In places, there are large blotches of mostly-stable elements, and in other places there are gaps where the elements are mostly unstable. These blotches are sometimes called "islands of stability".
Islands of stability happen when the number of protons or the number of neutrons in an atom's nucleus is a "magic number", or close to a "magic number". As you add protons or neutrons to a nucleus, they stack up in "shells" at different energy levels, much as electrons do in an atom. A completely full shell - a "closed shell" - is very stable. The "magic numbers" are the numbers of protons or neutrons required to have the outermost shell of the nucleus "closed" - exactly full. Iron is in the middle of one island of stability, and lead is in the middle of another.
One problem that scientists have had when trying to produce "superheavy" elements - elements with more protons than any element that we've found in nature - is that elements are less stable the more protons they have. This is why many of the "heavy" elements (elements with many protons) are radioactive. As they climb into the range of elements that have more than 100 protons, the elements get very unstable, so that you barely have enough time to detect them before they decay (or sometimes are left only looking at the decay products).
However, many scientists hope that there will be another island of stability around elements 116-118. These elements would have "magic" numbers of protons and neutrons, and might live much longer than the other "superheavy" elements produced so far. Some isotopes of them might even be stable. This "island" is called the "magic island of stability", because it's a group of stable or almost-stable elements in the middle of a sea of very unstable elements and isotopes. For many years, scientists have been trying to produce elements that were in this "magic island" to see if they actually are stable.
This article describes one of these experiments, that has succeeded in producing one of the elements in the "island". Whether it's as stable as hoped remains to be seen. In fact, each of the isotopes of this element will have to be produced to see whether or not the island really is stable.
Very exciting, for people who follow the quest for "superheavy" elements regularly
The main problem that I see is that there will be great pressure on the programmers to come up with projects that sponsors will like. This will be a market controlled by the buyers - projects that sponsors aren't interested in won't get funded, no matter how interesting or innovative they are. While the same is true in the bounty system described, this new approach doesn't alleviate it. IMO, neat but unprofitable work will continue to be done on spare time or by blue-sky development teams.
Secondly, I'd like to address the point re. bounty systems encouraging closed development. This can indeed happen - but it depends on how the bounty system is implemented. If I understand correctly, the newer schemes that have been proposed allow teams to bid on the jobs and sponsors to pick the teams that they like. Then the contract is finalized. If most work is done after the contract is in place, there isn't the duplication of effort that you get with the original bounty approach (six people writing something independently and only the first getting paid). You also don't have to get closed development - once the contract is in place, it doesn't matter if others can copy the work, because only the original group will get paid for it. The original group loses nothing by sharing. Finally, programmers would still have to work in groups under this system. A really large project just can't be handled by an individual. Smaller projects might be handled, but the sponsor may want it in a shorter length of time (though there are hard limits to how much a project can be shortened by adding developers). In short, I don't see a well-implemented bounty system hurting openness.
The one point which remains valid is that the software projects offered may not be very interesting or innovative. IMO, this is a tolerable tradeoff. Nothing prevents the programmers from doing something more useful in their free time; this is just a good way of arranging contract work so that the programmers can get paid.
There will also be pressures on sponsors to _make_ their projects interesting. If they present a project that nobody is interested in, they'll either have no takers, low quality takers, or have to jack up the price to unreasonably high levels. Employers presenting interesting, innovative projects will have the advantage in this regard, which is a Good Thing.
IMO, there's actually a place for both systems, but I feel that the modified bounty/work order system would be most practical in the near term.
There's always the Brute Force and Ignorance approach: Mine the limestone back off the ocean floor and break it down into calcium oxide and carbon dioxide again. This would take a fair amount of industry, but if we have the wherewithal to terraform a _planet_, this should be do-able (if we want to).
The last is a big caveat. Terraforming will be horriffically expensive. Either we'd need an extremely good reason to terraform, or the cost would have to drop a *lot* before we would do so.
I'm not sure that it would. The atomic weight of an element isn't the only influence on its density. The density is determined by the atomic weight, the crystal structure of the element in solid form, and the distance between atoms. The last item (and the middle item, to an extent) is a result of the structure of the electron shells around the atom.
IIRC, the second row of transition elements had a peculiar property that made atoms in that row very compact. Similar pecularities may exist elsewhere, but IIRC the actinides and following elements weren't particularly dense.
Osmium is still the densest element IIRC. I'm not sure exactly why uranium is used in shells as opposed to something denser, but it still works. It's dense, stronger than lead, and they have a lot of it left over when they produce enriched uranium (depleted uranium is uranium with less than the usual amount of U235; enriched has more).
Superheavy elements would be very difficult to produce in significant quantities with known techniques. Shells will probably continue to be uranium for quite a while.
6x10^14 Hz. Unless we can make ultraviolet fibres, that is an upper bound.
Not quite. Your sampling rate is limited to 6.0e14 Hz, but you can have many signal levels that can be detected. The problem is that for n levels, you need n*n photons to compensate for measurement uncertainty, which means that for b bits per sample you need 2^(2b) photons per sample. The energy requirements for this get nasty very fast, but for a small number of levels it's practical.
You run into analogous problems with frequency-domain schemes (this was a time-domain scheme). You can increase the data rate by increasing power, but the power cost is ugly.
Great. It will be interesting to see what the half-lifes of elements in the "Island of Stability" end up being. Half-lives of some of the intermediate elements have been milliseconds or longer, but it remains to be seen whether elements in the island will be stable enough to synthesize in macroscopic quantities (not that there's a good reason to do so yet).
This used a different approach to packing more information into the fiber - the use of many carriers, each modulated at a relatively low frequency, and spaced far enough apart that there wasn't cross-talk between them. The professor you refer to seems to be looking at ways of more quickly modulating a single carrier. This is certainly very useful, but there are other ways of increasing bandwidth. Frequency-domain schemes of the kind that I described are the ones that have been generating the recent news (though there are limits to how far it is practical to push this).
This was covered in a thread a couple of months back. A few limits apply.
Firstly, you are limited by the bandwidth of your optical carrier. For visible light and assuming reasonable power constraints, you won't be able to get more than about 1.0e15 bps. You could push this by pumping in a _lot_ more power or by using a higher frequency, but these have very serious problems. IMO, a better solution would just be to use bundles of fibers (or multiple lasers or what-have-you).
DWDM and other frequency domain techniques won't help here - as you modulate data onto a carrier, its frequency spreads out, limiting how densely you can do WDM, or how much data you can transmit per channel using a given density of carriers. 1.0e15 bps or thereabouts is as far as you can go without producing/using frequencies higher that the visible light range.
The other, more immediate limit is in the physical medium that is carrying your optical signal. In this case, fiber. Fiber is mainly limited by the operating frequency range of the amplifiers used to boost the signal (usually erbium-doped fiber lasers). I'm told that this is in the 1.0e11 to 1.0e14 Hz range (I honestly don't remember where within those bounds it fell). Other readers can probably give you more accurate information.
One of the points mentioned in the article was that they hoped to develop better amplifiers - that could process a wider range of frequencies and let them use another frequency range for transmitting data. This was a topic for future research, not an announcement of something they'd accomplished, though.
Actually, the article is describing practical application of known experimental technologies - exactly what is needed to bring it into real use in the backbone and (later) downstream. We've heard about multi-terabit transmission with DWDM before, but this is looking closer to an actual product.
Fusion reactions of any kind would still produce gamma rays, as this is one of the ways that nuclei shed excess energy after fusion. These should be easily detected, as the original poster stated.
Look up "Lawson Criterion" in your physics text.
Fiber has the wonderful advantage of being extremely easy to shield. It's a lot harder to do that to electrical cables. Also, the ultimate bandwidth available on fiber and other optical carriers is huge. Electrical systems are much more limited (shielding is difficult, parasitic capacitance and inductance are big problems, and the electrical characteristics of the wire itself get ugly at very high frequencies).
And this isn't about transmitting over something like cable, which is shielded and optimized for data transfer - it's about transmitting over household wiring. Household wiring is unshielded and has very messy geometry. It also has a huge number of devices with wildly varying electrical characteristics hanging off of it. Unless you're working under ideal conditions, trying doing serious data transfer over it would produce a garbled mess.
Phone lines within a house are a bit better, as there's less crud hanging off of them. Shielding still isn't great. 10 megabit has been achieved in commercial products, here.
As far as transmitting high frequency data over a city's power grid, good luck. Reflections, interference, and cross-talk will be nightmares.
We'll need a fiber infrastructure at some point anyways. I say just push for it instead of trying to use existing copper networks.
2. Accelerate to near light speed.
3. Warp back to earth, but 999 years before it left.
You could indeed do this with a faster-than-light drive. Where's the problem
The question then becomes, what are the physical consequences of time travel, and does this always result in contradictions? This will either rule out or severely limit what can be done with time travel, and by extension FTL drives.
You run into similar questions with tachyons.