lubuntu-desktop team mailing list archive
-
lubuntu-desktop team
-
Mailing list archive
-
Message #01609
Re: 64-bit install?
On Fri, 4 Jun 2010 11:40:19 -0400
CAD Outsourcing <CADout@xxxxxxxxx> wrote:
> Your question opens a higher-level debate, and this is why I'm
> answering. I'd be curious to know why you "need to know" this. Did
> one of your friends argue "it's not a "true" 64bit..."?
>
> 64bit OS adds 2 main benefits:
> * memory addressing that is much much larger (so large in fact that
> your computer isn't high peformance enough to handle it),
> * and allowing 64bit applications to run - where it makes a
> difference is CAD, especially 3D solid modeling.
> *with the exception of the new intel multicore i3 i5 i7 processors,
> your computer will be SLOWER running a mix of 32bit and 64 bit
> applications (meaning, if you run 32bit Office, or ANY 32bit stuff,
> it will be slower, and you'll never get 100% 64bit apps and utils
> going - not in a free OS anyways).
I think it's very much more likely that you get a 100% 64-bit system
using a free OS, than a proprietary one, considering Exactly what is
your point here? If you run OpenOffice.org from the Ubuntu archives, as
you should be doing if you're running Lubuntu, then that's 64-bit. The
same goes for almost every other application packaged in the
Ubuntu archive and PPAs alike. This is vastly different from a
proprietary system where you download and install software from various
vendors who don't provide 32-bit versions.
>
> So, are you running a server or server farm perhaps? You wouldn't
> select Lubuntu for that anyways. In fact, I don't even know why they
> BOTHER allocating resources to maintaining a 64 bit version, when
> there is lots of bugs to iron out in the 32 bit edition.
> IMHO distros should be labeled differently, to make it clearer to
> users that your computer will probably run faster with the 32-bit
> optimised version, and that you install the 64bit only if you have
> 64bit specific applications, like a $5000 Autodesk Inventor
> software... which incidentally, DOESN'T run under Linux anyways!
> What are we left with, in 64bit under Linux? Maybe some multi-media
> editing stuff... well, there IS a 64bit Ubuntu that does just that,
> already out there.
I believe you are mistaken. All packages in the Ubuntu archive
is uploaded in source code form, and built on i386, and amd64, among
various other architectures. There is no need to BOTHER allocating
resources to maintaining a 64-bit version, because it *already* exists.
Perhaps there isn't a 64-bit ISO, but you can always install a minimal
64-bit Ubuntu base and apt-get install the rest, and voila, 64-bit
Lubuntu installation.
Also, there are many CPU-intensive applications out there that can
benefit from a 64-bit architecture. The rule of thumb is: if your CPU
can run 64-bit code, it's already not functioning at its full potential
if you run a 32-bit OS on it. You probably won't see any difference
though.
>
> Lubuntu's very reason of existence is because people don't like the
> fact that Linux has gotten bloated and is starting to slow down 3
> year old machines.
> Because on a Core2Duo and higher (like the new i3 i5 i7 multi-core
> processors), you don't feel a difference in the slightest... BUT the
> current state of this OS does make itself felt! And with a fast
> machine, after much frustration and working really hard to make it
> work, you find yourself scrambling to go back to Mint-Ubuntu,
> Ubuntu... or Xubuntu which has been around longer and does pretty
> well on slower hardware, and allows owners of faster machines that
> satisfaction of knowing their OS has less bloat.
>
> Before we devote programmer time to develop a 64bit version, which is
> in contradiction to the need this OS wants to fullfill, maybe we
> should iron out the bugs in the standard 32bit edition first. Just
> my opinion... because right now, Lubuntu is BETA at best! And I'm
> really pissed that they label it final release, and waste valuable
> resources for stuff no one needs. After all, if you have a slower
> PC, netbook, whatever, that requires Lubuntu, WHY oh WHY would you
> need, and WHAT would you do with, a 64bit version in the first place?
Because you're an owner of a faster machine and want to have the
satisfaction of knowing that your OS has less bloat? There, I just
plucked out a reason you just posted two paragraphs ago.
> Wanting to maintain too many versions before you get one version
> straight, is only bad for the distro. Hence the harsh words, because
> the Lubuntu team is really shooting themselves in the foot here...
> especially if they want canonical to endorse them one day. Get it
> right, and then see if you want to branch out in to other versions
> (especially if they go contrary to the distro's mission).
Again, I'd like to stress that Lubuntu shares Ubuntu's archives, and
uploads are made in source code form, and built *automatically* on
buildds for at least i386 and amd64 architectures (lpia is also
included in PPAs, and several other architectures are also built for,
but not all of them succeed all the time). This is not a "branch" out,
it is already there.
In fact, if you're writing code that can't be compiled on amd64 but can
be compiled on i386, then you're usually doing something wrong
somewhere in the first place. Something stupid like casting pointers
into integers and back. (Hey, I saw that kind of stupidity in the source
code of nachos, a small OS simulator made for educational purposes.)
In a nutshell: If your CPU does 64-bit, then go 64-bit. But don't
expect any great leaps in performance. Any gain in performance is
likely to be small for anything that's not CPU-intensive.
The only drawbacks you might get from 64-bit Lubuntu is.. say..
Adobe Flash, and Skype. But these two are really easy to install these
days, since there's the flashplugin-installer package in the archive,
and skype in Canonical's partner repository. And mind, these are both
proprietary software. So much for 100% 64-bit being unachievable for a
free OS.
--
Kind regards,
Chow Loong Jin
Attachment:
signature.asc
Description: PGP signature
Follow ups
References