If they were underground, you wouldn't have any ice problems. Distance would also be less of a problem. And as the cables wouldn't need to support their own weight, you wouldn't have to worry so much about tensile strength. You'd also not have to cut any trees back. Oh, and you would save on not having to build large numbers of pylons.
Put all of the fusion researchers in a country like Alaska. Have an empty fusion reactor shell ready for them and provide them with adequate funding for whatever they want or need. The computers and other essential devices for research are on one circuit, the heating for the buildings is on another.
Cut the power to the heating circuit by 20% each year.
If they don't acieve fusion in time, put the next generation of fusion researchers up there, give them time to read the notes, turn the heating up to 100%, then start the cutting the following year.
The researchers are bright and capable. They suffer from funding (nobody wants to pay), politics (from within themselves and from their paymasters) and complacency ("it doesn't matter if we don't solve X, Y or Z in our lifetimes").
By eliminating all three problems, progress should improve substantially. Somehow, I seriously doubt anyone is going to try this method any time soon, though.
Use extremely high voltages and very low current. Power loss is proportional to voltage, but proportional to current squared. Extremely high-tension lines with next to no current should be able to deliver power over a very large region with very little loss.
With fewer power stations, the grid would be simpler and less likely to go into spasms when a tree falls on a power line or when some other accident occurs. Keeping things simple is Good.
Maybe three is an underestimate, but even one per State is vastly superior to the existing setup.
If you had two Linux virtual systems, you could update the one not in use, then fail-over all of the running applications to it. You then update the one that was in use. The kernel is then updated, but the user doesn't have to wait for a reboot, as a virtual system is always running.
Step 1 is only required if some patches are optional AND either have to be applied in a certain order or can't be applied together at all. This step involved using the %pre phase of the RPM to roll back any changes that will clash with the patch that you want to install.
Step 2 has two parts. Files that simply overwrite existing files can be installed with no further change. There probably wouldn't be too many examples of those. The other step is to install patch files into a patch archive directory.
Step 3 has one mandatory part and one of two optional parts. The first part is to apply the binary patch(es). You're always going to need that. The second part is to re-insert patches rolled out by the %pre phase that can be rolled back in again at this point. This is only meaningful if there is a %pre phase. Finally, if there isn't a %pre phase, you want to clean up the patch archive directory.
There's a campaign to ban energy-wasteful technology where cheaper, superior alternatives exist. In the unlikely event that the campaign achieves a meaningful result, America could dispose of several existing power stations without the need for nuclear stations to replace them.
(Better yet, if the campaign succeeds AND one of the two fusion reactor projects produces cheap energy, we could eliminate all conventional and all fission reactors entirely and have just two or three fusion reactors per continent.)
I just want to clarify one thing, though. When you say that the GIMP "has no interest" in supporting 16 bits per channel, would I be correct in taking that to mean that the GIMP developers have been approached on this but have stated that it's not something they're interested in supporting?
If the answer is "yes", I'm moving the item up my to-do list. That's exactly the sort of situation that does get to me. Coders have every right to decide what they want to code and what patches they want to accept, but there is a big difference between being selective and becoming stagnant. Selective is necessary. Stagnant is best left to swamps and marshland.
In fact, if early coders had kept pace, the GIMP might never have been written. Between existing painting programs, the Utah Raster Toolkit and xv, early image manipulators had plenty of resources. At least, for the time. Those tools have long-since rusted.
Now that's a different kettle of fish. (Though I would have preferred it if the other posters had considered the fact that I can't read minds as easily as I can read posts.)
16 bits per channel is much better. I still think the number of channels is limited, though. When you get right down to it, it would not be hard to have an image editor that supported stretchy integers for however many bits you wanted in the channel, and no hard-coded limit on the number of channels. (Although you'd presumably need a plug-in for channel types that were unknown.)
Well, I guess I'll add this to my long list of "things somebody, somewhere, really should do but it looks like nobody else is going to be bothered for a while". I worked on a very similar problem a long time ago and I vaguely remember the solution I used. At the very least, I should be able to put together something that'll work with images of arbitrary complexity.
16bpp seems... crude. Besides, there should be nothing in the palette that can't be produced in a 24-bit mode, since it's just a table of RGB values. Well, unless you've an alpha channel OR a layering channel, in which case you need a 32-bit mode. If you have both, you're into the 40-bit realm, and I'm almost certain there are no packages which support that.
If you add in support for tetrachromats (hey, why should we encourage discrimination?) and IBM's polarized monitor, we can get to 96bpp without much trouble. I'm sure, with some inventiveness, we can round it up to 128bpp quite easily.
Now, doesn't a 128bpp image editor sound sooo much cooler and geekier than a paltry 16bpp? Besides, with broadband taking off, we've got to soak up the excess bandwidth somehow.
GIMP is powerful - I use it a fair amount - but if people are finding it can't do what they want, then it's not powerful enough in the right ways.
One thing I don't like about any existing drawing/CAD package is that virtually everything out there assumes there's only one kind of user in the world only interested in doing one kind of task. (Or very close to that.)
I guess I've become spoiled with the flexibility of Slashboxes - I like being able to pick and choose the sorts of things that are visible, not being stuck with just one or two views. I guess I also run into the limitations of programs a lot - which either means the programs aren't flexible enough, or I'm just too weird for the coders.
Photoshop is standard. Fair enough. But if the menus and key sequences are soft-coded, you can write a skin to reproduce Photoshop's user interface. The same goes for Corel Draw, FontLab Studio, etc. Ultimately, you're manipulating some combination of bitmaps and vector diagrams, with some sort of mechanism for grouping and attaching components, plus a bunch of absolutely bog-standard scripts for defining lines, curves and outlines.
(You wouldn't WANT all of those capabilities in one program, but if the framework is solid and the scripting is powerful, you could plug in whatever combination you wanted with whatever interface you liked.)
People have been able to write modular code to some degree for at least the last 25 years. Computers and Operating Systems have had the power to sport highly sophisticated engines for almost as long. I fully understand that we need specific programs ported to this, that and the other, I just don't see why there's so little sign of moving past that point.
But I think a variant of this pre-dates Spiderman. "Sticky bombs" - grenades that used an impact adhesive of some kind to stick to vehicles - are a fairly old idea. It sounds as though somebody has refined the idea, improved the glue so that it's much more effective, and used a radio transmitter rather than an explosive charge.
There's no question that Spiderman would have used impact adhesives - he would want the web he launched to stick specifically to what he wanted and not to anything else. This would be an effective way to achieve exactly that. It would be interesting to know what ways such glues ARE used - both in the Real World and the Comic Book Universe.
Minowski space is non-Euclidian, so what is required is a set of suitable transforms so that you can do each individual operation within Euclidian space, even if you can't do the whole lot at once in a way that you'd like. Messy, but it does actually work.:)
I very much agree on the String Theory and believe it will be resolved by suitably compartmentalizing each aspect in turn and mapping it into a form we can visualize. Hey, it's very difficult to imagine N-dimensional regular solids, but it IS easy to imagine a torus. It turns out that, if you use staggeringly complex mathematics and Fermat's Last Theorum, a transform does in fact exist that maps 1:1 between the two types of shape.
(In fact, the nature of the transform is quite unimportant. If there is a hypersolid that is of interest, so long as you can identify the corresponding torus, you can do all of the operations you want on the torus without ever needing to know anything about the extremely complex theories that go into the mapping.)
The same will be true of Superstrings. There WILL be something simple and elegant that we can map these 12-dimensional anti-gravitational objects to. (Superstrings have negative gravity. It's one of those factoids that stuck with me at the Newton Tercentenary Lectures at Cambridge University, along with Black Holes having an internal resistance of 33 ohms.)
Once the transform has been established, all aspects to Superstring theory will be staggeringly obvious and calculations will be reduced to an extremely simple form - simple enough to be covered by 17-18 year olds, very likely. These sorts of things temd to reduce very easily, once they start reducing. Unfortunately, we're not at that point. I don't know of any elegant transform for a superstring and I doubt one will be discovered in the next 10-15 years. After that, all bets are off.
It'll just be a matter of finding the right perspective.
And it was a bit more generalized than that. I'd started with the argument that the whole of General and Special relativity could be derived solely from Pythagorean and Euclidian geometry, requiring absolutely no later knowledge whatsoever. In order to do that, an intermediate step requires that you can transform between linear and non-linear coordinate systems. Anyways, I was able to show that all of the necessary transforms exist to go between a "lumpy", chaotic relativistic system and a geometrically "perfect" Euclidian system and vice versa.
It was a fun project, for a number of reasons. One of the most interesting consequences is the implication that, had Greek civilization endured, they had sufficient theory to have managed Einstein's famous early lectures 2,000 years early. Without any way of actually validating the results - had they believed them - it would have remained theory until the present day anyway, so wouldn't have changed a whole lot. It is interesting to speculate what the Greek scholars would have made of such a proof, though, given my requirement that the proof had to require no knowledge they did not possess.
If anyone does figure out how to do time-travel within one's own light-cone, I guess I could ask.:)
A bridge with fish under it is called a heck. A troll under the bridge should be paid with the nest of golden eggs. The troll catches the fishing rod. "Nice craftsmanship, but not very valuable."
I started using International Packet Switch Stream in, oh, 1984 and developed a variable-speed networking protocol for a daisy-chained parallel port-based local area network maybe a couple of years earlier. Also got a crappy (but workable) speech synthesizer going on a 32K PET computer a year before that. Figured out that you could do a decent phonetic dictionary in software, even at 1MHz, and that the sound capabilities were just good enough to get usable output.
Rebuilt an R1155 in about 1977. (You ever TRY to get hold of half those valves?)
I wasn't just around. Sorry to hear there were such unfortunates.
The theory of time as being "special" requires that time not be symmetrical. Some things simply can't work in reverse. (There was a little uncertainty about this, in the case of the Universe contracting, but the problem was solved by Professor Hawking in the late 80s.) The Second Law of Thermodynamics requires that entropy can only increase, but if you could go back in time, you could violate this by having greater entropy in the past. There is great resistance by physicists to anything that might permit time-travel except into the future.
(If wormholes exist, they are only stable so long as you CANNOT violate the Second Law of Thermodynamics, strongly implying that any time-travel that is permitted is highly constrained, as wormholes certainly weren't envisaged with the laws of thermodynamics in mind. That property was unexpected, in many ways, but is reassuring in the sense that it does pass an important sanity check.)
I imagine that limited time-travel will be proven - at least in theory - but that all such methods obey those fundamental principles that appear to be universal to all points in space, time and scale. As such, totally free travel through time will likely not be possible (so, no TARDIS') but time-travel completely outside of the light-cone* of that region of space may be much less constrained.
*A light-cone is the region of space/time that is roughly cone-shaped that describes the maximum possible region of space at a given time that anything at the center of the cone could interact with, assuming no information can travel faster than the theoretical speed of light in a perfect vaccuum. Since the cone defines how far information can have travelled, NOTHING outside of the cone can have affected what lies at the center and vice versa. Thus, travelling through a non-simply-connected method from the center of the cone to ANYWHERE outside of it can NOT generate paradoxes for the traveller. As such, if connecting two points of space/time together that are distant enough to meet the requirements and in a way that is stable enough to traverse is possible, there is no obvious prohibition on where in time you could travel.
Oh, it's important to note that the cone extends in both directions in time from where you are now, so covers all of space that could have - at any time in the past - have interacted with you in the past or present.
Flatland, unfurtunately, doesn't help us here. However, with some slight modifications, Flatland CAN be used to teach students much earlier about the concepts of relativity in a way that does NOT require sophisticated equations. (Well, relativity can actually be covered at the same time as Pythagoras' theorum. I think it would be better if it was, and that if both were taught several years before they currently are.)
Imagine that Flatland were not strictly flat, but had hills and valleys. However, the inhabitants still only see along the "plane" of Flatland. Their Universe exists in the third dimension, even though they have no way of directly interacting with it.
Now, imagine that Flatland was rising through the third dimension, but not entirely evenly or at a constant rate. Thus, different parts moved through the third dimension faster than others, but which parts varied over time. Because of this, Flatland "stretches" (unevenly), so if it takes T seconds to slide from A to B at one time, it'll take T+N seconds to make the same journey at a different time.
Hmmm. Let's add a few more properties. Let's imagine that Flatland is rubbery, so that all Flatlanders create little dimples in Flatland. They can't see these dimples, because they can only see along the surface. They can't directly interact with the dimples at all. If they're observent, though, they'll notice other Flatlanders slide faster towards them than away. Flatlanders who eat more create bigger dimples.
Finally, let's sat that Flatlanders are all on speed. Even the really fat ones who weigh Flatland dow
Well, I advise others not to. I can't resist the temptation. The equations don't just apply to "flat" spacetime, because you are not specifying unit vectors. The award I won (for the most novel use of relativity, as part of the centenary awards) was in demonstrating that these equations are completely independent of the shape of spacetime, that the curvature of spacetime can actually be derived from them, and that the effect of gravity on relativistic time is a direct consequence NOT a distinct phenomena.
First off, it should be obvious to anybody that space can't just be deformed into nothingness. That has no meaning. Space is actually deformed into time and time is deformed into space.
No, M is not "rest mass". Relativity doesn't have a "rest mass", or a "rest" anything. Indeed, since Newton effectively eliminated absolute space, there hasn't been a notion of "rest mass" in physics (even classical physics) for over 300 years. You're showing your age a little, there.
Of course, the simplest "trick" is to assume that space/time is uniform (but not flat), determine the shape of space/time and derive a suitable set of vectors. The vectors need not be linear, they need only be orthogonal. Once you have those vectors, then space/time will be "flat" relative to those vectors at that instant. You'll need a new set of vectors for every instant, but the problem is quite solvable. Using transforms for turning a "hard" problem into a trivial one is a firmly-established tradition and works extremely well. You should try it some time.
For those who are simply looking in and wondering what the hell is going on, my sympathies. Simply put, relativity doesn't have any absolutes - other than C, which merely happens to equal the speed of light in a perfect vaccuum. The only way to measure anything in relativity is to measure relative to something. There are no fixed points in space or in time, so that leaves measuring relative to the observer. The measurement is not a trivial one, if you want to be precise, as mass deforms space/time, so the observer and the observed (and everything else nearby) complicates the picture.
Actually, it doesn't end there. The deforming of space isn't instantaneous, nor is it's resptoring. Information, including gravity, travels at a finite velocity and state changes take a finite time to complete. Thus, the "gravity well" around any object will not be uniform but look more like a comet tail - compacted at the front, stretched at the back - where the non-uniformness is going to depend on velocity. Now, here's the gotcha. There is no absolute velocity and no absolute space. You can picture everything being relative to all of the particles in the quantum foam, but they all travel at different velocities.
In consequence, at the microscopic level, gravity will not be uniform at all. The well will not be smooth, but will have irregularities in it. The irregularities will be small - usually - and have no measurable significance outside of quantum mechanics. Such details will be of far more interest to quantum cosmologists exploring the behaviour of particles travelling near the event horizon of a Black Hole.
If you want to deal with gravity at this scale, you cannot use the trivial transform I outlined above. You'd still need to use a transform, but now you'd need to transform into a chaotic system, not merely a non-linear one. The good thing, here, is that the curvature of space becomes a consequence of having Strange Attractors and is not something you actually need to model directly. However, chaotic systems are notoriously difficult to model (because they are highly sensitive to the precision of your calculations, the initial values used, etc).
For this reason, don't expect a quantum-scale model of gravity any time soon. I'm not even convinced that the exploration that is going on is in the right direction - superstrings need an awfully large number of zero-sized dimensions. I am firmly conviced that the k
That might very well work. The only problem, right now, is that the only way to generate neutrinos is through nuclear processes, which would add more waste than you'd remove. I would be willing to predict, though, that within 50-100 years, some variant of that approach will be used for nuclear waste disposal, but also in nuclear reactors (you could run the reactor with a lot less fuel and no control rods whatsoever if you could regulate it via neutrinos).
Yeah, I know you meant it as a joke, but it's one of those jokes that is likely to have more than a passing resemblance to something that actually happens...
And if you don't knw that T'=T/sqrt(1-v^2/c^2), with similar equations for M' and L', I can't help you. Confused? Well, having won an award on this subject, I do hope not. It would mean that there are an awful lot of very stupid professional physicists in England.
Where they exist, use fault-tolerent components for interconnects. Making things fault-tolerent is tough, so re-using such stuff will simplify the task. Best of all, use stuff with a significant history behind it, because communication will be the biggest headache and bugs there will be hard to pinpoint exactly.
When coding, assume that anything can crash. I don't care if you use exception handling, reactive methods or a purple pizza, but you want components to be able to recover from failure (by restarting if need be) and you want anything that talks to it (and the data!) to be able to survive a loss of connection and handle the condition in a predictable way. (This may mean resending to another node, waiting for the old one to reset, buying said pizza over the Internet, whatever.)
Keep It Simple! The more layers, the greater the liklihood of bugs. (There are exceptions - if you're using CORBA, then the ACE ORB is heavyweight but generally considered pretty solid. That's partly because it has a decent amount of maintenance and has been around a while. I would probably not go for lesser-known ORBs, though.) The more complexity you can avoid, the more certainty you can have that the code is solid.
Analyze, Specify, Design, Implement, Validate. There are no "perfect" techniques to Software Engineering, but a few things generally hold up fairly well. The first of these is to keep the steps in the process as clean and methodical as practical. There will be some overlap, but in general you can't implement good code until you know what good code you want implemented.
Testing Is Important. There are more schools of thought on testing than there are programmers. (At last count, at least three times as many.) Even if nobody is quite sure what role testing has, most seem fairly convinced it has got a role. One popular creed states that design should be from the top down and testing from the bottom up. (ie: test at the level of the components that call nothing else, then build up step by step.) Another states that since you have a specification (you do, don't you?:), you can write the tests according to the specification first, then write the code to comply with the tests. You can even follow both approaches, if it helps you feel better. Just pick something and stick to it. My preferred testing method is to check "typical" conditions, boundary (extreme) conditions and erronious conditions.
Never assume that some other coder's assumptions about the compiler's assumptions of what was assumed by someone else entirely bears any resemblance to what you think. Computers know all about luck and hope and how to utterly crush them when you're not looking.
Yes, some of those do conflict. How to keep things simple AND have fault-tolerence, for example. That's where a good design comes in handy, because you can get a better feel for where you should make the trade-off between certainty of working, certainty of working later on and getting some sleep this side of 2008. It's all a matter of weighing the options and investing time in the place most likely to benefit.
(Because everything is a trade-off, anything listed above may not apply. But then, it may not need to. If you've tested a component thoroughly along all boundaries, a good sample of valid conditions and a good sample of erronious conditions, AND everything has been kept as simple as possible so that really wierd cases are unlikely to crop up, then you may decide you can simplify or eliminate fault-tolerent components. There is no point in catching errors that won't occur. In fact, that adds complexity and violates the Keep It Simple rule.)
Oh, and as this is a networked system, testing should include testing network I/O. Use packet generators if necessary, to see how the system handles erronious packets or massive packet floods. You don't want "perfect" responses (unless you can define what "perfect" means), you want reliable responses. If X occur
If this guy is broadcasting to one person in Topeka, one in Taipei and one in Tennessee, does he need multicast? He doesn't.
Think again. Three copies means you chew up three times the bandwidth to get the same file out. If you multicast, you can: (a) transmit to all three the same information at the bandwidth of a single person, (b) transmit to all three three times the information at no extra bandwidth, (c) anywhere in between.
The first option basically means you can run a broadcast station and be doing other things on the Internet (surfing, downloading, whatever). Because broadcasts eat a lot of bandwidth, cutting out two redundant copies frees up a lot of the broadcaster's resources. Alternatively, as bandwidth costs money, the broadcaster can now reduce the speed of service they've bought, save money, AND still transmit to their entire audience.
The second option is also an important one. If you're doing a video feed, three times the bandwidth can mean the difference between b/w or full colour, or between low res or high res. For audio (such as Internet Radio operations), the difference can be between 8 bit mono and CD-quality MP4-AAC with full Dolby-like stereo.
The other important consideration is that multicast scales. If you go from an audience of 3 to an audience of 300, unicast uses 100 times the bandwidth. What could be done on a cheapo DSL line now takes a fractional T3 line, after which the broadcaster jumps off a bridge from crippling debt. With multicast, you could go from 3 to 3 million and not increase your bandwidth consumption by so much as a single byte.
(If you're running a mobile Internet broadcasting station, using nearby wifi access points or a nearby phone line plus a 56K modem, you'd better damn well have multicast if you expect to reach an audience of more than one.)
Should every router on the Internet participate in the creation of PIM trees or allow the inclusion of hundreds of thousands of/32 routes under the 224 prefix? They shouldn't.
Dunno where this comes from. If there's nobody downstream in the group, then the router doesn't carry that group. Plain and simple. Routers only send to routers to which there is at least one connection with a user subscribed to that group. Routers do not need to know every single group, they need only know of those groups they are explicitly forwarding. In consequence, multicasting is actually very light on the router requirements. (With IGMPv3, the tree can be further reduced. If more than half of the connections want the stream, then the router can invert the logic and transmit to all EXCEPT for those who don't want it. Routers can also filter by source, if instructed to do so, so the tree doesn't even have to carry excess traffic any more.)
How do I know this for sure? Well, aside from having run multicast routers myself, I know that the Internet backbone has been running native multicast for the better part of eight to ten years. Has the Internet obvious suffered from this? Not that I'm aware of. Sure, there have been partial meltdowns of the Internet, but those are invariably unicast, not multicast sessions. Of those, had multicasting been used instead of unicast, the Internet would have barely noticed the impact.
It sounds to me as though you've been learning about multicasting from some highly uninformed sources who aren't aware of the distinction between a broadcast protocol (where everyhing is sent to everyone) and multicasting (where only specifically requested streams within specifically selected groups are forwarded only to explicitly interested parties).
If that is the case, feel free to point them in my direction and I'll be more than happy to go through in meticulous detail every aspect of multicasting that they could possibly want to know about. And more. The same is true of anyone else on Slashdot - I am more than happy to provide detailed information on any aspect o
CU-SeeMe was originally from Cornell University and was black-and-white only, though the Mac version may have supported colour. I didn't use the Mac version much. White Pine bought the program, lock, stock and barrel, and switched it from being free to being $50 a copy. They added colour, but it wasn't terribly impressive, and the stability went to shit.
A bunch of CU-SeeMe enthusiasts, meanwhile, produced a full colour version of the free program. I don't believe the colour interoperated with the White Pine version. It was rock solid, it didn't have lots of bells and whistles that nobody used, and it was free. White Pine, if I recall correctly, went ape-shit and tried to stomp it out. That caused some ill-feeling. The reflector was OK but never evolved significantly beyond the freebie version that had been floating around with full sources for some time. I believe groups were added, but that's about it.
Later on, some other fans of CU-SeeMe reverse-engineered the new protocol and produced a library supporting it (I think it was called CU3) but this seems to have died a death as well. I can find no surviving source from this era.
Somewhere down the line, White Pine was bought out, completely, by First Virtual and the program was renamed "Click To Meet". First Virtual was then bought out by RADvision. Despite the disasterous commercial exploitation of CU-SeeMe, there still seems to be a persistant effort to prevent any free/open source rivals that interoperate with it. All evidence I have seen suggests that this prohibition may actually have led to the downfall of White Pine and later vendors, as the userbase for CU-SeeMe was extremely high at the outset and all existing videoconferencing services combined don't even have a fraction of what was there, despite the massive increase in numbers with computers and high-speed Internet access in the past ten years.
The MBONE operated this way for some considerable time. Multicast tunneling is trivial to set up between multicast "islands" of that kind. If you want to set up a single multicast tunnel on a Linux box, create a tunnel as per normal and have traffic for 224.0.0.0/240.0.0.0 directed through the tunnel.
If you want your box to act as a "junction" between multicast islands, you'll want a software multicast router - pimd is good, I'm not sure if Zebra of Xorp support multicasting but they really should at this point. Just configure the kernel to support pim routing and configure the router with the tunneling information.
The one thing you have to be careful of is that Linux does NOT support being a multicast host AND a multicast router at the same time. That is a real pig and whoever coded it that way should be forced to listen to the next State of the Union speech. WITHOUT ANY CAFFEINE. From the front row. AND answer questions on it later.
The equations are symmetric, so you can treat antimatter travelling in one direction as being mathematically the same as normal matter travelling in the opposite direction. (In the case of radioactive decay, in order to preserve momentum, you have to have EITHER an antineutrino being emitted OR a neutrino of exactly the same spin being absorbed.)
This leads to the "obvious" conclusion that you should be able to significantly accelerate nuclear decay by emitting neutrinos of just the right spin. (Now all we have to do is figure out how to generate neutrinos!) It should also be possible to reduce (but not totally suppress radioactive decay) by shieling out all incoming neutrinos, as that would eliminate one possible decay path.
Time is generally regarded as a "special case", in that it is not possible to move backwards in time, or rotate an object such that the time axis is pointing along a space axis and vice versa. Well, almost. I'll argue that it does actually allow the latter, just not in any trivial case.
Spacetime perceives time as a one dimensional vector that is orthogonal to all other vectors. Because relativistic equations for time, distance, mass, etc, use a sqare root function, you get imaginary distances and imaginary time when an object exceeds C. Usually, an imaginary quantity means that you're looking at the wrong axis.
(Trivial case in point: when solving a quadratic equation, if the parabola doesn't intersect the X axis, you will get a complex number. If you break that down into real and imaginary components, the imaginary components correspond to the displacement in the Y axis for that solution's real component value in the X axis.)
Ergo, if a tachyon exists, it would experience a spacial axis as "time" and the time axis as space, UNLESS "time" is not a single axis, in which case all bets are off.
In consequence of not having a telephone-number IQ, I can only speculate wildly, but I'm going to guess that the relativistic equations do indeed refer to some measure of bleeding between space and time and that no further dimensions are required - for GPS or for any other phenomena governed by relativity. (Superstrings being about the only exception I can think of.)
I personally think that part of the problem is that time IS regarded as "special", whereas perhaps it would be better if it were regarded as special "only as far as absolutely necessary". To the extent that specialness is an extra parameter, you want to eliminate all extra parameters as far as possible (and no further).
Slashdot Mirror
If they were underground, you wouldn't have any ice problems. Distance would also be less of a problem. And as the cables wouldn't need to support their own weight, you wouldn't have to worry so much about tensile strength. You'd also not have to cut any trees back. Oh, and you would save on not having to build large numbers of pylons.
It would make the fast-food restaurants cheaper. ("chicken nuggets" are actually electro-fried pigeons.)
Cut the power to the heating circuit by 20% each year.
If they don't acieve fusion in time, put the next generation of fusion researchers up there, give them time to read the notes, turn the heating up to 100%, then start the cutting the following year.
The researchers are bright and capable. They suffer from funding (nobody wants to pay), politics (from within themselves and from their paymasters) and complacency ("it doesn't matter if we don't solve X, Y or Z in our lifetimes").
By eliminating all three problems, progress should improve substantially. Somehow, I seriously doubt anyone is going to try this method any time soon, though.
With fewer power stations, the grid would be simpler and less likely to go into spasms when a tree falls on a power line or when some other accident occurs. Keeping things simple is Good.
Maybe three is an underestimate, but even one per State is vastly superior to the existing setup.
If you had two Linux virtual systems, you could update the one not in use, then fail-over all of the running applications to it. You then update the one that was in use. The kernel is then updated, but the user doesn't have to wait for a reboot, as a virtual system is always running.
Step 2 has two parts. Files that simply overwrite existing files can be installed with no further change. There probably wouldn't be too many examples of those. The other step is to install patch files into a patch archive directory.
Step 3 has one mandatory part and one of two optional parts. The first part is to apply the binary patch(es). You're always going to need that. The second part is to re-insert patches rolled out by the %pre phase that can be rolled back in again at this point. This is only meaningful if there is a %pre phase. Finally, if there isn't a %pre phase, you want to clean up the patch archive directory.
You now have a binary patch RPM.
(Better yet, if the campaign succeeds AND one of the two fusion reactor projects produces cheap energy, we could eliminate all conventional and all fission reactors entirely and have just two or three fusion reactors per continent.)
If the answer is "yes", I'm moving the item up my to-do list. That's exactly the sort of situation that does get to me. Coders have every right to decide what they want to code and what patches they want to accept, but there is a big difference between being selective and becoming stagnant. Selective is necessary. Stagnant is best left to swamps and marshland.
In fact, if early coders had kept pace, the GIMP might never have been written. Between existing painting programs, the Utah Raster Toolkit and xv, early image manipulators had plenty of resources. At least, for the time. Those tools have long-since rusted.
16 bits per channel is much better. I still think the number of channels is limited, though. When you get right down to it, it would not be hard to have an image editor that supported stretchy integers for however many bits you wanted in the channel, and no hard-coded limit on the number of channels. (Although you'd presumably need a plug-in for channel types that were unknown.)
Well, I guess I'll add this to my long list of "things somebody, somewhere, really should do but it looks like nobody else is going to be bothered for a while". I worked on a very similar problem a long time ago and I vaguely remember the solution I used. At the very least, I should be able to put together something that'll work with images of arbitrary complexity.
If you add in support for tetrachromats (hey, why should we encourage discrimination?) and IBM's polarized monitor, we can get to 96bpp without much trouble. I'm sure, with some inventiveness, we can round it up to 128bpp quite easily.
Now, doesn't a 128bpp image editor sound sooo much cooler and geekier than a paltry 16bpp? Besides, with broadband taking off, we've got to soak up the excess bandwidth somehow.
One thing I don't like about any existing drawing/CAD package is that virtually everything out there assumes there's only one kind of user in the world only interested in doing one kind of task. (Or very close to that.)
I guess I've become spoiled with the flexibility of Slashboxes - I like being able to pick and choose the sorts of things that are visible, not being stuck with just one or two views. I guess I also run into the limitations of programs a lot - which either means the programs aren't flexible enough, or I'm just too weird for the coders.
Photoshop is standard. Fair enough. But if the menus and key sequences are soft-coded, you can write a skin to reproduce Photoshop's user interface. The same goes for Corel Draw, FontLab Studio, etc. Ultimately, you're manipulating some combination of bitmaps and vector diagrams, with some sort of mechanism for grouping and attaching components, plus a bunch of absolutely bog-standard scripts for defining lines, curves and outlines.
(You wouldn't WANT all of those capabilities in one program, but if the framework is solid and the scripting is powerful, you could plug in whatever combination you wanted with whatever interface you liked.)
People have been able to write modular code to some degree for at least the last 25 years. Computers and Operating Systems have had the power to sport highly sophisticated engines for almost as long. I fully understand that we need specific programs ported to this, that and the other, I just don't see why there's so little sign of moving past that point.
There's no question that Spiderman would have used impact adhesives - he would want the web he launched to stick specifically to what he wanted and not to anything else. This would be an effective way to achieve exactly that. It would be interesting to know what ways such glues ARE used - both in the Real World and the Comic Book Universe.
I very much agree on the String Theory and believe it will be resolved by suitably compartmentalizing each aspect in turn and mapping it into a form we can visualize. Hey, it's very difficult to imagine N-dimensional regular solids, but it IS easy to imagine a torus. It turns out that, if you use staggeringly complex mathematics and Fermat's Last Theorum, a transform does in fact exist that maps 1:1 between the two types of shape.
(In fact, the nature of the transform is quite unimportant. If there is a hypersolid that is of interest, so long as you can identify the corresponding torus, you can do all of the operations you want on the torus without ever needing to know anything about the extremely complex theories that go into the mapping.)
The same will be true of Superstrings. There WILL be something simple and elegant that we can map these 12-dimensional anti-gravitational objects to. (Superstrings have negative gravity. It's one of those factoids that stuck with me at the Newton Tercentenary Lectures at Cambridge University, along with Black Holes having an internal resistance of 33 ohms.)
Once the transform has been established, all aspects to Superstring theory will be staggeringly obvious and calculations will be reduced to an extremely simple form - simple enough to be covered by 17-18 year olds, very likely. These sorts of things temd to reduce very easily, once they start reducing. Unfortunately, we're not at that point. I don't know of any elegant transform for a superstring and I doubt one will be discovered in the next 10-15 years. After that, all bets are off.
It'll just be a matter of finding the right perspective.
It was a fun project, for a number of reasons. One of the most interesting consequences is the implication that, had Greek civilization endured, they had sufficient theory to have managed Einstein's famous early lectures 2,000 years early. Without any way of actually validating the results - had they believed them - it would have remained theory until the present day anyway, so wouldn't have changed a whole lot. It is interesting to speculate what the Greek scholars would have made of such a proof, though, given my requirement that the proof had to require no knowledge they did not possess.
If anyone does figure out how to do time-travel within one's own light-cone, I guess I could ask.
I started using International Packet Switch Stream in, oh, 1984 and developed a variable-speed networking protocol for a daisy-chained parallel port-based local area network maybe a couple of years earlier. Also got a crappy (but workable) speech synthesizer going on a 32K PET computer a year before that. Figured out that you could do a decent phonetic dictionary in software, even at 1MHz, and that the sound capabilities were just good enough to get usable output.
Rebuilt an R1155 in about 1977. (You ever TRY to get hold of half those valves?)
I wasn't just around. Sorry to hear there were such unfortunates.
(If wormholes exist, they are only stable so long as you CANNOT violate the Second Law of Thermodynamics, strongly implying that any time-travel that is permitted is highly constrained, as wormholes certainly weren't envisaged with the laws of thermodynamics in mind. That property was unexpected, in many ways, but is reassuring in the sense that it does pass an important sanity check.)
I imagine that limited time-travel will be proven - at least in theory - but that all such methods obey those fundamental principles that appear to be universal to all points in space, time and scale. As such, totally free travel through time will likely not be possible (so, no TARDIS') but time-travel completely outside of the light-cone* of that region of space may be much less constrained.
*A light-cone is the region of space/time that is roughly cone-shaped that describes the maximum possible region of space at a given time that anything at the center of the cone could interact with, assuming no information can travel faster than the theoretical speed of light in a perfect vaccuum. Since the cone defines how far information can have travelled, NOTHING outside of the cone can have affected what lies at the center and vice versa. Thus, travelling through a non-simply-connected method from the center of the cone to ANYWHERE outside of it can NOT generate paradoxes for the traveller. As such, if connecting two points of space/time together that are distant enough to meet the requirements and in a way that is stable enough to traverse is possible, there is no obvious prohibition on where in time you could travel.
Oh, it's important to note that the cone extends in both directions in time from where you are now, so covers all of space that could have - at any time in the past - have interacted with you in the past or present.
Flatland, unfurtunately, doesn't help us here. However, with some slight modifications, Flatland CAN be used to teach students much earlier about the concepts of relativity in a way that does NOT require sophisticated equations. (Well, relativity can actually be covered at the same time as Pythagoras' theorum. I think it would be better if it was, and that if both were taught several years before they currently are.)
Imagine that Flatland were not strictly flat, but had hills and valleys. However, the inhabitants still only see along the "plane" of Flatland. Their Universe exists in the third dimension, even though they have no way of directly interacting with it.
Now, imagine that Flatland was rising through the third dimension, but not entirely evenly or at a constant rate. Thus, different parts moved through the third dimension faster than others, but which parts varied over time. Because of this, Flatland "stretches" (unevenly), so if it takes T seconds to slide from A to B at one time, it'll take T+N seconds to make the same journey at a different time.
Hmmm. Let's add a few more properties. Let's imagine that Flatland is rubbery, so that all Flatlanders create little dimples in Flatland. They can't see these dimples, because they can only see along the surface. They can't directly interact with the dimples at all. If they're observent, though, they'll notice other Flatlanders slide faster towards them than away. Flatlanders who eat more create bigger dimples.
Finally, let's sat that Flatlanders are all on speed. Even the really fat ones who weigh Flatland dow
First off, it should be obvious to anybody that space can't just be deformed into nothingness. That has no meaning. Space is actually deformed into time and time is deformed into space.
No, M is not "rest mass". Relativity doesn't have a "rest mass", or a "rest" anything. Indeed, since Newton effectively eliminated absolute space, there hasn't been a notion of "rest mass" in physics (even classical physics) for over 300 years. You're showing your age a little, there.
Of course, the simplest "trick" is to assume that space/time is uniform (but not flat), determine the shape of space/time and derive a suitable set of vectors. The vectors need not be linear, they need only be orthogonal. Once you have those vectors, then space/time will be "flat" relative to those vectors at that instant. You'll need a new set of vectors for every instant, but the problem is quite solvable. Using transforms for turning a "hard" problem into a trivial one is a firmly-established tradition and works extremely well. You should try it some time.
For those who are simply looking in and wondering what the hell is going on, my sympathies. Simply put, relativity doesn't have any absolutes - other than C, which merely happens to equal the speed of light in a perfect vaccuum. The only way to measure anything in relativity is to measure relative to something. There are no fixed points in space or in time, so that leaves measuring relative to the observer. The measurement is not a trivial one, if you want to be precise, as mass deforms space/time, so the observer and the observed (and everything else nearby) complicates the picture.
Actually, it doesn't end there. The deforming of space isn't instantaneous, nor is it's resptoring. Information, including gravity, travels at a finite velocity and state changes take a finite time to complete. Thus, the "gravity well" around any object will not be uniform but look more like a comet tail - compacted at the front, stretched at the back - where the non-uniformness is going to depend on velocity. Now, here's the gotcha. There is no absolute velocity and no absolute space. You can picture everything being relative to all of the particles in the quantum foam, but they all travel at different velocities.
In consequence, at the microscopic level, gravity will not be uniform at all. The well will not be smooth, but will have irregularities in it. The irregularities will be small - usually - and have no measurable significance outside of quantum mechanics. Such details will be of far more interest to quantum cosmologists exploring the behaviour of particles travelling near the event horizon of a Black Hole.
If you want to deal with gravity at this scale, you cannot use the trivial transform I outlined above. You'd still need to use a transform, but now you'd need to transform into a chaotic system, not merely a non-linear one. The good thing, here, is that the curvature of space becomes a consequence of having Strange Attractors and is not something you actually need to model directly. However, chaotic systems are notoriously difficult to model (because they are highly sensitive to the precision of your calculations, the initial values used, etc).
For this reason, don't expect a quantum-scale model of gravity any time soon. I'm not even convinced that the exploration that is going on is in the right direction - superstrings need an awfully large number of zero-sized dimensions. I am firmly conviced that the k
Yeah, I know you meant it as a joke, but it's one of those jokes that is likely to have more than a passing resemblance to something that actually happens...
And if you don't knw that T'=T/sqrt(1-v^2/c^2), with similar equations for M' and L', I can't help you. Confused? Well, having won an award on this subject, I do hope not. It would mean that there are an awful lot of very stupid professional physicists in England.
Yes, some of those do conflict. How to keep things simple AND have fault-tolerence, for example. That's where a good design comes in handy, because you can get a better feel for where you should make the trade-off between certainty of working, certainty of working later on and getting some sleep this side of 2008. It's all a matter of weighing the options and investing time in the place most likely to benefit.
(Because everything is a trade-off, anything listed above may not apply. But then, it may not need to. If you've tested a component thoroughly along all boundaries, a good sample of valid conditions and a good sample of erronious conditions, AND everything has been kept as simple as possible so that really wierd cases are unlikely to crop up, then you may decide you can simplify or eliminate fault-tolerent components. There is no point in catching errors that won't occur. In fact, that adds complexity and violates the Keep It Simple rule.)
Oh, and as this is a networked system, testing should include testing network I/O. Use packet generators if necessary, to see how the system handles erronious packets or massive packet floods. You don't want "perfect" responses (unless you can define what "perfect" means), you want reliable responses. If X occur
Think again. Three copies means you chew up three times the bandwidth to get the same file out. If you multicast, you can: (a) transmit to all three the same information at the bandwidth of a single person, (b) transmit to all three three times the information at no extra bandwidth, (c) anywhere in between.
The first option basically means you can run a broadcast station and be doing other things on the Internet (surfing, downloading, whatever). Because broadcasts eat a lot of bandwidth, cutting out two redundant copies frees up a lot of the broadcaster's resources. Alternatively, as bandwidth costs money, the broadcaster can now reduce the speed of service they've bought, save money, AND still transmit to their entire audience.
The second option is also an important one. If you're doing a video feed, three times the bandwidth can mean the difference between b/w or full colour, or between low res or high res. For audio (such as Internet Radio operations), the difference can be between 8 bit mono and CD-quality MP4-AAC with full Dolby-like stereo.
The other important consideration is that multicast scales. If you go from an audience of 3 to an audience of 300, unicast uses 100 times the bandwidth. What could be done on a cheapo DSL line now takes a fractional T3 line, after which the broadcaster jumps off a bridge from crippling debt. With multicast, you could go from 3 to 3 million and not increase your bandwidth consumption by so much as a single byte.
(If you're running a mobile Internet broadcasting station, using nearby wifi access points or a nearby phone line plus a 56K modem, you'd better damn well have multicast if you expect to reach an audience of more than one.)
Should every router on the Internet participate in the creation of PIM trees or allow the inclusion of hundreds of thousands of /32 routes under the 224 prefix? They shouldn't.
Dunno where this comes from. If there's nobody downstream in the group, then the router doesn't carry that group. Plain and simple. Routers only send to routers to which there is at least one connection with a user subscribed to that group. Routers do not need to know every single group, they need only know of those groups they are explicitly forwarding. In consequence, multicasting is actually very light on the router requirements. (With IGMPv3, the tree can be further reduced. If more than half of the connections want the stream, then the router can invert the logic and transmit to all EXCEPT for those who don't want it. Routers can also filter by source, if instructed to do so, so the tree doesn't even have to carry excess traffic any more.)
How do I know this for sure? Well, aside from having run multicast routers myself, I know that the Internet backbone has been running native multicast for the better part of eight to ten years. Has the Internet obvious suffered from this? Not that I'm aware of. Sure, there have been partial meltdowns of the Internet, but those are invariably unicast, not multicast sessions. Of those, had multicasting been used instead of unicast, the Internet would have barely noticed the impact.
It sounds to me as though you've been learning about multicasting from some highly uninformed sources who aren't aware of the distinction between a broadcast protocol (where everyhing is sent to everyone) and multicasting (where only specifically requested streams within specifically selected groups are forwarded only to explicitly interested parties).
If that is the case, feel free to point them in my direction and I'll be more than happy to go through in meticulous detail every aspect of multicasting that they could possibly want to know about. And more. The same is true of anyone else on Slashdot - I am more than happy to provide detailed information on any aspect o
A bunch of CU-SeeMe enthusiasts, meanwhile, produced a full colour version of the free program. I don't believe the colour interoperated with the White Pine version. It was rock solid, it didn't have lots of bells and whistles that nobody used, and it was free. White Pine, if I recall correctly, went ape-shit and tried to stomp it out. That caused some ill-feeling. The reflector was OK but never evolved significantly beyond the freebie version that had been floating around with full sources for some time. I believe groups were added, but that's about it.
Later on, some other fans of CU-SeeMe reverse-engineered the new protocol and produced a library supporting it (I think it was called CU3) but this seems to have died a death as well. I can find no surviving source from this era.
Somewhere down the line, White Pine was bought out, completely, by First Virtual and the program was renamed "Click To Meet". First Virtual was then bought out by RADvision. Despite the disasterous commercial exploitation of CU-SeeMe, there still seems to be a persistant effort to prevent any free/open source rivals that interoperate with it. All evidence I have seen suggests that this prohibition may actually have led to the downfall of White Pine and later vendors, as the userbase for CU-SeeMe was extremely high at the outset and all existing videoconferencing services combined don't even have a fraction of what was there, despite the massive increase in numbers with computers and high-speed Internet access in the past ten years.
If you want your box to act as a "junction" between multicast islands, you'll want a software multicast router - pimd is good, I'm not sure if Zebra of Xorp support multicasting but they really should at this point. Just configure the kernel to support pim routing and configure the router with the tunneling information.
The one thing you have to be careful of is that Linux does NOT support being a multicast host AND a multicast router at the same time. That is a real pig and whoever coded it that way should be forced to listen to the next State of the Union speech. WITHOUT ANY CAFFEINE. From the front row. AND answer questions on it later.
This leads to the "obvious" conclusion that you should be able to significantly accelerate nuclear decay by emitting neutrinos of just the right spin. (Now all we have to do is figure out how to generate neutrinos!) It should also be possible to reduce (but not totally suppress radioactive decay) by shieling out all incoming neutrinos, as that would eliminate one possible decay path.
Spacetime perceives time as a one dimensional vector that is orthogonal to all other vectors. Because relativistic equations for time, distance, mass, etc, use a sqare root function, you get imaginary distances and imaginary time when an object exceeds C. Usually, an imaginary quantity means that you're looking at the wrong axis.
(Trivial case in point: when solving a quadratic equation, if the parabola doesn't intersect the X axis, you will get a complex number. If you break that down into real and imaginary components, the imaginary components correspond to the displacement in the Y axis for that solution's real component value in the X axis.)
Ergo, if a tachyon exists, it would experience a spacial axis as "time" and the time axis as space, UNLESS "time" is not a single axis, in which case all bets are off.
In consequence of not having a telephone-number IQ, I can only speculate wildly, but I'm going to guess that the relativistic equations do indeed refer to some measure of bleeding between space and time and that no further dimensions are required - for GPS or for any other phenomena governed by relativity. (Superstrings being about the only exception I can think of.)
I personally think that part of the problem is that time IS regarded as "special", whereas perhaps it would be better if it were regarded as special "only as far as absolutely necessary". To the extent that specialness is an extra parameter, you want to eliminate all extra parameters as far as possible (and no further).