spinax

It's especially bad on a site like HN - an account only gets a downvote capability if they've received what is it, 400 upvotes? - so you're assured that every downvote you receive is someone who says lots of things other people like to upvote (or are a serial link poster getting link karma upvotes).

There is an echo chamber here based on how the downvote rules work, and I've watched people's comments get brigade downvoted in minutes for posting a well written post like yours which goes against what all the "cool kids" think. And unless you run at the mouth to become "liked", you don't get the chance to disagree with your own downvote.

I had to dig a little bit to get a better view of "will this make a mess of my email if I try/test it without commitment?"; the tl;dr is basically:

(a) there is a DeltaChat subfolder in your IMAP storing the messages;

(b) the app looks for a "Chat-Version" header on emails to know to move it to (a) folder (and you can set a server side rule to also do that);

(c) a number of popular email providers (IMAP is used) are listed with some notes to help you get started: https://providers.delta.chat/; and

(d) it's using the Autocrypt/PGP standards and you can apparently import your existing PGP key if you want

It's all in the FAQ or other docs, just highlighting the things which I wanted to know straightaway before making a mess by accident just to give it a try.

F-Droid builds in batches, about 3 days per batch (see monitor.f-droid.org). All the APKs are signed at once and published together so it should show up soon. Per the dev, the last beta is essentially what became the stable release so you could start today and just upgrade in a bit.

Not only is the new stable there, cketti has been posting all of the betas leading up to this on F-Droid for quite awhile. :) You have to manually look once in awhile in the F-Droid client for newer beta builds to opt into using.

Whoogle is a Google anonymizer and stripper-of-chaff, searx is a content aggregator on top of that same concept. While similar in the first context, searx provides a secondary layer of interacting with many search engines for well rounded content. Nothing wrong with whoogle, just not an exact 1-to-1 comparison. (cannot speak to your issues with speed and bugs, I suggest opening an issue on their Github and explaining your problems or a dedicated user forum maybe reddit?)

Just to share for readers, what are your personal RAM/CPU/disk usage measurements? The instance I use is shared with a small group so my numbers above may be skewed.

Ctrl+F shows nobody has mentioned searx yet, so let me - you can have your cake and eat it, too. searx uses modest resources (2G disk/2G RAM, cloud server friendly) and gives you all the results from all the search engines without being tracked in your end-user browser.

Here are some existing public instances to get started (visit Preferences! You can choose your own search engines!) and there are many, many more not listed on this page out there:

https://searx.space/

Give searx a try - what I like most is that it sees the same top result from 2 sources (say, Google and DDG) and places them as a single entry as first, but then offers a link that neither one of those had (say, Mojeek) as the second result. It actually helps you find more content by spreading out your searches to many engines at the same time and giving the best results grouped.

vim: https://github.com/chrisbra/vim-autosave

Not only simple browser plugins per the other reply (and a plethora of non-crashing mobile apps, whereas mobile PDF reading apps crash on me all the time) - the ePub format is just a zip file in disguise with plain text (HTML) inside and maybe some images/etc.

In a manner of speaking, ePub as a design has an inherent built-in fallback mechanism to manually obtain the internal content in case of failure - including ability to try and repair a broken zip format (zip -F/-FF) and grep it in place (zipgrep).

nod I think these are two branches of the tree and this problem is more in line with role disclosure (I'm not saying this well - for example, the need on job postings to list the actual salary range up front, like I know some non-US countries and I think recently Colorado? implemented into law).

The branch of this problem tree I speak of intersects more like "OK the band for level 3 is 50k-60k USD. Mark makes 60k and I make 50k but I feel my work is better than his and I've been here longer." This article is mostly about individual sharing, I think that quoted part is a nod in context to the other branch of the problem root which is just as important in it's own way. Not the best at making up examples, sorry.

These articles never seem to touch on the point which matters to me: I don't want the workplace social peer pressure of who makes more, or less, etc. and the drama which comes with it. The belief that every employee wants there to be open sharing of salary data is not universal.

US: quick search says Yes, at one time however it's was abandoned in 1994: https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:gm...

Current US trademark holder is a financial group: https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:gm...

Edit: it appears the USPTO has sent a notice refusing activation on the above due to requirements not met if I read this correctly: https://tsdr.uspto.gov/#caseNumber=88758894&caseType=SERIAL_...

Completely understood by me, hopefully I said this in a way that was productive. :) Per-app passwords have their use cases and I think techs have been banging on it in open source for awhile, example: https://www.happyassassin.net/posts/2014/08/26/adding-applic...

Use case: I have an unattended cron task polling my IMAP account to archive the mail every 4 hours. I specifically use an IMAP read-only unique ("per-app") password for that script/connection; under no circumstance should that password have access to write to IMAP, touch POP or SMTP. Fastmail allows me to do this with ease, and I can create as many as I'd like with different ACLs. The mxroute reasoning simply does not consider all the use cases people have and want per-app passwords for to increase their personal security posture.

> For those who want multi-domain email services for a lower (flat) price, look at mxroute

