The basic open-disassembler GUI is sketched in. Snapped in the interactive shell I patched up on Friday night first, so I can test UI and other stuff from within the app itself.
The idea is that I shouldn’t have to do all this sloppy re-encoding at the end of the video, the fixed output format of ogv, or the hundred ffmpeg/avconv switches to get a decent quality screencast up on youtube or vimeo. So I thought I should make a simple gui to do it, and hopefully replace gtk-record as the “go-to” screen recording app for Ubuntu.
- Simple interface
- Presets for streaming service
- Re-encoded on the fly (sorry folks, you need good hardware)
- Split interval for hours long video
- Selection of alsa audio input interface
- All in pygtk piping command lines instead of native interfaces to avoid API changes where possible
It’s something I thought should exist for some time now…
They seem to exist in different incarnations for different platforms, but I don’t think that should be the case. Currently I belted out a basic working version in a few days. I used pygi/gtk to do it. It works on python 2.x and python 3. This means it should work on pretty much any unix/linux or Windows system.
Now that we have a basic working copy, I’m looking at finishing off a couple of features and changing most of the UI components from Gtk to Kivvy. What does this mean? Well you lose python 3 support, but you gain almost every mobile platform known to man and Mac. So a cheap cryptogram solving game you can buy once and have across all platforms (not to mention an ad driven version for free).
Features are going to be first, then the UI rework/translation to Kivvy. I think it needs a pledgie or kickstarter though… We’ll see.
I’ld also like to cover more ground than simple substitution. The code is put together in such a way that I can, but again… it takes time.
Not horribly techie, but I think some readers might empathise. Here goes:
So, I have this thing with attaching activities to people and my emotional status towards them. Basically this means that I am further techie, because this is a heavily singular activity. Consider the following examples.
I liked it, but it became a weekly habit with a friend of mine. We had a falling out and I no longer enjoy it.
Sausage Gravy Biscuits:
Various other activities fall under similar umbrellas. I wonder if this is indicative of some underlying issue? No idea. Anyway, those are the half-sane ramblings for the day.
It seems to me that portability is becoming more and more paramount to software project success. Read as app-stores on various platforms(desktop and mobile), runtime requirements, and other similar difficulties…
So to my point:
I said quite some time ago that I thought all applications would eventually become web applications to facilitate portability. It appears that the late Jobs at one of the D8 summits agreed. His agreement was contingent on getting applications on to the iPad. The end result remains the same, everything becomes a web application. The interesting part is that we do have some really amazing tools. I’m recently exploring Ext4JS, SenchaTouch2, and PhoneGap.
Looking at them in more detail:
PhoneGap: Target all major app-markets in the mobile space for downloadable and HTML5/CSS3/JS based applications that run locally/off-line. There’s also an abstraction layer for accessing device data from JS. That’s interesting.
SenchaTouch: Target android and iOS (no windows phone support as of yet) with portable HTML5/CSS/JS applications that feel native. Definitely interesting. I found a webcast where a fellow was on a team developing a massive project and combined Sencha and PhoneGap for some native component integration. Again, interesting and more doable than something like Xamarin.
Ext4JS: Hugely interesting since it’s a lot like SenchaTouch for the desktop. Native-ish look and feel all with HTML5 and JS. My hope is that eventually we’ll have something like PhoneGap to do native component integration and portable packaging for desktop applications. Instead of erecting these application development barriers, seemingly on purpose, let’s make them all go away.
I never wanted to do web application or website design again, until I saw this novel approach and started thinking about more far reaching implications. Seems like a great idea to me.
Really short post this time. More of an announcement than a discussion of some issue.
I thought one should exist, and it didn’t. So I made one.
Pure python, but requires root permissions so it can move some folders around in /usr/share/unity. Give it a try if you like, it’s here.
I haven’t made an astronomical amount of progress, the original entry was just theoretical. So far, we have getting CVE only bugs into a python dictionary.
I’ve tested some `dpkg —get-selections | grep` lines and some `apt-cache search | grep` lines to get both an installed on host check and a candidate check.
Also included is an open from file option, but it’s not implemented. Thinking ahead there that maybe I will need to open a package list for packages on diverse architectures and devices(linux-ti-omap got me thinking about that one).
Still doing some streamlining on the checking part. It’s mostly complete though. I’m also including exact matches and fuzzy matches. The `linux` pseudo-package for example is not installed by default so you need a fuzzy `linux-*` and pam as listed in the project name isn’t really pam, it’s `libpam*`. Maybe I’ll find a way to keep parsing on launchpad instead of just falling back to fuzzy matches. Maybe not. If you’ve got thoughts on this hit me up on http://www.askubuntu.com chat or by email.
Hopefully I’ll have something usable available shortly.
- They don’t get funded
- They try to accomplish too much and don’t limit scope
- They try to target too small an area and disregard integration
Just my thoughts on the matter…but let’s take a look at them. Spacewalk from RedHat, for example, seems pretty great. It just targets rpm based distributions from what I’ve heard. That’s not to say there’s no other OS support, but that rpm based distributions are targeted. That’s understandable. The people that developed it run a commercial rpm based distribution. Let’s see why it succeeded though:
- It got funded.
- It limited scope.
- It cared about integration (not with other distributions in this case, but it was extended in to other tools).
There was an interesting project that tried to clone Spacewalk for debian derived distributions. This could be the wrong approach. Why is that? It failed. Why do I think it failed?
- It lost funding in the first 10% of it’s target cycle
- It didn’t care about integration
So if I’m critical of something I think is awesome, which I think the project could have been, what do I think is the right way to do it? Well, let’s look at each of those fails in more detail:
It didn’t get funded.
It’s hard to promise that you’ll probably have something next year if funding continues.
It didn’t care about integration.
It was a clone for debian derived. It may or may not have addressed doing the same things on rpm based distributions, windows, arch, or gentoo.
So if that’s what’s wrong, how would I do it?
I would look at modules. Don’t even flesh in a framework yet. Just start with modules. If your deliverable includes a gui, just make it an html div. This way you can show pretty/formatted output across all platforms. Since it’s a div, you can just style it differently or pack it into a scrollable later.
Basically what I’m getting at I think, is that we need to build small snap-ins that return predictably formatted data and let the consumer deal with formatting. This could also be parallel in a lot of security auditing tools. They, for the most part, make a CLI. The fancy ones even use ncurses. The output is often less than easily predictable. I suppose it could be by design to keep someone from integrating something in to a larger framework, but isn’t that what software licenses are designed to address?
Thought I should amend my post, it seems someone added some support as part of their thesis. Interesting to be sure…doing some more reading. The underlying point remains the same.
So BSD has had port-audit for a LONG time. I think linux distributions tend to think of package security as “apt-get update && apt-get upgrade > /dev/null 2>&1”. It simply isn’t so. The problem I think is that everything in linux is shared between a zillion different forks and half-breed distributions with a half dozen package management systems. Why don’t we have a standard package maintenance reporting system?
Today we’re looking at Ubuntu. So the advanced search on launchpad bug trackers is nice. You can find out about only bugs that match CVEs which is helpful. Launchpadlib, a useful bit of python that lets you interact with launchpad in various ways. I started looking at how I would implement a port-audit-like tool using webpage parsing or launchpadlib. Seems simple enough except that every time I used the search for all CVE bugs in all repositories I kept getting errors. That’s no good, what about a particular package.
Well that worked. Dandy. Let’s see if that URL works if I chop it up and search the whole release…and it does. So now I have a well formatted list of bugs and the package the bug is filed against. This should be easy. Let’s just parse the divs, find the CVE, note the package, and dpkg —get-selections | grep right? Yeah, sort of… Not good enough for me though. We need a way to track an entire enterprise’s installed packages. What would the easiest way to do that be?
Well there’s the commercial Landscape service. I think we need to start building small standalone tools/scripts to handle things like this in a cross distribution way and an agent to run them on near any linux platform. Then we can parse some output from our agents and know if we’ve got a package issue. It’s not a enterprise management solution, but it’s a start.