There seems to be a mass downvoting scheme on HN lately. I don't know who's behind it and what their motives are but I constantly see valid comments made within the last five minutes greyed out.
I made this post and it died on its arse initially, didn't even get an upvote. The second chance pool meant that it turned into a useful discussion about a pretty niche element of frontend development.
Not sure why you say this. I've been using Brave for years, and after spending like 20 seconds to turn off the 'show on new tab' things, I get a blank page ( well, with a random photo background ) when I open a new tab.
being an argument in favor of Firefox. I have to use Firefox every once in a while and I'm always surprised to see the garbage they peddle on the start page. I know I can turn it off but I never use it enough to bother.
Because paywalls are trivial to bypass and it's exhausting hearing people constantly complain about them. The GP in this thread has been on HN for 10 years. They should know how to bypass it by now. Hell, four minutes after they posted someone posted the bypassed link.
> In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.
Interesting. At the time, the vote count was notably low given the post age, and there were no comments IIRC. So my thought was, to avoid the poster thinking "well that didn't work - I guess HN didn't like this - doesn't want future similar posts from me", by noting an engagement funnel bounce step they may not have been aware of. Given that paywalls are often probabalistic UX. Sort of using an empty comment thread as TFA poster DM channel?
Hmm. So, maybe, if my comment had noted the age/vote pair, and was clearer about the motivation for mentioning the paywall, that would have been less likely to create a meta discussion? And perhaps been consistent with the "don't post complaints about paywalls" policy?
> The answer, plain and simple for any 5-year-old to see, is
Read it later. If you can't read it at work, you can read it on your phone or after work from another computer.
Also, the guidelines and FAQ are both easy to read, and shouldn't be blocked by any CMMC nonsense at your office if HN itself isn't blocked. This one is a useful guideline for people like you, whose shouting makes you seem like a crazy uncle sending emails from your AOL account:
> Please don't use uppercase for emphasis. Instead, put *asterisks* around it and it will get italicized.
"Read it later. If you can't read it at work, you can read it on your phone or after work from another computer."
Negative, as I have ZERO TIME when working with things involving security.
"Please don't use uppercase for emphasis. Instead, put asterisks around it and it will get italicized."
Yea, no. See your asterisks didn't italicize. I'm looking at your comment right now, with screencap in clipboard buffer if you need a pasted proof of this formatting not working - https://imgur.com/a/7TzQOKw - No italics there. Unless the > at the beginning indicates (stupidly) to ignore formatting rules placed after it, your comment has zero formatting outside of regular spacing.
But you see, I was already aware that function didn't work reliably. Which is why I will continue to use caps for emphasis as it's guaranteed to work.
Some things are worth an alias, or a script, some things aren't quite worth either but you still wanna run them again in the future. I think that's where history helps. Awkward niche one-liners. Also sometimes you do something for the first time, take a bit to figure it out, then 6-12 months later it's easier to check your shell history than relearn the process from scratch again. Also sometimes you may want to run something new that's very similar to an old thing you ran, like maybe you forget which rsync args you've been using lately and you wanna use the same ones but on different files. Search up your last rsync, edit paths.
I used to start my history over with each PC, but last year when I upgraded my primary machine I decided to copy over my browser history and shell history in addition to the usual dotfiles and stuff. It's honestly been really nice and convenient. It almost feels like cheating that I can see stuff older than the machine that I did.
>Some things are worth an alias, or a script, some things aren't quite worth either but you still wanna run them again in the future
I think the bigger problem is that sometimes it's just hard to know upfront exactly what is worth an alias or a script. It may at the time seem like something you'll not need to bother with again and then it turns out a year or two later you have to deal with it a fair amount. I guess one could be in the habit of just always documenting absolutely everything and doing aliases/scripts by default but as a practical matter that's a great deal of time given that many one-liners truly genuinely are one-liners that really won't ever get used again.
Automated history recording helps fill that gap. If you find you do need something again down the road that was a certain amount of effort to figure out the first time, the second (or third or whatever your heuristic is) time is when you can make an alias or script for it. Having the history on-hand simultaneously helps give a jumping off point and helps one decide that yes, actually I better formalize this because I had to do it before on dates X, Y & Z.
Same here, atuin is such a time-saver, especially when it comes "oh dang, I ran this command on another host but I need it here now". It just works as you'd expect!
Why do you care about 99.99% garbage when it's useful exactly for those .01% gems?
You don't look back at history, you search for it or it pops automatically
For example, for a command you run once a year you've spent your time researching proper use and created this invokation you'll never remember:
app -x +e -lsadfjku --avoid-footgun old new # maybe valuable comment/search tag for future you
then next year you just type app and have the autocomplete / search for app. Boom, history value received! No need to repeat the research process all over again
His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.
Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run.
The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web.
The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.
Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
reply