1,891 karma · joined October 12, 2016
You’re on Hacker News, this website is known for attracting open minded free thinkers that do not fall under the influence of government financed propaganda. Learn and reassess your thoughts.
Stunned to see that Gemini threw its digital arms in the air and gave up.
It would be a piece of trivia today if motorola were not 6 months late which forced IBM in frustration to change tracks to Intel and MS DOS instead (which worked on 8086). That 6 month drlay created WinTel of today.
I do old school embedded, the amount of desktop bloat is insane. Any function I really need to refactor, I can reduce size and improve performance. And there are better engineers out there that are more efficient than me.
Simple as that.
Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.
Blind leading the blind. Disclaimer - I do professional rendering engines.
child->Async(&ChildActor::Method, child, args);
Refactored it to use small buffer optimisation and std::move_only_function)
child<&ChildActor::Method>(args);
And saw a performance jump since no more malloc in std::function.
It also helped me decipher an animation bug in gtlf importer.
Productivity is x4 or higher.
I had the experience to keep calling out AI to simplify and downgrade the solution to something primitive, which ended up smaller, faster, easier to maintain. Juniors with real world experience would not bother, they’ll take the first working AI result.
Eg: delete_scene(void *arg) vs delete_scene<T>(T *arg)
Haiku is a unified system, so native apps have one windowing system, one desktop environment, one API, one media kit, one file system etc. There are less layers for data to travel, hence it will always be faster. Also Haiku targets desktop users (single user system, for better or worse), while Linux in all honesty targets servers and embedded with desktop a distant 3rd use case. Haiku package management is a generation ahead of Linux.
Finally, BeOS/Haiku core architecture is built from modern 90's designs, while Linux started as a clone of Unix (deep in the bowels of Linux there is a TTY terminal block device).
Finally, BeOS had a cool factor (and their fanboys) that Linux never had. Dual CPU from day #1. Blinkenlights. Geek port. Playing videos on a face of a cube. is_computer_on(). Linux is sooo boring in comparison.
Also, a long time ago (pre 486DX), processors did not have FPU circuitry instead it was a FPU coprocessor. When dealing with a kernel context switch, you'd have to copy all registers to a stack. With a coprocessor, you'd have to make sure those registers got copied as well. Which was slower with coprocessors ... So for a time some real time kernels did not allow context switching of FPU. To support that, you'd get the performance hit.
These days its all integrated so you dont have to worry about it ...
There is always a historic reason for a colour profile, sadly most software avoids terminology like the plague.