Slashdot Mirror

Try a couple Pascal ones such as Toro or Ultibo. Or try a couple of Rust ones such as Redox or Nebulet. OSDev is a good resource for operating system starting points in various languages. You can take one of their bare bones OS examples and build from there.

Interesting thing is that PCID predates INVPCID. And you can get some of the effects of an INVPCID on a processor which only supports PCID.

I.e.

http://forum.osdev.org/viewtop...

MOV to CR3. The behavior of the instruction depends on the value of CR4.PCIDE:

If CR4.PCIDE = 0, the instruction invalidates all TLB entries associated with PCID 000H except those for global pages. It also invalidates all entries in all paging-structure caches associated with PCID 000H.

If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 0, the instruction invalidates all TLB entries associated with the PCID specified in bits 11:0 of the instructionâ(TM)s source operand except those for global pages. It also invalidates all entries in all paging-structure caches associated with that PCID. It is not required to invalidate entries in the TLBs and paging-structure caches that are associated with other PCIDs.

If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 1, the instruction is not required to invalidate any TLB entries or entries in paging-structure caches.

See
https://www.intel.com/content/... page 145

This chap tried it, and apparently it works

http://www.dumais.io/index.php...

I.e. with bit 63 and 0:11 set to PCID a write to CR3 works like INVPCID in processors which don't have INVPCID.

This actually makes a difference. My 2012 Macbook pro has a

machdep.cpu.brand_string: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C

I.e. assuming the patches know the bit 63 set in writes to cr3 trick, they should be able to do page table invalidation per PCID even on rather old chips.

It looks like KAISER on Linux supports/will support this

https://github.com/nathanchanc...

https://lkml.org/lkml/2017/11/... [currently down(!) but the title is "Subject [PATCH 4/6] x86/mm/kaiser: Support PCID without INVPCID"]

Funny thing is that this bug is almost an example of Intel throttling old hardware. The KPTI fix is apparently less of a performance hit if you have a new Intel CPU with PCIDs

https://www.theregister.co.uk/...

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features - such as PCID - to reduce the performance hit. Your mileage may vary.

PCID - Process Context ID - means you can tag the TLB entries with a 11 bit process ID.

http://forum.osdev.org/viewtop...

Also, the Intel manual says bit 0-11 of CR3 is used as the PCID. Does it somehow related to the usual process id user mode code see? If yes, does it mean it imposes a limit on the # of user processes (4096) allowed ?

Which means you don't need to flush the whole TLB - you just invalidate the ones which belong to a process you're switching away from

http://linuxeco.com/?p=488

A PCID is a 12-bit identifier, and may be thought of as a "Process-ID" for TLBs. If CR4.PCIDE = 0 (but 17 of CR4), the current PCID is always 000H; otherwise, the current PCID is the value of bits 11:0 of CR3. Non-zero PCIDs are enabled by setting the PCIDE flag (bit 17 of CR4).

When a logical processor creates entries in the TLBs (Section 4.10.2 of the x86 prog reference manual) and paging structure caches (Section 4.10.3), it associates those entries with the current PCID (Oh ... such a loose association of PCID with PID). Note that this means that where the PGD is located is somehow being interpreted in the PID "process context". When using entries in the TLBs and paging-structure caches to translate a linear address, a logical processor uses only those entries associated with the current PCID, and hence flushes of the TLB are avoided.

Presumably you could have on PCID value for the kernel and the other 4095 for tasks and not need to go a TLB flush when switching until the PCID value wrapped.

Of course that means you need a sufficiently recent Intel CPU.

https://software.intel.com/sit...

FMA, AVX2, BMI1, BMI2, INVPCID, LZCNT, TSX - Haswell and later

I.e. you need a Haswell 4xxx processor or later

https://en.wikipedia.org/wiki/...

At least for the Linux KPTI fix it seems like it does support PCID

https://lwn.net/Articles/74060...

- Integrated all fixes and Peters rewrite of the PCID/TLB flush code.

So does the macOS fix

https://www.macrumors.com/2018...

Ionescu also says that performance drop on a system with PCID (Process-Context Identifiers), available on most modern Macs, is "minimal," so most users may not see an impact on day-to-day Mac usage.

Of course if you have an 2012 Macbook Pro you've got an i5-3210M so you don't have PCID so you'll either have an insecure machine or a performance hit.

