118 replies to this topic

[Brian M]

I'm personally voting for an arch base. Maybe we should begin managing the project properly - i.e. first of all design a preliminary first-stage task list, and go from there deciding who can, will, or is capable of doing what.

[Farstrider]

Barney, on 09 September 2012 - 19:38, said:

Before anyone starts pointing fingers, I just wanted to add that a project like this requires distinctive roles of developers, graphics people, PR people, and the like. It also requires a roadmap that eveyone on the team understands and follows. The importance of good orgaization and communication can not be under emphasizied. It also requires regular, organized meetings to sort out issues and assign tasks.

No one should be discouraged if the project slows down or speeds up. The ups and downs are a part of the journey. It took 3 years to get Shift up and running. We had Shift team members come and go......... we had several changes in lead developers. We also had several lapses while we re-organized... It takes time and committment to complete a community project.

If there is a team that is still interested, take your time and work through issues like this. Don't listen to the trolls and distractors. If you guys want this project to succeed, it will.

Just my 2 cents!

Barney

Nice words of encouragement, thanks for that! Totally agree with the above sentiment.

Stocker360, on 09 September 2012 - 21:09, said:

I'm really sorry guys, had a lot of stuff on my plate atm. I know it isnt cool for me not to post anything, and I apologise, but now that everything personally is sorted, I am still here, and I still want to get this going.

Looking at a few peoples comments, is Arch the best way to go forward, if it looks like there are people that still want to contribute, but wont because of the base choice, would it not be best to change it so we can actually get something started?

ARCH was agreed on at the beginning of the project and should be adhered too. The fact that ARCH is based on bare minimum to start with gives a clean base from which to work with and also that pacman is an excellent package manager to go forward with.

The beauty of pacman is that it is a utility which manages software packages and uses simple compressed files as a package format, and also maintains a text-based package database (more of a hierarchy) just in case some hand tweaking is necessary.

Pacman does not strive to "do everything." It will add, remove and upgrade packages in the system, and it will allow you to query the package database for installed packages, files and owners. It also attempts to handle dependencies automatically and can download packages from a remote server.

ARCH also has a few excellent "rollback" mechanisms in the event that added software needs to be uninstalled. That Arch Linux is a rolling release also ensures that the system is always up-to-date. The repositories are fantastically maintained and on the very rare occasion that something breaks there is always help on the front page detailing the workaround or fix.

I use ARCH on both of my boxes that I use in my office so yes, I am slightly biased but if I can get a grip then anyone can! It's a strong, good operating system and runs well on new as well as old architecture. I have ARCH with "systemd" and "awesome" running on my old 3500+ Athlone and it runs like an express train! Also everything works perfectly.

Thanks, just my 5 cents.

[Brian M]

One thing we used to have, which were quite productive, were meetings on IRC, where we could discuss things in real-time. It may be worthwhile trying to find a time when the vast majority of people will be free.

[+Stocker360]

Yeah, I have had a think about it, and still think that Arch is the best way to go. Just for the complete customisation you can do. Ubuntu did interest me just because of the mainstream support it seems to be getting but I suppose having something nearly premade goes agaisnt the point of this project.

Brian, what is the best way about getting the word across for IRC meetings? There really only used to be the few people that ever went on it, probably due to time zone or something (eg normally as I go on around 8-10PM UK everyone else seems to be going).

Im going to be on IRC now for the time being if anyone can make it on?

[AJerman]

I like the concept of Arch, but I also like the concept of FreeBSD still too. The issue is the same for me though, albeit not as bad with Arch. Linux support is limited still in software distribution, and while nearly all Linux software can be downloaded in source form, compiled, and installed on anything, I've grown quite partial to having installer packages such as deb packages. Maybe it's not the true Linux way, but when I use Linux on my home computer, I don't want to be spending my time compiling **** constantly.

That said, I do see that Arch allows you to install rpm and dpkg? I've never actually used Arch, so I don't know about this and if it all works just fine and everything. My Linux is a little rusty, but if I downloaded a deb for Ubuntu from a developer, dpkg should install it on Arch still assuming I can satisfy dependencies? If so then I've got nothing against Arch, and wouldn't mind giving it a try even. Perhaps that could be part of a focus in the Shift project. Including RPM and dpkg to make it as compatible as possible with software that's available without having to compile.

Anyway, just some random rambling. I'd possibly be interested in getting involved in the project, but I'd have to check out Arch and learn about it a little.

[+Stocker360]

AJerman, on 12 September 2012 - 16:53, said:

I like the concept of Arch, but I also like the concept of FreeBSD still too. The issue is the same for me though, albeit not as bad with Arch. Linux support is limited still in software distribution, and while nearly all Linux software can be downloaded in source form, compiled, and installed on anything, I've grown quite partial to having installer packages such as deb packages. Maybe it's not the true Linux way, but when I use Linux on my home computer, I don't want to be spending my time compiling **** constantly.

That said, I do see that Arch allows you to install rpm and dpkg? I've never actually used Arch, so I don't know about this and if it all works just fine and everything. My Linux is a little rusty, but if I downloaded a deb for Ubuntu from a developer, dpkg should install it on Arch still assuming I can satisfy dependencies? If so then I've got nothing against Arch, and wouldn't mind giving it a try even. Perhaps that could be part of a focus in the Shift project. Including RPM and dpkg to make it as compatible as possible with software that's available without having to compile.

