[Shift2] Dead?

[firey]

As i say once the basis GUI is done and it gets me to a desktop

I have tried countless times to get this working and cant

maybe i am just a complete dumbass

at first i thought it was my hardware but then i used archbang which is a Arch Live CD

i then tried to install gnome and borked it

Arch seems way too easy to break, i have even seen some of you guys leaving messages saying broken my arch VM need to redo it

Arch is pretty easy to get going once you have done it.

1) Setup DHCP/Internet

2) Setup HDDs

3) Install Base/Base Devel

4) Setup Files (Hostname, Hosts, Time (optional))

5) Make a user

6) Install your bootloader/configure

7) Reboot

8) Install X

9) Install Gnome

10) Install GDM

11) Install DBus and add it to daemons

12) Reboot

13) Login as root and run gdm (optionally add GDM to X Startup so that once you login GDM auto-boots). From there.. you have a nice gui (I then install cinnamon, and set it to auto load a cinnamon session on login).

[Haggis Veteran]

Thinking i am just going to install archbang

Its ARCH but with a DE, Openbox and Configuration done for you

although i did install it in a VM previously went to install gnome and broke it lmao

[Glassed Silver]

I'm one of the couple of guys who signed up to work on it and I must say I'm still interested.

I kind of lost the touch with the project when it got going so quick with so many threads going on...

I really think that we should have ONE central place to see an overview of all the discussion (even just links to forum postings etc etc)...

When I haven't been active on Neowin, came back and saw that so much talk had already been made without me (not blaming :p ^^) I was surprised people had gone ahead so quickly, so I gave up for a moment, because catching up was hard to do with all that stuff going on in my offline life.

After then I slacked and now I noticed myself the project is somehow a little sleepy. :D

I'm willing to contribute as graphics designer and photographer again, I somehow wish that catching up would be easier, because there will constantly be people who are stressed out in real life and have to slack a bit.

Re-entering the project should be simpler.

Maybe that's just me.

Glassed Silver:mac

[threesixtyflip]

Glad to see you took the time to think it over. Typical.

Wait wait wait.... What?

I havent even said anything yet, if you must know im looking at Ubuntu on my test machine atm anyway, in fact I'm writing this very post on it. All I was doing was agreeing on some of the benefits of Arch.

At the end of the day, regardless of decisions, this is an open source project. If you dont like something, the best thing about it is that you can change it to how you want.

Glassed Silver, it would be nice to have you back with us again, and again I must apologise for letting things get out of hand.

What I do need help is, is with organising things. As you can probably tell Im not the best at organising things and have bursts of threads, which I can see to some people may not be the easiest way to keep up with things. Would a single thread make things any easier though?

[Nothing Here]

.At the end of the day n_K you are right, if anyone wants to make a basic installer and submit it so we can call all go over it then that is great.

This is the comment that made me say that. n_k is probably the only person who can make the installer and if he leaves, then that breaks us. I'd rather see Shift2 make it, then have n_k leave and break it. n_k will only work on Shift2 if it's Arch based. I will only work on it if it's Fedora or Debian based. But in the end, you need people who actually know how to code, not someone who doesn't.

[Brian M. Veteran]

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]

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.

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. Veteran]

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.

[threesixtyflip]

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.

[threesixtyflip]

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]

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

[threesixtyflip]

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) :p

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

[Haggis Veteran]

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

[threesixtyflip]

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) :p

[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 :p

[Haggis Veteran]

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/manual/en/tutorials.helloadvanced.php

Anyone got any ideas of how to fix this ? :(

[AJerman]

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.

[AJerman]

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.

Okay, that's what I was curious about. If they ran properly and didn't break the system. If it's going to break things, then it's not worth it.

[Haggis Veteran]

n_K

cant wait to test out your GUI Installer

how far are you with it so far?

[n_K]

I'm just (attempting to) designing the interface in glade at the moment in-between crashes, then it'll be a case of getting the buttons and whatnot hooked up to PHP.

Although I'm not all that sure about how to the partitioning in a GUI :s was thinking maybe a listview and click to add partitions (or automatic partitioning), let me grab some snaps of what it's looking like now;

[Haggis Veteran]

looks awesome

i been playing with glade it confuses me lol

think i am just used to vb forms

[n_K]

Yeah it's a bit of a pain in the arse that you have to have everything fill up a box and use 'fixed space' boxes to make everything the same size.

I just found out how to make the buttons the same size, put them in a 1x1 box and set the height to 20, disable vertical stretching and filling but enable shrinkage :s