Slashdot Mirror

I realize you probably don't actually care about the origins of the phrase, but being the wordfreak that I am, I'm going to answer anyway. *grin*
Here's one result

Here's another

And yet another

They all point to Secretary of the Navy Josephus ("Joe" - get it?) Daniels.

This has been available for at least 6 months now. Sleep well.

This article links to what may be an earlier one, predating the current article numbering convention.

A Google search on the phrase "I Have A Post-Hellmouth Dream" finds plenty more.

Then Microsoft would have a seller! I've written on this before.

I don't know why Microsoft doesn't take advantage of its PC dependence and use that to keep them on the Windows platform. I mean, if you've got the capabilities in the unit, why not exploit them as much as you can? Especially in a set top unit that would be easier to maintain than a PC, but will do everything that 50% of what homes need?

Sure, there are issues with the screen display, but when it comes to balancing your checkbook, checking your on-line porforlio, writing simple letters, and a few other details that a good 50% of homes use, it's sufficient. Most of us /.'ers will still have a PC, but most home users aren't as savvy. A set-top box would be much better, since the PC is far too much more them. They just want gaming, TV recording, Internet browsing, checkbook balancing, investment tracking and writing letters -- nothing more. Heck, if it ran Quicken, I'd probably buy it (a 100% Linux user, both at work and home, for the last 4 years!).

I don't know why I'm the only one that seems to see this? I also don't know why Nokia or some other company in the TV Linux Alliance hasn't been able to team up with AT&T, the regional Bells, etc... to offer such a Linux-based "set-top box" for their cable (or, limitedly, DSL) subscribers yet. I've heard rumors, but nothing solid yet. If Microsoft wants to "take over," it should make a move on this. But, instead, it looks like they'll keep doing the "minimum required" combined with "dumping" and losing to other vendors again and again and again at a huge loss. And they probably won't wake up until someone else has a 50% marketshare with one of these devices either.

Then Microsoft would have a seller! I've written on this before.

I don't know why Microsoft doesn't take advantage of its PC dependence and use that to keep them on the Windows platform. I mean, if you've got the capabilities in the unit, why not exploit them as much as you can? Especially in a set top unit that would be easier to maintain than a PC, but will do everything that 50% of what homes need?

Sure, there are issues with the screen display, but when it comes to balancing your checkbook, checking your on-line porforlio, writing simple letters, and a few other details that a good 50% of homes use, it's sufficient. Most of us /.'ers will still have a PC, but most home users aren't as savvy. A set-top box would be much better, since the PC is far too much more them. They just want gaming, TV recording, Internet browsing, checkbook balancing, investment tracking and writing letters -- nothing more. Heck, if it ran Quicken, I'd probably buy it (a 100% Linux user, both at work and home, for the last 4 years!).

I don't know why I'm the only one that seems to see this? I also don't know why Nokia or some other company in the TV Linux Alliance hasn't been able to team up with AT&T, the regional Bells, etc... to offer such a Linux-based "set-top box" for their cable (or, limitedly, DSL) subscribers yet. I've heard rumors, but nothing solid yet. If Microsoft wants to "take over," it should make a move on this. But, instead, it looks like they'll keep doing the "minimum required" combined with "dumping" and losing to other vendors again and again and again at a huge loss. And they probably won't wake up until someone else has a 50% marketshare with one of these devices either.

I'm sorry if I'm being a bit dense here, but nowhere in this message can I find anything suggesting RedHat is going forward with x86-64.

All I see is a (good) suggestion for altering the current set of RedHat install CDs to allow for processor-specific optimisations in the kernel/system binaries. There is mention of how this would carry through into x86-64 support, but this is just a suggestion from someone outside RedHat.

As a fellow ECE, I'll give Intel a mark in the "innovative" column on IA-64. But the concepts of predication, EPIC and compiler-time optimizations we're NOT good enough to even make the new architecture competitive when not considering x86 compatibility. And Intel needs to be smacked for all those stupid extensions -- it's funny to see AMD accomodating them with less effort than Intel.

Alpha has always been the "64-bit RISC of RISCs" and they had binary translation techology c/o FX!32 so Linux/x86, NT/x86 and VMS/VAX apps could run on Linux/Alpha, NT/Alpha and VMS/Alpha, respectively. It was not only original, but using binary translation on the same OS, but different architecture, works far better for compatibility in software than general (any OS) architectural compatibility in hardware/microcode! With Alpha 364 at 0.13um would be kicking IA-64 butt. I mean, 3-year old Alpha 264 0.25um processors beat IA-64 at the same clock speeds!

Anyhoo, as a fellow EE/ECE, please read this post I made a few weeks ago and let me know what you think. It is entitled "How AMD and its partners are putting x86 back on the right track ... ". IA-64 was an ideal and novel concept, one that is not so good based in reality where good branch prediction is better than predication, and run-time optimization is just as important as compile-time. The Alpha 364 team predicted the "problems" with IA-64, which came true.

From: Richard Morrell
Sent: Saturday, September 22, 2001 2:58 PM
To: Wright, Corey
Cc: users@
Subject: Re: [users] What kernel source and distro-base?

DONT

If you think you have something to add use your brain

Come talk to the team

QoS is so so so unneeded.

You will get fuck all help from us dude

Richard Morrell, project manager and founder - SmoothWall
Technical Director - Caveonet Ltd

On Fri, 21 Sep 2001, Wright, Corey wrote:

> What kernel source (plus patches) and distribution (if any) is 0.9.9 based
> on?
>
> I'm wanting to add QoS capabilities to SmoothWall using kernel modules
> (sch_*), the tc application, and a script borrowed/modified from LRP
> sec-EtherToEtherFiles.html>.
>
> I know from looking at the smoothwall-0.9.9-kit.tar.gz tarball that the
> kernel config's are included in that and that the kernel was 2.2.19, but
> what kernel source was used (stock, patches, etc)? If the kernel was
> patched, is the modified kernel source provided somewhere, or at least the
> patches to apply to the stock kernel?
>
> What distribution was used as the base for the SmoothWall, if any? If all
> the apps came from a distro, then I can simply see if that distro provides
> tc (ex. in Red Hat's iproute rpm) instead of having to statically compile tc
> (or try to match library versions).
>
> The "donor" computer I currently use for SmoothWall 0.9.8 had Red Hat 6.2
> installed on it (just two weeks ago, right before 0.9.9 was released) and I
> had QoS set up, but with a simpler script. The script I used only provided
> "Stochastic Fair Queuing" and didn't discriminate between different types of
> traffic (like the LPR script does), but it really helped make web surfing
> and chatting tolerable while apt-getting debian packages over a dial-up
> link. (Instead of one large queue, like the tcp/ip stack has, SFQ creates
> multiple queues based on origin and destination ip address pairs [and
> possibly including destination port; can't remember], and pulls a packet off
> of each queue round-robin style. So even though there may be tons of
> packets queued, bound for a particular ftp server, packets bound for a
> [different] web server don't have to wait at the end of the line behind all
> those backed-up ftp packets, because those http packets have their own
> line.)
>
> I would be happy to document my work (assuming I get it to work) so that
> this could be incorporated into SmoothWall.
>
> Or if the SmoothWall team isn't interested, I'll just have to ask for this
> same information next time/version around. ;-)
>
> Corey
>
> PS Thanks for SmoothWall and I look forward to installing and modifying
> 0.9.9.