In 1982, The Who went on a huge farewell tour. At the time, Townsend went on and on in the music press about how he did not want to become a parody of the band they were. (I think he went for the Beach Boys as an analogy. Unfortunately, they are too easy of a target.) He didn't directly say that he knew they were past their prime, but anyone who listened to Face Dances or I'ts Hard knew that although the tunes might become hits, but they wouldn't become classics
I wish that they stuck their original idea. Its odd how peoples perceptions work though. When you're starting to get over the hill, you can say to youself that you better bow out gracefully. When you are way over the hill, you may not think of yourself that way. I bet that Pete can't imagine what was going through his head when he penned I hope I die before I get old. His ideas, perceptions, and experiences are so different, that whatever emotions brought those words up are entirely foreign by now.
But on the main point of the themes of story Lifehouse. I wish he'd stop bringing up that old dead horse. I'm not sure if Fred Brooks was familiar with Townshend's work, but it was a perfect example of what Brooks called the Second System Principle It seemed that he had a success in the Rock Opera genre with Tommy, got cocky, and thought he could do anything. When he couldn't get things together, he through it on Who's Next and went on from there. Now he tries to point to the Internet, point to his failed Lifehouse project, and declare himself a visionary. I don't think it was hard to imagine in the late '60s and early '70s that technology was advancing and allowing people more and more advanced forms of communication, yet making them feel less connnected.
It wasn't the metadata concept itself that made viruses so easy to write on the Macintosh, it was the search path for the resources. When looking for resources (for example a WDEF window definition, essentially a code snippet that describes how to draw a style of window) unless care is taken, an application first looks through the resource fork of the open document, then the current application, then finally the system file. This meant that a document or application could override the systems window drawing code, replacing it with its own. All the documents had to do is to copy itself into other documents and instant virus.
Windows is in the same position with viruses and worms in Outlook and Word as Apple was around Hypercard's heyday. It was simple to write hypercard stacks that contained scripts to find other hypercard stacks and insert itself into it.
The thing that makes things worse for Windows is the Internet makes sharing these mixed program/data files much easier.
This would actually be the third attempt that I know of. The first was Lisa XENIX. The second was A/UX. They also had "Macintosh Application Environment" for Solaris, HP/UX and others which is essentially what the "Classic Environment" is.
And then the BSD over Mach that makes up Darwin came originally from NeXT, who did have experience developing Unix.
I'm sorry, I personally don't remember it that way. Some of the first software development work I did was in C, and it was either systems that supported "the current draft of ANSI C" or weren't ANSI complient at all. And by that time, there were probably more C jobs than anything else being advertised. (Of course, it may be that "being advertised" is a big caveat. I've been told there is still a market for Smalltalk programmers, but since it is such a small club everyone knows where all the openings are.)
Or look at it this way, according to an old copy of "Design and Evolution of C++", Borland was the largest producers of C++ compilers, and they had shipped 500,000 units by October 1991. And that would be just the year after the C standard was ratified.
For C++ and Java though, you may be right. I just through that in to imply a trend. In actuality, I don't think Java is taking away projects from C++. Each one is suited for jobs the other is not. (At hte most, Java is being used for jobs that would have, but shouldn't have, been written in C++).
Also, I find your mention of Ada as a "legacy language" interesting, since it is a fairly recent language. Not at all in the category of Fortran or Cobol.I think that Ada is something that has its place, mostly for someone wanting an excplicitly standardized language. (A company can't call itself Ada until it passes the conformance tests.)
The best way to study the way perl executes a script is to build a special "-DDEBUGGING" version of perl and run short test program with the "-D14" switch.
At last years perl conference, a co-worker of mine cornered Gurusamy Sarathy and him why someone with so much skill developing perl would work for a company developing Windows products. (I thought it was a very obnoxious question, but the guy is a former reporter and used to asking obnoxious questions.)
His answer was, "sometimes when you are a missionary, you have to go out to the heathens"
Larry brings up two points in his article about why an external written standard would be good for Perl.
Personally, I don't buy the point about a standardized language being more accepted. The C and C++ standardization committees both probably started during the crest of their languages popularity. (Since C++'s prototypes got back ported to the C standard, you can tell they new they had to keep up with this competitor. And by the time C++ was standardized, all the hype had moved to Java.)
The point I agree with more, is that so much of what the language does is undocumented or ambiguously documented, you really have no way to ensure that your program will work in any future version of perl. (and can only guess if it works in past versions by testing.)
When a report of a change of behavior between the current version of perl and a previous version comes to the perl5porters, pretty much the first step (although the step can be implied at times.) is to decide on an adhoc basis the definition of the language. Sometimes they can use historical precedent to prove one implementation over another. Sometimes they use vague philisophical notions of what the "perlish" way to do it would be. Sometimes the arguments seem to consist of people quoting contradictory entries from lwall-quotes file.
Of course, standardation is antithetical to the current perl development model. Its enshrined in their "Rule Number One", and "Rule Number Two". (#1 is "Larry is alway right". #2 is "Larry is right even when he changes his mind" or "Don't try to use Rule Number One against Larry".)
Your CLI/GUI example isn't very accurate. If some sort of filemanager app isn't in sync with what is on the disk, it is simply failing within that particular program, not because of come CLI layer. (Its not like Windows Explorer calls COMMAND.COM to find out what files are on the disk.)
The Mac Finder continuously polls the directories on disk for any of its open windows, looking for new or changed documents. Any program displaying files can do this. Some programs are either poorly written and forget to, or are designed to be more efficient and don't waste the CPU cycles.
If a monolithic application doesn't have a rich enough apple event support (or some other method of getting and responding to external events) to have it do what you want, there will be no way to programatically access the portion of the application that you want.
You can already send apple events to applications using perl with the Mac::AppleEvents and optionally the Mac::Glue modules.
Writing a command line program to send that information is possible. And those tools could be run by a shell.
If thats your point, then I guess the Mac has sufficient hooks into its applications to allow the power you need, while providing an easy to use GUI for the novice.
I'm at work write now, and not at my mac, but I think the Applescript equivalent would be
tell application "Finder" set sizes to free space of every disk display dialog sizes end tell
A bit more verbose, I'll agree. But id does have some advantages. First of all, the output of df is very system dependant. I'm typing this on a Solaris box which uses the SYSV style output. Second of all, there are so many arbitrary decisions made in your pipeline. "Why choose only lines that contain a slash. (One answer: to remove df's noise lines. Why does df output noise lines? It isn't a very unixish design.) Why print out the fourth column? Thirdly, df and awk don't really agree on field separators, so sometimes the outputs won't quite work out right. I opened up a terminal on a Linux box and typed your pipeline again. I got a blank line followed by one that said "72%". So I ran "df" alone and got one line that said something like:
ent, I'm not sure if my path is really going to be helpful or not.
Basically reading about Rhapsody and OS X has got me interested in reading whatever I can find about NEXTSTEP and OPENSTEP. And reading about OPENSTEP has got me looking at Objective C and GNUStep.
So I'm hoping that playing around with GNUstep will give me a head start if I ever do anything with OS X. Even if it didn't, it is a fascinating subject to study.
I've always assumed that Apple was always mentioning Java in order to avoid turning off people who think of Objective-C as "the language that lost to C++".
The same shallow minded people probably would think of Java as a "winner".
In other words, it isn't Apple that might be pushing people to Java, but rather the market pushing Apple from ObjC. (Similar to Apple's move from Pascal to C interfaces)
Maybe Darwin + OPENSTEP + Quartz + Quicktime + a few random bits. Quartz replaced the DPS of OPENSTEP, and omitting it from the list minimizes its importance to OS-X
Unfortunately, display ghostscript isn't quite ready for prime time, and although GNUStep is making progress, it still has some work to go.
I suspect that you are measuring OS X against Linux. Your view of how good OS X depends on how good a Unix-line environment it is. And then everything un-Unix like gets discarded as irrelevant.
Re:Why I gave up on Apple. (They gave up on me.)
on
Apple Delays Mac OS X
·
· Score: 1
The 80287 was only a math co-processor. It did not have any of the MMU and v86 features that made the prefered platform. A '286 to '386 upgrade required a new motherboard.
Possibly, you were thinking about the 487SX, which really had the full functionality of a 486DX (when a 487SX was present, it disabled the main 486SX). Or possibly you were thinking of certain early 80386 motherboards which were designed to allow an 80287 rather than the 80387 (which arrived much later than the '386)
Or possibly, you have know idea what you are talking about.
Is it a victory? I find software and business only patents an aberation of the patent system. By using patented techniques which are free (as in beer), are we justifying the use of software patents to people like Unisys, Microsoft, Apple, and the rest.
I would think that the best thing that developers of free software could do is to publish their techniques so that they can be seen as prior art and prevent the USPTO from issuing patents on them.
I have never heard of any situation where the FSF has actually taken a conflict into a court. They have had their legal counsel discuss matters with representitives from other companies.
Its not as definative as a win in court, but probably far less costly. Its still a feather in their cap and can be used in negotiations against future infringers. ("You really think you can win if we take this to court? NeXT didn't think so, so they folded".)
I've seen two basic styles of chip programmers. Ones that have large enough buffers to hold a copy of the chips contents, and ones that depend on the data being transfered in time to meet the timing specs of the chip.
The ones that can hold all the data in a buffers usually accept Hex or S-Record format sent over a serial port. These should be able to be adapted to be used under linux with little or no problem. The drawback is that the memory and the processing power needed on the programmer makes these devices very expensive.
The ones that format the buffer on the computer and send them in time to meet the chips programming specs can be cheaper, (an ISA card with some line drivers on them) but it would be very difficult for Linux to supply data in spec. (Maybe with RT-Linux?)
You still seem to be missing what an X Terminal is (or was.) X terminals are machines that have X servers (the graphical display) running, but don't execute X client applications themselves.
An X server would be able to run things like Netscape and the Gimp. You won't be able to do that on your VT100 no matter how hard you try. (Unless you want to create an X server that draws ASCII art in escape sequences onto the terminal for a whopping 132x25 resolution.)
Also, "telnet" implies some sort of network connection, which a VT100 doesn't have, it just has full duplex serial connnection. Telnet mimics over a network what hardwired (like the VT100) terminals do.
In other words, I don't think the coffee really helped.
In the early '90s there was a huge rash of viruses for the Macintosh. I remember at the time Peter Norton (before he sold out to Symantec) saying that trying to produce Anti-virus software for the Mac was pretty much hopeless, since it was pretty much a breading ground for that kind of thing. (Since the way the Mac reads resources from its open documents before the application, and in applications, before the system file, putting things like MDEF menu handlers or WDEF window handlers in a document or application will override what is in the lower levels of the search.)
If rate of Mac virus growth has slowed while Windows virus has grown, its just because the Mac's declinig market share made it no longer an interesting target.
I use to think that it was eventually too easy of a target, but that hasn't stopped the VBA and executable email attachment based virus writers. Its like shooting fish in a barrel.
Whats to understand? An author of a work owns a copyright, an exclusive right to make copies. He or she can give a copy to anyone he wishes on whatever terms they wish. Microsoft can sell one Windows CD for $200 and another for $75. Identical disks if they want.
A software developer can distribute code to anyone he or she wishes. They own it. The person who receives the code can't produce additional copies, since that is a right granted only to the copyright holder. If the copyright holder wants someone else to distribute copies of the work, they can grant a license to allow them to do it. Each license to each distributor can be negotiated individually. One person can get a license as long as they pay you are $5 per copy royalty. Another can get a license for a $300 flat fee. A third can get a license as long as they agree to distribute the source code.
There are some real world examples of combination proprietary and GPL licenses both being used on the same code. Aladdin (the Ghostscript people) use at least three licenses. They have a relatively free license for most people. For commercial companies that can't abide by the free license, they are willing to negotiate additional licenses. And then for older versions, they release things under the GPL.
The thing that makes most open source projects difficult to multiple licenses is the number of people involved. If you have many contributors, and they have all distributed their code under the GPL, then to grant a different license it would require that all of the contributors agree on the new license terms.
Most of the things that QNX are used for, crypt() wouldn't be used anyway. Very likely, you would have no logins, and no user authentication. It has two features that make it noteworthy, a guarenteed maximum response time from interrupts, and a POSIX API. It isn't the only product to have either of the two features, but it is noteworthy because it has both.
If you check a couple of levels up from the URL that was posted, you can see dmr's description of the corperate and legal gyrations that affected his employer. Bell Labs is part of Lucent, not AT&T. Even when it was part of AT&T, it would not make them "Pacific Bell", "Bell Altantic", etc. as these were corporations created for businesses that AT&T needed to divest itself from. And I'm not sure what you mean by hiding their talent. I guess you could put Ritchie on the customer support phone lines of bellatlantic.net, and a couple of customers would get very good support. Or you could give him and environment where he can work well, but have his ideas misinterpreted each time they go through layers of people not as bright as he is.
Slashdot Mirror
I wish that they stuck their original idea. Its odd how peoples perceptions work though. When you're starting to get over the hill, you can say to youself that you better bow out gracefully. When you are way over the hill, you may not think of yourself that way. I bet that Pete can't imagine what was going through his head when he penned I hope I die before I get old. His ideas, perceptions, and experiences are so different, that whatever emotions brought those words up are entirely foreign by now.
But on the main point of the themes of story Lifehouse. I wish he'd stop bringing up that old dead horse. I'm not sure if Fred Brooks was familiar with Townshend's work, but it was a perfect example of what Brooks called the Second System Principle It seemed that he had a success in the Rock Opera genre with Tommy, got cocky, and thought he could do anything. When he couldn't get things together, he through it on Who's Next and went on from there. Now he tries to point to the Internet, point to his failed Lifehouse project, and declare himself a visionary. I don't think it was hard to imagine in the late '60s and early '70s that technology was advancing and allowing people more and more advanced forms of communication, yet making them feel less connnected.
Some visionary.
It wasn't the metadata concept itself that made viruses so easy to write on the Macintosh, it was the search path for the resources. When looking for resources (for example a WDEF window definition, essentially a code snippet that describes how to draw a style of window) unless care is taken, an application first looks through the resource fork of the open document, then the current application, then finally the system file. This meant that a document or application could override the systems window drawing code, replacing it with its own. All the documents had to do is to copy itself into other documents and instant virus.
The thing that makes things worse for Windows is the Internet makes sharing these mixed program/data files much easier.
This would actually be the third attempt that I know of. The first was Lisa XENIX. The second was A/UX. They also had "Macintosh Application Environment" for Solaris, HP/UX and others which is essentially what the "Classic Environment" is.
And then the BSD over Mach that makes up Darwin came originally from NeXT, who did have experience developing Unix.
I'm sorry, I personally don't remember it that way. Some of the first software development work I did was in C, and it was either systems that supported "the current draft of ANSI C" or weren't ANSI complient at all. And by that time, there were probably more C jobs than anything else being advertised. (Of course, it may be that "being advertised" is a big caveat. I've been told there is still a market for Smalltalk programmers, but since it is such a small club everyone knows where all the openings are.)
Or look at it this way, according to an old copy of "Design and Evolution of C++", Borland was the largest producers of C++ compilers, and they had shipped 500,000 units by October 1991. And that would be just the year after the C standard was ratified.
For C++ and Java though, you may be right. I just through that in to imply a trend. In actuality, I don't think Java is taking away projects from C++. Each one is suited for jobs the other is not. (At hte most, Java is being used for jobs that would have, but shouldn't have, been written in C++).
Also, I find your mention of Ada as a "legacy language" interesting, since it is a fairly recent language. Not at all in the category of Fortran or Cobol.I think that Ada is something that has its place, mostly for someone wanting an excplicitly standardized language. (A company can't call itself Ada until it passes the conformance tests.)
The best way to study the way perl executes a script is to build a special "-DDEBUGGING" version of perl and run short test program with the "-D14" switch.
His answer was, "sometimes when you are a missionary, you have to go out to the heathens"
Personally, I don't buy the point about a standardized language being more accepted. The C and C++ standardization committees both probably started during the crest of their languages popularity. (Since C++'s prototypes got back ported to the C standard, you can tell they new they had to keep up with this competitor. And by the time C++ was standardized, all the hype had moved to Java.)
The point I agree with more, is that so much of what the language does is undocumented or ambiguously documented, you really have no way to ensure that your program will work in any future version of perl. (and can only guess if it works in past versions by testing.)
When a report of a change of behavior between the current version of perl and a previous version comes to the perl5porters, pretty much the first step (although the step can be implied at times.) is to decide on an adhoc basis the definition of the language. Sometimes they can use historical precedent to prove one implementation over another. Sometimes they use vague philisophical notions of what the "perlish" way to do it would be. Sometimes the arguments seem to consist of people quoting contradictory entries from lwall-quotes file.
Of course, standardation is antithetical to the current perl development model. Its enshrined in their "Rule Number One", and "Rule Number Two". (#1 is "Larry is alway right". #2 is "Larry is right even when he changes his mind" or "Don't try to use Rule Number One against Larry".)
The Mac Finder continuously polls the directories on disk for any of its open windows, looking for new or changed documents. Any program displaying files can do this. Some programs are either poorly written and forget to, or are designed to be more efficient and don't waste the CPU cycles.
You can already send apple events to applications using perl with the Mac::AppleEvents and optionally the Mac::Glue modules.
Writing a command line program to send that information is possible. And those tools could be run by a shell.
If thats your point, then I guess the Mac has sufficient hooks into its applications to allow the power you need, while providing an easy to use GUI for the novice.
I'm at work write now, and not at my mac, but I think the Applescript equivalent would be
/home/langmead
tell application "Finder"
set sizes to free space of every disk
display dialog sizes
end tell
A bit more verbose, I'll agree. But id does have some advantages. First of all, the output of df is very system dependant. I'm typing this on a Solaris box which uses the SYSV style output. Second of all, there are so many arbitrary decisions made in your pipeline. "Why choose only lines that contain a slash. (One answer: to remove df's noise lines. Why does df output noise lines? It isn't a very unixish design.) Why print out the fourth column? Thirdly, df and awk don't really agree on field separators, so sometimes the outputs won't quite work out right. I opened up a terminal on a Linux box and typed your pipeline again. I got a blank line followed by one that said "72%". So I ran "df" alone and got one line that said something like:
fileserver:/home/langmead
37408576 26784104 10624472 72%
Since the path of the filesystem was greater than the fixed sized field df was outputing, it decided to print the rest on a second line.
Yes, it is nice that you can make ad hoc queries on the system like yours. Its better when they give the right answer.
ent, I'm not sure if my path is really going to be helpful or not.
Basically reading about Rhapsody and OS X has got me interested in reading whatever I can find about NEXTSTEP and OPENSTEP. And reading about OPENSTEP has got me looking at Objective C and GNUStep.
So I'm hoping that playing around with GNUstep will give me a head start if I ever do anything with OS X. Even if it didn't, it is a fascinating subject to study.
I've always assumed that Apple was always mentioning Java in order to avoid turning off people who think of Objective-C as "the language that lost to C++".
The same shallow minded people probably would think of Java as a "winner".
In other words, it isn't Apple that might be pushing people to Java, but rather the market pushing Apple from ObjC. (Similar to Apple's move from Pascal to C interfaces)
Maybe Darwin + OPENSTEP + Quartz + Quicktime + a few random bits. Quartz replaced the DPS of OPENSTEP, and omitting it from the list minimizes its importance to OS-X
Unfortunately, display ghostscript isn't quite ready for prime time, and although GNUStep is making progress, it still has some work to go.
I suspect that you are measuring OS X against Linux. Your view of how good OS X depends on how good a Unix-line environment it is. And then everything un-Unix like gets discarded as irrelevant.
The 80287 was only a math co-processor. It did not have any of the MMU and v86 features that made the prefered platform. A '286 to '386 upgrade required a new motherboard.
Possibly, you were thinking about the 487SX, which really had the full functionality of a 486DX (when a 487SX was present, it disabled the main 486SX). Or possibly you were thinking of certain early 80386 motherboards which were designed to allow an 80287 rather than the 80387 (which arrived much later than the '386)
Or possibly, you have know idea what you are talking about.
Is it a victory? I find software and business only patents an aberation of the patent system. By using patented techniques which are free (as in beer), are we justifying the use of software patents to people like Unisys, Microsoft, Apple, and the rest.
I would think that the best thing that developers of free software could do is to publish their techniques so that they can be seen as prior art and prevent the USPTO from issuing patents on them.
I thought there was also some sort of problem with the original redisplay code, but I can't find a reference to that.
The situation that shows best what kind of threat legal action against GPL violations could be is what NeXT tried to do with the GCC objective C extentions
Its not as definative as a win in court, but probably far less costly. Its still a feather in their cap and can be used in negotiations against future infringers. ("You really think you can win if we take this to court? NeXT didn't think so, so they folded".)
I've seen two basic styles of chip programmers. Ones that have large enough buffers to hold a copy of the chips contents, and ones that depend on the data being transfered in time to meet the timing specs of the chip.
The ones that can hold all the data in a buffers usually accept Hex or S-Record format sent over a serial port. These should be able to be adapted to be used under linux with little or no problem. The drawback is that the memory and the processing power needed on the programmer makes these devices very expensive.
The ones that format the buffer on the computer and send them in time to meet the chips programming specs can be cheaper, (an ISA card with some line drivers on them) but it would be very difficult for Linux to supply data in spec. (Maybe with RT-Linux?)
You still seem to be missing what an X Terminal is (or was.) X terminals are machines that have X servers (the graphical display) running, but don't execute X client applications themselves.
An X server would be able to run things like Netscape and the Gimp. You won't be able to do that on your VT100 no matter how hard you try. (Unless you want to create an X server that draws ASCII art in escape sequences onto the terminal for a whopping 132x25 resolution.)
Also, "telnet" implies some sort of network connection, which a VT100 doesn't have, it just has full duplex serial connnection. Telnet mimics over a network what hardwired (like the VT100) terminals do.
In other words, I don't think the coffee really helped.
In the early '90s there was a huge rash of viruses for the Macintosh. I remember at the time Peter Norton (before he sold out to Symantec) saying that trying to produce Anti-virus software for the Mac was pretty much hopeless, since it was pretty much a breading ground for that kind of thing. (Since the way the Mac reads resources from its open documents before the application, and in applications, before the system file, putting things like MDEF menu handlers or WDEF window handlers in a document or application will override what is in the lower levels of the search.)
If rate of Mac virus growth has slowed while Windows virus has grown, its just because the Mac's declinig market share made it no longer an interesting target.
I use to think that it was eventually too easy of a target, but that hasn't stopped the VBA and executable email attachment based virus writers. Its like shooting fish in a barrel.
Whats to understand? An author of a work owns a copyright, an exclusive right to make copies. He or she can give a copy to anyone he wishes on whatever terms they wish. Microsoft can sell one Windows CD for $200 and another for $75. Identical disks if they want.
A software developer can distribute code to anyone he or she wishes. They own it. The person who receives the code can't produce additional copies, since that is a right granted only to the copyright holder. If the copyright holder wants someone else to distribute copies of the work, they can grant a license to allow them to do it. Each license to each distributor can be negotiated individually. One person can get a license as long as they pay you are $5 per copy royalty. Another can get a license for a $300 flat fee. A third can get a license as long as they agree to distribute the source code.
There are some real world examples of combination proprietary and GPL licenses both being used on the same code. Aladdin (the Ghostscript people) use at least three licenses. They have a relatively free license for most people. For commercial companies that can't abide by the free license, they are willing to negotiate additional licenses. And then for older versions, they release things under the GPL.
The thing that makes most open source projects difficult to multiple licenses is the number of people involved. If you have many contributors, and they have all distributed their code under the GPL, then to grant a different license it would require that all of the contributors agree on the new license terms.
Most of the things that QNX are used for, crypt() wouldn't be used anyway. Very likely, you would have no logins, and no user authentication. It has two features that make it noteworthy, a guarenteed maximum response time from interrupts, and a POSIX API. It isn't the only product to have either of the two features, but it is noteworthy because it has both.
If you check a couple of levels up from the URL that was posted, you can see dmr's description of the corperate and legal gyrations that affected his employer. Bell Labs is part of Lucent, not AT&T. Even when it was part of AT&T, it would not make them "Pacific Bell", "Bell Altantic", etc. as these were corporations created for businesses that AT&T needed to divest itself from. And I'm not sure what you mean by hiding their talent. I guess you could put Ritchie on the customer support phone lines of bellatlantic.net, and a couple of customers would get very good support. Or you could give him and environment where he can work well, but have his ideas misinterpreted each time they go through layers of people not as bright as he is.