That particular tool's purpose was actually to shift the Amiga's very simple RTOS-like static priority scheduler more towards a more complex fairness-based scheduler like Linux/Windows currently has, making it less real-time than before. Yes, you could make rules that could elevate certain tasks by name matching automatically, giving you more control and predictability, but that's not something you couldn't already do.
Depending on the job, you can likely be fired without cause anyway. You can pretend to not poke the bear, but in a place that plays power games like that, it doesn't really matter.
Presumably performance matters above all else (although it likely doesn't in such a place). If Emacs actually makes a meaningful difference, then just use it to do your work more efficiently.
You can run a batch/shell script, right? Of course you can. Would you ask for permission to write and run a script? If not (and presumably you wouldn't because that would be silly) then you shouldn't ask to run Emacs. You "own" both and take on all the "risk". There's really no difference.
But really, truly ask yourself, is whatever cause you're working towards (that is, the mission of the company) worth sacrificing your dignity for?
The company I work for is pretty much washing its hands and going with off-the-shelf solutions, instead.
We are transitioning into a role that's mostly extending a main business software internally and externally. Externally it is using Logic Apps or Power Automate or Power Apps, etc.
With this, the "core" tools we are using are no longer needed in the minds of upper management, which is why I am concerned changing laptops that are fully setup with Intune.
This is also why in my meetings with management they are subtly suggesting software well before we move onto these modern projects - as if I wont understand what they doing.
technically we are still developers but not the way we were originally hired, and I am confused how we are going to hire new staff in this area... and the type of skills we require.
With all the above, I can see them being difficult with Emacs and other software I use.
Unix philosophy clearly favors and privileges certain methods of composition and interoperation. C-calls, program invocation, files and sockets/pipes. Calls inside various vms like lisp, java, python or wasm are not among those.
Emacs is a more usable interface to all those methods of composition than, say, a terminal emulator. Take dired for example; it presents the verbatim output of the ls command but allows me to interact with it in a much smoother way to rename, copy, and run arbitrary shell commands on them.
Why is it acceptable to compose simple modular tools in a bash script but not in an Emacs script?
Someone else here already pointed out the problem with that approach: After the second or third candidate, the interviewer is very familiar with the problem and may become unfairly judgemental with later candidates if they don't immediately see "the obvious". Which wasn't obvious at all to him as well, two weeks ago.
How would you run a project like this? People come and go. People do a one-time contribution and then you never hear from them again. People work on a project for years and then just go silent. Honestly, credit where credit is due, but how is a project like this supposed to manage this?
AmigaOS supported both. Each drive and in addition each medium had it's own name. If GAMEDISK was in floppy 0, you could reference it either as DF0: or as GAMEDISK:
You could even reference media that was not loaded at the time (e.g. GAMEDISK2:) and the OS would ask you to insert it into any drive. And there were "virtual" devices (assigns) that could point to a specific directory on a specific device, like LIBRARIES:
IMO the client certs are pretty elegant from a technical perspective. It works well with the CLI, but the browser experience is different enough to cause at least some base level wtf-ery.
Yeah, most enterprise deployments of Incus use OIDC for authentication and then OpenFGA for authorization with permissions typically synchronized with something like AD/Entra.
TLS certs remain used for some role account type stuff and as a break glass type of access for when OIDC is unavailable and there's an emergency. A nice characteristic of TLS certificates is that they can be generated safely in a HSM which you can then dump into a safe, works well in the corporate world, much better than passwords for this kind of thing.
