Brendan's Guide to OS Testing
Re: Brendan's Guide to OS Testing
If it's SCSI then all you need is a long 50 pin ribbon cable with a third connector, an extra PC power supply, and a SCSI CD drive (you can get them for $20). Then install from CD.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Re: Brendan's Guide to OS Testing
I never said anything that implied it wasn't.Troy Martin wrote:It's a laptop SCSI pullout, and the laptop is SPARC, not x86.Brynet-Inc wrote:They likely preformed a network installation.Troy Martin wrote:You guys seem to have a lot of computers!
I'm working on restoring a SPARCbook OpenBSD 2.6 box to network usability. I would put a new copy of OpenBSD or NetBSD or something modern on there, but there's no floppy OR CD drive. How the hell did they get it on there in the first place? It came with Solaris, then the person who gave it to me had formatted it with BSD FFS and put OpenBSD on there. Somehow...
It's documented for both OpenBSD and NetBSD:
http://www.openbsd.org/cgi-bin/man.cgi? ... ormat=html
http://www.netbsd.org/docs/network/netb ... o.sun.html
Please learn to properly quote people..
Re: Brendan's Guide to OS Testing
Hi,
I took a look through about 200 laptops on eBay. The cheapest (working) Pentium M I saw was about $300 plus $40 postage (I couldn't find anything with Geode, C7 or Nano CPUs). New replacement batteries go from about $125 to $190, so I'd be looking at around $500 for a second-hand laptop. A desktop system with similar specs is half that, new notebooks are less than that, and a new "budget" laptop isn't much more.
Cheers,
Brendan
I'd be looking for Intel Pentium-M, AMD GeodeLX, VIA C7 or VIA "Nano". I also want an Intel Atom, but things like the Eee 901 and MSI Wind are still relatively expensive (for a test machine) - at current prices I'd rather wait and get a dual core Atom when it's released...Dex wrote:I have found the eee pc a good cheap laptop for OS Dev and are available secondhand.Brendan wrote: Still, I'll keep an eye out for some sort of cheap laptop - I should have at least one...
http://forum.osdev.org/viewtopic.php?f= ... pc#p128597
I took a look through about 200 laptops on eBay. The cheapest (working) Pentium M I saw was about $300 plus $40 postage (I couldn't find anything with Geode, C7 or Nano CPUs). New replacement batteries go from about $125 to $190, so I'd be looking at around $500 for a second-hand laptop. A desktop system with similar specs is half that, new notebooks are less than that, and a new "budget" laptop isn't much more.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Brendan's Guide to OS Testing
Though I must say the OP has an impressive set of testsystems, I am wondering why someone would concern himself with such a bunch of old systems. OSes take years to mature, and unless one is actually targetting the OS at old, abandond systems, why deal with all the old muck? Even today's systems will be concidered old by the time most of us have a more or less complete OS running (what? only two cores? my god!) I shiver at the idea of having to target old Pentium systems, let alone 486s (VLB, anyone?) or older. So, anyone share my sentiments, or are you guys all geriaputerophiles?
JAL
JAL
Re: Brendan's Guide to OS Testing
I can agree with that. While it would be nice for my operating system to be lightweight and flexible enough to only need a 486, by the time anything I write ever gets finished, nobody will have less than an 8-core CPU. While I am going to write mainly for x86, that's simply because my current set of testbeds are all x86. Speaking of...
One thing I would like to know, do many people have more than just x86/x64 testbeds? Or rather, do people find it beneficial to develop for more than one platform at once? I know JamesM once made a comment in support of multiple platforms... IIRC. For instance, if I bought a PowerMac G4, would it be helpful?
One thing I would like to know, do many people have more than just x86/x64 testbeds? Or rather, do people find it beneficial to develop for more than one platform at once? I know JamesM once made a comment in support of multiple platforms... IIRC. For instance, if I bought a PowerMac G4, would it be helpful?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Brendan's Guide to OS Testing
If your goal is indeed that your OS be architecture-independent, then having an alternative platform is a good idea. And apparently, everybody wants a PowerPC box for that
The thing is, if you develop an OS for multiple platforms concurrently, then you will indeed try to make sharing kernel parts as easy and workable as possible.
The thing is, if you develop an OS for multiple platforms concurrently, then you will indeed try to make sharing kernel parts as easy and workable as possible.
Re: Brendan's Guide to OS Testing
Thanks. You mentioned that everybody wants a PowerPC box... are there any others I should get instead/as well as? I want to make my kernel as platform independent as possible.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Brendan's Guide to OS Testing
It seems to be the first thing people think about when considering different architectures.You mentioned that everybody wants a PowerPC box...
As for other architectures, SPARC seems to be a good (and common) candidate. There's MIPS, and less heard of, Hitachi's SuperH line which are good candidates. And HPPA in case you really want a challenge (its documentation is _horrible_)
Then there's the architectures without MMUs or with lesser MMU's: m68k, z80, ARM and AVR.
Of the above, I have actual programming experience with x86, SH4, HPPA, 68k and AVRs. PowerPC and ARM are on my list for systems-i-have-gotta-do-something-with-it.
Re: Brendan's Guide to OS Testing
Me too. However, I first go for x86, until that's stable enough, keeping in mind to seperate cpu specific stuff from the rest. Also, may of the alternative systems have less good emulation and debugging support, you need cross compilers, etc. Much hassle, but fun to do.JackScott wrote:Thanks. You mentioned that everybody wants a PowerPC box... are there any others I should get instead/as well as? I want to make my kernel as platform independent as possible.
JAL
Re: Brendan's Guide to OS Testing
Hi,
Mostly it's about eventually being able to say that I can't improve the kernel, and knowing it's the truth.
Cheers,
Brendan
It's about "future-proofing" a kernel by making sure it can handle a wide variation in features well. It's about allowing people to switch to my OS instead of upgrading all their hardware when the next newest version of some mainstream OS arrives. It's about supporting embedded systems (where you can still buy new "80486 class" CPUs made by STMicroelectronics and SiS). It's the simplicity of "80486 or later" with no exceptions, rather than "Pentium or later, except foo and bar, and maybe some other CPUs that might not work". It's about the difference between a skilled craftsman trying to create the best end product they can, in comparison to a factory mass-producing the same cheap plastic crap or a company trying to maximize profits for shareholders at the expense of customers.jal wrote:Though I must say the OP has an impressive set of testsystems, I am wondering why someone would concern himself with such a bunch of old systems. OSes take years to mature, and unless one is actually targetting the OS at old, abandond systems, why deal with all the old muck? Even today's systems will be concidered old by the time most of us have a more or less complete OS running (what? only two cores? my god!) I shiver at the idea of having to target old Pentium systems, let alone 486s (VLB, anyone?) or older. So, anyone share my sentiments, or are you guys all geriaputerophiles?
Mostly it's about eventually being able to say that I can't improve the kernel, and knowing it's the truth.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Brendan's Guide to OS Testing
Hi,
Cheers,
Brendan
I'd like to eventually make my OS architecture-independent, but if/when I do I'll write completely new/separate micro-kernels specifically designed to get the most out of each target architecture.Combuster wrote:If your goal is indeed that your OS be architecture-independent, then having an alternative platform is a good idea. And apparently, everybody wants a PowerPC box for that
If you have one huge blob of source code that tries to support all architectures, then would you do "lowest common denominator" programming (where you only use features that are supported in all architectures), or would you have a tangled mess of conditional code?Combuster wrote:The thing is, if you develop an OS for multiple platforms concurrently, then you will indeed try to make sharing kernel parts as easy and workable as possible.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Brendan's Guide to OS Testing
@Brendan : How many watts/month does your setup sum up to when you do extensive testing?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Brendan's Guide to OS Testing
I won't bother trying to set a standard for everybody here. The thing is, many programming concepts can be shared over multiple architectures. The extent to which you want to do that is based on design. Linux for example requires an MMU with sufficient protection mechanisms, which for that OS is the common denominator they designed to use, which definately is not the absolute lowest common denominator (since that includes at least my dad's old 100-instruction programmable calculator )Brendan wrote:I'd like to eventually make my OS architecture-independent, but if/when I do I'll write completely new/separate micro-kernels specifically designed to get the most out of each target architecture.
If you have one huge blob of source code that tries to support all architectures, then would you do "lowest common denominator" programming (where you only use features that are supported in all architectures), or would you have a tangled mess of conditional code?Combuster wrote:The thing is, if you develop an OS for multiple platforms concurrently, then you will indeed try to make sharing kernel parts as easy and workable as possible.
So people take a standard they consider "good enough", and use that as their lowest common denominator. That means they can (assuming linux' standard) share a physical memory manager, scheduler, drivers and more, while processor initialisation and MMU code is different.
And, #ifdef-ing all architectures in each source file can be done much nicer by putting arch-dependent code in separate source files. You of all people should know that
Re: Brendan's Guide to OS Testing
Hi,
My server is never turned off, and there's an ADSL modem, a KVM and an ethernet switch that are also never turned off. There's an LCD monitor that's on whenever I'm home/awake, and I use a Windows machine fairly regularly too (it's probably on for about 4 hours per day on average).
Usually the test computers aren't turned on for very long (long enough for me to boot and see the results), and when I'm testing all of them I usually only have about 5 on at a time. If my code has bugs that I'm trying to find then I just use one of the test machines and keep rebooting it.
For the last few years there hasn't been too much to do during testing (just check the messages displayed on the screen during boot), because I spend a lot of time on boot code and the micro-kernel. If I had networking, GUI/shell, applications, etc then I'd need to have test machines running for longer; but to me there's no point bothering with other stuff (drivers, applications, GUIs, shells, etc) until I'm happy with the boot code and micro-kernel. I've done that before (spend years working on higher level stuff and then throw it all away because the lower level stuff wasn't good enough) and learnt from my mistakes.
Cheers,
Brendan
I have no idea...prashant wrote:@Brendan : How many watts/month does your setup sum up to when you do extensive testing?
My server is never turned off, and there's an ADSL modem, a KVM and an ethernet switch that are also never turned off. There's an LCD monitor that's on whenever I'm home/awake, and I use a Windows machine fairly regularly too (it's probably on for about 4 hours per day on average).
Usually the test computers aren't turned on for very long (long enough for me to boot and see the results), and when I'm testing all of them I usually only have about 5 on at a time. If my code has bugs that I'm trying to find then I just use one of the test machines and keep rebooting it.
For the last few years there hasn't been too much to do during testing (just check the messages displayed on the screen during boot), because I spend a lot of time on boot code and the micro-kernel. If I had networking, GUI/shell, applications, etc then I'd need to have test machines running for longer; but to me there's no point bothering with other stuff (drivers, applications, GUIs, shells, etc) until I'm happy with the boot code and micro-kernel. I've done that before (spend years working on higher level stuff and then throw it all away because the lower level stuff wasn't good enough) and learnt from my mistakes.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
- Member
- Posts: 307
- Joined: Wed Oct 30, 2013 1:57 pm
- Libera.chat IRC: no92
- Location: Germany
- Contact:
Re: Brendan's Guide to OS Testing
First off, sorry for reopening up a 6-year old thread.
Second, Brendan, the first post is great. Could you put it into the wiki (you wrote it, it's your intellectual property)?
Second, Brendan, the first post is great. Could you put it into the wiki (you wrote it, it's your intellectual property)?