Re:Nope, it's the putative new users problem
on
Linux Needs Critics
·
· Score: 1
If you'd pay the projects to combine, I'm sure most of them would be willing. If nobody does, they'll do what they find most interesting.
I'm frankly surprised that it's worked out anywhere NEAR as well as it has. I didn't believe that it ever would. And I switched anyway because I despised the new EULA that MS was trying to foist on me.
Re:Nope, it's the putative new users problem
on
Linux Needs Critics
·
· Score: 1
But they will spend money to get the new version of MSWind? And the new hardware that it requires?
Yes, I understand it as being a valid problem, but if I can't do anything about it, then I can't do anything about it. And in that case, I've got enough problems that I *can* work on.
I do understand about there being valid reasons for not switching. I've still got an MSWind95 box, because of software lock-in. What that taught me is that software lock-in is to be avoided. When people refuse to learn that...I can't accept their problems as my own. It's their choice. I can advise, but that's about as far as I'll go. If they're someone close, I'll look for ways around the problem. For my wife I'll search diligently over a period of years. (And sometimes there doesn't seem to be an acceptable solution.)
But I *KNOW* that eventually my MSWind95 box will die. And it can't even be installed on new hardware. So any captive data is doomed, unless it escapes before then.
I've got a Mac that has Finale on it. Linux Music Score editors just aren't good enough. One can't control the appearance of the score printout. (OK. Possibly if you hand-edit Lilypad files you can. That's not an acceptable answer.) I'm currently looking for a good solution, and I have been for years. Now...I'm preparing to export the Finale files into etf format, and transfer those over to a Linux system. Then those can be run through etf2ly and the work is saved. But the editing is done in Finale, because there's no acceptable program on Linux. Which means that I've got to keep a Mac system viable. (And license changes mean it's a Mac system from a year or two ago.)
So it *IS* my problem. I've got quasi-answers in lots of special cases. And I recognize that real answers are legally prohibited. When people don't realize that, they blame developers for problems with another source. The only real answer is to refuse to use programs that lock their data behind impenetrable walls...and it doesn't matter whether the obstacles are technical or legal. But lots of people don't want to hear that answer. Sorry. There's lots of features about reality that I'm not to fond of myself.
State's Rights meant a lot more than being pro-slavery, but if you *were* pro-slavery, and the central authority was against it, you pretty much had to peg your opposition on State's Rights.
States' Rights was recognized by the original constitution. Read the 10th amendment. The current interpretation is quite strained, and is basically illegitimate...but was adopted because the feds wanted to do something and had sufficient support in the Supreme Court to ram-rod through a basically idiotic interpretation. This happened not just once, but several times. All parties have participated in this. Adapting the Constitution to work in modern society would require several amendments that haven't ever been made, but have just been sort of accepted via a silly interpretation of the existing text...and then validated by the Supreme Court.
If you want to consider how this might come to pass, consider the current status of presidential signing statements, and how they might come to be considered legitimate.
It's also true that the original framers of the constitution believed that the Constitution would prohibit the feds from abolishing slavery. They weren't all in favor of this, but it was necessary for them to get enough support to get the document approved. THEY were certainly strong supporters of State's Rights. Most of them wanted a central government just barely strong enough to construct a unified trade area. (Some disagreed, and essentially wanted a monarchy. But they were far from the majority.)
That's the wrong old school. The one you should be looking at is the dongle.
A usb stub (pass-though, so you can just leave it installed and still use the port) would probably be acceptable to most people. It could be pretty cheap and not draw a noticeable amount of power. It would be like requiring the CD, but less inconvenient to use and harder to duplicate.
I'll admit I hated the dongles, but not so much that I tended to boycott products. DRM as it exists is something that causes me to just avoid buying things. But it damned well better not get the reputation of either being fragile or causing systems to break, or I'll avoid it, just as I avoid DRM.
I'd heard that some DRM ran as a daemon. And consumed cycles in the background even if you weren't using anything related to it. Could be wrong, of course, but it sure sounds reasonable.
Waldos were first used to handle hot things inside nuclear power plants. Since then they've expanded their capabilities and uses. But until now they haven't been mentally controlled. (And I'm not certain that this counts...but it's sure getting a lot closer.)
The generic term is telefactor. Waldo is the name given to tele-operated hands. (And as I recall that's how "Waldo" in the story "Waldo" used the items.)
Maybe the specs for robots.txt should be changed to require a robots ALLOW configuration, and the requirement for that be phased in? That would get rid of these pinhead complainers. (And this is a problem that seems to keep recurring whenever some new PHB thinks he sees a new way to make money.)
Yes, it was a great print server. It was also a decent file server. And it had a few other nice capabilities. But it was basically limited. And it tended to develop problems that were quite difficult to diagnose.
If all you want is a print server, then Netware might be a good choice. Perhaps. (Which version?) But it wasn't very flexible. I suspect the basic design was designed to fit on an 8-bit computer, and then retrofitted for 16-bit machines. This would mean lots of ad hoc patches, even going from an 8088 to an 8086.
In that case there are other options. BeOS might be a good choice. They could fork the open version of that and have a "nearly working" system instantly, with some software already available. They'd need to train all their developers and maintenance people, but this would guarantee that the knowledge remained restricted.
And while Netware was rather secure, it was also rather limited in capability. BeOS would be a better place to start. And since it's only "a place to start", there would be NO collection of knowledge outside of the agency (and it's ex-employees).
I think they're better off, though, with Linux. The one that the NSA made secure modifications to. (The ones that are so complex that nobody else uses them properly.)
...As another commenter points out above, neither this, nor the US's first amendment, are apt to shield defamers from litigation....
Please, alleged defamers. The problem occurs because of the international scope of this law, and that it can be excessively expensive to defend against charges brought with minimal expense and without significant danger of retribution in an form. And as far as most of the likely victims of this assault, most of them will probably be innocent of any malice, and often innocent of factual mistakes. But unable to afford a lengthy international trip for the sole purpose of defending themselves against merit-less claims.
And if you ISP has business dealings within the UK, or is contemplating doing so at some time in the future? The law applies not only to you, but also to your ISP. Think they'll go out on a limb for you?
That's an actual result of the law, but not one of the major drawbacks. Only a minor one.
The major one that I'm aware of IS the internet. If you post something on the internet, it's considered published everywhere. And that means in Britain. So you could publish something that seems to you, living in, say, Peru, totally non-controversial and obviously true. You may need to defend yourself in Britain. Where you barely speak the language. And where the cost of a lawyer is, to you, truly exorbitant. But so is the cost of just traveling to Britain, if you can even get a Visa. So you're automatically guilty, because you can't defend yourself. And they informed you by mail, so the trial was already over before you heard about it. (Well, maybe that wouldn't happen.)
This seems like a truly vile law. Possibly unintentionally so, but nonetheless vile. And the low barrier to attacks, and small danger from making them, means that it will be frequently abused by people with little reason.
Think of it as a technique for deploying distributed censorship attacks.
Or doesn't want to bother proving. The goals and motives of your ISP are not your goals and motives. And the risks they will take on your behalf are very strictly limited. They'll be much more ready to expose you to risks on their behalf.
Merely having to pay a lawyer means that you've already lost. Merely having to take the time to defend yourself is already a cost that will not be recompensed, and definitely not at a fair rate.
When it's cheap and safe for someone to mount an attack, one can expect many to mount attacks for relatively little reason. Even if they don't win, they can still force the other to lose.
A theory isn't required to prove that it's the only possible explanation, merely that everything that it predicts matches observation. For that matter one CAN'T prove that there's only one explanation. Solipsism is an alternative explanation for everything. So is that we're living in a virtual reality. You can't distinguish between the predictions of those two theories.
Thus, I believe the earth is round. I don't know it. Knowledge refers to direct observations. Belief to the stories by which those observations are made into a coherent picture.
A nice piece of evidence that both the Earth and Luna are spheres (approximately) is the shape of the shadow that the earth casts on the moon. And the way it doesn't change during the night. There may be other explanations, of course, but most of them would seem a bit strange to me.
It's not just a matter of "can't afford". When the RIAA have been challenged on specific points they have frequently been proven not merely wrong, but wrong without a valid reason to have made the assertion in question. AND to have used illegal methods in deriving their bat-shit crazy result.
What can you say about an organization that sues people who have been dead for years, and grandmothers that have never even owned a computer, for abusing the computer?
My guess is they just got tired of trying to prove obviously fallacious cases, so they decided to use an approach that didn't allow people to challenge their assertions.
It's a bit absurd to call AT&T a private business. They're a regulated monopoly. (Not very heavily regulated, admittedly. Mainly the regulations prevent any competitors from entering the business.)
Paying well is no insurance against *this* kind of garbage. People who do this need to be vulnerable to impressive penalties when they so unreasonably exceed reasonable bounds. And slightly less when they are less unreasonable.
For this I'm not quite sure what would be appropriate. Firing without recommendation or severance pay, definitely. Probably also massive fines. I'm not sure about jail time.
Also "prescription strength ibuprofen"!!! Incredible! The supervisors of whoever ordered this should also be fired immediately. And probably their supervisors, too.
My suspicion is that religion is still around because it's built in as a bias of belief. And that there are MANY other such biases. Naturally, most such won't be realized as such, because they are uniformly believed by almost everyone. Religion is special because it was designed to keep various tribes moving away from each other, so it came with a built-in tendency towards schisms, which create contrast that allows the other people's beliefs to be seen as illogical. (Some of those are active in governments, too.)
If you want a real example of a bronze age idea that is kept alive, what about the existence of objects? It's a useful idea, but it's certainly a false one. Or how about "self". There's no such thing as a self, but everyone instinctively believes that they are one. But no "self" is persistent for more than a few minutes (and even then it's changing dynamically as it goes). Note that even though I write this, I do it from knowledge, not from belief. I still belief that I'm a persistent self, even though I know it's an illusion. I'm not the self I was yesterday. I don't have the same emotions. I don't have the same ideas. I don't have the same memories (though there's a fairly large overlap there...probably).
I programmed for 7094 FAP assembly for around a decade. Then I switched to mainly Fortran plus a small bit of SCOPE assembler (CDC 6400/6600/7600). After that I'd learned my lesson. Stay away from assembler except when it's forced. The efficiencies aren't worth the other costs. Except occasionally.
The purpose of recommending virtual assemblers is to demonstrate how an assembler works in an environment that is well protected. It's for teaching the underlying principles. For that a virtual assembler is sufficient. And you don't want to be using an assembler for any other reason unless there's a clear and prolonged need.
You're right that VM assembler doesn't have much job potential. Neither does *ANY* assembler work at the entry level. And not usually at the advanced level. Only in a very few very specific cases.
If he were that drawn to assembler, drawn enough to be the kind of programmer that wanted to work down at the metal, he wouldn't be asking about this when he was near graduation. And for most programmers it's a bad idea. Learning LISP or Forth would be a better choice. But to learn the basic principles, learning a virtual machine that's simple enough that it COULD be implemented in hardware is superior. Which is why I recommended the Parrot machine over the Java VM. Parrot code is simpler. (Yes, a JVM *has* been implemented in metal. Parrot is simpler. So has Forth, but that's not an argument for learning a Forth assembler, even though it would yield actual assembly code. It doesn't teach the right principles...it instead presumes that you already know them, and twists the code generation in ways that aren't normal (unless you're a Forth programmer.)
For that matter, you may have noticed that I didn't recommend that he learn Postscript. It's a simple language well implemented in hardware. But it doesn't teach what one is learning an assembler language to learn. Parrot code teaches about accumulating values in registers, storing registers in memory, storing temporary variable on the stack, testing flags, and all the other basic tricks that an assembler is supposed to teach. And the design of the machine is highly symmetric. Making it simple to learn. (This is all theoretic, based on a casual inspection, not based on actual learning.)
I down-graded MIX because it emphasizes optimizing storage management and compaction. These aren't anywhere as important now as they were when the machine was designed. Even embedded machines now have more memory that a sizable processor did then. It's more important to write simple code than to pack multiple flags into one byte.
That was excellent advice for the earlier generations of processors. I'm not convinced that it's a good idea now. But something similar could be achieved: Learn to write programs in JVM machine code.
Or Parrot. Or Python Virtual Machine. Or MIX, even.
Actually, Mix might be the best, but it's a bit more limited. But modern processors are too complicated for this to be a useful learning tool, and you don't want to REALLY start assembly language programming. A new generation of processors will break everything you've ever written.
For the purpose, Parrot machine code would probably be best. JVM the most useful.
OTOH, you might also consider LUA. It's not a great language, per se, but it's an excellent adjunct to C or C++.
Part of the problem is that there are a number of directions to go, and a limited amount of time. You really NEED to learn some sort of assembler, and for that I would recommend Parrot. It looked like a reasonably simple code, and reasonably well documented. But I'm not sure that this is the right time.
An alternative is to pick a language and start learning to use it's standard libraries and how to manipulate files. (When I was in college, I never got taught how to use files, and I regretted this for years, until I had backfilled the knowledge on my on time.) If you pick C++ STAY AWAY FROM TEMPLATES!! That's advanced work. (Yeah, use them for simple generics, but don't do anything fancy. They only exist to make your life simpler. Once they stop doing that, avoid them.) I can't give any comparable advice for C. In C and C++ both you need to restrain your use of macros and pointers. Prefer arrays over pointers. Prefer references over pointers. (And acknowledge that sometimes they are necessary evils...but they remain evil.)
My advice against pointers is symmetric to the standard advice against program jumps (AKA "Go to considered harmful") and in favor of structured programming (i.e., while loops, do loops, and function calls). I'm not sure that structured programming is even mentioned anymore as it's become so dominant. The same reasons it became dominant argue against the use of pointers. (You'll note that Java essentially eliminated the use of pointers. It's a [slightly] more recent design than C++, and not as close to the metal. But the efficiency cost of Java was more due to garbage collection and a virtual machine than it was to the elimination of pointers. [E.g., see Digital Mars D, which is about as efficient as C++, but severely limits the need for pointers.])
P.S.: Re:
Many of the current commercial languages belong in toyland. They are designed for programmers who really don't have any idea about managing resources efficiently.
That's a really obnoxious attitude. Different languages are designed for different situations. If you're writing code in a hurry, you don't want to worry about lots of unnecessary fiddling details that would be very important if you had plenty of time and really needed to optimize execution. So you'd use different languages. If you use C where you should use Ruby, everyone will be very unhappy with you, and likewise for the converse. Actually, I think that C is almost always the wrong choice. Most work that's done in C should really have been done in Ada...but the people doing it already knew C, and it was "good enough", so that's what they used. Don't ever, however, make the mistake that this prove that it was optimal. (Except in the sense of the costs of causing the programmer to learn a new language.) Ada would even often be a better choice in places where C++ is chosen, though less frequently. With Java the division is less clear cut. Where Java is used because the programmer didn't know C or C++, then the same comments apply. In many other cases, however, Java is a better choice. (Java is less efficient, but it has dynamic capabilities that are very difficult to manage in Ada.
Things get more complicated when you start to include complex libraries, such as Lua. In that case C + Lua is frequently a superior choice to Ada...because Lua interacts better with C and is only used when a bit of dynamic behavior is appropriate.
Slashdot Mirror
If you'd pay the projects to combine, I'm sure most of them would be willing. If nobody does, they'll do what they find most interesting.
I'm frankly surprised that it's worked out anywhere NEAR as well as it has. I didn't believe that it ever would. And I switched anyway because I despised the new EULA that MS was trying to foist on me.
But they will spend money to get the new version of MSWind? And the new hardware that it requires?
Yes, I understand it as being a valid problem, but if I can't do anything about it, then I can't do anything about it. And in that case, I've got enough problems that I *can* work on.
I do understand about there being valid reasons for not switching. I've still got an MSWind95 box, because of software lock-in. What that taught me is that software lock-in is to be avoided. When people refuse to learn that...I can't accept their problems as my own. It's their choice. I can advise, but that's about as far as I'll go. If they're someone close, I'll look for ways around the problem. For my wife I'll search diligently over a period of years. (And sometimes there doesn't seem to be an acceptable solution.)
But I *KNOW* that eventually my MSWind95 box will die. And it can't even be installed on new hardware. So any captive data is doomed, unless it escapes before then.
I've got a Mac that has Finale on it. Linux Music Score editors just aren't good enough. One can't control the appearance of the score printout. (OK. Possibly if you hand-edit Lilypad files you can. That's not an acceptable answer.) I'm currently looking for a good solution, and I have been for years. Now...I'm preparing to export the Finale files into etf format, and transfer those over to a Linux system. Then those can be run through etf2ly and the work is saved. But the editing is done in Finale, because there's no acceptable program on Linux. Which means that I've got to keep a Mac system viable. (And license changes mean it's a Mac system from a year or two ago.)
So it *IS* my problem. I've got quasi-answers in lots of special cases. And I recognize that real answers are legally prohibited. When people don't realize that, they blame developers for problems with another source. The only real answer is to refuse to use programs that lock their data behind impenetrable walls...and it doesn't matter whether the obstacles are technical or legal. But lots of people don't want to hear that answer. Sorry. There's lots of features about reality that I'm not to fond of myself.
State's Rights meant a lot more than being pro-slavery, but if you *were* pro-slavery, and the central authority was against it, you pretty much had to peg your opposition on State's Rights.
States' Rights was recognized by the original constitution. Read the 10th amendment. The current interpretation is quite strained, and is basically illegitimate...but was adopted because the feds wanted to do something and had sufficient support in the Supreme Court to ram-rod through a basically idiotic interpretation. This happened not just once, but several times. All parties have participated in this. Adapting the Constitution to work in modern society would require several amendments that haven't ever been made, but have just been sort of accepted via a silly interpretation of the existing text...and then validated by the Supreme Court.
If you want to consider how this might come to pass, consider the current status of presidential signing statements, and how they might come to be considered legitimate.
It's also true that the original framers of the constitution believed that the Constitution would prohibit the feds from abolishing slavery. They weren't all in favor of this, but it was necessary for them to get enough support to get the document approved. THEY were certainly strong supporters of State's Rights. Most of them wanted a central government just barely strong enough to construct a unified trade area. (Some disagreed, and essentially wanted a monarchy. But they were far from the majority.)
That's the wrong old school. The one you should be looking at is the dongle.
A usb stub (pass-though, so you can just leave it installed and still use the port) would probably be acceptable to most people. It could be pretty cheap and not draw a noticeable amount of power. It would be like requiring the CD, but less inconvenient to use and harder to duplicate.
I'll admit I hated the dongles, but not so much that I tended to boycott products. DRM as it exists is something that causes me to just avoid buying things. But it damned well better not get the reputation of either being fragile or causing systems to break, or I'll avoid it, just as I avoid DRM.
I'd heard that some DRM ran as a daemon. And consumed cycles in the background even if you weren't using anything related to it. Could be wrong, of course, but it sure sounds reasonable.
Waldos were first used to handle hot things inside nuclear power plants. Since then they've expanded their capabilities and uses. But until now they haven't been mentally controlled. (And I'm not certain that this counts...but it's sure getting a lot closer.)
The generic term is telefactor. Waldo is the name given to tele-operated hands. (And as I recall that's how "Waldo" in the story "Waldo" used the items.)
Maybe the specs for robots.txt should be changed to require a robots ALLOW configuration, and the requirement for that be phased in? That would get rid of these pinhead complainers. (And this is a problem that seems to keep recurring whenever some new PHB thinks he sees a new way to make money.)
Yes, it was a great print server. It was also a decent file server. And it had a few other nice capabilities. But it was basically limited. And it tended to develop problems that were quite difficult to diagnose.
If all you want is a print server, then Netware might be a good choice. Perhaps. (Which version?) But it wasn't very flexible. I suspect the basic design was designed to fit on an 8-bit computer, and then retrofitted for 16-bit machines. This would mean lots of ad hoc patches, even going from an 8088 to an 8086.
In that case there are other options. BeOS might be a good choice. They could fork the open version of that and have a "nearly working" system instantly, with some software already available. They'd need to train all their developers and maintenance people, but this would guarantee that the knowledge remained restricted.
And while Netware was rather secure, it was also rather limited in capability. BeOS would be a better place to start. And since it's only "a place to start", there would be NO collection of knowledge outside of the agency (and it's ex-employees).
I think they're better off, though, with Linux. The one that the NSA made secure modifications to. (The ones that are so complex that nobody else uses them properly.)
ssh? Sorry. Maybe it should have been ssl.
But do remember, even Debian can make mistakes. Think ssh.
...As another commenter points out above, neither this, nor the US's first amendment, are apt to shield defamers from litigation. ...
Please, alleged defamers. The problem occurs because of the international scope of this law, and that it can be excessively expensive to defend against charges brought with minimal expense and without significant danger of retribution in an form. And as far as most of the likely victims of this assault, most of them will probably be innocent of any malice, and often innocent of factual mistakes. But unable to afford a lengthy international trip for the sole purpose of defending themselves against merit-less claims.
And if you ISP has business dealings within the UK, or is contemplating doing so at some time in the future? The law applies not only to you, but also to your ISP. Think they'll go out on a limb for you?
That's an actual result of the law, but not one of the major drawbacks. Only a minor one.
The major one that I'm aware of IS the internet. If you post something on the internet, it's considered published everywhere. And that means in Britain. So you could publish something that seems to you, living in, say, Peru, totally non-controversial and obviously true. You may need to defend yourself in Britain. Where you barely speak the language. And where the cost of a lawyer is, to you, truly exorbitant. But so is the cost of just traveling to Britain, if you can even get a Visa. So you're automatically guilty, because you can't defend yourself. And they informed you by mail, so the trial was already over before you heard about it. (Well, maybe that wouldn't happen.)
This seems like a truly vile law. Possibly unintentionally so, but nonetheless vile. And the low barrier to attacks, and small danger from making them, means that it will be frequently abused by people with little reason.
Think of it as a technique for deploying distributed censorship attacks.
Or doesn't want to bother proving. The goals and motives of your ISP are not your goals and motives. And the risks they will take on your behalf are very strictly limited. They'll be much more ready to expose you to risks on their behalf.
Merely having to pay a lawyer means that you've already lost. Merely having to take the time to defend yourself is already a cost that will not be recompensed, and definitely not at a fair rate.
When it's cheap and safe for someone to mount an attack, one can expect many to mount attacks for relatively little reason. Even if they don't win, they can still force the other to lose.
A theory isn't required to prove that it's the only possible explanation, merely that everything that it predicts matches observation. For that matter one CAN'T prove that there's only one explanation. Solipsism is an alternative explanation for everything. So is that we're living in a virtual reality. You can't distinguish between the predictions of those two theories.
Thus, I believe the earth is round. I don't know it. Knowledge refers to direct observations. Belief to the stories by which those observations are made into a coherent picture.
A nice piece of evidence that both the Earth and Luna are spheres (approximately) is the shape of the shadow that the earth casts on the moon. And the way it doesn't change during the night. There may be other explanations, of course, but most of them would seem a bit strange to me.
It's not just a matter of "can't afford". When the RIAA have been challenged on specific points they have frequently been proven not merely wrong, but wrong without a valid reason to have made the assertion in question. AND to have used illegal methods in deriving their bat-shit crazy result.
What can you say about an organization that sues people who have been dead for years, and grandmothers that have never even owned a computer, for abusing the computer?
My guess is they just got tired of trying to prove obviously fallacious cases, so they decided to use an approach that didn't allow people to challenge their assertions.
It's a bit absurd to call AT&T a private business. They're a regulated monopoly. (Not very heavily regulated, admittedly. Mainly the regulations prevent any competitors from entering the business.)
I think he was talking about scatter-spectrum wireless. Or possibly a sort of grid-net.
Remember, he said, specifically, "it can't be metered".
Paying well is no insurance against *this* kind of garbage. People who do this need to be vulnerable to impressive penalties when they so unreasonably exceed reasonable bounds. And slightly less when they are less unreasonable.
For this I'm not quite sure what would be appropriate. Firing without recommendation or severance pay, definitely. Probably also massive fines. I'm not sure about jail time.
Also "prescription strength ibuprofen"!!! Incredible! The supervisors of whoever ordered this should also be fired immediately. And probably their supervisors, too.
My suspicion is that religion is still around because it's built in as a bias of belief. And that there are MANY other such biases. Naturally, most such won't be realized as such, because they are uniformly believed by almost everyone. Religion is special because it was designed to keep various tribes moving away from each other, so it came with a built-in tendency towards schisms, which create contrast that allows the other people's beliefs to be seen as illogical. (Some of those are active in governments, too.)
If you want a real example of a bronze age idea that is kept alive, what about the existence of objects? It's a useful idea, but it's certainly a false one. Or how about "self". There's no such thing as a self, but everyone instinctively believes that they are one. But no "self" is persistent for more than a few minutes (and even then it's changing dynamically as it goes). Note that even though I write this, I do it from knowledge, not from belief. I still belief that I'm a persistent self, even though I know it's an illusion. I'm not the self I was yesterday. I don't have the same emotions. I don't have the same ideas. I don't have the same memories (though there's a fairly large overlap there...probably).
I programmed for 7094 FAP assembly for around a decade. Then I switched to mainly Fortran plus a small bit of SCOPE assembler (CDC 6400/6600/7600). After that I'd learned my lesson. Stay away from assembler except when it's forced. The efficiencies aren't worth the other costs. Except occasionally.
The purpose of recommending virtual assemblers is to demonstrate how an assembler works in an environment that is well protected. It's for teaching the underlying principles. For that a virtual assembler is sufficient. And you don't want to be using an assembler for any other reason unless there's a clear and prolonged need.
You're right that VM assembler doesn't have much job potential. Neither does *ANY* assembler work at the entry level. And not usually at the advanced level. Only in a very few very specific cases.
If he were that drawn to assembler, drawn enough to be the kind of programmer that wanted to work down at the metal, he wouldn't be asking about this when he was near graduation. And for most programmers it's a bad idea. Learning LISP or Forth would be a better choice. But to learn the basic principles, learning a virtual machine that's simple enough that it COULD be implemented in hardware is superior. Which is why I recommended the Parrot machine over the Java VM. Parrot code is simpler. (Yes, a JVM *has* been implemented in metal. Parrot is simpler. So has Forth, but that's not an argument for learning a Forth assembler, even though it would yield actual assembly code. It doesn't teach the right principles...it instead presumes that you already know them, and twists the code generation in ways that aren't normal (unless you're a Forth programmer.)
For that matter, you may have noticed that I didn't recommend that he learn Postscript. It's a simple language well implemented in hardware. But it doesn't teach what one is learning an assembler language to learn. Parrot code teaches about accumulating values in registers, storing registers in memory, storing temporary variable on the stack, testing flags, and all the other basic tricks that an assembler is supposed to teach. And the design of the machine is highly symmetric. Making it simple to learn. (This is all theoretic, based on a casual inspection, not based on actual learning.)
I down-graded MIX because it emphasizes optimizing storage management and compaction. These aren't anywhere as important now as they were when the machine was designed. Even embedded machines now have more memory that a sizable processor did then. It's more important to write simple code than to pack multiple flags into one byte.
That was excellent advice for the earlier generations of processors. I'm not convinced that it's a good idea now. But something similar could be achieved:
Learn to write programs in JVM machine code.
Or Parrot. Or Python Virtual Machine. Or MIX, even.
Actually, Mix might be the best, but it's a bit more limited. But modern processors are too complicated for this to be a useful learning tool, and you don't want to REALLY start assembly language programming. A new generation of processors will break everything you've ever written.
For the purpose, Parrot machine code would probably be best. JVM the most useful.
OTOH, you might also consider LUA. It's not a great language, per se, but it's an excellent adjunct to C or C++.
Part of the problem is that there are a number of directions to go, and a limited amount of time. You really NEED to learn some sort of assembler, and for that I would recommend Parrot. It looked like a reasonably simple code, and reasonably well documented. But I'm not sure that this is the right time.
An alternative is to pick a language and start learning to use it's standard libraries and how to manipulate files. (When I was in college, I never got taught how to use files, and I regretted this for years, until I had backfilled the knowledge on my on time.) If you pick C++ STAY AWAY FROM TEMPLATES!! That's advanced work. (Yeah, use them for simple generics, but don't do anything fancy. They only exist to make your life simpler. Once they stop doing that, avoid them.)
I can't give any comparable advice for C. In C and C++ both you need to restrain your use of macros and pointers. Prefer arrays over pointers. Prefer references over pointers. (And acknowledge that sometimes they are necessary evils...but they remain evil.)
My advice against pointers is symmetric to the standard advice against program jumps (AKA "Go to considered harmful") and in favor of structured programming (i.e., while loops, do loops, and function calls). I'm not sure that structured programming is even mentioned anymore as it's become so dominant. The same reasons it became dominant argue against the use of pointers. (You'll note that Java essentially eliminated the use of pointers. It's a [slightly] more recent design than C++, and not as close to the metal. But the efficiency cost of Java was more due to garbage collection and a virtual machine than it was to the elimination of pointers. [E.g., see Digital Mars D, which is about as efficient as C++, but severely limits the need for pointers.])
P.S.: Re:
Many of the current commercial languages belong in toyland. They are designed for programmers who really don't have any idea about managing resources efficiently.
That's a really obnoxious attitude. Different languages are designed for different situations. If you're writing code in a hurry, you don't want to worry about lots of unnecessary fiddling details that would be very important if you had plenty of time and really needed to optimize execution. So you'd use different languages. If you use C where you should use Ruby, everyone will be very unhappy with you, and likewise for the converse. Actually, I think that C is almost always the wrong choice. Most work that's done in C should really have been done in Ada...but the people doing it already knew C, and it was "good enough", so that's what they used. Don't ever, however, make the mistake that this prove that it was optimal. (Except in the sense of the costs of causing the programmer to learn a new language.) Ada would even often be a better choice in places where C++ is chosen, though less frequently. With Java the division is less clear cut. Where Java is used because the programmer didn't know C or C++, then the same comments apply. In many other cases, however, Java is a better choice. (Java is less efficient, but it has dynamic capabilities that are very difficult to manage in Ada.
Things get more complicated when you start to include complex libraries, such as Lua. In that case C + Lua is frequently a superior choice to Ada...because Lua interacts better with C and is only used when a bit of dynamic behavior is appropriate.