Hacker Newsnew | past | comments | ask | show | jobs | submit | jmholla's commentslogin

> You continue to use it for something else? How is it different from any other default shortcut you don't line and change?

The author points out that Apple defaults often don't allow you to reuse them. They talk pretty far in the article about how that can't map globe+H to a different function. So, this theoretical is about them not being able to continue using their combination for what they want at Apple's whims.


Blocking keybinds is from a different section of the article

It also applies to application providers. The law requires them to have their applications ask the OS how old the user is whenever it is downloaded and launched.

Two important definitions that might surprise people:

(a) (1) “Account holder” means an individual who is at least 18 years of age or a parent or legal guardian of a user who is under 18 years of age in the state.

(a) (2) “Account holder” does not include a parent of an emancipated minor or a parent or legal guardian who is not associated with a user’s device.

(i) “User” means a child that is the primary user of the device.

User is the most surprising here. It really should just be minors, or non-emancipated minors. Further, I think there are interesting ways the definition of account holder and user combined play out in interpreting the rest of the law.


Colorado is trying to copy this law right now, too.

As others have pointed out, this is just a foot in the door. There's also a part of the law this article doesn't cover that requires EVERY application to query this information on every launch, regardless of whether or not the application has any age related limitations.

The language I found was:

> when the application is downloaded and launched

So it looks like the law only requires it on first launch. Which makes sense if the application can only be run from that one account. Apps that can be launched from multiple accounts are not singled out in the law, but the spirt of the law would have you checking what account is launching the app and are they in the correct age range.


That's not a guarantee. It's up to how the courts interpret that and. Given that this law is meant to handle a moving target like age, I fully expect them to interpret it as its disjunctive form.

The term "application" is explicitly defined in the bill and has a far narrower scope than just the word "application" on it's own means.

Far narrower is doing a lot of heavy lifting in your response.

> (c) “Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.

If your device can connect to a covered application store, every application on your computer must follow this.


I think that OP's point was that the alternative is even more locked down. There is no option for people who don't want to be nannied.


I stopped patronizing Best Buy when their store phone numbers started going to a corporate call center that couldn't tell me if something I was looking for was in stock at the store.


They do show stock on their website. For other things such as price matching their chat service has worked well for me and seems to be backed by real people. I can't remember the last time I tried to call in.


> Except companies provide wholly inadequate safeguards and tools. They are buggy, inconsistent, easily circumvented, and even at time malicious. Consumers should be better able to hold providers accountable, before we start going after parents.

We could mandate that companies that market the products actually have to deliver effective solutions.


Cue blog posts about section 230 and how it’s impossible to do hard things and parents should be held accountable not companies, meager fines, captured bureaucrats, libertarians, and on and on…


Here's a little extra magic so that you don't even need to be in the root of the repository to create such a temporary file (you'll have to change the readlink invocation if you're on MacOS):

    git-ignore-local () {
      root=$(git rev-parse --show-toplevel)
      path=$(readlink -f "$1")
      # ${path#${root}} should suffice if you don't have realpath
      relpath=$(relpath -m --relative-to="$root" "$path")
      echo "$relpath" >> "${root}.git/info/exclude"
    }
Edit: You could also put the function contents as an executable on your PATH called `git-ignore-local` then it becomes something you can invoke as `git ignore-local`.


FYI: you may want to check `git rev-parse --show-cdup`

- in root of the repo, it prints empty string

- if you're 1 level deep it prints `../`

- if you're 2 levels deep it prints `../../`

One minor drawback: inside `.git` subfolder, it always prints empty string too.


Whoops, there should be a slash after `${root}` in that last line.


You still want to put these kinds of things in every project where you are collaborating. You can't depend on everyone to know and do this, so best to just be prepared for those who don't.


I'd prefer to leave them out. That way I can see who's not paying attention when they make commits and are just doing `git commit -a -m "yolo"`.


Surely you'll be able to tell who's YOLOing commits without allowing junk into your repo that you'll have to clean up (and it almost certainly be you doing it, not that other person).

DS_Store files are just annoying, but I've seen whole bin and obj directories, various IDE directories, and all kinds of other stuff committed by people who only know git basics. I've spent way more effort over time cleaning up than I have on adding a comprehensive gitignore file.

It takes practically no effort to include common exclude patterns and avoid all that. Personally, I just grab a gitignore file from GitHub and make a few tweaks here and there:

https://github.com/github/gitignore/


I prefer to leave them in. Why waste my time reviewing PRs that would have been fin otherwise. And, why waste other people's time.


I have this two liner as part of my post-os-install setup script:

    curl -fsSL https://www.toptal.com/developers/gitignore/api/linux > ~/.gitignore
    git config --global core.excludesFile ~/.gitignore


Assuming your global config is ~/.config/git/config, you can download it to ~/.config/git/ignore and not need the overriding explicit excludesFile.


Huh, TIL


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: