This is infuriating. However, for those in this situation, know this: it works if the document or spreadsheet is in OneDrive. I just wish Copilot told you this instead of asking you to upload the doc.
The book that changed the game for me is “Leadership and Self-Deception”. The thesis being that the root of resentment is self-betrayal, where self-betrayal is denying your impulse to do right by others.
Ever since I read it, I’ve been more aware of when I am fixated on I and me.
It’s amazing. You can be completely “right” about a situation, yet still be fixated about the self. Escaping the box - terminology from the book - doesn’t change what’s real, but absolutely changes how you feel, and how your situation progresses.
Whether it is self help or blame or resentment, they are all in the box activities. There is another world- a better world.
The post you’re r replying to gets this right- lead time is everything. The fast you can iterate, the more likely that what you are doing is correct.
I’ve had a similar experience to what you’re describing. We are slower with AI… for now. Lean into it. Exploit the fact that you can now iterate much faster. Solve smaller problems. Solve them completely. Move on.
This is my focus protocol. Whenever I find myself having trouble trying started on a task, I create a new desktop and open windows related to the task only. DnD on. Pick a next step. Execute.
Tone at the top is most important - if this is not valued at an organization level, it will be tough sledding. Next is knowledge - you don’t know what you don’t know. However, one you learn - usually through a gap assessment with an audit firm - you are now going to remedy and get into the audit. This is bad because you will miss point three. Automation is a must. Automated compliance monitoring, automated rituals (document reviews scheduled by a tool, etc), automated rituals whatever you can. Without this, you will create a ton of work for yourself.
This process is hard because there is tension between ticking boxes and being effective. The most well meaning people will get caught in a box ticking exercise if a critical contract depends on it.
It doesn’t have to be this way, but if you want it to be easy, start before clients start asking. Focus on being effective and automated so that you don’t feel pressured to tick boxes.
Absolutely agree about the tone. I've seen teams where compliance becomes one person's problem instead of a company priority, and it shows during the audit.
On the knowledge gap: the gap assessment route works, but it's expensive upfront and still leaves you building the foundation afterward.
What I've been exploring is the step before the audit: getting teams organized enough that when they do engage a consultant or tool, they're not starting from zero, which would result in faster compliance.
I'm building a platform (Lumoar) focused exactly on this pre-audit organization phase, helping early-stage teams get structured before the compliance pressure hits.
Curious: in your experience, what's the biggest mistake teams make when they're under contract pressure to get SOC 2 done quickly?
The biggest mistake is accepting controls that they cannot manage. I mentioned automation earlier for this reason. If your controls place undue stress on the business then you’ve just created more work instead of enabling success.
Compliance can be a business enabler if done correctly or a burden if treated like a side project.
I’ve seen this pattern play out before. The pushback on simpler alternatives seems from a legitimate need for short time to market from the demand some of the equation and a lack of knowledge on the supply side. Every time I hear an engineer call something hacky, they are at the edge of their abilities.
systemd would be a derail even if you weren’t misrepresenting the situation at several levels. Experienced sysadmins in my experience were the ones pushing adoption because they had to clean up the messes caused by SysV’s design limitations and flaws, whereas in this case it’s a different scenario where the extra functionality is both unneeded and making it worse at the core task.
> Experienced sysadmins in my experience were the ones pushing adoption because they had to clean up the messes caused by SysV’s design limitations and flaws
That's funny. I used to have to clean up the messes caused by systemd's design limitations and flaws, until I built my own distro with a sane init system installed.
Many of the noobs groaning about the indignity of shell scripts don't even realize that they could write init 'scripts' in whatever language they want, including Python (the language these types usually love so much, if they do any programming at all.)
I think you’d have a more fruitful discussion if you stopped trying to call people noobs when they don’t agree with you.
For example, I’ve been dealing with SysV since the early 90s and while it’s gotten better since we no longer have to support the really bizarre Unix variants, my problem with init scripts wasn’t “indignity” but the lack of consistency across distributions and versions, which affects anyone shipping software professionally (“can’t do this easily until $distro upgrades coreutils”), and from an operator’s perspective using Python doesn’t make that better because instead of supporting one consistent thing you’d end up with the subset of features each application team felt like implementing, consistent only to the extent that they care to follow other projects. One virtue of systemd is that having a single common way to specify dependencies, restarts, customization, etc. avoids the ops people having to learn dozens of different variations of the same ideas and especially how to deal with their gaps. A few years back, a data center power outage at one place I worked really highlighted that: the systemd-based servers recovered quickly because they actually had working retries; all of the older stuff using SysV had to be manually reviewed because there were all kinds of problems like races on dependencies like DNS or NFS, retry logic which failed hard after a short period of time, failures because a stale PID file wasn’t removed, or cases where a vendor had simply never implemented retries in their init scripts. While in theory you can handle all of those in SysV most people never did.
After a couple decades of that, a lot of us don’t want to spend time on problems Microsoft solved in Bill Clinton’s first term.
I hate to blather on about systemd in this decade but how in the world does creating something completely different than sysv init help people shipping software? Now they have to support yet another init scheme.
Prior to all of the important distributions consolidating on systemd, you had to support each distribution’s convention for customization, overrides, dependencies, conventions for things like changing users or locations for PID files, not to mention the differences in various shell tools.
Nothing insurmountable but it meant init files were inevitably much longer than the corresponding Upstart or systemd files despite doing less, and anytime we shipped a new version you had more testing since you had to implement a lot of functionality which is built in to other things.
I just created my own OS, with my own init system that does things how I think it should be done--and it does it every time, without the bizarre bugs that come from Linux Puttering's shitware code.
It's the same thing any corporation should be doing if they were smart, instead of outsourcing everything to RedHat, Microsoft, Google, etc.
The reality is unit files are more portable than init scripts, regardless of what anyone says.
Systemd unified and simplified administration across a lot of distributions. Before, it was a hodge podge, and there was a lot of knowledge lost going from rhel to Debian.
It's entirely possible that both SysV init and systemd suck for different reasons. I'm still partial to systemd since it takes care of daemons and supervision in a way that init does not, but I'll take s6 or process-compose or even supervisord if I have to. Horses for courses.
I want to love s6 but every time I see the existence of s6-rc-compile I get heated. I'm sure there are excellent reasons behind it but I personally don't want services to work that way.
Yah, that does look awfully baroque. My experience with s6 has largely been minor tweaks to an existing setup where the complexity was hidden away from me. I used to use runit for managing daemons, but nowadays my supervisor of choice is docker compose. process-compose does look enticing though, and the Nix world seems pretty fond of it.
Specifying system processes and their dependencies declaratively, rather than in a tangle of arbitrary executable code, is cleaner, more efficient, easier to use, and more auditable. And that's not even getting into the additional process management duties systemd assumes.
You can write arbitrary scripts into systemd... or like one step removed at most? That's not really a difference unless you have some nuance in mind that I don't.
I honestly do not like systemd, either. It is okay for managing processes but I wish it didn't spread into everything else in the machine.
Or if it must, could it actually work cohesively across their concepts? Would be nice to have an obvious and easy way to run Quadlet as its own user to isolate further, would be nice to have systemd-sysusers present in /etc/subuid so they can run containers.
I like what they are doing with atomic distros. It would be great to have a single file declarative setup for something like running a containerized reverse HTTP proxy with an isolated user. Instead of "atomic" but you manually edit files in /etc after install.
I feel like this ‘cloud-first’ strategy will only get worse now that AI assisted development is common. I notice my personal AI assisted C# projects get far more complex than when I use some JS framework.
If it’s not the colleges and universities, you can bet the AIs are better trained on JS/TS.
jyn’s advice here is spot on, however it misses an important point: jyn you are exceptional because you do these things. This is what excellence looks like.
reply