News for hackers. Stuff that matters.

ndegruchy

Re:Firefox 147 Will Support the XDG Base Directory Specification on Thursday November 20, 2025 @09:56AM (#45993211)
I think there is probably a lot of work to do to fully pry the .mozilla folder apart. For a long time they've simply shipped everything in that folder and rolled with it. Making decisions on what is actually cache and what is user config vs "application data" is probably going to be harder than splitting the folder.
Re:Firefox 147 Will Support the XDG Base Directory Specification on Thursday November 20, 2025 @09:43AM (#45993053)
This is great news. Firefox respects the system-defined folders on Windows and macOS. Linux, being the free spirit it is, doesn't have a 'standard'. XDG makes recommendations that make a certain amount of sense and aligning to that is a great step forward for such a large project.
Re:A brief history of Time Machine (2024) on Monday November 10, 2025 @08:33AM (#45875850)
I've not had much of a problem with Time Machine. It works as advertised and does so quietly and without much input. The only thing I've had to do is turn off scheduled backups, as it tries to do a backup while I'm on a slow connection. This is because it can still see my NAS over Tailscale. I just put the menubar icon up there and trigger it when I get home.

I wonder if most folks have different expectations from it. Most of the HN crowd are probably already familiar with the usual suspects, so the lack of options and visibility into the process are probably concerns. For most folks, though, I imagine it's turn it on and forget it.

Re:Don't forget these tags to make HTML work like you expect on Monday October 27, 2025 @09:12AM (#45720665)
I do.

`<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.

Re:Jane Goodall has died on Wednesday October 01, 2025 @03:45PM (#45442414)
What a phenomenal woman, scientist and activist. We could use more people like her.

Rest in peace, Jane.

Yeah, the Windows directory story is a mess. Of all the vaunted backwards compatibility they offer, there are some very strange user-facing breaks that don't make much sense. The Home directory structure being one of them.

%APPDATA% is _fairly_ consistent for the past ~20 years. Local and LocalLow are odd distinctions, but have some interesting backgrounds. I don't find many programs abusing them. Roaming being the only real oddball that I find preferences for that aren't overridden by one of the other two folders.

It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session.

User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.

You only really see ~/.var for flatpaks.
> Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.

This is a fair take, and something that I've considered when going down the obsessively organized path.

Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_.

However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec.

> This isn't silly. At all.

I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user.

> but Windows isn't a monolith

It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way.

WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.

Oh, I'm well aware of this on Windows. It's stupid and easy enough to fix for the developer, but I'm also aware there is virtually no desire to implement.
I disagree with this.

macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would put data in `$HOME/.Application Data/Local/` on Linux. Why would macOS get bundled in with Linux? Because it's a unix? That's silly.

Personally, I have my zsh config repoint those directories into `~/Library/Application Data`, though (as some have pointed out) it's probably better to put some of those folders in `~/Library/Preferences`.

Re:Take Two: Eshell on Sunday July 06, 2025 @10:41AM (#44481187)
I feel like most folks misunderstand Eshell when going into it. It's not really their fault, as they _expect_ something bash-like, and in many ways it is. However, Eshell is _not_ bash. It's not zsh. It's not fish. It's Eshell. When you use Eshell, you get a marriage of command-line tools and Emacs. This isn't always the best case, and some tools are awful to try and use in Eshell.

Eshell shines when you're looking to use Emacs to do stuff in the shell, but not really deal with the shell itself. It will dutifully run whatever program you feed it, but the real magic is when you want to deal with the output. You can redirect outputs to buffers, which you can then manipulate with Emacs familiarity. You can even handle remote sessions just as easily as you would open a remote file in TRAMP. I've used this on many occasions to edit a remote config file, then trigger Eshell, which puts me in that directory, to then restart the service without having to launch a separate SSH session or terminal.

While there are a lot of clunky bits of Emacs, I feel like Eshell gets an especially bad rap. Some of it's justified: It presents itself as a bash-like interface, while actually having vastly different ways of handling things. I feel like folks don't really get the idea that it's an interactive Emacs session, a worksheet for the command-line that lets you ingest data from external tools in a more ergonomic way than doing `shell-command` or similar.

Re:The Prime Reasons to Avoid Amazon on Saturday July 05, 2025 @08:25PM (#44476689)
I honestly wish this were the case for 80% of the calls I make to local stores. Most people they have working the phones do not care about the inventory and will just say they're out of stock or don't know if there are any on the shelves. This goes double for requesting a special item from a store that would normally carry it, but doesn't. They put the order into their "system" and then it disappears, never to be heard from again.

Calling retail stores to do anything other than to see if they're open or, in the case of restaurants, get a reservation is just wasting time. At least for the retailers that I've communicated with.

Because he got paid $0. They hired him as an “intern” or volunteer.
Re:Show HN: Firefox from Ramdisk (macOS Only) on Saturday May 31, 2025 @11:39AM (#44144963)
Neat, this looks a lot like the Linux-focused Profile Sync Daemon[1], which can move your profile to a RAM-backed tmpfs. PSD does more browsers, though. I wonder if PSD could work on macOS, too.

[1]: https://github.com/graysky2/profile-sync-daemon

Where's the outcry and rage from the MPAA and RIAA that the infringement on their copyright is for more than all the money in the world combined?

It's fine to nail a $10m verdict against a guy with no money, but dare to tread on the beloved and bespoke * aI iNdUsTrY * and suddenly you've got better things to do?

Re:Comparison of Spreadsheet Software on Friday May 23, 2025 @04:14PM (#44076227)
Comparison of Spreadsheets, advertisement for Grid.is.

I guess it really matters what you need. Is Numbers going to take over accounting firms? No, they need Excel because it's Excel and that's what they use. If you need a free spreadsheet program, there are plenty. Google Sheets, Numbers, LibreOffice, Gnumeric. They're not going to change the way you use spreadsheets, but they'll put shit in columns and calculate to varying degrees of accuracy. Which is what most folks want/need.

Re:Mozilla to shut down Pocket on July 8 on Thursday May 22, 2025 @02:33PM (#44065190)
I remember requesting the source code after they bought it[1]. They kept kicking the can down the road. It looks like they dumped everything in a monorepo on Github[2] which does nothing good for anyone.

Seems like Mozilla is dead-set on grinding up any good will they get from users.

[1]: https://discourse.mozilla.org/t/pocket-source-code/43686/11 [2]: https://github.com/Pocket/pocket-monorepo

So we can't dragnet surveil our own people? Hmm, how about we just buy it from the folks who do it for work? Then _we're_ not doing it. _We're_ just buying a bundle of data from a broker.

Couple this with the idea that we soft-spy on our Allies and then trade that data for their spying on our people and yeah, wow.

Re:Ask HN: Any MacBook Alternative? on Wednesday May 21, 2025 @04:24PM (#44055930)
> Apple computers are now spyware

What? By what definition? Is there evidence of this?

I mean, you can get yourself any old laptop and run Linux on it, but it won't compare with a system that is run by the company building the hardware.

This was released on GitHub 5 years ago. Hardly new. Nice set of tools though. Glad to see the legacy of the old PowerToys living on.
Yeah, I don't have my KDE setup in front of me right now, but I feel like there is something in the keyboard settings that could emulate at least a subset of Epsanso's features. I know on macOS/iOS there is text replacements which are a simple replacement mechanism, without the ability to insert variables.

I agree, though, seems like a ripe piece of low-hanging fruit that could be better integrated and safer. Even if the lower level stuff just hands it off to a dedicated tool that handles the replacement text, at least the OS/WM should be the one watching the keys.

No, not especially. What Espanso does is watch keystrokes, looking for the specific combinations in the config to then expand the shortcut to whatever it's defined to do. There is similar functionality built into macOS/iOS but it's _far_ less featured.

In System Settings > Keyboard > Text Input > Text Replacements

Basically, it's a simple replacement tool, which works for some repetitive stuff (i.e. my name, my email address, my phone number, or a short string for closing out emails). Epsanso, and tools like it, do so much more.

Edit to add: Data detectors on macOS/iOS look for existing strings of text that you can then get more contextual options for. Things like dates and times might open up a calendar view, phone numbers might offer a menu to dial it, or addresses might offer the ability to open a map for it. Absolutely useful, but not the same thing.

Re:Working with Git Patches in Apple Mail (2023) on Sunday May 18, 2025 @05:12PM (#44024346)
Yeah, I used DAVMail with Emacs+MSMTP+MPOP+notmuch for ages. Works really well, the only occasional thing I had to do was reauthenticate the token, which pops up in a browser window.
Thanks for that. I kind of wondered how SQLite was relevant to SCM, but I hadn't really bothered to investigate it. Still, having it in a format that can be browsed and reasoned about is handy. Not that Git is any worse in this regard.

Plus, the only thing I need to do to transfer it to a new disk or network location is to move the `.fossil` file, since everything is nicely self-contained.

+1 for this. I love having a self-contained, syncable GitHub-lite. It uses SQLite for the format, too, which makes it easy to discover the internals.

It just needs some more 'modern' themes

So, he's Bob Pope?

...I'll see myself out.

Re:Memory-safe sudo to become the default in Ubuntu on Tuesday May 06, 2025 @09:36AM (#43904968)
Seems like the trifecta group is /just/ about migrating tools to rust? Am I understanding that right?

I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.

Re:Antinote: Beautiful macOS Productivity Scratchpad on Monday May 05, 2025 @09:45AM (#43895063)
Neat. Kind of like a scratch pad/buffer. I like that they're embracing the idea that they're not a note-taking app in the traditional sense. It's just for grabbing ideas as they happen and organizing later.
Re:Charmstone: Spatial Switcher Launcher for macOS on Thursday May 01, 2025 @07:47AM (#43856424)
Nice app. I use it as a sort of 'second dock'. Apps and folders I'd like to be able to get to quickly enough, but don't need frequently enough that they have a spot on my dock.

Older »