cytzol

You're damn right.

The other day, I was using the Twitter web interface, and I realised I'd accidentally clicked the "Like" button on a tweet as I was going back to the previous page. Oh no, I haven't liked a bad tweet, have I? Of course, I go forward, and the page has completely changed, showing me a bunch of stuff that wasn't there the last time I saw it. Great, now I need to navigate the UI. I scan the interface for some sort of "likes list". It's not in the sidebar. It's not in the "more" in the sidebar. It's not even in "lists".

So I open Tweetbot, search the menu bar for "like", find it in "Tabs → Likes", and perform the action I want in seconds. Web applications can never compare.

I love Just, but I love it because it's not a build system — I already have a build system, I just need a standard "entry point" to all my projects so each command a user could use to interact with the actual build system is in the same place for each project. I wouldn't build, say, a C project with Just and Just alone, where it tracks the dependencies between files and only rebuilds what's necessary.

So while it's replaced one use of Make for me, I can't rightly call it a Make replacement.

It's a bit of a weird one! I think the most famous example of the term comes from Richard Feynman, in his essay "Cargo Cult Science" (http://calteches.library.caltech.edu/51/2/CargoCult.htm):

> In the South Seas there is a Cargo Cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land.

It's about copying others to achieve a goal — but because you aren't copying the motives, only the visible methods, you don't succeed. In this case, it's about copying the engineering practices of big organisations without being a big organisation yourself, in the hope that you become one. Hope this helps.

> Right-arrow accepts the current suggestion.

If the '→' key is too far away from the home row for your liking, you can use Control-E instead, as long as you're at the end of the input buffer (it's the "go-to-end-of-buffer" command normally)

I've been using fish at home and bash at work for almost a decade now, and it's been fine — and because I'm at a fish shell on my own computer far more often than I'm at a bash shell on a work server, I'm willing to take the slight productivity hit there, because I gain overall.

The thing is, when I picked up fish, I couldn't forget my existing bash knowledge. I still have to write normal bash-dialect shell scripts, and with the fish syntax being so much nicer and simpler, the two can happily co-exist in my head. Occasionally I'll hit Up to search through history instead of Control-R, but I quickly realise what I've done and use the bash keybinding instead. And the only fish aliases I missed were 'l', 'll', and 'la', which I just manually copied over without bothering with the rest.

If I had to use bash more often at work... I'd still use fish at home after all the time I've sunk into it, but YMMV.

> Are there any linux distros for any platform that aren't shipping terminfo?

Ah, I was referring to higher-level languages such as Ruby here (I have a lot of scripts where I use it a shell script replacement) rather than C, where you can just download a compiled version and use it without any fuss. Ruby moved its curses interface out of the standard library a long time ago, so now you have to add it to your gems list.

> If you're pretty printing text for a human to read then I don't think the couple extra ms it will take to spawn a handful of tput processes is going to be an actual performance concern.

For scripts, I agree — I used to use tput, and only stopped because I'd eventually seen the ANSI escape codes enough time to just memorise them. But I find that if your program needs to use enough colours (my software has been called "overly colourful" before), the time it takes to run a tput once for every bold and normal variant of all eight colours quickly makes it seem like your program is running on the JVM, even if I cache the output. I appreciate that not all software needs every terminal style available to it, but it seems to me that the best interface should be able to scale to many styles, not just a few.

> I was going to refute the any language comment with libraries based on terminfo, but all the ones I ran across in 30 seconds just hard code the ANSI escape sequences.

This doesn't surprise me! I used to be concerned with the growing number of comments and guides on the internet that say things like "this is how you do bold in a terminal" as though it applies to all terminals, so I asked a question on Stack Exchange a while ago:

https://unix.stackexchange.com/questions/548158/in-2019-is-i...

I was hoping to find an answer from someone like yourself, who regularly works with non-ANSI terminals and was becoming increasingly annoyed at the proliferation of standards-shirking shell scripts... but I only got comments saying I was doing it wrong, as though I was the only one who didn't get the memo. You're the only obscure terminal user I've ever talked to in the wild, congratulations.

Anyway, I agree that we're stuck in this situation, and even though I am taking the easy way out, I still find that a shame.

> And it's not like it's difficult to avoid hard coding

There are upsides to hard-coding the escape sequences that you aren't mentioning. Using terminfo or ncurses requires an extra dependency with a clunky interface. Using tput requires spawning a process, which gets slow if you have to do it repeatedly. But simply hard-coding the escape sequences is dependency-free, as fast as printing, can be done in any language, and is going to work for at least 99.9% of the users out there.

I'm usually a big fan of "use a standard interface rather than one particular implementation", but I haven't found a solution, other than hard-coding the ANSI escape code set, that I'm happy with.

Something I found surprising is that a change to the GitHub codebase will be run in canary, get deployed to production, and then merged. I would have expected the PR to be merged first before it gets served to the public, so even if you have to `git revert` and undeploy it, you still have a record of every version that was seen by actual users, even momentarily.

Does anyone know the pros and cons of GitHub's approach?

> These are real, material examples of the benefit brought by developers being on your side.

I think it actually goes a little further. Growl is (was) a fantastic notifications system, but it wouldn't have succeeded without the healthy ecosystem of third-party programs that were willing to use it. When I installed it, long long ago, everything I wanted notifications from suddenly supported them. If the developers hadn't been talking to each other, it wouldn't have worked.

All I'm saying is that lookup.dog was originally going to contain a Shaun of the Dead GIF and nothing else, in the same vein as butt.holdings or cheese.singles. The DNS part came later.

Yeah, it didn't occur to me to not capitalise them, but I've seen many people stumble over this. I'll change it for the next version.

I actually agree: the thing that library has that dog doesn't is that it's been battle-tested. For example, I've already had to fix a case where it was mis-parsing TXT records because I missed part of the relevant RFC!

For a lot of people, that will be four running copies of Chromium.

Ah! My bad, I've simply forgotten to update the README. I'll do it later once I'm done with work.

This is my thinking too. I could add the option if there's enough interest, but aren't there already dedicated tools to do this?

As an example: I sometimes run 'curl ifconfig.me' to get my public IP from the command-line, but I wouldn't expect curl to add an '--ip' option to make this specific query easier to run. curl is a general tool, and the fact that you can use HTTP to get your public IP doesn't mean it needs a top-level option in an HTTP client. (I get that reverse lookup is an internet standard, and ifconfig.me is a third-party service, but still.)

There are binaries, at least, for three targets: https://github.com/ogham/dog/releases

I didn't think that feature fit. Would people really use a general DNS client for this? I use nslookup.

