|
flow control possibly? try ctrl q
|
#
?
Oct 6, 2016 19:39
|
|
|
|
| # ? Apr 20, 2024 08:54 |
|
|
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?
|
|
#
?
Oct 6, 2016 20:16
|
|
|
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.
|
|
#
?
Oct 6, 2016 20:41
|
|
|
What terminal type? And do you have a blinged-out prompt for some reason?
|
|
#
?
Oct 6, 2016 21:06
|
|
|
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.
|
|
#
?
Oct 6, 2016 22:41
|
|
|
echo $TERM Try setting the terminal type in PuTTY to "linux" instead of whatever it's defaulting to (vt100? xterm?)
|
|
#
?
Oct 6, 2016 22:48
|
|
|
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.
|
|
#
?
Oct 6, 2016 23:04
|
|
|
The XKCD Larper posted:[xkcdlarp@localhost ~]$ pkcon install foo
|
|
#
?
Oct 6, 2016 23:13
|
|
|
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.
|
|
#
?
Oct 7, 2016 00:25
|
|
|
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).
|
|
#
?
Oct 7, 2016 01:29
|
|
|
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.  you can't just sudo?
|
|
#
?
Oct 7, 2016 01:32
|
|
|
VOTE YES ON 69 posted:Why are you using i3 and gnome crap? 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:
You'll really need to check the PackageKit logs... Have you thought about just using dnf/yum?
|
|
#
?
Oct 7, 2016 02:51
|
|
|
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?
|
|
#
?
Oct 7, 2016 05:03
|
|
|
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.
|
|
#
?
Oct 7, 2016 05:29
|
|
|
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.
|
|
#
?
Oct 7, 2016 06:56
|
|
|
apropos man posted:I'm also having terminal issues. Both wifi and powerline networking is unstable as poo poo. Just sounds like interference to me. Try using mosh instead of ssh
|
|
#
?
Oct 7, 2016 07:43
|
|
|
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. 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.
|
|
#
?
Oct 7, 2016 10:47
|
|
|
evol262 posted:echo $TERM 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 14:09 on Oct 7, 2016 |
|
#
?
Oct 7, 2016 14:00
|
|
|
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. 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.
|
|
#
?
Oct 7, 2016 14:48
|
|
|
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.
|
|
#
?
Oct 8, 2016 01:10
|
|
|
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.
|
|
#
?
Oct 8, 2016 04:25
|
|
|
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.
|
|
#
?
Oct 8, 2016 04:51
|
|
|
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".
|
|
#
?
Oct 8, 2016 05:49
|
|
|
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.
|
|
#
?
Oct 8, 2016 08:00
|
|
|
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.
|
|
#
?
Oct 8, 2016 15:02
|
|
|
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
|
|
#
?
Oct 8, 2016 17:22
|
|
|
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.
|
|
#
?
Oct 9, 2016 00:38
|
|
|
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
|
|
#
?
Oct 9, 2016 01:28
|
|
|
evol262 posted:This elitism and Stockholm Syndrome is why Arch gets poo poo on. 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. 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) 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 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
|
|
#
?
Oct 9, 2016 02:13
|
|
|
Toalpaz posted:
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.
|
|
#
?
Oct 9, 2016 02:21
|
|
|
Keito posted:Because it expects the whole system to be up to date, and this allows for much simpler package management. 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. 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. 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 02:42 on Oct 9, 2016 |
|
#
?
Oct 9, 2016 02:36
|
|
|
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
|
|
#
?
Oct 9, 2016 03:44
|
|
|
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.
|
|
#
?
Oct 9, 2016 04:22
|
|
|
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. 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. evol262 posted:"We didn't implement this basic sanity check that everyone else does (even Gentoo) because it's 'simpler'" is also not defensible. evol262 posted:"If you didn't read the docs, you can corrupt your system doing normal operations" is also not defensible. evol262 posted:I don't use Arch often enough to remember whether "-Sy" or "-Syy" didn't what I meant. PACMAN(8) posted:SYNC OPTIONS 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. https://wiki.archlinux.org/index.php/pacman#Installing_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. 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.
|
|
#
?
Oct 9, 2016 12:42
|
|
|
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.
|
|
#
?
Oct 9, 2016 15:20
|
|
|
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.
|
|
#
?
Oct 9, 2016 16:36
|
|
|
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.
|
|
#
?
Oct 9, 2016 16:57
|
|
|
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. 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. 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. 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? 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. 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. Keito posted:Most of Arch's bad reputation seems to be coming from people wanting it to be something it's not. 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.
|
|
#
?
Oct 9, 2016 17:20
|
|
|
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.
|
|
#
?
Oct 9, 2016 17:26
|
|
|
|
| # ? Apr 20, 2024 08:54 |
|
|
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. "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..."
|
|
#
?
Oct 9, 2016 17:38
|
|