Most code that PHB #324 needs will either already have been written, or can be written by someone using a high-level development tool, such as a CDE
Really?
How many CDEs are there? I dont know of any practical usefull ones. Maybe tomorrow, not today. And I think this misses a whole point. Fred Brooks' accidentant and essential complexity. In the same way that configuring IP in old school UNIX and Windows NT is different levels of complexity. But the underlying knowledge you have to have about IP doesnt really change, does it? You dont have to remember so much stuff about "this file handles this part, it is there, and the wand needs to be waved thus to change things". But you do need to know on both what does this thing need to do, how do I configure it. The wand waving is the accidental part, that can be minimized. The essestial part is the knowing what the thing does.
As to your calling fewer programming jobs non sequitur, I wonder. Because that is in fact the whole of the point
Short term, I think the GP is probably correct about this. American programmers seem to be losing jobs, but American corporations do seem to be hiring outsourcing firms. Total numbers? I dont know, but I dont know that we can say they are going down now, really. ( and there probably is some outfall of the "bubble" runup, in that there were many people hired as programmers because they could recognize a computer 3 out of 4 times. Those who did not have the real talents will fall out of the pool, but they probably should not have been in in the first place. I personally dont really count those. ). Long term? You and TFA may have the beginnings of a point, but remember that COBOL brought us the same promise ( that the business people would take the reins and do the "programming". ). That and think about the accidental/essestial complexity I mentioned above. I have yet to meet a business person who understands the issues involved. For example, one thing I keep running into is business people, when relating requirements, who tell me "oh, but you dont have to worry about that, it doesnt happen all that often". But, then, if the application didnt handle that case ( infrequent though it be ) they would be all over me about it. ( dont worry, my app handled it.:-) ( Yes, more than one instance ).
This saving and restoring-- I wonder if the files are changed by this process;
My understanding is that no change is needed. Also, this is ( in my mind anyway ) confirmed by the change in underlying CPU machine code in an AS/400 upgrade that I performed. No recompilation was required to run once the new CPU was installed, only the machine dependant parts ( TIMI, HAL ) were changed. The tape was suprisingly small that accomplished this. My recollection ( could be mistaken, but I dont think so ) is that the HAL abstracts you away from the underlying hardware, and the OS and Applications all run atop that abstract layer. ( And, I think this is my point: if the HAL in NT did this also, then one "binary" could ship, and the actual CPU in the machien would not be an issue, you would only target that abstract machine layer, not the CPU. )
Either that, or the code was never in native machine language; it was just interpreted on demand like Java bytecode. I guess if the CPU had support to natively execute different instruction sets
The "binary" was not in the CPU's native format, it was in the AS/400's native format, at least the abstracted machines native format. It is kinda like bytecode, conceptually, I guess, but it is a bit different ( and I am trying not to oversimplify:-)
I was operations manager at a shop that had an AS/400 in the early ninties, that is where I learned what I know about them. Stoggy machines in a lot of ways, but they were bullet proof, very easy to keep running and use.
The only kind of abstraction layer I know of that lets you compile into a cpu independent format is a VM...
"The machine survives because the Hardware abstraction layer of its microcode (called TIMI for "Technology Independent Machine Interface" by IBM) allows the operating system and application programs to take advantage of advances in hardware and software without recompilation. This means that a program written and compiled on a S/38 can be run as a native 64 bit program. The HAL allows a system that costs $9000 to run the exact same operating system and software as a $2 million system."
so, no I dont think a recompile is needed. As I mentioned in a previous post, a company I worked for upgraded from the old CPU style to a PowerPC based CPU. Different machine languages. The HAL was updated, the machine ran ( faster ), and we did not recompile any of the applications we had written on it.
There is nothing that you could DO with it in user mode...
I dont mean user mode. I understand that. I meant that if the same kind of architecture was in place on a PC as in the AS/400, the user mode applications would not need recompiled due to a change in the underlying CPU ( Intel, Alpha, MIPS, PPC, etc ). The HAL would change, and that would be it.
Upshot would be that you *could* have one "binary" format that would run on any processor architechure that a HAL was available for.
So you DO understand that the NT HAL doesn't provide CPU portability alone?
That was my intial point, that it does not.
If MS had gone the AS/400 route, then many binaries ( those not involved in the HAL ) *would* be interchangable across platforms.
OTOH, the HAL and part of the kernel do provide CPU portability on a source code level...
And I am not talking about at a source code level, but at a deeper level. A completely abstracted machine.
I agree we need to slow human growth and otherwise learn to me more efficient with the earth we have.
I dont see how that means that space, both near and far will not be *part of* a solution to overcrowding.
I dont agree that we will run out of land and resources before we can send *some* people off to space colonies. At least not if we *begin* sometime soon. If we wait, then yes, we may run out.
Also, there are other benefits to having a human population in space.
A: Catastrophies happening to earth dont wipe out the human race. ( debate on wiping out the human race being a good thing can begin now:-)
B: All the manufacturing that is so polluting here on earth need not be so in space. Not to mention the raw materials that would be available to us without having to damage the earth.
I would guess there are other benefits I am not seeing right now.
So, in my opinion, the solution is here on the ground, in near space, in deep space.
The article mentioned that if you dont have a partner station to slow down the craft at the end of the voyage, you simply dont push it up to full speed. Just fast enough to get it there, without it being "catchable" by gravity or the resources available in the craft ( ordinary rockets, or whatever ). Use this "slow mode" to get enough out there to build a catching/relaunching station, then go to full power.
Others have responded with good info. If there were a counter beam, consider that it would not *have* to be aimed at earth. It might be such that both jets form a tangent to the surface of the earth below.
Also, multiple beams at angles to the propulsive beam could be used to keep the attitude adjustment beams from being pointed at earth.
*And*, who says these things need to be in earth orbit? Put them in a Lagrange point somewhere, and let them work from there. Some work would need to be done to keep the beam from pointing at things we want to keep, but it seems that that wouldnt be too hard.
The NT HAL is for anything in kernel mode. It would be useless to user mode programs.
It doesnt *have* to be only for kernal mode. Granted that would be more work, and probably more overhead.
What you are describing sounds like a VM environment, like Java. It's not
I was trying to describe the abstracted machine layer that the AS/400 provides. No, not like Java.
On an AS/400, there are only two ways to get binary code... Still, binary code does in fact exist....
OK, but my point is that as a compiler writer or whatever, my target properly would be that abstraction layer, not the underlying chip's native language. Of course, *something* has to be in the native format for the chipset of the machine, but not your user applications.
The NT HAL is there to abstract certain functions that drivers and the kernel need to use regardless of the machine's chipset. It does not provide CPU portability.
That's part of my point. On the AS/400, the abstraction layer *does* provide CPU portability.
And I remember the AS/400, which had a real HAL. Extended to the applications, not just the OS.
On the AS/400, a different processor architecture would not require porting. Replace the HAL, off you go. I have seen it in action, too, we upgraded an AS/400 to a PowerPC from whatever was in the box originally. None of the applications changed at all. Not even a recompile. Just ran.
I have always wondered why MS didnt extend the HAl to everything.
I seem to recall MS talking about how the HAL in NT enabled other underlying platforms. Not an obligation. Marketing? I dont quite know.
I always thought it was part a reining in of Intel, and a way to position themselves ( MS ) to move to other platforms should Intel prove not to be the platform that was going places.
Not elsewhere. The AS/400, for instance, had a true hardware abstraction layer ( HAL ). Dont confuse this with NT's "HAL". On the AS/400, nothing touched the real machine, OS or Apps. In NT, the HAL was *only* for the OS. The Apps had to compile to the underlying actual hardware. If the HAL in NT was there for everything, all the mentioned issues would not have been there.
I am just literate enough in the subject matter to know what SNMP is basically. I have not implemented anything, nor dealt with it in any meaningfull way.
My question is: what is broken about it particularly? I am a programmer, so dont make the answer too "dumbed down".
I did that in my mother's '73 Ford wagon once ( engine died while driving ), got the worst kind of noise as the retaining pawl tried to seat to hold the car from moving ( I was on the freeway doing 60+ ). Thank GOD nothing was damaged, I put it in neutral, got my restart, and continued driving.
What happened to your car when it was put into park? Or did she just put it in neutral?
Slashdot Mirror
Most code that PHB #324 needs will either already have been written, or can be written by someone using a high-level development tool, such as a CDE
:-) ( Yes, more than one instance ).
Really?
How many CDEs are there? I dont know of any practical usefull ones. Maybe tomorrow, not today. And I think this misses a whole point. Fred Brooks' accidentant and essential complexity. In the same way that configuring IP in old school UNIX and Windows NT is different levels of complexity. But the underlying knowledge you have to have about IP doesnt really change, does it? You dont have to remember so much stuff about "this file handles this part, it is there, and the wand needs to be waved thus to change things". But you do need to know on both what does this thing need to do, how do I configure it. The wand waving is the accidental part, that can be minimized. The essestial part is the knowing what the thing does.
As to your calling fewer programming jobs non sequitur, I wonder. Because that is in fact the whole of the point
Short term, I think the GP is probably correct about this. American programmers seem to be losing jobs, but American corporations do seem to be hiring outsourcing firms. Total numbers? I dont know, but I dont know that we can say they are going down now, really. ( and there probably is some outfall of the "bubble" runup, in that there were many people hired as programmers because they could recognize a computer 3 out of 4 times. Those who did not have the real talents will fall out of the pool, but they probably should not have been in in the first place. I personally dont really count those. ).
Long term? You and TFA may have the beginnings of a point, but remember that COBOL brought us the same promise ( that the business people would take the reins and do the "programming". ). That and think about the accidental/essestial complexity I mentioned above. I have yet to meet a business person who understands the issues involved. For example, one thing I keep running into is business people, when relating requirements, who tell me "oh, but you dont have to worry about that, it doesnt happen all that often". But, then, if the application didnt handle that case ( infrequent though it be ) they would be all over me about it. ( dont worry, my app handled it.
Nothing here, move along.
This saving and restoring-- I wonder if the files are changed by this process;
:-)
My understanding is that no change is needed. Also, this is ( in my mind anyway ) confirmed by the change in underlying CPU machine code in an AS/400 upgrade that I performed. No recompilation was required to run once the new CPU was installed, only the machine dependant parts ( TIMI, HAL ) were changed. The tape was suprisingly small that accomplished this. My recollection ( could be mistaken, but I dont think so ) is that the HAL abstracts you away from the underlying hardware, and the OS and Applications all run atop that abstract layer. ( And, I think this is my point: if the HAL in NT did this also, then one "binary" could ship, and the actual CPU in the machien would not be an issue, you would only target that abstract machine layer, not the CPU. )
Either that, or the code was never in native machine language; it was just interpreted on demand like Java bytecode. I guess if the CPU had support to natively execute different instruction sets
The "binary" was not in the CPU's native format, it was in the AS/400's native format, at least the abstracted machines native format. It is kinda like bytecode, conceptually, I guess, but it is a bit different ( and I am trying not to oversimplify
I was operations manager at a shop that had an AS/400 in the early ninties, that is where I learned what I know about them. Stoggy machines in a lot of ways, but they were bullet proof, very easy to keep running and use.
The only kind of abstraction layer I know of that lets you compile into a cpu independent format is a VM...
"The machine survives because the Hardware abstraction layer of its microcode (called TIMI for "Technology Independent Machine Interface" by IBM) allows the operating system and application programs to take advantage of advances in hardware and software without recompilation. This means that a program written and compiled on a S/38 can be run as a native 64 bit program. The HAL allows a system that costs $9000 to run the exact same operating system and software as a $2 million system."
From
this site
so, no I dont think a recompile is needed. As I mentioned in a previous post, a company I worked for upgraded from the old CPU style to a PowerPC based CPU. Different machine languages. The HAL was updated, the machine ran ( faster ), and we did not recompile any of the applications we had written on it.
There is nothing that you could DO with it in user mode...
I dont mean user mode. I understand that. I meant that if the same kind of architecture was in place on a PC as in the AS/400, the user mode applications would not need recompiled due to a change in the underlying CPU ( Intel, Alpha, MIPS, PPC, etc ). The HAL would change, and that would be it.
Upshot would be that you *could* have one "binary" format that would run on any processor architechure that a HAL was available for.
So you DO understand that the NT HAL doesn't provide CPU portability alone?
That was my intial point, that it does not.
If MS had gone the AS/400 route, then many binaries ( those not involved in the HAL ) *would* be interchangable across platforms.
OTOH, the HAL and part of the kernel do provide CPU portability on a source code level...
And I am not talking about at a source code level, but at a deeper level. A completely abstracted machine.
Then say that and dont be sarcastic.
:-)
I agree we need to slow human growth and otherwise learn to me more efficient with the earth we have.
I dont see how that means that space, both near and far will not be *part of* a solution to overcrowding.
I dont agree that we will run out of land and resources before we can send *some* people off to space colonies. At least not if we *begin* sometime soon. If we wait, then yes, we may run out.
Also, there are other benefits to having a human population in space.
A: Catastrophies happening to earth dont wipe out the human race. ( debate on wiping out the human race being a good thing can begin now
B: All the manufacturing that is so polluting here on earth need not be so in space. Not to mention the raw materials that would be available to us without having to damage the earth.
I would guess there are other benefits I am not seeing right now.
So, in my opinion, the solution is
here on the ground,
in near space,
in deep space.
All of the above.
They are doing other bad things, it's OK, dont complain about this one?
The FCC *should* be trying to do the right thing.
Interesting reply. Full of information about why you are right and I am wrong.
Thanks!
The article mentioned that if you dont have a partner station to slow down the craft at the end of the voyage, you simply dont push it up to full speed. Just fast enough to get it there, without it being "catchable" by gravity or the resources available in the craft ( ordinary rockets, or whatever ). Use this "slow mode" to get enough out there to build a catching/relaunching station, then go to full power.
Others have responded with good info. If there were a counter beam, consider that it would not *have* to be aimed at earth. It might be such that both jets form a tangent to the surface of the earth below.
Also, multiple beams at angles to the propulsive beam could be used to keep the attitude adjustment beams from being pointed at earth.
*And*, who says these things need to be in earth orbit? Put them in a Lagrange point somewhere, and let them work from there. Some work would need to be done to keep the beam from pointing at things we want to keep, but it seems that that wouldnt be too hard.
Mix and match as needed.
Nothing says this has to happen in an afternoon.
The NT HAL is for anything in kernel mode. It would be useless to user mode programs.
It doesnt *have* to be only for kernal mode. Granted that would be more work, and probably more overhead.
What you are describing sounds like a VM environment, like Java. It's not
I was trying to describe the abstracted machine layer that the AS/400 provides. No, not like Java.
On an AS/400, there are only two ways to get binary code... Still, binary code does in fact exist....
OK, but my point is that as a compiler writer or whatever, my target properly would be that abstraction layer, not the underlying chip's native language. Of course, *something* has to be in the native format for the chipset of the machine, but not your user applications.
The NT HAL is there to abstract certain functions that drivers and the kernel need to use regardless of the machine's chipset. It does not provide CPU portability.
That's part of my point. On the AS/400, the abstraction layer *does* provide CPU portability.
And I remember the AS/400, which had a real HAL. Extended to the applications, not just the OS.
On the AS/400, a different processor architecture would not require porting. Replace the HAL, off you go. I have seen it in action, too, we upgraded an AS/400 to a PowerPC from whatever was in the box originally. None of the applications changed at all. Not even a recompile. Just ran.
I have always wondered why MS didnt extend the HAl to everything.
Read with the parent title, then mod this funny.
I seem to recall MS talking about how the HAL in NT enabled other underlying platforms. Not an obligation. Marketing? I dont quite know.
I always thought it was part a reining in of Intel, and a way to position themselves ( MS ) to move to other platforms should Intel prove not to be the platform that was going places.
Not elsewhere. The AS/400, for instance, had a true hardware abstraction layer ( HAL ). Dont confuse this with NT's "HAL". On the AS/400, nothing touched the real machine, OS or Apps. In NT, the HAL was *only* for the OS. The Apps had to compile to the underlying actual hardware. If the HAL in NT was there for everything, all the mentioned issues would not have been there.
Will not hate them as long as they continue to not be evil.
I have long thought that a company could do "good" and do "well". I am glad to see them do both successfull ( AFAIK, anyway... )
Search for your *thang*?
I mean no real offence, it was just too much to pass up!
That Walmart is death?
Written by:
William Stevenson, Ivy Jo Hunter, Marvin Gaye.
© Jobete Music Co. Inc. ASCAP/Stone Agate Music Division BMI
All Rights Reserved.
*covered* by Van Halen, amoung others.
I am just literate enough in the subject matter to know what SNMP is basically. I have not implemented anything, nor dealt with it in any meaningfull way.
My question is: what is broken about it particularly? I am a programmer, so dont make the answer too "dumbed down".
Genuinely curious.
Thanks,
David
Cause you didnt heed #1. Or #2, for that matter.
I dont hate managers, but I gotta tell you, mlh hit the nail *right* on the head.
From the listening will come many many concrete steps.
No. Only some have it.
It's hard to spend quality time with billions of children. Some dont turn out just like I want.
Sorry. I'll work on that.
Yeah, thats the ticket.
She shifted into park? While the car was moving?
I did that in my mother's '73 Ford wagon once ( engine died while driving ), got the worst kind of noise as the retaining pawl tried to seat to hold the car from moving ( I was on the freeway doing 60+ ). Thank GOD nothing was damaged, I put it in neutral, got my restart, and continued driving.
What happened to your car when it was put into park? Or did she just put it in neutral?
How about an uninterested third party does the inspections? Renault has a motive for not finding anything, and for burying it deep if they do.