If Apple decides that only those under NDA should see it, and only a select few will be granted NDA to see it, then they shouldn't see it, period. You can wax philosophic about the pros of early access by the public, but it means nada in this case.
I'd be happy to run the tests, but I'd need support from the linux community as I'm not experienced enough with it to be comfortable claiming x.y.z is a reasonable setup environment.
Blech, you did your testing with 5.1?! Had you actually checked with anyone in the FreeBSD community at the time, or read the lists, you would have seen 5.x was still very much in the teething stage and you'd have been better off with 4.x.
That said, it'd be interesting to rerun against 4.11 and 6.1-RC to see how they're doing.
Er, blocking outbound port 25 for consumer grade connections isn't all that evil. It's pretty much a recomended practice for most ISPs. The ISP provides a smtp relay, you're in their ip space, use the relay. Opening up port 25 for most people just means crazy amounts of spam spewing out of your network.
Not really... Apple has been working on this for what, 10 years now? OS X, Rhapsody, and all the projects before trying to get away from Classic while maintaining some form of backwards compatibility gave them plenty of practice. Heck, A/UX had a classic emulation layer, and it's how old?
Depends on the state. In Maine, it's illegal for anyone under 21 to consume alcholic beverages, period. Dad can't pass a capful of Bud to his son at dinner, under their own roof. I think the majority of states are that way.
Interesting, maybe it was only certain drives that had the 'no quibble' policy then? Although the drives I used it on were Best Buy specials so I didn't think there was anything out of the ordinary with them. Were you dealing with the online RMA tool, or calling direct?
But on the flip side, Maxtor had a 'no quibble' warranty. I could call up, say aliens flipped me off, replace my HD, and as long as it was within the warranty window, it'd get replaced. No questions asked, no running diag software, nada.
Came in handy when I had two drives from a 4 drive array that wrote at about 1/8th the speed of the other two. I couldn't produce a fault with any test, other than abysmal write speed. No problem, two new drives, advance replacement, done.
ALL HDs fail, so in my mind, a warranty that's easy to use is the one that wins for me. The big question in my mind is if Seagate will continue this policy. That plus a standard 5 year warranty, and I'll be buyning nothing but Seagate.
Psst, people can put and get video and other media online, RIGHT NOW! Why wait for the current media giants to take over the new venue by hook, crook, and legislation?
Court - "Fix your software to meet our requirements for our market." Kazaa - "Nah, we'll just pull out of your market, no infringement, no issue." Court - "Uh... like, no, you have to offer software to us so we can impose requirements on it, cause, ummm..." Austrailian RIAA - "Yeah, cause we loose if we don't have someone to blame for 'lower profits!'" Court - "Thats not quite right, shut up you!"
At least in ID they spent some time figuring out the target system before deciding they could inject anything. This is just sending out raw 'code' and hoping it works.
Actually, I've dealt with many Windows boxen under constant high load. One example, I used to run the largest US Quake server farm, back in the heady days when quakeworld was a fun new way to do multiplayer... I had 5 boxen running NT 4, up 24x7, cpus pegged 24x7. One AMD 5x86 OC'd to 160mhz (the runt), One P2 333, one dual P166, one dual Celeron 300a, and my favorite, my Alpha 21164 533 running at 600mhz. I was averaging about 3 month uptimes, they would have been better but the breaker kept blowing at inopportune times in the dorm. : ) Given their behavior, the only thing that could have killed them, mem leaks in netquake/quakeworld. The guestimate was the Alpha would choke from them first, if it hit 6 months. As I said though, less than stellar power kept that from occuring. I had a second 5x86 box running Linux, 2.0.something kernel, I could consistantly blow it up with more than 6gb total transfer, the nic driver would implode. That box had a cron scheduled weekly reboot. I think that driver was fixed after I moved that machine to FreeBSD, never did follow up on it.
In any case, those machines went to 3 months under full load without incident, I have no reason to believe the OS would have nuked them down the road. The only internal uptime hazzards, the mem leaks in the apps I chose to run.
Actually, auto ads regularly mention competing brands directly. For refrence, a Ford ad where they have 'Mr Tough Ford driver' pull out three sample frame rails, with the Ford unit being bigger. He then shows the 'inferior' units while saying which brand they come from, Dodge and Chevy.
Mazda (I think) has adds with techs wearing lab coats blazoned with "Toyota", "Honda", on them drooling over Mazda's latest and greatest.
One of the two conditions was met, it worked flawlessly on all tests up to and including the one at 9 mins before launch. Once in space, the booster tank is already jettisoned, sensor included, so if it wants to fail during reentry, more power to it.
Fuel SENSOR, not valve. One of 4 redundant units, which only come into play when a few systems above them, which are duplicated for redundancy, fail. For this particular system to botch, the three other sensors would also have had to fail.
After draining the tank, NASA could not reproduce the failure. Wiring was tested/replaced/etc, no failures.
The decision was to test multiple times before the launch, including one last test at 9 minutes before. The only conditions that would allow launch to continue, the sensor works, or fails in the exact same mannor as before. Any other behavior patterns would have halted the launch. Had it failed the same way, the behavior would have been predictable, and the systems setup to ignore the faulty sensor and rely on three other duplicates.
Ooofh, that test data is so out of date it hurts. : ) FreeBSD 5.x up till recently was very much a debug build that was still being tuned. I'd like to see the tests rerun using current releases, toss DragonFly in there as well.
Slashdot Mirror
Fair enough.
If Apple decides that only those under NDA should see it, and only a select few will be granted NDA to see it, then they shouldn't see it, period. You can wax philosophic about the pros of early access by the public, but it means nada in this case.
I'd be happy to run the tests, but I'd need support from the linux community as I'm not experienced enough with it to be comfortable claiming x.y.z is a reasonable setup environment.
Blech, you did your testing with 5.1?! Had you actually checked with anyone in the FreeBSD community at the time, or read the lists, you would have seen 5.x was still very much in the teething stage and you'd have been better off with 4.x.
That said, it'd be interesting to rerun against 4.11 and 6.1-RC to see how they're doing.
Er, blocking outbound port 25 for consumer grade connections isn't all that evil. It's pretty much a recomended practice for most ISPs. The ISP provides a smtp relay, you're in their ip space, use the relay. Opening up port 25 for most people just means crazy amounts of spam spewing out of your network.
Not really... Apple has been working on this for what, 10 years now? OS X, Rhapsody, and all the projects before trying to get away from Classic while maintaining some form of backwards compatibility gave them plenty of practice. Heck, A/UX had a classic emulation layer, and it's how old?
So... IBM making Win compatible PCs and shipping them with OS/2 doesn't predate Apple making Win compatible PCs and shipping it with !Windows how?
They don't show the xbox booting that DVD, but reading from it after a hot swap while the system is running...
Depends on the state. In Maine, it's illegal for anyone under 21 to consume alcholic beverages, period. Dad can't pass a capful of Bud to his son at dinner, under their own roof. I think the majority of states are that way.
Good thing the US doesn't control all the root servers!
Interesting, maybe it was only certain drives that had the 'no quibble' policy then? Although the drives I used it on were Best Buy specials so I didn't think there was anything out of the ordinary with them. Were you dealing with the online RMA tool, or calling direct?
But on the flip side, Maxtor had a 'no quibble' warranty. I could call up, say aliens flipped me off, replace my HD, and as long as it was within the warranty window, it'd get replaced. No questions asked, no running diag software, nada.
Came in handy when I had two drives from a 4 drive array that wrote at about 1/8th the speed of the other two. I couldn't produce a fault with any test, other than abysmal write speed. No problem, two new drives, advance replacement, done.
ALL HDs fail, so in my mind, a warranty that's easy to use is the one that wins for me. The big question in my mind is if Seagate will continue this policy. That plus a standard 5 year warranty, and I'll be buyning nothing but Seagate.
I for one do NOT welcome these new img tag bearing overlords.
Psst, people can put and get video and other media online, RIGHT NOW! Why wait for the current media giants to take over the new venue by hook, crook, and legislation?
I don't see the contempt of court here.
Court - "Fix your software to meet our requirements for our market."
Kazaa - "Nah, we'll just pull out of your market, no infringement, no issue."
Court - "Uh... like, no, you have to offer software to us so we can impose requirements on it, cause, ummm..."
Austrailian RIAA - "Yeah, cause we loose if we don't have someone to blame for 'lower profits!'"
Court - "Thats not quite right, shut up you!"
Really? All these people with defective units are being told they won't be repaired or replaced under warranty? THATS news, if it's true.
So you're saying Gtk+ WebCore is so badly coded it will ONLY run on a linux kernel based OS?
At least in ID they spent some time figuring out the target system before deciding they could inject anything. This is just sending out raw 'code' and hoping it works.
Handy thing about OS X, you can develop drivers in Darwin and use them under OS X. If Darwin supports it, OS X does too!
Of course, by your logic, noone would run linux, a BSD, etc. MS-Dos works, whats the problem?
Actually, I've dealt with many Windows boxen under constant high load. One example, I used to run the largest US Quake server farm, back in the heady days when quakeworld was a fun new way to do multiplayer... I had 5 boxen running NT 4, up 24x7, cpus pegged 24x7. One AMD 5x86 OC'd to 160mhz (the runt), One P2 333, one dual P166, one dual Celeron 300a, and my favorite, my Alpha 21164 533 running at 600mhz. I was averaging about 3 month uptimes, they would have been better but the breaker kept blowing at inopportune times in the dorm. : ) Given their behavior, the only thing that could have killed them, mem leaks in netquake/quakeworld. The guestimate was the Alpha would choke from them first, if it hit 6 months. As I said though, less than stellar power kept that from occuring. I had a second 5x86 box running Linux, 2.0.something kernel, I could consistantly blow it up with more than 6gb total transfer, the nic driver would implode. That box had a cron scheduled weekly reboot. I think that driver was fixed after I moved that machine to FreeBSD, never did follow up on it.
In any case, those machines went to 3 months under full load without incident, I have no reason to believe the OS would have nuked them down the road. The only internal uptime hazzards, the mem leaks in the apps I chose to run.
Back on topic, that Linux machine must have had some hardware flaw. Bad memory comes to mind...
If there was, it should show up under Windows as well.
Actually, auto ads regularly mention competing brands directly. For refrence, a Ford ad where they have 'Mr Tough Ford driver' pull out three sample frame rails, with the Ford unit being bigger. He then shows the 'inferior' units while saying which brand they come from, Dodge and Chevy.
Mazda (I think) has adds with techs wearing lab coats blazoned with "Toyota", "Honda", on them drooling over Mazda's latest and greatest.
One of the two conditions was met, it worked flawlessly on all tests up to and including the one at 9 mins before launch. Once in space, the booster tank is already jettisoned, sensor included, so if it wants to fail during reentry, more power to it.
Fuel SENSOR, not valve. One of 4 redundant units, which only come into play when a few systems above them, which are duplicated for redundancy, fail. For this particular system to botch, the three other sensors would also have had to fail.
After draining the tank, NASA could not reproduce the failure. Wiring was tested/replaced/etc, no failures.
The decision was to test multiple times before the launch, including one last test at 9 minutes before. The only conditions that would allow launch to continue, the sensor works, or fails in the exact same mannor as before. Any other behavior patterns would have halted the launch. Had it failed the same way, the behavior would have been predictable, and the systems setup to ignore the faulty sensor and rely on three other duplicates.
Ooofh, that test data is so out of date it hurts. : ) FreeBSD 5.x up till recently was very much a debug build that was still being tuned. I'd like to see the tests rerun using current releases, toss DragonFly in there as well.