5 ms·

Dependency hell has very little to do with kernel design - it's entirely a user mode problem. Neither Linux or Windows NT in the modern iterations are true mon

Dependency hell has very little to do with kernel design - it's entirely a user mode problem. Neither Linux or Windows NT in the modern iterations are true monolithic kernels - e.g. on Linux FUSE allows filesystems in user space, loadable and unloadable kernel modules, Windows has a User mode drivers framework which is increasingly used post Vista. Neither QNX or Minix are as feature full as Linux or Windows NT - almost all development on Linux and Windows is in driver development, not core kernel work (e.g. scheduler, IO system, memory manager). Windows NT remains a more modern kernel (in terms of internal consistent object model, basic kernel primitives) than either BSD or Linux, but whether it's absolutely better is a harder argument. In general the argument regarding micro/monolithic kernels is old hat in practice we can make extra-ordinarily reliable monolithic kernels, while we can also avoid a lot of the pain associated with microkernels - e.g. minimising context switch time. The reliability, security, flexibility argument is largely made redundant by man-power dropped into modern kernels - better use Linux because although it's theoretically inferior it has 1000s of days of development thrown at it. Kernel development also appears to be transitioning to using safety in compilers to improve reliability, but that's been a research topic for decades - the answer to 'can we build a sufficiently smart compiler' has been 'maybe' for a long time - though LLVM and Rust's compiler show a way forwards.

nickpsecurity 11y ago
"Dependency hell has very little to do with kernel design - it's entirely a user mode problem." The comparison was desktop Windows to desktop Linux, where it matters. The Linux software managers work around this problem most of the time but can fail hard in ways that require a different interface and level of knowledge. With Windows, I usually just uninstalled and reinstalled a specific component. All done. "Neither QNX or Minix are as feature full as Linux or Windows NT - almost all development on Linux and Windows is in driver development, not core kernel work (e.g. scheduler, IO system, memory manager)." "n general the argument regarding micro/monolithic kernels is old hat in practice we can make extra-ordinarily reliable monolithic kernels, while we can also avoid a lot of the pain associated with microkernels - e.g. minimising context switch time. " Again, within my claim, this has less relevance. What work went into QNX and Minix led to systems with better attributes (esp reliability & maintenance) than UNIX's at similar level of labor. This was almost totally due to their architecture: variants of microkernel design. Improvements in CompSci & industry to microkernel work killed a lot of their disadvantages. The kludgey ways of emulating such things in monoliths take a ton of work to get right and still don't go as far as the real thing. So, it's a worthwhile comparison. You can band-aid up bad architectures all day until they seem to get by well. Doesn't change the fact that building on good architectures gets better ROI in terms of attributes they provide. "Windows NT remains a more modern kernel (in terms of internal consistent object model, basic kernel primitives) than either BSD or Linux, but whether it's absolutely better is a harder argument." Only way I can see to make assessment is to see how easily amateurs make readable, maintainable, consistent, efficient code with each. Not sure how that would turn out. "The reliability, security, flexibility argument is largely made redundant by man-power dropped into modern kernels - better use Linux because although it's theoretically inferior it has 1000s of days of development thrown at it." I've lost too much data to Linux desktops, the mainstream ones, to ever believe that nonsense. I'd switch over to a more resilient architecture the second I had the chance should one have been developed. Unfortunately, clean-slating an OS is a ton of work even with a good starting point: Solaris 10 was almost $200 mil. It's mainly economics that keeps them going: cheaper/easier to maintain backward compatibility & use good enough features with bandaids for availability & reliability. I use Linux desktop (with plenty backups!) for the same reason. Note that this doesn't counter technical arguments against using such architectures at all. New, clean-slate projects should use what got better results. Projects focused on practical... something usable now... should build on cleanest prior OS's. "Kernel development also appears to be transitioning to using safety in compilers to improve reliability, but that's been a research topic for decades - the answer to 'can we build a sufficiently smart compiler' has been 'maybe' for a long time - though LLVM and Rust's compiler show a way forwards." It was more or less answered with things like Ada where common issues were countered by language and compiler design. It was even used in high assurance OS's like Army Secure OS (ASOS). Tools like Cyclone, SPARK, Astree, SVA-OS w/ SafeCode, and Softbound + CETS take it even further to kill even more issues. Hell, even Burroughs in 1961 caught out-of-bounds, stack, and invalid argument issues at hardware level with acceptable performance for OS written in high-level, ALGOL variant. It's not a lack of evidence than better language, architecture, or hardware design leads to more robustness: it's a lack of adoption by mainstream like always. They'll ignore most developments no matter how little work or performance overhead if it's not the norm. As you said, LLVM and Rust are bringing it back in people's consciousness. A Very Good Thing. They're already experimenting with verified compilation, safe OS's, etc. Maybe they'll rediscover some of that 60's or 80's wisdom. Maybe, probably, learn great new things on the way.

nickpsecurity 11y ago

"Dependency hell has very little to do with kernel design - it's entirely a user mode problem." The comparison was desktop Windows to desktop Linux, where it matters. The Linux software managers work around this problem most of the time but can fail hard in ways that require a different interface and level of knowledge. With Windows, I usually just uninstalled and reinstalled a specific component. All done. "Neither QNX or Minix are as feature full as Linux or Windows NT - almost all development on Linux and Windows is in driver development, not core kernel work (e.g. scheduler, IO system, memory manager)." "n general the argument regarding micro/monolithic kernels is old hat in practice we can make extra-ordinarily reliable monolithic kernels, while we can also avoid a lot of the pain associated with microkernels - e.g. minimising context switch time. " Again, within my claim, this has less relevance. What work went into QNX and Minix led to systems with better attributes (esp reliability & maintenance) than UNIX's at similar level of labor. This was almost totally due to their architecture: variants of microkernel design. Improvements in CompSci & industry to microkernel work killed a lot of their disadvantages. The kludgey ways of emulating such things in monoliths take a ton of work to get right and still don't go as far as the real thing. So, it's a worthwhile comparison. You can band-aid up bad architectures all day until they seem to get by well. Doesn't change the fact that building on good architectures gets better ROI in terms of attributes they provide. "Windows NT remains a more modern kernel (in terms of internal consistent object model, basic kernel primitives) than either BSD or Linux, but whether it's absolutely better is a harder argument." Only way I can see to make assessment is to see how easily amateurs make readable, maintainable, consistent, efficient code with each. Not sure how that would turn out. "The reliability, security, flexibility argument is largely made redundant by man-power dropped into modern kernels - better use Linux because although it's theoretically inferior it has 1000s of days of development thrown at it." I've lost too much data to Linux desktops, the mainstream ones, to ever believe that nonsense. I'd switch over to a more resilient architecture the second I had the chance should one have been developed. Unfortunately, clean-slating an OS is a ton of work even with a good starting point: Solaris 10 was almost $200 mil. It's mainly economics that keeps them going: cheaper/easier to maintain backward compatibility & use good enough features with bandaids for availability & reliability. I use Linux desktop (with plenty backups!) for the same reason. Note that this doesn't counter technical arguments against using such architectures at all. New, clean-slate projects should use what got better results. Projects focused on practical... something usable now... should build on cleanest prior OS's. "Kernel development also appears to be transitioning to using safety in compilers to improve reliability, but that's been a research topic for decades - the answer to 'can we build a sufficiently smart compiler' has been 'maybe' for a long time - though LLVM and Rust's compiler show a way forwards." It was more or less answered with things like Ada where common issues were countered by language and compiler design. It was even used in high assurance OS's like Army Secure OS (ASOS). Tools like Cyclone, SPARK, Astree, SVA-OS w/ SafeCode, and Softbound + CETS take it even further to kill even more issues. Hell, even Burroughs in 1961 caught out-of-bounds, stack, and invalid argument issues at hardware level with acceptable performance for OS written in high-level, ALGOL variant. It's not a lack of evidence than better language, architecture, or hardware design leads to more robustness: it's a lack of adoption by mainstream like always. They'll ignore most developments no matter how little work or performance overhead if it's not the norm. As you said, LLVM and Rust are bringing it back in people's consciousness. A Very Good Thing. They're already experimenting with verified compilation, safe OS's, etc. Maybe they'll rediscover some of that 60's or 80's wisdom. Maybe, probably, learn great new things on the way.