HackerTrans
トップ新着トレンドコメント過去質問紹介求人

oftenwrong

15,020 カルマ登録 14 年前
[email protected]

投稿

Pressurizing a Chicken Coop to Clean it [video]

youtube.com
2 ポイント·投稿者 oftenwrong·昨日·0 コメント

Hello TinyTree

tinytree.dev
2 ポイント·投稿者 oftenwrong·2 か月前·1 コメント

Apartments Are the Climate Solution Hiding in Plain Sight

sightline.org
3 ポイント·投稿者 oftenwrong·2 か月前·0 コメント

Traffic safety improvements frequently die by popular vote

fastcompany.com
5 ポイント·投稿者 oftenwrong·4 か月前·1 コメント

Adding Up What Urban Highways Cost

bloomberg.com
1 ポイント·投稿者 oftenwrong·4 か月前·1 コメント

The NIMBY Buyout Plan (2025)

substack.com
4 ポイント·投稿者 oftenwrong·5 か月前·0 コメント

Modeling Inclusionary Zoning's Impact on Housing Production in LA (2024) [pdf]

ternercenter.berkeley.edu
1 ポイント·投稿者 oftenwrong·7 か月前·0 コメント

The Surprising Lack of Good Permitting Data and What to Do about It

bostonindicators.org
6 ポイント·投稿者 oftenwrong·8 か月前·0 コメント

Four Strategies for Organizing Code (2016)

medium.com
2 ポイント·投稿者 oftenwrong·9 か月前·0 コメント

The Oddest Car Park in the World? (2015)

speedhunters.com
4 ポイント·投稿者 oftenwrong·9 か月前·0 コメント

Trusting builds with Bazel remote execution

blogsystem5.substack.com
4 ポイント·投稿者 oftenwrong·10 か月前·0 コメント

[untitled]

1 ポイント·投稿者 oftenwrong·10 か月前·0 コメント

コメント

oftenwrong
·一昨日·議論
I am anticipating a move away from git-style version control entirely.

One possible shape is something like unison-lang's CAS AST model:

https://www.unison-lang.org/docs/the-big-idea/

This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
oftenwrong
·17 日前·議論
Seems that it is already supported: https://docs.memcached.org/features/flashstorage/
oftenwrong
·先月·議論
Somewhat similar: https://github.com/facebook/dotslash
oftenwrong
·2 か月前·議論
I still have my copy of Learning Perl. Mostly because it represents a milestone in my learning. I have kept and obtained a number of other books simply because they are antiquated, special and/or classics that are interesting to read even if they are not that useful to me, like Codd's relational book, or Calendrical Calculations. I hope the AI is trained on these sorts of books, so that the knowledge can live on in a different way.
oftenwrong
·3 か月前·議論
I have long used underscores for _emphasis_, but I never made the connection that it was meant to resemble an underline until now.
oftenwrong
·3 か月前·議論
I might be missing your sarcasm, but this is a common approach for large scale builds. Virtual filesystems are used to provide a pre-computed tree hash as a xattr. In a more typical case, you can read the git tree hash.
oftenwrong
·4 か月前·議論
Surely the school streets are a great benefit for families, yes? That seems as pro-child as public space allocation could be.
oftenwrong
·4 か月前·議論
>The browser extension doesn’t work half the time. In addition to being frustrating, that makes it a less secure system, as one of the benefits is that it only fills the password on the specified domain. A lack of reliability of the extension leaves people more vulnerable to phishing, since they have to copy/paste passwords out of the app.

This is my main frustration with it as well. It is one of the main features in my mind, and it often does not work. It seems to work for many sites I use on desktop (Firefox on Linux, Mac), but doesn't work well at all on Android (Android app and Firefox). I can understand if this issue is outside of 1password's control because it possibly is due to specifics of Android's APIs, but I would prefer transparency in the matter.
oftenwrong
·4 か月前·議論
I have used savevers.vim for many years as a way to recover old versions of files.

https://www.vim.org/scripts/script.php?script_id=89

It is comparatively unsophisticated, but I need it so infrequently that it has been good enough.

I do like the idea of maintaining a complete snapshot of all history.

This is a good application for virtual filesystems. The virtual fs would capture every write in order to maintain a complete edit history. As I understand it, Google's CitC system and Meta's EdenFS work this way.

https://cacm.acm.org/research/why-google-stores-billions-of-...

https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...
oftenwrong
·4 か月前·議論
https://github.com/mikehaertel/minrx
oftenwrong
·5 か月前·議論


    #!/usr/bin/env java --source 25
    void main() {
        IO.println("Hello, World!");
    }
oftenwrong
·5 か月前·議論
Seems that the Google-style approach would be a good fit: mostly one codebase with a well-defined dependency graph, and build/test infrastructure that supports fast and comprehensive validation. This would seem to obviate the need for the catalog system described, but probably requires more investment in the build system.
oftenwrong
·5 か月前·議論
This is one of the main problems I have banging my head on for the past decade, and many of the things mentioned, like Buf, Unison, and more, I only stumbled upon randomly on my own. It's refreshing to read an article on this subject simply because it's so under-discussed. I also wonder to what degree these problems have been solved within the high walls of the tech giants like Google and Amazon.
oftenwrong
·5 か月前·議論
This is perhaps a bit different, but Fossil supports storing more types of written company artifacts in the repo:

>One notable feature of Fossil is that it bundles bug tracking, wiki, forum, chat, and technotes with distributed version control to give you an all-in-one software project management system.

https://fossil-scm.org/home/doc/trunk/www/whyallinone.md
oftenwrong
·6 か月前·議論
I have been doing this for decades. My files are in a sub-directory of $HOME. It also makes it very obvious when a piece of software does not treat your $HOME with respect.
oftenwrong
·6 か月前·議論
What is the benefit of having this be a standard? Can't an agent follow a guide just as easily in document with similar content in a different structure?
oftenwrong
·6 か月前·議論
I don't think it's meant to be a point against abstraction or a point against complexity. I think it's widely understood that abstraction is part of how advancement is made in our practice, as well as in other disciplines. I have taken this saying to be an observation that there is almost always possible failure beneath the façade provided by the abstraction. Therefore, yes, you avoid having to let that complexity enter your brain, but only when the abstraction is holding. Beyond that point, often after pages are sent, you will still have to engage with the underlying complexity. A proactive measure following from this idea would be to provide support in or alongside your abstractions for situations where one must look under the bonnet.
oftenwrong
·6 か月前·議論
You can do better now:

    #!/usr/bin/env java --source 25
    void main() {
        IO.println("Hello, World!");
    }
https://openjdk.org/jeps/330 https://openjdk.org/jeps/458 https://openjdk.org/jeps/512

I often combine these approaches with https://get-coursier.io/ when I need to fetch third-party dependencies.
oftenwrong
·7 か月前·議論
What you are describing is basically remote buildkitd. That allows all of your docker builds to share a big cache. The cache-to/cache-from approach is of limited usefulness.
oftenwrong
·7 か月前·議論
This is based on this write-up:

https://www.linkedin.com/pulse/wont-main-break-all-time-your...

archive copies:

https://archive.is/wI4b0

https://web.archive.org/web/20251211132753/https://www.linke...

https://ghostarchive.org/archive/bN17w