Exactly this. I use a Macbook for my day to day computing, programming, and general internet use. I have a Windows 11 gaming rig. Well, it turns out Hades 2 runs great on my macbook and that's been my game as of late, so the desktop hasn't been powered on in weeks. I just don't like Windows 11, and Linux just isn't there yet for my mixed DPI monitor setup (though I hear is getting close), or VR titles just yet.
SteamVR runs great on Linux, unless for some oddly reason your favorite desktop on GNOME. Valve tested it on X11, KDE Plasma on Wayland (because duh) and wlroots (hyprland and friends) without problems.
There are tons of people happily running mixed DPI setups with -at least- wlroots based compositors (although first time setup can be a bit tricky, as these are built by hackers for hackers)
I'll be checking this project out! I'm a big fan of ECS and have lofty goals to use it for a data processing project I've been thinking about for a long time that has a lot in common with a programming language, enough that I've basically been considering it as one this whole time. So it's always cool to see ECS turn up somewhere I wouldn't otherwise expect it.
I just stumbled across armbian recently and I must say I really like it.
I wanted to use UEFI, but my orangepi cm5 modules don't seem to have the SPI chip needed to store the UEFI there, so I'd have to load it on a partition and lose out on some features like persisting variables across boot.
The arm ecosystem really needs to settle on some sort of universal boot loader / firmware layer and stop just hacking up the linux kernel and not contributing back to it.
I'm not an Arm dev and am just a consumer so I may be misunderstanding, but isn't Arm SystemReady pretty much the thing that's intended to solve the problem you're talking about (among others)?
It is, but it seems like only servers are adopting it at the moment. Or high end ARM workstations. I can't think of any consumer devices or SBC's off the top of my head that support it.
Depends on your definition of prime, by your reasoning, I could say 7 * 1 * 1 = 7, so it's not prime. Better to say a prime is any number with a set of divisors of length 2 including 1 and itself. If you want to exclude 1.
Your reasoning is flawed, eating vegetables or not basically only affects you and your health, not wearing a seatbelt turns you into a projectile against the general public.
To answer your questions, no, they do not use an editor that isn't Xcode. And I would also suspect none of them use desktop macs daily and instead use macbooks.
Not a developer at Apple, but I've been using Magic Keyboard's (without numpad) for about ten years now exactly because it has the same layout as every Macbook I own(ed). If they were to ever make a numpad version with the fn key at the same place I probably wouldn't switch either because I would just be trying to hit the numpad when I'm on the laptop's keyboard.
I feel like this is a book most programmers should work through at some point or another. Doing so made me really appreciate just what's going on inside a compiler / language toolkit. It's also one of the most well written technical guides I've ever followed, it really helped me internalize the concepts, and they are useful all over the place, not just in compilers.
IMO compilers make you a lot more mature in recursive algorithms and trees, and then after that much more conscious about what exactly the code you write resolves to in terms of that languages semantics. Learning how closures work(variable capture and having to traverse the scope stack to find bound variables) is also a positive.
And that’s just for your first recursive descent compiler. One thing to remember is that you will also one day want extended functionality in your language and either implement C FFI in your language(straightforward or even freely done for you depending on language) and call some C library for the purpose or you have to implement the functionality somehow. So you end up writing a lot of stuff you wouldn’t otherwise.
I'm not sure if this is considered animation or not, but I've demonstrated code refactors between slides by adding a colored border around the code in question (both in the before and in the after slide).
I'd probably do something similar for stepping through code. But at that point it's a quasi-animation (albeit, one that can still be understood by pdf slides).
As someone in an otherwise healthy position at my job, fuck yes, I want to get away from Unity, but there's just no better option for the platforms we're targeting and how quickly we want to ship things. Something about the devil you know, ya know?
As someone who's worked quite a bit with both, no. I have hopes for Godot but in terms of actually shipping commercially-viable games, it's not even in the same league as Unity. This comes from many things, but some of the big ones are:
* Ability to do first-party console ports
* 3D rendering fidelity and speed
* Asset store quality & quantity
* Robustness & stability - they both have tons of bugs but with Unity there is almost always a way around the bug, due to the decades of commercial games that paved the path before you.
For one quick example, Godot's physics engine is well-known to be poor, both in terms of performance and in terms of accuracy/stability. It has tons of bugs, tunneling, jittering, etc. Both the 2D and 3D physics engines in Godot are currently slated to be ripped out & replaced with external ones of higher quality (Box2D and Jolt). But currently, that hasn't happened, so one of the foundational parts of most games - physics - is guaranteed to be broken to some degree in a Godot game.
I adore Godot and have been learning it on my own time, but it's just not there for XR stuff yet, our current project has the Vision Pro as a target, for instance, and Unity is really the only option there. Apple's native tools (Reality Composer Pro) are just abysmal.
But yes, all of my personal projects are in Godot now, and I'm planning to use it for some tooling at work, just because it's UI system is nicer than Unity's as well as it having better support for re-using editor UI components in an application.
