I do not know if this has changed during the recent decades, but indeed in the past it was standard in all countries for the military fitness physical exam to be done nude (for males).
Moreover, it was completely pointless to be shy about this, because if you were conscripted, the norm was to have common showers, so anyone could have a good look at you for much more than the few seconds of the physical exam.
I absolutely love your project and I hope it will become a breakout success. It has all the right components for a computing environment that is not controlled.
Have you thought about RISC-V implementations of the kernel as well (iirc you're on ARM and on x64)?
Oh, it only gets better. Thank you so much. If you ever get to the point where you have something ready to order please drop me a line (mail in profile) and I'll buy one set to evaluate and if it works well I will get some more people on it.
The board is part of the CI pipeline for the OS. The kernel is built in the normal CI pipeline, unit tested, etc. then platform-specific images are built.
Those are picked up by GitHub CI runners (could be anything but I'm using GH for now) that pull those image artifacts and send them over the internet to the board, which stores them on the microSD slot.
Then the board will boot the device-under-test (either by enabling a USB VBUS line, asserting PS_ON and pressing the power button, whatever the device needs) and will serve the image either a via USB mass device or by switching on access to the microSD card directly via a ribbon connector/custom microSD PCB and ribbon cable.
The kernel then communicates over serial back to the Link, which proxies that back up to the CI runner for evaluating test runs, etc.
Everything is configured using MQTT and mDNS. Using async Rust via Embassy for the firmware.
5-pin on the bottom left is for power - 5V 2A 'always on' supply (on the ATX24 adapters that's the 5vsb line), 5V 3A aux line (for VBUS, optional and not otherwise used to power the board itself), a sense line for the aux power (board will shut down and display an error on over-current of the main line if not sensed), active-low aux line enable signal (PS_ON for ATX24 sources), and ground.
This means that it's used to cut power on x86 machines, or to use a stock desktop PSU even for arm/riscv dev boards. In the future I want to make this all rack mounted and have a dedicated power supply for multiples of these.
Sorry, by build script I mean the script that generates the package, not the actual build. That should run on the build server, not the developer's machine.
I think it would be better if the build process ran on both the build server and the devs machine and get the exact same output on both with deterministic/reproducible build processes.
Which build server? Not everyone has the luxury, and that also means you have to secure a build server now too. For rust, there is no build server. Packages are distributed as code.
This is very "old man yells at cloud" reductionist commentary IMO. You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
> You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
You're doing exactly what the other poster in a different thread above said is happening:
>>> Long ago, I remember seeing a cartoon which involved a tag-team of two people robbing a third, with A pointing a gun at C and saying "give your money to B", while B comments "I'm really just standing here, but I figure it's best if you do as he says". I'm not sure what exact piece of day-to-day politics this was made to comment on (though it was probably some or another flavour of political violence), but it seems somewhat applicable here as well. The lines just become "accept the supply chain, or suffer my public ridicule" and "I'm just providing the software 'as-is', but you probably should do as he says".
One party hurls insults at those who don't want to switch, the other party (you) is going "I'm just standing here offering the download, but you should probably do what he says".
Not quite the history as I remember it. These package managers were often created by small teams of people who originally didn't know they'd turn into Microsoft acquired corporations. The intent wasn't to onboard newbies. People just didn't have a reason to use insanely targeted attacks on OSS Things because OSS being used in such a widespread manner wasn't as common as it is today. It really feels like people have forgotten how things were back then.
Well. Treasure Valley felt remarkably more WS-ey to me this last time visiting home. The time before that was right before the election, so it feels like it's gotten even worse over time.
You are in a bubble. Some segments use essentially no AI, while others have gone all in. Just because the type of engineers you're surrounded by do engineering that is obsolete doesn't mean that's the case across the board. All the best game engineers I know still write at least 90% of the code (probably closer to 99%). The bad ones use AI nearly exclusively - just like yourself. They can't create very complex or performant game systems, and they struggle even with highly unique or interactive game UI systems. I've looked over their code; almost every choice is bad, and it's clear why their projects completely collapse after a certain point. They simply can't build super complex, performant, or novel systems.
I'm going to assume you do the type of engineering where all the hard problems are solved for you already, and you are merely connecting inputs/outputs and hooking up APIs. Because, frankly, the value in "software plumbing" is gone; anyone with a Claude license can do that now.
You're condescending for no valid reason and I will tell you that what you say is not correct. Models superseded "plumbing" tasks and went well into the engineering grounds a generation or two ago already. Evidence is plenty. We see models perfectly capable reasoning about the kernel code yet you're convinced that game engines are somewhat more special. Why? There're plenty of such examples where AI is successfully applied to hard engineering tasks (database kernels), and where it became obvious that the models are almost perfectly capable reasoning about that tbh quite difficult code. I think you should reevaluate your stance and become more humble.
Link me the research on the hard engineering tasks they've done on database kernels, I'd love to see it, sounds interesting.
As long as people comment, "Only bad/stupid engineers hand-write code because LLMs are better in every way," and that's objectively not true in various engineering circles, I'll keep trolling them and being just as hyperbolic in the inverse because it amuses me. Don't take things too seriously on the internet; you'll have a bad time ;)
> They simply can't build super complex, performant, or novel systems.
Neither can single humans.
If you introduce some reasonable constraints AI will come out ahead most of the time, especially for optimization cases where AI will run circles around your average programmer and is perfectly happy to inline some ASM for you.
You still have bespoke cordwainers/cobblers 100 years after that process has been well and truly automated. But they're rare and almost nobody cares.
The pic above is representation of skeleton screen on youtube.com when opened in browser
Placeholder with same dimension or colors as actual content, which will get replaced it keep user engaged rather having a blank screen that suddenly fills or spinners.
reply