Signal.

Wired had an interview with Signal’s President last year that I found enlightening and provided an entry point for me to self educate further. Here’s an archive.org snapshot of it: https://web.archive.org/web/20240828100224/https://www.wired.com/story/meredith-whittaker-signal/

For the click-averse here’s an excerpt I find compelling:

Going back to your sense of Signal’s new phase: What is going to be different at this point in its life? Are you focused on truly bringing it to a billion people, the way that most Silicon Valley firms are?

I mean, I … Yes. But not for the same reasons. For almost opposite reasons.

Yeah. I don’t think anyone else at Signal has ever tried, at least so vocally, to emphasize this definition of Signal as the opposite of everything else in the tech industry, the only major communications platform that is not a for-profit business.

Yeah, I mean, we don’t have a party line at Signal. But I think we should be proud of who we are and let people know that there are clear differences that matter to them. It’s not for nothing that WhatsApp is spending millions of dollars on billboards calling itself private, with the load-bearing privacy infrastructure having been created by the Signal protocol that WhatsApp uses.

Now, we’re happy that WhatsApp integrated that, but let’s be real. It’s not by accident that WhatsApp and Apple are spending billions of dollars defining themselves as private. Because privacy is incredibly valuable. And who’s the gold standard for privacy? It’s Signal.

I think people need to reframe their understanding of the tech industry, understanding how surveillance is so critical to its business model. And then understand how Signal stands apart, and recognize that we need to expand the space for that model to grow. Because having 70 percent of the global market for cloud in the hands of three companies globally is simply not safe. It’s Microsoft and CrowdStrike taking down half of the critical infrastructure in the world, because CrowdStrike cut corners on QA for a fucking kernel update. Are you kidding me? That’s totally insane, if you think about it, in terms of actually stewarding these infrastructures.

Near as I understand it: years ago some dumb engineering decisions were made, acknowledged, and corrected. Is there some recent scandal I’m out of the loop on?

Sure! That’s an SMTP Relay. A lot of folks jumped on the poopoo wagon. It’s common wisdom in IT that you don’t do your own email. There are good reasons for that, and you should know why that sentiment exists, however; if you’re interested in running your own email: try it! Just don’t put all of your eggs in one basket. Keep your third party service until you’re quite sure you want to move it all in-house (after due diligence is satisfied and you’ve successfully completed at least a few months of testing and smtp reputation warming).

Email isn’t complex. It’s tough to get right at scale, a pain in the ass if it breaks, and not running afoul of spam filtering can be a challenge. It rarely makes sense for even a small business to roll their own email solution. For an individual approaching this investigatively it can make sense so long as you’re (a.) interested in learning about it, (b.) find the benefits outweigh the risks, and (c.) that the result is worth the ongoing investment (time and labor to set up, secure, update, maintain, etc).

What’ll get you in trouble regardless is being dependent on that in-house email but not making your solution robust enough to always fill its role. Say you host at home and your house burns down. How inconvenient is it that your self-hosted services burned with it? Can you recover quickly enough, while dealing with tragedy, that the loss of common utility doesn’t make navigating your new reality much more difficult?

That’s why it rarely makes sense for businesses. Email has become an essential gateway to other tooling and processes. It facilitates an incredible amount of our professional interactions. How many of your bills and bank statements and other important communication are delivered primarily by email? An unreliable email service is intolerable.

If you’re going to do it make sure you’re doing it right, respecting your future self’s reliance on what present-you builds, and taking it slow while you learn (and document!) how all the pieces fit together. If you can check all of those boxes with a smile then good luck and godspeed says I.

Stolen shamelessly from someone else who posted it further up the thread.

The features would break if they were built in.

You can’t know that and I can’t imagine it would be true. If the plugins many folks find essential were incorporated into GNOME itself then they’d be updated where necessary as a matter of course in developing a new release.

GNOME has clear philosophy and they work for themselves, not for you so they decide what features they care to invest time and what features they don’t care about.

You’re not wrong! This is an arrogant and common take produced in poor taste though. A holdover from the elitism that continues to plague so many projects. Design philosophy leads UX decision making and the proper first goal for any good and functional design is user accessibility. This is not limited to accomodations we deem worthy of our attention.

