0bfusct3

Professional Linux Kernel Architecture has a good introduction into the Linux/os nomenclature.

People that have all this "talent" is nothing more than a drive for something - the talent in x, y, z is a side effect. My drive is for a distributed, vm based operating system and a language to go with it, subsequently I'm versed in mathematics, computer science, etc.

Tivo releases what they see as either not a competitive advantage or a burden to maintain. Just like Nvidia releases the shim but nothing relating the how the hardware works - it's a business they aren't here to plant daisies in the FOSS fields there here to make a bottom line.

My example may have been flawed (it was meant for exaggeration ) but the point still remains that API use is fine under GPL v2.

Then taking it all the way down to the hardware, every user of x86 should be required to agree to a license agreement to use an x86 processor since it 'interprets' opcodes on-the-fly thus everything that uses x86 is under an intel license QED. I don't know the full details of the thesis theme but use an API doesn't constitute violation of the GPL v2 - see: tivo and thousands of routers, wireless cards, etc.

Overhead of the operating system and more likely a massive amount of packets per second will easily peg a single core.. I did some tests with nginx (comparable to node.js) and it easily pegged a xenon 2 cpu quad core 8GB ram (all 8 cpu's were 90+%) with a paltry 8055.77 rps over 2 x 10gbit ethernet but then this is more likely an OS / fine tuning limitation

Maybe it's just me but I think this is incredibly stupid - He's abstracting the issue that Unix isn't distributed into a single application. It's like putting $5000 rims and mufflers on a $100 van.

Configuration files need to be static key value or a relational algebra - you cannot have mutations and branches based on logic within a configuration or else you introduce issues you wouldn't want to even dream of.

c, capabilties (or lack there of), self healing, runtime based optimizations, concurrency, locking, threading and just generally the way it's structured it's not meant to be a distributed operating system the applications developed for it show this. Have you seen how glusterfs, lustre or any other distributed FS works? They bend over backwards trying to implement a POSIX API usually with hideous hacks.

Sure they do but they use extremely specialized software that probably took years to apply to the platform let alone developing the software. Linux is the top in distributed computing because it filled a niche (free) and has momentum if BSD, L4, etc was created then / didn't have some sort of issue we'd all be using kernel x instead of linux

That's like saying language y is fine because I can just search and copy and paste... no you cannot. If you do anything beyond a simple [[ -f somefile ]] && do something sh turns into a nightmare.. case in point autotools.

Simple interfaces tying into a vm for complete distribution of software on any architecture. Concurrent, functional and slightly object orientated low level languages allowing automatic formal provability and easier formal provability. This is all quiet similar to Microsofts Midori / Singularity from what I can read on it anyways... but I'm sure Microsoft will screw it up somehow and cripple it.

The same can be said for *nixes, in order to create something in sh using programs you need literally days of reading man pages for switches, etc or use perl, python, etc.. but even then many tools don't have bindings so you're back to use sh.

All operating systems currently popular are crap except for the most popular one in it's usage domain.

Unix is bad, crusty and getting less relevant due to how computers are becoming more distributed and less as a single system. Linux may be the top of the herd right now but sooner rather than later there is going to be a huge paradigm shift into distributed computing. Linux will have no place in distributed computing without either layers upon layers to the POSIX API (aka backwards compatibility) or well a new operating system.

Get a hardware book and read up on how computers actually work. This will help an immeasurable amount to understanding why C is the way it is.

I recently ditched rails for sinatra / padrino (mostly sinatra) due to the fact that if you want to do something off the beaten path, even in rails 3 it's a complete crap shoot of trying to tie together different pieces since it seems people only work with rails specific active_* parts - You spend more time wrestling libraries in rails 2-3 than actually doing work.

Not to crap on the parade or anything but new languages are a dime a dozen and most all offer the same exact paradigms rehashed over and over and over. What I want is a low level easy to verify OOP/chaining functional concurrent language based on term rewriting. Something needs to be done to allow easier proving of programs with a language that is designed for this. I'm working on one.

This shows nothing more than a badly implemented api. POSIX is a bad api for anything modern (distributed).

This 6k vs 6M LoC comparison is pretty dubious. If your disk driver has a bug and overwrites some data you're just as screwed up, be it running in userspace or kernel space. The argument these bugs are less powerful because they are now in userspace "can't do very much" is at best limited

They are less powerful in user-space he states this about 25 minutes into the talk "moving bugs to user-space will do less damage"...roughly.This is true instead of getting full ring0 access to anything I can only do what the driver is allowed to do if I exploit a bug in the driver.

Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug

Why would there be added complexity? Linux has an api just as well but less defined than simple ipc - even more complex. Hard to debug? you do understand that having parts of the kernel in userspace makes it easier to debug

The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver.

Read LWN theres roughly a root exploit every 2 weeks

An ideal operating system would be a sort of exokernel but proven and a 'relaxed' api that would allow distributed computing. Unverified applications would run under a vm with proven parts being compiled as well as compiling heuristically verified parts and jitting the other needed parts.

Linux has exploitable bugs about once a week, read lwn and scan over the security page for kernel cve's.

The problem with opscode is that it still does take work to scale due to applications needing to be reconfigured in order to allow multiple servers (and this is the main issue with scaling: work). Currently I'm working on a very very similar project that does almost exactly what opscode does but it scales with zero configuration (where's my 11 million) meaning you could simply create an instance with your normal 1 server configuration and when the time comes scale to as many you want with no changes whatsoever. Maybe opscode does this as well.

Can we just call it what it's been known as in computer science since oh 1960's distributed operating systems?