Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 23 Jul 2014, 22:26
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Community Edition anyone interested?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 38 of 42 [621 Posts]   Goto page: Previous 1, 2, 3, ..., 36, 37, 38, 39, 40, 41, 42 Next
Author Message
ttuuxxx


Joined: 05 May 2007
Posts: 10747
Location: Ontario Canada,Sydney Australia

PostPosted: Sat 14 Dec 2013, 08:53    Post subject: Re: Puppy needs attractiveness to those who have other OSes  

gcmartin wrote:
On the subject of Puppy CE to attract Windows users, see this thread.

New membership can indeed find comfort in this community. .... with a little help and thoughtfulness from us.

I hope we can address ease of understanding and a robust starting package to exploit the RAM in more than 99% of all PCs ever manufactured since 1995. A 2nd approach could be to focus on a robust 64bit CE distro.

The 64 bit is an real world idea, but people tend to come to puppy for speed for older kits, Plus we don't have much, if any 64 bit apps compiled on a server, so it would be like starting from scratch unless we base it on a well known 64 bit distro, which will bring a lot of bloat in our backend. I'm in any which way it goes, but I do have a preference for keeping older pc's up and going. There's a lot of 3rd world countries that use puppy daily. but 64 bit also should have a solid place in puppy
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile

Back to top
View user's profile Send private message Visit poster's website 
darry1966

Joined: 26 Feb 2012
Posts: 364
Location: New Zealand

PostPosted: Sat 14 Dec 2013, 09:12    Post subject:  

I believe Fatdog caters for 64bit and Lighthouse.
Back to top
View user's profile Send private message 
ttuuxxx


Joined: 05 May 2007
Posts: 10747
Location: Ontario Canada,Sydney Australia

PostPosted: Sat 14 Dec 2013, 09:25    Post subject:  

darry1966 wrote:
I believe Fatdog caters for 64bit and Lighthouse.

yes he does and has done a great job with that, but we are talking hundreds of custom compiled apps.
It wouldn't be based on his version, a complete different backend. Sure some might work, some might have errors, it would make the Ce a unstable version if we went down that route to recycle his apps.
Its always best to compile with the glibc, gtk, x-server being used to keep things stable.
Jeff

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile

Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4277

PostPosted: Sun 15 Dec 2013, 15:13    Post subject:  

ttuuxxx wrote:
Its always best to compile with the glibc, gtk, x-server being used to keep things stable.
Unless you are building a multi-distro package. You should build against the oldest supported versions with the implied social contract that newer versions are not supposed to break things compiled against older versions (though someone needs to inform the gtk folks).

This BS is why we can't run Chrome on some pups, why people using Redhat, CentOS and Debian can't run Dart... google just doesn't get it and seem to be perpetuating their flawed logic. Don't be a victim.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sun 15 Dec 2013, 16:28    Post subject:  

technosaurus wrote:
ttuuxxx wrote:
Its always best to compile with the glibc, gtk, x-server being used to keep things stable.
Unless you are building a multi-distro package. You should build against the oldest supported versions with the implied social contract that newer versions are not supposed to break things compiled against older versions (though someone needs to inform the gtk folks).

Right, programs that use new features won't work correctly..same as with any software development. I just added a feature onto an android app, and was informed that older versions won't support it. Many of us used gtkdialog features not available in older versions...which is why we asked for them.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4277

PostPosted: Sun 15 Dec 2013, 17:06    Post subject:  

Its one thing if a newer version is _required_ due to new features. This is not the case for many precompiled proprietary apps that the only reason they don't run is a stupid glibc version string crammed in because they built against a new glibc. Many apps have fallbacks for compiling against older versions (see abiword, geany, yad source) that will still work on new versions. This is especially valid for gtk where they often add new functions that are pretty damn redundant.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sun 15 Dec 2013, 17:36    Post subject:  

technosaurus wrote:
This is especially valid for gtk where they often add new functions that are pretty damn redundant.


Many useful features were added to gtk that make a world of difference for providing a user friendly interface. There are still a lot of limitations where work-arounds are required. Again, languages are always evolving. In android, there is also a lot of deprecated code that simply doesn't work any longer. There's a point where you draw a line regarding backward support. The only function for an OS is to support applications. You can always stick with old applications for an old distro that runs on old hardware.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4277

PostPosted: Sun 15 Dec 2013, 18:11    Post subject:  

I don't want to get too off topic, but from personal examination of all versions of gtk from 1.2 to 3.10, I can say quite matter-of-factly that over the years, while gtk has added many new features, most of the new functions added were simply an old function renamed with extremely minor changes and typically deprecating the old function. In 2.8 they added cairo, in 2.10 they added statusicon (and many others), in 2.12 they added gtkbuilder, but since then not much _real_ improvement, gtk3 still hasn't gotten most of the real improvements that were planned (the cairo only backend for instance that would have allowed asyncronous apps via cairo-xcb ... or the xcb backend for that matter) ... the only real reason to build gtk3 is the broadway or wayland backends and honestly its just as fast to just use a vnc client on a gtk2 build. (though gtk3's javascript bindings and css styling vs. gtkrc are not bad ideas, I don't personally find them useful)
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
cthisbear