Good artists set ego aside to better serve their art. Engineers must set pet peeves aside to better serve their projects. If what they find irksome gets in the way of their ability to build functionally better bridges, homes, and software then it isn’t reality which has failed to live up to the Engineer’s standards. This is where GNOME, and many other projects, fall short. Defenders standing stalwart on the technical correctness of a volunteer’s lack of obligation to those whose needs they ostensibly labor for does not induce rightness. It exposes the masturbatory nature of the facade.

Engineers have every right to bake in options catering to their pet peeves (even making them the defaults). That’s not the issue. When those opinions disallow addressing the accessibility needs of those who like and use what they’ve built there is no justification other than naked pride. This is foolish.

Having a standardised method for plugins is in my opinion good enough, nobody forces you to use extensions. And if you don’t want extensions to break, then wait till the extensions are ready prior updating GNOME.

I agree! Having a standardized method for plugins is good, however; the argument which follows misses the point. GNOME lucked into a good pole position as one of the default GNU/Linux DEs and has enjoyed the benefit of that exposure. Continuing to ignore obvious failures in method elsewhere while enshrining chosen paradigms of tool use as sacrosanct alienates users for whom those paradigms are neither resonant nor useful.

No one will force Engineers to use accessibility features they don’t need. Not needing them doesn’t justify refusing the build them. Not building them as able is an abdication of social responsibility. If an engineer does not believe they have any social responsibility then they shouldn’t participate in projects whose published design philosophy includes language such as:

People are at the heart of GNOME design. Wherever possible, we seek to be as inclusive as possible. This means accommodating different physical abilities, cultures, and device form factors. Our software requires little specialist knowledge and technical ability.

Their walk isn’t matching their talk in a few areas and it is right and good to call them to task for it.

Post statement: This is coming from someone who drives Linux daily, mostly from the console, and prefers GNOME to KDE. All of the above is meant without vitriol or ire and sent in the spirit of progress and solidarity.

Whichever species, if any, rise to sapience after the age of mammals comes to its close.

Uh oh. Was someone grumpyyyyy? Poor thing. Thanks so much for taking the time to leave such an insightful and well considered contribution to the discussion. Invaluable stuff.

TL;DR: Check out the KeyChron K3 V2 Non-Backlight edition. Decent quality, inexpensive, no lights, and no knowledge required.

ZSA make good stuff, sell it at reasonable prices, provide incredible support, and give a shit about artists/humans/the world. Any time mechanical keyboards are mentioned I feel compelled to inject their name into the conversation. I’ve owned a Moonlander for a while now and I have nothing but good things to say about it. I’d recommend the ZSA Voyager for someone checking out not shitty keyboards for the first time.

With that out of the way: it’s tough to find a lightless mech keyboard these days because backlights make sense and, so long as you’re putting lights behind keycaps, you might as well use full color range LEDs and let the user set a low brightness white color or turn them off if they don’t care for it. Some companies make non-backlight versions (KeyChron’s K series for instance) but they’re a rarity. Why produce and stock inventory that’s not moving?

I recommend doing some research on how mechanical keyboards are built (watch a 10 minute video on the internet) and then using RTINGS’ keyboard table for some comparison shopping. You’re looking for a well rated keyboard with hot swappable PCBs designed to accommodate south-facing LEDs (they point down - less bright). One of the advantages of going mechanical is customization. Don’t want the LEDs at all? Remove them from your build. Even without PCB hot swapping: no one will stop you desoldering LEDs from your keyboard.

Building out something like a Gem80 from NuPhy or a 60HE from Wooting will net you a high quality mechanical keyboard that won’t get in your way but is customizable enough for you to avoid RGB-induced eye sores.

The only effective answer to organized greed is organized labor.

Unionizing every industry so there is nowhere for the owning class to practice naked greed sans consequence or feel any pressure to do otherwise is our only answer. It’s not one which matches the aesthetic or level of ease most are looking for. So that’s the current goal. Shift public perception of unions and collective bargaining from “talking about that will get me fired” to “unionization is essential for any working class person”. Shift the current climate from “violence is inevitable” to “striking is necessary”.