Interesting thing is if there was a class action lawsuit, I wonder if you could get Intel to give you a new CPU with PCID to minimise the impact of the bug fix.

There may not be an official way, but if your possible systems are all from a limited set and you're really only having to differentiate between Windows and UEFI or DOS and Windows (the other poster pointed out that there's an official way of having both DOS and Windows entry points),

That was me

then it should be possible to find a system call that just provides information on both systems and has a return value that lets you tell them apart. You do this early and then jump to the relevant entry point.

The problem is that even though Windows and UEFI both use PE files, there are significant differences.

Windows applications use subsystem=2 for GUI and 3 for console

https://msdn.microsoft.com/en-...

UEFI applications uses subsystem=10

http://wiki.osdev.org/UEFI#Bin...

Also windows executables are .exe and UEFI applications are .efi

I.e. it's hard to build a single executable that would pass the subsystem and file extension checks to run on both Windows and UEFI. Which of course is by design - otherwise people would run executables on the wrong platform and brick it.

Here it seems like Dell just distribute a bunch of different executables. One for Windows/FreeDOS(.exe), one for Linux(.bin) and one for UEFI (.efi)

http://www.dell.com/support/ho...

You could have them share a data file if space is at a premium.

Though a Win32/UEFI polyglot may be possible I can't find one. And I'm not sure how it would work.

The one possibility would be if Terse Executable files can begin at something other than offset zero in a file. TE files are a sort of stripped down PE file with all the unnecessary crap removed from the PE headers.

http://wiki.phoenix.com/wiki/i...

But it seems unlikely UEFI executable loader code is willing to skip bytes endlessly until it sees a VZ signature.

Virtualization vendors can't manage to keep people from finding new escape vulnerabilities.

Nor can CPU vendors. Despite the engineers' best efforts, some CPUs ship with defects that allow userspace software to lock the physical CPU. Some examples:

Maybe Redux will be something interesting. But, as I said, they need to do a lot of work first, and then, maybe, there will be others willing to help out.

Yeah, it's on the list.

The real question is whether they'll use X or Wayland.

Why not? People are making it for free. There's actually a wiki devoted to OSes, and there are quite a lot of them. Working on a kernel is fun.

These are the advantages and challenges of the GNU kernel. If you want to understand why people like the Hurd kernel, I would suggest reading that.

Why not? People are making it for free. There's actually a wiki devoted to OSes, and there are quite a lot of them. Working on a kernel is fun.

These are the advantages and challenges of the GNU kernel. If you want to understand why people like the Hurd kernel, I would suggest reading that.

I know you're joking, but if I ever have plenty of free time, I'll go here and spend some time figuring out how to boot systemd on the raw metal, making a true systemdOS. And I never joke. j/k. not.

You can move into C++, but then you have to be extremely careful of new/delete support

How much more careful do you have to be of new/delete support than malloc/free support?

Not much I'll wager.

You actually have to completely avoid it until you setup the functions necessary to support it. It's been a while since I've looked at doing it, but it's non-trivial, as is much functionality at that early boot stage.

And it's not like you have to support it. None of my Atmel code uses new or delete. Static allocation all the way.

This is why most embedded and kernel stuff only uses C as even C++ adds enough bloat due to those supports that when every byte counts it's just not useful.

C++ does not add bloat. That's an old, false meme which needs to die.

True, you can avoid stuff by following best practices for embedded and using pure stack allocation. But that only goes so far. You can also run into issues with Exceptions. For instance http://wiki.osdev.org/Bare_Bon... documents several issues.

I wonder what use they're thinking at all.

They see it as a highly efficient, waste-no-resources OS. Check out the memory footprint of Linux sometime.

Also, there are so many people building their own OS that there's a wiki devoted to it. It's fun.

Ok, has anyone ever written an OS kernel in Pascal? How about bare-metal code which tweaks registers?

They sure have. You, too, can write your own OS in Pascal. Nikolay Nikolov did.

What happens if Windows expires?

No prob, build your own OS!

And without GNU Linux couldn't have came to be -- Not like Linus create a command shell, file system, text editor, assembler, compiler / linker, etc. features that you MUST have for an OS to actually do anything with it.

