While you're accurately describing the situation today, it need not stay this way. There are some very interesting projects, out in academia, which might address this very important issue.
Take a look at "slim binaries" and "Dynamic Code Reoptimizers" here for a starting point.
The interesting aspect to this, from a social and economic perspective, is that it is projects like this which could reduce the benefit of any existing monopolistic position on the desktop. Given this, I'm somewhat saddened that these ideas haven't been picked up by companies like SUN or communities like Linux. Perhaps this really isn't ready for 'prime time', but cash and interest from SUN could go a long way to aiding this work.
Intel would also gain from this. As you've pointed out, software tends to be optimized towards the least common denominator of hardware. That eliminates much of the advantage of newer architectures. Techniques such as these would increase the incentive for hardware upgrades, as existing softwares' performance would be immediately improved.
I suppose that I was insufficiently clear. I know that the FAA has no jurisdiction in international airspace. But we were discussing ROW rules, and I thought it useful to add a little real information on how those rules are expressed, in one (large) jurisdiction.
Also, the fact that Chinese airspace is not required to follow FAA rules is irrelevent. That airspace was not violated until after the incident occurred.
When discussing international airspace, one must consider ICAO rules/agreements (www.icao.org). However, I'm not especially familiar with these. I've read elsewhere, though, that an agreement amongst parties including China provides for aircraft in distress landing as necessary.
But by FAA rules, size of aircraft is not a factor in determining right of way. For fixed wing aircraft with neither under distress, the vehicles are considered equivilent (there are distinctions drawn, but only when adding airships, gliders, etc. to the equation).
For a situation where one aircraft is overtaking another, the vehicle being overtaken has the right of way. But one could use this to draw stupid scenarios. For example, the chinese fighter could move ahead of the P-3, and then decelerate. In that case, it would be the responsibility of the P-3 to avoid the fighter (by passing to the right, if we're going to stay pedantic {8^).
See FAR 91.113.
But this is really silly. A few months ago, I was on a collision course with another aircraft. I had the right of way. But he wasn't moving (likely hadn't noticed me).
I avoided him.
I'd rather that than argue ROW rules to death.
Of course, the Chinese pilot was already violating FAA rules. Specifically, 91.111.b states that formation flying requires arrangement with each of the involved pilots.
And what is wrong with thinking of each object as "an independent little program"? Such reasoning serves a person well in a distributed or multithreaded programming environment.
But your posting is exactly the sort of thinking that, as an educator, I have to work out of many people with prior programming experience. Your "from the ground up" approach puts an emphasis on implementation instead of interface. This yields a tendency to discuss pieces of "how" before knowing all of the "what" or "why".
Obviously, a programmer needs to be concerned about implementation details. But these tend to come very late in the process, for successful projects.
Of course, there are exceptions. Real time or embedded systems, for example, have as a part of their description what would normally be considered low level details (ie. memory management). But these can be taught later, perhaps after circuit design and assembler classes have explained the building blocks involved.
But perhaps we're begging the question of "what is the CS program to produce?" Is the goal to produce programmers, or to produce software engineers? I generally view the goal as the latter.
Actually, a CS program could probably move in either direction: from circuits up, or from concepts down. I'd tend to choose the later, simply because a greater number of engineers work at high levels than low.
But the final result should be the same in either case. The program should yield professionals that can discover requirements, synthesize designs, and produce implementations. They should be equipped with a wide array of "tools" towards these goals, including understandings of algorithms, proofs, sets, concurrency, resource management, various forms of decomposition and design (ie. OO, functional, procedural, etc.), and so on.
When you look at it this way, it actually becomes less important where you start the students, and more important how you fit it all in.
I agree and disagree with both of you. Having taught beginners, both at the University and corporate levels, I've come to two conclusions.
OO, taught properly, is *easy*. It is not terribly different from how most people operate in the real world, after all. Everyone classifies via similarities and differences. Everyone abstracts away the "unimportant" details. Everyone groups. And so on.
It's just a matter of identifying what people do in the real world, and mapping this back to OO concepts. I still recall Booch's cat diagrams, for example.
On the other hand, I find Java to have too rich a syntax to make a good first language. It's too easy to get bogged down in details there, which costs time spent on the concepts.
For one small example, consider a class method. I'd rather teach this second, and object methods first. Yet, in Java, one cannot build a program w/o a static main().
So instead, one teaches class methods first. But now one must describe the "static" keyword as "magic" to be explained later.
And that is a second example. An ideal first language would have a syntax that permits the first program to be built with a minimum of constructs.
Unfortunately, the myth of "point n click" administration has been deeply embedded within the corporate consciousness. A side effect is the belief that "MS" administrators are cheaper, as the job is easier.
Fortunately, I think that this myth is dying. All of our production machines are, and the primary target of our development efforts is, UNIX. It used to be I'd get puzzled looks when I explained that this was to keep costs down. Now, I get understanding agreement.
I won't argue that installing a blank password isn't bad. It is.
But so what? Your DB shouldn't be accessible to outsiders anyway. It should be "hidden" somewhere unreachable, preferably in nonroutable space (RFC1918). Your applications need to reach it. Outsiders don't.
Of course, using UNIX is no magic solution. I know of a company that deals (if they still exist) with *money* in their DB. The child DBA installed Sybase on a public IP and left the password blank. That he did this on a Solaris box didn't make a difference; it was still stupid.
Needless to say, they didn't bother with a firewall.
Back to your message: hardcoding *any* password is an invitation to problems. I know of a different company that had a password hardcoded throughout their software. This was a password which provided login access to the web servers (among other things). Of course, an ex-employee of reduced morals exploited this and gave them a nice "rm -rf/" to consider.
It wasn't the root password, so it didn't kill everything. But it took out all of their application software.
They'd have changed the password more often, but "it was too hard" to do so because it was encoded all over the place.
We won't even discuss the wisdom of how this company organized their file ownerships and access rights.
So the blank password is really a red herring. Access to the DB from outside is wrong. Hardcoding any password is wrong.
And these are wrongs that can be committed on any OS.
What you say implies that there is at least one content type for which people are willing to pay: new and timely information.
This is consistent with what is done with quotes from the stock exchanges: the delayed feed is available for free, while the realtime feed is a for-pay option.
But I think there are other areas for which people are willing to pay. One example: quality. If there's a significant quality difference between the free information and the for-pay information, then at least some people will pay for the latter.
This quality comes in at least two forms: the presentation of the information itself, and the organization of - or easy of locating - the information.
For example, I pay for a subscription to "The Economist". I do this for all of the above reasons.
But micropayments raise a completely different issue than just "will people pay for content". I pay for subscriptions (ie. The Economist) based upon a fixed rate. It's a kind of "fire and forget" model.
If I had to pay for each article (which is the possibility introduced by micropayments), I end up doing a lot more work to read, just in the process of deciding whether or not an article is worth the fee. That work - which involves time - is a cost over and above the actual cash payment being made. It is a cost paid for each and every article, WHETHER OR NOT I DECIDE TO BUY.
That's a disincentive to review a site for possible articles, and will therefore bring readership down. Note that this is before we even consider whether an individual piece of content is worth the price being charged.
That is not a good sign for the "pay per view" model on the Internet.
Unfortunately, as others have pointed out, the ones paying are actually the other students. The payment is coming from the school district's funds, which - presumably - would otherwise be spend on the kids.
It's too bad that the distict was liable. Better to sue the actual fools that committed the offense.
With respect to this being a "dog bites man" story, I opine that the current climate is very much against online rights and protections. A court finding *for* speech rights online is worthy news indeed.
Well, I can give you a little information from the other side. We've two positions open, and we're actively looking for people.
We've put ads at several places on the net, including Hotjobs, Dice, and a few NY-area-centric sites.
By far the majority of resumes we're seeing are not well suited to the positions. For example, we're looking for people experienced (esp. in the case of the senior position) in UNIX technologies. Yet we get resumes of people with nothing but ASP and Front Page. Annoying!
We're also seeing people with maybe a year or two of experience in the field applying for the senior position.
Finally, we've put some very specific details in our ads regarding how we'd like to see resumes. Clearly placed on each is "text only". Yet people still send MS Word documents.
Obviously, I'm not describing all people. But do please recall that those of us hiring have our frustrations too. We're trying very hard to hire other than "warm bodies". And some of us don't have the luxury/curse of an NR department!
Authentication isn't entirely the issue. If it were, we'd all be happily accepting ActiveX components. Instead, we also need control over authorization.
The solution to the sharing of executables is the sandbox model. I got a kick out of the subthread here on anti-viral programs, as virtual CPUs were mentioned there as an AV technique. That, along with security constraints, is also a solution to the idea of sharing executables.
Certification provides the authentication. We then add authorization in the form of security constraints which vary from identity to identify, and a nice solution is now created.
Untrusted software might be given no network access and limited disk access (ie. a few megabytes in a fixed directory), trusted software given full access, and all the greys in between.
To the best of my knowledge, one is not free to make money in any way whatsoever. There are numerous limits to this, from criminal law to behaviors being civilly actionable.
This negates your second point.
With respect to your first and forth points, MAPS very clearly states that one of the behaviors which will cause a "bad review" (an RBL listing) is to sell "spamware". Thus, sending spam is not the only available reason for inclusion.
This leaves your third point. But since there are no facts being mistated, and no rights being violated, MAPS's right to provide a "poor review" (an RBL listing) are retained. Simplistically, they may be "saying bad things", but the things are true, documented, and documented as "bad" by the reviewer's documented standards.
Your final analogy is wanting. It would be better to use the case of a gun manufacturer suing the provider of a list of builders of things which kill. It is a nasty assertion being made, but a true one.
Re:Small towns and geographic monopoly
on
MAPS Sued Again
·
· Score: 1
It is also worth noting that sendmail (perhaps
with a patch that I found on the net; I'm not
sure since it's been so long) permits selection
of filter rules by domain or even email address.
We, for example, have some clients which use the
RBL and others which do not. The "do not" list is,
not surprisingly, shrinking.
Oh, yes! I'd wondered too, and you're right on the mark. By running the auction, NSI avoids losing the domain to a better registrar.
But the worse part of this - personally - is that we received a notice regarding this auction which made no reference to a domain name. So we might or might not have a domain at "risk", that might have slipped through our fingers (we run quite a few here).
>The problem is that "server", in its technical >definition also includes things like telnetd, >nfsd, rpc, ftpd, and so on, that us in the UNIX >world have come to expect as part of the core OS.
Did anyone ever do a survey on this? I'm curious, as I'm a medium-term UNIX user (since about 1985) and I disagree with your assertion regarding those services. To me, they're applications (which also happen to be servers).
While it isn't *proof* of my assertion, it should be found telling that a UNIX box works perfectly well w/o telnetd.
Sadly, I think that any successful politician today will be easily bought.
The reason is that money is a major factor in any campaign today, and "being bought" means having money. So being easier to buy means getting more money, and therefore greater chance of being successful as a politician.
The only exception, I suppose, is a politician that is already *very* wealthy and can therefore buy a seat w/o help.
>There's also a practical matter, though: >Writing a Java VM is a job for OS programmers, >not application programmers. Just from an >organizational standpoint, it should be done >in the OS division.
I'm afraid that I must disagree. A VM consists of an interpreter that makes calls to the OS to accomplish certain specific tasks (ie. file I/O). Although details obviously differ, this is conceptually no different from what any interpreter does. That includes Perl, for example, which runs very well on many OSes despite a complete separation between Perl development and OS development.
Admittedly, there are certain skills common to both OS authors and VM authors, but that's true for many different types of software projects.
There's another possible sequence of events that would prevent the breakup: the DOJ backing off. Before you claim this impossible, recall that there's an election coming and that MS has paid some hefty dollars towards "good will" there.
Admittedly, this isn't *too* likely, esp. with the news coverage of MS's attempts at gathering support from Bush. But it isn't impossible, either.
>Yes, all of the interesting problems have been >solved
Excellent. Please point me at the download for the OS which will manage the resources of multiple hardware components connected via a WAN. Load balancing, up to and including process migration, is a must. Also required is HA style protection against the death various components.
I must be old. When altering a sendmail configuration, I futz directly with the CF file. Once it is working properly, I try to get equivilent behaviour out of those damned M4 macros.
Rule based pattern matching makes sense to me. Macros make sense too, but M4 just has too many oddities for me.
>Throughout history people have had to work at >the speed of technology. With every >technological advance people have >had to work harder, and faster than before.
I'd much rather be doing this than working in a (low tech) factory or coal mine.
>This coming demise of market prices invalidates >all the economic theory that justifies >free-market capitalism.
You see this as a universal negative for the consumer. It can go the other way too, where retailers are forced to drop prices as market friction decreases. Your "mortician" example works because of the high friction (the high cost of going to another town while dead {8^). But, just as network technologies enable the retailer to "optimize" pricing, the consumer is enabled to "optimize" (in the other direction, of course {8^) purchasing.
I'm not predicting, mind you. I'm just indicating that this possibility exists too.
The largest population of machines here run Solaris (with Linux as #2). Reading here that Solaris 8 will not include Open Windows is very bad news for me. I *like* OW more than any other GUI that I've ever seen.
It is in use on almost every desktop at this company.
Slashdot Mirror
See http://voteview.uh.edu/antitrst.htm for information on this.
While you're accurately describing the situation today, it need not stay this way. There are some very interesting projects, out in academia, which might address this very important issue.
Take a look at "slim binaries" and "Dynamic Code Reoptimizers" here for a starting point.
The interesting aspect to this, from a social and economic perspective, is that it is projects like this which could reduce the benefit of any existing monopolistic position on the desktop. Given this, I'm somewhat saddened that these ideas haven't been picked up by companies like SUN or communities like Linux. Perhaps this really isn't ready for 'prime time', but cash and interest from SUN could go a long way to aiding this work.
Intel would also gain from this. As you've pointed out, software tends to be optimized towards the least common denominator of hardware. That eliminates much of the advantage of newer architectures. Techniques such as these would increase the incentive for hardware upgrades, as existing softwares' performance would be immediately improved.
I suppose that I was insufficiently clear. I know that the FAA has no jurisdiction in international airspace. But we were discussing ROW rules, and I thought it useful to add a little real information on how those rules are expressed, in one (large) jurisdiction.
Also, the fact that Chinese airspace is not required to follow FAA rules is irrelevent. That airspace was not violated until after the incident occurred.
When discussing international airspace, one must consider ICAO rules/agreements (www.icao.org). However, I'm not especially familiar with these. I've read elsewhere, though, that an agreement amongst parties including China provides for aircraft in distress landing as necessary.
I'm a private pilot; not military.
But by FAA rules, size of aircraft is not a factor in determining right of way. For fixed wing aircraft with neither under distress, the vehicles are considered equivilent (there are distinctions drawn, but only when adding airships, gliders, etc. to the equation).
For a situation where one aircraft is overtaking another, the vehicle being overtaken has the right of way. But one could use this to draw stupid scenarios. For example, the chinese fighter could move ahead of the P-3, and then decelerate. In that case, it would be the responsibility of the P-3 to avoid the fighter (by passing to the right, if we're going to stay pedantic {8^).
See FAR 91.113.
But this is really silly. A few months ago, I was on a collision course with another aircraft. I had the right of way. But he wasn't moving (likely hadn't noticed me).
I avoided him.
I'd rather that than argue ROW rules to death.
Of course, the Chinese pilot was already violating FAA rules. Specifically, 91.111.b states that formation flying requires arrangement with each of the involved pilots.
It pays to study the classics. Please see this for an explanation of a back door which remains hidden despite your "check".
And what is wrong with thinking of each object as "an independent little program"? Such reasoning serves a person well in a distributed or multithreaded programming environment.
But your posting is exactly the sort of thinking that, as an educator, I have to work out of many people with prior programming experience. Your "from the ground up" approach puts an emphasis on implementation instead of interface. This yields a tendency to discuss pieces of "how" before knowing all of the "what" or "why".
Obviously, a programmer needs to be concerned about implementation details. But these tend to come very late in the process, for successful projects.
Of course, there are exceptions. Real time or embedded systems, for example, have as a part of their description what would normally be considered low level details (ie. memory management). But these can be taught later, perhaps after circuit design and assembler classes have explained the building blocks involved.
But perhaps we're begging the question of "what is the CS program to produce?" Is the goal to produce programmers, or to produce software engineers? I generally view the goal as the latter.
Actually, a CS program could probably move in either direction: from circuits up, or from concepts down. I'd tend to choose the later, simply because a greater number of engineers work at high levels than low.
But the final result should be the same in either case. The program should yield professionals that can discover requirements, synthesize designs, and produce implementations. They should be equipped with a wide array of "tools" towards these goals, including understandings of algorithms, proofs, sets, concurrency, resource management, various forms of decomposition and design (ie. OO, functional, procedural, etc.), and so on.
When you look at it this way, it actually becomes less important where you start the students, and more important how you fit it all in.
I agree and disagree with both of you. Having taught beginners, both at the University and corporate levels, I've come to two conclusions.
OO, taught properly, is *easy*. It is not terribly different from how most people operate in the real world, after all. Everyone classifies via similarities and differences. Everyone abstracts away the "unimportant" details. Everyone groups. And so on.
It's just a matter of identifying what people do in the real world, and mapping this back to OO concepts. I still recall Booch's cat diagrams, for example.
On the other hand, I find Java to have too rich a syntax to make a good first language. It's too easy to get bogged down in details there, which costs time spent on the concepts.
For one small example, consider a class method. I'd rather teach this second, and object methods first. Yet, in Java, one cannot build a program w/o a static main().
So instead, one teaches class methods first. But now one must describe the "static" keyword as "magic" to be explained later.
And that is a second example. An ideal first language would have a syntax that permits the first program to be built with a minimum of constructs.
Unfortunately, the myth of "point n click" administration has been deeply embedded within the corporate consciousness. A side effect is the belief that "MS" administrators are cheaper, as the job is easier.
Fortunately, I think that this myth is dying. All of our production machines are, and the primary target of our development efforts is, UNIX. It used to be I'd get puzzled looks when I explained that this was to keep costs down. Now, I get understanding agreement.
I won't argue that installing a blank password isn't bad. It is.
/" to consider.
But so what? Your DB shouldn't be accessible to outsiders anyway. It should be "hidden" somewhere unreachable, preferably in nonroutable space (RFC1918). Your applications need to reach it. Outsiders don't.
Of course, using UNIX is no magic solution. I know of a company that deals (if they still exist) with *money* in their DB. The child DBA installed Sybase on a public IP and left the password blank. That he did this on a Solaris box didn't make a difference; it was still stupid.
Needless to say, they didn't bother with a firewall.
Back to your message: hardcoding *any* password is an invitation to problems. I know of a different company that had a password hardcoded throughout their software. This was a password which provided login access to the web servers (among other things). Of course, an ex-employee of reduced morals exploited this and gave them a nice "rm -rf
It wasn't the root password, so it didn't kill everything. But it took out all of their application software.
They'd have changed the password more often, but "it was too hard" to do so because it was encoded all over the place.
We won't even discuss the wisdom of how this company organized their file ownerships and access rights.
So the blank password is really a red herring. Access to the DB from outside is wrong. Hardcoding any password is wrong.
And these are wrongs that can be committed on any OS.
What you say implies that there is at least one content type for which people are willing to pay: new and timely information.
This is consistent with what is done with quotes from the stock exchanges: the delayed feed is available for free, while the realtime feed is a for-pay option.
But I think there are other areas for which people are willing to pay. One example: quality. If there's a significant quality difference between the free information and the for-pay information, then at least some people will pay for the latter.
This quality comes in at least two forms: the presentation of the information itself, and the organization of - or easy of locating - the information.
For example, I pay for a subscription to "The Economist". I do this for all of the above reasons.
But micropayments raise a completely different issue than just "will people pay for content". I pay for subscriptions (ie. The Economist) based upon a fixed rate. It's a kind of "fire and forget" model.
If I had to pay for each article (which is the possibility introduced by micropayments), I end up doing a lot more work to read, just in the process of deciding whether or not an article is worth the fee. That work - which involves time - is a cost over and above the actual cash payment being made. It is a cost paid for each and every article, WHETHER OR NOT I DECIDE TO BUY.
That's a disincentive to review a site for possible articles, and will therefore bring readership down. Note that this is before we even consider whether an individual piece of content is worth the price being charged.
That is not a good sign for the "pay per view" model on the Internet.
Unfortunately, as others have pointed out, the ones paying are actually the other students. The payment is coming from the school district's funds, which - presumably - would otherwise be spend on the kids.
It's too bad that the distict was liable. Better to sue the actual fools that committed the offense.
With respect to this being a "dog bites man" story, I opine that the current climate is very much against online rights and protections. A court finding *for* speech rights online is worthy news indeed.
Well, I can give you a little information from the other side. We've two positions open, and we're actively looking for people.
We've put ads at several places on the net, including Hotjobs, Dice, and a few NY-area-centric sites.
By far the majority of resumes we're seeing are not well suited to the positions. For example, we're looking for people experienced (esp. in the case of the senior position) in UNIX technologies. Yet we get resumes of people with nothing but ASP and Front Page. Annoying!
We're also seeing people with maybe a year or two of experience in the field applying for the senior position.
Finally, we've put some very specific details in our ads regarding how we'd like to see resumes. Clearly placed on each is "text only". Yet people still send MS Word documents.
Obviously, I'm not describing all people. But do please recall that those of us hiring have our frustrations too. We're trying very hard to hire other than "warm bodies". And some of us don't have the luxury/curse of an NR department!
Authentication isn't entirely the issue. If it were, we'd all be happily accepting ActiveX components. Instead, we also need control over authorization.
The solution to the sharing of executables is the sandbox model. I got a kick out of the subthread here on anti-viral programs, as virtual CPUs were mentioned there as an AV technique. That, along with security constraints, is also a solution to the idea of sharing executables.
Certification provides the authentication. We then add authorization in the form of security constraints which vary from identity to identify, and a nice solution is now created.
Untrusted software might be given no network access and limited disk access (ie. a few megabytes in a fixed directory), trusted software given full access, and all the greys in between.
To the best of my knowledge, one is not free to make money in any way whatsoever. There are numerous limits to this, from criminal law to behaviors being civilly actionable.
This negates your second point.
With respect to your first and forth points, MAPS very clearly states that one of the behaviors which will cause a "bad review" (an RBL listing) is to sell "spamware". Thus, sending spam is not the only available reason for inclusion.
This leaves your third point. But since there are no facts being mistated, and no rights being violated, MAPS's right to provide a "poor review" (an RBL listing) are retained. Simplistically, they may be "saying bad things", but the things are true, documented, and documented as "bad" by the reviewer's documented standards.
Your final analogy is wanting. It would be better to use the case of a gun manufacturer suing the provider of a list of builders of things which kill. It is a nasty assertion being made, but a true one.
It is also worth noting that sendmail (perhaps
with a patch that I found on the net; I'm not
sure since it's been so long) permits selection
of filter rules by domain or even email address.
We, for example, have some clients which use the
RBL and others which do not. The "do not" list is,
not surprisingly, shrinking.
Oh, yes! I'd wondered too, and you're right on the mark. By running the auction, NSI avoids losing the domain to a better registrar.
But the worse part of this - personally - is that we received a notice regarding this auction which made no reference to a domain name. So we might or might not have a domain at "risk", that might have slipped through our fingers (we run quite a few here).
Frustrating.
>The problem is that "server", in its technical
>definition also includes things like telnetd,
>nfsd, rpc, ftpd, and so on, that us in the UNIX
>world have come to expect as part of the core OS.
Did anyone ever do a survey on this? I'm curious, as I'm a medium-term UNIX user (since about 1985) and I disagree with your assertion regarding those services. To me, they're applications (which also happen to be servers).
While it isn't *proof* of my assertion, it should be found telling that a UNIX box works perfectly well w/o telnetd.
Sadly, I think that any successful politician today will be easily bought.
The reason is that money is a major factor in any campaign today, and "being bought" means having money. So being easier to buy means getting more money, and therefore greater chance of being successful as a politician.
The only exception, I suppose, is a politician that is already *very* wealthy and can therefore buy a seat w/o help.
>There's also a practical matter, though:
>Writing a Java VM is a job for OS programmers,
>not application programmers. Just from an
>organizational standpoint, it should be done
>in the OS division.
I'm afraid that I must disagree. A VM consists of an interpreter that makes calls to the OS to accomplish certain specific tasks (ie. file I/O).
Although details obviously differ, this is conceptually no different from what any interpreter does. That includes Perl, for example, which runs very well on many OSes despite a complete separation between Perl development and OS development.
Admittedly, there are certain skills common to both OS authors and VM authors, but that's true for many different types of software projects.
There's another possible sequence of events that would prevent the breakup: the DOJ backing off. Before you claim this impossible, recall that there's an election coming and that MS has paid some hefty dollars towards "good will" there.
Admittedly, this isn't *too* likely, esp. with the news coverage of MS's attempts at gathering support from Bush. But it isn't impossible, either.
It's a scary thought.
>Yes, all of the interesting problems have been
>solved
Excellent. Please point me at the download for the OS which will manage the resources of multiple hardware components connected via a WAN. Load balancing, up to and including process migration, is a must. Also required is HA style protection against the death various components.
I must be old. When altering a sendmail configuration, I futz directly with the CF file. Once it is working properly, I try to get equivilent behaviour out of those damned M4 macros.
Rule based pattern matching makes sense to me. Macros make sense too, but M4 just has too many oddities for me.
>Throughout history people have had to work at
>the speed of technology. With every
>technological advance people have
>had to work harder, and faster than before.
I'd much rather be doing this than working in a
(low tech) factory or coal mine.
>This coming demise of market prices invalidates
>all the economic theory that justifies
>free-market capitalism.
You see this as a universal negative for the consumer. It can go the other way too, where retailers are forced to drop prices as market friction decreases. Your "mortician" example works because of the high friction (the high cost of going to another town while dead {8^). But, just as network technologies enable the retailer to "optimize" pricing, the consumer is enabled to "optimize" (in the other direction, of course {8^) purchasing.
I'm not predicting, mind you. I'm just indicating that this possibility exists too.
The largest population of machines here run Solaris (with Linux as #2). Reading here that Solaris 8 will not include Open Windows is very bad news for me. I *like* OW more than any other GUI that I've ever seen.
It is in use on almost every desktop at this company.
Post the petition's location; I'll sign.