Seems to me that most people are comparing FreeBSD to Redhat/Mandrake. Let's not forget that Debian Linux is not only fast (starts up much faster than other distro's) as well as being stable and secure thanks to apt. Packages can be installed from source or binary, AND with just one command.....
...and, like {Free,Net,Open}BSD, it's a volunteer project, not a commercial product. If somebody wants to compare the BSDs to a Linux distribution, Debian is probably the most appropriate one with which to compare them.
And with good reason, if you're used to the GNU binutils and BASH, you're in for a bit of a surprise with FreeBSD.
Yes, the binutils are surprisingly different from the GNU ones:
> uname -sr
FreeBSD 4.1-RELEASE
> cc --version
2.95.2
> ld --version
GNU ld 2.10.0
Copyright 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
Supported emulations:
elf_i386
> as --version
GNU assembler 2.10.0
Copyright 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `i386-unknown-freebsd4'.
> nm --version
GNU nm 2.10.0
Copyright 1997, 98, 99, 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
> ar --version
GNU ar 2.10.0
Copyright 1997, 98, 99, 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
...
(No, that hasn't changed in later releases.)
Yes, it's not GNU/BSD in the sense that most of the utilities are not GNU utilities, but the BSDs do use the GNU toolchain.
What you have to realise is at the time, my Dad and other people working on the LEOs genuinely believed that these were the world's first computers ever, not just the world's first business computers as they later became known.
Your Dad mustn't have hung around the University of Manchester, then; they had a stored program computer running in 1948, but the leo-computers.org.uk site says that, although the directors of Lyons "decided to take an active role in promoting the commercial development of computers" in October 1947, the LEO wasn't operational until 1951. Were the Manchester SSEM or Mark I military secrets?
I don't know where Gates gets his figures, but Google [google.com] tells me that Canada is up there with South Korea with penetrations of around 40-50%. This neat page of summary stats [internet.com] shows Denmark and Sweden at around 14% and I suspect many Scandinavian and other European countries are on par with the US's 11% broadband penetration rate. Sounds to me like the US is fighting for fifth at best.
A (PDF) OECD report on "The Development of Broadband Access in OECD Countries" has, on page 8, a graph of "Broadband penetration in OECD countries, June 2001", showing the US in fourth place, behind Korea (way ahead of everybody else, with 14 broadband subscribers per 100 inhabitants), Canada (6/100), and Sweden (~4.3/100). The Netherlands appears to be epsilon below the US, and following it are Austria, Denmark, Belgium, Iceland, Luxembourg, Germany, Japan, and various others (see the graph for the full list).
Presumably the 40-50% figures are something other than percentages of the inhabitants, for example percentages of Internet users.
Google can tell you lots of things, depending on what page you found; you didn't indicate which page it found, nor did you indicate what you searched for. A search for "broadband penetration" found a Newsbytes article from October 4, 2001, saying that South Korea has 95% of home Internet users connected with broadband, Hong Kong with 53%, Taiwan with 35%, and Singapore with 24%, but only 5% in Australia and 4% in New Zealand. It says that a separate study shows 17.5% in the US.
An older report by the Strategis Group referred to in
this CNN article names Australia, Canada, The Netherlands, Singapore, and Sweden as likely to lead broadband penetration.
To be precise, it says
The report, "International High-Speed Access: The Residential Marketplace 1999," said that less than 1 percent of the world's households use broadband Internet access. It predicts that combined DSL and cable modem penetration of total households will reach 10 to 30 percent by 2003 in several markets, including Australia, Canada, The Netherlands, Singapore, Sweden,
and the US.
I think he is implying that Microsoft broke ground and created a standards-based system of software (Office, Windows, etc) and the Open Source movement is using some of his original ideas and yet claiming to be at odds with MS.
MR. GATES: Let me start out, really the reason that you see open source there at all is because we came in and said there should be a platform that's identical with millions and millions of machines, and the bios of that should be open to everybody to use, and all the extensibility should be there. And so it was very predictable that once we had gotten the PC going, and going and gotten hundreds of millions of machines out there, that it had always been sort of free software and the universities would flourish and there would be more of that.
which sure seems to me, at least, as if he's talking about the PC hardware platform.
I.e., it sounds more like what the person to whom you replied was saying than what you're saying.
Now, whether the PC became a mass-market platform because Microsoft "came in" and decreed that it should be open and standard is another matter. I think early versions of MS-DOS, at least, could run on x86 machines that weren't "IBM PC-compatible", and did run on some (I think the DEC Rainbow wasn't PC-compatible but did run DOS); it may have been that a bunch of applications, not all of which were from Microsoft (who I don't think were the dominant application vendor for DOS in the early days), which required "IBM-compatible" hardware.
Wine is free software, and its license (contained in the file LICENSE in each distribution) is X11 style.
Basically, this means that you can do anything with Wine except claim that you wrote it.
I seem to remember reading about a license change to an X-style license at one point.
I think the problem with running Wine on anything other than x86 is the need to interpret x86 machine code.
Yes, hence my references to interpreters and binary-to-binary translators.
Even if you got it to work, it would be slow.
Well, with a good binary-to-binary translator, it might not be. Anybody know how well FX!32 did running NT/x86 binaries on NT/Alpha?
But even there I expect Windows source code to have a lot of x86 assumptions.
Some might, some might not. (Then again, there's probably an unfortunate amount of code written for Linux with x86 assumptions or, at least, "the world is little-endian" assumptions; I've certainly seen code contributed to Ethereal, for example, which worked only on little-endian machines....)
Well, that depends on the part of Wine you're talking about. As the "about" page says:
Wine provides both a development toolkit (Winelib) for porting Windows sources to Unix and a program loader, allowing unmodified Windows 3.1/95/NT binaries to run under Intel Unixes.
The program loader part - which is what CrossOver uses - is tied to x86 (I guess if somebody were really ambitious they could try to make it run MIPS, PowerPC, or Alpha Windows NT binaries - and at some point somebody might do that for IA-64 - but there are a lot fewer non-x86 Windows binaries than x86 Windows binaries, so there's probably not going to be much effort devoted to that soon). So you probably aren't going to see CrossOver for Solaris/SPARC; Solaris/x86 might be possible, but there's probably not much effort going to be devoted to that, either.
(Well, I suppose somebody could try gluing an x86 interpreter, or x86-binary-to-native-binary translator, to Wine, to make a version to run x86 binaries on non-x86 UNIXes, along the lines of Sun's WABI. I don't know whether anybody's thinking about that, however.)
The Winelib library, however, does, I think, work on non-x86 platforms, letting somebody who has source to a Windows application - that "somebody" might be the developer; the idea is, I think, that this can be used for closed-source applications, which I suspect is why WINE isn't GPLed or LGPLed - port it to UNIX.
One of the services that Codeweavers offers is assistance in porting Windows applications to Linux; they speak of "native versions", so this may involve using Winelib.
Another point, I dont think you can ever have a successful operating system without any command prompt. Copying and moving files can never be as easy using a dumb GUI file manager.
Yes, I sometimes use the command prompt window on my desktop (well, deskside, really) Windows box at work, and on the Windows partition on my home machine.
Of course, they're both running Windows NT - NT 4.0 on the Windows partition at home, and NT 5.0, err, umm, Windows 2000 on the machine at work.
The command prompt I use at home is, err, umm, a UNIX command prompt, with Cygwin; I often use it rather than the file manager. I do so less often at work, although I'm not sure if that's because I use the machine at home for software development while I mainly use the machine at work as an X terminal (for the Solaris, etc. boxes on which I do my real work) and platform for Web browsing, and thus don't often copy/move/etc. files on the work machine, or because the Windows NT command prompt isn't as nice as the Bash prompt at home.
Then again, when I'm running KDE on the FreeBSD partition of my machine at home, I use the GUI file manager rather than the command line to read the various networking standards documents I have stored there, as I find it more convenient than switching to an xterm (or popping up a new xterm) and cding to the appropriate directory and firing up (Acrobat Reader, microEmacs, whatever).
So, as far as I'm concerned, there's a place for command lines and for GUI file managers.
The point is that 1 and 2 may be true, but the whole point of open source is that one can fix the code. This does
not mean that you have to, but it means that you can.
You can if you are a programmer, and familiar with the language in which the program is written, and familiar with the theory behind the program (if any).
If you can fix it, do so. If you can't, submit the bug. But whining and doing nothing are
not acceptable.
If "submit the bug" means "report the problem to the developers" (they may not have a formal bug-tracking system; perhaps they should, but that doesn't mean they necessarily will), then, yes, one should do that, regardless of whether the software is open-source. If the developers don't know about it, they aren't likely to it, except by accident.
However, all too often the "fix it yourself, or submit a bug" response to complaints gets over-simplified to "fix it yourself, you have the source", which is an error - there may be users who don't have the knowledge to fix the problem themselves. If that's what you really meant, that's what you should have said, clarifying "do something useful", which, in your previous message, was preceded by "Open source means you can fix the code", a statement, that, as noted, is not necessarily true unless you use a rather unrealistic definition of "can" (e.g., "can, if you learn a programming language and spend a lot of time studying the code and the theory behind it first").
And if your posting was responding to Petreley's article, accusing him of "whining and doing nothing", note that he wasn't just complaining about specific problems (which he should report to the GNOME, KDE, etc. developers), he was complaining about an apparent general attitude, and "filing bugs" on that may mean filing bugs on projects that don't even exist yet, so that when people write some new project they take more care handling errors, including those that "can't happen".
3. Open source means
you can fix the code. So stop complaining and do something useful.
I presume that's either a troll or a parody of the sort of nonsense that all too often gets put out in response to complaints. If it isn't, I'll simply note that you probably can't fix the code if you are not a programmer, which a lot of users aren't.
(On the other hand, users of open-source software should bear in mind that the developers are often not working full-time on the program - they may have day jobs, or may be going to school, etc. - and therefore that the feature that they really really really want may not have been implemented yet because nobody's had time to implement it, so they may Just Have To Wait.)
Or, at least, tell you something more useful than "We're sorry, your call cannot be completed as dialed". What, am I supposed to stand on one foot and dial with my nose? Will the call go through if I dial it that way?
I seem to remember some human-interface type praising that message because it apologized for the problem, and didn't blame it on the user, and otherwise didn't hurt the user's sensitive feelings. If they just tell me what to do so that the call does go through, I'd put up with them calling me a blithering idiot....
The site doesn't say it's "for Windows NT compatible DCE/RPC middleware"; that's one place where DCE/RPC can be used, but DCE/RPC antedates Microsoft's heavy use of it.
Not true. Since Day One, it also supported TCP; the Sun TIRPC stuff (done for System V Release 4) also allows it to work on other transports - for example, during at least one Connectathon, testing of NFS and other ONC RPC-based services over OSI transport protocols (I forget whether they did only CLTP or CLTP and COTP) was done, as I remember.
ONC/RPC's security is GSS/API
Not true. ONC RPC does support other authentication flavors, although they're either weak ("none" and "system" authentication), have (I think) been broken (DES authentication) or use Kerberos V4 rather than V5 (Kerberos authentication), so the intent is, as I understand it, to move to GSS/API authentication.
'Unclefish Beholding' is a great piece -- it's atomic science using the English we'd have if there had been no Norman invasion, i.e. no latin/greek-derived words.
Define "supported". FreeBSD now has Boris Popov's smbfsin the CVS tree, for example; it looks as if it's been MFC'ed, so it's at least in -stable.
There's also an SMB client and server available for MacOS Classic from Thursby Software.
I guess getting smbfs to work on other unixs and mac os is pretty hard, because it's been this way for a while.
No, it hasn't. Heck, I think that one of the earliest SMB clients servers was an SMB implementation for Xenix (yeah, the version of UNIX that those people did, a long time ago) from Intel, called OpenNet or something such as that, and, as already indicated, there already exist SMB file system clients (i.e., transparent clients, not FTP-like clients) for FreeBSD and MacOS classic.
We'll know it's ready for the Turing test when it makes a posting with a goatsex link. ("Hi, I'm Cyc, and this is my f1rst p0st to Slashdot! For those curious about how I work, <a href="http://goatse.cx">here's</a> a link giving detailed internal information.")
I think I might have tried that only to have Netscape whine that the DLL was missing, rather than just running the Acrobat Reader program. But it was a while ago, so I may be misremembering....
> Hell, Acrobat files even come up in the browser pane.
which is a common, but evil, bug in the graphical browsers. OK, it's part of a family of bugs. Users should be able to override *all* of the silly things that page designers do... using plugins instead of external applications...
Actually, the fact that Acrobat files come up in the browser pane isn't, as far as I know, the result of a page designer's choice, it's the result of Acrobat Reader running as a plugin.
Perhaps I've missed something, but I didn't see any point in the Acrobat Reader installation process, at least on Windows, where I can tell it not to install the plugin, nor did I see any obvious way to tell Netscape 4.73, at least, not to run the Acrobat plugin, but to just run the Acrobat Reader binary.
So, unless I have missed something, it's a silly thing that Adobe and the developer of your browser did, not a silly thing that a page designer did, but it still doesn't seem to be overridable.
I found that sufficiently annoying (with all the extra screen real estate at the top of my browser windows, the actual display window in which the Acrobat reader appears is too short for me to be able to see a full page at a font size that I can read without moving my head right up to the screen) that I
uninstalled Acrobat Reader;
renamed my Netscape directory under Program Files to Fuckscape;
installed Acrobat Reader - it didn't find Netscape, so it installed no plugins;
renamed Fuckscape to Netscape.
Fortunately, either the Acrobat Reader installation process on various UNIX-flavored OSes lets you say "no plugin, please", or the plugin isn't found because, on FreeBSD, I'm using a BSD version of Netscape and a Linux version of Acrobat Reader, so I didn't have to get out the chainsaw to fix this on my FreeBSD partition at home.
Most likely what is going on, is your being serviced by a "sub-station". Thats not the real name, but I don't know the real one.
It tends to be called names like "remote subscriber terminal" (and possibly other things with "remote" and "subscriber" in them). Here's a tutorial on Digital Loop Carrier systems, that being the name of the technology. In effect, a digital loop (T1, or more, possibly fibre) is run to the "sub-station" (remote terminal), and subscriber phone lines are run to the "sub-station" as well. The "sub-station" performs some of the functions that would be performed at the central office for subscribers whose phone line goes directly to the CO, e.g. analog-to-digital and digital-to-analog conversion.
This multiplexes N phone circuits over the digital loop, so you only have to run that one loop to the neighborhood, not one loop per subscriber. (This is called "pair gain" because you can serve more subscribers with one or two pairs to the neighborhood.)
Unfortunately, this means that everything above about 4 KhZ or so on the subscriber's phone line gets lost - the remote terminal filters it out and spits out the standard 8000-samples-per-second digitized signal. As ADSL uses stuff well above 4 KhZ, you can't do ADSL with this.
However, one might then ask "well, as the stuff going back to the central office is digital anyway, why not convert the ADSL signal to a bit stream at the remote terminal and send that back to the central office?"
That's what SBC's Project Pronto, and probably some other projects of other phone companies, is all about; here's a discussion of "Digital Loop Carrier meets ADSL". The link to the neighborhood is fibre, not copper, and it runs, among other things, ATM back to the central office; ADSL carries ATM cells, and those cells get shipped back to the CO, and, ultimately, to your ISP.
If the original poster can't get ADSL "because they have fibre running to their neighborhood", it's probably because Verizon don't have one of those shiny new ADSL-capable remote terminals in their neighborhood.
It has some annoying javascript/flash but it has a lot of useful information.
And if you find stuff that uses Flash instead of Boring Old HTML extremely irritating (I certainly do; I just want to read some text, not wait for some animated crap to pop up), you can get a Boring Old HTML version at http://www.spike-wireless.com/main.html.
Slashdot Mirror
...and, like {Free,Net,Open}BSD, it's a volunteer project, not a commercial product. If somebody wants to compare the BSDs to a Linux distribution, Debian is probably the most appropriate one with which to compare them.
Yes, the binutils are surprisingly different from the GNU ones:
(No, that hasn't changed in later releases.)
Yes, it's not GNU/BSD in the sense that most of the utilities are not GNU utilities, but the BSDs do use the GNU toolchain.
As does one of Slashdot readers' favorite sites.
Your Dad mustn't have hung around the University of Manchester, then; they had a stored program computer running in 1948, but the leo-computers.org.uk site says that, although the directors of Lyons "decided to take an active role in promoting the commercial development of computers" in October 1947, the LEO wasn't operational until 1951. Were the Manchester SSEM or Mark I military secrets?
A (PDF) OECD report on "The Development of Broadband Access in OECD Countries" has, on page 8, a graph of "Broadband penetration in OECD countries, June 2001", showing the US in fourth place, behind Korea (way ahead of everybody else, with 14 broadband subscribers per 100 inhabitants), Canada (6/100), and Sweden (~4.3/100). The Netherlands appears to be epsilon below the US, and following it are Austria, Denmark, Belgium, Iceland, Luxembourg, Germany, Japan, and various others (see the graph for the full list).
Presumably the 40-50% figures are something other than percentages of the inhabitants, for example percentages of Internet users.
Google can tell you lots of things, depending on what page you found; you didn't indicate which page it found, nor did you indicate what you searched for. A search for "broadband penetration" found a Newsbytes article from October 4, 2001, saying that South Korea has 95% of home Internet users connected with broadband, Hong Kong with 53%, Taiwan with 35%, and Singapore with 24%, but only 5% in Australia and 4% in New Zealand. It says that a separate study shows 17.5% in the US.
To be precise, it says
I don't, because what the shareholder meeting transcript quotes Gates as saying is
which sure seems to me, at least, as if he's talking about the PC hardware platform.
I.e., it sounds more like what the person to whom you replied was saying than what you're saying.
Now, whether the PC became a mass-market platform because Microsoft "came in" and decreed that it should be open and standard is another matter. I think early versions of MS-DOS, at least, could run on x86 machines that weren't "IBM PC-compatible", and did run on some (I think the DEC Rainbow wasn't PC-compatible but did run DOS); it may have been that a bunch of applications, not all of which were from Microsoft (who I don't think were the dominant application vendor for DOS in the early days), which required "IBM-compatible" hardware.
This entry in the Wine FAQ says otherwise:
I seem to remember reading about a license change to an X-style license at one point.
Yes, hence my references to interpreters and binary-to-binary translators.
Well, with a good binary-to-binary translator, it might not be. Anybody know how well FX!32 did running NT/x86 binaries on NT/Alpha?
Some might, some might not. (Then again, there's probably an unfortunate amount of code written for Linux with x86 assumptions or, at least, "the world is little-endian" assumptions; I've certainly seen code contributed to Ethereal, for example, which worked only on little-endian machines....)
The "about" page on the Wine Web site says Wine "works on most popular Intel Unixes, including Linux, FreeBSD, and Solaris."
Well, that depends on the part of Wine you're talking about. As the "about" page says:
The program loader part - which is what CrossOver uses - is tied to x86 (I guess if somebody were really ambitious they could try to make it run MIPS, PowerPC, or Alpha Windows NT binaries - and at some point somebody might do that for IA-64 - but there are a lot fewer non-x86 Windows binaries than x86 Windows binaries, so there's probably not going to be much effort devoted to that soon). So you probably aren't going to see CrossOver for Solaris/SPARC; Solaris/x86 might be possible, but there's probably not much effort going to be devoted to that, either.
(Well, I suppose somebody could try gluing an x86 interpreter, or x86-binary-to-native-binary translator, to Wine, to make a version to run x86 binaries on non-x86 UNIXes, along the lines of Sun's WABI. I don't know whether anybody's thinking about that, however.)
The Winelib library, however, does, I think, work on non-x86 platforms, letting somebody who has source to a Windows application - that "somebody" might be the developer; the idea is, I think, that this can be used for closed-source applications, which I suspect is why WINE isn't GPLed or LGPLed - port it to UNIX.
One of the services that Codeweavers offers is assistance in porting Windows applications to Linux; they speak of "native versions", so this may involve using Winelib.
Yes, I sometimes use the command prompt window on my desktop (well, deskside, really) Windows box at work, and on the Windows partition on my home machine.
Of course, they're both running Windows NT - NT 4.0 on the Windows partition at home, and NT 5.0, err, umm, Windows 2000 on the machine at work.
The command prompt I use at home is, err, umm, a UNIX command prompt, with Cygwin; I often use it rather than the file manager. I do so less often at work, although I'm not sure if that's because I use the machine at home for software development while I mainly use the machine at work as an X terminal (for the Solaris, etc. boxes on which I do my real work) and platform for Web browsing, and thus don't often copy/move/etc. files on the work machine, or because the Windows NT command prompt isn't as nice as the Bash prompt at home.
Then again, when I'm running KDE on the FreeBSD partition of my machine at home, I use the GUI file manager rather than the command line to read the various networking standards documents I have stored there, as I find it more convenient than switching to an xterm (or popping up a new xterm) and cding to the appropriate directory and firing up (Acrobat Reader, microEmacs, whatever).
So, as far as I'm concerned, there's a place for command lines and for GUI file managers.
You can if you are a programmer, and familiar with the language in which the program is written, and familiar with the theory behind the program (if any).
If "submit the bug" means "report the problem to the developers" (they may not have a formal bug-tracking system; perhaps they should, but that doesn't mean they necessarily will), then, yes, one should do that, regardless of whether the software is open-source. If the developers don't know about it, they aren't likely to it, except by accident.
However, all too often the "fix it yourself, or submit a bug" response to complaints gets over-simplified to "fix it yourself, you have the source", which is an error - there may be users who don't have the knowledge to fix the problem themselves. If that's what you really meant, that's what you should have said, clarifying "do something useful", which, in your previous message, was preceded by "Open source means you can fix the code", a statement, that, as noted, is not necessarily true unless you use a rather unrealistic definition of "can" (e.g., "can, if you learn a programming language and spend a lot of time studying the code and the theory behind it first").
And if your posting was responding to Petreley's article, accusing him of "whining and doing nothing", note that he wasn't just complaining about specific problems (which he should report to the GNOME, KDE, etc. developers), he was complaining about an apparent general attitude, and "filing bugs" on that may mean filing bugs on projects that don't even exist yet, so that when people write some new project they take more care handling errors, including those that "can't happen".
I presume that's either a troll or a parody of the sort of nonsense that all too often gets put out in response to complaints. If it isn't, I'll simply note that you probably can't fix the code if you are not a programmer, which a lot of users aren't.
(On the other hand, users of open-source software should bear in mind that the developers are often not working full-time on the program - they may have day jobs, or may be going to school, etc. - and therefore that the feature that they really really really want may not have been implemented yet because nobody's had time to implement it, so they may Just Have To Wait.)
BBSpot had an article about a similar scheme....
I seem to remember some human-interface type praising that message because it apologized for the problem, and didn't blame it on the user, and otherwise didn't hurt the user's sensitive feelings. If they just tell me what to do so that the call does go through, I'd put up with them calling me a blithering idiot....
Also, the DCE/RPC information page at that site makes some inaccurate claims about Sun's ONC RPC:
Not true. Since Day One, it also supported TCP; the Sun TIRPC stuff (done for System V Release 4) also allows it to work on other transports - for example, during at least one Connectathon, testing of NFS and other ONC RPC-based services over OSI transport protocols (I forget whether they did only CLTP or CLTP and COTP) was done, as I remember.
Not true. ONC RPC does support other authentication flavors, although they're either weak ("none" and "system" authentication), have (I think) been broken (DES authentication) or use Kerberos V4 rather than V5 (Kerberos authentication), so the intent is, as I understand it, to move to GSS/API authentication.
"Uncleavish Truethinking". See this Poul Anderson bibliography.
Define "supported". FreeBSD now has Boris Popov's smbfs in the CVS tree, for example; it looks as if it's been MFC'ed, so it's at least in -stable.
There's also an SMB client and server available for MacOS Classic from Thursby Software.
No, it hasn't. Heck, I think that one of the earliest SMB clients servers was an SMB implementation for Xenix (yeah, the version of UNIX that those people did, a long time ago) from Intel, called OpenNet or something such as that, and, as already indicated, there already exist SMB file system clients (i.e., transparent clients, not FTP-like clients) for FreeBSD and MacOS classic.
Then give it access to Slashdot.
We'll know it's ready for the Turing test when it makes a posting with a goatsex link. ("Hi, I'm Cyc, and this is my f1rst p0st to Slashdot! For those curious about how I work, <a href="http://goatse.cx">here's</a> a link giving detailed internal information.")
I think I might have tried that only to have Netscape whine that the DLL was missing, rather than just running the Acrobat Reader program. But it was a while ago, so I may be misremembering....
Actually, the fact that Acrobat files come up in the browser pane isn't, as far as I know, the result of a page designer's choice, it's the result of Acrobat Reader running as a plugin.
Perhaps I've missed something, but I didn't see any point in the Acrobat Reader installation process, at least on Windows, where I can tell it not to install the plugin, nor did I see any obvious way to tell Netscape 4.73, at least, not to run the Acrobat plugin, but to just run the Acrobat Reader binary.
So, unless I have missed something, it's a silly thing that Adobe and the developer of your browser did, not a silly thing that a page designer did, but it still doesn't seem to be overridable.
I found that sufficiently annoying (with all the extra screen real estate at the top of my browser windows, the actual display window in which the Acrobat reader appears is too short for me to be able to see a full page at a font size that I can read without moving my head right up to the screen) that I
- uninstalled Acrobat Reader;
- renamed my Netscape directory under Program Files to Fuckscape;
- installed Acrobat Reader - it didn't find Netscape, so it installed no plugins;
- renamed Fuckscape to Netscape.
Fortunately, either the Acrobat Reader installation process on various UNIX-flavored OSes lets you say "no plugin, please", or the plugin isn't found because, on FreeBSD, I'm using a BSD version of Netscape and a Linux version of Acrobat Reader, so I didn't have to get out the chainsaw to fix this on my FreeBSD partition at home.The telcos are aware that the technology in question exists; they just might not want to spend the money installing it.
Yes, but would you be happy to have {Verizon,Belgacom,...} have access, as they deem necessary, to your basement?
Really? You might want to check with Alcatel or Lucent or AFC or NEC or Nortel about that.
(Maybe they don't go into curb boxes, but they do go into the neighborhood DLC remote terminal....)
Correct.
It tends to be called names like "remote subscriber terminal" (and possibly other things with "remote" and "subscriber" in them). Here's a tutorial on Digital Loop Carrier systems, that being the name of the technology. In effect, a digital loop (T1, or more, possibly fibre) is run to the "sub-station" (remote terminal), and subscriber phone lines are run to the "sub-station" as well. The "sub-station" performs some of the functions that would be performed at the central office for subscribers whose phone line goes directly to the CO, e.g. analog-to-digital and digital-to-analog conversion.
This multiplexes N phone circuits over the digital loop, so you only have to run that one loop to the neighborhood, not one loop per subscriber. (This is called "pair gain" because you can serve more subscribers with one or two pairs to the neighborhood.)
Unfortunately, this means that everything above about 4 KhZ or so on the subscriber's phone line gets lost - the remote terminal filters it out and spits out the standard 8000-samples-per-second digitized signal. As ADSL uses stuff well above 4 KhZ, you can't do ADSL with this.
However, one might then ask "well, as the stuff going back to the central office is digital anyway, why not convert the ADSL signal to a bit stream at the remote terminal and send that back to the central office?"
That's what SBC's Project Pronto, and probably some other projects of other phone companies, is all about; here's a discussion of "Digital Loop Carrier meets ADSL". The link to the neighborhood is fibre, not copper, and it runs, among other things, ATM back to the central office; ADSL carries ATM cells, and those cells get shipped back to the CO, and, ultimately, to your ISP.
If the original poster can't get ADSL "because they have fibre running to their neighborhood", it's probably because Verizon don't have one of those shiny new ADSL-capable remote terminals in their neighborhood.
Yes, but it still sucks less than the Flash version, as far as I'm concerned.
And if you find stuff that uses Flash instead of Boring Old HTML extremely irritating (I certainly do; I just want to read some text, not wait for some animated crap to pop up), you can get a Boring Old HTML version at http://www.spike-wireless.com/main.html .
s/flashlight/laser pointer/; U.S. Patent 5,443,036 "Method of exercising a cat" speaks of using a laser.