If you're using a GUI, that means whatever you're doing you're not doing a lot of it, since you don't need to automate it. I would expect a world-class enterprise engineer to be able to automate most tasks, and from that they would be very comfortable with the command line.
Can you do everything with a GUI that you can on a command line? Yeah probably, if the developer is at all the features properly. Can you automate it easily? No not at all. So the more you do something the more you tend to want to deal with the vocabulary of the command line because it's more expressive and allows for automation.
I will die on this hill!
Documentation too. Frontends change all the time, but CLI tools usually don't, so you can usually rely on old documentation. But have you ever tried googling how to do something in MS office, found and article from half a year ago and found that none of the things it mentions exist anymore? It's ridiculous how much time people waste trying to figure out stuff multiple times because it changes so much.
After long periods of not using GUIs, I found myself very confused every time I want to do something. I was trying to insert a code block into Power Point yesterday, took me half an hour of googling and didn't manage to do it. With Latex, I googled and in 2 minutes I had a code block.
Given that Latex is a clusterfuck of legacy, it speaks volumes that it's still so much easier to do things there rather than in powerpoint.
With MS office I've also adopted a "fuck it, I'll just take a screenshot" approach.
A collection of screenshots send around by mail after having poorly drawn arrows and frames in it, is official documentation. Source: my corporation
Yup, I tried doing it properly too when I started and now I don't give a shit. If the company wants us to use crappy tools, that's what they get.
What are you saying? The project is finished, the new stuff implemented and now you want to buy some fancy software and shedule 100 hours for documentation? We dont need that! Just help out your colleagues, when they have a question. They'll all know what to do in no time!
Depends on what system youโre running, and especially what task youโre doing. Trying to operate firewall rules via CLI is an exercise in self-inflicted pain, as is trying to set a complex cron schedule without a handy calculator.
on the contrary, CLI is the BEST way to deal with firewall rules.
Personally, I'd take it a step further. Firewall rules should be defined as code in a git repo. So if you're building rules in a gui, you're simply doing it wrong. While a cli and/or api should be used, that should be automated and invisible to a human.
TIL there are people configuring firewalls via GUIs. Okay โฆ Iโm do that too on my private equipment because Iโm lazy. But it feels wrong doing so in an enterprise context.
You using a Cisco firewall or something?
Iโve been using F5 in the past. Not doing that anymore though.
Junos CLI is a real treat. I work with the SRX line regularly, particularly the SRX4600 and the SRX300 series.
CLI debuggers can't hold a candle to the Visual Studio debugger. This is generally not something you automate, and I haven't met many engineers that know gdb well. But pretty much anyone can use VS debugger.
Honestly, some things can be done faster/as fast on GUI. So really just use whatever increases your productivity.
IMO GUIs are always faster when it's something you've never used before, or use very infrequently.
CLI is better if you're used to the task you're doing, or automating things. But for infrequent tasks looking up the commands (or looking at old notes to find it) is very slow and rather annoying.
Moving files across several subfolder levels tends to be much faster on a GUI. Finding files is usually much faster via CLI, even when you have to look up again how to use the find command of your choice
The more you use the commands the more you remember them. I got good at the CLI by forcing myself to use it for things I would normally do in a GUI. Now everyone thinks Iโm a wizard which I wonโt discourage
Is there an instant GUI find tool on linux? find is very slow compared to using Everything on windows, and sorting results is really hard via CLI.
Oh, you're not aware of "locate"
I am but searching via CLI I'm not sure how to easily sort by last modified time, or restrict to a specific root path first.
I don't know about GUI tools, but:
Everything is so fast because it uses the index built into NTFS to find files by filename quickly, and NTFS is the definitive file system on Windows so it works everywhere.
On Linux, there isn't really an index built into the filesystem - some might have that, but I don't know about it. That said, plocate is a common tool that uses its own index. You have to update the database when files change (you'll probably have a job doing that daily), but searching the index is very fast.
locate
I usually just make a bat or py script to move and create specific files to specific folders.
I only do this because I'm lazy and numbering, renaming and creating folders is a drag and can be easily automated, but just copy/paste or cut/paste is faster in GUI, especially with alt tab and the new tab file system on windows.
A GUI with a search function is always the best way to deal with filesystems, in my experience.
Always orders of magnitude slower and near-infinitely less featureful, in my experience.
Your filesystem must be monstrously huge if it's actually perceptibly slow. I also get tired of typing in long filenames with a ton of special characters I have to escape.
You've never had to search through hundreds of gigabytes of source files, I guess. Congratulations.
No, I've never had that displeasure, Nothing I've worked on has been that big. My condolences.
Pshaw! CLI and GUI? Real network engineers make hand crafted API calls!
You gotta admit, it's fun to meme the opposite camp. Whether you are a GUI or CLI person.
But you look way cooler when using the terminal for most of your stuff ๐โโ๏ธ also using a riced out window manager and riced out Vim config for which you spent hundreds of hours on customizing every aspect of it :p normal people don't know what the fuck is going on on your pc so you can feel instantly feel superior to those normies!
Ah also btw i use arch ;)
I use both. I use the CLI for a lot of stuff but I also use the GitHub Desktop fork for Linux lol.
I don't care how powerful git is in CLI, that gui is just so nice imo
It took me forever to realize I could edit config files in a graphical text editor. When you have a really long file it's just nicer to have properly formated text wrapping and a scrollbar with a preview box.
Exactly. Use the tools you have the way they fit you best.
If it aids your work flow learn the CLI commands you use the most. If it's something obscure or rarely used, use the gui.
Another not mentioned benefit of becoming comfortable with using the cli is that you then can more easily script stuff.
To get annoyingly serious on a funny post, the one huge danger of GUIs that I've personally witnessed in many of my juniors is that they abstract away the need to understand the tool you're using.
I regularly use a Git GUI, and I might have to google the rebase command for more complex tasks, but I know how Git works. I know what I can do with rebase, even if I don't exactly know how to. If you only live in the GUI, you can get far never understanding the system. Until one day, when you fuck up a commit or a push, and you're totally hosed because there isn't a pretty button with the exact feature you want in your GUI.
Somehow I've made it 7 years without messing up a git command that I couldn't fix in like 2 seconds. I primarily use vscode's source controller more featured source controllers like sourcetree feel overly complex and typing out git commands is fine but you spend more time doing that than you would with vscode's approach. I'm really curious about what you mean by fuck up a commit or push
Try reverting a reverted commit (revert of revert, yes) while other team members are working on a branch which has the first revert. It's super fun merging after that.
(Or something of that effect, can't remember the exact details of that fuckup)
I don't think I will, mostly cause I work on a team of 1 right now which makes my branches wonderfully simple.
Yeah, fuck that. It's perfectly fine to build a GUI that makes things a bit easier, but make the GUI so that it resembles the fucking workflow. I hate that when I want to automate something thats super easy in the GUI and it takes AGES because there is no equivalent to what I'm doing in the GUI
I hate that when I want to automate something thats super easy in the GUI and it takes AGES because there is no equivalent to what Iโm doing in the GUI
glares angrily at Azure CLI
Azure CLI and AzPowershell are somehow so powerful and useful until they fall flat on their face.
So... my only requirement for my tools is that they have a well-supported CLI, and can be installed headless without graphical dependencies. Tools must be scriptable.
That said, it's nice to have a UI. My ideal configuration is a scriptable tool with a good API, and a separate GUI tool that can drive it.
One of the best tools I've used is SuperSlicer. It's a slicer for 3D printers. It has GUI, it has CLI and it has a DLL/SO so you can add its features to your own application. And it's open source if linking against an existing library is too hard for you, lol.
"graphical user interfaces make easy tasks easy, while command line interfaces make difficult tasks possible"
William E. Shotts Jr., The Linux Command Line: A Complete Introduction
It has taken me a long time to get comfortable using a Linux CLI (definitely not as familiar with windows cmd prompt/powershell), and I know that if I log into a box anywhere, If it has sh or bash or some variant of those shells, I'll be able to get by.
Now, on my home server, moving & renaming a bunch of media files has me really wishing I had a DE installed there to Ctrl + click/Drag-n-drop...
Also, I love using VScodium/Code as an IDE bc of its configurability & rich plugin ecosystem -- but recently I had some performance hiccups with extensions not playing nice together and started (again) down the masochistic path of configuring neovim to use as an "IDE"...
Why not mount your server as a share and use your desktop GUI to manipulate files? Then you can do both.
Laziness so far haha but yes that's a good plan
I always feel that graphical interfaces make easy things difficult, in most cases. A bunch of figity clicking around, instead of a few keystrokes I could press with my eyes closed. They are more discoverable, though.
If you use emacs, dired and wdired together are fantastic for managing files like that. You can even run dired over tramp, so you can manage files on a remote server that doesn't have emacs installed, using the emacs on your desktop. But there are also good cli options, you might want to look at the rename command, as one that's probably installed by default on any given distro. That's outside my expertise, though, as I just use emacs.
Yes I've used rename! In my case, I just need to rename and reorganize a bunch of movies & associated metadata files into directories. I don't have too many stored digitally now, so I think just shaving the yak and doing it manually via file share will work for now.
Never been an emacs user... Seems like quite a rabbit hole
Skip the masochism, try helix. Switched to that + zellij with about 20 lines of config and never looked back
Takes a second to get used to the keybindings but after about ~2w you can painlessly switch back and forth between vim and helix pretty much instantly
Helix + zellij huh? I'll definitely try it out
Feel free to ping me if I can help, at least in the form of starter configs/small hacks that emulate VS Code workflows or something :)
Personally I was the guy that had thousands of lines of Vim and Emacs configurations, so I really had to do this to manage the time sink (like you I had a stint with VS Code in between that eventually stopped working for me)
Yeah, keep telling yourself that buddy.
So far I don't think anyone has interpreted the meme correctly, the wikiHow guy is supposed to be an obvious shortcoming expressed as a guy trying to convince himself it's not a problem.
Using the right tool for the right task is a big part of being a good engineer.
thank you.
I think I really only use GUIs if I am learning something new and trying to understand the process/concepts or if I'm doing something I know is too small to automate. Generally once I understand a problem/tool at a deeper level, GUIs start to feel restrictive.
Notable exceptions are mostly focused around observability (Grafana, new relic, DataDog, etc) or just in github. I've used gh-dash before but the web ui is just more practical for day to day use.
For context, I'm in SRE. I feel like +90% of my day is spent in kubernetes, terraform, or ci/cd pipelines. My coworkers tend to use Lens but I'm almost exclusively in kubectl or the occasional k9s.
Searching a log file? I want less. Searching all log files? I want log aggregation lol.
Exactly.
One log file, or all, I want grep or awk, maybe with find in front, possibly throw some jq on top if something is logging big json blobs.
That's a lot slower at scale than something like Loki.
I feel you. The problem with a lot of Elastic style document search engines is that they don't ever let you search by very explicit terms because of how the index is built. I believe the pros outweigh the cons but I often wish I could "drop into" grep, less, and others from within the log aggregation tool.
If I knew what I was looking for I could grep all the log files and pipe the output to another file to aggregate them.
The problem is that they're all on different servers. Once you use log aggregation stuff like DataDog, Splunk, or Kibana you get it, but before it's hard to see the benefits. Stuff like being able to see a timestamp of when an error first appeared and then from the same place see what other stuff happened around the same time.
If I had dozens or hundreds of servers that would make a huge difference, but for under a dozen I think the cost of setting that all up isn't worth the added benefit. Plus if the log aggregation goes down (which I've seen happen with some really hairy issues) you're back to grepping files so it's good to know how.
Totally. I'm talking more from the enterprise perspective. Even apart from that I'm not sure if the cost is worth it at that scale. Even using foss solutions the dev hours setting it up might not be worth it.
Github's UI is total garbage compared to basic git commands, though.
You can't manage pull requests, github actions, repo collaborators, permissions, or any number of the dozens of other things github does just from basic git commands.
Someone told me that windows server UI interface has more options than CLI. I got scared of windows server (how do you repeatedly Setup the same server, with a screenshot documentation ???)
It's been a while since I've found that true. You can do everything you want to do in powershell now days.
Yeah, I think MS started adding PowerShell for everything after server 2012 R2.
First of all, most Windows settings are in the registry, so you don't have to go to the UI, you can just upload new settings straight into the registry through CLI.
Second, PowerShell exists and it's awesome!
And third, you can always use UI automation tools if you're bad at registry and PowerShell. Just record your session and run whenever needed.
Newer versions of Windows can give you the exact Powershell code it's executing based on what you've configured in the gui. This is still extremely inconsistent across Windows services though. I don't know that I'd feel comfortable running a headless windows server yet. Too much stuff still assumes you'll use the gui for most things.
To be honest, if you really need Windows servers you should run core if possible. Basically all Microsoft's management shit can be run remotely from your jump/management host. That said a lot of shit requires gui and refuses to run on core, like adsync
Is there a significant performance difference? I'm assuming the attack surface is lower.
There's slight difference in resource usage of course, which does scale if you're unlucky enough to have lot of them.
Minimum ram required is 512mb for core, 2gb for desktop experience so we can safely assume keeping the gui usable eats some 1.5gb memory. 500 servers adds some 750gb overhead in theory.
Then there's of course the fact that less bloat will generally add up to less problems. Ever rdp to a server and start menu refuses to open or other weird gui shit. That's just wasting your time.
PSA: Since his finger and the reflection touches, he's likely looking into a one way mirror. There's someone behind the glass.
I just walked around my house touching all my mirrors and they all do this. Hope they're not on to me now... Think I'll wait for night and try to make a break for it.
Or it's an extremely thin glass.
Or just a reflective surface.
Or his name is Truman Burbank
it makes you a Windows engineer which is worse
"Windows engineer' lmao.
Well, there technically are communities for enterprise engineering.... they just, aren't very active.
Exactly. Posting to a community of a dozen people who don't engage on content seems like a pointless endeavor.
Well, some fellow over here on my instance created it a month or so back. But, yea, it seems pretty quiet in there.
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !networking@lemmyonline.com
Funnily enough, Sync seems to load communities from URLs on my local instance just fine. I suppose features like that are the best part of using a well-built third-party app.
Facts
Hard disagree. I use arch btw
๐๐๐ arch btw ๐คค๐คค๐คค I use arch btw ๐ฅบ๐ฅบ๐ฅบ you ๐ซต๐ซต๐ซต๐ซต๐ซต๐ซต๐ซต should use arch too btw ๐โค๏ธ I used to be a filthy ๐คฎ windows ๐คฎ user ๐คฎ but now I use arch!!! ๐คค๐คค donโt be afraid of the install process, youโre just a dumbass normie ๐ค๐ค๐ค๐ค
i feel you bro. people in here talking shit like they donโt know that some net devices are literally made for webgui first and foremost, and programmatic changes donโt work for every api even if it says itโs supported (fucking looking at brocade).
if youโre used to cisco cli, shit like juniper or palo alto or f5 can be intimidating when looking at the configs.
but i swear to fucking god if you use gui instead of cli for cisco, we gon have words.
Cisco and Juniper CLIs are terrible imo.. Why won't they just use a proper modern set of tools instead of their own proprietary shit that doesn't interface with anything else?
because cisco fears change and doesnt innovate technologies so much as acquire other companiesโ tech and frankenstein it into their portfolio.
Had to get some metrics out of an old Cisco box that weren't available through SNMP, and the only solution I could come up with was to periodically SSH some commands and regex the results.
That required way too much shell-foo and the SSH daemon would just randomly refuse/drop connections.
If only there was some kind of standard metric API that every other modern software supports out of the box...
To be fair. In Star Trek they're not really using a GUI like we use a GUI today. They are using a high level AI to take voice commands. And they use the visuals to confirm. That is not what gooies are today
Use a computer in whatever way you want and/or need to best get the job done. It's a tool for accomplishing tasks. The amount of random gatekeeping for no goddamn reason in tech/programming/FLOSS is ridiculous.
See: Cisco. At least when I last used it, the web server configuration utility added a lot of garbage to your running config that made it unreadable if you swapped back to the cli.
Systems that built the GUI first aren't too bad. Palo Alto UI is pretty decent.
I don't know how fair it is to use Cisco as an example for a GUI.
I often prefer GUI/TUI, but I always like a good CLI. It makes automating things so much easier
In my experience, CLIs are easier to design but harder to design well. Because of that, when I find a good CLI tool it runs as smooth as silk, but I would easily take a decent GUI over a shitty or rushed CLI.
It's a different interface for the same thing. Each one has its advantages and disadvantages depending on the job. You should definitely try the CLI if you're into programming or administration
The CLI is like magic words, and a GUI is like Dr. Strange magic with your hands waving around.
All the good GUIs have a license fee.
What is this thing you call โgood guiโ?
It's what you put on bad software to make it palatable.
Like a sugar coating. It's why no one codes in Java anymore without 80 terabytes of ram for their IDE.
I wonder what's this "good software" (you meant language?) that doesn't require an IDE to code efficiently.
Good luck ever doing anything embedded if you always need a clunky IDE. Best thing I ever did was get comfortable in a solely vim/cmake/gcc environment. Even if the majority of work doesn't require it, it'll teach you a lot.
I mean, we're rewriting everything in Rust, so there's no need to learn cmake anymore /s
To conter your comment a little bit, I think anyone doing coding for a living should absolutely use an editor that supports LSPs. They're an insanely helpful tool with zero downsides.
I disagree somewhat with their take, but there's definitely languages that cmoe with features built-in that reduce the need for a fancy IDE.
For example, instead of null checks via annotations that the IDE has to parse and warn about, just have nullable types. Or instead of IDE features to generate a bunch of boilerplate, just don't require that boilerplate.
That being said, on the other side of the spectrum, anyone writing code without using an LSP is just throwing away productivity by the handfull.
Using a TUI however makes you an absolute beast mode rockstar engineer
True
CLIs are much more comfortable to use.
And can be automated easily.
And it takes less time to do stuff.
When I see an IT professional who can't use the CLI, I assume they're lazy IT professionals.
To me, your choice of worlstation OS says a lot more about your priorities.
Mine is Ubuntu. What it says is "I installed it years ago because it was the one I knew most about but now very much regret doing so."
At some point I'll have time and switch. Maybe go with Mint or Debian. There's way too many things that randomly break and it's become rather laggy over time.
Honestly, portainer makes my life so easy
Right? I'm fully capable of using docker compose. But portainer adds an easy and useful admin layer to it.
What specifically does portainer add?
Pretty buttons and the ability to scroll and see all my configs in one window with a single click
Pretty buttons
Umm okay. Personal preference.
the ability to scroll and see all my configs in one window with a single click
Isn't scrolling a single docker-compose.yml easier to see everything? I mean, if you want to change anything - you just edit and re-run command.
Isn't scrolling a single docker-compose.yml easier to see everything? I mean, if you want to change anything - you just edit and re-run command.
Personal preference. I prefer a gui for some things. I also prefer to not put all my containers in one monolithic config. It can also automate using configs in GitHub which is nice.
It also provides a nice dashboard of container health across multiple hosts and makes it easy to manage those hosts from a "single pane of glass".
But, personal preference.
I ran a kvm host manually for years. Years. I recently started over with proxmox because it could be exhausting and this is easier.
Click something and you're there (e.g. viewing logs of a container). You don't have to remember docker commands to do simple and quick operations.
luci ui on openwrt is so good
I use the UI for some stuff and then the CLI for other stuff.
I like using IDE's for code as they can annotate the code and other smart stuff (I know vi can do something similar)
CLI is great for bash oneliners and combing through logs or text files.
Yes, i also prefer GUI.
Using the CLI lets you automate things a lot easier, which makes you a better engineer.
I'd argue that if you only know how to start your own project using the play button, then you aren't a software engineer.
I've written a pretty big application for my employer in visual studio. Never once have I run a "dotnet build" command. Only ever used the little play button. Guess I'm no software engineer
The real software engineers are those who can 2 minute Google "how to build with cli" their Hello world console app.
But you knew about dotnet build
Tbf, I looked it up on Google. I know you can do everything you can with Visual Studio also in the CLI, but never bothered checking out the specific commands. 2 second search on Google returned donet build.
A software engineer isn't defined by what commands he knows or what functions he can remember off the top of his head or what languages he used to write hello world. Those are easily Googlable things that have little to no value irl. The ability to actually solve a problem or build an architecture, a system, even if only in pseudocode is much much more valuable than knowing any specific command.
Case in point, I routinely Google stuff I already used or self reference previous code I've written cause I can't remember how I did certain things. Nothing wrong with that.
There's no shame in being a play-button corporate programmer who's in it only for the money! In fact, most employers prefer this kind of people.
Knowing how to do something in the CLI and choosing to use the gui is different than only being able to use the gui.
I don't. Looked it up on Google, not that hard. I also never use git from the terminal, I know I could, but I don't and if you were to ask me off the top of my head how to use it from the cli, I probably wouldn't be able. Not because I can't use git, I just can't be bothered to remember all the commands when a gui is available and does the exact same thing I needed to do anyway. If and when I'll need to use the terminal for git, I'll check the docs for the exact syntax.
Again, knowing the exact syntax it's not what defines a software engineer, IMO.
Then yes, you are not a software engineer. You used programming to solve one problem one time and you didn't understand what was happening under the hood. Building one deck does not make you a carpenter. Writing one app does not make you a software engineer.
Yeah... that's literally my job... but keep on gatekeeping, don't let my existence stop you.
The point isn't whether you use the GUI. The point is whether you are capable of doing your job without it. I'm not going to throw shade but personally I hate being at someone else's mercy - such as when the GUI breaks and I am forced to wait for someone else to fix it. One reason I stay away from the JavaScript browser/electron ecosystem is because there are so many opaque, inscrutable tools (namely bundlers and module resolvers) and I have no freaking clue how they work under the hood and they're virtually impossible to debug.
Sounds like someone has DNACenter with fully deployed ISE and SDN fabric. I'm honestly a little jealous.
I prefer CLI for many applications, because GUIs have become more difficult and overwhelming to use.
I prefiere using tools like ansible or terraform, but I write the code for it in a GUI from jet brains. Then I deploy from CI, using git from the command line.
Excellent
I have charybdis keyboard with built in trackball, I have hotkey on all my apps, also I don't have to move my hands to use mouse trackball. I mostly use hotkeys in ui apps, I like good ui apps like git fork to view complex repositories, I run circles around cli guys who live in cli (cli is just one off apps for me) when we collaborate or when I drive or teach ppl. Where are some who really good at vim, temux and even tilling vm. I know how they work, I can do things faster in many cases. Eventually it's all about what u like and what works for u, stop comparing workflows, there is always prons and cons to anything, it's not black and white.
GUI requires much more software engineering and development hours than a CLI to create. So yes it makes your a worse engineer; don't wait for someone to expose a feature to you via API and web interface if you can get there via CLI today. Cripes.
I absolutely love using git on the command line. I'm comfortable with the commands, and there isn't much need for clicking since a lot of it is just typing commands, viewing files/diffs, repeat until files are staged, committed, and pushed up. Who needs a GUI for that?
OTOH, I really like postman for constructing and templating network requests. There are a few helpful panes and forms that just fit better on one screen that I can interact with.
To say working with GUIs makes someone a worse engineer sounds very short sighted to me. IMO the best engineers are the ones who use tools that maximize their efficiency.
Postman is literally the only GUI I use for development, except for a browser I guess. Everything else is in terminals/WSL2 at work
You should give a git GUI a whirl. I like Fork. I definitely made do for years with the command line, but there were things like browsing all the diffed files between 2 commits that feel like inherently visual tasks to me, and the GUI makes that so much more natural.
Who needs a GUI for that?
I do. It takes less time and is less error-prone to commit code, especially when you need partial staging, via a decent GUI.
If you're using a GUI, that means whatever you're doing you're not doing a lot of it, since you don't need to automate it. I would expect a world-class enterprise engineer to be able to automate most tasks, and from that they would be very comfortable with the command line.
Can you do everything with a GUI that you can on a command line? Yeah probably, if the developer is at all the features properly. Can you automate it easily? No not at all. So the more you do something the more you tend to want to deal with the vocabulary of the command line because it's more expressive and allows for automation.
I will die on this hill!
Documentation too. Frontends change all the time, but CLI tools usually don't, so you can usually rely on old documentation. But have you ever tried googling how to do something in MS office, found and article from half a year ago and found that none of the things it mentions exist anymore? It's ridiculous how much time people waste trying to figure out stuff multiple times because it changes so much.
After long periods of not using GUIs, I found myself very confused every time I want to do something. I was trying to insert a code block into Power Point yesterday, took me half an hour of googling and didn't manage to do it. With Latex, I googled and in 2 minutes I had a code block.
Given that Latex is a clusterfuck of legacy, it speaks volumes that it's still so much easier to do things there rather than in powerpoint.
With MS office I've also adopted a "fuck it, I'll just take a screenshot" approach.
A collection of screenshots send around by mail after having poorly drawn arrows and frames in it, is official documentation. Source: my corporation
Yup, I tried doing it properly too when I started and now I don't give a shit. If the company wants us to use crappy tools, that's what they get.
What are you saying? The project is finished, the new stuff implemented and now you want to buy some fancy software and shedule 100 hours for documentation? We dont need that! Just help out your colleagues, when they have a question. They'll all know what to do in no time!
Depends on what system youโre running, and especially what task youโre doing. Trying to operate firewall rules via CLI is an exercise in self-inflicted pain, as is trying to set a complex cron schedule without a handy calculator.
on the contrary, CLI is the BEST way to deal with firewall rules.
Personally, I'd take it a step further. Firewall rules should be defined as code in a git repo. So if you're building rules in a gui, you're simply doing it wrong. While a cli and/or api should be used, that should be automated and invisible to a human.
TIL there are people configuring firewalls via GUIs. Okay โฆ Iโm do that too on my private equipment because Iโm lazy. But it feels wrong doing so in an enterprise context.
You using a Cisco firewall or something?
Iโve been using F5 in the past. Not doing that anymore though.
Junos CLI is a real treat. I work with the SRX line regularly, particularly the SRX4600 and the SRX300 series.
CLI debuggers can't hold a candle to the Visual Studio debugger. This is generally not something you automate, and I haven't met many engineers that know
gdbwell. But pretty much anyone can use VS debugger.Honestly, some things can be done faster/as fast on GUI. So really just use whatever increases your productivity.
IMO GUIs are always faster when it's something you've never used before, or use very infrequently.
CLI is better if you're used to the task you're doing, or automating things. But for infrequent tasks looking up the commands (or looking at old notes to find it) is very slow and rather annoying.
Moving files across several subfolder levels tends to be much faster on a GUI. Finding files is usually much faster via CLI, even when you have to look up again how to use the find command of your choice
The more you use the commands the more you remember them. I got good at the CLI by forcing myself to use it for things I would normally do in a GUI. Now everyone thinks Iโm a wizard which I wonโt discourage
Is there an instant GUI find tool on linux?
findis very slow compared to using Everything on windows, and sorting results is really hard via CLI.Oh, you're not aware of "locate"
I am but searching via CLI I'm not sure how to easily sort by last modified time, or restrict to a specific root path first.
I don't know about GUI tools, but:
Everything is so fast because it uses the index built into NTFS to find files by filename quickly, and NTFS is the definitive file system on Windows so it works everywhere.
On Linux, there isn't really an index built into the filesystem - some might have that, but I don't know about it. That said, plocate is a common tool that uses its own index. You have to update the database when files change (you'll probably have a job doing that daily), but searching the index is very fast.
locate
I usually just make a bat or py script to move and create specific files to specific folders.
I only do this because I'm lazy and numbering, renaming and creating folders is a drag and can be easily automated, but just copy/paste or cut/paste is faster in GUI, especially with alt tab and the new tab file system on windows.
A GUI with a search function is always the best way to deal with filesystems, in my experience.
Always orders of magnitude slower and near-infinitely less featureful, in my experience.
Your filesystem must be monstrously huge if it's actually perceptibly slow. I also get tired of typing in long filenames with a ton of special characters I have to escape.
You've never had to search through hundreds of gigabytes of source files, I guess. Congratulations.
No, I've never had that displeasure, Nothing I've worked on has been that big. My condolences.
Pshaw! CLI and GUI? Real network engineers make hand crafted API calls!
https://xkcd.com/378/
I love xkcd ๐คฃ
You gotta admit, it's fun to meme the opposite camp. Whether you are a GUI or CLI person.
But you look way cooler when using the terminal for most of your stuff ๐โโ๏ธ also using a riced out window manager and riced out Vim config for which you spent hundreds of hours on customizing every aspect of it :p normal people don't know what the fuck is going on on your pc so you can feel instantly feel superior to those normies! Ah also btw i use arch ;)
I use both. I use the CLI for a lot of stuff but I also use the GitHub Desktop fork for Linux lol. I don't care how powerful git is in CLI, that gui is just so nice imo
It took me forever to realize I could edit config files in a graphical text editor. When you have a really long file it's just nicer to have properly formated text wrapping and a scrollbar with a preview box.
Exactly. Use the tools you have the way they fit you best. If it aids your work flow learn the CLI commands you use the most. If it's something obscure or rarely used, use the gui.
Another not mentioned benefit of becoming comfortable with using the cli is that you then can more easily script stuff.
To get annoyingly serious on a funny post, the one huge danger of GUIs that I've personally witnessed in many of my juniors is that they abstract away the need to understand the tool you're using.
I regularly use a Git GUI, and I might have to google the rebase command for more complex tasks, but I know how Git works. I know what I can do with rebase, even if I don't exactly know how to. If you only live in the GUI, you can get far never understanding the system. Until one day, when you fuck up a commit or a push, and you're totally hosed because there isn't a pretty button with the exact feature you want in your GUI.
Somehow I've made it 7 years without messing up a git command that I couldn't fix in like 2 seconds. I primarily use vscode's source controller more featured source controllers like sourcetree feel overly complex and typing out git commands is fine but you spend more time doing that than you would with vscode's approach. I'm really curious about what you mean by fuck up a commit or push
Try reverting a reverted commit (revert of revert, yes) while other team members are working on a branch which has the first revert. It's super fun merging after that.
(Or something of that effect, can't remember the exact details of that fuckup)
I don't think I will, mostly cause I work on a team of 1 right now which makes my branches wonderfully simple.
Yeah, fuck that. It's perfectly fine to build a GUI that makes things a bit easier, but make the GUI so that it resembles the fucking workflow. I hate that when I want to automate something thats super easy in the GUI and it takes AGES because there is no equivalent to what I'm doing in the GUI
glares angrily at Azure CLI
Azure CLI and AzPowershell are somehow so powerful and useful until they fall flat on their face.
So... my only requirement for my tools is that they have a well-supported CLI, and can be installed headless without graphical dependencies. Tools must be scriptable.
That said, it's nice to have a UI. My ideal configuration is a scriptable tool with a good API, and a separate GUI tool that can drive it.
One of the best tools I've used is SuperSlicer. It's a slicer for 3D printers. It has GUI, it has CLI and it has a DLL/SO so you can add its features to your own application. And it's open source if linking against an existing library is too hard for you, lol.
It has taken me a long time to get comfortable using a Linux CLI (definitely not as familiar with windows cmd prompt/powershell), and I know that if I log into a box anywhere, If it has
shorbashor some variant of those shells, I'll be able to get by.Now, on my home server, moving & renaming a bunch of media files has me really wishing I had a DE installed there to Ctrl + click/Drag-n-drop...
Also, I love using VScodium/Code as an IDE bc of its configurability & rich plugin ecosystem -- but recently I had some performance hiccups with extensions not playing nice together and started (again) down the masochistic path of configuring neovim to use as an "IDE"...
Why not mount your server as a share and use your desktop GUI to manipulate files? Then you can do both.
Laziness so far haha but yes that's a good plan
I always feel that graphical interfaces make easy things difficult, in most cases. A bunch of figity clicking around, instead of a few keystrokes I could press with my eyes closed. They are more discoverable, though.
If you use emacs, dired and wdired together are fantastic for managing files like that. You can even run dired over tramp, so you can manage files on a remote server that doesn't have emacs installed, using the emacs on your desktop. But there are also good cli options, you might want to look at the rename command, as one that's probably installed by default on any given distro. That's outside my expertise, though, as I just use emacs.
Yes I've used rename! In my case, I just need to rename and reorganize a bunch of movies & associated metadata files into directories. I don't have too many stored digitally now, so I think just shaving the yak and doing it manually via file share will work for now.
Never been an emacs user... Seems like quite a rabbit hole
Skip the masochism, try helix. Switched to that + zellij with about 20 lines of config and never looked back
Takes a second to get used to the keybindings but after about ~2w you can painlessly switch back and forth between vim and helix pretty much instantly
Helix + zellij huh? I'll definitely try it out
Feel free to ping me if I can help, at least in the form of starter configs/small hacks that emulate VS Code workflows or something :)
Personally I was the guy that had thousands of lines of Vim and Emacs configurations, so I really had to do this to manage the time sink (like you I had a stint with VS Code in between that eventually stopped working for me)
Yeah, keep telling yourself that buddy.
So far I don't think anyone has interpreted the meme correctly, the wikiHow guy is supposed to be an obvious shortcoming expressed as a guy trying to convince himself it's not a problem.
Using the right tool for the right task is a big part of being a good engineer.
thank you.
I think I really only use GUIs if I am learning something new and trying to understand the process/concepts or if I'm doing something I know is too small to automate. Generally once I understand a problem/tool at a deeper level, GUIs start to feel restrictive.
Notable exceptions are mostly focused around observability (Grafana, new relic, DataDog, etc) or just in github. I've used gh-dash before but the web ui is just more practical for day to day use.
For context, I'm in SRE. I feel like +90% of my day is spent in kubernetes, terraform, or ci/cd pipelines. My coworkers tend to use Lens but I'm almost exclusively in kubectl or the occasional k9s.
Searching a log file? I want
less. Searching all log files? I want log aggregation lol.Exactly.
One log file, or all, I want grep or awk, maybe with find in front, possibly throw some jq on top if something is logging big json blobs.
That's a lot slower at scale than something like Loki.
I feel you. The problem with a lot of Elastic style document search engines is that they don't ever let you search by very explicit terms because of how the index is built. I believe the pros outweigh the cons but I often wish I could "drop into" grep, less, and others from within the log aggregation tool.
If I knew what I was looking for I could grep all the log files and pipe the output to another file to aggregate them.
The problem is that they're all on different servers. Once you use log aggregation stuff like DataDog, Splunk, or Kibana you get it, but before it's hard to see the benefits. Stuff like being able to see a timestamp of when an error first appeared and then from the same place see what other stuff happened around the same time.
If I had dozens or hundreds of servers that would make a huge difference, but for under a dozen I think the cost of setting that all up isn't worth the added benefit. Plus if the log aggregation goes down (which I've seen happen with some really hairy issues) you're back to grepping files so it's good to know how.
Totally. I'm talking more from the enterprise perspective. Even apart from that I'm not sure if the cost is worth it at that scale. Even using foss solutions the dev hours setting it up might not be worth it.
Github's UI is total garbage compared to basic git commands, though.
You can't manage pull requests, github actions, repo collaborators, permissions, or any number of the dozens of other things github does just from basic git commands.
Someone told me that windows server UI interface has more options than CLI. I got scared of windows server (how do you repeatedly Setup the same server, with a screenshot documentation ???)
It's been a while since I've found that true. You can do everything you want to do in powershell now days.
Yeah, I think MS started adding PowerShell for everything after server 2012 R2.
First of all, most Windows settings are in the registry, so you don't have to go to the UI, you can just upload new settings straight into the registry through CLI.
Second, PowerShell exists and it's awesome!
And third, you can always use UI automation tools if you're bad at registry and PowerShell. Just record your session and run whenever needed.
Newer versions of Windows can give you the exact Powershell code it's executing based on what you've configured in the gui. This is still extremely inconsistent across Windows services though. I don't know that I'd feel comfortable running a headless windows server yet. Too much stuff still assumes you'll use the gui for most things.
To be honest, if you really need Windows servers you should run core if possible. Basically all Microsoft's management shit can be run remotely from your jump/management host. That said a lot of shit requires gui and refuses to run on core, like adsync
Is there a significant performance difference? I'm assuming the attack surface is lower.
There's slight difference in resource usage of course, which does scale if you're unlucky enough to have lot of them.
Minimum ram required is 512mb for core, 2gb for desktop experience so we can safely assume keeping the gui usable eats some 1.5gb memory. 500 servers adds some 750gb overhead in theory.
Then there's of course the fact that less bloat will generally add up to less problems. Ever rdp to a server and start menu refuses to open or other weird gui shit. That's just wasting your time.
PSA: Since his finger and the reflection touches, he's likely looking into a one way mirror. There's someone behind the glass.
I just walked around my house touching all my mirrors and they all do this. Hope they're not on to me now... Think I'll wait for night and try to make a break for it.
Or it's an extremely thin glass.
Or just a reflective surface.
Or his name is Truman Burbank
it makes you a Windows engineer which is worse
"Windows engineer' lmao.
Well, there technically are communities for enterprise engineering.... they just, aren't very active.
Exactly. Posting to a community of a dozen people who don't engage on content seems like a pointless endeavor.
Like enterprise networking?
https://lemmyonline.com/c/networking
Well, some fellow over here on my instance created it a month or so back. But, yea, it seems pretty quiet in there.
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !networking@lemmyonline.com
Funnily enough, Sync seems to load communities from URLs on my local instance just fine. I suppose features like that are the best part of using a well-built third-party app.
Facts
Hard disagree. I use arch btw
๐๐๐ arch btw ๐คค๐คค๐คค I use arch btw ๐ฅบ๐ฅบ๐ฅบ you ๐ซต๐ซต๐ซต๐ซต๐ซต๐ซต๐ซต should use arch too btw ๐โค๏ธ I used to be a filthy ๐คฎ windows ๐คฎ user ๐คฎ but now I use arch!!! ๐คค๐คค donโt be afraid of the install process, youโre just a dumbass normie ๐ค๐ค๐ค๐ค
This but unironically
No, thank you, I'll be staying on Gentoo tyvm
Is this your first attempt at emoji pasta?
i feel you bro. people in here talking shit like they donโt know that some net devices are literally made for webgui first and foremost, and programmatic changes donโt work for every api even if it says itโs supported (fucking looking at brocade).
if youโre used to cisco cli, shit like juniper or palo alto or f5 can be intimidating when looking at the configs.
but i swear to fucking god if you use gui instead of cli for cisco, we gon have words.
Cisco and Juniper CLIs are terrible imo.. Why won't they just use a proper modern set of tools instead of their own proprietary shit that doesn't interface with anything else?
because cisco fears change and doesnt innovate technologies so much as acquire other companiesโ tech and frankenstein it into their portfolio.
Had to get some metrics out of an old Cisco box that weren't available through SNMP, and the only solution I could come up with was to periodically SSH some commands and regex the results.
That required way too much shell-foo and the SSH daemon would just randomly refuse/drop connections.
If only there was some kind of standard metric API that every other modern software supports out of the box...
The keyboard. How quaint.
So much GUI, and never a mouse click. Only the best hackers get a whole new screenfull of GUI for every one of their seemingly random key presses.
https://hackertyper.net never fails to impress.
That is awesome, and now I feel awesome.
To be fair. In Star Trek they're not really using a GUI like we use a GUI today. They are using a high level AI to take voice commands. And they use the visuals to confirm. That is not what gooies are today
And now the timeline is forked.
Here is an alternative Piped link(s): https://piped.video/watch?v=LkqiDu1BQXY&
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source, check me out at GitHub.
Use a computer in whatever way you want and/or need to best get the job done. It's a tool for accomplishing tasks. The amount of random gatekeeping for no goddamn reason in tech/programming/FLOSS is ridiculous.
See: Cisco. At least when I last used it, the web server configuration utility added a lot of garbage to your running config that made it unreadable if you swapped back to the cli.
Systems that built the GUI first aren't too bad. Palo Alto UI is pretty decent.
I don't know how fair it is to use Cisco as an example for a GUI.
I often prefer GUI/TUI, but I always like a good CLI. It makes automating things so much easier
In my experience, CLIs are easier to design but harder to design well. Because of that, when I find a good CLI tool it runs as smooth as silk, but I would easily take a decent GUI over a shitty or rushed CLI.
It's a different interface for the same thing. Each one has its advantages and disadvantages depending on the job. You should definitely try the CLI if you're into programming or administration
The CLI is like magic words, and a GUI is like Dr. Strange magic with your hands waving around.
All the good GUIs have a license fee.
What is this thing you call โgood guiโ?
It's what you put on bad software to make it palatable.
Like a sugar coating. It's why no one codes in Java anymore without 80 terabytes of ram for their IDE.
I wonder what's this "good software" (you meant language?) that doesn't require an IDE to code efficiently.
Good luck ever doing anything embedded if you always need a clunky IDE. Best thing I ever did was get comfortable in a solely vim/cmake/gcc environment. Even if the majority of work doesn't require it, it'll teach you a lot.
I mean, we're rewriting everything in Rust, so there's no need to learn cmake anymore /s
To conter your comment a little bit, I think anyone doing coding for a living should absolutely use an editor that supports LSPs. They're an insanely helpful tool with zero downsides.
I disagree somewhat with their take, but there's definitely languages that cmoe with features built-in that reduce the need for a fancy IDE. For example, instead of null checks via annotations that the IDE has to parse and warn about, just have nullable types. Or instead of IDE features to generate a bunch of boilerplate, just don't require that boilerplate.
That being said, on the other side of the spectrum, anyone writing code without using an LSP is just throwing away productivity by the handfull.
So that's my point. Don't write or use bad software. Then the GUI (bad or good) isn't necessary.
Using a TUI however makes you an absolute beast mode rockstar engineer
True
CLIs are much more comfortable to use.
And can be automated easily.
And it takes less time to do stuff.
When I see an IT professional who can't use the CLI, I assume they're lazy IT professionals.
To me, your choice of worlstation OS says a lot more about your priorities.
Mine is Ubuntu. What it says is "I installed it years ago because it was the one I knew most about but now very much regret doing so."
At some point I'll have time and switch. Maybe go with Mint or Debian. There's way too many things that randomly break and it's become rather laggy over time.
Honestly, portainer makes my life so easy
Right? I'm fully capable of using docker compose. But portainer adds an easy and useful admin layer to it.
What specifically does portainer add?
Pretty buttons and the ability to scroll and see all my configs in one window with a single click
Umm okay. Personal preference.
Isn't scrolling a single
docker-compose.ymleasier to see everything? I mean, if you want to change anything - you just edit and re-run command.Personal preference. I prefer a gui for some things. I also prefer to not put all my containers in one monolithic config. It can also automate using configs in GitHub which is nice.
It also provides a nice dashboard of container health across multiple hosts and makes it easy to manage those hosts from a "single pane of glass".
But, personal preference.
I ran a kvm host manually for years. Years. I recently started over with proxmox because it could be exhausting and this is easier.
Click something and you're there (e.g. viewing logs of a container). You don't have to remember
dockercommands to do simple and quick operations.luci ui on openwrt is so good
I use the UI for some stuff and then the CLI for other stuff.
I like using IDE's for code as they can annotate the code and other smart stuff (I know vi can do something similar)
CLI is great for bash oneliners and combing through logs or text files.
Yes, i also prefer GUI.
Using the CLI lets you automate things a lot easier, which makes you a better engineer.
I'd argue that if you only know how to start your own project using the play button, then you aren't a software engineer.
I've written a pretty big application for my employer in visual studio. Never once have I run a "dotnet build" command. Only ever used the little play button. Guess I'm no software engineer
The real software engineers are those who can 2 minute Google "how to build with cli" their Hello world console app.
But you knew about
dotnet buildTbf, I looked it up on Google. I know you can do everything you can with Visual Studio also in the CLI, but never bothered checking out the specific commands. 2 second search on Google returned
donet build.A software engineer isn't defined by what commands he knows or what functions he can remember off the top of his head or what languages he used to write hello world. Those are easily Googlable things that have little to no value irl. The ability to actually solve a problem or build an architecture, a system, even if only in pseudocode is much much more valuable than knowing any specific command.
Case in point, I routinely Google stuff I already used or self reference previous code I've written cause I can't remember how I did certain things. Nothing wrong with that.
There's no shame in being a play-button corporate programmer who's in it only for the money! In fact, most employers prefer this kind of people.
Knowing how to do something in the CLI and choosing to use the gui is different than only being able to use the gui.
I don't. Looked it up on Google, not that hard. I also never use git from the terminal, I know I could, but I don't and if you were to ask me off the top of my head how to use it from the cli, I probably wouldn't be able. Not because I can't use git, I just can't be bothered to remember all the commands when a gui is available and does the exact same thing I needed to do anyway. If and when I'll need to use the terminal for git, I'll check the docs for the exact syntax.
Again, knowing the exact syntax it's not what defines a software engineer, IMO.
Then yes, you are not a software engineer. You used programming to solve one problem one time and you didn't understand what was happening under the hood. Building one deck does not make you a carpenter. Writing one app does not make you a software engineer.
Yeah... that's literally my job... but keep on gatekeeping, don't let my existence stop you.
The point isn't whether you use the GUI. The point is whether you are capable of doing your job without it. I'm not going to throw shade but personally I hate being at someone else's mercy - such as when the GUI breaks and I am forced to wait for someone else to fix it. One reason I stay away from the JavaScript browser/electron ecosystem is because there are so many opaque, inscrutable tools (namely bundlers and module resolvers) and I have no freaking clue how they work under the hood and they're virtually impossible to debug.
Sounds like someone has DNACenter with fully deployed ISE and SDN fabric. I'm honestly a little jealous.
I prefer CLI for many applications, because GUIs have become more difficult and overwhelming to use.
I prefiere using tools like ansible or terraform, but I write the code for it in a GUI from jet brains. Then I deploy from CI, using git from the command line.
Excellent
I have charybdis keyboard with built in trackball, I have hotkey on all my apps, also I don't have to move my hands to use mouse trackball. I mostly use hotkeys in ui apps, I like good ui apps like git fork to view complex repositories, I run circles around cli guys who live in cli (cli is just one off apps for me) when we collaborate or when I drive or teach ppl. Where are some who really good at vim, temux and even tilling vm. I know how they work, I can do things faster in many cases. Eventually it's all about what u like and what works for u, stop comparing workflows, there is always prons and cons to anything, it's not black and white.
GUI requires much more software engineering and development hours than a CLI to create. So yes it makes your a worse engineer; don't wait for someone to expose a feature to you via API and web interface if you can get there via CLI today. Cripes.
I absolutely love using git on the command line. I'm comfortable with the commands, and there isn't much need for clicking since a lot of it is just typing commands, viewing files/diffs, repeat until files are staged, committed, and pushed up. Who needs a GUI for that?
OTOH, I really like postman for constructing and templating network requests. There are a few helpful panes and forms that just fit better on one screen that I can interact with.
To say working with GUIs makes someone a worse engineer sounds very short sighted to me. IMO the best engineers are the ones who use tools that maximize their efficiency.
Postman is literally the only GUI I use for development, except for a browser I guess. Everything else is in terminals/WSL2 at work
You should give a git GUI a whirl. I like Fork. I definitely made do for years with the command line, but there were things like browsing all the diffed files between 2 commits that feel like inherently visual tasks to me, and the GUI makes that so much more natural.
I do. It takes less time and is less error-prone to commit code, especially when you need partial staging, via a decent GUI.
It totally does. GUI is for weaklings.