OSDever.net abandoned?

[nexos]

Hello,
I just tried going to OSDever.net, as they have some good resources. But it appears to be down or abandoned. Does anyone know?
Greetings,
nexos

[PeterX]

I just tried going to OSDever.net, as they have some good resources. But it appears to be down or abandoned. Does anyone know?

No, I don't know. But I didn't use that site. I think this site (the forum combined with the great wiki) is the best resource for hobby/amateur OS developers. There was sabre/nondot.org but that has gone, too, since Chris Lattner is working for a programming language in the MacOS universe (I think it's Swift).

There is some probability that the maintainer of osdever.net lost interest in OS dev and don't want to pay the webspace anymore. But that's just guessing.

Greetings
Peter

[nexos]

That makes since. I think Brendan maintained that site, and it hasn't been active in years.

[nullplan]

That makes since. I think Brendan maintained that site, and it hasn't been active in years.

Heh, shouldn't he have time now? Cheap shot, I know.

[Seahorse]

I imagine that because OS Dev is getting even more complicated than it used to be, the niche is becoming ever smaller as time goes. Maybe that is just my cynic talking.

[nullplan]

I imagine that because OS Dev is getting even more complicated than it used to be, the niche is becoming ever smaller as time goes.

Not really, but it is becoming different. We used to have to write arcane incantations in assembler to load our kernels, now we can write our bootloaders in C and aren't restricted to half a kilobyte. So that's a big plus. Problem is that there's lots and lots of outdated information flying around out there, and people interested in the topic are more likely to find the old information than the current stuff.

After loading the kernel, OS work has always been difficult. It is programming without a net (or, as one of our vendors put it, open heart surgery); if you have a bug in your interrupt handling, there is very little that might help you find it. You can only read the code and hope you find the problem. Which is why I personally like to keep things as simple as possible, because then there is little that can go wrong.

I personally believe interest in OS development is waning because interest in the PC is waning. Give it time. Once the new computing world order has been established and we all know what kind of platform we are working on the next few decades, interest might be sparked again. Meanwhile, I will polish my interrupt handling code. And when all the world has moved on to ARM, I will buy a PowerPC development kit, just to show them.

[bzt]

We used to have to write arcane incantations in assembler to load our kernels, now we can write our bootloaders in C and aren't restricted to half a kilobyte. So that's a big plus.

I see it the other way around. we used to have a clean and easy to use interface to load our kernel, and half a kilobyte of code was enough to do that. Now we have to deal with extremely overcomplicated, badly designed, non-universal, non-portable stuff hidden behind bloated SDKs, and not even 64k is enough to load our kernel! See

EFI is this other Intel brain-damage (the first one being ACPI).
...
For example, instead of ACPI, we could just have had standardized hardware
(and a few tables to define things like numbers of CPU's etc). It would
have been simpler for everybody. But no, people seem to think that it's
somehow "better" to have wild and crazy hardware, and then have a really
complicated way of describing it - and driving it - dynamically.

So EFI has this cool shell, a loadable driver framework, and other nice
features. Where "nice" obviously means "much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work".

I share his opinion on this. 99.9999% of the time nobody cares nor wants a boot shell nor loadable driver support at boot time, makes just no sense. For things that you do need a configurable environment, like editing the kernel command line and specifying modules, well, they are already implemented in GRUB (on IA-64 too) and in other boot loaders, so having all of this in a firmware is completely unnecessary and just resource-wasting redundancy. By the time TianoCore shows up its logo, I can already boot my OS entirely with BIOS. Is this really "progress"?

Problem is that there's lots and lots of outdated information flying around out there, and people interested in the topic are more likely to find the old information than the current stuff.

That's true.

After loading the kernel, OS work has always been difficult. It is programming without a net (or, as one of our vendors put it, open heart surgery); if you have a bug in your interrupt handling, there is very little that might help you find it.

Wrong. Learn how to use your tools. Read Kernel Debugging on the wiki. I've just realized how much VirtualBox debugger has evolved since the last time I've used it. In functionality it is now in par with bochs, and far better than GDB (you can list page translation walks for example, or dump PIC registers, etc. something unimaginable in GDB).

Which is why I personally like to keep things as simple as possible, because then there is little that can go wrong.

On that I couldn't agree more

I personally believe interest in OS development is waning because interest in the PC is waning. Give it time. Once the new computing world order has been established and we all know what kind of platform we are working on the next few decades, interest might be sparked again. Meanwhile, I will polish my interrupt handling code. And when all the world has moved on to ARM, I will buy a PowerPC development kit, just to show them.

Haha, good plan!

Cheers,
bzt

[Seahorse]

What i was getting to originally was that technology ilstandards are only getting more complex, especially for a modern-featured system. In the 70s-80s and even perhaps the 90s a serious hobby project that could have been accepted as a "modern" OS may have been more realistic.

[nullplan]

What i was getting to originally was that technology ilstandards are only getting more complex, especially for a modern-featured system.

Well, sometimes we get to throw out unused things, and that brings complexity down a notch. Some people complicate their memory manager just so it would be possible to do ISA DMA with it, and then they notice that was bloody pointless, because nothing uses ISA DMA anymore. Also, hardware standards are getting better. More complex, maybe, but also more streamlined. Wrapping your head around USB's transfer queues might be a bit of a steep learning curve, but when you read the AHCI spec, you notice that it's almost the same thing there. And from USB to AHCI to ATAPI, everything uses the same SCSI commands in a different wrapper.

And hardware manufacturers are getting better about releasing documentation. 30 years ago, finding out what the hardware protocol to the IDE adapter looks like would require you to head to the local Google shop (aka library), where you would employ your own personal search agent (librarian) to find that info written onto the bark of a dead tree somewhere. Or else go to a book store and pay actual money, sometimes quite a significant amount, to take the tree bark home with you, also sometimes a quite significant amount and fire hazard. That's if there was any amount of money you could pay the hardware guys to tell you what is going on. Sometimes the info would only be available under NDA, and sometimes not at all, and then you are reverse engineering drivers all night to figure out how something works.

In the 70s-80s and even perhaps the 90s a serious hobby project that could have been accepted as a "modern" OS may have been more realistic.

What's modern? I'm serious, I look around various recent operating systems to find that feature that really is new, but the most serious departure from the original Multics is still the GUI. So the most revolutionary development in OS technology happened in the early 90ies, and we have been finding new ways to write that OS ever since. Sometimes the OS comes in tiny little packages that aren't linked together, sometimes it comes as a big slab of those same packages, but glued together hard. Sometimes it comes under a black veil, and sometimes it flashes all its private bits around, but fundamentally, it's always the same OS and the same bloody calculator program.

And don't look to me for innovation; my claim to fame is trying to find out how many parts you can remove from Linux and still have an OS.

[bzt]

And don't look to me for innovation; my claim to fame is trying to find out how many parts you can remove from Linux and still have an OS.

About that,

• Linux kernel tinification, and
• LFS for small userland.

For the latter the absolute bare minimum is an /sbin/init, which has all the required libraries statically linked in. (There are actually build scripts to do that, very popular approach for running microservices on virtual machines.)

IMHO what is small but still usable (in general purpose OS sense), is TinyCore (but it has a serious drawback. It ships all applications in disk images, and instead of copying the files it just mounts the disk images on a loopback device. With some (not too many) installed apps you'll notice incredible slowdown on file operations because of the lots of mount points.)

Cheers,
bzt

[iansjack]

I've just realized how much VirtualBox debugger has evolved since the last time I've used it. In functionality it is now in par with bochs, and far better than GDB (you can list page translation walks for example, or dump PIC registers, etc. something unimaginable in GDB).

Unless I'm missing something obvious, The VirtualBox debugger doesn't allow you to debug at the source-code level. Granted you sometimes need to look at the raw machine but, as work progresses, I find it far more useful to be able to work with the source. The best solution is to use a combination of debuggers and monitors (the qemu monitor can give you a lot of information, as well as being able to look at physical memory) - horses for courses. So I wouldn't write off gdb just yet.

[bzt]

Unless I'm missing something obvious, The VirtualBox debugger doesn't allow you to debug at the source-code level.

Neither does qemu nor bochs. You can load a list of symbols in best case, but that's it.

So I wouldn't write off gdb just yet.

I did not wanted to suggest that. Gdb is for debugging your code, and not for debugging the virtual machine's actual state (the fact is, there's no place in the gdb protocol for things like debugging MMU tables, IDT or GDT entires, dumping PIC or PIT registers, examining UART fifo etc. but in return it can parse the source file references in executable). I agree one should use the combination of both for maximum effectiveness. For example if you mess up paging tables, it is really difficult to find that bug watching your source code only. On the other hand listing the MMU tables that the CPU is actually using is much more helpful. Likewise, seeing that the IRQ hasn't been enabled when you dump PIC won't tell you where the bug is, you'll need to see the source next to the running code to solve that.

Cheers,
bzt

[iansjack]

Neither does qemu

That's just not true.

Use qemu in conjunction with gdb (or VirtualBox + gdb) and you get full source-code level debugging. Step through your kernel (or user-space program) with breakpoints, straightforward or conditional, and watches, etc. I don't know if you can use gdb in conjunction with Bochs as I don't use it. You can also debug at the machine level if you want to.

It's an order of magnitude more useful than a simple machine-level debugger, like the VirtualBox one, for most debugging. I can only think that you haven't actually tried this combination.

[nexos]

I don't know if you can use gdb in conjunction with Bochs as I don't use it.

Yes, you can use GDB in Bochs as long as Bochs was configured with --enable-gdb-stub, and if gdbstub: enabled=1, port=1234, text_base=0, data_base=0, bss_base=0 is in your bochsrc.

[iansjack]

Can Bochs also produce a dump file of network packets in the way that qemu can? I'm finding this particularly useful right now.

Debugging TCP/IP at the machine level would be a nightmare! (Although producing an annotated listing of your kernel with objdump -d -S <objectfile> is a useful tool.)