I think power users are not the main target of Ubuntu.
I have put my parents on Ubuntu (gnome) in 2013 to replace windows XP. My mother is 88 now. I think it is the perfect fit for her (dad is dead years ago).
I use ubuntu gnome because tweaking my computer is not where I want to spend my time. YOLO. Using a "mainstream" desktop that can be explained to "non specialist" has its benefits. I accept to suffer some annoyances and there is always a way to fix the most annoying ones by sacrificing time.
>I think power users are not the main target of Ubuntu.
Then who is? Normies buy iPads and casuals stay on Windows. Is this why Linux can't gain any market share?
IMHO, Ubuntu is trying to gain market share by targeting non-experts — making Linux simple enough for normies and casual users. Casual users are generally less likely to mess things up on Ubuntu than on Windows.
Every time I run Ubuntu on a computer it always ends up in a state where it does not boot after a few months. This has happened on multiple computers, none with nVidia GPUs, over a period of a bit over 15 years. I don't do anything funny with my computers. No custom kernel, no weird kernel modules, no trying to shoehorn in 3rd party repos intended for Debian, etc. The last time I tried was last year, when I got a new job and my work laptop came with Ubuntu 24.04. Sure enough, after a few months an update made it unable to boot. I have not had this problem with any other distro. I switched the laptop to Fedora and it's worked perfectly fine. This makes me question the logic of trying to give Ubuntu to novice computer users.
This isn't true any more, and hasn't been for some years, you know.
It was true but times change.
Microsoft chose to kill off Windows 10, which it once promised would be the last desktop Windows ever. Its replacement is bigger, slower, stuffed with adverts and upselling attempts, and has an artificial demand for TPM 2.
That's driven thousands of people to check out Linux, and if you don't know anything about Linux, then Ubuntu is the number one best-known distro. Many techies dislike Snap (to the extent of spreading lies like "it's not FOSS"), but it makes version upgrades safer, which matters more to non-techies.
(I say thousands so the pedants don't shout at me, but I suspect the reality is at least hundreds of thousands, maybe millions.)
Linux Mint is friendlier, yes, and so is Zorin OS, but both are based on Ubuntu.
Valve has sold millions of Steam Decks, which demonstrate that it's now possible to run premier new Windows games on Linux with performance at least as good as on Windows. All Linux users know their hardware runs faster and cooler with Linux than Windows anyway.
Chromebooks (which are as cheap as laptops get) outsold Macs (which are expensive) by revenue in 2017 in the USA and within 3 years in the rest of the world. ChromeOS is a desktop Linux, based on Gentoo. It has hundreds of millions of users who have never heard the word "Linux".
Companies with cloud-based IT are deploying ChromeOS Flex as a response to ransomware attach. (E.g. Nordic Choice hotels.)
Many of us see Ubuntu's characteristic desktop in shops, bars, travel stations and things regularly now. I hear its startup sound on trains. I have totally non-techie friends running Ubuntu at home. I've given Mint to lots of mildly technophobic friends and they get on just fine.
It's not over, but the year of Linux on the Desktop came about a decade ago, and the penguin taleban were too busy in-fighting to notice.
>That's driven thousands of people to check out Linux, and if you don't know anything about Linux, then Ubuntu is the number one best-known distro.
Not really. Most normies seem to choose meme gaming distros based off Fedora like CachyOS or Bazzite. Many are waiting for official SteamOS release which is based on Arch.
Snap is TERRIBLE for non-technical people. Imagine installing an image editor via Snap, and then the default sandboxing making it unable to access the images on your media drive. No errors, it just silently fails.
This has been a problem I’ve dealt with on nearly every single Snap I’ve installed. If you’re a file editor, you must let me edit my damn files!
I often hear things like this, but I never encounter them myself.
I've run every single version of Ubuntu ever released. Work machines stay on LTSes, testbeds run interim versions.
After the 22.04 release, I carefully de-snapped my work laptop, using `deb-get` to install native packages of everything. Worked a treat, took less disk space, things started a tiny bit faster.
Then I enabled Ubuntu Pro and it force-reinstalled snapd. It's fair enough to have it as a dependency: it's a standard component. I was very annoyed, though.
But when I upgraded to 24.04, a lot of things broke. I had to spend ages re-enabling repositories, getting new keys, changing version strings in stuff under `/etc/apt/sources.list.d` and so on. It's a PITA.
So I have performed a volte face. I removed all my `deb-get` packages, and reinstalled the snap versions. All my comms and messaging apps, music and media players, and so on.
It's much easier. No extra repos. I experimentally took one laptop from 24.04 to 24.10 to 25.04 to 25.10 and yesterday to 26.04. All my apps stay in place. Nothing broke. No custom repos. No changes needed to any config file. It just works.
I've been using Linux for 30 years, starting on Slackware and moving to Red Hat and Caldera and SUSE via lots of others. But I'm old and grumpy and I want stuff to work without fiddling. I want low maintenance. Snap is low maintenance. My messaging apps can download stuff into my Downloads folder, open attachments from Documents, and so on.
I run native packages of my own browsers (Waterfox and Chrome) and AppImages of Panwriter and Logseq, and I have none of these difficulties.
Life is easier if you don't fight the OS and the vendor.
And Ubuntu is still easier and less hassle than Debian, Fedora, openSUSE, Arch, or any of the other big names.
I was student between 1990 and 1993 and Ada was the main language. Compilation speed was not an issue. I remember that Eiffel was very slow to compile, but not Ada. Between 1994 and 1999, I have worked with Ada on Vax machines. The full recompilation took 2 hours because the machine was slow, not because of the language. Other languages were similarly slow (pascal, C). C was slow because of the lack of precompiled headers (many headers had to be parsed many times). With Ada (alsys ada), there were "libraries" that were black boxes directories containing object code and already parsed package specifications.
Between 1999 and 2002, I have handled projects in Ada, C++ and Java. C++ was slightly slower than Ada (slow link). Java was a lots faster.
Nowadays, Ada compilation is faster than C++.
also "Make America Great Again" states that America is not currently great, which given its geo-political and economic position is just dishonest. Combined with "America First" you get an entirely clean canvas to be incredibly radical while cosplaying conservative.
At that time, there was almost no spam because we could report them to abuse@domain...
There was no firewall in front of our campus and we were using rlogin to connect outside. I used export DISPLAY from Brest to Paris (to use xdvi that was not installed locally).
IMO, the security (ssh and killing rlogin) is the main change that is a really useful progress.
make 2>&1 | tee m.log is in my muscle memory, like adding a & at the end of a command to launch a job, or ctrl+z bg when I forget it, or tar cfz (without the minus so that the order is not important). Without this terseness, people would build myriads of personal alias.
This redirection relies on foundational concepts (file descriptors, stdin 0, stdout 1, stderr 2) that need to be well understood when using unix. IMO, this helps to build insight and intuitiveness. A pipe is not magic, it is just a simple operation on file descriptors. Complexity exists (buffering, zombies), but not there.
Are you sure you understood the comment you replied to?
I agree that 2>&1 is not complex. But I think I speak for many Bash users when I say that this idiom looks bad, is hard to Google, hard to read and hard to memorize.
It’s not like someone woke up one morning and decided to design a confusing language full of shortcuts to make your life harder. Bash is the sum of decades of decisions made, some with poor planning, many contradictory, by hundreds of individuals working all over the world in different decades, to add features to solve and work around real world problems, keep backwards compatibility with decades of working programs, and attempt to have a shared glue language usable across many platforms. Most of the special syntax was developed long before Google existed.
So, sure, there are practical issues with details like this. And yet, it is simple. And there are simple methods for learning and retaining little tidbits like this over time if you care to do so. Bash and its cousins aren’t going away, so take notes, make a cheat sheet, or work on a better replacement (you’ll fail and make the problem worse, but go ahead).
Yeah, seriously. It's as if people want to playact as illiterate programmers.
The "Redirections" section of the manual [0] is just seven US Letter pages. This guy's cheat sheet [1] that took me ten seconds to find is a single printed page.
> The "Redirections" section of the manual [0] is just seven US Letter pages.
"Just" seven US Letter pages? You're talking about redirections alone, right? How many such features exist in Bash? I find Python, Perl and even Lisps easier to understand. Some of those languages wouldn't have been even conceived if shell languages were good enough.
There is another shell language called 'execline' (to be precise, it's a replacement for a shell). The redirections in its commands are done using a program named 'fdmove' [1]. It doesn't leave any confusion as to what it's actually doing. fdmove doesn't mention the fact that it resorts to FD inheritance to achieve this. However, the entire 'shell' is based on chain loading of programs (fork, exec, FD inheritance, environment inheritance, etc). So fdmove's behavior doesn't really create any confusion to begin with. Despite execline needing some clever thinking from the coder, I find it easier to understand what it's actually doing, compared to bash. This is where bash and other POSIX shell languages went wrong with abstractions. They got carried away with them.
Yes. It's the syntax alongside prose explaining the behavior in detail. Go give it a read.
If you want documentation that's done up in the "modern" style, then you'll prefer that one-page cheat sheet that that guy made. I find that "modern" documentation tends to leave it up to each reader to discover the non-obvious parts of the behavior for themselves.
> I find Python ... easier to understand.
Have you read the [0] docs for Python's 'subprocess' library? The [1] docs for Python's 'multiprocess' library? Or many of the other libraries in the Python standard library that deal with nontrivial process and I/O management? Unless you want to underdocument and leave important parts of the behavior for users to incorrectly guess, such documentation is going to be much larger than a cheat sheet would be.
> Yes. It's the syntax alongside prose explaining the behavior in detail. Go give it a read.
Bold of you to assume that I or the others didn't. I made my statement in spite of reading it. Not because I didn't read it. So my opinion is unchanged here.
The point here is simple. Documentation is a very important addition. But you can't paper over other deficiencies with documentation, especially if you find yourself referring the same documentation again and again. It's an indication that you're dealing with an abstraction that can't easily be internalized. Throwing the book at everyone isn't a good solution to every problem.
> Have you read the [0] docs for Python's 'subprocess' library? The ...
Yes, I have! All of those. Their difference with bash documentation is that you get the idea in a single glance. I spend much less time wondering how to make sense of it all. Python's abstractions are well thought out, carefully selected, consistently and orthogonally implemented and stays out of the way - something I can hardly say about bash. If that's not enough for you, Python has something that bash lacks - PEPs. The documents that neatly outline the rationale behind their decisions. That's what a lot of programmers want to know and every programmer should know.
Fun fact: The Epstein files contain a copy of the bash manual! Of course they weren't involved in his crimes. It was just one of the documents found on his system. A sysadmin is believed to have downloaded it for reference. But it's telling that it wasn't the Python manual, or the Perl manual, or something else. Meanwhile, I don't really think that Epstein was running Linux on his system.
> Unless you want to underdocument and leave important parts of the behavior for users to incorrectly guess, such documentation is going to be much larger than a cheat sheet would be.
If properly designed, such expansive documentation would be unnecessary, as they would be obvious even with the abstractions. For example when you use a buffer abstraction in modern languages, you have a fairly good idea what it does and why you need it, even though you may not care about its exact implementation details. That's the sort of quality where bash and other POSIX shells fail on several counts. In fact, check how many other shells break POSIX compatibility to solve this problem. Fish and nushell, for example.
"The developer is too lazy to read the documentation" isn't the appropriate stance to assume when so many are expressing their frustration and displeasure at it. At some point, you have to concede that there are genuine problems that cannot be blamed on the developer alone.
> But you can't paper over other deficiencies with documentation, especially if you find yourself referring the same documentation again and again. It's an indication that you're dealing with an abstraction that can't easily be internalized.
> Their difference with bash documentation is that you get the idea in a single glance.
> If properly designed, such expansive documentation would be unnecessary, as they would be obvious even with the abstractions.
What is it the kids say? "Tell me you don't make use of 'multiprocessing', 'subprocess', and other such inherently-complicated modules without telling that you don't..."? Well, it's either that, or you that often use them, and rarely use bash I/O redirections... because, man, the docs for just the 'subprocess.Popen' constructor are massive and full of caveats and warnings.
You're resorting to non sequiturs, nitpicking and vague assertions to just skirt around the point here. Python syntax rarely confuses people as much as bash does. Look at this entire discussion list for example.
subprocess module isn't a reasonable example to the contrary, because it isn't Python's syntactical sugar that makes it confusing. And even in case of modules that aren't well designed, the language developers and the community strive to provide a more ergonomic alternative.
But instead of addressing the point, you decided to make it about me and my development patterns based on some wild reasoning. But that's not surprising because this started with you asserting that it's the developers' fault that bash appears so confusing to them. Just some worthless condescension instead of staying on topic. What a disgrace!
I am french. Everydays, we use DD/MM/YYYY or DD/MM/YY. Sometimes, I encounter YYYY-MM-DD, for example at the beginning of a document reference or in a file name. For me, it feels natural and I have no issue to make this switch mentally. The only problem I encounter is in english: MM/DD/YYYY. Hopefully less and less people are using this insane order.
I still have my palm IIIxe
I have used it to write my games during Go tournaments. I have a usb/serial adaptor. The software was easy to install on linux. Just to write this comment, I have tried to use it (I have not done any tournament since 7 years), but I got an error when I enter "apt-get install pilot-link". I still have my notes on how to use it:
Some more patches at https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/pi....
./configure --enable-conduits && make && make install
sudo
export LD_LIBRARY_PATH=/usr/local/lib
then it works like a charm.
Thank you very much. My usb serial converter is the cheapest chinese one I found.
Tell me more about this cable. I bought a IIIxe of eBay for cheap recently for the nostalgia of it, but put it aside when I realized I couldn’t physically connect it to anything. I’d love to play with it a little more.
I have 1 "big" xsl file in a project I maintain. I have fixed an issue this year. I have tried to use chatgpt prompt. The scope was perfect: I had the buggy xsl, the buggy result, the expected result and a clear explanation.
It generated syntactically correct code (almost) that did not work because chatgpt does not understand.
This was not a complete loss: a good refresher of the syntax, but I had to do the thinking fully alone and found alone how to use "node-set".
My previous change in this file was in 2017 when I replaced xalan by the xslt processor built in java. I was very surprised I had to make the following changes:
I think that Marissa Meyer had given yahoo back a bit of its lustre. That meant cutting dividends in favour of investment. Restoring a reputation takes time. I stopped taking an interest when she was ousted by impatient shareholders.
I am not an insider, maybe I am wrong.
She wasn't ousted because shareholders were impatient. She was ousted because under her leadership Yahoo had collapsed to the point that the only thing left to do was to sell it.
When a new CEO is brought in to right a sinking ship (which Yahoo very much was at the time of her hiring), their number one responsibility is to have a solid core strategy based in leveraging the company's existing strengths and then execute competently on it.
She had no solid core strategy. Her strategy at Yahoo, as she described it, was "to throw lots of spaghetti at the purple walls and see what sticks"; which is exactly what she needed to not be doing. She blew a lot of money on a lot of very varied things and ended up with lots of expensive puzzle pieces with no plan for how to fit them all together into something that would stop Yahoo's bleeding.
At the end, the company as a whole had a valuation less than the company's Alibaba investment -- she drove Yahoo not just to zero, but past zero; and that's 100% due to her not understanding how to lead a shrinking company.
I have put my parents on Ubuntu (gnome) in 2013 to replace windows XP. My mother is 88 now. I think it is the perfect fit for her (dad is dead years ago).
I use ubuntu gnome because tweaking my computer is not where I want to spend my time. YOLO. Using a "mainstream" desktop that can be explained to "non specialist" has its benefits. I accept to suffer some annoyances and there is always a way to fix the most annoying ones by sacrificing time.
reply