My Take on Linux - Will it Ever Beat Windows?

English Soapbox
#21

To be fair, there are some markings of a troll. A troll rarely sees himself as a troll. A troll thinks himself an expert. And a troll is often argumentative and condescending in tone.

Now arguing in and of itself may not be bad as that is how to debate. However, a debate is an exchange of ideas and information, often for the purpose of sueding the other party to your side.

So let’s examine your arguments. You complain and say Linux will never make it. First off, you should never make a prediction unless you have foreknowledge. You reference your threads about asking for help, yest you talk about SAP. SAP is a business application for corporations at an IT level. This would suggest you might have IT experience. IT experience can actually work against you in Linux. You have to unlearn all the Windows habits.

As to the commands, SO WHAT. So there are over 4000 commands on my system, and each command has several switches. Which means i have somewhere in the neighborhood of around over a million possible command variations. Yeah, so what! I can do most of them via the GUI. That’s right.

Now if you really want to help Linux, why not change your attitude, file bug reports, instead of what you have demonstrated here. If your not a troll, you’ll heed my advise. If you are a troll, you’ll ignore my advise. Your call.

#22

The second sentence I understand, but stating that “all” the Windows habits, may be OTT. Surely they got a few things right? The first sentence leads me to think that the OP has a point. If IT experience works against Linux, then it has a much bigger mountain to climb with IT departments than stated by the OP

If it is a pain for the IT staff to maintain then it will not be adopted.

If your not a troll, you’ll heed my advise. If you are a troll, you’ll ignore my advise.
Your preceding advice made sense, but this one smacks of “You’re either with us; or you’re against us.” by one G. Bush, IIRC. I don’t subscribe to that here.

Trolls don’t usually make these statements:

    1. Spectacular product
  • Install was far better than previous versions
  • this release (11.1) is certainly a huge advance
  • Great product

Whether one agrees or disagrees, IMO the OP’s comments were given in the spirit of feedback, and some very good points were made in various responses from other contributions. :slight_smile:

#23

And which are these “common” things? How do you decide what is common or not for an individual and its specific work situation? One user may just need audio and/or video processing command line tools while another one may be totally uninterested in these and may need totally different tools. Again, you’re not thinking when speaking. The utilities that can scratch the surface and can be labeled as common are all present in the standard GNU set packages, eg coreutils, findutils, binutils & co and every system has them. These packages include commands such as cp, rm, mv, cat, find, etc and are needed on every Linux system, regardless if the user will need them or not as the core of the system depends on them, such as boot init scripts that are responsible for starting up your services or do regular background tasks through cron jobs. In the end, it is your own ignorance that makes problems, not the commands

From what I heard so far from you, you have absolutely no clue how UNIX-like operating systems work and why they dominate the upper end of computing (hint: there’s a very good reason for this). What I can suggest is for you to get a good book about UNIX or Linux internals/philosophy and workings, read it and understand how and why this platform is as it is. Windows is not the only way of controlling a computer and there are many different ones, arguably much better ones too. As with every platform switch, there’s always learning involved. If you’re not prepared to do this, then don’t switch over. No one forces you to do so. If UNIX/Linux looked and behaved exactly as Windows does, what is the point of having them around? This is a very common mistake people make and you did it too. They switch over to an entirely different platform and then expect it to look & behave as their previous one. If it doesn’t, they either run away from it without at least trying to understand things, or, they try to tell us or the people who invented it how it should be done. The funny thing in this last part is that they base their arguments and thinking on what they have known in the past and have worked with, without knowing the new platform they’re on or being accustomed to in order to do a fair comparison

#24

For my own personal use…Linux has already beat Windows. And that is all that matters to me.:wink:

#25

Well overall most of the linux commands have GUI’s just not all of them.
To be fair though Linux is new to GUI in comparison to Windows, Windows has been GUI oriented since its beginnings in 93.
Linux on the other hand never really had a true GUI till 1997 or so, KDE is 10 years old now and it was one of the first major desktop environments for linux.
Window managers are older but none really were as “windows like” as KDE first was.
Although I think FVWM was around back then too, I sort of forget the history of most of the linux GUI’s.
Still Linux is young too, Windows was based on DOS and DOS is quite old.
Linux is more or less based on Minix, and I think Minix came out in 1989 or something like that.

#26

Not really true :wink:

Does grep have a GUI? cat? mv? cp? tr? find? head? tail? more? less? ln? ls? …

No they don’t, and there are far more I didn’t mention above. However, you can consider GUIs which use these commands underneath to accomplish a specific task as being a GUI to said commands, but that GUI is not a native one for the command line utilities. These utilities certainly don’t need a GUI while the GUI that uses them certainly needs them :slight_smile:

I still fail to picture how a GUI of ‘cp’ will look like and how useful it’ll be. cp is a utility to copy files/dirs from one place to another. Since desktop environments have native C implementations to do such things, writing a GUI for ‘cp’ will be redundant and useless. This however does not make ‘cp’ on itself useless since if you do not need GUI, ‘cp’ is the one you can rely upon to copy stuff over, especially on places that don’t need a GUI like servers

To be fair though Linux is new to GUI in comparison to Windows, Windows has been GUI oriented since its beginnings in 93.
Linux on the other hand never really had a true GUI till 1997 or so, KDE is 10 years old now and it was one of the first major desktop environments for linux.
Window managers are older but none really were as “windows like” as KDE first was.
Although I think FVWM was around back then too, I sort of forget the history of most of the linux GUI’s.

There were things like CDE (and a few more), which also ran on Linux, that predates the now standard KDE/GNOME/XFCE environments and was used a lot before these replaced it mostly

Still Linux is young too, Windows was based on DOS and DOS is quite old.
Linux is more or less based on Minix, and I think Minix came out in 1989 or something like that.

Not so young really, Linux became public in 1991, which is 18 years ago. The issue here is that even though Linux was developed by Linus as a personal project for his studies and he focused only on the desktop as that’s what mattered to him at that time, when he released it to the public, it shifted interest towards servers and higher ends and desktop development sort of started to lag behind. Only in recent years did the desktop part jumped up and one reason is because Linux has achieved maturity on the server/high-end and thus needed much more improvements on the desktop side as this is one of the goals for Linux. Support everything from bottom up to top, which translates to: support everything (or run on everything) from embedded, desktop, industrial, up to high-end servers and mainframes.

As for Minix, not entirely true either. Yes, Minix had an influence on Linux and that’s why Linus started to develop it as Minix was proprietary and not available for your basement pleasures and mad scientist experiments. Linus did Linux development on Minix and ported some of the utils over to it which later on got entirely replaced by the GNU toolkit and utilities. But, Linux and Minix are entirely different implementations of UNIX-like systems. Minix is a microkernel while Linux is a monolith and there have been various flames over the years between Torvalds and Tanenbaum about which one is better and more efficient. Even till this day, they still on and off argue about this

#27

You completely misunderstand. I don’t care whether he is with us or not. The OS he chooses to use is entirely up to him. I simply advised him of the proper way to provide feedback. Doing it on the forum wont get back to the devs.

#28

Though I believe the original posters intent is to promote discord (especially since he did not address the replies he had got but focused on finding “Troll” references), I felt a comment was in order here.

Microchips knowledge is lightyears beyond mine in the Linux area, That said; most of what he posted as commands can be done in the Gui environment of a File manager. cp (copy) is relatively easy in a file manager as well as mv (move) ln (link) and many others. Those used to command line rarely bother with the overhead of having the file manager open. However it does not need to be command line. I tend to prefer the Graphic environment for some of these things.

Now in a Linux Forum most people who provide assistance respond with the command line method. I notice this big time recently with the zypper method of Software Management. I tend to think this is a mistake in some cases. It can tend to convince people the only way to use openSUSE is via a command line. I understand the ease for those that are proficient but it is a negative to others. There are excellent gui’s for all this stuff that do not get the development needed when people ignore using them.

Heres a challenge to all the command line honchos. Try the Gui method for everything you need to do for a while. If the gui is insufficient to the task, provide feedback to help make it better.

