Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 19/06/2020 00.18, Eli Schwartz via arch-general wrote: > > I've provided rationale why I don't believe it will break much, you > *agree* with me, and yet you say my arguments don't hold water? > Heh, I'm too tired to get into a detailed debate, but it's very possible to be right for the wrong reasons! :) Regards,
Re: [arch-general] dash as default shell?
On 18/06/2020 18.22, Eli Schwartz via arch-general wrote: > On 6/18/20 12:08 PM, li...@2ion.de wrote: >> On Wed, Jun 17, 2020 at 11:17:08PM +0100, Piscium via arch-general wrote: >>> But switching to dash would also be about security, as less code means >>> less bugs [5]. >> >> Usage of a more concise, powerful and clean shell language is much more >> suitable as a point when bringing forth an argument of there being less >> bugs. >> >> I'd say that the amount of bugs in the underlying implementation of a >> shell almost does matter nothing when compared to the horrors of >> hacked-together shell scripts that try to be as "basic" as possible, >> trying to be as "compatible" as possible with anything, exchanging >> cleanliness and expressiveness for horrible Debian init script-style >> code. >> >> Saving a pseudo-array into a string just to manually reconstruct the >> pseudo-list when the occasion arises to access a specific element is >> just one example of what awaits people who ignore the benefits of Bash >> arrays when they could have had them just by using a different shebang. > > Why does this have anything to do with switching /bin/sh? Scripts which > do not "ignore the benefits of bash arrays when they could have had them > just by using a different shebang", would not be affected by such a > change as they do not, in fact, use a different shebang. > > Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken > even if /bin/sh is a symlink to bash. Bash disables some, but not all, > features of bash if it is invoked in POSIX mode, such as via a symlink > named /bin/sh -- so, you do not even get the benefits of bash, and never > have, if you used /bin/sh as your shebang. > This is a valid argument. >> And nearly everybody who has to write this quickly will do it wrong. > > And yet, some do not. Some write elegant, simple POSIX sh scripts which > do it right. For example, people often forget that pipelines and > functions are an option, and sometimes a much faster and better option > than global state variables. > > And most people who are writing /bin/bash scripts are *also* doing it > wrong because they don't really know what they are doing. Just saying. :p > This is an argument from the Perfect/Robot programmer and is utterly false. We should just collectively face the truth that shell is not a good way to program anything non-trivial. :D Regards,
Re: [arch-general] dash as default shell?
On 18/06/2020 06.33, Eli Schwartz via arch-general wrote: > On 6/18/20 12:11 AM, David C. Rankin wrote: >> On 06/17/2020 01:18 PM, Piscium via arch-general wrote: >>> Today I set dash as my default shell [1] on two PCs. We will see if I >>> get into trouble. >>> >>> This question was asked years ago but maybe good to ask again. Could >>> dash be made the default shell in Arch? >> >> Please NO. Bash has been the default, and while there is nothing wrong with a >> Bourne-again (or Debian Almquist) type shell, it would break more than a >> decade of setups... >> >> If you want Dash, make the change after install. > > You pulled this assertion out of thin air, do you have any proof that it > "breaks more than a decade of setups"? OP is the one making an assertion, so the burden of proof is on them. That said... I suspect most the system-wide breakage that would have been expected would be due to init scripts and systemd ameliorates that to a large degree. > > Note that as has already been pointed out, any setup which it breaks is > inherently flawed, and in addition was broken on Debian, the most > popular linux distribution by sheer numbers, as well as most non-Linux > forms of Unix. > Inherent flaws in a setup doesn't mean that shit doesn't break. Ideally, yes, there would be no flaws, but this is the real world. Doubtless, we all try to strive towards perfection, but there is no such thing in practice. > It's actually in practice very unlikely that this will break anyone's setup. > > Also if you really think Arch Linux is afraid to break people's setups, > I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/ > In practice, I agree that it probably won't break much, but your arguments largely don't hold water. Regards and FWIW,
Re: [arch-general] dash as default shell?
On 17/06/2020 21.27, Piscium via arch-general wrote: > On Wed, 17 Jun 2020 at 20:19, Kusoneko wrote: > >> Pretty much this, to be honest. I don't really see the point of changing >> everyone's /bin/sh for one person's personal preference when there isn't >> really any point in doing so to begin with. > > The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, > less bugs and more security. A simple benchmark I ran with several > shells using konsole (which is one of the fastest terminals according > to my simple benchmarks): > > time ls -R / > > • dash 8.45 > • zsh 8.53 (1 % bigger) > • bash 17.1 > • fish 19.55 > > Times are in seconds, on my desktop that has a spinning drive. The > first time it takes longer as the system caches stuff so the times > above are after running a few times. I read that in some benchmarks > dash is up to 4 times faster than bash. > Sorry, but... wat? This is a benchmark of $SOMETHING, but the $SOMETHING is so far removed from any common use case that I struggle to understand its relevance to... anything. So for me the answer would be: No. (Also, stop trying to optimize the wrong things.) Regards,
Re: [arch-general] Kernel 4.19 preventing Firefox from playing videos
On 14/11/2018 17.54, Frank Zimmermann wrote: > Good evening, > > I have a very strange issue with kernel 4.19.1 With this kernel Firefox > no longer plays any videos. It opens the page but the video wont play. > It gets even worse when I open another tab. This will freeze Firefox > though system load is ok. But I cannot kill Firefox, even logging off > and on will keep it running in the background. Only way to stop it is a > reboot and shutdown will take approx 10 to 15 mins for various stop > jobs running. just downgraded to Kernel 4.18.19 and things are fine. > I'm running Gnome on a Thinkpad X201. > > KR Frank > Just another data point: (Might be related, might not...) I'm seeing something similar with 4.19.1, though it doesn't completely crash it just casues all GUI operations (even just switching windows) to become *really* sluggish until I reboot the machine. At that point firefox gets so slow that it's basically unusable -- this might be experienced as it having hung on a slower machine. I am able to quit it with regular Ctrl+Q though. Downgrading to 4.18.19 seems to fix it for me. (Running KDE on a Radeon GPU.) Regards,
Re: [arch-general] How to have multiple JDKs parallel?
On 20/09/2018 09.13, Eli Schwartz via arch-general wrote: > On 9/19/18 11:50 AM, Bardur Arantsson wrote: >> (One *hopes* that the trend will become that only the LTS-labeled >> versions will be used for actually releasing stuff to the world, but >> that the intermediate versions will be more seen as experimental. That >> would mean that Arch would only have to care about LTS releases.) > > Gosh, I'd hope the trend was instead to have modern, up-to-date releases > that actually work properly. > There's no need for snark. Java/JDK upstream take compatibility and quality *extremely* seriously. Java releases are usually incredibly backward-compatible, but a) generally the JVM world is (understandably IMO) very careful in moving from one version to next because JVM applications are usually *huge* with many many corner cases. The JVM itself + the standard class library is also quite big and it's basically impossible to do any change without *something* *somewhere* relying on the existing (possibly buggy) behavior. Most responsible developers at least try out version N+1, report any bugs upstream and wait for those to be fixed and try out version N+1 when the first 'wave' of bugs is fixed. While doing that, having access to both version N and N+1 is kind of critical. b) sometimes a new feature simply changes how something fundamentally works and the feature is (by design) incompatible with the previous state of things. This is the case for the 'modules' feature, for example: It simply not possible to both have the module classpath isolation and not have it at the same time. (It's actually possible to disable this globally, but that's kind of a moot point.) Regards,
Re: [arch-general] How to have multiple JDKs parallel?
On 19/09/2018 17.00, Carsten Mattner via arch-general wrote: > On 9/19/18, ProgAndy wrote: > >> There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8 >> and Java 11 are declared as supported until at least 2022 [1]. These >> versions may be of interest for Arch Linux. > > I'm not a Java developer anymore and probably unaware of new stuff, > and what you say makes sense. Though, isn't LTS packaging a niche > feature in Arch and wouldn't Arch follow the current latest JDK. > So JDK-LTS would be an extra package while a hypothetical meta > package like openjdk would track latest stable branch. Make sense? > In the specific case of Java 8 (LTS by AdoptOpenJDK) -> Java 11 (LTS by AdoptOpenJDK), I suspect that there will be a hard requirement for most Java developers to have support for both simultaneously on their development machines because of the whole "module" thing; see below. Of course that support would ideally come via the distribution and there's a similar precedent for e.g. the node.js LTS releases, I imagine for similar reasons to do with large incompatible changes. Anyway, if such support is not offered, I'm pretty I certainly will be forced off Arch Linux for practical reasons. Btw, even though the Java language and the byte code are very stable "formats", there Java 8 -> Java 9 module transition has been everything but trivial and has required a lot of tooling/build changes which would be really hard to do across all of the ecosystem at once and any similar change in the future could hold up a a Java N -> Java N+1 migration for a pretty long time since everybody moves at their own pace. (One *hopes* that the trend will become that only the LTS-labeled versions will be used for actually releasing stuff to the world, but that the intermediate versions will be more seen as experimental. That would mean that Arch would only have to care about LTS releases.) Regards,
Re: [arch-general] Arch Linux PC as a Remote Desktop Node
On 2018-07-27 19:46, Foxtrot Mike via arch-general wrote: > > The issue with x2go and ltsp is that I'll have to separately manage > username and passwords for local Linux login. The solution that I'd > rather prefer would use Active directory authentication so the current > system administrator won't have to do anything extra. The group policies > are already there. Once the Arch system is properly configured, I'd > disable local logins so there will be very limited chance for a user to > corrupt/modify Arch system. And ideally, the user would have no way to > interact with the local system. Thats why I want to limit the user to > freeRDP. Anything else, and the X-session expires. I'm not up to speed on the windows world, but could PAM LDAP authentication perhaps be of help here? Regards,
Re: [arch-general] Curious about arch repository policy
On 2018-03-27 22:13, Leonid Isaev via arch-general wrote: > > But I thought [core] was supposed to be self-contained, or it only used to be? > Not sure about the history here, but given the fact that most systems are bootstrapped from e.g. a cross-compiler, I don't think there's any real system that's self-contained these days. (That's not to say that it doesn't matter *at all* what's required, but it makes a lot of sense to separate "build system" dependencies from the runtime dependencies.) Cheers,
Re: [arch-general] Server Management Tools
On 2017-10-13 21:14, Karol Babioch wrote: > unexpected errors. Indeed, this is the most terrifying of messages to ever appear. You just ran a command across N machines, two of them failed. Ugh. The *BEST* case is things like e.g. "apt-get update" failing because of a spurious mirror resolution failure. (Or maybe the UDP DHCP query failed for one or two or three of your hosts?.) > > Other than that orchestration is great (Ansible, Puppet, etc.), although > it takes more knowledge and experience. > Choose this path. (I have no idea of what's best, but almost *anything* is better than "iterate through hosts and run command".) Regards,
Re: [arch-general] Leftover kde4 stuff
On 2017-02-18 02:56, Oon-Ee Ng via arch-general wrote: > I just hit a bug with okular (rarely used it and just got surprised by this) [--snip--] > > Did I miss an announcement or anything where I'd have noted these packages > disappearance and uninstalled them? Nah, I don't think so unless there's something special about these packages in particular, this is just the way pacman works AFAIUI but now that you mention it, it might a good idea to have pacman mention orphaned packages like e.g. 'apt' does. (OTOH, maybe it would be too costly to do so every time it's run. Of course one could always set up a monthly cron job to remind about packages that are orphaned.) Regards,
Re: [arch-general] Christmas gift?
Ok, mods (assuming we have such) can be we please ban this joker? Regards,
Re: [arch-general] Systemd services start by default
On 2016-12-07 23:56, sivmu wrote: > Today I noticed there were network services running on my system. > I DON'T have have permanently running network services. > WTF happened? Systemd happened! > Or rather systemd-resolved and the systemd time sync daemon. > > It seems that a recent update set those services to start by default. > > I thought I would let you know and maybe this is worth an announcement > because I won't be the only one not happy about systemd enableing > services an my system that I don't need/want. > I might be worth having a look in /usr/lib/systemd/network and reporting back what you find. Regards,
Re: [arch-general] time setting problem after installing.
On 07/07/2016 07:19 AM, Jude DaShiell wrote: > ln -s /usr/share/zoneinfo/America/New_York >/etc/localtime That's incorrect. There should be no '>' there.
Re: [arch-general] Alternative init system proposal
On 02/13/2016 04:17 PM, João Miguel wrote: >>> I feel it pertinent to point out that a different rolling-release >>> distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or >>> sysvinit. Void Linux uses runit exclusively, and thus patches projects like >>> KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody >>> has cared enough yet to put in the effort). >> Well, that's *amazing*... what does it mean for me, the user? > To me, the user, it means I there is a possibility for an alternative > init system without the devs having to do anything. It means there are > people out there working on this and work towards alternatives does not > need to start from scratch. You're on Linux: you ought not to be only a > user, but also a contributor, thus "voting" with your actions. That's > why you're on a mailing list, or at least why I am. I don't think you've presented any plausible "use case" except "I want to be different" -- which is fine, btw, but shouldn't drive development decisions in the large. I mean, if you really want to you can still write your own /sbin/init, but I'm not seeing the point here. (If your goal is to *learn*, then yes $DEITY yes, do that, but for practical things... you need some more concrete and tangible goals to challenge the decision of systemd-only for Arch Linux.) Regards,
Re: [arch-general] Alternative init system proposal
On 02/13/2016 05:35 PM, João Miguel wrote: >> (If your goal is to *learn*, then yes $DEITY yes, do that, but for >> practical things... you need some more concrete and tangible goals to >> challenge the decision of systemd-only for Arch Linux.) > The decision was to have systemd as a default, not to forbid any other > init system to be mentioned Again... no "use case" apart from "I don't want to use systemd". . I don't agree with the OP of this thread > when he said there should be an official version of Arch with OpenRC, > that's too much work. > OK, so thread over? Regards,
Re: [arch-general] Alternative init system proposal
On 02/12/2016 11:50 PM, Toyam Cox wrote: > I feel it pertinent to point out that a different rolling-release > distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or > sysvinit. Void Linux uses runit exclusively, and thus patches projects like > KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody > has cared enough yet to put in the effort). > Well, that's *amazing*... what does it mean for me, the user? I can only re-iterate: Can we please stop this thread?
Re: [arch-general] Alternative init system proposal
On 02/10/2016 12:53 PM, Jack L. Frost wrote: > On Tue, Feb 09, 2016 at 10:33:55PM +0100, Christian Rebischke wrote: >> What does this mean? It means that I prefer a linux distribution that >> supports the newest changes in the linux development. Systemd is one of >> thesee changes. Systemd improves a lot of stuff. There is a reason why all >> other big distribtions are also moving to systemd. It's the future. All the >> shellscript-based init systems are the past. > > As another person on here said, change is not progress. It's new, but it's > debatabe if it's a net positive. > "change is not progress" has no bearing on whether systemd is a net positive or not. The person you responded to explicitly said -- in the very part you quoted, no less! -- "systemd improves a lot of stuff", so clearly they're _not_ relying on the fallacious reasoning of "change = progress"... so why bring it up unless you're just being argumentative for no good reason? >> I really think that Arch Linux shouldn't be a rock in this flow of >> development. We should do it like fedora and support it. We shouldn't help >> to tube-fed all other init systems. >> >> Furthermore there will be (maybe) kdbus in the kernel. Kdbus is at the >> moment still systemd only. I am sure there will come more systemd-specific >> interfaces for the kernel. Kdbus is just one example. > > A detour from the point of this discussion, but I don't think that's a good > thing that the kernel might actually depend on systemd in some ways. Other way around: systemd may at some future point depend on a Linux-only IPC protocol. (One assumes that this would be indirectly via a DBUS-like client library, but whatever...) (Kind of ironic considering your point about ignorance.) > >> 3. The ISO and Arch Linux installation process >> If Arch Linux would support openRC we would have to offer two ISOs. One with >> systemd and one with openRC. > > What? Why? Having a handful of new packages in the repos doesn't mean anything > has to change. If you want to be extra nice about it, then maybe a separate > base group (base-openrc or something), but not a separate iso. > >> Also the way of the installation process would be different. > > Not by much. You're overestimating the whole thing greately. There's a huge difference between "I maintain systemd-free systems for my own use" and "I maintain packages for a very popular distribution". The latter has to work in a huge number of cases you haven't thought of. Anyway, can we please end this thread now? It's not constructive. Regards,
Re: [arch-general] Anyone using virtualbox-5.0.0 yet?
On 08/02/2015 02:59 AM, walt wrote: Arch updated vbox to 5.0.0 on 22 July, so I'm wondering if anyone is actively using it, and if you've had any problems with it. I certainly had a catastrophic problem when I tried it on my everyday gentoo desktop machine recently. Yes, I've been using it but it crashes my guest VMs a *lot*. It appears to be triggered by transitions to/from full-screen DirectX (in the guest). It's not a *critical* thing for me, per se, so I'm waiting to see what fun the next version brings... Regards,
Re: [arch-general] current flash vulnerabilities - what to do?
On 07/16/2015 01:37 AM, Sebastian Pipping wrote: On 16.07.2015 01:22, D C wrote: I've actually posted a thread on the forums about this. For youtube you can just use HTML5. To my best knowledge, it depends on the video / the compression algorithm used. For some videos on YouTube HTML5 works just fine, for some Videos you still need Flash. FWIW, I don't think I've ever encountered a non-HTML5-friendly video on YouTube in at least 2 years. (Granted, this is just anecdata, but...)
Re: [arch-general] systemd new dependencies impede using OpenRC
On 07/03/2015 04:31 PM, Tobias Hunger wrote: To be fair: There is more to here than Unix philosophy and I hate Lennart. STOP! Can we please end this discussion now? This no longer has anything to do with Arch Linux and is just spam (for this list) at this point. I'm sure people who are interested can find other places to discuss the merits (or otherwise) of systemd. Regards,
Re: [arch-general] systemd new dependencies impede using OpenRC
On 07/03/2015 12:19 AM, Daniel Micay wrote: WHAT? The opinion of users has no weight here ?!?!?! [--snip--] Just to add a little bit to what Daniel said: Can we please calm down a bit here? It's not like there's no overlap between what developers want and what ordinary users want -- in fact there seems to be rather a lot of overlap given the number of users Arch has. Remember that developers are users too! (P.S. I'm not a developer/packager just an ordinary user.)
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 28-04-2015 21:39, Guus Snijders wrote: Op 28 apr. 2015 21:04 schreef Bardur Arantsson s...@scientician.net: On 28-04-2015 20:39, Daniel Micay wrote: People forget vi(1) is part of POSIX so required on systems that both support the User Portability Utilities option and define the POSIX2_CHAR_TERM symbol. [ http://pubs.opengroup.org/onlinepubs/9699919799/ ] [...] It's great to have vim-minimal on the install media (which is now the case), but that doesn't mean it needs to be in base. Indeed, AFAICT the only important thing to consider here is whether the booted system is fixable from within itself if you forgot to install something during the boot from install media. (E.g. by forgetting to install *some* editor or other. Everybody likes different editors, but nano will do until you can install something better.) A very nice thing about having vi installed by default, is that you don't have to think about which editors are available. It's a unix(y) system, so vi just works. No need to remember if it's nano/pico/whatever on this specific distro. It's easy enough to add one's favorite editor when installing. On Windows, for example, i assume notepad is available, Word etc are optional (though I usually keep (g)vim on systems I use often). Oh, indeed, but frankly I never bothered learning vi beyond ESCESCESCESC:q![1], so I think an editor (like nano) that displays the obvious commands should be kept as a part of a base install. (I don't object to vi being installed by default, btw.) [1] I like C-xC-s much better, because -- obviously -- it's objectively better :p Regards,
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 28-04-2015 20:39, Daniel Micay wrote: People forget vi(1) is part of POSIX so required on systems that both support the User Portability Utilities option and define the POSIX2_CHAR_TERM symbol. [http://pubs.opengroup.org/onlinepubs/9699919799/ ] The former is probably a good idea, seeing as the User Portability Utilities option in POSIX is written to be: a requirement for a user portability interactive system. It is required frequently except for those systems, such as embedded realtime or dedicated application systems, that support little or no interactive time-sharing work by users or operators The latter is defined to mean that at least one terminal type has all user control options. Unless Arch Linux wants to be deliberately non-POSIX compatible, vi should be in base. The Linux kernel, glibc and various GNU utilities already deliberately deviate from POSIX compatibility in many ways. I don't think it's a very important consideration, just trivia. It's great to have vim-minimal on the install media (which is now the case), but that doesn't mean it needs to be in base. Indeed, AFAICT the only important thing to consider here is whether the booted system is fixable from within itself if you forgot to install something during the boot from install media. (E.g. by forgetting to install *some* editor or other. Everybody likes different editors, but nano will do until you can install something better.) Regards,
Re: [arch-general] NFS server broke after reboot - *urgent* need help
On 01/31/2015 10:14 PM, Genes Lists wrote: I have a problem where nfs failed. 2 units fail to start rpc-statd.service nfs-server.service. - rpc-statd: systemctl status rpc-statd rpc.statd[736]: Version 1.3.2 starting rpc.statd[736]: Flags: TI-RPC rpc.statd[736]: Running as root. chown /var/lib/nfs to choose different user rpc.statd[736]: failed to create RPC listeners, exiting systemd[1]: rpc-statd.service: control process exited, code=exited status=1 systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. systemd[1]: Unit rpc-statd.service entered failed state. systemd[1]: rpc-statd.service failed. - I am unable to start this by hand either - continues to fail same way. I had seen this once a month or so back - but was able to start it by hand after machine was up. - nfs-server: systemctl-status nfs-server ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2015-01-31 16:05:32 EST; 5min ago Process: 743 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=1/FAILURE) Process: 741 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 743 (code=exited, status=1/FAILURE) rpc.nfsd[743]: rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused) rpc.nfsd[743]: rpc.nfsd: unable to set any sockets for nfsd systemd[1]: nfs-server.service: main process exited, code=exited, status=1/FAILURE systemd[1]: Failed to start NFS server and services. systemd[1]: Unit nfs-server.service entered failed state. systemd[1]: nfs-server.service failed. - Machine is fully updated from testing repo. I did try kernel 3.19.rc6 but it does not help. nfs-utils 1.3.2-1 linux 3.18.5-1 rpcbind 0.2.2-1 Really appreciate some help - this is my main nfs server and I can no longer get it working ... I'm unlikely to be able to help, but it might be a good idea to try journalctl -u nfs-server journalctl -u rpc.statd etc. just to see if there's some output you've missed.
Re: [arch-general] NFS server broke after reboot - *urgent* need help
On 01/31/2015 10:32 PM, Genes Lists wrote: On 01/31/2015 04:28 PM, Bardur Arantsson wrote: On 01/31/2015 10:14 PM, Genes Lists wrote: This was original thread: https://lists.archlinux.org/pipermail/arch-general/2014-June/036617.html First, in case it's relevant: DON'T PANIC! That's the worst you can possibly do in a situation like this. Secondly, I mentioned journalctl -u, not systemctl. There may be relevant stuff in there that isn't mentioned by systemctl status (due to cutoff). Good luck,
Re: [arch-general] postgresql 9.3 - 9.4
On 01/29/2015 05:40 PM, Don deJuan wrote: From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin. You might try putting yourself in others' shoes when evaluating their opinions. Not everybody is running Arch in prod on a ton of servers. Some Arch users are just plain desktop users, or (probably slightly more likely) developers of some type or other. Also, if you're running Arch on a ton of servers, I take it that this is your day job? If so, then it *is* your responsibility to be very sure what you're doing and using canary servers, etc. to make sure nothing gets screwed up on an upgrade. Plus you hopefully get *paid* to do this. You probably also have automation tools to help you do this. This may or may not be typical for users of Arch Linux -- I honestly have no idea. Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make. Certainly, but people make mistakes (or are sometimes just plain non-perfect and non-attentive due to routine) and an extra warning pre-upgrade might be enough to avoid some significant percentage of those mistakes. Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability? I think the OP actually admitted that he made a mistake? Know the software you run, dont let the software run you. AFAICT, blaming the user for lack of user-friendliness is exactly let[ting] the software run you. *Shrugs*... As it is this thread has stopped being constructive, so I'm out.
Re: [arch-general] postgresql 9.3 - 9.4
On 01/29/2015 02:24 PM, Martti Kühne wrote: On Thu, Jan 29, 2015 at 2:22 PM, Bardur Arantsson s...@scientician.net wrote: On 01/29/2015 01:00 PM, Martti Kühne wrote: On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne mysat...@gmail.com wrote: You could also write a pacman wrapper that interferes with pacman's execution upon specific output. (Doesn't scale to more than one user since nobody else is going to be using that script.) Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like. To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update. Uh, there's a difference between a) We *know* that upgrade X will break your system and/or require manual intervention. and b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention. So, my script doesn't scale and your notion of 'we' does? How comes? I think we may have a language barrier -- I have no idea what you're getting at. I said doesn't scale up to more than one *user*. We = package/pacman owners/developers -- this *does* scale to all the users of Arch Linux. Was this not clear? I'm not saying the developers/packagers have infinite reasources, I was pointing out that it might make sense and be worth the effort to implement something (process/pacman support/whatever) which would scale to all the users of Arch Linux and could hopefully be specified in-package once and for all for known cases where upgrades WILL break things.
Re: [arch-general] postgresql 9.3 - 9.4
On 01/29/2015 01:00 PM, Martti Kühne wrote: On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne mysat...@gmail.com wrote: You could also write a pacman wrapper that interferes with pacman's execution upon specific output. (Doesn't scale to more than one user since nobody else is going to be using that script.) Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like. To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update. Uh, there's a difference between a) We *know* that upgrade X will break your system and/or require manual intervention. and b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention. This was clearly a case of the former and not the latter. The risk tradeoff between doing an upgrade when you know you're in case a) vs. case b) is also drastically different -- though, yes, would could always end up with a broken system even in situation b). I don't see how pacman warning the user explicitly that they're in siutation a) is somehow a huge problem. AFAICT it has also been the practice to post notices at least on archlinux.org for all the breaking updates that that were known of ahead of time. (Obviously, I can't know if that's actually true of things that wouldn't have affected my particular set of installed packages, but...) Georg's request seems eminently sensible to me. If the problem here is that it would be a chore to do this for maintainers for every X.Y - X.(Y+1) upgrade, then maybe Arch package descriptions could grow a field or flag to handle such things semi-automatically? Maybe something as simple as if the version number is about to change in *this way*, then warn loudly using *this message*. Regards,
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On 2014-12-16 19:58, Sebastiaan Lokhorst wrote: Hello everyone, Since more than a year now, fdisk (provided by util-linux) has had GPT support. This theoretically makes gdisk a duplicate of fdisk, and we could replace gdisk with fdisk. Now, I'm not asking to drop gdisk or anything like that, but in an effort to clean up the Beginners' guide of the Arch Wiki, we want to use a single partitioning tool for both MBR and GPT partitioning instructions.[1] util-linux fdisk is able to provide this functionality, but we are not completely sure if it is stable by now (it should be, I think). Speaking from complete ignorance... do significant numbers of people still use MBR for non-obsolete platforms/machines? Regards,
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On 2014-12-16 20:23, Jakub Klinkovský wrote: On 16.12.14 at 20:15, Bardur Arantsson wrote: On 2014-12-16 19:58, Sebastiaan Lokhorst wrote: Hello everyone, Since more than a year now, fdisk (provided by util-linux) has had GPT support. This theoretically makes gdisk a duplicate of fdisk, and we could replace gdisk with fdisk. Now, I'm not asking to drop gdisk or anything like that, but in an effort to clean up the Beginners' guide of the Arch Wiki, we want to use a single partitioning tool for both MBR and GPT partitioning instructions.[1] util-linux fdisk is able to provide this functionality, but we are not completely sure if it is stable by now (it should be, I think). Speaking from complete ignorance... do significant numbers of people still use MBR for non-obsolete platforms/machines? The Beginners' guide still applies to people with obsolete hardware... Oh, sure, but maybe such complications should be pushed to a subpage? I'm not sure why you put obsolete in quotation marks...? I have a machine from ~5 years ago that has no problem with GPT. I certainly understand that we should strive to support old hardware and such *as long as it makes sense effort-wise*, but perhaps the Beginner's Guide is not the place to do that? (Beginners are perhaps likely to have reasonably up-to-date hardware, etc. etc.) (I don't feel strongly about it, so whatever. Just offering it as a PoV.) Regards,
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On 2014-12-16 20:40, Patrick Burroughs (Celti) wrote: I had to use MBR on a relatively recent machine because the supposedly-UEFI firmware refused to even recognise GPT disks, let alone boot from them. It's still relevant. Interesting. Care to name-and-shame said firmware? (I don't necessarily think it influences the decision, even so. Surely the Beginner's Guide should be optimized for the common case rather than edge cases, as yours probably was?) Regards,
Re: [arch-general] How do I _really_ fix the superblock?
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--] I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways. Please don't insinuate conspiracies without good evidence. IMO there's no valid reason not to chose local time. Here's a reason: A time zone is for *DISPLAY PURPOSES ONLY*. UTC is well-defined for machine time (which is a continuum), but local time may not be continuous -- there are holes and overlaps in a local time depending on daylight saving time. Always use UTC unless you have absolutely no other choice. Regards,
Re: [arch-general] Why is it dangerous to run makepkg as root?
On 2014-05-17 14:40, Roland Tapken wrote: Hi, I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question: Why is it considered dangerous to run makepkg as root? My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package. Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman), there is a slight theoretical advantage to the current behavior in that if you never run $NEW_PACKAGE *as root* then your system cannot be compromised quite as extensively as if you had run PKGBUILD as root (which would allow completely arbitrary commands as root, either through a malicious PKGBUILD or other attack channels such as an exploitable gcc, etc.). Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd only have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything. Regards, /b [0] Actually, there have been quite a few local user - root exploits of the Linux kernel, so really you should wipe everything and reinstall from scratch anyway. Remember, I'm only speaking theoretically in the above.
Re: [arch-general] Why is it dangerous to run makepkg as root?
On 2014-05-17 21:50, Roland Tapken wrote: Hi Bardur, Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman), Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script? I always thought that this package needs users X,Y and Z was handled via some metadata in the package description, not via scripts per se. Maybe I'm wrong on that too. Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd only have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything. Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation. Ah, yes. True, of course. I knew I'd missed something! :) Regards,
Re: [arch-general] Why is it dangerous to run makepkg as root?
On 2014-05-17 22:08, Bardur Arantsson wrote: On 2014-05-17 21:50, Roland Tapken wrote: Hi Bardur, Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation. Ah, yes. True, of course. I knew I'd missed something! :) Hm. Rethinking this I was going to say something about listing (and screening) all the files that a package *would* install, but it seems that it's not possible to list files installed by a package before installing it...? (pacman -Ql only accepts installed packages, apparently.) Regards,
Re: [arch-general] Why is it dangerous to run makepkg as root?
On 2014-05-17 22:55, ushi wrote: Am 17.05.2014 22:08, schrieb Bardur Arantsson: On 2014-05-17 21:50, Roland Tapken wrote: Hi Bardur, Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman), Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script? I always thought that this package needs users X,Y and Z was handled via some metadata in the package description, not via scripts per se. Maybe I'm wrong on that too. Such things are handled via install scripts[0], called by pacman when (un)installing/upgrading packages... and yes, packagers can put arbitrary code in there. (postfix exmaple[1]) I see. Good to know. The premise for my whole hypothetical was thus dismissed and I hang my head in shame ;). Regards,
Re: [arch-general] My Apache Sever Compromised?
On 2014-04-09 19:32, Jameson wrote: On Tue, Apr 1, 2014 at 9:30 AM, Nowaker enwuk...@gmail.com wrote: 199.83.93.35 - - [29/Mar/2014:22:04:54 -0400] GET http://ro2.biz/pixel.png HTTP/1.0 200 151 But the most interesting part is that your apache is replying with 200, that is OK! Nice catch! It's certainly a proxy. Thanks for everyone's help with this. I did in fact have ProxyRequests set to On thinking it was needed for reverse proxies as well, and have turned it off. Now, when I open up port 80, it looks like they're still trying, but I'm replying with 404. Is that what it should be doing? I probably also need to make sure I have some throttling setup in case this is too much for my Internet connection. One approach I've seen mentioned and which seemed fun, but -- I hasten to add -- have never personally tried is to start returning shock site images for all such requests (obviously not for all 404s, just attempts at abusing you as a proxy). Regards,
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On 2014-04-09 09:07, Magnus Therning wrote: Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. It should be noted that cabal-install isn't a package manager in the true sense[1]. I'm not sure this is an argument against making the change you propose, but it's worth noting. With sandboxing/hsenv I've actually found cabal-install it to work much better than attempting to use distro packages for some libraries. (There error messages for stuff that requires native C libraries aren't always stellar, but that's something you quickly get used to.) There are quite a few other language/frameworks that have language-specific build/package systems, Python, Ruby, Perl, node.js... Are Python developers on Arch pointed towards using pip to install Python libs? I can only speak to node.js, but I think the general consensus there is to only use the distro-provided node.js and npm and then have user-specific/project-specific node_modules directories. (This is driven in part by npm's design and the extreme pace at which the ecosystem seems to be moving.) Given the limitations of GHC when it comes to module interoperability between versions, I think this approach makes sense for GHC too. (Btw, there's work afoot to adress this, but it's probably a few years off: http://plv.mpi-sws.org/backpack/ ) I think sometimes the right thing is to point users to another package manager, e.g. packaging vim scripts for system wide installation is a bit silly, since installing a vim script affects ALL users on the system. So doing that would require providing some sort of vim-script manager to users. Then there's very little difference compared to just telling users to use Vundle/Pathogen/whatever directly instead. However, this isn't the case for Haskell/GHC... AFAIK (and unfortunately) globally installed Haskell/GHC packages can greatly constrain what other packages you can install in a sandbox. That's been a huge problem for me in practice, which is why I personally always install ONLY ghc and cabal-install and use cabal sandboxing/hsenv for the rest. (Did this on Ubuntu as well when I was a user of that.) I think it would be a good idea to strip everything back to just having GHC and cabal-install in the base and to take some time to rethink how packaging everything else should work. I don't know if Cabal supports such a thing, but one idea off the top of my head for a new approach would be to have a distro-provided read-only *sandbox* which other read/write sandboxes could be *overlaid* on top of. That would mean that you could opt out of the distro-installed packages if you need to, but could still install distro packages if you, e.g. wanted/needed a Haskell program which depended on having haskell packages installed (git-annex?). Crazy idea? Regards,
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On 2014-04-10 06:39, Thomas Dziedzic wrote: On Wed, Apr 9, 2014 at 8:12 PM, Allan McRae al...@archlinux.org wrote: Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead? I wouldn't actually be opposed to this idea. A lot of effort is duplicated with regards to Archlinux's official haskell packages and Arch-Haskell's packages. We could try to work out something between the existing haskell package maintainers and arch-haskell maintainers. It might lead to a possibly better overall haskell experience on archlinux. Arch-haskell could maintain official haskell packages using pacman. I (and anyone interested) could support haskell package installation using the cabal-install route. Would this mean that only ghc and cabal-install would be in any of the official repos and that everything else would be relegated to arch-haskell? If so, then +1. (As mentioned in another email I think Haskell distro packaging in general could use a rethink, possibly based on sandboxing.) Regards,
Re: [arch-general] Problem with cups 1.71 when restart service
On 2014-02-04 16:54, Maykel Franco wrote: Thanks for your responsed. The problem isn't cups not start... The problem is cups not printed... This is a long shot, but have you installed an updated kernel without rebooting? Regards,
Re: [arch-general] Fwd: Proposal for the static library problem in Arch
On 2013-09-28 23:50, Dan Liew wrote: [1] 11.4.2. LLVM is a Collection of Libraries http://www.aosabook.org/en/llvm.html My last reply was flippant. Apologies for that. However, I don't see any mention of why static libraries should supposedly be better for LLVM at the above URL. Can you direct us to a specific section/sentence/whatever of that document? Regards,
Re: [arch-general] Fwd: Proposal for the static library problem in Arch
On 2013-09-28 23:50, Dan Liew wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/09/13 19:32, Thomas Bächler wrote: Am 28.09.2013 16:26, schrieb Delcypher: I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro This has been discussed more than once, always with the same result. Static libraries are a dead end and are going away. I think it's a shame people think that static libraries are completely dead. Although I agree that shared libraries are usually preferable to static libraries there are circumstances where their use is warranted (e.g. building portable executables). I would also be remiss if I did not point out a prominent software project that I doubt will ever switch to using shared libraries completely which is LLVM. [1] explains the reasoning behind using static libraries which is completly sensible. I notice that the Arch llvm package still has it's static libraries. Just my two cents. [1] 11.4.2. LLVM is a Collection of Libraries http://www.aosabook.org/en/llvm.html I don't think static library means what you think it means. $ ldd `which clang` linux-vdso.so.1 (0x7fff933fe000) libLLVM-3.3.so = /usr/bin/../lib/libLLVM-3.3.so (0x7fd694c3c000) ^^ libpthread.so.0 = /usr/bin/../lib/libpthread.so.0 (0x7fd694a1e000) libstdc++.so.6 = /usr/bin/../lib/libstdc++.so.6 (0x7fd69471a000) libgcc_s.so.1 = /usr/bin/../lib/libgcc_s.so.1 (0x7fd694504000) libc.so.6 = /usr/bin/../lib/libc.so.6 (0x7fd694159000) libz.so.1 = /usr/bin/../lib/libz.so.1 (0x7fd693f43000) libffi.so.6 = /usr/bin/../lib/libffi.so.6 (0x7fd693d3b000) libdl.so.2 = /usr/bin/../lib/libdl.so.2 (0x7fd693b37000) libm.so.6 = /usr/bin/../lib/libm.so.6 (0x7fd693834000) /lib64/ld-linux-x86-64.so.2 (0x7fd696502000) Regards,
Re: [arch-general] Arch mailing list for subjective discussions
On 05/18/2013 08:34 PM, Joan Rieu wrote: 2013/5/18 Ralf Mardorf ralf.mard...@alice-dsl.net This comes into my mind, when I read a statement about the policy of Mint, thread: Fully wroking GTK3(+GTK2) theme for Gnome 3.8? E.g. desktop environments require sometimes discussions that IMO don't belong to Arch general, but there perhaps is the need to compare notes. Hi Ralf, IMHO, the example you give explains why using the forum would be more appropriate. Long technical discussions are of course interesting, provided you care about the topic, which is not always the case. What this means is that you might start receiving tens of emails that you really have no interest in. You might say you're not forced to join the ML, but I think it's not an option since some topics will be of interest to me for sure and I would like to follow those. There are two solutions to this: a) Use a mail reader which can actually handle a larger mail volume more sanely. (Filters, or a mail reader which can kill threads so that you don't receive future replies on a given thread, etc.) b) Use Gmane.org to give you an NNTP interface to mailing lists and use a news reader -- high-volume lists is what NTTP and news readers were meant for. (I'm using Thunderbird.) It's trivial to set up and effortlessly lets you follow along in lots and lots of mailing lists without having to set up any mail client magic. On the other side, a forum allows you to focus on the discussions you really care about, and you can just ignore the irrelevant threads. You still have to actively go to the specific Arch forums to keep up with replies, etc. There's no unified show me everything new in all the forums I'm a member of page where I can go to keep up. That's a much bigger problem for many mail-oriented users than setting up a filter or two. Regards,
Re: [arch-general] Arch mailing list for subjective discussions
On 05/19/2013 10:44 AM, Karol Blazewicz wrote: You still have to actively go to the specific Arch forums to keep up with replies, etc. There's no unified show me everything new in all the forums I'm a member of page where I can go to keep up. You can subscribe to rss feeds of these forums and your rss reader will then show you everything new in all the forums I'm a member of. Good point, but that needs the forum to support it(*) and leads to a proliferation of RSS feeds. IME feed readers aren't as good as handling large numbers of subscriptions as news readers, so I always prefer the NTTP way :). You can subscribe to individual threads, so you shouldn't miss replies - you'll get an e-mail notification. IME this is even more annoying -- you usually can't reply directly to such emails and it's often a multistep process to be able to reply (requiring login, and so forth). Regards,
Re: [arch-general] GHC 7.6.1 now in [extra]
On 10/09/2012 06:11 AM, Thomas Dziedzic wrote: Hey everyone! It's that time again for arch to get the latest ghc! GHC 7.6.1 comes with a bunch of new and exciting features: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html It took just over a month to do the full rebuild because of the amount of patching and coordination with upstream we had to do. I would like to thank everyone who worked on this rebuild! Cheers! (Apologies if anyone should receive this twice. I apparently fail at mailing lists.) Unfortunately, Cabal and cabal-install seem to be rather badly broken at the moment. I've filed a bug at https://bugs.archlinux.org/task/31864 with more details. Regards, (and thanks for the hard work to all involved!)
