Best posts made by QuixoticJustin

New feature is that after a ticket has been opened, you are now able to add additional "CC" contacts on both the customer and the tech support sides.

@manxam said in Sodium Update:

@quixoticjustin : I notice that the Quixotic team is spending a lot of time on the ticketing end of things but the asset screen is getting little love. When will one be able to view running processes, inspect the event log, uninstall an application, etc?

Well if you go into what we sometimes call the "DeepDive" view of an asset (not the dashboard, but getting the individual machine details) you might notice that in the last release we've added the ability to view available updates and to install them. We've been keeping quiet about it as it is a major feature and we don't know how stable it is yet. We are testing it heavily to try to find issues with it. But this is a pretty major feature release for that side of things. We are running one update after another in testing right now and so far things are good, but there is a lot to test.

Event Log is quite a ways off, it requires a lot of storage and planning. Running processes we hope to have sooner than later. Uninstalling apps is complex because it has to handle a lot of operating systems and installation / uninstallation methods.

Right now, we are carefully trying to get what is there solid and useful before we expand into new features. We don't want to make the mistake of half releasing features (like the helpdesk) that then get abandoned for something newer and shinier. Everything that we do we need to have working solidly and helpdesk is still quite some way from that. We'd absolutely love to be working on the coolest, most fun features immediately, but if we don't have a solid base, no one will care. So we have to balance where we are focused very carefully.

And it's official! Okay, not official, there is no downloadable installer yet. But, SS is working on Mac OS. We have our first install and it went pretty smoothly. Was all manual, but worked great. Requires HomeBrew which is not ideal, but not a big deal, either. We will likely make different versions of the installer or something like that, in the future. For now, though, a HomeBrew managed install is simple and working. We might have an installer built and out by the end of the weekend.

One of the big goals of tonight's latest release is to eliminate the accidental "global chat" option that appears from time to time.

It's been a bit since we posted an update large enough to mention. This morning's update is quite large. Not in new features, but SodiumSuite is quite different this morning.

Two major new changes are now in the system:

1. Chat has been removed. I'll post more about this later, but the decision was to take IM communications in a new direction and as such the chat feature is no longer included in the SS system and is not on the pages.
2. The log out problem appears to have been fixed. This one has been a long time trying to track down. The system now should be able to keep people logged in for long periods of time with data regularly updating without any interaction needed.

The changes have also brought about significant performance improvements. Pages are certainly snappier today. And without the space used for chat, there is a lot more screen real estate for tickets, assets, or whatever you are viewing. Very helpful for those on smaller displays.

We have added Solus to our support matrix.

Windows 8 & 8.1 added as working.

We have added PCLinuxOS - a Mandriva derivative that uses APT to manage RPM. Talk about complex.

@wrx7m said in Ticketing Solutions for IT Department:

@quixoticjustin That's right. You did say SaaS. Hosted was one of my requirements

Account created.

Awesome. Once you sign in, just hit the Helpdesk tab. It's very rough looking, but a lot of functionality is there now and more day by day.

Well at first, GitLab just went offline. That was about two hours ago, I think. Then they updated their status an hour and a half ago to say that they were doing a deployment. That went on for a while.

A few minutes ago, they announced this...

@dengelhardt said in Sodium Update! New Dashboard!:

Just installed. I want to see what it can do.

Well right now, it is very much a tech preview, but we are excited about how it is going. Our focus at the moment is getting solid data collection that really lets you see your assets and keep track of them. One step at a time, we have a lot of work to do. But things are coming along and changes are happening daily!

Yes, it is standard for any high performance application in modern times to use an in memory database for performance of at least part of its workload. Sodium is planning on this as part of its design.

The most commonly known database for this is Redis.

We've been updated. GitLab is down because Azure East 2 is down. Microsoft's latest status is that they are down for a while and will give another status update in about an hour.

And the evening of deployments begins.....

Hopefully we will see some new stuff tonight. Fingers crossed.

@networknerd said in Using In-Memory Databases, Anyone?:

@jimmy9008 said in Using In-Memory Databases, Anyone?:

@networknerd said in Using In-Memory Databases, Anyone?:

• They actually point out in the podcast that they had the best success with in-memory databases on local storage or SAN (NAS not a good choice) and that ethernet was the networking avenue of choice.

Not sure what this means... not that I know about this, but, if its in memory, its in... memory, right? So, what does it have to do with local storage, SAN, or NAS?

Anyway, other databases load what is used frequently in to memory so its quick to access. Its why lots of places would build an SQL server with a ton of RAM - so that SQL can put what is used often in to RAM (fast) and keep it available... right?

Well, at some point you do have to write the data to disk (whether synchronously or asynchronously) to keep a less volatile copy of the data (at least that is what I remember from the podcast). It seems like synchronous data writes would be near impossible because you cannot keep it going at the same speed.

I definitely do not claim to understand it all really well.

Not necessarily. Persistence to disk is not a guaranteed feature of in memory databases. It is common, for sure, but not guaranteed. But you should think of it as taking a backup of the database, not as storing it normally. That's the big difference between the two approaches.

At least we are getting lots of other testing done in the meantime around here.

I know that it seems like a quiet evening here, but we are hard at work behind the scenes. Just wrapping up the work on one new installer and trying to do some polishing on another. @QuixoticJeremy is working on some complexities of key management and orchestration.

@matteo-nunziati said in Using In-Memory Databases, Anyone?:

@quixoticjustin you mean volatile session data?

Yes, data that is needed for performance and consistent session behavior but if lost would not have a real impact.

@kelly said in What Are You Doing Right Now:

@QuixoticJeremy @QuixoticJustin Maybe this needs to have its own thread, but how are you funding your tools? I'm always interested in working with new tools, but the world of FOSS is littered with abandonware.

We are funded by a private equity group in Texas that invests in technology-related businesses, primarily. I doubt that we will be going anywhere, we have no venture capital type people to answer to, and our backers have been around for a long time and are just changing their investment style. Traditional VC is churn and burn (build it up, get market, sell it) but ours are long term growth investors - they specialize in building long running businesses focused on revenues years out and make their returns from operational success, not selling to a larger player like California style VC focuses on.

Data collection has definitely improved some at this point. We are seeing more data and the main table is generally filled out properly. So small steps.

We were hoping for more to show tonight, but Azure outages killed our GitLab and we'd rather stay productive on other things than work around our deployment processes, at least for the moment.