Re: [9fans] Re: Building GCC - Plan9

This is a discussion on Re: [9fans] Re: Building GCC - Plan9 ; On Jan 23, 2008 11:17 PM, Iruata Souza wrote: > flash doesn't have anything to do with compliance. nor does javascript. > speaking of the web, you should be compliant with what you choose to implement. > if you only ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 49

Thread: Re: [9fans] Re: Building GCC

  1. Re: [9fans] Re: Building GCC

    On Jan 23, 2008 11:17 PM, Iruata Souza wrote:
    > flash doesn't have anything to do with compliance. nor does javascript.
    > speaking of the web, you should be compliant with what you choose to implement.
    > if you only implement html and you're compliant with w3c, you are compliant.


    Screw w3c. Much as it pains me to admit it, to ignore javascript is
    to ignore the web.
    A modern web browser is more like a VM. But instead of having some
    sort of sane rendering backend it uses HTML/CSS. Javascript/plugins
    serve as the "userspace" code, if you will. HTTP exports the local
    rendering interface and cpu to remote machines.
    Gecko makes the JVM look sleek.
    -sqweek

  2. Re: [9fans] Re: Building GCC

    > A modern web browser is more like a VM. But instead of having some
    > sort of sane rendering backend it uses HTML/CSS. Javascript/plugins
    > serve as the "userspace" code, if you will. HTTP exports the local
    > rendering interface and cpu to remote machines.


    I haven't looked at any implementation of an HTML rendering engine, so
    I may be totally off the mark, but presumably there is merit in the
    ability to take a textual source and turn it into a two-dimensional
    graphical representation of the intended document?

    Now, HTML may be a poor realisation of the language such a rendering
    engine would interpret, but it must be possible to design a mark-up
    language (and let's not let "mark-up" or "language" condition our
    thinking) that can be used as the human-editable source for a
    graphical production. I don't suggest that there is a "perfect" such
    notation, merely that we have had enough experience with word
    processors (a long list), text processors (TeX, troff, etc.) and page
    layout languages (Postscript, are there any other interesting ones?)
    to be able to explore the next generation, together with the tools
    they would need to manipulate them.

    Given a rendering engine with a powerful and hopefully flexible input
    language, one may be able to write compilers or interpreters for the
    more popular brands. Or am I missing the wood for the trees?

    If I'm not, I propose that Plan 9 could provide the platform for such
    an engine as well as for the various interpreters. Designing a useful
    graphical description language is no small project, but surely there
    is some prior art out there than one can draw on?

    ++L


  3. Re: [9fans] Re: Building GCC

    > Given a rendering engine with a powerful and hopefully flexible input
    > language, one may be able to write compilers or interpreters for the
    > more popular brands. Or am I missing the wood for the trees?
    >


    i think you're right on the mark. suppose that acme and rio were built
    on "liblayout" and not libframe. liblayout provides a basic boxes-n-glue
    view of the world; acme/rio export /dev/layout. a box could contain an image or a
    text frame. then acme could display things like images along with text,
    static html content (given an educated htmlfmt), etc.

    - erik

  4. Re: [9fans] Re: Building GCC

    And then we can have raw images as filenames, raw images in plain
    text, text as the stroke style for a line, etc. I'd like raw images
    in text - it makes mpictures and converting to PostScript unnecessary.

    According to the wiki page on TODO, it says htmlfmt needs knowledge
    of tables. With this, we could just put the HTML parser and rendering
    in acme/rio and avoid htmlfmt.

    Unfortunately, we're about 20 years too late. People have Microsoft
    Word and they don't need an operating system with useful features,
    automated backup at no additional cost, and a wealth of
    documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
    I use troff now. If you disagree, raise your virtual hands.

    Instead of debating on what's the right thing to do to add innovation
    about 10+ years old to a system that should've had it 10 years ago,
    let's focus on how to innovate for the future, shall we? It's not
    that I don't like starting debates (I did start this one), but now my
    original idea sounds unnecessary.

    I just wanted Konqueror so I could browse the whole web, but with
    someone adding CSS to abaco and JavaScript in charon, can we merge
    them or add JavaScript to abaco or something? I don't know anymore.
    If you need me, I'll be adding tables to htmlfmt.


  5. Re: [9fans] Re: Building GCC

    >> Given a rendering engine with a powerful and hopefully flexible input
    >> language, one may be able to write compilers or interpreters for the
    >> more popular brands. Or am I missing the wood for the trees?
    >>

    >
    > i think you're right on the mark. suppose that acme and rio were built
    > on "liblayout" and not libframe. liblayout provides a basic boxes-n-glue
    > view of the world; acme/rio export /dev/layout. a box could contain an image or a
    > text frame. then acme could display things like images along with text,
    > static html content (given an educated htmlfmt), etc.


    How far away is abaco from all this? My impression is that it at
    least aims in that direction. Thing is, it always struck me that
    abaco and acme ought to be blended, not constructed independently of
    each other.

    But I must confess that I'm still too scared to look under the larger
    Plan 9 applications, I accept them as they come.

    ++L


  6. Re: [9fans] Re: Building GCC

    > If you need me, I'll be adding tables to htmlfmt.

    In bocca al lupo!

    But you can't add JavaScript to htmlfmt so we're still miles away from
    being able to do one's banking in Plan 9.

    Personally, I mix VNC and an UBUNTU laptop to get things done, because
    I have to. Perhaps the consolation I can draw from noticing the
    sluggishness of these devices is that all exponential growth
    eventually exceeds available resources.

    When wintelinux comes crashing down through an inability to sustain
    growth, Plan 9 will be a good candidate for the next hardware
    platform. There will be others, all of them, hopefully, skinnier than
    their predecessors.

    In fact, at the current rate, wintelinux ought to be slowing down
    relative to Plan 9, if not already, certainly pretty soon.

    ++L


  7. Re: [9fans] Re: Building GCC

    > Unfortunately, we're about 20 years too late. People have Microsoft
    > Word and they don't need an operating system with useful features,
    > automated backup at no additional cost, and a wealth of
    > documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
    > I use troff now. If you disagree, raise your virtual hands.


    it's quite a stretch to go from acme being able to handle layouts
    to microsoft word. the oberon system had something like layouts,
    but layouts were part of the text module. thus there was no such
    thing as plain text. the next station had display postscript. but
    that's a quite complicated model. i think text should be text and
    images should be images.

    but you just can't do graphics or html layout with just text.
    you need something to glue (sorry) things together. it's
    fairly annoying that proof text is not selectable and doesn't
    work inside acme.

    i realize there are holes around the edges. i don't see how to
    edit or select a layout, just the text within layouts. maybe
    select skips non-text bits.

    what's so wrong about this idea?

    - erik

  8. Re: [9fans] Re: Building GCC

    I wish page(1) would do the same. However, I think page operates via
    libdraw, and either:
    - they need to modify libdraw to allow text selection, or
    - they need to use libcontrol instead and write a rich text system
    for libcontrol
    Both of them are as difficult as each other. I've seen code for word
    processors (tried to contribute to AbiWord, autotools slowed me down)
    and it's quite big.

    On Jan 24, 2008, at 1:52 PM, erik quanstrom wrote:

    >> Unfortunately, we're about 20 years too late. People have Microsoft
    >> Word and they don't need an operating system with useful features,
    >> automated backup at no additional cost, and a wealth of
    >> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
    >> I use troff now. If you disagree, raise your virtual hands.

    >
    > it's quite a stretch to go from acme being able to handle layouts
    > to microsoft word. the oberon system had something like layouts,
    > but layouts were part of the text module. thus there was no such
    > thing as plain text. the next station had display postscript. but
    > that's a quite complicated model. i think text should be text and
    > images should be images.
    >
    > but you just can't do graphics or html layout with just text.
    > you need something to glue (sorry) things together. it's
    > fairly annoying that proof text is not selectable and doesn't
    > work inside acme.
    >
    > i realize there are holes around the edges. i don't see how to
    > edit or select a layout, just the text within layouts. maybe
    > select skips non-text bits.
    >
    > what's so wrong about this idea?
    >
    > - erik



  9. Re: [9fans] Re: Building GCC

    I'm also saying that if and when Plan 9 does gets this layout feature
    that works like Oberon (which I tried, but never managed to get
    installed, so I have no first-hand experience - more of Wirth's junk
    in the trunk), people might be reluctant to leave Microsoft Word for
    it. acme does not need to support .doc. However, I don't think people
    would want to have a windowing environment where your commands are
    not accessed via a Start menu or Dock, where you use the right mouse
    button to create windows, and where there is no readily visible close
    button in a familiar place. For Plan 9, it's what we, its users,
    want, not what they, the rest of them that don't see us, want. If
    they do Plan 9, they'll probably get the QEMU module from somewhere
    in /n/sources/contrib to install Windows or go right to Inferno's wm/
    wm (and Inferno's acme would need to be updated too) and skip all of
    Plan 9's glory.

    On Jan 24, 2008, at 1:52 PM, erik quanstrom wrote:

    >> Unfortunately, we're about 20 years too late. People have Microsoft
    >> Word and they don't need an operating system with useful features,
    >> automated backup at no additional cost, and a wealth of
    >> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
    >> I use troff now. If you disagree, raise your virtual hands.

    >
    > it's quite a stretch to go from acme being able to handle layouts
    > to microsoft word. the oberon system had something like layouts,
    > but layouts were part of the text module. thus there was no such
    > thing as plain text. the next station had display postscript. but
    > that's a quite complicated model. i think text should be text and
    > images should be images.
    >
    > but you just can't do graphics or html layout with just text.
    > you need something to glue (sorry) things together. it's
    > fairly annoying that proof text is not selectable and doesn't
    > work inside acme.
    >
    > i realize there are holes around the edges. i don't see how to
    > edit or select a layout, just the text within layouts. maybe
    > select skips non-text bits.
    >
    > what's so wrong about this idea?
    >
    > - erik



  10. Re: [9fans] Re: Building GCC

    > i realize there are holes around the edges. i don't see how to
    > edit or select a layout, just the text within layouts. maybe
    > select skips non-text bits.
    >
    > what's so wrong about this idea?


    Nothing, you need to think out of the box. Current selection in
    sam/acme is linear, even though it is shown as two-dimensional. Text
    is treated as linear (might explain why HTML tabels are treated with
    contempt) even though it has some two-dimensional properties, at least
    on the screen or on paper.

    For layouts (I'm pretty ignorant here, please excuse any blunder I may
    utter), you need at least as many dimensions as occur in the
    representation, one is not a practical option, two would be normal,
    more will no doubt be possible in the future. My gut feel is that
    once one breaks away from the linear interpretation of text, a lot of
    things will fall into place.

    One thought is that vertical font sizes are an additional dimension,
    while images are merely single characters with unusual height and
    width. The horizontal character size is in the first dimension, of
    course.

    As for mark-ups, they require their own treatment, probably along the
    lines of living in a separate layer as would be the case in image
    editing. Using layers seems to me like a good concept to edit
    enhanced text. Perhaps horizontal and vertical dimensions also belong
    in layers distinct from the abstract text.

    Just a naive idea...

    ++L


  11. Re: [9fans] Re: Building GCC

    > Nothing, you need to think out of the box. Current selection in
    > sam/acme is linear, even though it is shown as two-dimensional. Text
    > is treated as linear (might explain why HTML tabels are treated with
    > contempt) even though it has some two-dimensional properties, at least
    > on the screen or on paper.


    selection implies you can paste. if you can paste, you need a Word
    Processorâ„¢ to edit these layouts. so i think selection is something to be avoided.

    - erik

  12. Re: [9fans] Re: Building GCC

    > I wish page(1) would do the same. However, I think page operates via
    > libdraw, and either:
    > - they need to modify libdraw to allow text selection, or
    > - they need to use libcontrol instead and write a rich text system
    > for libcontrol
    > Both of them are as difficult as each other. I've seen code for word
    > processors (tried to contribute to AbiWord, autotools slowed me down)
    > and it's quite big.


    page can't be made to do this. page manipulates images created by
    other programs.

    if you're thinking rich text, you're on a different track than i.
    think rich text is not worth the cost. the layout needs to enclose
    blocks of text or images.

    you also write seperately

    > installed, so I have no first-hand experience - more of Wirth's junk
    > in the trunk), people might be reluctant to leave Microsoft Word for


    dr. wirth can not be accused of software bloat nor of poor programming.
    is work is excellent. the oberon system is so spartian there are no directories.
    that's just too spartain for me.

    you know, i don't feel like i need to get the world using plan 9.
    it's enough to change myself.

    - erik

  13. Re: [9fans] Re: Building GCC

    On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
    >>

    > dr. wirth can not be accused of software bloat nor of poor
    > programming.
    > is work is excellent. the oberon system is so spartian there are
    > no directories.
    > that's just too spartain for me.
    >


    I can agree Wirth has improved his ways over the past 20 years, but I
    never got Oberon installed. No directories has not been practiced
    ever to my memory; the closest I can think of off the top of my head
    is the first Macintosh only having directories in / and no
    subdirectories.

    > you know, i don't feel like i need to get the world using plan 9.
    > it's enough to change myself.
    >
    > - erik


    The world doesn't need to use Plan 9 - I doubt there is advertising
    anymore. But if someone else hears about Plan 9 and doesn't want to
    use it because he doesn't find it familiar, he'll probably say the
    same thing. I am perfectly comfortable with Plan 9 the way it is, and
    I enjoy troff, but the rest of the world may think otherwise.

    This discussion started with me trying to get GCC to work. Now it's
    run off into about 3,000 different directions and I don't know much
    anymore. I just want to mention that I also tried GCC to see if I
    could build Ruby 1.9.0 with it.


  14. Re: [9fans] Re: Building GCC

    I think that...

    We have to take a look at Plan 9 history to realize that it has more
    to offer than to envy.

    The whole point of Plan 9, imho, is not to become the everywhere
    avaliable "me too" OS... More likely it is the "can you do this?" OS.

    The way information is presented to the user has changed a lot.
    Everything has become "shiny"... Even writing a boring essay
    apparently needs 3d shadows and some wobbly windows... And don't get
    me started with web browsing... I would say that I have seen good uses
    of interactive animations to show data, regardless of the platform
    they are built on. I have also seen good use of web standards...

    And of course many abuses.

    But anyway... I can't see Plan 9 as an enviroment to "clone" things...
    It is more like a confortable greenhouse where you can grow new ideas.
    Perhaps there are new ideas around that anyone can freely try to
    "plant" inside the greenhouse... But I think that the final purpose
    should be doing that same thing in a more efficient, beautiful and
    better way....

    I personally can't find a reason to port konqueror to plan 9, but I
    can think of many reasons to work on abaco... We can learn a lot from
    quality challenged/impaired software like firefox or konqueror, and we
    can avoid those mistakes with the elegance that characterizes to the
    Plan 9 Philosophy.

    But I am just a moron talking about things I don't really understand.

    Cheers!

    On 1/24/08, Pietro Gagliardi wrote:
    > On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
    > >>

    > > dr. wirth can not be accused of software bloat nor of poor
    > > programming.
    > > is work is excellent. the oberon system is so spartian there are
    > > no directories.
    > > that's just too spartain for me.
    > >

    >
    > I can agree Wirth has improved his ways over the past 20 years, but I
    > never got Oberon installed. No directories has not been practiced
    > ever to my memory; the closest I can think of off the top of my head
    > is the first Macintosh only having directories in / and no
    > subdirectories.
    >
    > > you know, i don't feel like i need to get the world using plan 9.
    > > it's enough to change myself.
    > >
    > > - erik

    >
    > The world doesn't need to use Plan 9 - I doubt there is advertising
    > anymore. But if someone else hears about Plan 9 and doesn't want to
    > use it because he doesn't find it familiar, he'll probably say the
    > same thing. I am perfectly comfortable with Plan 9 the way it is, and
    > I enjoy troff, but the rest of the world may think otherwise.
    >
    > This discussion started with me trying to get GCC to work. Now it's
    > run off into about 3,000 different directions and I don't know much
    > anymore. I just want to mention that I also tried GCC to see if I
    > could build Ruby 1.9.0 with it.
    >
    >


  15. Re: [9fans] Re: Building GCC


    On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:
    > When wintelinux comes crashing down through an inability to sustain
    > growth, Plan 9 will be a good candidate for the next hardware
    > platform. There will be others, all of them, hopefully, skinnier than
    > their predecessors.


    I just saw the following in another mailing list. It seems to echo
    your sentiments:

    Jay Levitt wrote:
    > Eclipse (and Java in general) is a great example of what I call
    > "stratification" - the re-implementation of lower layers in ever-
    > higher
    > layers, because nobody even remembers the lower layer is there
    > anymore.
    >
    > If you build a mail system that relies on a database, someone will
    > inevitably decide that a mail system, with its built-in queueing,
    > routing
    > and simplicity, is a great transport for asynchronous replication,
    > which in
    > turn, can be used to create a distributed file system. And once
    > you've got
    > a file system, well, wouldn't it be great to get a database running
    > on it?


    Gary Wright

  16. Re: [9fans] Re: Building GCC

    Grazie, ho finito.

    Actually, it might not be what you want, and it isn't perfect. What
    it does is it formats each cell to be the length of the longest of
    the whole table. There's some hooks to get it working. However, a few
    setbacks:
    - it only works with text data (no )
    - no nested tables
    I'm working on all of these, as well as changing it so that each
    column is the length of its largest item rather than the whole
    table's largest item.

    On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:

    >> If you need me, I'll be adding tables to htmlfmt.

    >
    > In bocca al lupo!
    >
    > But you can't add JavaScript to htmlfmt so we're still miles away from
    > being able to do one's banking in Plan 9.
    >
    > Personally, I mix VNC and an UBUNTU laptop to get things done, because
    > I have to. Perhaps the consolation I can draw from noticing the
    > sluggishness of these devices is that all exponential growth
    > eventually exceeds available resources.
    >
    > When wintelinux comes crashing down through an inability to sustain
    > growth, Plan 9 will be a good candidate for the next hardware
    > platform. There will be others, all of them, hopefully, skinnier than
    > their predecessors.
    >
    > In fact, at the current rate, wintelinux ought to be slowing down
    > relative to Plan 9, if not already, certainly pretty soon.
    >
    > ++L
    >



  17. Re: [9fans] Re: Building GCC

    Just added:
    - proper column sizing
    - cellpadding and cellspacing support
    Planned:
    - nested images, rules, forms, etc.
    - borders (made using either ASCII or Unicode characters; I'll
    discuss the differences later)
    - nested tables
    Once at least nested non-text is finished, I'll submit it to patch.

    On Jan 24, 2008, at 9:47 PM, Pietro Gagliardi wrote:

    > Grazie, ho finito.
    >
    > Actually, it might not be what you want, and it isn't perfect. What
    > it does is it formats each cell to be the length of the longest of
    > the whole table. There's some hooks to get it working. However, a
    > few setbacks:
    > - it only works with text data (no )
    > - no nested tables
    > I'm working on all of these, as well as changing it so that each
    > column is the length of its largest item rather than the whole
    > table's largest item.
    >
    > On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:
    >
    >>> If you need me, I'll be adding tables to htmlfmt.

    >>
    >> In bocca al lupo!
    >>
    >> But you can't add JavaScript to htmlfmt so we're still miles away
    >> from
    >> being able to do one's banking in Plan 9.
    >>
    >> Personally, I mix VNC and an UBUNTU laptop to get things done,
    >> because
    >> I have to. Perhaps the consolation I can draw from noticing the
    >> sluggishness of these devices is that all exponential growth
    >> eventually exceeds available resources.
    >>
    >> When wintelinux comes crashing down through an inability to sustain
    >> growth, Plan 9 will be a good candidate for the next hardware
    >> platform. There will be others, all of them, hopefully, skinnier
    >> than
    >> their predecessors.
    >>
    >> In fact, at the current rate, wintelinux ought to be slowing down
    >> relative to Plan 9, if not already, certainly pretty soon.
    >>
    >> ++L
    >>

    >



  18. Re: Building GCC

    On Jan 24, 9:39 pm, pietr...@mac.com (Pietro Gagliardi) wrote:
    > On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
    >
    >
    >
    > > dr. wirth can not be accused of software bloat nor of poor
    > > programming.
    > > is work is excellent. the oberon system is so spartian there are
    > > no directories.
    > > that's just too spartain for me.

    >
    > I can agree Wirth has improved his ways over the past 20 years, but I
    > never got Oberon installed. No directories has not been practiced
    > ever to my memory; the closest I can think of off the top of my head
    > is the first Macintosh only having directories in / and no
    > subdirectories.
    >
    > > you know, i don't feel like i need to get the world using plan 9.
    > > it's enough to change myself.

    >
    > > - erik

    >
    > The world doesn't need to use Plan 9 - I doubt there is advertising
    > anymore. But if someone else hears about Plan 9 and doesn't want to
    > use it because he doesn't find it familiar, he'll probably say the
    > same thing. I am perfectly comfortable with Plan 9 the way it is, and
    > I enjoy troff, but the rest of the world may think otherwise.
    >
    > This discussion started with me trying to get GCC to work. Now it's
    > run off into about 3,000 different directions and I don't know much
    > anymore. I just want to mention that I also tried GCC to see if I
    > could build Ruby 1.9.0 with it.


    Thinking how to get some piece of alien software work on Plan 9, e.g.
    web browser to access the web is certainly not a try of
    evangelisation. Web access is normal and legitimate activity and many
    people who use Plan 9 want to access the web and the thing is that it
    really does not make any sense to write web browser from the ground
    up, if there is a workable version. And it does not mean that people
    would use other system instead. So, the initial solution was to use
    VNC, it implies network. Now, linuxemu allows to get the result
    locally. It is elegant, because you put development effort in one
    place and you get many applications work.

  19. Re: Building GCC

    On Jan 24, 9:24 pm, lu...@proxima.alt.za wrote:
    > > i realize there are holes around the edges. i don't see how to
    > > edit or select a layout, just the text within layouts. maybe
    > > select skips non-text bits.

    >
    > > what's so wrong about this idea?

    >
    > Nothing, you need to think out of the box. Current selection in
    > sam/acme is linear, even though it is shown as two-dimensional. Text
    > is treated as linear (might explain why HTML tabels are treated with
    > contempt) even though it has some two-dimensional properties, at least
    > on the screen or on paper.
    >
    > For layouts (I'm pretty ignorant here, please excuse any blunder I may
    > utter), you need at least as many dimensions as occur in the
    > representation, one is not a practical option, two would be normal,
    > more will no doubt be possible in the future. My gut feel is that
    > once one breaks away from the linear interpretation of text, a lot of
    > things will fall into place.
    >
    > One thought is that vertical font sizes are an additional dimension,
    > while images are merely single characters with unusual height and
    > width. The horizontal character size is in the first dimension, of
    > course.
    >
    > As for mark-ups, they require their own treatment, probably along the
    > lines of living in a separate layer as would be the case in image
    > editing. Using layers seems to me like a good concept to edit
    > enhanced text. Perhaps horizontal and vertical dimensions also belong
    > in layers distinct from the abstract text.
    >
    > Just a naive idea...
    >
    > ++L


    Treating image as character (with unusual width and height) means
    indefinite number of potential characters and if a machine (not human)
    does not able to differentiate between "text characters" and "image
    characters" it renders character sets unusable.

  20. Re: Building GCC

    On Jan 24, 8:23 pm, pietr...@mac.com (Pietro Gagliardi) wrote:
    > And then we can have raw images as filenames, raw images in plain
    > text, text as the stroke style for a line, etc. I'd like raw images
    > in text - it makes mpictures and converting to PostScript unnecessary.
    >
    > According to the wiki page on TODO, it says htmlfmt needs knowledge
    > of tables. With this, we could just put the HTML parser and rendering
    > in acme/rio and avoid htmlfmt.
    >
    > Unfortunately, we're about 20 years too late. People have Microsoft
    > Word and they don't need an operating system with useful features,
    > automated backup at no additional cost, and a wealth of
    > documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
    > I use troff now. If you disagree, raise your virtual hands.
    >
    > Instead of debating on what's the right thing to do to add innovation
    > about 10+ years old to a system that should've had it 10 years ago,
    > let's focus on how to innovate for the future, shall we? It's not
    > that I don't like starting debates (I did start this one), but now my
    > original idea sounds unnecessary.
    >
    > I just wanted Konqueror so I could browse the whole web, but with
    > someone adding CSS to abaco and JavaScript in charon, can we merge
    > them or add JavaScript to abaco or something? I don't know anymore.
    > If you need me, I'll be adding tables to htmlfmt.


    If I were on your place, I would take a look at linuxemu. It is hot.

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast