Slashdot Mirror

the further you get away from the "standard" i386 the worse support gets. Look at Fedora Core 2 for AMD64 - mysql is 32bit...

Um, this statement is false. The mysql server and client are fully 64-bit... here's proof.

While we have dozens of distributions there is not a single 64bit Linux out there that is even close to being as full-featured as debian, fedora, redhat, mandrake,... on i386 are...

If you want something as full-featured as i386, then (aside from simply running i386) x86-64 is the best game in town, because it actually runs i386 binaries. For example, my copy of Mathematica for i386 Linux runs perfectly in Fedora 2 x86-64.

As an aside, x86-64 clearly contradicts the story summary's claim of being the "first linux distribution to offer a 64-bit top-to-bottom solution which is not a toy environment." Red Hat Enterprise 3 for AMD64 was released six months ago with a full 64-bit userspace environment, and I don't think anybody can seriously argue that RHEL3 is a "toy environment" compared to a beta gentoo-ppc64 release.

on my 64bit systems (alpha) running rh 7.1, this is not true. Upgrading is not really an option for me, and I consider them "remotely modern" because they are about 2.5 years old.

The person who submitted this Ask Slashdot question is considering buying a new AMD64 machine. Although I don't mean this in a harsh way, your own personal experience with a 2.5 year old linux distribution is not relevant to the submitter's situation, and you should not be using such experience as a basis for advice to someone in that situation.

If someone is purchasing new hardware today, it is pretty safe to say that the new hardware will be running a new operating system. To advise against the purchase based on your experiences with 2.5 year old versions of linux is, at best, not helpful.

Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.

Linking to a two year old kernel trap article is not very convincing, especially since the kernel trap article in question contains a fix for the very problem itself. I am quite sure the 2Tb limit for 64-bit platforms is fixed in Linux 2.6. The Linux LFS page dated 2004-04-21 claims that the 2Tb limit is only on 32-bit. However, I admit that I have not yet actually tried to create such a large block device.

platform does matter, how?

You take a look at this screenshot (again) and try to tell me that platform doesn't matter. The 32-bit platform on the left doesn't work, and the 64-bit platform on the right does work. That's pretty clear cut evidence to me.

Most of this post is just pure misinformation. Some of it has already been corrected in the replies. I will focus on the bits that have not yet been corrected.

Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs.

For example, cat over_2Gig_file > /dev/null will fail

I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.

Perhaps your problem is that you're not compiling your applications using the large file support API, which all modern distributions do for you whenever possible.

You will find these limitations from time to time, and rarely does the platform matter.

You take a look at this screenshot and try to tell me that platform doesn't matter.

Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).

Ironically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.

Most of this post is just pure misinformation. Some of it has already been corrected in the replies. I will focus on the bits that have not yet been corrected.

Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs.

For example, cat over_2Gig_file > /dev/null will fail

I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.

Perhaps your problem is that you're not compiling your applications using the large file support API, which all modern distributions do for you whenever possible.

You will find these limitations from time to time, and rarely does the platform matter.

You take a look at this screenshot and try to tell me that platform doesn't matter.

Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).

Ironically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.

Nonlinear history traversal -- if you mean jumping back more than one page at a time, that's been a feature since Netscape 4.0 at least. Or do you mean something else?

Sorry, I didn't really say what I meant here. What I meant to say was nonlinear site navigation, which includes of course nonlinear history navigation, but much much more.

Nonlinear means you are not limited to going backwards and forwards. I do not mean just jumping back more than one page at a time. I mean that you should be able to (among other things) view your entire browsing history as a tree and jump to any branch of it, even branches off the main line. Some of this (but not all) can be achieved in Mozilla using the History window (Ctrl-H).

I also would like to see IE adopt innovations such as site navigation tabs (as in this example). Navigation tabs are much more useful than mere navigation links, which are often off-screen or on a different page from the page you're viewing.

Are there really any tolerable programs for Linux that'd do wav-based subtitling?

Since you asked...

My subtitling guide describes how I (used to) subtitle in linux and my timing guide describes how I do wav timing.

Both of these documents are unfortunately old, and I have not had the time to update them to reflect recent improvements. For the subtitling engine I have switched to using transcode instead of mplayer, because transcode has all the features I described in the previous post, including inverse pulldown which is very important for anime! (Probably not important for finnish TV, since pulldown is an NTSC-only abomination.)

For wav timing, I still use the same basic input setup as described on my timing page, but I have written a graphical interface which allows somewhat sane editing of the script without *having* to know SQL. A preliminary version can be seen in this screenshot. I plan to release this software as well, probably at the same time I update the guide.

At the present time my Ph.D thesis takes priority, so expect to wait a few months before I get back into fansubbing mode.