I was very interested and very seriously considering signing up, until I read this: https://mxroute.com/docs/do-you-support-2fa-on-email-account... While I respect Jarland's opinion/stance, I do not agree.

H&R Block wanted to upcharge me additional $$ just to fill out a Schedule D on top of the $$ tier fee (the past few years these forms were included in that tier price). They lost a long term (10yr?) customer by trying to grift me this year.

I used https://www.taxslayer.com/ instead this past year, a bit more DIY but if you've done your taxes for years and they're generally the same year after year it's not that hard to read your docs and type them in the boxes. You pay for Support level, not tax form access with this service.

It has been my career experience that 5+ digit employee companies more resemble Chiba City than they do the USS Enterprise.

System Ops (at scale, large company, lots of teams) in a nutshell: you did not build the system or choose what kind, it was most likely installed using vendor defaults by the systems owner and you were called in because it's misbehaving. Most likely 50 other people have touched various parts of it, some with skill some without.

"Give me an IP, username and password - what OS is it?" are about all you start with and go from there. It's probably a critical system to someone, and everyone swears on a stack of bibles that nobody did anything, touched anything or made a change. You have very specific domain knowledge (kernel, grub, SAN/storage, systemd, dbus, etc.) and typically ask a lot of questions to the systems owner as your fingers are flying ruling out reasons (low hanging fruit common issues).

> added a log trimmer config for squid

I feel your pain - I'm curious, was it a drop-in /etc/logrotate.d/ config which was sending a HUP? I don't run squid but Google'd up that it will take a USR1 to rotate logs which should not close the HTTP connections (allegedly HUP closes them). Perhaps the AL2 folks chose the wrong signal? https://wiki.squid-cache.org/SquidFaq/InstallingSquid#squid_...

> You can run gunzip < /mnt/brokensystem/var/log/messages.1.gz from that other working OS to read text logs; you can also run journalctl --root /mnt/brokensystem to read journald logs.

It's subtle, and you've accidentally missed it like many do - you made an assumption that everything logs through journald. On my personal system where I do not have rsyslog (aka trying to live the journald life) I have non-journald text logging for: httpd, sa (sar/sysstat), lightdm, audit, atop, Xorg, cups, fdsync and samba. If we just stick to httpd, sa and samba (most folks know how those work) it shows how logging is way more complex than what is captured in the journal - these apps by design maintain their own logs.