You can write a kernel in a weekend. I've written several, some even from scratch using just a hex editor -- You can't do shit with just a kernel though, you have no idea how much more work there is to creating a self hosting OS from scratch than just getting your kernel up and running. People write kernels all the damn time. Linux is great because Linus is a great project manager, and Linus can be a great project manager because Git works beautifully -- not that it is beautiful, some real kludgey crap in there with multiple languages and what not, but that's not what matters: It WORKS and its ACTUALLY USABLE. Linus hardly even writes code anymore, he could manage the Linux kernel from within OSX or Windows at this point.

A C compiler is MOUNTAINS more work than a dinky little kernel. RMS really did write a shit load more code to make a free OS happen. So much, in fact, that his hands are fucking ruined from coding so much, and he can't even type but on a special light touch keyboard because it's so painful. The damn Linux kernel didn't even have an init procedure, or any really useful features at all when I first used it. There wasn't even an installer or ability to multi boot, which even a baby's 1st boot loader can do: Relocate your bootstrap in memory, walk the drives and partitions display the ones with 55h & AAh in 510th & 511th bytes, load the selected partition's 1st sector at 07C0h and jump to it -- Which I used instead of just the bootloader that Linux's "install" instructions would have left one with so I could keep GNU/Linux, DR-DOS and MSDOS partitions on the same machine.

Linux was a shitty and stupid design, it really was. x86 machines were everywhere. All the other most important pieces of the puzzle were laying there. Soon as Linus had his literally dumb bootstrap loader and sophomoric monolithic x86 kernel running he immediately asked for help, and boy did he need it! That he was able to wrangle the resulting tsunami is awe inspiring: He basically lived though an atomic blast that would have destroyed almost anyone else, and that's what his true contribution is: Being a realist who's in touch with how real people use software, and willing to accept help when someone says, "no, that's stupid, you need an init system, here." Unlike so many open source projects Linus knows how to delegate authority and keep it from becoming a petty ridiculous fiefdom. He also knows when to deal outrage where it's due. Berating morons for doing stupid shit also helped keep everyone from becoming up-tight corporate politically correct passive aggressive intellectual douchbags, which would have been FAR less inviting to the average hacker submitting their first patch.

Every time I say something to this effect a bunch of morons down mod me, but it's true. I call the fucking fanbois who down mod this morons because they're missing the whole damn point. Linux was nothing special, it just came in at the right place at the right time, with the right license. So fucking what? That doesn't take away from Linus' real achievements: Being an amazing project manager who knows the product inside and out. He's a clever guy, but come the fuck on, heaping praise for the kernel code he did would be like congradulating the doctor for pulling out the baby instead of the mother's who went through labor and months of bullshit to make the new life a success. RMS wasn't paying attention to what really mattered: Having the most people Being able to USE the OS as soon as possible. Most folks had personal computers, not mainframes or minicomputers, etc. big machines you find in university. Most hackers with computers weren't in University.

So, right after Linus asks for help, EVERYONE got interested because you could have

PC keyboards have a micro controller in them that does the keyboard scanning. When it gets a key it triggers an interrupt. The OS reads the scancode from a port for a PS/2 keyboard.

http://wiki.osdev.org/%228042%22_PS/2_Controller#Interrupts

If you have a USB keyboard it works the same but instead of IO port access the OS ends up reading the data from a USB Interrupt end point. It sets up linked lists in memory which the (UHCI,OHCI or EHCI) USB host controller scans through to poll the end points at the frequency they request

So is there a keyboard scan loop? Yes, but it's runs on a micro controller (actually you cold probably set up things on the micro controller so it sits in a halt instruction until there's an interrupt and you get an interrupt when any key is pressed, so you only scan when you know you'll find something for power efficiency). Is there polling? Yes, but the USB host controller does that by looping through a linked list of end point descriptors that the OS set up in memory. There's no code executing on the host CPU.

Incidentally the USB scheme changes in USB 3.0 and XHCI controllers to save power.

http://en.wikipedia.org/wiki/Extensible_Host_Controller_Interface#Power_efficiency

Yes, we can have mature conversation about Java.

1) Should become a Java developer? Consider all the hate so many people project at Java. Do you think people just hate it because it's so great? You dont get respect if dont act respectable.
2) Java keeps needlessly expanding and some parts get dropped.
3) Java is not a long-lived everyday programming language. Java showed up about the mid 1990s. C has been going strong since the early 1970s. C++ was an extension of C that came around in the 1980s.
3.1) How many programs do you have that are written in Java? The one's on your smartphone? Well, do you want to write those forever?
3.2) OSes are written in C and C++.
3.3) You can go with C# but you will be stuck on Windows until MS decides to reinvent the wheel again and C and C++ will still be widely used.

Java: write once, slow everywhere.

People who possess those skills are usually busy doing something else

Protip: Linux is successfull because of amazing project management by Linus. Hell, I consider Git a bigger boon to the world than Linux. Anyone can write a damn simple monolithic kernel, but to immediately gather a community and be able to maintain it is a rare skill. Leadership isn't key in sci-fi? Being in the right place at the right time with the right people helps too -- Also evidenced in sci-fi: A rag-tag group of ethnically diverse individuals from all walks of life will save the day! Diversity can help bring new ideas to the table...

Speaking of tables: Don't worry about the time table, if the engineer has to fix it before the deadline, they will find a way, even if it means working overtime: "I'm giving her all she can take captain!" Not to worry, they'll pull some engineering magic out out of thin air during the commercial break because this story arc is about to end.

Speaking of endings: How exactly does Neo see machines as orange colored lights? He didn't get a wireless upgrade, right? Programs escaping into the "real world"? Wait, he can kill sentenals wirelessly with his mind? Yep, instead of a green monochrome inspired world, he's trapped in an amber-screen level of the matrix. The Matrix shows you can always add another layer of indirection...

Look, it's a confirmation bias piece, it's just for fun.

So why can't you run OpenBSD? Nothing about the hardware forces you to run Linux. Here is a tutorial on how to write and boot your own basic kernel.

However, if your faith forbids the touching of 'unclean' hardware, then who am I to question it!

http://wiki.osdev.org/Context_Switching
It seems context switching from user to kernel space on a 2.8GHz P4 takes 481ns, on a 200MHz P2 it takes about 1335ns.
Switching back takes 330ns and 900ns respectively.
If you've had to switch address space as well, add another few hundred nano seconds.

So you've lost a microsecond just doing context switches.
Your IRQ thats triggered your ignition timing event also has a variable amount of latency to deal with, since you don't know what address space is going to be active when it occurs.

That's just plain ol' x86. It's getting better, slowly. Over a decade the CPU speed went up 14x but the context switching cost only went down 3x.

And remember that this isn't black and white. The Cathedral and the Bazaar was a comparison of two GPL licensed code bases...

Meanwhile, the Bazaar Cathedrill was about making a strange little prickish hose that people pissed themselves over. Neither had any real merit when discussing license adoption because they were about software development strategies, not licensing.

You also forgot the part where GNU had a complier and all the tools an OS needs that Linus NEEDED in order to make an OS, and the work he needed to do was pretty simple (by comparison) -- I know, I've made several shitty little bootloaders and OS kernels in ASM, and it was fucking easy, and Linus used C (and Assembly), which is even easier. Lots of folks do this, it's not hard.. Also, he was getting help from other folks during the development of the kernel, it didn't just spring forth fully formed only from his head. So, that Linus was using the GPL was due to the environment (litterally) the userland. If it had been BSD userland, he'd have probably adopted that.

None of that has much to do at all about popularity -- or moving code. The first usable ANYTHING gains lots of traction. Linus was making a UNiX like system for x86 PCs. Being the first popular thing in their respected areas is why both Windows and Linux have the success they do. License be damned, windows was firster, so it's now more popular.

if it weren't for Mr. Torvald's kernel, the GNU project would be still spinning its wheels.

Creating a kernel is easy. How long did it take Linus? Certainly not DECADES. Were it not for GNU, Linus's kernel wouldn't have done ANYTHING, and we'd STILL be waiting for him to get a decent compiler and userland tool suit running. Think about it. "I'm going to install the Linux Kernel!" "Why, it just sits there not doing a damned thing, doesn't even have a file system." Seriously. People make Monolithic Kernels all the damn time, it's not even hard. I wrote such a kernel and boot loader in x86 ASM in about two weeks worth of evenings for my toy OS. Linus' was just the first one to come along, and that's good enough for FLOSS. It sucks that GNU gets dropped from the name given how much MORE work was put into it than the dead simple kernel Linus wrote, and it really sucks that he didn't use the "at your option any future version" text in the license, -- I mean, he made it impossible to change the license why? It's not like commercial folks couldn't stay with GPL2 "at their option". I don't know man, you sound like you're putting Linus on a much higher pedestal than you need to. Great guy and all, but come on, what he did was and still is a TINY fraction of the work.

Going further, I wonder if it is possible to rip the 32-bit parts completely away from the silicon at some point?

Do you want that to happen before or after ripping out the 16-bit parts? Even the latest 64-bit CPUs boot up in 16-bit mode. As far as I recall you still need 32-bit mode because there isn't support for switching directly from 16-bit mode to 64-bit mode.

IIRC, I believe you switch into 64-bit mode just like 32-bit mode - by setting a flag in the processor then executing a far jump. So I believe you can indeed go from 16-bit mode directly to 64-bit mode with the AMD64/Intel64 instruction sets.

Documentation: http://wiki.osdev.org/X86-64#Entering_Long_Mode_directly
Code: http://wiki.osdev.org/Entering_Long_Mode_Directly

essentially - you can do it but you do risk resetting the processor if you don't setup the minimal protected mode environment - even if you don't actually go into protected mode.

And, for the record, you do not need to do anything special to go from 16-bit real-mode to 32-bit real mode aside from changing what instructions you are using.

Going further, I wonder if it is possible to rip the 32-bit parts completely away from the silicon at some point?

Do you want that to happen before or after ripping out the 16-bit parts? Even the latest 64-bit CPUs boot up in 16-bit mode. As far as I recall you still need 32-bit mode because there isn't support for switching directly from 16-bit mode to 64-bit mode.

IIRC, I believe you switch into 64-bit mode just like 32-bit mode - by setting a flag in the processor then executing a far jump. So I believe you can indeed go from 16-bit mode directly to 64-bit mode with the AMD64/Intel64 instruction sets.

Documentation: http://wiki.osdev.org/X86-64#Entering_Long_Mode_directly
Code: http://wiki.osdev.org/Entering_Long_Mode_Directly

essentially - you can do it but you do risk resetting the processor if you don't setup the minimal protected mode environment - even if you don't actually go into protected mode.

And, for the record, you do not need to do anything special to go from 16-bit real-mode to 32-bit real mode aside from changing what instructions you are using.

And, why do they hate Linus so much? From the Tresquel web page:

"Linus Torvalds did not write a whole operating system, he only wrote the last missing piece, a kernel"

Yeah, sure, completely gloss over the fact that the kernel is by far the most important piece.

The compiler is the most important piece. Without it you don't make kernels... I know, I've tried making one in machine code by entering hex. I gave up and wrote an assembler in machine code instead to develop the kernel with -- Linus just used the existing FLOSS compiler. Once you've got a compiler and Kernel running it doesn't do anything. You need at least a great shell program, some window managers if you're the GUI type, lots of command line tools, hell, even a file system before all that! The portion Linus contributed truly was a fraction of the work -- I've tried doing all of it myself from scratch (I have a crazy security related itch to scratch [separate stacks for data and instruction pointers] that means no C -- at first), and in doing so I gained a lot more respect for GNU and a lot less for Linus. That's when I started calling it GNU/Linux, and yes the GNU should come first.

Additionally, the kernel design of Linux is sort of dumb. It's the same insecure monolithic methodology that's applied in Windows. The fastest route, not the most secure, but hey, he was going for the fastest and easiest route. I don't discount what Linus did, but as someone who sometimes makes kernels for embedded systems, I can tell you that many people grossly overestimate the role a kernel plays. People make kernels all the time, it's not that hard to make them, just hard to be in the right place at the right time. Linus could have built his kernel on Windows, but I know from experience it wouldn't have attracted any users unless it had that awesome POSIX compliant GNU userland.

TL;DR: Why do think Linus deserves more love?

I agree with the bottom up approach to learning programming & CS.

I started off learning BASIC, but it was very slow going. As soon as I got into 8086 Assembly everything clicked into place. After making a few simple games, I built my own Boot loaders and toy OSs, Languages, etc. without any teaching or courses needed. I remember thinking, "I wonder how you make a bootable disk?", Turns out everything I needed to know was in the BIOS documentation: Interrupt 19

I agree that knowing about the circuitry was neat, and necessary for completeness, but it's by no means essential for CS, IMO. Learning the electronics didn't really help me much because at the instruction level even things like CALL are abstractions for more logic... Maybe if I had been learning on RISC hardware, or had been content to stay in some VM Sandbox I'd have a different view?

The difference between the NAND to Tetris course, and taking a crash course on (x86 | ARM) Assembly + RTFM for your BIOS and CPU is in the end, my programs actually worked on Real hardware. That makes my efforts far more useful immediately and far more relevant. For instance, I built disk partition tools and undelete utilities and actually sold them on a BBS I built myself, and I still use them to this day. I've got a .ISO with my OS and disk tools, and some games that I can put on Floppies, HDs, USB drives, CDs / DVDs, etc. and boot them with any x86 or x64 system.

I understand the course is for Universities, and so contains a certain level of depth, but IMO, after you study how NANDs can perform computations they should switch to ARM or x86 assembly using Real hardware -- A Raspberry PI costs less than their damn physical book!

Furthermore, NANDs alone do not a computer make. That's just WRONG. You need something to pulse the logic gates, like a Capacitor. If you want it to be actually useful then it'll need I/O: You'll need some buttons and a display. If you're not going to teach CS then why focus on the irrelevant underlying circuitry to such a large degree? When I was 18 I actually wired transistors, capacitors, resistors, LEDs and button switches together to "Program" an actual working Tetris game -- Didn't require a VM to run, and my friends were far more impressed than they would have been with some program inside an existing computer.

My point is: Don't preach building computers from scratch unless you're actually going to enable folks to do just that in real life. If it's a CS course then utilize an actual chipset. IMHO, Save time & download (QEMU | VMWare) + (GNU Assembler | NASM) then start building your own bootstrap loader that will run on real hardware.

Join the club. You and everybody else.

Join the club. You and everybody else.

There are plenty of people out there who might be interested in working on it. To understand how big the open source talent pool is, check out this page of people who made their own OS (more or less). Open source doesn't lack developers, think how many Windows Managers there are, and those take a lot of effort.

No, what Open Source lacks is quality, project management, stable APIs stable ABIs.

I don't know yet an FLOSS Operating System as usable as Windows or Os X.

There are plenty of people out there who might be interested in working on it. To understand how big the open source talent pool is, check out this page of people who made their own OS (more or less). Open source doesn't lack developers, think how many Windows Managers there are, and those take a lot of effort. It lacks people who know how to put polish on a product.

If the processes and government of WebOS are more open than Android, it may well gather more developers than Android. That is the true democracy of the marketplace of ideas.

Or maybe HP will release it 'open' with some restrictive license. Then wonder why everyone ignores them.

It is just a side effect that it would prevent other operating systems who don't have the correct security systems in place to sign their boot loaders from installing.

Such as any homemade operating system or any other operating system whose user base is too small to convince a major OEM to sign its key.

Not quite the same – but nevertheless (I couldn’t find the original of the one I was referring to): http://forum.osdev.org/viewtopic.php?p=158449#p158449

And you can make the Goatse image yourself easily enough in GIMP... Slashdot wouldn’t display a thumbnail anyway, I’ll let you figure out what sites to post it on...

If you are mostly interested in x86 hardware programming, you can visit the OSDev.org community.

The linked page is a wiki which explains the basics of os development quite well. The forum community is mostly newbie-friendly but also interesting for advanced developers. It's always nice to have a platform to publish your results when you figured something out on your own. The wiki and forum are ideal places for your own findings, and you will quickly get feedback from the community. :)

You've just demonstrated the precise problem: the Linux kernel developers would rather maintain a set of ideals with which the vast majority of their users do not agree than provide a standard driver interface for Linux drivers that would leave them source-compatible or binary-compatible between different versions of the Linux kernel. They'd rather release kernel updates that break every third-party driver every so often to encourage driver and hardware developers to open-source their work in exchange for integration into the mainline kernel tree.

Three separate attempts to create a portable standard for device drivers have already come and gone: the Uniform Driver Interface that started from the mainstream commercial Unix world, guaranteed source and binary compatibility of UDI drivers between OSs on one architecture, and died from pure politics; the Extensible Driver Interface (disclaimer: by me) that pandered to free software ideals by guaranteeing mere source compatibility but failed to gain a following in its tiny home community; and the Common Device Interface that has gained some currency in the German hobbyist OS-development community but has very little material available in English. If the Linux kernel developers went through these and picked any one of them to implement, it could not only increase the market share of Linux operating systems out in "the world" but serve the ideals of free, open software by giving to the OS research and hobbyist world a real, usable way to avoid the tedious drag of reimplementing device drivers for even the most primitive functionality on every single new OS.

There's a discussion that is similar to this on osdev.org @ http://forum.osdev.org/viewtopic.php?f=2&t=19353&p=151513

Writing a monolithic Unix-style kernel from scratch is no big deal. Students do that as a project in universities. Check out osdev.org -- it's literally packed with operating system development hobbyists. Similar scenes exist for compiler design, programming language design, realtime 3d graphics, non-realtime 3d graphics, and what have you, with varying levels of overlap with academia.

A conservative UNIX clone is clearly not what the FSF went for with the Hurd. The FSF has always had the goal of being "sufficiently dissimilar" to Unix tools to not attract the same kind of shitstorm that kept FreeBSD in a legal limbo for a decade. Thus, the FSF went with an unorthodox, Mach-based microkernel design and slapped on a number of fairly advanced things like user-mountable filesystems, pervasive object-based access control and so forth. This may have been too much to chew, particularly with the Free Software management protocols and procedures in use at the time (i.e. do as rms says, regardless of whether he's involved in that particular subdesign or not. use of CVS, the only game in town, leading to megachangesets that cannot be reasonably backed out of.)

Research operating systems take time. Most never get to the stage where they're runnable. Don't accuse the FSF of incompetence: they already did 1-to-1 replacements for 95% of UNIX, and that's a bloody huge job compared to an operating system kernel.

armchair OS designer's reading list

Read this to get a handle on other possibilities for OS-level parallelism support.

Thanks for the link to the Open Graphics Project, that was new to me. I run a website for ameatur operating system developers and while a 3d version of a VESA BIOS would be nice I can say that most of us would just be happy with open specs. Note to others: People are trying to make all kinds of truly open hardware, on of the biggest sites is http://www.opencores.org/

Each page(sometimes a grouping) needs to become it's own community. I run a forum about writing operating systems and I've just setup a mediawiki to contain osdev(as it's called) information. My mediawiki requires accounts to edit/post content to the wiki and (with a free mediawiki plugin)the accounts are just forum members that I've placed in a certain group. Myself and fellow moderators can very easly determine who has valid content to contribute to a osdev wiki but it's just to overwhelming to try to maintain that level of control for topics I'm not familiar with. You compare just the "amateur systems" section on http://en.wikipedia.org/wiki/Osdev with my project list at http://www.osdev.org/wiki/index.php/Projects, 23 vs 132 OS projects listed. I'm not saying that people visiting the Osdev page on wikipedia should be redirected to my site, I think more community features need to be added to mediawiki. I say lock all pages and require community involvement to gain editing rights. You might lose a poster that just wanted to dump off information but that's why I have a forum for people to make requests in. Basically the forums become the filter/distiller for the wiki in the long run.

here and here

Half of what you want is cpu documentation, Intel makes nice free guides to their 32 bit x86 cpus. Sometimes they even will send out the manuals free in book format, right now it looks like you can download them or order a free cd. Check back often because the free books(shipping free too) come and go. http://developer.intel.com/design/pentium4/manuals /index2.htm

The other main half is BIOS info, check our Ralf Brown's int list: http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/p ub/WWW/files.html

For the rest you just need lots docs about various hardware like floppy controllers and such, check out my site for OS developers since I probably have more links listed then anyone else. Besides this stuff you might want to re-include java in your google searches because most of the research into virtual machines that I've seen uses java but alot would still apply.

• Courier IMAP - Supports Maildir, works well with most IMAP webmail setups, easy to setup, support Secure IMAP
• Postfix for SMTP - Can offload mail delivery to another program like Procmail, replaces Sendmail
• Procmail for Delivery - The Great thing about IMAP is that you have message folders on the server, procmail will allow you to sort incoming mail as it arrives.
• Spamassassin - Integrates with Procmail to sort spam into a folder or /dev/null
• SquirrelMail - Seems to be one of the best web based IMAP clients around, done in PHP