Hacker Newsnew | past | comments | ask | show | jobs | submit | dmustillo's commentslogin

It blows my mind how many comments here think you are wrong. You are absolutely correct. A new user does not care how great x,y,z feature is if they can't do basic things that are ubiquitous in other operating systems. New users might hear Unix is better, but if it doesn't feel that way, they're going to go back to what they know works when the next deliverable/project/essay/game comes out.


> New users might hear Unix is better, but if it doesn't feel that way, they're going to go back to what they know works

For anyone who doubts the above, think about how much help you'd have to give many of your family members (spouse, parents, kids, etc.) for installing Thunderbird or another popular desktop app.

For all of my family members, the moment they have to open a terminal to do something basic they'd say "that's it, I'm going back to macOS (or Windows)."


If you download a .deb file on Ubuntu, click on it, it will install it and do all the right things.

There is Windows files also distributed as zip files, just as unusable.


The problem is deb files don’t work on all distros and browsers tend to hide the specific distro from the user agent for privacy.

Never link to a deb or rpm as the primary “download”. It should be a flatpak or app image and then an advanced options section for distro specific packages.


The problem is flatpack/appimage are equally bad/opaque, they solve one problem at the expense of being better off just in windows or osx.

tar.gz is opaque in a different way - the solution would be more like an interpreter - something which has a good guess how you should install/run the file.

There is the issue also of integration with the distribution, this is a problem with distribution apis - package maintainers are invested in their formats and distribution list not solid apis with which to interact. If you could build against such a set of Apis you could bundle an interpreter which just knows what to do.

Tar.gz is a hell of a lot simpler than any other format, it's not the issue, it's the desktop distros who are underfunded/at fault.


> If you download a .deb file on Ubuntu, click on it, it will install it

Yes, this is true.

But it is no help on RPM-family distros, or Arch-family ones, or Alpine or Void or whatever.

> and do all the right things.

No, mostly, it won't. Because the file won't be added to the OS's list of repositories and it will never get updated.

This is not automatic behaviour, but it can be: Google does this right. Do this with Chrome or Google Earth or whatever and it just magically happens, and that is the Right Thing™.

https://www.google.com/linuxrepositories/


“It will never be updated” is a property that is just as true/false on Windows or Mac applications. What do people do? They build self updated into their programs!

And like you said, Google does it. They do it with a single deb you click on.

I feel like package managers on distos are a thing that kinda make people forget that applications can be distributed “normally” outside this chain.


This is a fair point, and valid and true.

However, for better or for worse, it is not the Linux way.

Maybe it should be, but it isn't.

I can't think of a single Linux app that self-updates this way. I suspect that on most distros, permissions issues would prevent it.

I also suspect that if it were easy, Google would have done it. It is not a company that does things the hard way for fun.

Packaging apps as distro-native packages isn't trivial but there's tons of existing tooling for it. Ditto for hosting repos.

So what Google did is package stuff so that it adds its own repos when you install it, and then it is left up to the OS to keep it updated.

That to me says that that was an easier job than writing self-updating Linux apps, like Chrome on Windows or on macOS.


How many of these inexperienced linux users are running Arch linux?


It is an _example_.

OTOH do not forget that Arch is a family of distros now, not a single distro, just as Debian is.

In fact I suspect that it is the 2nd biggest family of distros, after Debian.

Debian encompasses many dozens: Ubuntu, plus dozens of Ubuntu derivatives including Mint, Elementary, PopOS, ZorinOS, Linux Lite etc.; LMDE; Devuan; MX Linux; SpiralLinux; etc. etc.

Arch now encompasses at least Manjaro, EndeavourOS, Garuda and more. https://wiki.archlinux.org/title/Arch-based_distributions

But that is not the point.

The point is that _tens of millions_ are running non-Debian-derived distros, mostly ChromeOS and CloudReady/ChromeOS Flex.

Offering a .deb package is _not_ a useful approach to offering a generic Linux package, no.


The RHEL and SuSE family is definitely bigger than arch and arch adjacent distros but I agree with your point


Yes, that's true.

