Copyright law, when it was first enacted, did not protect artists from businessmen. It protected businessmen from each other in order to allow one business to invest the large amounts of money necessary to print a run without fear of being undercut by a rival.
The printing press was never a threat to writers. It *was* a threat to scribes. Imagine if the printing press had existed in aristotle's time without any copyright laws in place. Net effect: aristotle's work gets printed and seen by more people, improving his stature in society. I can't think of any economic impact it would have had on him.
As far as Metallica being millionares goes, keep in mind that even for a successful artist you'd be lucky to get more than 15% of the take. Actors, script writers and directors all get a tiny portion of the million dollar industry that is film making. The bulk of the money goes to those people who invested the money to get the work made/distributed. Which is fine, btw, as far as I'm concerned (they took the financial risk, so they should be financially rewarded).... unless that investment was unnecessary.
Ironically, while Stephen King might own the copyright to his work, but the majority of creators of copyrighted have no such luxury.
You miss the point though. Amazingly, you can be reimbursed as a writer without stringent enforcement copyright laws. Here's a thought: it'd be trivial to post Stephen King's book on Gnapster or Freenet, and thereby avoid paying for it. Instead, people ARE paying for it for two reasons:
They feel he has given them $2 worth of value and would give it to him regardless of the fact that they could get around it.
They want to see more of the same work, and by supporting him they encourage him to continue (and if he was poor they'd be providing him with the ability to continue his work without seeking other employment).
Similar principles apply to most forms of art work. One way to look at it is this: writers, musicians, researchers, sculptors, painters, etc. all existed prior to the existence of copyrights. So somehow it's possible. On the flip side, publishing companies, recording companies, etc. didn't. Copyright makes it possible for those kinds of businesses to exist.
Now, publishing and recording companies actually have, in the past, served a very useful purpose for society, namely they broadened the exposure of various works of writing or music. They were the most efficient way to get the job done. However, with the growth of the Internet, there is now an even MORE efficient means of pushing around intellectual information. Unfortunately, publishing companies and recording companies are slowing this process around. Ironically, where they were once an accelerant they now are an impedement.
I'm not saying that these kinds of companies need to go away, as there's a lot more to either business than just printing and shipping books and cd's. However, owning the material they print one of the ways they make their money, and that aspect of things has to change because it no longer is beneficial to society.
Actually, Java's approach to parallelism is very hard to map to a VLIW architecture. Generally speaking you use VLIW to execute a ton of instructions from one thread at once. Threads are too high level and typically execute completely asynchronously from each other (as opposed to VLIW where instructions typically execute lock-step together).
What you really want are languages like High Performance Fortran that have the programmer declare segments of code that can be executed in parallel (not quite the same as threads).
The old rule about open source: if you don't like how things are progressing, stop whining and start coding.
I'm sure lots of the WSP members don't have the necessary technical skills to contribute to Mozilla. Fine, to that end they should recognize that they have no idea how much work is involved and are in no position to judge. Those members that DO have the necessary technical skills are in a great position to judge the project's performance (and as such should know better), but rather than whining about it they should contribute to the work.
Unless I COMPLETELY missed something, Wordperfect for Linux uses libwine, not WINE. Wordperfect for Linux is NOT Wordperfect for Windows + WINE but an actual version of the Wordperfect codebase which has been targeted for Linux x86 and linked with libwine. Indeed, I believe you'll find it quite impossible to get Wordperfect for Linux to run on Windows, and if you run Wordperfect for Windows in Wine it'll behave differently than Wordperfect for Linux.
Hybrid vehicles get to drive in the carpool lane in L.A. now. If you drive to work by yourself in L.A., you'll realise that this alone could save you an hour a day. Depending on how much you get paid this could pay for itself in a matter of months.
Who cares? Users certainly don't care as the kernel is totally invisible to them. Developers don't care as there is no need to touch any Mach or BSD specific stuff when writing applications for OS-X (on either Cocoa or Carbon). The only people who care are geeks who think the kernel actually makes a spit of difference to anyone aside from the people that actually work on the OS services.
You're missing the point. The original post said that ESR's description as UI being something which is an add-on to an OS was incorrect. The original post said that usability had to be the overriding priority from the begginning of the OS-design process. My point is that this is not true for MacOS X, as it's built from the Mach/BSD basis which was not focused on usability, something you've only reinforced.
I myself don't care what the foundation is that MacOS X is built on, so long as it's a solid, efficient, and flexible. I don't consider the UI to be part of the foundation. Certainly good usability is an exceptionally important part of the value of a computer system, and I might even agree that it's more important than the foundation, but this doesn't make usability the overriding design principle for the foundation.
As far as whether users care about good OS services, I would argue that all the statements about how wonderful MacOS X Server was at handling high server loads and tons of multimedia, the excitement about MacOS X's improved stability, etc. are all indications of the value of good OS services. For the longest time better OS services were one of the touted advantages of the Macintosh platform over windows. You can't change the rules just because you fall behind.
It's not the first time someone thought they'd come up with a new, ultra-fast encryption algorithm which proved to be completely useless once it was rigorously tested by the outside world.
Having tons of keys to encrypt mutliple parts of a piece of music is essentially indistinguishable from just using one really long key to encrypt the same material. Perhaps this helps skirt encryption export laws, but beyond that it really doesn't buy you significantly better protection.
It's quite likely there is a brute force attack that allows you to attack all keys simultaneously. Indeed, from the sounds of it you would think the individual key lengths would be quite short, making this approach much more viable.
I see nothing with this technique that provides protections for music after it's been decrypted, so I don't know why they are talking about applying it to music specifically. There must be something more that the article missed. Nonetheless, this doesn't prevent people from intercepting the playback signal and recording that. For that you'll need tamper-proof speakers.
Can you imagine the key-management insanity of generating and transmitting all these keys? I would imagine it would signficantly increase the total download size of whatever you were grabbing to the point where people would get annoyed. They say that this is based on PK-crypto, but I don't see how it'd would work (does someone publish 50,000 personal public keys or something? doesn't this crowd the keyspace?).
Umm... OSX is finally catching up with where every Unix has been for quite some time in terms of technical capability. On top of that OSX is not out there yet, so 99.9% of Mac users are using the very crufty MacOS 9 or less. ESR's comments about the state of the OS seem accurate to me, and are consistent with most Mac developers I've talked with (John Carmack would seem to agree as well).
As far as the GUI thing goes.... MacOS X is built on a Mach/BSD kernel, similar in many ways to Digital Unix. However, there can be little question that part of MacOS X was a porting of the MacOS GUI to a modern OS kernel. So it is very MUCH an add on. Indeed, this is the way it should be, otherwise MacOS X will inevitably be outdated when touch screens, voice access, etc. come in to the fore. Indeed, MacOS could arguably be described as NeXTStep 5.0 with a MacOS look-and-feel. Either way, the kernel of MacOS X is indeed a Mach kernel, and it's safe to say that usability was not the first priority when that thing was built.;-)
I properly setup escrow would be protected even in the event of a buyout. Certainly things like pension funds and the like can be setup so they can't be touched even during a takeover. Similar things could be done with data. Also note that expiration terms would make the data less valuable anyway.
NT's BSOD problems lie almost entirely in device drivers these days. My suggestion would be to write some kind of device driver who's sole purpose was to crash the machine. There are lots of ways to do this, but probably the best is to just pass the kernel a bad pointer.
It used to be pretty easy to crash NT by simply stressing IIS, but I haven't had much luck with that of late. My suspicion is that Active Directory Services is the new IIS (in the sense that it's new, delivers lots of functionality that is relied upon by core components). So probably writing a program that recursively adds itself to ADS is probably pretty effective.;-)
Out of curiosity, what the heck do you think the NEC chip is? Sure, it's not x86 or 68k, but then I've heard rumours of CPU's built on other instruction sets.;-)
Ironically, my argument is strengthened by the Actel part in a context that I'd given up on (DSP-like function). Instead of using a fixed-purpose ASIC they programmed an FPGA to behave like one. General purpose hardware wins again!
MP3 work is typically exactly the kind of task you want to have a DSP for. That being said, you might want to open up your MP3 player and see just how "specific" the hardware is. Lots of them have StrongArm chips in them. Almost all of them are either general purpose CPU's or general purpose DSP/CPU hybrids. This is why most of the players can support multiple compression formats.
The thing that's killing the WinCE/PPC unit is WinCE, not the PPC.
True enough, if you CPU is already loaded you're screwed, but that's what SMP is for.;-) Seriously, by using a general purpose CPU you tend to have more flexibility and power available to you. It's amazing what a difference it makes.
Your example of the hardware excelleration is interesting, particularly since the direction they are going tends to be towards full-bore CPU for graphics (hence the silly term GPU), much as SGI did ages ago. To the extent that this is not true I'd argue a lot of the lower-end graphics stuff is really not processing (the kind of thing that would burn up a CPU), but rather some simple ASIC functionality.
Basically the one area where CPU's can get their butts kicked is DSP. However, even against a DSP, after the DSP has worked on the data it needs to be handed up to the CPU, whereas when you use a CPU it's basically right there. Depending on what you're doing (and this seems like such a case) this may be a significant advantage.
Another way to look at it is to compare using your CPU for PPP compression/decompression vs. dedicated hardware. Your CPU has more power, can adjust how much power it applies to allow better application performance as the situation justifies it, and can easily have new algorithms installed.
The one thing that WOULD be cool would be if this was all done in the highly-parallel MMU of a CPU.
Ok. Even if it's done in hardware this kind of thing has been around for quite some time. The Hobbit processors do this, along with a slew of other embedded processors.
One thing to think about is how much faster is a hardware implementation really? Time and time again general purpose CPU's seem to kick the butts of dedicated hardware in all but the most esoteric cases (like encryption). If it's done by the CPU then the data you need is already in the L1 cache and possibly in registers, all while avoiding pain for the outer caches. Then add in architectures like EPIC which have nothing better to do with some of their units anyway...
I don't know, I don't know if IBM's claims will pan out.
This kind of technology has been around for ages, and it's been sold commercially. Products like RamDoubler and the like were very popular during the 90's for exactly this reason.
I don't understand what's supposed to be unique about this technology.
Actually, what you described is very standard stuff in the application server market. It may sound like new coming from Microsoft, but it's not. Most CORBA ORB's will provide you with all this, but you'll find the fastest growing market for this technology is Java2 Enterprise Edition servers like Weblogic and iPlanet Application Server.
Of course, there's the secondary matter about how easy any of these platforms is to actually get something done, and I'd have to say, J2EE wins hands down here. You can download a trial edition of Weblogic from their website. Give it a try.
Actually, truth be told even an old Pentium-II 233 can keep a Samba network VERY busy.
Mutliple CPU's can be helpful on a minor scale for a couple of reasons:
Fewer context switches. If you have a LOT of processes running, it's amazing how much CPU time gets lost to context switches. SMP helps reduce this overhead because it reduces the number of processes per CPU. Of course, it also increases context switch time, so you have to balance it.
Better interrupt handling. On most PC's, the interrupt hardware sucks. This is important for a network server because it usually gets hit by quite a bit of interrupts between disk and network cards. SMP systems tend to have APIC and other fancy interrupt handling mechanisms, although some of the newer single CPU boards are now incorporating these features.
Better I/O subsystems. In general, SMP motherboards tend to have better I/O subsystems, because with multiple CPU's it's much easier to stress the I/O subsystem. Things like 64-bit 66MHz PCI can really help a serer. Of course, if you get a really fancy single CPU system this is less of a factor.
Faster authentication. Authentication can actually be the bulk of the latency people encounter when accessing data from an SMB server. If you are using the SMB box as a domain controller then you are going to have a lot of CPU performance lost to authentication. Being a domain controller is heavy duty work (so much so that Microsoft suggests secondary domain controllers for large networks). This can really slow things down. Of course, the best solution is to have a seperate box dedicated to doing authentiction, but if not, this is one area that will take advantage of CPU performance.
Your biggest performance improvements will probably come from doing a few basic things right:
Get a(some) very nice NIC(s). For maximum performance get something which will handle the IP stack on board.
Go with a fancy disk subsystem. If you really need performance go with Ultra-160 SCSI, preferably hooked up to 64-bit 66MHz PCI. Think about RAID, think about multiple controllers.
RAM. Lots of it and as fast as possible. This will increase the disk cache and how many processes/sockets you can have going at once.
Ease up on the language wars eh? Every language has it's pros and cons. C++ wouldn't be my first choice as a teaching language, but there are worse options. Hell, there was a time when Ada was popular. Fortran 77 was also popular.
Everyone want's to tout their favourite language (and your advocacy of Pascal is a good example), but in reality, programming languages are not the essence of what you teach to programmers anyway. Heck, most of my comp. sci classes in University would introduce a language to you during the first week, expecting you to be able to use it well enough to cover the material in the course. This was really not a problem, because in the end design techniques don't necessarily require you to excercise esoteric language features (they're mostly there to frustrate developers and compiler designers;-).
Nothing against C++, but equating the tool is laughable. Syntactically, they are similar, but if you've used both, you'll know that they are different. If nothing else having non-pointer based objects, no garbage collection, and templates significantly changes how one does programming.
Realistically, if they were so similar, Java wouldn't have had much of a chance of being successful.
You know, you have a point. I mean, programs which just display files are basically not that important. Things like MS-Word, Excel, Emacs, Acrobat, Quicktime, are essentially of no consequence.;-)
Seriously, browsers are becoming the defacto interface to just about everything. They are much more than just parsing and displaying HTML, which most Linux browsers do just fine. Browsers are software platforms, hosting scripting languages, multi-media plugins, and Java programs. On top of that they are probably the most commonly used piece of software that speaks a network protocl, so they also dictate a lot of what goes on over networks.
Another way to look at it would be to list all the things one can do with a browser. We're talking banking, shopping, research, communication, tax filing, etc., etc. Just think of how much you can do with an iOpener, which is essentially a "browser terminal".
Browsers are about as small potatoes today as GUI's were in the 90's. That is to say that they aren't everything, they're the only thing.;-)
Slashdot Mirror
Copyright law, when it was first enacted, did not protect artists from businessmen. It protected businessmen from each other in order to allow one business to invest the large amounts of money necessary to print a run without fear of being undercut by a rival.
The printing press was never a threat to writers. It *was* a threat to scribes. Imagine if the printing press had existed in aristotle's time without any copyright laws in place. Net effect: aristotle's work gets printed and seen by more people, improving his stature in society. I can't think of any economic impact it would have had on him.
As far as Metallica being millionares goes, keep in mind that even for a successful artist you'd be lucky to get more than 15% of the take. Actors, script writers and directors all get a tiny portion of the million dollar industry that is film making. The bulk of the money goes to those people who invested the money to get the work made/distributed. Which is fine, btw, as far as I'm concerned (they took the financial risk, so they should be financially rewarded).... unless that investment was unnecessary.
Ironically, while Stephen King might own the copyright to his work, but the majority of creators of copyrighted have no such luxury.
You miss the point though. Amazingly, you can be reimbursed as a writer without stringent enforcement copyright laws. Here's a thought: it'd be trivial to post Stephen King's book on Gnapster or Freenet, and thereby avoid paying for it. Instead, people ARE paying for it for two reasons:
Similar principles apply to most forms of art work. One way to look at it is this: writers, musicians, researchers, sculptors, painters, etc. all existed prior to the existence of copyrights. So somehow it's possible. On the flip side, publishing companies, recording companies, etc. didn't. Copyright makes it possible for those kinds of businesses to exist.
Now, publishing and recording companies actually have, in the past, served a very useful purpose for society, namely they broadened the exposure of various works of writing or music. They were the most efficient way to get the job done. However, with the growth of the Internet, there is now an even MORE efficient means of pushing around intellectual information. Unfortunately, publishing companies and recording companies are slowing this process around. Ironically, where they were once an accelerant they now are an impedement.
I'm not saying that these kinds of companies need to go away, as there's a lot more to either business than just printing and shipping books and cd's. However, owning the material they print one of the ways they make their money, and that aspect of things has to change because it no longer is beneficial to society.
Actually, Java's approach to parallelism is very hard to map to a VLIW architecture. Generally speaking you use VLIW to execute a ton of instructions from one thread at once. Threads are too high level and typically execute completely asynchronously from each other (as opposed to VLIW where instructions typically execute lock-step together).
What you really want are languages like High Performance Fortran that have the programmer declare segments of code that can be executed in parallel (not quite the same as threads).
The old rule about open source: if you don't like how things are progressing, stop whining and start coding.
I'm sure lots of the WSP members don't have the necessary technical skills to contribute to Mozilla. Fine, to that end they should recognize that they have no idea how much work is involved and are in no position to judge. Those members that DO have the necessary technical skills are in a great position to judge the project's performance (and as such should know better), but rather than whining about it they should contribute to the work.
Unless I COMPLETELY missed something, Wordperfect for Linux uses libwine, not WINE. Wordperfect for Linux is NOT Wordperfect for Windows + WINE but an actual version of the Wordperfect codebase which has been targeted for Linux x86 and linked with libwine. Indeed, I believe you'll find it quite impossible to get Wordperfect for Linux to run on Windows, and if you run Wordperfect for Windows in Wine it'll behave differently than Wordperfect for Linux.
Hybrid vehicles get to drive in the carpool lane in L.A. now. If you drive to work by yourself in L.A., you'll realise that this alone could save you an hour a day. Depending on how much you get paid this could pay for itself in a matter of months.
Could you imagine the joy of having designated areas where both cell phones don't ring AND babies don't cry????
Can you think of any software publishers who have used copyright for anti-competitive purposes? ;-)
You're missing the point. The original post said that ESR's description as UI being something which is an add-on to an OS was incorrect. The original post said that usability had to be the overriding priority from the begginning of the OS-design process. My point is that this is not true for MacOS X, as it's built from the Mach/BSD basis which was not focused on usability, something you've only reinforced.
I myself don't care what the foundation is that MacOS X is built on, so long as it's a solid, efficient, and flexible. I don't consider the UI to be part of the foundation. Certainly good usability is an exceptionally important part of the value of a computer system, and I might even agree that it's more important than the foundation, but this doesn't make usability the overriding design principle for the foundation.
As far as whether users care about good OS services, I would argue that all the statements about how wonderful MacOS X Server was at handling high server loads and tons of multimedia, the excitement about MacOS X's improved stability, etc. are all indications of the value of good OS services. For the longest time better OS services were one of the touted advantages of the Macintosh platform over windows. You can't change the rules just because you fall behind.
Reasons why this is not a big deal:
Umm... OSX is finally catching up with where every Unix has been for quite some time in terms of technical capability. On top of that OSX is not out there yet, so 99.9% of Mac users are using the very crufty MacOS 9 or less. ESR's comments about the state of the OS seem accurate to me, and are consistent with most Mac developers I've talked with (John Carmack would seem to agree as well).
;-)
As far as the GUI thing goes.... MacOS X is built on a Mach/BSD kernel, similar in many ways to Digital Unix. However, there can be little question that part of MacOS X was a porting of the MacOS GUI to a modern OS kernel. So it is very MUCH an add on. Indeed, this is the way it should be, otherwise MacOS X will inevitably be outdated when touch screens, voice access, etc. come in to the fore. Indeed, MacOS could arguably be described as NeXTStep 5.0 with a MacOS look-and-feel. Either way, the kernel of MacOS X is indeed a Mach kernel, and it's safe to say that usability was not the first priority when that thing was built.
I properly setup escrow would be protected even in the event of a buyout. Certainly things like pension funds and the like can be setup so they can't be touched even during a takeover. Similar things could be done with data. Also note that expiration terms would make the data less valuable anyway.
If personal information was kept in some kind of escrow system with guarunteed expiries and the like.
;-)
Ultimately you're always vulnerable to bancrupcies, but presumably a places like Verisign are more likely to exist than Boo.com...
NT's BSOD problems lie almost entirely in device drivers these days. My suggestion would be to write some kind of device driver who's sole purpose was to crash the machine. There are lots of ways to do this, but probably the best is to just pass the kernel a bad pointer.
;-)
It used to be pretty easy to crash NT by simply stressing IIS, but I haven't had much luck with that of late. My suspicion is that Active Directory Services is the new IIS (in the sense that it's new, delivers lots of functionality that is relied upon by core components). So probably writing a program that recursively adds itself to ADS is probably pretty effective.
Out of curiosity, what the heck do you think the NEC chip is? Sure, it's not x86 or 68k, but then I've heard rumours of CPU's built on other instruction sets. ;-)
Ironically, my argument is strengthened by the Actel part in a context that I'd given up on (DSP-like function). Instead of using a fixed-purpose ASIC they programmed an FPGA to behave like one. General purpose hardware wins again!
MP3 work is typically exactly the kind of task you want to have a DSP for. That being said, you might want to open up your MP3 player and see just how "specific" the hardware is. Lots of them have StrongArm chips in them. Almost all of them are either general purpose CPU's or general purpose DSP/CPU hybrids. This is why most of the players can support multiple compression formats.
The thing that's killing the WinCE/PPC unit is WinCE, not the PPC.
True enough, if you CPU is already loaded you're screwed, but that's what SMP is for. ;-) Seriously, by using a general purpose CPU you tend to have more flexibility and power available to you. It's amazing what a difference it makes.
Your example of the hardware excelleration is interesting, particularly since the direction they are going tends to be towards full-bore CPU for graphics (hence the silly term GPU), much as SGI did ages ago. To the extent that this is not true I'd argue a lot of the lower-end graphics stuff is really not processing (the kind of thing that would burn up a CPU), but rather some simple ASIC functionality.
Basically the one area where CPU's can get their butts kicked is DSP. However, even against a DSP, after the DSP has worked on the data it needs to be handed up to the CPU, whereas when you use a CPU it's basically right there. Depending on what you're doing (and this seems like such a case) this may be a significant advantage.
Another way to look at it is to compare using your CPU for PPP compression/decompression vs. dedicated hardware. Your CPU has more power, can adjust how much power it applies to allow better application performance as the situation justifies it, and can easily have new algorithms installed.
The one thing that WOULD be cool would be if this was all done in the highly-parallel MMU of a CPU.
Ok. Even if it's done in hardware this kind of thing has been around for quite some time. The Hobbit processors do this, along with a slew of other embedded processors.
One thing to think about is how much faster is a hardware implementation really? Time and time again general purpose CPU's seem to kick the butts of dedicated hardware in all but the most esoteric cases (like encryption). If it's done by the CPU then the data you need is already in the L1 cache and possibly in registers, all while avoiding pain for the outer caches. Then add in architectures like EPIC which have nothing better to do with some of their units anyway...
I don't know, I don't know if IBM's claims will pan out.
This kind of technology has been around for ages, and it's been sold commercially. Products like RamDoubler and the like were very popular during the 90's for exactly this reason.
I don't understand what's supposed to be unique about this technology.
Actually, what you described is very standard stuff in the application server market. It may sound like new coming from Microsoft, but it's not. Most CORBA ORB's will provide you with all this, but you'll find the fastest growing market for this technology is Java2 Enterprise Edition servers like Weblogic and iPlanet Application Server.
Of course, there's the secondary matter about how easy any of these platforms is to actually get something done, and I'd have to say, J2EE wins hands down here. You can download a trial edition of Weblogic from their website. Give it a try.
NO!!! It's Emacs!! ;-)
Actually, truth be told even an old Pentium-II 233 can keep a Samba network VERY busy.
Mutliple CPU's can be helpful on a minor scale for a couple of reasons:
Your biggest performance improvements will probably come from doing a few basic things right:
Ease up on the language wars eh? Every language has it's pros and cons. C++ wouldn't be my first choice as a teaching language, but there are worse options. Hell, there was a time when Ada was popular. Fortran 77 was also popular.
;-).
Everyone want's to tout their favourite language (and your advocacy of Pascal is a good example), but in reality, programming languages are not the essence of what you teach to programmers anyway. Heck, most of my comp. sci classes in University would introduce a language to you during the first week, expecting you to be able to use it well enough to cover the material in the course. This was really not a problem, because in the end design techniques don't necessarily require you to excercise esoteric language features (they're mostly there to frustrate developers and compiler designers
Nothing against C++, but equating the tool is laughable. Syntactically, they are similar, but if you've used both, you'll know that they are different. If nothing else having non-pointer based objects, no garbage collection, and templates significantly changes how one does programming.
Realistically, if they were so similar, Java wouldn't have had much of a chance of being successful.
You know, you have a point. I mean, programs which just display files are basically not that important. Things like MS-Word, Excel, Emacs, Acrobat, Quicktime, are essentially of no consequence. ;-)
;-)
Seriously, browsers are becoming the defacto interface to just about everything. They are much more than just parsing and displaying HTML, which most Linux browsers do just fine. Browsers are software platforms, hosting scripting languages, multi-media plugins, and Java programs. On top of that they are probably the most commonly used piece of software that speaks a network protocl, so they also dictate a lot of what goes on over networks.
Another way to look at it would be to list all the things one can do with a browser. We're talking banking, shopping, research, communication, tax filing, etc., etc. Just think of how much you can do with an iOpener, which is essentially a "browser terminal".
Browsers are about as small potatoes today as GUI's were in the 90's. That is to say that they aren't everything, they're the only thing.