Joined: 29 Jan 2006
Posts: 3386
Location: Sydney Australia

PostPosted: Sun 15 Dec 2013, 19:00    Post subject:  

From uncle Barry.

" Yes, there is a reason for not using GTK 2.24.x.
It has some rendering changes that make some apps misbehave.
I think that the developers were moving up to the 3.x series, and some
stuff went into 2.24 that perhaps shouldn't have.

I have found that the vast majority of apps still compile with 2.20.1. "

http://distro.ibiblio.org/quirky/quirky6/x86/quirky-6.0/release-Quirky-6.0.htm

Chris.
Back to top
View user's profile Send private message 
gcmartin

Joined: 14 Oct 2005
Posts: 4075
Location: Earth

PostPosted: Sun 15 Dec 2013, 21:43    Post subject:  

Even though we seem to diverge for the moment, its probably a good thing if we are looking to the future. The Linux distros in or out of Puppyland will continue to dominate the desktop/laptop usage. It may even move, with touch, to the smart device (tablet/tabletop) scene.

So with this as an understand tucked away in the back of our minds, its a right thing to do to cover this area as it has tremendous benefit or locked-in drawback down the road. That's why I thing member developers are covering this. It is an important area of the system. As in the auto ownership when a issue arises: "Pay me now or pay me later, but you WILL pay!"

That being said is GTK here because it is a PUP standard or because it was/is easier to create and support screen manipulation for apps. If its not a standard, are there any other approaches that can be brought to bear that DOES NOT can a massive rewrite of application. IBM has use a technique in some of its development of apps where it can take an application written for one type of desktop and have the app run thinking its using one version, when in fact, the subsystem in completely different as it populates to screen. But, that is/was an internal tool and there may not be an equivalent for this community's use.

That being said, I found this write-up which, i think, clearly explains what the GTK discussion is about while OFFERING insight to another that is seen in other PUPPY distros. Those unaware of the GTK discussion may appreciate the short article's info.

Questions
  • Is the write-up accurate?
  • And is there additional issues, some of which has been written over last day, that the article doesn't make clear?
Thanks, in advance, for any clarity on this, as the CE planning moves forward.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4277

PostPosted: Sun 15 Dec 2013, 21:57    Post subject:  

@gc
that article barely touches the architecture behind the toolkits

re: the ibm infrastructure ... as part of backporting gtkdialog to gtk1 many gtk2 functions were mapped to gtk1... it is entirely possible to write gtk2 and glib2 to link to and use gtk1 with additional widgets and functions defined in terms of their gtk1 counterparts ... the same goes for gtk3 ... but since these are lgpl you probably will never see it. I have considered writing an MIT licensed gtk wrapper over agar, so that gtk apps can build against libagar.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Mon 16 Dec 2013, 04:46    Post subject:  

technosaurus wrote:
I have considered writing an MIT licensed gtk wrapper over agar, so that gtk apps can build against libagar.

Lots of choices. Moving a community is another matter. Generally it's best to stay with the familiar.
Back to top
View user's profile Send private message 
nubc


Joined: 23 Jan 2007
Posts: 994
Location: USA

PostPosted: Mon 16 Dec 2013, 11:38    Post subject:  

Do something different, like create/maintain a rolling release. (Who needs another Puppy variation?) Pre-configure VLC as default media player, as in "VLC Plus Extras" by Ttuuxxx. Need I point out that a rolling release Puppy would attract new users, since it would address a major drawback of Puppy, rapid obsolescence.

Point release vs. rolling release: Developer, user, and security considerations
http://www.techrepublic.com/blog/it-security/point-release-vs-rolling-release-developer-user-and-security-considerations/

Last edited by nubc on Mon 23 Dec 2013, 02:28; edited 2 times in total
Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 764
Location: Union New Jersey USA

PostPosted: Sat 21 Dec 2013, 21:07    Post subject: Where do we go from here?  

Let's look on the bright side. Problems with glibc's and gtk's are currently rare, and may shortly become a thing of the past.
Currently rare because:
Most puppy users won't “customize” further than installing a pet via PPM or Quick-pet or down-load SFS via SFS-downloader.
Pets neither included by a Dev, nor mentioned in the thread of a Pup as being compiled in that Pup, have their own thread --or won't be found-- in which the compiler/builder usually identifies in which Pup they were compiled and in which Pups tested and working.
Loaded SFSes which don't run are unloaded, and the user moves on.
If a user tries running an app via Program Folder, it will work or the folder deleted and the user moves on.
And for the most part, the potential for conflict only exists in the T2 branch (quirky, wary, racy, saluki, Carolina) which, if no one is using T2SDE to create new binaries, will go extinct.

If all that we are using woof for is to build a Pup from the binaries of some other distro, we can stop worrying about compiling glibc's and gtk's recognizable by kernels or not in conflict, and smugly take the attitude “It ain't my job”. And if some curious user asks us about a problem, we can pass the buck: “The devs at so-and-so screwed up.”
Of course, what interest Puppy Linux would still hold for the likes of technosaurus, amigo, goingnuts, and others of our most accomplished-least-heralded Devs, I don't know.

