Open Source the new name for crappy software



  • @bridget99 said:

    The same holds true for terminal emulation. Nobody seems willing to just use Hyperterminal, and this creates problems.

    We already knew you were the Worst Programmer On This Forum, now it turns out you're a time traveler, too!

    Please, tell us about the wonders of the past when HyperTerminal was shipped with Windows as its default terminal emulation program! And we can, in exchange, educate you on the wonders of the 21st century, where we have inventions you never imagined like automatic red light speed trap cameras, and Justin Bieber.



  • @Daniel Beardsmore said:

    I was baiting Bridget99, I wasn't expecting anyone else to offer advice

    Arse. IHBT!

    @ender said:

    BTW, I've got a newer Windows version of wget hosted here.

    Leeched, ta. Joins all those other useful command-line utils in c:\windows\local\bin.



  • @bridget99 said:

    It's not the fact that command line FTP has any particular UI that appeals to me; it's the fact that it is the default, OS-supplied program for FTP.

    That means that it's readily available, but that's not a reason to resist investigating newer and better ways of doing things (else all Windows users would be stuck on OS-provided Notepad or Wordpad and refrain from installing Word[1]). lftp is a command-line FTP client, it just provides all the functionality of the standard FTP client plus more, so I've favoured its use over the defaultOS-provided util.

    @bridget99 said:

    The same holds true for terminal emulation. Nobody seems willing to just use Hyperterminal, and this creates problems. When I'm trying to get support from the people on the other end of the connection, for example, all of those fancy, scriptable terminal emulators just create problems. They give the person on the other end of the connection the opportunity to say something like "oh... you're using Terminaut 2000... that may be the problem; in any case, we can't support it." As a result, I typically end up using Hyperterm anyway, if only to humor the people attempting to support me. This is a problem, because I have to figure out how to create all of that stupid Terminaut scripting and figure out how to recreate it in Hyperterm. This is a fantastic waste of time, and the attempt to avoid Hyperterm is ultimately unsuccessful anyway, since I end up using it.

    This isn't a problem with people not willing to use Hyperterminal, it seems more of an issue with people favouring a specific tool but not knowing it well enough to implement the process you're communicating - or end-users not using a tool that your team are familiar with - and the support conversation becomes one of a training issue than a troubleshooting/incident-resolution issue. This could be easily solved in one of two ways:

    1. Publish a list of utilities that your support team know well, and make end-users aware that if they use one of those "approved" utils then they're supportable
    2. Establish, by policy, that if the end-user decides to use their own favourite tool that's missing off the list, they can operate it well enough to acheive the goals stated by the support team and the support team isn't expected to hand-hold them through unfamiliar functionality.

    This situation is pretty common in places of higher education, and many of those that have followed the above steps have reduced their support times (and end-user frustration) greatly. Without establishing some common ground, you're almost dictating that an end-user is forbidden to use PuTTY because the support team may not be familiar enough with it. Although that may be the reason, it should be communicated in ways that set a level playing field for all parties involved.

    @Daniel Beardsmore said:

    Wait … you build software that talks to ftp.exe? Seriously? That's not even a good attempt at trolling.

    I write scripts that rely on the presence of other system utilities (grep/sed/awk/cat/et) but I don't think that's what he means...



  • @Cassidy said:

    Arse. IHBT!

    I see you've responded to Trollet99 as well … it’s not your day today :)

    @Cassidy said:

    @ender said:

    BTW, I've got a newer Windows version of wget hosted here.

    Leeched, ta.

    Ditto. I see that my copy of wget Win32 was rather out of date as well.



  • @Daniel Beardsmore said:

    Wait … you build software that talks to ftp.exe? Seriously? That's not even a good attempt at trolling.
     

    I will never use the ftp.exe scripting feature ever again, just because you say so.


  • @Cassidy said:

    I write scripts that rely on the presence of other system utilities (grep/sed/awk/cat/et) but I don't think that's what he means...

    You sure? I've had to deal with two graphical applications that farmed out FTP uploads and downloads to ftp.exe, and naturally it was hopelessly unreliable. The developer has since swapped to Chilkat FTP library for VB (!), giving him reliable programmatic control over FTP operations.



  • @Daniel Beardsmore said:

    I see you've responded to Trollet99 as well … it’s not your day today :)

    I pride myself on having lurked in these forums to get an idea of poster personalities.. it's clear my powers of observation leave a lot to be desired!

    @badcaseofspace said:

    I will never use the ftp.exe scripting feature ever again, just because you say so.

    Erm.. that's not writing software that uses ftp.exe, that's popping commands macro-like into a file that the FTP client will use. Not quite the same, methinks. 



  • Open source isn't all bad. Open Source Software certainly has its gaping holes and I see only one setup that really works - An open source ('community') variant backed by a supported variant. Fixes are paid for by licensed users in the supported version and those fixes are flushed irregularly to the community version. The other way around is also true; fixes are done by the community to the open source version which then get flushed to the licensed version. This creates a healthy support cycle in which everyone benefits and money is still made. Companies like Red Hat do that very well.

    The other side of the fence is open source libraries, which I will always prefer to closed source libraries. Not only do you have code available for debugging purposes, but such environments are driven by developers (the target audience), source repositories and bug tracking software; a very powerful trio indeed. This is where open source really shines IMO.



  • That's only true if the developers actually pay attention to their bug tracker. Which way too many open source developers don't do.



  • I feel that stems from behavioural and organisational issues:

    • behavioural because many coders want to be creative, they want to work on new and exciting things, rather than have to wade through someone else's code and fix borked things (unless you're snoofle)
    • organisational because all participants in any opn-source project form a great communal resource that can benefit from a management team who allocates resources to where they can be best utilised (perhaps 80% coding new things, 20% bug-hunting and problem resolution).
    The latter is quite important in the perception of the product: people often judge not by how good it is, but how bad it is - 90% of success can be overlooked simply by the 10% failure.


  • @DescentJS said:

    That's only true if the developers actually pay attention to their bug tracker. Which way too many open source developers don't do.

    Yup. Even the big name open source projects with corporate sponsorship (like Chromium) never read their fucking bug tracker.

    I actually have a lot of respect for Mozilla, not because I give a shit about their products or think they're making good strategic decisions, but because whenever I report a bug there it actually gets read within a couple days, and if it's a violation of the DOM spec (which Firefox has shitloads of-- everybody's so obsessed with CSS nobody's QAing DOM), they'll actually turn-around a fix pretty quick. Example. Hell, they even sent me a t-shirt for that one.

    It's still fucking inexcusable that they had a extremely basic DOM bug in the product in 2010. But at least it was resolved quickly.



  • @Cassidy said:

    @Helix said:

    THAT IS MY POINT - they are broken on the filezilla web page

    Okay.. well.. given that from your post I couldn't distinguish between links manually added versus quoted content containing broken links - and there was nothing more added to put it into context - I'm afraid your point wasn't too clear to me (or someone else, it seems).

    Thanks for clearing that up.

     

     

    No problem, welcome to quotes " " " they are used for quotations, for when you want to quote stuff in general.

     



  • @DescentJS said:

    That's only true if the developers actually pay attention to their bug tracker. Which way too many open source developers don't do.
     

    That would be a good reason to not use their products. I've actually seen one instance where a user gave a detailed bug report and the answer to it was simply this: "So?"

    I have grown the habit of poking around for documentation and support sites before I choose to use something. Especially bug trackers are a valuable source of information and can give a good idea of how stable the product is right now but even more importantly, how much security you have that the product is going to stay stable; lots of regression fixes for example is a big sign that both the development team and the release management process is disorganized and thus a huge red flag.



  • This thread makes me think of Android's built-in music player.


Log in to reply