It'd be very interesting to run the same experiment except rather than on different engines, just on different versions of Google in different years. Sadly I can't really search 2005 Google anymore of course but it would be interesting nonetheless to see if it's Google in general or rather the recent "enshittification" of their results. It may be intriguing to expand to survey takers outside of Reddit to get a potentially less biased set of results, yes.
Woah it was because I had run out of API credits, fixed! I'll improve the error screen for that. Sorry, did not expect this traffic, it's had several thousand searches today!
That's fair enough. For the record I do intend to apply for a non-profit official entity. I would say it still has a role as opposed to Brave considering the lack of advertising though.
Yup, it is pretty much just a better frontend for existing search. I want to build my own index and ranking algorithm in the future, but sadly it's quite resource intensive so it will depend on financial viability a bit in terms of timeframe.
That is very true, and it's not cheap to maintain. I do however really hope that donations can cover it enough, and I have plans about other ways to monetise it while remaining not-for-profit without ads or anything that affects the user.
Honestly I agree. This is part of what I love about the idea of Kagi. I do believe a not-for-profit alternative is needed, however if there's any for-profit model a search engine should have, it should be paid for by the user rather than the advertiser imo.
This is a really interesting view, but I'm not sure I agree. So many amazing projects are truly free without the goal of profit yet their maintainers still do amazing work. I feel like part of the reason this works is because often the load is split between several maintainers (of which I hope to onboard soon, and have one or two offers already from people to contribute) and also the fact it's genuinely something enjoyable to work on (of course, to the extent it's not too stressful and overworked).
This is sadly probably quite true. I'm sure there are workarounds, like slightly changing it every month or two, although that would require quite heavy maintenance. Perhaps the core algorithm stays the same but some constants that decide on the weights of different things are randomised? Not too sure.
I see nilch as slightly more about being simplistic and not having many features that are unnecessary. I do share many of the values and benefits with searxng (and really love their work!), however this is also about my own specific desire for something that is clean and has very little that is unnecessary.
Thank you! I would definitely consider custom ddg bangs, yes. Is there any particular reason you want that rather than just all ddg's bangs like it is currently?
I'll have a look into that project, thank you. Cost is a slight issue so far, yes. There have been about 4,000 searches in the past couple days but I've slightly improved cost efficiency with caching, and I've received two small donations which do help a bit, so the hope is that donations will be able to sustain it.
Partnering with Ecosia is a really interesting idea, however I think that there may be a conflict of interest since they do aim to make money with ads, just to go towards environmental efforts rather than a corporation. They would be disadvantaged if nilch was at an advantage over their users.
I do love the wikipedia model and I hope that nilch can run similarly. Thank you again!
Mostly just because C is a lot simpler, and in kernel dev, simplicity is everything. I've used rust for other projects but I feel like in kernel dev I would much rather use a simple and readable language than a safe language.
Yeah mmap is quite a stub lol, I def cheated on that. I just wanted framebuffer access, but the user heap uses sbrk internally instead of mmap anyway so I properly
I think the thing is, Doom was originally written __for__ DOS. Part of the cool part is porting 3rd party software to my OS that wasn't originally written for it. That was part of my reasoning at least.
Yeah no problem. Multitasking isn't really complex - it's generally split into two categories: collaborative and preemptive. Collaborative multitasking is simply having user programs call a yield syscall which tells the kernel that it's ready to give up control of the CPU and it switches to the next task, but this is not very secure and is uncommon on newer systems. Alternately, preemptive scheduling generally has a timer which goes off regularly which automatically switches to the next task. Choosing the next task is the next part which the simplest one is round robin, where you literally just have a list of tasks and it always selects the next task and gives each task an equal amount of time. You also have SMP versions (that work for multiple cores) and also priority-based schedulers (which give certain tasks, such as system daemons, more processing time). Hopefully that extra info helped a bit!
That __is__ true, Doom can run on bare metal, but that's a fairly hacky solution in many ways. Doing it properly in userspace with a LibC and conceptually POSIX syscalls require a bit more effort. It requires a list of LibC functions and POSIX utilities as well as a few OS specific implementations.
Umm that's probably the extreme end of OSDev which I likely wouldn't be able to do, at least not for a driver you can buy. Qemu's emulated GPU is documented decently and could be possible, but things like nvidia GPUs are badly documented (and until recently, the docs were fully closed source) - even Linux has issues with this (and I actually see a few other hobby OS devs who just use Linux's GPU drivers in the end). There aren't a lot of things I've marked as near impossible but writing a genuinely decent GPU driver for a common GPU isn't really something I imagine I'll ever be able to do sadly.