> IP protection of compilation. RMS hates the latter, but it's the basis of the 21st century economy
Based on what you can affirm that? For what I see IP protection is a stumbling block to Economy and Liberty alike. I would rather say information sharing is the basis of both Economy and Society itself.
Anyway it's bad practice trying to predict what will come, and even less the whys and hows of it.
I have my own experience. With Microsoft you learn the interfaces, and never know what's really going on. With free software you have documentation in several levels, down to the source code, so you can always debug and troubleshoot to your heart's content.
Anyway, most computing books are trash anyway... exceptioned the usual Knuth, Djikstra, Date, Darwen, Pascal, Codd, and assorted others.
I did a superficial investigation on source control systems, and found some very interesting really free ones, like Aægis.
Does someone know if free alternatives to BK were considered, and if so why a semi-free one was choosen? If BK was better, specifically how it compared to Aægis and other alternatives?
My point about ARM is that it is part of consolidation, not diversification -- at a time you could have workstations with so many processors, now only Intel, PowerPC and UltraSPARC have future, only Intel is really safe in numbers and UltraSPARC seems to be forever confined at the Sun solar system. Once you had so many processors for PDAs, now only StrongARM has mindshare.
As for LISP, unfortunately it is not so advanced in definition of services -- for RMS and others LISP is the right foundation, but hasn't got so sophisticated envelopes yet. But LISP with Gnome, yum yum...
Apt is the backend... the desktop user has gnome-apt.
I haven't said Debian is already here for the end user, but it has the right foundations -- dpkg, apt and sane policies. The rest is (necessary, already late, but in development) window dressing.
The GNU/Linux port would make the PS2 part of a viable marchitecture, just as XBox is part of the Win32 marchitecture.
Yes, PC games are buggy -- but the whole point about the XBox, besides being a cheap, legacy-free PC that hooks to a TV and has superb graphics but everything else low-cost, is that it is a controlled, stable environment, where it is much, much easier to debug; this has nothing to do with hardware, but with drivers, libraries, APIs.
Re:How could Alpha benefit IA64?
on
Intel's Big Chip
·
· Score: 2
You missed the point -- the best Alpha engineers never arrived at Intel, they left when Compaq announced Alpha was dead.
You couldn't be wronger regarding SMT. You got only the name right. What IBM and Digital proposed as SMT is precisely what Intel marketing calls HyperThreading.
The VM is only important if platform diversity gets back to the end user environment -- today it is absent except for the IA-32 on the desktop / StrongARM at the PDA division -- *and* if users have nothing like dpkg to help them install already compiled packages.
Also, RMS ultimate plan is the resurgence of Lisp and Scheme running over the Hurd... that would also preclude the need for much compilation, and would be a helluva development and user-extension environment.
1) You need more people to take care of Microsoft boxen than with free software;
2) Microsoft security updates are usually late, and they can break even programs running from IIS itself, like Mercury Interactive's TestDirector;
3) You need many more Microsoft boxen than free software ones;
4) It's easier to learn with free software, and no you don't need to know how to compile kernels. Editing conf files is trivial, and is also necessary in the Microsoft world. In fact easier and safer than editing the Windows Registry.
Red Hat won't probably ever be in the desktop, because it is hard to manage with its rpm system. But once it's ready with a nice installer and a good selection of polished packages, with a manageable system there's no reason why IT departments wouldn't love to deploy GNU/Linux... and once people get used to it in the work, the home market is a given.
You forget XBox is a 1.0 product... Microsoft will keep trying until XBox 2.005 (supposing one revision each three years) finally succeeds because Sony failed to open enough the PS line to make it viable as a platform.
The fact is that XBox gets lots of crosspolination from PC games, and is poised to get even more as the world upgrades to XP, thus converging the platforms... OTOH, Sony attempt at making PS2 a viable platform is half-hearted, since PS2 still lacks some goodies that come standard with XBox, the Linux port is half-hearted due to the proprietariness of the hardware specs, and anyway it's not a standard (RH-compatible, Debian or Slackware) distro.
I've never seen a good explanation of how Alpha concepts could possibly benefit the IA64 architecture. Usually it's only talk about HyperThreading, which is just Intel marketspeak for SMT (Symmetrical Multi Threading) a feature long ago promised for the Alpha and PowerPC product lines -- and a marginal improvement more related to packaging and manufacturing than an architectural feat.
I fail to see how Alpha could benefit IA64, since the fundamentals underlying the two different architecture are quite opposite -- changing IA64 to be more like Alpha would give us probably a worse Alpha or a not so bad IA64, but would fail to realize Alpha's promise of a clean, balanced architecture, and so would be mediocre compared to PowerPC, perhaps UltraSPARC and probably to what Alpha, PA-RISC and MIPS could have became weren't them orphaned.
In fact, it seems to me that even a hypothetical SMT StrongARM would run faster and cooler than an equivalent cost and size IA64. But that's only my quite uneducated guess.
Re:What I've always wondered ...
on
Intel's Big Chip
·
· Score: 2
First, pride. Not invented here syndrome -- while Intel has already digested some external technology like the StrongARM, still their engineers must have some pride left -- and big ones, since the best engineers have already left and the mediocre ones tend to be the proudest. Also, it's not Intel only, but Intel and HP, so if Intel would shift everything to the Alpha HP would have to agree on that.
Second, dumbness. VLIW probably isn't a good idea anyway to general purpose microprocessors, and while EPIC tries to address some VLIW shortcomings it makes for a pretty complex architecture which negates some of the VLIW proposed benefits. The picture gets still worse if you throw in IA32 compatibility.
Third, they own the design, but once again the best engineers left the company. No self-respecting engineer wants to work for Intel, they have a long history of abusing employees and imposing dumb management decisions on technicians for a long time now, in their branchs all over the world.
So the only sane architectures left with a future on the market are PowerPC and UltraSPARC. Sad but true.
You would have gotten it right if you said my entire reply is really just evidence of why Debian wasn't chosen. Way too much principles.
As for Database Debunkings, it isn't supposed to look like anything -- it's all about content, not looks. These guys aren't academic at all, they are simply the maintainers of the relational model for database management after EF Codd stepped down in the early nineties. Try to refute them, you will see what's logics and reason itself.
As for GNU, BSD uses GNU software but wasn't built around it; for example, what defines the common interface for the OS is its C library. BSD has its own, ancient and efficient libc, GNU has glibc for both Linux and the Hurd.
FSF and GNU zealotry, not technology? Could you live without gcc, glibc, Emacs, just to name a few? Have you ever taken a look at http://www.gnu.org./software/software.html? Have you any idea about the importance of the GNU GPL?
Being stable is not about feature. It's about being stable, and if 2.4 crashes and Alan Cox say so, who are you to decide otherwise?
The fact is that for most applications 2.2 is OK, and for the most demanding ones 2.4 isn't quite there yet.
1. You didn't do your homework, did you? Ever heard of gnome-apt, console-apt? There are probably others also. Also this is barely relevant at a business desktop environment, where you would want control over the configurations, and do everything from a central location anyway, probably sharing/usr and/home from central file servers at each LAN.
2. You miss the point... obviously RH is not "horrible", after all it's still GNU/Linux. The point is that it is suboptimal: forking, not sending patches to upstream maitainers, relying on proprietary software, calling it just Linux -- not only the base system is the GNU one, there's much more to the kernel there. And the point is that commercial enterprises relying in rpm formats tend to duplicate efforts at the distribution level, while companies relying on Debian -- The Distro Formerly Known As Corel, Progeny, Libranet -- tend to contribute more and avoiding forks. Even forks themselves in Debian are more of "unstable-unstable branches" whose objective is merging back to Debian. Last but not least, Debian is more distributed -- there's a community of individuals, projects and companies doing the distribution itself, companies to support, to burn and/or distribute CDs, and so on.
3. Business friendly all too much often means technically mediocre... witness the Database Debunkings of SQL, and similar comparisions of academic or community initiatives like functional programming against company-sponsored buzzwOOrd-compliant technologies...
Anyway which are the "so many Debian-based distros"? They are much less in number than rpm ones, they are far less divisive, and tend to exist for a shorter time, folding back when their technologies get integrated into the main distro -- witness Progeny and Debian-jp; on the other hand some of them are simply specializations, like Debian-jr and demudi.
You also miss the point that Debian only makes the distribution; support is left to independent companies. In fact Debian welcomes these independent support companies, as well as derived distributions.
4. You must be too young... many billionaire companies have came by and went away in the History of Computing, few remained: basically IBM and HP... Compaq and Microsoft are too young and bad models anyway. Meanwhile since non-profit organizations began in the late sixties ACM, Usenix, the X Consortium (and its son XFree), the FSF all still exist and are in good health (all right, X and the FSF are also younger)... not to mention informal organizations that create and maintain software like TeX and LaTeX, the Linux kernel itself, and so on.
The fear about organizations and reliance on business is mislead, because business are also organizations -- the difference is between profit and non-profit. Non-profit organizations tend to be much better targetted, focusing on specific goals and existing as long as the goal is worthy pursuing -- perhaps less, perhaps longer, but not as erratic as profit organizations. Witness the churches and national states as opposed to the Leagues, the Hansa, the Companies of the Indias, and so on. This fear is due to the irrational fear of the other, and so should be confronted, not regarded.
Finally, you subestimate the complexity of software... the simple fact is that 2.4 still not stable, no matter how much testing.
I know these realities, and I know how deficient are sysadmins -- but the fact remains, and you couldn't refute it, that business systems have preconfigured CDs that don't use the install systems at all, so that's not an issue.
Not to mention that GNU/Linux seldom needs reinstallation -- Debian in particular, if properly handled, never.
HP could provide support for Debian because (1) it makes for better manageability and reliability, therefore less support costs and higher-quality products and services and (2) because investing in Debian benefits the whole community, not only some companies that are potential future competitors. That seems far-fetched now, but that the producer of Micro-Soft BASIC would be a competitor to IBM also seemed so.
Obviously the bug fixing should be accelerated to allow a faster release cycle, but here's something that HP, and other companies could help. In fact, as the Debian community debugs the process, additional users and attention will tend to get the releases done faster as there will be more bug fixes. Moreover, once there's some (undefined) critical mass Debian could possibly become so important as to warrant more attention from the upstream software maintainers, and that can only help obviously. Bear in mind that many bugs fixed by Debian (and OpenBSD also, BTW) are really quality problems in the original software, so that which keeps Debian release cycle so slow also makes other distros low-quality.
You also misses the general picture of technical excellence: once people taste the excellence of Debian, usually they run to it once they get disillusioned with the low quality of other distros... they realize the way is to help Debian in its shortcomings, not divert efforts to dumb corporations. Sorry, I'm calling Red Hat dumb, but what else you call the company who created rpm instead of helping finish dpkg?
Finally, the adoption of Debian in the desktop would have the side effect of educating users and particularly sysadmins to the benefits of the good policies that form Debian's core... that can only benefit everyone.
Have you ever used a business system? You *never* run the operating system generic install... the system integrator creates a CD that does a customized installation complete with system-specific drivers and default configurations.
Anyway, if a SysAdmin doesn't appreciate the flexibility of the Debian installer and doesn't create his own automated configuration for it, he's not worth the salt he eats...
It seems you missed the whole point... having Debian preinstalled would automagically solve its biggest problem, which is the installation process -- basically the base system and X (at least) would be preinstalled, and then the sysadmin (that may happen to be the user) would just care about running gnome-apt or some similar apt front-end. Less headaches for both the sysadmin and HP's support.
That said, the truth is that as desktop GNU/Linux is still evolving desktop users typically need some cutting edge packages, and Debian release cycle makes even testing somewhat outdated... nothing that a corporation like HP couldn't help by dedicating some top-notch programmers to bug fixing.
BTW I'm totally against the idea of "each user, a sysadmin"... we're talking business desktops, these should be controlled by internal help desks, not its users -- unless the user is a programmer or system analist himself, in which case he's probably capable of administrating his own system.
Obviously the ideal would be dumping PCs and have everyone but technical staff running X terminals hooked to big, mean RISC machines...
First, obviously any minimally decent relational-like, even SQL database is better than any non-relational (object, hierarchical) one &ndash& before proceeding please read Database Debunkings. So substituting MS SQL Server for NTFS should be A Good Thing(tm).
Second, SQL isn't a good implementation of the relational model... so it doesn't matter what's the management system behind it (MS SQL, DB/2, Oracle), if it's SQL it's not ideal -- a really relational system should be faster, have less arbitrary restrictions, and do everything a hierarchical or OO database management system could possibly do. But still SQL would be far better than any hierarchical or OO filesystem.
Third, as a SQL implementation MS SQL isn't quite ideal, and Jet (Access, Exchange, the registry) is simply horrible. So while this will probably improve Windows feature-wise, it will make Windows even more bloated, perhaps even less stable and slower. But if they manage to fix the database engine, it could even make Windows faster and more stable.
Fourth, this has already been done. By Oracle. It's called iFS (sorry but I couldn't access Oracle site to get a better page), and exports SMB and other filesystems. As Oracle is too big, proprietary and isn't even SQL compliant, and iFS does not support NFS, I didn't care much about it, but I may have an opportunity to use it as a kind of version control for binaries very shortly.
Last but not least, this idea should be adopted by the Free Software comunity ASAP. We should create a really relational implementation, ideally based on Tutorial D -- there's already a SourceForge project, but nothing has been done up to now. Then this would became a Hurd filesystem (because of Hurd's flexibility) to be ported to Linux. That would blow Longhorn out of water.
If we don't do it better than Microsoft, and if computers continue to get faster and Windows less unreliable, we could have serious competition, say some two or three generations after Longhorn.
Yes, you got me -- I was confused about Darwin and Mac OS X. The 96 MB figure applies to Mac OS X, not Darwin -- I knew that but my reasoning broke like Microsoft Windows.
Anyway, Darwin is bloated yes -- it incorporates Mach in the BSD kernel for no good reason, since it takes no advantage neither of microkernel's best characteristic, that is flexibility nor of BSD, which has speed and leanness; this combination robs Mach of flexibility and BSD of its speed. It is a monolithical microkernel, because it has a single server.
OTOH Hurd is a true microkernel, flexible because of its multiple server architecture. Please go read the Hurd introductory documentation...
The free market failed us here... if it was really free, not conditioned by information hoarding (closed, proprietary software, protocols, file systems, hardware interfaces) we'd be running a real 64 bits RISC processor that needed no cooling in our desktops, notebooks and PDAs... this is the history of a obsolete specification enduring too long -- like Windows, BTW.
Slashdot Mirror
> IP protection of compilation. RMS hates the latter, but it's the basis of the 21st century economy
Based on what you can affirm that? For what I see IP protection is a stumbling block to Economy and Liberty alike. I would rather say information sharing is the basis of both Economy and Society itself.
Anyway it's bad practice trying to predict what will come, and even less the whys and hows of it.
Freedom is more important. Specially if there are alternatives.
I have my own experience. With Microsoft you learn the interfaces, and never know what's really going on. With free software you have documentation in several levels, down to the source code, so you can always debug and troubleshoot to your heart's content.
Anyway, most computing books are trash anyway... exceptioned the usual Knuth, Djikstra, Date, Darwen, Pascal, Codd, and assorted others.
I did a superficial investigation on source control systems, and found some very interesting really free ones, like Aægis.
Does someone know if free alternatives to BK were considered, and if so why a semi-free one was choosen? If BK was better, specifically how it compared to Aægis and other alternatives?
My point about ARM is that it is part of consolidation, not diversification -- at a time you could have workstations with so many processors, now only Intel, PowerPC and UltraSPARC have future, only Intel is really safe in numbers and UltraSPARC seems to be forever confined at the Sun solar system. Once you had so many processors for PDAs, now only StrongARM has mindshare.
As for LISP, unfortunately it is not so advanced in definition of services -- for RMS and others LISP is the right foundation, but hasn't got so sophisticated envelopes yet. But LISP with Gnome, yum yum...
I'm the troll but you are the AC.
Apt is the backend... the desktop user has gnome-apt.
I haven't said Debian is already here for the end user, but it has the right foundations -- dpkg, apt and sane policies. The rest is (necessary, already late, but in development) window dressing.
The GNU/Linux port would make the PS2 part of a viable marchitecture, just as XBox is part of the Win32 marchitecture.
Yes, PC games are buggy -- but the whole point about the XBox, besides being a cheap, legacy-free PC that hooks to a TV and has superb graphics but everything else low-cost, is that it is a controlled, stable environment, where it is much, much easier to debug; this has nothing to do with hardware, but with drivers, libraries, APIs.
You missed the point -- the best Alpha engineers never arrived at Intel, they left when Compaq announced Alpha was dead.
You couldn't be wronger regarding SMT. You got only the name right. What IBM and Digital proposed as SMT is precisely what Intel marketing calls HyperThreading.
Since when OpenStep was an UI? It was a development and deployment Objective C framework. Kinda Java but closer to C and without the VM.
BTW, OpenStep still lives -- now it's called Mac OS X and GNUStep.
The VM is only important if platform diversity gets back to the end user environment -- today it is absent except for the IA-32 on the desktop / StrongARM at the PDA division -- *and* if users have nothing like dpkg to help them install already compiled packages.
Also, RMS ultimate plan is the resurgence of Lisp and Scheme running over the Hurd... that would also preclude the need for much compilation, and would be a helluva development and user-extension environment.
1) You need more people to take care of Microsoft boxen than with free software;
2) Microsoft security updates are usually late, and they can break even programs running from IIS itself, like Mercury Interactive's TestDirector;
3) You need many more Microsoft boxen than free software ones;
4) It's easier to learn with free software, and no you don't need to know how to compile kernels. Editing conf files is trivial, and is also necessary in the Microsoft world. In fact easier and safer than editing the Windows Registry.
Red Hat won't probably ever be in the desktop, because it is hard to manage with its rpm system. But once it's ready with a nice installer and a good selection of polished packages, with a manageable system there's no reason why IT departments wouldn't love to deploy GNU/Linux... and once people get used to it in the work, the home market is a given.
You forget XBox is a 1.0 product... Microsoft will keep trying until XBox 2.005 (supposing one revision each three years) finally succeeds because Sony failed to open enough the PS line to make it viable as a platform.
The fact is that XBox gets lots of crosspolination from PC games, and is poised to get even more as the world upgrades to XP, thus converging the platforms... OTOH, Sony attempt at making PS2 a viable platform is half-hearted, since PS2 still lacks some goodies that come standard with XBox, the Linux port is half-hearted due to the proprietariness of the hardware specs, and anyway it's not a standard (RH-compatible, Debian or Slackware) distro.
I've never seen a good explanation of how Alpha concepts could possibly benefit the IA64 architecture. Usually it's only talk about HyperThreading, which is just Intel marketspeak for SMT (Symmetrical Multi Threading) a feature long ago promised for the Alpha and PowerPC product lines -- and a marginal improvement more related to packaging and manufacturing than an architectural feat.
I fail to see how Alpha could benefit IA64, since the fundamentals underlying the two different architecture are quite opposite -- changing IA64 to be more like Alpha would give us probably a worse Alpha or a not so bad IA64, but would fail to realize Alpha's promise of a clean, balanced architecture, and so would be mediocre compared to PowerPC, perhaps UltraSPARC and probably to what Alpha, PA-RISC and MIPS could have became weren't them orphaned.
In fact, it seems to me that even a hypothetical SMT StrongARM would run faster and cooler than an equivalent cost and size IA64. But that's only my quite uneducated guess.
First, pride. Not invented here syndrome -- while Intel has already digested some external technology like the StrongARM, still their engineers must have some pride left -- and big ones, since the best engineers have already left and the mediocre ones tend to be the proudest. Also, it's not Intel only, but Intel and HP, so if Intel would shift everything to the Alpha HP would have to agree on that.
Second, dumbness. VLIW probably isn't a good idea anyway to general purpose microprocessors, and while EPIC tries to address some VLIW shortcomings it makes for a pretty complex architecture which negates some of the VLIW proposed benefits. The picture gets still worse if you throw in IA32 compatibility.
Third, they own the design, but once again the best engineers left the company. No self-respecting engineer wants to work for Intel, they have a long history of abusing employees and imposing dumb management decisions on technicians for a long time now, in their branchs all over the world.
So the only sane architectures left with a future on the market are PowerPC and UltraSPARC. Sad but true.
You would have gotten it right if you said my entire reply is really just evidence of why Debian wasn't chosen. Way too much principles.
As for Database Debunkings, it isn't supposed to look like anything -- it's all about content, not looks. These guys aren't academic at all, they are simply the maintainers of the relational model for database management after EF Codd stepped down in the early nineties. Try to refute them, you will see what's logics and reason itself.
As for GNU, BSD uses GNU software but wasn't built around it; for example, what defines the common interface for the OS is its C library. BSD has its own, ancient and efficient libc, GNU has glibc for both Linux and the Hurd.
FSF and GNU zealotry, not technology? Could you live without gcc, glibc, Emacs, just to name a few? Have you ever taken a look at http://www.gnu.org./software/software.html? Have you any idea about the importance of the GNU GPL?
Being stable is not about feature. It's about being stable, and if 2.4 crashes and Alan Cox say so, who are you to decide otherwise?
The fact is that for most applications 2.2 is OK, and for the most demanding ones 2.4 isn't quite there yet.
1. You didn't do your homework, did you? Ever heard of gnome-apt, console-apt? There are probably others also. Also this is barely relevant at a business desktop environment, where you would want control over the configurations, and do everything from a central location anyway, probably sharing /usr and /home from central file servers at each LAN.
2. You miss the point... obviously RH is not "horrible", after all it's still GNU/Linux. The point is that it is suboptimal: forking, not sending patches to upstream maitainers, relying on proprietary software, calling it just Linux -- not only the base system is the GNU one, there's much more to the kernel there. And the point is that commercial enterprises relying in rpm formats tend to duplicate efforts at the distribution level, while companies relying on Debian -- The Distro Formerly Known As Corel, Progeny, Libranet -- tend to contribute more and avoiding forks. Even forks themselves in Debian are more of "unstable-unstable branches" whose objective is merging back to Debian. Last but not least, Debian is more distributed -- there's a community of individuals, projects and companies doing the distribution itself, companies to support, to burn and/or distribute CDs, and so on.
3. Business friendly all too much often means technically mediocre... witness the Database Debunkings of SQL, and similar comparisions of academic or community initiatives like functional programming against company-sponsored buzzwOOrd-compliant technologies...
Anyway which are the "so many Debian-based distros"? They are much less in number than rpm ones, they are far less divisive, and tend to exist for a shorter time, folding back when their technologies get integrated into the main distro -- witness Progeny and Debian-jp; on the other hand some of them are simply specializations, like Debian-jr and demudi.
You also miss the point that Debian only makes the distribution; support is left to independent companies. In fact Debian welcomes these independent support companies, as well as derived distributions.
4. You must be too young... many billionaire companies have came by and went away in the History of Computing, few remained: basically IBM and HP... Compaq and Microsoft are too young and bad models anyway. Meanwhile since non-profit organizations began in the late sixties ACM, Usenix, the X Consortium (and its son XFree), the FSF all still exist and are in good health (all right, X and the FSF are also younger)... not to mention informal organizations that create and maintain software like TeX and LaTeX, the Linux kernel itself, and so on.
The fear about organizations and reliance on business is mislead, because business are also organizations -- the difference is between profit and non-profit. Non-profit organizations tend to be much better targetted, focusing on specific goals and existing as long as the goal is worthy pursuing -- perhaps less, perhaps longer, but not as erratic as profit organizations. Witness the churches and national states as opposed to the Leagues, the Hansa, the Companies of the Indias, and so on. This fear is due to the irrational fear of the other, and so should be confronted, not regarded.
Finally, you subestimate the complexity of software... the simple fact is that 2.4 still not stable, no matter how much testing.
I know these realities, and I know how deficient are sysadmins -- but the fact remains, and you couldn't refute it, that business systems have preconfigured CDs that don't use the install systems at all, so that's not an issue.
;-)
Not to mention that GNU/Linux seldom needs reinstallation -- Debian in particular, if properly handled, never.
HP could provide support for Debian because (1) it makes for better manageability and reliability, therefore less support costs and higher-quality products and services and (2) because investing in Debian benefits the whole community, not only some companies that are potential future competitors. That seems far-fetched now, but that the producer of Micro-Soft BASIC would be a competitor to IBM also seemed so.
Obviously the bug fixing should be accelerated to allow a faster release cycle, but here's something that HP, and other companies could help. In fact, as the Debian community debugs the process, additional users and attention will tend to get the releases done faster as there will be more bug fixes. Moreover, once there's some (undefined) critical mass Debian could possibly become so important as to warrant more attention from the upstream software maintainers, and that can only help obviously. Bear in mind that many bugs fixed by Debian (and OpenBSD also, BTW) are really quality problems in the original software, so that which keeps Debian release cycle so slow also makes other distros low-quality.
You also misses the general picture of technical excellence: once people taste the excellence of Debian, usually they run to it once they get disillusioned with the low quality of other distros... they realize the way is to help Debian in its shortcomings, not divert efforts to dumb corporations. Sorry, I'm calling Red Hat dumb, but what else you call the company who created rpm instead of helping finish dpkg?
Finally, the adoption of Debian in the desktop would have the side effect of educating users and particularly sysadmins to the benefits of the good policies that form Debian's core... that can only benefit everyone.
Are you hearing, Bruce?
Have you ever used a business system? You *never* run the operating system generic install... the system integrator creates a CD that does a customized installation complete with system-specific drivers and default configurations.
Anyway, if a SysAdmin doesn't appreciate the flexibility of the Debian installer and doesn't create his own automated configuration for it, he's not worth the salt he eats...
It seems you missed the whole point... having Debian preinstalled would automagically solve its biggest problem, which is the installation process -- basically the base system and X (at least) would be preinstalled, and then the sysadmin (that may happen to be the user) would just care about running gnome-apt or some similar apt front-end. Less headaches for both the sysadmin and HP's support.
That said, the truth is that as desktop GNU/Linux is still evolving desktop users typically need some cutting edge packages, and Debian release cycle makes even testing somewhat outdated... nothing that a corporation like HP couldn't help by dedicating some top-notch programmers to bug fixing.
BTW I'm totally against the idea of "each user, a sysadmin"... we're talking business desktops, these should be controlled by internal help desks, not its users -- unless the user is a programmer or system analist himself, in which case he's probably capable of administrating his own system.
Obviously the ideal would be dumping PCs and have everyone but technical staff running X terminals hooked to big, mean RISC machines...
First, obviously any minimally decent relational-like, even SQL database is better than any non-relational (object, hierarchical) one &ndash& before proceeding please read Database Debunkings. So substituting MS SQL Server for NTFS should be A Good Thing(tm).
Second, SQL isn't a good implementation of the relational model... so it doesn't matter what's the management system behind it (MS SQL, DB/2, Oracle), if it's SQL it's not ideal -- a really relational system should be faster, have less arbitrary restrictions, and do everything a hierarchical or OO database management system could possibly do. But still SQL would be far better than any hierarchical or OO filesystem.
Third, as a SQL implementation MS SQL isn't quite ideal, and Jet (Access, Exchange, the registry) is simply horrible. So while this will probably improve Windows feature-wise, it will make Windows even more bloated, perhaps even less stable and slower. But if they manage to fix the database engine, it could even make Windows faster and more stable.
Fourth, this has already been done. By Oracle. It's called iFS (sorry but I couldn't access Oracle site to get a better page), and exports SMB and other filesystems. As Oracle is too big, proprietary and isn't even SQL compliant, and iFS does not support NFS, I didn't care much about it, but I may have an opportunity to use it as a kind of version control for binaries very shortly.
Last but not least, this idea should be adopted by the Free Software comunity ASAP. We should create a really relational implementation, ideally based on Tutorial D -- there's already a SourceForge project, but nothing has been done up to now. Then this would became a Hurd filesystem (because of Hurd's flexibility) to be ported to Linux. That would blow Longhorn out of water.
If we don't do it better than Microsoft, and if computers continue to get faster and Windows less unreliable, we could have serious competition, say some two or three generations after Longhorn.
Does HP's commitment to Debian mean that Debian will have the same (or similar) exposure as Mandrake in HP's desktop line?
Or does HP consider that Debian is (not yet) adequate to the desktop?
Bruce?
Yes, you got me -- I was confused about Darwin and Mac OS X. The 96 MB figure applies to Mac OS X, not Darwin -- I knew that but my reasoning broke like Microsoft Windows.
Anyway, Darwin is bloated yes -- it incorporates Mach in the BSD kernel for no good reason, since it takes no advantage neither of microkernel's best characteristic, that is flexibility nor of BSD, which has speed and leanness; this combination robs Mach of flexibility and BSD of its speed. It is a monolithical microkernel, because it has a single server.
OTOH Hurd is a true microkernel, flexible because of its multiple server architecture. Please go read the Hurd introductory documentation...
The free market failed us here... if it was really free, not conditioned by information hoarding (closed, proprietary software, protocols, file systems, hardware interfaces) we'd be running a real 64 bits RISC processor that needed no cooling in our desktops, notebooks and PDAs... this is the history of a obsolete specification enduring too long -- like Windows, BTW.
But what is the DBMS? Is the database relational? How it was modelled?