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

Note on Windows you can disable the touch device and it goes back to the old density. Don't know if Macs support it.


Are all commercial uses illegal or only those that display your likeness?


A news broadcast for a commercially run news network does not need releases nor does it need to compensate people who walk through the background.

Likewise, journalistic photographs (for commercial use) are legal and don't require releases or compensation for people who are part of the scene.

https://www.krages.com/ThePhotographersRight.pdf (note the credentials in the lower right corner - and if you want to know more I'd suggest https://www.krages.com/bpkphoto.htm )

    The general rule in the United States is that anyone may take photographs of whatever they want when they are in a public place or places where they have permission to take photographs. Absent a specific legal prohibition such as a statute or ordinance, you are legally entitled to take photographs. Examples of places that are traditionally considered public are streets, sidewalks, and public parks.


> Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release.

How far is Clang on reflection and contracts?


Clang’s C++2c implementation status page simply says “no” for both reflection and contracts. GCC’s says “yes”.

https://clang.llvm.org/cxx_status.html

https://gcc.gnu.org/projects/cxx-status.html


That much I'm aware, but that's just about feature availability. I was wondering how far the implementations have progressed internally, despite the features being unavailable.


Clang basically doesn't implement anything regarding reflection right now. There is some support for parsing (https://github.com/llvm/llvm-project/blob/main/clang/test/Pa...) but that's it. There are some open PRs for other parts though.


Thanks, yeah, I was worried that might be the case. Given how complicated these features sound, it makes me wonder if they're gonna finish before the decade is over...


Bloomberg has a clang implementation of reflection: https://github.com/bloomberg/clang-p2996

It has been on compiler explorer for a while

This has been used to add reflection to simdjson


If one power bank has independent probability p of failure, then n of them have probability 1 - (1 - p)^n of failure.

What you're saying is equivalent to claiming that this quantity is somehow independent of n.


Depends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.


Assert doesn't work like that in any language.


It does in Rust: assert is always enabled, whereas the debug-only version is called debug_assert.

But yes, “assert” in most languages is debug-only.


He said

> some people would expect it to enforce that the pointer is non-null, then proceed

No language magically makes the pointer non-null and then continues. I don't even know what that would mean.


If you don't even know what that would mean then it's premature to declare that nothing works that way. Understanding the meaning is a prerequisite for that.

In this case, it may help to understand that e.g. border control enforces a traveler's permission to cross the border, then lets them proceed.


Say someone has a very sensitive secret (say, a Bitcoin private key) in their free private Github repo, and uses Copilot on that repo and touches the secret with it. Would you be willing to assure here that toggling that setting would not affect the likelihood of that secret leaking, and that that likelihood is also unaffected by whether the account is Business or Free?


I assume the court case [1] is referring to 10 U.S. Code § 3252 [2]?

[1] https://www.courtlistener.com/docket/72379655/134/anthropic-...

[2] https://www.law.cornell.edu/uscode/text/10/3252


You started using it because it had that capability I imagine, not because it is the default. You could easily just alias a command with the right flag if the capability was opt-in.


No, because it was default.

> You could easily just alias a command with the right flag if the capability was opt-in.

I tried a search to make grep ignore .gitignore because `--exclude=...` got tedious and there was ripgrep to answer my prayers.

Maintaining an alias would be more work than just `rg 'regex' .venv` (which is tab-completed after `.v`) the few times I'm looking for something in there. I like to keep my aliases clean and not have to use rg-all to turn off the setting I turned on. Like in your case, `alias rg='rg -u'`, now how do you turn it off?


> I tried a search to make grep ignore .gitignore because `--exclude=...` got tedious and there was ripgrep to answer my prayers.

To be clear, I was not suggesting an alias for grep, but for a hypothetical alternate ripgrep that searches everything by default but has a flag to skip ignored files. Something like

  alias rgi='rg --skip-ignored'
or whatever. Or if it came with a short flag that could work too, so you could use it without an alias easily.

> Like in your case, `alias rg='rg -u'`, now how do you turn it off?

You don't use the same name, you make a new alias. Like rgi or something. Bonus point is you find out immediately if it's missing.


I use very short aliases with fallbacks to standard tools if ripgrep/fd/bat/... isn't installed. For my use searching files in `.gitignore` is useless 9/10 times, why would I want that to be default?

> Or if it came with a short flag that could work too

It does, `-.` for hidden and `-u` for hidden + ignored.


> It does, `-.` for hidden and `-u` for hidden + ignored

I'm not sure you understood what I wrote? Those are opt-out. The entire discussion is about opt-in.


> Those are opt-out. The entire discussion is about opt-in.

Depends on your perspective, to me you have them flipped, and enabling them is "opt-in", i.e: "now I would like to see the hidden files please".

But I don't think I misunderstood you. You're telling me I should prefer hidden files to be the default, and I disagree and give my arguments. It's not more complicated than that.

To me rg only follows the same principle as the rest of my tools, fd requires `-H/--hidden`, ls `-a` or `-A` and so on. It is a big reason to why I prefer rg and fd over grep and find. Which brings us back to your first comment:

>> You started using it because it had that capability I imagine, not because it is the default.


`\rg foo` or `command rg foo`


I agree, it's a great tool with a catastrophically wrong default that silently and unpredictably catches people off-guard. I've tried using ripgrep many times but have been burnt too many times and can never trust its search to be comprehensive. It absolutely fails to find important stuff, and I can rarely predict whether the files it's going to skip intersect with my files of interest. And at this point I'm too burnt to care to pass flags to stop it from doing that. Which basically means I always run grep unless I know the number of matches beforehand and it's too large a directory to wait a few seconds for, in which case I run grep after rg fails to find it.

If it actually matched grep's contract with opt-in differences that'd be a gamechanger and actually let it become the default for people, but that ship seems to have sailed.


> getting a different perspective (to a dog, dog food is delicious!)

Didn't you just destroy your own argument? If dog food is expected to be more delicious to dogs than humans, how is eating it supposed to indicate anything about whether it's well-made for the dog? Shouldn't you have your dog eat it, rather than yourself?

So isn't your manager's alternative the one that actually makes sense?


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: