An interesting read:
And yes, I am probably the oldest kid on the block.
I am Commodore Pet old…
I’m punch cards on an IBM 1130 old…
1 Like
Indeed, many punched cards for me too.
So, how might Graphviz lurch forward?
- “Fresh blood”? (sounds like a bad vampire movie).
- If so, where do they come from?
- How do they get mentored?
- What changes might they want to make?
- More (some) AI?
- Merger with other systems in the same boat? (A standard business solution)
- Pack it in and head to the nearest retirement home?
I think one of the hard truths is that few young people want to maintain a >30 year old C code base riddled with memory safety problems and UB.
True, though probably the issue is not mainly technical problems like memory safety in C, but more broadly, having too much difficult work without sufficient incentives, even indirect ones like eligibility for better employment. We had a great run, though.
1 Like
Yes, this might be a problem for other projects. Luckily I’m young and fresh and not very gray and Matthew is roughly 20+ years younger than me, so I expect Graphviz to still be going strong for at least 30 more years. By that time, most certainly all memory safety problems and UB will be long gone, given the pace Matthew has. Unless an AI, trained on all the world’s existing programs, has taken over and re-introduced them of course.
BTW, I’m ABC80 old. Go figure!
Everybody gets a guess, this is mine:
- in 5-ish years (+/-3), the tools and processes to convert C, C++, … to “safe” languages (Rust, Go, …) will be good enough to go with (see https://www.cisa.gov/sites/default/files/2024-06/joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf and Introduction to C2Rust :: Immunant, Inc)
- Graphviz is not “important” enough to receive direct governmental pressure to convert
- However, internal & external auditors will push businesses and governmental organizations to clean-up their tool sets
- Also, some of the tools that use Graphviz (see External Resources | Graphviz) will start to lean on Graphviz
- Someone (or some team) will convert Graphviz - and thousands of other open source tools
- Finally, the mad scramble to find enough rust/go/… developers to support all these newly-translated systems. Whee.
Yes, you’re right.
You’re quite optimistic 
I might be younger than you, but I am still old enough that I intend to retire well before 30 years time.
As I’ve occasionally opined in the past, I don’t think any language conversion (even automated) is worthwhile for Graphviz. It’s a program that takes input and writes output. The pragmatic path to safety is just to sandbox it in a way where it has stdin/stdout/stderr, but no file I/O, and no network.
These are the reasons I am vested in WebAssembly, while it doesn’t solve the memory issues, it does prevent them from being exploited, especially as we continue to transition (back) to centrally shared resources.
(…plus a bunch of other interesting benefits…)
1 Like
A niggle - gvpr can read & write files and has a system call.
I don’t think it’s possible to meaningfully sandbox gvpr. By its nature, it runs arbitrary code.
There’s a discussion right now on kernel-hardening about a new Landlock feature for restricting execution. One thread of this has people asking about sandboxing things like Bash and Python and is basically circling the same core problem: you cannot meaningfully sandbox a general purpose interpreter.