So now you launch your rescue ISO (let's assume modern sysrescuecd which has journalctl) and get your filesystems mounted, you have to employ two different techniques - journalctl for that single-use format and then your traditional find/grep skills for everything else. You don't know why it crashed, how it crashed and are on a fishing expedition. Was it an RPM upgrade? (logged to yum.log or rpm.log, not journald) Was it update-initramfs running out of disk space truncating your initrd? (sometimes logged to journald depending on distro, sometimes not). Don't know until you start following breadcrumbs, find/grep is the superior toolset (much like the trebuchet is the superior siege weapon).

It's not that you cannot do it, it's that journald-only (no rsyslog) forces using a specific method with specific tools to access what should be extremely easy to access data. Keeping logging all in the same format (text) is what I want, it's not that I don't know how to use journalctl; I don't want to use journalctl, it's a pig in lipstick.

> (Not to mention UNIX has log files that have been in a binary format since time immemorial, like utmp and wtmp.)

I agree with this, they belong over in /var/lib/ somewhere and those files bug me, always have. "Just because these other guys did it" is however a logical fallacy, they are (IMO) just as wrong because they're more like database files than they are logs in my opinion. (the secure/auth.log is more a "log")

As a systems guy with a focus more on ops, I agree. It's not all roses - journald/journalctl and binary logging can go die in a pit of fire for example - however setting LimitNOFile= in a unit is just really, really nice (as well as CPU limits and all sorts of other cgroup/namespace needs). But let me just mention again that journald/journalctl can go die in a pit of fire - if it wasn't for everyone adding rsyslog to create regular text files we would be a world of hurt. But in return we get almost complete, painless cgroup level handling right in the unit file with a simple key=value structure (so really, you don't have to know anything at all about cgroups or namespaces to be very effective). Most options have a doc for them - it's usually easier for me to find an obscure systemd setting with a nice blurb about what it does (in non-programmer speak) than it is to dig up an obscure sysctl setting, e.g.

I can/could do without timesyncd and resolved (it's easy - just use chrony e.g.) but I like udevd being now part of systemd. It would be nice to not write /etc/udev/rules.d/ and instead have a foo.udev unit type, perhaps that is in our future (we do have .device units, but it's not the same - yet? the future). In this ballpark I think it's more on each distro picking and choosing - Ubuntu for example drank the kool-aide much deeper than RHEL - RHEL for example uses chrony out of the box, not timesyncd. However udevd and logind seem to be common across all distros now, as another user commented the KillBackground=yes setting in logind is just horrible to have as a default. The whole "homed" thing makes me sad that it's even being coded, I hope nobody adopts that (I dislike it for the same reason I dislike automount); someone out there wants it though.

The ability to dynamically edit a unit (systemctl edit) and to dynamically alter the running service constraints (systemctl set-property), all PID file type needs are handled in /run (getting rid of the nasty SysV stale unexpected crash reboot pid problem which many scripts failed to handle properly). Users having the ability to use their own private init items (systemctl --user) is great - timers, socket activation, custom login units, all very well extended down into the user's control to leverage. I'm sort of 50/50 on cron vs. timers, that's more of a use case by use case decision (example: tossing a https://healthchecks.io "&& curl ..." is just a lot quicker and easier in cron, but running a dyndns script on my laptop with a timer is nicer).

Touching on systemctl edit, it's really easy now to show folks (think a DBA team who only has the fundamental ops skill) how to quickly chain their After= and Before= needs for start/stop of their (whatever) without having to go down a rabbit hole - it's simple to use, the words and design are accessible and familiar, the method by which it works is a little obtuse (it's rooted in understanding the "dot-d" sub-include design pattern). On RHEL at least it uses nano as the default editor, annoying to me but good for casual non-vim users and easy enough to override using $EDITOR.

I used SysVinit for all the same years as everyone else (Solaris to Debian to Red Hat, ops touches it all) and wrote many my fair share of complex init units to start DB2, Oracle, java appservers (anyone remember ATG Dynamo?); systemd handles natively what 75% of that work was/is (managing PID files, watching/restarting failures, implementing namespaces/cgroups, handling dependency chains, etc.); for those complex scenarios (looking at you, Tomcat) you can still just have a unit launch a very complex shellscript "like in the old days". I haven't looked in awhile, but last time I knew in RHEL7, Red Hat did exactly that with Tomcat - just had the systemd unit launch a script.

It is, however, a real bear to debug sometimes - it's far easier to "bash -x /etc/init.d/..." and figure out what in the world is going wrong than it is to debug systemd unit failures. But, the same holds true for trying to debug DBus (if you've never tried / had to, it's not fun at all without deep dbus knowledge). I would like to see the future add more ops-oriented debugging methodology - if you've every used "pcs" (the commandline tooling for Pacemaker offered by RHEL), we could really use "systemctl debug-start" type of interfaces to the commandline offer the same experience as "bash -x" days of old. There are debug settings, they're just not ergonomically dialed in for the ops user, IMHO - systemctl debug-start would save people a lot of headaches.

Quick bootstrap: you normally want a "helper" to handle downloading things and running the compile steps (it can all be done manually, and in fact you have to bootstrap yourself the first time that way). I prefer this one, pikaur, due to how well it integrates (looks and feels like pacman) and has a rich featureset: https://aur.archlinux.org/packages/pikaur

After getting that downloaded, compiled and installed then try a sample simple AUR package like "downgrade" - `pikaur -S downgrade` - to get feel for it. https://aur.archlinux.org/packages/downgrade/ It really is kinda that simple, the rest is just learning the basic "how are Arch packages actually made?" which is a good thing to learn in general.

RedReader is a fantastic reddit mobile client for Android - they are rolling out a new version right now with a ton of community contributions (both bugfixes and new features).

https://old.reddit.com/r/RedReader/comments/o7oxdu/version_1...

> If I type in `apt update && apt update -y` I can be sure that my computer will be usable after a reboot

As from my other replies, that's awesome - you're looking for a usage paradigm that is not what Arch is for; it requires attention and regular maintenance, and "keeping up" on a regular basis. You've hit the nail on the head with the followup sentence, you have to be willing to spend a day every now and then keeping up.

Arch is not for people who want to ignore their system and hope it all just keeps working, then update 700 packages all at once and have it come crashing down. There is an agreement (the social kind, not the legal kind) you enter into when using Arch that you actually engage with it on a regular basis because you like doing that and like to tinker. It's build for experienced Linux techs who like to engage on a regular basis with the plumbing.

> I had 700 packages or so updating

You absolutely ignored your Arch system for far too long and most likely missed important News notifications that manual actions were required, it happens now and again. With updating 700 packages at once you've just dug yourself a hole - Arch is not a system you can ignore for that long, by design it's always changing to reflect the newest upstream changes to software. As I posted to the other person, if you want a distro to ignore over time then Arch is not for you.

This is part of the agreement for using Arch, it's not a system you can ignore, you must actually pay attention to these news items. The upgrade tool I use actually shows new news to you front and center when performing an upgrade so you're blatantly aware that you have to follow instructions. Those are not "problems", they are "following instructions to keep up with changes." If you wand a distro to just ignore and hope it all goes well, Arch is not for you. Never was.

Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it.

The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them.

You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.

> Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.

I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.

I agree, RPM is similarly just as easy amongst others who all sort of stick to a single control file design. This exact DEB ergonomic pain of files all over the place keeps me at arms length, it's clunky (to me) and the build process weirds me out with how many variations on tools used to get the same result. It's backwards compatible as all get go, I'll give you that.

Real life +1, Google is used for the basic Android setup needs and that's it, all other needs are non-Google services (well, technically NewPipe is Youtube because who doesn't like a good cat video). One key app most people will want is DAVx5: https://www.davx5.com/ (also available on f-droid)