You are not logged in.

#1 2006-03-19 15:05:11

Machiavelli
Member
Registered: 2005-08-24
Posts: 92

Project pitch: SHZ

I am an extremely untalented (and unattractive) joke of a "programmer" (or rather, I like to randomly enter code into a textfile until it provides some kind of noise or text output, to which I react with the unbridled excitement of a twelveyearold), that between writing useless and bloated bash scripts and contemplating suicide occassionally come up with an idea that although I am aware of it suckyness, provides me with the will to live for the few weeks that it occupies my mind.

This is one such idea. I call it 'shz' (not to be confused with 'zsh') and it is entirely written in bash (which I suck at - but then, again, I am a total failure). The shz stands for something. To be honest, at first, I had no idea what, but I thought it sounded cool. Now I've decided that it either stands for "ShellZ" (like in a zipped shellscript) or "ShieldZ" (like in a zip-based InstallShield-like solution).

These early mockups might give you an idea of what I was going for:
small_shz_real_qt.png
small_shz_mockup.png

I was thinking about how Linux could be more adjusted to the desktop-oriented user. Now, I am not a believer in desktop-oriented system administration (as per Windows), but I thought that maybe if we couldn't get the users to package installation solutions, maybe we could get the package installation solutions to the user?

The SHZ solution is this: you have a .shz file. You double click it. If it's the first time you double click it, it deploys into the folder where it is located. Then it runs. Simple.

The .shz file is really just a zipped archive with a couple of necessary scripts, configuration files, and a binary installation of the program being installed PLUS all of it's depencies. Yes, this sounds bizzare. And, yes, I am probably high. But hear me out. When the archive deploys the shz script checks which of the files in the archive it should keep, and which could be thrown out without consequences (if, for example, they are already present in the system). When the .shz has deployed, it repacks itself with only the scripts and configuration files, thus shrinking to the size of a few kilobytes. Left in the folder is only the files needed for the program to run.

It's so crazy it just might work.
Here is some records of the progress I've had with this idea (note: these are real screenshots, not mockups):
http://machiavelli.homelinux.org/shz/screenshots

As you see, the program ends up being pretty confused as it is. Otherwise, the idea pretty much works.. pretty much. :cry:

Besides generally killing my idea, I was hoping you could help me with this latter problem. While binaries and libraries for the program is correctly loaded (thanks to $PATH and $LD_LIBRARY_PATH variables, for example), other things like data (typically $prefix/share-stuff) is searched for where the configuration script was told it would be (here: /Main/Data/). What I need to do is fool the entire program that it is, infact, mobile, and that it, theoretically and with the right adjustment of environment variables, could be placed anywhere. But I have like NO idea how to do this because I am a worthles human being and pathetic in bed.

Any ideas?  wink

Offline

#2 2006-03-19 15:48:53

jaboua
Member
Registered: 2005-11-05
Posts: 634

Re: Project pitch: SHZ

I've never tried it, but I think that's what klik does.

Offline

#3 2006-03-19 16:00:54

Machiavelli
Member
Registered: 2005-08-24
Posts: 92

Re: Project pitch: SHZ

http://klik.atekon.de/wiki/index.php/Architecture

"The klik server calculates dependencies either from entries in the klik database or by using the debian package database. While with traditional package managers dependency resolution is performed by the locally installed package manager, it is performed on the server with klik."

This is so typically Linux. The klik model still makes you dependent on having just one source of installation. My vision is .shz files being distributed the same as .msi files: anywhere, for anyone.

Despite this klik *does* seem to have gotten some things right. I'm gonna check out how it handles setting paths and some other stuff aswell. Thanks for the tip.

Offline

#4 2006-03-19 16:10:36

elasticdog
Member
From: Washington, USA
Registered: 2005-05-02
Posts: 995
Website

Re: Project pitch: SHZ

Machiavelli wrote:

But I have like NO idea how to do this because I am a worthles human being and pathetic in bed.

