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

Nice work!!!


Another one damn


The contract has been signed already. How do they even end the software ip purchased from weta?


They don't. As per Weta's statement [1]

> Unity will continue to own the technology it acquired and will evaluate the best way to enhance its offerings over time.

[1]: https://www.fxguide.com/quicktakes/unity-software-with-a-com...


hypothetically if the board faced enormous pressure from the public/investor and decided to reverse their decision, is this theoretically possible?

of course its highly unlikely that board would do that, but I'm just asking if this is theoretically possible?


backend of McDonald's app is handled by a third party new Zealand company plexure

https://www.plexure.com/

not sure what their architecture is


Plexure are only used in select McDonald's markets. Almost all Hacker News readers are in markets where the McDonald's app is developed in-house by McDonald's.


Thanks for sharing this, that's very insightful.


No problem. If you are going to do a blog post and need stats, you can contact me through my profile info.


Oops, typo :p


It's certainly plausible

It's currently using wcc to compile the kernel https://github.com/wandwramp/wcc. We can swap it with gcc for sure, but require bit of work, especially the output format and backend.

Winix assumes the output file is in srec format https://en.wikipedia.org/wiki/SREC_(file_format), so we would need to tweak gcc to support this header format and add backend support for WRAMP architecture.

ELF is quite complicated, if I have to do this, I probably just copy some codes from linux.


If you're not supporting DSOs (shared libraries) then ELF is pretty straightforward. In fact, from the kernel point of view it's still fairly straightforward since all you need to do is either load the (non-DSO) program and go, or else load the (non-DSO) program named in the interpreter entry and go, and leave the hard lifting to the interpreter. The kernel itself never needs to understand about DSOs or GOTs and PLTs or DWARF or any of the other fancy magic that ELF brigs to the table. Just how to find and load the LOAD segments and where the entry address is, or where the PT_INTERP string is.

It's really just that easy.


Thanks for the info, good to know that it's easy to implement from kernel's perspective


Linus is a genius, I don't think I could ever reach his level

Yeah it was a side gig for me, I did spend major of my days for the duration of 2 months last year to work on this.

In fact, I paused on the development of this project for 1-2 year.

But most of the time, it's just 1-2 hour per week side projects on average.


Wow, I didn't know WAND had a github page. I'll get my fork merged with the main repo in that case.

The custom fork basically adds a extra button "Quick Load", since the srec file can be quite large to transfer through serial port to load, so I just implemented extra button to read srec file directly into memory.


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

Search: