Who is going
to support you in the absence of a contract and no OS community.
Who is going to support me with no driver source? What makes nVidia any more interested in providing me with support than SGI, in the absence of a contract with either? In fact, nVidia would be significantly less interested, because their products are inexpensive commodity items. SGI has a motive (near-bankruptcy) to keep their customers, even small ones, happy; what's nVidia's motive? Not a damn thing. They don't care whether I buy their products now or ever. So in the end, if I want a decent level of support for an nVidia product, it'll have to be a community-based effort based on, as always, source availability (really, how do you have community support without source? "ok, now dd if=mypatch of=binarydriver offset=0x455fc count=0x458, sacrifice a chicken and a virgin, and pray that it works on your system"??? Come on now). Since nVidia doesn't seem to want that, I've the choice of paying SGI for support or using a product from a friendlier vendor. Either way, the nVidia way loses.
You do realize that MS is lying when it says that drivers are at fault.
While I don't exactly trust anything Microsoft says, I'm inclined to believe, based on my experiences with binary-only (as if there's another kind) winblows drivers, that the vendors are partially to blame. Sure, nt itself blows goats, but the vendor-supplied drivers make it swallow too.
It advances Linux in the home and workstation markets, and gives users an incentive to use linux.
You assume that I judge what's good for the environment based on what increases its market share. Market share means nothing if the actual quality and quantity of true hardware support decreases. I quite frankly don't give a rat's ass how many or few people use Linux, or anything else. It's much more important to me that the climate in the industry move more toward general openness than that some loser gamez d00d (or even 10 million of them) takes up Linux.
If a company treats
Linux equal to Microsoft it shows that they take Linux seriously, not that they think that the two OSs are of similar quality.
Who cares what they think of Linux? Just give me the specs and I'll buy their product; it hardly matters what OS I choose to use it on.
["die hard" OSS people] Outside/., you guys are a rare breed.
Slashdot is for amusement only. If you base any of your impressions on the posts you see here, you've made a mistake. The fact is, the people you are characterizing as "die hard" here are the very people who've written the software that makes this discussion, and so much more, possible. The simple fact is that without people who are truly committed to the cause, it never would have gone anywhere and Linux most likely would not exist (how would Linus have compiled it???).
...all my hardware is overclocked...
No wonder I find your arguments spurious and counterproductive. Please don't take this personally, but I've yet to have an intelligent conversion with an 0v3rcl0kk3r d00d.
Also, SGI is not exactly known for shipping the most stable
software products in the "you can't afford it" catagory.
Well, I have several of them that have been up for 150+ days, brought down only for maintenance. Both hardware and software seem to work exceedingly well. Much like sparc-sun-linux machines, I never even think about my mips-sgi-irix6.5 systems. They just work, and are damn fast. YMMV I guess, but they work fine for me, far far better than any peecee I've ever seen. If I've got to have something I can't afford, I'd rather it work.
Your attitude, and the knowledge that many others share it, have convinced me that Stallman made an error when he wrote the GPL. It should add in a simple clause that states that you cannot use GPL'd software to call, link, load, execute, build, or manipulate closed-source software. IOW, a pure system requirement. You're all going to throw away twenty years of work.
This is good for Linux. The OSS die hards might not like it, and it is unfortunate that the Alpha people can't use it, but overall it is
good. It furthers Linux in the home market and the desktop 3D workstation market. It make linux a higher quality, more usable
environment.
No, it is not. It makes Linux a lower quality, less usable environment. Why? Well, if you buy nVidia's products, and use their binary-only drivers, you are sending the message that that level of support (ie practically none) is acceptable. If every hardware vendor offers drivers under the same license, your once-stable unix-like operating system has become the hell that is NT. Worse still, do you really want to get yourself in a situation wherein you can't upgrade your OS (let's say a major security hole was found and patched...) because you're tied to a binary-only driver? Bottom line: binary-only ANYTHING is BAD, BAD, BAD.
It is good for Linux users.
No, it is not. See above.
It shows that Linux is being treated equally among OSs. nVidia wouldn't release their source to Microsoft, and they aren't doing it for
the OSS community.
How is this good? The purpose of Free software is not to gain a place in the proprietary software world as an equal to Microsoft's offerings!!! It's to be a fundamentally different, and better, way of using computers.
Ultimately, however, it is their decision, and it is up to them what they want to do with their work.
On this, at least, you are right. And, in exactly the same way, it is your choice whether to give them your business. Not me, man.
Do any of you care about speed? Voodoo 5 has already shown to be only moderatly faster than a
GeForce but you'd prefer an open Voodoo, rather than a closed GeForce 2? Doesn't anyone care about SPEEEED!??:)
Your argument makes no sense. Voodoo5 is faster AND more open than nVidia's offerings...where's the beef? Besides, if I really cared about 3d graphics speed, I'd go with either Sun's new Expert3d or one of many fine offerings from SGI. Sun and SGI may not offer source either, but at least their stuff is FAST and HIGH QUALITY. If SGI ships me a binary IRIX driver for (let's say) an Infinite Reality Engine, I'm pretty damn sure that it'll work and not crash my system. Do you really place the same level of faith in nVidia? Coding for a system they most likely don't understand well? Sure, kid.
To use your example, gcc is less functional than VC 6.
REALLY? Cool, now I won't need my sparc-sun-linux hosted mips-dec-ultrix cross compiler any more! Or my Palm Pilot development environment! Or my 64-bit native Sparc compiler! Oh wait, VC 6 only runs on i386-pc-windows and, for that matter, only compiles for i386-pc-windows. And doesn't even do a very good job of that. Doesn't sound very functional to me. I suppose that if your definition of functionality is the size of the code it generates, or the number of ways it ignores the applicable standards documents, then you are correct.
gcc may or may not generate the best code of any compiler on a given target, but it generates good code on many many more targets than anything else, and since it's open source and quite portable, it's also usable on more systems than anything else. That's infinitely more useful to me than having the option to write noncompliant c++ and have it compile into a nice slow 300 MB winblows-only binary, which, if I use the right flags, might not be able to crash the OS more than once or twice a day. Functionality? I don't think so. And, yes, I've used VC. The editor sucks, the compiler is substandard, and the toolchain's portability is nonexistent.
Look, I see your point, but you're just being paranoid. If Linux becomes ubiquitous, the OS market will be unaffected. In particular, an effort like Linux itself could always start up again if people felt that the climate was too oppressive.
My point was not that nothing else is functional; I personally prefer ******* or **** (names removed to prevent holy war), but my point was that Linux is infinitely preferable to Winders on technical merit, even if the marketplace behaviors were equally bad.
Unlicensed software? Yes it can be free, but it would be unprotected; anyone could steal it and then try to sell it as their own; closed source, no 'piracy' and all that.
Oh, like the BSD license?
The whole purpose of a license is to protect the software and the programmer; at least thats the way I see it.
I see it differently. The purpose of the license varies by licensor. Microsoft wants protection for their profit machine, Red Hat licenses in a certain way to maintain their standing in the community, the BSD projects license according to tradition and their particular beliefs, and the GNU project licenses according to a very specific agenda. I could go on, but the point is made: there are many different licenses, each of which means something a little different to each entity that uses it (as a direct counterexample, the BSD license provides no protection for the programmer whatsoever). If the programmer desires protection, there are many licenses that can provide it in different ways, but that's not the only reason for licenses.
Naturally you are free to think whatever you like. But even if your worst fears are realized, you're left with the comparison of "nonfunctional software, no choices" and "functional software, no choices." Which is better? In any case, it's an academic question because Stallman has no power to restrict your choices. It's not like gcc has a special license restriction that applies the GPL to whatever you compile with it...
I know this comes off like a troll, but I can't believe the best example he could think of was StarOffice. This is easily the lowest-quality piece of software I've ever seen running on Unix (yes, worse even than netscape). Why not mention things like Oracle or some of the SGI tools? You know, software that actually works. On the other hand, this example provides some nice insight into why Caldera's distro sucks so much. Judge a man by his heroes?
The BSD license has had the advertising clause removed for some time now. In fact, there is not a great deal of difference between BSD and public domain now. In any case, honest individuals will always attribute their sources...
The question of "distribution" was raised and debated at length back during the Corel Linux beta debacle. I recommend you read that discussion if you want the split hairs.
Aren't Linux users the ones who target Microsoft for its abuse of users?
Those users have paid Microsoft for a product. That product does not measure up to the promises that are made, and the users are not given the opportunity to correct the problems themselves. In the Linux world, you don't pay the developers, no promises are made about the software, and if there's something you want done you are free to do it yourself. If that means a fork, then it means a fork. At least you have a choice.
It has nothing to do with being abusive toward users. If all the users are doing is taking from the community without contributing (since most of them can't anyway), then I fail to see why someone who has invested his own time and effort into a piece of software that represents his view of correctness should be required to support these users by either working on or accepting patches that conflict with his own ideas. If you want something with UDI, you are free by virtue of the GPL to put out Fredix, or to pay SCO for it. If you don't like these options, tough. You have in the Free Software community a large number of people willing to give you something for nothing. If that something is of no value to you, then you've still come out ok. I fail to see the parallel with Microsoft; you pay them $500 for an OS and a web server that they promise will work, and then it doesn't work. Well, in that case you're out $500. You pay Linus nothing for Linux, which is delivered to you as-is; if it doesn't work, so what? Where along the line did you acquire the right to insist that he add UDI (or anything else) to his operating system for your benefit?
The way I see it, Linux belongs to Linus. It is his OS; he has generously allowed you to have, use, modify, and redistribute the fruits of his efforts, as have all the other hundreds of major contributors. If it's useful to you, great. But it still belongs to them, and if they don't want your changes in it, that's their right. They owe you nothing.
Then they're idiots. Consistent interfaces are the lifeblood of continued interoperability
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
To this end, BTW, documenting that behavior in detail is a valuable step but all too rare in the Linux world. Documenting dependencies on specific behavior would be nice too.
It's happening. Look in the latest 2.3.99 versions; parts are being documented in DocBook format.
For example, as a filesystem developer I can only shake my head at the Linux VFS and buffer-cache layers.
Try 2.3. You aren't the only one who thought the old way sucked.
What's missing is a widespread recognition that the most important reason to protect code from change is the importance to other components of maintaining its current behavior even in small details.
No. The most important reason to protect code is that it is correct, fast, and maintainable. While one correct, fast, and maintainable solution can be replaced with another that is easier to interface with, no decrease in correctness, performance, or maintainability is considered acceptable. It's true that some of the kernel hackers have axes to grind in some portions of the code. This is true in any project. Unlike closed-source projects, Linux offers you the opportunity to go off on your own, implement what you want, measure its performance, and post your results.
Unfortunately, doing this usually requires foresight in the _original_ version of the code, leaving room for versions or capability flags so that both called and callers know which behavior to expect or provide. Sadly, the code most in need of an upgrade is inevitably also most marked by lack of programmer foresight.
This type of thing has a name: cruft. Programmer foresight is a nice thought, but nobody can think of everything. Everyone tries anyway. The nice thing about Linux is that when a failed effort to think of everything starts to cause problems, it gets replaced. In the proprietary world it stays around forever (IDE, the 640 limit, the list goes on).
>In Solaris or Windows, where most people don't get decent performance anyway That's a pretty offhand and inaccurate statement, at least for Solaris. It's not great, but neither is Linux.
Look, I've used Solaris. I admin it sometimes. It sucks on SPARC, and is simply godawful on x86. I bitch at Linux too, sometimes for other things (like NIS), but when it comes to Solaris I gripe about performance. It just sucks.
It all seems like a wash to me. How does UDI actually make this problem worse than it is anyway?
By significantly reducing the amount of work needed to produce something that can realistically be called "Linux support." Producing a fully native Linux driver requires significantly more work and knowledge than taking the UDI boilerplate code and throwing in the microcode for your device's ASIC. Producing a UDI driver (or letting someone else do so for their own proprietary OS) and then saying look, it works with Linux is much easier. It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
Again, where exactly is the compromise here? How would enabling UDI drivers enable disreputable proprietary behaviors that aren't already being practiced anyway?
By asking this question you illustrate your lack of understanding. The point is not that keeping UDI of of the mainstream Linux kernel somehow prevents proprietary practices. Rather, if UDI is put in (ignoring for a moment the substantial body of technical reasons it should not be), and vendors begin providing the same low-quality binary-only drivers for Linux that they do for 'doze, the new Linux users unaccustomed to our high standards will accept these inferior drivers. Once they have done so, there will be less motivation than ever for hardware vendors to provide documentation ("Why do you need the docs?" "To write a Linux driver." "But we already provide one! See, here - foo4355.o; it works on UP Red Hat 7.2 on Intel only" "But I have a Sun and I run Debian" "You need foo4355.o for Linux"). Don't kid yourself - this is guaranteed to happen. In fact, it's already a problem because binary modules are allowed at all. Thankfully the developers refuse to support kernels with binary-only modules loaded. Still, UDI will only make the problem worse.
And if that change happens to annoy Inexperienced End User Who Wants To Give You Market Share But Can't Because Of A Philosophy Decision, is it tough shit too?
I do not care how much or how little market share Linux has. Whether someone else uses it means nothing to me; I can continue to use it as I please even if every single other person stops using it. Welcome to Free software.
More users result in more developers. More developers result in more support. More support results in more things that you want for your OS.
I don't really think this is true any more. The type of new users Linux is attracting today doesn't know a stack frame from a superblock, and doesn't intend to learn. These people aren't kernel hackers. They aren't applications developers. They aren't even helpful bug-report-submitting users who understand what quality software is all about and are proud to help it along in some small way. In other words, unlike previous Linux adopters, they take, take, take, and give nothing back. From a developer's point of view, these people do nothing to help the process of making a great system; all they do is clutter up mailing lists with useless bug reports and inane feature requests. New projects? Yeah, right. Patches? Don't hold your breath.
Even if these people were useful developers, they wouldn't be able to help much with the issue at hand, device support. Today's support for devices is limited by documentation, not coders. Help is always appreciated of course, but one more programmer's manual would make a lot more difference than one more developer.
You can... sign mass petitions to get a native driver.
I don't do that. I vote with my currency units. No open source? No specs? No money, then. Petitions are for whiners.
To be more precise, the Linux purists are afraid that Linux users will be satisfied with the UDI drivers and won't be as eager to join mass driver movements.
These people were satisfied with windows six months ago!!! Of course they'll be satisfied with UDI drivers; they'd be satisfied with three tons of steaming shit and a more comfortable chair. The nice thing about Linux is that the people who make it won't be satisfied with UDI drivers. But these "mass driver movements" you mention actually have very little to do with getting native drivers written. In fact, what usually ends up happening is that some competitor gets wise and mails a manual to some hacker who then writes a driver. The hundreds of petition signers don't know how to write drivers and in most cases are probably just following the Slashdot crowd anyway ("what's the petition for? d00d, it's a driver for the Mumblebazco Vapourware 5200!!! The WHAT? Oh well, I'll sign anyway.")
If you don't want users to be complacent with UDI drivers, then tell them so.
Right. "That driver offers 30% suboptimal performance!" "So? It plays quake."
But don't take away the choice just because you're too lazy to do it.
But you see, we don't write this code for others. We write it for ourselves, and share it with others because we feel it's the right thing to do. We don't have any responsibility to the users whatsoever. For the 99.8% of us who write Free Software and don't get paid for it, the fact that some user wants UDI means nothing. The simple fact is that the people who generously volunteer their time and skills to work on these projects have earned the right to decide what goes in and what does not. And UDI will not. Not because we're too lazy to do it (not that it would matter even if we were; we owe you nothing), but because we don't think it's a good idea. If you want UDI, you're free to write it yourself and maintain your own tree. Did Linus wait 10 years for Tanenbaum to open-source Minix? Did RMS sit around and wait for all the proprietary software vendors to collapse? Of course not. They rolled up their sleeves and got to work. Unlike them, you aren't forced to be a pioneer; you'll find a ready and willing crowd of people to test and maybe even contribute to your project. You can even get free project hosting if you want it. In fact, all you need to provide are your skills and time.
There are only two ways to ensure you get what you want: pay someone for it, or do it yourself. Berating volunteers for being "too lazy" to give you what you want, against their own better judgment, is rude and selfish. Stop and think for a moment; if you felt UDI were a bad idea poorly implemented, would you want it in a world-famous product that bears your name?
Tell that to the large number of people waiting for drivers that aren't forthcoming, who don't have the skills to write the driver themselves.
I do, unapologetically. If you don't release specs so that an open source driver can be written, I won't buy your product. It's just that simple. It's unfortunate that some people won't switch to a Free operating system because they have hardware that isn't supported, but their annoyance and indignation - and that of the people who have to explain this to them - should be directed at the vendors, where it belongs, rather than at the legions of volunteers who have written excellent drivers for documented hardware. Compromising with the devil is rarely a profitable exercise. I would much prefer Linus to announce today that he will no longer allow binary-only drivers.
A driver version should not be tied to a kernel version in the first place. With a well-defined API (i.e. UDI), this sort of backward-compatibility and forward-compatibility will work and should be encouraged. Needing to rebuild every driver because you updated the kernel is a waste of time and effort, especially when the drivers need updates to match kernel changes.
No. Firstly, kernel source PIs do not change within a stable series. But what you are forgetting here, since we're talking about binary compatibility now, is that Linux has no consistent or guaranteed kernel binary PI. That's right, none. Linus and everyone else doesn't see the need, and I wholeheartedly agree. Linux is an open source operating system, and the source KPI is guaranteed within a stable series. So given driver source, there is no issue here. The kernel hackers can feel free to make changes that break binary module compatibility, and it only harms binary-only drivers. Big deal. If a change needs to be made, it needs to be made. And if that change happens to annoy Big Proprietary Hardware Vendor Inc., tough shit.
It only hinders development if poor API's were chosen to begin with.
Only as long as those PIs continue to exist. In Linux, when it's determined that an existing KPI (it's not an API if they're not applications after all) sucks, it gets replaced in the next development series. We can do that in an open source world. Your proprietary binary-only world prevents those kinds of changes and instead encourages setting arbitrary limits like the ones you mention ("since we can never change it, we'll just make it as high as we think is necessary today"). In fact, it is the anchor of binary compatibility that holds you to the rocky bottom of 1980's OS technology.
Jury's still out on performance. [UDI]
Not really. Alan Cox has explained in several l-k posts, in detail, why UDI drivers, in Linux anyway, cannot have performance equal to their native counterparts. In Solaris or Windows, where most people don't get decent performance anyway, UDI sounds like a good idea. But in Linux, wherein crazy socially maladjusted individuals pride themselves on removing one cycle from the kernel's execution time, any penalty is too much. The rationale is simple: our OS kicks the living shit out of yours; why should we be the ones to change to your driver model? I have yet to hear a good answer to this question.
Untrusted drivers could be loaded into userspace and run slowly but safely. After they've proven themselves, the user/sysadmin could choose to allow the driver to run in kernelspace for performance. Best of both worlds. (This switching could potentially even be automated...)
Right. So on my production system, I have three choices: a userspace UDI driver that most likely won't crash my system but will run so slowly that nobody can get their work done; a kernelspace UDI driver that will do God-knows-what to my system; and a 7-year-old battle-tested open source native driver held together by volunteers who know their device better than the people who made it. Guess which one I'm going to choose, even if it means using different hardware?
UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support.
This is not a bad point but for one thing: if the people who use those OSs want, they can take a driver from another open source OS and port it. The real "best hope" is for every piece of hardware to have available a programmer's manual. Linux is where it is today because many people felt it was a good use of their time to write drivers for hardware that wasn't previously supported. The same can be said of FreeBSD and other projects as well. If nobody feels that writing a HURD driver for some odd hardware is worth doing, then it won't get done. In 1992, nobody picked up Linux and started using it because it supported their hardware. In fact, some of them picked it up because it didn't support their hardware.
Too much is made today of how to get the computer-illiterate digital have-not GNOME-wanting RedHat-investing Luddite fuckwits to come use our great new wonderful OS. Am I the only one who doesn't really care whether they do or not? Linux is for the people who make it. If someone else finds it useful and wants to use it, they are free to do so by virtue of the license. But it's not the responsibility of the kernel developers to put in support for every two-bit half-assed self-serving proprieatry piece of crap "standard" that comes their way. In fact, in most cases, it's not their job to work on Linux at all. They do it because they choose to, not so that you can feel all warm and fuzzy telling all your 1337 friends how well it supports your brand-new XFR3-5432DSA fuxor card.
There's also the problem that doing things like direct port access is inherently nonportable. For example, many types of systems nowadays have PCI buses. Under Linux (and possibly Solaris, but it's hard to tell), PCI devices can be supported on multiple platforms by the same drivers. Using an i386-specific method may allow you to use this product to port among i386 operating systems (at severely reduced performance of course), but costs you any opportunity to remain compatible across architectures. It's just not worth it. I find it exceedingly cool that, for example, I can stick a 3com PCI network adapter in a Sun box and have it just plain work with the exact same driver that it uses on an x86 box. Wouldn't it be a shame if 3com had decided 6 years ago to produce a pseudo-driver in binary-only format, and thus the current driver never existed at all? You'd be a slave to 3com, and to Intel becuase you'd have no portable drivers at all.
Of course, this cross platform thing would be useful for making sure there is support for as many possible platforms ASAP, then optimised platform specific ports could come at a later date...
Yes, where "later date" == "never". You're ignoring the lessons of history. If it's "good enough," it'll stick around forever and its vastly superior replacement will never see the light of day. It's happened way too many times. How else do you explain people willingly buying a 16-bit operating system for a 32-bit CPU that can't compete with its 64-bit competitors that have been around for five years? Good enough indeed.
on linux-kernel. UDI, for those who are unfamiliar, is an initiative by some hardware and proprietary software people to do write-once drivers for Unix. Like any such effort, it relies on an abstraction layer that interfaces the "real" OS-level driver layer with the driver components themselves.
The problem with this product, as with UDI, is that performance suffers. The linux people refuse to take part in UDI for a number of various good reasons, which can most simply be expressed as "the performance sucks rocks." See also a similar discussion based on a misunderstanding of ImageWorks new WAN code. Essentially, the concept of providing a common binary interface to multiple different kernels - be they different systems altogether or simply different, incompatible versions of the same system - is an old one, something of a Holy Grail to some people it seems.
The bottom line is, hardware vendors who refuse to open up the specs to their hardware are always looking for a way to provide as much "checkbox" operating system support as possible without actually doing any work or participating in the development community. There's an important technical downside as well, besides the poor performance these abstractions cause: if a vendor writes a poor winblows driver, then ports it to $favourite_os, what do you think this does for the stability of $favourite_os when the driver is loaded? That's right, it goes to hell. Microsoft has said for a long time that the stability problems their platform is known for are caused by third-party drivers. While I don't believe that's the whole story, they have a legitimate gripe here. If someone takes that same driver and loads it into Solaris, Linux, or vxWorks, they're going to suffer many of the same problems they would on winblows.
So no, this isn't as good as it sounds. Linux especially is rejecting such ideas from its mainline tree, but it's important that people also be aware of what their distribution vendors are shipping - it might be too tempting for one of them to say, look we can support winmodems but we'll have to add this proprietary cruftware patch to the kernel; it sucks but we'll be the first so let's do it. I'm wondering more and more whether Linus is regretting his binary-only module license exception.
No x86 processor is good for anything. If you're really asking about realtime stuff, you want Motorola 68k-based microcontrollers. If you're really asking about high-end scientific computation, you want MIPS, SPARC, or Alpha depending on the specific properties of the work involved. If you really mean "I want to do high-end scientific computation in real time," for example, simulate a nuclear bomb explosion in real time, I don't know whether to laugh or recommend a large area such as Asia stacked eight deep with SGI Origin 2000s. Rephrase your question please.
The Onyx2 is a piece of crap. Try a Power Challenge or Origin system instead. I never have problems with mine. Alphas are nice, but there's nothing wrong with SGIs. Ultra 10? I stand before you, laughing hysterically in a mocking way. Let me guess, you run Solaris on it too. Free clue: don't venture off Slashdot; people elsewhere won't be so easily confused.
I dunno what else they could do to maintain any form of economy.
Get a product people care about maybe? Nobody cares about thin clients because, even though buyers want them, nobody wants to sell the hardware. In order to make a compelling case for thin client hardware, it has to be significantly cheaper than the alternative. Cheap computers have terrible margins, so hardware vendors don't want to bother. And thus SCO finds itself up shit creek, and the Penguin swimming upstream came along and grabbed the Unixware paddles.
This attitude of "open source it!" is senseless. Has it occurred to anyone that maybe the reason open source software works so well isn't that it's open source but rather that a real person, not a committee or focus group, saw a need - usually his own - and started hacking up a solution? A product that doesn't meet any need will be no more successful just because the license has changed. That doesn't mean that some sort of procedure by which a failed company's IP becomes automatically open to the world would be bad. But counting on open source to save your ass from a bad product decision isn't the right approach, and it doesn't work.
Microsoft... the vendor that has the most to gain from IA64.
Really? I don't think so. I think they can gain little but lose a great deal. The ultra-low-end market is their strong point, which will be totally unaffected by IA64 for at least 5 years. The high end, which is supposedly targeted by IA64, already has a strong competitor, Linux. If M$ gets their act together, they can possibly hold their current market share. If not, their days of producing anything but low-end software for home users will be over. They aren't going to gain much, no matter what happens. First, Itanium won't offer the performance of its "traditional server vendor" rivals. So it's not going to grab much share from them, if any. Most of the IA64 share will come out of the existing peecee market. People running Linux on peecees aren't going to run out and buy M$ for IA64. The most M$-optimistic outcome is that current enntee users migrate en masse to IA64/enntee. In which case M$ holds its current market share, which, in this environment, isn't very high (37% or so last I saw). If any current enntee/peecee user needs more performance but is unwilling to leave Intel, he may find that his only choice is Linux - that is, if M$ doesn't get their IA64 OS done in time. In that case, M$ loses more market share to Linux and misses the opportunity to gain a foothold in the IA64 world.
So what can they gain? Not much. They might convince a few of the dumber IT manglers that Itanium + enntee can compete with traditional high-end solutions, or maybe that it's better than Linux (unlikely given current trends), but this certainly isn't going to help them very much. At best, they stand to gain a very small chunk of the market. At worst, they stand to lose their entire presence in the non-home market. Given this fact, I join you in surprise at their decision making. Not because they have so much to gain but because they have so much to lose.
If anyone comes out of IA64 a big winner it will be Linux, which will be the only option that runs on current peecees, future peecees, and the majority of the workstions/servers using non-Intel CPUs as well. It certainly won't be M$, and it probably won't be Intel. During this time I fully expect Intel to lose a good chunk of their customers to the traditional RISC vendors (Sun, SGI, etc) and people like IBM. Itanium will flop initially at least, and Intel isn't going to come out of it looking good. Nor is AMD, especially if this Sledgehammer really represents their primary plan.
I sorta wonder if the whole "Sledgehammer" hype is just FUD smoke that AMD is blowing at IA-64.
Seems like a pretty good theory. But I'd FUD better than that if I were AMD. Of course, there are plenty of good reasons to have F, U, and D about Itanium that have nothing to do with AMD.
Intel is going to be backing away from the x86 market to push IA-64 - an unknown, expensive quantity with very little software running on it and poor x86 performance.
I do not see the poor x86 performance as a serious issue. GCC has already been ported to produce native code, and Linux is ready to go. There is presumably a bit of glibc work left but I fully expect that a full native distribution will ship the same day as the CPUs. Full native == no x86 performance problems, and full native == full software availability. The real problem with Itanium is that its performance is going to disappoint, even in native mode. By the time Intel works out the problems inherent in any new processor, not to mention the problems with their supply chain, their competitors will be well ahead of them, shipping stable, mature products with superior performance and, thanks to not having to supply two chips in one, at lower cost as well.
Add a little "64-bit" gloss to Windows 98, and AMD might gain some serious market share here.
Who's going to do this? Microsoft doesn't have any incentive to do it; they're already selling all the winblows 98 they want. They're going to be far too busy trying not to lose their shirts to Linux in the IA-64 sphere to give two shits about a warmed-over 64-bit AMD with miniscule market share. Anyone expecting to see winblows on native Sledgehammer is in for a nasty surprise. Linux probably will be ported at some point, but by that time I doubt it will still be in production.
If it's priced the same as Intel's 32-bit chips
It won't be. You know it, I know it, AMD knows it.
On the other hand, if it's more expensive than a 32-bit chip and doesn't offer any real advantage to the average user, what's the point?
Bingo. This is a product in search of a market. The engineers (and probably the lawyers too, but that's just rampant speculation) told the droids that it would be easier to produce a 64-bit x86 processor than an IA64-compatible one. So that's what they're going to do. I don't think AMD ever even considered something non-Intel compatible, it was more a question of which Intel to be compatible with. They just wanted to say "we have a 64-bit processor too." Well, big deal, AMD; everyone has a 64-bit processor these days. Having the weakest one of all isn't going to turn any heads, unless it's at the next shareholders' meeting.
Slashdot Mirror
Who is going to support me with no driver source? What makes nVidia any more interested in providing me with support than SGI, in the absence of a contract with either? In fact, nVidia would be significantly less interested, because their products are inexpensive commodity items. SGI has a motive (near-bankruptcy) to keep their customers, even small ones, happy; what's nVidia's motive? Not a damn thing. They don't care whether I buy their products now or ever. So in the end, if I want a decent level of support for an nVidia product, it'll have to be a community-based effort based on, as always, source availability (really, how do you have community support without source? "ok, now dd if=mypatch of=binarydriver offset=0x455fc count=0x458, sacrifice a chicken and a virgin, and pray that it works on your system"??? Come on now). Since nVidia doesn't seem to want that, I've the choice of paying SGI for support or using a product from a friendlier vendor. Either way, the nVidia way loses.
While I don't exactly trust anything Microsoft says, I'm inclined to believe, based on my experiences with binary-only (as if there's another kind) winblows drivers, that the vendors are partially to blame. Sure, nt itself blows goats, but the vendor-supplied drivers make it swallow too.
It advances Linux in the home and workstation markets, and gives users an incentive to use linux.
You assume that I judge what's good for the environment based on what increases its market share. Market share means nothing if the actual quality and quantity of true hardware support decreases. I quite frankly don't give a rat's ass how many or few people use Linux, or anything else. It's much more important to me that the climate in the industry move more toward general openness than that some loser gamez d00d (or even 10 million of them) takes up Linux.
If a company treats Linux equal to Microsoft it shows that they take Linux seriously, not that they think that the two OSs are of similar quality.
Who cares what they think of Linux? Just give me the specs and I'll buy their product; it hardly matters what OS I choose to use it on.
["die hard" OSS people] Outside /., you guys are a rare breed.
Slashdot is for amusement only. If you base any of your impressions on the posts you see here, you've made a mistake. The fact is, the people you are characterizing as "die hard" here are the very people who've written the software that makes this discussion, and so much more, possible. The simple fact is that without people who are truly committed to the cause, it never would have gone anywhere and Linux most likely would not exist (how would Linus have compiled it???).
No wonder I find your arguments spurious and counterproductive. Please don't take this personally, but I've yet to have an intelligent conversion with an 0v3rcl0kk3r d00d.
Also, SGI is not exactly known for shipping the most stable software products in the "you can't afford it" catagory.
Well, I have several of them that have been up for 150+ days, brought down only for maintenance. Both hardware and software seem to work exceedingly well. Much like sparc-sun-linux machines, I never even think about my mips-sgi-irix6.5 systems. They just work, and are damn fast. YMMV I guess, but they work fine for me, far far better than any peecee I've ever seen. If I've got to have something I can't afford, I'd rather it work.
Your attitude, and the knowledge that many others share it, have convinced me that Stallman made an error when he wrote the GPL. It should add in a simple clause that states that you cannot use GPL'd software to call, link, load, execute, build, or manipulate closed-source software. IOW, a pure system requirement. You're all going to throw away twenty years of work.
No, it is not. It makes Linux a lower quality, less usable environment. Why? Well, if you buy nVidia's products, and use their binary-only drivers, you are sending the message that that level of support (ie practically none) is acceptable. If every hardware vendor offers drivers under the same license, your once-stable unix-like operating system has become the hell that is NT. Worse still, do you really want to get yourself in a situation wherein you can't upgrade your OS (let's say a major security hole was found and patched...) because you're tied to a binary-only driver? Bottom line: binary-only ANYTHING is BAD, BAD, BAD.
It is good for Linux users.
No, it is not. See above.
It shows that Linux is being treated equally among OSs. nVidia wouldn't release their source to Microsoft, and they aren't doing it for the OSS community.
How is this good? The purpose of Free software is not to gain a place in the proprietary software world as an equal to Microsoft's offerings!!! It's to be a fundamentally different, and better, way of using computers.
Ultimately, however, it is their decision, and it is up to them what they want to do with their work.
On this, at least, you are right. And, in exactly the same way, it is your choice whether to give them your business. Not me, man.
Do any of you care about speed? Voodoo 5 has already shown to be only moderatly faster than a GeForce but you'd prefer an open Voodoo, rather than a closed GeForce 2? Doesn't anyone care about SPEEEED!?? :)
Your argument makes no sense. Voodoo5 is faster AND more open than nVidia's offerings...where's the beef? Besides, if I really cared about 3d graphics speed, I'd go with either Sun's new Expert3d or one of many fine offerings from SGI. Sun and SGI may not offer source either, but at least their stuff is FAST and HIGH QUALITY. If SGI ships me a binary IRIX driver for (let's say) an Infinite Reality Engine, I'm pretty damn sure that it'll work and not crash my system. Do you really place the same level of faith in nVidia? Coding for a system they most likely don't understand well? Sure, kid.
REALLY? Cool, now I won't need my sparc-sun-linux hosted mips-dec-ultrix cross compiler any more! Or my Palm Pilot development environment! Or my 64-bit native Sparc compiler! Oh wait, VC 6 only runs on i386-pc-windows and, for that matter, only compiles for i386-pc-windows. And doesn't even do a very good job of that. Doesn't sound very functional to me. I suppose that if your definition of functionality is the size of the code it generates, or the number of ways it ignores the applicable standards documents, then you are correct.
gcc may or may not generate the best code of any compiler on a given target, but it generates good code on many many more targets than anything else, and since it's open source and quite portable, it's also usable on more systems than anything else. That's infinitely more useful to me than having the option to write noncompliant c++ and have it compile into a nice slow 300 MB winblows-only binary, which, if I use the right flags, might not be able to crash the OS more than once or twice a day. Functionality? I don't think so. And, yes, I've used VC. The editor sucks, the compiler is substandard, and the toolchain's portability is nonexistent.
My point was not that nothing else is functional; I personally prefer ******* or **** (names removed to prevent holy war), but my point was that Linux is infinitely preferable to Winders on technical merit, even if the marketplace behaviors were equally bad.
Oh, like the BSD license?
The whole purpose of a license is to protect the software and the programmer; at least thats the way I see it.
I see it differently. The purpose of the license varies by licensor. Microsoft wants protection for their profit machine, Red Hat licenses in a certain way to maintain their standing in the community, the BSD projects license according to tradition and their particular beliefs, and the GNU project licenses according to a very specific agenda. I could go on, but the point is made: there are many different licenses, each of which means something a little different to each entity that uses it (as a direct counterexample, the BSD license provides no protection for the programmer whatsoever). If the programmer desires protection, there are many licenses that can provide it in different ways, but that's not the only reason for licenses.
Naturally you are free to think whatever you like. But even if your worst fears are realized, you're left with the comparison of "nonfunctional software, no choices" and "functional software, no choices." Which is better? In any case, it's an academic question because Stallman has no power to restrict your choices. It's not like gcc has a special license restriction that applies the GPL to whatever you compile with it...
I know this comes off like a troll, but I can't believe the best example he could think of was StarOffice. This is easily the lowest-quality piece of software I've ever seen running on Unix (yes, worse even than netscape). Why not mention things like Oracle or some of the SGI tools? You know, software that actually works. On the other hand, this example provides some nice insight into why Caldera's distro sucks so much. Judge a man by his heroes?
The BSD license has had the advertising clause removed for some time now. In fact, there is not a great deal of difference between BSD and public domain now. In any case, honest individuals will always attribute their sources...
The question of "distribution" was raised and debated at length back during the Corel Linux beta debacle. I recommend you read that discussion if you want the split hairs.
Those users have paid Microsoft for a product. That product does not measure up to the promises that are made, and the users are not given the opportunity to correct the problems themselves. In the Linux world, you don't pay the developers, no promises are made about the software, and if there's something you want done you are free to do it yourself. If that means a fork, then it means a fork. At least you have a choice.
It has nothing to do with being abusive toward users. If all the users are doing is taking from the community without contributing (since most of them can't anyway), then I fail to see why someone who has invested his own time and effort into a piece of software that represents his view of correctness should be required to support these users by either working on or accepting patches that conflict with his own ideas. If you want something with UDI, you are free by virtue of the GPL to put out Fredix, or to pay SCO for it. If you don't like these options, tough. You have in the Free Software community a large number of people willing to give you something for nothing. If that something is of no value to you, then you've still come out ok. I fail to see the parallel with Microsoft; you pay them $500 for an OS and a web server that they promise will work, and then it doesn't work. Well, in that case you're out $500. You pay Linus nothing for Linux, which is delivered to you as-is; if it doesn't work, so what? Where along the line did you acquire the right to insist that he add UDI (or anything else) to his operating system for your benefit?
The way I see it, Linux belongs to Linus. It is his OS; he has generously allowed you to have, use, modify, and redistribute the fruits of his efforts, as have all the other hundreds of major contributors. If it's useful to you, great. But it still belongs to them, and if they don't want your changes in it, that's their right. They owe you nothing.
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
To this end, BTW, documenting that behavior in detail is a valuable step but all too rare in the Linux world. Documenting dependencies on specific behavior would be nice too.
It's happening. Look in the latest 2.3.99 versions; parts are being documented in DocBook format.
For example, as a filesystem developer I can only shake my head at the Linux VFS and buffer-cache layers.
Try 2.3. You aren't the only one who thought the old way sucked.
What's missing is a widespread recognition that the most important reason to protect code from change is the importance to other components of maintaining its current behavior even in small details.
No. The most important reason to protect code is that it is correct, fast, and maintainable. While one correct, fast, and maintainable solution can be replaced with another that is easier to interface with, no decrease in correctness, performance, or maintainability is considered acceptable. It's true that some of the kernel hackers have axes to grind in some portions of the code. This is true in any project. Unlike closed-source projects, Linux offers you the opportunity to go off on your own, implement what you want, measure its performance, and post your results.
Unfortunately, doing this usually requires foresight in the _original_ version of the code, leaving room for versions or capability flags so that both called and callers know which behavior to expect or provide. Sadly, the code most in need of an upgrade is inevitably also most marked by lack of programmer foresight.
This type of thing has a name: cruft. Programmer foresight is a nice thought, but nobody can think of everything. Everyone tries anyway. The nice thing about Linux is that when a failed effort to think of everything starts to cause problems, it gets replaced. In the proprietary world it stays around forever (IDE, the 640 limit, the list goes on).
>In Solaris or Windows, where most people don't get decent performance anyway That's a pretty offhand and inaccurate statement, at least for Solaris. It's not great, but neither is Linux.
Look, I've used Solaris. I admin it sometimes. It sucks on SPARC, and is simply godawful on x86. I bitch at Linux too, sometimes for other things (like NIS), but when it comes to Solaris I gripe about performance. It just sucks.
By significantly reducing the amount of work needed to produce something that can realistically be called "Linux support." Producing a fully native Linux driver requires significantly more work and knowledge than taking the UDI boilerplate code and throwing in the microcode for your device's ASIC. Producing a UDI driver (or letting someone else do so for their own proprietary OS) and then saying look, it works with Linux is much easier. It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
By asking this question you illustrate your lack of understanding. The point is not that keeping UDI of of the mainstream Linux kernel somehow prevents proprietary practices. Rather, if UDI is put in (ignoring for a moment the substantial body of technical reasons it should not be), and vendors begin providing the same low-quality binary-only drivers for Linux that they do for 'doze, the new Linux users unaccustomed to our high standards will accept these inferior drivers. Once they have done so, there will be less motivation than ever for hardware vendors to provide documentation ("Why do you need the docs?" "To write a Linux driver." "But we already provide one! See, here - foo4355.o; it works on UP Red Hat 7.2 on Intel only" "But I have a Sun and I run Debian" "You need foo4355.o for Linux"). Don't kid yourself - this is guaranteed to happen. In fact, it's already a problem because binary modules are allowed at all. Thankfully the developers refuse to support kernels with binary-only modules loaded. Still, UDI will only make the problem worse.
Thanks for making this point so succinctly. To answer the rhetorical question, essentially none. :)
I do not care how much or how little market share Linux has. Whether someone else uses it means nothing to me; I can continue to use it as I please even if every single other person stops using it. Welcome to Free software.
More users result in more developers. More developers result in more support. More support results in more things that you want for your OS.
I don't really think this is true any more. The type of new users Linux is attracting today doesn't know a stack frame from a superblock, and doesn't intend to learn. These people aren't kernel hackers. They aren't applications developers. They aren't even helpful bug-report-submitting users who understand what quality software is all about and are proud to help it along in some small way. In other words, unlike previous Linux adopters, they take, take, take, and give nothing back. From a developer's point of view, these people do nothing to help the process of making a great system; all they do is clutter up mailing lists with useless bug reports and inane feature requests. New projects? Yeah, right. Patches? Don't hold your breath.
Even if these people were useful developers, they wouldn't be able to help much with the issue at hand, device support. Today's support for devices is limited by documentation, not coders. Help is always appreciated of course, but one more programmer's manual would make a lot more difference than one more developer.
You can ... sign mass petitions to get a native driver.
I don't do that. I vote with my currency units. No open source? No specs? No money, then. Petitions are for whiners.
To be more precise, the Linux purists are afraid that Linux users will be satisfied with the UDI drivers and won't be as eager to join mass driver movements.
These people were satisfied with windows six months ago!!! Of course they'll be satisfied with UDI drivers; they'd be satisfied with three tons of steaming shit and a more comfortable chair. The nice thing about Linux is that the people who make it won't be satisfied with UDI drivers. But these "mass driver movements" you mention actually have very little to do with getting native drivers written. In fact, what usually ends up happening is that some competitor gets wise and mails a manual to some hacker who then writes a driver. The hundreds of petition signers don't know how to write drivers and in most cases are probably just following the Slashdot crowd anyway ("what's the petition for? d00d, it's a driver for the Mumblebazco Vapourware 5200!!! The WHAT? Oh well, I'll sign anyway.")
If you don't want users to be complacent with UDI drivers, then tell them so.
Right. "That driver offers 30% suboptimal performance!" "So? It plays quake."
But don't take away the choice just because you're too lazy to do it.
But you see, we don't write this code for others. We write it for ourselves, and share it with others because we feel it's the right thing to do. We don't have any responsibility to the users whatsoever. For the 99.8% of us who write Free Software and don't get paid for it, the fact that some user wants UDI means nothing. The simple fact is that the people who generously volunteer their time and skills to work on these projects have earned the right to decide what goes in and what does not. And UDI will not. Not because we're too lazy to do it (not that it would matter even if we were; we owe you nothing), but because we don't think it's a good idea. If you want UDI, you're free to write it yourself and maintain your own tree. Did Linus wait 10 years for Tanenbaum to open-source Minix? Did RMS sit around and wait for all the proprietary software vendors to collapse? Of course not. They rolled up their sleeves and got to work. Unlike them, you aren't forced to be a pioneer; you'll find a ready and willing crowd of people to test and maybe even contribute to your project. You can even get free project hosting if you want it. In fact, all you need to provide are your skills and time.
There are only two ways to ensure you get what you want: pay someone for it, or do it yourself. Berating volunteers for being "too lazy" to give you what you want, against their own better judgment, is rude and selfish. Stop and think for a moment; if you felt UDI were a bad idea poorly implemented, would you want it in a world-famous product that bears your name?
I do, unapologetically. If you don't release specs so that an open source driver can be written, I won't buy your product. It's just that simple. It's unfortunate that some people won't switch to a Free operating system because they have hardware that isn't supported, but their annoyance and indignation - and that of the people who have to explain this to them - should be directed at the vendors, where it belongs, rather than at the legions of volunteers who have written excellent drivers for documented hardware. Compromising with the devil is rarely a profitable exercise. I would much prefer Linus to announce today that he will no longer allow binary-only drivers.
A driver version should not be tied to a kernel version in the first place. With a well-defined API (i.e. UDI), this sort of backward-compatibility and forward-compatibility will work and should be encouraged. Needing to rebuild every driver because you updated the kernel is a waste of time and effort, especially when the drivers need updates to match kernel changes.
No. Firstly, kernel source PIs do not change within a stable series. But what you are forgetting here, since we're talking about binary compatibility now, is that Linux has no consistent or guaranteed kernel binary PI. That's right, none. Linus and everyone else doesn't see the need, and I wholeheartedly agree. Linux is an open source operating system, and the source KPI is guaranteed within a stable series. So given driver source, there is no issue here. The kernel hackers can feel free to make changes that break binary module compatibility, and it only harms binary-only drivers. Big deal. If a change needs to be made, it needs to be made. And if that change happens to annoy Big Proprietary Hardware Vendor Inc., tough shit.
It only hinders development if poor API's were chosen to begin with.
Only as long as those PIs continue to exist. In Linux, when it's determined that an existing KPI (it's not an API if they're not applications after all) sucks, it gets replaced in the next development series. We can do that in an open source world. Your proprietary binary-only world prevents those kinds of changes and instead encourages setting arbitrary limits like the ones you mention ("since we can never change it, we'll just make it as high as we think is necessary today"). In fact, it is the anchor of binary compatibility that holds you to the rocky bottom of 1980's OS technology.
Jury's still out on performance. [UDI]
Not really. Alan Cox has explained in several l-k posts, in detail, why UDI drivers, in Linux anyway, cannot have performance equal to their native counterparts. In Solaris or Windows, where most people don't get decent performance anyway, UDI sounds like a good idea. But in Linux, wherein crazy socially maladjusted individuals pride themselves on removing one cycle from the kernel's execution time, any penalty is too much. The rationale is simple: our OS kicks the living shit out of yours; why should we be the ones to change to your driver model? I have yet to hear a good answer to this question.
Untrusted drivers could be loaded into userspace and run slowly but safely. After they've proven themselves, the user/sysadmin could choose to allow the driver to run in kernelspace for performance. Best of both worlds. (This switching could potentially even be automated...)
Right. So on my production system, I have three choices: a userspace UDI driver that most likely won't crash my system but will run so slowly that nobody can get their work done; a kernelspace UDI driver that will do God-knows-what to my system; and a 7-year-old battle-tested open source native driver held together by volunteers who know their device better than the people who made it. Guess which one I'm going to choose, even if it means using different hardware?
UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support.
This is not a bad point but for one thing: if the people who use those OSs want, they can take a driver from another open source OS and port it. The real "best hope" is for every piece of hardware to have available a programmer's manual. Linux is where it is today because many people felt it was a good use of their time to write drivers for hardware that wasn't previously supported. The same can be said of FreeBSD and other projects as well. If nobody feels that writing a HURD driver for some odd hardware is worth doing, then it won't get done. In 1992, nobody picked up Linux and started using it because it supported their hardware. In fact, some of them picked it up because it didn't support their hardware.
Too much is made today of how to get the computer-illiterate digital have-not GNOME-wanting RedHat-investing Luddite fuckwits to come use our great new wonderful OS. Am I the only one who doesn't really care whether they do or not? Linux is for the people who make it. If someone else finds it useful and wants to use it, they are free to do so by virtue of the license. But it's not the responsibility of the kernel developers to put in support for every two-bit half-assed self-serving proprieatry piece of crap "standard" that comes their way. In fact, in most cases, it's not their job to work on Linux at all. They do it because they choose to, not so that you can feel all warm and fuzzy telling all your 1337 friends how well it supports your brand-new XFR3-5432DSA fuxor card.
Of course, this cross platform thing would be useful for making sure there is support for as many possible platforms ASAP, then optimised platform specific ports could come at a later date...
Yes, where "later date" == "never". You're ignoring the lessons of history. If it's "good enough," it'll stick around forever and its vastly superior replacement will never see the light of day. It's happened way too many times. How else do you explain people willingly buying a 16-bit operating system for a 32-bit CPU that can't compete with its 64-bit competitors that have been around for five years? Good enough indeed.
The problem with this product, as with UDI, is that performance suffers. The linux people refuse to take part in UDI for a number of various good reasons, which can most simply be expressed as "the performance sucks rocks." See also a similar discussion based on a misunderstanding of ImageWorks new WAN code. Essentially, the concept of providing a common binary interface to multiple different kernels - be they different systems altogether or simply different, incompatible versions of the same system - is an old one, something of a Holy Grail to some people it seems.
The bottom line is, hardware vendors who refuse to open up the specs to their hardware are always looking for a way to provide as much "checkbox" operating system support as possible without actually doing any work or participating in the development community. There's an important technical downside as well, besides the poor performance these abstractions cause: if a vendor writes a poor winblows driver, then ports it to $favourite_os, what do you think this does for the stability of $favourite_os when the driver is loaded? That's right, it goes to hell. Microsoft has said for a long time that the stability problems their platform is known for are caused by third-party drivers. While I don't believe that's the whole story, they have a legitimate gripe here. If someone takes that same driver and loads it into Solaris, Linux, or vxWorks, they're going to suffer many of the same problems they would on winblows.
So no, this isn't as good as it sounds. Linux especially is rejecting such ideas from its mainline tree, but it's important that people also be aware of what their distribution vendors are shipping - it might be too tempting for one of them to say, look we can support winmodems but we'll have to add this proprietary cruftware patch to the kernel; it sucks but we'll be the first so let's do it. I'm wondering more and more whether Linus is regretting his binary-only module license exception.
No x86 processor is good for anything. If you're really asking about realtime stuff, you want Motorola 68k-based microcontrollers. If you're really asking about high-end scientific computation, you want MIPS, SPARC, or Alpha depending on the specific properties of the work involved. If you really mean "I want to do high-end scientific computation in real time," for example, simulate a nuclear bomb explosion in real time, I don't know whether to laugh or recommend a large area such as Asia stacked eight deep with SGI Origin 2000s. Rephrase your question please.
The Onyx2 is a piece of crap. Try a Power Challenge or Origin system instead. I never have problems with mine. Alphas are nice, but there's nothing wrong with SGIs. Ultra 10? I stand before you, laughing hysterically in a mocking way. Let me guess, you run Solaris on it too. Free clue: don't venture off Slashdot; people elsewhere won't be so easily confused.
Get a product people care about maybe? Nobody cares about thin clients because, even though buyers want them, nobody wants to sell the hardware. In order to make a compelling case for thin client hardware, it has to be significantly cheaper than the alternative. Cheap computers have terrible margins, so hardware vendors don't want to bother. And thus SCO finds itself up shit creek, and the Penguin swimming upstream came along and grabbed the Unixware paddles.
This attitude of "open source it!" is senseless. Has it occurred to anyone that maybe the reason open source software works so well isn't that it's open source but rather that a real person, not a committee or focus group, saw a need - usually his own - and started hacking up a solution? A product that doesn't meet any need will be no more successful just because the license has changed. That doesn't mean that some sort of procedure by which a failed company's IP becomes automatically open to the world would be bad. But counting on open source to save your ass from a bad product decision isn't the right approach, and it doesn't work.
Really? I don't think so. I think they can gain little but lose a great deal. The ultra-low-end market is their strong point, which will be totally unaffected by IA64 for at least 5 years. The high end, which is supposedly targeted by IA64, already has a strong competitor, Linux. If M$ gets their act together, they can possibly hold their current market share. If not, their days of producing anything but low-end software for home users will be over. They aren't going to gain much, no matter what happens. First, Itanium won't offer the performance of its "traditional server vendor" rivals. So it's not going to grab much share from them, if any. Most of the IA64 share will come out of the existing peecee market. People running Linux on peecees aren't going to run out and buy M$ for IA64. The most M$-optimistic outcome is that current enntee users migrate en masse to IA64/enntee. In which case M$ holds its current market share, which, in this environment, isn't very high (37% or so last I saw). If any current enntee/peecee user needs more performance but is unwilling to leave Intel, he may find that his only choice is Linux - that is, if M$ doesn't get their IA64 OS done in time. In that case, M$ loses more market share to Linux and misses the opportunity to gain a foothold in the IA64 world.
So what can they gain? Not much. They might convince a few of the dumber IT manglers that Itanium + enntee can compete with traditional high-end solutions, or maybe that it's better than Linux (unlikely given current trends), but this certainly isn't going to help them very much. At best, they stand to gain a very small chunk of the market. At worst, they stand to lose their entire presence in the non-home market. Given this fact, I join you in surprise at their decision making. Not because they have so much to gain but because they have so much to lose.
If anyone comes out of IA64 a big winner it will be Linux, which will be the only option that runs on current peecees, future peecees, and the majority of the workstions/servers using non-Intel CPUs as well. It certainly won't be M$, and it probably won't be Intel. During this time I fully expect Intel to lose a good chunk of their customers to the traditional RISC vendors (Sun, SGI, etc) and people like IBM. Itanium will flop initially at least, and Intel isn't going to come out of it looking good. Nor is AMD, especially if this Sledgehammer really represents their primary plan.
I sorta wonder if the whole "Sledgehammer" hype is just FUD smoke that AMD is blowing at IA-64.
Seems like a pretty good theory. But I'd FUD better than that if I were AMD. Of course, there are plenty of good reasons to have F, U, and D about Itanium that have nothing to do with AMD.
I do not see the poor x86 performance as a serious issue. GCC has already been ported to produce native code, and Linux is ready to go. There is presumably a bit of glibc work left but I fully expect that a full native distribution will ship the same day as the CPUs. Full native == no x86 performance problems, and full native == full software availability. The real problem with Itanium is that its performance is going to disappoint, even in native mode. By the time Intel works out the problems inherent in any new processor, not to mention the problems with their supply chain, their competitors will be well ahead of them, shipping stable, mature products with superior performance and, thanks to not having to supply two chips in one, at lower cost as well.
Add a little "64-bit" gloss to Windows 98, and AMD might gain some serious market share here.
Who's going to do this? Microsoft doesn't have any incentive to do it; they're already selling all the winblows 98 they want. They're going to be far too busy trying not to lose their shirts to Linux in the IA-64 sphere to give two shits about a warmed-over 64-bit AMD with miniscule market share. Anyone expecting to see winblows on native Sledgehammer is in for a nasty surprise. Linux probably will be ported at some point, but by that time I doubt it will still be in production.
If it's priced the same as Intel's 32-bit chips
It won't be. You know it, I know it, AMD knows it.
On the other hand, if it's more expensive than a 32-bit chip and doesn't offer any real advantage to the average user, what's the point?
Bingo. This is a product in search of a market. The engineers (and probably the lawyers too, but that's just rampant speculation) told the droids that it would be easier to produce a 64-bit x86 processor than an IA64-compatible one. So that's what they're going to do. I don't think AMD ever even considered something non-Intel compatible, it was more a question of which Intel to be compatible with. They just wanted to say "we have a 64-bit processor too." Well, big deal, AMD; everyone has a 64-bit processor these days. Having the weakest one of all isn't going to turn any heads, unless it's at the next shareholders' meeting.