derek

Long time guitar owner here. You could get some wood glue and use a small amount to affix the chip back to the guitar pretty seamlessly so long as you've got a steady hand. In my experience it's harder than it looks.

My direct advice? Keep the missing chunk in a safe place and live with the guitar as-is for a month. There's no rush and this will give you some time to process.

If the gouge ends up sticking in your mind as something you want gone? Call a local luthier, explain what happened, that you'd like it restored, and ask for an estimate or evaluation if you want to budget for the expense. If you have a preference for a kind of repair you can ask for that too. Mending a wound on an instrument can be an opportunity to add beauty instead of simply removing a blemish. What kind of repair you want is entirely up to you and a temp fix now might make the repair more difficult / expensive.

If none of that sounds appealing and if after a few weeks the idea of a nail polish scar or other punky hack makes you happy then go for it! It's your instrument and best is conditional so go nuts. 🙂

My only concern with leaving the natural wood exposed would be moisture and cracking/paint flaking over time. Even if you think the chip looks bad ass and you end up wanting to keep it: I would ask a luthier to seal it up to preserve the instrument (battle-scar and all).

I find it more likely because it's pathetic.

Would you elaborate on this concern? I'm not sure I understand but I'd like to.

I don't know what tools they use but if Windows is an issue then the artist could use Linux.

How? What mechanisms, conditions, etc, are we manipulating which produce such a significant effect? After a bit of searching I found this write up:

https://thor3d.ca/wp/the-effects-of-print-orientation-on-strength/

Is this what we're referring to? To summarize (if I've understood this properly): Printing at 45 degrees ensures none of the print's three axes are aligned with the printer's least accurate axis of movement.

And a one 🎶 and a two 🎶 and a one, two - one two three four!

There's some good advice in the comments already and I think you're on the right track. I'd like to add a few suggestions and outline how I think about the problem.

Ask if the vendor has installation administrator guides, whitepaper, training material, etc. If yes: ask that they send it to you. You may also be able to find these on the vendor's website, customer portal, or a public knowledgebase / PDF repo.

I would want to know three things.

1. How do users authenticate through the application?
2. What are all of the ways users may access the application (local only, remote desktop, LAN only, full server/client model)?
3. Does the vendor have any prescribed solutions for defining who has access to the application, at what privilege level, with access to what features?

i.e. What parts of the user access, authenticate, authorize pipeline do application admins or system admins have control over and how can we exercise that control?

Based on some context I assume that the app is reading from Active Directory using RADIUS or LDAP for user auth and that people are physically logging into the machine.

If this is the only method of authentication then I would gate the application with a second account for each employee who requires access for business reasons defined in their job description (or as close as you can get to that level of justification - some orgs never get there). You can then control who has access to the machine via group policy. Once logged in the user can launch the application with their second account (which would have the required admin access) via "Run as..." or whatever other methods you'd prefer. No local admins logging in directly and yet an application which users can launch as admin. Goal achieved.

This paradigm lets us attempt balancing security concerns with user pain. The technically literate and daringly curious will either already know or soon discover they can leverage this privilege to install software and make some changes to the system. The additional friction, logging, and 1:1 nature of the account structure makes abusing this privilege less attractive and more easily auditable if someone does choose the fool's path.

I can imagine more complex set ups within these constraints but they require more work for the same or worse result.

Ideally you run the app with a service account and user permissions are defined via Security Groups whose level of access is tied to application features instead of system privs. There are other reasonable schemes. This one is box standard and a decent default sans other pressures.

If other methods of auth are available (like local, social, cloud, etc) then you'll have more decent options. I would define the security objectives for application access, define the user access objectives from the Organization's perspective, and then plot each solution against those two axes (napkin graphs - nothing serious). Whichever of the top three is the least administratively burdensome is then selected as my first choice for implementation with the other two as alternatives.

An aside: unless there is only one reasonable choice most folks find one option insufficient, two options difficult to decide between, and four options as having one option too many - whenever possible, if another party's buy-in is desired, present either three options or three variations on one option. This succeeds even when the differences are superficial, especially when the subject is technical, and 2x if the project lead is ignorant of the particulars. People like participating.

I'd then propose these options to my team/direct report/client, decide on a path forward together, and plan the rest from there. There's more to consider (again dependent on org maturity) but this is enough to get the project oriented and off the ground.

Regarding FOSS alternatives: you're likely locked in with the vendor's proprietary software for monitoring the cameras. There are exceptions but most commercial security system companies don't consider interoperability when designing their service offerings. It might be worth investigating but I'd be surprised if you find any third party solutions for monitoring the vendor's cameras which doesn't require either a forklift replacement of hardware, flashing all of the existing hardware, or getting hacky with the gear/software.

I hope this helps! <3

Your statement is too vague to convey an actionable suggestion. I'm intrigued by the thought you seem to be hinting at. Would you expand on this, include a recommended method, and reason about why it's an alternative to violence?

100%. In poorly designed kitchens, if one has the time/space, adding some detail can take a callout from "casual proactive safety blanket" to something much more impactful and helpful with a smidge of context.

Not necessarily. You're correct that we cannot account for intention. Neither can we assert whether we are simulated. Even if we can prove this reality is simulated we cannot be sure if we are part of the simulation or inserted into it (a la The Matrix) from our current position.

"Coming through!" "Make a hole!" "Hot! Burn risk is moving!" "Do not move! I'm passing behind you!" "Sharp! Broken glass/knife/whatever is moving!"

I'm sure there are others along similar lines. These are the ones I remember from another life working in food service.

Wipe first. Use soap if you want to be really clean.

I got a cheap bidet a few years back and I use it all the time. The fancy ones can be nice but most of the extra features are gimmicky things that don't have a large impact on function. They're marketed like magic poop-away devices but bidets aren't magic. Bidets are showerheads for your toilet bowl meant to make buttwashing more accessible. Use your bidet like a butt-shower instead of a magic no-effort poo cleaner and you'll have better results.