staticshock

Because it got voted up by people who found it interesting

As a rule of thumb, when the pause between two adjacent sentences implied by the period seems a bit too halting, try a semicolon.

I find it easier to think about the utility of semicolons from the perspective of individual sentences to be combined. And therefore, if a properly used semicolon were to be replaced with a period, the two resulting sentences should still make sense in isolation, they'd just feel ever so slightly too far apart.

"Semicolons bring the drama. That's why I love them." Does it work? Yes. Is there a clear through-line from one sentence to the next? Yes. Does the pause between the sentences feel a bit too abrupt, though? Maybe!

("Establish clear through-line" can be another nice reason to combine sentences with a semicolon.)

Ignoring for the moment the fact that this particular article is a book summary, a task LLMs excel at, it's interesting that the (warranted) comparison to LLM outputs casts doubt on the credibility of the writing, and in some ways maybe even caps its implied utility.

Just like how human beings choose different ways of presenting themselves to the world (e.g. masculine/feminine, gay/straight, goth/punk/preppy) as a form of social signaling, today's LLMs emit a certain "I'm AI" signal that humans pick up on, and human writers will likely have to continue evolving the counter-position(s) to that signal.

If the results of relatively simple, unsophisticated prompts get better at passing for human-written articles/blog posts/forum comments/etc, that'll increase the fraction of human writing that falls into this uncanny valley, and exacerbate the need for stronger counter-positioning over time.

From linked guidelines:

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Scammers can jam this by reporting legitimate phone numbers as scam numbers, no?

I love makefiles as well and do something similar to OP: for every repo I contribute to, especially if it's not one of mine, I'll create an uncommitted makefile to track all the shell commands that add up to my workflow within that codebase.

The ability to create dependencies between targets is the cherry on top, but the main value is just the ability to create a cheat sheet of shell snippets accessible via `make <target>` from the root of the repo.

Such a makefile is always (1) version controlled as a secret github gist (though, as personal rule, i never hardcode secrets into it), (2) committed & pushed on `make` (3) git ignored via `.git/info/exclude`. This has worked quite well for me.

One downside with this approach is that the best syntax for passing parameters down to the target from the shell is to use environment variables, which is a little awkward. `NAME=value make target` is less pleasant than `make target --name=value` would have been.

In defense of linkedin: there are different strains of toxicity and malevolence running rampant on every other major social media platform (body shaming, bullying, harassment, predation, scams, various kinds of radicalization, etc.), and many of those strains are rather subdued on linkedin.

Linkedin, of course, has some strains of its own (e.g. workism), but, surprisingly, I find it to be by far the healthiest social network out there.

That's probably owing more to self censorship than to moderation or algorithmic curation: your "professional" persona is more on display here than anywhere else.

So, yeah, sure, seems reasonable to suggest that linkedin has an anti-link bias, and the incentives for that bias are fairly intuitive. That being said, is it actually a bad thing, or does it also function as another tenet of their quiet but, in my mind, reasonably effective moderation approach?

> The point of rigour is not to destroy all intuition; instead, it should be used to destroy bad intuition while clarifying and elevating good intuition.

This is a key insight; it's something I've struggled to communicate in a software engineering setting, or in entrepreneurial settings.

It's easy to get stuck in the "data driven" mindset, as if data was the be-all and end-all, and not just a stepping stone towards an ever more refined mental model. I think of "data" akin to the second phase in TFA (the "rigor" phase). It is necessary to think in a grounded, empirical way, but it is also a shame to be straight-jacketed by unsafe extrapolations from the data.

tldp is notoriously full of bad advice, especially when it comes to shell scripting. From my time on #bash back when freenode was a thing, this was the superior resource: https://mywiki.wooledge.org/BashGuide

This is a pretty suspect list.

"Built-in commands" showcases [ ] vs [[ ]]. This is not an efficiency win, but a matter of using older POSIX syntax vs more modern and richer bash syntax. The utility of the bash syntax is that it supports nicer operators, such as < > in addition to stuff like -gt / -lt.

