My proposal for creating a hobby OS Dev SE was closed as a duplicate of computer science SE.

While I certainly don't agree with that, what should I expect to happen for proposing the same site but with a broader scope, say Operating System Development. This does not include writing modules for Linux or anything specific to a particular OS. This site considers questions related to general operating system development.

Why do I believe that OS Dev does not fit into Computer Science SE?

Here is a question related to operating system development but is bound to get closed in CS SE as off-topic.

  1. How do I distinguish between onboard and PnP PCI devices?

  2. How can I use unreal mode to load a kernel past 1MB using BIOS interrupts?

  3. Setting GDT register causes CPU to triple fault

  4. Do I have to wait for the i8259 for a response before sending out an ICW?

  5. What are the methods used to keep the kernel code independent of the system architecture?

  6. Is loading a hardware abstraction layer as a separate module which in turn loads the kernel expensive?

  7. Why are 12bit entries used instead of 16bit entries in FAT12 file system?

  8. Efficiency of moving FPU state from one core to another

Operating system development is a specialization and hence, most programmers or computer scientists who haven't specialized in the field would have little to zero clue about OS development. A person who is trying to optimizing algorithms or working on a new faster algorithm to factor numbers won't be able to answer questions on operating systems.

Operating system development is a very broad field and doesn't fit well in any of the existing Q&A sites.

Topics which might be covered in operating system development could be:

  1. General Topics

    1. Processor Architecture
      • x86 (serves as an example, this site would support more architectures)
        1. Global Descriptor Table
        2. Interrupt Descriptor Table
        3. CPU Exceptions
        4. Real Mode
        5. Virtual 8086 Mode
        6. Protected Mode
        7. Long Mode
        8. Unreal Mode
      • ARM
      • MIPS
      • PowerPC
    2. Memory Architecture
    3. Operating System Design
    4. Hardware Abstraction
  2. Build toolchain and emulators

    1. Building crosscompilers
    2. Standard Libraries/Freestanding
    3. Assembler Selection
    4. Emulators
  3. Firmware

    1. Basic Input Output System
    2. SM BIOS
    3. UEFI
    4. BIOS Data Area (BDA/EBDA)
    5. Boot process
  4. Kernel Design

    1. Monolithic Kernel
    2. Micro Kernel
    3. Nano Kernel
    4. Hybrid Kernel
    5. Exo Kernel
    6. Modular Kernel
    7. Kernels for virtualization
  5. Process Management/Multitasking

    1. Interprocess Communication
    2. Scheduling
    3. Task Models (monotasking, multitasking, real-time)
    4. Multiprocessor Task Switching
    5. Semaphores
    6. Spinlocks
    7. System Calls
    8. Priority Tree
    9. Threads
  6. Memory Mangement

    1. Physical Memory Management
    2. Virtual Memory Management
    3. Segmentation
    4. Memory Models
    5. Paging
    6. Memory Allocation/Deallocation
    7. Heap, Garbage Collectors, etc.
  7. Devices and Drivers

    1. Timers and Clocks
    2. Peripheral Component Interconnect (PCI)
    3. Peripheral Component Interconnect Express (PCIe)
    4. Universal Serial Bus (USB)
    5. Network Devices
    6. Storage Media
      • Floppy Disks
      • ATA
      • ATAPI
      • DMA
      • AHCI
    7. Keyboard, Mouse
    8. Serial Ports
    9. Parallel Ports
    10. Video
    11. Audio
  8. Input/Output

    1. Deadlocks
    2. Interrupts Requests
    3. Interrupt Service Routines
    4. Sharing Interrupts
    5. Programmable Interrupt Controller (PIC)
  9. File Systems

    1. Files and Directories
    2. Implementation
    3. Security
    4. Existing file systems
      • ext
      • FAT12/16/32
      • NTFS
      • VFS
      • and more
  10. User-interface

    1. Graphical User Interface
    2. Window Managers
    3. Command Line Interface/Shell/Terminal

There are topics which at first might seem to belong to an existing SE site. For example, interrupts are used in DOS but this has almost nothing to do with what we are talking here. The DOS interrupts are ways to trigger interrupts and install interrupt handlers. When we talk about interrupts in the scope of the proposed site, we are talking about programming the interrupt controllers, setting up interrupt vector tables, etc.

When we talk about memory allocation, we are not talking about the new or delete operators. In fact, the C++ new and delete operators are simply not available in operating system development. An OS developer will have to implement his own methods to allocate and deallocate memory. In our context, memory allocation would mean about managing and finding free memory blocks and allocating them to the process which requested it.

A more silly example might be timers. The standard library provides a time library but this has nothing to do with operating system development. In fact, the time library provided by the standard library is pretty much useless. When we talk about timers in the operating system development context, we talk about programming the PIT or HPET device and using their facilities to maintain a tick count.

For obvious reasons, this is not computer science and hence OS Dev SE is not a duplicate of computer science.

share
up vote 5 down vote accepted

Your enumerated list of subjects looks eerily like the syllabus of every computer science curriculum I've studied. But no matter; proposals for new sites are considered if they can define a new topic space not already covered by our existing sites.

But understand that early Operating System proposals were closed as a good fit for Stack Overflow, so when we created two Computer Science sites to explicitly cover that space, many more were closed as a duplicate there. But we finally gave in and built an Operating Systems site… and it barely topped two dozen questions because nobody showed up — the audience was already being well-served across our many many programming sites.

We are proceeding under the assumption that you already have an existing audience who are willing and eager to actively build this site. But this proposal will have to demonstrate that it will do much better than under the subjects that already cover that space.

Good luck.

share

Like any applied computer science topic, operating systems spans both computer science and programming. Operating systems development does not fit in Computer Science, but it does fit in Computer Science plus Stack Overflow. Most of the topics you list here are fit for Stack Overflow.

If there's a new site about OS development, it wouldn't be to cover a space that the existing sites do not cover, but to find a unified home for a transversal topic.

We tried it once, and there was extremely little traffic during the private beta, so the site didn't take off. Creating a new site for a transversal topic only makes sense if the existing sites don't cater to that topic well and there's enough of a community for it. So:

  • Do SO and CS together cover all topics related to OS development? Yes. (Perhaps some architecture topics might be a better fit for Software Engineering, but there's very little if anything that would be off-topic on both SO and SC.) Most questions from the OS private beta were migrated to
  • Do SO and CS do a good enough job with OS-related questions? I think so (as much as any other topic), and I haven't seen evidence to the contrary.
  • Is there enough of a community to sustain a separate site? There wasn't in 2014.

Creating a separate site introduces fragmentation because it splits the community. Back in 2014, I argued against a separate OS site for that reason. (Note: my day job is to make an embedded operating system. I'm not trying to kill your buzz: your buzz is my job!)

The right size of a topic for a Stack Exchange site is typically a university department. Universities have computer science or software engineering departments, sometimes both, they don't have operating system departments. Operating systems are one level down, best handled by tags on a broader site. This rule of thumb doesn't always apply — it doesn't generalize well to non-academic topics like computer usage or vehicle maintenance — but in this case, I find that it does.

Having a separate site is not a matter of prestige, or importance. There are Stack Exchange sites about niche topics (I learnt about the existence of more than one CMS when I discovered that there was a Stack Exchange site for it) and there are important topics that are just a tag on a site. Separate sites are separate communities. OS developers are not fundamentally different from other developers in the way developers are fundamentally different from historians or car mechanics. OS development doesn't have its own university department or its own professions. It's one specialty among others, and it's closely intertwined with other programming and computer science topics such as low-level programming, concurrency, security, etc. We don't need a separate site.

So please go and ask your questions on Stack Overflow, or, if you have more theoretical questions, on Computer Science.

share

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .