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

abp in firefox doesn't really remove them. I've seen and reported multiple scummy popup-like looking ads like tfn and saw it again for weeks...

There may be gaps every now and then in block lists of ad blocking solutions, but besides that, you are using the wrong ad blocker. abp is not to be trusted to reliably block all ads it could. It has a different mission than uBlock Origin.

Use ublock origin rather than ABP. ABP was dead the moment they sold out to "responsible" ads.

ABP as in adblock plus?

Don't use that. Use Ublock Origin.


ive looked at your project before but forgot about it. I think mine is in a similar vein: https://github.com/mischief/clm

it grew out of annoyance of dependencies on js runtimes, probably similar to you. mine additionally works on solaris and esp32.

could be interesting to collaborate!


I'm using fourlexboehm's minimal agent[1], it's only 674 lines of C (with comments), which results in a tiny ~10KB binary (after various optimizations). Dynamically linked, with only libcurl and libc as direct dependencies. Could probably shave a couple of KBs further if I UPX'd it.

If anyone's aware of a smaller agent than this, hit me up!

[1] https://gist.github.com/fourlexboehm/a60e4ef9306744483731cd1...


The annoyance is real. Let's do it.

this is my favorite Wikipedia article: https://en.wikipedia.org/wiki/Timeline_of_the_far_future


It puts everything in perspective, although not sure if the best one, can be overwhelming and ie many religious people tune out since there are no clear answers they were conditioned from childhood to expect, its hard to find god in endless universe with protons decayed for example.

Its easy to feel that everything is meaningless on long/large enough scale, even if we decide to annihilate Earth, or whole Solar system, or entire Milky way somehow. Universe will continue its dance from sub-quarks to largest filaments of galaxies unaffected and end state is as inevitable as the fact that tomorrow will happen.



Thank you for the recommendation! Once started, I just couldn't stop watching it.


i got annoyed by this especially the memory use and non portability aspect of bun so I had claude (lol) and kiro cook up my own agent. it runs on linux, openbsd and even on omnios and esp32. it's just a personal project so there are probably rough edges, but I am using it on my clockworkpi uconsole daily now. https://github.com/mischief/clm


08:46:37.125 [err] [fps] 4.0 (12 frames in 3.0s) 08:46:40.225 [err] [fps] 1.0 (3 frames in 3.1s) 08:46:41.224 FIRM | * ASSERTION FAILED: ASSERTN 08:46:41.443 [err] DEBUG post-reset: halted=0 stopped=1 R13=0x20002170 R15=0x080001b4 thumb=1 08:46:42.123 [err] clktree_recalc_output_freq: Clock PCLK1 output frequency (32000000 Hz) exceeds max frequency (30000000 Hz).

found an assertion just by clicking up/down. doesn't seem too stable.


Yeah that happens when trying to go up into the timeline.


it's modern art


my only wish for ghostty is that there was openbsd support. some work needs to be done in the io layer to support openbsd kqueue to make it work.


I'm surprised that whatever IO primitive is used on Mac doesn't work on OpenBSD. Mac has select and some variant of kqueue, right? What is ghostty doing there that doesn't work on OpenBSD?

E.g., here it is kqueue-aware on FreeBSD: https://github.com/mitchellh/libxev/blob/34fa50878aec6e5fa8f...

Might not be that different to add OpenBSD. Someone would begin here: https://github.com/mitchellh/libxev/blob/main/src/backend/kq... It's about 1/3 tests and 2/3 mostly-designed-to-be-portable code. Some existing gaps for FreeBSD, but fixing those (and adding OpenBSD to some switch/enums) should get you most of the way there.


i know freebsd and macos have similar implementations, but it is just different enough that it is nontrivial to make work. i had started fixing it locally but didn't quite get it working, since i'm not really that familiar with zig, although i like the idea of the language.


my one gripe after using mc for a few years is no parallel transfer support. it slows down significantly when transferring small files compared to one large file.


That I agree with. In Total Commander I typically do F5 copy and then put it in the background F2. Then start another.

This isn't possible in MC. And also a concrete parallelization is not available. This sounds like a feasible feature request to the upstream MC project! I'm sure Gnu Parallel or just pure C code would be able to handle parallelization of copy jobs.

EDIT: Wait! It does have background transfer now. Which means my technique of how I do it in Total Commander will work in MC now as well. It is almost like having Parallelization.


it could be interesting to see what ispc does with similar code.


yes, very much so. libera.chat is alive and well.


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

Search: