Corba isn't an Unix protocol. Your belief is just evidence that Windows developers tend to be Microsoft blinded and impervious to technologies from places other than Redmond.
X11 is a specific application protocol. For that particular application, a binary protocol make sense. It doesn't belong in this discussion.rpc/portmap has little actual use outside of NFS. I place it into the category of application-specific protocols.
DCOP and Bonobo (which is just Corba, you know) are current desktop environments' attempts at copying the Microsoft/Apple architectures. They are not proven, and I doubt they get the same kind of interoperability plain text interfaces do.
Plain text interfaces are at the core of most of the +2000 binaries I have sitting in/usr/bin. The fact of the matter is that all of these are self-documented, and all of these are pieces for me to use as a developer -- even when developing small, one shot, shell commands. This kind of power was never available to Microsoft OS users, and will probably never be.
PS: And, naturally 'cat/dev/sda1' does not produce text. It could never produce text. When people run out of arguments, they start nitpicking on details...
i would say that textual interfaces were more popular before bandwidth started becoming readily available. the rise of bandwidth has seen a rise of GUI applications because it is quite feasible to VNC from home->work and to run GUI. before ADSL it was a pain in the arse and using textual interfaces was fast and convenient.
That completely misses the point of a textual interface. When Unix people talk about textual interfaces, the important interface isn't the user-interface. It's inter-application interfaces that really matter. Unix applications don't talk to each other via strange, binary, unreadable protocols such as Corba, COM, DCOM, COM+ or whatever MS is selling these days. They talk text. Simple, human readable, text. Stuff that I can probe and poke and dismantle. Stuff I can disassemble and assemble together again. I can pick and match little utilities to process data the way I want to.
Take cdrecord. cdrecord does the same stuff that the windows cd-rom recording libraries do: write a cd-rom. How do you feed the windows libraries data to write? I don't know. Are they self-documented? Nope. How do you feed cd-record? The most obvious way: give it an image to write via stdin:
cat image.iso | cdrecord
If I didn't know this, cdrecord --help tells me what to do. man cdrecord has a longer explanation with examples. I can get the application, usable by end users, and place it inside my backup scripts. Do this with the windows libraries or Nero or some other burning application. Tell me how long do you have to sift through documentation to do this: Find a way to backup a disk partition to a cdrom using the windows libraries. In any unix, this is something like:
cat/dev/sda1 | cdrecord
Will a end-user have trouble using command line cdrecord? Naturally. But cdrecord is a core application, which shouldn't be used by end users. That's what the Rule of Separation is about. Grab krecord or something like that, and use it.
Zope has got to be the best looking web technology out there, killed by lack of documentation. I've fiddled with quite a bit but, frankly, I don't have the time or inclination to always be using the source as API reference.
The *Terminate* part is the important one. In DOS, a task had to terminate in order for another one to be started. No longer. We've been using multitasking OSes for sometime now. Nowadays you can (*gasp*) run more than one app simultaneously.
A TSR? I haven't heard of those in well over a decade. The kind of TSR that grabs an interrupt handler? Are you talking of those? I got news: DOS is long dead in the mainstream market. We all run multitasking OSes these days:-)
My experience also, albeit not with LFS 4.1. I tried LFS a couple of years ago, and I don't remember the version exactly. It's excellent as a learning tool, and I recommend it to every newbie with a tech vein (i.e. if you want to look under the hood, this is one of the best tools).
However, for a long running system, LFS is way too time consuming. I switched to Gentoo after a while, with all the customization, at a fraction of the time cost.
RMS *must* be a low level hacker. He shows all the signs: long beard, long hair, smells, can't behave in front of people, yawns at conferences. Heck, he even farted at a conference at my Uni.
If he isn't a lowest level hacker, my world foundations are crumbling...
Try to get an smtp server on a port other than 25. Or try to have users remember that your url is http://www.example.com:3245/ and not wonder why you are down when they try to access through http://www.example.com/ and hit a different box.
NAT is a kludge and, albeit its success will never be more than a kludge, with bad side-effects.
But, I have to grant this, you are technically correct, and probably know NAT's problems as well as I do. It's just that less informed people might think that: a) NAT's don't have side effects. b) NAT's are good for security because they filter packets. Both are wrong.
You'll never escape the limit of n internal servers for n publicly addressable IPs. Not unless you do some kludge like having an http proxy looking at Host: headers on requests.
Microsoft's monopoly status was asserted in court, with highly solid evidence. I didn't think anyone would question it. Microsoft does does have exclusive control of the OEM market, using OEM pricing as a leverage to market domination. Owning the OEM market, they own the first instalation of software on the PC, allowing for their products to be placed first before the eyes of the user. Inertia then does the rest of the marketing...
It is a bug. No, don't get offended. Request for enhacements are usually treated just like bugs. It's a change request, will get a patch that solves the problem, and will require testing before inclusion in the main tree.
XF86 developers are right when directing you to bugzilla.
I think it usually is filesystem design. You see, in Windows, file locks are identified with the filename. So, if DLL C:\Windows\a32.dll is open and locked, the patch can't replace it and will schedule the replacement for the next reboot.
In most unix filesystems (namely ext2), a filename (directory entry) is a link to an inode number. Locks are applied to inodes. So, if I want to replace/usr/lib/a32.so, I unlink the directory entry, recreate the file with another inode, and fill it out with the new contents. The old contents, still locked by the application are still available on disk and untouched under the old inode. When the app restarts, it will read the new inode pointed by the new directory entry. You still need to restart applications affected, though.
And if your computers take longer to reboot than that, you have another problem.
Well, then I have a problem. Our central mail server, an IBM x350 takes two minutes to pass POST -- with no errors whatsoever, just regular testing -- and then up to five minutes reading up mail queues. Fortunately, it's a Linux box, so the last reboot was months ago.
How can you blame them? MS provides the hardware, the bandwidth, and the assumes the risk of operating this chat network. I like my 3rd party client, but you know what? I leach from MS by using it. They have every right to restrict who can use their network and how. If they want to use technological measures to limit who can access the network, than fine, so be it. I'll use their product or a competeting protocol.
This would be all very sane and true, were not Microsoft price dumping their entrance into the IM market. No, they are not alone in this nonsense. However, couple the price dumping with the ubiquitous presence of MSN on every windows desktop, and my sense of unfair competition is sounding an alarm. Now, when, in the future, Microsoft decides to lock out people (today was just a protocol change, no lock out happened), I'll feel more competent players for this position were kept out of the market by Microsoft's iron hand on the desktop and immensely deep pockets.
Describe the project in terms of technologies, size and, if possible, objectives. People reading resumes don't need to know exactly the project. If you need to reveal anything more to a potential employer, your letters to previous employer's legal departments will be much more focused (permission to reveal data X,Y and Z to individual W in the scenario of prospective employment).
Miguel, you focused your reply on the case of tail-chasing Microsoft APIs. Naturally, you concluded that tail-chasing will not hurt Mono, since there is no breakage of applications -- only breakage of portability between Mono.net and MS.net.
You forgot to mention the much bigger problem of patent brandishing. Microsoft did patent key components of.net. This gives them the power to suddenly yank out of Mono a set of components. It will surely cause applications to break. What do you expect the result to be? Will companies relying on Mono.net wait out until cases come out of court, will they rewrite their apps, or will they switch to windows? The answer is pretty obvious to me.
I don't think the adoption of Mono on OSS will be so significant that an event like this could cause a major earthquake. After all, most projects are still written in C. However, if it were, Mono could prove the biggest shot in the foot in modern times.
Remember, hardware, bandwith and system administrators all cost money.
So, please, by all means, charge me (as an end user) for the costs. Don't everybody (MSN,AIM/ICQ,Yahoo) try to leverage existing market dominance into a messenger monopoly. The network cost is not an excuse when you're dumping your way into a market.
Right now, I have friends using only one of MSN or AIM/ICQ. They were all, on occasion, uncontactable due to their respective IM network owners trying to finally shoot up to the IM market top position by closing protocols. Yahoo protocol closing was not so bad just because they have a crappy protocol. None of my friends use Yahoo as the only IM client.
I just hope all this nonsense makes people start switching to open protocols, even if they're just plain old IRC.
Slashdot Mirror
X11 is a specific application protocol. For that particular application, a binary protocol make sense. It doesn't belong in this discussion.rpc/portmap has little actual use outside of NFS. I place it into the category of application-specific protocols.
DCOP and Bonobo (which is just Corba, you know) are current desktop environments' attempts at copying the Microsoft/Apple architectures. They are not proven, and I doubt they get the same kind of interoperability plain text interfaces do.
Plain text interfaces are at the core of most of the +2000 binaries I have sitting in /usr/bin. The fact of the matter is that all of these are self-documented, and all of these are pieces for me to use as a developer -- even when developing small, one shot, shell commands. This kind of power was never available to Microsoft OS users, and will probably never be.
PS: And, naturally 'cat /dev/sda1' does not produce text. It could never produce text. When people run out of arguments, they start nitpicking on details...
duh!
Before filing any other complaints, please double-check current offerings.
Take cdrecord. cdrecord does the same stuff that the windows cd-rom recording libraries do: write a cd-rom. How do you feed the windows libraries data to write? I don't know. Are they self-documented? Nope. How do you feed cd-record? The most obvious way: give it an image to write via stdin:
cat image.iso | cdrecord
If I didn't know this, cdrecord --help tells me what to do. man cdrecord has a longer explanation with examples. I can get the application, usable by end users, and place it inside my backup scripts. Do this with the windows libraries or Nero or some other burning application. Tell me how long do you have to sift through documentation to do this: Find a way to backup a disk partition to a cdrom using the windows libraries. In any unix, this is something like:
cat /dev/sda1 | cdrecord
Will a end-user have trouble using command line cdrecord? Naturally. But cdrecord is a core application, which shouldn't be used by end users. That's what the Rule of Separation is about. Grab krecord or something like that, and use it.
<html>
<head/>
<body>
</body>
</html>
Wow! Really bloated...
I've canned it after two months.
The *Terminate* part is the important one. In DOS, a task had to terminate in order for another one to be started. No longer. We've been using multitasking OSes for sometime now. Nowadays you can (*gasp*) run more than one app simultaneously.
However, for a long running system, LFS is way too time consuming. I switched to Gentoo after a while, with all the customization, at a fraction of the time cost.
Troll? Moderators are on crack... Again.
If he isn't a lowest level hacker, my world foundations are crumbling...
NAT is a kludge and, albeit its success will never be more than a kludge, with bad side-effects.
But, I have to grant this, you are technically correct, and probably know NAT's problems as well as I do. It's just that less informed people might think that: a) NAT's don't have side effects. b) NAT's are good for security because they filter packets. Both are wrong.
NATing is *one* sort of packet filtering. You can have packet filtering without NAT without losing anything on security.
You'll never escape the limit of n internal servers for n publicly addressable IPs. Not unless you do some kludge like having an http proxy looking at Host: headers on requests.
Oh, not by any means :-) You can't coerce a dictionary definition by sheer money power. On second thought...
Microsoft's monopoly status was asserted in court, with highly solid evidence. I didn't think anyone would question it. Microsoft does does have exclusive control of the OEM market, using OEM pricing as a leverage to market domination. Owning the OEM market, they own the first instalation of software on the PC, allowing for their products to be placed first before the eyes of the user. Inertia then does the rest of the marketing...
I'd equate Gentoo to a semi-automatic.
XF86 developers are right when directing you to bugzilla.
In most unix filesystems (namely ext2), a filename (directory entry) is a link to an inode number. Locks are applied to inodes. So, if I want to replace /usr/lib/a32.so, I unlink the directory entry, recreate the file with another inode, and fill it out with the new contents. The old contents, still locked by the application are still available on disk and untouched under the old inode. When the app restarts, it will read the new inode pointed by the new directory entry. You still need to restart applications affected, though.
Well, then I have a problem. Our central mail server, an IBM x350 takes two minutes to pass POST -- with no errors whatsoever, just regular testing -- and then up to five minutes reading up mail queues. Fortunately, it's a Linux box, so the last reboot was months ago.
Describe the project in terms of technologies, size and, if possible, objectives. People reading resumes don't need to know exactly the project. If you need to reveal anything more to a potential employer, your letters to previous employer's legal departments will be much more focused (permission to reveal data X,Y and Z to individual W in the scenario of prospective employment).
You forgot to mention the much bigger problem of patent brandishing. Microsoft did patent key components of .net. This gives them the power to suddenly yank out of Mono a set of components. It will surely cause applications to break. What do you expect the result to be? Will companies relying on Mono.net wait out until cases come out of court, will they rewrite their apps, or will they switch to windows? The answer is pretty obvious to me.
I don't think the adoption of Mono on OSS will be so significant that an event like this could cause a major earthquake. After all, most projects are still written in C. However, if it were, Mono could prove the biggest shot in the foot in modern times.
You haven't been here in a while, have you?
Right now, I have friends using only one of MSN or AIM/ICQ. They were all, on occasion, uncontactable due to their respective IM network owners trying to finally shoot up to the IM market top position by closing protocols. Yahoo protocol closing was not so bad just because they have a crappy protocol. None of my friends use Yahoo as the only IM client.
I just hope all this nonsense makes people start switching to open protocols, even if they're just plain old IRC.