Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple. Apple Please

digipres.club

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Apple. Apple Please

#51

Post by KolenCh »

paulmd wrote: post #48
paulmd wrote: post #37

Earlier quoted context omitted.

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.

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…

Portmaster?

Re: Apple. Apple Please

#52

Post by paulmd »

KolenCh wrote: post #51
paulmd wrote: post #48

Earlier quoted context omitted.

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…

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

Re: Apple. Apple Please

#53

Post by sumuyuda »

aidos wrote: post #32
xyst wrote: post #30

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…

> 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).

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.

Re: Apple. Apple Please

#55

Post by KolenCh »

paulmd wrote: post #52
KolenCh wrote: post #51

Earlier quoted context omitted.

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

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.

Re: Apple. Apple Please

#56

Post by amelius »

MOARDONGZPLZ wrote: post #4
kevingadd wrote: post #2

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.

> 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)

Re: Apple. Apple Please

#57

Post by dangus »

hagbard_c wrote: post #47
dangus wrote: post #43

Earlier quoted context omitted.

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.

> ...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.

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.

Re: Apple. Apple Please

#58

Post by MawKKe »

judofyr wrote: post #26
ahoka wrote: post #18

Earlier quoted context omitted.

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...

Re: Apple. Apple Please

#59

Post by hagbard_c »

dangus wrote: post #57
hagbard_c wrote: post #47

Earlier quoted context omitted.

> ...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.

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.

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?

Re: Apple. Apple Please

#60

Post by PaulRobinson »

dangus wrote: post #43
sharpshadow wrote: post #41

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.

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…

Post reply on HN