Re: [fw-wiz] MJR on Linux/OSS

From: Christopher Hicks (chicks_at_chicks.net)
Date: 03/10/05

  • Next message: Darren Reed: "Re: [fw-wiz] MJR on Linux/OSS"
    To: Firewall Wizards Mailing List <firewall-wizards@honor.icsalabs.com>, Devdas Bhagat <devdas@dvb.homelinux.org>
    Date: Thu, 10 Mar 2005 12:09:27 -0500 (EST)
    
    

    On Mon, 7 Mar 2005, Devdas Bhagat wrote:
    > http://www.ranum.com/editorials/divide-conquer/
    > Summary: Diversity in interfaces is bad. Microsoft's consistent interface
    > is good.

    Your summarization skills leave a lot to be desired. A better summary
    would be that UNIX/FOSS folks are self-defeating because of the numerous
    petty squabbles we engage in.

    > Which consistent interface would suit everyone?

    There are a variety of interfaces to consider here. The USER interface is
    pretty consistant. Folks don't seem to have much trouble working with
    Macs, Windows, KDE, or Gnome. All of them work similarly 90% of the time
    from the user's perspective. Except for cut-and-paste I could work on a
    Windows client as easily as a Linux one. (And there are patches to fix
    that if I cared to install them.)

    The more significant interface in terms of Marcus' article is the
    programmer/developer interface. This includes the tool chain, libraries,
    and deployment. Here we end up with "great diversity" which is mostly
    pointless. The LSB folks have done an admirable job of reducing these
    petty differences. Hopefully this effort will continue to gain momentum.
    Even if it does you still have the various BSD's and commercial UNIXen
    that won't conform for the forseeable future. This apparent in-fighting,
    even if its passive and quiet, discourages developers from aiming their
    software at the FOSS world.

    > As opposed to users saying "I know this interface, and I don't want to
    > learn anything new", which interface would be acceptable?
    > KDE? GNOME? WindowMaker? Windows? MacOS? The command line?

    As I said above, that stuff is hardly what matters and is totally beside
    the point that Marcus' article was making.

    > Oh yes, you can run any distro with no big real difference between
    > them. The major lines: Debian, Redhat, Gentoo. The rest are clones, or
    > similar enough to transition easily between.

    The differences between these distros from a sysadmin or developer
    perspective are pretty significant actually. A user's ability to switch
    isn't the concern, but whether a developer or sysadmin could switch
    painlessly. That's far from the case. The idea behind .deb and .rpm are
    pretty similar. It's like VHS vs. Betamax. But in the FOSS world we'll
    keep both until the end of time. As a developer that's a real pain
    because I know how to build rpm's and I don't really care to learn to make
    .debs. Keeping track of all these distro-to-distro nuances is a full time
    job at many development shops and detracts from real development.

    > The trouble with a single dominant monoculture is that it does increase
    > the damage caused by a single hole. See blaster, and the long thread
    > which was spawned by *that* on this list.

    The solution to these problems isn't a monoculture. The solution to these
    problems is to stop arguing over petty sh*t and make the common pieces
    standardized and interchangeable so that innovation can focus on making
    new things.

    > I guess this is one of those things on which I disagree with Marcus.

    You really seem to be disagreeing with something that he wasn't trying to
    convey.

    > Hopefully, this leads to another good discussion on what would work
    > best for what requirements (as opposed to the /. threads).

    Hopefully this will encourage a few folks to put down their partisan flags
    and work together, but since this list isn't a list of developers for the
    most part it probably won't have much effect.

    > Oh, and Marcus: DLL hell ;)

    Mercifully UNIX/FOSS folks have mostly figured out that versioned libs are
    a path out of DLL hell, but that's not enough to overcome our other issues
    to bring in the big boys of software. Oracle and Sybase are certainly
    feathers in the cap and help legitimize things, but they're not the
    software that most businesses care about. (These guys run on almost
    everything anyway, so yet another port for them isn't a major surprise.)
    Adobe, Macromedia, Corel, Microsoft, and games are what are going to make
    a difference. When those folks start shipping Linux versions in parity
    (time and featurewise) with their Windows releases then there will be
    something to write home about.

    -- 
    </chris>
    "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
    -Ed Howdershelt (Author)
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    

  • Next message: Darren Reed: "Re: [fw-wiz] MJR on Linux/OSS"

    Relevant Pages

    • Re: Message-based vs. method-based interaction [was: Re: LSP and subtype]
      ... interface is always the method signature. ... We can name it for the owner context of what it does or we can name it for the client context, but we can't do both. ... overlaying some sort of developer structure on the 3GL syntax. ...
      (comp.object)
    • Re: Message-based vs. method-based interaction [was: Re: LSP and subtype]
      ... interface is always the method signature. ... We can name it for the owner context of what it does or we can name it for the client context, but we can't do both. ... overlaying some sort of developer structure on the 3GL syntax. ... Such separation is impossible to do with pure 3GL language syntax. ...
      (comp.object)
    • I need help...
      ... to provide a conversational interface. ... Hopefully gathering together a developer or two from ... 3D scene visualization and construction ... Custom server and network visualization and maintenance environment ...
      (microsoft.public.development.device.drivers)
    • I need help...
      ... to provide a conversational interface. ... Hopefully gathering together a developer or two from ... 3D scene visualization and construction ... Custom server and network visualization and maintenance environment ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Rich GUI in C#
      ... buyt I'm an experienced vc# developer. ... How can I develope an interface to my app like "Media Center Edition" style? ... > programming, which I applaud (programming is the love of my life, next to my ... >> thx for your answers. ...
      (microsoft.public.dotnet.languages.csharp)