The Apple IIgs was not a precursor to the Macintosh. It was released almost three years after the Macintosh was, an upgrade of the Apple IIe, but virtual cripple compared to the Macintosh. A 2.8 Mhz 65816 is a 8/16 bit CPU only a couple of times faster than the original Apple II released in 1977. Where the Macintosh had an 8 Mhz 16/32 bit 68000, probably a dozen times faster.
Programming the Apple IIgs in assembly (to get any speed out of it at all) was a complete nightmare compared to the Mac. In fact the Apple IIgs was probably the most underpowered computer Apple ever made, relative to what it was trying to accomplish. As far as I can tell the sole reason for its existence was to upsell to the elementary education market, which had a *large* installed base of Apple IIs, so compatbility was at a premium.
The Macintosh was pretty nice, but as a home computer it paled in comparison to the Amiga and Atari ST, which were released about the same time as the Apple IIgs. Both had similar 68000 processors, but much better graphics. Macintosh was 512x342 black and white (no grey), the original Amiga did 640x400 in 16 selectable colors, and up to 4096 in some modes. The Atari ST was in between. And of course the Amiga had preemptible multitasking, something that Windows didn't get until 1995, along with a whole host of other features that made it more pleasant to use than most computers today. One could run dozens of small programs (e.g. shells) in 512 KB(!) of ram, with interactivity far exceeding most modern computers with 1,000 times that much memory. Virtual memory is a curse for a desktop.
Of course most PCs circa 1986 are hardly worth mentioning, at least as far as graphics are concerned. Better than a Mac minus the UI, but a pale shadow of the Amiga and Atari ST. The one bit sound wasn't much to speak of either. Amiga/Mac/Atari ST all had 8 bit sampled sound, 4 channels / stereo, with additional 6 bit volume modulation in the Amiga's case, making for a 14 bit dynamic range.
I like what the data say just fine, thank you. You said off by an order of magnitude, implying $15,000 per customer connection on average, over ten years.
You should know that UTOPIA ISPs are currently selling 15 Megabit/sec residential connections for $44/month. How much of that price do you think is being forwarded to UTOPIA? My guess is about $20/month. Xmission (http://www.xmission.com/utopia/index.html) is a good example.
Now of course UTOPIA's long term viability depends on delivering cable television services over their fiber as well.
MStar Metro provides video + data packages ranging from $58 to $90 per month, plus somewhat higher priced voice + video + data packages. Under UTOPIAs current scheme, carriage charges are divided into essentially fixed fees for those three separate categories.
It is worth recognizing that UTOPIA is basically a large, MPLS based Ethernet VLAN. With the proper equipment one can be connected to multiple providers at once, each on a different VLAN #. Voice, and video are generally delivered on separate VLANs, with separate QoS controls than plain old data, although usually one gets some combination of voice, video, and data from the same provider.
Now as far as costs are concerned, relatively rural cities are often cheaper than urban suburbs because the fiber does not have to be buried. In Utah at least, even in rural areas, houses are generally densely located around a town center, and not scattered hither and yon. All those town centers in the remotest sections of Utah are viable candidates, those living three or more miles away from a town center are likely to be more economically served by wireless services for a long time. Wireless ISPs are a big deal in Utah to serve an amazing number of areas, even in urban centers that are not reached by DSL or Cable. (Pretty much Qwest and Comcast, respectively, although Qwest provides DSL carrier services to other ISPs, and Comcast does not).
Cringley's figures are accurate. Please check out these outside plant costs from Utopia Net, the largest municipally owned fiber project in the United States.
The dispute is not about fork(). It is about techniques to avoid copying the contents of I/O buffers from user space to kernel space - aka "zero copy" writes.
Linus (minus the ad hominem characterizations) is arguing that the FreeBSD method of VM based copy on write is a poor performer under real world loads, due to the cost of handling the page faults.
He says that an effective zero copy I/O system requires more explicit coordination between the application and the kernel.
The electrons along the way are certainly affected - but the signal itself is propagated by changes in the electric field. The electric field does not have, nor require any medium - just like light.
More particularly electric signals are not propagated through the sea of free electrons like sound through a gas. The electrons are necessary to deliver actual current at the other end, but the information transfer in a high frequency circuit is virtually all electromagnetic. The electrons vibrate sympathetically, but it is the E-M field that does the work. Collision induced pressure vibrations migrate hundreds of times slower.
Typical electrical signals are propagated by electromagnetic waves in the wire, not by the electrons themselves. Conduction electron velocity is normally hundreds of times slower than electromagnetic waves in the same material, waves which propagate at healthy fraction of the speed of light (same thing as light actually, just with a different wavelength and a reduced speed due to interaction with the transmission medium).
Electrons are practically bystanders in the propagation of a signal down a transmission line. The signal itself is an electromagnetic wave different only in wavelength and frequency from any other electromagnetic wave, including light. They play a crucial role at the ends, but in the middle they just slow things down.
That is the mean electron drift velocity, the absolute electron velocity between collisions is on the order of hundred thousand meters per second, depending on the temperature.
That is still a lot slower than the signal propagation velocity, which is comparable to the speed of light (0.7c or so), subject to reactive loading.
Those are what are called rhetorical questions, mister. The slashdot post links to a Groklaw article that does not even mention the organization. It also wrongly implies that it has any independent legal authority. The choice of arbitrators is generally subject to veto by the other side. Is SCO going to request "summary judgment" even before one is selected?
What would really be 'nice' would be a way to set relative SCHED_OTHER thread priorities on Linux...
Or even better a way to run threads in different security contexts in the same process, with memory protection, visibility control, and so on. The POSIX standards in this area are a real drag...
The Atari ST was nice, especially compared to the PCs of the day, but the OS left a lot to be desired. The Amiga, on the other hand, ran circles around machines released ten years later using a fraction of the resources. I still miss pull down, variable resolution screens, volume:dir/file style path names and the related volume insertion request system, the way you could eject a disk that had open files, even in the middle of a write, and everything would be okay if you put it back in when asked to, etc.
Logical 'assigns' were much more useful than symbolic links too, mostly because they were global. Sort of like network drive letters, except multiple character like volume names. It would be nice if Unix had dynamically updating / delayed binding environment variables that could be used anywhere a file name is accepted...Amiga style volume specifiers would be even better.
Maybe. But you need to demonstrate that is actually the case, legally speaking. It doesn't really matter, though, because different laws apply in each case.
Theoretically, however, we have a *legal* system, not a "whatever the judge thinks is right" system.
AT&T's cooperation with the government in this matter is required by current FCC regulations. The FCC's authority over this derives from CALEA, the Communications Assistance to Law Enforcement Act, a law enacted in October 1994.
The NSA *may* not be doing anything illegal - we have no way of knowing what traffic they are intercepting from the information we have available. All we know is they have the capability to intercept a broad variety of a traffic, a developement which is not particularly surprising. The rule that expanded the scope of CALEA from traditional telecom operators to Internet service providers was published by the FCC last August.
The Internet is not inspired by OSI, more the reverse. Also, regardless of the actual presence or absence of various layers, the OSI layer numbering nomenclature is nearly universal in the networking world, where the alternatives for TCP/IP layer numbering are not even consistent with each other - some have four layers, some have five, etc.
The original 6502 had dynamic register storage (using capacitors, similar to dynamic RAM) that would lose information if the clock was held off for very long. So the CPU clock had to be run at a certain minimum frequency (a few hundred kilohertz IIRC) and though it could be stopped briefly, more than a few microseconds would cause the CPU to crash hard.
Processor cores do not "talk" to each other on such a low level as to be affected one way or the other. Unless instructed otherwise with special fence, barrier, or lock instructions contemporary CPU cores do not order memory operations for the benefit of other cores at all.
The relevant design issue is where do you want to be on the spectrum of core complexity vs. number of cores. If you simplify the cores, you can fit more on a single die, but single threaded performance suffers. If you make the cores more capable, you can fit fewer, but single threaded performance improves. The first strategy befits busy servers, the latter strategy personal computers and workstations. Many workloads aren't effectively parallelizable, so anything reasonable that can be done to improve single threaded performance is usually effort well spent.
There is more than enough "capacity" (bandwidth) to handle video conferencing. What there isn't enough of is end-to-end QoS - and the reason for that has little to do with technology and a lot to do with economics. QoS controls do not cross autonomous systems because there is no economic incentive (read: settlements) for providers to do so.
That was the case about a decade ago, but no longer. Backbones have plenty of configured bandwidth, and modern carrier class routers can handle the load without breaking a sweat.
"RF TV" is accurate. Optical fiber is perfectly capable of carrying RF modulated television signals. The cable companies have been doing it for years with a technique called Hybrid Fiber Coax (HFC). Basically fiber from the headend delivers the same set of RF modulated television signals over fiber to a neighborhood node that amplifies and retransmits the same signal over existing coax.
The Verizon FiOS system is similar, except the RF television signals are carried completely over fiber. Of course, "RF modulated" doesn't mean that the input is analog - one can RF modulate both analog and digital signals. Most modern RF television systems (including FiOS, DVB, and most cable systems) carry MPEG2 encoded video streams. In a decade or two, everyone will likely be running IPTV instead, but it is still an up and coming technology.
Unfortunately, unless you and your neighbors share the same ISP, or live near a major traffic exchange point, it is very likely that the traffic between you will be routed though several nearby states. Try it out some time - traceroute is your friend.
Well, the original Amiga OS is considerably faster than Mac OS 9, the problem is there is no task isolation, memory protection, or security to speak of.
The classic Mac OS is even worse off, because the system API was not designed for a pre-emptively multitasking environment, let alone kernel / user mode separation. Too much application level access to systems globals at fixed addresses in particular.
In any case, whatever the problem is, it cannot be blamed on on adapting to "textual" OS. Adapting an insufficiently forward looking design to the modern world is more like it.
Slashdot Mirror
The Apple IIgs was not a precursor to the Macintosh. It was released almost three years after the Macintosh was, an upgrade of the Apple IIe, but virtual cripple compared to the Macintosh. A 2.8 Mhz 65816 is a 8/16 bit CPU only a couple of times faster than the original Apple II released in 1977. Where the Macintosh had an 8 Mhz 16/32 bit 68000, probably a dozen times faster.
Programming the Apple IIgs in assembly (to get any speed out of it at all) was a complete nightmare compared to the Mac. In fact the Apple IIgs was probably the most underpowered computer Apple ever made, relative to what it was trying to accomplish. As far as I can tell the sole reason for its existence was to upsell to the elementary education market, which had a *large* installed base of Apple IIs, so compatbility was at a premium.
The Macintosh was pretty nice, but as a home computer it paled in comparison to the Amiga and Atari ST, which were released about the same time as the Apple IIgs. Both had similar 68000 processors, but much better graphics. Macintosh was 512x342 black and white (no grey), the original Amiga did 640x400 in 16 selectable colors, and up to 4096 in some modes. The Atari ST was in between. And of course the Amiga had preemptible multitasking, something that Windows didn't get until 1995, along with a whole host of other features that made it more pleasant to use than most computers today. One could run dozens of small programs (e.g. shells) in 512 KB(!) of ram, with interactivity far exceeding most modern computers with 1,000 times that much memory. Virtual memory is a curse for a desktop.
Of course most PCs circa 1986 are hardly worth mentioning, at least as far as graphics are concerned. Better than a Mac minus the UI, but a pale shadow of the Amiga and Atari ST. The one bit sound wasn't much to speak of either. Amiga/Mac/Atari ST all had 8 bit sampled sound, 4 channels / stereo, with additional 6 bit volume modulation in the Amiga's case, making for a 14 bit dynamic range.
I like what the data say just fine, thank you. You said off by an order of magnitude, implying $15,000 per customer connection on average, over ten years.
You should know that UTOPIA ISPs are currently selling 15 Megabit/sec residential connections for $44/month. How much of that price do you think is being forwarded to UTOPIA? My guess is about $20/month. Xmission (http://www.xmission.com/utopia/index.html) is a good example.
Now of course UTOPIA's long term viability depends on delivering cable television services over their fiber as well.
MStar Metro provides video + data packages ranging from $58 to $90 per month, plus somewhat higher priced voice + video + data packages. Under UTOPIAs current scheme, carriage charges are divided into essentially fixed fees for those three separate categories.
It is worth recognizing that UTOPIA is basically a large, MPLS based Ethernet VLAN. With the proper equipment one can be connected to multiple providers at once, each on a different VLAN #. Voice, and video are generally delivered on separate VLANs, with separate QoS controls than plain old data, although usually one gets some combination of voice, video, and data from the same provider.
Current information can be found here:
http://www.utopianet.org/news/teamemail_may06.htm
Now as far as costs are concerned, relatively rural cities are often cheaper than urban suburbs because the fiber does not have to be buried. In Utah at least, even in rural areas, houses are generally densely located around a town center, and not scattered hither and yon. All those town centers in the remotest sections of Utah are viable candidates, those living three or more miles away from a town center are likely to be more economically served by wireless services for a long time. Wireless ISPs are a big deal in Utah to serve an amazing number of areas, even in urban centers that are not reached by DSL or Cable. (Pretty much Qwest and Comcast, respectively, although Qwest provides DSL carrier services to other ISPs, and Comcast does not).
Cringley's figures are accurate. Please check out these outside plant costs from Utopia Net, the largest municipally owned fiber project in the United States.
http://www.utopianet.org/business_case/costs.htm
In the great state of Utah (minus NewSCO), of course.
The dispute is not about fork(). It is about techniques to avoid copying the contents of I/O buffers from user space to kernel space - aka "zero copy" writes.
Linus (minus the ad hominem characterizations) is arguing that the FreeBSD method of VM based copy on write is a poor performer under real world loads, due to the cost of handling the page faults.
He says that an effective zero copy I/O system requires more explicit coordination between the application and the kernel.
The electrons along the way are certainly affected - but the signal itself is propagated by changes in the electric field. The electric field does not have, nor require any medium - just like light.
More particularly electric signals are not propagated through the sea of free electrons like sound through a gas. The electrons are necessary to deliver actual current at the other end, but the information transfer in a high frequency circuit is virtually all electromagnetic. The electrons vibrate sympathetically, but it is the E-M field that does the work. Collision induced pressure vibrations migrate hundreds of times slower.
Typical electrical signals are propagated by electromagnetic waves in the wire, not by the electrons themselves. Conduction electron velocity is normally hundreds of times slower than electromagnetic waves in the same material, waves which propagate at healthy fraction of the speed of light (same thing as light actually, just with a different wavelength and a reduced speed due to interaction with the transmission medium).
Electrons are practically bystanders in the propagation of a signal down a transmission line. The signal itself is an electromagnetic wave different only in wavelength and frequency from any other electromagnetic wave, including light. They play a crucial role at the ends, but in the middle they just slow things down.
That is the mean electron drift velocity, the absolute electron velocity between collisions is on the order of hundred thousand meters per second, depending on the temperature.
That is still a lot slower than the signal propagation velocity, which is comparable to the speed of light (0.7c or so), subject to reactive loading.
"give away" is just a little exaggeration, don't you think?
Novell, I mean.
Those are what are called rhetorical questions, mister. The slashdot post links to a Groklaw article that does not even mention the organization. It also wrongly implies that it has any independent legal authority. The choice of arbitrators is generally subject to veto by the other side. Is SCO going to request "summary judgment" even before one is selected?
What would really be 'nice' would be a way to set relative SCHED_OTHER thread priorities on Linux...
Or even better a way to run threads in different security contexts in the same process, with memory protection, visibility control, and so on. The POSIX standards in this area are a real drag...
What in the world does this have to do with the International Chamber of Commerce? What authority would they have to bar SCO from doing anything?
The Atari ST was nice, especially compared to the PCs of the day, but the OS left a lot to be desired. The Amiga, on the other hand, ran circles around machines released ten years later using a fraction of the resources. I still miss pull down, variable resolution screens, volume:dir/file style path names and the related volume insertion request system, the way you could eject a disk that had open files, even in the middle of a write, and everything would be okay if you put it back in when asked to, etc.
Logical 'assigns' were much more useful than symbolic links too, mostly because they were global. Sort of like network drive letters, except multiple character like volume names. It would be nice if Unix had dynamically updating / delayed binding environment variables that could be used anywhere a file name is accepted...Amiga style volume specifiers would be even better.
Maybe. But you need to demonstrate that is actually the case, legally speaking. It doesn't really matter, though, because different laws apply in each case.
Theoretically, however, we have a *legal* system, not a "whatever the judge thinks is right" system.
AT&T's cooperation with the government in this matter is required by current FCC regulations. The FCC's authority over this derives from CALEA, the Communications Assistance to Law Enforcement Act, a law enacted in October 1994.
The NSA *may* not be doing anything illegal - we have no way of knowing what traffic they are intercepting from the information we have available. All we know is they have the capability to intercept a broad variety of a traffic, a developement which is not particularly surprising. The rule that expanded the scope of CALEA from traditional telecom operators to Internet service providers was published by the FCC last August.
The Internet is not inspired by OSI, more the reverse. Also, regardless of the actual presence or absence of various layers, the OSI layer numbering nomenclature is nearly universal in the networking world, where the alternatives for TCP/IP layer numbering are not even consistent with each other - some have four layers, some have five, etc.
The original 6502 had dynamic register storage (using capacitors, similar to dynamic RAM) that would lose information if the clock was held off for very long. So the CPU clock had to be run at a certain minimum frequency (a few hundred kilohertz IIRC) and though it could be stopped briefly, more than a few microseconds would cause the CPU to crash hard.
Processor cores do not "talk" to each other on such a low level as to be affected one way or the other. Unless instructed otherwise with special fence, barrier, or lock instructions contemporary CPU cores do not order memory operations for the benefit of other cores at all.
The relevant design issue is where do you want to be on the spectrum of core complexity vs. number of cores. If you simplify the cores, you can fit more on a single die, but single threaded performance suffers. If you make the cores more capable, you can fit fewer, but single threaded performance improves. The first strategy befits busy servers, the latter strategy personal computers and workstations. Many workloads aren't effectively parallelizable, so anything reasonable that can be done to improve single threaded performance is usually effort well spent.
There is more than enough "capacity" (bandwidth) to handle video conferencing. What there isn't enough of is end-to-end QoS - and the reason for that has little to do with technology and a lot to do with economics. QoS controls do not cross autonomous systems because there is no economic incentive (read: settlements) for providers to do so.
That was the case about a decade ago, but no longer. Backbones have plenty of configured bandwidth, and modern carrier class routers can handle the load without breaking a sweat.
In my experience, the average ISP HTTP proxy slows things down considerably. May be if they kept everything in RAM...
"RF TV" is accurate. Optical fiber is perfectly capable of carrying RF modulated television signals. The cable companies have been doing it for years with a technique called Hybrid Fiber Coax (HFC). Basically fiber from the headend delivers the same set of RF modulated television signals over fiber to a neighborhood node that amplifies and retransmits the same signal over existing coax.
The Verizon FiOS system is similar, except the RF television signals are carried completely over fiber. Of course, "RF modulated" doesn't mean that the input is analog - one can RF modulate both analog and digital signals. Most modern RF television systems (including FiOS, DVB, and most cable systems) carry MPEG2 encoded video streams. In a decade or two, everyone will likely be running IPTV instead, but it is still an up and coming technology.
Unfortunately, unless you and your neighbors share the same ISP, or live near a major traffic exchange point, it is very likely that the traffic between you will be routed though several nearby states. Try it out some time - traceroute is your friend.
Well, the original Amiga OS is considerably faster than Mac OS 9, the problem is there is no task isolation, memory protection, or security to speak of.
The classic Mac OS is even worse off, because the system API was not designed for a pre-emptively multitasking environment, let alone kernel / user mode separation. Too much application level access to systems globals at fixed addresses in particular.
In any case, whatever the problem is, it cannot be blamed on on adapting to "textual" OS. Adapting an insufficiently forward looking design to the modern world is more like it.