I am keeping my hopes up, hoping that something like the Hurd and the Berlin Project may make an Operating System that is as good with a graphical user interface as Unix is good with the console.
The server is designed to run on any POSIX system with support for threads and TCP/IP; do[sic] date we have built it on Linux and FreeBSD but should be able to use most other major OSs.
so it appears to be a window system for, err, umm, UNIX-flavored OSes, so it doesn't appear as if it'll contribute to the death of UNIX.
The Hurd provides a familiar programming and user environment. For all intents and purposes, the Hurd is a modern Unix-like kernel. The Hurd uses the GNU C Library, whose development closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open.
so it looks as if it's intended to, among other things, provide a UNIX-like API. ("UNIX NT"?)
Perhaps you should replace your subject line with "UNIX must evolve." - both Berlin and the Hurd appear to be trying to contribute to UNIX's evolution, not its death.
(What sort of "baggage" do you see being the problem? What do you see as the consequences of UNIX "[having] been a console-based operating system for a very long time"?)
The GPL is the license that keeps people from forking the code. The BSD license allowed the code to fork like crazy (BSD, FreeBSD, NetBSD, OpenBSD) before.
Given that FreeBSD, NetBSD, and OpenBSD are all free software, I'm not sure how "the BSD license" allowed them to spin off from BSD and "the GPL" would have prevented that.
The GPL doesn't say you can't take the Linux kernel or GCC or... and make your own separate version thereof; you just have to make source available to everyone to whom you make the binary available, "cause the modified files to carry prominent notices stating that you changed the files and the date of any change", allow anybody who got your separate version to freely give it away, etc..
Wasn't it SCO that paid royalties to MS until recentely because they were using some Xenix source code???
I don't know if they paid royalties, but SCO UNIX (and some other SVR3/SVR4 UNIXes) did include Xenix-compatibility code; there was a suit wherein, as I remember, SCO sued to be allowed to yank that code out of one of their UNIXes.
As far as I know, Xenix was originally a Microsoft product; I think they ended up handing it off to SCO.
A good case in point would be Micros~1 long file names with spaces.
Given that UNIX systems have supported long (as in greater than 14 characters) file names, with spaces, as far back as 1982, what are they a "good case" of? (They supported file names with spaces at least as far back as 1975-1976; I'm using 1982 as the first time they supported long file names, as that's when, as I remember, the BSD file system first arrived - I'm assuming, perhaps incorrectly, that it was the first UNIX file system to support file names longer than 14 characters.)
Until OS/2 came out, "Micros~1 long file names with spaces" presumably meant Xenix file names with spaces, but, as far as I know, Xenix had the old V7 UNIX file system, with 14-character names.
Convienent for the user maybe, but a bitch to parse. At what point, and after how many special cases, do you give up and decide that you have reached a new token?
You require that a token that contains spaces be included within quotes, as UNIX shells have done for ages, and as the Microsoft Windows NT shell (and, I think, the Windows OT shell) does. (At least in UNIX you can use double or single quotes; I often forget that single quotes don't work in the Windows NT shell.)
In a GUI, the quotes may not be necessary, but that applies to UNIX or MacOS, say, just as it applies to Windows.
what would you use 64 IRQs for in the first place?
Good question. I may be missing something, but, as far as I can tell, there's no hardware reason why an OS couldn't let multiple PCI devices share the same IRQ (heck, I did much of the PCI support for an OS that did so on hardware not too far from a somewhat fancy PC, namely NetApp's Data ONTAP on the F3xx and F2xx filers).
Perhaps many PC OSes don't support that, but, if so, perhaps those OSes will get fixed for IA-64 (although if Windows 9x is one of those OSes , it may not get fixed, so people who have to reboot their shiny new IA-64 workstation to run some games might be screwed).
Could be; if I remember correctly, they handled the transition from the 16-bit stack-machine HP 3000's to the 32-bit PA-RISC HP 3000's by doing binary-to-binary translation, and they may plan on handling the PA-RISC to IA-64 transition in the same fashion.
Does this mean that the Linux port can start occuring out in the "Open" now?
Start, perhaps, but not finish. The document in question is the IA-64 Application Developer's Architecture Guide, which appears not to give all the details needed for low-level OS programming; it says:
Full details of the IA-64 programming environment including the system architecture and software conventions will be provided in IA-64 Programmer's Reference Manual to be available later.
and some of those details will presumably be necessary for OS kernel work.
I really don't think Micros~1 "does" anything but Win32. Therefore I doubt if they have Linux developers doing this and figure they have a porting layer of Win32 APIs mapping Win32 to GNU/Linux APIs.
...or mapping Win32 to UNIX/X APIs (given that GNU/Linux APIs are largely the same as those on other UNIX-flavored OSes).
In fact, that is what they did for the Solaris and HP-UX ports; they used Mainsoft's MainWin, as I mentioned in another comment. Presumably Mainsoft's stuff can be made to work on Linux, as well.
The IE ports to UNIX are implemented atop Mainsoft's MainWin product, which is a "Win32 API atop UNIX" package. See this item about IE5 and MainWin, which says:
Rather than rewrite the code for the UNIX version, Microsoft chose to use MainWin to rehost the source code on UNIX.
The same was true of IE4, according to stuff on Mainsoft's site.
I saw something ages ago on, I think, Microsoft's Web site indicating that they were developing a Win32-atop-MacOS package and getting third parties to do Win32-atop-UNIX packages; they were, I think, pushing this as a way of getting app developers - or, at least, custom in-house app developers - to write Win32 apps and to get them on other platforms with those packages. I don't know if that's the way they do MacOS ports of their own apps.
In early 1992 already Linus acknowledged that a microkernel design would have been better.
"True, linux is monolithic, and I agree that microkernels are nicer. [...] From a theoretical (and aesthetical) standpoint linux looses."
Umm, he said that it loses "from a theoretical (and aesthetical) standpoint". This is inequivalent to saying that it "would have been better" from a pragmatic standpoint. uote>Proprietary kernels probably evolve much faster but you don't get to watch it.
Perhaps, perhaps not. The fact that "you don't get to watch it" means you can only guess (unless you happen to be one of the people who "get to watch it").
How much have, say, the Solaris or NT kernel architectures changed, relative to the extent that the Linux (or *BSD) kernels have changed? (BTW, neither of them are what I would call a microkernel, not even NT - NT's device drivers, file systems, and networking stack run in kernel mode, for example.)
Lastly, good kernel programmers are rare. If you were one of the few would you rather spend your working hours coding for love and Linus or earning good money instead?
I have the impression that at least some of the developers of kernel code for free OSes do both.
1. NT did not start from a clean slate. A good part of the source code was borrowedb *cough* by D. Cuttler...
Fascinating assertion. Do you have any references to prove that Cutler took VMS code (or code from any of the OS projects I think he worked on at DEC after VMS) and put it into NT, if that's what you're claiming?
Yes, some of the NT I/O subsystem looks VMSish, but perhaps Cutler thought he did it right in VMS and didn't see any good reason to do things differently; taking ideas (or even data structure names, e.g. I/O Request Packets) from elsewhere is different from taking code.
And VA Research has SPEC numbers on their site last I checked.
But there aren't any SPECWeb results on the SPEC Web site (that's "SPEC" "Web site", not "SPECWeb" site; i.e., it's the Web site for the Standard Performance Evaluation Corporation).
A search for "SPECweb" on VA Research's Web site turned up nothing; where did you find their SPECweb numbers? (SPECCPU numbers, say, aren't SPECweb numbers; the only "SPEC numbers" that count as a response to Microsoft's claim are SPECweb numbers....)
Lxrun is an open source application that enables you to run Linux applications unmodified with Solaris(TM) applications on the Solaris operating environment
on Intel platforms.
(emphasis added by me).
Re:Userland threads is faster
on
*BSD News
·
· Score: 2
So if FreeBSD's threads are implemented entirely in userland, how do they avoid putting all of a process's threads to sleep when one thread blocks on IO?
By wrapping a pile of API calls (e.g., read(), write(), etc.) so that descriptors run in non-blocking mode (with the non-blocking mode that the API calls return being maintained by the threads library, rather than being the kernel's value for that mode), using an unwrapped select() in the thread scheduling loop, etc.. See the stuff in the lib/libc_r/uthread directory in the FreeBSD source tree.
No, it doesn't keep the entire process from blocking if, say, a file read() reading from a file server blocks because the file server isn't responding, but it catches the common case of reads or writes from serial ports, network connections, and the like.
Re:Why should I switch to *BSD?
on
*BSD News
·
· Score: 1
For example, the BSD groups have been so strapped for cash that they can not even afford to manufacture their own CD ROMS anymore.
Do you have any evidence to back this up? The story cited in another posting says only that they're "providing grants to the OpenBSD, FreeBSD, NetBSD, and Debian Linux development projects, to support each of them in issuing new releases.", and says that this is "because CDs of their distributions will be given away for free at the Usenix Technical Conference in June".
If the continued existence of the BSDs (or of Debian GNU/Linux, for that matter) makes you unhappy, I wish you many years of continued unhappiness....
Windows and MacOS have the GUI integrated into the kernel
At least in Windows NT, most of the GUI still appears to run in userland, even in 4.0, even though the low-level GDI stuff was shoved into the kernel in 4.0.
So do you believe that Multics wasn't fine technology, or do you believe it didn't end up on the ash heap?
I am not saying BeOS is doomed to end up on the ash heap. I don't know where BeOS will end up (and I suspect many of the people who think they know - whether they think they know it'll succeed, or that it'll end up on the ash heap - don't really know, either). I'm saying I've seen nothing to lead me to believe that "Fine technology never makes it to the ash heap." It'd be lovely if that were true, but I've seen nothing to convince me it's true.
BTW, why doesn't anyone mention Dennis Ritchy? He has said some good things about Linux. Also, he did a hell of a lot more work on AT&T Unix than Thompson did. He wrote the C compiler and put together most of the kernel. Thompson wrote the filesystem and text formatters.
UNIX was written by K. Thompson. I wrote much of the system software; Ken most of the rest; Other contributors have been Joe Ossanna, Doug McIlroy, and Bob Morris.
Upon what do you base your assertion that Dennis "put together most of the kernel"?
For that matter, as I remember, Joe Ossanna wrote "nroff" and "troff"....
Subsequently, I aided Ken Thompson in creating the Unix operating system. After Unix had become well established in the Bell System and in a number of educational, government and commercial installations, Steve Johnson and I (helped by Ken) transported the operating system to the Interdata 8/32, thus demonstrating its portability, and laying the groundwork for the widespread growth of Unix: the Seventh Edition version from the Bell Labs research group was the basis for commercial Unix System V and also for the Unix BSD distributions from the University of California at Berkeley. The last important technical contribution I made to Unix was the Streams mechanism for interconnecting devices, protocols, and applications.
As I recall, the 36-bit extention to the Pentium Pro/II/III is an ugly hack.
Perhaps uglier than, say, what the SPARC Reference MMU did on boring old 32-bit SPARC V7 and SPARC V8 processors to let you get 36-bit physical addresses, as the P6 trick requires 64-bit page directory and page table entries, while the SRMMU did it with 32-bit PTEs, but that might be a result of all the historical baggage Intel has to carry around.
I think only a special version of Wint can use it.
Given that the person to whom you're replying said
Sun has done it already with Solaris 7 3/99 release:
The Physical Address Extension (PAE) is a new feature of the Intel platform edition of the 3/99 update that provides greater scalability and higher performance for Intel Pentium Pro systems. It allows you to address up to 32 Gbytes of physical memory on a Pentium Pro system...
The two gig limit is a x86 limit; try putting more then two gigs on a non-xenon system.
I may be misremembering, but I think Sequent had systems with 4GB per NUMA-Q node (and, I suspect, probably allowed each node to access memory in the other nodes) before Xeon Warrior Princess was out.
Xenon's have a hack to see more then two gigs
The MMU trick to handle more than 4GB (not 2GB) of main memory dates back to the Pentium Pro; it wasn't introduced in the Xeons. The support chips for Xeon may have introduced features to handle more than 4GB of physical memory, but that's a different issue (and folks such as Sequent may well have rolled their own support chips).
Very often, you get a specific client that asks for improvements in the compiler, and pays for it. So they get back their compiler, and for a while it's unavailable to the public at large.
...unless the client decides to give the compiler away to the public, which they may choose to do - or may choose not to do. The GPL doesn't let Cygnus keep the client from doing so; it also doesn't oblige the client to do so. (A clarification, in case anybody argues that the GPL requires that the compiler be available to the public from Day One, not a disagreement with the points you make, which are correct.)
Re:Hmm they said they had GNU/linux working AND ..
on
Gcc for the IA-64.
·
· Score: 1
well they said they had GNU/Linux working already on IA64 a while back
I must've missed that. Could you give a reference?
well intel will want to keep all of its dirty little secrets of the compiler to itself or anybody can reproduce the silicon easy peasey because the machine is dumb and the compiler knows all !!
There are other ways of keeping people from implementing your instruction set architecture, e.g. patents; there are a couple of patents that might apply to IA-64 implementations, namely US patent 5638525 and US patent 5859999.
(I also wouldn't assume there's no cleverness in the silicon; punting a lot of the work to the compiler doesn't necessarily mean getting a CPU "so simple even a child could do it".)
For instance, SuSE is based on proprietary tools. It could easily get rid of even the free-of-charge distribution it offers today if it gains a monopoly. Then, even though the kernel would be free, the whole OS would no longer be.
If there are "proprietary tools" in SuSE, then "the whole OS", in the sense of SuSE Linux, is already "no longer [free]", at least in the "speech" sense.
However, more than just the kernel is free, in the speech (and beer) sense; the C library is free, as are the other libraries that implement the UNIX API, and as are the utilities that implement the UNIX command set and most of the GUI (Qt 1.x being an exception, although 2.0 might be considered free).
SuSE (or any other distributor), for example, couldn't keep you from redistributing, for free (speech and beer), the free components in its OS. Only if its monopoly got people to depend on the proprietary parts of the OS (and if those parts couldn't be, or weren't, cloned) would they have a stranglehold.
Blocking in software vs. ignoring in meatware
on
ShutUp Software
·
· Score: 1
One of the most elemental, if not technological, freedoms of any reader is to simply ignore what he or she deems a waste of time. Scroll to the next column or feature; why isn't that choice enough? Why build new software to ban ideas?
Because, if the volume of stuff on some forum is sufficiently high, a little technological assistance in separating wheat from chaff might make the difference between continuing to read a forum - including, perhaps, some stuff with which you disagree - and simply giving up, which still means you don't see the stuff that you would have blocked, but also means you see stuff that you wouldn't have blocked.
If somebody wishes to choose to use meatware to do all their filtering, more power to them; I will not always make that choice. I don't consider everything worth reading, and am willing to take the risk of not seeing something worth reading if it's in a thread filled with, say, fact-free opining - or, for that matter, if it's discussing a topic in which I have no interest.
I sympathize with your comments about software that blocks at the source, as that's Person A keeping Person B from seeing something; I don't sympathize with your comments about blocking at the reader, as that's just Person A choosing to have something they don't want to read not even offered to them, rather than dismissing it after a quick glance (if there's enough stuff to read, the fact that you only have to glance quickly at one item to realize you're not interested doesn't necessarily mean glancing at all the items won't take a significant amount of your time).
Slashdot Mirror
The architecture page on the Berlin Consortium Web site says:
so it appears to be a window system for, err, umm, UNIX-flavored OSes, so it doesn't appear as if it'll contribute to the death of UNIX.
As for the Hurd, the page on the Hurd on the GNU Project Web site says:
so it looks as if it's intended to, among other things, provide a UNIX-like API. ("UNIX NT"?)
Perhaps you should replace your subject line with "UNIX must evolve." - both Berlin and the Hurd appear to be trying to contribute to UNIX's evolution, not its death.
(What sort of "baggage" do you see being the problem? What do you see as the consequences of UNIX "[having] been a console-based operating system for a very long time"?)
Given that FreeBSD, NetBSD, and OpenBSD are all free software, I'm not sure how "the BSD license" allowed them to spin off from BSD and "the GPL" would have prevented that.
The GPL doesn't say you can't take the Linux kernel or GCC or... and make your own separate version thereof; you just have to make source available to everyone to whom you make the binary available, "cause the modified files to carry prominent notices stating that you changed the files and the date of any change", allow anybody who got your separate version to freely give it away, etc..
I don't know if they paid royalties, but SCO UNIX (and some other SVR3/SVR4 UNIXes) did include Xenix-compatibility code; there was a suit wherein, as I remember, SCO sued to be allowed to yank that code out of one of their UNIXes.
As far as I know, Xenix was originally a Microsoft product; I think they ended up handing it off to SCO.
Given that UNIX systems have supported long (as in greater than 14 characters) file names, with spaces, as far back as 1982, what are they a "good case" of? (They supported file names with spaces at least as far back as 1975-1976; I'm using 1982 as the first time they supported long file names, as that's when, as I remember, the BSD file system first arrived - I'm assuming, perhaps incorrectly, that it was the first UNIX file system to support file names longer than 14 characters.)
Until OS/2 came out, "Micros~1 long file names with spaces" presumably meant Xenix file names with spaces, but, as far as I know, Xenix had the old V7 UNIX file system, with 14-character names.
You require that a token that contains spaces be included within quotes, as UNIX shells have done for ages, and as the Microsoft Windows NT shell (and, I think, the Windows OT shell) does. (At least in UNIX you can use double or single quotes; I often forget that single quotes don't work in the Windows NT shell.)
In a GUI, the quotes may not be necessary, but that applies to UNIX or MacOS, say, just as it applies to Windows.
Good question. I may be missing something, but, as far as I can tell, there's no hardware reason why an OS couldn't let multiple PCI devices share the same IRQ (heck, I did much of the PCI support for an OS that did so on hardware not too far from a somewhat fancy PC, namely NetApp's Data ONTAP on the F3xx and F2xx filers).
Perhaps many PC OSes don't support that, but, if so, perhaps those OSes will get fixed for IA-64 (although if Windows 9x is one of those OSes , it may not get fixed, so people who have to reboot their shiny new IA-64 workstation to run some games might be screwed).
Could be; if I remember correctly, they handled the transition from the 16-bit stack-machine HP 3000's to the 32-bit PA-RISC HP 3000's by doing binary-to-binary translation, and they may plan on handling the PA-RISC to IA-64 transition in the same fashion.
Start, perhaps, but not finish. The document in question is the IA-64 Application Developer's Architecture Guide, which appears not to give all the details needed for low-level OS programming; it says:
and some of those details will presumably be necessary for OS kernel work.
...or mapping Win32 to UNIX/X APIs (given that GNU/Linux APIs are largely the same as those on other UNIX-flavored OSes).
In fact, that is what they did for the Solaris and HP-UX ports; they used Mainsoft's MainWin, as I mentioned in another comment. Presumably Mainsoft's stuff can be made to work on Linux, as well.
The same was true of IE4, according to stuff on Mainsoft's site.
I saw something ages ago on, I think, Microsoft's Web site indicating that they were developing a Win32-atop-MacOS package and getting third parties to do Win32-atop-UNIX packages; they were, I think, pushing this as a way of getting app developers - or, at least, custom in-house app developers - to write Win32 apps and to get them on other platforms with those packages. I don't know if that's the way they do MacOS ports of their own apps.
Umm, he said that it loses "from a theoretical (and aesthetical) standpoint". This is inequivalent to saying that it "would have been better" from a pragmatic standpoint. uote>Proprietary kernels probably evolve much faster but you don't get to watch it.
Perhaps, perhaps not. The fact that "you don't get to watch it" means you can only guess (unless you happen to be one of the people who "get to watch it").
How much have, say, the Solaris or NT kernel architectures changed, relative to the extent that the Linux (or *BSD) kernels have changed? (BTW, neither of them are what I would call a microkernel, not even NT - NT's device drivers, file systems, and networking stack run in kernel mode, for example.)
I have the impression that at least some of the developers of kernel code for free OSes do both.
Fascinating assertion. Do you have any references to prove that Cutler took VMS code (or code from any of the OS projects I think he worked on at DEC after VMS) and put it into NT, if that's what you're claiming?
Yes, some of the NT I/O subsystem looks VMSish, but perhaps Cutler thought he did it right in VMS and didn't see any good reason to do things differently; taking ideas (or even data structure names, e.g. I/O Request Packets) from elsewhere is different from taking code.
But there aren't any SPECWeb results on the SPEC Web site (that's "SPEC" "Web site", not "SPECWeb" site; i.e., it's the Web site for the Standard Performance Evaluation Corporation).
A search for "SPECweb" on VA Research's Web site turned up nothing; where did you find their SPECweb numbers? (SPECCPU numbers, say, aren't SPECweb numbers; the only "SPEC numbers" that count as a response to Microsoft's claim are SPECweb numbers....)
(There are NT+IIS numbers on the SPEC site.)
...and, probably, a common libc, at least when all distributions adopt glibc2.1. There's more to an ABI than just system calls....
They are only talking about x86 Solaris; this item from Sun's Web site (linked to by the article) says:
(emphasis added by me).
By wrapping a pile of API calls (e.g., read(), write(), etc.) so that descriptors run in non-blocking mode (with the non-blocking mode that the API calls return being maintained by the threads library, rather than being the kernel's value for that mode), using an unwrapped select() in the thread scheduling loop, etc.. See the stuff in the lib/libc_r/uthread directory in the FreeBSD source tree.
No, it doesn't keep the entire process from blocking if, say, a file read() reading from a file server blocks because the file server isn't responding, but it catches the common case of reads or writes from serial ports, network connections, and the like.
Do you have any evidence to back this up? The story cited in another posting says only that they're "providing grants to the OpenBSD, FreeBSD, NetBSD, and Debian Linux development projects, to support each of them in issuing new releases.", and says that this is "because CDs of their distributions will be given away for free at the Usenix Technical Conference in June".
If the continued existence of the BSDs (or of Debian GNU/Linux, for that matter) makes you unhappy, I wish you many years of continued unhappiness....
At least in Windows NT, most of the GUI still appears to run in userland, even in 4.0, even though the low-level GDI stuff was shoved into the kernel in 4.0.
So do you believe that Multics wasn't fine technology, or do you believe it didn't end up on the ash heap?
I am not saying BeOS is doomed to end up on the ash heap. I don't know where BeOS will end up (and I suspect many of the people who think they know - whether they think they know it'll succeed, or that it'll end up on the ash heap - don't really know, either). I'm saying I've seen nothing to lead me to believe that "Fine technology never makes it to the ash heap." It'd be lovely if that were true, but I've seen nothing to convince me it's true.
Here are some notes Dennis Ritchie found on an old DECtape he had, in which he says:
Upon what do you base your assertion that Dennis "put together most of the kernel"?
For that matter, as I remember, Joe Ossanna wrote "nroff" and "troff"....
In his bio on his Web site, Dennis also says:
Perhaps uglier than, say, what the SPARC Reference MMU did on boring old 32-bit SPARC V7 and SPARC V8 processors to let you get 36-bit physical addresses, as the P6 trick requires 64-bit page directory and page table entries, while the SRMMU did it with 32-bit PTEs, but that might be a result of all the historical baggage Intel has to carry around.
Given that the person to whom you're replying said
I'm not sure why you think that.
I may be misremembering, but I think Sequent had systems with 4GB per NUMA-Q node (and, I suspect, probably allowed each node to access memory in the other nodes) before Xeon Warrior Princess was out.
The MMU trick to handle more than 4GB (not 2GB) of main memory dates back to the Pentium Pro; it wasn't introduced in the Xeons. The support chips for Xeon may have introduced features to handle more than 4GB of physical memory, but that's a different issue (and folks such as Sequent may well have rolled their own support chips).
...unless the client decides to give the compiler away to the public, which they may choose to do - or may choose not to do. The GPL doesn't let Cygnus keep the client from doing so; it also doesn't oblige the client to do so. (A clarification, in case anybody argues that the GPL requires that the compiler be available to the public from Day One, not a disagreement with the points you make, which are correct.)
I must've missed that. Could you give a reference?
There are other ways of keeping people from implementing your instruction set architecture, e.g. patents; there are a couple of patents that might apply to IA-64 implementations, namely US patent 5638525 and US patent 5859999.
(I also wouldn't assume there's no cleverness in the silicon; punting a lot of the work to the compiler doesn't necessarily mean getting a CPU "so simple even a child could do it".)
If there are "proprietary tools" in SuSE, then "the whole OS", in the sense of SuSE Linux, is already "no longer [free]", at least in the "speech" sense.
However, more than just the kernel is free, in the speech (and beer) sense; the C library is free, as are the other libraries that implement the UNIX API, and as are the utilities that implement the UNIX command set and most of the GUI (Qt 1.x being an exception, although 2.0 might be considered free).
SuSE (or any other distributor), for example, couldn't keep you from redistributing, for free (speech and beer), the free components in its OS. Only if its monopoly got people to depend on the proprietary parts of the OS (and if those parts couldn't be, or weren't, cloned) would they have a stranglehold.
Because, if the volume of stuff on some forum is sufficiently high, a little technological assistance in separating wheat from chaff might make the difference between continuing to read a forum - including, perhaps, some stuff with which you disagree - and simply giving up, which still means you don't see the stuff that you would have blocked, but also means you see stuff that you wouldn't have blocked.
If somebody wishes to choose to use meatware to do all their filtering, more power to them; I will not always make that choice. I don't consider everything worth reading, and am willing to take the risk of not seeing something worth reading if it's in a thread filled with, say, fact-free opining - or, for that matter, if it's discussing a topic in which I have no interest.
I sympathize with your comments about software that blocks at the source, as that's Person A keeping Person B from seeing something; I don't sympathize with your comments about blocking at the reader, as that's just Person A choosing to have something they don't want to read not even offered to them, rather than dismissing it after a quick glance (if there's enough stuff to read, the fact that you only have to glance quickly at one item to realize you're not interested doesn't necessarily mean glancing at all the items won't take a significant amount of your time).