Just because its a finite space that may eventually be discovered is a poor reason to announce where things are!
Besides, the time to scan the whole board is too time consuming in a battleship game, but scanning the whole internet on the other hand only take a few minutes[1]
Even within infosec, certain types of information disclosure are considered security problems. Leaking signed up user information or even inodes on the drives can lead to PCI-DSS failures.
Why is broadcasting your records treated differently? Because people would find the information eventually if they scanned the whole internet? Even then they might not due to SNI; so this is actually giving critical information necessary for an attack to attackers.
With the public ledger or not, you will still need to implement proper security measures. So it shouldn't matter if your address is public or not, in fact making it public raises the awareness for the problem. That's the argument.
I'd rather .agents/claude or something so we can get these files out of the root directory, which, at least for typescript projects, is already a confetti-like jumble of json files for every little "simple" tool that needs its own configuration file.
I get why package.json isn't enough. But would a .config directory standard really have hurt us so much?
try {
// Parallel execution of independent operations
const [config, userData] = await Promise.all([
readFile('config.json', 'utf8'),
fetch('/api/user').then(r => r.json())
]);
...
} catch (error) {
// Structured error logging with context
...
}
This might seem fine at a glance, but a big grip I have with node/js async/promise helper functions is that you can't differ which promise returned/threw an exception.In this example, if you wanted to handle the `config.json` file not existing, you would need to somehow know what kind of error the `readFile` function can throw, and somehow manage to inspect it in the 'error' variable.
This gets even worse when trying to use something like `Promise.race` to handle promises as they are completed, like:
const result = Promise.race([op1, op2, op3]);
You need to somehow embed the information about what each promise represents inside the promise result, which usually is done through a wrapper that injects the promise value inside its own response... which is really ugly. // Parallel execution of independent operations
const [
{ value: config, reason: configError },
{ value: userData, reason: userDataError },
] = await Promise.allSettled([
readFile('config.json', 'utf8'),
fetch('/api/user').then(r => r.json())
]);
if (configError) {
// Error with config
}
if (userDataError) {
// Error with userData
}
When dealing with multiple parallel tasks that I care about their errors individually, I prefer to start the promises first and then await for their results after all of them are started, that way I can use try catch or be more explicit about resources: // Parallel execution of independent operations
const configPromise = readFile('config.json', 'utf8')
const userDataPromise = fetch('/api/user').then(r => r.json())
let config;
try {
config = await configPromise
} catch (err) {
// Error with config
}
let userData;
try {
userData = await userDataPromise
} catch (err) {
// Error with userData
}
Edit: added examples for dealing with errors with allSettled[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Edit: just read https://devblogs.microsoft.com/commandline/edit-is-now-open-... and it seems that all 32bit windows versions had edit. I was probably using Windows XP 32 the last time I remember using edit
My idea was very similar, using TigerVNC and just launching Steam without a WM. Unfortunately I think I lost the code for it