Now we're seeing FOSS' killer application -- mix and match modularity. Obviously RH needs to respond to Novel's efforts or potentially lose market/mind share. Because the different approaches are built on a truely open platform, you don't have to ditch your current environment from the hardware on up in order to get the solution that is right for you. Competition to fill niches exposed by open API's works. Anyone can play. (And of course there's also the fact that someone can come along and distill the best of serveral solutions into a derivative FOSS work.) There's something quite satisfying about that, particularly in relation to much of the rest of the modern world.
Hybrids are great for city start-and-stop driving. For long trips, nothing beats a VW TDI. I get around 45mpg in my Jetta TDI wagon cruising 85mph on long trips. Great thing about a turbo diesel is the torque. You never have to shift out of 5th gear no matter how steep the grade. (My speed dropped slightly below 85 going up the I-10 incline headed East out of LA enroute to Austin.) And you can run it on biodiesel. Just filled mine with 100% soy biodiesel. Great thing is no more diesel fumes -- smells like a Pad Thai stand!
Seems to me that most users that have actually tried gentoo really like it. I've run small networks of workstations on redhat (2yrs), debian (2yrs), fedora (2yrs), have run a small cluster on the rocks distribution. I made all of these work. They all have their strong points. I've recently switched to gentoo (several months) and find it to be by far the best for experienced admins / technical users. It does seem to attract a lot of kids that want to impress their friends by using an advanced distro. However, the core developers have done thus far a superb job desiging gentoo and it is very stable and capable in the hands of an expert.
BTW, resorting to name calling really only betrays ignorance.
I didn't say it was a conspiracy. And yes, you are probably right -- its probably unfair to blame Red Hat for ESRI thinking linux = red hat (search for 'linux' on their web site and you'll see they're beginning to release for linux, um Red Hat). I still fault Red Hat for not taking more of an early leadership role in LSB and binary compatibility in general. Actually, I think RH has the most to lose. LSB wont hurt them; they have great brand recognition and that's not going away. Binary compatibility will only make Linux more appealing in general.
Clearly its in Red Hat's interest to get software companies to release only for Red Hat. They're perfectly in their right to do so. Its also my right to say that down that path lies balkanization, fragmentation and general unpleasantness for Linux users.
I use Debian too, and your point is?...
Hop on over to (random example) ESRI's web site (www.esri.com) and then tell me that I have a choice of linux distributions if I want to run ESRI software. Is Red Hat encouraging them to release LSB compliant packages. I highly doubt it. Unless you can fulfill all your computing needs with source-available software, binary compatibility does matter. Linux _is_ fragmented at the binary-compatible level and I don't see Red Hat actively fighting that.
As far as I can tell, Raster wrote a tricked out monstrosity that had no clear direction and was rightly abandoned by Gnome and pretty much everyone else (which is not to say that parts of it weren't brilliant bits of coding). Now that he's failed in that arena, he's declaring it dead. Gnome has had its growing pains, but its a pretty good desktop. I've used it everyday since v1 (and cursed it more than a few times, but probably much less than I would have windows).
these sorts of structures kill migratory birds by the thousands (millions?) annually when they hit the guy wires. Not sure if the proposed location is in the path of any migration routes, but in some locations, it would be a disaster.
Its a shame that Progeny's NOW project is on hold. The project had great promise. (Progeny as a distribution is still quite nice; I have it running on several machines.)
GNU/Linux desperately needs a single-system-image infrastructure. It seems that too few Linux devlopers have experience with large networks of workstations. I have yet to see any distribution take advantage of the fact that other machines on the network are already up and running. I'd like to see an installation prompt to the effect: "I've detected a cluster of machines on the local network. Do you want me to merge as a member of this cluster?" Instead, you have to reenter all the configuration information again and spend days setting up network file systems and network authentication. Why isn't LDAP the default, out-of-the-box authentication method? NFS at least is a no-brainer, but leaves lots to be desired for clustering. NIS packages are generally primitive and require a fair amount of hand configuration (with poor documentation in my experience). LDAP is far worse. (It should be as simple as DHCP---"Ah, there's an LDAP authentication server on this network. Should I use it?")
There is hope. See compaq's SSI project. It may well be that the open-sourcing of proprietary cluster infrastructure is what drove Progeny to put their NOW project on hold.
I just canceled my order for a Dell 620 which uses PIII Xeon and RDRAM (fortunately still sitting on the secretaries desk). I'm curious though. I've been searching and cannot find any benchmark numbers comparing a PIII Xeon to a regular PIII (e.g., otherwise identical Dell 620 v. 420). I find it rather amazing. Tom's hardware et al. seem only interested in 3D game performance. Where's the data? Has no one run SPEC CPU2000 on a Xeon? (Perhaps that says enough!)
The thing is the more you abstract, the more performance you lose.
I don't agree; abstraction is the key to performance. Looked at any modern numerical codes lately? Good design is always the key to performance and careful abstraction facilitates good design. The idea that brute force, low level code is necessary for performance is fortunately dying (RIP;-)
Imagine for a moment a database system that presented two interfaces. The first is your typical database interface: a database connection, SQL queries, transaction and concurrency control. The second interface allows you to simply log into the database and edit any table by hand---no transactions, triggers, referential integrity, input validation and so on. The second interface, used alone, could actually work, but it would require the users to adopt to a sound policy, i.e., manually implement all of the features of the first interface. Obviously, the first interface is preferable and used alone will help result in a stable system. If the two interfaces are used together, you have a disaster, because users of the first interface would assume that the database system is enforcing policy and would trample on users of the second interface, with database corruption the only outcome.
The answer is to get rid of the second, direct interface and force everyone to use the first, policy-enforcing interface. That's why I think we need to get rid of (gulp!) the current UNIX file system model. Current file systems expose a hierarchical name space, but it is too closely tied to the physical storage (partitions a prime example---yes I know about logical volume managers). Furthermore, the hierarchical name space is too difficult to index and search effectively (witness [s]locate which does not update its indices on each file system transaction, but has to be run at regular intervals). So Miguel et al's idea of a component based configuration system is great. Except that it is too high level and leaves the standard file system interface intact. I suggest we need a single component interface to access system resources. (I'm mostly thinking of files, but the idea can be extended.) A first step in that direction might be to create a CORBA-based file system (basically persistent object storage). NFS wrapped the file system interface with RPC. CORBA is (in part) object oriented RPC. Seems a natural way to present resources as objects/components and provide a policy rich interface to these resources.
Red Hat et al. are not going to give up RPM. Debian is not going to give up deb packaging. I don't see any chance that we will have a standard package format anytime soon. I think we need a meta-package format that encodes all the information needed to create an RPM, deb or other package. The meta-package format would need to store distribution specific information, but at least it would all be stored in one place. Once you have a meta-package, you could then run "metapac --distribution redhat --version 6.2 my-meta-package" and it would spit out an RPM for Red Hat 6.2; "metapac --distribution debian --version x.x my-meta-package" would generate a deb. You could have a utility that extracts information from existing rpms and debs and places it in the meta-package, e.g., "metapac --update-from my-package.rpm my-meta-package" and so on. Then create a centralized repository for meta-packages.
Which is more ethical? Making software tools developed in the course of one's taxpayer supported research program available under a liberal open source licence, or quiting your job at the university and taking your taxpayer supported software/ideas and selling them as a closed source proprietary product? (Hint: If you had any federal funding, e.g., NSF, you are required to release your source code.) Cheers, Tim
Slashdot Mirror
Now we're seeing FOSS' killer application -- mix and match modularity. Obviously RH needs to respond to Novel's efforts or potentially lose market/mind share. Because the different approaches are built on a truely open platform, you don't have to ditch your current environment from the hardware on up in order to get the solution that is right for you. Competition to fill niches exposed by open API's works. Anyone can play. (And of course there's also the fact that someone can come along and distill the best of serveral solutions into a derivative FOSS work.) There's something quite satisfying about that, particularly in relation to much of the rest of the modern world.
Isn't that precious... (apologies to SNL)
But is still fun to google yourself. (So shameless!)
Hybrids are great for city start-and-stop driving. For long trips, nothing beats a VW TDI. I get around 45mpg in my Jetta TDI wagon cruising 85mph on long trips. Great thing about a turbo diesel is the torque. You never have to shift out of 5th gear no matter how steep the grade. (My speed dropped slightly below 85 going up the I-10 incline headed East out of LA enroute to Austin.) And you can run it on biodiesel. Just filled mine with 100% soy biodiesel. Great thing is no more diesel fumes -- smells like a Pad Thai stand!
Seems to me that most users that have actually tried gentoo really like it. I've run small networks of workstations on redhat (2yrs), debian (2yrs), fedora (2yrs), have run a small cluster on the rocks distribution. I made all of these work. They all have their strong points. I've recently switched to gentoo (several months) and find it to be by far the best for experienced admins / technical users. It does seem to attract a lot of kids that want to impress their friends by using an advanced distro. However, the core developers have done thus far a superb job desiging gentoo and it is very stable and capable in the hands of an expert.
BTW, resorting to name calling really only betrays ignorance.
Ciao.
I didn't say it was a conspiracy. And yes, you are probably right -- its probably unfair to blame Red Hat for ESRI thinking linux = red hat (search for 'linux' on their web site and you'll see they're beginning to release for linux, um Red Hat). I still fault Red Hat for not taking more of an early leadership role in LSB and binary compatibility in general. Actually, I think RH has the most to lose. LSB wont hurt them; they have great brand recognition and that's not going away. Binary compatibility will only make Linux more appealing in general.
Clearly its in Red Hat's interest to get software companies to release only for Red Hat. They're perfectly in their right to do so. Its also my right to say that down that path lies balkanization, fragmentation and general unpleasantness for Linux users. I use Debian too, and your point is?...
Hop on over to (random example) ESRI's web site (www.esri.com) and then tell me that I have a choice of linux distributions if I want to run ESRI software. Is Red Hat encouraging them to release LSB compliant packages. I highly doubt it. Unless you can fulfill all your computing needs with source-available software, binary compatibility does matter. Linux _is_ fragmented at the binary-compatible level and I don't see Red Hat actively fighting that.
As far as I can tell, Raster wrote a tricked out monstrosity that had no clear direction and was rightly abandoned by Gnome and pretty much everyone else (which is not to say that parts of it weren't brilliant bits of coding). Now that he's failed in that arena, he's declaring it dead. Gnome has had its growing pains, but its a pretty good desktop. I've used it everyday since v1 (and cursed it more than a few times, but probably much less than I would have windows).
these sorts of structures kill migratory birds by the thousands (millions?) annually when they hit the guy wires. Not sure if the proposed location is in the path of any migration routes, but in some locations, it would be a disaster.
Its a shame that Progeny's NOW project is on hold. The project had great promise. (Progeny as a distribution is still quite nice; I have it running on several machines.)
GNU/Linux desperately needs a single-system-image infrastructure. It seems that too few Linux devlopers have experience with large networks of workstations. I have yet to see any distribution take advantage of the fact that other machines on the network are already up and running. I'd like to see an installation prompt to the effect: "I've detected a cluster of machines on the local network. Do you want me to merge as a member of this cluster?" Instead, you have to reenter all the configuration information again and spend days setting up network file systems and network authentication. Why isn't LDAP the default, out-of-the-box authentication method? NFS at least is a no-brainer, but leaves lots to be desired for clustering. NIS packages are generally primitive and require a fair amount of hand configuration (with poor documentation in my experience). LDAP is far worse. (It should be as simple as DHCP---"Ah, there's an LDAP authentication server on this network. Should I use it?")
There is hope. See compaq's SSI project. It may well be that the open-sourcing of proprietary cluster infrastructure is what drove Progeny to put their NOW project on hold.
I just canceled my order for a Dell 620 which uses PIII Xeon and RDRAM (fortunately still sitting on the secretaries desk). I'm curious though. I've been searching and cannot find any benchmark numbers comparing a PIII Xeon to a regular PIII (e.g., otherwise identical Dell 620 v. 420). I find it rather amazing. Tom's hardware et al. seem only interested in 3D game performance. Where's the data? Has no one run SPEC CPU2000 on a Xeon? (Perhaps that says enough!)
I don't agree; abstraction is the key to performance. Looked at any modern numerical codes lately? Good design is always the key to performance and careful abstraction facilitates good design. The idea that brute force, low level code is necessary for performance is fortunately dying (RIP ;-)
Imagine for a moment a database system that presented two interfaces. The first is your typical database interface: a database connection, SQL queries, transaction and concurrency control. The second interface allows you to simply log into the database and edit any table by hand---no transactions, triggers, referential integrity, input validation and so on. The second interface, used alone, could actually work, but it would require the users to adopt to a sound policy, i.e., manually implement all of the features of the first interface. Obviously, the first interface is preferable and used alone will help result in a stable system. If the two interfaces are used together, you have a disaster, because users of the first interface would assume that the database system is enforcing policy and would trample on users of the second interface, with database corruption the only outcome.
The answer is to get rid of the second, direct interface and force everyone to use the first, policy-enforcing interface. That's why I think we need to get rid of (gulp!) the current UNIX file system model. Current file systems expose a hierarchical name space, but it is too closely tied to the physical storage (partitions a prime example---yes I know about logical volume managers). Furthermore, the hierarchical name space is too difficult to index and search effectively (witness [s]locate which does not update its indices on each file system transaction, but has to be run at regular intervals). So Miguel et al's idea of a component based configuration system is great. Except that it is too high level and leaves the standard file system interface intact. I suggest we need a single component interface to access system resources. (I'm mostly thinking of files, but the idea can be extended.) A first step in that direction might be to create a CORBA-based file system (basically persistent object storage). NFS wrapped the file system interface with RPC. CORBA is (in part) object oriented RPC. Seems a natural way to present resources as objects/components and provide a policy rich interface to these resources.
Red Hat et al. are not going to give up RPM. Debian is not going to give up deb packaging. I don't see any chance that we will have a standard package format anytime soon. I think we need a meta-package format that encodes all the information needed to create an RPM, deb or other package. The meta-package format would need to store distribution specific information, but at least it would all be stored in one place. Once you have a meta-package, you could then run "metapac --distribution redhat --version 6.2 my-meta-package" and it would spit out an RPM for Red Hat 6.2; "metapac --distribution debian --version x.x my-meta-package" would generate a deb. You could have a utility that extracts information from existing rpms and debs and places it in the meta-package, e.g., "metapac --update-from my-package.rpm my-meta-package" and so on. Then create a centralized repository for meta-packages.
When web/magazine reviews include a dB measurement in their ratings, the problem will go away.
Which is more ethical? Making software tools developed in the course of one's taxpayer supported research program available under a liberal open source licence, or quiting your job at the university and taking your taxpayer supported software/ideas and selling them as a closed source proprietary product? (Hint: If you had any federal funding, e.g., NSF, you are required to release your source code.) Cheers, Tim