How is Flynn's stuff "real"? I looked at his pages and it was immediately obvious that he has made the same mistake that so many permanent magnet fetishists have made: he has confused force and energy.
Any motor that's not 100% efficient will dissipate the remainder of its input power in losses such as friction, windage, Joule heating, and the like. If you are going to improve the efficiency of a motor, you must reduce one or more of these losses; there is no other way. How, exactly, does Flynn reduce these losses? His diagrams shed absolutely no light on that. In fact, he doesn't talk about energy or dissipative mechanisms at all, only about force -- which isn't the same thing.
The vast majority of cellular revenue may come from people who roam between work and home, but most of them talk on the way. How well does 802.11 currently work from a moving car? (I admit this would have the advantage of getting drivers off the phone.)
Even for Internet access I find myself frequently using my Verizon 1xEVDO card because I can't get or maintain 802.11 coverage, or don't want to have to pay all the various 802.11 service providers.
I didn't realize until this thread just how young most Slashdotters must be. I was already 8 years into my engineering career when Challenger failed. I'd already seen a lot of shuttle launches (including one in person at KSC, STS-9 in 1983), but I still couldn't get enough of them. I knew that the "regular" networks weren't carrying it, so I couldn't count on seeing it at work. So I stayed home that morning and watched it live on CNN.
I guess that does put me in a minority, and as those of you who also watched it live can agree, it was a very different experience than seeing it only after being told that something horrible had happened. I don't remember much after that except making a bunch of phone calls and staring at the TV.
I have no idea how many dozen more times I saw it at work that afternoon. It was a bad day.
Your professor almost certainly was talking about a series of US "high altitude" (i.e., space) nuclear weapons tests performed in 1958 and in 1962. This was at the very beginning of the "space age", so while the radiation effects on the few satellites in orbit were very significant (or fatal in some cases) there weren't many of them up there to be destroyed.
You can find good writeups in any good history of US nuclear testing. The Wikipedia article on "Nuclear testing" is as good a place to start as any. Look for "Rocket-propelled warheads".
This sort of thing was banned by the Limited Test Ban Treaty, signed by the US and USSR in 1963.
Disposal orbits don't have to be totally different or hard to reach from operational orbits. They just have to be far enough away to not jeopardize the satellites that are still operating. No plane change is required.
Whether it takes less delta-vee to deorbit or go into a disposal orbit depends on the orbit. Deorbiting a geostationary satellite is much harder than kicking it into a slightly higher disposal orbit, so that's what usually happens. Only one precise altitude is geostationary, so anything higher is not especially useful for communications.
Low orbits are different. Deorbiting is often practical. If not, then a slightly higher disposal orbit is again used. The most popular LEO orbits are just inside the lower edge of the inner Van Allen belt, so radiation levels increase sharply with altitude and it doesn't take much delta-V to reach an orbit that's too hot for an operational satellite.
Launcher upper stages are an important special case. Most either carry enough fuel to deorbit immediately or are placed into short-lived orbits. Often those orbits are highly eccentric (e.g., upper stages on geostationary launches) and they tend to be unstable and short-lived due to lunar and solar perturbations.
It's true that RAID doesn't eliminate the need for backups, but can form the basis of a simple and convenient backup scheme.
Set up a two-disk RAID-1 array. Every month or so, shut the system down, remove the second disk in the array and put it in a safe place. Install a new blank drive in its place. Bring the system up, add the new drive to the array and let it rebuild the mirror.
This is a nice way to give you a consistent full disk image backup without any more downtime than it takes to swap a drive; the actual copying takes place as the system runs.
I have also had problems with my 15" Powerbook. I never could find third-party memory that would work reliably. Sometimes RAM with the correct advertised parameters wouldn't work at all! Only recently did I learn about "bus slewing" and that this model requires RAM that supports it. Apple certainly didn't make it obvious in their specs, probably so they could continue to sell their ridiculously overpriced expansion options.
When it was about 6 months old, it slid off my bed about 2 feet onto a hardwood floor, bending the front right corner of the bottom case and distorting the very narrow feed slot for the optical drive. Those (thin) metal cases aren't nearly as strong as they look! Apple wanted $700 to fix it, which seemed way too much. (I didn't have Applecare, and it doesn't cover abuse anyway.) So I opened the unit myself and bent the case back into shape. The nylon guides inside the optical drive had been pushed out of position, so I moved them back and the drive began working again.
The machine has always locked up annoyingly often, even when it was new, and that only got worse with time. Eventually one of the RAM slots failed completely, so I just gave up on the whole thing. After agonizing for a long time over whether I wanted to reward Apple for having built a flaky product by giving them even more business, I bought a new 17" Powerbook plus 1GB of aftermarket memory. So far it has been solid. It stays up for weeks at a time. So perhaps my 15" PB was just a lemon, not indicative of Powerbooks in general.
Although the hard drives on my Powerbooks have been okay, my wife has not been so lucky. The 40GB unit in my wife's 12" PB failed recently after 2 years of use. Since it didn't have Applecare, I replaced it myself. It's tedious even when you follow the instructions; it made me appreciate the easy removability of hard drives in IBM Thinkpads, among others.
Hard drive reliability in Apple desktops hasn't been stellar either. I've had to replace the drive in my wife's iMac G5 and in my own Powermac G5, though recent drives seem to be more reliable than those made a few years ago.
Before reading too much into Allan's comments linked here, take the time to read the other stuff on his site. He regularly buys into pseudoscientific crap like permanent magnet motors, "zero point energy", Blacklight Power, and just about every other free energy scam in existence.
To his credit, he regularly exposes individual scams, often turning overnight from a booster to a scammer's worst nightmare. Many of the "true believers" never figure out that they've been taken, even after they've lost their life savings. But Allan never seems to learn the bigger lessons about science and nature, so his cycle continues to repeat.
Those interested in new energy technologies would do well to pay close attention in physics, chemistry and thermodynamics classes and remember that whenever something seems too good to be true, it usually is.
There's a certain romantic appeal in disconnecting from the power grid, I'll admit. I thought about it when I installed my photovoltaic array.
But it's not rational. Going off the grid means having a battery plant large enough to run everything through long cloudy stretches in winter. Most people end up with a gasoline or diesel backup generator and all the extra hassle that entails. If your battery isn't large enough to absorb your excess summer production, you have to either figure out what to do with that excess energy, or just let it go to waste.
Batteries aren't cheap, and they wear out. They also need regular maintenance. The depreciation costs of the cheapest commodity-grade lead-acid batteries work out to about 15 cents per kilowatt-hour, not counting the energy losses in charging and discharging. That significantly increases the operational cost of a photovoltaic system.
The better alternative is grid-tied photovoltaic. When you need more power than you can generate, you buy it from the utility. When you generate more power than you need, you run the meter backward. It's like having a free, infinite capacity battery. In California, you can let things ride for an entire year at a time. That lets you build up a surplus in the summer and spend it in the winter, or alternatively run up a deficit in the winter and pay it back in the summer. Once per year you "true up" by paying for the net amount you use, hence the term "net metering". California has an especially good net metering law, but many other states have similar laws.
There are situations where going off the grid makes sense. If you have property in a remote location, it may be prohibitively expensive to have a utility line installed. If you can take care of your other needs, e.g., by digging a well and a septic tank, then installing a battery plant as part of an independent PV/wind system may make perfect sense. But it makes no sense at all to disconnect from an existing utility connection.
The US power grid is a remarkably effective system. It is the cheapest, safest and most efficient means known for transmitting large amounts of energy over long distances. It's an excellent way to redistribute renewable energy such as solar and wind given their inherent unpredictability. And unlike the "hydrogen economy" that's been so heavily hyped of late, the electric grid is already here, and it works. So what's so terrible about it?
That estimate is just ridiculous. IPv6 has been in Linux, BSD, Mac OS X and Windows XP for at least several years. BIND has had support for AAAA records for some time. It's in Cisco router images. We just have to turn it on and use it!
And we don't have to wait for our ISPs, either. I've been using 6to4 (IPv6 tunneled over IPv4) for years. It's especially useful on home networks where multiple servers have to share a single IPv4 address on a cable or DSL modem.
6to4 works very well. A 6to4 tunnel coexists nicely with an IPv4 NAT on my home router. The computers on my home network can run conventional clients through the NAT just as they always have, while servers running on those computers can be contacted directly from the outside using IPv6.
While not every Internet application yet speaks IPv6, the important ones already do. SSH is the most important, but popular SMTP, IMAP and HTTP implementations do as well.
I cannot believe the handsprings users are expected to perform on retail commodity routers with kludges like "port forwarding" when 6to4 tunneling is both simpler and far more general and powerful.
It certainly can make traffic analysis harder, but it's also pretty obvious that it's extremely inefficient. This seems to be a property of every halfway effective method to defeat traffic analysis from the endpoints, so much so that they're really not very practical for routine or high volume use.
And I still don't know that even something as elaborate as a mixmaster is really secure against a well designed statistical attack.
Compared to the traffic analysis threat, confidentiality is practically a solved problem. End-to-end encryption costs almost nothing. But it's increasingly clear that confidentiality is almost irrelevant in the big scheme of things since so much can be learned about you and your life simply from who you talk to and when, and people are so easily found guilty by mere association. And thanks to a Supreme Court that has never understood the power of traffic analysis, there were no effective safeguards against government abuse even before the so-called Patriot Act.
You don't understand the problem. Extremely incriminating evidence can be obtained through traffic analysis, knowing who you talk to and when, without acquiring the actual content of your communications. That's what a "pen register" is -- traffic analysis of a telephone. Encrypting your calls or your emails won't help much if, for example, they can see you're talking to known terrorists.
The growth in routing table size was a major topic of discussion during the development of IPv6, but it's not really something specific to either protocol. It has to do more with how address blocks of either protocol are allocated. A major debate broke out on whether address blocks should be "portable", that is, assigned to a user more or less permanently and capable of being moved from one ISP to another, or allocated only through the big ISPs, which would sub-allocate pieces of larger blocks to their customers. In the latter case, customers would have to re-address when switching ISPs.
The argument for the latter approach is that it would minimize growth in the core routing tables; the argument against is that it would give too much power to the big ISPs by making it more difficult for users to take their business elsewhere. At the same time, the design of IPv6 makes it inherently easier to re-address large subnetworks should that be necessary when changing ISPs.
I don't understand your point. Do you favor IPv6 or not?
Getting rid of router fragmentation in IPv6 was a good move. Fragmentation seemed like a good idea when it was first put into IPv4, but experience has shown it to be more trouble than it's worth. It's been recommended practice for a long time to avoid router IPv4 fragmentation (e.g., by using path MTU discovery). But hosts and routers still have to implement it to remain compatible, and that opens up opportunities for various nasty denial-of-service attacks that involve running victim hosts out of memory.
Eliminating router fragmentation from IPv6 not only removed these potential DoS vulnerabilities, but it also simplified the protocol quite a bit and made it easier to implement at high speed.
Well, why not IPv6? What's so wrong with it? A lot of effort went into it over the past decade, all of the major host and router vendors implement it, and it really does work. So why not just turn it on and use it?
I once asked some of the same questions, such as why 128 bits. Now that I've used it myself for a while, I think there's a lot to be said for being able to imbed your MAC address in your IPv6 address. MAC addresses are globally unique, so your IPv6 address is also guaranteed to be unique. While
DHCP servers do work pretty well most of the time, they can and do fail, lose state and require an administrator to fix; that's just one less thing to worry about in IPv6 autoconfiguration.
IPv6 also benefits from the deletion of several other features from IPv4 that turned out to be more trouble than they were worth. The elimination of IP header checksums makes it easier to build really fast routers, as does the elimination of router fragmentation. At the same time, the addition of flow labels makes it easier to implement effective QoS mechanisms.
I can't believe you think that NAT port-forwarding hacks are at all acceptable. With IPv6, the need for NATs and all the painful klugery that's grown up around them just disappears. Gone. That alone would be enough reason for me to use IPv6. The other stuff above is just icing on the cake.
Quite right -- IPv6 is no longer some amorphous hypothetical future thing. It already exists, and it works. Linux, Mac OS X and Windows XP have all had IPv6 stacks for years. You only have to turn it on and use it!
You say your ISP doesn't support IPv6? Irrelevant! Thanks to "6to4 tunneling", there's already a simple, standard way to tunnel IPv6 over IPv4 without the cooperation or even the knowledge of your ISP. If you have even a single routable IPv4 address, a/48 IPv6 network block is already yours to use; you don't have to apply to anyone to begin using it. Just enable 6to4 tunneling on your router and, voila! -- You have both IPv6 and IPv4 on your network.
This gives you the best of both worlds. An application can still use IPv4 as before, complete with NATs and all the warts they make necessary. Or it can switch to IPv6 and regain the transparent end-to-end addressing that originally made the Internet so flexible.
I expect this combination of IPv4-with-NAT and IPv6 via 6to4 tunneling will become very popular on home networks. Traditional applications like email clients and web browsers work fairly well over IPv4 despite NATs, so there's no reason to discard them overnight. But newer applications, especially peer-to-peer servers, now have a much cleaner way to jettison the architectural baggage of NATs. And the two network protocols can coexist indefinitely.
The only real obstacle to the widespread use of IPv6, other than end-user inertia and lack of awareness, is the lack of 6to4 tunneling support by the three big retail router vendors (Linksys, Netgear and DLink). So we need to lean on them to introduce it; as soon as one does, you can bet that the other two will quickly follow. Until then, you can still set up a 6to4 router with Linux, BSD, Mac OS X or possibly Windows XP. And when you do, you'll quickly discover just how nice it is to no longer have to deal with those horrible port-forwarding kludges that have grown like cancers on IPv4 NAT boxes.
The really sad thing about articles like this is that they're written by and for people who don't know that we already had a commercially available, hydrogen powered car that really worked. It produced its own hydrogen on-board from an external electrical power supply and stored it in a compact solid form. As the car was driven, the oxidized hydrogen (i.e., water) was kept on board so it could later be recycled back into hydrogen with more external electrical energy.
Not only did this avoid the need for a massive hydrogen production and delivery infrastructure in favor of an electrical supply grid that already exists, but the overall end-to-end energy efficiency of the process was vastly greater than the proposed "hydrogen economy" can ever be.
The car in question was the GM Gen 2 EV1 with nickel metal/hydride batteries. I drove one every day from 2000-2003, when GM pulled them all off the road and sent them to the crusher even though everyone who had one would have gladly continued to pay real money to drive them.
The hydrogen-powered car is pure hype. In every respect (cost, range, energy efficiency) it is inferior to the battery EVs that could be had now. So why have the automakers pushed the hydrogen fuel cell so much? Simple. California had a mandate on the books that 2% of cars in the 2002 model year would be zero emission (that mandate had already been delayed from 1997). Automakers like GM, as well as the oil companies, loathed that mandate, but they couldn't say so right out loud. So to a gullible public they dangled the promise of "something even better" -- hydrogen -- at some indeterminate time in the future in exchange for killing the mandate that was here and now. And sadly, they succeeded.
Just one of the many benefits brought to you by a horrific degree of scientific illiteracy among both average Americans and their leaders.
Who says it has to be TCP traffic? To pass the filter, it only has to look like TCP traffic.
TCP is an end-to-end protocol. It's only a convention (though one very widely followed) that putting a "6" in the "protocol" field of an IPv4 header means that what follows is a standard TCP header defined in RFC793 et al. But nothing requires that this be so if the end points agree on other meanings.
It's time for a general-purpose tunneling protocol specifically designed to thwart any and all port and protocol blocking in the network when it is not desired by consenting endpoints. Nothing past the IP header was ever meant for the eyes of an intermediate router, and filtering on the basis of those post-IP headers was never considered in the design of the Internet protocols.
And so the end-to-end principle will survive, and the world's telcos will be brought, kicking and screaming, into the 21st century. Or they will be left behind.
What other reason do we need to oppose BPL beyond the fact that it interferes with our signals? "Other than that, Mrs. Lincoln, how did you like the play?"
"Notching out" the ham bands is much more easily said than done. It's easy enough to not generate signals in the ham bands -- it's OFDM, so you just turn off the carriers in question -- but then power at the notched frequencies is regenerated as soon as the composite signal passes through the broadband amplifiers needed to drive the power lines.
All amplifiers have some amount of intermodulation distortion, and that's how the notched frequencies get regenerated. In fact, generating broadband noise, notching out a narrow frequency range, running it through an amplifier and measuring the power in the notched spectrum is the standard way to measure intermodulation distortion in an RF amplifier. This is the NPR (Noise Power Ratio) test.
If it were easy to build broadband amplifiers without intermodulation distortion, the cable companies never would have had to roll out all that fiber a few years ago. Since the signal gets converted back to coax before it reaches your house, it's obvious that fiber's greater bandwidth wasn't the reason. The real reason was that it proved impossible to keep the intermodulation distortion of a whole bunch of cascaded amplifiers between the head end and your house down to reasonable levels except by using much less than the coax's total theoretical bandwidth. By bringing the signal to your neighborhood with fiber, converting it to coax and running it through only one or two amplifiers at most, the intermodulation distortion is kept low enough that all of the coax's bandwidth can be filled up.
You may remember what cable TV looked like before hybrid fiber coax -- a fine haze of noise and herringbone patterns in the background on every channel. That's intermodulation distortion.
Even without its RF interference problems, BPL is a terrible excuse for a broadband technology. A power company's most valuable assets are not its wires; its most valuable assets are its rights of way. If the power companies realized this and weren't so goddamned cheap, they'd be out there pulling fiber right now. Rather than play catch-up with the phone and cable companies, the power companies could kick their asses.
Simply saying "wake up in X seconds" is fine, it doesn't matter what time it is when you wake up.
Precisely my point. And if you do need a simple, standard, unambiguous way to describe that future wakeup time, use one of the standard timescales that doesn't follow leap seconds. Don't change UTC.
If the spin of the earth is arbitrary, then what isn't?
Being chaotic is not the same thing as being arbitrary.
Very little isn't chaotic or arbitrary in this physical world. And the essence of both "chaotic" and "arbitrary" is "unpredictable". Compared to the regularity of the atomic clock, pretty much everything is chaotic, arbitrary and unpredictable.
There are different definitions of seconds. GMT and UT1 use a second which eliminates the necessity of leap seconds. These seconds aren't easily measured by atomic clocks, which is why UTC was invented.
There is only one important version of the second left: the fundamental SI unit by that name. As such it's deeply embedded in the definition of many important derived units including those for distance, volume, velocity, force, energy, power, frequency, acceleration, etc. Some of these units are even used by politicians who write them into laws and regulations.
Sure, there's still something called the sidereal day, which implies there's still something called the sidereal second, but it doesn't find very many uses outside astronomy.
The point is, you don't define unix time one way and then fundamentally change things later. But besides that, using UTC for unix time isn't a good idea, because it doesn't easily convert to and from an integer.
I agree more than you think. I read Dan Bernstein's page that you mentioned and thought it was right on the mark. I have no problem, and I don't think you really do either, with defining the UNIX epoch to be a particular instant on the UTC time scale and representing other times as an integer count of seconds before or after that epoch. That's not the same thing as trying to represent UTC times as an integer, which I agree is broken. That's also different from what we both agree is the broken practice of effectively moving the UNIX epoch every time there's a leap second so that conversion functions that know nothing about leap seconds will match UTC for timestamps produced after the leap second event.
I think we've hammered this one out as much as we can, and we're pretty much in agreement on the main points.
You'd need an atomic clock in the computer, not just "a simple down counter"
Not at all. Good crystal oscillators can easily keep time to well under a second over several months. Besides, atomic clocks are getting smaller and cheaper all the time; reference that NIST announcement some months ago.
But I still don't understand *why* you'd want to do such a thing. I guess if you're trying to make the perfect bomb which didn't rely on any radio signals
There are many uses for precise timers beyond time bombs. Constructive ones, in fact. Again, most of the examples I can think of come from spacecraft. Remember the Galileo probe? It separated from the mother ship five months before arrival at Jupiter, and during that time only a timer was running. At the appropriate moment, just before entering the atmosphere, it woke up.
time is relative
Would you please forget about relativity here? The effects are negligible for most real-world engineering applications, and even when it's not you can deal with it by simply agreeing on a standard reference frame for your measurements. TAI, UTC, etc are already referred to the geoid for just this reason.
Oh boy, so you have to be careful. So what? Be careful.
Well, sure. If you never made mistakes, if complexity weren't an issue, we could measure time in units of pounds-time, shillings-time and pence-time, with arbitrary, time-varying conversions between these units. But what's the point? There's much to be said for standard units and measurement scales that are as simple and elegant as possible to minimize the chances for error.
Leap seconds aren't arbitrary. They're based on the spin of the Earth.
And the spin of the earth is arbitrary. Otherwise we could predict and schedule leap seconds many years into the future. Better yet, we could have defined the second so that leap seconds weren't necessary, or at least that their long-term sum would be zero instead of positive. (The second was last redefined in 1967, and it's far too late to do it again.)
GMT would be a better system for human purposes
I disagree. The second is such a fundamental unit, and so much of the rest of physics depends on it, that it must be nailed down precisely. It also helps that time is the basic dimension we can measure most accurately, thanks to atomic clocks. That's why the meter is now defined in terms of the speed of light.
If you need a very precise model of the earth's rotation, then you have no choice but to build a complex, precise model -- it's complex, and there are irregular perturbations due to things like atmospheric mass movements. UTC and its system of leap seconds does a pretty good job in keeping the earth's rotation close enough to civil time for most purposes. It was just a mistake, though, to make it the internal basis for timestamps and such when a timescale that doesn't use leap seconds could have been used.
Without specifying a frame of reference, that definition is rather meaningless:).
Okay, once again the frame of reference is the geoid, approximately equivalent to average sea level. That's how the second and the UTC timescales are already defined.
According to him it's a broken localtime(), combined with a broken xntpd which catered to the broken localtime().
Right.
But I also noticed that the original definition was in GMT. So really the error was in changing GMT to UTC instead of UT1, and in thinking that we meant TAI seconds instead of GMT seconds.
I have no problem with basing the official definition of UNIX time on UTC, and I suspect Thompson and Ritchie would agree. They specified GMT for the UNIX epoch only because UTC didn't exist yet; it came into being (replacing GMT) on January 1, 1972.
Slashdot Mirror
Actually, the floppies on the VAX 11/780 were 8", and they held about 243 kilobytes. Still pretty tiny by today's standards.
Any motor that's not 100% efficient will dissipate the remainder of its input power in losses such as friction, windage, Joule heating, and the like. If you are going to improve the efficiency of a motor, you must reduce one or more of these losses; there is no other way. How, exactly, does Flynn reduce these losses? His diagrams shed absolutely no light on that. In fact, he doesn't talk about energy or dissipative mechanisms at all, only about force -- which isn't the same thing.
Please read the cited web page, in particular the "over the 100% barrier" remark.
Even for Internet access I find myself frequently using my Verizon 1xEVDO card because I can't get or maintain 802.11 coverage, or don't want to have to pay all the various 802.11 service providers.
Disclaimer: I work for Qualcomm.
I guess that does put me in a minority, and as those of you who also watched it live can agree, it was a very different experience than seeing it only after being told that something horrible had happened. I don't remember much after that except making a bunch of phone calls and staring at the TV.
I have no idea how many dozen more times I saw it at work that afternoon. It was a bad day.
Your professor almost certainly was talking about a series of US "high altitude" (i.e., space) nuclear weapons tests performed in 1958 and in 1962. This was at the very beginning of the "space age", so while the radiation effects on the few satellites in orbit were very significant (or fatal in some cases) there weren't many of them up there to be destroyed.
You can find good writeups in any good history of US nuclear testing. The Wikipedia article on "Nuclear testing" is as good a place to start as any. Look for "Rocket-propelled warheads".
This sort of thing was banned by the Limited Test Ban Treaty, signed by the US and USSR in 1963.
Disposal orbits don't have to be totally different or hard to reach from operational orbits. They just have to be far enough away to not jeopardize the satellites that are still operating. No plane change is required.
Whether it takes less delta-vee to deorbit or go into a disposal orbit depends on the
orbit. Deorbiting a geostationary satellite is much harder than kicking it into a slightly higher disposal orbit, so that's what usually happens. Only one precise altitude is geostationary, so anything higher is not especially useful for communications.
Low orbits are different. Deorbiting is often practical. If not, then a slightly higher disposal orbit is again used. The most popular LEO orbits are just inside the lower edge of the inner Van Allen belt, so radiation levels increase sharply with altitude and it doesn't take much delta-V to reach an orbit that's too hot for an operational satellite.
Launcher upper stages are an important special case. Most either carry enough fuel to deorbit immediately or are placed into short-lived orbits. Often those orbits are highly eccentric (e.g., upper stages on geostationary launches) and they tend to be unstable and short-lived due to lunar and solar perturbations.
Set up a two-disk RAID-1 array. Every month or so, shut the system down, remove the second disk in the array and put it in a safe place. Install a new blank drive in its place. Bring the system up, add the new drive to the array and let it rebuild the mirror.
This is a nice way to give you a consistent full disk image backup without any more downtime than it takes to swap a drive; the actual copying takes place as the system runs.
When it was about 6 months old, it slid off my bed about 2 feet onto a hardwood floor, bending the front right corner of the bottom case and distorting the very narrow feed slot for the optical drive. Those (thin) metal cases aren't nearly as strong as they look! Apple wanted $700 to fix it, which seemed way too much. (I didn't have Applecare, and it doesn't cover abuse anyway.) So I opened the unit myself and bent the case back into shape. The nylon guides inside the optical drive had been pushed out of position, so I moved them back and the drive began working again.
The machine has always locked up annoyingly often, even when it was new, and that only got worse with time. Eventually one of the RAM slots failed completely, so I just gave up on the whole thing. After agonizing for a long time over whether I wanted to reward Apple for having built a flaky product by giving them even more business, I bought a new 17" Powerbook plus 1GB of aftermarket memory. So far it has been solid. It stays up for weeks at a time. So perhaps my 15" PB was just a lemon, not indicative of Powerbooks in general.
Although the hard drives on my Powerbooks have been okay, my wife has not been so lucky. The 40GB unit in my wife's 12" PB failed recently after 2 years of use. Since it didn't have Applecare, I replaced it myself. It's tedious even when you follow the instructions; it made me appreciate the easy removability of hard drives in IBM Thinkpads, among others.
Hard drive reliability in Apple desktops hasn't been stellar either. I've had to replace the drive in my wife's iMac G5 and in my own Powermac G5, though recent drives seem to be more reliable than those made a few years ago.
Eh? What's a "hybrid" in this context? That link appears to be a religious site unrelated to this discussion.
To his credit, he regularly exposes individual scams, often turning overnight from a booster to a scammer's worst nightmare. Many of the "true believers" never figure out that they've been taken, even after they've lost their life savings. But Allan never seems to learn the bigger lessons about science and nature, so his cycle continues to repeat.
Those interested in new energy technologies would do well to pay close attention in physics, chemistry and thermodynamics classes and remember that whenever something seems too good to be true, it usually is.
But it's not rational. Going off the grid means having a battery plant large enough to run everything through long cloudy stretches in winter. Most people end up with a gasoline or diesel backup generator and all the extra hassle that entails. If your battery isn't large enough to absorb your excess summer production, you have to either figure out what to do with that excess energy, or just let it go to waste.
Batteries aren't cheap, and they wear out. They also need regular maintenance. The depreciation costs of the cheapest commodity-grade lead-acid batteries work out to about 15 cents per kilowatt-hour, not counting the energy losses in charging and discharging. That significantly increases the operational cost of a photovoltaic system.
The better alternative is grid-tied photovoltaic. When you need more power than you can generate, you buy it from the utility. When you generate more power than you need, you run the meter backward. It's like having a free, infinite capacity battery. In California, you can let things ride for an entire year at a time. That lets you build up a surplus in the summer and spend it in the winter, or alternatively run up a deficit in the winter and pay it back in the summer. Once per year you "true up" by paying for the net amount you use, hence the term "net metering". California has an especially good net metering law, but many other states have similar laws.
There are situations where going off the grid makes sense. If you have property in a remote location, it may be prohibitively expensive to have a utility line installed. If you can take care of your other needs, e.g., by digging a well and a septic tank, then installing a battery plant as part of an independent PV/wind system may make perfect sense. But it makes no sense at all to disconnect from an existing utility connection.
The US power grid is a remarkably effective system. It is the cheapest, safest and most efficient means known for transmitting large amounts of energy over long distances. It's an excellent way to redistribute renewable energy such as solar and wind given their inherent unpredictability. And unlike the "hydrogen economy" that's been so heavily hyped of late, the electric grid is already here, and it works. So what's so terrible about it?
And we don't have to wait for our ISPs, either. I've been using 6to4 (IPv6 tunneled over IPv4) for years. It's especially useful on home networks where multiple servers have to share a single IPv4 address on a cable or DSL modem.
6to4 works very well. A 6to4 tunnel coexists nicely with an IPv4 NAT on my home router. The computers on my home network can run conventional clients through the NAT just as they always have, while servers running on those computers can be contacted directly from the outside using IPv6.
While not every Internet application yet speaks IPv6, the important ones already do. SSH is the most important, but popular SMTP, IMAP and HTTP implementations do as well.
I cannot believe the handsprings users are expected to perform on retail commodity routers with kludges like "port forwarding" when 6to4 tunneling is both simpler and far more general and powerful.
Even better, the guy you're trying to talk to won't know it, so he won't be able to blab to anyone else!
And I still don't know that even something as elaborate as a mixmaster is really secure against a well designed statistical attack.
Compared to the traffic analysis threat, confidentiality is practically a solved problem. End-to-end encryption costs almost nothing. But it's increasingly clear that confidentiality is almost irrelevant in the big scheme of things since so much can be learned about you and your life simply from who you talk to and when, and people are so easily found guilty by mere association. And thanks to a Supreme Court that has never understood the power of traffic analysis, there were no effective safeguards against government abuse even before the so-called Patriot Act.
You don't understand the problem. Extremely incriminating evidence can be obtained through traffic analysis, knowing who you talk to and when, without acquiring the actual content of your communications. That's what a "pen register" is -- traffic analysis of a telephone. Encrypting your calls or your emails won't help much if, for example, they can see you're talking to known terrorists.
The argument for the latter approach is that it would minimize growth in the core routing tables; the argument against is that it would give too much power to the big ISPs by making it more difficult for users to take their business elsewhere. At the same time, the design of IPv6 makes it inherently easier to re-address large subnetworks should that be necessary when changing ISPs.
I'm not sure about the outcome of the debate.
Getting rid of router fragmentation in IPv6 was a good move. Fragmentation seemed like a good idea when it was first put into IPv4, but experience has shown it to be more trouble than it's worth. It's been recommended practice for a long time to avoid router IPv4 fragmentation (e.g., by using path MTU discovery). But hosts and routers still have to implement it to remain compatible, and that opens up opportunities for various nasty denial-of-service attacks that involve running victim hosts out of memory.
Eliminating router fragmentation from IPv6 not only removed these potential DoS vulnerabilities, but it also simplified the protocol quite a bit and made it easier to implement at high speed.
I once asked some of the same questions, such as why 128 bits. Now that I've used it myself for a while, I think there's a lot to be said for being able to imbed your MAC address in your IPv6 address. MAC addresses are globally unique, so your IPv6 address is also guaranteed to be unique. While DHCP servers do work pretty well most of the time, they can and do fail, lose state and require an administrator to fix; that's just one less thing to worry about in IPv6 autoconfiguration.
IPv6 also benefits from the deletion of several other features from IPv4 that turned out to be more trouble than they were worth. The elimination of IP header checksums makes it easier to build really fast routers, as does the elimination of router fragmentation. At the same time, the addition of flow labels makes it easier to implement effective QoS mechanisms.
I can't believe you think that NAT port-forwarding hacks are at all acceptable. With IPv6, the need for NATs and all the painful klugery that's grown up around them just disappears. Gone. That alone would be enough reason for me to use IPv6. The other stuff above is just icing on the cake.
You say your ISP doesn't support IPv6? Irrelevant! Thanks to "6to4 tunneling", there's already a simple, standard way to tunnel IPv6 over IPv4 without the cooperation or even the knowledge of your ISP. If you have even a single routable IPv4 address, a /48 IPv6 network block is already yours to use; you don't have to apply to anyone to begin using it. Just enable 6to4 tunneling on your router and, voila! -- You have both IPv6 and IPv4 on your network.
This gives you the best of both worlds. An application can still use IPv4 as before, complete with NATs and all the warts they make necessary. Or it can switch to IPv6 and regain the transparent end-to-end addressing that originally made the Internet so flexible.
I expect this combination of IPv4-with-NAT and IPv6 via 6to4 tunneling will become very popular on home networks. Traditional applications like email clients and web browsers work fairly well over IPv4 despite NATs, so there's no reason to discard them overnight. But newer applications, especially peer-to-peer servers, now have a much cleaner way to jettison the architectural baggage of NATs. And the two network protocols can coexist indefinitely.
The only real obstacle to the widespread use of IPv6, other than end-user inertia and lack of awareness, is the lack of 6to4 tunneling support by the three big retail router vendors (Linksys, Netgear and DLink). So we need to lean on them to introduce it; as soon as one does, you can bet that the other two will quickly follow. Until then, you can still set up a 6to4 router with Linux, BSD, Mac OS X or possibly Windows XP. And when you do, you'll quickly discover just how nice it is to no longer have to deal with those horrible port-forwarding kludges that have grown like cancers on IPv4 NAT boxes.
Not only did this avoid the need for a massive hydrogen production and delivery infrastructure in favor of an electrical supply grid that already exists, but the overall end-to-end energy efficiency of the process was vastly greater than the proposed "hydrogen economy" can ever be.
The car in question was the GM Gen 2 EV1 with nickel metal/hydride batteries. I drove one every day from 2000-2003, when GM pulled them all off the road and sent them to the crusher even though everyone who had one would have gladly continued to pay real money to drive them.
The hydrogen-powered car is pure hype. In every respect (cost, range, energy efficiency) it is inferior to the battery EVs that could be had now. So why have the automakers pushed the hydrogen fuel cell so much? Simple. California had a mandate on the books that 2% of cars in the 2002 model year would be zero emission (that mandate had already been delayed from 1997). Automakers like GM, as well as the oil companies, loathed that mandate, but they couldn't say so right out loud. So to a gullible public they dangled the promise of "something even better" -- hydrogen -- at some indeterminate time in the future in exchange for killing the mandate that was here and now. And sadly, they succeeded.
Just one of the many benefits brought to you by a horrific degree of scientific illiteracy among both average Americans and their leaders.
TCP is an end-to-end protocol. It's only a convention (though one very widely followed) that putting a "6" in the "protocol" field of an IPv4 header means that what follows is a standard TCP header defined in RFC793 et al. But nothing requires that this be so if the end points agree on other meanings.
It's time for a general-purpose tunneling protocol specifically designed to thwart any and all port and protocol blocking in the network when it is not desired by consenting endpoints. Nothing past the IP header was ever meant for the eyes of an intermediate router, and filtering on the basis of those post-IP headers was never considered in the design of the Internet protocols.
And so the end-to-end principle will survive, and the world's telcos will be brought, kicking and screaming, into the 21st century. Or they will be left behind.
"Notching out" the ham bands is much more easily said than done. It's easy enough to not generate signals in the ham bands -- it's OFDM, so you just turn off the carriers in question -- but then power at the notched frequencies is regenerated as soon as the composite signal passes through the broadband amplifiers needed to drive the power lines.
All amplifiers have some amount of intermodulation distortion, and that's how the notched frequencies get regenerated. In fact, generating broadband noise, notching out a narrow frequency range, running it through an amplifier and measuring the power in the notched spectrum is the standard way to measure intermodulation distortion in an RF amplifier. This is the NPR (Noise Power Ratio) test.
If it were easy to build broadband amplifiers without intermodulation distortion, the cable companies never would have had to roll out all that fiber a few years ago. Since the signal gets converted back to coax before it reaches your house, it's obvious that fiber's greater bandwidth wasn't the reason. The real reason was that it proved impossible to keep the intermodulation distortion of a whole bunch of cascaded amplifiers between the head end and your house down to reasonable levels except by using much less than the coax's total theoretical bandwidth. By bringing the signal to your neighborhood with fiber, converting it to coax and running it through only one or two amplifiers at most, the intermodulation distortion is kept low enough that all of the coax's bandwidth can be filled up.
You may remember what cable TV looked like before hybrid fiber coax -- a fine haze of noise and herringbone patterns in the background on every channel. That's intermodulation distortion.
Even without its RF interference problems, BPL is a terrible excuse for a broadband technology. A power company's most valuable assets are not its wires; its most valuable assets are its rights of way. If the power companies realized this and weren't so goddamned cheap, they'd be out there pulling fiber right now. Rather than play catch-up with the phone and cable companies, the power companies could kick their asses.
Simply saying "wake up in X seconds" is fine, it doesn't matter what time it is when you wake up.
Precisely my point. And if you do need a simple, standard, unambiguous way to describe that future wakeup time, use one of the standard timescales that doesn't follow leap seconds. Don't change UTC.
If the spin of the earth is arbitrary, then what isn't?
Being chaotic is not the same thing as being arbitrary.
Very little isn't chaotic or arbitrary in this physical world. And the essence of both "chaotic" and "arbitrary" is "unpredictable". Compared to the regularity of the atomic clock, pretty much everything is chaotic, arbitrary and unpredictable.
There are different definitions of seconds. GMT and UT1 use a second which eliminates the necessity of leap seconds. These seconds aren't easily measured by atomic clocks, which is why UTC was invented.
There is only one important version of the second left: the fundamental SI unit by that name. As such it's deeply embedded in the definition of many important derived units including those for distance, volume, velocity, force, energy, power, frequency, acceleration, etc. Some of these units are even used by politicians who write them into laws and regulations.
Sure, there's still something called the sidereal day, which implies there's still something called the sidereal second, but it doesn't find very many uses outside astronomy.
The point is, you don't define unix time one way and then fundamentally change things later. But besides that, using UTC for unix time isn't a good idea, because it doesn't easily convert to and from an integer.
I agree more than you think. I read Dan Bernstein's page that you mentioned and thought it was right on the mark. I have no problem, and I don't think you really do either, with defining the UNIX epoch to be a particular instant on the UTC time scale and representing other times as an integer count of seconds before or after that epoch. That's not the same thing as trying to represent UTC times as an integer, which I agree is broken. That's also different from what we both agree is the broken practice of effectively moving the UNIX epoch every time there's a leap second so that conversion functions that know nothing about leap seconds will match UTC for timestamps produced after the leap second event.
I think we've hammered this one out as much as we can, and we're pretty much in agreement on the main points.
Not at all. Good crystal oscillators can easily keep time to well under a second over several months. Besides, atomic clocks are getting smaller and cheaper all the time; reference that NIST announcement some months ago.
But I still don't understand *why* you'd want to do such a thing. I guess if you're trying to make the perfect bomb which didn't rely on any radio signals
There are many uses for precise timers beyond time bombs. Constructive ones, in fact. Again, most of the examples I can think of come from spacecraft. Remember the Galileo probe? It separated from the mother ship five months before arrival at Jupiter, and during that time only a timer was running. At the appropriate moment, just before entering the atmosphere, it woke up.
time is relative
Would you please forget about relativity here? The effects are negligible for most real-world engineering applications, and even when it's not you can deal with it by simply agreeing on a standard reference frame for your measurements. TAI, UTC, etc are already referred to the geoid for just this reason.
Oh boy, so you have to be careful. So what? Be careful.
Well, sure. If you never made mistakes, if complexity weren't an issue, we could measure time in units of pounds-time, shillings-time and pence-time, with arbitrary, time-varying conversions between these units. But what's the point? There's much to be said for standard units and measurement scales that are as simple and elegant as possible to minimize the chances for error.
Leap seconds aren't arbitrary. They're based on the spin of the Earth.
And the spin of the earth is arbitrary. Otherwise we could predict and schedule leap seconds many years into the future. Better yet, we could have defined the second so that leap seconds weren't necessary, or at least that their long-term sum would be zero instead of positive. (The second was last redefined in 1967, and it's far too late to do it again.)
GMT would be a better system for human purposes
I disagree. The second is such a fundamental unit, and so much of the rest of physics depends on it, that it must be nailed down precisely. It also helps that time is the basic dimension we can measure most accurately, thanks to atomic clocks. That's why the meter is now defined in terms of the speed of light.
If you need a very precise model of the earth's rotation, then you have no choice but to build a complex, precise model -- it's complex, and there are irregular perturbations due to things like atmospheric mass movements. UTC and its system of leap seconds does a pretty good job in keeping the earth's rotation close enough to civil time for most purposes. It was just a mistake, though, to make it the internal basis for timestamps and such when a timescale that doesn't use leap seconds could have been used.
Without specifying a frame of reference, that definition is rather meaningless :).
Okay, once again the frame of reference is the geoid, approximately equivalent to average sea level. That's how the second and the UTC timescales are already defined.
According to him it's a broken localtime(), combined with a broken xntpd which catered to the broken localtime().
Right.
But I also noticed that the original definition was in GMT. So really the error was in changing GMT to UTC instead of UT1, and in thinking that we meant TAI seconds instead of GMT seconds.
I have no problem with basing the official definition of UNIX time on UTC, and I suspect Thompson and Ritchie would agree. They specified GMT for the UNIX epoch only because UTC didn't exist yet; it came into being (replacing GMT) on January 1, 1972.