*sigh* C:\Program Files\



  • I see so many qoutes on Oracle wont install on C:\Program Files<br>
    Annyone ever tried to install it into C:\progra~1????



    I'll bet ya this will work.



    To bad Oracle just is not "clicker di click, Done!"  ;)












  • It just sucks that Oracle doesn't support spaces in folder names. This
    is legal in Windows since 1995 when the first 32-bit versions of
    Windows were marketted. So after 10 years of Windows, Oracle still
    sucks supporting this nice feature...



    And of course, because Oracle isn't a user-friendly database system,
    many people either have to hire expensive experts or they have to
    choose for easier alternatives like MS SQL, InterBase or whatever else.
    Anyway, for any system that doesn't require huge database tables, any
    other database system would just be a better option. For example, a
    company with 20 employees could even use MS Access for it's internal
    employee's database. Oracle would be overkill in that case.



    I think it always depends on what you'll need to use a database for.



  • Like it was said in other topics:

    Oracle does support spaces in names but the JAVA part in it does not..





    ( JAVA platform independant, WHA! sure.... )




  • Sure, blame Java for the fact that the installation doesn't work as it's supposed to.



    Anyway, it's a stupid choice that they decided to use Java for the
    installer anyway. If they had just used C++ like they did for all the
    other Oracle binaries (Assuming they are using C++) then the whole
    installer would have been able to support spaces in names, and better,
    it would run faster and without the need of any Java Virtual machine...



    To be honest, I HATE Java... The language is okay, but the runtime is
    crap. Even worse, some companies are even creating all kinds of Java
    applications for all kind of purposes so they are
    "platform-independant" but if I ever get such a program, I will refuse
    to use it. The Java Virtual machine has been removed from my PC and it
    will never be on it either.



    Oracle, when it is running, is performing quite nice in general, yet
    the company made a huge mistake by choosing for such a crappy
    installer...



  • @Katja Bergman said:

    Sure, blame Java for the fact that the installation doesn't work as it's supposed to.



    Anyway, it's a stupid choice that they decided to use Java for the
    installer anyway. If they had just used C++ like they did for all the
    other Oracle binaries (Assuming they are using C++) then the whole
    installer would have been able to support spaces in names, and better,
    it would run faster and without the need of any Java Virtual machine...



    To be honest, I HATE Java... The language is okay, but the runtime is
    crap. Even worse, some companies are even creating all kinds of Java
    applications for all kind of purposes so they are
    "platform-independant" but if I ever get such a program, I will refuse
    to use it. The Java Virtual machine has been removed from my PC and it
    will never be on it either.



    Oracle, when it is running, is performing quite nice in general, yet
    the company made a huge mistake by choosing for such a crappy
    installer...




    IMO, the installation does work as it should.  It's designed to be
    run on multiple OS;  not just windows.  Just because Windows
    will let you put a space in a folder name doesn't mean that Solaris, or
    Unix Sys V will.



    As an aside, I learned DBMS using Oracle.  That probably sets me
    up as being biased, but since then I've used Postgres and MySql and
    find that they both do just as well as Oracle.  I hear a lot of
    complaints, especially here, about how Oracle is so horrible, because
    it does X or X.  When I actually sit down and look up whatever X
    happens to be, I've always found it to be something that was put there
    to make some lazy morons life easier, not because it's a good
    construct.  As such, it doesn't get used. 



    I think a lot of the Oracle gripes come down to having a base
    equivalency with the language wars.  People ranting and raving
    against something they simply don't like to use, with all the opinion
    and conjecture in the world to back them up.



  • @Katja Bergman said:

    The Java Virtual machine has been removed from my PC and it
    will never be on it either.




    In my experience, laying down such hard guarantees usually lead to the exact opposite happening.



    Never say never.



  • on my current computer, I decided to put everything in "C:\Programs"
    instead, to get around problems like this. However, I've still managed
    to get caught out - some things still require 8.3 filenames >.<.



    So, next time, I'm going for "C:\bin". And yes, "C:\home" in place of
    Documents and Settings wherever possible. It may even be possible to do
    some nasty hack to make these actually work like their
    badly-named-but-more-featureful counterparts, but so far, this's proved
    sufficient.



  • Wait, "Programs" is 8.3-compatible. It's "Documents" that isn't. I
    think one of the computers here has a folder called "Document.s" for
    that very reason. (Yes, folders can have suffixes under 8.3. I
    discovered that by pure chance.)



  • @JThelen said:

    IMO, the installation does work as it should.  It's designed to be
    run on multiple OS;  not just windows.  Just because Windows
    will let you put a space in a folder name doesn't mean that Solaris, or
    Unix Sys V will.




    And your point is? Does a program that wants to support multiple OSs
    have to go down to the least common denominator? Wouldn't a proper
    program be able to use features if they are available, and not if they
    aren't?



  • @Irrelevant said:

    on my current computer, I decided to put everything in "C:\Programs\" instead, to get around problems like this. However, I've still managed to get caught out - some things still require 8.3 filenames >.<.

    So, next time, I'm going for "C:\bin\". And yes, "C:\home\" in place of Documents and Settings wherever possible. It may even be possible to do some nasty hack to make these actually work like their badly-named-but-more-featureful counterparts, but so far, this's proved sufficient.

    If Micro$oft had used shorter names in the first place none of this would've happened. M$ was just too eager to show off their new file naming convention, it seems. I have a \bin and \usr on one of the NT machines. (Search+Replaced "Program Files" with "bin" and 10 nulls, and "Documents and Settings" with "usr" and 19 nulls in all of the binaries on the system).

    I've always hated long filenames, especially ones with spaces in them. The length I don't mind, as long as it's not too long (I've seen "The Program by The Softwarecompany" as the default name of an installation directory) but spaces shouldn't have been allowed. Underscores make a suitable substitute.

    Directories shouldn't have extensions to them in 8.3 - they should've just had a maximum of 11 characters, allowing "\Documents" to exist.



  • @llxx said:

    @Irrelevant said:

    on my current computer,
    I decided to put everything in "C:\Programs" instead, to get around
    problems like this. However, I've still managed to get caught out -
    some things still require 8.3 filenames >.<.

    So, next
    time, I'm going for "C:\bin". And yes, "C:\home" in place of
    Documents and Settings wherever possible. It may even be possible to do
    some nasty hack to make these actually work like their
    badly-named-but-more-featureful counterparts, but so far, this's proved
    sufficient.

    If Micro$oft had used shorter names in the first place none of this would've happened. M$ was just too eager to show off their new file naming convention, it seems. I have a \bin and \usr on one of the NT machines. (Search+Replaced "Program Files" with "bin" and 10 nulls, and "Documents and Settings" with "usr" and 19 nulls in all of the binaries on the system).

    I've always hated long filenames, especially ones with spaces in them. The length I don't mind, as long as it's not too long (I've seen "The Program by The Softwarecompany" as the default name of an installation directory) but spaces shouldn't have been allowed. Underscores make a suitable substitute.

    Directories shouldn't have extensions to them in 8.3 - they should've just had a maximum of 11 characters, allowing "\Documents" to exist.



    Why did you use a $ in place of the S in MS and Microsoft throughout that post?

    Sincerely,

    Richard Nixon


  • I agree completely regarding the crappy Java runtime - I hate it and will never install it.

    And what's wrong with long path names?  You have a problem with a folder full of photos titled "Trip to Mexico 2005" instead of "Mex_2k5"?  Which would the home user find more readable?  I take the long file names with spaces ("Trip_to_mexico_2005"???) over an 8.3 or 11.0 format any time.

     



  • but spaces shouldn't have been allowed


    Yes they should. Spaces should not be a problem. If a program chokes on a space, it's the fault of that program. Spaces are a normal feature of filenames.

    Limiting to 8.3 is exactly the same as saying "640k should be enough for everyone." This isn't 1985 anymore. I have 2000 times as much RAM as that, and I'll damn well name my files how I want to, spaces and all.


  • i think it is a pain that some programs fail whenever i choose to rename a directory. If tomorrow i want to name "Documents and Settings" to "the place where important things are stored" it should be my choice. Why isn´t there an internal identifier for a folder and the folder name is an attribute of the folder object. The name of the folder should be just presentation. That way an OS can be truly localized. I can have

    c:\programma bestanden

    c:\documenten en instellingen

    or whatever i choose to have



  • @JThelen said:



    IMO, the installation does work as it should.  It's designed to be
    run on multiple OS;  not just windows.  Just because Windows
    will let you put a space in a folder name doesn't mean that Solaris, or
    Unix Sys V will.


    Bad choices of alternate OSen... both of those will allow spaces in directory names.  It's not widely used because it's annoying having to escape the space on the command line (and some applications can't handle it), but it can be done.

    I don't understand the appeal of using a cross-platform installer when installing platform-specific applications; if there are as many platform-specific details to work around as I suspect there are, it makes little sense to try to use a single installer.



  • @Benjamin Geiger said:

    @JThelen said:


    IMO, the installation does work as it should.  It's designed to be
    run on multiple OS;  not just windows.  Just because Windows
    will let you put a space in a folder name doesn't mean that Solaris, or
    Unix Sys V will.


    Bad choices of alternate OSen... both of those will allow spaces in directory names.  It's not widely used because it's annoying having to escape the space on the command line (and some applications can't handle it), but it can be done.

    I don't understand the appeal of using a cross-platform installer when installing platform-specific applications; if there are as many platform-specific details to work around as I suspect there are, it makes little sense to try to use a single installer.


    A cross-platform installer in this case sounds a bit like a micro-opitimization.



  • /usr (or rather, /usr/local) is fine for relatively small packages.  Oracle is not a small package.  (X11 is installed under /usr for historical reasons.)

    /opt is a newer development, and not all Unix-alikes use it.  My Linux boxen don't have an /opt and I doubt they will anytime soon.  (Of course, my Linux boxen don't run anything heavier than firewalling or Samba...)

    I agree, however, with your assessment that external programs should use the package management features of the OS.  However, each variant of Unix (and even each distribution of Linux) has a different packaging scheme.  (I'm partial to .deb, but that's just me.)  Also, Windows really doesn't have a suitable package management system.

    (Oh, and (can you (tell) (I've (been) learning) Lisp)?)



  • /opt is meant for large, self-contained packages.  Oracle is one of them.  Most stuff in your Fedora system's /usr is likely not.  Also, BSD-derived Unices are less likely to have /opt, though it's gradually becoming more common.  Personally, if I were the one who decided on the filesystem change, I would have placed it under /usr/opt just for cleanliness' sake.

    /bin should [i]not[/i] be symlinked to /usr/bin.  Ever.  /bin and /sbin contain things that are often required to get /usr mounted.  (It's extremely common to have an entire lab full of Unix workstations share a single /usr, mounted over the network.  /bin and /sbin contain things like mount and fsck that are needed before the network can be accessed.)

    I agree that packaging according to the OS is trivial for OSen that have package management systems in place (meaning most commercial Unices and many distributions of Linux) but it's less so for OSen that have either a malfunctioning package management system (Windows) or none at all (Slackware).



  • @Phince said:

    Like it was said in other topics:

    Oracle does support spaces in names but the JAVA part in it does not..





    ( JAVA platform independant, WHA! sure.... )


    Java does support long files names, and always has.

    The Oracle installer is trash. Don't blame the runtime.


Log in to reply