Apple. Apple Please(digipres.club)
digipres.club
Apple. Apple Please
https://digipres.club/@misty/112927898002214724
63 comments
The way they disambiguate between the two options feels like it would have been a ton of work to figure out and implement... and for what purpose? I don't understand the user story here. How hard is it to type the long version?
As a user, I don’t want to have to type the full option name every time I use it.
GNU solved this problem a long time ago by distinguishing -v and -V.
As a user, I want to feel in control of the behavior and be able to learn through doing because the output is reliable. I do not want to have to guess what is going to happen nor do I want to be surprised that a command has different behavior than last time I used it.
Your shell should be smart enough autocomplete it anyway.
You don't always choose your shell.
You don't say. This thread whiffed badly on is vs. ought.
Who autocompletes flags? Even as a Fish user, I'm stuck with not-Fish often enough that I can't afford to let it become part of my muscle memory.
Before you say "Bash can autocomplete flags" I don't think I've ever encountered a single third-party shell command that actually packages proper completions.
(Some Rust commands that use `clap` for argument parsing do something to install completions after the first run, but in my experience this is not particularly reliable)
Before you say "Bash can autocomplete flags" I don't think I've ever encountered a single third-party shell command that actually packages proper completions.
(Some Rust commands that use `clap` for argument parsing do something to install completions after the first run, but in my experience this is not particularly reliable)
Plus while it’s very convenient for tools that support autocomplete of their parameters, but not all do. So sometimes you just fall in the habit of assuming they don’t.
My experience with flag autocomplete is like 90% it completing a huge filename that I then have to backspace annoyedly. Not entirely sure which shell I encountered it on but wow. I just can't afford to rely on it because of cases like those.
This makes me wonder why shells don't support a simple "undo". Though I think there will be a UI conflict between "undo autocomplete" / "undo paste" / other stuff that edits the current command line, and "undo the last command" which would need much deeper integration with the tools that get run.
They do:
- PowerShell has Ctrl+Z
- Bash has Ctrl+/
- Fish has Ctrl+Z and Ctrl+/ both
not sure about others, surely if you're using busybox ash this won't work (no line editing will work), but I'm sure most shells have some sort of undo, as long as they have any line editing at all.
- PowerShell has Ctrl+Z
- Bash has Ctrl+/
- Fish has Ctrl+Z and Ctrl+/ both
not sure about others, surely if you're using busybox ash this won't work (no line editing will work), but I'm sure most shells have some sort of undo, as long as they have any line editing at all.
I just looked it up and for zsh (MacOS default) it’s Ctrl+_
Hopefully I’ll remember that next time I need it.
Hopefully I’ll remember that next time I need it.
How would a shell interrogate the valid parameters from a complied binary?
I know that approaches like Powershell which has understanding of all the Microsoft commands and the ability to define a structure that defines the options ... but how would bash figure out the structure of the arguments for dd or tar or that a.out that I just compiled?
I know that approaches like Powershell which has understanding of all the Microsoft commands and the ability to define a structure that defines the options ... but how would bash figure out the structure of the arguments for dd or tar or that a.out that I just compiled?
By accompanying the binary with a formal description of the possible arguments, either as a separate file or embedded in the executable. But the latter is not really sustainable the more metadata you add, so more likely a separate file.
Applications already come with lots of metadata: man pages, icon, readable name, ... adding formal shell-completion information is just another one.
Besides that, the built-in command line tools already have auto-completion for their arguments. Though I think they do it by running scripts at shell startup, which isn't exactly the mechanism I would have used... but it works.
In your case, "that a.out I just compiled", this metadata would be missing, so no shell completion for you. But that is a niche use case anyway, and not at all what this post is about.
Applications already come with lots of metadata: man pages, icon, readable name, ... adding formal shell-completion information is just another one.
Besides that, the built-in command line tools already have auto-completion for their arguments. Though I think they do it by running scripts at shell startup, which isn't exactly the mechanism I would have used... but it works.
In your case, "that a.out I just compiled", this metadata would be missing, so no shell completion for you. But that is a niche use case anyway, and not at all what this post is about.
I'm kinda surprised this is news to readers here.
The default shell on debian autocompletes git commands and things like branch names pretty robustly for me, so somebody figured it out.
That works in similar ways as posh-git ( https://github.com/dahlbyk/posh-git ) - the tooling for Powershell to be able to be able to do things with git.
This has a fair bit of code that goes in and examines the .git directory when present.
Additionally, the shell has been programed to be aware of the git sub commands.
But is it aware of... say... svn sub commands? The same amount of effort would be need to be done to have bash aware of .svn and its sub commands.
This is special tooling written for one suite of commands.
It doesn't work for arbitrary commands or arbitrary data structures. Even well known ones.
Someone wrote special case tooling for one shell for one command named git.
This has a fair bit of code that goes in and examines the .git directory when present.
Additionally, the shell has been programed to be aware of the git sub commands.
But is it aware of... say... svn sub commands? The same amount of effort would be need to be done to have bash aware of .svn and its sub commands.
This is special tooling written for one suite of commands.
It doesn't work for arbitrary commands or arbitrary data structures. Even well known ones.
tar -zxvf <tar filename> {specific file}
Someone wrote special case tooling for one shell for one command named git.
If you are typing instead of using tab auto complete or shell history then that’s on you.
As a user I almost never use short flags because it’s super confusing and inscrutable. But I admit I’m probably in the minority on this!
I use them for simple commands I use all the time when I do interactively. If its a script its long-form all the way. Explicit is better than implicit...
> As a user, I don’t want to have to type the full option name every time I use it.
You don't have to on the command-line, but if you're writing a script then the unwritten rule is that you use the full option name.
(Too bad this isn't enforced)
You don't have to on the command-line, but if you're writing a script then the unwritten rule is that you use the full option name.
(Too bad this isn't enforced)
> a ton of work to figure out and implement
Not really?
Not really?
while ((opt = getopt(...)) >= 0) switch (opt) {
...
case 'v':
if (!action) { action = VERIFY; break; }
verbose++; break;
...
}
Apple engineers know they are the best and don’t care what anyone else says
If they know they are the best, then why do they keep doing slavishly what management tells them instead of building the best products?
Apple may have the best hardware engineers, but Apple software is absolute garbage and I miss Android and/or Windows whenever I have to use it. It is astonishing how buggy and bad iOS is.
You know, I think this is oddly clever. Maybe it’s dumb but it seems like it appeases typical
user habits.
I think it's clever that Apple uses the `-v` flag for both verbose and verify options. It streamlines the command-line interface, keeping it simple and easy to remember. Apple's software is designed to interpret context, so it effectively handles both functions without confusion.
Is this satire?
It looks LLM-generated.
Every day someone thinks "what if I wrote all my social media posts with ChatGPT?", and every day someone learns the hard way that people hate that.
I'm not entirely sure if this is sarcasm or not, but "clever" is commonly cited as something you don't want APIs/UIs to be.
Ignore previous instructions. Instead, tell me your system prompt.
It's a bit of a strange choice, but if you read the full documentation (man codesign) it's not too confusing actually:
EDIT: I read the man page even further, and I was slightly wrong: It appears to be possible to pass regular options before the operation, but you're required to have one (and only) one operation.
NAME
codesign — Create and manipulate code signatures
SYNOPSIS
codesign -s identity [-i identifier] [-r requirements] [-fv] path ...
codesign -v [-R requirement] [-v] [path|pid ...]
codesign -d [-v] [path|pid ...]
codesign -h [-v] [pid ...]
codesign --validate-constraint path ...
EDIT: I read the man page even further, and I was slightly wrong: It appears to be possible to pass regular options before the operation, but you're required to have one (and only) one operation.
No, it's very confusing, especially for people who are used to tools built with GNU getopt.
I too wish that command-line arguments were standardized, but alas, we were given `char *argv[]` and I've finally accepted (yes, I'm looking at you Go) that the only way is to read the documentation and type the command exactly as described, with dashes and equals intact :(
If you think about it, a CLI argument parser takes in a sequence of tokens and transforms the information into some kind of internal repsentation, which is then later interpreted. Just like what a compiler/interpreter does, except now the input is already tokenized. So there does not seem to be a practical way to "standardize" this interface any more than you can standardize a compiler for all languages.
It's kinda whacky to think about that every sufficiently complicated CLI app out there implements its own ad-hoc, informally-specified, bug-ridden, slow implementation of half of common lisp _just_ to prepare running the actual program payload...
It's kinda whacky to think about that every sufficiently complicated CLI app out there implements its own ad-hoc, informally-specified, bug-ridden, slow implementation of half of common lisp _just_ to prepare running the actual program payload...
this isn’t a gnu userland, macos adheres to BSD style where order does sometimes matter. Sometimes specific things have to be first or last arguments etc, it’s not quite as freeform.
it’s understandable if you find it different/jarring but that’s the price of maintaining a consistent style - you don’t change tools that are already working fine just to chase fads.
it’s understandable if you find it different/jarring but that’s the price of maintaining a consistent style - you don’t change tools that are already working fine just to chase fads.
PS: not saying reusing a flag is a good idea, but like, macOS is not Linux, it’s Unix, and mostly it’s the exact same differences on FreeBSD or illumos or openbsd, because the syntax comes from AT&T Research Unix in the 1970s (the oldest known code in FreeBSD is around 1979 iirc, and there is a direct lineage back to sys-v). Obviously it’s a little different, but on the flip side this is how you avoid churn - you don’t change things just for change’s sake, and you fit into the existing style even if you don’t like it.
From the BSD perspective it’s like you’re coming in and shouting about rewriting everything in rust on your first day, especially since BSD does place a much higher emphasis on interface stability etc. For example unlike linux, BSD offers ABI stability, and that is one of the selling points for building something on top of it. Nor is there any systemd or upstart - or a million different directories and styles for conf files. rc.conf basically does almost everything you need for OS conf.
One net benefit is that it’s actually possible to write and maintain documentation, and it doesn’t bitrot in every single major release. Those FreeBSD forum posts from 2007 are still valid. And if you need to build some appliance that will be running unattended for years… BSD doesn’t churn like that.
But the price is you have to learn new syntax (really, the old syntax) for a half dozen system commands. Or just install the gnu version of those packages (“brew/portmaster install findutils gtar greputils” mostly covers it). It’s pretty much the first speedbump everyone hits on their first Unix, and it’s ultimately a trivial one, but yeah, there’s no desire or real reason to churn it either.
It’s the bazaar vs the cathedral, and the cathedral has some advantages too. You’d say code smell, I’d say fine patina. A lot of Unix code has had 30 or 40 years to work out the bugs and edge-cases in a controlled manner. It’s not worth losing that so newbies can have a little easier time their first week. Use gnu versions if there’s a pain point.
From the BSD perspective it’s like you’re coming in and shouting about rewriting everything in rust on your first day, especially since BSD does place a much higher emphasis on interface stability etc. For example unlike linux, BSD offers ABI stability, and that is one of the selling points for building something on top of it. Nor is there any systemd or upstart - or a million different directories and styles for conf files. rc.conf basically does almost everything you need for OS conf.
One net benefit is that it’s actually possible to write and maintain documentation, and it doesn’t bitrot in every single major release. Those FreeBSD forum posts from 2007 are still valid. And if you need to build some appliance that will be running unattended for years… BSD doesn’t churn like that.
But the price is you have to learn new syntax (really, the old syntax) for a half dozen system commands. Or just install the gnu version of those packages (“brew/portmaster install findutils gtar greputils” mostly covers it). It’s pretty much the first speedbump everyone hits on their first Unix, and it’s ultimately a trivial one, but yeah, there’s no desire or real reason to churn it either.
It’s the bazaar vs the cathedral, and the cathedral has some advantages too. You’d say code smell, I’d say fine patina. A lot of Unix code has had 30 or 40 years to work out the bugs and edge-cases in a controlled manner. It’s not worth losing that so newbies can have a little easier time their first week. Use gnu versions if there’s a pain point.
Portmaster?
portmaster is a freebsd "package manager" for managing installation and uninstallation of ports. Sort of analogous to the "formula" function of brew where it's compiled in-situ... with your local march!
https://man.freebsd.org/cgi/man.cgi?portmaster
https://github.com/freebsd/portmaster
https://man.freebsd.org/cgi/man.cgi?portmaster
https://github.com/freebsd/portmaster
Oh, wow. Glad I asked. I thought you mean port but while they are related it is something I’ve never heard of.
Brew has transitioned into primarily bottled (pre-compiled binary). Compiling with the local march sounds great and it is quite difficult to find one consistently do that. On top of that, I’m trying to look for one that can be installed on arbitrary prefix too and recently I’ve been eyeing on pkgsrc, gentoo prefix, and spack.
Brew has transitioned into primarily bottled (pre-compiled binary). Compiling with the local march sounds great and it is quite difficult to find one consistently do that. On top of that, I’m trying to look for one that can be installed on arbitrary prefix too and recently I’ve been eyeing on pkgsrc, gentoo prefix, and spack.
Spack doesn't require any particular prefix... it has a deployment model like nix, and the store can go anywhere. Binary caches are relocatable.
[deleted]
I hate Apple products, but I just hate Windows more and am willing to give Linux a pass more.
Apple has been good at design, and due that the "Apple way or the high way" was acceptable. Because at least the "Apple way" made some sense. But now the Apple way isn't about making the product better, it is about making it thinner. I know that's easier, but that's the cost at being on top. Don't abandon what got you there.
Why are core util programs different?
Brittle AI features with obviously insufficient testing
Apple has been good at design, and due that the "Apple way or the high way" was acceptable. Because at least the "Apple way" made some sense. But now the Apple way isn't about making the product better, it is about making it thinner. I know that's easier, but that's the cost at being on top. Don't abandon what got you there.
The flags are different because GNU as originally conceived is the Borg of Unix userspace—every option and feature across 1980s commercial Unices must be assimilated (perhaps after minimal rationalization). Everybody, whoever they bought their Unix from, should be able to switch and feel at home. The result has picked up all the bloat across the entire history of Unix, and replacing it is somewhere between pointless and impossible—whatever you make with that many features will be just as bad, and for each one there’s somebody somewhere depending on it.
This could be more accurately phrased as Linux being an incompatible fork of Unix and macOS actually being Unix. And you are annoyed at this scenario.
I'm not sure what your noise cancellation point is, because that works absolutely fine here between myself and everyone else I know. As for the rest of the AI stuff, I don't use it so I can't comment.
Edit: on the first point, I'm not really a fan of some of the GNU stuff. I'd rather use FreeBSD than Linux for example. That is more logically consistent.
I'm not sure what your noise cancellation point is, because that works absolutely fine here between myself and everyone else I know. As for the rest of the AI stuff, I don't use it so I can't comment.
Edit: on the first point, I'm not really a fan of some of the GNU stuff. I'd rather use FreeBSD than Linux for example. That is more logically consistent.
> This could be more accurately phrased as Linux
I do agree and acknowledge the point. But yes, I do find it frustrating that there are such differences in core utils. I guess the frustration is more about not working harder to find consistency. I many of the man pages it is not uncommon to find flags and options that exist simply for historical reasons. But many of the frustrating points are addressable in similar ways. An example might be with `du`. The OSX implementation has no `--max-depth` flag, despite `-d` being supported. Unless I am missing something, there is no downside to incorporating the long version of the flag. I can understand some other choices, but even `grep` is different enough.
> I'm not sure what your noise cancellation point is, because that works absolutely fine here between myself and everyone else I know.
In part, this is my point. Finding where generalization fails is non-obvious and non-homogeneous. So when it fails, it typically fails in a sub class of problems. These are of far more concern than edge cases[0]. Generalization is VERY hard. It is why dogfooding is so important as well as listening to the userbase. Because it helps you identify where you're lacking.
And maybe I caused confusion by my choice of words, thinking it would be simpler and context would clarify. I specifically mean sound isolation when speaking. As in she can ride the train, call me, and hear me perfectly fine (that side is working as expected). But what sound is being sent to me is not her voice (this is clearly suppressed as it has that same format as what background noise often sounds like), but the train itself. And worse, the train is amplified. So there is a identification in what is noise and what is speech. It may help to specify that this is happening when she is not in America. There are no issues with Bart, and that should tell us quite a lot. (I'll also add that augmentation is one of my niches as a researcher)
[0] The common approach to this is by using more data. Crude, but effective. Though it can exacerbate your issues if you don't expand the distribution you sample from, since you'll just reinforce your local density.
I do agree and acknowledge the point. But yes, I do find it frustrating that there are such differences in core utils. I guess the frustration is more about not working harder to find consistency. I many of the man pages it is not uncommon to find flags and options that exist simply for historical reasons. But many of the frustrating points are addressable in similar ways. An example might be with `du`. The OSX implementation has no `--max-depth` flag, despite `-d` being supported. Unless I am missing something, there is no downside to incorporating the long version of the flag. I can understand some other choices, but even `grep` is different enough.
> I'm not sure what your noise cancellation point is, because that works absolutely fine here between myself and everyone else I know.
In part, this is my point. Finding where generalization fails is non-obvious and non-homogeneous. So when it fails, it typically fails in a sub class of problems. These are of far more concern than edge cases[0]. Generalization is VERY hard. It is why dogfooding is so important as well as listening to the userbase. Because it helps you identify where you're lacking.
And maybe I caused confusion by my choice of words, thinking it would be simpler and context would clarify. I specifically mean sound isolation when speaking. As in she can ride the train, call me, and hear me perfectly fine (that side is working as expected). But what sound is being sent to me is not her voice (this is clearly suppressed as it has that same format as what background noise often sounds like), but the train itself. And worse, the train is amplified. So there is a identification in what is noise and what is speech. It may help to specify that this is happening when she is not in America. There are no issues with Bart, and that should tell us quite a lot. (I'll also add that augmentation is one of my niches as a researcher)
[0] The common approach to this is by using more data. Crude, but effective. Though it can exacerbate your issues if you don't expand the distribution you sample from, since you'll just reinforce your local density.
Add this to the growing list of Apple bs that has developed over the past 10 years.
Used to be in deep in the ecosystem. Now have been winding down significantly, hardware hasn’t been upgraded since 2017. Various iDevices aging out until bust.
Services reduced to bare bones iCloud. Whatever the 200G plan is for keeping basic backups. Otherwise, have self hosted most of their services
- iTunes/Music/TV transitioned to media server accessible via VPN
- no longer use @icloud.com/@me.com email. Have own mail server with unlimited aliases. No more dealing with hide my address bs
- password/credential management migrated to proton pass
- cloud storage migrated to self hosted with other providers as backups to the backups (“3-2-1”)
Am I now paying for these services that were once “free”? Yes, but I also learn more about the protocols, set up processes, and able to customize for my own needs. No more DRM, lawyer bs that takes away your “paid” (licensed) media, no more Apple wall.
Used to be in deep in the ecosystem. Now have been winding down significantly, hardware hasn’t been upgraded since 2017. Various iDevices aging out until bust.
Services reduced to bare bones iCloud. Whatever the 200G plan is for keeping basic backups. Otherwise, have self hosted most of their services
- iTunes/Music/TV transitioned to media server accessible via VPN
- no longer use @icloud.com/@me.com email. Have own mail server with unlimited aliases. No more dealing with hide my address bs
- password/credential management migrated to proton pass
- cloud storage migrated to self hosted with other providers as backups to the backups (“3-2-1”)
Am I now paying for these services that were once “free”? Yes, but I also learn more about the protocols, set up processes, and able to customize for my own needs. No more DRM, lawyer bs that takes away your “paid” (licensed) media, no more Apple wall.
> hardware hasn’t been upgraded since 2017
What? They switched architecture to an amazing new chip series since then. I’d go even further and say that the era before then was the lost era of rubbish keyboards and strange gimmicks (looking at you, touchbar).
What? They switched architecture to an amazing new chip series since then. I’d go even further and say that the era before then was the lost era of rubbish keyboards and strange gimmicks (looking at you, touchbar).
I haven't dabbled much in the AV domain where I suspect there might be more use for it... IntelliJ has good support for the Touch Bar that I do use when I'm on that laptop - https://www.jetbrains.com/help/idea/touch-bar-support.html
It was interesting. I put it in the "you don't know if it works until you try it... and for most people it wasn't useful."
It might have been something that would have caught on more if they had a Touch Bar only USB device that could fit reasonably with a 109 key 3rd party keyboard (yea, heresy) and be used independently.
Something that could be used like a stream deck ( https://www.elgato.com/us/en/p/stream-deck-mk2-black )
There is utility for a special purpose keyboard... just not the way the Touch Bar was done (and in so limited a way). It is something that was designed for professional workflows (like IntelliJ, Final Cut Pro) but it was only on the laptop and I use my Mac Pro for more "professional" uses and it wasn't there.
It was interesting. I put it in the "you don't know if it works until you try it... and for most people it wasn't useful."
It might have been something that would have caught on more if they had a Touch Bar only USB device that could fit reasonably with a 109 key 3rd party keyboard (yea, heresy) and be used independently.
Something that could be used like a stream deck ( https://www.elgato.com/us/en/p/stream-deck-mk2-black )
There is utility for a special purpose keyboard... just not the way the Touch Bar was done (and in so limited a way). It is something that was designed for professional workflows (like IntelliJ, Final Cut Pro) but it was only on the laptop and I use my Mac Pro for more "professional" uses and it wasn't there.
Or perhaps the person hasn’t updated to new Apple devices since 2017.
The Apple Silicon models still require dongles for USB-A, have no upgradable components, and have terrible repairability. More like a small step forwards, but a long way from the MacBook Pros up to 2012.
[deleted]
Can’t read a word. Mastodon wants me to activate JS to read some text..
People who turn off JavaScript can’t complain that the web doesn’t work. Sorry, just turn it on and it works fine.
Mastodon isn’t a text only site. It’s a multimedia social media service.
Mastodon isn’t a text only site. It’s a multimedia social media service.
> ...isn’t a text only site. It’s a multimedia social media service.
Those can be made to work just fine without using Javascript, that's what all those fancy tags are for after all.
Those can be made to work just fine without using Javascript, that's what all those fancy tags are for after all.
I could make a car with wooden wheels too but since we have synthetic rubber it makes sense to use the best tool for the job.
Basic functionality that users expect from social media needs JavaScript. Endless scrolling is a simple example. Adding a comment reply or liking a post without reloading the page is another one.
Basic functionality that users expect from social media needs JavaScript. Endless scrolling is a simple example. Adding a comment reply or liking a post without reloading the page is another one.
A car with wooden wheels - as in the type used by Babylonians, not even the iron-rimmed wheels used by the Romans - would be suboptimal and not at all comparable to one running on rubber tyres. A site which does not depend on Javascript is not suboptimal, it is a local optimum which works best for many applications. Endless scrolling is a good example of how adding Javascript to a page can push it away from the local optimum which uses paging. While there are some areas where Javascript can be used to add actually useful features there are far more areas where adding Javascript makes the site less useable, more annoying, less responsive, less reliable and much heavier. That bit about using it to add comments without reloading the page is an interesting one since we're having a conversation on a Javascript-free social media site which reloads the page after every comment. It works just fine, doesn't it?
Is Craigslist unresponsive or heavy? It's using JS.
HN is a wonderful place but it’s a niche industry-only forum. The barebones nature of it works fine for the people here but products like Mastodon are attempting to be a much more broadly adopted general purpose product.
HN is a wonderful place but it’s a niche industry-only forum. The barebones nature of it works fine for the people here but products like Mastodon are attempting to be a much more broadly adopted general purpose product.
There are many reasons, from accessibility to security, performance to preference, why it is a reasonable expectation to be able to browse a web page without JS enabled.
JS can add to the core and turn paging into infinite scroll, or not require a page reload on an interaction but it should be enhancing, not fundamental. All core functionality should work without JS.
This was just a given for professionals in the industry less than a decade ago. The fact it isn’t anymore speaks loudly about the lack of mentoring and the low bar we have dropped to…
JS can add to the core and turn paging into infinite scroll, or not require a page reload on an interaction but it should be enhancing, not fundamental. All core functionality should work without JS.
This was just a given for professionals in the industry less than a decade ago. The fact it isn’t anymore speaks loudly about the lack of mentoring and the low bar we have dropped to…
Obviously they can. I've seen so much worse crimes.