Is The Unix Philosophy Still Important?
Vložit
- čas přidán 7. 06. 2024
- Today's video topic is "The Unix Philosophy". I often get asked about my thoughts on The Unix Philosophy, or what I think about certain pieces of software that violate the philosophy. Well, I've some mixed feelings on this.
WANT TO SUPPORT THE CHANNEL?
💰 Patreon: / distrotube
💳 Paypal: czcams.com/users/redirect?even...
🛍️ Amazon: amzn.to/2RotFFi
👕 Teespring: teespring.com/stores/distrotube
DONATE CRYPTO:
💰 Bitcoin: 1Mp6ebz5bNcjNFW7XWHVht36SkiLoxPKoX
🐶 Dogecoin: D5fpRD1JRoBFPDXSBocRTp8W9uKzfwLFAu
📕 LBC: bMfA2c3zmcLxPCpyPcrykLvMhZ7A5mQuhJ
DT ON THE WEB:
🕸️ Website: distrotube.com/
📁 GitLab: gitlab.com/dwt1
🗨️ Mastodon: fosstodon.org/@distrotube
👫 Reddit: / distrotube
📽️ LBRY/Odysee: odysee.com/@DistroTube:2
FREE AND OPEN SOURCE SOFTWARE THAT I USE:
🌐 Brave Browser - brave.com/dis872
📽️ Open Broadcaster Software: obsproject.com/
🎬 Kdenlive: kdenlive.org
🎨 GIMP: www.gimp.org/
💻 VirtualBox: www.virtualbox.org/
🗒️ Doom Emacs: github.com/hlissner/doom-emacs
Your support is very much appreciated. Thanks, guys! - Věda a technologie
I always felt that the "UNIX philosophy" fits best on a lower level, especially individual programs at the command line. I don't think it applies quite as well to a GUI or GUI programs. The CLI features a ton of little, yet powerful programs, and they can be used and piped with each other... that, I feel, is the UNIX philosophy at its best.
GUIs can also be made like that but I don't know of such
@@spicynoodle7419 suckless as a whole is hyper for the unix philosophy like DWM or SURF or tabbed etc
Well you are right. Users should not expect a GUI program that can only do exactly one thing.
Yes, it was much more geared to the command line. Maybe in the more modern era it could be better applied to libraries where various libraries are called from a more complex gui program in a similar fashion to stringing together cli programs.
My thinking precisely.
coreutils are individual programs. They dont violate the Unix philosophy. They are each separate programs that do one thing and do it well. It’s the miscilanous bits and bobs. “Core. Utilitie(s)”. They arent one big monolithic thing. If you have a busybox based coreutils. That does violate the philosiphy. They are just packed in a single package becuase they are really common stuff. It’s like the stuff thats at the bottom of every old lady’s purse. (Nail clippers cuticle scissors. Coins of various sizes and shapes Kleenexes an eyeglasses repair kit. They are each individual items that are useful on their own
I think busybox follows the UNIX philosophy, it's a program consisting of many sub-programs. The philosophy doesn't imply they should be their own files.
I agree, this point was an obvious false equivalent
Yeah I dont know why DT mention this... He hasnt stopped thinking about what he says. I think half this video doesnt make sense in many ways. Just chattery
One of the worst violations of the UNIX philosophy in my opinion actually forms the _bedrock_ of modern GNU/Linux systems: GCC.
I recall hearing an anecdote that the FSF actually made the decision to make the divide between the backend IRs (GIMPLE &c, lower-level representations of computations that are language- and architecture-independent) and the frontends in a place where it was _almost impossible_ for anyone to replace the front or backend themselves, to prevent companies from exploiting the linkage exception in the LGPL to make proprietary compilers based on GCC.
While I understand the FSF's reasoning, this means GCC is _antimodular._ When you look at the unparalleled success of LLVM's approach in comparison on both performance and philosophical grounds (seriously, the difference between Clang single-threaded and GCC single-threaded on a recent HPC benchmark I ran was about the same as the overhead of running Clang OpenMP on a _single core_), it makes one wonder how much better free software could be if Stallman et. al. were just a touch closer to the BSD mentality.
Coreutils is the embodiment of Unix philosophy. You can't care if people violate it if you don't even know what it is.
Talking about a suite of "50 or 60 little programs" as a violation of the Unix philosophy totally lost me.
Yes, look at what the Web has become.
dont remind me😑
I don’t like the current web either, but technically aren’t web browsers just a platform like for example kernels and emacs are? But I’m not sure if being a platform can be considered as one thing 🤔
It's always strange to me when I see a video like this. The UNIX philosophy is about how you structure the programs, it's basically an issue of project management. The core idea is that it's better if you make your tools play nice with other tools so that you can combine said tools to make ever more complex and powerful tools.
If we look into the world of math, you take a handful of core ideas (axioms) and then use those to core concepts to prove that this or a relationship (Pythagorean Theorem) or even just confirm the status of a particular function or series (Does it converge? Is it differentiable?) . Typically a mathematician will not start from scratch when trying to prove something about a complicated type of problem, since we're usually a good ways past the usefulness of raw axiom these days, they start with things that we already know derived from those axioms. It's the same principle with software development, you don't need to reinvent the wheel, you can usually use existing libraries and even whole programs to do certain tasks for you: this is the premise of do one thing and do it well, that you make future problems easier to solve by making tools that can apply to as many situations as possible.
Well said! And having programs simple and focused and modular means that it's easier to pick it to use it for a situation, otherwise you might have extras that make it a hassle/incompatible/too slow.
I think it's a great philosophy. It's a timeless philosophy. It's a personally empowering philosophy. It embraces KISS. I think we need it more now than ever before.
No offense intended, but if the Unix philosophy is so timeless, why did Unix die and become extinct, the Kiss idea was from an era of innovation but with limitations, systems couldn't do what they can do now.
@@KingMasadaX It died because, before Linux, it priced itself out of its own market. It's an extremely easy question to answer.
Commercial UNIX licences were extremely expensive after it appeared in the early 1980's - shortly afterwards, Microsoft and IBM started putting out versions of consumer-grade OSes like DOS, OS/2 and then Windows and that is what the business and home user computing community went for.
In other words, the UNIX philosophy has nothing to do with the decline of commercial UNIX anyway. They are completely unrelated issues.
Because with the UNIX philosophy you can make software that is intransient, that is, one which happens to be useful after generations have changed and the current environment is completely different - as its independent components can be individually repurposed to fit into a new schema and still fulfill the concrete tasks they were intended to. The Linux kernel has already begun to lose favour in demanding fields and almost everywhere you look the replacement in preparation is a microkernel based on the microkernels that were created about the same time ago as Linux.
@@gimlam5909 "Because with the UNIX philosophy you can make software that is intransient, that is, one which happens to be useful after generations have changed and the current environment is completely different"
The CLI environment is not completely different - vim, sed, awk, ls, df, etc. etc. have not changed radically for decades.
"The Linux kernel has already begun to lose favour in demanding fields"
Where, precisely? Linux has already "won" in the server space.
"everywhere you look the replacement in preparation is a microkernel based on the microkernels"
I'm interested to know what field you work in because I've been working in Linux server administration and hardening for 20 years now and I see none of these "microkernels" of which you speak.
I've also used Linux at home since 1996, including making my own builds on several types of SBC boards - surely if micro-kernels were that prevalent, one of the first places they would appear would be on SBCs and embedded devices. But I see no evidence of them.
Besides which, the Linux kernel is scaleable anyway - just turn off what you don't want in the configuration. If the Linux kernel was that "big and bloated", how come it's already being used in so many embedded devices like car management systems, routers, etc. already?
@@KingMasadaX My guess about Unix going extinct is that it had more to do with ineffective corporate marketing than anything technical.
KISS is still a basic foundational approach to design and development in general.
I seem to remember back in the 80's and 90's there were quite a few magazine articles talking about the benefits of simplifying, not just hardware architecture like RISC but also
languages and methods all the while systems were capable of doing more and more.
Unix philosophy is about making software easy and desirable from developers’ perspective, not the user. It’s all about the modularity really, and how easy it is to develop, debug, and change.
The minimal vs maximal application thing is another story, which is up to user preference and optimization between tradeoffs.
Nonsense. As a child, the first thing you learn is how to use words to read books or write sentences. The UNIX terminal of "writing words" to do things is just a natural extension of that, hence why it's a popular interface that has survived long before UNIX appeared in 1982.
You are looking at this purely from a blinkered perspective. All of us "used words" long before we learnt to use mice to drive GUIs - lots of people seem to forget that they were able to read and write before they ever started using a mouse and a GUI, and there had to be some familiarisation of how to use a computer that way.
It always amuses me that people complain about the Linux command line but they forget that it is just about "familiarity" and that they had to go through a "familiarisation" process even to use Windows - whether they were taught Windows in school or in their place of work.
I can't repair my car so I give it to a specialist mechanic to repair - it's not the car's fault that I can't repair it myself.
@@terrydaktyllus1320 "Nonsense. As a child, the first thing you learn is how to use words to read books or write sentences."
Nonsense. Language is not the first thing you learn and when you do it is for speaking and listening, not for reading and writing, which come later.
"The UNIX terminal of "writing words" to do things is just a natural extension of that, hence why it's a popular interface that has survived long before UNIX appeared in 1982"
UNIX development began in 1969 and publication began in the 1970's, not 1982.
"You are looking at this purely from a blinkered perspective. All of us "used words" long before we learnt to use mice to drive GUIs"
You are looking at this from a blinkered perspective. While it's true that most people learned to read and write before they used computer mice (mouses?) and computer GUIs, it's also a fact that we learned to do things with objects, touch, movement etc and the concept of pointing at things, poking and prodding things etc (of which GUIs and a computer mouse are a natural extension of) before writing words and understanding computer logic and syntax.
"It always amuses me that people complain about the Linux command line but they forget that it is just about "familiarity" and that they had to go through a "familiarisation" process even to use Windows"
Correct, but it is easier for people to become familiar with GUIs than with the command line. That is even further shown by the rise of touchscreen interfaces in which even stupid people or people with dyslexia etc are able to intuitively use smartphones and tablets.
I'm not saying people can't learn to use the command line or that the command line isn't great, just addressing the fact that a GUI and mouse actually is more transferable and relatable to nature and intuitive use regardless of the fact that CLIs came first.
@@folksurvival I read the first paragraph and stopped reading. You wasted your time writing the rest of it.
You're still talking rubbish. Again, one of the first things you learn are words and how to put them together. That is fact and not up for debate.
Unless you accept that premise, there is no further discussion to be had, no matter how long the "missive" you respond with.
@@terrydaktyllus1320 "I read the first paragraph and stopped reading. You wasted your time writing the rest of it."
Ok, so you are admitting that you choose to be ignorant.
"You're still talking rubbish. Again, one of the first things you learn are words and how to put them together. That is fact and not up for debate."
You're now shifting to "one of" the first things and then generalizing language when your original comment was:
Quote:
"As a child, the first thing you learn is how to use words to read books or write sentences."
Which is *not* a fact.
@@folksurvival Yes, I am invoking my choice to ignore your comment which I believe will contain little intelligent content. You'll have to live with it, as will I.
The discussion is now closed, I am not getting into a "slanging match" with a stranger on the Internet.
Run along now.
The Unix philosiphy was what made gnu/linux possible. It allowed the replacing of components one by one so instead of working a whole OS they worked on one piece at a time.
And still keeps it going for the most part. At least the tiling WMs
I think the whole 1 tool for 1 action was really applied to OS level command line tools for the most part. As for SystemD I have a huge problem with the politics and how the main author sees the community and the OS. Also, remember that this thought pattern came for the OLD UNIX days when there really wasn't a GUI bolted on top. I think Linux as an OS has moved on from that in some ways, but when you start scripting that 1 tool/action mindset makes things a lot easier.
Also you shouldve pointed out why the unix philosophy is important in the first place, its why unix itself was born, its a keep it straightforward simple OS compared to the feature rich large codebase multics that never really worked
I think a very important part of Unix philosophy that wasn't mentioned in this video is to have a simple text output and where practical non interactive input.
I think lots of folks complaining about sustemd don't like the binary logs. I don't particularly care about the init system, because I never had to interact with it much, but I do like having a simple text output in programs: it makes scripting things so much easier.
your spelling of systemd is sus
Very thoughtful video today DT. Good to think about. I agree with Jeffrey Bryant that the unix philosophy applies very well to the CLI. The rules have changed for a GUI. Change is good, especially when you know the history.
I think its a really useful concept to keep in mind when programming - it makes debugging a lot easier, imo makes code a lot more readable. obviously you cant apply this to everything, but using it where appropriate will save time
Wise words 👏👏👏 Thanks for this DT ❤️
It's always a pleasure to hear your points and discussions! And, as so many times before, I gotta agree with you.
UNIX 'philosophy' is powerful (as well as having a standard like POSIX is) but the heart (aka needs and use cases) wants what the heart wants.
hello DT :) You should start a podcast. You are good freestyle and also informative along with sharing your opinions.
dunno. a lot of highly featured programs i would consider great and are basically indispensable for a lot of people. for example blender or krita. i would say practicality > philosophy when applicable (basically, the arch philosophy)
Those are profesional suites, not really regular applications. They still meet the Unix philosophy.
There is definitely a place for complex software like Blender that does a lot of things in the same space, but sometimes all you want is one little piece of it, and having to navigate that complex system to get the one thing out of it you need can be a burden. For example, KDE has a screenshot app called Spectacle. It's a moderately simple application, but it does have some extra features like cropping, annotations, and basic editing. Which is nice in some cases, but guess what, I don't want to stop what I'm doing every time I hit print screen to deal with that dialog, where I have to do about 6 to 8 clicks to actually save it. So I wrote 200 lines of C code to grab that key and the root window from the X server, and call libpng to save it to /tmp. Then I deal with them in bulk later. I think it's great that Spectacle exists, and I don't judge anyone for using it, but it's... more than I need, or want. It has the capability to perform the task I need, but no "quick" way of accessing that one small part.
I probably echo what others have said, but I feel the Unix Philosophy is more of guidelines to follow and that "free as in freedom" philosophy is more the most important thing to follow.
GNOME perfectly adheres to the UNIX philosophy, it accommodates one workflow, and it does that perfectly, hence people complaining about how non customizable it is. Just because a program takes up a lot of RAM does not disqualify it from fitting the UNIX philosophy.
Aside from the long list of dependencies, if you install gnome yourself manually and not just install the usual gnome group install, I agree I think it does a pretty good job of following it
@@andremaldonado7410 long list of dependency is not against the Unix philosophy. In fact dependency hell is the direct result for end user software using Unix programs/libraries/API, as instead of using one multi functional program in the back end, they are using many small reusable programs that do one thing and one thing only.
GNOME is easily the most bloated UI out there. And yet it is the least flexible. They keep chopping and changing things around between versions, to the great annoyance of many users.
As far as GUI apps are concerned, I think the Unix philosophy stops at the display server. Because that’s as far as you can go with “mechanism, not policy”. Everything above that is specific to some particular policy, it isn’t just mechanism any more.
I agree, Mate is far better than Gnome 3.
@@lawrencedoliveiro9104 yeah that's kinda what I was getting at with the whole long list of dependencies thing, it's definitely bloated, regardless of whether or not you only install exactly what you need in the desktop environment rather than the meta group
One of your best vids yet, user choice is important. Change is good, and if so called change is bad for you then dont change which on Linux you have the freedom to do.
Can you do a review on Gnu guix(ie. Nonguix installer from system crafters channel) because it usable as a daily operating system.
Does this mean that you will be making an Emacs based Distro? With BSPWM as the window manager?
all i got out of it is that it's so long ago that i use a DM that I can not remember how they work? emacs too?
Great video thank u.
I used Unix SRV5 many years ago, did the hardware administration, and wrote service manuals on that system. It was a publishing system, hooked to a photo-typesetter, and my first introduction to a multi-user, multi-tasking system. Could that be why I am so bloody happy with my Linux daily driver these days? We are the sum of our experiences after all.
Back in the day, 'do one thing and do it well' was very, very important. Computers just didn't have the oomph. Try paging a PDP11 which had 64KB of live memory. Now you get a million times as much for ten bucks.
Now, with shedloads of memory you can do it - and perhaps safer with more automated testing.
Except - hang on to one. Be able to pipe data from one to another (and tee it if needed). That's so powerful.
As for emacs, it's a great OS, just lacks a kernel. And a decent editor.
HAHAHAHA.
Who says you have "shedloads of memory"? What about embedded systems like those used in car management or routers? I'd actually argue that one of Linux's core strengths is its scalability as a result of "keep it simple" which means you can scale it to run on anything.
So many people have fallen into the same trap as you have - in as much as you've lost perspective on the fact that just because you have an incredibly powerful computing device at your own fingertips that you can just upgrade as you need to, that that is the same the world over.
As I have said a couple of times here already, back in the mid-90's, I was using a Commodore Amiga A1200 running at 14MHz with about 8MB RAM to connect to the Internet via dial-up modem and viewing web pages in the "iBrowse" browser - most TCP/IP services like HTTP were developed in times when we had much less computing power at our fingertips and therefore started out being "light by design".
If you play modern games or do a lot of video editing then, yes, you probably need as much CPU power and RAM as you can get. Plus the modern web is completely bloated and crap anyway, which means so much of that web processing is done on the client side anyway - it's additions like Javascript that mean you have to have a better CPU and more RAM to do the processing that the web server hands off to you.
By the same token, if you don't need to do those things above on a computer, then you can work with much lower specifications.
@@terrydaktyllus1320 I do in fact build stuff for Linux (the kernel) and some GNU utilities on Raspberries. The small ones. For that, cross compile (or wait a long long time).
And I also do compile on the small ones - W zero ARM6 - just to show the code is OK. And it is; GNU/Linux is most impressive.
But I won't run neovim with the full monty on a W zero; it is just too slow. No problem; I strip its init down so's I can edit happily.
I'm pretty old. I used a PDP-11, really, in anger (for particle physics, at CERN) and the very small lightweight stuff was vital. (RSX-11M, Unix was then just a-building).
And javascript can go suck. I'm getting to Rust now. But the pipe and tee is still a powerful idea.
@@chrissaltmarsh6777 I also worked on PDP-11s also. Back in the late 1980's we were using them in the first call centres here in the UK to do call reporting and screen popping - they were running RSX-11 which was an "eclectic" OS, to say the least!
I'm a fan of Gemini as a "back to the roots" replacement for the modern web, which has been ruined by evil corporations. Yes, Javascript sucks but I also find Rust an annoyance.
I repair, rebuild and collect old IBM Thinkpads, my Linux of choice is Gentoo and has been since 2003 - I build it on everything, including Raspberry Pi's and some more ecletic SBCs like Orange Pi and even a couple of Olimex Olinuxino boards.
Where I don't like Rust is it's dependency on the SSE2 CPU instruction set which Pentium III CPUs don't have. I still have a few old Pentium III laptops, they run Gentoo very well but it's a pain in the backside trying to avoid Rust dependencies on those machines.
But it makes new generations less skilled & even more lazy (my biased opinion on own example) Lazy in that bad sense, not the good one of avoiding complexity for sake of a better solution. Everything can be solved by more primitive less effective solution and unlimited resources fueling it. It's like feudal way of doing things ;-)
Does it seem as technological bottlenecks can also play a role at improving things?
I think Gordian Knot (windows, a decade back or more, may still be around) is an example of do one thing and do it well. Gordian Knot was, most simply, a graphical frontend to a number of smaller, faster, highly tuned tools. It shipped with the tools it needed in the same installer. I'm OK with that. There was the frame server that split out the source into frames for processing, the video encoder(s), the audio encoder(s), the muxer (to put the video and audio together into one file), maybe some other elements I'm forgetting. The purpose, which the Gordian Knot frontend accomplished in spades was to sus out what the user wanted done to the video, audio, and subtitles (that's the part I forgot earlier) and then to execute the not-quite-a-script to get the subordinate tools to accomplish that task, remembering to summon the muxer to merge the final result.
Several CD/DVD burning programs were also similar, knowing that it was useless to reinvent the wheel and summon the mature and fast tools to do the heavy lifting while predominantly providing the user a convenient and friendly user interface. I think k3b was one of these, but it's been years since I burned any optical media, so I'm not certain.
At times, I use lynx, but for anything graphical it is inappropriate. Though if it had the ability to spawn an interactive window in the user's display for the user to interact with, graphics, links, etc. I think that would not be a bad thing. It would still be doing its one thing as a web browser, and doing it well. The graphical display and interaction element might be a modular component that the user could sub out if they don't like the one that lynx prefers.
Big web browsers could be split out into little, well tuned, modular sub-components. wget, curl, or something else could be the network heavy lifting. Different types of parsers could handle decoding of the multiple filetypes a browser is expected to handle, possibly with media players summoned to handle in-page playback elements. I could keep going, but I think the point has been made. These things could be "atomized" for lack of a better word. But few are interested in those steps.
Yes, there's no questioning it. It's like asking "Is the wheel still important?" Much like the wheel the UNIX philosophy should be improved upon not thrown out and reinvented.
Actually emacs does only one thing and does it perfectly, interprets elisp ÷)
Core Utils is a collection of small utilities that in most cases DO adhere to the Unix philosophy of small components that do single tasks. We bundle them together to simplify, but they are still separate (mostly) independent programs. The idea that more things should be done that way is something I support. DE's used to be extremely messy, some still are. But that was the result of a leadership problem IMO. The solution seems to currently be "build it all here" which leads to big, un-auditable, difficult to debug, code. It's a bad path, but the one we seem to be on. Coding this way truly is easier than doing the hard work of providing real leadership and direction to a VERY diverse group of people with sometimes little interest in listening to ideas that aren't theirs. That doesn't mean it's not the right path, just that it's difficult.
It depends on how you define the “one thing.” If you approach it from a workflow or deliverable perspective, “one thing” could mean “edit this video.” That might include multiple sub-tasks, but most people don’t want to jump between a bunch of programs where each is focused on only one sub-task. Also, while you might think it’s better for developers to focus their app on one thing, that means they are “beholden” to other apps. For example, if you could not edit audio in a video editor, the video editor becomes impacted by the state of audio editors because editing audio is a key part of the video editing process.
Furthermore, GUI apps don’t have a universal or standard way of inputting and outputting data between apps in the way CLI apps do via pipe.
Like you mentioned with Emacs, IDEs and Advanced Text Editors like Jetbrains, Eclipse, VS Code, Emacs, Vim, etc don't "do one thing," but they're not necessarily worse off for it.
It's possible to go too far with features, for sure, and arguably, some of the ones I just listed can go too far, but to go too far the other way is also wrong.
The Unix philosophy mainly fits utilities and dedicated kinds of work, rather than all software.
It is useful for preventing scope tho, so I think you could revise the philosophy to be a little more general like instead of simply do one thing, maybe "fit one workflow." Yes, only put in what's necessary but recognize that it might be more than just ONE thing. Like some DEs for instance
I always thought of it as keeping development time short and programs small in order to more easily manage code (because it's divided and modular).
i think the unix philosophy is very important for getting a well optimized system in a community driven work force, so say for example if someone figured out a way to add a huge performance boost to tabs in browsers, it would likely end up in that one sole browser but if it went into something like suckless' tabbed it would make the work more important
Why use a video editor when there's ffmpeg?
Even if your web browser only renders HTTP and HTTPS sites - it's still beyond doing one thing and doing one thing well.
It has to deal with at least three different languages (HTML, CSS, JavaScript), each one of them packed to the brim with features, it has to store a complex structure known as the DOM to enable all of the languages to work with the page, it has to manage all of the files needed to render the page (images, source code, videos, etc), it has ways to interact with both OS features (such as notifications) and hardware features (such as battery level). It also has to render everything, which these days has to be done using hardware accelerated graphics.
It also has the capability to adjust the page (if designed right) to any form factor imaginable, from a cell phone to a PC to a kiosk to a TV.
With the big push to make web pages become apps in and of themselves, the browser has essentially become an operating system of sorts. Even if all you do is look at web pages, it's a complex beast under the hood.
It would be interesting if someone made a project where they took all the components of a browser and made them separate modules. Markup parser, layout engine, style applicator, script interpreter (that's a whole beast by itself)... though I think performance is the main reason these things are all packaged together, it could theoretically be split across a well defined interface and made into linkable .so or .dll objects that could be swapped out. Imagine if you had as many ways to put together a browser suite as you did to customize a graphical desktop.
I wish emacs was multi-threaded
1:10 The problem with “do one thing and do it well” is that such simple examples inevitably have to build on much larger and more complex underlying layers. For example, does any command-line shell “do one thing and do it well”? Does X11 “do one thing and do it well”? Does the Linux kernel “do one thing and do it well”? What about glibc, the good old C runtime library, that just about every userland program depends on?
I would say that none of these things fits that paradigm. But they all enable the creation of pieces on top of them that do.
This applies to systemd as well. Writing a systemd service file is typically so much simpler than all the boilerplate you need to include in an old-style sysvinit script. That’s why it’s worth using.
A simple comparison, I like to use the knife to cut things, but sometimes the Swiss Army knife is more useful.
But I will not haul swiss army knife with me. All its features are useless unless you are willing to deal with always carrying it with you. Swiss army knife is only useful if you do not know what you will be doing and it is never best tool for the job
@@oalfodr I think you misunderstood the logic, so I'll simplify it even further.
Imagine that you are Batman and you load what you need in your utility Batbelt.
Nothing is useless, it's smarter than just carrying batarangs, which do the job, but having options is always better.
@@guilherme5094 Maybe I misunderstood. My point was that I am always ok not being able to do unplanned tasks in favor of tools giving me the slightest advantage in my regular tasks. Also my point was that having these options is a good thing only in rare case you need them and in all other regular cases it might be a inconvenience
My recollection as an ex Digital engineer with Ultrix is it was an alternative development environment for the science and education segments - just another commercial product we offered.
But coreutils are small, effective and portable UNIX programs, by your logic AT&T UNIX contradicts itself because it has a lot of programs. If you want a kernel that is UNIX in your definition, look into the HURD.
Well said!
I can remember when folks got "up in arms" about multi-tasking doling more than one thing on a computer when it was introduced, the sentiment being, "I have one processor, how can it get it to do all this and still do it fast". But you generally don't want to write to a program that addresses solving one problem. Watched further and agree on your examples, I think that video, audio 3D animations, etc are so inter-connected now (as an industry) that we will see more crossover like DaVinci Resolve Fusion and Blender doing video editing, so on. The webbrowser is by far the best example you gave, although there are older protocols for early Internet (one can always Gopher it). But technically, browsers violate the UNIX philosophy for sure 🙂
Been using Fedora for 2 months now. Wayland seems to be more stable for me despite me using my desktop for a lot of games. Only experienced a few hiccups so far but most are minor.
Hey DT have you played Minecraft and the hypixel server? ( I know that your not much of a gamer but I’m just curious ) and I’m glad that your one of the best Linux desktop to be specific youtubers ever in my opinion :)
How many of those lines are drivers.
I like this approach, I never thought of it that way.
I try not to use Vim's means of choosing files, so that I have one file picker that I learn well and use it globally. I'm questioning this decision.
Neovim is easily counter Unix. Because to me, violating the Unix philosophy is setting things, so you end up turning a program into an operating system. Using Emacs only for org mode should give you the benefits of the Unix philosophy, at least the ones I care about. You'd learn one thing and learn it well.
Neovim is just vim with a LuaJIT compiler. The rest is little programs that do one thing, like a file tree, a terminal emulator, etc. everything is an atomic plugin. Contrast that to JetBrains or Visual Studio who actually violate the UNIX philosophy and it’s night and day
Some quick thoughts:
- I think the Unix philosophy should be be defaulted to and only be neglegted purposely after thinking about well.
It is not a strict rule but one should probably strive for it (in my opinion).
Sometimes it's not practical but hopefully we can keep it up most of the time!
- I think software suites such as GNU are following the unix ph., as it's a bunch of small programs that mostly do one thing and one thing right. Isn't the whole idea that you can than combine them with pipes?
In cases like that you might say some separate programs within it don't follow the unix ph. and some others do but I don't see how a set of software isn't following the unix ph. because it's big all combined.
A software suite with 10 big programs might not follow the unix ph. but a suit with a million small ones might even though the whole thing is much bigger than the former.
- DE's are also a bunch of smaller programs that are packaged as one 'product' so I wouldn't judge them to quickly as to not following the unix ph. (you would really have to look how it's structured).
- Just because one uses software that does not follow the unix ph. doesn't mean that it's good and you are happy with it. For example, yes browsers are massive monsters, I use them too, it's not the end of the world, but I do find it regrettable.
- About the claim that nobody complains about browsers and DE's not following the unix ph.: Many people call them 'bloated' and I think in many cases something being bloated and something not following the unix ph. go hand in hand and people mean very similar things with either expression.
Basically it has some many features, it does too much.
- When is something 'small'? That's of course down to taste. If you find something too big, it's would be nice to clarify what you think is 'too much' and what parts you would separate out into it's own programs.
The reason why browsers are bloated is because as the human race we've let a few big corporations turn the web into complete sh*t.
I keep going back to this point but when I started connecting to the Internet over dial-up modem in the mid-90's, I could use a Commodore Amiga A1200 running at 14MHz with 8MB RAM to download web pages with the iBrowse web browser.
Unfortunately, since the commercialisation of the web, we've let evil corporations run rife with dynamic web pages and Javascript such that now web rendering is most client side - which means you and I need ever more powerful CPUs and more RAM to deal with it. Not to mention the power consumption across the world as we all have to buy more and more powerful computers.
I think one thing that changed since the UNIX days is that the size of a maintainable project has grown quite substantially, which delegates modular software to huge applications where resilience and scalability is important.
I think what we have here is the problem of definition what does the term "one thing" mean. For example, for cat utility this is the reading content from the file, but for web browser surfing the Internet is one thing that it doing well, encapsulating stuff with encoding/decoding video, HTTP, different TCP/IP protocols, etc. I suppose good example of software that violating principle of "do one thing and do it well" would be IDE, cause it stands for INTEGRATED development environment, gathering together stuff like debugger, docker, test runner, shells, etc.
the unix philosophy is about software architecture and managebility. smaller and targeted programs are more modular by design from consumption pov and give users flexibility so for example if you have issues with gdb debugging tool you can switch it with lldb.
it also lead to more concise targets to reach in project planning and as you don't have too many inter-dependencies you also have easier time to optimize and manage their complexity. these in turn also escapes users from single point of failure in their dependency chain.
It also not limited to cli apis, gui apps including what you mentioned(blender, good desktop environment and such) adhere to it,it is expected of a 3d rendering tool in the industry to handle compositing, video/scene editing and animation and it is invoked in manner that user can switch between if they need more specialized tool.
desktop env is not really one application but a modular application suite that if designed well each part can be user replaceable.
systemd dependencies as far as I understand are not really modular as they depend upon each other in subtle ways and dependencies upon them force the consumer of the app to include them and once it used it take over the system and can only be manged through systemd designated api tools.
Today in the enterprise sector things shifted toward this modularity with interchangable utilities that do a single functionality due to the reasons above.
The Unix phillosophy is the equivalent of an engineer designing a single part for an engine and calling it a complete product. They are technically correct but you still don't have a working engine untill you get the rest of the parts and put them together. This is a main reason people are turned away from linux or turn to Ubuntu. Fault Apple all you want but at least Steve had the foresight to create a ecosystem not just a platform.
Linux Mint, PopOS, and Fedora are great starts but I think KDE is the best example (I know it ain't a distro...). While it can be a bit buggy and not all of their programs are the best at least KDE offers an entire suite of software. However due to it being a volunteer based development backed by donations rather than a profitable company it has taken years and years to get it optimized and super smooth. If System76 or Pine can emulate KDE and Apple I think Linux will succeed far better. You can keep the software FOSS and make money on the hardware, it's perfect.
Instead of the Unix phillosophy I propose the interchangable manufacturing phillosophy: all the parts are the same and so they can be swapped out. Think of a Honda Civic sure you can put in a corvwtte engine and truck tires but it makes more sense to use parts meant for a Civic or at least a sedan. Unix likes to act as if there is no need for specialization, everything is modular! Well then you have nothing optimized to work coherently together.
The Unix philosophy isn't "call a part of an engine a complete product", but rather "make the engine out of many small parts, so if something breaks you only need to fix the part that broke, and you put it back in"
@@tamoozbr designing an engine where every part is designed separately leads to an unoptimized incoherent product. Part interchangablity is where all the parts are designed together and made to be modular, therefore allowing 3rd parties to develop after market parts or for you to use stock parts for repair. I think Suckless software is probably the best example interms of design but it comes "unassembled" and so is more equivalent to a parts kit than a finiahed product. Still Suckless is coherent in it's design and goal with a unified team of developers working together to follow those strict goals.
Nope, you don't get it.
@@user-he4ef9br7z I do get it, you just don't understand engineering a coherent product suitable for mass adoption.
@@Bagginsess I do understand engineering a product for mass consumption. Windows and Mac do a good job doing that. Linux is a specialist's operating system. Linux distros aren't products, you can't modify and redistribute products. The whole point of FOSS is that the end result is not a product, but something people can shape and tailor according to their own needs.
Unix philosophy is not about calling a part a product. It's got nothing to do with products, it's to do with systems.
Good video.
“Do one thing,” “keep it simple,” and “be modular” doesn’t quite capture it. Something you mentioned toward the end should be given more emphasis: composability. The developers of Unix preferred to write programs that accepted input from other programs, and produced output that could be consumed by other programs. The format of the input and output was most commonly text. User interaction and side effects were eschewed.
I wanted to say the same thing! With composability, you can have a program do something, and if it does it well, and it's simple, configurable, modular, it can be used for all future projects directly, with no need to code that thing again.
Make a video about best window managers.
I think that what makes GNU/Linux so great is that it's in nearly every form for any skill level and software philosophy: If you're cool with proprietary software and drivers, there's Ubuntu, Linux Mint, and a whole mess of distros like it, whereas if you want something totally open-source, you can learn how to use something more complicated like Arch or Debian. At the end of the day, what matters is getting people off of Windows and OS X, and the rabbit hole just keeps going from there.
I've enjoyed using my computer a whole lot more ever since I finally switched to Manjaro KDE, and I've been running some pet project VMs running ArcoLinux and Debian, so I can learn, configure, and break things as I please. It's a whole lot of fun.
I don't use Ubuntu (I use Gentoo) but where are the "proprietary software and drivers" in it? I am not aware of any so I think you're mistaken on that point.
There ARE binary firmware blobs and some proprietary drivers (e.g. NVIDIA cards) that sit in the KERNEL, but (with the exception of a few patches here and there) the same kernel sources are ultimately used across all distros - so it's not specifically a Ubuntu thing.
GNU Emacs may not be a tiny program that you mostly use to compose pipelines with other such programs, but it absolutely nails the whole ‘everything is just text’ concept that is so central to the Unix philosophy.
Hey DT!
In my opinion, as a programmer, one word can summarize the UNIX philosophy: API (Application Programming Interface)
Systemd is a good opposite example. The point is that it's PURPOSE is against community-driven development. It is more like a proprietary software where only the creator knows how it should work, and how to use it properly. I mean systemd consists of several subsystems itself, with their own purpose. Fine, modular. But they just DO something without any stable API. An init/service layer is so important, it indeed should be an API instead of an ad-hoc instant implementation of billion something, then with the power of majority (which is also inhomogenous, and generally convenience-oriented) force to everybody. Typically big tech complanies do this, seemingly helping open source. But not really. They build their own proprietary empire. Look at Fedora these days. It is a very USABLE/ATTRACTIVE system, but it is practically the beta version of RHEL. The purpose is to build an enterprise system with proprietary, non-standard solutions. It's fine, the are a corporation. But we, the community should see clearly, Fedora is getting to be a Windows-like OS. Just think about forced reboot on updates: The user CAN NOT decide if she shuts down the system. It will force rebooting and finish the installation. Like Windows. Systemd, too. You can not easily change from systemd to another service management layer, because it has practically no API on both kernel space and user space. In result, both kernel and user space developers SHOULD follow the big tech's idea. And, there it is, you are tied to it. Is that freedom?
You mentioned linux kernel as example of a complex system. It is. But, it is modular, and it has an API towards user space. It has a stable system call layer. This makes it possible for other UNIX users to run linux binaries on BSD easily for example.
API is the communication layer for the outside world. This is the missing part of systemd. Or more generally a service manager layer in linux.
Cheers, and thank you for your cool videos!
Bonus: Which is the only Desktop Environment strictly tied to systemd? Bingo: GNOME.
IBM -> RHEL -> CentOS Stream -> Fedora -> kernel -> systemd -> GNOME. You are in the walled garden.
The same principles as the best practices for new programmers in how to write functions section. The other was to make code self-commenting & self-explanatory.
Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no."
I think more people need to get a sense for what the unix philosophy is for and where and when it applies. I've seen a guy argue that GIMP is following the unix philosophy by refusing to implement svg tools and that if you wanted a way to edit an svg in GIMP it should be a button that opens inkscape and then returns the shape you made. Which hopefully I don't need to explain why that is stupid. My understanding of the unix philosophy is about preventing every command from becoming another image magik or ffmpeg, making cli commands easier to remember and scripts easier to read, which should provide the user with the most optimal amount of flexibility to time spent reading documentation. So in what world does making gui tools more convoluted, harder to use and waste more time follow the unix philosophy? The only question I need to ask to determine whether a program should follow the unix philosophy is "will users want to use scripts to automate this process?". Blender handles this well actually, the only editing operations that are exposed from the cli if you run it without a gui are rendering and running internal scripts. I'd argue that in that sense it does follow the unix philosophy.
While I love and agree with the Unix philosophy, I think it’s pretty common that people fail to make their one thing actually work well.
Ultimately, I think the best compromise is making it easy to quickly and consistently utilize other software when needed. In a video editor, make it easy to be able open and edit what you need in your preferred audio editor then seamless take the finished audio back into the video.
Rigid philosophies and standards also have value because of all the fun discussions they inspire. I was working in a data center systems team in 2003 when IBM succeeded in certifying its flagship mainframe operating system, OS/390, as POSIX (TM, IEEE) compliant. It was sort of a "Take THAT!" moment. Not much practical value, but IBM could claim its mainframe could (should) run UNIX (TM, The Open Group; earlier AT&T) applications. :))
There is an Emacs Lisp init system ;)
So when we say programs are these only things the user interacts with? What about APIs? Should those be there to, I always felt this argument has more nuances than anyone ever talks about
There is a lot about the Unix philosophy that resonate with me, as taken from here (en.wikipedia.org/wiki/Unix_philosophy): small programs that do one thing well. seek simplicity, using flat text files for data and config, use of scripts to automate things, filtering and piping of input/output between programs, succeed quietly but fail loudly, using open and extensible protocols. These are all things that make Unix and Unix-like operating systems desirable over others for me.
First. And to answer your question, I'd say yes; Linux is a unix clone so...
Confirmed as first. And confirmed that Linux is a Unix clone.
@@DistroTube your video prompted a response on another channel:
czcams.com/video/Q0vMon0sN3U/video.html
Something you failed to mention about Blender. Every tool that is provided in the environment is something that as a 3D modelor you would find use for. In fact I can remember back to Lightwave 3D on the Amiga and how it incorporated many of the same tools.
So is Blender "simple"? Maybe not for me or you, but what does someone who uses modelling tools all the time think?
They could break the tools up into individual applications that work together. I think that would be a little pointless though for this case. Although I love the little video editor and wouldn't mind having it as a single application :)
three main points:
- Write programe that do one thign and do it well
- write programs to work together.
- write programs to handle text stream, cuz a universal interface.
dunno how I feel about the third one.
What looks like a monolith from the outside can be unix-philosophy compliant under-the-hood. Piping data-structures through cli programs would require them to be repeatedly parsed. But you can avoid that by composing small programs under a "monolith" umbrella that a user arranges like piping, sometimes building the pipeline interactively as they go. That's kind of how your emacs plugins work: they're independent small programs that operate on buffers under the monolith.
That's a good point. The unix philosophy tends to be applied within software projects, where you have modules that do one thing well, but are then combined into a larger program and presented as a package. Heck, look at C++20's ranges with the pipe operator. It's just like piping shell commands, but it all happens in the same process, in binary, with no OS-level file handles or streaming between processes to slow things down. I think the philosophy is more important in how you develop the tools. When it actually comes to using them, the UX and overall workflow is more important.
great take
Is "GNU utils" argument valid?
Every program does it's thing. One package does not have to do one thing, but it's programs do
Life as a whole has never stayed simple. In the 80s you had 4 channels on a TV, a 386 computer that ran some applications. Internet was intranet where it was exclusive to those companies. I think it's a philosophy that people "try" to stick by to keep the focus. Even in the BSD world things have been added to their versions of kernels thru the years. All of it. All the software that has been around for many moons. There's a problem that needs fixed and then more problems arise. The same with laws the same with everything. The point is your right. Init system doesn't always matter. It's nice to keep things simple but you could do it with systemD if you wanted. Instead of gvfs fuse you could just use systemD exclusively to mount all your drives. What I do like about a simple init system and having exclusive components for different functions is having more control over those that take place. It is what it is and software is going to continue to expand it'll be cool to continue to see
Systemd is not a single program that does various things, it is a collection of programs and each program in that collection does a specific thing. So I am not sure why people say that it doesn't follow Unix philosophy.
And then we have people saying things like "speed doesn't matter anymore" and "just use Python because compooter fast"
I think it's a good philosophy, but not for everyone. I can well remember myself few years back being practically unable to compile any piece of software, yet I still wanted to use Linux. Now, I prefer when I can compile whatever program from source, because I've learnt quite a lot in between. And yes, the modular and granular approach would be nice to have, especially with compositors. Also coreutils are individual programs, just bundled together.
One thing I did not agree with you as a content creator is the video editing programs. As they say, an audio is a half of the video. Being able to mix and master your audio directly in your multimedia workbench (should be called like that) is much better, not only because when you do any minor adjustments to the video, you don't have to re-export, import, find, change, export, import, but just change, but also it provides a sort of better visualization of what's happening. I'm talking specifically about Davinci Resolve.
The problem with the UNIX philosophy is the question - "what is ONE thing?" Your examples are good. That philosophy started in the days where the shell was the *only* thing and pipelines between text processing utilities was about as sophisticated as it got.
Re: systemd, it's more like a project that is an umbrella for multiple programs. It's more akin to GNU userspace, since it's not a single binary. The main difference is that the components inter-communicate over DBus rather than more traditional mechanisms. And I think what gets a lot of people salty is that they create competing, alternative implementations to things that they deem to be "solved." Like resolved, homed, networkd, etc. But like the others these are standalone binaries, optional parts of systemd, and you could write competing daemons or clients for them as long as you can talk the requisite DBus interface.
To me the UNIX philosophy, in modern times, is like the programming ethos of "prefer composition to inheritance." I.e. try to make things inter-communicate vs. making monolithic projects. It's my reason for preferring vim/nvim over emacs. The former community *tends to* (there are always exceptions) integrate existing things in with scripting, emacs community *tends to* prefer complete reimplementations that run inside emacs. Oh well. As they say, emacs would be a better OS if it had a halfway decent text editor.
I agree with most of this DT and I think pragmatism is important. As a developer, I will continue to write small pieces of code and modular APIs that have a clearly defined goal if nothing else to avoid headaches in the future. If you are a young developer and you think this is stupid, wait until you have to debug some massive spaghettified code someone else wrote and then maybe you'll appreciate it. 🙂
I'm one of the many here who'd say that "free as in freedom" is more important than "do one thing, and do it well". I mean, would you *really* prefer to have one application for cutting videos and another for rendering them?
Modular programming is key here: to avoid one module interfering with others, to always make it easy to see which module has which problem, to be able to fix very specific issues relatively easily. Only FOSS can do that, and only while it keeps the UNIX philosophy at heart but understands suites such as, say, KDEnlive as modular entities.
"Do one thing, and do it well" is more relevant than ever, but in a somewhat different way: modern applications are, in fact, collections of smaller ones. The maxim must now refer to those smaller ones.
"I'm one of the many here who'd say that "free as in freedom" is more important than "do one thing, and do it well"."
And now you're going to explain why you can't have both simultaneously?
DT good point on Linux kernel being bloated. I never see things like init system and kernel as bloated since most of the kernel components will not work without other components. If you take out a feature from system d the entire init falls apart. What we Unix philosophers call bloat is things like Emacs, Firefox since you can take out features that are not nessasary and yes GNU core utils is bloated comparing to bsd counterparts
You should watch the tragedy of systemd by benno rice, i think alot of people misunderstand what systemd is tbh, but i think that if linux is ever to have a mainstream pick your desktop kind of deal i think a "system layer" like systemd is important to growing the adoptability and customizability, along with usablity for mainstream distros. foss is cool, but i think the unix philosphy is good for lowerlevel things, not so much for certain things
Wait, Desktop Environments are not modular? Does the availability of a metapackage (which is just an empty package with claims to depend on a bunch of other packages to get the dependency system to install them all in a batch) means you cannot install these packages individually? Can one get gedit without installing Nautilus and the rest of the Gnome ecosystem?
As for systemd, do you _really_ need a caching dns resolver bundled in with my init system? If you do need one, why not install unbound or bind9 separately? Do one thing, and do it well. If it's a complex task, like with The Gimp, the program should be comparatively more complex than an init system, but it still shouldn't come with an implementation of minesweeper on its plugin system. Just because it can be done, it doesn't mean it's a good idea.
Finally, the Linux kernel; there is worry currently that with the ballooning of the kernel source code, sometime soon the effort required to keep already implemented systems compatible with each other and free of exploits may end up taking so much effort that it will be functionally impossible to add new ones.
The concept of the Linux philosophy is a really good ideal. Now I will say that software design has cycles, and that philosophy does come back in various forms. I can say that there is a limit to how simple something can be and still be useful. The problem is that complexity is always there. It's a question on where you feel that complexity. Whether it's in the single software package, or in how you deploy software and have it work together--it's the same amount of complexity. So the trade-offs are always there, and it's all in that balance with maintainability, stability, and flexibility.
To be fair the GNU Core Utilities is a large collection, yes, but it's a large collection of a lot of simpe very much Unix philosophy programs. I assume there's some monster apps there too, but most of them are just GNU implementations of the original Unix utils. But I agree that large size is not a problem in itself. The main point for me (and I think the original intent too) is that you make software that does one thing well and is easy to interface with other independent software. In the original Unix world that meant small apps and it meant mostly text based input output; but if a problem is large or performance means it's better to couple several utilities tightly together and use binary input/output thats also fine. As long as you make the non-text based protocols open and easy to use and don't make it needlessly hard to swap out a function provided by a tightly coupled module with another independent application; I think it's completely fine. Forcing everything to be converted into text and back using base64 et al. just to make it "technically text based" is just wasteful and doesn't make it any more interoperable than an open and well defined binary protocol.
Some software that that I would definitly say break the Unix philosophy (not that they are even remotely trying, being priprietary too) that I'm forced to use because of my job is things like MS Outlook and MS Teams. Outlook which I think used to be an email client, is now it's a calendar and email client and probably a lot more I don't even know about because I'm only forced to use it for my work email and my work calendar. I don't know what Teams started as but we mostly use it as a video chat app, but it has a bunch of other bloated features including a terrible text chat, some terrible file sharing ant lots more. And in this case it's actually really detrimental that they are "everything-apps" because the things they do are not really things that lends itself to multitasking in any way and they are not at all related tasks; so I have to switch between email mode and calendar mode in Outlook which means I either don't see what's in my calendar or I don't see new emails; and there's so much irrelevant nonsense and the notification system in MacOS is so bad that I'm completely blind to those. So if I want to keep an eye on both I have to run two instances of the same software! And while I only use Teams for the video meetings I still have to pay the performance cost of it trying to do everything. And bizarrely the two supposedly independent programs Outlook and Teams have some sort of weird interaction where having both open at the same time they very often each use twice as much CPU as when the other is closed
I think the kernel is fine - it runs your hardware, what else does it do? It's big because there is a lot of hardware out there and because there are a lot of parts to running your hardware.
But the rest of the software... Emacs may be fine having those problems, your web browser you can get away with it violating them philosophies, but when your init software exibits all of the problems is when we really have to watch out, because your whole system relies on it... If systemd gets compromised what do you do? It's not like installing a different browser.
I don't use systemd, I don't use desktop environments. Xorg... I don't know much about it actually. I guess it is the only thing I can't run away form. (do you even need to?)
yes
I feel like the arguments are also all based on opinion and perspective. You can argue that gnomes one thing is "making interfacing with your machine simple". you can get as granular as you like, but if the argument is that simple for someone...
It's simple, you are not a dev, this is more like a react channel than actually doing this. You wouldn't get it.
I might point out that the Linux coreutils does not purport to be "a program". Instead, it is a suite of programs which constitute the Gnu/Linux OS.
actually the Linux kernel is quite small and simple (for a kernel standard), most of the complexity and "bad stuff" is delegated to modules (it does have modularity then).
Now, many many many modules are always on, by default and you cannot really have it working without them, but still it's on the unix philosophy
I think the unix philosophy applies to single files, and not file packages. The idea is to write the code,then break it down to separate command calls that each serv one function which is reusable to other scripts or programs. Package suites can follow the unix philosophy when their scripts and libraries are subbed out appropriately.
I am not agree with the idea that programs should do 1 thing and 1 thing only, however, if you take a program and split it by it's modular form (in oop I mean classes, in clasic c I mean its files, in the linux kernel I mean the modules, etc.) you will find that almoust every good software is splitted in modules that are following the unix way.
I think it’s a good principle but you can stretch it if necessary. SystemD is very modular in design so arguably it still follows it.
Just because an application is modular does not mean that the core programs are not overly huge and bloated.
@@terrydaktyllus1320 That is true but imo systemd's modules aren't very bloated. A lot of them consist of only a few files with a few hundred lines each.
@@riley3269 I see what you did there. You avoided my point by talking about some modules only being small, when my actual point was the core program being bloated.
Just so you know - Gentoo Linux (no systemd) has been my main OS at home since 2003 but I have built, maintained and hardened Red Hat (Enterprise) Linux servers (with systemd) at work for something like 20 years now.
So I know both systemd and non-systemd environments well.
That’s good you have experience in it. I don’t think the core modules are bloated either but it’s subjective. Open to reasoning as to how core is bloated.
@@riley3269 "Core modules"? Surely you mean "core" or "modules"?
Sometimes I need a program, like a PDF viewer. I don't need to edit PDFs, I don't need to merge files in one. I need just PDF reader. That's where UNIX philosophy should apply.
The unix philosophy needs a bit of translation for modern times. The core principles are making your software components composable, using well-defined, interoperable interfaces between components, and defining the boundaries of components in such a way that each component has a single, easily abstractable purpose. Those core principles are still very relevant, even in the spaces where they aren't applied much right now. The linux kernel is one example, things like blender and web browsers are too. You could build something like blender in such a way the it was essentially just a UI, which made manipulation of underlying software components, which had interoperable interfaces, easier. The linux kernel could also be a LOT more modular than it is, if the infrastructure was designed differently.
That's why I'm on musl and runit
the unix philosophy is neat,but it's ultimately a means to an end (with the end being high-quality,freedom respecting software).
and there are multiple means to that end for me,so i am pretty indifferent to if it follows the philosophy and am more concerned with it being high quality and freedom respecting.
I don't think it's a clear cut answer anymore. In terms of programming and debugging it makes sense to keep it simple and modular. But the Unix philosophy was coined back when computers were limited in what they could do. One core of a CPU these days can handle what it took hundreds to do.
I look at a lot of the email clients for Linux and think most are overkill - with calendar schedulers, note taking - you name it. I think a program like Thunderbird certainly does the Unix philosophy where it handles email well, but you can add functionality through plugins. Sometimes this is a good thing as you can customise it's functionality how you like. By the same token misses functionality that probably should be included by default - like import/export backup.
For command line programs, yes it should be one job done well. In a GUI situation I don't think it translates that well these days.