There was no problem with the software that came with the system. The operating system and the development environment were second to none.
The NeXT software was an excellent and practical engineering achievement: it married Smalltalk-like object-oriented technology with the C language and a UNIX kernel. By industry standards (i.e., compared to Windows, MacOS, and UNIX) it also had good tools and a good development environment.
But it wasn't second to none. The NeXT machine, like the Macintosh that preceded it, mostly just took selected aspects from Smalltalk and similar systems and brought the to the masses on a more mainstream platform. But the originals actually arguably had better development tools and a better runtime.
The NeXT machine was a smartly packaged, excellent practical compromise. Jobs deserves a lot of credit for good taste and practicality. But it wasn't breakthrough or even particularly novel technology given the systems that preceded it by nearly a decade. And, of course, reasonable as it was technically, it was still considered too radical and too expensive by industry.
The real missed opportunity of the 1980's was probably Smalltalk. Sun had actually apparently considered bundling Smalltalk-80 with every Sun workstation sold, but the deal fell through. The world of computing would be a very different place if the graduate students of the 1980's and early 1990's had grown up with that software on their Sun workstations.
I agree that the UNIX command line is a bit deficient in new-user-handholding: it won't prompt you or converse with you. On the other hand, UNIX documentation used to be easy to get to, relevant, and concise, making up for the simplistic command line to some degree. Keeping the UNIX command line interface simple also made it easier for people to develop new command line tools for UNIX. And many UNIX systems (actually, probably the majority of commercially deployed UNIX systems) have excellent menu systems to help inexperienced users.
As someone who has used TOPS, I appreciated the hand it held out to new users. But once you got a little below the surface, I found it was the same as any other system: where it was simple it was simple because it was limited, and where it wasn't limited, it was as complex as anything else. I didn't think it was significantly better overall than UNIX.
One of the advantages of using 36 bits is that you can have the 32 bit types everybody expects (int, IEEE float), and still have a few bits over for type tags, to distinguish pointer types from numerical types. That way, when you read a word of data from memory, you'd know whether it was, say, a floating point number or a pointer before you dereference it. That would be helpful for making C/C++ code safer, and help even more with the compilation of Java, Python, Smalltalk, and other languages.
In the future, you are probably going to see a lot more people treating 64 bit machines as "32 bit machines with a few extra bits in each word", for just that reason.
I think this is some evidence
that even to people working with card-reading machines, and programming their own mainframe system utilities
in assembly, that Unix was still user-unfriendly.
Any system one doesn't know well appears "user unfriendly". That's true for mainframes, UNIX machines, Windows, and even the Macintosh.
And to get good at any system requires quite a bit of effort. The only area systems like Macintosh differ in is that they make it easy to get started (good for sales and motivation). Once you are over the initial hump, they are as complex as everything else.
Of course, some systems really do suck, even when you know them well...
If someone came up with a 68bit (for instance) architecture nowadays we'd all be on/. accusing them of smoking crack!
That's an artifact of languages like C/C++, which provide 8bit byte addressability and use 8bit bytes extensively for string processing. In many other programming languages, you would hardly notice: they provide abstract string types, automatic packing and unpacking of arrays, and other features.
It's also an artifact of ASCII, in which characters are 8 bits. In fact, 36 bits is nicely divisible by 6, often used as the character size on mainframes.
It is kind of ironic how much the C/C++ programming language has driven the development of hardware. That sad thing is that now that the hardware has adapted so much to C/C++, many nice features that aren't in C/C++ are a lot harder to implement.
Incidentally, 36 bit or 68 bit architectures need not be a big problem for C/C++: you could treat them like byte addressable 32 bit and 64 bit architectures and use the extra 4 bits as type tags. That would actually make compiling languages like Java, Python, Lisp, and others a lot easier.
take that book with a big lump of salt
on
PDP-10 Revival
·
· Score: 2
The machines favored by the crowd who contributed to the "UNIX Hater's Handbook" sucked in their own way. I know: I used most of them, including VMS, Symbolics, and TOPS-10. I don't want to go into a long litany of what is wrong with those other systems. But while those systems had many nice ideas, ultimately, the market decided, rightfully as I believe, that they were simply not cost-effective, efficient, or flexible enough. It may take a tough man to make a tender chicken, but the non-UNIX chickens were as tough and unsatisfying as the UNIX chicken, and a whole lot more expensive.
Of course, UNIX does have lots of problems. Unfortunately, many of the complaints in the "UNIX Hater's Handbook" are not even particularly interesting because they reflect more the lack of experience of the contributors with UNIX than any interesting shortcomings. For insightful UNIX criticism, don't bother with the "UNIX Hater's Handbook".
Furthermore, while the contributors to the "UNIX Hater's Handbook" like to complain a lot, I haven't seen much coming from them to actually improve the situation. Maybe Don can provide some links to that kind of work, rather than promoting his book?
Lots and lots of devices are coming on line that let you browse the web. Sites that rely extensively on IE-only technologies won't be able to reach mobile browsers, set-top boxes, cell phones, and other devices.
Yes, Microsoft is trying to muscle their way into that, weaving an intricate web of dependencies among their authoring tools, MS Office, servers, and content they provide, but whether their nefarious plans work out is still an open question. And if they do, the antitrust suit will get new fuel.
While the AltaVista search engine isn't bad, it's clearly losing against Google. Now, those who can't win in the market, by delivering a superior product, go out and start patent lawsuits against their competitors. Many other companies have done that, and the short-term interests of venture vultures like CMGI are driving this process.
Perhaps you can express your displeasure by not letting them index your web site (robots.txt) and not using them for searches.
If Digital wanted purely "defensive" protection, it would have been sufficient to file disclosures; that would have been a lot cheaper, too. Patents are never purely "defensive".
However, they may have filed them in order to have bargaining chips in case other companies claimed infringement against other patents. That's not purely defensive, but it's still different from going out and sueing other people.
For less than $100, you can buy a little box that converts VGA output to something your TV understands. They are usually used for presentations (PowerPoint), but work fine for general usage, games, etc. as well.
Yes, the Apple toolkits are better than Qt and Gtk+. But you can get equivalent toolkits for Linux already. Just look at GNUStep, Java/Swing, and a variety of other toolkits.
As for Visual Cafe and Powerbuilder, there have been numerous attempts to build similar tools for UNIX and Linux, and they have failed to catch on. I suspect the reason is that those tools are actually not very effective in comparison to programmatic (scripted or declarative) GUI development.
Linux is succeeding in the marketplace precisely because all its components are open and open source. Companies build hardware around it, they hack it, the repackage it, they make money off it.
That, rather than technical differences, is why MacOS X is no threat to Linux. And given how stubborn and wrong-headed Apple's policies have been so far, it doesn't look like that's going to change anytime soon.
The fundemental advantage Apple has over Linux is Apple's ability to choose the "one true way"
I don't view that as an advantage. I like the fact that I can get half a dozen good toolkits for X11. And the X11 architecture is good enough to actually make all that stuff work reasonably well together. Companies like Apple or Microsoft don't even try.
it's pretty clear we're never going to make anything even remotely like MacOS X.
And I'm grateful for that. I'll take the messy, vibrant open source software community over the centrally directed, glitzy, market-research-driven behemoth any time. Your preferences may, of course, differ.
It does come down to numbers, and in my experience, open source software like Linux fares a lot better than Windows when it comes to security. What the reason for that is speculative; it is probably considerably more intangible and indirect than who does security reviews on the code when.
One reason I suspect that close source software is worse off when it comes to security is that a lot of the security risks associated with closed source software like Windows is ill thought out hooks for future enhancements and occasional deliberate back doors; that's the kind of stuff developers catch on an open source project when they look at the daily check-ins. Another is simply that companies like Microsoft are not forced through exposure to their customers to have any consistent coding standards or conventions; for example, their programmers can go on merrily using "gets", even though in an open source project, silly bugs like that would be caught very quickly.
Customers who want to can probably get a secure, sealed license server they can plug into their network. (And to guarantee high uptimes, it will probably be running Linux:-)
No, it's neither faster, nor does it avoid blinking, nor is it the default:
The "clear area" happens automatically on the server, and it need not happen if the rectangle gets repaired quickly enough by the client.
Disabling the clear area doesn't avoid blinking: the area is damaged and a redraw needs to happen anyway. But you will cause unnecessary visual artifacts if you don't set the background color correctly (i.e., to something close to the actual background of the window content for text documents).
Netscape 4 did have some blinking issues, but they were minor and avoidable with a better use of the X11 protocol (among other things, the window background should be set to the actual page background.)
Clear-to-background isn't new or unusual. It has been like that since X10. It's the default when you create a new window through Xlib. And this functionality is why windows have backgrounds in the first place; otherwise, they wouldn't have to. It's only some recent toolkits that mess with this default and cause havoc in the process.
In a network transparent window system, you simply cannot guarantee timely redraws. And even local applications cannot do so. Not allowing the server to clear damaged areas often results in visually very confusing displays. Even if clearing did cause some unnecessary flashing (which it doesn't), disabling it would still be a bad tradeoff from a usability point of view. Mozilla is just broken in that regard, as is Qt. Microsoft Windows also gets this wrong, although it is less critical on Windows. Gtk and Tcl/Tk seem to do it right.
If you really want to avoid flashing, turn on backing store. That's what it is there for. But you have to decide whether the cost is worth it for your application. For Mozilla, it's unnecessary.
I have yet to find an IE-only website that is worth going to. Even among the plug-ins, the only ones that seem useful (and only rarely at that) are Java and Flash4.
The release is getting pretty good, but there are still a few problems. It crashed when converting the Netscape profile, when trying to install Java, it just hangs if it can't write the directory, and rendering is a bit sluggish. Text wrapping in text areas is a bit off (spaces at the beginning of lines).
Most importantly, though, why does Mozilla still insist on changing X11 screen redraw semantics? By default, damaged areas of X11 windows get cleared. Mozilla insists on leaving the damage, leading to very confusing screen displays with parts of one window ghosted in another. Can't this be fixed? Why deviate from the X11 convention in the first place? Windows gets this wrong, and X11 just gets it right.
I think this will hurt Microsoft less than it seems. Most new computers ship with the OS anyway, and Windows already was so cumbersome to install that few people bothered. I think this is mainly something to address the problem of dealers using the same license for multiple units that they ship.
However, I think this is altogether a good thing, because it takes the wind out of Microsoft's argument that every new PC must ship with Windows because otherwise it can only mean piracy. Ultimately, this may help non-Microsoft systems.
OOP is not a single technique. Languages that supposedly support "OOP" differ profoundly by how much they support encapsulation, substitutability, inheritance, safety, isolation, dynamic binding, and other features considered part of "OOP". C++, for example, may have better encapsulation than Smalltalk at the level of the type system, but it allows any object to hack the bits of any other object, even accidentally, through pointer tricks. Smalltalk allows objects to be substituted for each other if they have the same methods, while C++ and Java place very tight restrictions on what can be substituted where.
In fact, I think none of those things are what have made OOP successful. Inheritance and dynamic binding are marginally useful techniques that actually play a role in only a tiny part of most real programs, and there are excellent alternatives to them. (Of course, some methodologies, like the Eiffel/Meyer school of programming use something they call "inheritance" for expressing all sorts of concepts but the same concepts could be expressed just as easily using other constructs, so that doesn't make "inheritance" essential.)
What has made OOP successful is that it encourages its practitioners to build abstractions and to think about how software may evolve and be reused in the future. That would have been possible in reasonable, traditional, procedural languages, but the world needed a gimmick in order to have people listen, and that gimmick was OOP.
However, unlike many people who criticize OOP, I don't believe that "C is all you need" or something like that. I think better languages and better programming constructs are very important for building better software. It is just that the constructs central to OOP don't give you much more functionality than you would already have gotten from a decent type system and function pointers.
But support for runtime safety, garbage collection, reflection, genericity, aspects, and other features is important and allows you to build much more complex software systems much more easily. That's, at least, my experience from using a variety of languages, procedural, functional, dynamic, and object oriented over the last 20 years.
The IRC protocol and conventions need a major overhaul, IMO. On the one hand, they are not robust to many kinds of abusive behavior. On the other hand, they expose the IP addresses and login names of users, creating privacy and security concerns as well without helping protect IRC itself significantly.
Unless IRC gets fixed or replaced by a new open protocol, you are probably going to see more and more chatting move to proprietary protocols and servers.
Well, and as soon as the technology for genetic tests became available, it became blatantly obvious that you could use it to look for specific DNA sequences that correlate with diseases. Using it to look for any particular sequence isn't a "superset".
Which DNA sequence corresponds to color blindness is an empirical fact. That's nice, but it's not an invention, it's a scientific discovery, and it shouldn't be patentable. Applying that knowledge in order to produce a genetic test doesn't involve innovation. So, these kinds of patents are an attempt to patent something that isn't patentable by misrepresenting it to be something else that is.
Slashdot Mirror
The NeXT software was an excellent and practical engineering achievement: it married Smalltalk-like object-oriented technology with the C language and a UNIX kernel. By industry standards (i.e., compared to Windows, MacOS, and UNIX) it also had good tools and a good development environment.
But it wasn't second to none. The NeXT machine, like the Macintosh that preceded it, mostly just took selected aspects from Smalltalk and similar systems and brought the to the masses on a more mainstream platform. But the originals actually arguably had better development tools and a better runtime.
The NeXT machine was a smartly packaged, excellent practical compromise. Jobs deserves a lot of credit for good taste and practicality. But it wasn't breakthrough or even particularly novel technology given the systems that preceded it by nearly a decade. And, of course, reasonable as it was technically, it was still considered too radical and too expensive by industry.
The real missed opportunity of the 1980's was probably Smalltalk. Sun had actually apparently considered bundling Smalltalk-80 with every Sun workstation sold, but the deal fell through. The world of computing would be a very different place if the graduate students of the 1980's and early 1990's had grown up with that software on their Sun workstations.
As someone who has used TOPS, I appreciated the hand it held out to new users. But once you got a little below the surface, I found it was the same as any other system: where it was simple it was simple because it was limited, and where it wasn't limited, it was as complex as anything else. I didn't think it was significantly better overall than UNIX.
In the future, you are probably going to see a lot more people treating 64 bit machines as "32 bit machines with a few extra bits in each word", for just that reason.
Any system one doesn't know well appears "user unfriendly". That's true for mainframes, UNIX machines, Windows, and even the Macintosh.
And to get good at any system requires quite a bit of effort. The only area systems like Macintosh differ in is that they make it easy to get started (good for sales and motivation). Once you are over the initial hump, they are as complex as everything else.
Of course, some systems really do suck, even when you know them well...
That's an artifact of languages like C/C++, which provide 8bit byte addressability and use 8bit bytes extensively for string processing. In many other programming languages, you would hardly notice: they provide abstract string types, automatic packing and unpacking of arrays, and other features.
It's also an artifact of ASCII, in which characters are 8 bits. In fact, 36 bits is nicely divisible by 6, often used as the character size on mainframes.
It is kind of ironic how much the C/C++ programming language has driven the development of hardware. That sad thing is that now that the hardware has adapted so much to C/C++, many nice features that aren't in C/C++ are a lot harder to implement.
Incidentally, 36 bit or 68 bit architectures need not be a big problem for C/C++: you could treat them like byte addressable 32 bit and 64 bit architectures and use the extra 4 bits as type tags. That would actually make compiling languages like Java, Python, Lisp, and others a lot easier.
Of course, UNIX does have lots of problems. Unfortunately, many of the complaints in the "UNIX Hater's Handbook" are not even particularly interesting because they reflect more the lack of experience of the contributors with UNIX than any interesting shortcomings. For insightful UNIX criticism, don't bother with the "UNIX Hater's Handbook".
Furthermore, while the contributors to the "UNIX Hater's Handbook" like to complain a lot, I haven't seen much coming from them to actually improve the situation. Maybe Don can provide some links to that kind of work, rather than promoting his book?
If you have to rely on AltaVista for people to find your site, you're already in trouble.
Yes, Microsoft is trying to muscle their way into that, weaving an intricate web of dependencies among their authoring tools, MS Office, servers, and content they provide, but whether their nefarious plans work out is still an open question. And if they do, the antitrust suit will get new fuel.
Perhaps you can express your displeasure by not letting them index your web site (robots.txt) and not using them for searches.
However, they may have filed them in order to have bargaining chips in case other companies claimed infringement against other patents. That's not purely defensive, but it's still different from going out and sueing other people.
For less than $100, you can buy a little box that converts VGA output to something your TV understands. They are usually used for presentations (PowerPoint), but work fine for general usage, games, etc. as well.
As for Visual Cafe and Powerbuilder, there have been numerous attempts to build similar tools for UNIX and Linux, and they have failed to catch on. I suspect the reason is that those tools are actually not very effective in comparison to programmatic (scripted or declarative) GUI development.
That, rather than technical differences, is why MacOS X is no threat to Linux. And given how stubborn and wrong-headed Apple's policies have been so far, it doesn't look like that's going to change anytime soon.
I don't view that as an advantage. I like the fact that I can get half a dozen good toolkits for X11. And the X11 architecture is good enough to actually make all that stuff work reasonably well together. Companies like Apple or Microsoft don't even try.
it's pretty clear we're never going to make anything even remotely like MacOS X.
And I'm grateful for that. I'll take the messy, vibrant open source software community over the centrally directed, glitzy, market-research-driven behemoth any time. Your preferences may, of course, differ.
One reason I suspect that close source software is worse off when it comes to security is that a lot of the security risks associated with closed source software like Windows is ill thought out hooks for future enhancements and occasional deliberate back doors; that's the kind of stuff developers catch on an open source project when they look at the daily check-ins. Another is simply that companies like Microsoft are not forced through exposure to their customers to have any consistent coding standards or conventions; for example, their programmers can go on merrily using "gets", even though in an open source project, silly bugs like that would be caught very quickly.
In fact, that has been a common practice for tapes in Europe for decades. And it should work even better for CD-RWs.
Customers who want to can probably get a secure, sealed license server they can plug into their network. (And to guarantee high uptimes, it will probably be running Linux :-)
In a network transparent window system, you simply cannot guarantee timely redraws. And even local applications cannot do so. Not allowing the server to clear damaged areas often results in visually very confusing displays. Even if clearing did cause some unnecessary flashing (which it doesn't), disabling it would still be a bad tradeoff from a usability point of view. Mozilla is just broken in that regard, as is Qt. Microsoft Windows also gets this wrong, although it is less critical on Windows. Gtk and Tcl/Tk seem to do it right.
If you really want to avoid flashing, turn on backing store. That's what it is there for. But you have to decide whether the cost is worth it for your application. For Mozilla, it's unnecessary.
I have yet to find an IE-only website that is worth going to. Even among the plug-ins, the only ones that seem useful (and only rarely at that) are Java and Flash4.
Most importantly, though, why does Mozilla still insist on changing X11 screen redraw semantics? By default, damaged areas of X11 windows get cleared. Mozilla insists on leaving the damage, leading to very confusing screen displays with parts of one window ghosted in another. Can't this be fixed? Why deviate from the X11 convention in the first place? Windows gets this wrong, and X11 just gets it right.
However, I think this is altogether a good thing, because it takes the wind out of Microsoft's argument that every new PC must ship with Windows because otherwise it can only mean piracy. Ultimately, this may help non-Microsoft systems.
In fact, I think none of those things are what have made OOP successful. Inheritance and dynamic binding are marginally useful techniques that actually play a role in only a tiny part of most real programs, and there are excellent alternatives to them. (Of course, some methodologies, like the Eiffel/Meyer school of programming use something they call "inheritance" for expressing all sorts of concepts but the same concepts could be expressed just as easily using other constructs, so that doesn't make "inheritance" essential.)
What has made OOP successful is that it encourages its practitioners to build abstractions and to think about how software may evolve and be reused in the future. That would have been possible in reasonable, traditional, procedural languages, but the world needed a gimmick in order to have people listen, and that gimmick was OOP.
However, unlike many people who criticize OOP, I don't believe that "C is all you need" or something like that. I think better languages and better programming constructs are very important for building better software. It is just that the constructs central to OOP don't give you much more functionality than you would already have gotten from a decent type system and function pointers.
But support for runtime safety, garbage collection, reflection, genericity, aspects, and other features is important and allows you to build much more complex software systems much more easily. That's, at least, my experience from using a variety of languages, procedural, functional, dynamic, and object oriented over the last 20 years.
Unless IRC gets fixed or replaced by a new open protocol, you are probably going to see more and more chatting move to proprietary protocols and servers.
Well, and as soon as the technology for genetic tests became available, it became blatantly obvious that you could use it to look for specific DNA sequences that correlate with diseases. Using it to look for any particular sequence isn't a "superset".
Which DNA sequence corresponds to color blindness is an empirical fact. That's nice, but it's not an invention, it's a scientific discovery, and it shouldn't be patentable. Applying that knowledge in order to produce a genetic test doesn't involve innovation. So, these kinds of patents are an attempt to patent something that isn't patentable by misrepresenting it to be something else that is.