Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«749 »
  • Post
  • Reply
hifi
Jul 25, 2012



flow control possibly? try ctrl q

Adbot
ADBOT LOVES YOU

thebigcow
Jan 3, 2001

Bully!

Are you using a laptop where the right half of the keyboard is also a ten key pad if you press a button and then mashing insert?

hooah
Feb 6, 2006
WTF?

The behavior starts if I hit the home key. After that, home, end, page up, and page down all toggle the case of the character under the cursor and move to the next cursor. Delete still does forward delete. Most of the alphabetic characters don't do anything, but e.g. P seems to copy the current character.

evol262
Nov 30, 2010
#!/usr/bin/perl

What terminal type?

And do you have a blinged-out prompt for some reason?

hooah
Feb 6, 2006
WTF?

This is over putty, if that's what you mean by terminal type. If that isn't what you mean, then please tell me how to figure that out.

evol262
Nov 30, 2010
#!/usr/bin/perl

echo $TERM

Try setting the terminal type in PuTTY to "linux" instead of whatever it's defaulting to (vt100? xterm?)

The XKCD Larper
Mar 1, 2009

by Lowtax


evol262 posted:

Try "pkcon install foo"

[xkcdlarp@localhost ~]$ pkcon install foo
Resolving [=========================] Package not found: foo
Command failed: This tool could not find any available package: No packages were found

Same error with root.

anthonypants
May 6, 2007

by Nyc_Tattoo


Dinosaur Gum

The XKCD Larper posted:

[xkcdlarp@localhost ~]$ pkcon install foo
Resolving [=========================] Package not found: foo
Command failed: This tool could not find any available package: No packages were found

Same error with root.
"foo" is a substitute for the name of the package you want to install. Do you know the name of the package you're trying to install, and if not, do you know the name of the program?

pseudorandom name
May 6, 2007
INSOLENT


Grimey Drawer

i3 doesn't have a PolicyKit agent; consequently GNOME Software can't ask for permission to install packages and always fails.

The solution to your problem is to either stop attempting to use GNOME Software, stop using a window manager for angry graybeards, or manually install & configure a PolicyKit agent from a desktop environment that actually supports PolicyKit.

The XKCD Larper
Mar 1, 2009

by Lowtax


anthonypants posted:

"foo" is a substitute for the name of the package you want to install. Do you know the name of the package you're trying to install, and if not, do you know the name of the program?



tried with amarok and calibre - both stall at the Resolving stage (IE right away).

Mao Zedong Thot
Oct 16, 2008




Taco Defender

Why are you using i3 and gnome crap?

pseudorandom name posted:

i3 doesn't have a PolicyKit agent; consequently GNOME Software can't ask for permission to install packages and always fails.

The solution to your problem is to either stop attempting to use GNOME Software, stop using a window manager for angry graybeards, or manually install & configure a PolicyKit agent from a desktop environment that actually supports PolicyKit.

you can't just sudo?

evol262
Nov 30, 2010
#!/usr/bin/perl

VOTE YES ON 69 posted:

Why are you using i3 and gnome crap?


you can't just sudo?

PackageKit and PolicyKit both communicate over dbus. Yes, "sudo dnf -y install foo" will work. But sudo doesn't have a lot to do with it otherwise.

The XKCD Larper posted:



tried with amarok and calibre - both stall at the Resolving stage (IE right away).

You'll really need to check the PackageKit logs... Have you thought about just using dnf/yum?

HPL
Aug 28, 2002

Worst case scenario.

Just a bit of wondering here. Is it possible to get a VPS and make a remote desktop connection broker so that I could get RDP or VNC or whatever to work easily through firewalls like Teamviewer or Chrome Remote Desktop do?

evol262
Nov 30, 2010
#!/usr/bin/perl

Of course, but I don't know of any preexisting tools. You have a couple of ways to make this work:

Set up an l2tp/ipsec server (because that's supported on basically every device), with a DNS server alongside it. Use ppp up scripts on new connections along with some trivial scripts to pull the hostname from the guest, and add it as "hostname.vpn". Push split horizon DNS so not all of the traffic crosses the VPN. Or use consul.

Add a simple webserver (or have the script update etcd/redis/whatever and read that from the webserver) to easily monitor guests. Send yourself emails if you want, or script a desktop notifier which subscribes to redis/rabbit/whatever on connection.

Connect using the DNS name the client gets. Your webserver can generate a connection link on the webpage if you want.

-----------------------------

Write your own very trivial server which accepts proto buffers/json/xmlrpc/jsonrpc/whatever from clients and adds mappings (public_ip -> port) to a k/v store (redis, etcd, memcached, whatever)

Build desktop clients or small cli binaries which punch holes in the host firewall using some upnp/igd library. You can use electron+node, python+wxwidgets+py2exe or whatever you want.

Once the port is opened, make an API call to your server to update the k/v store. Again, pub/sub to update some UI on the client. Or update a webpage. Or text the key. Or whatever.

This is probably how TeamViewer/chrome actually do it, but I've never investigated. They may also set up reversed tunnels to some man in the middle server. You could do this with ssh and paramiko

------------

Obviously both methods need authentication of some kind. Both will also require some programming. Neither is really worth it if you can just use TeamViewer/whatever.

apropos man
Sep 5, 2016

You get a hundred and forty one thousand years and you're out in eight!

I'm also having terminal issues.

I keep experiencing freezing of the terminal when I'm logged into my home server. It lasts about 10 seconds (roughly) and when it returns control to me all of the keys I've angrily mashed appear in the terminal. The freezing seems to occur randomly, two or three times a day.

I'm logging in from my laptop most of the time: over WiFi, through the router, via powerline adaptors to the server.

The server's running Lubuntu Xenial and I don't think I've changed much that would cause it to temporarily hog resources so much that the terminal would freeze. I'm not even sure that it's a resource issue. It's possible that it could be my local network.

Is there some kind of 'ps' command I could log the server with, to try and see what's occurring at the same time as a freeze?

I changed the motherboard two days ago, from a similar mini-ITX board to a newer version, but the freezing was happening before I swapped boards so it's not that.

I'm going to re-install Lubuntu to try luks at the weekend but I'd like to discover what's causing the freezing before I wipe the OS. It's good to learn how to deal with stuff in case it happens again.

Oh, and I use byobu terminal on my laptop and desktop but the standard lxterminal on Lubuntu.

Keito
Jul 21, 2005

WHAT DO I CHOOSE ?


apropos man posted:

I'm also having terminal issues.

I keep experiencing freezing of the terminal when I'm logged into my home server. It lasts about 10 seconds (roughly) and when it returns control to me all of the keys I've angrily mashed appear in the terminal. The freezing seems to occur randomly, two or three times a day.

I'm logging in from my laptop most of the time: over WiFi, through the router, via powerline adaptors to the server.

Both wifi and powerline networking is unstable as poo poo. Just sounds like interference to me.

Try using mosh instead of ssh

The XKCD Larper
Mar 1, 2009

by Lowtax


evol262 posted:

PackageKit and PolicyKit both communicate over dbus. Yes, "sudo dnf -y install foo" will work. But sudo doesn't have a lot to do with it otherwise.


You'll really need to check the PackageKit logs... Have you thought about just using dnf/yum?

Like I said I can install packages through the command line [with DNF] if I find the applicable one. I just wanted a smooth app-store like experience for the GUI stuff that I do try occasionally. I think if the solution involves picking through logs and there's no Google results then it's time to just go with dnf. It's not the biggest deal. Thank you for helping troubleshoot.

Other than the store Gnome applications seem to run fine in I3.

hooah
Feb 6, 2006
WTF?

evol262 posted:

echo $TERM

Try setting the terminal type in PuTTY to "linux" instead of whatever it's defaulting to (vt100? xterm?)

TERM is xterm. I changed PuTTY to linux from "ESC[n~". The home key still does weird things, but only on the first press, so it's a lot more tolerable. Thanks!

hooah fucked around with this message at Oct 7, 2016 around 13:09

evol262
Nov 30, 2010
#!/usr/bin/perl

hooah posted:

TERM is xterm. I changed PuTTY to linux from "ESC[n~". The home key still does weird things, but only on the first press, so it's a lot more tolerable. Thanks!

Consider using "Ctrl+A" instead. The emacs/readline bindings are used all over the place, and the sooner the better.

The XKCD Larper posted:

Like I said I can install packages through the command line [with DNF] if I find the applicable one. I just wanted a smooth app-store like experience for the GUI stuff that I do try occasionally. I think if the solution involves picking through logs and there's no Google results then it's time to just go with dnf. It's not the biggest deal. Thank you for helping troubleshoot.

Other than the store Gnome applications seem to run fine in I3.

There aren't Google results because the intersection of "I run a tiling WM" & "I prefer to use a GUI application instead of a terminal" is vanishingly small.

Speaking generally, you can expect a lot of other things to not work (flash drive automounting, notifications from amarok, virt-manager authenticating you as if you don't start it as root, etc) to not work without some tweaking.

A lot of communication happens over D-BUS and polkit.

Make sure you're starting i3 with "dbus-session". Install a policykit agent (polkit-gnome). Make sure you're starting the agent before you start i3. It will work then.

Xik
Mar 10, 2011



Dinosaur Gum

Tiling WMs own and i3 is pretty much the cream of the crop, but if 90% of your time isn't already spent in a terminal, then stop punishing yourself and get a real desktop.

Ultimately, what do you think is a better way to "learn linux"? Spending a weekend trying to figure out how to do something almost every competent distro already gives you "out of the box", or putting some quality time into learning what happens when you start a process on Linux? Or reading a cool zine about strace and perf.

evol262
Nov 30, 2010
#!/usr/bin/perl

I dunno. I mean, I agree in some sense (though you can actually learn some useful stuff about dbus by deconstructing why some desktop app works), because the plainly broken wifi config doesn't need to be, et al.

On the other hand, I'm also not sure that reading about process spawning, forking, response handlers, or random syscalls is actually informative in any meaningful way if you're not a developer (or you're not even close to ever writing an application which needs to fork).

At least debugging why gnome software doesn't work might teach you about dbus, because you're actually doing something. Reading about strace can get bookmarked for when you might understand it (or even what O_NONBLOCK means)

Doing things is the best way to learn, IMO. Debugging why poo poo is needlessly broken (because the arch devs shipped a package with broken ldd, since the other libraries it's actually linked against are in an "optional" package for some reason), no. Debugging D-BUS, maybe.

HPL
Aug 28, 2002

Worst case scenario.

evol262 posted:

(Whole lotta crazy talk)

Wow, that's a little more complicated than I bargained for. Guess I'll stick with the tried and true. Thanks for taking the time to answer the question though.

Xik
Mar 10, 2011



Dinosaur Gum

evol262 posted:

On the other hand, I'm also not sure that reading about process spawning, forking, response handlers, or random syscalls is actually informative in any meaningful way if you're not a developer (or you're not even close to ever writing an application which needs to fork).

You're probably right, it was mostly a (possibly extreme) counter-example to the idea that newbies should pick a distro that makes frequent breaking changes, has poor package management or has no installer because it is somehow a "useful learning tool".

evol262
Nov 30, 2010
#!/usr/bin/perl

I think we can all agree on that. Distro maintenance is hard for experienced developers. We work hard to ensure that your user experience isn't lovely. Just pulling the latest tarball from upstream and packaging it is never good.

Toalpaz
Mar 20, 2012

Peace through overwhelming determination


Xik posted:

You're probably right, it was mostly a (possibly extreme) counter-example to the idea that newbies should pick a distro that makes frequent breaking changes, has poor package management or has no installer because it is somehow a "useful learning tool".



I can't help but feel like that was directed at me. Well no breaking updates yet, fingers crossed.

evol262
Nov 30, 2010
#!/usr/bin/perl

Eventually you will "pacman -Sy somepackage", and everything will break, because pacman doesn't bother to check whether removing/upgrading the dependency of foo breaks something really important

Keito
Jul 21, 2005

WHAT DO I CHOOSE ?


evol262 posted:

Eventually you will "pacman -Sy somepackage", and everything will break, because pacman doesn't bother to check whether removing/upgrading the dependency of foo breaks something really important

You install things that way and it's just a good old case of PEBKAC. Arch was never designed for partial upgrades.

evol262
Nov 30, 2010
#!/usr/bin/perl

This elitism and Stockholm Syndrome is why Arch gets poo poo on.

Please give a single good reason why pacman (unlike every other package manager) does not bother checking whether it's destroying the dependency chain of other packages when upgrading.

Please explain where it would be obvious to a new user that upgrading their web browser may blow up libreadline and their shell (plus probably vi and everything else linked against the now missing libreadline)

I specifically suggested that installing (not upgrading a single package) may do this. Because if a user hypothetically did not have Firefox installed, "pacman -Syy firefox" to install it would to the same idiotic poo poo as upgrading a single package.

This is not defensible from a distro in 2016, and "the problem with this is users" is wrong in so many ways I can't even list them

Keito
Jul 21, 2005

WHAT DO I CHOOSE ?


evol262 posted:

This elitism and Stockholm Syndrome is why Arch gets poo poo on.
It works for me. I'll let you know down the line if it turns out I've been an abuse victim all along.

evol262 posted:

Please give a single good reason why pacman (unlike every other package manager) does not bother checking whether it's destroying the dependency chain of other packages when upgrading.
Because it expects the whole system to be up to date, and this allows for much simpler package management.

evol262 posted:

Please explain where it would be obvious to a new user that upgrading their web browser may blow up libreadline and their shell (plus probably vi and everything else linked against the now missing libreadline)
If a new user had read the system maintenance documentation linked at the end of the installation guide, they would've been aware that partial upgrades are unsupported.

evol262 posted:

I specifically suggested that installing (not upgrading a single package) may do this. Because if a user hypothetically did not have Firefox installed, "pacman -Syy firefox" to install it would to the same idiotic poo poo as upgrading a single package.
If you were just installing a new package, this wouldn't happen. With the command you refer to in quotes there, you are force-refreshing the package database before installing Firefox along with all its dependencies as they are defined in the newly updated database. Installation assumes a system running up to date with the package database.

If you ran "pacman -S firefox" instead, nothing would break.

evol262 posted:

This is not defensible from a distro in 2016, and "the problem with this is users" is wrong in so many ways I can't even list them
If you're using an unsupported feature without knowing what you're doing then yeah it's user error.

Xik
Mar 10, 2011



Dinosaur Gum

Toalpaz posted:



I can't help but feel like that was directed at me. Well no breaking updates yet, fingers crossed.

I promise this wasn't a jab at anyone in particular, it's a fairly common theme in this thread and in other communities.

Keito posted:

You install things that way and it's just a good old case of PEBKAC. Arch was never designed for partial upgrades.

Dependency resolution is one of the primary roles of a package manager, so I find it difficult to justify this sort of attitude. Still, if as a user, you weigh up your distro choice and go in, with full knowledge of the possible limitations and quirks, that's fine. The issue is that it is recommended for newbies and quite frequently, this means users that don't even have a concept of what a "package manager" is. As a Windows or Mac user, it's taken for granted that you can't break half your system when you decide to upgrade your web browser.

evol262
Nov 30, 2010
#!/usr/bin/perl

Keito posted:

Because it expects the whole system to be up to date, and this allows for much simpler package management.
"We didn't implement this basic sanity check that everyone else does (even Gentoo) because it's 'simpler'" is also not defensible.

Keito posted:

If a new user had read the system maintenance documentation linked at the end of the installation guide, they would've been aware that partial upgrades are unsupported.
"If you didn't read the docs, you can corrupt your system doing normal operations" is also not defensible.

Keito posted:

If you were just installing a new package, this wouldn't happen. With the command you refer to in quotes there, you are force-refreshing the package database before installing Firefox along with all its dependencies as they are defined in the newly updated database. Installation assumes a system running up to date with the package database.

If you ran "pacman -S firefox" instead, nothing would break.
I don't use Arch often enough to remember whether "-Sy" or "-Syy" didn't what I meant.

Unless you ran "pacman -Sy && #... Do other stuff && pacman -S firefox" eventually. This is explicitly mentioned as a breaking case, and it's incredible.

Set a flag which warns users to "-Syu" first and clear it after the upgrade is done. Actually depsolve installed packages. Do anything. Clearly it's a problem, and they're even willing to invest a little engineering time in it. Go all the way.

Keito posted:

If you're using an unsupported feature without knowing what you're doing then yeah it's user error.

Or, you can (and should) blame the distro maintainers for allowing basic misuse of a package manager to break your system. This is not "I chowned something or symlinked something in /usr/lib64 or 'I used an unstable package or cloned from git or read the source and called a flag not in the manpage'". It's basic.

This is distro maintainer error, not user error. This is why Arch (and Arch users) have a bad reputation.

E: before the "upstream rolling distro" defense force, remember that there are other rolling release distros which are pure upstream (or close) which don't have these problems. Because QE catches them. And Arch doesn't QE. But pacman is not upstream. It's a steaming pile the arch devs maintain directly, and they are 100% responsible for all its misbehaviors. Not users.

evol262 fucked around with this message at Oct 9, 2016 around 01:42

ToxicFrog
Apr 26, 2008



And as a point of comparison, if you try doing the same thing in SUSE (including the SUSE rolling release version, Tumbleweed), you get something like this:

pre:
Package 'bash' depends on 'libreadline(version=5)', but 'libreadline(version=6)' is to be installed. Please pick an option:
  1. Upgrade bash to version x.y.z
  2. Break bash by ignoring some of its dependencies
  3. Do not upgrade libreadline, and break firefox by ignoring some of its dependencies
This has been a solved problem in distros that aren't Arch for a long time.

evol262
Nov 30, 2010
#!/usr/bin/perl

Fedora Rawhide (rolling) is similar.

This is a personal point of bitchiness for me, because an absolute ton of work has gone into (and keeps going into) "user experience". Linux is not in 2003 anymore. It should not be needlessly arcane and fail badly in idiotic ways under the guise of "user error". Most of the time when your software falls down in this way, it's the developer's fault.

I called this Stockholm Syndrome because Arch apologists don't want to admit this for some reason, but no sane distro/package manager behaves this way.

Not even portage, homebrew, or pkgsrc.

Keito
Jul 21, 2005

WHAT DO I CHOOSE ?


Xik posted:

Dependency resolution is one of the primary roles of a package manager, so I find it difficult to justify this sort of attitude.
Dependency resolution is working fine if you use the package manager in the way it's intended to be used, so I find it an unjustified complaint is all.

Xik posted:

Still, if as a user, you weigh up your distro choice and go in, with full knowledge of the possible limitations and quirks, that's fine. The issue is that it is recommended for newbies and quite frequently, this means users that don't even have a concept of what a "package manager" is. As a Windows or Mac user, it's taken for granted that you can't break half your system when you decide to upgrade your web browser.
Most definitely. There are limitations to this way of handling things, as evidenced by the "bug" reports linked above. Newcomers to Linux should probably start out somewhere else to avoid themselves a lot of pain. FWIW I never recommend this distro to anyone, it's just my personal preference.

evol262 posted:

"We didn't implement this basic sanity check that everyone else does (even Gentoo) because it's 'simpler'" is also not defensible.
pacman is working with the assumption that the system's software matches the package database, this makes its operations a lot simpler. You might think it's indefensible, others might disagree. It's what Arch has chosen and you have lots of other OS options if you dislike this way of doing things.

evol262 posted:

"If you didn't read the docs, you can corrupt your system doing normal operations" is also not defensible.
You can break your systems in lots of worse ways improperly using coreutils, maybe those need more of the "safety scissors" approach as well?

evol262 posted:

I don't use Arch often enough to remember whether "-Sy" or "-Syy" didn't what I meant.
Yeah that's understandable but you actually want neither. Never pass the update flag to the sync operation unless you actually intend on upgrading the whole system or know what you're doing:

PACMAN(8) posted:

SYNC OPTIONS
-y, --refresh
Download a fresh copy of the master package database from the server(s) defined in pacman.conf(5). This should typically be used each time you use --sysupgrade or -u. Passing two --refresh or -y flags will
force a refresh of all package databases, even if they appear to be up-to-date.

evol262 posted:

Unless you ran "pacman -Sy && #... Do other stuff && pacman -S firefox" eventually. This is explicitly mentioned as a breaking case, and it's incredible.
Like I've been telling you for a while now, do that and you're doing it wrong.
https://wiki.archlinux.org/index.ph...alling_packages

evol262 posted:

Set a flag which warns users to "-Syu" first and clear it after the upgrade is done. Actually depsolve installed packages. Do anything. Clearly it's a problem, and they're even willing to invest a little engineering time in it. Go all the way.

Or, you can (and should) blame the distro maintainers for allowing basic misuse of a package manager to break your system. This is not "I chowned something or symlinked something in /usr/lib64 or 'I used an unstable package or cloned from git or read the source and called a flag not in the manpage'". It's basic.

This is distro maintainer error, not user error. This is why Arch (and Arch users) have a bad reputation.
https://wiki.archlinux.org/index.ph...User_centrality
It's user error, plain and simple. If you are unwilling to read documentation you shouldn't be running an OS that expects you to do so.

Most of Arch's bad reputation seems to be coming from people wanting it to be something it's not.

xzzy
Mar 5, 2009

wakey wakey to
this bowl of tasty


Yams Fan

I like Arch and use it on my workstation because I dig the rolling release system, it's nice always having the latest and greatest on tap. I like literally anything else for machines I actually have to support because gently caress putting something like that on 2000+ machines and not knowing what incompatibilities version changes introduce with user processes.

Give me a distro with an annual point release for that. If I had to ask users to do compliance testing on any shorter a scale I'd end up shooting myself.

Suspicious Dish
Sep 24, 2011



Fun Shoe

Keito posted:

pacman is working with the assumption that the system's software matches the package database, this makes its operations a lot simpler.

If so, why does it explicitly have a flag to break this invariant? pacman -Sy? They could have checked this invariant. Or warned the user. Or put something in the man page about it. Or even mention this assumption anywhere (I couldn't find it in a quick "man pacman" skim, but maybe I missed it)

But Arch does none of the above. This is an invariant I didn't know of, even after three years of using Arch a while ago.

Mao Zedong Thot
Oct 16, 2008




Taco Defender

If you think upgrading your system is a fun hobby and you get a little thrill when you run 'apt-get upgrade' yeah Arch sounds great. If you want to just use your computer, maybe not.

Ricing computers was fun when it was a learning experience. At this point, for me, it's like smashing my head into a brick wall repeatedly and voluntarily to recreate a bad day at work.

evol262
Nov 30, 2010
#!/usr/bin/perl

Keito posted:

Dependency resolution is working fine if you use the package manager in the way it's intended to be used, so I find it an unjustified complaint is all.
The point of dependency resolution is that it's actually supposed to handle this without resorting to weasel arguments like "the way it's intended to be used".

Keito posted:

Most definitely. There are limitations to this way of handling things, as evidenced by the "bug" reports linked above. Newcomers to Linux should probably start out somewhere else to avoid themselves a lot of pain. FWIW I never recommend this distro to anyone, it's just my personal preference.
And I'm not disparaging Arch users. I'm disparaging the Arch developers. And users who defend this as a correct design decision. Instead of calling a bug a "bug" to discredit it.

Keito posted:

pacman is working with the assumption that the system's software matches the package database, this makes its operations a lot simpler. You might think it's indefensible, others might disagree. It's what Arch has chosen and you have lots of other OS options if you dislike this way of doing things.
If you disagree, please try to honestly defend why a package manager should not track dependencies. Please defend why pacman should not set a flag after a package database update which is only cleared after a system upgrade. This is the right way to do things (from a software perspective). The current situation is not a "design decision". It's a flaw in the implementation which they've somehow convinced is a feature to defenders.

Keito posted:

You can break your systems in lots of worse ways improperly using coreutils, maybe those need more of the "safety scissors" approach as well?
Most of coreutils actually has "safety scissors", and you have to rerun the command with "-f".

But (for those which don't) `dd` is not an apples-to-apples comparison to a package manager, and you know it.

Keito posted:

Like I've been telling you for a while now, do that and you're doing it wrong.
Well, I'm not, but my use cases for Arch are pretty small (mostly single board ARM systems that I'm testing on), and I haven't personally encountered this. The fact that it's possible is galling. "You're doing it wrong" (as a pejorative against users) is a forum/mailing list response from 10 years go.

This lowers the level of discourse. "You didn't read this wiki page/forum post/manpage, where we warn you that taking this action might break your system, but we didn't bother to put basic safety checks in place" is not the user's fault. If you (as a developer) know that some actions should not be taken (-Sy, then installing without upgrading first, for example), block it and add an additional flag (-f) to force it. This leaves users who are already doing the "right thing" without a need to change their workflow, and stops everyone else.

Keito posted:

It's user error, plain and simple. If you are unwilling to read documentation you shouldn't be running an OS that expects you to do so.
The point here is that it's developer error.

Keito posted:

Most of Arch's bad reputation seems to be coming from people wanting it to be something it's not.
No.

I mean, we're clearly not going to agree. But I actually want Arch to be (almost) exactly what it is. There's incredible value in having a very minimal distro which doesn't apply any of its own patches, with a large community, with a large secondary package system (through the AUR), with great documentation. I want Arch to be a usable recommendation for mid-level users (or even newbies). But it isn't.

And it isn't because of decisions like this. Not running PolicyKit/D-BUS by default is good in some way, because you need learn that those run and why. "My system blew up in my face because I installed a package" isn't even good from a 'I understand how my system works' perspective. Because really building it from the ground up means you'd need to rebuild libreadline (in this case). It wouldn't silently change under you. The Arch developers could put 5 hours into fixing very basic nonsense and it would be 100% improved.

It also isn't because of the incredibly hostile user base whose first response is "this is user error", but that's an aside.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell


My cars wheels fall off if I drive it at 56 miles per hour. Sure there's no good argument for it to be that way, and there is no benefit to anyone, and it's incredibly dangerous, but it's not stupid because it was a design decision to make it do this.

That's what I'm hearing from the pro-Arch camp so far here.

Adbot
ADBOT LOVES YOU

Suspicious Dish
Sep 24, 2011



Fun Shoe

Thermopyle posted:

My cars wheels fall off if I drive it at 56 miles per hour. Sure there's no good argument for it to be that way, and there is no benefit to anyone, and it's incredibly dangerous, but it's not stupid because it was a design decision to make it do this.

That's what I'm hearing from the pro-Arch camp so far here.

"Dashboard lights or alarms? gently caress you. That would inhibit my ability to conveniently drive at high speeds, knowing the tradeoffs of losing a wheel. Can't you read? It says so SUPER CLEARLY on page 163 of 522 in the User's Manual. PEBWAC. Users are so stupid..."

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«749 »