#29

It’s not really a question if you can do it with the GUI too. The question is how easy and efficiently it can be done. Consider this:

I want to see the exact contents of, say, /etc/fstab. This can be done both with a GUI and a command line utility. With the GUI, you need to open the file manager, navigate to /etc, scroll through the file list and search for it (there are many files/dirs in /etc), click on fstab and then it opens in a text editor. Or you can directly open a text editor and then click on “Open file” in it, again go to /etc, scroll through the list and locate and open the file

With a command line utility, this is what needs to be done: open a terminal and do ‘cat /etc/fstab’ and in a blink of the eye you have its contents. This is an order of about 3 steps less, which had to be taken when using a GUI to accomplish the same task

Also, a GUI does not really allow you (or is not really easy to implement it) complex command strings, input/output piping, complex regex and all other sort of things. Often a GUI is just impractical for such things and command line is preferred. F.ex piping data through 4 different programs is really though to do in GUI mode (though not impossible) but far easier in command line mode…

cat /path/to/file | grep somestring | nl | awk ‘{print $1}’

what the above does is read contents from a file, pipe it over to grep and look only for lines containing ‘somestring’, pipe the output of grep to nl which prints a number for each time ‘somestring’ was found then pipe its output over to awk which only reads the first positional thus displaying only the numbers of nl and leaving out ‘somestring’. Try to do this easily with a GUI :wink:

#30

I remember many of the windows vs command line debates, when the early MacIntoshes, and then later MS-Windows-3.0 started becoming popular.

And here we are almost 20 years later, and the debate continues :slight_smile:

My view is they both have their place. In general I find the GUI fans tend to dismiss the terminal/command line as archaic. The terminal/command fans tend to recognize the GUI has its place, but also have a distinct view of the GUI limitations (something I believe the GUI users overlook).

In a perfect world, everyone would make the look/feel of a GUI the same, and navigation would be trivial. But in fact, that is often far from the case. So much so that with many applications in MacIntosh, MS-Windows and indeed X-Windows (KDE, Gnome, xfce, what-ever) it can be very slow and time consuming to navigate the various windows, trying to find some elusive menu setting. In such cases, of the many examples of poorly built gui, it is significantly faster to go to a terminal, type "man < some command > " (assuming one knows the command) and then determine the options to apply. If its a common and repetitive command, the terminal is often much much faster even if the GUI is well known and friendly.

If one is providing help on a forum, it is often faster and less painful for a person providing help, to just state the command, rather than try to explain to a new user how to navigate thru a confusing maze of GUI menu options.

I believe there are some operations where the terminal simply can NOT compete with the GUI. And the reverse is true. There are some operations where the GUI can NOT compete with the terminal.

I also believe to forsake one for the other puts any Operating System at a disadvantage, and the Linux mix of GUI (with X window) and terminal gives Linux a distinct advantage. BUT to understand that advantage, one needs a level of knowledge that new users to Linux do not understand. Indeed experienced MacIntosh users and experienced Windows users who have no vms, no unix, nor any Linux experience, tend to have no grasp of the power of the terminal based commanding, and they IMHO often illustrate their lack of experience by dismissing the terminal as archaic.

I believe they both (GUI and terminal) have their uses in a cutting edge/modern 21st century operating system.

#31

Actually, everything that a GUI can do can command line also do, even complex graphical rendering, programming and computations. There are ray-tracing programming languages and full blown graphical programming languages only available as command line programs often used in scientific environments or industrial environments. The question is, which one of those is easier and more suited for a specific task for the person doing the specific task?. A graphical designer who only knows (or has learned how to) do designes using a GUI program, for him there’s a high chance he’ll prefer a GUI solution. Someone else who has learned how to programm in such graphical design languages, he may prefer a command line over the GUI solution, especially if the task is easier accomplished than within a GUI. It really depends a lot on multiple factors and people themelves. Personally, the combination for me of combining GUI with command line is the most powerful tool around and I use one or the other to accomplish a task. How I decide which one to use is based on my familiarity with both of them and I know for a specific task which one can/will be faster and easier to use.

