Hacker News new | past | comments | ask | show | jobs | submit | InsideOutSanta's comments login

Yeah, same. On a phone or smaller e-reader, regular PDFs designed for normal book size are often unreadable.

>It would be crazy if in an auto factory people were measuring to make sure every angle is correct

Yeah, but there's still something checking the angles. When an LLM writes code, if it's not the human checking the angles, then nothing is, and you just hope that the angles are correct, and you'll get your answer when you're driving 200 km/h on the Autobahn.


>Strangely I seem to have built all of my software without dependency injection

I'm going to guess that you've most likely used dependency injection without even thinking about it. It's one of those things you naturally do because it makes sense, even if you don't know it has an actual name, frameworks, and all that other stuff that often only makes it more confusing.


The Mac image editor Acorn uses SQLite as its file format. It's described here:

https://shapeof.com/archives/2025/4/acorn_file_format.html

The author notes that an advantage is that other programs can easily read the file format and extract information from it.


It is clearly a composite file format [1]:

> Acorn’s native file format is used to losslessly store layer data, editable text, layer filters, an optional composite of the image, and various metadata. Its advantage over other common formats such as PNG or JPEG is that it preserves all this native information without flattening the layer data or vector graphics.

As I've mentioned, this is a good use case for SQLite as a container. But ZIP would work equally well here.

[1] https://flyingmeat.com/acorn/docs/technotes/ACTN002.html


>Most extensions have three characters, which means the search space is pretty crowded. You may want to consider using four letters.

Is there a reason not to use a lot more characters? If your application's name is MustacheMingle, call the file foo.mustachemingle instead of foo.mumi?

This will decrease the probability of collision to almost zero. I am unaware of any operating systems that don't allow it, and it will be 100% clear to the user which application the file belongs to.

It will be less aesthetically pleasing than a shorter extension, but that's probably mainly a matter of habit. We're just not used to longer file name extensions.

Any reason why this is a bad idea?


A 14-character extension might cause UX issues in desktop environments and file managers, where screen real estate per directory entry is usually very limited.

When under pixel pressure, a graphical file manager might choose to prioritize displaying the file extension and truncate only the base filename. This would help the user identify file formats. However, the longer the extension, the less space remains for the base name. So a low-entropy file extension with too many characters can contribute to poor UX.


> it will be 100% clear to the user which application the file belongs to.

The most popular operating system hides it from the user, so clarity would not improve in that case. At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format.

Otherwise I think the decision is largely aestethic. If you value absolute clarity, then I don't see any reason it won't work, it'll just be a little "ugly"


I don't even think it's ugly. I'm incredibly thankful every time I see someone make e.g. `db.sqlite`, it immediately sets me at ease to know I'm not accidentally dealing with a DuckDB file or something.

Yes, oh my god. Stop using .db for Sqlite files!!! It’s too generic and it’s already used by Windows for those thumbnail system files.

>The most popular operating system hides it from the user, so clarity would not improve in that case.

If you mean Windows, that's not entirely correct. It defaults to hiding only "known" file extensions, like txt, jpg and such. (Which IMO is even worse than hiding all of them; that would at least be consistent.)

EDIT: Actually, I just checked and apparently an extension, even an exotic one, becomes "known" when it's associated with a program, so your point still stands.


> At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format.

mostly for executable files.

I doubt many Linux apps look inside a .py file to see if it's actually a JPEG they should build a thumbnail for.


Your doubts are incorrect. There's a fairly standard way of extracting the file type out of files on linux, which relies on a mix of extensions and magic bytes. Here's where you can start to read about this:

https://wiki.archlinux.org/title/XDG_MIME_Applications

A lot of apps implement this (including most file managers)


I'm a little surprised that that link doesn't go to libmagic[1]. No doubt XDG_MIME is an important spec for desktop file detection, but I think libmagic and the magic database that underpins it are more fundamental to filetype detection in general.

It's also one of my favorite oddities on Linux. If you're a Windows user the idea of a database of signatures for filetypes that exists outside the application that "owns" a file type is novel and weird.

[1]: https://man7.org/linux/man-pages/man3/libmagic.3.html


libmagic maintains its own separate database from xdg. XDG db is meant from the ground up to have other apps add to it etc… so that one is the one apps use as a library usually, if they want to integrate nicely and correctly with other installed apps. libmagic is the hacking of the two :)

It’s tedious to type when you want to do `ls *.mustachemingle` or similar.

It’s prone to get cut off in UIs with dedicated columns for file extensions.

