DRAW 1280, 1024

Discussion in 'Ruby' started by Benjohn Barnes, Sep 9, 2006.

  1. 20 years ago, the subject line would have drawn me a line across one
    of my screen's diagonals. Ruby is awesomely more powerful than BBC
    BASIC, but why no trivial graphics support?

    My two requirements are that it should be really easy to draw, and it
    should be possible to do so interactively (from irb).

    I've looked unsuccessfully in the past, but if this is a solved
    problem then I'd really like to know. Otherwise, does anyone have a
    suggestion of where to start?

    Personally, I'm on a Mac. If there is a solution for my world, that
    would do for me. Something global would rock though.

    Hope you have a lovely weekend,
    Benjohn
     
    Benjohn Barnes, Sep 9, 2006
    #1
    1. Advertising

  2. On 9 Sep 2006, at 09:20, Paul Lutus wrote:

    > Benjohn Barnes wrote:
    >
    >> 20 years ago, the subject line would have drawn me a line across one
    >> of my screen's diagonals. Ruby is awesomely more powerful than BBC
    >> BASIC, but why no trivial graphics support?

    >
    > Because there is no trivial way to make graphics facilities
    > platform-independent. You may notice that Ruby has native libraries
    > for
    > graphic interfaces, but these are also not platform-independent.
    > Through
    > those graphic interfaces, you can make drawings, but you then
    > cannot run
    > the program anywhere but on the original platform (with some
    > exceptions).


    It may not be trivial, but it's hardly difficult. There must be
    dozens of Ruby modules that have varying implementation by platform
    (sockets, for example)? Ruby itself pulls the feat of quite nicely
    too. Note that I'm not talking about taking full control of graphics
    hardware and exploiting all features. It's just really basic drawing
    support that would be good.

    >> My two requirements are that it should be really easy to draw, and it
    >> should be possible to do so interactively (from irb).

    >
    > Well, "irb" has a special purpose, and being a user interface for a
    > drawing
    > program isn't the purpose.


    I'm not suggesting that irb needs changing. I'm suggesting that the
    design of the graphics API I'm hoping for should be "irb friendly",
    which I believe it will be if well designed. Thus, using irb, I
    should be able to issue a commands and see the result. I shouldn't
    have to create contexts and windows, program up call backs, cache my
    drawing commands somewhere ready for a re-paint and string the lot
    together.

    >> I've looked unsuccessfully in the past, but if this is a solved
    >> problem then I'd really like to know. Otherwise, does anyone have a
    >> suggestion of where to start?
    >>
    >> Personally, I'm on a Mac. If there is a solution for my world, that
    >> would do for me. Something global would rock though.

    >
    > Global, there's the rub. I am sure there are libraries on the Mac
    > that allow
    > graphic interfaces to Ruby programs, but they aren't likely to be
    > portable.


    I've not even found something that merely works on the Mac, yet alone
    globally!

    I apologise if I sound exasperated Paul, and thank you for replying.
    It's not like I'm asking for a flying car here though: I just want my
    bicycle back.
     
    Benjohn Barnes, Sep 9, 2006
    #2
    1. Advertising

  3. Benjohn Barnes

    Chad Perrin Guest

    On Sat, Sep 09, 2006 at 04:39:04PM +0900, Benjohn Barnes wrote:
    > 20 years ago, the subject line would have drawn me a line across one
    > of my screen's diagonals. Ruby is awesomely more powerful than BBC
    > BASIC, but why no trivial graphics support?
    >
    > My two requirements are that it should be really easy to draw, and it
    > should be possible to do so interactively (from irb).
    >
    > I've looked unsuccessfully in the past, but if this is a solved
    > problem then I'd really like to know. Otherwise, does anyone have a
    > suggestion of where to start?
    >
    > Personally, I'm on a Mac. If there is a solution for my world, that
    > would do for me. Something global would rock though.


    If you're willing to try a different language, there's always Logo. In
    particular, I like UCBLogo (which, unlike other Logo versions,
    implements macros along with the rest of the Lispishness of the
    language). It has a very friendly functional syntax, has an excellent
    lineup of native graphics procedures (aka "functions), and is the
    example language used for an excellent trilogy of computer science books
    that are available free, online.

    Since this is a bit off-topic for this venue, I'll shut up now, but let
    me know if you want more information (links to resources, et cetera).

    As for Ruby . . . I don't know of any capabilities such as those you
    suggest, and I don't see them arising any time soon. I could be
    mistaken, however.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    unix virus: If you're using a unixlike OS, please forward
    this to 20 others and erase your system partition.
     
    Chad Perrin, Sep 9, 2006
    #3
  4. On 9/9/06, Benjohn Barnes <> wrote:
    > 20 years ago, the subject line would have drawn me a line across one
    > of my screen's diagonals. Ruby is awesomely more powerful than BBC
    > BASIC, but why no trivial graphics support?
    >
    > My two requirements are that it should be really easy to draw, and it
    > should be possible to do so interactively (from irb).


    You could build something atop Rubygame [ http://rubygame.seul.org/ ]
    fairly easily. In fact you could probably write a BBC graphics
    emulator, though the cursor-based thing would seem slightly odd in
    this day and age :) A QBasic graphics emulator otoh might be a
    worthwhile effort - IIRC it was pretty well thought-out and simple to
    use. Here's a quick example using plain Rubygame:

    irb(main):001:0> require 'rubygems'
    => true
    irb(main):002:0> require 'rubygame'
    => false
    irb(main):003:0> Rubygame.init
    => nil
    irb(main):004:0> screen = Rubygame::Screen.set_mode([640, 480])
    => #<Rubygame::Screen:0xb78ebc20>
    irb(main):005:0> red = [255, 0, 0]
    => [255, 0, 0]
    irb(main):006:0> Rubygame::Draw.line(screen, [0, 0], [639, 479], red)
    => #<Rubygame::Screen:0xb78ebc20>
    irb(main):007:0> screen.update
    => #<Rubygame::Screen:0xb78ebc20>

    The simplest way would be to have a class that automatically
    initialized a screen and held it as an instance variable, and a set of
    methods that wrapped the methods in Rubygame::Draw but passed in the
    default screen and remembered the last colour that was used in case no
    colour was supplied. For example
    -------------------------------------------------------------------------------------------
    require 'rubygems'
    require 'rubygame'

    class Sketchpad
    def initialize(x,y)
    @screen = Rubygame::Screen.set_mode([x, y])
    @color = [255, 255, 255] #white
    Thread.new {
    loop {
    @screen.update
    sleep 0.01
    }
    }
    end

    def line(x1, y1, x2, y2, color=@color)
    @color = color
    Rubygame::Draw.line(@screen, [x1, y1], [x2, y2], @color)
    @screen.update
    end
    end
    -------------------------------------------------------------------------------------------
    irb(main):001:0> require 'sketchpad.rb'
    => true
    irb(main):002:0> s = Sketchpad.new(640, 480)
    => #<Sketchpad:0xb791b808 @color=[255, 255, 255],
    @screen=#<Rubygame::Screen:0xb791b7cc>>
    irb(main):003:0> s.line(0, 0, 639, 479)
    => #<Rubygame::Screen:0xb791b7cc>
    irb(main):004:0> s.line(0, 479, 639, 0, [0, 0, 255])
    => #<Rubygame::Screen:0xb791b7cc>

    martin
     
    Martin DeMello, Sep 9, 2006
    #4
  5. On 9/9/06, Benjohn Barnes <> wrote:
    >
    > I'm not suggesting that irb needs changing. I'm suggesting that the
    > design of the graphics API I'm hoping for should be "irb friendly",
    > which I believe it will be if well designed. Thus, using irb, I
    > should be able to issue a commands and see the result. I shouldn't
    > have to create contexts and windows, program up call backs, cache my
    > drawing commands somewhere ready for a re-paint and string the lot
    > together.


    There's no getting around the "have to create contexts and windows"
    part - base ruby has absolutely no built-in idea of a graphics
    context. However, you can do this automatically as follows: to the
    bottom of sketchpad.rb add

    @sketchpad = Sketchpad.new(640, 480)

    def line(*args)
    @sketchpad.line(*args)
    end

    (that is, outside the class definition)

    now 'require sketchpad.rb' will execute the lines, create a @sketchpad
    object accessible from within irb, and let you call line as a function
    straight from the prompt. As a final touch, you can automatically
    require sketchpad.rb from your irbrc.

    Look also at the Delegator and Forwardable modules for some ways of
    automating the method wrapping.

    martin
     
    Martin DeMello, Sep 9, 2006
    #5
  6. Benjohn Barnes

    Chad Perrin Guest

    On Sat, Sep 09, 2006 at 06:46:51PM +0900, Robert Dober wrote:
    >
    > Chad
    > maybe you remember the post where I was discarding D and you kind of made me
    > think about it twice. This is a good time to come back [ I consider this
    > group flexible enough not to be bothered by slighly off topic posts but feel
    > free to tell me if I am wrong ] to you on this point.
    > I do not regret at all looking at D a second time and it indeed seems a very
    > nice thing to have in your toolbox!!!.
    > So why not toss in the links for UCBLogo?
    > I feel it might be of interest for more folks than just OP and myself.
    > If you feel differently about it could you reply to me offlist?
    > Thx in advance


    Good point(s). I'll post links here, at least:

    central UCBLogo resources page:
    http://www.cs.berkeley.edu/~bh/logo.html

    Computer Science Logo Style
    Volume 1: Symbolic Computing
    http://www.cs.berkeley.edu/~bh/v1-toc2.html

    Computer Science Logo Style
    Volume 2: Advanced Techniques
    http://www.cs.berkeley.edu/~bh/v2-toc2.html

    Computer Science Logo Style
    Volume 3: Beyond Programming
    http://www.cs.berkeley.edu/~bh/v3-toc2.html

    At least some Linux distributions (Debian included) provide UCBLogo
    packages in their software archives. I was delighted to find that I
    could install UCBLogo on my Debian systems by typing "apt-get install
    ucblogo" (without the quotes) into a root shell. Quite convenient.

    Logo has been called the "Lisp without parentheses", and that's pretty
    much what it is. Most implementations have been somewhat neutered in
    the creators' zeal for producing a language implementation that is
    friendly to young students, but UCBLogo is not of that ilk -- it goes so
    far as to include support for Lisp macros (though I haven't personally
    explored their use enough to be able to make a determination about how
    well they're supported, the syntax and use seems quite similar to that
    of ANSI Common Lisp).

    It's an open source distribution of Logo created by a Berkeley
    professor, Bryan Harvey, who is also the author of the above-mentioned
    university computer science textbooks that make use of UCBLogo as the
    example language. I've found the books to be well-written (so far -- I
    have been often and thoroughly distracted by the demands of other
    languages in my life, alas), and the language absurdly easy to learn.
    It has been the single biggest factor in my growing appreciation for
    arithmetic prefix notation, and functional syntax in general, so far.

    Suddenly, I'm considering creating a mailing list . . . damn. Like I
    don't have enough on my plate already.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "Real ugliness is not harsh-looking syntax, but having to
    build programs out of the wrong concepts." - Paul Graham
     
    Chad Perrin, Sep 9, 2006
    #6
  7. Benjohn Barnes wrote:
    > Personally, I'm on a Mac. If there is a solution for my world, that
    > would do for me. Something global would rock though.


    The best I can think of in portability is using wxWidgets / FOX / Gtk to
    draw inside a 2D buffer in a window / GUI widget. OpenGL or SDL to draw
    full-screen. I don't think it's trivially easy to doodle over someone's
    GUI though - though OpenGL or SDL might be able to draw on the overlay
    too. Lookup bindings to those libraries, I'm fairly sure that they're
    both available, and reasonably cross-platform.

    David Vallner
     
    David Vallner, Sep 9, 2006
    #7
  8. On 9/9/06, David Vallner <> wrote:
    > Benjohn Barnes wrote:
    > > Personally, I'm on a Mac. If there is a solution for my world, that
    > > would do for me. Something global would rock though.

    >
    > The best I can think of in portability is using wxWidgets / FOX / Gtk to
    > draw inside a 2D buffer in a window / GUI widget.


    I think all the GUI toolkits insist on running their own mainloop,
    which plays badly with IRB

    > OpenGL or SDL to draw full-screen.


    You can run OpenGL or SDL inside their own windows. I think this is
    the way to go.

    > I don't think it's trivially easy to doodle over someone's
    > GUI though - though OpenGL or SDL might be able to draw on the overlay
    > too. Lookup bindings to those libraries, I'm fairly sure that they're
    > both available, and reasonably cross-platform.


    Doodling over a GUI is of limited use anyway. Simply having a canvas
    you can interactively draw on from IRB is a neat thing. It was one of
    the features I'd planned for FXIrb, but I don't have the time to
    maintain that these days :(

    martin
     
    Martin DeMello, Sep 9, 2006
    #8
  9. Martin DeMello wrote:
    > I think all the GUI toolkits insist on running their own mainloop,
    > which plays badly with IRB
    >


    Spawn off inna thread, then jump through event posting hoops?

    Just ranting, SDL would be prolly both easier to get to work and with a
    richer API for drawing.
     
    David Vallner, Sep 9, 2006
    #9
  10. On 9/9/06, Paul Lutus <> wrote:
    > Martin DeMello wrote:
    >
    > But (IMHO) you shouldn't be using irb anyway. You should be using a user
    > entry event loop that evaluates the user's entries with "eval".
    >
    > > Doodling over a GUI is of limited use anyway. Simply having a canvas
    > > you can interactively draw on from IRB is a neat thing. It was one of
    > > the features I'd planned for FXIrb, but I don't have the time to
    > > maintain that these days :(

    >
    > I am at a loss to understand why you think irb is essential to your plan.
    > There are much better solutions for talking to the user.


    Because IRB has already solved the general problem of a good, robust
    REPL. Why should drawing to a canvas be treated as a separate problem?
    Ideally it should just be another set of things you can do from the
    ruby REPL.

    martin
     
    Martin DeMello, Sep 9, 2006
    #10
  11. Benjohn Barnes

    Chad Perrin Guest

    On Sun, Sep 10, 2006 at 12:58:10AM +0900, Martin DeMello wrote:
    > On 9/9/06, Paul Lutus <> wrote:
    > >
    > >I am at a loss to understand why you think irb is essential to your plan.
    > >There are much better solutions for talking to the user.

    >
    > Because IRB has already solved the general problem of a good, robust
    > REPL. Why should drawing to a canvas be treated as a separate problem?
    > Ideally it should just be another set of things you can do from the
    > ruby REPL.


    The upshot, I think, is that you'd probably have better luck creating a
    new REPL interface than integrating what you want to accomplish with
    IRB.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "There comes a time in the history of any project when it becomes necessary
    to shoot the engineers and begin production." - MacUser, November 1990
     
    Chad Perrin, Sep 9, 2006
    #11
  12. On 9/9/06, Paul Lutus <> wrote:
    > Martin DeMello wrote:
    > >
    > > Because IRB has already solved the general problem of a good, robust
    > > REPL. Why should drawing to a canvas be treated as a separate problem?

    >
    > Because of the problem of the event loop, which will be hijacked by irb if
    > it's part of the application.


    That only applies to a full-fledged GUI, complete with listeners,
    though - all the OP wanted was a simple canvas to which he could draw.
    I've already posted a working proof-of-concept of a canvas with a
    thread to update itself every few milliseconds, controllable from irb
    - I see no reason why that can't be extended to a more featureful
    drawable object that works happily alongside irb.

    martin
     
    Martin DeMello, Sep 9, 2006
    #12
  13. Benjohn Barnes wrote:
    > 20 years ago, the subject line would have drawn me a line across one of
    > my screen's diagonals. Ruby is awesomely more powerful than BBC BASIC,
    > but why no trivial graphics support?
    >
    > My two requirements are that it should be really easy to draw, and it
    > should be possible to do so interactively (from irb).
    >
    > I've looked unsuccessfully in the past, but if this is a solved problem
    > then I'd really like to know. Otherwise, does anyone have a suggestion
    > of where to start?
    >
    > Personally, I'm on a Mac. If there is a solution for my world, that
    > would do for me. Something global would rock though.
    >
    > Hope you have a lovely weekend,
    > Benjohn
    >
    >
    >
    >

    Well ... the closest to "global" that you're likely to get is Ruby/Tk,
    which is a port of Perl/Tk. There are some hints about getting started
    with it in the Pickaxe book, but you'll end up wanting a good Perl/Tk
    book to learn everything that it can do. As far as global is concerned,
    it at least runs on Windows, Mac and Linux. I'm sure it works on AIX,
    Tru64 and Solaris and can be made to work on HP-UX :).

    Another source of inspiration/guidance is to install a full Tcl/Tk
    distribution. It's available on all the major Linux distributions and
    from ActiveState (www.activestate.com) for Windows. It's probably
    available for MacOS if not installed by default. The worst case is that
    you need to build it from source.

    Inside the Tcl/Tk distribution is a rather nifty collection of demos --
    really cool things like drag and drop, sketchpads, etc. The source code
    is in the Tcl scripting language, but is easily translated into Perl,
    Python or Ruby.

    If you're really adventurous, you might try Rails and Ajax. Most of the
    common GUI things, including drag and drop, are available in libraries.

    Hmmmm ... there's an interesting Ruby quiz/ smallish educational project
    ... write a translator that converts the Tcl scripts in the Tcl/Tk demo
    package to Ruby/Tk.
     
    M. Edward (Ed) Borasky, Sep 9, 2006
    #13
  14. On Sep 9, 2006, at 6:22 AM, Chad Perrin wrote:

    > On Sat, Sep 09, 2006 at 06:46:51PM +0900, Robert Dober wrote:
    >>

    >
    > Good point(s). I'll post links here, at least:
    >
    > central UCBLogo resources page:
    > http://www.cs.berkeley.edu/~bh/logo.html
    >
    > Computer Science Logo Style
    > Volume 1: Symbolic Computing
    > http://www.cs.berkeley.edu/~bh/v1-toc2.html
    >
    > Computer Science Logo Style
    > Volume 2: Advanced Techniques
    > http://www.cs.berkeley.edu/~bh/v2-toc2.html
    >
    > Computer Science Logo Style
    > Volume 3: Beyond Programming
    > http://www.cs.berkeley.edu/~bh/v3-toc2.html
    >


    (Getting _really_ OT now...)

    I just want to say thanks, the chapter on Automata was really good,
    and it had the best explanation of the proof of the halting problem
    I've ever read.

    >
    > --
    > CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    > "Real ugliness is not harsh-looking syntax, but having to
    > build programs out of the wrong concepts." - Paul Graham
    >
     
    Logan Capaldo, Sep 9, 2006
    #14
  15. Benjohn Barnes

    Chad Perrin Guest

    On Sun, Sep 10, 2006 at 04:03:52AM +0900, Logan Capaldo wrote:
    >
    > On Sep 9, 2006, at 6:22 AM, Chad Perrin wrote:
    > >
    > >Good point(s). I'll post links here, at least:


    [ snip ]

    >
    > (Getting _really_ OT now...)
    >
    > I just want to say thanks, the chapter on Automata was really good,
    > and it had the best explanation of the proof of the halting problem
    > I've ever read.


    Quite welcome. I'm glad it was valuable.

    Now if I can just get Brian Harvey to relicense UCBLogo under less
    restrictive distribution terms than GPL, my work will be complete.

    Sorta.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "A script is what you give the actors. A program
    is what you give the audience." - Larry Wall
     
    Chad Perrin, Sep 9, 2006
    #15
  16. Thanks very much for all of the posts - I'll read them all on the bus
    in a moment!

    Cheers,
    Benjohn
     
    Benjohn Barnes, Sep 9, 2006
    #16
  17. Benjohn Barnes

    E. Mark Ping Guest

    In article <>,
    Chad Perrin <> wrote:
    >Now if I can just get Brian Harvey to relicense UCBLogo under less
    >restrictive distribution terms than GPL, my work will be complete.


    I'd say that's unlikely. He's quite the idealist (he was my first
    instructor in CS, and I was a TA for him later). Not quite RMS (he's
    far more relaxed), but in the same vein.

    On the other hand, if you offer him enough potstickers, you never know
    what he might do. A BSD-style license might interest him.
    --
    Mark Ping
     
    E. Mark Ping, Sep 10, 2006
    #17
  18. Benjohn Barnes

    Chad Perrin Guest

    On Sun, Sep 10, 2006 at 08:55:09AM +0900, E. Mark Ping wrote:
    > In article <>,
    > Chad Perrin <> wrote:
    > >Now if I can just get Brian Harvey to relicense UCBLogo under less
    > >restrictive distribution terms than GPL, my work will be complete.

    >
    > I'd say that's unlikely. He's quite the idealist (he was my first
    > instructor in CS, and I was a TA for him later). Not quite RMS (he's
    > far more relaxed), but in the same vein.
    >
    > On the other hand, if you offer him enough potstickers, you never know
    > what he might do. A BSD-style license might interest him.


    Idealism isn't an obstacle to me -- it's the wrong ideology. The things
    I dislike about the GPL have nothing to do with commercializing things
    as proprietary software, and everything to do with granting people the
    right to distribute software freely. The GPL, in case you haven't
    heard, has been used by the FSF as justification for threatening small
    Linux distros with lawsuits if they don't devote significant resources
    to maintaining, and making available, archives of software for several
    years after the software in question has become obsolete by the
    project's standards. According to the GPL, once you make a piece of GPL
    software availabl to someone in binary form, even if only for a few
    hours, you must then provide easy accessibility to the source for three
    years thereafter -- and linking them upstream is not sufficient to suit
    the FSF.

    This is going to make a lot of would-be Linux distributors think twice
    about creating and distributing a distribution. It will especially
    affect smaller project would-be founders think twice.

    It made me think twice. I now won't ever be part of any GPL binary
    distribution chain, ever -- which pretty much makes BitTorrent a
    non-option for me as a means of getting Linux installer images, since
    BitTorrent's value for that is negated when I'm not allowing uploads to
    "give back" to the torrent availability. A distribution I was working
    on has been canned. Et cetera.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    unix virus: If you're using a unixlike OS, please forward
    this to 20 others and erase your system partition.
     
    Chad Perrin, Sep 10, 2006
    #18
  19. Chad Perrin wrote:
    > Idealism isn't an obstacle to me -- it's the wrong ideology. The things
    > I dislike about the GPL have nothing to do with commercializing things
    > as proprietary software, and everything to do with granting people the
    > right to distribute software freely. The GPL, in case you haven't
    > heard, has been used by the FSF as justification for threatening small
    > Linux distros with lawsuits if they don't devote significant resources
    > to maintaining, and making available, archives of software for several
    > years after the software in question has become obsolete by the
    > project's standards. According to the GPL, once you make a piece of GPL
    > software availabl to someone in binary form, even if only for a few
    > hours, you must then provide easy accessibility to the source for three
    > years thereafter -- and linking them upstream is not sufficient to suit
    > the FSF.
    >
    > This is going to make a lot of would-be Linux distributors think twice
    > about creating and distributing a distribution. It will especially
    > affect smaller project would-be founders think twice.


    I can't personally imagine why someone would want to be a "Linux
    distributor". There are two major "for-profit" Linux distributors
    already, Red Hat and Novell, three major community distributors,
    Slackware, Debian and Gentoo, and lots of little splinters and hangers
    on. If you're motivated by money, work for Red Hat or Novell or someone
    who uses them. If you're motivated by community, contribute to Debian or
    Gentoo or Slackware.

    There are a lot of things not to like about the GPL and the FSF in
    addition to the ones you mention. But even in the absence of potential
    FSF lawsuits, there are lots more interesting and potentially profitable
    problems to be solved within the context of existing distributions,
    rather than creating a new one.
    >
    > It made me think twice. I now won't ever be part of any GPL binary
    > distribution chain, ever -- which pretty much makes BitTorrent a
    > non-option for me as a means of getting Linux installer images, since
    > BitTorrent's value for that is negated when I'm not allowing uploads to
    > "give back" to the torrent availability. A distribution I was working
    > on has been canned. Et cetera.


    I wasn't aware of the BitTorrent interpretation of this FSF policy. Has
    someone actually been asked not to participate in BitTorrent exchange of
    Linux install media by the FSF? I download Quantian, Gentoo, CentOS,
    OpenSuse and occasionally other distro images all the time with BitTorrent.

    Speaking of licensing, a couple of days ago I downloaded OpenSuse 10.1
    and installed it. You ought to read the Novell EULA when you install it
    -- I almost bailed out and probably won't use it, since it was quite a
    bit slower than Gentoo anyhow. :) Oops ... one of the terms of the EULA
    was that I not publish benchmarks. :)
    >
     
    M. Edward (Ed) Borasky, Sep 10, 2006
    #19
  20. Benjohn Barnes

    Chad Perrin Guest

    On Sun, Sep 10, 2006 at 10:15:51AM +0900, M. Edward (Ed) Borasky wrote:
    > Chad Perrin wrote:
    > >
    > > It made me think twice. I now won't ever be part of any GPL binary
    > > distribution chain, ever -- which pretty much makes BitTorrent a
    > > non-option for me as a means of getting Linux installer images, since
    > > BitTorrent's value for that is negated when I'm not allowing uploads to
    > > "give back" to the torrent availability. A distribution I was working
    > > on has been canned. Et cetera.

    >
    > I wasn't aware of the BitTorrent interpretation of this FSF policy. Has
    > someone actually been asked not to participate in BitTorrent exchange of
    > Linux install media by the FSF? I download Quantian, Gentoo, CentOS,
    > OpenSuse and occasionally other distro images all the time with BitTorrent.


    Nobody associated with BitTorrent distribution of GPL software binaries
    has been threatened with a lawsuit or otherwise coerced to cease
    participation in BitTorrent exchanges YET, but I don't want to run that
    risk personally. Someone was the first person to get individually sued
    by the RIAA -- someone may be the first person to get individually sued
    by the FSF. I'll let it be you.


    >
    > Speaking of licensing, a couple of days ago I downloaded OpenSuse 10.1
    > and installed it. You ought to read the Novell EULA when you install it
    > -- I almost bailed out and probably won't use it, since it was quite a
    > bit slower than Gentoo anyhow. :) Oops ... one of the terms of the EULA
    > was that I not publish benchmarks. :)


    I'm still waiting to see if EULAs are even enforceable -- that hasn't
    been settled yet. In any case, I don't favor SuSE of any flavor, so
    that's not much of a concern for me personally. That doesn't mean I
    approve of the EULA approach to things. Retroactive contractual terms,
    particularly when implicitly applied, don't make me happy in the least.

    You may notice that I snipped all your rambling to the effect of "Nobody
    should want to create a new distro anyway." There's a good reason for
    that: it's not for you to decide what someone else does or does not want
    to do, and it is in large part the ability to fork and/or compete as a
    lone enthusiast that keeps the FLOSS community vibrant. All of your
    commentary about why one might or might not want to spin off another
    distribution is irrelevant to the point at hand, as far as I'm
    concerned.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "The ability to quote is a serviceable
    substitute for wit." - W. Somerset Maugham
     
    Chad Perrin, Sep 10, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan
    Replies:
    9
    Views:
    5,190
  2. Anthony J Bybell
    Replies:
    0
    Views:
    711
    Anthony J Bybell
    Jan 28, 2005
  3. Replies:
    5
    Views:
    395
  4. Tor Erik Sønvisen

    Most efficient way of storing 1024*1024 bits

    Tor Erik Sønvisen, Nov 2, 2005, in forum: Python
    Replies:
    15
    Views:
    519
    Alex Stapleton
    Nov 4, 2005
  5. Replies:
    2
    Views:
    545
    Bergamot
    Jul 25, 2007
Loading...

Share This Page