chrsig

Yeah, helm is...interesting. it's just a gnarly yaml -> template -> yaml cycle. it's better than nothing for the problem it solves....but god, there's gotta be a better way.

Without additional context, this is my default understanding. If it were in a compiler development conversation, I'd think of outputted machine code.

Yes, there's nothing novel about an append only log. What's missing (or unbeknownst to me) is a library or small server that provides a good general purpose implementation.

It's not just a matter of "write to log, done!". Ensuring persistence, keeping track of consumer offsets, transparent compression, waking up consumers on new message availability, support for transactions...

It's not just a append only log that's wanted, it's a system for managing append only logs, without the complications like leadership election, replication, partitioning, etc.

It's relatively easy -- removing any networking requirements drastically simplifies the problem. There's still some non-trivial bits that vary depending on granularity for concurrency.

It's a weekend project to demonstrate the concept, maybe a few weeks to really flesh it out and iron out quirks. I imagine if you're willing to use sqlite as a backend for persistence, it gets a bit easier.

One of my desires would be for it to be persistent. Hopefully with the option of different storage tiers, so as logs became older they could be moved to less costly medium and transparently fetched when requested.

Having an event sourced system doesn't make much sense unless you maintain messages from the start of the system. You can snapshot state and resume in order to quickly rebuild from a known good state. That doesn't help if there was a logic error corrupting every state from the start, and a full rebuild is required.

I'm unsure how redis streams behave with regard to cache eviction, nor am I familiar enough with rabbitmq to comment on it's behavior. It's been 10 years since I used either, and at the time neither were good solutions for a log based system.

Not that I'm aware of. I've been very tempted to write my own.

It seems a lot of the complaints weren't about kafka itself, but rather seemed to stem from internal communication problems. Custom kafka message headers could very well be custom http headers, and the problem is the same. Kafka is just coincidental.

Looking at the volume though, kafka is overkill. They most likely could have just used the database and reaped the benefits of doing everything in a single transaction, with easier row level locking. The post acknowledges this.

I do think it highlights the need for a small scale kafka, though. It's conceptually great to have everything work off of logs, but kafka does add a non trivial operational burden.

All spaces are invisible :)

Hipchat would insert non visible characters when copy and pasting messages. I don't know if they still do. I remember spending an absurd amount of time replacing every single bit of a sql query until I finally discovered that it was the "spaces" that the mysql parser was yelling about.

When considering bad faith actors, I tend to consider taking extreme: I worry that the toggles don't actually do anything at all. Or there's some other means of exfiltration in use that's not covered by the existing controls.

This is assuming the use of a monotonic clock. the system wall clock may jump backwards in time. Itt also assumes that only one id can be generated per millisecond (or whatever clock resolution). In the case of multiple threads or processes on multiple cores, it becomes more likely that there will be a collision.

Timestamps don't make for a great ordering key.

I'm sure there's some equivalent of putting a playing card into the spokes

The departure from precise timestamps in UIs is unpleasant. It's not just github, gitlab does it as well.

I'm not defending them, I'm being critical of the approach taken by the OP, because of the clear attempt to rile people into picking up their pitchforks.

If the corporation doesn't care, why are you spending energy complaining about it?

Are you hoping to enact change, or are you just complaining?

Sure, but if you're looking to have a dialog with the corporation about it, bringing specific actionable feedback is going to be met better than petulant foot stomping.

Honey vs vinegar, and all.

Given the text of that first post, it's no wonder why there's been silence. What do you even do with that?

It gives no details about why whatever the new feature is bad, or what was good about the prior behavior. It's presumptive, antagonistic, and doesn't leave any room for discussion.

It really seems like OP is hoping that dogpiling on the issue will bring about positive change.

> Another limitation of unix domain sockets is that the size of the path string must be less than PATH_MAX. I've run into this when the only directory I had write access to was already close to the limit. Local TCP sockets obviously do not have this limitation.

This drove me nuts for a long time, trying to hunt down why the socket couldn't be created. it's a really subtle limitation, and there's not a good error message or anything.

In my use case, it was for testing the server creating the socket, and each test would create it's own temp dir to house the socket file and various other resources.

> In general, I choose a shared memory queue for local-only inter-process communication.

Do you mean the sysv message queues, or some user space system? I've never actually seen sysv queues in the wild, so I'm curious to hear more.

none, and I do use gnome.

to be honest, I'm not even sure where I'd get a shell extension, or what I'd want out of one. I tend to run apps in full screen and switch between virtual desktops.

To be fair, there is a meth problem in the US.

Also there's a huge chasm between lab grade amphetamine and street meth.

I'm sure all missiles will eventually cause problems for someone, somewhere

there is of course one notable use for turning off garbage collection

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Glad to have my wild speculation disproven :) And glad that becoming a full time independent maintainer is working out for you!

Though, in hopes you see this, I have to ask: Is there any sort of plan for if you wanted to step down from a maintainers role of the go crypto packages?

You're sort of known as "the" go crypto person, so I guess it occurred to me that your bus factor might be quite high. Any thoughts you can give to assuage fears in that regard? Is there anything the community can do to share the load, short of becoming cryptography experts?

my bet is it has something to do with Filippo Valsorda having left google, but that's pure speculation on my part.

https://github.com/FiloSottile

So next up, we'll be hiring people to put the bugs into the code base, so AI companies like this can stay in business, right? No bugs means no AI to fix bugs.

I've been actively trying to find ways to offload tasks to software assistants -- I've slowly been getting a bit more comfortable using siri.

My first impression is that the results tracking will just be a report of failures and wind up causing disinterest in the application as a whole.

I also am concerned that the AI may wind up placing demands on me that I may think I want in one moment, but don't wind up engaging with...leaving a bunch of stuff piling up.

The example of the presentation just sort of leaves it at "About the presentation ...", at which point it seems like the user is expected to ...tell the ai about the presentation. So I haven't really been shown how it solves any problem that I have.

Also remember that AIs are biased on the training set and you're targeting a minority of a population. It's probably not going to know "how" to speak to me, what tones actually work, etc.

I hope that all amounts to useful feedback -- I do really want an effective product to offload stuff to -- but if it's not effective, it has negative value in my life.

What outcome were you hoping for when you decided to spend that time and energy?

unfortunately, you need a PlanetUML server when using a self hosted gitlab install.

running directly in the browser is, imho, the best feature of mermaidjs

I'm not sure what point you're trying to make. Can you rephrase, please?

I'm sorry you had to live through that, and I'm glad you had tools to subvert that oppression. I'm relieved that it sounds like you've escaped from that situation.

It was not my intent to assert any privilege, and it was my intent to acknowledge that scenario. If I may provide some clarification:

Marriam webster[0] defines 'double edged sword' to mean

> something that has or can have both favorable and unfavorable consequences

The use of Tor in the scenario you describe is one of the two blades (edges) I was referring to in my use of 'double bladed sword' -- the altruistic use case for which Tor absolutely should exist

The other side of the blade however, it's also used to facilitate terrible acts of abuse, notably to children (as demonstrated by the article) -- the destructive use case for which Tor absolutely should not exist.

It leaves Tor in a morally ambiguous place to me. It's not inherently bad or good. There are situations where it can be used for great good, and others when it can be used for great evil. Those situations would exist with or without Tor. I don't know if I should be thanking anyone maintaining it any more than I would thank an arms dealer.

[0] https://www.merriam-webster.com/dictionary/double-edged%20sw...

> Running a tor node is a thankless thing one can choose to do. Nevertheless I did for years. I don't do it anymore.

It's hard to determine tor's net-value to society, since it's such a double bladed sword. I'm not sure it's something deserving of thanks.