Comment by chomp | Hacker News Reader

Comment by chomp | Hacker News Reader

Parent Full thread

Very heavy headline for a very nuanced position by Linus.

It's an open secret that the ideal of choice fragments the focus of creating a tight UX on the desktop. You have to understand when you watch this video though that all Linus and the kernel team can do is make the kernel itself. The community is what will end up driving the desktop UX, and they haven't done a great job creating something that can capture the average PC user.

I am not sure if this is even a bad thing. My daily driver is a Dell laptop running Fedora and I don't think I'd change a thing aside from some minor UX gripes about Cinnamon. ChromeOS really is the best hope for mass Linux adoption, and I personally know people who hate the Linux desktop experience but use a Chromebook daily.

I'm not sure what I'm trying to say here other than my personal opinion that desktop Linux has found a local maximum and I think only the distros themselves can push DE volunteers to find something that has wider appeal (I'm not sure if that is even desirable, because again, I'm personally very happy with my experience).

> I personally know people who hate the Linux desktop experience but use a Chromebook daily.

Google nailed that UI and everything just works.

Settings are just bundled in with your browser settings, no cli anything to run.

I dream of seeing a web interface all existing Ubuntu apps.

* a google docs Web GUI clone for replace OpenOffice. * all files store locally by default. * Goes to cloud only when users need to share.

* Web base apt, dpkg system. * Web base app for view/manage all system logs, dmesg. * Web base interface for gdb * Web base python interface. * etc, etc,

* Desktop is just Firefox with home page with a lot app icons.

-- Now time to wake up, take the red pill and continue use vim, git, insmod, strace and cat /proc/.......

Open Office? Haven't heard about that in years!

Now we use LibreOffice and there is already a Web UI :-)

Here you are: https://www.collaboraoffice.com/code/

Just use NextCloud / Syncthing or a traditional NFS and you're good to go.

For system logs you could use the ELK stack or something like that.

Python Web UI = Jupyter Notebook (it's awesome you should check this out)

APT / DPKG: why web based?

Also I don't know why you see vim as the only alternative. There is NeoVim / SpaceVim and some fancy emacs stuff you can use as well.

For git there is really good tools nowadays like GitKraken, SourceTree or this tool from the sublime creator. Also you have integration into good IDE's. When you want to use a web UI then I'd recommend you check out GitLab. Even the CE is awesome and much more I was hoping to see any time soon.

I use SpaceVim and am totally happy as it has nearly all features of IntelliJ Idea that I use daily but runs on my shell (great for keeping your old thinpads battery on a decent level for some time).

And eventually they will not even need the Linux kernel, the last standing GPL thingie on their stack.

all Linus and the kernel team can do is make the kernel itself

In some sense that's a self-imposed limitation. Linus could have chosen to create an OS (like BSD) instead of a kernel.

Not really, GNU existed for a while before Linux and Linus' kernel slotted into the missing hole in GNU (since Hurd _really_ wasn't ready and likely won't ever be). So I would argue that Linus chose to build an operating system, and ended up with focusing on a kernel because the rest of the system already existed.

The BSDs (and Solaris) all branched from the original Unix tree, and thus have historically always just been a full OS. GNU was trying to do the same, but from scratch and as free software, but Linux came about just as GNU was getting very popular (people would replace the proprietary Unix utilities with the GNU ones).

Also, the BSDs and Solaris all use GNOME or KDE -- which aren't developed solely by those people. I think this is quite reasonable actually, since desktop environments really shouldn't be tied to a single Unix-y OS.

> Linus could have chosen to create an OS (like BSD) instead of a kernel.

The BSD people also don't make a GUI.

On the contrary, they have. Lumina, for starters.

* https://lumina-desktop.org/ (https://news.ycombinator.com/item?id=14282349)

Yeah, Linus is in a power position and could lean on teams to create his vision of Linux on the desktop. But he's a very tech oriented guy and that's ok. He has a tech vision of what the core of the OS should do, and I think the community needs that as much as a person who guides the frontend vision (which is absent for now).

Also... this is the guy who invented git. I'm not really sure we want him working on a desktop UX.

I mean... I like git... Linux kernel and git are perhaps the two most constant aspects of my job. What is the problem?

Git is easily (edit: one of) the best version-control software available, hands down. But, you can't deny that it's very difficult to use. There's an incredibly steep learning curve and the software is very unforgiving.

This can be argued to be a good thing (git just gives you the tools to shoot your own foot), but for an average user, a DE needs to be easier to use than git.

I guess what I'm trying to say is, git is great for experienced users, but most users don't want to have to be experienced just to use a computer.

I wouldn't say easily. Mercurial has a credible claim to that title as well, if you ignore network effects that favour using git.

That's fair. I updated my post to reflect that.

Git has a learning curve, yes. Everything has a learning curve. It helps to actually read the documentation, to go through a few tutorials and to generally play around with Git.

Is it intuitive without prior experience? No. Nothing nontrivial is.

As an example: I have not grokked Blender though I have tried a few times. But I have tried it fully intuitively, just exploring the UI without really reading documentation at all (when I have time I will study it more). Does the UX make sense? No, not to me. Does it mean Blender has a bad UX? No, I don't think so! It has a learning curve like everything else, and learning it is something I have to do if I want to be able to use it. I cannot expect someone else to learn it for me.

git user experience is very bad, objectively and not because of the complexity or the learning curve. A good UX allows you to learn patterns which are applicable across the application. git, on the other hand, offers you an absolutely bewildering mismash of commands and switches to express whether the operation involves a remote, the index or the working tree. This could've been and should've been consistent but no such thing.

Beyond the consistency argument, Jef Raskin: Humane Interface argues for universal undo which git almost has via the reflog except it should've built a safety net for git reset --hard which is possible https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 (and no, disk space usage isn't a concern for 99.99% of the codebases, "disk is the new tape" predates git _and_ even without that recognition most codebases are tiny) and then it could git undo happily.

