Date: Sun, 3 Dec 2000 21:59:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mwm@mired.org (Mike Meyer) Cc: professional3d@home.com (xavian anderson macpherson), mwm@mired.org (Mike Meyer), questions@FreeBSD.ORG, advocacy@FreeBSD.ORG, tagdot57@aol.com, mongor@mail.com, onybear@aol.com Subject: Re: installing freebsd from windows nt without using boot disks Message-ID: <200012032159.OAA02961@usr05.primenet.com> In-Reply-To: <14888.13097.187777.80105@guru.mired.org> from "Mike Meyer" at Dec 01, 2000 05:24:25 PM
next in thread | previous in thread | raw e-mail | index | archive | help
xavian anderson macpherson <professional3d@home.com> types: > i paid for the right to whine! i still have a $60 box of software that is > nothing more than a doorstop. ironically, the only way that i may be able to > use the software on the freebsd cd's, is to buy a MICROSOFT PRODUCT aka > INTERIX. THE ONLY REDEMPTION YOU HAVE NOW IS TO WRITE A FREEBSD KERNEL THAT > FUNCTIONS AS A DLL OR EXE IN WINDOWS! if you can make all of the stability > features of freebsd portable to windows, such that freebsd becomes a package > that windows users can add-on to their existing platform, to function in the > same way as the ANTICRASH and other utilities that i have running on my > system, then you may have some sort of redemption in terms of a future. I hate it when people who don't understand science and engineering make demands on scientists or engineers, based solely on their misperception of how the universe works. The bottom line is that no aggregate structure can be more solid than the foundations upon which it is based. That means that the best you can possibly do with a program that runs on an operating system is to make it as stable as the operationg system itself -- but no more so. So if your Windows system crashes after 43 days of continuous uptime because a 32 bit nanosecond counter has rolled over, no matter what a programmer does, they can not make their own software stay uf for more than 43 days. The "anticrash" program you reference is largely a joke on unsuspecting consumers, the same way "RAM doubler" and similar programs were a joke at the consumer's expense. Windows does not perform correct resource tracking on a large number of resources, and following an application crash, is therefore not able to recover those resources from the crashed program. Eventually, after several crashes of the program, your system will not be able to recover sufficient resources to allow it to continue to operate. If it were possible to make Windows stable to several sigmas while maintaining backward compatability, Microsoft would have done it. For all of their mistakes, and their use of new/raw graduates to work on things like APIs and other "unsexy" work, which their truly excellent programms feel is "beneath them" leading to more instabilities than necessary, Microsoft _does_ have world-class engineers working on things like stability. But realize this: the market has spoken, just as you have here, and stated that maintaining compatability with the Windows system is more important to them (just as it is more important to you to be able to run Windows programs), than stability. So they made the trade-off in favor of compatability. You have made a decision: you can no more have both Windows compatability and BSD stability simultaneously, than you can have a liter of vodka a day and keep your liver. Windows compatability _equals_ reduced stability. For more details on this, please look up the term "Mean Time Before Failure" or "MTBF", and how additive failure rates are calculated. There are kludge soloutions available. You could run FreeBSD as the primary OS, and run VMWare under FreeBSD, and host your Windows OS as a hosted OS under FreeBSD. This would keep your host OS stable, but would not increase the Windows stability; in addition, it would also mean that application interoperability between the wo environments would be reduced. In other words, you can trade integration for stability which excludes Windows itself. Beware that this approach adds the MTBF for VMWare to that of FreeBSD and Windows, for the Windows system, and the MTBF of VMWare and FreeBSD for FreeBSD. Here are a couple of other corrections to some of your other misconceptions: > THE ONLY THING THAT PREVENTED MICROSOFT FROM HAVING ABSOLUTE DOMINANCE > BEFORE, WAS IT'S LACK OF A VIABLE UNIX IMPLEMENTATION. Microsoft has had a UNIX implementation since 1982. > when MICROSOFT does with linux what freebsd did, and allows > linux to run in windows NT/2000, linux and unix will fall > under the single auspices of MICROSOFT. Linux does not "run under" FreeBSD. FreeBSD provide ABI compatability, so that _programs written for Linux_, and _not Linux itself_, can run under FreeBSD. Microsoft _already_ has this same capability: it recently acquired a company that provided Linux ABI compatability under Windows. Realize that this is limited, due to the need to integrate most desktop applications via the X protocol, but that server applications will run. As above, however, this does _not_ render the platform any more stable than if these were native Windows applications. > ONCE MICROSOFT HAS NEGATED THE ARGUEMENT OF WINDOWS VS UNIX (BY > PORTING UNIX TO WINDOWS) THERE WILL NOLONGER BE ANY ATTENTION > PAID TO ANYTHING OTHER THAN WINDOWS. NT achieved technical compliance with POSIX in 1994. Technical compliance is not the same as stability. As long as smart people are hired to make technical decisions on behalf of organizations, most technical decisions will result in a meritocracy. Technical people are not swayed by marketing, they are swayed by the results of testing and evaluations which they perform themselves. > IT WAS A HEROIC ATTEMPT AT THE PRESIDENCY, BUT MICROSOFT CONTROLS > THE ELECTION! IT'S OVER!! Luckily, Microsoft does not have the option of going to court and insisting that we count a limited subset of the whole, with rules changes on each iteration, until they get the result they want. The only court that matters is the court of the checkbook, and so long as people keep ginving money to their competitors, they will not have achieved a victory. > THE QUESTION WAS, WHEN WILL IT BE POSSIBLE TO INSTALL FREEBSD > FROM WINDOWS NT WITHOUT HAVING TO USE BOOT DISKS TO DO SO. There is a _huge_ difference between "installing from" and "installing on". It's possible to solve the "installing from" problem with code. However, realize that you will not be able to utilize FreeBSD without a reboot, should the code to do the job become available to you. In general, it is unlikely that the "installing from" problem will be resolved, even though it is possible to do the work; several barriers stand in the way: o It's complex; doing complex things in a Windows programming environment, which is where the work would have to take place, is not fun, it is tedious. Because of this, if it is to occur at all, it will have to be funded. o The resulting code can not be called FreeBSD, unless the code is part of the FreeBSD project, due to constraints that have been asserted on the use of the FreeBSD trademark. Because of this, there is no method of getting ROI (Return On Investment) for anyone other than the FreeBSD project itself, short of creating another BSD distribution entirely. The FreeBSD project has not (yet) committed the funds for the work. o The value of doing the work is limited, since you would need to use a program similar to "Partition Magic" to do the repartitioning needed to reserve space for the new installation. Such products require either licensing, or parallel developement, neither of which is free. Again, the ROI equation means that such developement would have to be funded by the FreeBSD project itself. o It's really questionable whether having to reboot is an acceptable cost for getting the ability to install both systems simultaneously, if only one can run at a time, since the intent appears to be to "have the best of both worlds"; as previously discussed, this is not technically possible. At this point it is traditional to say "patches are welcomed". [ ... Interix ... ] > <IF I HAD ONLY KNOWN ABOUT THIS BEFORE, I WOULD NOT HAVE BROUGHT FREEBSD!!> The claims are greatly exaggerated. The limitations are as noted previously. If you choose to believe these claims, it is at your own risk, as the Micorsoft EULA (End User License Agreement) points out. > i have absolutely no idea how something so superior to windows and linux is > unable to recognize the presense of my adaptec aha152x scsi adaptor on my > soundblaster 16 card. maybe it's too beneath freebsd to recognize my lowly > implementation of scsi. The Adaptec 1520 does not have a boot ROM. I have a number of these cards: this is the same SCSI interface that ships with HP scanners, and is a truly cheap card. You can not boot from this thing. Boot from floppies, and use the "-v -c" kernel options to bring up the visual configurator, and set the iRQ and base address to the same settings as show up in the controller configuration under Windows. You will then be able to use the boot floppies to boot, and the CDROm to install from. Of course, you may not have read this far in the message, which would be your loss. > freebsd is the alien, not MS. You have a strange sense of history. Did it ever occur to you that MS incompatability with other systems is in fact gratuitous and intended as an anticompetitive practice? > when freebsd generates the code that allows NT to write to UFS Artisoft did this for Windows 95 in 1996; I was on the project. A port to Windows NT would be rather trivial, as the IFSMgr interfaces are comparable. The Windows 95 code rights are currently held by people I could put you in contact with, as they took rights in the code as part of their severance, when Artisoft's Tucson division was going under. > and UFS to write to NTFS COMPRESSED, This is a matter of code and of someone dedicating the effort to write it. I would go so far to say that, other than VOP_ABORT, it is nothing more than "grunt work". The major amount of the effort would be dealing with the log and the compression. If you are willing to provide the equipment and software I would need, and willing to put up a surety bond that I will be paid $170,000 for completing the work in no less than 3 months and no more than 6 months, I'd be willing to do the work. If you are willing to change that to $510,000, I will do it as a work-for-hire, which would mean that you would keep the rights to sell, license, or otherwise dispose of the code, since you, not I, would be the copyright holder. Realize that other limits may apply, since I would start with the read-only NTFS code that is in FreeBSD today (prices go up for a wholly independent work). My risk is that, if I do not complete the work, I do not get paid. I'm open to negotiation on timeframe and amount, of course, and would provide for a time-limited exclusivity for somewhere in the middle of the two amounts. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012032159.OAA02961>