What I find interesting is that you even know all this stuff :). Keep pumping out them knowledge vids DJ and thanks for sharing as always.
@CyberGizmo4 жыл бұрын
Welcome Tax Action, just a head full of useless computer trivia )
@CyberGizmo4 жыл бұрын
When talking about Multics and how UNIX "borrowed" from what Bell Labs had learned from Multics I said "Rob Thorton" and it should have been Ken Thompson...Rob Thorton was the 3D genius behind Babylon 5. Yeah I've been re-watching the series...
@sleepyeyesvince3 жыл бұрын
Still my all time favourite sci-fi series
@BrucesWorldofStuff3 жыл бұрын
Love me some B-5. Watching last night... :-)
@mishrasidhant2 жыл бұрын
What a goldmine, will be binging your videos! Much appreciated, for a newby to get filtered knowledge from someone so experienced is a blessing!
@CyberGizmo2 жыл бұрын
Thank you, Sid!
@danielkrajnik3817 Жыл бұрын
absolutely wunderbar presentation
Жыл бұрын
I appreciate you so much! Thank you for your videos. I really believe that the passing down of history and "lore" really does a lot for a more holistic understanding. Not only the "what" things are and where they came from... how they evolved... but especially the why things are how they are. It's one of those "intangible" things that I really think makes a huge difference in the development of one's own understanding and skill set. Anyone can suss out the nuts and bolts of a thing. But the story that goes with it adds so much. This, I think, is an important - if often overlooked - aspect of mentoring. Mentors can educate and guide you, of course. Everyone knows that. But they also can deepen your understanding and get you involved in the story of things. And I think that matters.
@scottdrake5159 Жыл бұрын
I said exactly the same thing to a friend last night. Different societal structures had and haven't had "loremasters" as a role, and I think there's value in those that have them. In this time, I think our "loremasters" are invaluable. Knowledge can be passed down, lost and rediscovered, in "archival" or written/artistic form, as was the case with the Greek classics and many other discoveries of archaeology, but we always lack context and have no way to verify that we're not missing something that would turn it all on its head (and we almost certainly are.) I'm grateful for these videos, as well.
@hexearth82583 жыл бұрын
Yes, please more. Let the "Linux Internals Series" start!
@CyberGizmo3 жыл бұрын
Will do, thanks Hex Earth
@scottdrake5159 Жыл бұрын
Sorry to post twice, but I just realized that I do have a request for a future episode. I've never in my life requested one from a YT essayist, but since it was mentioned, and I see others do so: I've written a couple of device drivers; exclusively just to get something to work I that I needed, and succeeded even if it was a hack. It would be wonderful if a _good_ kernel module using Linux 6+ (or even 5) APIs was documented, being developed in a video. Guides exist, I know, but it would be great to see your process, given your experience with multiple generations of Unix (including those without kernel modules, I guess.)
@CyberGizmo Жыл бұрын
Scott thanks for the suggestion will look into it
@tourdesource Жыл бұрын
@@CyberGizmo People would probably pay for that, too. There's loads of basic content out there, but few with hands steady enough to do what Scott suggested.
@Random_Gopnik Жыл бұрын
Well worded technical explanation and history lesson in one video, amazing! Thank you.
@DrZingo_3 жыл бұрын
Short answer; Yes more of this stuff.
@CyberGizmo3 жыл бұрын
Will do and thanks Markus
@sleepyeyesvince3 жыл бұрын
Thank you DJ, keep these coming!
@robannmateja5000 Жыл бұрын
Great video! Thanks1
@guilherme50943 жыл бұрын
Interesting video, thank you very much.
@CyberGizmo3 жыл бұрын
Welcome Felix
@dezmondwhitney12084 жыл бұрын
Very Interesting. Thank You.
@CyberGizmo3 жыл бұрын
Welcome Dezmond
@dezmondwhitney12083 жыл бұрын
@@CyberGizmo My first and last semi-serious IT Experience was with UCSD Pascal run in a Dos shell, during the late 1980's in the Uk. I have a bisa this and bitsa trhat interest in thing IT ever since at a non-professional level. However, for various reasons , I have followed Linux since 2004 ish and now run OpenSuse Leap as my sole Operating System. Your information in your uploads is interesting and I learn something each time. Thank You.
@OleksandrBazna3 жыл бұрын
Awesome. Thanks a lot for your videos.
@diegonayalazo2 жыл бұрын
Thanks
@gorgeous_cloud Жыл бұрын
Your videos are gold!
@night4wl9593 жыл бұрын
Thank you, very helpful..
@CyberGizmo3 жыл бұрын
You're welcome!
@bacshy Жыл бұрын
How about the idea of Immutable systems? can you talk about the subject and maybe show how to use such a system?
@royhills Жыл бұрын
I remember that the Vax architecture also has four protection rings, and I think it predates Intel's protected mode. Dec's VMS operating system used these for the kernel, the filesystem, the shell and the user code.
@BrucesWorldofStuff3 жыл бұрын
Interesting stuff! Thanks for the video... LLAP
@CyberGizmo3 жыл бұрын
Welcome Bruce
@catsupchutney Жыл бұрын
I did not know that a daemon was not the same as a demon.
@thebigmacd Жыл бұрын
Linguistically, they are alternative spellings of the same word, both pronounced "dee-mon." It means "messenger." The same way "paediatrics" and "pediatrics" are the same word with a single pronunciation. "Ae" comes from Latin in this case and is pronounced "ee." The pronunciation "daymon" seems to arise from people trying to emphasize a distinction in words when there really is none.
@tsiiphsycoii Жыл бұрын
I need a mirror to see my ring
@Remigrator4 жыл бұрын
Ah shoot, I hoped that would be something that I could buy my g/f to protect her from Windows 🤣
@CyberGizmo4 жыл бұрын
hmmmm lol
@scottdrake5159 Жыл бұрын
I'm really shocked about the "demon"/"daemon" thing. I started consciously pronouncing both as "demon" years ago, maybe for the wrong reasons if you are correct. You seem to be a primary source for this, yes? I couldn't find other sources, and ran to peers to ask about it, but we are babes in the woods. I'd love to know more (sorry to hyper-focus on something that might be trivial.)
@CyberGizmo Жыл бұрын
the differentiation came from Steven Bourne during one of his classes on UNIX, I don't think Linux follows that convention as I do no see any mention of it in their docs or source code.
@LinuxJediMaster2 жыл бұрын
I have never seem "demon" being used to reference a device driver, and could not find any reference to it other than this video ...
@CyberGizmo2 жыл бұрын
You probably won't unless you happen to stumble over the AT&T System V source code, its in there.
@CyberGizmo2 жыл бұрын
Took some digging, but this is from Research Unix 10: Its a piece of the comment block for udemon one of the device drivers that handled the file system /* * fdemon tiu txt msiz [trace] * file store demon to handle commands from (tiu). * the txt arg is not used. * The maximum message size sent to the user is (msiz). * If (trace) is present the demon will trace on the specified file. * the current output is used if '-' is specified. */
@NitroNilz3 жыл бұрын
Yes, more of these "it all came from Multics"-videos (joke)! These long lines back in history without drowning in details is really a nice format. A twinkle of trivia here and there only boosts it (is that English?). You are a Linux fan and probably most of your audience - but why call'em **Linux rings**, when they are **Multics rings**? I also just discovered that Multics didn't lay down until 2000 and something. Might have been Multics.org EDIT: That domain was "stolen" by Super Dimensional Fortress (a public access Unix system, run by NetBSD on DECs). The site is Multicians.org!
@CyberGizmo3 жыл бұрын
Thank you Nitro, and yep will do more like this one. And I understood you clearly, thanks again
@sergesereda13543 жыл бұрын
Thanks for another great video! But I'd like to act as an advocate of Microsoft Windows for a little. Microsoft Windows kernel architecture is described among others in the ‘Windows Internals’ book by Mark Russinovich et al. One can acquaint with its fragment about Windows kernel architecture for free thanks to Google Books service (books.google.com/books?id=y83LDgAAQBAJ&pg=PT28&source=gbs_selected_pages&cad=2#v=onepage&q&f=false). In particular it contains paragraphs ‘Kernel mode vs. User mode’ (Chapter 1) and ‘Virtualization-based security architecture overview’ (Chapter 2) with overall description of actual Windows kernel operating principles.
@sergesereda13543 жыл бұрын
Also there is a series of three videos about Isolated User Mode in Windows 10 at channel9 (filmed in 2015): 1. Isolated User Mode in Windows 10 with Dave Probert - channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert 2. Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel - channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel 3. More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert - channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert And I also found there a standalone video ‘Windows 10 Virtual Secure Mode with David Hepkin’ - channel9.msdn.com/Blogs/Seth-Juarez/Windows-10-Virtual-Secure-Mode-with-David-Hepkin Of course, we can’t name these videos ‘technical documentation’ but they, indeed, contain some information about Windows kernel.
@lewiscole51936 ай бұрын
A few piddly points of no real importance. First, about the history of "rings", I think that a case can be made that they came long before Intel, Unix, or Multics although In The Beginning they had nothing to do with protection/"trust". Instead, in The Good Days, there was no OS and so each program needed to include software to deal directly with the hardware. Presumably, at some point in time, people got tired of writing their own versions of this hardware management software and so made it into its own blob that could be added to the other software they wrote. You just added the deck of cards for your new software to a smaller deck of software that you kept laying around somewhere. Similarly, someone presumably came up with the bright idea to separate the truly dependent hardware management software from that which effectively created a function/service abstraction which could be made into its own separate "library". Tanenbaum describes this partitioning into layering of software in his book, "Operating Systems Design and Implementation, 3rd Edition", and specifically mentions Dijkstra's "THE" system which was officially released in 1965, which as I'm sure you are aware, was before Unix hit the fan. Layer 0 contained code for processor allocation and multiprogramming, layer 1 contained code for memory and drum management, layer 2 contained code for operator-process communications, layer 3 contained code I/O management, layer 4 contained user programs, and layer 5 was for the operator. Second, Multic was originally run on a GE 645 which didn't originally support "rings" or if you prefer, didn't support any more than two rings. It had a mode/privilege bit that indicated whether you were in "master" mode or "slave" mode. The bit about "rings" and what to do to make transitions between them had to be simulated by software until the hardware was changed. IOW, to go from into the OS ("master" mode) which then routed you to where you wanted to be ("slave" mode) after doing the necessary magic to make it look like there were hardware "rings". I don't know how the hardware was changed (I'm not a Multician), but presumably something was cooked up to implement a "gate" which is conceptually how you're supposed to go from one ring to another. In a way, the same sort of non-sense was implemented for Minix-3 in that there's a relatively small amount of code that executes in gawd mode which is capable of doing anything and everything else which executes in user mode, but with a certain hierarchy of trust implemented by controlling what messages can be sent to whom via the gawd mode code. Third, when the 386 came along, it had hardware recognized gate segment descriptors which could be used to transition from one ring to another *WITHOUT* making a system call (i.e. executing an instruction that causes an interrupt). To change ring levels, you just did a jump or call referencing the gate and the hardware took care of changing the CPL (Current Privilege Level) when doing so was permissible. This took significant effort on the part of the hardware, but that's what CISC is for. But the effort was supposedly less that taking an interrupt to get some code in gawd mode to make a change. I don't know what OS/2 did with rings, but I doubt that the used the gate descriptors provided by the hardware. But that's just my guess. If I'm right, the poor performance that you attribute to the use of rings actually comes from their not using the hardware that Intel provided and instead at best trying to fake rings just the same as the original GE 645 did. Certainly, there's nothing about rings that requires taking an interrupt in order to have/use them. I would remind you that Kidder's book "Soul of a New Machine" waved it's arms at how ring protection as implemented on the Eclipse where the upper bits of each address were treated as a ring number. I don't know what they did to deal with ring transitions, but ISTM that one could get there from here through the use of a little extra hardware that only allowed entry into one ring from another only if one entered the ring at just one location, say, the start of a ring's code. IOW, no interrupts, no gates, just a jump/call to a particular location. Fourth, I take issue with your characterization of what Intel wanted to do with its x86 rings. They created hardware that would let you (the operating system writer) do whatever you wanted, and threw in the kitchen sink so that you could. But they did not say that ring 0 was for kernel, ring 1 was for device drivers, ... , etc. You cannot find anything in the Intel 386 programmer reference manual that says anything of this sort. Moreover, since we're talking about rings in terms of "protection", what we're really talking about is "trust". Is a particular piece of code trusted enough to use certain resources of the CPU? This means that only certain ring levels are permitted to use certain instructions. In the case of I/O instructions, for example, the 386 let you execute them provided that the CPL indicated greater trust/privilege than the IOPL (I/O Privilege Level), not just when the CPL is for gawd mode. Finally, the reason why I bothered to look at your video after all this time was because I was interested whether it might mention what OSs (if any) might have bothered to use rings and the gate hardware that went with them. So far as I can tell, Intel threw in rings into the x86 family and Unisys threw in rings and domains into the M-Series 2200s, but so far as I can tell, no OSs really bothered to use these features, presumably because the OSs that already ran on them didn't historically use anything like them. Assuming that the hardware still works as described, I'd like to think that using gates to go between rings and using segments/banks to protect code is a much better way to implement an OS, but that's not going to happen so long as there's a sizeable existing code base that doesn't know what the are and/or how to deal with them.