Our owners cannot steal our wages if we refuse to produce goods and services for them. Yes this means workers will experience pain. Not being able to pay bills, buy groceries, etc. This is the intention of the current economic reality we find ourselves locked in mortal combat with. Keeping us too scared to bite the hand that feeds for us to realize we can starve out our oppressors by doing nothing and being loud about it. Picketing is a siege on the fortress of oligarchy.

They concentrate wealth like dragons protecting a hoard not for the love of money. It’s not about the money. It’s about insulating themselves so securely from such a siege that we starve before they do. History tells us that’s a winning strategy. It’s how the aristocracy survived and evolved into the modern era. Knowing this we can reason about what is necessary to avoid repeating the past.

One may argue for governing reforms, better voting systems, government-backed protections for workers, more public sector jobs/industries, kai ta hetera, et cetera, and so on… And these things may help voters weed out elitists/sympathizers or insulate an industry for a few decades. They are placations though. Not solutions. These capitulations leave workers in stasis and package today’s injustice up as an inheritance for those next in the human assembly line. That sounds like deja vu to me.

Similarly goes violent direct action. Yes, the civil rights movement was lifted by the pressure or the threat of violence from aligned and allied movements and, yes, such methods may yield short term results in any righteous struggle. No, workers do not require the same assistance for success. Labor is not fighting against any government. Governance is the medium through which the owning class wishes to arbitrate. Refuse this entrapment. No one is coming to save us.

Organize, vocalize, and strike, or lose.

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.

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?

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.

Make a container out of isomalt. Shatter it. Eat the pieces. Laugh in god’s face.

I haven’t experienced what you’re describing. Previous experience suggests exposure is the next step for you. If a cooking class isn’t feasible right now then start with watching some videos online (best if they’re home cooks - you want to watch common cooking of foods you like to eat).

You’re not trying to memorize anything or learn hard skills during this time. You’re only trying to become more familiar with people working in a kitchen so it doesn’t feel as alien and maybe not quite as scary.

Do that regularly for a while. If it’s too much for you: dial it back. You do want to push your boundaries but only when you’re feeling ok about it. Small wins will turn into more small wins and eventually you might be interested in trying to cook something.

If that happens, and I suspect it will, know that it is OK to start cautiously and take your time learning how to use the oven and stove top. Try turning a burner on with no pan or pot on top. Let it get hot. Turn it off. Let it cool down. Repeat that across a few days if the first one helps you.

Once you’re comfortable you should do that practice again and add water to a pan until its half full. Once the burner is hot: place your pan of water on top of the stove burner. Let the water come to a boil. Remove the pan from the stove top. Let the pan and water cool down. Note how much water is missing (some of it will have steamed away while boiling). Add that much water back to the pan and practice this again.

You can build your experiences, step by step, with safe extensions and new footholds, until you’re feeling confident about cooking something with the boiling water. You’re going to boil an egg!

Complete your practice again but instead of taking the water off right after it boils: leave it on the burner for 6 minutes. Then remove it and let it cool. Success? Do that again using a pot instead of a pan. Pot half full of water. Grab a serving spoon or similar item. Once the water comes to a boil:

1. Lower the burner temperature to half / medium. The water should be moving and steamy but the bubbles should be very gentle or cease. Dropping the egg into actively boiling water may cause the egg to crack prematurely.
2. Use the serving spoon to gently place the egg in the center of the boiling water.
3. Wait six minutes.
4. Remove the pot of water from the burner.
5. Turn the burner off.
6. Use the serving spoon to lift the egg out of the hot water.
7. Run the egg under cold water (this helps it from over cooking and helps make peeling easier).
8. Enjoy your egg.

You can absolutely boil any kind of pasta, lots of vegetables, and almost all starchy foods. Boiling is very safe because the water regulates the temperature for us. So long as there is water in the pot the pot is unable to meaningfully exceed 100 degrees Celsius (the boiling point of water / ~212F). It is very difficult to burn anything or start a fire while boiling water.

Best of luck my friend.

laughs in home lab

Not that I’d buy it but, if I did, that power button might get used twice a year. Likely less since I wouldn’t be able to upgrade or maintenance its hardware.