"Efficient File Operations" showcases IFS=, which is not used for the sake of efficiency, but to change how the line is tokenized. (And what good is an efficiency claim that's not backed up by any data?)

I did not look too closely, but I suspect the rest of this list is equally eyebrow-raising.

I see quite a bit more false outrage in your statements than in the ones you're replying to. Also, on what grounds do you consider your position to be apolitical? Self-evidence?

Do you have any plans to open source the thing?

Heyo, looks like it's Gregory Schier, the maker of Insomnia: https://schier.co/

I completely agree. My willingness to pay is directly proportional to my conviction in the effectiveness of the proposed solution.

The internet has revealed us to be very picky shoppers. We do a lot of comparison shopping, looking for the "best" deal on the silliest item. That same skepticism applies to policies, even effective ones. I want to fund the best ideas, and the best ideas should be backed by compelling models and, ideally, empirical evidence.

There's something to be said for the VC mindset here: funding many things, each of which has a low probability of succeeding, and using unicorns to subsidize numerous losses. Tax payers don't like losses, but an example of something kind of similar that the government already does today is science funding.

Seconded. vim-angry is an excellent plugin that exposes args as text objects.

In an expression such as (foo, ba|r, baz), where | is the cursor, it does the following:

via - (foo, |bar|, baz)

vaa - (foo|, bar|, baz)

vaA - (foo, |bar, |baz)

Plenty of racism in humans isn't malicious, either, but is just a byproduct of bad training data. The outcome is bad regardless of what was intended, and it's the outcome that matters.

Agreed, this could make the graphs much more comparable and maybe reflective of project culture. Comparing something like the linux kernel to VueJS is nonsensical without any normalization with respect to overall repo size.

There's one photo organization feature I really want that I haven't yet seen in any existing asset managers: a way to group bursted photos together and hide a set of images behind one "representative" image in the main stream, while still making them accessible if necessary. Anyone aware of software that comes close?

If anyone here hasn't listened to his "protocol for dying" episode of The Changelog from several months ago, you really should: https://changelog.com/205/

From personal experience, I've tried scraping my own TD Ameritrade data and quickly got flagged by their system as a virus because my request pattern likely failed some heuristic check. They disabled my account "until I get that cleaned up" and I had to plead with multiple people over the phone just to get it re-enabled.

The overall experience was quite terrible, but I wouldn't be surprised if it's the norm.

For the record, that's not German, that's Russian. Moscow, to be specific:

> 111398, г. Москва, ул. Перовская, 20

#bash on freenode, and http://mywiki.wooledge.org/BashFAQ

That sounds like an unnecessarily expensive way to go--I imagine that a specialized connector is more likely. The article makes a good point about this category of concerns:

> But just because it will be inconvenient for some users doesn’t mean that Apple won’t do it. In fact, you can almost hear the stage patter when the feature is unveiled: Most connectivity is wireless these days, we’ve made a great $49 accessory that adds all the ports you’d want, and the included power adapter—the most innovative power adapter ever—features a breakaway magnetic coupler and is itself a USB and Thunderbolt hub. I’m making the details up, but you’ve got to think there would be more to the story than, “Yeah, your power plug is also your USB plug, get used to it.”

Guys, the `less -S` problem is bunk, because you can easily change it at runtime. From the OPTIONS section of `man less`:

Most options may be changed while less is running, via the "-" command.

So, just start `journalctl -l` as you would, then type in `-S` and scroll the screen in any direction to force it to re-draw.

Discussing it any further is bikeshedding, and distracts from the much more interesting segfault discussion.

Sadly, SUA is only available in the Ultimate and Enterprise editions of Win7.

The main benefit of PowerShell over other shells is the object pipeline.

In classical shells, a pipe basically connects binary stdout -> binary stdin. A pipe between PowerShell cmdlets, on the other hand, can produce .NET objects directly without having to serialize them, so the pipe can connect .NET object producer -> .NET object consumer. If the consumer can't handle objects, the pipe degrades to binary stdout -> binary stdin.

For instance, the pipe in `ls | grep` is drastically different from `ls | fl`, because the latter is an in-process transfer of a .NET object collection, while the former transfers lines of text from one process to another, (in this case, to GNU Grep.)

Upside: the consumer doesn't have to "parse" stdin to get reasonable data on which it can operate.

Downside: if you want to write a consumer, you're stuck in .NET land. (Oh, how I wish I could write a consumer written in python that could advertise that it supports a specific object-oriented serialization on stdin! Then we could write a PowerShell stdin/stdout compatibility layer into python as a module... Alas, I'm guessing this task is reasonably hard.)

Oddly, I couldn't find a great readable intro to the topic, but this comes close: http://www.darkoperator.com/blog/2013/1/28/powershell-basics...

Fascinating! I never would have guessed that the Where We Live intro is an Apex Twin song.

I've been reasonably happy with my solution to this, which is https://github.com/staticshock/seashell

It's a fully contained Makefile that gives my dotfiles repo `make && make install` semantics. `make` initializes whatever needs to initialize locally on that system, and `make install` creates all the necessary symlinks in the $HOME directory.

Sure, debug that shell script, but then don't forget to propagate the fix to all the shell scripts.

The shell script approach violates the DRY principle--it's probably super similar to some 50 other init scripts on the same system. systemd, in principle, removes the boilerplate so that the bug would only have to be fixed once.