#32

I agree with you here for the most part. I think that the GUI should just as powerful as the command line. I also think that most users prefer the GUI to the command line. I do think tech support should be provided with the GUI way.

Just that there are so many times when the command line is so much faster and easier.

I think I hybrid of what you propose would be ideal. A GUI approach with command line.

#33

(Donning my Socrates robe and baseball cap)
Not all Gui fans dismiss the Command line as being “archaic” Many consider the command line to have its place but requires memory of obscure commands like what microchip quoted with; grep pipe to awk and sed away. Whereas with a visual environment you can see the relations between some of this stuff. So the extra steps of clicking on the interfaces is nothing because they lead from one to the other. The command line can require looking up the correct command or having more brain cells active than old people like me can manage.

I do agree that use of both makes for a better experience. However I think my observation is true that the many Linux help Forums tend to dismiss the gui way of doing things for the command line. Thus the neophyte can get the impression that Linux is only for those that can grasp the commands. I think that is a unfortunate conclusion when it comes to Linux adoption.

#34

I don’t entirely agree with this viewpoint but also do not entirely dismiss it either. I think it is beneficial to treat command line on equal footstep with the GUI when it comes to Linux/UNIX systems. Why? Because command line sits at the core of UNIX-like operating systems and has been proven many times since its existence to be of huge value, including for people who do 95% of things through the GUI. Suppose X breaks for a person at some point and he has absolutely no knowledge of the underlying command line workings or tools. Conclusion? There’s a high chance he won’t be able to get it up and either will have to completely re-install it or do something else to fix it. Since the GUI is gone for him, the only two options for him (not considering he has friends who can fix it for him) are 1) reinstall or 2) try to use a command line he has no clue about, nor does he knows which commands to use, how to open and write files, etc. If he has a different computer and comes to the forum, chances are that people will give him good advice on how to fix his system through the command line and he gets the benefit of learning something new and getting a bit familiar with the CLI which may rescue him again in the future. However, if he had enough knowledge of the CLI already, fixing this problem that may seem a huge deal to someone only accustomed to a GUI will probably be only a matter of a few minutes (assuming the problem isn’t that big).

In GUI only environments like Windows, if the same thing happens to the graphical systems, what do you get? You get a completely broken system as it’ll BSOD constantly and there’s not even an option to fix it through a command line so you’ll have to look for diagnostic CDs/programs or like most do completely reinstall it or bring it back to the shop for fixing. At least in UNIX-like systems, when the GUI is gone you have something to fall back on and if you even have a minimal knowledge of the CLI, there’s a bigger chance you may fix it than compared to a GUI only system without a CLI. Once the GUI falls down on such systems, those only accustomed to it will be completely hopeless and sometimes even geeks will have no other option but reinstalling the complete OS.

I think it is more beneficial for newcomers to try and accustom them to a bit of command line than just to focus on the GUI side. Someone with lots of CLI knowledge (don’t look at me as I won’t do it :P) should write a wiki or something about how a CLI can be beneficial in various cases, including for accomplishing tasks faster and more efficiently than with a GUI, and point out the limitations of both GUI and CLI and why a specific task given as example can be much easier/take far less time under CLI than under GUI

#35

Dismiss is a harsh word :slight_smile: … My view, as noted above, is it takes extra time to provide text explaining how to navigate to the correct menu item. While often an experienced user can rattle off a command in a fraction of the time it would take to write down the complex menu navigation specifics.

Possibly a feature that might be helpful would be to be able to navigate to a menu, and then by pressing some sort of mouse or key sequence, have the navigation automatically copied to a text file that is also automatically opened, so that one can then simply copy and paste that menu navigation (written in text) to a help thread. Else, for a user who is providing help, but has limited time, making the extra effort to manually type a complex maze of menu selections is for some of us simply too time consuming.

And in some cases, we simply do not know the GUI selection, although its there, but we DO know the command line. So what do we do. Ignore the user’s help request? Waste extensive time trying to find a menu way that we have never used ourselves? or very quickly help them with our command line knowledge (and hence have time to help someone else)?