It does not — it didn't make the cut for v0.1, but I've raised an issue (#4) so I don't forget about it.

Author here. Didn't expect this to show up so soon, but I'm glad people like it — I only published v0.1 on Saturday.

Over on the Rust forum I gave a brief overview of the crates and developer tools I used: https://users.rust-lang.org/t/dog-a-command-line-dns-client/...

> Your tools seem to be bizzarely obsessed with colors, though

Y'know, for some reason, I get that a lot.

The point you seem to have missed, though, is that I'm a user too. I want a user-agent to view the things that I, a user, want to see, and those things are colours and bold and italics. I don't want to have the flashiest site around to wow everyone; I want to see more sites like mine. My content has colours and formatting and images, where they're a part of the content, not merely its presentation; and one of my tools is doing very well, so even if you don't agree with it, there are enough people that do to make it worth my while.

And if Gemini ever gains the requisite capabilities, I won't be offended if you turn the colours off. It's your right as a user, too.

I know that one of the goals of Gemini is not just to have a protocol with no tracking, but to have a protocol where no tracking can sneak in. Looking at the state of the Web right now, that's a laudable goal. The same goes for having a simple easy-to-implement protocol, which formatting would throw a wrench right in the middle of.

But if that's the case — if not being able to have my preferred Gemini experience is considered "collateral damage" because Gemini prioritises other features than my favourite ones — then please just say that, rather than insinuating that I don't count, or don't understand. I'm trying to engage with you as a "netizen" (I haven't used that word for a decade), and you reply with "this time we actually mean it", as though there are sides in a fight. I don't want to be stuck with the Web any more than you do.

While I was reading this post, I felt the same way as I read the HN comments on the Mozilla layoffs two months ago: misplaced blame.

I admit I have a soft spot for Mozilla, having used Firefox since Firebird. I really want them to succeed, which colours my thoughts on this topic, and it makes me sad to hear them engaging in shady behaviour.

But the impression I got from this post is this: the author believes if Mozilla focuses solely on Firefox (no VPN, more engineers, Servo development full steam ahead) they would be doing better, with Firefox having more users and more money than ever before to go around. I do not believe this to be the case. The post frames "Laid off 25% of its employees, mostly engineers, many of whom work on Firefox" and "Used their brand to enter the saturated VPN grift market" and "Started, and killed, a dozen projects which were not Firefox" as Mozilla's self-inflicted failures, rather than wounds sustained while engaging in battle with corporate giants. I disapprove of the increased executive pay, as well as the advertisements and add-on changes. But I cannot quite find them to be totally at fault for all seven listed items.

There's been a lot of engineering effort recently from big companies to make the Web more featureful, and its associated infrastructure faster, than ever before. I completely agree with the author (see the linked post) when he points out that the massive side-effect of this is that only a big company can make a Web browser. It's something that seems to have crept up on us, and will almost certainly take control away from individual users. It sucks.

So as far as I'm concened, Google has been the company complicating Web standards without talking to anyone else, developing infrastructure that's only appropriate for massive organisations, and (more recently) exempting themselves from opting out of tracking, all while pushing their browser through previously-unheard-of advertising channels to give them the advantage. All this means Firefox has to catch up, and the money has to come from somewhere — hence the layoffs and other projects. I don't see any other way for them to reach the future I want.

To repeat: it sucks.

While I wasn't old enough to donate, I liked seeing the 2004 Firefox page in the New York Times. A few years ago I walked through London and saw three electronic Chrome adverts in half an hour. I think Mozilla has the deck stacked against them, severely. And I think nothing would make Google executives happier than to find _Firefox_ is the one getting called names.

I disagree, and I'm a little bit insulted.

I'm pretty much in Gemini's exact target market: my websites are simple and almost entirely text, with no tracking, minimal JavaScript, and a hefty CSP. I like implementing simple network protocols and I'm annoyed with the ever-increasing complexity of the Web. And I write command-line software, so Gemini is right up my alley. So when I first heard of it, about a year ago, I was really excited for there to be a new way to convert my sites to this new, simpler hypertext–

But when I tried it, it didn't let me build the sort of site that I, personally, would want to read.

• The documentation sites for my software (https://specsheet.software, https://dns.lookup.dog, https://the.exa.website) all feature inline code samples, complete with the colours you'll see in your terminal. Being able to see an example command and then see its exact output really helps me learn a tool, and I wish more programs were documented in this way. When I re-wrote the documentation as man pages, it was like going from colour to black-and-white, and when I Gemini-ified the documentation, it felt like I was reading man pages.

• My personal home page has blog posts that use styles to sound like the way I talk. I emote. I emphasise. I bold important sentences, and shove side-notes to the side. If I'm writing technically, I'll include charts and side-tables of data. And, again, I like to include syntax-highlighted code snippets and images where appropriate.

I'm not a marketer. I abhor advertising. I'm not trying to usurp the world's communications channel for my own gain. I'm just trying to publish content I want to see more of, and my attempts at offering a Gemini version resulted in exactly zero pages.

This is why it disappoints me when you say this:

> The rest of the web is either (1) best served some other way or (2) not worth keeping.

Do you really think I belong with "the rest of the web"? Or do you think my sites are not worth keeping?

I read an overview of Gemini that described it like this:

    gemini is a new internet protocol which:
    - is heavier than gopher
    - is lighter than the web
    - will not replace either

It looks like you disagree — how come?

> 1Password supports standalone licenses

The 1Password macOS and Windows clients can be bought stand-alone, but their newer clients (such as the command-line client, for some reason) are subscription-only. It's confusing, and it looks like this Linux client is also subscription-only.

I have a Microsoft account for OneDrive, and if that account ever gets banned — say, a defective algorithm thinks I've uploaded pirated content when I haven't — I don't want to also lose access to a game I've already paid for. Right now, the accounts are separate.

It reminds me of people who lost access to their e-mails and photos for making YouTube comments (a completely unrelated service).

> Use NixOS, and at least you are standing atop the tower of Babel and able to see all the parties that don't communicate.

I haven't used NixOS but this sounds intriguing. Could you explain in a little more detail how it helps with this?

I feel like that phrase was extremely accurate... before the buggy OSes, awful keyboards, and hordes of security prompts. If you're starting to use Apple devices in 2020 I can see why you'd think that phrase is infuriating, but believe me when I say things used to be so much better!

> Sometimes I think it's fascinating the rabbit holes we'll go down, when ultimately, the user just doesn't care.

All those things you mention don't affect the user's first experience on your site, you're right: you can use plain JS, ignore clean code practices, have no unit tests, and use the frameworks you're most familiar with even though they don't quite fit, and still start a successful service.

However, they all come into play when you start to evolve your website or service. TypeScript makes it easier to refactor your code when it gets complicated. async/await lets you serve more users. Clean code practices lets you onboard more developers easier. Unit tests and end-to-end tests mean you can iterate more quickly without worrying about breaking existing functionality — something users definitely do care about — which makes it something you should care about too, if you want to keep them around.

> Link to a screenshot of this Safari notification when Chrome is run?

https://danieljwilson.me/2019/10/16/a-catalina-double-standa...

> Reference to an article about this?

It's this article: https://mjtsai.com/blog/2020/02/17/the-paywalled-garden-ios-...

But it's referencing this tweet: https://twitter.com/marcoarment/status/1228431785442381824

> This is something other apps can't display...?

You're right, I should have been more specific: it shows the badge even when I don't have System Preferences open, while other apps (such as my chat client, or mail client) only show badges when they're open. It shouldn't show the badge at all, though.

> It is possible to still make all of these work by having frameworks that hold the permission to access the functionality, or by having entitlements to more tightly restrict which applications have access to a feature.

I agree with this, but I can't fully get on board with it.

I've worried about the lax security model of desktop software too. Apps these days need to ask permission before accessing my documents, or my desktop, or my downloads folder, but they can still access all my company's code and SSH private keys. It feels wrong for this to be open-by-default. Same with accessing the clipboard, or drawing on the screen, or changing system settings, or injecting code into the Finder: these all seem like things I want to opt in to doing.

But my problem with this — and it's a stretch, I know — is that if the only extra entitlements a program can have are the ones that Apple explicitly allows, then no developer can have any ideas outside of what's already been thought up. As we increase security, we also dry up the innovation well.

For example, there's a Finder API that allows you to add badges to files in a directory to reflect their syncing status. This is an API that Apple allows apps to use — but it was originally implemented by Dropbox, which injected code into the Finder. They had the idea, and the idea turned into a general API.[1] (Now that I think about it, there's almost certainly prior art to this, but Dropbox was where I first saw it)

Similarly, I use a whole bunch of background utilities that currently use the "Screen Recording" or "Accessibility" Privacy permission on macOS, even if they aren't screen recorders or accessibility helpers: things like letting me move windows by holding Option, or switching apps by using the keyboard, or a Spotlight replacement, or adding a delay to ⌘Q, or the snippet manager I just used to insert the '⌘' character there. The entitlements that allow these applications to continue existing were developed after the applications themselves, and to use them, I have to opt-in to functionality that was previously allowed. If the entitlements didn't exist, we'd have to rely on Apple to think it up, and the way they're behaving, I doubt they'd be as generous as allowing one like "can read any pixel and draw anywhere on the screen".

Clipboard managers are another thing that wouldn't exist if OSes started out locked down. Not only do you need to access the keyboard, you need to do so from the background! It was the openness of desktop OSes that gave developers this idea — on iOS, nobody would have thought it up.

Way back when, in iOS 4, Apple gave apps the ability to run in the background, but only certain types of app — music playing, voice calling, and location-based apps received dedicated APIs to do that. Again, Apple waited to see which types of program were popular on other platforms, and based their APIs around allowing those specific kinds of app. If all platforms started life locked-down, maybe one or two of these categories won't be available today.

f.lux, the program that runs in the background and dims your screen red in the evening, is another example. I used to love using it on my desktop computer. But in iOS, they asked for the API, and weren't given it. And honestly, I'm kind of on Apple's side with this one: tinting the screen is the sort of system property I want only done by the OS itself, not an app, so now I use Apple's implementation of the same idea, Night Shift. But again, if the ability to tint your screen did not exist on desktop OSes, I'm willing to bet that Apple would not have come up with the idea.

And even if the idea is there for an entitlement to exist, that doesn't mean that Apple are going to allow it: adding one costs developer time, testing time, and documentation time. In a recent episode of Accidental Tech Podcast, I discovered that Switchglass (a Dock replacement I use) isn't allowed to Quit other apps, a feature I've sorely missed, because it's disallowed by the macOS sandbox. The idea for the entitlement is there, and the need is there, but Apple isn't bothered about apps opting in to such fine-grained functionality as quitting others. Ask me it through a prompt! That would be great!

I hope you see what I'm trying to say here. It used to be the case that macOS "allowed" iOS to exist, because it soaked up all the complexity — and slowly, features that proved popular on the desktop were allowed to exist, in a secure fashion, on mobile. I'm worried about how when I run random programs on my Mac, they have access to all my important files. But I'm also worried about the future. The tighter the grip OS manufacturers have on what sort of code can run on users' machines, the less innovation we'll see, and the worse computers will become.

[1]: https://developer.apple.com/library/archive/documentation/Ge...