Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM

In <20070618221022.GA17952@xxxxxxxxxxxxxxxxxxxx>, Jeremy Chadwick <koitsu@xxxxxxxxxxx> typed:
On Mon, Jun 18, 2007 at 05:15:30PM -0400, Martin Turgeon wrote:
My setup is fairly standard (as I described), should I expect problem with
64 bit version of these programs?
Like I said, I don't run 64-bit OSes because I prefer compatibility.

So you have no first-hand experience with support for 64-bit OSes.

Believe me, the instant you run into some quirky problem with either the
kernel or any of its subsystems, or a third-party program (from ports or
otherwise), the first thing you'll be told is "it works for me on i386,
have you tried i386?"
I'm sorry if this sounds condescending or combative, but it's what I
continually see on other lists.

I don't mean to sound condescending either, but I continually see "it
works for me on <change random config thing>" on other lists as
well. Linux vs. FreeBSD, 64 vs. 32 bits, LOCALBASE being something
other than /usr/local, etc. People trying to help try what you say
doesn't work. If it works for them, they'll latch on to whatever is
the most obvious thing that's different between your two systems as
the most likely cause. Sometimes they may be right, but not always.

I've found support for 64 bit FreeBSD and the applications in the
ports tree to be nearly indistinguishable from 32 bit FreeBSD. The
developers are either responsive, and things will get fixed (or are
already fixed, and you need to update your sources), or they aren't
responsive, and you'll be stuck trying to fix it yourself. If the
developer is responsive and you are reasonably capable and willing to
do some work yourself, whether or not the developer has a 64 bit box
simply isn't an issue. If the developer isn't responsive, whether
you're running on 32 or 64 bit hardware isn't an issue either.

For applications, there have been 64 bit Unix boxes around for a long
time. Especially servers. Anything that's in serious use almost
certainly had all the 32 vs. 64 bit issues shaken out long ago.

Yeah, some things are probably so 32-bit dependent they'll never be
fixed (the X server code in tightvnc comes to mind), but there are
usually alternative solutions available. Some things are proprietary,
and aren't available (like Windows codecs). The only way to figure out
where your applications fit on the list is to try them and see.

<mike
--
Mike Meyer <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Jeff Stephenson from MS--are you out there?
    ... As I'm a developer (*not* a support person), ... to keep my real address out of the lists so that I can pick and choose what ... > Jeff--E-mail to your address bounces back. ...
    (microsoft.public.outlook)
  • SourceForge.net Sitewide update June 23rd, 2004 (fwd)
    ... Puzzle ITC provides software development services based on Open Source ... support of SourceForge.net. ... recent rolled out several other new features, ... lists. ...
    (comp.os.linux.announce)
  • Re: A convert to Apple says thanks
    ... questions in the thread "A convert to Apple needs friendly ... Clearly, Mac ... CCMP support seems to be quite a new thing and thus still quite ... > The 802.1X config panel lists these authentication mechanisms ...
    (uk.comp.sys.mac)
  • Re: Anthonys drive issues.Re: ssh password delay
    ... the equivalent of Windows 2003 in terms of release ... drivers for the Mac, latest Windows, and Linux support. ... > FreeBSD. ... I got help from the lists, ...
    (freebsd-questions)
  • Will Lombardo distribute the grid?
    ... it promotes a syndrome too loose to her unusual ... Let's smash in support of the gastric warehouses, ... There Marwan will draft the developer, ... It can especially search inland and deals our prospective, ...
    (sci.crypt)