LMAO...sounds like an awesome project matey!  I too am a worthless human being and pathetic in bed, or I'd be able to help you out.  big_smile   Don't give up on it though, it's a cool idea!

Offline

#5 2006-03-19 16:48:50

max_sipos
Member
From: Ithaca, NY
Registered: 2004-10-31
Posts: 106
Website

Re: Project pitch: SHZ

Sounds like autopackage to me:

autopackage.org/

although the website seems to be down at the moment.

--
Maksim Sipos

Offline

#6 2006-03-20 06:16:22

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Project pitch: SHZ

Yeah, it does sound like some combo of klik and autopackage, *BUT* I hate the way both of those apps work.
I think this sounds closer to the way the mac .app files work.

I say go for it.  Is that gimp working, or just a mockup?

Offline

#7 2006-03-20 14:17:10

jaboua
Member
Registered: 2005-11-05
Posts: 634

Re: Project pitch: SHZ

phrakture wrote:

Yeah, it does sound like some combo of klik and autopackage, *BUT* I hate the way both of those apps work.
I think this sounds closer to the way the mac .app files work.

I say go for it.  Is that gimp working, or just a mockup?

He said "These early mockups might give you an idea of what I was going for"

Offline

#8 2006-03-20 17:00:39

cactus
Taco Eater
From: t͈̫̹ͨa͖͕͎̱͈ͨ͆ć̥̖̝o̫̫̼s͈̭̱̞͍̃!̰
Registered: 2004-05-25
Posts: 4,622
Website

Re: Project pitch: SHZ

Machiavelli wrote:

It's so crazy it just might work.
Here is some records of the progress I've had with this idea (note: these are real screenshots, not mockups):
http://machiavelli.homelinux.org/shz/screenshots

Sounds like the screenshots are working...


"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍

Offline

#9 2006-03-20 18:01:49

Machiavelli
Member
Registered: 2005-08-24
Posts: 92

Re: Project pitch: SHZ

The screenshots are all authentic. But I wouldn't call it "working". I mean, it's looking for all data in /Main/Data, for example.

Offline

#10 2006-03-20 18:50:21

Sander
Member
Registered: 2006-02-26
Posts: 138

Re: Project pitch: SHZ

When the archive deploys the shz script checks which of the files in the archive it should keep, and which could be thrown out without consequences (if, for example, they are already present in the system).

Would they be replaced with symlinks or something? Or does it work differently?

I quite like the concept, though.


You like cheese? You like peas? You'll love cheezy peas!

Offline

#11 2006-03-20 23:07:20

Machiavelli
Member
Registered: 2005-08-24
Posts: 92

Re: Project pitch: SHZ

Sander wrote:

When the archive deploys the shz script checks which of the files in the archive it should keep, and which could be thrown out without consequences (if, for example, they are already present in the system).

Would they be replaced with symlinks or something? Or does it work differently?

I quite like the concept, though.

I am not exactly sure what you mean, so I'm gonna give you a rundown of the works.

The whereis command is used to check the availability of each of the files packaged in the .shz. Those not available will be extracted into the directory. Then the package repacks itself, ergo it creates a new package with only the script in it that replaces the first package. Voila.

One of the scripts is a profile.d script that gets sourced, which sets a couple of environment variables that makes the program look for libraries and binaries in the paths concerned, for example.

According to my earlier programming experiences, this could probably be done in a much easier way. I suspect that setting variables in this way won't help me in the long run. The program starts at the source code configuration level. I individually set all the *dir arguments (--bindir, --mandir, etc) to /Main/Binaries, /Main/Manpages, etc. I have a pretty weak understanding of the internals of the GNU Make model and perhaps this makes me downright unsuitable for the job of making this program work. Anyway, it's an unavoidable fact that the program will keep looking for the files where the configure-script believes them to be, no matter what env variables I declare. Binary and library files can be set, but what about data paths? This is my real dilemma.

Offline

Board footer

Powered by FluxBB