As you say, it’s unconventional and therefore risks not being immediately recognized as a file extension.

On the other hand, Java uses .properties as a file extension, so there is some precedent.


> call the file foo.mustachemingle

You could go the whole java way then foo.com.apache.mustachemingle

> Any reason why this is a bad idea

the focus should be on the name, not on the extension.


Why should a file format be locked down to one specific application?

Both species are needed:

Generic, standardized formats like "jpg" and "pdf", and

Application-specific formats like extension files or state files for your program, that you do not wish to share with competitors.


I think the Mac got this right (before Mac OS X) and has since screwed it up. Every file had both a creator code and a type code. So, for every file, you would know which application created it and also which format it was.

So, double-clicking the file opened it in the application it was made in, but the Mac would also know which other applications could open that file.


I couldn't find a way to contact the author, but in case he's reading this or anyone knows his contact information: I'd like to subscribe to your blog, but your RSS feed is currently broken.

> I couldn't find a way to contact the author

If you remove the "blog." subdomain and go to https://pipetogrep.org/ you are greeted by a typical "about me" page. It includes a link back to the blog, as well as a mailto link, and links to GitHub and LinkedIn profiles.


What are you, some kind of hacker wizard

This is Wizard News after all.

I want to subscribe to your comments but your RSS feed is currently broken.

I'm guessing you were being funny but https://hnrss.org/replies?id=44086171

Oh nice, thank you! Didn't know that was a thing.

Noted and thanks. I will try to get it fixed.

Hey, thanks for letting me know. I have not tried the RSS functionality of BSDG yet but I will try to get it fixed.

I think the main issue is that ampersands aren't escaped correctly.

RSS feed is fixed. Thanks again!

Somebody needs to bring back Fucked Company for AI companies.

Can we bring back Webshit Weekly while we're at it? RIP n-gate, you would have loved talking shit about AI companies.

That blog aged very well

> TikTok (business model: "Uber for Vine") is more popular than Facebook (business model: "Uber for Sino-Soviet Propaganda"), presumably because it bypasses the middleman and delivers the content straight from the source. Hackernews debates whether it's just a matter of time before it turns out to be evil, or whether a social-media application targeted at children and operated by a government full of genocidal monsters is and shall remain "fun." Other Hackernews point out that the app, which is operated by a company in which the murderous, barbaric Chinese government has an ownership stake, is mean to fat people.

> Github (business model: "Uber for README.MD") directs its employees to eat its own dog food. Because of Github's acquisition by Microsoft (business model: "Uber for customer abuse"), it turns out that what Github engineers are eating came out of the dog to begin with. Hackernews tries to figure out whether they, as customers of Microsoft's latest desperate attempt to get anyone to use Azure, have any control over their information, or whether they'd be better off remaining with their existing workstation-as-a-service provider, Apple (business model: "Uber for garden walls").


The prose makes my head hurt. Horribly written.

I'm sure an LLM would be up to the task of shit talking as a service. All the big models are probably trained on all of n-gate already. With a bit of high quality prompt engineering as your moat, raising a few million shouldn't be too arduous.

This is probably one of the most essential bits of advice you can get. Not only is it beneficial to your friends and career, but it's also beneficial for your mental health.

It's not easy, at least initially. Jealousy is an emotion that's easy to come by and hard to dismiss. It's also an emotion that makes you unhappy, so learning to feel pride and happiness instead of jealousy made my life immeasurably better. I don't care if it's reciprocal; I do it because it's right for others and it's right for me.


I've tried all of the options: Linkwarden, Linkding, Karakeep, Shiori, Wallabag, Grimoire—you name it, I've tried it. These are all great tools, and I use Karakeep myself, but I use it to bookmark and archive links, not as a "read it later" tool.

In my opinion, no self-hosted read-it-later tool can replace Instapaper or Pocket, as they focus on providing an exceptional reading experience in a native app that works offline. None of the self-hosted tools offer a comparable experience.

So, depending on how you used Pocket, there are either better or no self-hosted options.

I wish Mozilla would open-source Pocket so it could be made into a self-hostable option.

> Wallabag


They open sourced some stuff already https://github.com/Pocket

I’m in process of trying different tools.

I broke requirements down to 3 use cases

Links I visit often (general bookmarks) Links I visit once( read later) Links I preserve forever (offline storage)


You're not helping. You're doing something that the host or owner of the website does not want you to do, circumventing their protections. This means they'll end up strengthening their protections, which only makes things worse for everybody.

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

Search: