THANK YOU! So many people in the Linux world have zero desire to help newbies.
Unused resources that are never used is wasted. OTOH, used resources that are used at idle are unavailable resources to heavy duty applications. Setting up virtual memory, storage optimization, process prioritization, and some other optimizations are important to serious system administrators for minimizing online response times and maximizing data processing throughput. Using 'git' for production control was the most useful bit of information provided here, but only for newbie to IT systems. This video is really for beginners and is a disservice to anyone planning on a corporate IT career.
I have to take a moment to thank you somewhere. I've been using various forms of your videos a lot over the last few years. I began switching over about 4 or 5 years ago, and now I don't really bother with windows for much of anything. I'm technically adept, but of course, the switch left me a bit in the "deep end" for the first few months. Your in depth educational videos have been the cornerstone of me wrapping my head around many of the more "difficult" concepts to grasp coming from the Windows world. It took me a moment to grasp the whole "everything is a file" concept fully, but man, that's a good one. Anyhoo, just wanted to say I genuinely appreciate the knowledge you share so freely.
I would love a series of videos like these. Tips for current Sys Admins that are still learning.
4:56 It would be easier just to say that inodes limit the maximum number of files you can create on the volume, regardless of the space they occupy. So if you run out of inodes, you cannot create any new files (or directories), you can only extend existing ones.
8:28 The point about using a different distro if you don't like the user interface - I would take this one step further and point out that for the most part you can install pretty much any desktop environment or window manager on any distribution. You don't have to even switch distros. Ubuntu is famous for it's unique spin on Gnome, but you can easily rip that out and replace it with anything you want. Or, you can install several desktop environments and switch between them as your mood dictates without any real issues.
2:27 Yes, it most certainly is true. Remember, userland apps like GNOME are not responsible for managing filesystem cache--that is done by the kernel. So any RAM the apps are using is actual regular application RAM, and if they are using a lot more than other comparable apps, then yes, that counts as “bloat”.
Point 1 applies only if you have high enough ram to begin with. You'd need a decently high amount of ram if your workflow involves sometimes using lightweight apps and occasionally running multiple heavy programs at the same time. No unused memory is really wasted. You're just being prepared for when you do need it
I’m just a dumb windows admin who dabbles with Linux in my home lab, but I cannot count how many awesome videos Jay has taught me something new. Thanks Jay.
I agree about not trying to remember commands you don't frequently use. As long as you can remember a search term or part of the actual command your trying to utilize then you can look it up online or in the man pages, etc.
Thanks so much for your Linux Instructional Videos: When I first jumped into Linux 15 years ago, as an alternative to Windows, I just wanted to be a user ... not a script writer, analyst, or administrator. I soon found out that to be a Linux User, is to wear all of those hats. The ability to self-educate was difficult for me as the availability of quality instructional material was difficult to find ... at least at first. I do have a friend who is an experienced Linux Administrator and that has helped over the years ... especially with the catastrophes that can happen. I am glad I found your channel ... it's been a good source of quality information. I still have a long journey ahead. Thanks once again.
Memory from the cache can be provided to any application which needs it. So basically we should have free memory more, instead of Cache memory as cache memory is not that important. If we have cache memory more, we can either reboot the system to increase the memory and eliminate it from cache, or we can use a command -> [echo 3 > proc/sys/vm/drop_caches] Correct me, if I'm wrong 👍🏻👍🏻
I think it's such an important point that even the most experienced people do not memorise everything, and thank you for saying it because I think it's often a scary thing for us newer and less experienced people often worry about. It's something I learnt with Photography that even the best photogs do not turn up take one shot and it's perfect. they take thousands of pictures to find their best shot to show the world. I've been watching lots of the "into the terminal" series form Red Hat recently and it's so great seeing one of their most experience people there even makes mistakes and forgets things. It's just down to what you use on a daily basis is different from the next person. I'd love to learn more about your career, how you transitioned and what you do now. I think it would also be really great to learn what you use for your note taking. Obsidian is such a widely discussed tool these days. I've taken a look at Logseq which looks really interesting but I cannot wrap my head around how to use it effectively and always find myself comparing it to Obsidian which I probably shouldn't. Do you host things like your notes or do you keep them local on your computer?
High CPU usage might not be an issue on a server, but if your desktop is idling at, say 80%, you don't really have much overhead for other applications
LVM is not a backup solution but many think so because it can include a “cloud” service. Data exists only where it located. In other words if the data in any one place, like an LVM cloud space there is no backup. Unless there a considered plan to make data replicated in more than one place it can be lost. Usually data should exist in three places, the original, a live backup, and an offline backup (one offsite and dead to changes, think of a place that is kept in a safety deposit box.
When it comes to using Linux commands, I think it’s worthwhile to try to remember the general syntax of commands you use frequently, but don’t worry about remembering all the options / flags / arguments/ etc. So long as you have the name of the command, most commands are a simple “command -h” or “command —help” away from getting a list of available options and ways to use it. Yes you can do “man command”, but manual pages are confusing and terrible! 😀 They’re either way to brief with no additional info or WAY too long and convoluted, so at least see if the command has a -h or —help flag first.
Yes, that's info that I can definitely use. Now I will use git and LVM in ways that I didn't realize. I see them all of the time and thought that only admins and devs needed them. I had forgotten about inodes because I haven't had problems with those for years. But it's a good idea to know how to fix the problem in case it ever comes about. I think that it happened to me a long time ago but I thought that the distribution was buggy. 😏
I use flash cards for Linux Commands & specialty terminology. I wanted to remember ... to memorize certain things because they were new to me when I first learned them, and I planned on using that info regularly. For me, repetition was the most effective memory tool for Linux.
I've been in Linux System Operations for about a dozen years but have been using Linux since 2.2. This is a well done list. I think the only thing I'd add to really introductory material like this is this: du and df. They might (probably will) report different usages. This can be frustrating when tracking down a "disk full" issue. This, really, is far more common than the exhausted inodes issue. If a file is deleted (but still actually open by a process), df will report that space as still used, while du will not. If this deleted file is very large, the difference could be huge. lsof (list open files) will help you track down the culprit in this case. Often this is caused by a log rotation that does not restart the application doing the logging.
@shawnlewis389