Buy windows 2000 and you have to download 1 service pack and thats means its a terrible OS that needs constant patching. Download linux 2.4.0 then 2.4.1 and then 2.4.2 in less than half that timespan and rather than meaning that 2.4.0 was a terrible OS that needs constant patching it is an innovative OS with a rapid turnaround. Am I the only one who spots the hipocracy here?
I see no hypocrisy.
First, when I make a judgement like that about a Microsoft product, it's not because of the number of service packs. I realize that all software of that complexity has bugs. It's instead that their software doesn't work well for me, even after applying all the service packs. Their service packs just don't seem to fix all the important problems for me, no matter how many I apply. For example, I've patched my Windows 98 system to the latest Windows Update stuff, but I'm still having some weird problems with Internet Explorer.
Second, Linux x.y.z releases are not just bugfix releases. In this case, it probably is...x.y.[1-5] typically are. But there are many new features introduced in point releases. 2.2.18 (or was it 2.2.19?), for example, backported USB support to the 2.2 series. I see a lot of important new features introduced in new Linux point releases, which I don't see in Windows service packs. Having a specific x.y just means the basic architecture is constant, not that the feature set is.
Third, as someone else mentioned, you don't need to upgrade to a new kernel revision to fix a bug. You have the source code, and you have the full patches. If you just want to fix one bug, you can do that. You don't have that option with Microsoft code, since it's not open-source.
You may be right. But it is theoretically possible, and IMO people should always behave in any sort of public forum as if it is likely; never saying overly negative things except in a professional manner, and being able to back them up. I imagine the original questioner did that, but I would have to see the message and really know the situation to be sure.
I believe that Yahoo has a nice disclaimer that says something like there is no guarantee to the validity of the statements made on the message boards.
That's not quite what it says. It says that Yahoo does not guarantee the validity of these statements. That's the standard disclaimer just about any message board has, since they can't go through every message and verify everything. The people who post have the same responsibility to the truth as they would in any other forum.
The fact that the company is even considering "going after" this guy is just funny (see: sick and wrong). Seems to me that they need a reality check - or they're afraid simply afraid of what was posted and are panicking.
No argument there.
Either way, the company can do nothing.
Not quite true. If it is libel, they can take it to court and win. But the strongest argument against a libel case is, of course, the truth. If he can back up what he said, they can do nothing.
Yes, this is a monopolistic situation, but as with most Microsoft "monopolies" this is a natural monopoly.
You're partly right. Yes, this is a monopoly. Yes, this is a natural monopoly — Microsoft did something no one else does, and there's nothing wrong with that. I object, though, that you said this is as with most Microsoft "monopolies" a natural monopoly. The courts have ruled that Microsoft has abused their monopoly in the past with anti-competitive practices. They don't appear to be doing so in this case (at least I have no evidence of it) but they certainly have in other areas. Don't forget that.
join a battlenet game of starcraft hosted by someone on the same LAN.
I have this problem, too, but I don't think there's anything Linux or other NAT-capable OSs can do about it. I found this on the blizzard homepage a long time ago:
Q: I can play games but only with one machine at one time. A: This is because you only have one IP address.
So it sounds like battle.net needs a unique IP for each user. I think I'd be preaching to the choir if I said how incredibly stupid this is.
I'd say the iptables way is easier to understand, for a couple reasons:
ipfilter has a "quick" flag to block and pass. If it is set, packets immediately do that action. If it is not, it sets a flag...the next rule down could reverse it. iptables is more simple; effectively the same as ipfilter with everything quick. In my opinion, simplicity is very important for a firewall, since you really don't want your firewall admin to be confused about what's really happening. (I do realize that an ipf admin could use the quick keyword on everything if (s)he wanted to. I still think it should always be this way, since it's easy to miss.)
The ipfilter "keep state" bypasses all normal firewall rules; there's an implicit allow to everything with state associated with it. iptables requires you to specify the rule accepting things with state information. This is much more clear, at least to me. Again...you don't want confused firewall admins. I like seeing everything that happens. Hidden rules scare me.
You posted this setup:
block in quick on tun0 all head 1
block out quick on tun0 all head 11
pass on tun0 from any to any keep state group 1
From my memory (I have set up ipf on an OpenBSD machine, but it's been a while) and the ipf(5) manpage, that does this:
packets with state information pass through
new packets coming IN to the machine from ipf set up new state information, but the lead packet is rejected
all new packets going OUT of the machine are rejected
I think what you meant to say was this...
pass out quick on tun0 all keep state
block in quick on tun0 all
Which looks very, very simple. But remember...it has a hidden rule. I don't like that.
The iptables setup is very clear, at least to me. You accept packets that are part of or related to established connections. (The ip_conntrack_ftp line and the RELATED keyword are options that do not exist in ipf, so they don't complicate it. To do a true comparison of the same firewall, you should take them out.) You also accept new packets that don't come from the ppp interface. I imagine this is more in line with what you wanted.
The one that is easiest to read is not necessarily the one with the fewest number of lines. ipfilter has a more complex grammar but AFAIK doesn't support any more capabilities.
I am really looking forward to stuff using the X Render extension (anyone have any examples of anyone using it? Docs on how to use them? I so want real transparent terminals...)...
The RENDER extension is definitely being used, by Qt. KDE's CVS version of Qt now includes patches to make it do font rendering. The great thing is that this is all at a very low level, so it's completely transparent to the application programmer. All of my KDE applications have well-kerned, well-hinted, fully anti-aliased proportional fonts. The same is possible with gtk+; in fact I'd heard that someone had it working at one point.
As far as docs, I don't believe there is much right now. There is an incomplete Xft manual page for the library dealing with the font stuff (basically renders fonts in truetype and feeds them to X using the render extension). There is also probably likely to be something at the render mailing list.
Real transparent terminals...as I understand it, that requires a seperate extension. Render creates the option of alpha blending, but it takes something else to do it on the window level, rather than on top of an opaque window.
Perhaps you could model them as a bag of *indepedent* features rather than try
to filter them through a hierarchical taxonomy.
I'm not exactly sure how something like that would work.
I suppose one way would be to have base classes like Readable, Writable, Seekable, and Selectable. Then each class, like FileStream would be derived from just the ones it implements.
But that doesn't really make the problem of things appearing to do more than they can go away, because what a FileStream can do depends on what you open. Ie, you can select() on/dev/tty but not/etc/passwd. You can lseek() on/etc/passwd but not/dev/tty. And besides, it makes everything considerably more complicated to have lots of multiple inheritance involved.
Another solution might be to make each of these -- Readable, Writable, Seekable, and Selectable -- something you get from the Stream. Ie, you have a stream and call getReadable() on it. If it returns null, you can't do that. It would give a complete picture of what the object could do, even if it changes at runtime...but it would also make it slightly more complicated to do basic operations. I don't really like that.
My solution to this problem is to put most of these things -- read, write, seek -- all the way in the base class. I also have canRead(), canWrite(), and canSeek() members to tell me if these options are available. (If you try to use read(), write(), seek(), or tell() when they are not, a CallerLogicError is thrown.) Since the answer can change at runtime, this seems to be the only real option to me. Plus, this way makes the interface very simple and easy to understand, a big goal for my project. It doesn't perfectly model everything, but it's better than having a different set of functions for dealing with each type of stream...a complete pain to use.
StreamSocket, on the other hand, is a dogcat. I gave an abbreviated version of my inheritance. More completely...
OSStream : public Stream, public virtual Descriptor
Socket : public virtual Descriptor
StreamSocket : public OSStream, public Socket
... so StreamSocket combines the attributes of a stream and the attributes of a socket. It can be closed, created, connecting, connected, or listening. (bound is not listed, it seems to be optional when either connecting or listening.) Most socket options are available in any state. Most stream options are available only when connected. I had to design the Stream interface a bit carefully so this wouldn't violate it. In particular, its isClosed() and isOpened() checks may both return false, if the StreamSocket is in one of these other states. So far, this choice works well. StreamSocket gives much of the functionality of the basic UNIX system calls already, and I see no reason it can't eventually do it all. All while being fairly easy to use.
I've done quite a bit of C++ programing and never once in my life have I reused code through inheritance
Then you weren't doing object-oriented programming. I don't care what language you used, that's a central part of OO. You can write in C without using do/while/for/switch as well, it just won't be good C.
The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.
That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.
That allows me to have the same easy IO operations on top of many different kinds of streams:
OSStream - what the operating system considers a stream. Can attach to a given fd, etc.
FileStream - derived from OSStream, adds the ability to open a named object. (kind of a misnomer, could be a FIFO or whatever.)
StreamSocket - also derived from OSStream, blends with a lot of socket functionality.
PGLargeObjectStream - a PostgreSQL BLOB (binary large object). Basically, like a file but stored in a PostgreSQL database instead of using an inode. Handy because filesystems have limited number of inodes, not good for lots and lots of small files.
SSLStream - a SSL connection, requires another open Stream (probably a StreamSocket) to connect.
Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.
This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.
This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.
Thank you for answering the question concisely with your comparison to FreeBSD. I know a lot of FreeBSD advocates who would just say generally Linux sucks and should be scrapped. Instead, you gave two specific examples of things you think FreeBSD does better (and certainly there's some evidence to support your claim). Things which are possible, though not necessarily easy, to fix.
Slashdot Mirror
Buy windows 2000 and you have to download 1 service pack and thats means its a terrible OS that needs constant patching. Download linux 2.4.0 then 2.4.1 and then 2.4.2 in less than half that timespan and rather than meaning that 2.4.0 was a terrible OS that needs constant patching it is an innovative OS with a rapid turnaround. Am I the only one who spots the hipocracy here?
I see no hypocrisy.
First, when I make a judgement like that about a Microsoft product, it's not because of the number of service packs. I realize that all software of that complexity has bugs. It's instead that their software doesn't work well for me, even after applying all the service packs. Their service packs just don't seem to fix all the important problems for me, no matter how many I apply. For example, I've patched my Windows 98 system to the latest Windows Update stuff, but I'm still having some weird problems with Internet Explorer.
Second, Linux x.y.z releases are not just bugfix releases. In this case, it probably is...x.y.[1-5] typically are. But there are many new features introduced in point releases. 2.2.18 (or was it 2.2.19?), for example, backported USB support to the 2.2 series. I see a lot of important new features introduced in new Linux point releases, which I don't see in Windows service packs. Having a specific x.y just means the basic architecture is constant, not that the feature set is.
Third, as someone else mentioned, you don't need to upgrade to a new kernel revision to fix a bug. You have the source code, and you have the full patches. If you just want to fix one bug, you can do that. You don't have that option with Microsoft code, since it's not open-source.
You may be right. But it is theoretically possible, and IMO people should always behave in any sort of public forum as if it is likely; never saying overly negative things except in a professional manner, and being able to back them up. I imagine the original questioner did that, but I would have to see the message and really know the situation to be sure.
I believe that Yahoo has a nice disclaimer that says something like there is no guarantee to the validity of the statements made on the message boards.
That's not quite what it says. It says that Yahoo does not guarantee the validity of these statements. That's the standard disclaimer just about any message board has, since they can't go through every message and verify everything. The people who post have the same responsibility to the truth as they would in any other forum.
The fact that the company is even considering "going after" this guy is just funny (see: sick and wrong). Seems to me that they need a reality check - or they're afraid simply afraid of what was posted and are panicking.
No argument there.
Either way, the company can do nothing.
Not quite true. If it is libel, they can take it to court and win. But the strongest argument against a libel case is, of course, the truth. If he can back up what he said, they can do nothing.
Yes, this is a monopolistic situation, but as with most Microsoft "monopolies" this is a natural monopoly.
You're partly right. Yes, this is a monopoly. Yes, this is a natural monopoly — Microsoft did something no one else does, and there's nothing wrong with that. I object, though, that you said this is as with most Microsoft "monopolies" a natural monopoly. The courts have ruled that Microsoft has abused their monopoly in the past with anti-competitive practices. They don't appear to be doing so in this case (at least I have no evidence of it) but they certainly have in other areas. Don't forget that.
Some of the things I cannot do are:
join a battlenet game of starcraft hosted by someone on the same LAN.
I have this problem, too, but I don't think there's anything Linux or other NAT-capable OSs can do about it. I found this on the blizzard homepage a long time ago:
Q: I can play games but only with one machine at one time.
A: This is because you only have one IP address.
So it sounds like battle.net needs a unique IP for each user. I think I'd be preaching to the choir if I said how incredibly stupid this is.
I'd say the iptables way is easier to understand, for a couple reasons:
You posted this setup:
block in quick on tun0 all head 1
block out quick on tun0 all head 11
pass on tun0 from any to any keep state group 1
From my memory (I have set up ipf on an OpenBSD machine, but it's been a while) and the ipf(5) manpage, that does this:
I think what you meant to say was this...
pass out quick on tun0 all keep state
block in quick on tun0 all
Which looks very, very simple. But remember...it has a hidden rule. I don't like that.
The iptables setup is very clear, at least to me. You accept packets that are part of or related to established connections. (The ip_conntrack_ftp line and the RELATED keyword are options that do not exist in ipf, so they don't complicate it. To do a true comparison of the same firewall, you should take them out.) You also accept new packets that don't come from the ppp interface. I imagine this is more in line with what you wanted.
The one that is easiest to read is not necessarily the one with the fewest number of lines. ipfilter has a more complex grammar but AFAIK doesn't support any more capabilities.
I am really looking forward to stuff using the X Render extension (anyone have any examples of anyone using it? Docs on how to use them? I so want real transparent terminals...)...
The RENDER extension is definitely being used, by Qt. KDE's CVS version of Qt now includes patches to make it do font rendering. The great thing is that this is all at a very low level, so it's completely transparent to the application programmer. All of my KDE applications have well-kerned, well-hinted, fully anti-aliased proportional fonts. The same is possible with gtk+; in fact I'd heard that someone had it working at one point.
As far as docs, I don't believe there is much right now. There is an incomplete Xft manual page for the library dealing with the font stuff (basically renders fonts in truetype and feeds them to X using the render extension). There is also probably likely to be something at the render mailing list.
Real transparent terminals...as I understand it, that requires a seperate extension. Render creates the option of alpha blending, but it takes something else to do it on the window level, rather than on top of an opaque window.
Perhaps you could model them as a bag of *indepedent* features rather than try to filter them through a hierarchical taxonomy.
I'm not exactly sure how something like that would work.
I suppose one way would be to have base classes like Readable, Writable, Seekable, and Selectable. Then each class, like FileStream would be derived from just the ones it implements. But that doesn't really make the problem of things appearing to do more than they can go away, because what a FileStream can do depends on what you open. Ie, you can select() on /dev/tty but not /etc/passwd. You can lseek() on /etc/passwd but not /dev/tty. And besides, it makes everything considerably more complicated to have lots of multiple inheritance involved.
Another solution might be to make each of these -- Readable, Writable, Seekable, and Selectable -- something you get from the Stream. Ie, you have a stream and call getReadable() on it. If it returns null, you can't do that. It would give a complete picture of what the object could do, even if it changes at runtime...but it would also make it slightly more complicated to do basic operations. I don't really like that.
My solution to this problem is to put most of these things -- read, write, seek -- all the way in the base class. I also have canRead(), canWrite(), and canSeek() members to tell me if these options are available. (If you try to use read(), write(), seek(), or tell() when they are not, a CallerLogicError is thrown.) Since the answer can change at runtime, this seems to be the only real option to me. Plus, this way makes the interface very simple and easy to understand, a big goal for my project. It doesn't perfectly model everything, but it's better than having a different set of functions for dealing with each type of stream...a complete pain to use.
StreamSocket, on the other hand, is a dogcat. I gave an abbreviated version of my inheritance. More completely ...
... so StreamSocket combines the attributes of a stream and the attributes of a socket. It can be closed, created, connecting, connected, or listening. (bound is not listed, it seems to be optional when either connecting or listening.) Most socket options are available in any state. Most stream options are available only when connected. I had to design the Stream interface a bit carefully so this wouldn't violate it. In particular, its isClosed() and isOpened() checks may both return false, if the StreamSocket is in one of these other states. So far, this choice works well. StreamSocket gives much of the functionality of the basic UNIX system calls already, and I see no reason it can't eventually do it all. All while being fairly easy to use.
Anyway, thanks for the suggestion.
I've done quite a bit of C++ programing and never once in my life have I reused code through inheritance
Then you weren't doing object-oriented programming. I don't care what language you used, that's a central part of OO. You can write in C without using do/while/for/switch as well, it just won't be good C.
The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.
That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.
That allows me to have the same easy IO operations on top of many different kinds of streams:
Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.
This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.
This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.
You can use either your Visa card or your PayPal account to send your contribution.
Support MasterCard and I'd donate. I don't have a Visa card, and it seems pretty silly to me to go through two intermediaries - FairTunes and PayPal.
Thank you for answering the question concisely with your comparison to FreeBSD. I know a lot of FreeBSD advocates who would just say generally Linux sucks and should be scrapped. Instead, you gave two specific examples of things you think FreeBSD does better (and certainly there's some evidence to support your claim). Things which are possible, though not necessarily easy, to fix.
You are correct; it is all of those things.
But...some non-features:
If you want a browser, I suggest:
So...those are your choices. Rejoice.