Anyway, just some random rambling. I'd possibly be interested in getting involved in the project, but I'd have to check out Arch and learn about it a little.

It looks like DPKG is in the AUR.... apparently anyway.
Ohh, dpkg and rpm support, if doable sounds like a good idea.

[n_K]

Brian M, on 11 September 2012 - 11:50, said:

I'm personally voting for an arch base. Maybe we should begin managing the project properly - i.e. first of all design a preliminary first-stage task list, and go from there deciding who can, will, or is capable of doing what.

Agreed!

Why bother with dpkg and rpm support? They offer nothing except pointless baggage from a very outdated model, Arch has the AUR which and PKGBUILDs which are far superior. If you can think of any reasons why rpm or dpkg would actually be of any benefit please do tell me.

Anyway I reckon things we need to get working right now are:
-> Base ISO that will boot a GNOME3 GUI and load the required X11 drivers (intel/nvidia/ati) via a simple lspci script, or if that fails present a menu in CLI? (And have the option of force-showing the menu using a boot command line)
-> Basic looking non-functioning installers in PHP-GTK, PY-GTK and C# to compare them
-> Get Shift2 images onto the bootup ISO and change the version/name strings to say Shift2

[+Stocker360]

n_K, on 13 September 2012 - 12:10, said:

Agreed!

Why bother with dpkg and rpm support? They offer nothing except pointless baggage from a very outdated model, Arch has the AUR which and PKGBUILDs which are far superior. If you can think of any reasons why rpm or dpkg would actually be of any benefit please do tell me.

Anyway I reckon things we need to get working right now are:
-> Base ISO that will boot a GNOME3 GUI and load the required X11 drivers (intel/nvidia/ati) via a simple lspci script, or if that fails present a menu in CLI? (And have the option of force-showing the menu using a boot command line)
-> Basic looking non-functioning installers in PHP-GTK, PY-GTK and C# to compare them
-> Get Shift2 images onto the bootup ISO and change the version/name strings to say Shift2

Sounds like a plan n_K

I was just thinking of putting dpkg/rpm/etc on there just to help with compatibility. Especially for when things like Steam come out (finally)

EDIT: Again, if anyones around for some IRC'n then just pop in and say hi.

[Haggis]

as soon as we have an iso that boots to a gnome3 gui am in lol

[+Stocker360]

Haggis, on 13 September 2012 - 18:51, said:

as soon as we have an iso that boots to a gnome3 gui am in lol

Come on, join us on the dark side (code)

[n_K]

After a lot of hacking around.... Behold the results of PHP 5.2 with PHP-GTK2 and a (partially) working GLADE3-GTK2 (although it segfaults a lot ) via remote X11 over SSH [Possible bug? After a while of inactivity, trying to run it gives 'Could not startup.'].

Now onto working out how to control that with PHP events

Attached Images

• 
• 

[Haggis]

that looks awesome lol

[n_K]

OK bit of a severe problem... Can't seem to make passwords masked, enabling the 'invisible char' from glade still shows them as plain text, as does the guide here http://gtk.php.net/m...lloadvanced.php

Anyone got any ideas of how to fix this ?

[AJerman]

n_K, on 13 September 2012 - 12:10, said:

Agreed!

Why bother with dpkg and rpm support? They offer nothing except pointless baggage from a very outdated model, Arch has the AUR which and PKGBUILDs which are far superior. If you can think of any reasons why rpm or dpkg would actually be of any benefit please do tell me.

Anyway I reckon things we need to get working right now are:
-> Base ISO that will boot a GNOME3 GUI and load the required X11 drivers (intel/nvidia/ati) via a simple lspci script, or if that fails present a menu in CLI? (And have the option of force-showing the menu using a boot command line)
-> Basic looking non-functioning installers in PHP-GTK, PY-GTK and C# to compare them
-> Get Shift2 images onto the bootup ISO and change the version/name strings to say Shift2

Well, as I said, a lot of software is distributed in binary form in RPM or DEB form. Granted there are repos for most of what you'd need with AUR, but how would it hurt to be compatible with almost all packages so people don't have to worry about what format they download the binary installer in, or don't have to compile something from source because there is no package built for AUR. To me that's really the only "disadvantage" to Arch, even if it's package manager is considered better.

[n_K]

Alright sorted the problem!
Turns out the example (which was commented out);
$txtPassword->set_invisible_char('*');

only sets the character, you needed to search the wiki page for this;
$txtPassword->set_visibility(false);

And the reason it's not a great idea to include dpkg and rpm support is because they're dysfunctional with arch, inside arch PKGs you've got various files that tell pacman where to place files, what files to update or ignore if they've been modified by the user, how to know what file is owned by what package.
dpkg and rpm contain none of that information, if you install one of them and then decide you don't want the package, great, just remove it and be lumbered with hundreds of random files scattered all over the place, and if there's any in places like /usr/src and there's a big change with the folders and how arch uses them, you won't be able to update because you'll have a bunch of orphaned files that pacman can't find a package for and refuse to update packages because of problems with files being where they shouldn't be.