FWIW, I have tried both the Snap and AppImage versions of TB 102.

Both were very easy to install. The problem is that Snap confinement meant that TB could not see my existing profile. I just got the first-run wizard.

This did not affect the AppImage, which is working well.


The "right thing" is submitting a patch to popular distros to have your package included in the repos.

IME: it's always application devs who are upset about this, not users.


No, I disagree. I can see at least 3 reasons:

[1] That will happen in time anyway. This is a flagship app.

[2] I would not expect any distro to include a major version in its stable release. So, even if they do that, it will take months to percolate out.

[3] When it happens, it will need an OS version upgrade.

This is a standalone app release, not an OS release. It is in many OSes and it will make its way to them in time. You are conflating 2 different things.

The question we are discussing here is: I run T'bird on my own box, and I want to try the new version; how do I do that?

There are 2 possible solutions to this: either provide distro-native packages (as Google does; this is mainly appropriate to proprietary apps, which T'bird is not); or, provide some kind of cross-distro package. Since both Snap and Flatpak need support tools installed, and AppImage does not, that makes AppImage the best choice, IMHO.

Snapcraft and Flathub will do their own thing in time.

On which note, T'bird 102 is already on Snapcraft, but it does not pick up existing T'bird settings or profiles.


I believe the GUI-based DEB installed was removed from recent Debian/Ubuntu versions. You can of course install it from the CLI but that's terrible from a user experience point of view.


If Linux distros implemented every feature "new users" wanted then you would end up with something nearly identical to ChromiumOS (and those same users would probably just run ChromeOS.) If you want that then go run that.

EDIT: Everyone here knows how to type "sudo apt install thunderbird." People are failing to install bleeding edge software. This shouldn't be surprising or upsetting.


This isn't just a feature, this is installing apps. Many users are failing to install apps. Users on this forum, even, which is telling because this forum is a sort of filter to select those who are more tech savy than the average person. There is a usability issue here that absolutely should be talked about and addressed, which involves a solution that isn't "switch to chrome OS".


I would hazard a guess that many users on this forum are really only familiar with macOS and a smattering of CLI magical invocations.

Package managers exist for a reason. Flatpack, snap etc all exist. You can't just hand wave real complexity away by yelling "usability!" without having fiat power over an incredibly diverse ecosystem.

The lowest common denominator for installing software on Linux distributions is well below what an incurious user will put up with. If you don't want to understand that kind of low level tinkering, you have to wait for whatever ecosystem you bought into to catch up.

That might mean moving back to Apple's curated experience. That's fine; so long as Linux itself isn't a curated walled garden, it'll never be as seamless in every instance, and that's not for everyone.


> There is a usability issue here that absolutely should be talked about and addressed

Addressed by whom, exactly? "The Linux community" is busy addressing the things they care about. Nobody is telling anybody to use Linux if it doesn't work for their needs.


I think we're assuming that if an application ever wants to be "mainstream", it has to be useable by people who don't know what a command line is, let alone what "sudo" means.


I'm not sure why it matters. In discussions like this there seems to be the assumption that Linux must be usable by non-technical people, and if it isn't, then someone is doing something wrong.

Linux is immensely useful to me and everyone else who uses it. It doesn't really bother me that my mom doesn't use it; she is perfectly happy with Windows. If someone made a Linux distro that was exactly as polished and easy-to-use for non-technical people as macOS or Windows is, it would not affect me at all.

Who is this strawman entity who "wants Linux to be mainstream" ? Does anyone really care? Certainly my mom doesn't, and as far as I can tell, most Linux users who are happy with it don't either.

Furthermore, it's quite easy to understand why this hasn't happened, as doing that would cost huge amounts of money and there is no incentive structure that exists to raise it.


> Who is this strawman entity who "wants Linux to be mainstream" ?

The ones doing desktop environments, UIs, package managers, etc. They thrive for mass adoption.

Developers that want their applications cross-compatible and painless for the users.

People that cannot (or are not willing to) pay for a Windows license.

The ones waiting for the "year of Linux Desktop".

> a Linux distro that was exactly as polished and easy-to-use for non-technical people as macOS or Windows

While I truly appreciate the efforts, the problem is that the above is the intention, but it's kind-of half baked right now.

For example, having to search online, open a console and editing files for simple stuff like regulating the speed of the mouse wheel.


> They thrive for mass adoption

I doubt it. I have never seen anyone in the Ubuntu community for example claiming that their goal is the "mass adoption" of Ubuntu. That's, obviously, an impossible pipe dream. Can you provide recent examples?


Yeah... I know the tactic and you want me to go for a hunt of some comment somewhere. Otherwise it's a dismissal.

I'll just use common sense and say that all the evident effort that is put into Desktop environments and user applications is not just to keep their (tiny) user base happy or to be used less.


> Who is this strawman entity who "wants Linux to be mainstream" ? Does anyone really care?

I think it's basic human desire for things to be relatable, but more than that there are those who experience the tyranny of 'modern' life - if you interface with the world, it is perhaps natural to want to do so simply, constantly switching contexts is not productive.

I suppose, I do really care, because every time I am forced to use a system which I don't really want to use, is another time I don't really like the world I live in, I am resentful, and ultimately I really want to not care at all about the device in question.

So, for a wide range of devices I interact with, I view them as trash, because I don't care about trash either, except to remove it from my home on a regular basis.

There are others like me, I know, and there are others in similar positions but not about linux I know as well, e.g. anyone who has ever read a good book and wishes the author were more well read, and simultaneously is affronted by the cheap dime novellas they encounter while e.g. browsing a department store.

"Furthermore, it's quite easy to understand why this hasn't happened, as doing that would cost huge amounts of money and there is no incentive structure that exists to raise it."

There isn't, yet. There are various companies which have sought to bring it there. To use the (perhaps bad) author metaphor, we haven't had our JK Rowling moment yet.

There have been pushes, e.g. Ubuntu, Redhat, but so far market forces have conspired against us, not necessarily because no one cares or no attempts have been made.


It's not market forces conspiring against you, it's nature. You're not making the system simpler, just building more systems inside it.

Linux based OSes will never be popular and have the same freedom they have. The principles the developers have that make it free are the same ones that create these "usability problems" which make it so unpopular.


I guess I don't buy this - there are systems which offer a lot of freedom and are still popular.

Legos, Jeeps, Cooking. HTML, Minecraft, some real-world, software options.

"Usability" can be something you buy on top of the simple system, or it can be free, depending. These aren't diametrically opposite properties of systems.


I'd prefer if I could use a single OS for most of my needs instead of having to context switch between platforms.

In particular, I hate that I need to have a Windows machine for gaming in addition to a Unix machine for everything else. If Linux were a substantial competitor on the desktop, more developers would feel compelled to port their games to Linux, and I wouldn't have to make that choice.


Oh you know what I mean. "Mainstream" distros have GUIs that wrap package managers. Also my girlfriend figured apt out like a week after installing a debian based distro. It's not exactly rocket science.


I struggled with this a lot. Drove me nuts we couldn't get decent code coverage because of error handling for errors I don't even know how to replicate in the first place.

Plus once your code throws one error, every bit of calling code also needs to handle that error. The problem cascades through a codebase quickly. Seemed like a huge violation of DRY principles.

Rob Pike (my understanding as one of the main guys who created the language) has actually addressed this, it's a good read:

https://go.dev/blog/errors-are-values

Tldr refactor your error handling to treat it like code. DRY and SOLID principles would apply and etc. Article makes example of handle your errors in one place rather than 20 by using no-ops on remaining operations after an error occurs.

I don't actually agree with the choice, as it takes one key library which throws errors at every call (like I'm dealing with now) for this to just become a huge pain to do. I had to completely change business logic to implement his suggestion, which isn't always viable (and I'm subsequently finding that out that that wasn't completely viable for us first hand now). Also a lot more boilerplatey type no value add type code needs to be written.

I much prefer unchecked exceptions for the most part, but at least I can understand WHY error handling is the way it is in Go.


Approximately 0% of code bases do this in golang practice. I would be floored if someone provided an example of a large project that does.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: