I dislike many Microsoft products as much as the next (Unix) guy, based on what I see as poor features/function in said software/languages. And IF you have the correct skill set, there are Unix/Linux specific jobs out there (think admin or consulting); if you are a developer, there are many OS-neutral languages. If you want hired, however, you had better have the documented experience/expertise to justify that hiring. Otherwise, (IMHO) you would be better served by continuing to get the paycheck and taking courses or otherwise getting the requisite experience and then making the change at your leisure. I've encountered more than a few "wanna-be's" out there who fell flat when I put them to the test during a pre-employment interview.
If people disagree with the stupid oaf who did this, why don't you just let him know??
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: WHYFIREFOXISBLOCKED.COM
Created on: 06-Aug-07
Expires on: 06-Aug-08
Last Updated on: 06-Aug-07
Administrative Contact:
Carlton, Danny godaddy@DannyCarlton.net
19724 E Pine St
Suite #149
Catoosa, Oklahoma 75015
United States
(918) 697-4039 Fax --
Technical Contact:
Carlton, Danny godaddy@DannyCarlton.net
19724 E Pine St
Suite #149
Catoosa, Oklahoma 75015
United States
(918) 697-4039 Fax --
I guess that some version of CBDTPA could be introduced, but the landscape has changed some (it's not certain how much). First and foremost, Fritz ("Hollywood Whore") Hollings no longer chairs the committee - that's now McClain. How that plays out.... we'll see. Meanwhile, "HW" is still on the committee (AFAIK), but with far less power. Hollywood should have learned by now that when you hire a whore with a long term contract, you should make sure (s)he can go the distance. All in all, it's probably good to see opposition groups arising, even accepting that some members may have their own (equally noxious) agendas. After all, playing both sides against the middle is a proud and effective tradition. I guess we'll see where it all leads.
Hi Bazzargh, WGT the slim binaries, I agree that this would allow, in theory, a platform-independent structure with native performance. However, there are two issues (at least) that need be considered: First of all, the load/translate-to-native-code/link process must actually be within a factor of (I'm thinking) two compared with normal load/link times for a 'real' binary. For typical 'applet' size processes, this probably could be met without much effort. For larger applications (which are likely to be saved in local storage), an (automated) first-time compile with subsequent local storage of the resultant (native) binary would seem reasonable. However, the more significant issue is that of the API. For the slim binary to actually be platform independent, then each (unique) hardware/OS combination will have to have a common API to which the source can be written. This is analogous to many of the core classes in the java run time environment. Also, like the jre, the API will need to abstract data types (eg: integer, floating point, char/string, etc),I/O and file structure platform dependencies so as to provide a common (virtual) environment for the slim binary source code. I would also add that the API must allow for platform independent data exchange and rpc/rmi-like functions between hosts. I guess what I'm really saying, is that the API would have to supply the vast majority of what the current java run time is providing. The only substantive difference would be translation to native code at load time vs use of a vm; seems like an awful lot of redundant development. I think that an approach using a jvm byte code compiler and appropriate (compiled) classes is a more expedient way to go. Just my $0.02
Slashdot Mirror
I dislike many Microsoft products as much as the next (Unix) guy, based on what I see as poor features/function in said software/languages. And IF you have the correct skill set, there are Unix/Linux specific jobs out there (think admin or consulting); if you are a developer, there are many OS-neutral languages. If you want hired, however, you had better have the documented experience/expertise to justify that hiring. Otherwise, (IMHO) you would be better served by continuing to get the paycheck and taking courses or otherwise getting the requisite experience and then making the change at your leisure.
I've encountered more than a few "wanna-be's" out there who fell flat when I put them to the test during a pre-employment interview.
If people disagree with the stupid oaf who did this, why don't you just let him know??
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: WHYFIREFOXISBLOCKED.COM
Created on: 06-Aug-07
Expires on: 06-Aug-08
Last Updated on: 06-Aug-07
Administrative Contact:
Carlton, Danny godaddy@DannyCarlton.net
19724 E Pine St
Suite #149
Catoosa, Oklahoma 75015
United States
(918) 697-4039 Fax --
Technical Contact:
Carlton, Danny godaddy@DannyCarlton.net
19724 E Pine St
Suite #149
Catoosa, Oklahoma 75015
United States
(918) 697-4039 Fax --
--AC -:)
I guess that some version of CBDTPA could be introduced, but the landscape has changed some (it's not certain how much). First and foremost, Fritz ("Hollywood Whore") Hollings no longer chairs the committee - that's now McClain. How that plays out .... we'll see. Meanwhile, "HW" is still on the committee (AFAIK), but with far less power. Hollywood should have learned by now that when you hire a whore with a long term contract, you should make sure (s)he can go the distance. All in all, it's probably good to see opposition groups arising, even accepting that some members may have their own (equally noxious) agendas. After all, playing both sides against the middle is a proud and effective tradition.
I guess we'll see where it all leads.
Hi Bazzargh, WGT the slim binaries, I agree that this would allow, in theory, a platform-independent structure with native performance. However, there are two issues (at least) that need be considered: First of all, the load/translate-to-native-code/link process must actually be within a factor of (I'm thinking) two compared with normal load/link times for a 'real' binary. For typical 'applet' size processes, this probably could be met without much effort. For larger applications (which are likely to be saved in local storage), an (automated) first-time compile with subsequent local storage of the resultant (native) binary would seem reasonable. However, the more significant issue is that of the API. For the slim binary to actually be platform independent, then each (unique) hardware/OS combination will have to have a common API to which the source can be written. This is analogous to many of the core classes in the java run time environment. Also, like the jre, the API will need to abstract data types (eg: integer, floating point, char/string, etc),I/O and file structure platform dependencies so as to provide a common (virtual) environment for the slim binary source code. I would also add that the API must allow for platform independent data exchange and rpc/rmi-like functions between hosts. I guess what I'm really saying, is that the API would have to supply the vast majority of what the current java run time is providing. The only substantive difference would be translation to native code at load time vs use of a vm; seems like an awful lot of redundant development. I think that an approach using a jvm byte code compiler and appropriate (compiled) classes is a more expedient way to go. Just my $0.02