I measure it in the amount of time it takes me to configure a new printer. Isn't that how everybody does it?
Let me think... no? I measure it in how usable (do not read that as user friendly) the system is, and while I haven't tried Monad yet (since I don't have Windows), I find it a lot easier to actually get stuff done in Linux than in Windows.
And even so, I don't know when you last tried Linux, but last I tried (as I am typing this), printers are automatically detected upon installation and upon hotplug in Linux. Just like any other piece of hardware that doesn't require proprietary drivers.
Try to remember a time when you didn't think it was logical to edit text files in buried/etc to fix things.
Oh yes, the Windows registry and Microsoft Management Console are obviously better... or was that your point? I'm asking because I couldn't really see it.
MS will have a rendered graphics engine before linux
You mean like Xgl, which, unlike Longhorn, exists?
they will have a DB filesystem (or at least an overlay) before linux.
You mean like Reiser4, which, unlike Longhorn (and especially WinFS), exists?
And they will continue to have far better dev tools than linux has.
You haven't considered that that just might be personal preference? Thanks, but I think I'll stick with Emacs. And yes, you can call me "brainwashed" if it makes you feel better.
like the ones we have now which aim implement their current work
Yeah, isn't that strange? Or could it be that if an open source application needs to find its way into Windows, the open source community ports it to Windows, while if a proprietary application needs to find its way off its initial platform, it needs to be duplicated if the initial developer won't port it?
And you're right about the Start Button. Totally lame idea.
You are aware that Microsoft didn't invent the Start menu, right? RISC OS (or so I think -- it might have been another GUI) had it long before. Same thing goes for the task bar, and most of the "innovative" features of Windows 95.
So why the hell can't OSS figure out something better than to copy such a lame idea? Why don't we have works of staggering genius coming out of OSS where we don't even recognize the desktop it's so new? There's no money to be lost. There's nothing holding back innovation. Why do we get clones of commercial products? Why don't we have crazy experimental GUIs where windows are done away with (they are overrated, anyway, and only arbitratily limit your view of what you're currently doing)?
I could mention at least two, if only I could remember their names (one of them was mentioned on Slashdot a few months back)... argh.:-/ The problem is that, precisely as how people aren't willing to switch to a new OS (say, for example, from Windows to OSX or from Windows to Linux), they aren't willing to switch to a new desktop paradigm either. The desktop is pretty much locked in place, because people don't want innovation. Or so it seems.
Even you yourself praise Apple. Why aren't people switching to OSX if innovation is all that counts?
Why don't we have completely new blank-slate ideas coming out of OSS like shells which pipe XML instead of text?
Oh boy, where should I start? Because it's stupid? Because XML is overrated? Because XML is text?
All that said, I can agree that neither Gnome nor KDE are exactly boiling plates of desktop innovation. The obvious explanation is that many open source programmers don't really care that much about a desktop environment, since they don't use it much themselves, but rather think of it as a necessary evil to get people to get over from the Microsoft camp. At least it seems as though Gnome 3 is going to have some innovation. They have a roadmap somewhere in their Wiki.
Side note: I am amazed at the hypocrisy I see when this issue appears. Many people who post they want the GPL upheld using copyright law, turn around and want to deprive others of their rights under copyright law.
While that may well be called hypocrisy, it should be noted well that there is a rather large difference. When copying music illegally, you are, as the receiver of the information, increasing your own rights, and the rights of all that in turn receive it from you, to that information. When infringing on a GPLd piece of software, you are, as the receiver, increasing your own rights, but you are decreasing on the right of those that, in turn, receive it from you.
Therefore, it's not very strange that these "other people" cheer you on when copying music illegally, while booing when you infringe on a GPLd piece of software. It's not necessarily "hipocrisy" -- they are merely acting in their own interest.
XML is great as a document format (which is what it was invented for), but that is where its usefulness stops. For more generic data representation, XML is not only clumsy and bloated, but also lacking in capabilities. There are tons of already existing technologies that are many times better (my favorite being s-expressions, but even JSON is better than XML).
It may well be true that everyone doesn't hate Microsoft. However, I think that the GP's point was that there are very few people that actually like Microsoft.
Regardless of whether any given person hates Microsoft, or merely dislikes them, or doesn't even know that they exist (and think the Windows is "the computer" and IE "the Internet"), you would be rather hard pressed to find a person outside of Redmond that actually feels the warm fuzzies for Microsoft. And, judging from people like Mini-Microsoft, those people seem to grow fewer even inside Redmond.
Actually, I first read the post as PSP Users More Likely to Cheat, Shoplift. I was really starting to wonder. Actually, I read it 4x, and didn't catch the error until reading a few comments. Darn those Canadian PSP users, the hosers!
The funny thing is that the report would have remained at the exact same level of "validity" if it indeed were changed to say PSP users. People in the ages 18-29 are probably more likely to use PSPs than people of other ages, just as they are most likely to be using P2P software.
You can easily have open source software that's not Free: it would be the case where you have access to the code, but don't have permission to distribute it, make derived works, etc. (RMS's "four freedoms").
Sorry, but that's not correct. Take a look at the open source definition (OSD). It requires a compliant license to permit "Free Redistribution" (criterion #1), and to permit "Derived Works" (criterion #3).
Open source software and free software means almost the exact same thing in practice. They only differ in philosophy: The open source movement desires these freedoms in order to create superior software, while the free software movement doesn't care about software quality, they want freedom and a community.
Just to demonstrate, let me show it for each one of RMS's four freedoms:
The freedom to run the program, for any purpose (freedom 0).
Covered by OSD criteria #5 and #6
The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
Covered by OSD criteria #2 and #3.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
Covered by OSD critera #1, #5, #6, #7, #8, #9 and #10.
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
Covered by OSD criterion #3.
Personally, I believe much more in the free software philosophy than the open source one, but it's not as if software under an OSD-compliant license isn't Free.
I still haven't even bothered to move to 2.6.x as I have no reason to.
Well, every man to himself, but are you nuts?
The single largest attraction of the 2.6 series is the new driver model with its/sys filesystem. It allows not only taking driver coldplugging and, especially, hotplugging to a new level, but I also use it on servers because of the hardware introspection capabilities that it offers.
There are also some really interesting things coming in 2.6, such as SECCOMP, NFSv4 and kernel key retention. SECCOMP allows per-process syscall jails for secure execution of third-party untrusted binaries, and kernel level key retention will allow you to, for example, keep Kerberos credentials in the kernel (once it has been implemented in the Kerberos libraries, that is), which allows for much more stateful key inspection and manipulation (to do stuff like automatic renewal and creds-to-process/user mappings). Of course, it can do the same things with other cryptographic keys as well, like SSH keys, X.509 certs, saved passwords, and what not.
Then, of course, there are tidbits of interesting things all over the place, like kernel thread preemption and what not.
Of course, if you, for any reason, aren't interested in any of this, that's your choice, but I was running the test versions of the 2.6 kernel before 2.6.1 was released because I was looking forward so immensely to many of these features.
but would still insist that although modularity can lead to runtime flexibility, and runtime flexibility is often a sign of underlying modularity, it is important to not conflate the two concepts, since (strictly speaking) either one is possible without the other.
I, on my hand, would insist that that is only half true. It is true, as you say, that absence of runtime flexibility is not necessarily an indication of the absence of modularity (it could be explained as easily as the lack of a dynamic loader, depending on the context and kind of system). However, I would argue that true runtime flexibility is not possible without a modular design.
For example, I read about that new network architecture in Windows Vista, and how they have implemented per-session routing tables and user-installable tunnelling devices in order to allow VPN connections on a per-user basis without requiring administrator privileges. It is also typical of the kind of engineering that goes on over at Redmond -- they solve the problem at hand, but only superficially and without remedying the real, underlying problem. They added some runtime flexibility, but it only goes as far as modifying the state of the code that exists, instead of adding the ability of loading new code modules dynamically. Doing that wouldn't only have solved their problem, but it would also potentially solve millions of upcoming problems, and not only for them, but for other users as well (for example, if I wanted to write an IP-over-SSH driver and plug it in on a time-sharing system). In other words, it is my not-so-very humble opinion that true runtime flexibility requires dynamic code loading, and that, in turn, requires modularity in the existing code base. Runtime flexibility which only means changing the state of currently loaded code hardly even counts as runtime flexibility.
It is well worth noting that the GNU Hurd is capable of doing all of the things that I mentioned. It can load file system drivers, memory managers, network stacks and much more during runtime. Ordinary users can do it for themselves without requiring administrative privileges or affecting other users. Now when they're switching from the Mach microkernel to the L4 microkernel, they have even added the missing piece of being able to load device drivers dynamically, in user space, and without special privileges (Mach requires device drivers to run in kernel space, much like monolithical kernels). This is why I am an avid supporter of microkernels.
Could you cite a specific example of where there are two specific regions of code within those systems that are not linked through a well defined interface, and make a convincing argument that they should be?
Well, I don't exactly know OSX inside out, so these may already be so, but how about filesystem drivers, memory managers, I/O schedulers, device drivers (in particular drivers for devices like USB or Firewire) and network stacks?
I think the arguments for all of these should be rather obvious, but just in case they aren't:
Filesystem drivers: It doesn't exactly hurt to be able to mount an FTP, WebDAV, SMB or NFS server on any directory as any user, nor does it hurt to be able to write extra filesystem drivers (for some archaic network protocol or filesystem dump or anything) and use them, as a user, without permission to alter the kernel.
Memory managers: It's not exactly an impossible thought that I'd like to mmap a shared memory segment over TCP or write my own swapping algorithm. It would also be necessary to write a memory manager in order to write a complete filesystem driver ("complete" in the sense of being able to mmap files).
I/O schedulers: Well, there may not be any obvious advantages to this.:) It doesn't hurt to be able to either, though.
Device drivers: There would be tremendous advantages for a user to be able to plug in his or her own USB device and use a non-installed driver for it, without modifying the kernel or risking to bring down the system.
Network stacks: It would be a good thing for a user to be able to plug his or her own tunneling driver or transport layer protocol (for example, for VPNs) without having to modify the kernel or affect other users.
Did you know, by the way, that a system can be modular on the source code level and then (based upon a compilation flag) it can either be built such that (A) both regions are in kernel space, or (B) one region is in kernel space and the other is in user space. The former would use a very efficient interface, whereas the latter would use one that was more expensive (for having to cross that boundary).
In both cases, the regions exist in separate modules...it's just a compile-time optimization. Modularity is mostly a "maintainability" concept. The user should never care whether two regions are communicating via a Mach message or a pointer on the function-call stack to a struct in the heap. Using the latter does not make the source less modular.
That's not entirely true. First of all, modularity is not only an aspect of maintainability. It is also a matter of being able to reconfigure a system during runtime, without the need for restarting components or recompiling any source code.
Also, the latter does often make toe source less modular. Being able to share a memory space (on a somewhat normal computer) enables much greater flexibility which cannot be emulated over a communication port. If you pass a struct over a function call, that struct is able to contain pointers to other parts of the same address space, which cannot be done over a communication port. In order to even being able to think of doing that over a port, you need to think long and hard over several aspects of data serialization (since most communication ports simply send arrays of ordered bytes back and forth). Since C doesn't offer any introspection into structs and other datatypes, this kind of serialization always needs to be done manually in C-based programs. In order to be able to overcome this limitation, the entire system would optimally have to be written in a more flexible language, like LISP or Java, but only being able to run managed code on a system would be ugly. A suboptimal solution would be a C-based language with introspection (and possibly type-tagging), but that, too, is quite ugly.
Of course, the lack of non-ugly solutions to this problem lies in th
Now I'll have to waste the entire night recompiling 1.0.7 on my Gentoo systems.:)
On a more serious note, I'd be very glad if they took their time to fix the memory leaks in Firefox. Just keeping it running for a week increases its RAM usage by at least 100 MB.
Online isn't at all related to the Internet specifically, even these days. It means that a certain connection is established and working. That connection could be an Internet connection, but it could also be, as two other posters have pointed out, an established carrier over an POTS modem connection or an established printer connection. It could also refer to any other RS-232 connection, a UUCP connection, a USB connection, and even in the context of the Internet it can refer to a specific PPP or TCP link. Or virtually anything else that involves a connection.
As the word implies, it just means that something is "on the line".
I don't see why a solution based on OpenLDAP, MIT/Heimdal Kerberos and (if you really need it) Samba would be "cobbled together". Would you mind expanding on that?
As I see it, each of these programs perfectly implements the standard it was designed for, and the directory service you get by combining them is just that: a directory service. It seems to be fulfilling the intended purpose perfectly.
Is the "cobbled-togetherness" a result of them not being shrink-wrapped together into a product with a single name, as all the "professional" directory services are? I'm not intending to troll, but I just can't see any other way they are "cobbled together".
I'm not really an expert at the Windows "architecture", but is MSIE really so closely integrated with the OS as everyone keeps saying?
As far as I know, the browser core is some kind of OLE/ActiveX stuff packed in a library called MSHTML.DLL, which MSIE-the-executable just packs into a normal application window. The integration, as far as I've been led to believe, is just the fact that Windows' file explorer also uses the same component to render some UI elements and so on. It's not exactly like it's a kernel module or anything.
I'm not trying to troll or anything here, the above is just what I think I know. If someone knows that that isn't the case, and there really is some closer "integration" besides that which I know of, please tell me so.
Furthermore, if I'm right, then Microsoft has just done basically the same thing that Apple has, if memory serves me. A news item for Tiger was that the modified KHTML components had been brought out from Safari and made into a library (in Objective C?) called WebCore, which Safari then uses as a widget. If you ask me, this rather obvious piece of architecturing is far better than what e.g. Gecko-based browsers do (they have to link statically against the Gecko code, right?).
I find it interesting how people are complaining about desktop Linux being inconsistent with different programs using different toolkits.
Windows is just as bad, if not worse, since every other software vendor decides to write their own toolkit, just for the sake of it. Hardly two different programs look the same. I'd say desktop Linux is absolutely consistent when compared to any given Windows desktop.
The most interesting thing about this is precisely Office. I find it amazing that even Microsoft themselves design different toolkits for different programs. Can't they even keep consistent within the same company?
Of course, Apple isn't much better. They even designed two different themes directly into the operating system. Why couldn't they just keep with either Aqua or Brushed Metal (or, alternatively, keep it selectable, but consistent for all applications, as can be done with GTK)?
That's not just correct, it is correct by definition. "It's" isn't a word in itself or anything, it's just short for "it is". The apostrophe is used to signify the removal of the space and the second "i". Nothing more, nothing less.
There are (I expect) a large number of people reaing this who believe that SCO is not a company you should do business with.
I, for one, believe that that's still better than seeing SCO ride the GPL and include a version of MySQL that doesn't cost them any money.
Since they could just have included the GPL'd version of MySQL, it seems better to me that a) SCO loses money on a proprietary license and b) MySQL AB gets money from something that doesn't hurt anyway. It doesn't hurt since a) SCO could have had MySQL anyway and b) people using SCO software (if there still are any) will be further disadvantaged by getting a non-free version of MySQL.
Your statement doesn't make any sense. Win32 is an API of which NT is one implementation.
That's not true, unfortunately. I don't like NT either, but Win32 is a layer on top of the NT kernel. The NT kernel does not in itself implement Win32. On an NT kernel with SFU installed, the POSIX subsystem and the Win32 subsystem are peers -- POSIX isn't built on top of Win32.
I'd like to see a piece-by-piece breakdown of his "inaccuracies", rather than a blind assertion that he is wrong. Until then, I see no reason to disbelieve him.
Then, so be it. GGP:
Part of the problem is that Unix's directory and authentication systems are 30+ years old. PAM and NSS are attempts to fix some of the problems and cruft, but they really aren't all that nice, either.
So far he speaks the truth.
It's amazing that things like Samba's winbind [irtnog.org] work at all, and even then, there are serious flaws.
I haven't used winbind (since I have no Windows servers), so I can't speak about any "flaws", but I find it in no way amazing that it works (in other words, I see no reason why it should be amazing).
For example, searching for a particular user account is a straight table scan, order O(n), when using the getpwent API.
This is patently false. Any of the getpwent and related functions just patch right through to the name service switch (NSS) module which is selected in/etc/nsswitch.conf (at least on glibc-based systems, such as GNU/Linux), and that module is free to use whatever algorithm it chooses. I can speak of this authoratively, because I have first-hand experience in writing NSS modules. For more info on this, see section 28 ("System Databases and Name Service Switch") of the GNU libc texinfo manual.
If your Unix box is a member of an Active Directory domain with lots of accounts (where "lots of" is "more than 1,000"), that user lookup takes forever.
Therefore, this is also false. The complexity order of the lookup depends completely on the NSS module which handles the lookup. In the case of Active Directory, this should be handled by the LDAP NSS module (although less experience admins have been seen to try to integrate with AD using the Winbind module, which is most likely a lot slower), which means that the lookups will be a perfectly normal LDAP query, which can be implemented at any order of complexity at the LDAP server.
As another poster mentioned, if the lookups are slow nonetheless (because of network latency, busy LDAP servers, or anything else), the Name Service Caching Daemon (nscd) can be used to cache the directory information locally. Then, every lookup will be fast.
Guess what: every time you do an "ls -l", that lookup happens for each line.
If he ever experienced slowness when running ls -l, it was not because of any system architectural fault. I do not know his circumstances, but I'd imagine using the Winbind module is slow. Also, he may not have set up nscd, and his Windows server may have been slow.
Now, the newest version of winbind tries to do some caching and whatnot (as do the tools that use account information), but since they are restricted to the 70s-era UNIX get*ent APIs that assume your password file is a flat, unindexed, small, and locally available file, the Samba team cannot make the actual searches faster than O(n).
Even if it were true that the get*ent APIs assume that the password file is flat, unindexed, small and local (which it is not, as I have proved above), it would still not be a valid point. My university has a large number of Solaris computers, and they actually do use the/etc/passwd file (for some strange reason which I cannot imagine). Their passwd file contains over 18000 lines, and while operations such as ls -l aren't exactly ligtning fast, it's certainly fast considering how they actually are using a flat, unindexed, small and local file:
Slashdot Mirror
And even so, I don't know when you last tried Linux, but last I tried (as I am typing this), printers are automatically detected upon installation and upon hotplug in Linux. Just like any other piece of hardware that doesn't require proprietary drivers.
Oh yes, the Windows registry and Microsoft Management Console are obviously better... or was that your point? I'm asking because I couldn't really see it. You mean like Xgl, which, unlike Longhorn, exists? You mean like Reiser4, which, unlike Longhorn (and especially WinFS), exists? You haven't considered that that just might be personal preference? Thanks, but I think I'll stick with Emacs. And yes, you can call me "brainwashed" if it makes you feel better. Yeah, isn't that strange? Or could it be that if an open source application needs to find its way into Windows, the open source community ports it to Windows, while if a proprietary application needs to find its way off its initial platform, it needs to be duplicated if the initial developer won't port it? You are aware that Microsoft didn't invent the Start menu, right? RISC OS (or so I think -- it might have been another GUI) had it long before. Same thing goes for the task bar, and most of the "innovative" features of Windows 95. I could mention at least two, if only I could remember their names (one of them was mentioned on Slashdot a few months back)... argh.Even you yourself praise Apple. Why aren't people switching to OSX if innovation is all that counts?
Oh boy, where should I start? Because it's stupid? Because XML is overrated? Because XML is text?All that said, I can agree that neither Gnome nor KDE are exactly boiling plates of desktop innovation. The obvious explanation is that many open source programmers don't really care that much about a desktop environment, since they don't use it much themselves, but rather think of it as a necessary evil to get people to get over from the Microsoft camp. At least it seems as though Gnome 3 is going to have some innovation. They have a roadmap somewhere in their Wiki.
Therefore, it's not very strange that these "other people" cheer you on when copying music illegally, while booing when you infringe on a GPLd piece of software. It's not necessarily "hipocrisy" -- they are merely acting in their own interest.
You wouldn't by any chance happen to have meant "its effect", would you?
XML is great as a document format (which is what it was invented for), but that is where its usefulness stops. For more generic data representation, XML is not only clumsy and bloated, but also lacking in capabilities. There are tons of already existing technologies that are many times better (my favorite being s-expressions, but even JSON is better than XML).
For more info, including some examples.
Regardless of whether any given person hates Microsoft, or merely dislikes them, or doesn't even know that they exist (and think the Windows is "the computer" and IE "the Internet"), you would be rather hard pressed to find a person outside of Redmond that actually feels the warm fuzzies for Microsoft. And, judging from people like Mini-Microsoft, those people seem to grow fewer even inside Redmond.
Open source software and free software means almost the exact same thing in practice. They only differ in philosophy: The open source movement desires these freedoms in order to create superior software, while the free software movement doesn't care about software quality, they want freedom and a community.
Just to demonstrate, let me show it for each one of RMS's four freedoms:
The freedom to run the program, for any purpose (freedom 0). Covered by OSD criteria #5 and #6 The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. Covered by OSD criteria #2 and #3. The freedom to redistribute copies so you can help your neighbor (freedom 2). Covered by OSD critera #1, #5, #6, #7, #8, #9 and #10. The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. Covered by OSD criterion #3. Personally, I believe much more in the free software philosophy than the open source one, but it's not as if software under an OSD-compliant license isn't Free.The single largest attraction of the 2.6 series is the new driver model with its /sys filesystem. It allows not only taking driver coldplugging and, especially, hotplugging to a new level, but I also use it on servers because of the hardware introspection capabilities that it offers.
There are also some really interesting things coming in 2.6, such as SECCOMP, NFSv4 and kernel key retention. SECCOMP allows per-process syscall jails for secure execution of third-party untrusted binaries, and kernel level key retention will allow you to, for example, keep Kerberos credentials in the kernel (once it has been implemented in the Kerberos libraries, that is), which allows for much more stateful key inspection and manipulation (to do stuff like automatic renewal and creds-to-process/user mappings). Of course, it can do the same things with other cryptographic keys as well, like SSH keys, X.509 certs, saved passwords, and what not.
Then, of course, there are tidbits of interesting things all over the place, like kernel thread preemption and what not.
Of course, if you, for any reason, aren't interested in any of this, that's your choice, but I was running the test versions of the 2.6 kernel before 2.6.1 was released because I was looking forward so immensely to many of these features.
Not that I doubt you, but could I ask you to be a bit more specific? As I've understood it, the NT kernel is pretty universal in Windows systems.
For example, I read about that new network architecture in Windows Vista, and how they have implemented per-session routing tables and user-installable tunnelling devices in order to allow VPN connections on a per-user basis without requiring administrator privileges. It is also typical of the kind of engineering that goes on over at Redmond -- they solve the problem at hand, but only superficially and without remedying the real, underlying problem. They added some runtime flexibility, but it only goes as far as modifying the state of the code that exists, instead of adding the ability of loading new code modules dynamically. Doing that wouldn't only have solved their problem, but it would also potentially solve millions of upcoming problems, and not only for them, but for other users as well (for example, if I wanted to write an IP-over-SSH driver and plug it in on a time-sharing system). In other words, it is my not-so-very humble opinion that true runtime flexibility requires dynamic code loading, and that, in turn, requires modularity in the existing code base. Runtime flexibility which only means changing the state of currently loaded code hardly even counts as runtime flexibility.
It is well worth noting that the GNU Hurd is capable of doing all of the things that I mentioned. It can load file system drivers, memory managers, network stacks and much more during runtime. Ordinary users can do it for themselves without requiring administrative privileges or affecting other users. Now when they're switching from the Mach microkernel to the L4 microkernel, they have even added the missing piece of being able to load device drivers dynamically, in user space, and without special privileges (Mach requires device drivers to run in kernel space, much like monolithical kernels). This is why I am an avid supporter of microkernels.
In case you didn't know, all Microsoft's server systems are built on the same kernel and libraries as XP was.
Well, I don't exactly know OSX inside out, so these may already be so, but how about filesystem drivers, memory managers, I/O schedulers, device drivers (in particular drivers for devices like USB or Firewire) and network stacks?
I think the arguments for all of these should be rather obvious, but just in case they aren't:
That's not entirely true. First of all, modularity is not only an aspect of maintainability. It is also a matter of being able to reconfigure a system during runtime, without the need for restarting components or recompiling any source code.
Also, the latter does often make toe source less modular. Being able to share a memory space (on a somewhat normal computer) enables much greater flexibility which cannot be emulated over a communication port. If you pass a struct over a function call, that struct is able to contain pointers to other parts of the same address space, which cannot be done over a communication port. In order to even being able to think of doing that over a port, you need to think long and hard over several aspects of data serialization (since most communication ports simply send arrays of ordered bytes back and forth). Since C doesn't offer any introspection into structs and other datatypes, this kind of serialization always needs to be done manually in C-based programs. In order to be able to overcome this limitation, the entire system would optimally have to be written in a more flexible language, like LISP or Java, but only being able to run managed code on a system would be ugly. A suboptimal solution would be a C-based language with introspection (and possibly type-tagging), but that, too, is quite ugly.
Of course, the lack of non-ugly solutions to this problem lies in th
A search for "web browser" brings up Mozilla first, though.
On a more serious note, I'd be very glad if they took their time to fix the memory leaks in Firefox. Just keeping it running for a week increases its RAM usage by at least 100 MB.
Online isn't at all related to the Internet specifically, even these days. It means that a certain connection is established and working. That connection could be an Internet connection, but it could also be, as two other posters have pointed out, an established carrier over an POTS modem connection or an established printer connection. It could also refer to any other RS-232 connection, a UUCP connection, a USB connection, and even in the context of the Internet it can refer to a specific PPP or TCP link. Or virtually anything else that involves a connection.
As the word implies, it just means that something is "on the line".
As I see it, each of these programs perfectly implements the standard it was designed for, and the directory service you get by combining them is just that: a directory service. It seems to be fulfilling the intended purpose perfectly.
Is the "cobbled-togetherness" a result of them not being shrink-wrapped together into a product with a single name, as all the "professional" directory services are? I'm not intending to troll, but I just can't see any other way they are "cobbled together".
As far as I know, the browser core is some kind of OLE/ActiveX stuff packed in a library called MSHTML.DLL, which MSIE-the-executable just packs into a normal application window. The integration, as far as I've been led to believe, is just the fact that Windows' file explorer also uses the same component to render some UI elements and so on. It's not exactly like it's a kernel module or anything.
I'm not trying to troll or anything here, the above is just what I think I know. If someone knows that that isn't the case, and there really is some closer "integration" besides that which I know of, please tell me so.
Furthermore, if I'm right, then Microsoft has just done basically the same thing that Apple has, if memory serves me. A news item for Tiger was that the modified KHTML components had been brought out from Safari and made into a library (in Objective C?) called WebCore, which Safari then uses as a widget. If you ask me, this rather obvious piece of architecturing is far better than what e.g. Gecko-based browsers do (they have to link statically against the Gecko code, right?).
Windows is just as bad, if not worse, since every other software vendor decides to write their own toolkit, just for the sake of it. Hardly two different programs look the same. I'd say desktop Linux is absolutely consistent when compared to any given Windows desktop.
The most interesting thing about this is precisely Office. I find it amazing that even Microsoft themselves design different toolkits for different programs. Can't they even keep consistent within the same company?
Of course, Apple isn't much better. They even designed two different themes directly into the operating system. Why couldn't they just keep with either Aqua or Brushed Metal (or, alternatively, keep it selectable, but consistent for all applications, as can be done with GTK)?
That's not just correct, it is correct by definition. "It's" isn't a word in itself or anything, it's just short for "it is". The apostrophe is used to signify the removal of the space and the second "i". Nothing more, nothing less.
Since they could just have included the GPL'd version of MySQL, it seems better to me that a) SCO loses money on a proprietary license and b) MySQL AB gets money from something that doesn't hurt anyway. It doesn't hurt since a) SCO could have had MySQL anyway and b) people using SCO software (if there still are any) will be further disadvantaged by getting a non-free version of MySQL.
That might just be me, though.
Then, so be it. GGP:
So far he speaks the truth.
I haven't used winbind (since I have no Windows servers), so I can't speak about any "flaws", but I find it in no way amazing that it works (in other words, I see no reason why it should be amazing).
This is patently false. Any of the getpwent and related functions just patch right through to the name service switch (NSS) module which is selected in /etc/nsswitch.conf (at least on glibc-based systems, such as GNU/Linux), and that module is free to use whatever algorithm it chooses. I can speak of this authoratively, because I have first-hand experience in writing NSS modules. For more info on this, see section 28 ("System Databases and Name Service Switch") of the GNU libc texinfo manual.
Therefore, this is also false. The complexity order of the lookup depends completely on the NSS module which handles the lookup. In the case of Active Directory, this should be handled by the LDAP NSS module (although less experience admins have been seen to try to integrate with AD using the Winbind module, which is most likely a lot slower), which means that the lookups will be a perfectly normal LDAP query, which can be implemented at any order of complexity at the LDAP server.
As another poster mentioned, if the lookups are slow nonetheless (because of network latency, busy LDAP servers, or anything else), the Name Service Caching Daemon (nscd) can be used to cache the directory information locally. Then, every lookup will be fast.
If he ever experienced slowness when running ls -l, it was not because of any system architectural fault. I do not know his circumstances, but I'd imagine using the Winbind module is slow. Also, he may not have set up nscd, and his Windows server may have been slow.
Even if it were true that the get*ent APIs assume that the password file is flat, unindexed, small and local (which it is not, as I have proved above), it would still not be a valid point. My university has a large number of Solaris computers, and they actually do use the /etc/passwd file (for some strange reason which I cannot imagine). Their passwd file contains over 18000 lines, and while operations such as ls -l aren't exactly ligtning fast, it's certainly fast considering how they actually are using a flat, unindexed, small and local file: