Many have posted that a trackball is more ergonomic than a mouse. I agree completely, and wouldn't give up my Logitech Marble FX without a fight. But the original question was about window managers, so I'll share my thoughts. I've used a bunch of wm's, including fvwm, AfterStep, WindowMaker, Enlightenment, and olvwm, and it's that last one I would suggest. The Open Look virtual window manager has its roots in the Open Look vs. Motif wars, a time when apps were written with the platform's prevalent wm in mind. And since it began its life as a commercial product, it has a lot of the polish that all-open-source projects have lacked, since the quality of Open Look could potentially have made or broken big deals for Sun. Anyway: 1. it's very easy to bind keys to common functions. This statement in your ~/.Xdefaults set up LeftAlt+Tab to do a Windows-like next-window function: olvwm.KeyboardCommand.NextWindow: Alt_L+Tab There are many more functions that can be bound in this manner... 2. it's menus are fully keyboard-navigable. If you bind a key to open up a window's menu, you can use the arrows and Enter to navigate it and select your choice, or hit Esc to cancel it. 3. it's *virtual desktop* is keyboard-navigable. Using the Windows key as a modifier, the arrow keys swap between the different virtual desktops. Or, for those using a mouse, simply focusing the root window makes the arrows alone act the same way. These and many more helpful facilities are documented in the portion of the olwm(1) and olvwm(1) manpages devoted to the subject of Mouseless Operation. Open Look may be a tad ugly, but it's easy to configure and very suited to mouseless use. MoNsTeR
Yes, 100MHz FSB versus 66MHz is a 50% increase. But BladeEnc is CPU limited, not bandwidth limited. It might as well be running on a 1GHz FSB, it wouldn't make any significant difference in this or most other tests/cases. Intel would like you to believe otherwise;)
If anyone else has an -O6 -mpentiumpro BladeEnc running on an egcs-compiled distro / 466MHz CPU, would they care to do some encodes (at the console, of course) and report the *.**X results for comparison?
"Important point - dual or not dual is irrelevant in this test. Bladeenc is a single"
I am aware that single-threaded apps benefit not from an SMP system, as I own and treasure one myself. However, when a program that wants as much CPU as it can get, such as BladeEnc, is run on an SMP system that is not bearing any other significant load, it's pretty much guaranteed to get one entire CPU to itself. So on Jonny's dual 466, BladeEnc had 466MHz all to itself, whereas on my 450, some of those cycles were going to the system daemons. Not very significant, probably a total of 3% or less, but still non-zero.
The one I've heard most often, and the one that makes the most sense to me is that pentium-optimized binaries will not run at all on 486's. Personally, I don't see this is a problem any more, since I can't fathom that any significant number of linux boxes are 486's anymore.
As for optimizations not making much of a difference, that's what I said when it was first mentioned to me. I thought, "yeah, right. what can a few compiler optimizations *really* do for most of my programs?" Then I tried it. I tried Stampede, and now run TurboLinux and I'll tell you, the difference can be huge. I said this in a reply post in the original story, but I'll repeat it here. Comparing MP3 encoding speed using BladeEnc, my Celeron 450 beats my friend's dual Celeron 466 by about 25% in encoding speed. At the time of the test, he was running Debian 2.1, I was (and still am) running TurboLinux 3.6. Lots of people complain about how many CPU cycles XMMS chews up. Me? I compiled it with -06 -mpentiumpro and top shows each xmms thread using 0.0% of my CPU time. For each program, it might make only a small difference, but it tends to add up.
The problem isn't so much mucking through the extra packages. If it were that simple, I'd just grin and bear it with the crappy multi-cd install. But the real issue is development time. With over 2000 packages to stabilize, releases come once in a blue moon. My slightly-old TurboLinux release has GTK+ 1.2.3 and kernel 2.2.10 (which I've updated to 2.2.11), whereas the stable Debian doesn't even have a 1.2.x GTK+ and still uses a 2.0.x kernel. Yes, I know that the "unstable" branch tends to be basically reliable after maturing for a while, but then I face the bandwidth problem (256K DSL is $50/m here HAHA funny). Basically, if I as Joe Linux user pick up a Debian CD (set) and install it, then want to add any current-release software (XMMS being a great example), chances are I'll have an outdated library to deal with. Assuming I have the competence to d/l and compile a lib myself, I'll be defeated by dpkg, since even if I do install a new version of this lib, dpkg won't know about it so I can't install any.deb's that depend on it. It's a real nasty catch-22: do you want current software, or do you want to be able to use the packaging system? I know there are workarounds, but it's all just too much effort.
"1- pentium optimisation doesn't do anything to help ppro/ii/iii etc cores, so it's not worth doing in a general-purpose dist like debian"
This is simply and purely false. I've tested it, a might ad hoc, but I have tested it. I have a Celeron OC'd to 450MHz, my friend has a dual Celeron 466. At the time of the test, he was running Debian 2.1, I was running TurboLinux 3.6. Each of us had compiled BladeEnc on our respective systems, and done a lot of encoding (at the console, for comparison). Even though he had an extra 16MHz on me, plus the fact that BladeEnc had a whole CPU to itself while mine had to share with the system daemons, my system beat his by about 25%. This is probably a best-case scenario, but it IS there.
I started using Linux at home with Debian 1.3, and stayed with it through 2.1. After that though, I switched to TurboLinux (though it might just as well have been RH or SuSE) for two reasons: 1) it seems Debian will forever be compiled i486, and thus never benefit from the oft-huge speed increase of egcs/pgcc 2) the size and growth rate of Debian are, IMHO, inexcusable. The main section no longer fits on one CD!
If it were just #1, I could probably live with it and just install a seperate compiler and library to compile and run the apps that I really need the speed from. But #2 is just nuts. The multi-CD method of install is very rough and difficult to figure out / use, and installing via ftp is simply not an option for those of us with 28.8 modems. Worse yet, this has caused the pace of Debian to slow to a crawl. "Stable" released versions contains libraries and apps of ancient (by the linux time scale) version, and the dependency structure of dpkg makes substituting self-compiled versions effectively impossible. In short, it's very difficult to have a Debian system that is at all current. So, my questions are these:
1. Is the Debian project planning, at any point, to create a Pentium-optimized release?
2. Is the Debian project planning, at any point, to create something like a Debian-lite, that includes only a core of packages such as commonly used libraries, X, popular user agents such as mutt, lftp, and lynx, essential and popular server daemons like sendmail, yp[stuff], nfs, and apache...? Basically, a distro of similar size to the more popular distros that fit easily onto one CD.
If Debian were to do those things, which I see as modernizing and streamlining respectively, I would switch back (or at least try it out in vmware =]).
How about an SGI Origin 2000?;) Or a Sun Enterprise 10000? Or one of HP's high-end boxes?
Seriously though, looking at the kind of machines NCAR (national center for atmospheric research) buys for doing their weather simulations, I see no Alphas at all. They have everything from lowly Sun Ultra workstations and SGI Indigo2's to a handful of Crays and a brand-spanking new 128-cpu Origin 2k. If clustered Alphas provided better performance or lower price, they'd use 'em.
teach yourself to install GNU tools on commercial unix, more like it... Tru64's basic tools SUCK. find doesn't have -maxdepth, du doesn't have -b, the list goes on. It's basically agony to work on w/o having GNU tools.
But anyway, if you want to learn a commercial UNIX, why Tru64 (aka Digital UNIX, DG-UX)?? From what I've seen in job descriptions, Solaris, HP-UX, and AIX skills are in much higher demand. And Solaris can be had for like $20 for non-commercial purposes (with SCSL'd source forthcoming...).
Although there are already nearly 200 comments so it's unlikely this'll ever get seen, I feel the need to point something out.
What leapt out at me was not the modifications PHT made to the kernel, but that their application-level support for these facilities would not be open. I mean, assuming PHT's clustering implementation doesn't suck, I can't imagine Linus rejecting it. Clustering of this kind is something that, AFAIK, we don't have AT ALL right now, so any contribution of it ought to be welcomed. But what good does kernel-level clustering do if you have no way of taking advantage of it from userspace? I can't very well enjoy the bttv video capture driver without xawtv et al. I couldn't take advantage of kernel support for filesystems without "mount", could I? PHT is going to submit their kernel changes to Linus for approval and that's great, but until the userspace support software is open this whole thing will make me nervous.
I'm a TurboLinux user myself, and I nearly hopped over to LinuxMall to order a SuSE CD when I heard about this. I understand that if PHT releases the code for TurboClusterD, it can then be incorporated into other distros thus lessening the incentive to buy from PHT. But I believe that the anti-proprietary backlash from the community could very well cancel out any gains they may make from being the sole provider of TurboClusterD. However, my worries have partially been put to rest by reading a comment posted by the TL kernel maintainer (moderated up to 5, shouldn't be hard to find) saying that their plan is to open up TurboClusterD in the not-tooooooo-distant future. Still, I think that bringing out the applications OSS along with the kernel changes is not only ideologically Right(tm), but could turn enough linux-using heads, idealist or otherwise, to get PHT better recognition and support in markets other than Asia (where it dominates, as SuSE does in Europe and RH does in US).
At the risk of seeming insensitive to the real damage the Taiwan quakes have caused, mainly to life, limb, and dwelling, I'd like to briefly address the issue of ludicrous RAM prices.
If you recall, RAM prices got to sky-high levels quite a bit before Taiwan's first quake, and in fact weren't shaken much by the quake itself. The *real* cause behind the prices are TARIFFS. Yes tariffs, those ever-present enemies of free trade. You see, Micron, the only American DRAM manufacturer afaik, filed a complaint with the US International Trade Commission claiming that the Japanese companies were "dumping", that is, selling their wares at ultra-low (below cost) prices in order to drive competitors out (this is what MS did with IE). How big are these tariffs? Looks like between 8 and ***69*** PERCENT! So that 128MB stick that would've been wholesaled for about, I dunno $50-$70?, a few months ago, would have a tariff of as much as $35-$48 slapped on it.
(I saw this at ArsTechnica, the URL they gave is http://www.ebnonline.com/story/OEG19991014S0009L)
It's strange how so many of its fanatics characterize Apple as the greatest company in the world, who only has the best interests of its customers in mind. I'll be amazed to see what kind of FUD the Mac-fanatics come up with to make this whole flimflam excusable.
But seriously, the original G4-cancellation announcement was wrong (in the immoral sense). Telling your paying customers the product they ordered simply won't be available but they can have a lesser product for its original price is tantamount to a slap in the face. I imagine the flak they caught over that caused them to make the change they did, which was the Right thing to do. Now this? This like slapping your customers in the face, apologizing and promising to make amends, then slapping them again.
As man id-ites know, you developed Quake on NeXTStep and then ported it to DOS (then Windows and Linux). Since Quake2, however, you've been developing natively on Windows NT, which I remember you lamenting at one point because it made you a bit lazy in your programming habits... Anyway, what I'm wondering is, "what would it take for Linux to become your preferred development platform?" Obviously, better 3D hardware support is paramount, but what other issues are there? Would you need a feature-full, cohesive IDE? Better support for the vector instruction sets (MMX, 3DNow!, SSE)? A simpler GUI? At the time of Quake's development, Linux as a game (development) platform would have seemed pretty silly, but with Quake[123], Kingpin, and Unreal Tournament making Linux appearances, as well as Loki's ports of Civ:CTP and Railroad Tycoon, Linux-as-game-platform is starting to seem quite viable...
I just wanted to throw in my (lame) $.02, that being that TurboLinux is cool;) I used Debian for a long time, but with recent releases it's gotten to a point of inexcusable bloat yadda yadda yadda. So I went shopping for a new distro and eventually decided on TL. So far, I've been very pleased. It's much faster than generic i486-compiled distros (of which there are fewer every day...), has a great installer by my standards, has timely updates (XF86 3.3.5, for instance), and just generally feels good. Hopefully, this new influx of investor's money will make TL even better!
The damned thing won't even RUN without glibc 2.1!
Maybe that'll be a fairly reasonable assumption by the time Mozilla is released (hehe), but it's not right now. On the one hand, it doesn't make sense to cut out of alpha testing everyone who's running RH 6, TurboLinux (me), older SuSE, Debian 2.2, et cetera. But OTOH, I can see how some enterprising soul could d/l the current source and figure out a workaround so that it eventually *will* run on 2.0.
I still hope against hope that Mozilla 5.0 will manage to pick the best features from Netscape 3.x and 4.x, and put them together in a browser with the speed of lynx;)
Only this time it looks like Beta gets to win! IIRC, Beta was the superior video tape technology, but VHS had the muscle of Sony behind it, so it won eventually, despite its technical inferiority. For a while, I feared the same would happen with Rambus: it's truly a crappy RAM arch, offering little to no performance gains (in some cases, losses) while bringing sky-high prices, proprietarty design and royalties to Rambus. But it has Intel trying to push it through... Lucky for us, the RAM manufacturers, motherboard manufacturers, IHV's (look at Micron's decision to dump Intel chipsets), and best of all, CONSUMERS, have figured out that Intel and Rambus are trying to screw us here, and we won't stand for it. The day DDR SDRAM is available at a reasonable price, the last nail will be in Rambus' coffin!
I can only say.. IT'S ABOUT TIME!!! UNIX printing has always struck me as a total relic. I can see how it was appropriate years ago when everyone printed text and printers didn't need drivers, etc., but in today's printing world something more advanced was needed.
1. who cares? Linux can be made to be as reliable and robust as Solaris, but Solaris can't be made to be as fast on modest hardware as Linux is. Further, the SCSL has won the approval of exactly ZERO open-source advocates, so I don't think any of the idealist crowd will be switching over. 2. Does the SCSL prohibit us from incorporating their code into our projects, or from using *ideas* in their code in our projects? If not, I say we just JACK ALL THE GOOD STUFF out of Solaris. 3. But really, why would we want to do that, when SGI is going to *give* us most of what we need. They've given us XFS (coming soon? please?), they'll be adding ccNUMA support, who knows what's next? Their strategy seems to be taking the good stuff out of Irix and putting it in Linux cuz they can reach a lot more market with Linux (and the general consensus is 'Irix sucks'). And however you slice it, SGI is much "cooler" than Sun;) MoNsTeR
Well, for one, it's not NEW. Many (most?) of the first quad-xeons basically melted from excess heat. The heat, of course, came from the chips, but it was the IHV's lack of engineering foresight that created the fatal heat build-up. This time, it's Intel's fault. When 8 Xeons are used in their own board(!), too much power is supplied to the chips (VRM malfunction?) thus causing a similar system-meltdown condition. I tend to support Intel, rather than bash them, but they've just f***ed a moose with this whole Xeon line. I'll trust the professional benchmarkers who tell me that 1-2MB of cache "makes a difference" in "server applications" with multiple processors. I'll also take their word that that "difference" is worth about $3000/CPU. But if it's really that "worth it", then Intel ought to be able to engineer the damn things not to generate so much heat! Contract your heatsinks to that HP division, or get Alpha (Sun's heatsinks, popular with OC community) to do them, but whatever you do, Intel, do SOMETHING!
woops. Anyway... My original take on the "challenge" was that Oracle COULDN'T LOSE, because the EULA for MS SQL server explicity states that you, as a user, are not allowed to publish benchmarks. Thus, even if you could buy the hardware (yeah, right. What Intel hardware can outdo a huge Sun Enterprise?) and get the software to work long enough to beat Oracle's record, you couldn't prove it, so there was no way to win.
With mention of the hardware, I ought to also say it wasn't really a fair challenge anyway. To test how fast one piece of software is versus another, everything else must remain constant. Comparing Oracle on a Sun Enterprise bigger than my refridgerator (and running Solaris) to a Dell Poweredge (or whatever; running NT of course) is hardly fair. Of course, you could take that opportunity to point out the choice of hardware and software platforms that Oracle provides as opposed to MSSQL;)
I don't have any "sound technical reasoning" to bring to the table, I just wanted to point out that in the little technical brief put out by Amiga fairly recently, they stated that they *would* be using X, and adding their own GUI system on top of it. Why let X go to waste when it's so easy to build on top of it?
This wasn't exactly news to me, since I read it on the front page of The Denver Post's business section...
I can hardly express how happy I will be if Qwest does indeed buy USWest. If you have to ask why, then you must not be a USWest customer. Their service is abysmal. Analog connections above 33.6Kbps are IMPOSSIBLE in Metro Denver because of the shitty condition of USWest's lines, which they would never even think of upgrading. Their DSL service is wildly overpriced, at $50/month (including line and ISP) for 256Kbps. Some Canadians I talk to on IRC have the nerve to COMPLAIN about paying $55can/month for 1.5Mbps!!!
I can only guess that USWest's monopoly in these parts has taught them to be lazy. When I heard that AT&T/TCI would be laying a new framework in order to deliver phone/TV/Internet, I was overjoyed! But then the Denver City Council took a page out of Portland, Oregon's book and decided to delay the construction so they could force AT&T/TCI to share out their lines. What BS! They lay the lines, they get to do what they want with them. Unfortunately, as you probably know, Oregon won their little dispute, and now it's doubtful whether AT&T/TCI will continue their project there AT ALL. The same is likely to happen here. But now with the prospect of a Qwest buyout of USWest, there is new hope in Denver of inexpensive, reliable, and generally high-quality phone service and broadband internet access!!!
Slashdot Mirror
Many have posted that a trackball is more ergonomic than a mouse. I agree completely, and wouldn't give up my Logitech Marble FX without a fight. But the original question was about window managers, so I'll share my thoughts. I've used a bunch of wm's, including fvwm, AfterStep, WindowMaker, Enlightenment, and olvwm, and it's that last one I would suggest. The Open Look virtual window manager has its roots in the Open Look vs. Motif wars, a time when apps were written with the platform's prevalent wm in mind. And since it began its life as a commercial product, it has a lot of the polish that all-open-source projects have lacked, since the quality of Open Look could potentially have made or broken big deals for Sun. Anyway: 1. it's very easy to bind keys to common functions. This statement in your ~/.Xdefaults set up LeftAlt+Tab to do a Windows-like next-window function: olvwm.KeyboardCommand.NextWindow: Alt_L+Tab There are many more functions that can be bound in this manner... 2. it's menus are fully keyboard-navigable. If you bind a key to open up a window's menu, you can use the arrows and Enter to navigate it and select your choice, or hit Esc to cancel it. 3. it's *virtual desktop* is keyboard-navigable. Using the Windows key as a modifier, the arrow keys swap between the different virtual desktops. Or, for those using a mouse, simply focusing the root window makes the arrows alone act the same way. These and many more helpful facilities are documented in the portion of the olwm(1) and olvwm(1) manpages devoted to the subject of Mouseless Operation. Open Look may be a tad ugly, but it's easy to configure and very suited to mouseless use. MoNsTeR
Yes, 100MHz FSB versus 66MHz is a 50% increase. But BladeEnc is CPU limited, not bandwidth limited. It might as well be running on a 1GHz FSB, it wouldn't make any significant difference in this or most other tests/cases. Intel would like you to believe otherwise ;)
If anyone else has an -O6 -mpentiumpro BladeEnc running on an egcs-compiled distro / 466MHz CPU, would they care to do some encodes (at the console, of course) and report the *.**X results for comparison?
MoNsTeR
"Important point - dual or not dual is irrelevant in this test. Bladeenc is a single"
I am aware that single-threaded apps benefit not from an SMP system, as I own and treasure one myself. However, when a program that wants as much CPU as it can get, such as BladeEnc, is run on an SMP system that is not bearing any other significant load, it's pretty much guaranteed to get one entire CPU to itself. So on Jonny's dual 466, BladeEnc had 466MHz all to itself, whereas on my 450, some of those cycles were going to the system daemons. Not very significant, probably a total of 3% or less, but still non-zero.
MoNsTeR
Agreed, which is why I asked the question.
The one I've heard most often, and the one that makes the most sense to me is that pentium-optimized binaries will not run at all on 486's. Personally, I don't see this is a problem any more, since I can't fathom that any significant number of linux boxes are 486's anymore.
As for optimizations not making much of a difference, that's what I said when it was first mentioned to me. I thought, "yeah, right. what can a few compiler optimizations *really* do for most of my programs?" Then I tried it. I tried Stampede, and now run TurboLinux and I'll tell you, the difference can be huge. I said this in a reply post in the original story, but I'll repeat it here. Comparing MP3 encoding speed using BladeEnc, my Celeron 450 beats my friend's dual Celeron 466 by about 25% in encoding speed. At the time of the test, he was running Debian 2.1, I was (and still am) running TurboLinux 3.6. Lots of people complain about how many CPU cycles XMMS chews up. Me? I compiled it with -06 -mpentiumpro and top shows each xmms thread using 0.0% of my CPU time. For each program, it might make only a small difference, but it tends to add up.
MoNsTeR
The problem isn't so much mucking through the extra packages. If it were that simple, I'd just grin and bear it with the crappy multi-cd install. But the real issue is development time. With over 2000 packages to stabilize, releases come once in a blue moon. My slightly-old TurboLinux release has GTK+ 1.2.3 and kernel 2.2.10 (which I've updated to 2.2.11), whereas the stable Debian doesn't even have a 1.2.x GTK+ and still uses a 2.0.x kernel. Yes, I know that the "unstable" branch tends to be basically reliable after maturing for a while, but then I face the bandwidth problem (256K DSL is $50/m here HAHA funny). Basically, if I as Joe Linux user pick up a Debian CD (set) and install it, then want to add any current-release software (XMMS being a great example), chances are I'll have an outdated library to deal with. Assuming I have the competence to d/l and compile a lib myself, I'll be defeated by dpkg, since even if I do install a new version of this lib, dpkg won't know about it so I can't install any .deb's that depend on it. It's a real nasty catch-22: do you want current software, or do you want to be able to use the packaging system? I know there are workarounds, but it's all just too much effort.
MoNsTeR
"1- pentium optimisation doesn't do anything to help ppro/ii/iii etc cores, so it's not worth doing in a general-purpose dist like debian"
This is simply and purely false. I've tested it, a might ad hoc, but I have tested it. I have a Celeron OC'd to 450MHz, my friend has a dual Celeron 466. At the time of the test, he was running Debian 2.1, I was running TurboLinux 3.6. Each of us had compiled BladeEnc on our respective systems, and done a lot of encoding (at the console, for comparison). Even though he had an extra 16MHz on me, plus the fact that BladeEnc had a whole CPU to itself while mine had to share with the system daemons, my system beat his by about 25%. This is probably a best-case scenario, but it IS there.
MoNsTeR
I started using Linux at home with Debian 1.3, and stayed with it through 2.1. After that though, I switched to TurboLinux (though it might just as well have been RH or SuSE) for two reasons:
1) it seems Debian will forever be compiled i486,
and thus never benefit from the oft-huge speed increase of egcs/pgcc
2) the size and growth rate of Debian are, IMHO,
inexcusable. The main section no longer fits on one CD!
If it were just #1, I could probably live with it and just install a seperate compiler and library to compile and run the apps that I really need the speed from. But #2 is just nuts. The multi-CD method of install is very rough and difficult to figure out / use, and installing via ftp is simply not an option for those of us with 28.8 modems. Worse yet, this has caused the pace of Debian to slow to a crawl. "Stable" released versions contains libraries and apps of ancient (by the linux time scale) version, and the dependency structure of dpkg makes substituting self-compiled versions effectively impossible. In short, it's very difficult to have a Debian system that is at all current.
So, my questions are these:
1. Is the Debian project planning, at any point, to create a Pentium-optimized release?
2. Is the Debian project planning, at any point,
to create something like a Debian-lite, that includes only a core of packages such as commonly used libraries, X, popular user agents such as mutt, lftp, and lynx, essential and popular server daemons like sendmail, yp[stuff], nfs, and apache...? Basically, a distro of similar size to the more popular distros that fit easily onto one CD.
If Debian were to do those things, which I see as modernizing and streamlining respectively, I would switch back (or at least try it out in vmware =]).
MoNsTeR
How about an SGI Origin 2000? ;)
;)
Or a Sun Enterprise 10000?
Or one of HP's high-end boxes?
Seriously though, looking at the kind of machines NCAR (national center for atmospheric research) buys for doing their weather simulations, I see no Alphas at all. They have everything from lowly Sun Ultra workstations and SGI Indigo2's to a handful of Crays and a brand-spanking new 128-cpu Origin 2k. If clustered Alphas provided better performance or lower price, they'd use 'em.
Of course, it *is* a US Gov't facility, so....
MoNsTeR
teach yourself to install GNU tools on commercial unix, more like it...
Tru64's basic tools SUCK. find doesn't have -maxdepth, du doesn't have -b, the list goes on. It's basically agony to work on w/o having GNU tools.
But anyway, if you want to learn a commercial UNIX, why Tru64 (aka Digital UNIX, DG-UX)?? From what I've seen in job descriptions, Solaris, HP-UX, and AIX skills are in much higher demand. And Solaris can be had for like $20 for non-commercial purposes (with SCSL'd source forthcoming...).
MoNsTeR
Although there are already nearly 200 comments so it's unlikely this'll ever get seen, I feel the need to point something out.
What leapt out at me was not the modifications PHT made to the kernel, but that their application-level support for these facilities would not be open. I mean, assuming PHT's clustering implementation doesn't suck, I can't imagine Linus rejecting it. Clustering of this kind is something that, AFAIK, we don't have AT ALL right now, so any contribution of it ought to be welcomed. But what good does kernel-level clustering do if you have no way of taking advantage of it from userspace? I can't very well enjoy the bttv video capture driver without xawtv et al. I couldn't take advantage of kernel support for filesystems without "mount", could I? PHT is going to submit their kernel changes to Linus for approval and that's great, but until the userspace support software is open this whole thing will make me nervous.
I'm a TurboLinux user myself, and I nearly hopped over to LinuxMall to order a SuSE CD when I heard about this. I understand that if PHT releases the code for TurboClusterD, it can then be incorporated into other distros thus lessening the incentive to buy from PHT. But I believe that the anti-proprietary backlash from the community could very well cancel out any gains they may make from being the sole provider of TurboClusterD. However, my worries have partially been put to rest by reading a comment posted by the TL kernel maintainer (moderated up to 5, shouldn't be hard to find) saying that their plan is to open up TurboClusterD in the not-tooooooo-distant future. Still, I think that bringing out the applications OSS along with the kernel changes is not only ideologically Right(tm), but could turn enough linux-using heads, idealist or otherwise, to get PHT better recognition and support in markets other than Asia (where it dominates, as SuSE does in Europe and RH does in US).
Please, PHT, open TurboClusterD!!!
MoNsTeR
At the risk of seeming insensitive to the real damage the Taiwan quakes have caused, mainly to life, limb, and dwelling, I'd like to briefly address the issue of ludicrous RAM prices.
:(
If you recall, RAM prices got to sky-high levels quite a bit before Taiwan's first quake, and in fact weren't shaken much by the quake itself. The *real* cause behind the prices are TARIFFS. Yes tariffs, those ever-present enemies of free trade. You see, Micron, the only American DRAM manufacturer afaik, filed a complaint with the US International Trade Commission claiming that the Japanese companies were "dumping", that is, selling their wares at ultra-low (below cost) prices in order to drive competitors out (this is what MS did with IE). How big are these tariffs? Looks like between 8 and ***69*** PERCENT! So that 128MB stick that would've been wholesaled for about, I dunno $50-$70?, a few months ago, would have a tariff of as much as $35-$48 slapped on it.
(I saw this at ArsTechnica, the URL they gave is http://www.ebnonline.com/story/OEG19991014S0009L)
Don't ya just love big government?
http://www.lp.org
MoNsTeR
It's strange how so many of its fanatics characterize Apple as the greatest company in the world, who only has the best interests of its customers in mind. I'll be amazed to see what kind of FUD the Mac-fanatics come up with to make this whole flimflam excusable.
But seriously, the original G4-cancellation announcement was wrong (in the immoral sense). Telling your paying customers the product they ordered simply won't be available but they can have a lesser product for its original price is tantamount to a slap in the face. I imagine the flak they caught over that caused them to make the change they did, which was the Right thing to do. Now this? This like slapping your customers in the face, apologizing and promising to make amends, then slapping them again.
I hate Marketing departments...
MoNsTeR
As man id-ites know, you developed Quake on NeXTStep and then ported it to DOS (then Windows and Linux). Since Quake2, however, you've been developing natively on Windows NT, which I remember you lamenting at one point because it made you a bit lazy in your programming habits...
Anyway, what I'm wondering is, "what would it take for Linux to become your preferred development platform?"
Obviously, better 3D hardware support is paramount, but what other issues are there? Would you need a feature-full, cohesive IDE? Better support for the vector instruction sets (MMX, 3DNow!, SSE)? A simpler GUI?
At the time of Quake's development, Linux as a game (development) platform would have seemed pretty silly, but with Quake[123], Kingpin, and Unreal Tournament making Linux appearances, as well as Loki's ports of Civ:CTP and Railroad Tycoon, Linux-as-game-platform is starting to seem quite viable...
MoNsTeR
I just wanted to throw in my (lame) $.02, that being that TurboLinux is cool ;)
I used Debian for a long time, but with recent releases it's gotten to a point of inexcusable bloat yadda yadda yadda. So I went shopping for a new distro and eventually decided on TL. So far, I've been very pleased. It's much faster than generic i486-compiled distros (of which there are fewer every day...), has a great installer by my standards, has timely updates (XF86 3.3.5, for instance), and just generally feels good.
Hopefully, this new influx of investor's money will make TL even better!
MoNsTeR
The damned thing won't even RUN without glibc 2.1!
;)
Maybe that'll be a fairly reasonable assumption by the time Mozilla is released (hehe), but it's not right now. On the one hand, it doesn't make sense to cut out of alpha testing everyone who's running RH 6, TurboLinux (me), older SuSE, Debian 2.2, et cetera. But OTOH, I can see how some enterprising soul could d/l the current source and figure out a workaround so that it eventually *will* run on 2.0.
I still hope against hope that Mozilla 5.0 will manage to pick the best features from Netscape 3.x and 4.x, and put them together in a browser with the speed of lynx
MoNsTeR
Only this time it looks like Beta gets to win! IIRC, Beta was the superior video tape technology, but VHS had the muscle of Sony behind it, so it won eventually, despite its technical inferiority. For a while, I feared the same would happen with Rambus: it's truly a crappy RAM arch, offering little to no performance gains (in some cases, losses) while bringing sky-high prices, proprietarty design and royalties to Rambus. But it has Intel trying to push it through...
Lucky for us, the RAM manufacturers, motherboard manufacturers, IHV's (look at Micron's decision to dump Intel chipsets), and best of all, CONSUMERS, have figured out that Intel and Rambus are trying to screw us here, and we won't stand for it.
The day DDR SDRAM is available at a reasonable price, the last nail will be in Rambus' coffin!
MoNsTeR
I can only say..
IT'S ABOUT TIME!!!
UNIX printing has always struck me as a total relic. I can see how it was appropriate years ago when everyone printed text and printers didn't need drivers, etc., but in today's printing world something more advanced was needed.
Hopefully, this is it
MoNsTeR
1. who cares? Linux can be made to be as reliable and robust as Solaris, but Solaris can't be made to be as fast on modest hardware as Linux is. Further, the SCSL has won the approval of exactly ZERO open-source advocates, so I don't think any of the idealist crowd will be switching over. 2. Does the SCSL prohibit us from incorporating their code into our projects, or from using *ideas* in their code in our projects? If not, I say we just JACK ALL THE GOOD STUFF out of Solaris. 3. But really, why would we want to do that, when SGI is going to *give* us most of what we need. They've given us XFS (coming soon? please?), they'll be adding ccNUMA support, who knows what's next? Their strategy seems to be taking the good stuff out of Irix and putting it in Linux cuz they can reach a lot more market with Linux (and the general consensus is 'Irix sucks'). And however you slice it, SGI is much "cooler" than Sun ;) MoNsTeR
Well, for one, it's not NEW. Many (most?) of the first quad-xeons basically melted from excess heat. The heat, of course, came from the chips, but it was the IHV's lack of engineering foresight that created the fatal heat build-up.
This time, it's Intel's fault. When 8 Xeons are used in their own board(!), too much power is supplied to the chips (VRM malfunction?) thus causing a similar system-meltdown condition.
I tend to support Intel, rather than bash them, but they've just f***ed a moose with this whole Xeon line. I'll trust the professional benchmarkers who tell me that 1-2MB of cache "makes a difference" in "server applications" with multiple processors. I'll also take their word that that "difference" is worth about $3000/CPU. But if it's really that "worth it", then Intel ought to be able to engineer the damn things not to generate so much heat! Contract your heatsinks to that HP division, or get Alpha (Sun's heatsinks, popular with OC community) to do them, but whatever you do, Intel, do SOMETHING!
MoNsTeR
woops. Anyway...
;)
My original take on the "challenge" was that Oracle COULDN'T LOSE, because the EULA for MS SQL server explicity states that you, as a user, are not allowed to publish benchmarks. Thus, even if you could buy the hardware (yeah, right. What Intel hardware can outdo a huge Sun Enterprise?) and get the software to work long enough to beat Oracle's record, you couldn't prove it, so there was no way to win.
With mention of the hardware, I ought to also say it wasn't really a fair challenge anyway. To test how fast one piece of software is versus another, everything else must remain constant. Comparing Oracle on a Sun Enterprise bigger than my refridgerator (and running Solaris) to a Dell Poweredge (or whatever; running NT of course) is hardly fair. Of course, you could take that opportunity to point out the choice of hardware and software platforms that Oracle provides as opposed to MSSQL
MoNsTeR
I just want one here in the Mile High City ;)
MoNsTeR
I don't have any "sound technical reasoning" to bring to the table, I just wanted to point out that in the little technical brief put out by Amiga fairly recently, they stated that they *would* be using X, and adding their own GUI system on top of it. Why let X go to waste when it's so easy to build on top of it?
MoNsTeR
http://slashdot.org/articles/99/02/10/0852241.shtm l
so it was Feb, not quite 6 months. blah.
MoNsTeR
Don't y'all remember this? I distincly remember seeing this on /. like, 6 months ago at least.
It was a whole paradigm shift, with on-the-fly FPGA re-programming and all that...
MoNsTeR
This wasn't exactly news to me, since I read it on the front page of The Denver Post's business section...
I can hardly express how happy I will be if Qwest does indeed buy USWest. If you have to ask why, then you must not be a USWest customer. Their service is abysmal. Analog connections above 33.6Kbps are IMPOSSIBLE in Metro Denver because of the shitty condition of USWest's lines, which they would never even think of upgrading. Their DSL service is wildly overpriced, at $50/month (including line and ISP) for 256Kbps. Some Canadians I talk to on IRC have the nerve to COMPLAIN about paying $55can/month for 1.5Mbps!!!
I can only guess that USWest's monopoly in these parts has taught them to be lazy. When I heard that AT&T/TCI would be laying a new framework in order to deliver phone/TV/Internet, I was overjoyed! But then the Denver City Council took a page out of Portland, Oregon's book and decided to delay the construction so they could force AT&T/TCI to share out their lines. What BS! They lay the lines, they get to do what they want with them. Unfortunately, as you probably know, Oregon won their little dispute, and now it's doubtful whether AT&T/TCI will continue their project there AT ALL. The same is likely to happen here. But now with the prospect of a Qwest buyout of USWest, there is new hope in Denver of inexpensive, reliable, and generally high-quality phone service and broadband internet access!!!
MoNsTeR