Upon the actual release of R6 (or sooner), will there be a 64 bit kernel and drivers? 32 bit userland is fine, even preferable. With a 32 bit kernel, though, only a little over half of my machine's RAM is usable. Plus, considerable performance boosts have been reported by people using a 64 bit kernel on 64 bit Myth boxes. 64 bit support is probably the only major feature that the other Myth distros have that LinHES doesn't (although LinHES is far better in pretty much every other aspect - I'd rather run MythTV on a toaster than use MythBuntu).

I dunno, maybe one of the devs will comment. I would think that their emphasis would be on getting R6 up to a certain level feature-wise before adding a second architecture. I dunno about the "64-bit is better" claims, but in my experience, 64-bit kernel will give you the ability to see more than 3.5 gigs of RAM and that's about it. I dunno how many of us have >3.5 gigs on our LH boxes or even if >2 gigs of memory is even needed. I have 1 gig on my SDTV box (single PVR-250) and looking back at my rrd logs, I never tapped into the swap space before.

_________________
Retired KM user (R4 - R6.04); friend to LH users.

I'm playing around with my first Xeon powered box, running 64 bit Kubuntu at the moment. It's wicked fast, but I'm concluding that it would be heat producing overkill for a Mythbox.

Last time I ran rrd on one of my HD boxes, it was keeping memory useage inside 512 meg, although 1 gb was available ... so maybe overkill looking at a lot of memory too...

And 64 bit has annoyances like 'Flashplayer doesn't support Linux 64 bit systems'.....

I would be surprised if 64 bit gave you much of a boost but I haven't analyzed how it runs with streaming.

As for memory, 32 bit kernels can access above 4GB just fine depending on the kernel of choice. I'm relatively new to the Debian/Knoppix side but on my base server I run CentOS (2.6.9 based) and as I recall, the smp kernel supports up to 16GB; the hugemem kernel up to 64GB.

The key is ensuring no single process is bigger than 4GB.

My main backend server's base has 8GB of memory (shared with many other apps). All of my front ends have 2GB or less with 512MB shared with the on board Nvidia 9300.

C

I have been using the 64 bit flash from adobe for the last month, it has been working fine. The only application I cannot really use so far is acrobat reader -- not a bit loss on a myth box.

Also, users on the mythtv-users mailing list have reported that commercial flagging is literally twice as fast in 64 bit mode as 32 bit mode.

Hmm, my machine has 4GB ram, but with the stock R6 kernel, only about 2.5GB is usable:



I've tried setting "mem=4096MB" in menu.lst, but no change. The stock kernel is compiled with CONFIG_HIGHMEM4G, so from what I understand I should at least have about 3.5GB available. I assumed it was because it was a 32-bit kernel, but maybe it's some other problem. The BIOS recognizes all 4GB, so it's not like one of the RAM sticks is bad or not inserted all the way or anything.

I personally don't think there is any need for a 64bit kernel as it moves away from the core purpose of what LinHES is about. Cecil has lamented many a time that LinHES (KnoppMyth) is an appliance, always has been, always will be.

I use 64bit Winblows at the moment and from desktop perspective it is very good, but for me I am happy with LinHES the way it is.

_________________
Girkers

Interesting. It would be very cool to have someone do a controlled experiment to test this. Often "users" on a mailing list tend to make all sorts of claims that aren't necessarily backed-up with hard data.

_________________
Retired KM user (R4 - R6.04); friend to LH users.

Really? You mean all that stuff I've been watching on this box was just my imagination?

The "no 64 bit flash support" hasn't been true for at least 5-6 months now. The Flash 10 plugin works great and I've been using it since before Thanksgiving on both the work and home workstation machines. See this page for instructions: http://nareshv.blogspot.com/2008/11/64-bit-flash-10-on-fedora-10.html

Well, for now anyway, I'm running the x86_64 ArchLinux kernel and drivers. It works great, and the system just feels a little bit more responsive, and all my RAM is available. If anyone else wants to try this, here's what I did (don't do this unless you know your way around Linux). To sum up, though, to run a 64 bit kernel, we'll only need 64 bit versions of three packages: kernel26, lirc and nvidia.

1. Download the kernel26, lirc and nvidia packages from the ArchLinux x86_64 repos (do not install with pacman! Just download the package tarballs themselves)

2. Extract the kernel26 package in a temporary directory. Move the modules and source directories to /lib/modules and /usr/src. Move the kernel itself (vmlinuz26) to /boot, but give it a different name so it doesn't overwrite your LinHES kernel. I named it vmlinuz26_64bit. You should now have the directories /usr/src/linux-2.6.29-ARCH/ and /lib/modules/2.6.29-ARCH/ and the file /boot/vmlinuz26_64bit.

3. Create an initrd for the new kernel. Run these commands (assuming you named the new kernel vmlinuz26_64bit):


4. Edit /boot/grub/menu.lst. Copy the second entry (should be labeled bootsplash), paste it at the end, and change "kernel vmlinuz26" to "kernel vmlinuz26_64bit" and "initrd /boot/kernel26.img" to "initrd /boot/kernel26_64bit.img". Change the "title" line to something descriptive like "LinHES 64 bit".

5. Extract the lirc and nvidia packages you downloaded in step 1 to some temporary directory. Extract them and copy the files within to their proper places in /lib/modules/2.6.29-ARCH.

6. EDIT: As of 5/3/09, Arch's NVIDIA drivers are at 180.51, so there is no reason to revert the LinHES packages to earlier versions. Just download the NVIDIA drivers and copy the kernel module to the correct place. I'll leave this here, though, in case the versions get out of sync again:

For now, since Arch's NVIDIA drivers are still at 180.44 and LinHES is at 180.51, you'll need to downgrade your drivers to 180.44. cd to /data/var/cache/pacman/pkg and run

Once Arch updates to 180.51, you can reinstall the LinHES 180.51 packages in the same way, then download the Arch 180.51 nvidia package and repeat step 5.

7. Run "sudo depmod -a" and reboot. Press esc at the GRUB prompt and pick your new 64 bit entry. You should see the Arch logo momentarily in the top left corner of your screen, then the LinHES splash screen should come up. If you did everything right, X should come up normally. If not, ssh in (or switch to a console) and run "depmod -a" again as root, then try rebooting again.

OK- I've got my 'imagination' going now ! Thanks !!!...



Yeah, I believed the 'don't support your system' blurb at Adobe, and didn't know about the 64 bit beta tucked away in an obscure place...
Just goes to prove that getting the job done is 90% 'knowing where the bones are buried'......

I didn't know this, is there a reason that we can't use one of these kernels OOTB with LH? I am fairly adamant about only running one server 24x7 but I need to run more stuff than just LH. So either I load up LH with extra stuff (which would require doing things I shouldn't like installing stuff from the core repos) or I run VMs, either way but esp. with the latter, I need more than 3.5GB....

_________________
Paul O'Flynn

The plan is at some point to do 64 bits.

I've gathered in the past that part of the hesitation to do a 64-bit port was that you didn't want to maintain 2 ports.
So does the switch in underlying distro mean two ports would be much easier to maintain, or does the plan to do 64 bits coincide with a plan to drop 32 bits?

I doubt they would ever drop support for the i386 architecture.

_________________
Retired KM user (R4 - R6.04); friend to LH users.