When talking about this point, the argument that "programmers need to eat" doesn't apply: as Red Hat Software shows, a software company can feed programmers without writing any proprietary software at all.
How many programmers?
Look at it another way to put it in perspective:
How many programmer-years went into developing Linux and everything that runs on it?
How many programmers are paid by every distributor and open-source development company?
It seems to me that there is a large discrepancy here. Some open-source coders are paid for their efforts, but most aren't. The "programmers need to eat" argument still holds. Postulate a model in which everyone who codes gets paid for their efforts at a salary consistent with that they would be earning coding on proprietary projects, and I might jump on to the "down with proprietary software" bandwagon. Until then, I fail to see why both alternatives can't exist in the world.
What exactly is intrinsically evil about proprietary software? I was under the impression that one of the tenets of _both_ communities was that people had the right to release their source or hold on to it as they wished.
I agree that in a purely proprietary world, there is a strong tendency to produce bloated, overpriced, low-quality software (coughcoughMicrosoftcough), but in a purely non-proprietary world, you would have a lot of starving programmers. Being tech support doesn't cut it. This has been brought up by many people already.
IMO, the best kind of system is pretty close to the one that we have now (or will have in a year or two), with both proprietary and non-proprietary software on the market. Open software is wonderful for keeping proprietary software vendors honest. If Windows gets sufficiently bad, then Joe Average User will be willing to go through the headaches of Linux installation just to get away from frequent blue screens. So, proprietary software vendors are forced to put in at least _some_ quality control, to the relieve of Joe Average User, and hard-core programmers and open-source advocates have their open OS and applications to play with.
But starting a Jihad against proprietary software? Come on. If it's as bad as the rabid open source advocates say that it is, it will die on its own when faced with open source competition. Step down from your pulpits and write code for once.
The K7 doesn't support SSE, but does have 3DNow.
on
More AMD K7 Details
·
· Score: 1
Can it handle PIII special instructions? does it have it's own?
As I understand it, the K7 supports the PII instruction set, but doesn't support the SSE/KNI instructions. Programs that depend on these won't work on the K7 (or on a PII, for that matter).
The K7 certainly supports 3D-Now, and I remember hearing rumours of an extended version of 3D-Now at one point. I don't remember hearing anything about it since, though.
If MS does the port, so what? Some people might look at it and say, yeah cool, Office for Linux! and try it out. Most people with a clue will run in the opposite direction, fast.
You are assuming that most of the people installing word processors under Linux would have a clue. Right now that's probably the case, but if Linux ever becomes mainstream, it won't be.
Business decisions seem to be based on either whim or on "industry standard", and the "industry standard" for document exchange seems to be Microsoft Word, however ugly that may be. So, unless you are looking at companies that are unusually receptive to reasonable requests made by the programmers, Word is what will get installed in the majority of locations, IMO.
The home market is respectable, but the business market is where Microsoft makes most of its money if I understand correctly. Business licenses for Office are expensive.
My point about revokability is that it CAN happen... regardless of circumstances or restrictions. Think of it this way - a revokable license is one where the original license holder can revoke your rights to any or all of the code, even if YOU have not in any way violated the license. An irrevokable license is one where the license holder may only revoke your rights if YOU PERSONALLY violate the agreement.
By that definition, the APSL is not revokable, then. It only is terminated (for your code, at least) if you violate the license. Apple's code is only revoked if _Apple_ violated the law when it wrote it. Where is the problem (with the APSL)?
I put a disclaimer at the top of my message, but perhaps I should have stated it more clearly - I am not touching the issue of revokability in general - only the specific comment made that said that Apple could revoke developers' rights to their modified code at whim.
So, I'm having trouble seeing what specifically in my message you are responding to. The revokability-in-general issue is interesting, but not what I was writing about.
I'm not trying to be impolite, I'm just trying to clarify what I was and was not saying in my previous post, and to figure out what in that post you are addressing here.
I would first like to say that I am not disputing most of the points that you made in your post. However, I am not sure that your statement about the APSL is accurate:
The real distaste for both the Jikes and APSL licenses lies in the fact that the companies can revoke the licenses, and the work of independent developers will be lost.
As far as I can tell from reading the license carefully, Apple cannot revoke your right to do what you want with "Your Modifications" unless you explicitly break the license yourself. Clauses of concern and my take on them are as follows:
9.1 Infringement
The worst that Apple can do here is (c) terminate Your rights to use the Affected Original Code. "Affected Original Code" is "Original Code" (from Apple) that becomes the subject of a claim of infringement. So all of your modifications are still yours, under this scenario. You'd just have to code a replacement for the missing part, or use whatever replacement Apple winds up producing (which corresponds to Apple taking option (b) modify the Affected Original Code so that it is no longer infringing).
12.1 Termination
The relevant clause here is a referral to other clauses: (b) immediately in the event of the circumstances described in Sections 9.1 and/or 13.6(b). 9.1 we've already covered (though it could perhaps be stated more clearly that clause 12.1(b) applies only to the extent described in the clauses indicated). 13.6(b) is discussed below.
13.6 Severability
The relevant clause here is: (b) Notwithstanding the foregoing, if applicable law prohibits or restricts You from fully and/or specifically complying with Sections 2 and/or 3 or prevents the enforceability of either of those Sections, this License will immediately terminate (...). Section 3 basically states that you let any interested third parties use your code under this license, and let Apple incorporate it back into its development tree. As long as Apple exists, that's not a problem (I'll get back to the case where it doesn't exist). Section 2 places conditions on the use of code internally and externally. Internally, you have to document your code well and include the license and other relevant information. For code or binaries released externally, you also have to make sure that people obtain the source, and make sure that Apple can obtain the source. This is another clause that raises potential concerns.
So, the only real concern seems to be that Apple could disappear, making it impossible for you to grant them a license to your code and making it impossible to fill out the information required on their web page. IMO, these can be reasonably addressed as follows:
Granting Rights to Apple
If Apple dies and is bought by someone, I would argue that their buyer takes the place of Apple in the clauses mentioned, because Apple is now a part of the buyer. This means that the buyer must be able to obtain, use, and further modify the modifications that you made - just like everyone else. I don't see this as a problem.
If Apple dies and drops off the face of the earth, then I would make two arguments. Firstly, as Apple no longer exists and nobody picks up their IP claims, then I doubt that anybody is going to bother enforcing termination of the license. If somebody picks up the IP and complains, then I would argue that they are now Apple, and there is no violation. I'm a bit hazy on what happens to IP that isn't picked up by anyone. I suspect that it would devolve to the public domain (anybody care to check this?). This would IMO make the public domain "Apple" for the purposes of sections 2 and 3, and again there is no violation (as you are most certainly making your modifications available to the public).
Filling Out Apple's Information Page
The exact clause, 2.2 (c), reads: You... must notify Apple and other third parties of how to obtain Your Deployed Modifications by filling out and submitting the required information found at (url).
Note that this doesn't say that you must submit the information through the web page - just that you must fill out a version of the form presented there and get it to Apple and "other third parties". If you're worried about the site going down or about Apple removing the site to void the license, fear not - just print out a version of the page and fax the completed form to whoever winds up with Apple's IP rights when the dust settles.
Or, these are the arguments that I would use in court if somebody tried to pull the license out from under me under the above scenarios. I think that they'd stand up reasonably well.
MS Office is ok, I HATE how it can't seem to convert HTML to a.doc in it. MS Office becoming an HTML editor was a LAME move in my opinion.
The subject says it all. I've never understood the need for anything fancier than a text editor for HTML editing. Better control and less cruft generated.
I keep hearing all this anti-aliased stuff (gnome, png, etc). But I'm not a big graphics person. Does anyone have a good def?
I'm not sure exactly what they're referring to in this context, but I can tell you what anti-aliasing is in general.
"Aliasing" refers to artifacts in images that result from the fact that images are made up of pixels. Moire patterns, "staircase" pixel patterns on edges, and the wierd speckles, checkerboards, and what-have-you that can show up when you resample an image count as aliasing.
"Anti-aliasing" refers to a set of techniques designed to remove aliasing artifacts from images that are being resampled or otherwise displayed in a form other than their original and/or ideal forms. This usually involves smoothing/filtering and blending against whatever background the image is being displayed against.
What I think it refers to in this context is just using true alpha-blending to smooth jagged edges of things like fonts and icons against a background. You can't do this with transparent.GIFs, so they wind up either looking jagged or else having an ugly coloured fringe if you change the background colour.
Yea - I expected it to work and was surprised when it didn't. The E-Machine MB just has a plain old Rage Pro 3D IIC with 4 Megs of video ram. I installed BeOS R4 with no problems, but when it boots to the desktop it comes up on the generic (gray) server with an error message saying the video card is not supported. My guess is that the IIC is pretty new - in particular it is an embedded version of the (supported) Rage Pro II. It doesn't seem like it should make any difference to the driver, but maybe the BeOS looks for model numbers or something???
System configuration noted, and I've passed on this bug report to my superiors.
AFAIK the IIC isn't that new; it's certainly in the table of supported devices in the driver. However, this might indeed be a wierd variant. BeOS drivers check the vendor and device ID in PCI configuration space to identify the cards in the system. In principle, all IICs should have the same device ID (4756 hex), and so should be recognized. However, a wierd variant might have a different ID.
If it isn't too much trouble, please run BeOS and check the device ID of the chip. This can be done by typing "poke" from the command line in a terminal window, and then "pci" to list all devices in PCI space. "quit" exits. Look for something with a vendor ID of "1002". The device ID *should* be "4756", but if it isn't, that would explain a few things.
The serial number off of the chip and the make of the motherboard would be useful too, but don't go out of your way if it's too much trouble. The idea is that we'd have enough information to exactly pinpoint the cases in which the problem occurs.
He was referring to the initial boot, not the OS boot. I've yet to have a BIOS which let me boot with a video card. You do get lots of cool beeping, though.
I have yet to encounter this problem. I've booted my BeOS box without a video card on several occasions, and it works fine (though I have to telnet into it to do anything useful).
For reference, the system that I'm using is a PII-266 with an Asus P2L97 motherboard.
What meaning the word "naive" have for you? Just a fool believes that a commercially-oriented company is likely to make all its apis *not* hidden...
Think about what you're saying before you type it.
Be doesn't have the resources to develop an applications suite. Hiding parts of the API would gain nothing for them. They have instead made a great effort to _display_ the API, providing documentation and support for anyone who wants to develop for it. This helps Joe Average Coder write BeOS applications, which helps Be by creating more nifty things that run on their operating system.
Believe it or not, not every company is a Microsoftian monopoly. Did you even look at the API documentation, or is this just a knee-jerk reaction?
[bus locking is impossible] unless you put a clock in the processor... but taking the clock out of the processor is what the bus speed and multiplier were invented for in the first place, so that would make no sense at all.
If you put a purely transistor-based oscillator in the CPU, it won't be terribly accurate (i.e. useless for core clocking) but would catch people overclocking 66 MHz busses to 100 MHz. Or, you could put a crystal in the chip module (even the old socketed "chips" are modules) and verify the bus speed to within a few percent or better. This would be very cheap and would stop bus overclocking.
The reason why you'd still use the bus clock to generate your internal clock is synchronization. The core clock and the bus clock remain in lockstep under the present system, with clock edges precisely converging every (n) clocks. Using the bus-locking crystal to generate the core clock would cause the two clocks to drift with respect to each other, making data transfer troublesome. You could add synchronization circuitry to keep the clocks in step, but if you're doing this much you might as well just multiply the bus clock instead, as that would take less silicon.
Small denominator and relatively small numerator, sorry. Alternatively, "the solution to a binomial with small coefficients", but that's not terribly relevant.
Namely, that the ratio between the core speed and the bus speed must be a rational number with small coefficients. If you feel that you _must_ overclock your system bus so that your processor can have a 1% speed increase, then go ahead, of course. Personally, I don't see what the big deal about overclocking is.
My system at home is a P100. It works adequately. Ditto the PII systems at work.
With this kind of thing, perhaps they could now remove the multiplier lock and allow hackers to play around with the multiplier to their hearts' content.
Unlikely, IMO. They still want anyone running at 450 instead of 400 to pay for a 450 (that is still a very expensive step, around here at least).
Why exactly they even did this much is hazy, but I suspect that it's so that unscrupulous manufacturers are forced to buy the higher speed chips from Intel instead of remarking. It might also be to try to gather public support for bus locking ("see? we caught all of these people gouging you for overclocked chips! let us stop them"). I know exactly how well that would fly here, but bear in mind that most PC buyers don't overclock and so might like this pitch.
Why exactly would price/performance become a bigger driver of the market if Linux becomes mainstream? The quotation left out the justification for the statement.
One argument is that Windows is primarily available only for Intel-compatible chips. But you have clone makers like AMD and Cyrix building chips with more efficient architectures that Windows can run on already, and you can get NT for the Alpha or the Sparc or whatever else you want.
The only other argument that I can think of is that Linux is able to handle multi-processor and multi-box systems more gracefully than Windows, allowing you to use multiple cheap processors, but network and bus bandwidth limit the performance of these systems more than processor power does (n chips do not perform n times as fast as one chip in most cases).
As far as I can tell, the market already _is_ dominated by cost/performance. x86 chips and clones aren't wonderful for speed, but compared to the alternatives they are cheap, and so are bought.
If this is coming out in 2001, HDTV may be common enough to make a higher polygon count worthwhile. This is especially true in Japan, which amounts to about half of the world's console gaming market if I understand correctly.
NTSC should still benefit somewhat. You just wind up with polygons with areas of only a few pixels. As long as your anti-aliasing blends these triangles in correctly, this will give you very smooth-looking surfaces (no more jagged borders).
...According to what I've heard coming out of the game development industry. How many the N2000 ends up doing under actual gaming conditions remains to be seen, but I could believe 20 million for a 2001 release date.
Be wants to take over M$ using the same tactics: closed source APIS.
Um, you might want to doublecheck some of your statements.
Microsoft is infamous for *hiding* parts of its API. This means that you only have full access to its features if you work for Microsoft. This seriously hinders software development by third-party developers.
Be's API is right there for you to look at, in/boot/develop/headers. There's even reasonably good documentation for it, in The Be Book (which comes with BeOS and can also be downloaded from the web). Be has done its best to allow third-party developers to write applications for BeOS, because they know that it is in their best interests to do so.
Hidden APIs aren't the only tool that Microsoft uses to keep its monopoly. Integration of applications into the OS are a much bigger concern. I think that MS's next step in this trend would logically be replacing Notepad completely with Wordpad, to force people to buy Word-compatible word processors.
I'd like someone to explain how Open Source is an answer to this problem, since I can't think of one. (Only honest, intelligent answers need apply.)
If I understand correctly, the idea is that you release an open source library while it's still beta so that you have a very large testing base to find bugs and patch holes that you might have missed in-house. This has the advantage of being fairly thorough in the long run, but takes a while to produce final results, and requires that the software in question be open-source (with all of the resulting advantages and disadvantages).
I'm Looking to make a mp3 box for my brother's car, I just need something with onboard NIC & Sound, the video just needs to be there so it will boot.
Why is the video necessary to boot? It would be useful for selecting the MP3s to play, but AFAIK both Linux and BeOS will boot just fine without a video card.
Keyboards, OTOH, can be a problem. The BIOS usually looks for one on startup, though I'm told that this can be disabled on some systems.
A board designed for embedded applications might be your best bet, but good luck finding one under budget.
I helped a friend install linux on an E-Machines box, which has an ATI Rage IIC embedded in the MB. [...] Unfortunately BeOS does not yet have a driver for this (although they have good ATI support) - maybe in 4.1?
The existing RagePro driver should support everything from the original Rage chip on up (though not the Rage 128). What was the exact configuration of the system that you tried this on, and what were the exact symptoms observed on failure?
[shameless plug]
altsoftware.com is perfectly willing to develop BeOS drivers for you; regrettably, we can't work for free, but rest assured that anything you contract from us will most definitely be worth the money. Our web page is at http://www.altsoftware.com.
[/shameless plug]
And don't blame me for the web page layout, as it's not my fault:).
Slashdot Mirror
How many programmers?
Look at it another way to put it in perspective:
How many programmer-years went into developing Linux and everything that runs on it?
How many programmers are paid by every distributor and open-source development company?
It seems to me that there is a large discrepancy here. Some open-source coders are paid for their efforts, but most aren't. The "programmers need to eat" argument still holds. Postulate a model in which everyone who codes gets paid for their efforts at a salary consistent with that they would be earning coding on proprietary projects, and I might jump on to the "down with proprietary software" bandwagon. Until then, I fail to see why both alternatives can't exist in the world.
Free Software + Proprietary Software == Bad
What exactly is intrinsically evil about proprietary software? I was under the impression that one of the tenets of _both_ communities was that people had the right to release their source or hold on to it as they wished.
I agree that in a purely proprietary world, there is a strong tendency to produce bloated, overpriced, low-quality software (coughcoughMicrosoftcough), but in a purely non-proprietary world, you would have a lot of starving programmers. Being tech support doesn't cut it. This has been brought up by many people already.
IMO, the best kind of system is pretty close to the one that we have now (or will have in a year or two), with both proprietary and non-proprietary software on the market. Open software is wonderful for keeping proprietary software vendors honest. If Windows gets sufficiently bad, then Joe Average User will be willing to go through the headaches of Linux installation just to get away from frequent blue screens. So, proprietary software vendors are forced to put in at least _some_ quality control, to the relieve of Joe Average User, and hard-core programmers and open-source advocates have their open OS and applications to play with.
But starting a Jihad against proprietary software? Come on. If it's as bad as the rabid open source advocates say that it is, it will die on its own when faced with open source competition. Step down from your pulpits and write code for once.
does it have it's own?
As I understand it, the K7 supports the PII instruction set, but doesn't support the SSE/KNI instructions. Programs that depend on these won't work on the K7 (or on a PII, for that matter).
The K7 certainly supports 3D-Now, and I remember hearing rumours of an extended version of 3D-Now at one point. I don't remember hearing anything about it since, though.
Whoops. You're right. I ascribe it to bit rot caused by sitting too close to my monitor
You are assuming that most of the people installing word processors under Linux would have a clue. Right now that's probably the case, but if Linux ever becomes mainstream, it won't be.
Business decisions seem to be based on either whim or on "industry standard", and the "industry standard" for document exchange seems to be Microsoft Word, however ugly that may be. So, unless you are looking at companies that are unusually receptive to reasonable requests made by the programmers, Word is what will get installed in the majority of locations, IMO.
The home market is respectable, but the business market is where Microsoft makes most of its money if I understand correctly. Business licenses for Office are expensive.
By that definition, the APSL is not revokable, then. It only is terminated (for your code, at least) if you violate the license. Apple's code is only revoked if _Apple_ violated the law when it wrote it. Where is the problem (with the APSL)?
I put a disclaimer at the top of my message, but perhaps I should have stated it more clearly - I am not touching the issue of revokability in general - only the specific comment made that said that Apple could revoke developers' rights to their modified code at whim.
So, I'm having trouble seeing what specifically in my message you are responding to. The revokability-in-general issue is interesting, but not what I was writing about.
I'm not trying to be impolite, I'm just trying to clarify what I was and was not saying in my previous post, and to figure out what in that post you are addressing here.
The real distaste for both the Jikes and APSL licenses lies in the fact that the companies can revoke the licenses, and the work of independent developers will be lost.
As far as I can tell from reading the license carefully, Apple cannot revoke your right to do what you want with "Your Modifications" unless you explicitly break the license yourself. Clauses of concern and my take on them are as follows:
The worst that Apple can do here is (c) terminate Your rights to use the Affected Original Code. "Affected Original Code" is "Original Code" (from Apple) that becomes the subject of a claim of infringement. So all of your modifications are still yours, under this scenario. You'd just have to code a replacement for the missing part, or use whatever replacement Apple winds up producing (which corresponds to Apple taking option (b) modify the Affected Original Code so that it is no longer infringing).
The relevant clause here is a referral to other clauses: (b) immediately in the event of the circumstances described in Sections 9.1 and/or 13.6(b). 9.1 we've already covered (though it could perhaps be stated more clearly that clause 12.1(b) applies only to the extent described in the clauses indicated). 13.6(b) is discussed below.
The relevant clause here is: (b) Notwithstanding the foregoing, if applicable law prohibits or restricts You from fully and/or specifically complying with Sections 2 and/or 3 or prevents the enforceability of either of those Sections, this License will immediately terminate (...). Section 3 basically states that you let any interested third parties use your code under this license, and let Apple incorporate it back into its development tree. As long as Apple exists, that's not a problem (I'll get back to the case where it doesn't exist). Section 2 places conditions on the use of code internally and externally. Internally, you have to document your code well and include the license and other relevant information. For code or binaries released externally, you also have to make sure that people obtain the source, and make sure that Apple can obtain the source. This is another clause that raises potential concerns.
So, the only real concern seems to be that Apple could disappear, making it impossible for you to grant them a license to your code and making it impossible to fill out the information required on their web page. IMO, these can be reasonably addressed as follows:
If Apple dies and is bought by someone, I would argue that their buyer takes the place of Apple in the clauses mentioned, because Apple is now a part of the buyer. This means that the buyer must be able to obtain, use, and further modify the modifications that you made - just like everyone else. I don't see this as a problem.
If Apple dies and drops off the face of the earth, then I would make two arguments. Firstly, as Apple no longer exists and nobody picks up their IP claims, then I doubt that anybody is going to bother enforcing termination of the license. If somebody picks up the IP and complains, then I would argue that they are now Apple, and there is no violation. I'm a bit hazy on what happens to IP that isn't picked up by anyone. I suspect that it would devolve to the public domain (anybody care to check this?). This would IMO make the public domain "Apple" for the purposes of sections 2 and 3, and again there is no violation (as you are most certainly making your modifications available to the public).
The exact clause, 2.2 (c), reads: You
Note that this doesn't say that you must submit the information through the web page - just that you must fill out a version of the form presented there and get it to Apple and "other third parties". If you're worried about the site going down or about Apple removing the site to void the license, fear not - just print out a version of the page and fax the completed form to whoever winds up with Apple's IP rights when the dust settles.
Or, these are the arguments that I would use in court if somebody tried to pull the license out from under me under the above scenarios. I think that they'd stand up reasonably well.
The subject says it all. I've never understood the need for anything fancier than a text editor for HTML editing. Better control and less cruft generated.
I'm not sure exactly what they're referring to in this context, but I can tell you what anti-aliasing is in general.
"Aliasing" refers to artifacts in images that result from the fact that images are made up of pixels. Moire patterns, "staircase" pixel patterns on edges, and the wierd speckles, checkerboards, and what-have-you that can show up when you resample an image count as aliasing.
"Anti-aliasing" refers to a set of techniques designed to remove aliasing artifacts from images that are being resampled or otherwise displayed in a form other than their original and/or ideal forms. This usually involves smoothing/filtering and blending against whatever background the image is being displayed against.
What I think it refers to in this context is just using true alpha-blending to smooth jagged edges of things like fonts and icons against a background. You can't do this with transparent
System configuration noted, and I've passed on this bug report to my superiors.
AFAIK the IIC isn't that new; it's certainly in the table of supported devices in the driver. However, this might indeed be a wierd variant. BeOS drivers check the vendor and device ID in PCI configuration space to identify the cards in the system. In principle, all IICs should have the same device ID (4756 hex), and so should be recognized. However, a wierd variant might have a different ID.
If it isn't too much trouble, please run BeOS and check the device ID of the chip. This can be done by typing "poke" from the command line in a terminal window, and then "pci" to list all devices in PCI space. "quit" exits. Look for something with a vendor ID of "1002". The device ID *should* be "4756", but if it isn't, that would explain a few things.
The serial number off of the chip and the make of the motherboard would be useful too, but don't go out of your way if it's too much trouble. The idea is that we'd have enough information to exactly pinpoint the cases in which the problem occurs.
I have yet to encounter this problem. I've booted my BeOS box without a video card on several occasions, and it works fine (though I have to telnet into it to do anything useful).
For reference, the system that I'm using is a PII-266 with an Asus P2L97 motherboard.
Just a fool believes that a commercially-oriented
company is likely to make all its apis *not*
hidden...
Think about what you're saying before you type it.
Be doesn't have the resources to develop an applications suite. Hiding parts of the API would gain nothing for them. They have instead made a great effort to _display_ the API, providing documentation and support for anyone who wants to develop for it. This helps Joe Average Coder write BeOS applications, which helps Be by creating more nifty things that run on their operating system.
Believe it or not, not every company is a Microsoftian monopoly. Did you even look at the API documentation, or is this just a knee-jerk reaction?
If you put a purely transistor-based oscillator in the CPU, it won't be terribly accurate (i.e. useless for core clocking) but would catch people overclocking 66 MHz busses to 100 MHz. Or, you could put a crystal in the chip module (even the old socketed "chips" are modules) and verify the bus speed to within a few percent or better. This would be very cheap and would stop bus overclocking.
The reason why you'd still use the bus clock to generate your internal clock is synchronization. The core clock and the bus clock remain in lockstep under the present system, with clock edges precisely converging every (n) clocks. Using the bus-locking crystal to generate the core clock would cause the two clocks to drift with respect to each other, making data transfer troublesome. You could add synchronization circuitry to keep the clocks in step, but if you're doing this much you might as well just multiply the bus clock instead, as that would take less silicon.
Small denominator and relatively small numerator, sorry. Alternatively, "the solution to a binomial with small coefficients", but that's not terribly relevant.
My system at home is a P100. It works adequately. Ditto the PII systems at work.
Unlikely, IMO. They still want anyone running at 450 instead of 400 to pay for a 450 (that is still a very expensive step, around here at least).
Why exactly they even did this much is hazy, but I suspect that it's so that unscrupulous manufacturers are forced to buy the higher speed chips from Intel instead of remarking. It might also be to try to gather public support for bus locking ("see? we caught all of these people gouging you for overclocked chips! let us stop them"). I know exactly how well that would fly here, but bear in mind that most PC buyers don't overclock and so might like this pitch.
...According to the article, at least.
One argument is that Windows is primarily available only for Intel-compatible chips. But you have clone makers like AMD and Cyrix building chips with more efficient architectures that Windows can run on already, and you can get NT for the Alpha or the Sparc or whatever else you want.
The only other argument that I can think of is that Linux is able to handle multi-processor and multi-box systems more gracefully than Windows, allowing you to use multiple cheap processors, but network and bus bandwidth limit the performance of these systems more than processor power does (n chips do not perform n times as fast as one chip in most cases).
As far as I can tell, the market already _is_ dominated by cost/performance. x86 chips and clones aren't wonderful for speed, but compared to the alternatives they are cheap, and so are bought.
NTSC should still benefit somewhat. You just wind up with polygons with areas of only a few pixels. As long as your anti-aliasing blends these triangles in correctly, this will give you very smooth-looking surfaces (no more jagged borders).
...According to what I've heard coming out of the game development industry. How many the N2000 ends up doing under actual gaming conditions remains to be seen, but I could believe 20 million for a 2001 release date.
Um, you might want to doublecheck some of your statements.
Microsoft is infamous for *hiding* parts of its API. This means that you only have full access to its features if you work for Microsoft. This seriously hinders software development by third-party developers.
Be's API is right there for you to look at, in
Hidden APIs aren't the only tool that Microsoft uses to keep its monopoly. Integration of applications into the OS are a much bigger concern. I think that MS's next step in this trend would logically be replacing Notepad completely with Wordpad, to force people to buy Word-compatible word processors.
Be uses neither of these tactics.
If I understand correctly, the idea is that you release an open source library while it's still beta so that you have a very large testing base to find bugs and patch holes that you might have missed in-house. This has the advantage of being fairly thorough in the long run, but takes a while to produce final results, and requires that the software in question be open-source (with all of the resulting advantages and disadvantages).
Why is the video necessary to boot? It would be useful for selecting the MP3s to play, but AFAIK both Linux and BeOS will boot just fine without a video card.
Keyboards, OTOH, can be a problem. The BIOS usually looks for one on startup, though I'm told that this can be disabled on some systems.
A board designed for embedded applications might be your best bet, but good luck finding one under budget.
Serves me right for trying to surf and write messages at the same time
The existing RagePro driver should support everything from the original Rage chip on up (though not the Rage 128). What was the exact configuration of the system that you tried this on, and what were the exact symptoms observed on failure?
[shameless plug]
altsoftware.com is perfectly willing to develop BeOS drivers for you; regrettably, we can't work for free, but rest assured that anything you contract from us will most definitely be worth the money. Our web page is at http://www.altsoftware.com.
[/shameless plug]
And don't blame me for the web page layout, as it's not my fault