Some of my biggest peeves about linux - Linux

This is a discussion on Some of my biggest peeves about linux - Linux ; So I was talking with someone about Linux today, and I started into a list of all the things that really bug me about it, whithout realizing just how much they bothered me. So, I decided to list them here. ...

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

Thread: Some of my biggest peeves about linux

  1. Some of my biggest peeves about linux

    So I was talking with someone about Linux today, and I started into a list
    of all the things that really bug me about it, whithout realizing just how
    much they bothered me. So, I decided to list them here.

    1) Lack of embedded resources/icons in executables.

    This is one of my biggest pet peeves. Windows has always had this, very
    basic feature... as has MacOS. Why is it that even in 2007, Linux
    applications cannot have embedded resources? Why do I have to go looking
    for icons for apps that I want in my kicker or whatever quick launcher you
    want to use? It's not like it's even impossible to do this with ELF, there
    have been several proposals for this.

    This brings me into gripe #2

    2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    quicklauncher and have an entry inserted to access it, icon and all? Why
    am I forced to use some arcane configuration applet or edit a text file for
    this basic funcationality that Windows and OSX have had for more than 10
    years? And while we're at it, why not drag and drop in the program menus
    that most DE's have as well?

    3) Why is it that, even after all these years, Desktop Environment dialogs
    and panels all still look like they're the cousin of the old AmigaOS 3.x?
    Let's compare:

    http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    http://www.gnome.org/~davyd/gnome-2-...int-dialog.png

    http://www.installationexcellence.co...s/old_save.png
    http://content.answers.com/main/cont...eet_dialog.jpg

    ----------------------

    You may think of these things as nit picks, but to me they're highly
    annoying.

  2. Re: Some of my biggest peeves about linux

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Mon, 1 Oct 2007 18:40:42 -0500,
    Erik Funkenbusch wrote:
    > So I was talking with someone about Linux today, and I started into a list
    > of all the things that really bug me about it, whithout realizing just how
    > much they bothered me. So, I decided to list them here.
    >
    > 1) Lack of embedded resources/icons in executables.
    >
    > This is one of my biggest pet peeves. Windows has always had this, very
    > basic feature... as has MacOS. Why is it that even in 2007, Linux
    > applications cannot have embedded resources? Why do I have to go looking
    > for icons for apps that I want in my kicker or whatever quick launcher you
    > want to use? It's not like it's even impossible to do this with ELF, there
    > have been several proposals for this.
    >


    dunno, hasn't bothered me, but I can see how some folks would be annoyed
    by this nit.

    > This brings me into gripe #2
    >
    > 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    > 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    > quicklauncher and have an entry inserted to access it, icon and all? Why
    > am I forced to use some arcane configuration applet or edit a text file for
    > this basic funcationality that Windows and OSX have had for more than 10
    > years? And while we're at it, why not drag and drop in the program menus
    > that most DE's have as well?
    >


    this works fine for me with Gnome, are you sure you have tried this? I
    dragged a binary from a nautilus window into the gnome panel, and it
    starts fine. What fails for you?


    > 3) Why is it that, even after all these years, Desktop Environment dialogs
    > and panels all still look like they're the cousin of the old AmigaOS 3.x?
    > Let's compare:
    >
    > http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    > http://www.gnome.org/~davyd/gnome-2-...int-dialog.png
    >


    Um, Erik? Gnome2.8 may have been released in mid september, but it was
    mid september in 2004...

    And no, they *dont't* look like old AmigaDos 3.x

    > http://www.installationexcellence.co...s/old_save.png
    > http://content.answers.com/main/cont...eet_dialog.jpg
    >
    > ----------------------
    >
    > You may think of these things as nit picks, but to me they're highly
    > annoying.


    Whining about the look of the dialogs, without exploring the various
    themes available for same, is pretty lame.

    Now granted, the clearlooks theme (OSX Aqua like) puts the three glossy
    gumdrops on the right, instead of the left side of the menu bar, but
    that's configurable.

    Of the three you mention, only one is actually valid as stated, and
    that's a piss poor hit rate Erik. Please try again.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHAZNXd90bcYOAWPYRAqQQAKC1Zcl6YL4zIX/4m1+H1ojaOPaVJgCgn3qh
    Qp+aoAVfRoUsNQhduGAK+vI=
    =bEyU
    -----END PGP SIGNATURE-----

    --
    Jim Richardson http://www.eskimo.com/~warlock
    I have seen the light. I was not impressed.

  3. Re: Some of my biggest peeves about linux

    In comp.os.linux.advocacy, Erik Funkenbusch

    wrote
    on Mon, 1 Oct 2007 18:40:42 -0500
    <1qyn3zb84lchy$.dlg@funkenbusch.com>:
    > So I was talking with someone about Linux today, and I started into a list
    > of all the things that really bug me about it, whithout realizing just how
    > much they bothered me. So, I decided to list them here.
    >
    > 1) Lack of embedded resources/icons in executables.
    >
    > This is one of my biggest pet peeves. Windows has always had this, very
    > basic feature... as has MacOS. Why is it that even in 2007, Linux
    > applications cannot have embedded resources? Why do I have to go looking
    > for icons for apps that I want in my kicker or whatever quick launcher you
    > want to use? It's not like it's even impossible to do this with ELF, there
    > have been several proposals for this.


    An interesting request, but be careful what you ask for.
    Are you asking for:

    [1] Embedding of data within ELF executables? This is
    almost trivial; one need merely declare a data structure
    and link it in, such as:

    struct fubar {
    char * name;
    char * rank;
    char * serialNumber;
    } soldiers[5] = {
    {"Beetle Bailey", "Private", "000-00-0000"},
    {"Gomer Pyle", "Private", "001-00-0000"},
    ...
    };

    Of course such structures are generally ad-hoc, and
    hard to process by other programs.

    [2] Scanning of this embedded data by file browser tools?

    Presumably, one could declare a data structure that the
    file browser might be able to search for, with a format
    that is standardized. One could either look for a "magic
    number" within the executable itself (that's of debatable
    reliability) or, more likely, a specialized section,
    adjacent to the standard CODE, DATA, or BSS sections of
    an ELF executable -- something along the lines of DEBUG,
    maybe called ICONS or RESOURCES. man objdump for more
    information about headers.

    The program could of course use its own resources, much like
    ad-hoc data formats.

    [3] Scanning of this embedded data by arbitrary tools? This
    would require library support -- probably a good idea, generally,
    although we might already have it and are not using it.

    >
    > This brings me into gripe #2
    >
    > 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    > 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    > quicklauncher and have an entry inserted to access it, icon and all?


    Why not indeed?

    > Why
    > am I forced to use some arcane configuration applet or edit a text file for
    > this basic funcationality that Windows and OSX have had for more than 10
    > years? And while we're at it, why not drag and drop in the program menus
    > that most DE's have as well?


    And why not drag and drop arbitrary files while one
    is at it? This should clearly not be limited to mere
    executables; scripts, pictures, applets, PS and PDF
    files, HTML widglets, libraries, and Java .jar files.
    (The libraries would probably do nothing all that
    interesting, though one might extract resources therefrom.
    The .jar files would have to be associated with some sort
    of clustering mechanism, but Linux can be easily modified
    to run .class files, and probably could look for PKZIP
    archives as well.)

    The Konqueror and Nautilus applications would of course
    look at their respective configuration systems to determine
    what tool to run when.

    See all this in more detail below.

    >
    > 3) Why is it that, even after all these years, Desktop Environment dialogs
    > and panels all still look like they're the cousin of the old AmigaOS 3.x?
    > Let's compare:
    >
    > http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    > http://www.gnome.org/~davyd/gnome-2-...int-dialog.png
    >
    > http://www.installationexcellence.co...s/old_save.png
    > http://content.answers.com/main/cont...eet_dialog.jpg
    >
    > ----------------------
    >
    > You may think of these things as nit picks, but to me they're highly
    > annoying.


    They are not nit picks, but fundamental issues with
    the look and feel of both KDE and Gnome, which strongly
    need to be refreshed. KDE in particular needs to support
    semitransparent widgets in its title bar (akin to the red
    "x" in Vista); these should be skinnable, and ideally
    movable (in other words, if I want that "x" in the lower
    left hand corner, I should be able to put it there).
    The support thereof should not be that difficult, as
    semitransparent PNG support has long since been available.
    I'd have to look regarding X extensions, but that might
    not be a big issue. Ideally, a semitransparent title
    bar would show exactly what's underneath it -- including
    other windows and moving backgrounds. In practice, I
    might expect lag.

    Gnome has similar issues. The print dialog in particular
    offers a list form; an icon form should also be available.
    Either form would furthermore require dropdowns --
    hover over a printer, see its general characteristics
    such as single- or double-sidedness, b/w or color, paper
    tray size, general readiness. One should also be able
    to search through a list of printers for those matching
    any of these characteristics. The printer icons might
    mutate based on some of these characteristics (e.g.,
    a color printer might have a little colorwheel on it).

    The file dialog should have the ability to show the free
    space for all known mounted volumes and for all dynamically
    mountable volumes (if the system can detect a floppy or USB
    stick system, it should scan it, check it, display it --
    such might have to be done outside of the requester proper,
    using an automounting tool). If an inserted CD is audio it
    should display that fact, and show the audio tracks, ready
    to play or possibly even rip, depending on application (for
    most applications, they might not care). DVDs with video
    should have similar capabilities. Note, again, that this
    should be *within the standard dialog*, not the application
    using it (though ideally the application should be able
    to extend the dialog if it wishes). Additional info could
    be presented as a hover dropdown, as well. I'd have to look
    to see how audio track metadata (artist, genre, etc.)
    is stored on a CD or DVD.

    The file dialog should show all known shares -- these
    can be CIFS/SMB, which is a de facto standard, known
    NFS mounts, NFS automounts, or other such. I'd frankly
    have to look through such issues as AFS. Ideally the
    discovery thereof would be done infrequently enough to be
    non-annoying, and frequently enough to be useful. These
    would be readily distinguishable from locally mounted
    files.

    The file dialog should also support drag and drop.
    Depending on the application, a number of behaviors are
    possible here:

    [1] Invoke, select existing. File dialog immediately
    comes up. The user selects a file here; no drag and drop
    really required. If the user selects a file icon, the
    file manager will call the tool with that filename
    or some sort of open buffer descriptor (see #6). Unfortunately,
    because of Unix's quirks, there might be some issues here;
    the main problem is that most tools will not accept URLs
    (e.g., file:///etc/passwd). The tools might therefore
    have to be rewritten.

    [2] Invoke, select new. In most cases the file dialog is
    not an issue; the tool opens an empty window ready to go.
    (This window can be iconified; see #6, below.)

    [3] Open existing. In this case, one can either pick a
    menu or simply drag and drop a file entry from another
    application -- usually Nautilus or Konqueror, but not
    always. The application closes the file in the working
    buffer[*] and opens the new one.

    [4] Embed Existing. Same as [3], except that
    the existing buffer is not closed, but the dropped
    item is immediately incorporated thereinto via a copy.
    Note that subsequent edits to the source (see #6) will
    not affect this copy.

    [5] Reference Existing. Same as [3], though in this
    case the application would simply put a pathname into its
    working buffer. The source may or may not display the
    referenced item (e.g., one might contemplate a simple
    underlined link), but any edits to the underlying item
    must be reflected as soon as practical if it does.

    [6] Iconification. A method should be possible by which
    an editing tool's working buffer can be transmogrified
    into an icon *on the desktop* (currently, it is treated as
    any other process icon, and usually placed into the lower
    icon bar in the panel). The title of this icon might be
    e.g. "New Project -- OOWriter" or "My Stuff (Modified) --
    Scribus" or some such (the exact name is up to the tool);
    it is possible the tool managing this would *not* iconify
    itself in the standard way, but would simply vanish as a
    window, leaving only the desktop icon (probably easiest
    to have this user-configurable). If possible, the desktop
    icon should show either an icon representative of the tool,
    or a small picture of the edit buffer.

    Upon double-clicking on this icon, the window would
    reappear, ready to edit (the tool having been notified to
    deiconify and/or reconstruct its window). Note that this
    icon would *not* be represented by a visible file in the
    user's Desktop directory, if one were to e.g. use "ls"; it
    might be implemented via a hidden socket in a known area
    (which would admittedly be visible to "ls"), a temporary
    file in a known area, or represented as a communication
    between the file browser on a known port, and the tool
    wishing to set up the icon. Furthermore, these working
    buffers should be draggable and droppable into any tool
    supporting file input; the tool supporting the working
    buffer will do any conversions necessary. Killing the
    tool's process would cause all of its working buffer icons
    to vanish; presumably the file browser would be able
    to detect this as a broken pipe and/or closed socket.
    (Some corner cases ensue if a transfer is in progress;
    said transfers should do something reasonable sensible.)

    It is also possible that the tool's death, if controlled
    enough, might instead convert the working buffers into
    true files, sitting in the desktop; that way data might
    be recoverable if the user logs out without closing the
    tool first. It is even possible that the tool would be
    reinvoked upon login, with recovery of the working buffers.
    (There are some issues with this, especially if the user's
    home directory is NFS-mounted. One of the problems with
    Windows is the huge amount of copying needed during login
    to set up the user's desktop.)

    [7] Section iconification. In this case, the user
    highlights part of an open working buffer, and then
    drags it into the desktop and drops it. The rules for
    such snippets would be almost identical to [6], with the
    exception that the tool should be smart enough to make sure
    the snippets make sense as subsequent edits are done to the
    source buffer. It is possible to snip a snippet, creating
    another snippet; the dependency tree will flatten out in
    that case (in other words, the second snippet would not
    refer to where it came from, but instead to the originating
    buffer.)

    It is possible to drop sections onto another icon; the
    behavior in that case will depend on that icon:

    * folder: the section gets dropped into the directory
    represented thereby. Depending on user configuration,
    the directory may open, showing the new snippet.

    * supported drops: the tool supporting the icon gets
    invoked or awoken, and it might request a position
    and/or a context to handle the dropped snippet.
    The precise behavior depends on the tool.

    * unsupported drops: the snippet would simply snap
    back to the highlighted text; e.g. an audio file
    dropped into a spreadsheet icon might be rejected.

    [8] #6 and #7 should also apply to all open file requesters;
    in other words, if an application has an open requester,
    a snippet can be dropped thereinto, or a working buffer
    moved thereinto.

    [9] Open file requesters should auto-update. This
    shouldn't be that big of a problem since they already
    auto-update for files; the functionality need merely be
    extended to the working buffers and snippets.

    [10] Read-only/read-write buffer support for URLs such
    as http://..., ftp://..., and gopher://... . Ideally,
    tools should be able to transparently take those as input
    pathnames, and open them read-only, or editable but not
    saveable (unless DAV is enabled on the other side -- an
    issue beyond the scope of this diatribe proper, but the
    tool or library might be able to discern such). Note that
    the tool might not be able to update references using such
    URLs (see #5) in a timely fashion, and snippets using
    these URLs might run into the usual issues, especially
    if the Webmaster referenced thereby decides to overhaul
    his website.

    [11] Multiple selections. It should be possible to
    have multiple selections, in the sense that each window
    will allow highlight of an area. The active window will
    control X's selection token, and highlight its area in
    a distinctive way (presumably, white-on-black, if the
    window is normally black-on-white); all other windows will
    maintain their selections but use a different highlight
    method (e.g., white-on-gray). All this coloration should
    be user-configurable. If the user uses focus-follows-mouse,
    the windows will redraw appropriately. A new application
    taking the selection token will cause the loser of that
    token to redraw itself as normal -- *not* to lose the
    selection. Of course, legacy applications such as xterm
    will be exempt from some of these requirements, and
    the selection will simply vanish in that case.

    [12] Cut and paste. Ctrl/C, Ctrl/X, and Ctrl/V should be
    consistently supported across all non-legacy applications
    (xterm uses Ctrl/C for interrupts, so there are some issues
    there). Ditto for the left and middle mouse buttons.

    Admittedly, all of this is my opinion only, and there
    might be some issues with Apple and Microsoft patents.
    I'm not sure what to think about "search folders", which
    is a Vista innovation of some sort; the general idea
    is apparently to show objects matching various criteria.

    * * *
    [*] actually, the file is probably not open anyway, in
    the strict sense of a file descriptor being allocated,
    though there might be a cooperative locking protocol
    available.

    --
    #191, ewill3@earthlink.net
    Useless C++ Programming Idea #23291:
    void f(item *p) { if(p != 0) delete p; }

    --
    Posted via a free Usenet account from http://www.teranews.com


  4. Re: Some of my biggest peeves about linux

    Erik Funkenbusch wrote:

    > So I was talking with someone about Linux today, and I started into a list
    > of all the things that really bug me about it, whithout realizing just how
    > much they bothered me. So, I decided to list them here.
    >
    > 1) Lack of embedded resources/icons in executables.
    >
    > This is one of my biggest pet peeves. Windows has always had this, very
    > basic feature... as has MacOS. Why is it that even in 2007, Linux
    > applications cannot have embedded resources? Why do I have to go looking
    > for icons for apps that I want in my kicker or whatever quick launcher you
    > want to use? It's not like it's even impossible to do this with ELF,
    > there have been several proposals for this.
    >


    Because mime actually works on *NIX and we don't need embedded icons. The
    system can figure it out from the mime type, which is how any sane system
    should work. Embedding icons is a piss-poor hack thought up by a 5th-rate
    programmer because he couldn't figure out how to get metadata working on
    the sad excuse for a file system windows was hampered with for so long. My
    question is, in 2007, why do we still have anything that still expects
    graphical icons to be embedded in binary executable code?

    > This brings me into gripe #2
    >
    > 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    > 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    > quicklauncher and have an entry inserted to access it, icon and all? Why
    > am I forced to use some arcane configuration applet or edit a text file
    > for this basic funcationality that Windows and OSX have had for more than
    > 10
    > years? And while we're at it, why not drag and drop in the program menus
    > that most DE's have as well?


    By "most", I assume you mean "the last couple of versions of windows and
    OSX"? Most desktops don't have that, and by most, I mean only the last few
    versions of windows and OSX actually support that. If there's enough user
    demand, then it'll get added. Until then, at least in KDE, right-clicking
    and choosing "add to task bar" doesn't seem that hard. Also, at
    least as far as windows goes, there's only one special tool bar that lets
    you drag-n-drop icons onto it to get short cuts. That would be the quick
    launcher windows toolbar. I keep it disabled, since I find that
    functionality fairly useless.

    > 3) Why is it that, even after all these years, Desktop Environment dialogs
    > and panels all still look like they're the cousin of the old AmigaOS 3.x?
    > Let's compare:
    >
    > http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    > http://www.gnome.org/~davyd/gnome-2-...int-dialog.png
    >
    >

    http://www.installationexcellence.co...s/old_save.png
    > http://content.answers.com/main/cont...eet_dialog.jpg
    >
    > ----------------------
    >
    > You may think of these things as nit picks, but to me they're highly
    > annoying.


    Those are real pretty screen shots. Too bad the underlying OS is a piece of
    crap. And if I want prettier dialogs, all I have to do is change my theme.
    Hint: that's to be expected when function is emphasized over appearance,
    and when I control the OS, rather than the OS controlling me. So I suggest
    you run along and go back to drooling over Aero, or whatever it is you do
    when not trolling here. Or hey, if it really bothers you that much, write
    some new code for QT or GTK and make those pretty dialog boxes that seem to
    be so important to you.

    --
    "This rudderless world is not shaped by vague metaphysical forces. It is
    not God who kills the children. Not Fate that butchers them or Destiny
    that feeds them to dogs. It's us. Only us." - Rorschach, Watchmen

  5. Re: Some of my biggest peeves about linux

    In article <4701b64c$0$32523$4c368faf@roadrunner.com>,
    Rob Hughes wrote:
    > > This is one of my biggest pet peeves. Windows has always had this, very
    > > basic feature... as has MacOS. Why is it that even in 2007, Linux
    > > applications cannot have embedded resources? Why do I have to go looking
    > > for icons for apps that I want in my kicker or whatever quick launcher you
    > > want to use? It's not like it's even impossible to do this with ELF,
    > > there have been several proposals for this.
    > >

    >
    > Because mime actually works on *NIX and we don't need embedded icons. The
    > system can figure it out from the mime type, which is how any sane system
    > should work. Embedding icons is a piss-poor hack thought up by a 5th-rate


    How does the system know the MIME type of some random executable?

    And how does the system know what icon is associated with that MIME type?

    > programmer because he couldn't figure out how to get metadata working on
    > the sad excuse for a file system windows was hampered with for so long. My
    > question is, in 2007, why do we still have anything that still expects
    > graphical icons to be embedded in binary executable code?


    What sets up this metadata of which you speak? How do I preserve it
    when I copy an application to a different system via scp?

    --
    --Tim Smith

  6. Re: Some of my biggest peeves about linux

    In article ,
    The Ghost In The Machine wrote:
    > >
    > > 1) Lack of embedded resources/icons in executables.
    > >

    ....
    > An interesting request, but be careful what you ask for.
    > Are you asking for:
    >
    > [1] Embedding of data within ELF executables? This is
    > almost trivial; one need merely declare a data structure
    > and link it in, such as:

    ....
    > [2] Scanning of this embedded data by file browser tools?

    ....
    > [3] Scanning of this embedded data by arbitrary tools? This
    > would require library support -- probably a good idea, generally,
    > although we might already have it and are not using it.


    Why require GUI executables to be single files? Make them directories
    that contain the program code, plus GUI resources, including icons.
    That's how NeXT did it, and that's how OS X does it for most apps.
    Basically, if you have a directory named foo.app, and that directory
    contains certain specific files, then the GUI shows that directory as an
    application named "foo". Open it, and it launches the application
    (executes a specific executable within the directory).

    I don't know if that specific executable actually has to be compiled
    code, or if it could be, say, Perl or Python. I have seen applications
    that include jar files in the .app directory, and the executable that
    the system launches seems to just be a wrapper that starts Java.

    The .app directory can contain all kinds of things the application
    needs. That can be somewhat surprising at times. I saw a document on
    my system with an icon I didn't recognize. I brought up the "open with"
    context menu, to see what the default application was for this
    document--it was Opera. That was odd, I thought, because I had not
    installed Opera! Out of curiosity, I tried to open the document--and
    Opera launched.

    A little investigation showed that Adobe Help Center actually includes
    inside its .app directory a copy of Opera, which it apparently uses as a
    document viewer.

    --
    --Tim Smith

  7. Re: Some of my biggest peeves about linux

    Erik Funkenbusch :
    > So I was talking with someone about Linux today, and I started into a list
    > of all the things that really bug me about it, whithout realizing just how
    > much they bothered me. So, I decided to list them here.
    >
    > 1) Lack of embedded resources/icons in executables.
    >
    > This is one of my biggest pet peeves. Windows has always had this, very
    > basic feature... as has MacOS. Why is it that even in 2007, Linux
    > applications cannot have embedded resources? Why do I have to go looking
    > for icons for apps that I want in my kicker or whatever quick launcher you
    > want to use? It's not like it's even impossible to do this with ELF, there
    > have been several proposals for this.


    I'm not sure I understand what exactly this gripe is. Is it that each
    executable shows a particular icon automagically as the icon itself is
    part of the executable? I think that the highly modular nature if the
    Linux beast would frown on that.

    > This brings me into gripe #2
    >
    > 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    > 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    > quicklauncher and have an entry inserted to access it, icon and all? Why
    > am I forced to use some arcane configuration applet or edit a text file for
    > this basic funcationality that Windows and OSX have had for more than 10
    > years? And while we're at it, why not drag and drop in the program menus
    > that most DE's have as well?


    Um, i sorta have that already so I dont know what this gripe is about.
    I'm using Slack 12 with Dropline gnome and I can right click anything in
    the menu and select 'Add launcher to desktop/panel', and then drag and
    drop it where I want it. I know thats not dragging and dropping, but
    doesn't this functionality suit your needs? Do you have a right mouse
    button?

    > 3) Why is it that, even after all these years, Desktop Environment dialogs
    > and panels all still look like they're the cousin of the old AmigaOS 3.x?
    > Let's compare:
    >
    > http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    > http://www.gnome.org/~davyd/gnome-2-...int-dialog.png


    Weird. http://www.websterscafe.com/pd.png

    My printer dialog looks much different. You can change that y'know.

    > http://www.installationexcellence.co...s/old_save.png
    > http://content.answers.com/main/cont...eet_dialog.jpg


    http://www.websterscafe.com/db.png

    > ----------------------
    >
    > You may think of these things as nit picks, but to me they're highly
    > annoying.


    And highly changeable.

    --
    Absolutely nothing should be concluded from these figures except that
    no conclusion can be drawn from them.
    -- Joseph L. Brothers, Linux/PowerPC Project)

    http://www.websterscafe.com

  8. Re: Some of my biggest peeves about linux

    Handover Phist wrote:

    What Rob said. MIME just works under Linux.

    > > 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    > > 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    > > quicklauncher and have an entry inserted to access it, icon and all? Why
    > > am I forced to use some arcane configuration applet or edit a text file for
    > > this basic funcationality that Windows and OSX have had for more than 10
    > > years? And while we're at it, why not drag and drop in the program menus
    > > that most DE's have as well?

    >
    > Um, i sorta have that already so I dont know what this gripe is about.
    > I'm using Slack 12 with Dropline gnome and I can right click anything in
    > the menu and select 'Add launcher to desktop/panel', and then drag and
    > drop it where I want it. I know thats not dragging and dropping, but
    > doesn't this functionality suit your needs? Do you have a right mouse
    > button?


    I dunno what version of Gnome you folks are running, but 2.18.1 on this
    Ubuntu box lets me left-mouse-button drag and drop application
    launchers right off the Applications menu onto the desktop, panels,
    into drawers on panels, an from the desktop to any panel. This has also
    "just worked" for quite a while now as far as I remember (I hardly ever
    do it). For that matter I can drag and drop launchers into my mail
    client (Claws-Mail) and be given a choice whether to attach or insert
    the text in line.

    For THAT matter, I can do the same with graphics from gThumb, or mp3
    files from Amarok. I can even "Insert" a non-text file in a mail message
    and it will actually plaster binary all over the message itself if I
    feel sadistic.

    I don't really get how this is any different than Windoze drag and
    dump..??

    > > 3) Why is it that, even after all these years, Desktop Environment dialogs
    > > and panels all still look like they're the cousin of the old AmigaOS 3.x?
    > > Let's compare:
    > >
    > > http://www.kdecn.org/dot/img/vol5_355_kmplot_dialog.png
    > > http://www.gnome.org/~davyd/gnome-2-...int-dialog.png

    >
    > Weird. http://www.websterscafe.com/pd.png
    >
    > My printer dialog looks much different. You can change that y'know.


    Indeed, my print dialog looks completely different.

    >
    > > http://www.installationexcellence.co...s/old_save.png
    > > http://content.answers.com/main/cont...eet_dialog.jpg

    >
    > http://www.websterscafe.com/db.png
    >
    > > ----------------------
    > >
    > > You may think of these things as nit picks, but to me they're highly
    > > annoying.

    >
    > And highly changeable.


    Second that also.


    >



  9. Re: FUD, fresh from the oven ...

    Erik Funkenbusch wrote:

    > So I just got the latest FudPack from Microsoft and I'd just like to

    seed COLA with some, with a little help from all you troll feeders who
    ignore positive Linux advocacy but have loads of time for fuddie and
    chums ..

    This brings me into gripe #4

    Why is it there is no Drag and Drop for viruses like there has been in
    Windows since v 3.11. Why can't I execute a virus by opening an e-mail
    or clicking on a Web Link, come on you COLA nuts, do my homework for me
    ......

  10. Re: Some of my biggest peeves about linux

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Tim Smith wrote:

    >>> 1) Lack of embedded resources/icons in executables.
    >>>

    > ...
    >> An interesting request, but be careful what you ask for.
    >> Are you asking for:
    >>
    >> [1] Embedding of data within ELF executables? This is
    >> almost trivial; one need merely declare a data structure
    >> and link it in, such as:

    > ...
    >> [2] Scanning of this embedded data by file browser tools?

    > ...
    >> [3] Scanning of this embedded data by arbitrary tools? This
    >> would require library support -- probably a good idea, generally,
    >> although we might already have it and are not using it.

    >
    > Why require GUI executables to be single files?


    Why indeed.

    > Make them directories that contain the program code, plus GUI
    > resources, including icons. That's how NeXT did it, and that's how OS
    > X does it for most apps. Basically, if you have a directory named
    > foo.app, and that directory contains certain specific files, then the
    > GUI shows that directory as an application named "foo". Open it, and
    > it launches the application (executes a specific executable within the
    > directory).


    That's not really all that different from how Linux and other *nix
    systems organize files. Only difference is that the organization is
    based on what the specific files do, not what application they belong
    to. With a decent package management system, the difference is
    effectively nothing more than philosophical. Also, I know of no
    mainstream distributions that don't also pack in the required
    configuration to add the application to the relevant menu.

    > I don't know if that specific executable actually has to be compiled
    > code, or if it could be, say, Perl or Python. I have seen
    > applications that include jar files in the .app directory, and the
    > executable that the system launches seems to just be a wrapper that
    > starts Java.


    Well, JAR files *are* essentially executables (especially when using the
    miscellaneous binary format interface), in much the same way a script
    is.

    > The .app directory can contain all kinds of things the application
    > needs. That can be somewhat surprising at times. I saw a document on
    > my system with an icon I didn't recognize. I brought up the "open
    > with" context menu, to see what the default application was for this
    > document--it was Opera. That was odd, I thought, because I had not
    > installed Opera! Out of curiosity, I tried to open the document--and
    > Opera launched.
    >
    > A little investigation showed that Adobe Help Center actually includes
    > inside its .app directory a copy of Opera, which it apparently uses as
    > a document viewer.


    How horribly inefficient.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHAhfsd1ZThqotgfgRAlFkAKC5WQlQ2N1bmme95Pp69l T9JZsXJQCgx1Y6
    jzGB/MxEjCYD04JKy0qqw5k=
    =qOX5
    -----END PGP SIGNATURE-----
    --
    PeKaJe
    He left the unspoken question hanging in the air. How /did/ one
    annoy a two-kilometer-long black rectangular slab? And just
    what form would its disapproval take? -- 2010, Arthur C. Clarke

  11. Re: Some of my biggest peeves about linux

    In comp.os.linux.advocacy, Tim Smith

    wrote
    on Mon, 01 Oct 2007 21:32:50 -0700
    :
    > In article ,
    > The Ghost In The Machine wrote:
    >> >
    >> > 1) Lack of embedded resources/icons in executables.
    >> >

    > ...
    >> An interesting request, but be careful what you ask for.
    >> Are you asking for:
    >>
    >> [1] Embedding of data within ELF executables? This is
    >> almost trivial; one need merely declare a data structure
    >> and link it in, such as:

    > ...
    >> [2] Scanning of this embedded data by file browser tools?

    > ...
    >> [3] Scanning of this embedded data by arbitrary tools? This
    >> would require library support -- probably a good idea, generally,
    >> although we might already have it and are not using it.

    >
    > Why require GUI executables to be single files?


    Executables already have DLLs, both CLI and GUI. The main
    culprit: /lib/ld-2.5.so .

    > Make them directories


    I'd prefer archives. The kernel might be able to process
    directories, but it's probably easier to decode a format
    from a single file.

    Windows in particular has a format that it has been using
    for decades, a modified Intel PE format. While Linux probably
    wouldn't want to use this format (too machine-specific), it
    could probably add sections to ELF for the new data, consisting
    of icons and such, if Linux wants to go that route.

    Of course, if one needs GUI resources in a directory,
    Linux has that capability already: /opt/package/whatever.
    I do not know if the /opt/package subdirectory structure
    has been standardized or not, but a number of packages
    put stuff in there.

    Another possibility is
    /usr/X11R6/lib/X11/app-defaults/Myapplication,
    where Myapplication is the name of one's application.
    (The X11R6 is now deprecated; it is a symlink to '.' .)
    There are other pathnames available, though I'm not sure
    now where they are documented in Xt Intrinsics. There
    are provisions for user customization and internationalization,
    that much I know. This file is a little limited; it's basically
    expr: value pairs, where expr: is a wildcard dotted expression.
    For example, in the XTerm file one sees lines such as

    *vtMenu*autowrap*Label: Enable Auto Wraparound

    The good news: one can specify pathnames to other resources here.
    The bad news: no one uses Intrinsics anymore, except Motif.

    > that contain the program code, plus GUI resources, including icons.
    > That's how NeXT did it, and that's how OS X does it for most apps.
    > Basically, if you have a directory named foo.app, and that directory
    > contains certain specific files, then the GUI shows that directory as an
    > application named "foo". Open it, and it launches the application
    > (executes a specific executable within the directory).


    There is the risk of losing the directory; Xt Intrinsics in
    particular defines fallback resources, which are hardcoded
    in the application proper. The fallbacks implement basic,
    barely-usable functionality.

    >
    > I don't know if that specific executable actually has to be compiled
    > code, or if it could be, say, Perl or Python.


    Perl or Python would be processed using interpreters,
    as would Bash, Tcl/Tk, and (to some extent) Java.

    > I have seen applications
    > that include jar files in the .app directory, and the executable that
    > the system launches seems to just be a wrapper that starts Java.


    A straightforward implementation, yes. With IBM's SWT
    one might even get an app that looks reasonably close to
    native, as well -- on Windows and OSX as well as on Linux.

    >
    > The .app directory can contain all kinds of things the application
    > needs. That can be somewhat surprising at times. I saw a document on
    > my system with an icon I didn't recognize. I brought up the "open with"
    > context menu, to see what the default application was for this
    > document--it was Opera. That was odd, I thought, because I had not
    > installed Opera! Out of curiosity, I tried to open the document--and
    > Opera launched.
    >
    > A little investigation showed that Adobe Help Center actually includes
    > inside its .app directory a copy of Opera, which it apparently uses as a
    > document viewer.
    >


    Wasteful, though not totally unreasonable. If one already
    has Opera one now has two copies of Opera to manage.

    --
    #191, ewill3@earthlink.net
    Useless C/C++ Programming Idea #40490127:
    for(; ;

    --
    Posted via a free Usenet account from http://www.teranews.com


  12. Re: Some of my biggest peeves about linux

    On Mon, 1 Oct 2007 17:39:52 -0700, Jim Richardson wrote:

    > dunno, hasn't bothered me, but I can see how some folks would be annoyed
    > by this nit.


    It's funny that you guys bitch and moan about the "arduous" task of finding
    device drivers when you install Windows, but don't even blink about having
    to search (or create) artwork for icons.

    >> This brings me into gripe #2
    >>
    >> 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    >> 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    >> quicklauncher and have an entry inserted to access it, icon and all? Why
    >> am I forced to use some arcane configuration applet or edit a text file for
    >> this basic funcationality that Windows and OSX have had for more than 10
    >> years? And while we're at it, why not drag and drop in the program menus
    >> that most DE's have as well?

    >
    > this works fine for me with Gnome, are you sure you have tried this? I
    > dragged a binary from a nautilus window into the gnome panel, and it
    > starts fine. What fails for you?


    Interesting, I've tried this with KDE and a number of others, but I don't
    recall if I tried it with Gnome. If it works for Gnome, then mea culpa.
    Still, KDE should really provide this functionality as well.

    > Um, Erik? Gnome2.8 may have been released in mid september, but it was
    > mid september in 2004...


    Sorry, was doing a quick search. I missed that. Here's better example:

    http://www.gnome.org/start/2.20/note...omboy-sync.png
    http://www.gnome.org/start/2.20/note...references.png

    > And no, they *dont't* look like old AmigaDos 3.x


    Actually, Gnome does share a lot of UI element similarties to AmigaOS.
    Notice the font-size selector in that last image, very similar to Amiga's
    rotational selector (although it's probably closer to the MacOS dropdown
    list)

    > Whining about the look of the dialogs, without exploring the various
    > themes available for same, is pretty lame.


    It's not the graphics or the shading or the colors. It's the layouts.
    They're square and blocky with huge amounts of dead space. These are
    things no amount of theming is going to change.

  13. Re: Some of my biggest peeves about linux

    On 02 Oct 2007 10:05:30 GMT, Peter Kai Jensen wrote:

    > That's not really all that different from how Linux and other *nix
    > systems organize files.


    Hmm.. I'm not sure I understand what you're getting at. Linux and Unix
    tend to dump all executables into one of a few folders. Now, this is
    similar to the MacOS "Applications" folder, but the difference is that the
    Mac apps have their subfolders for all their non-configurable (and some
    configurable) files.

    I actually like the way OSX does things, and I think it could be easily
    adaptable to Linux.

    > Well, JAR files *are* essentially executables (especially when using the
    > miscellaneous binary format interface), in much the same way a script
    > is.


    This is a very interesting idea. You could gzip (or even shar or tar) all
    the files into a single archive with a special header (or maybe even just a
    file flag inside the archive) that differentiates it as a "package". Then,
    the shells could be modified to recognize this and execute the apps within.
    The only problem being the need to decompress the archives to run the
    application, which could negatively impact performance. The files could be
    loaded into memory though instead of saved onto disk.

  14. Re: Some of my biggest peeves about linux

    On Mon, 01 Oct 2007 22:09:01 -0500, Rob Hughes wrote:

    > Because mime actually works on *NIX and we don't need embedded icons. The
    > system can figure it out from the mime type, which is how any sane system
    > should work. Embedding icons is a piss-poor hack thought up by a 5th-rate
    > programmer because he couldn't figure out how to get metadata working on
    > the sad excuse for a file system windows was hampered with for so long. My
    > question is, in 2007, why do we still have anything that still expects
    > graphical icons to be embedded in binary executable code?


    Umm.. I think we're talking about different things. Mime can only
    differentiate file types. It would show the same icon for all
    applications. Not exactly what most people want.

    >> This brings me into gripe #2
    >>
    >> 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    >> 2007. Why can't i just drag a program from Konqueror or Nautilus onto the
    >> quicklauncher and have an entry inserted to access it, icon and all? Why
    >> am I forced to use some arcane configuration applet or edit a text file
    >> for this basic funcationality that Windows and OSX have had for more than
    >> 10
    >> years? And while we're at it, why not drag and drop in the program menus
    >> that most DE's have as well?

    >
    > By "most", I assume you mean "the last couple of versions of windows and
    > OSX"?


    No. Windows has had this since Windows 98. MacOS X has always had it.

    > Most desktops don't have that, and by most, I mean only the last few
    > versions of windows and OSX actually support that.


    No. Not true at all.

    > If there's enough user
    > demand, then it'll get added. Until then, at least in KDE, right-clicking
    > and choosing "add to task bar" doesn't seem that hard. Also, at
    > least as far as windows goes, there's only one special tool bar that lets
    > you drag-n-drop icons onto it to get short cuts. That would be the quick
    > launcher windows toolbar. I keep it disabled, since I find that
    > functionality fairly useless.


    No. You can drag and drop any file into the start menu. You can drag and
    drop any file into the quicklaunch. You can create multiple
    Quick-launchers, andywhere you want on the screen, again with drag-and
    drop. There are multiple areas in the start menu that icons can be dragged
    to (they can be pinned to the top of the start menu. They can be pinned to
    the top of the Programs Menu, they can be addeded to the 'frequently used'
    list by drag-and-drop as well.

  15. Re: FUD, fresh from the oven ...

    On Tue, 02 Oct 2007 10:34:28 +0100, Doug Mentohl wrote:

    > Erik Funkenbusch wrote:
    >
    > > So I just got the latest FudPack from Microsoft and I'd just like to

    > seed COLA with some, with a little help from all you troll feeders who
    > ignore positive Linux advocacy but have loads of time for fuddie and
    > chums ..
    >
    > This brings me into gripe #4
    >
    > Why is it there is no Drag and Drop for viruses like there has been in
    > Windows since v 3.11. Why can't I execute a virus by opening an e-mail
    > or clicking on a Web Link, come on you COLA nuts, do my homework for me
    > .....


    Daeron. You have gone too far. It is absolutely intolerable to
    manufacture quotes. This is bull****, you lying prick.

  16. Re: Some of my biggest peeves about linux

    Erik Funkenbusch wrote:

    > On Mon, 1 Oct 2007 17:39:52 -0700, Jim Richardson wrote:
    >
    >> dunno, hasn't bothered me, but I can see how some folks would be annoyed
    >> by this nit.

    >
    > It's funny that you guys bitch and moan about the "arduous" task of
    > finding device drivers when you install Windows, but don't even blink
    > about having to search (or create) artwork for icons.
    >
    >>> This brings me into gripe #2
    >>>
    >>> 2) No Drag and Drop for desktop docks/panels/kickers/etc.. Again, it's
    >>> 2007. Why can't i just drag a program from Konqueror or Nautilus onto
    >>> the
    >>> quicklauncher and have an entry inserted to access it, icon and all?
    >>> Why am I forced to use some arcane configuration applet or edit a text
    >>> file for this basic funcationality that Windows and OSX have had for
    >>> more than 10
    >>> years? And while we're at it, why not drag and drop in the program
    >>> menus that most DE's have as well?

    >>
    >> this works fine for me with Gnome, are you sure you have tried this? I
    >> dragged a binary from a nautilus window into the gnome panel, and it
    >> starts fine. What fails for you?

    >
    > Interesting, I've tried this with KDE and a number of others,


    Certainly, Erik, you have "tried this with KDE"

    Problem is, it works with KDE. Now, why am I not surprised? "Dozens of root
    exploits" anyone?

    > but I don't
    > recall if I tried it with Gnome. If it works for Gnome, then mea culpa.
    > Still, KDE should really provide this functionality as well.
    >
    >> Um, Erik? Gnome2.8 may have been released in mid september, but it was
    >> mid september in 2004...

    >
    > Sorry, was doing a quick search. I missed that. Here's better example:
    >
    > http://www.gnome.org/start/2.20/note...omboy-sync.png
    >

    http://www.gnome.org/start/2.20/note...references.png
    >
    >> And no, they *dont't* look like old AmigaDos 3.x

    >
    > Actually, Gnome does share a lot of UI element similarties to AmigaOS.
    > Notice the font-size selector in that last image, very similar to Amiga's
    > rotational selector (although it's probably closer to the MacOS dropdown
    > list)
    >
    >> Whining about the look of the dialogs, without exploring the various
    >> themes available for same, is pretty lame.

    >
    > It's not the graphics or the shading or the colors. It's the layouts.
    > They're square and blocky with huge amounts of dead space. These are
    > things no amount of theming is going to change.


    Ah yes. So you loaded a real ancient version and selected the most hideous
    theme. Figures

    My KDE for example does not look anywhere near your "examples"
    --
    What happens if a big asteroid hits Earth? Judging from realistic
    simulations involving a sledge hammer and a common laboratory frog,
    we can assume it will be pretty bad. --- Dave Barry


  17. Re: FUD, fresh from the oven ...

    Erik Funkenbusch wrote:

    > On Tue, 02 Oct 2007 10:34:28 +0100, Doug Mentohl wrote:
    >
    >> Erik Funkenbusch wrote:
    >>
    >> > So I just got the latest FudPack from Microsoft and I'd just like to

    >> seed COLA with some, with a little help from all you troll feeders who
    >> ignore positive Linux advocacy but have loads of time for fuddie and
    >> chums ..
    >>
    >> This brings me into gripe #4
    >>
    >> Why is it there is no Drag and Drop for viruses like there has been in
    >> Windows since v 3.11. Why can't I execute a virus by opening an e-mail
    >> or clicking on a Web Link, come on you COLA nuts, do my homework for me
    >> .....

    >
    > Daeron. You have gone too far. It is absolutely intolerable to
    > manufacture quotes. This is bull****, you lying prick.


    Interesting that you *never* objected to it when it was done by windows
    using scum, Erik

    And they do it *often*

    Most of the wintrolls in here have edited quotes. There are very few
    exceptions
    --
    Microsoft's Guide To System Design:
    If it starts working, we'll fix it. Pronto.


  18. Re: FUD, fresh from the oven ...

    On Tue, 02 Oct 2007 19:02:22 +0200, Peter Köhlmann wrote:

    > Erik Funkenbusch wrote:
    >
    >> On Tue, 02 Oct 2007 10:34:28 +0100, Doug Mentohl wrote:
    >>
    >>> Erik Funkenbusch wrote:
    >>>
    >>> > So I just got the latest FudPack from Microsoft and I'd just like to
    >>> seed COLA with some, with a little help from all you troll feeders who
    >>> ignore positive Linux advocacy but have loads of time for fuddie and
    >>> chums ..
    >>>
    >>> This brings me into gripe #4
    >>>
    >>> Why is it there is no Drag and Drop for viruses like there has been in
    >>> Windows since v 3.11. Why can't I execute a virus by opening an e-mail
    >>> or clicking on a Web Link, come on you COLA nuts, do my homework for me
    >>> .....

    >>
    >> Daeron. You have gone too far. It is absolutely intolerable to
    >> manufacture quotes. This is bull****, you lying prick.

    >
    > Interesting that you *never* objected to it when it was done by windows
    > using scum, Erik
    >
    > And they do it *often*
    >
    > Most of the wintrolls in here have edited quotes. There are very few
    > exceptions


    So, you condone "turnabout is fair play"?

    I don't read every message in here, nor do I read threads once they
    degenerate into troll fests. I don't see you criticizing 7 or Kent or any
    of a number of so called "advcoates" either. Yet you criticize me for not
    doing so. Why?

    I've said it a number of times. I don't feed trolls. If you and others
    ignored them, they would get bored and go away because they're only looking
    for responses.

    We're not talking about a known troller here. We're not talking about
    flatfish or linuxsux. We're talking about someone who purports to be a
    real Linux advocate who is now reduced to fabricating entire messages and
    attributing them to others.

  19. Re: Some of my biggest peeves about linux

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Erik Funkenbusch wrote:

    >> That's not really all that different from how Linux and other *nix
    >> systems organize files.

    >
    > Hmm.. I'm not sure I understand what you're getting at. Linux and
    > Unix tend to dump all executables into one of a few folders.


    Executables, yes. And the config files go in the config file folder,
    the icons in the icon folder, and the menu shortcuts in the menu
    shortcut folder.

    > Now, this is similar to the MacOS "Applications" folder, but the
    > difference is that the Mac apps have their subfolders for all their
    > non-configurable (and some configurable) files.


    Right, and in Linux all these files are placed where their function
    dictates. The difference is only philosophical, in that the end user
    should never have to find these folders in the first place (in both
    Linux and OSX).

    > I actually like the way OSX does things, and I think it could be
    > easily adaptable to Linux.


    What isn't easily adaptable to Linux? But what benefit does it bring?

    >> Well, JAR files *are* essentially executables (especially when using
    >> the miscellaneous binary format interface), in much the same way a
    >> script is.

    >
    > This is a very interesting idea. You could gzip (or even shar or tar)
    > all the files into a single archive with a special header (or maybe
    > even just a file flag inside the archive) that differentiates it as a
    > "package".


    Or just an extension, if one uses the binfmt_misc interface.

    > Then, the shells could be modified to recognize this and execute the
    > apps within.


    Binfmt_misc and a simple shell script.

    > The only problem being the need to decompress the archives to run the
    > application, which could negatively impact performance.


    For most applications, it would be a short startup delay. With an
    intelligent packing and coding, one could even make sure that the most
    vital parts are unpacked first, so the application can start to load.

    > The files could be loaded into memory though instead of saved onto
    > disk.


    Well, /dev/shm/ comes to mind. I think it would take about 15 minutes
    to implement a simple version of what you describe (and it's essentially
    what a JAR file does). I just don't think it's a particularly good
    idea, as I don't see which benefit it provides.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHAoTgd1ZThqotgfgRAtG8AJ44lF5zyVBrkTlWsJxjA0 tdMJvKSACfZ5C4
    OVMDXaPbaRcQeju0UqOtPUc=
    =PcCg
    -----END PGP SIGNATURE-----
    --
    PeKaJe

    We are Pentium of Borg. Division is futile. You will be approximated.

  20. Re: FUD, fresh from the oven ...

    In comp.os.linux.advocacy, Peter Köhlmann

    wrote
    on Tue, 02 Oct 2007 19:02:22 +0200
    :
    > Erik Funkenbusch wrote:
    >
    >> On Tue, 02 Oct 2007 10:34:28 +0100, Doug Mentohl wrote:
    >>
    >>> Erik Funkenbusch wrote:
    >>>
    >>> > So I just got the latest FudPack from Microsoft
    >>> > and I'd just like to
    >>> seed COLA with some, with a little help from all
    >>> you troll feeders who ignore positive Linux advocacy
    >>> but have loads of time for fuddie and chums ..
    >>>
    >>> This brings me into gripe #4
    >>>
    >>> Why is it there is no Drag and Drop for viruses like
    >>> there has been in Windows since v 3.11. Why can't I
    >>> execute a virus by opening an e-mail or clicking on a
    >>> Web Link, come on you COLA nuts, do my homework for me
    >>> .....

    >>
    >> Daeron. You have gone too far. It is absolutely
    >> intolerable to manufacture quotes. This is bull****,
    >> you lying prick.

    >
    > Interesting that you *never* objected to it when it was
    > done by windows using scum, Erik
    >
    > And they do it *often*
    >
    > Most of the wintrolls in here have edited quotes.
    > There are very few exceptions



    There's quote editing, and quote editing. *I* edit
    quotes to reformat the line widths (they get too wide
    after awhile); apologies in advance if I totally munge
    the meaning thereby.

    Of course, that's different from manufacturing quotes:

    * I eat dead people, with shallots

    :-)

    --
    #191, ewill3@earthlink.net -- actually, I do eat bones in Eternal Life,
    but most of those people I had to kill again, since they were skeletons
    Useless C/C++ Programming Idea #992381111:
    while(bit&BITMASK) ;

    --
    Posted via a free Usenet account from http://www.teranews.com


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