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

While Fossil uses SQLite for underlying storage (instead of the filesystem directly) and various support infrastructure, its actual format is not based on SQLite: https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki

It's basically plaintext. Even deltas are plaintext for text files.

Reason: "The global state of a fossil repository is kept simple so that it can endure in useful form for decades or centuries. A fossil repository is intended to be readable, searchable, and extensible by people not yet born."


If you paste the comment it replies to into ChatGPT, it generates almost exact same answer as that comment. Also, "Finally, ..." and "it's not A, it's B" is a good tell.

Damn, I tried doing what you did and got a similar response too, down to exact wordings like "short answer, long answer" and "conservative maintenance". I will admit i was too quick to dismiss the accusation in my previous reply.

> If you paste the comment it replies to into ChatGPT, it generates almost exact same answer as that comment.

But would it have generated almost the same comment 4 hours ago, when the comment was posted here?

A few months ago I posted a comment in a thread about some new law that would not have been needed if a law from many years early had not seemingly arbitrarily limited itself to some particular cases. I speculated on some reasons why the original law might have been written that way.

A couple hours later I asked an LLM about it (Perplexity) and it gave the same reasons I had guessed. I checked the links it provided to get a suitable reference if the topic ever came up again...and it turned out my comment was its source!


Not with small files.

If that's about using predefined dictionaries, zstd can use them too.

If brotli has a different advantage on small source files, you have my curiosity.

If you're talking about max compression, zstd likely loses out there, the answer seems to vary based on the tests I look at, but it seems to be better across a very wide range.


No, it's literally just compressing small files without training zstd dict or plugging external dictionaries (not counting the built-in one that brotli has). Especially for English text, brotli at the same speed as zstd gives better results for small data (in kilobyte to a few of megabyte range).

How do you implement this keyboard navigation with SSR (if you use buttons)?

https://www.radix-ui.com/primitives/docs/components/radio-gr...


I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.


That's what I mean: if you reimplement it, you need client-side JS to support keyboard navigation.


Yes, but it reviews not only PRs in your repos, it also reviews any PRs you create on any repo and marks these as if you requested the review. Unacceptable.

You can disable it here: https://github.com/settings/copilot/features under "Automatic Copilot code review".


Thanks!

I checked that link. That setting says -

"Show Copilot

Enable Copilot for all GitHub features, including navigation bar, search, and dashboard.

When disabled, Copilot will be hidden and unavailable. This setting does not apply to Copilot search on GitHub Docs."

Does this disable PR code reviews too? The setting description doesn't say anything about PR reviews. If it does disable Copilot PR review comments, which repos does it affect? It cannot disable PR reviews for my PRs on other people's repos, can it?

Anyway thanks for your answer. Much appreciated.


Somewhat related: The other day I was in the mobile instead of the notebook and I saw a confusing link, and when I clicked it requested a review. I think it was bad UI or my natural stupidity instead of artificial intelligence. Anyway, I didn't find how to unrequest the review :(


"Too late now, I suppose, but the only file extension I would endorse is “.markdown” [...]

(I personally use “.text” for my own files, and have BBEdit set to use Markdown syntax coloring for that extension, which is why I never saw a need to endorse an official extension.)"

https://daringfireball.net/linked/2014/01/08/markdown-extens...


Thanks for finding this post. I did a quick search for it and came up empty.


It's fast, easy to implement, has very concise code, takes any key length up to 256 bytes, comes from a famous cryptographer, and there weren't a lot of alternatives.


It's not, iOS 18.7.3 also released https://support.apple.com/en-us/125885


It is not available. The release is 2 days old and the download is not showing up on the phone.


My iPhone 12 mini was bugging me about it the other day. I declined it. I don't want liquid glass and whatever else it does to make that phone feel slower and less usable. I refuse to buy a newer iPhone. They are all too big.


12 mini user here. Phone is just as slow and usable as prior to updating to 26. (Immediately after updating was slow for a little while which scared me initially, but I think it was just still doing some background stuff related to updating).


13 mini here too and last iPhone/smartphone I will buy.

Settings > Accessibility > Motion > Reduce motion and Settings > Accessibility > Display and text size > Reduce transparency make it usable-ish. There is hundreds of ms lag at times inexplicably w/touch and upwards of a second plus when connected to CarPlay. But I can't blame iOS 26. I have to reboot this thing sometimes weekly, sometimes less frequent than that since iOS 18. I can no longer justify spending hundreds of dollars on things that don't meet my standard of "works" even if it's 2025.


Wrong. Enable 18 beta, refresh, install 18.7.3, disable beta. Problem solved.

Security updates are typically available for the most current 2 OS versions, and 18 is still officially supported, perhaps until 2026 or 2027. 18.7.3 exists with similar security updates as 26.2. It may not show up on iPhone as an update option without being on the beta 18 channel because they're trying to force people onto 26 using dark patterns, but it shows up on iPadOS without any additional magic.


Having to toggle the beta is not acceptable and the parent is right to class that as not available


Thanks for your support. I also find these dark patterns unacceptable and even as a technical person one needs forums to figure out why it only shows the 26.2 update very prominently and not the relevant one. x


We can argue over whether 3 extra taps to access counts as "acceptable" or not, but it's clearly not enough of a hurdle to be considered "not available". Otherwise you might as well count iOS 26 as not being available either, because that needs at least 4 taps to install (settings -> about -> software updates -> install -> enter pin -> ok).


It's about being a hidden trick, and you know it.


Way to move the goalposts. The comments prior to your comment were:

>Liquid Glass is now mandatory if you care about security.

and

>It is not available. [...] the download is not showing up on the phone.


I stand corrected on this front


IOS 26 is even less acceptable, so pick your poison.


Let's not labour the definition of acceptable to derail the conversation further


Genuinely didn’t know it was hidden behind a beta flag. Ty for this!


This worked for me, thanks.


Because it's economically infeasible to drive?


Yes, but also it's just annoying to have a car in NYC. For many routes the subway is going to be faster than driving and sitting in traffic, unless you're traveling between outer borough neighborhoods that only have a connection in Manhattan. If you're making that commute often (say, Bushwick to East Flatbush, or Flushing to Canarsie), a car might make sense, but then this whole congestion pricing thing doesn't apply to you.

Transit is $3/ride (in a few weeks), 24 hours, and all over the city. It's not perfect, but for the vast majority of cases owning a car in NYC is just not really worth it. If you need one because you have a weekend home out in Long Island or up in the Hudson Valley, you can afford the $9 toll.


It's economically infeasible for a large percentage of people to drive in a dense urban area, period.

That's true even without congestion pricing. A city would go broke and bulldoze itself trying to add enough stacked lane, highways, and parking to handle everyone who would prefer to drive in or through if the capacity existed.


It would be before the congestion fee anyway - parking costs alone are absurd and cumbersome right?


Well yeah — cars are expensive.


That was the case before congestion pricing too.


This fits the template in the post you're replying.


No; it was already economically infeasible, and thus the drop was not marked.


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

Search: