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

I think it's a little disappointing. Almost all questions are about AI, and a few of them are written very suggestively. This may have been the last one I filled out.


They are already doing that. There is an official summer break until September 02.


As the top comment states, there is a lint rule, but you have to turn it on.


Every program can listen to keypresses via /dev/input


This is false. A process needs read permission on the relevant `/dev/input/` device, typically by running as root or as a user in a group like `input`. Normal desktop users generally should not be in the input group. Regular applications receive keyboard input through the compositor/windowing system.


Not on my machines, or most for that matter.



If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.


Relying on porcelain commands' output is the official way of interacting with git, they famously always refused to break it into a library. Nobody is going to use the low level git commands because: 1. Their output isn't any more reliable than the porcelain, and 2. How the porcelain uses them is also subject to change, so your UI might end up doing something different from the git high level command which is undesirable.

At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.


That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing



> "Goulash Programming Night" sounds almost like a cooking marathon for sleep-deprived computer science students. What began in 2002 in a basement room in Karlsruhe with a few technology enthusiasts has since grown into one of the largest events of the Chaos Computer Club. The topics are wide-ranging: the core consists of hardware and software development, as well as data security. In addition, data protection, digital policy, and many other fascinating subjects are covered: How do you cook the perfect goulash? Can you craft beautiful jewelry from hardware scrap? How does a sewing machine actually work? How do you fly spaceships?


Wenn wouldn't have pearls like while (dst++ = src++);


What a wierd phrasing. It reads to me like it excludes the possibility of it being the same.


It's said this way because the default assumption is that a school district extends only to city or county lines. They can be larger or smaller, though.


"can be" ≠ "must be"


"can be" is used to list all possible values, which is where the confusion arises. It sounds like: ∀x, x>C v x<C.

"Might be", I think would be better.


"can" can be a synonym for "might" / "may"

(purists would argue that it can't, but common usage trumps purism)

Also, I will point out that, even from the perspective of formal logic, the original statement has "city or county". In other words there is no single fixed C - C could be a city or a country. Since counties can be larger than cities, it stands to reason that a school district could be larger than the size of a city while being equal to the size of a county. And can be smaller than the size of a county while being equal to the size of a city.

So, even assuming that the original statement is taken to have the logical meaning you've interpreted, that meaning does not technically forbid school districts from being equal to the size of a county (as long as that county is larger than some city, so that we can still make the true statement "this district is larger than a city"), nor from being equal to the size of a city (as long as that city is smaller than some county, so that we can still make the true statement "this district is smaller than a county").


MAY is the correct choice.

https://www.rfc-editor.org/rfc/rfc2119


This is not in the context of a requirement level. The definition of MAY as defined there makes no sense here.


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

Search: