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.
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.
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.
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
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 🤔
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.
I have also been trading with him, the profits are secured and over a 100% return on your investment directly sent to your wallet. I made up to $560, 000 in 2Months trading with him.
After watching so many youtube tutorial videos about trading I was still making losses until Mr Thomas Rowe started managing my investments now I make $60,567 weekly. God bless Mr Thomas he's been a blessing to my family.
Trading investment is a safer and surest way to make more money now because I have made up to $132,000 recently from investment trading and management.
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.
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.
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
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.
@@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
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.
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
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)
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.
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?
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.
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.
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.
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.
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.
@@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.
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
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.
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.
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.
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.
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.
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.
“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.
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.
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.
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.
Everyone says "Unix" philosophy, like it's a badge of honor, I don't know about all of you, but maybe during the 8 bit era it meant something, but In 2022, there's a reason Unix went the way of the dodo.
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.
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.
I have to disagree about emacs, it's like saying the shells violate UNIX philosophy by being able to run a bunch of tools each one adhering to the "do one thing and one thing well". If you're looking at each package as a tool, each package does one thing and one thing well. I'm not an emacs expert by any stretch of the imagination but I am trying to learn it. That's my opinion right now.
Today, it's more of a guideline. Back in the day, before GUI, Unix was a pure terminal environment, on a large shared computer, which had tiny memory cores, little disk space, and laughable processing power, at least by today's standards. Back when you maxed out at 64 kilobytes, a humongous program wouldn't have fit in the memory. Recall that 64k is 64,000, and 64g is 64,000,000,000 memory locations. That's roughly 1 million times the size of yesteryear's memory size. Put another way, yesteryear's memory was 1 millionth of the size of today's. Small programs, each doing one thing well, designed modularly, that made sense in those parameters. Relatively, today's desktop is yesterday's supercomputer. A feature laden program can be run with others, with no problem.
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?
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. :))
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.
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 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
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 keyword towards this subject is "dogmatic". Forcing certain rules and standards where they don't work well creates dogmatism, but the extreme opposite creates chaos and this chaos may cause lots of problems for the software project. Although I agree with you that freedom is important and that rule-breaking sometimes leads to innovation, I think there's a balance between complete anarchy and absolute dictatorship that should be addressed in order to avoid too much chaos and make good technology projects. Good technology must, in my humble opinion, allow growth and innovation but at the same time accept some standard(s) in order to interoperate well with other programs/systems and have a nice maintainability (unless of course you are designing a software to a very specific use case that doesn't fit in any existing standard). Controlled chaos is preferable to complete chaos or immobility. There's no silver bullet, and the unix philosophy is good for some projects but not for others.
It's just my obsessive nerdy pet peeve, but the community should really call it the "Unix idealogy". As in really simple abstract terms, philosophy is: "asking questions/thinking about answers", whilst ideology is: "deciding on answers and living by them". Anyway, doesn't matter. I'm just insane... All I know is that GNU is 'NOT Unix' 🌝
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 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.
Still important, only if you understanding it right :) Let me xplain. When you start developing something, you definitely need to start with "this component is doing 1 thing and doing it well" approach, but when your component evolves in time - it also grows. By following the Linux philosophy at every step of the component's evolution, you will make sure that it still doing 1 thing well, but already on a broader scale. This "1 thing" will also evolve. Like example of a video editor - program definitely started with the video editing, but evolved into smth like "video product editing", which not only about video, but about audio, text animations and so on, which all still related to it's core component - video, but now it is a complete video product. So, my statement is that even the huge piece of software, if all of it's components are "low coupled but highly cohesive", it becomes a mini-land, where each part follows the common idea, and this common idea is still 1 well-defined thing, which doing it's job well.
The *actual* UNIX philosophy is what is known as "worse is better", that is, to keep the implementation as simple as possible and transfer the complexities to the user. This certainly has its merits. It allows for quick deployment and the development of small, simple programs that can, at least theoretically, be used with other programs through "universal interfaces" to compose solutions to more complex problems. That "universal interface" is of course text, and each program has to parse the text it gets as input. While this does work well for problems that deal with text, it has shown to fall apart with complex structured data, requiring very ugly, if not impractical, chains of text manipulation commands in order to feed ths data into the programs. A non-textual object interface, such as in Windows NT, that can deal better with complex structured data, would of course be a divergence from the UNIX philosophy. It's also important to keep in mind that the UNIX philosophy was conceived at the time when computing and hardware constraints were radically different from what we have today. The creators of UNIX had only dozens of kilobytes to work with, and timesharing multiuser interactive systems were only beginning to become popular, and separate interfaces were used to work with data on different devices. The modern idea of desktop, let alone smart devices, simply didn't exist.
People ought to stop with the complaining ! If one can do better then just make it work and try to convince me without humiliating me doing so 🙂 That is the attitude I appreciate you for mr. Taylor. Thank you.
I think you "hit the nail on the head" when you said EMACS actually does one thing and that is interpret (paraphrased). As Linux provides the framework, etc., etc... the big picture IMHO, there are bigger rats to kill ergo move on.
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.
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.
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
The UNIX philosophy was relevant in the times that the computers that ran UNIX existed. The moment the GUI became a thing the UNIX philosophy became anachronic
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.
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.
My issue is that Linux youtuber's start to think they're some kind of authority for no reason. Not saying you DT but good examples would be Lunduke and Brodie. Don't get me started on the insanity of Luke Smith. Linux "community" has become a joke compared what it used to be in the 90s and early 2ks.
@@louistournas120 if you're new to linux how can you hope to understand. Its now riddled with people who don't understand the actual mindset and what linux was about. Weebs and other weirdos took over. We had some weirdos but not the same. We, of course, had weirdos like Richard Stallman but now its not the same mindset. You have people who get offended when you tell them you'd rather not use EMACS for example and accuse you of not knowing how to use it like their whole persona revolves around EMACs for example. Id rather use VIM since it follows more the linux philosophy. Not that I'm adamant about it but still I would rather not write a book on my reasons even though I could.. Weebs I've already mentioned and well you have your SJWs who've taken over. People like ADA or whatever her name is aka the coding witch.
@@davidgomez79 I guess some people have been using those software (EMACS, VIM) for 30 y and have perfected their knowledge of it. I can understand their view but one size does not fit all. This is why having multiple distros, multiple DE, multiple software that does the same thing is better than just 1 Windows with one theme and a world of just closed source software. For example, I prefer a GUI. If I am going to write software, I prefer a IDE like Qt Creator. I prefer highly customizable software. I like to change the background color, text color, text size, scroll bar size, and more. That way, we can have the maximum joyfulness for the maximum number of users. For example, I like the metric system but I am not going to force everyone to change. A software like LibreOffice should offer both and it does. For example, some people are confused. They don’t know how a kilo is sometimes 1000 and sometimes 1024. Some people want 1 kB = 1000 B. Some want 1 KB = 1024 B. Some want 1 kiB = 1024 B. How about having software that supports the 3 systems? Dolphin does support displaying all 3 systems. I am not hostile to closed source. All those game publishers should come on over to Linux. AutoCAD, Maya, SoftImage, Adobe Photoshop should all come to Linux.
Emacs is a Lisp machine that runs small, well-defined packages. Most packages does one thing, and do it well. So, I would argue that Emacs is a great example of a program that adheres to the UNIX philosophy.
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 🙂
I disagree with your interpretation of the Unix philosophy. It’s not the lines of code or the size of the program that makes it counter the Unix philosophy, it’s when something does many things poorly, instead of doing one thing well. Web browsers are a great example, as you stated. they play videos audio, render games so many things, and they do them all poorly. As an example, I have an old laptop that when playing video over 480p in a browser pegs the cpu to 100%. But using a video player that was designed from the onset to be a video player and using ani-cli to grab the files without having to use a web browser makes the machine capable of much more.
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.
UNIX philosophy was invented back in the day for CLI to facilitate interfacing between small programs through piping, and combine them in various different ways to be able to to engineer new solutions. Trully, you can look at it as an ingenious application of (only in modern times gotten more popular) functional programming paradigm for the CLI: piping is a one way data stream and small programs that do one thing well are clearly defined functions. Don't forget that UNIX was made by programmers for programmers. Hence why big monolithic "black box" programs that do many things don't fit well into that paradigm, the same why we don't see single big functions that do many different things in functional languages. It doesn't mean you can't do that, you can, but by that you erode the system. Obviously, GUI-only applications are historically bad in that department: not only they are generally big bloated projects, they also interface poorly with other programs - you generally can't easily pipe output from one GUI to the other like you can with CLI programs. But since GUI's main role is to interface with the user, everything else goes by the wayside generally. What people take the real issue with is when UNIX philosophy getting eroded on system-wide/CLI level.
@@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.
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
Unix was invented before SQL. Unix was created in the days when your database was a 2MB text file that you could read through in a few hours and skim in a few minutes. The modern world has no need for the Unix way of doing because of how inefficient it is.
You have three kinds of ppl or components of ppl in different personal ratio. Artists interpreters: These interested in esthetics, design, natural proportions, composition, representation, the human reactions, sizing things to fit human tastes & visualising abstractions to accessible form, translating mechanical to human & natural. Blacksmith Masters: These interested in how things work especially tools, learning, perfecting them & using them to maximum of their usability, automating, speeding up, optimising what exists. Alchemists: Those interested in exploring beyond limits of things existing, for new possibilities, new abstractions, side effects, features, new combinations of old functions, finding problems & improving, finding solutions & conceptualising new tools. In what style, for whom and adding what, how (fast, well, much) and using what, what for, what else and why not differently. Using fast a multitool is as effective as using normally dedicated tools for every singe thing. It's the same know how. But should we learn everything & know how everything is built & works? Opinions vary. Why one system and not a multisystem tool then? Why not a segregated specialised service layers for different purposes? I guess that's how some want to redefine internet protocol splitting into autonomous functional layers. What is core? Baby no more. #MyTool
The coreutils does follow the unix philosophy in the sense that each one of those programs do one thing and do one thing well. So idk where you tried to go with that argument.
Coreutils is not a program. It is a package of multiple separate programs that largely adheres to the UNIX Philosophy. There is a clear argument against busybox for example. You cannot compare a suite of programs to a single program. The main argument of the philosophy is you create building blocks that are comparatively simple to debug as units, and easy to combine for complex tasks. There are times that you need something more specialized. Definitely agree to use what works for you.
Anyone that says that "emacs violates the UNIX philosophy" would be wrong becauz like you said, it's an elisp interpreter and just because you can do a lot of things with a certain program doesn't mean it's not following the philosophy.
sophisticated software architecture, well documented and maintained standards and apis, and a culture of "fewer is more" would be enough. todays software is an expanding bubble of more and more layers of abstraction as a workaround against the inability to actually rethink and improve basic technology with new concepts in joint effort for the better of all. - pride, power, monetization -> fragmentation and inefficiency. it's not about granular or monolithic.
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.
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
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.
In the case of following The UNIX Philosophy... if you have a viable option that follows it, it usually is better to take that option. That being said... you don't always have a viable option In the case of systemd... I remember trying to set stuff up before that... and the part of The UNIX Philosophy people forget about is that the small program needs to do the task WELL. Before systemd, the process of starting up a system wasn't done well. Most of the time it didn't get done (so many systems that managed to boot up, despite most of the start up not actually succeeding... and gosh the later errors down the line I'd get from THAT) With X11... in the case of Xorg and XFree86 (hey... remember debugging xconf files?) we don't have a variation of Xlib that follows The UNIX Philosophy more effectively. That being said... both Xorg and XFree86 do the modular portion of stuff with some uh... well, I've managed to release the magic smoke by exploiting the modularity of this, to compile a library for XFree86 to talk with Xorg... don't ask for details, I might give them to you xD In order to effectively create a pipeline with The UNIX Philosophy, you'd need to have a decent signalling system and comprehensive glue interface between them. Which creates a situation where following The UNIX Philosophy to its full extend results in violating The UNIX Philosophy. To prove this, I propose a system that makes heavy usage of UUCP, NNTP, FTP, SMTP, POP3, IMAP, HTTP, SQUID and Perl 4. Why Perl 4? Well, because I've literally seen books published on setting up software using The UNIX Philosophy that were published after 1995 which made heavy usage of Perl 4, and I must share the pain. Ever example of Perl glue code in those books could be broken by adding "use strict;" to the top of those source files You can do a lot to have people cool their jets about The UNIX Philosophy by letting them know about how this requires glue code. While Raku has managed to turn into a butterfly, after being a hungry camel (some configuration option must have been misset... but it would be in Perl 4... so good luck figuring that out)... if you look at what ends up being required with glue code... you end up coming to the forced realisation that The UNIX Philosophy inevitably ends in violation of itself when taken to its extreme In the case of EMACS... it being Elisp and a Software Ecosystem based on Elisp is a good counter argument to the "violates The UNIX Philosophy"--at which point you should look at each element of that Elisp Software Ecosystem to see what could be done to break up stuff and still have it be useful to some amount. Oh right "Software Ecosystems" are kind of an unavoidable notion, that are their own form of following The UNIX Philosophy... that yes, will also create a violation in itself
The problem with any philosophy is when people start treating it as an axiom instead of a philosophy. As a way of looking at goals, it’s excellent - but “do one thing and do it well” does not fit 100% of the time in all situations. Anyone who hates violation of the Unix Philosophy is more than welcome to offer replacements for those specific pieces of software that solves all the same use cases as it does, but does so in a modular way in a suite of multiple interworking programs. There’s a reason these paths have been successful - because they fix things that KISS did not fix. Things like eMacs and systemd didn’t evolve out of a vacuum- they came along to solve specific use cases that sysVinit, upstart, or other equivalents did not have answers for, same with vi/vim and eMacs - I’m a long time vi/vim user, am terrible in eMacs, and can’t stand it, but I’m glad it exists to solve the cases that vim or nano does not solve. Simpler is often better, but it is not always better. It is, in fact, the best route to try first, but if it’s necessary for a reason, even if it’s not YOUR reason, that doesn’t mean “they’re doing it wrong.”
As Benno Rice put it very nicely in the Linux conference afew years back "The truth is...*UNIX is dead*" That's exactly right Some part of it is quite nice to have, but it's by no means applicable anymore in the current century The UNIX Philosophy shouldn't be kept anymore because it's holding all *NIX derivatives - BSD, Linux etc - Back from trying new things and expanding as an operating system Future generations won't give an absolute toss about UNIX anymore, let alone even know about UNIX to begin with
I love modularity in my applications, for example in Python or especially Shellscript, because it makes my OCD mind not want to commit seppuku whenever I start a new project But if I want to make a single-file project/application/script that allows you to - use curl/git to download - run and - install that shouldn't be looked down by others, in fact, it's by design to be as such
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...
The worst problem in floss communities is the bigotry from those few who believe they know better. Let's face it, we're all idiots in most things. Without each other's expertise, we'd be useless. Diversity is essential. There should be lots of UNIX-like philosophies and a diversity of options that users can choose from. The freedom to choose is key.
Blender the a perfect example of a program not following the UNIX principle. Though sometimes a good framework makes the software modular anyways. Think of what you can do with graph-based programming. Not only shaders, Blender already contains most of the code required to implement a GPU-accelerated modular synthesizer. And then it already has a sequencer from its animation capabilities. Now, add MIDI input + multi-channel audio input, and you have a DAW, that can also produce a music video. Indeed, through the node system, different channels from the mix can animate different parts of the scene.
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.
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
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 🤔
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.
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.
Despite the economic downturn, I'm so happy 😊. I have been earning $60,000 returns from my $7,000 investment every 13days
Same here, I started with $12,000 now earning $88,300 bi-weekly with profits with Mr Thomas Rowe trading program.
I have been hearing about Mr Thomas and he's genius mind in the crypto market, how good is him?
I have also been trading with him, the profits are secured and over a 100% return on your investment directly sent to your wallet. I made up to $560, 000 in 2Months trading with him.
After watching so many youtube tutorial videos about trading I was still making losses until Mr Thomas Rowe started managing my investments now I make $60,567 weekly. God bless Mr Thomas he's been a blessing to my family.
Trading investment is a safer and surest way to make more money now because I have made up to $132,000 recently from investment trading and management.
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 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
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
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
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.
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
It's simple, you are not a dev, this is more like a react channel than actually doing this. You wouldn't get it.
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.
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.
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?
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.
hello DT :) You should start a podcast. You are good freestyle and also informative along with sharing your opinions.
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.
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.
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.
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.
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
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.
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.
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.
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."
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.
Actually emacs does only one thing and does it perfectly, interprets elisp ÷)
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.
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.
“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.
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.
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.
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.
Everyone says "Unix" philosophy, like it's a badge of honor, I don't know about all of you, but maybe during the 8 bit era it meant something, but In 2022, there's a reason Unix went the way of the dodo.
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:
ua-cam.com/video/Q0vMon0sN3U/v-deo.html
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.
And then we have people saying things like "speed doesn't matter anymore" and "just use Python because compooter fast"
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.
I have to disagree about emacs, it's like saying the shells violate UNIX philosophy by being able to run a bunch of tools each one adhering to the "do one thing and one thing well". If you're looking at each package as a tool, each package does one thing and one thing well. I'm not an emacs expert by any stretch of the imagination but I am trying to learn it. That's my opinion right now.
Today, it's more of a guideline. Back in the day, before GUI, Unix was a pure terminal environment, on a large shared computer, which had tiny memory cores, little disk space, and laughable processing power, at least by today's standards.
Back when you maxed out at 64 kilobytes, a humongous program wouldn't have fit in the memory. Recall that 64k is 64,000, and 64g is 64,000,000,000 memory locations. That's roughly 1 million times the size of yesteryear's memory size. Put another way, yesteryear's memory was 1 millionth of the size of today's.
Small programs, each doing one thing well, designed modularly, that made sense in those parameters.
Relatively, today's desktop is yesterday's supercomputer. A feature laden program can be run with others, with no problem.
I wish emacs was multi-threaded
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?
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. :))
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.
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 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
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 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 keyword towards this subject is "dogmatic". Forcing certain rules and standards where they don't work well creates dogmatism, but the extreme opposite creates chaos and this chaos may cause lots of problems for the software project.
Although I agree with you that freedom is important and that rule-breaking sometimes leads to innovation, I think there's a balance between complete anarchy and absolute dictatorship that should be addressed in order to avoid too much chaos and make good technology projects. Good technology must, in my humble opinion, allow growth and innovation but at the same time accept some standard(s) in order to interoperate well with other programs/systems and have a nice maintainability (unless of course you are designing a software to a very specific use case that doesn't fit in any existing standard). Controlled chaos is preferable to complete chaos or immobility.
There's no silver bullet, and the unix philosophy is good for some projects but not for others.
It's just my obsessive nerdy pet peeve, but the community should really call it the "Unix idealogy". As in really simple abstract terms, philosophy is: "asking questions/thinking about answers", whilst ideology is: "deciding on answers and living by them". Anyway, doesn't matter. I'm just insane... All I know is that GNU is 'NOT Unix' 🌝
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 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.
Quote from the movie "Prince of Persia: The Dagger of Time " : Everything changes with time...We should know this best of all
Still important, only if you understanding it right :) Let me xplain.
When you start developing something, you definitely need to start with "this component is doing 1 thing and doing it well" approach, but when your component evolves in time - it also grows. By following the Linux philosophy at every step of the component's evolution, you will make sure that it still doing 1 thing well, but already on a broader scale. This "1 thing" will also evolve.
Like example of a video editor - program definitely started with the video editing, but evolved into smth like "video product editing", which not only about video, but about audio, text animations and so on, which all still related to it's core component - video, but now it is a complete video product.
So, my statement is that even the huge piece of software, if all of it's components are "low coupled but highly cohesive", it becomes a mini-land, where each part follows the common idea, and this common idea is still 1 well-defined thing, which doing it's job well.
The *actual* UNIX philosophy is what is known as "worse is better", that is, to keep the implementation as simple as possible and transfer the complexities to the user.
This certainly has its merits. It allows for quick deployment and the development of small, simple programs that can, at least theoretically, be used with other programs through "universal interfaces" to compose solutions to more complex problems.
That "universal interface" is of course text, and each program has to parse the text it gets as input.
While this does work well for problems that deal with text, it has shown to fall apart with complex structured data, requiring very ugly, if not impractical, chains of text manipulation commands in order to feed ths data into the programs.
A non-textual object interface, such as in Windows NT, that can deal better with complex structured data, would of course be a divergence from the UNIX philosophy.
It's also important to keep in mind that the UNIX philosophy was conceived at the time when computing and hardware constraints were radically different from what we have today. The creators of UNIX had only dozens of kilobytes to work with, and timesharing multiuser interactive systems were only beginning to become popular, and separate interfaces were used to work with data on different devices.
The modern idea of desktop, let alone smart devices, simply didn't exist.
People ought to stop with the complaining ! If one can do better then just make it work and try to convince me without humiliating me doing so 🙂 That is the attitude I appreciate you for mr. Taylor. Thank you.
I think you "hit the nail on the head" when you said EMACS actually does one thing and that is interpret (paraphrased). As Linux provides the framework, etc., etc... the big picture IMHO, there are bigger rats to kill ergo move on.
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.
'Small, simple, and modular' is how I like my computers. SBC's for everything!
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.
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
The UNIX philosophy was relevant in the times that the computers that ran UNIX existed. The moment the GUI became a thing the UNIX philosophy became anachronic
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.
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.
My issue is that Linux youtuber's start to think they're some kind of authority for no reason. Not saying you DT but good examples would be Lunduke and Brodie. Don't get me started on the insanity of Luke Smith. Linux "community" has become a joke compared what it used to be in the 90s and early 2ks.
What do you mean by joke? I've switched to Linux after MS pulled the plug on Win 7. The community seems ok except for certain people.
@@louistournas120 if you're new to linux how can you hope to understand. Its now riddled with people who don't understand the actual mindset and what linux was about. Weebs and other weirdos took over. We had some weirdos but not the same. We, of course, had weirdos like Richard Stallman but now its not the same mindset. You have people who get offended when you tell them you'd rather not use EMACS for example and accuse you of not knowing how to use it like their whole persona revolves around EMACs for example. Id rather use VIM since it follows more the linux philosophy. Not that I'm adamant about it but still I would rather not write a book on my reasons even though I could.. Weebs I've already mentioned and well you have your SJWs who've taken over. People like ADA or whatever her name is aka the coding witch.
@@louistournas120 Coraline Ada Ehmke that's "thems" name. Ridiculous.
@@louistournas120 Nevermind I see you're subbed to secular talk. You wouldn't understand. You're one of the people I'm talking about.
@@davidgomez79 I guess some people have been using those software (EMACS, VIM) for 30 y and have perfected their knowledge of it. I can understand their view but one size does not fit all.
This is why having multiple distros, multiple DE, multiple software that does the same thing is better than just 1 Windows with one theme and a world of just closed source software.
For example, I prefer a GUI. If I am going to write software, I prefer a IDE like Qt Creator.
I prefer highly customizable software. I like to change the background color, text color, text size, scroll bar size, and more.
That way, we can have the maximum joyfulness for the maximum number of users.
For example, I like the metric system but I am not going to force everyone to change. A software like LibreOffice should offer both and it does.
For example, some people are confused. They don’t know how a kilo is sometimes 1000 and sometimes 1024.
Some people want 1 kB = 1000 B. Some want 1 KB = 1024 B. Some want 1 kiB = 1024 B.
How about having software that supports the 3 systems? Dolphin does support displaying all 3 systems.
I am not hostile to closed source. All those game publishers should come on over to Linux.
AutoCAD, Maya, SoftImage, Adobe Photoshop should all come to Linux.
Emacs is a Lisp machine that runs small, well-defined packages. Most packages does one thing, and do it well. So, I would argue that Emacs is a great example of a program that adheres to the UNIX philosophy.
The inventors of UNIX recognized the shortcomings and limitations of the UNIX philosophy already by the late 1980s. That's why they moved to Plan9.
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 🙂
I disagree with your interpretation of the Unix philosophy. It’s not the lines of code or the size of the program that makes it counter the Unix philosophy, it’s when something does many things poorly, instead of doing one thing well. Web browsers are a great example, as you stated. they play videos audio, render games so many things, and they do them all poorly. As an example, I have an old laptop that when playing video over 480p in a browser pegs the cpu to 100%. But using a video player that was designed from the onset to be a video player and using ani-cli to grab the files without having to use a web browser makes the machine capable of much more.
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.
Its a philosophy, but some people treat it as a religion.
UNIX philosophy was invented back in the day for CLI to facilitate interfacing between small programs through piping, and combine them in various different ways to be able to to engineer new solutions. Trully, you can look at it as an ingenious application of (only in modern times gotten more popular) functional programming paradigm for the CLI: piping is a one way data stream and small programs that do one thing well are clearly defined functions. Don't forget that UNIX was made by programmers for programmers.
Hence why big monolithic "black box" programs that do many things don't fit well into that paradigm, the same why we don't see single big functions that do many different things in functional languages. It doesn't mean you can't do that, you can, but by that you erode the system.
Obviously, GUI-only applications are historically bad in that department: not only they are generally big bloated projects, they also interface poorly with other programs - you generally can't easily pipe output from one GUI to the other like you can with CLI programs. But since GUI's main role is to interface with the user, everything else goes by the wayside generally.
What people take the real issue with is when UNIX philosophy getting eroded on system-wide/CLI level.
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"?
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
Unix was invented before SQL. Unix was created in the days when your database was a 2MB text file that you could read through in a few hours and skim in a few minutes. The modern world has no need for the Unix way of doing because of how inefficient it is.
You have three kinds of ppl or components of ppl in different personal ratio.
Artists interpreters: These interested in esthetics, design, natural proportions, composition, representation, the human reactions, sizing things to fit human tastes & visualising abstractions to accessible form, translating mechanical to human & natural. Blacksmith Masters: These interested in how things work especially tools, learning, perfecting them & using them to maximum of their usability, automating, speeding up, optimising what exists. Alchemists: Those interested in exploring beyond limits of things existing, for new possibilities, new abstractions, side effects, features, new combinations of old functions, finding problems & improving, finding solutions & conceptualising new tools. In what style, for whom and adding what, how (fast, well, much) and using what, what for, what else and why not differently.
Using fast a multitool is as effective as using normally dedicated tools for every singe thing. It's the same know how. But should we learn everything & know how everything is built & works? Opinions vary.
Why one system and not a multisystem tool then? Why not a segregated specialised service layers for different purposes? I guess that's how some want to redefine internet protocol splitting into autonomous functional layers.
What is core? Baby no more. #MyTool
Can you do a review on Gnu guix(ie. Nonguix installer from system crafters channel) because it usable as a daily operating system.
The coreutils does follow the unix philosophy in the sense that each one of those programs do one thing and do one thing well. So idk where you tried to go with that argument.
Coreutils is not a program. It is a package of multiple separate programs that largely adheres to the UNIX Philosophy. There is a clear argument against busybox for example.
You cannot compare a suite of programs to a single program. The main argument of the philosophy is you create building blocks that are comparatively simple to debug as units, and easy to combine for complex tasks.
There are times that you need something more specialized. Definitely agree to use what works for you.
Anyone that says that "emacs violates the UNIX philosophy" would be wrong becauz like you said, it's an elisp interpreter and just because you can do a lot of things with a certain program doesn't mean it's not following the philosophy.
sophisticated software architecture, well documented and maintained standards and apis, and a culture of "fewer is more" would be enough. todays software is an expanding bubble of more and more layers of abstraction as a workaround against the inability to actually rethink and improve basic technology with new concepts in joint effort for the better of all. - pride, power, monetization -> fragmentation and inefficiency. it's not about granular or monolithic.
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.
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
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.
In the case of following The UNIX Philosophy... if you have a viable option that follows it, it usually is better to take that option. That being said... you don't always have a viable option
In the case of systemd... I remember trying to set stuff up before that... and the part of The UNIX Philosophy people forget about is that the small program needs to do the task WELL. Before systemd, the process of starting up a system wasn't done well. Most of the time it didn't get done (so many systems that managed to boot up, despite most of the start up not actually succeeding... and gosh the later errors down the line I'd get from THAT)
With X11... in the case of Xorg and XFree86 (hey... remember debugging xconf files?) we don't have a variation of Xlib that follows The UNIX Philosophy more effectively. That being said... both Xorg and XFree86 do the modular portion of stuff with some uh... well, I've managed to release the magic smoke by exploiting the modularity of this, to compile a library for XFree86 to talk with Xorg... don't ask for details, I might give them to you xD
In order to effectively create a pipeline with The UNIX Philosophy, you'd need to have a decent signalling system and comprehensive glue interface between them. Which creates a situation where following The UNIX Philosophy to its full extend results in violating The UNIX Philosophy. To prove this, I propose a system that makes heavy usage of UUCP, NNTP, FTP, SMTP, POP3, IMAP, HTTP, SQUID and Perl 4. Why Perl 4? Well, because I've literally seen books published on setting up software using The UNIX Philosophy that were published after 1995 which made heavy usage of Perl 4, and I must share the pain. Ever example of Perl glue code in those books could be broken by adding "use strict;" to the top of those source files
You can do a lot to have people cool their jets about The UNIX Philosophy by letting them know about how this requires glue code. While Raku has managed to turn into a butterfly, after being a hungry camel (some configuration option must have been misset... but it would be in Perl 4... so good luck figuring that out)... if you look at what ends up being required with glue code... you end up coming to the forced realisation that The UNIX Philosophy inevitably ends in violation of itself when taken to its extreme
In the case of EMACS... it being Elisp and a Software Ecosystem based on Elisp is a good counter argument to the "violates The UNIX Philosophy"--at which point you should look at each element of that Elisp Software Ecosystem to see what could be done to break up stuff and still have it be useful to some amount. Oh right "Software Ecosystems" are kind of an unavoidable notion, that are their own form of following The UNIX Philosophy... that yes, will also create a violation in itself
The problem with any philosophy is when people start treating it as an axiom instead of a philosophy. As a way of looking at goals, it’s excellent - but “do one thing and do it well” does not fit 100% of the time in all situations. Anyone who hates violation of the Unix Philosophy is more than welcome to offer replacements for those specific pieces of software that solves all the same use cases as it does, but does so in a modular way in a suite of multiple interworking programs. There’s a reason these paths have been successful - because they fix things that KISS did not fix.
Things like eMacs and systemd didn’t evolve out of a vacuum- they came along to solve specific use cases that sysVinit, upstart, or other equivalents did not have answers for, same with vi/vim and eMacs - I’m a long time vi/vim user, am terrible in eMacs, and can’t stand it, but I’m glad it exists to solve the cases that vim or nano does not solve. Simpler is often better, but it is not always better. It is, in fact, the best route to try first, but if it’s necessary for a reason, even if it’s not YOUR reason, that doesn’t mean “they’re doing it wrong.”
The answer is pretty simple: Gnu is Not Unix.
So no GNU/Linux should necessearly adhere to the Unix philosophy to be part of the Linux ecosystem.
GNU's Not UNIX was supposed to mean that unlike UNIX, GNU is free.
@@iskamag yeah, it was suposed to, but the years gone by and now it is not Unix in many other ways.
@@nuldorvamoysenor2091 oh how isn't it? GNU even has a working microkernel OS.
As Benno Rice put it very nicely in the Linux conference afew years back
"The truth is...*UNIX is dead*"
That's exactly right
Some part of it is quite nice to have, but it's by no means applicable anymore in the current century
The UNIX Philosophy shouldn't be kept anymore because it's holding all *NIX derivatives - BSD, Linux etc - Back from trying new things and expanding as an operating system
Future generations won't give an absolute toss about UNIX anymore, let alone even know about UNIX to begin with
I love modularity in my applications, for example in Python or especially Shellscript, because it makes my OCD mind not want to commit seppuku whenever I start a new project
But if I want to make a single-file project/application/script that allows you to
- use curl/git to download
- run and
- install
that shouldn't be looked down by others, in fact, it's by design to be as such
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...
The worst problem in floss communities is the bigotry from those few who believe they know better. Let's face it, we're all idiots in most things. Without each other's expertise, we'd be useless. Diversity is essential. There should be lots of UNIX-like philosophies and a diversity of options that users can choose from. The freedom to choose is key.
Let's flip the script: "Use less apps that do their tasks well". Could you imagine having a separate app for each individual task?
Wise words 👏👏👏 Thanks for this DT ❤️
Blender the a perfect example of a program not following the UNIX principle. Though sometimes a good framework makes the software modular anyways. Think of what you can do with graph-based programming. Not only shaders, Blender already contains most of the code required to implement a GPU-accelerated modular synthesizer. And then it already has a sequencer from its animation capabilities. Now, add MIDI input + multi-channel audio input, and you have a DAW, that can also produce a music video. Indeed, through the node system, different channels from the mix can animate different parts of the scene.
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.