#36

Dissmiss or dat lady is irrelevant because

Part of knowing Linux should include the GUI selection. Now if you wanted to point fingers and say “I have it on good authority your knowledge of Linux is about that of a slime mold,” I would be forced to concur. However the statement does stand that perhaps when dealing with those needing help to keep the gui approach in mind.

<Off Topic a bit, A pet peeve of mine is to see command line instructions that do not contain all the steps. Someone needs help and the answers is to do a zypper update. “???”, says the person who gets such instructions. Looking down at my zypper it seems to be fully up, (thank goodness) " so what is it I am supposed to do?" Quite often there is not a better instruction of opening a terminal program (either with key combination or going to menu etc.) typing in the code as follows {random code} then hitting the enter or return key. Sometimes the code to enter is missing all the elements and or mistyped. When that occurs the frustration levels mounts for the beginner.>

BTW, excellent arguments of Microchip regarding learning command line basics, it is necessary and needs to be understood. The question just comes in to is where in the learning process that should be. Should the new person be tossed into the deep end of the pool? Or perhaps it would be best for them to start in the shallow end. Being from the shallow end of the gene pool I tend to favor the latter approach first.

#37

No, I certainly did not completely misunderstand you. Originally you said:

Now if you really want to help Linux, why not change your attitude, file bug reports,
My comment referring to that was:
Your preceding advice made sense

It would be difficult to misunderstand that. However you then followed with:

If your not a troll, you’ll heed my advise. If you are a troll, you’ll ignore my advise
My comment about that was:
but this one smacks of “You’re either with us; or you’re against us.” by one G. Bush, IIRC
Why? Your statement has a flavour of the Bush statement, where the options are limited to a binary choice, to avoid any complexity. A sort of “my way or the highway” tactic. If only you had simply advised him as you now claim; and left it there, instead of trying to justify the use of immature name-calling from a previous post.

#38

Actually, those who do very often use solutions or at least informations retrieved from CLI because they have GUI approaches in mind.

Why use the inferior solution and decreasing SNR at the same time?

The people asking for help should keep in mind, that they are the ones who want help, so they should adapt to the methods which are proven to work in any environment.

As far as I am concerned, I am interested in the problem and in its solution and not that xyz has $PROBLEM.

I don’t care if xyz solves his problem or not, I want to solve the problem. If xyz does not give any impression of cooperation, I don’t care, the chances of somebody having the same problem are very good, so maybe she/he will cooperate better.

#39

@Akoellh:
Interesting.

Sounds like the person asking the question takes second place to the method of solving (answering) the question. Not sure this method will attract people to adopting Linux. And if that is not your goal it is perhaps reasonable for you to take that stance. Very few people using Linux would reduce the signal to noise level considerably.

#40

You are getting it wrong, but I did not expect you to understand.

If minimal cooperation is there, those users will get good help and they will learn how to deal with problems when being forced to cooperate and think for themselves, therefore more likely stay with linux, so they will benefit from it.

If a problem is really interesting, one will invest more time, even if cooperation is bad, the community will benefit from a new solution.

Solving the same problem over and over again will not improve anything, having good threads or howtos from threads will improve quality.

Today (I won’t post links) were three or four threads of the same person, no cooperation, no post more than two or three lines written by the OP to clarify his problem, several threads with the exact same solution posted in every thread, the OP just ignored a very good tutorial given to him in one of the first answers.

And some members played along for 5, 6 pages on at least 3 threads running at the same time.

In the same time one could have solved perhaps three or five or more different (sic!) problems with cooperative users.

I give that guy 2 weeks and he will be back to windows for the better of all.

And no, the quality of Linux is not directly related to the amount of users, the day it will start to go into that direction, which for proprietary OSes is the normal one, because every new user is XY$, will be the day linux will start to suck.

Linux is great because developers want to write good programs, mostly solving their “itches” (read ESR on that) and not looking if they get 1, 10 or 1.000.000 users when writing code.