On Mar 22, 2005, at 6:39 AM, Anthony Atkielski wrote:
Peter Risdon writes:
You _are_ trying to run a version of FreeBSD equivalent to 2003/XP.
No, I'm just running FreeBSD 5.3. It has nothing to do with Windows.
This seems to be evidence that you're intentionally being obtuse.
Are you incapable of making the cognitive leap of comprehension that FreeBSD 5.3 is effectively the latest release, just as MS's Windows 2003 is their latest release? And if you jumped from Windows 2000, nearly 5 years old, to the newest version of FreeBSD's release, the *equivalent* is going to Windows 2003?
Hence the word, "equivalent", in that context?
Because you were making comparisons with an 8 y.o. version of Windows.
Because it might be the case that you also have to run an 8 y.o. version
of Windows.
That is your guess.
Personally, I decided not to guess, so I actually looked it up on Microsoft's Hardware Compatibility List for Windows 2000. My machine is still there. See
ftp://ftp.microsoft.com/services/whql/hcl/win2000hcl.txt
and look for the HP Vectra XU 6/200 PPro (2p).
And is it on the FreeBSD compatibility list?
Because your hardware is 8 years old. Obvious, obvious, obvious.
Uh-huh. See above. Care to try again?
And it's on an old compatibility list for an old OS. Bravo! Now is it on the current HCL for FreeBSD?
You don't have to actively maintain code for hardware platforms that are
not changing.
Even if the subsystems or other parts of the OS change in a way that breaks old code? I think that means it has to be actively maintained. Duh.
If eight-year-old code worked with eight-year-old hardware eight years ago, it will still work with the same hardware today. You don't have to remove it or "maintain" it.
Only if you're running the old version of the software from the time. See previous statement.
UNIX is a prime example of this, since it contains decades-old code that
still works, if you can find the hardware to exercise it.
Want to run a diff against the sources to see what, if anything, has changed? How much hasn't changed?
Yes you do. No code is an island. Rather than see unmaintained code break as dependencies get changed, it gets removed.
That's not true. I've been there and done that. You don't have to change anything. Code doesn't wear out. If it worked then, it will work now.
Only if nothing in the interfaces has changed. Or firmware. Or anything else that it must interact with. Unless the system is so braindead simple that it doesn't take advantage of anything advanced in hardware...but if that were your goal, I'm sure you'd be running a version of FreeDOS.
That's the sort of completely uninformed guess that has been pissing people off.
Well, no. I researched the problem, and people have been complaining about it for a long time. Google is your friend. Instead of getting pissed off, you might want to actually look something up. I'm not the first person with problems like this by any means, but it looks like nobody has ever addressed them. Lots of people in denial, though, and that part obviously hasn't changed.
Sooo you've researched it, and of course posted your links to substantiate your claims (correct?), and move into the realm of arguing with people to support old hardware. If your links checked out and it is overwhelmingly obvious that it's the code, then maybe you can start being your charming self and convince people to start rewriting code to support an old chipset in their spare time. Look through the support lists for the name(s) of developers that are in charge of the scsi code in question and ask them nicely if they would be willing to look into it instead of telling everyone what dimwits they are in a questions list.
Sure - you have the source code. You CAN hack it, or pay someone to hack
it, to make your drives work. If you wanted to, you could then
distribute your own version of the OS, or maintain it in-house if the
project closes or the product is discontinued. This isn't an option with
closed source software and it means you actually own your technology
yourself, fully and completely. And this is as obvious as it's possible
to get.
That's not an advantage. Nobody can dive into source code that way. That's not the way operating systems are built.
Oh? What's stopping you from going through the source yourself if you're a programmer? Time?
Can't have your cake and eat it too. The point is, you CAN do it. No license or law is stopping you. Only you are stopping you. Stop asking for an example of an advantage, which there are several people who have taken advantage of the very example he pointed out themselves, then dismissing the example given. It's a legitimate response. Deal with it.
It's a choice made by Microsoft too and it hasn't brought them to their knees.
No. Microsoft sets goals and developers meet the goals or find employment elsewhere. The company's objective is to make money, not to pander to overgrown teenagers who are too immature to work effectively in a cooperative engineering environment.
Oooh...So close. You're right in that their goal is to make money. FreeBSD is not out to rule the world, and as a matter of fact the developers probably don't give too doodah's about your personal gripes when you sound like you'd be ungrateful for their efforts anyway.
And with a spread out open-source effort that it takes to coordinate the work on an OS like FreeBSD or Linux, I don't know if the ad hominem attack on them (immature overgrown teenagers?) is very accurate. We've seen what cooperative engineering environments with a healthy dose of politics can churn out of MS labs. I'll take the "overgrown teenager"'s work.
Such as?
As I recall, the company planned to fix some problems by requiring an upgrade and I made it clear that an upgrade would not be acceptable to the customer base, and eventually they backed down.
Or they lose money...oddly enough this fits with their primary mission.
Changes are made to FreeBSD following user interaction. This process is
actually embedded in the FreeBSD development process (man 1 send-pr).
I'd like to get the bugs fixed first, before considering changes.
Everything you have is bug free, eh?
Did you read my other post about the API problem with Windows from tombom?
If you had a camera that was old enough to use film stock that is no longer widely made, you'd have to cut your own.
The film stock used in these cameras is still made today, and is available at every drugstore.
Dude's not swiss cheese only because he keeps missing the point.
You don't. Why on earth do you say things like this?
If you think eight years is old for a computer, then clearly you believe
that computers must be replaced at regular and frequent intervals.
Holy crap eight years isn't old in the computer industry?
If the system is still working fine for what you use it for, keep it. but a lot has changed performance-wise in eight years. If your users are doing anything that demands processor power and you're running 8 year old hardware just because you object to updating it,...well, we'd be lynched for it.
I don't see any reason to do that. This old machine still runs just fine; why would I replace it?
Then don't. Put your old OS back on and chalk it up to the OS doesn't support the system (is it on the compat list?)
I have no idea what your problem is ...
I agree. Now if only someone who actually knew what he was talking about and were interested in helping out would reply.
Wow, you must be a sysadmin with people skills like that...
"Hey! Nitwit! Help me with this, wouldja'? You're piece of crap coding doesn't like my old computer...evidently you're too stupid to do it right in the first place!...where are you going?..."
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
