You can make any leaps of logic into chaos theory. hell, maybe a fully-occupied orphanage will burn down because of some percolation of events that wouldn't have occurred had CloudFlare kept running. Maybe the next genocidal leader was conceived at the precise moment because CloudFlare was down and his parents used the time to make whoopie?
I don't follow. A "corporation" is just an entity that's filed articles of incorporation with the appropriate government office. You can have a single person that owns a corporation or LLC. (Source: I own an LLC.)
Yeah, I've worried about this a lot. Perhaps there's someone I could hire to give hucksh a clean bill of health. I wonder how much Bruce Schneier would charge? :) (That's a joke; I'm confident that, even if he'd do it, I couldn't afford him. But something like that is what I'm thinking of.)
Googling "security audit my code" finds several companies that offer such a service. My concern would be (aside from the admittedly non-trivial benefit of just having better code), would it make a difference to anybody that was on the fence about it? I suspect that the matrix of "potential customers" vs "what auditing service they'd trust" is large.
I've read your comment a couple of times, and I think (maybe) I finally understand it.
I don't think hucksh (or any shell) could provide an automatic way to undo some series of arbitrary commands. If nothing else, "/bin/rm" is forever, generally speaking.
What it could do is let you select individual commands and then automatically combine them all into a single command that you can save or copy&paste to someone else. Right now, the UI shows the command ID, which is a database key, so you could do something similar yourself, something along the lines of
hucksh sql "select command
from command_history
where id in (101, 103, 105, 107, 109)
order by id"
where the "101, 103, 105, ..." are the IDs of the commands you entered and want to reify into a single "one-liner". Noting them and entering them by hand would be a drag, but it'd work.
Hope this helps. If I've misunderstood you in some way, let me know. Thanks for your comment, regardless. :)
Please give the trial version a shot before using it (literally? :) in anger.
It's as good and stable as I can make it at the moment, but I'm not going to pretend it's, you know, absolutely rock solid against anything you can throw at it, and I'd hate for it to crash out from under you in the middle of a competition.
On the plus side, of course, if it does you should be able to just restart it and be on your merry way; that's what I do. :) So maybe it'd be fine.
> I see this as capture of processes -- their invocation, context, and results -- in a relatively normalized form for analysis and re-use.
That's a nice, neat, concise way of putting it. Thanks.
> There are many possible applications based on analyzing these ...
Those are some neat ideas. I'd certainly have to talk about them with some real users to understand the demand and use-case. I think the easy sharing I mentioned could go a long way to achieving that goal.
You can also already pretty easily extract just the commands run, to (as you put it) hoist it into a larger script or workflow. E.g. in my current instance, `hucksh sql "select command from command_history where id > 2863 order by id"` dumps out the most recent 10 commands you ran.
> No one likes to have this level of intrusion or monitoring, but everyone seems to accept running code in containers, so if this were built in to the container, it might be easily deployed and widely accepted.
Hmm, perhaps.
That does give me an idea for another use-case for hucksh in containers: mount the hucksh database file into a container, across invocations, to have a more seamless history of working in the container.
> A more narrow goal based on the current implementation could be to build and maintain a library of bash functions or scripts, possibly shared by a team.
Indeed. That's where I was going when I said "I hope in the future to make it easy to share history, which could help with new employee onboarding, [etc]."
> My goal is always to migrate any bash that gets big [...]
Yes, I agree.
Thanks again for your comment. Some neat stuff here.
Use code HN-1223 at checkout for 90% off ($40 -> $4) a license key through the end of the year. (... Which is a lot closer than it used to be, sigh. Time marches on.)
Correct, it's not open source. I did mention that it's a commercial product, but of course some commercial products are also OSS. Mine is not.
> I would want to see a lot more justification for why this is closed
I'm not sure what justification I can offer besides "because I want to try to make a living selling my own software, starting with this product, and I think that'll be easier if it's closed source".
We might certainly differ over price points or value added. Pricing is a bit of a black art and this is my first commercial software product. (As I mentioned in another comment, I'm happy to offer a discount code, if that would help and not get me banned.) Like, would you be happier if it were 1, 5, 20 dollars? Or does the price, as such, even bear on the open-vs-closed question?
I'm unclear on how you (or I) would correlate "added value" or "private lines of code" vs. "justification for being closed source".
Thank you for your comment, this is an interesting discussion.
I'm not the previous poster and I don't think you need to "justify" anything, but the main reason I'd like the source code is so I can fix my own problems and don't need to rely on you. I care a lot less whether that's under an open source license or NDA or whatever: as long as I can build it and include any changes I want.
Maybe Tuesdays tend to be a big day for me, and instead of "down for a day", it's "lose almost a quarter of my income for the month".
Cloudflare is pretty pervasive, there are all kinds of people and businesses, in all kinds of situations, impacted by this.