Couldn't (alpha) have (alpha) something (alpha) to (alpha) do (alpha) with (alpha) HP (alpha) stabbing (alpha) another (alpha) processor (alpha) in (alpha) the (alpha) back... one that didn't need heroic measures to get top of the line performance...
that merely using higher level languages to abstract yourself away from how the machine executes, won't make a blind bit of difference
Sure it will.
Well, first of all, it's not so much "using a higher level language", it's "using a language that guarantees certain behaviour". There's some quite low-level languages that have bounds checking and type checking in the definition of the language, and quite high level ones that don't.
Anyway...
Just because it doesn't prevent all failure modes that may be exploited, it eliminates one possible failure mode that may be exploited. That increases the security and robustness of the system as a whole.
The counterargument that the bad guys will just exploit something else is pretty much dead. It's like a Windows user saying it's OK for IE to have really bad security, because if you fix that they'll just use social engineering instead. Just because there's other avenues of attack doesn't mean that improving one of the barricades isn't a good thing.
So, like, when I said "fixing the interfaces isn't the whole solution" I didn't mean "don't fix the interfaces", I meant "still fix the deeper exploits, if you can".
just because you validate in your program at the initial user input, someone might use your lower level functions without doing so, so every function must (complexity aside) check its input
Yes, that's right, I had no intention of implying otherwise, and I apologise if I led you to make that inference.
OK, when people talk about "input validation" I start worrying about whether they're talking about Perl "taint mode". (shudder)
But the point I was getting at was that there's some components that are doing such complex things with the input that the only way to validate them is to duplicate them. And zlib's one of them.
Input is just one interface... every internal interface in a system also needs to be designed so that it only accepts known safe or encapsulated data, and if there's limits on safe input they need to be something that the upper layer can reasonably check without having to effectively replicate the component it's passing the data to.
Let's say, for example, that this overflow involves a pathological artificially created compressed stream. To test for it, you may have to implement most of the algorithms in zlib. To test for it in an image file, you'd have to implement a decoder for that image format that would at least extract the compressed streams to pass to zlib... as well as implementing zlib.
If the problem in the underlying component is a bug that involves the structure of a complexly encoded data stream, it can't really be described in the input or any internal interfaces. Which means that you're not going to catch it with input validation.
Which means that while resiliant interface design is important, it's not going to be enough to block deep attacks. The only way to do that is to make the components themselves secure and resilient. And depending on input validation can cause problems, just ask anyone with an unusual surname.
1. Dynamic linking carries its own set of security issues and its own history of exploits.
2. Dynamic linking is pretty much the norm these days anyway. It's definitely the norm on the two big closed-source platforms where this might be an issue: Windows and Macintosh.
3. Where static linking is common, it's also common to have either source or relocatable object so you can rebuild or relink anyway.
But given that dynamic linking really is the norm, I'm not sure I get what you're talking about. Who are the "so many people"?
The problem with writing code in a typesafe language is, as you have noted, integration with libraries. The main reason that so much code is writen in C is that C needs pretty close to zero runtime support.
Not only do languages like Lisp need a fairly extensive runtime, they need dynamic memory allocation and garbage collection, and when you share garbage-collected objects between languages (potentially between multiple languages each with their own allocation models) you're asking for a whole new kind of hurt.
Find a type-safe language where the generated code is standalone and has an easy mechanism for importing and exporting data, and you'll get some traction. And much as I like lisp-family languages myself, that's not the way to go... nor is anything like Java. Perhaps there's something in the Modula family that will work, though my own experience with Modula 2 has not been encouraging.
Well, almost nobody. Publishers aren't generally seeing any value in eBook rights, and are sitting on them... except for Baen Books, who are going into non-DRMed eBooks in a big way.
I've bought over 60 eBooks from Baen and over 600 non-DRMed eBooks (mostly short stories) from Fictionwise, and one DRMed eBook (the annotated version of A Fire Upon the Deep)... and the DRM on that was so annoying to deal with I ended up finding a pirated copy online to sit alongside it.
Last time I played with jails there was no strict resource control and separation, so I don't see this as a commercially viable technology for virtual hosting.
Yes, you can DOS other jails by forkbombing yourself. There's no CPU accountability, but if you're CPU-bound you need a dedicated host anyway... the CPU overhead of any real virtual environment is so high that you lose worse there. I don't know of any commercial hosting environment that can prevent denial of service attacks like this, it's not cost effective to try and prevent all possible misbehaviour... you just enforce privacy and deal with DOS through social and contractual avenues.
On Interix and NT: yep, NT was also not very innovative, Cutler just recreated some of his previous work for VMS. But we have changed the subject
I don't think this is really off-topic. Microsoft is claiming to be more innovative than OSS. OSS is pretty bad at eye candy, because that requires skill sets that cost real money to hire... but there's all kinds of places for innovation under the hood, things Ballmer can't dance around on stage and rave about because it's not pretty, and an awful lot of that is going on in open source.
I mean... BSD is still probably the best testbed for academic operating systems work: commercial operating systems make publication hard and the Linux kernel APIs are just too unstable. It was certainly the testbed of choice during the '80s and '90s. And there's a lot of great stuff coming out of there.
Couldn't you implement the same thing with a new directory that no one (in the jail) has permission to write to, and hard links to the files that are the same?
If the Jail was the kind of "lower rights" environment you're thinking of, yes. "Rights", however, are part of a discretionary access control system. The thing about the Jail is that it's a compartment in the Orange Book sense of the word: it treats the rest of the system as a higher classification in the mandatory access control sense: there's no way for a program in the jail to communicate outside the jail except through the channels that would be available to a completely separate system.
I rent a couple of servers, each in a "jail" like this, and it looks like a regular FreeBSD box, except that there may be dozens of other peole running webservers on it... and even if I "su" to root I can't see them, I can't see their processes, I can't see their network ports, I'm completely isolated. I can run my own DNS, my own webserver... like a dedicated box or a virtualized server but for a fraction of the price of either.
Re:These "innovations" are up to 40 years old.
on
Ballmer on Innovation
·
· Score: 2, Insightful
By the way:
some wacko obscure package
Smalltalk is "some whacko obscure package" in the same way that Newton was "some whacko obscure philosopher".
Re:These "innovations" are up to 40 years old.
on
Ballmer on Innovation
·
· Score: 1
Oh for goodness sake, readline is not and never has been an equivalent to IntelliSense.
I'll take your word for it, since I've never used Intellisense... but I've seen some pretty amazing things hooked in to readline and similar libraries... you start typing a command, hit ESC, and get context-appropriate suggestions even for external applications.
I have used Interlisp-D on the Xerox Dorado, and its Do What I Mean feature is... notorious, I think is the word.
why are Microsoft not "innovative" but Apple are?
This isn't Microsoft-vs-Apple, this is Ballmer-vs-Open-Source. Ballmer claimed that FOSS is just copying stuff, and a couple of steps later someone went "hey, look, Apple's just copying Microsoft".
My point is Apple, Microsoft, and everyone else are ALL mining the same historical archive. It's no more innovative for Microsoft to put a class browser in a GUI IDE than for Apple to do it... not when the class browser originated as part of a GUI IDE back when Microsoft's core product was BASIC.
You can get innovation in Linux, and I'd expect to see more and more of it as core infrastructure issues get solved increasingly rapidly and more developers move out into app development.
One thing that seems to make it hard to do innovative things in the Linux kernel is the extreme instability of the API. The BSD kernel has a number of long-term stable internal APIs, which is probably a result of it being the academic testbed for most of the '80s and '90s, and which makes it more attractive as a place to do experimental work.
Apple seems to have noticed this and has frozen many of THEIR kernel APIs in Tiger.
Agree with you on CORBA. I'm a big fan of simple public interfaces that layer on things that are easy to implement. That's one thing that makes me stay clear of Microsoft's APIs: they have so many interdependent layers that the result more resembles an ecosystem than an organic whole.
Virtualization or paravirtualization is hardly OSS innovation
Jails are not virtualization. They're an extension of the chroot environment into a complete sandbox. Unlike a virtualized OS, all jails are running on the same kernel. It can be used to do the same kind of thing as a virtual environment (which goes back to VM), but it doesn't force you to run multiple kernels with multiple device-like interfaces to the underlying OS.
Overlay file systems and immutible file systems allow you to even share most of the files in the jail, without exposing the jails to substitution attacks from other jails. Again, this gives you a significant improvement in efficiency because you don't have to actually duplicate the userland either.
So instead of each jail taking up a multi-gigabyte virtual partition, all it takes up is the set of files that actually differ from the base system. For hosting solutions with small storage requirements, you can get away with megabytes per jail, instead of gigabytes... and yet the applications in the jail see a complete OS of their own.
You are forgetting, that Interix/OpenNT was also not possible without NT's once beautiful (although, uglified by GDI-related stuff in NT4) kernel design, allowing multiple subsystems.
Any microkernel or microkernel-like OS can do the same. A lot of NT is just the "second system" for the open-source Mach... which Apple uses to run a UNIX environment (they even call it the BSD subsystem) and a Classic Mac OS subsystem alongside each other. Not that Mach is a particularly nice microkernel-like OS, but it does satisfy your concerns.
I don't know how complete the notification mechanism in NT is. Is that in NTFS or can you get notifications from any file system like you can on FreeBSD where the notifications happen at the vnode layer? Why doesn't Microsoft make more use of it?
Oh, and that new graphics library (the one Apple beat to the punch with Core Image in Tiger) in Longhorn? "Avalon" is basically a copy of an open source window system called "Berlin" that never caught on because it was a bit early... good OpenGL video cards weren't cheap enough soon enough.
They opened the market for cheap computers made of interchangeable parts that can exchange software because of software compatibility.
"What is CP/M and the S100 bus, Alex?"
"You're absolutely right, Peter!"
I was writing software for a UNIX clone on a CP/M-compatible S-100 bus before I ever saw an IBM PC, and for several years after the PC came out one of the most important cards was the "Baby Blue" CP/M emulator so you could actually get commodity interchangable software for your PC clones... because MS-DOS was so ineffective that most developers write their software for the IBM or Zenith or Tandy BIOS... and all the really portable software was either public domain (open source wasn't a buzzword yet) source in basic and C, or commercial CP/M-80 software.
Are there any projects out there that really innovate, coming from Open Source developers?
Scripting languages: Perl, Tcl, Python,... the whole explosion of amazing automated websites (like, you know, google) depend on that.
Kernel events: They seem pretty obscure and geeky, until all of a sudden Apple's sending events from the file system to applications in Spotlight.
Immutable file systems, overlay file systems and Jails: they don't show up on the front lines, but they let you build the same kind of sandboxed environment as in VMware or Xen with a fraction of the resources spent on each environment. This is a killer technology for shared hosting.
XPI: building the whole application user interface out of XML. Look at the MASSIVE flood of innovative extensions to Firefox that have resulted from that.
Softway's Interix: it's a whole UNIX system running under the NT kernel, built on top of GCC and OpenBSD. Not Open Source, but it wouldn't have been possible without it. Microsoft liked it so much they bought the company, and they wouldn't have been able to convert Hotmail to NT if they hadn't had it.
I've installed three linux distributions on a server of mine just this past month, and let me tell you, they're not all that impressive to your typical Windows person.
That's because they are copying Windows. But for an OS with an open source core that isn't, turn them on to Mac OS X. Yeh, Apple's built a bunch of closed-source stuff on top of it, but it wouldn't have happened without the open source innovation under the covers.
Dialup is a different technology than cable or DSL, that's definitely true. Dialup can be used anywhere, direct cable or DSL are tied to a specific location. Dialup can be metered or flat rate, and can be metered by the phone company as well (or be subject to absurd premums at hotels). Cable and DSL started out being moderately distinct, but they've become almost identical sets of packages with VOIP and soon Lightstream.
So... dialup is one market, Cable/DSL another, cellular a third, and WiFi a fourth. There are of course overlapping sets of customers, but each has a customer base that's unique to them that's completely disjoint from any of the others.
This reminds me of the big arguments a few years back over WiFi vs Bluetooth. It's *possible* to use WiFi for "virtual cables", and it's *possible* to set up "Bluetooth Access Points", but the two technologies have sufficiently different strengths that these days you often have both WiFi and Bluetooth on the same devices.
Slashdot Mirror
Alpha suffered from basically the same problem.
If the problem is "no consumer software", OK, but then anything but x86 (and Power PC, at least for the next year or three) suffers from that.
If the problem is something else, let us in on it. There's pretty much no comparison between Alpha and Itanium otherwise.
Couldn't (alpha) have (alpha) something (alpha) to (alpha) do (alpha) with (alpha) HP (alpha) stabbing (alpha) another (alpha) processor (alpha) in (alpha) the (alpha) back... one that didn't need heroic measures to get top of the line performance...
Beating x86 is like kissing your sister.
Think of where Apple might be today if we had an improved Netscape SuiteSpot running on Mac OS X.
*shudder*
You know what this makes me thing of? "Think of where we might be today if George Lucas had made all mine Star Wars movies."
that merely using higher level languages to abstract yourself away from how the machine executes, won't make a blind bit of difference
Sure it will.
Well, first of all, it's not so much "using a higher level language", it's "using a language that guarantees certain behaviour". There's some quite low-level languages that have bounds checking and type checking in the definition of the language, and quite high level ones that don't.
Anyway...
Just because it doesn't prevent all failure modes that may be exploited, it eliminates one possible failure mode that may be exploited. That increases the security and robustness of the system as a whole.
The counterargument that the bad guys will just exploit something else is pretty much dead. It's like a Windows user saying it's OK for IE to have really bad security, because if you fix that they'll just use social engineering instead. Just because there's other avenues of attack doesn't mean that improving one of the barricades isn't a good thing.
So, like, when I said "fixing the interfaces isn't the whole solution" I didn't mean "don't fix the interfaces", I meant "still fix the deeper exploits, if you can".
just because you validate in your program at the initial user input, someone might use your lower level functions without doing so, so every function must (complexity aside) check its input
Yes, that's right, I had no intention of implying otherwise, and I apologise if I led you to make that inference.
OK, when people talk about "input validation" I start worrying about whether they're talking about Perl "taint mode". (shudder)
But the point I was getting at was that there's some components that are doing such complex things with the input that the only way to validate them is to duplicate them. And zlib's one of them.
The "so many people" are typically the novice developers who do short contract work and then are difficult to find when something goes wrong.
If you haven't kept the code for stuff like this, you're hosed anyway.
There's plenty of share/demo-ware out there that's shipped like this too, and small business uses that like mad.
Switch to the Mac, application bundles really wipe out most of the reasons for shipping statically linked code.
Input is just one interface... every internal interface in a system also needs to be designed so that it only accepts known safe or encapsulated data, and if there's limits on safe input they need to be something that the upper layer can reasonably check without having to effectively replicate the component it's passing the data to.
Let's say, for example, that this overflow involves a pathological artificially created compressed stream. To test for it, you may have to implement most of the algorithms in zlib. To test for it in an image file, you'd have to implement a decoder for that image format that would at least extract the compressed streams to pass to zlib... as well as implementing zlib.
If the problem in the underlying component is a bug that involves the structure of a complexly encoded data stream, it can't really be described in the input or any internal interfaces. Which means that you're not going to catch it with input validation.
Which means that while resiliant interface design is important, it's not going to be enough to block deep attacks. The only way to do that is to make the components themselves secure and resilient. And depending on input validation can cause problems, just ask anyone with an unusual surname.
1. Dynamic linking carries its own set of security issues and its own history of exploits.
2. Dynamic linking is pretty much the norm these days anyway. It's definitely the norm on the two big closed-source platforms where this might be an issue: Windows and Macintosh.
3. Where static linking is common, it's also common to have either source or relocatable object so you can rebuild or relink anyway.
But given that dynamic linking really is the norm, I'm not sure I get what you're talking about. Who are the "so many people"?
The problem with writing code in a typesafe language is, as you have noted, integration with libraries. The main reason that so much code is writen in C is that C needs pretty close to zero runtime support.
Not only do languages like Lisp need a fairly extensive runtime, they need dynamic memory allocation and garbage collection, and when you share garbage-collected objects between languages (potentially between multiple languages each with their own allocation models) you're asking for a whole new kind of hurt.
Find a type-safe language where the generated code is standalone and has an easy mechanism for importing and exporting data, and you'll get some traction. And much as I like lisp-family languages myself, that's not the way to go... nor is anything like Java. Perhaps there's something in the Modula family that will work, though my own experience with Modula 2 has not been encouraging.
Well, almost nobody. Publishers aren't generally seeing any value in eBook rights, and are sitting on them... except for Baen Books, who are going into non-DRMed eBooks in a big way.
I've bought over 60 eBooks from Baen and over 600 non-DRMed eBooks (mostly short stories) from Fictionwise, and one DRMed eBook (the annotated version of A Fire Upon the Deep)... and the DRM on that was so annoying to deal with I ended up finding a pirated copy online to sit alongside it.
If you could somehow bias the emission of gamma radiation enough, you wouldn't need a working fluid: you'd have a light drive.
Why not just work with chroot jails?
Indeed.
FreeBSD jails provide about the same level of isolation as virtual servers for a fraction of the cost in disk space and virtually none in performance.
This whole scheme seems like a massive step backwards... do they sell blade servers?
Last time I played with jails there was no strict resource control and separation, so I don't see this as a commercially viable technology for virtual hosting.
Yes, you can DOS other jails by forkbombing yourself. There's no CPU accountability, but if you're CPU-bound you need a dedicated host anyway... the CPU overhead of any real virtual environment is so high that you lose worse there. I don't know of any commercial hosting environment that can prevent denial of service attacks like this, it's not cost effective to try and prevent all possible misbehaviour... you just enforce privacy and deal with DOS through social and contractual avenues.
On Interix and NT: yep, NT was also not very innovative, Cutler just recreated some of his previous work for VMS. But we have changed the subject
I don't think this is really off-topic. Microsoft is claiming to be more innovative than OSS. OSS is pretty bad at eye candy, because that requires skill sets that cost real money to hire... but there's all kinds of places for innovation under the hood, things Ballmer can't dance around on stage and rave about because it's not pretty, and an awful lot of that is going on in open source.
I mean... BSD is still probably the best testbed for academic operating systems work: commercial operating systems make publication hard and the Linux kernel APIs are just too unstable. It was certainly the testbed of choice during the '80s and '90s. And there's a lot of great stuff coming out of there.
It's kind of weird how all the control is through serial ports.
Couldn't you implement the same thing with a new directory that no one (in the jail) has permission to write to, and hard links to the files that are the same?
If the Jail was the kind of "lower rights" environment you're thinking of, yes. "Rights", however, are part of a discretionary access control system. The thing about the Jail is that it's a compartment in the Orange Book sense of the word: it treats the rest of the system as a higher classification in the mandatory access control sense: there's no way for a program in the jail to communicate outside the jail except through the channels that would be available to a completely separate system.
I rent a couple of servers, each in a "jail" like this, and it looks like a regular FreeBSD box, except that there may be dozens of other peole running webservers on it... and even if I "su" to root I can't see them, I can't see their processes, I can't see their network ports, I'm completely isolated. I can run my own DNS, my own webserver... like a dedicated box or a virtualized server but for a fraction of the price of either.
By the way:
some wacko obscure package
Smalltalk is "some whacko obscure package" in the same way that Newton was "some whacko obscure philosopher".
Oh for goodness sake, readline is not and never has been an equivalent to IntelliSense.
I'll take your word for it, since I've never used Intellisense... but I've seen some pretty amazing things hooked in to readline and similar libraries... you start typing a command, hit ESC, and get context-appropriate suggestions even for external applications.
I have used Interlisp-D on the Xerox Dorado, and its Do What I Mean feature is... notorious, I think is the word.
why are Microsoft not "innovative" but Apple are?
This isn't Microsoft-vs-Apple, this is Ballmer-vs-Open-Source. Ballmer claimed that FOSS is just copying stuff, and a couple of steps later someone went "hey, look, Apple's just copying Microsoft".
My point is Apple, Microsoft, and everyone else are ALL mining the same historical archive. It's no more innovative for Microsoft to put a class browser in a GUI IDE than for Apple to do it... not when the class browser originated as part of a GUI IDE back when Microsoft's core product was BASIC.
You can get innovation in Linux, and I'd expect to see more and more of it as core infrastructure issues get solved increasingly rapidly and more developers move out into app development.
One thing that seems to make it hard to do innovative things in the Linux kernel is the extreme instability of the API. The BSD kernel has a number of long-term stable internal APIs, which is probably a result of it being the academic testbed for most of the '80s and '90s, and which makes it more attractive as a place to do experimental work.
Apple seems to have noticed this and has frozen many of THEIR kernel APIs in Tiger.
Agree with you on CORBA. I'm a big fan of simple public interfaces that layer on things that are easy to implement. That's one thing that makes me stay clear of Microsoft's APIs: they have so many interdependent layers that the result more resembles an ecosystem than an organic whole.
Virtualization or paravirtualization is hardly OSS innovation
Jails are not virtualization. They're an extension of the chroot environment into a complete sandbox. Unlike a virtualized OS, all jails are running on the same kernel. It can be used to do the same kind of thing as a virtual environment (which goes back to VM), but it doesn't force you to run multiple kernels with multiple device-like interfaces to the underlying OS.
Overlay file systems and immutible file systems allow you to even share most of the files in the jail, without exposing the jails to substitution attacks from other jails. Again, this gives you a significant improvement in efficiency because you don't have to actually duplicate the userland either.
So instead of each jail taking up a multi-gigabyte virtual partition, all it takes up is the set of files that actually differ from the base system. For hosting solutions with small storage requirements, you can get away with megabytes per jail, instead of gigabytes... and yet the applications in the jail see a complete OS of their own.
You are forgetting, that Interix/OpenNT was also not possible without NT's once beautiful (although, uglified by GDI-related stuff in NT4) kernel design, allowing multiple subsystems.
Any microkernel or microkernel-like OS can do the same. A lot of NT is just the "second system" for the open-source Mach... which Apple uses to run a UNIX environment (they even call it the BSD subsystem) and a Classic Mac OS subsystem alongside each other. Not that Mach is a particularly nice microkernel-like OS, but it does satisfy your concerns.
I don't know how complete the notification mechanism in NT is. Is that in NTFS or can you get notifications from any file system like you can on FreeBSD where the notifications happen at the vnode layer? Why doesn't Microsoft make more use of it?
If Microsoft hadn't decided to keep the rights to sell DOS, there wouldn't have been any IBM clones ;-)
If the IBM PC had become popular, there would have. They'd just be running CP/M-86 and then MP/M-86 instead of MS-DOS.
# Incremental compilation
# Incremental linking
Forth, um, 1972? Lisp, 1965?
# Pre-compiled headers
Manx C on the Amiga in 1986.
# A very strong visual debugger, with useful features like DataTips.
# Integrated source browser
# Integrated class browser
Smalltalk, 1978
Remote debugging over tcp/ip
EVERYONE, as soon as TCP/IP existed.
Intellisense (auto-completion)
GNU Readline?
It's the kernel, not the eye candy.
Oh, and that new graphics library (the one Apple beat to the punch with Core Image in Tiger) in Longhorn? "Avalon" is basically a copy of an open source window system called "Berlin" that never caught on because it was a bit early... good OpenGL video cards weren't cheap enough soon enough.
They opened the market for cheap computers made of interchangeable parts that can exchange software because of software compatibility.
"What is CP/M and the S100 bus, Alex?"
"You're absolutely right, Peter!"
I was writing software for a UNIX clone on a CP/M-compatible S-100 bus before I ever saw an IBM PC, and for several years after the PC came out one of the most important cards was the "Baby Blue" CP/M emulator so you could actually get commodity interchangable software for your PC clones... because MS-DOS was so ineffective that most developers write their software for the IBM or Zenith or Tandy BIOS... and all the really portable software was either public domain (open source wasn't a buzzword yet) source in basic and C, or commercial CP/M-80 software.
Are there any projects out there that really innovate, coming from Open Source developers?
... the whole explosion of amazing automated websites (like, you know, google) depend on that.
Scripting languages: Perl, Tcl, Python,
Kernel events: They seem pretty obscure and geeky, until all of a sudden Apple's sending events from the file system to applications in Spotlight.
Immutable file systems, overlay file systems and Jails: they don't show up on the front lines, but they let you build the same kind of sandboxed environment as in VMware or Xen with a fraction of the resources spent on each environment. This is a killer technology for shared hosting.
XPI: building the whole application user interface out of XML. Look at the MASSIVE flood of innovative extensions to Firefox that have resulted from that.
Softway's Interix: it's a whole UNIX system running under the NT kernel, built on top of GCC and OpenBSD. Not Open Source, but it wouldn't have been possible without it. Microsoft liked it so much they bought the company, and they wouldn't have been able to convert Hotmail to NT if they hadn't had it.
I've installed three linux distributions on a server of mine just this past month, and let me tell you, they're not all that impressive to your typical Windows person.
That's because they are copying Windows. But for an OS with an open source core that isn't, turn them on to Mac OS X. Yeh, Apple's built a bunch of closed-source stuff on top of it, but it wouldn't have happened without the open source innovation under the covers.
Dialup is a different technology than cable or DSL, that's definitely true. Dialup can be used anywhere, direct cable or DSL are tied to a specific location. Dialup can be metered or flat rate, and can be metered by the phone company as well (or be subject to absurd premums at hotels). Cable and DSL started out being moderately distinct, but they've become almost identical sets of packages with VOIP and soon Lightstream.
So... dialup is one market, Cable/DSL another, cellular a third, and WiFi a fourth. There are of course overlapping sets of customers, but each has a customer base that's unique to them that's completely disjoint from any of the others.
This reminds me of the big arguments a few years back over WiFi vs Bluetooth. It's *possible* to use WiFi for "virtual cables", and it's *possible* to set up "Bluetooth Access Points", but the two technologies have sufficiently different strengths that these days you often have both WiFi and Bluetooth on the same devices.