[Mark]

No reason to switch at all, turgid. Standard 32-bit Bodhi can make use of all the ram you have. As I say, most people (because of advertising) are drawn to numbers -- the higher the better (unless it's the cost of petrol or your home heating bill ).

I'm running my HP G60 with 4 GB ram on 1.0.0 just fine. Runs like a scalded dog. (Ugly imagery, that, but a rural phrase from my childhood.)

The real speed demons with 6 or 8 GB ram can always "man up" and install the PAE extensions on their own until a high-quality 64-bit's available. No way I'm going to release anything of lesser quality than the work Jeff has gone to -- the Bodhi brand demands that much from my own sense of what's quality/what's not.

Very few (of any) driver issues exist anymore for a pure 64-bit system. In fact, that's one reason Slackware too until '09 to release its 64-bit system. Until 64-bit became pretty much pure commodity hardware and Adobe, for instance, began releasing a testing 64-bit Flash, most people's experience would have been compromised. And it took Eric Hameleers to build Slack's 64-bit from scratch to show Pat Volkerding that it was time for a 64-bit Slack in terms of benchmarked gains over 32-bit.

Don't let speed gains fool you, though. We're talking about a 30%, perhaps 40% gain at most (which isn't noticeable, really, unless you're doing a massive compile or other proc-intensive task) and for gamers or multimedia editing, you have to have a really good video card to notice a gain.

For an off-the-shelf lappy or box you didn't custom build with higher-end parts...not so much a difference.

Plus, the size of the install disk is larger even with the exact same programs on it because an identical 64-bit program are simply physically larger than its 32-bit brother. Because it's 64-bit & you need more of what we call "headroom" as well.

Long answer, but point everyone who says, "But you don't have a 64-bit yet! Waaaaa!" here.

The same thing's true with dual-cores and more. Your average program really isn't compiled to take advantage of SMP in its full glory (for one thing, it really does mean having to expand your coding skillset) of 2 and 4 and more (!) cores these days.

And that, as they say, is that.

[turgid]

thank for clearing that up Mark. greatly appreciated.

[Jose]

64 bit just makes life easier if u have a lot of RAM and testing applications... but its a developer thing. Users shouldn't really have a need to update...

[Mark]

General news after a couple of weeks: first, work's started on the package manager. I follow the Andy Hertzfeld model of programming, which is to rough out something, test it, add a bit more functionality and clean up after yourself some, test it again...add a bit more...what I call a mouse circus approach. Chaotic looking from the outside, but darned if it doesn't garner results.

Building a package manager's as much art as engineering. Looking back at design decisions for pm's written a decade, a decade-and-a-half ago plus in the context of the time is a whale of an education. If there's not a CS course on the history, design and implementation on package managers somewehere, there should be. And taught by somebody who's been involved in it...not some purely academic instructor. Huge difference, that.

Look for the next update in about 2 1/2 to 3 weeks. Merrily we roll along....

[jarope]

turgid,

As far as I know with low memory there is little point changing.

Cant answer re the drivers.

jarope

[meanpt]

Mark, on 27 March 2011 - 03:25 PM, said:

Very few (of any) driver issues exist anymore for a pure 64-bit system. In fact, that's one reason Slackware too until '09 to release its 64-bit system. Until 64-bit became pretty much pure commodity hardware and Adobe, for instance, began releasing a testing 64-bit Flash, most people's experience would have been compromised. And it took Eric Hameleers to build Slack's 64-bit from scratch to show Pat Volkerding that it was time for a 64-bit Slack in terms of benchmarked gains over 32-bit.

... not getting it ... sometimes I read "amd64" as in ubuntu, others I read x86_64 as in fedora ... what's the difference ... well, I mean, is amd64 a multicore architecture too? Which architecture works better in a multicore? ...and ... I thought my core i3 was a dual core but, then, hardinfo tells me I have four cpu's ... two of them running at 1.33 Ghz and two at 666 Mhz ... finally, while one should expect less drivers problems if running a 64 bit os in a 64 bit architecture, one of these days I read Klaus Knoppler writing in Linux Magazine that the care put on 64 bit OS drivers's support have not been as good as on 32 bit OSs

[Jeff]

amd64 and x86_64 are the same thing today for all intents and purposes.

~Jeff

[oshunluvr]

Just to expand a bit more on this topic: Some Intel processors (like the Core i3) support hyper-threading which allows multitask processing like a quad core, but not as efficently. Another way to describe it would be you have 4 logical cores, but really only two physical ones. The end result is something on the order of 20-40% increase in processing over a non-hyper-threading but otherwise similar CPU. The true quad core will always perform better.

However - this is a 64bit thread which has little or nothing to do with the number of cores.

Two vs. Four cores = Two vs. Four simultanous processes.
32 vs. 64 bit = 32 bit wide data path vs. 64 bit wide data path (twice as much data in/out)

As far as architecture naming AMD64 and x86_64 refer to the same instruction set - only the name was changed (to promote the AMD brand name). IA64 is a separate 64 bit Intel/HP architecture for high-end server based applications.

Ultimately the real world benefits are totally dependant on actual use. I do DVD encoding and a 64 bit OS makes a huge difference when I'm doing that. But solitare runs exactly the same.

EDIT: and yes I'm waiting impatiently for a 64 bit version of Bodhi!

[meanpt]

... gentleman, thank you for this really enlightening piece of understanding knowledge ... ... now I understand where those two "hidden" CPUs came from ... heckt ... where is that 64 bit bodhi? ... despite really liking the damned paldo os (a light, fast, simple, and reliable always rolling release) the lack of some applications and hardware support has put me off of it .. not to mention the script system for installing and updating which seems to make things harder when it comes to design a package manager for it ...

[Jeff]

64bit Bodhi is a work in progress. Do not expect an Alpha release until late this year at the earliest.

~Jeff

[once]

out of topic, but is archbodhi still progress? the forum is gone?

[Jeff]

once, on 23 April 2011 - 05:16 AM, said:

out of topic, but is archbodhi still progress? the forum is gone?

Working on a news post for tomorrow afternoon that will cover questions such as this. Please hang tight till then.

~Jeff

[fore17]

To elaborate a little beat about the amd64 and the x86-64, here's a wikipedia copy/paste:

"Historically, AMD has developed and produced processors patterned after Intel's original designs, but with x86-64, roles were reversed: Intel found itself in the position of adopting the architecture which AMD had created as an extension to Intel's own x86 processor line"

"Intel's name for this technology has changed several times. The name used at the IDF was CT (presumably for Clackamas Technology, another codename from an Oregon river); within weeks they began referring to it as IA-32e (for IA-32 extensions) and in March 2004 unveiled the "official" name EM64T (Extended Memory 64 Technology). In late 2006 Intel began instead using the name Intel 64 for its implementation, paralleling AMD's use of the name AMD64."

"x86-64 is still used by many in the industry as a vendor-neutral term, while others, notably Sun Microsystems^[4] (now Oracle Corporation) and Microsoft,^[5] use x64."

So, as Jeff said above, x86-64 and amd64 is the same thing. The truth is that for Linux new comers, looking to download their first iso from DW, the terminology used by many distros may be a source of confusion, with so many different specifications.

I've though in different occasions that it could be very helpful for new Linux users, to find at the distros they chose to try, a well done sort of article/wiki, explaining these and the so many particular and specific Linux terms and operations that are unique of it.

[fore17]

meanpt, on 21 April 2011 - 09:01 AM, said:

... gentleman, thank you for this really enlightening piece of understanding knowledge ... ... now I understand where those two "hidden" CPUs came from ... heckt ... where is that 64 bit bodhi? ... despite really liking the damned paldo os (a light, fast, simple, and reliable always rolling release) the lack of some applications and hardware support has put me off of it .. not to mention the script system for installing and updating which seems to make things harder when it comes to design a package manager for it ...

I've also been with Paldo for the most part of the 2 years I'm now with Linux, and found some of the draw backs you listed, specially about the scripts failing when updates were issued. I survived that by always having two installs, just in case one of it braking, which has happened. More recently it seemed these issues were happening more often while the forum were almost not active.
Like I found myself always coming back to Paldo in the past, I start to see myself now preferring Bodhi.
For some reason, Juerg, Paldo developer did not delegate and build a board community around him, as Jeff has done here.
One day he got involved with the Vala project and there was nobody to continue to develop Paldo. When Amnon, a packager and forum moderator left to Chakra, it seems that the Paldo community has also disbanded. I still believe they will manage sometime to make of it the great distro it has conditions to be.

[Mark]

You've hit the target by your reference to a broad community, fore17. Paldo could simply be at a stasis point; it's shown what an OS built from a LFS/BLFS genesis can evolve into. Perhaps like Judd Vinet, Juerg may want to pass active development on to someone else either for a while or permanently. Someone with a passion for Paldo might even volunteer to take up the reins for a while.

Even Linus T. has written that if it hadn't been for people beginning to submit patches here and there and others requesting new features, he likely would have lost interest in Linux development a few months after its release.

Building a community is about newcomers feeling welcomed, having places where they can contribute, and leadership that can say both "great idea" and "nah -- we're not doing that" to keep everybody focused on a central vision. Pat Volkerding does a great job at that. So does Jeff.

Our package manager for the 64-bit Bodhi OS should be a huge community linchpin for us: a packaging framework with simple-enough steps so that anyone who wants to see a particular piece of software available can actually try their hand at packaging it instead of "just" requesting it. There's a reward knowing, I made that happen which can be truly satisfying.

The other community resource 64-bit will need is people spending time checking on original upstream sources for core system software. It's easy having dozens of pairs of eyes checking status for a few minutes once or twice a week on the changelog of the hundreds of utilities that don't have rss feeds. Then the folks doing core system maintenance can spend time doing maintenance. The same is true for people highly interested in security alerts. "Follow your interests" is the watchword.

Having an original OS to properly maintain will take more man-hours than upgrading already fixed packages from a parent distro. Multi-level community building begins with the alpha release. If enough people are interested in a 64-bit system succeeding, then it should. If not, then falling back to find a parent distro is the only other remaining option.

It's a gamble, but the best things in life usually are.

[ChipDoc]

Actually a lot of the crappy things in life are a gamble too. I just try to take it one day at a time. 64 bit isn't nearly as important to me as Stable, though I'll certainly participate in a community effort.

[Mark]

I agree, ChipDoc, that 64-bit's primary importance is for nonlinear video editing, video transcoding, sophisticated modeling of all sorts. I don't go back as far as the PDP-8 days, but I do go back to pre-monitor days.

I've said often enough that for the average person, 64-bit only makes a noticeable difference only because there's usually a whole lot of ram behind it. Bodhi's a speed demon on my modest 64-bit lappy and more responsive than most OSes even on my almost-5-year-old lappy with a single gig of ram.

Perspective's a huge part of it. We've experienced enough seven-to-twelve year cycles in advertising, media, politics, etc. and life to filter the important from the unimportant.

More-is-better advertising has most people thinking that 64-bit's better than 32-bit; multiple cores are better than single cores or that hyperthreading matters. Most everyday software's not optimized for any of it and true multi-core programming by itself (if you're doing it right) can be a PITA.

But folks want a 64-bit OS. Not having one available gives someone an excuse to not even look at Bodhi without prejudice, so I got it into my head that if we're going to even have a 64-bit system, we're going to make it worthy of being tagged as a Bodhi.

Whatever areas of interest you bring to the 64-bit community table will be greatly appreciated.

If anybody's still reading at this point, let me add that building the skeleton for a 64-bit OS isn't the difficult part. It's not easy, but it can be done by any moderately talented programmer given enough time.

What's difficult is looking at the ecosystem of both Linux and the userland, and deciding what's important to what degree. Should apparmor be enabled or disabled by default? You look at the apparmor wiki and read all the docs and the draft-docs and you look at which kernel you're going to be using and finally you make a decision.

It's only after having read everything directly from it's main page that you look back at all of the distros that included not only apparmor but selinux as an alternative and you see that the folk of this distro or that distro decided to go with the belt-and-suspenders option by including both. Granted, apparmor wasn't included by default in the kernel until recently, but as a developer you can't help but wonder why both options were included in a distro's base....

And that's only looking into one optional component and a Do we or Don't we choice.

Of course, having non-Linux experience helps. FreeBSD, OpenBSD, NetBSD and yes, even DragonFly BSD add another level of perspective. Digging deeper into the heart of RHEL/Fedora, Mandriva, Unity, Debian/Ubuntu, Arch, Slackware, Frugalware, Crux, and, yes, even Gentoo and thinking, That's worthwhile and That's not what we want to do makes for fascinating work.

Throw in a unique package management philosophy taking the best bits of this pm and that pm and everybody's wish list and fairly soon you have an idea of what will and won't work if it's implemented this way or that way.

What it is is a terrific real-world learning experience and -- I have to admit -- a lot of fun. But then I like being close to the core more than most folks. Probably due to having come from the old days of not only assembly programming, but having had (very, very limited) experience in direct machine code programming. Yep -- nothing but a string of ones and zeros just for the experience of doing it -- because I didn't know at the time how "needless" it was. Needless, but not pointless (from my twisted pov).

The icing on the cake is that our 64-bit community as a whole will help decide what finally constitutes a stable 64-bit release.

Considering these and hundreds of other things, it's no wonder the Big Distros have so many children.

But doing it this way's a lot of fun. And hopefully everybody now sees a bit more clearly why our original 64-bit system's some time in coming. Historically, the "average" development for a truly new system is between 6 to 18 months. From when this system started, we're looking at a good alpha having taken around seven to nine months. Not too shabby IMO.

[fore17]

Its really fascinating and a great lesson. Your writings Mark, are always an excellent reading for those who have a minimum interest on knowing the reality about how things happen and the multitude of different nuances facing someone who decides to engage himself in a project like building a distro from ground zero. Many could think that its only a mater of joining a kernel with a windowing system, add a package manager, and its done.... but that could only happen in a perfect world, or better, in a not yet foreseen future. Your writing above is a wonderful trip starting from the times of the assembly languages until the present and future, which is the 64 bit and the multi core.
I'm with you regarding a 64 bit version for Bodhi. For all the reasons you mentioned. It reminds me a phrase I've just read that's:

"I always remember - Anand Lal Shimpi - what AMD's Eric Demers once told me: the best way to lose a fight is to not show up."

[xdunlapx]

I would love to be a tester for the 64-bit bodhi. I don't know much in the way of coding but I can certainly test none-the-less. It'll be a new experience for me to try to learn another package manager (I'm used to aptitude, personally.). Will the ubuntu-based bodhi be maintained as this project goes forward or will the 64-bit ground-up version be the true bodhi experience?

[ottermaton]

Brittany, on 01 May 2011 - 05:36 AM, said:

Will the ubuntu-based bodhi be maintained as this project goes forward or will the 64-bit ground-up version be the true bodhi experience?

Ubuntu base will be supported for quite a while, though perhaps not indefinitely. See here.

cheers
mark