If you are satisfied with that state of affairs, you can skip the rest of this post.

Conflicts between --and the failure of a kernel to recognize-- glibc's and gtk's are a unfortunate bi-product of the “merge-file-system” by which frugally installed Puppies achieve their expandability. Those who run Puppies as Full Installs have no more right to complain about “conflicts” than would a Ubuntu 12 user who installed a Slackware 11 app. A seminal vaudeville routine which runs:

Smith: Doctor, it hurts when I do this.
Dale: Don't do that.

That it is a “merged-file-system” problem is best illustrated by an old Pup Aitch reminded me of as I read my way thru the original pUPnGo thread. Its name was Underdog. In Underdog the user was able to link to a full install of any distribution on Underdog's home partition and run the applications of that other distribution. That raised a number of interesting questions. If you haven't noticed, I'm better at asking questions than answering them.

My understanding is that the T2 branch can't run Chrome & Clones because their kernels were not compiled to support the glibc's required by those applications and/or the glibc's used by those applications were not compiled against the kernels used by those Pups.
In theory, an SFS or a Program Folder --if a static build and if it contains all the libs and links it will use-- should run under any kernel against which such libs were compiled. Are Chrome & Clones self-contained? Specifically, are they statically built containing the necessary glibcs or are they built expecting those glibs to be found on the system? See below for a partial answer.

If it is a glbc-kernel problem, do we have any volunteers who will attempt recompilations?
Do we have any volunteers who will attempt to woof a Pup at least in part from the binaries Barry K recently build for quirky 5.99 and 6, together the compilation of necessary glibc's against the 3.12.2 kernel compiled for those quirkys?

Alternatively, Saluki & Carolina's custom-builder includes a routine for changing the kernel provided the desired kernel exists as a pet. Among the quirky5.99 & 6 packages Barry K built are several linux-kernel pets in the 3 Series, http://distro.ibiblio.org/quirky/quirky6/x86/packages/pet_packages-quirky6/ (3.6 & 3.12). Geoffrey pointed out glibc-2.17 is available for compilation. Exactly how does Saluki-Carolina's kernel substitution routine work? Knowing that could make it easier than woofing from “scratch” to test the various T2 binaries Barry K built to determine if some combination provides a satisfactory kernel-glibc-2.17 combination.

PUPnGo uses a “base-system” consisting of a stripped (then modified) Pup 4.12 to which you then load an SFS based on a different “distro”. Among the SFSes by which goingnuts was able to extend pUPnGo via such SFS extensions were TinyCore, BasicLinux, xwoaf, and Snowpuppy (Lucid 5.11 variant). Although goingnuts refers to pUPnGO's acquisition of such SFSes as “loading,” it employs a different mechanism/script from that provided by BootManager or SFS-load(-on-the-fly). Is it sufficiently different, or is the way goingnut packaged the SFSes sufficiently different, that glibc-kernel problems are avoided?
[By the way, when asked how to compile applications using pUPnGo, goingnuts explained, you don't. You compile applications in the distro used as the extending-SFS. Which, of course, would avoid glibc-kernel complications during the compiling process. I supposed pUPnGo theoretically could be used to compile applications for its base system. Or Pup 4.12. Note, however, someone else? (goingnuts?) posted a Youtube of a pUPnGo using Pup 4.31 as a base. http://www.youtube.com/watch?v=CVsIHuHy_rY. That suggest that, if we were sufficiently ambitious and it made sense to do so, we could utilize pUPnGO's technique to create a pUPnGO based on wary. Note, however, that a teaser screenshot of a Pup goingnuts is currently working on may be either that or employ wary as its SFS-extension.]

It appears that quirky 6 has a 3.12.2 kernel and glibc 2.17. http://murga-linux.com/puppy/viewtopic.php?p=743922#743922. Is it possible to "transfer" these to wary or racy?

Edit: Removed. My double-check something.

mikesLr

Last edited by mikeslr on Sun 22 Dec 2013, 14:06; edited 1 time in total
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 215

PostPosted: Sun 22 Dec 2013, 12:55    Post subject:  

why not start looking at pupngo as a base for ce
i feel it has a lot of potential

1. it is an advance on the puppy system but could still retain all of puppy's strengths.
2. it could be made glibc gtk etc neutral (static built core and basic apps)
3. it is modular so different versions for different needs could be made concurrently by different teams (even members with limited knowledge can work on or test the modules)
4. etc

i am trying to read the pupngo thread and test things because i want to incorporate some of the ideas into my stuff but as i said i feel it is an excellent candidate for the ce base

also the ce project can (and probably should) take a while to mature i dont see any rush

wanderer
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 38 of 42 [621 Posts]   Goto page: Previous 1, 2, 3, ..., 36, 37, 38, 39, 40, 41, 42 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1231s ][ Queries: 12 (0.0178s) ][ GZIP on ]