I have a pair of external FW800 drives in a software RAID-1 configuration. Every month I bring one of them home from the office, remirror, break the mirror again and take it back to the office.
If I have a total system loss (fire, theft, etc.) I'm worst case 1 month out of date.
My very critical data that I can't tolerate a 1 month loss of, I use online backup (http://www.tarsnap.com)
Neither is cloning. Neither will protect you from human error.
Re:Too bad we can't mod the original article Troll
on
Java Is So 90s
·
· Score: 1
Actually he explicitly said the Objective-C based WebObjects, which Apple killed off. 4.5.1 update 4 is the last version Apple produced, and it isn't supported on anything newer than Mac OS X 10.1.
The bastardized Java version (5.x) was a step backwards. They spent years rewriting everything in Java and lost the advantage they had over their competition. WebObjects fans didn't like it because it meant rewriting all of their code in an inferior language, and Java people didn't like it because it didn't use standard java programming idioms.
The biggest problem I've seen is the lack of decent dynamic runtime support.
For instance, you can't write transparent proxy objects because you can't write a method to capture messages that are not implemented in the class.
Objective-C has had this behavior for nearly 20 years now:
doesNotRecognizeSelector: Handles aSelector messages the receiver doesn't recognize.
- (void)doesNotRecognizeSelector:(SEL)aSelector
Discussion The runtime system invokes this method whenever an object receives an aSelector message it can't respond to or forward. This method, in turn, raises an NSInvalidArgumentException, and generates an error message.
You can subclass this method and transparently forward the request to another object, marshall it up and send it across the network to a remote process, etc.
>> On-seat power outlets for your laptop? Forget it. >> >> Seatback TV screens? Not even close. >> >> Comfy leather seats? Those are decadant luxuries of the West, >> don't you know. >> >> Well, I'm sorry.
Wow, sounds like pretty much every American Airlines flight I've been on. I have yet to have an airline seat with w power adaptor. I did have a TV screen once on a transatlantic flight, but the video playback system on the plane was broken so all I could get was the map. Do you have to pay for overpriced first-class seats just to get a basic power socket?
I can't wait until Apple gets rid of the need for the prebinding hack. I'm tired of my binaries always being modified. I can't compare checksums on two different machines to see if a binary has been changed, backups are slower than necessary, etc.
Also, from the developers point of view, you need to MANULLY specify the load address of frameworks...the devtools aren't smart enough fo figure them out for you.
That's the one thing I hate about Mozilla. It works well enough (well compared to the alternatives anyway). It's just butt-ugly. I haven't found a the yet to make it clash less with Aqua. Even if it LOOKED 100% Aqua, it still would behave odd though.
Does anyone know how to make Mozilla use my preferred e-mail program instead of Mozilla when I click on a mailto: link for instance?
This brings up another long time gripe of mine (totally unrelated to Sci-Fi channel). It's with how cable and satellite companies package their channels. There is no way to 'send a message' to Sci-Fi by dropping them without dropping a lot of other channels. I'm not giving up Comedy Central (gotta have my South Park) just to drop Sci-Fi.
Why won't they just let us pick (and pay for) only the individual channels that we want to watch? I never watch the Home Gardening Network for instance, but I have to take if if I want Comedy Central.
Lately I've given up on Sci-Fi channel. I've found that Showtime is starting to become a better Sci-Fi channel than the Sci-Fi channel:-)
I haven't found anything yet of the quality of Babylon 5, but Jeremiah and Odyssey 5 have done a better job of drawing me in than anything Sci-Fi channel currently offers.
I did like season #2 of Lexx...but it REALLY sucked after that.
Sort of reminds me of the psuedo-serial connector on the back of my Magellan GPS. It had 3 or so flat metal "plates" flush with the back of the unit. The end of the cable has 3 matching metal brushes that line up with the plates. You screw in the connector (with the attached thumbscrew) to make contact.
Weird, but it works well for the enviornment. A traditional plug wouldn't work. Pins would break off, or holes would get clogged with gunk/mud. flush metal plates stand up well in the rough environemnt. Just wipe it off and you're ready to go.
I think there should be a special place in Hell reserved for the inventor of the cursed hard drive power plug. I can't count how many times I've ended up with a bloody hand after straining to pull the damn plug free only to have it suddently break free sending my hand into some sharp part of my computer innards:-(
Yes, the lack of driver support would be the problem. It doesn't matter that Apple has a standard PCI bus. There are hundreds of standard PCI cards on the market that I can't use on my Mac due to lack of drivers.
Apple does a majority of the driver development themselves, since most vendors honestly don't care enough to make OS X drivers. In the WinTel side of the world, the vendors DO care enough about Windows support to write the drivers. So, drivers are not Microsoft's responsility.
I with 3rd parties cared more about OS X. I would love to be able to buy any PCI card on the shelf at CompUSA and have some hope of using it in a Mac. After all, the hardware is compatible...it's just a matter of software.
Actually there is an Intel port. There has been for years. Way back in the Rhapsody days there were two developer releases available for Intel. Just because they stopped making them available doesn't mean they stopped building it.
The biggest reason is that maintaining an Intel version ensures that everything they write stays reasonably portable. It they can stay compatible with PPC and Intel in the code, than supporting any other chip that comes along can't be much more difficult.
Internal builds used to always be built fat...they would just be stripped to PPC-only when it came time to press to a CD for external use. I don't know if it's still the case, but I don't see why they would stop the practice.
Also, maintaining compatibility keeps future migration options open to them.
Most of OS X is highly portable already. The kernel is Mach, which was fundamentally designed with portability in mind. Above that is the BSD layer which is regularly synched with the OpenBSD source tree, which is x86 code -- so it's portable. CoreFoundation is part of Darwin, so it already compiles on x86. Cocoa is very high level and used to run on x86 back in the OpenStep days...no big issues there. I see no reason why Cocoa couln't easily go to Darwin as well. Apple had to basically build the Carbon library from scratch after the developer community refused to migrate en-masse to Cocoa. I don't believe Apple would be short-sighted enough to not write it in a portable fashion. Really, Classic is the only part of OS X that would cause a problem with an x86 port. If push comes to shove, Apple could just draw a line in the sand and say that Classic isn't supported...developers have had enough time to move their stuff forward.
Of course, just because the port is possible doesn't mean that Apple will ever make it a product. Support for such a thing would be a nightmare given the huge number of hardware options in the x86 world. Apple is barely capable of keeping up with drivers for there exremely limited set of hardware options.
Actually Cisco hardware *IS* PC hardware (at least the case in the PIX). The difference is that the PIX OS is designed solely for the purpose of being a firewall...not as a general purpose OS like Windows or Linux. And the NIC is nothing special...it's an Intel EtherExpress Pro 100/b.
I've been developing in ObjC for nearly 6 years now. The biggest advantages of ObjC is it's simplicity, and that fact that it is really dynamic.
Some of the features that I like:
Categories: This allows you to add a method to a pre-existing class without having to have source to it. For instance, if you think the NSString class should have a urlEncodedString method, just add it. Now all NSStrings will respond to this method!
PoseAs: Even cooler. This allows a subclass to actually "pose as" it's parent. Normally a dangerous technique if you aren't careful, but it's an excellent way of tracing object interactions go or fixing library bugs.
However, I still think that the coolest part (inherited from Smalltalk) is the dynamic dispatch architecture. For instance, you can implement a method named 'forwardInvocation:' That way, if any unknown message gets sent to your instance, it will first get sent to the forwardInvocation: method allowing you a 2nd chance at processing it. This is cool because you can redirect the invocation to another object and become a transparent proxy. This makes distributed object systems EXTREMELY easy to work with.
Stateless is actually better at the raw protocol layer. It's a LOT easier to implement transparent failover if you don't have to worry about state issues.
Pipelining my get rid of connection overhead, but it still has a fundamental limitation: The requests must be responded to in the same order that they arrived. This is a BIG problem if you have a server that handles multiple request types, some of them fast, some of them slow. If you get a slow request followed by a dozen fast requests, those fast requests will have to wait until you can generate an answer for the slow request, since you MUST send the answer for the slow request first.
This is the main reason why I implement my own protocol instead of just use HTTP. Supposedly BEEP can handle this case, but the code doesn't seem to compile, so I haven't tried it out.
I tried playing with it. For an idea whose goal is to provide a platform-neutral protocol foundation, the implementations I found seem highly unportable. None of them would even come close to compiling on OS X.
I originally intended to dump my proprietary protocol code, but it turns out easier to maintain what I already have than to get BEEP to even function.
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/s sh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-serv er\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keys ign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-he lper\" -DHAVE_CONFIG_H -c canohost.c cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory canohost.c: In function `get_remote_hostname': canohost.c:68: warning: implicit declaration of function `getnameinfo' canohost.c:91: warning: subscript has type `char' canohost.c:108: warning: implicit declaration of function `getaddrinfo' canohost.c:120: warning: implicit declaration of function `freeaddrinfo' canohost.c: In function `check_ip_options': canohost.c:153: warning: implicit declaration of function `getprotobyname' canohost.c:153: warning: assignment makes pointer from integer without a cast canohost.c:154: dereferencing pointer to incomplete type *** Error code 1 make: Fatal error: Command failed for target `canohost.o'
I'm sure glad I'm not required to move to 3.4 to plug the hole...
Java on the server never made sense to me. After all, you KNOW what hardware/OS you are running on. What's the point of paying a virtual machine penalty for platform independence when you don't need it, since you control the box?
Slashdot Mirror
news about stuff that maters: http://www.tomatonews.com/
I have a pair of external FW800 drives in a software RAID-1 configuration. Every month I bring one of them home from the office, remirror, break the mirror again and take it back to the office.
If I have a total system loss (fire, theft, etc.) I'm worst case 1 month out of date.
My very critical data that I can't tolerate a 1 month loss of, I use online backup (http://www.tarsnap.com)
I thought that was vampires.
Noel is a she. I met her last year soon after Apple hired her away from Sun.
Neither is cloning. Neither will protect you from human error.
Actually he explicitly said the Objective-C based WebObjects, which Apple killed off. 4.5.1 update 4 is the last version Apple produced, and it isn't supported on anything newer than Mac OS X 10.1.
The bastardized Java version (5.x) was a step backwards. They spent years rewriting everything in Java and lost the advantage they had over their competition. WebObjects fans didn't like it because it meant rewriting all of their code in an inferior language, and Java people didn't like it because it didn't use standard java programming idioms.
The biggest problem I've seen is the lack of decent dynamic runtime support.
For instance, you can't write transparent proxy objects because you can't write a method to capture messages that are not implemented in the class.
Objective-C has had this behavior for nearly 20 years now:
doesNotRecognizeSelector:
Handles aSelector messages the receiver doesn't recognize.
- (void)doesNotRecognizeSelector:(SEL)aSelector
Discussion
The runtime system invokes this method whenever an object receives an aSelector message it can't respond to or forward. This method, in turn, raises an NSInvalidArgumentException, and generates an error message.
You can subclass this method and transparently forward the request to another object, marshall it up and send it across the network to a remote process, etc.
>> On-seat power outlets for your laptop? Forget it.
>>
>> Seatback TV screens? Not even close.
>>
>> Comfy leather seats? Those are decadant luxuries of the West, >> don't you know.
>>
>> Well, I'm sorry.
Wow, sounds like pretty much every American Airlines flight I've been on. I have yet to have an airline seat with w power adaptor. I did have a TV screen once on a transatlantic flight, but the video playback system on the plane was broken so all I could get was the map.
Do you have to pay for overpriced first-class seats just to get a basic power socket?
I can't wait until Apple gets rid of the need for the prebinding hack. I'm tired of my binaries always being modified. I can't compare checksums on two different machines to see if a binary has been changed, backups are slower than necessary, etc.
Also, from the developers point of view, you need to MANULLY specify the load address of frameworks...the devtools aren't smart enough fo figure them out for you.
That's the one thing I hate about Mozilla. It works well enough (well compared to the alternatives anyway). It's just butt-ugly. I haven't found a the yet to make it clash less with Aqua. Even if it LOOKED 100% Aqua, it still would behave odd though.
Does anyone know how to make Mozilla use my preferred e-mail program instead of Mozilla when I click on a mailto: link for instance?
This brings up another long time gripe of mine (totally unrelated to Sci-Fi channel). It's with how cable and satellite companies package their channels. There is no way to 'send a message' to Sci-Fi by dropping them without dropping a lot of other channels. I'm not giving up Comedy Central (gotta have my South Park) just to drop Sci-Fi.
Why won't they just let us pick (and pay for) only the individual channels that we want to watch? I never watch the Home Gardening Network for instance, but I have to take if if I want Comedy Central.
Lately I've given up on Sci-Fi channel. I've found that Showtime is starting to become a better Sci-Fi channel than the Sci-Fi channel :-)
I haven't found anything yet of the quality of Babylon 5, but Jeremiah and Odyssey 5 have done a better job of drawing me in than anything Sci-Fi channel currently offers.
I did like season #2 of Lexx...but it REALLY sucked after that.
Sort of reminds me of the psuedo-serial connector on the back of my Magellan GPS. It had 3 or so flat metal "plates" flush with the back of the unit. The end of the cable has 3 matching metal brushes that line up with the plates. You screw in the connector (with the attached thumbscrew) to make contact.
Weird, but it works well for the enviornment. A traditional plug wouldn't work. Pins would break off, or holes would get clogged with gunk/mud. flush metal plates stand up well in the rough environemnt. Just wipe it off and you're ready to go.
I think there should be a special place in Hell reserved for the inventor of the cursed hard drive power plug. I can't count how many times I've ended up with a bloody hand after straining to pull the damn plug free only to have it suddently break free sending my hand into some sharp part of my computer innards :-(
Yes, the lack of driver support would be the problem. It doesn't matter that Apple has a standard PCI bus. There are hundreds of standard PCI cards on the market that I can't use on my Mac due to lack of drivers.
Apple does a majority of the driver development themselves, since most vendors honestly don't care enough to make OS X drivers. In the WinTel side of the world, the vendors DO care enough about Windows support to write the drivers. So, drivers are not Microsoft's responsility.
I with 3rd parties cared more about OS X. I would love to be able to buy any PCI card on the shelf at CompUSA and have some hope of using it in a Mac. After all, the hardware is compatible...it's just a matter of software.
Actually there is an Intel port. There has been for years. Way back in the Rhapsody days there were two developer releases available for Intel. Just because they stopped making them available doesn't mean they stopped building it.
The biggest reason is that maintaining an Intel version ensures that everything they write stays reasonably portable. It they can stay compatible with PPC and Intel in the code, than supporting any other chip that comes along can't be much more difficult.
Internal builds used to always be built fat...they would just be stripped to PPC-only when it came time to press to a CD for external use. I don't know if it's still the case, but I don't see why they would stop the practice.
Also, maintaining compatibility keeps future migration options open to them.
Most of OS X is highly portable already. The kernel is Mach, which was fundamentally designed with portability in mind. Above that is the BSD layer which is regularly synched with the OpenBSD source tree, which is x86 code -- so it's portable. CoreFoundation is part of Darwin, so it already compiles on x86. Cocoa is very high level and used to run on x86 back in the OpenStep days...no big issues there. I see no reason why Cocoa couln't easily go to Darwin as well. Apple had to basically build the Carbon library from scratch after the developer community refused to migrate en-masse to Cocoa. I don't believe Apple would be short-sighted enough to not write it in a portable fashion. Really, Classic is the only part of OS X that would cause a problem with an x86 port. If push comes to shove, Apple could just draw a line in the sand and say that Classic isn't supported...developers have had enough time to move their stuff forward.
Of course, just because the port is possible doesn't mean that Apple will ever make it a product. Support for such a thing would be a nightmare given the huge number of hardware options in the x86 world. Apple is barely capable of keeping up with drivers for there exremely limited set of hardware options.
Actually Cisco hardware *IS* PC hardware (at least the case in the PIX). The difference is that the PIX OS is designed solely for the purpose of being a firewall...not as a general purpose OS like Windows or Linux. And the NIC is nothing special...it's an Intel EtherExpress Pro 100/b.
I've been developing in ObjC for nearly 6 years now. The biggest advantages of ObjC is it's simplicity, and that fact that it is really dynamic.
Some of the features that I like:
Categories: This allows you to add a method to a pre-existing class without having to have source to it. For instance, if you think the NSString class should have a urlEncodedString method, just add it. Now all NSStrings will respond to this method!
PoseAs: Even cooler. This allows a subclass to actually "pose as" it's parent. Normally a dangerous technique if you aren't careful, but it's an excellent way of tracing object interactions go or fixing library bugs.
However, I still think that the coolest part (inherited from Smalltalk) is the dynamic dispatch architecture. For instance, you can implement a method named 'forwardInvocation:' That way, if any unknown message gets sent to your instance, it will first get sent to the forwardInvocation: method allowing you a 2nd chance at processing it. This is cool because you can redirect the invocation to another object and become a transparent proxy. This makes distributed object systems EXTREMELY easy to work with.
Stateless is actually better at the raw protocol layer. It's a LOT easier to implement transparent failover if you don't have to worry about state issues.
Pipelining my get rid of connection overhead, but it still has a fundamental limitation: The requests must be responded to in the same order that they arrived. This is a BIG problem if you have a server that handles multiple request types, some of them fast, some of them slow. If you get a slow request followed by a dozen fast requests, those fast requests will have to wait until you can generate an answer for the slow request, since you MUST send the answer for the slow request first.
This is the main reason why I implement my own protocol instead of just use HTTP. Supposedly BEEP can handle this case, but the code doesn't seem to compile, so I haven't tried it out.
I tried playing with it. For an idea whose goal is to provide a platform-neutral protocol foundation, the implementations I found seem highly unportable. None of them would even come close to compiling on OS X.
I originally intended to dump my proprietary protocol code, but it turns out easier to maintain what I already have than to get BEEP to even function.
3.4 doesn't even compile on Solaris 5.8:
s sh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-serv er\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keys ign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-he lper\" -DHAVE_CONFIG_H -c canohost.c
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/
cc1: warning: changing search order for system directory "/usr/local/include"
cc1: warning: as it has already been specified as a non-system directory
canohost.c: In function `get_remote_hostname':
canohost.c:68: warning: implicit declaration of function `getnameinfo'
canohost.c:91: warning: subscript has type `char'
canohost.c:108: warning: implicit declaration of function `getaddrinfo'
canohost.c:120: warning: implicit declaration of function `freeaddrinfo'
canohost.c: In function `check_ip_options':
canohost.c:153: warning: implicit declaration of function `getprotobyname'
canohost.c:153: warning: assignment makes pointer from integer without a cast
canohost.c:154: dereferencing pointer to incomplete type
*** Error code 1
make: Fatal error: Command failed for target `canohost.o'
I'm sure glad I'm not required to move to 3.4 to plug the hole...
Wow, so sort of like the FBI then. Where do I sign up for this wonderful "service"?
Java on the server never made sense to me. After all, you KNOW what hardware/OS you are running on. What's the point of paying a virtual machine penalty for platform independence when you don't need it, since you control the box?