Add these two and you have a user friendly git without taking away any power.

With git reset --hard protection do you mean accidentally resetting a branch which has uncommitted changes?

If you do that a lot, why not commit your changes more often to your topic branch? You can always squash it later to make it look nice.

Or use stash or something.

git reset --hard throws away work. Nuclear bomb operations should never be a simple switch away.

Of course it does. So does rm -rf. The dd command can ruin your entire disk with a typo.

Their primary goal, however, is not tracking changes. Of course a tool made for deleting or lower level copying is destroying data, that's their primary use. git, however, is almost always undoable.

If you have not committed the changes, then Git is simply not aware that you want to keep those changes in the first place.

It is like editing a file, and not saving it. Is the editor at fault? Should it autosave the file? Under what name? Under what directory? Or should the editor just do what you tell it to?

For this particular case, git stash might help.

In general (danger: personal opinion), it is good practise to be mindful of dangerous commands and take a deep breath before issuing them, whatever they are. That is what I do after having learnt it the hard way, as I have also messed up stuff with the hard Git reset, dd, rm, chmod, chown, cp, mv, tar, you name it...

So, if you ask me, Git does not have an "objectively bad UI" as some say, it just does what it is told to. (Insert joke about computers being like an Old Testament God.)

Read Jef Raskin's Humane Interface.

> It is like editing a file, and not saving it. Is the editor at fault?

Yes

> Should it autosave the file?

Yes

> Under what name? Under what directory?

I don't care, just stash it somewhere so my work doesn't get lost. Notepad++ does it, for example. It doesn't even reveal where does it stash it, but "Noname 1" happily survives even a reboot.

No that would make it unusable to use git in automation. what you are looking for is a training gui around git. until your learn enough to not shoot your foot. no need to dumb down a tool because someone doesn't get it.

I am unsure which of the two would be a bane of git automation but if it is git undo, the fix is really simple: make it opt out. I have git config and I am not afraid to use it.

> no need to dumb down a tool because someone doesn't get it.

If your goal is to make a tool useful to the widest audience possible, then yes, that the goal is precisely to dumb it down so as many people as possible "get it".

I understand the difference, and understand why you use one over the other, but the fact that git has separate "squash", "merge", and "rebase" functions is a UX disaster.

They are different commands because they are different things conceptually.

Rebase is when you transplant another branch on top of another.

Merge joins two branches together.

Squash combines two or more commits into a single one

They are by no means the same thing.

I never said they were the same, I said that having three commands to contribute code is very confusing. A better design would not need "merge", "squash", and "rebase". For example, you wouldn't need to "merge" or "squash" if the system made it easy to visually group changes together.

>It helps to actually read the documentation, to go through a few tutorials and to generally play around with Git.

Yeah, that's the problem. People don't want to do that. Keep in mind, you're not talking about people you find on HN. You're talking about Grandma Sally and Aunt Susan. These are people who can barely use Gmail. They don't want to crack open the documentation

Why would they use Git at all, then?

My point is: people who actually need software version control to get something done are perfectly capable of learning to use Git, warts and all, in 2-4 days which includes reading some of the documentation and playing around with it.

Sure, they might have to refer to the documentation for some time after, and also have a personal "cheat sheet" for commands, but I completely believe it is doable, and over a slightly longer period of time they will not need documentation or cheat sheets at all.

Arguing that people, who are implied to not need software version control to begin with, would consider Git difficult to learn is a bit strange argument.

The point is that inventing Git and designing a good UX require completely different skill sets.

I like git as well but UX wise... just look at the number of different syntaxes to delete something.

Git doesn’t scale.

FB and Google have had to stray from the beaten path.

Git, with its limitations, imposes non-trivial workflow constraints on millions of developers worldwide. It’s far from ideal.

It’s an application ripe for disruption.

Reply on news.ycombinator.com