Nowadays, releases seem to be few and far between. Is this slowing down caused by lack of resources, lack of developers interest, or simply, lack of developers?
Actually, the answer is "none of the above". When Barry was at helm, Puppy was in its growing phase. A lot of ideas were tried and dropped, new tools were added (and later dropped), etc. It was also in flux. Nowadays, Puppy is more mature and less tinkering is needed, so you don't see releases that often.
Another reason is, there were complaints when releases were made too often. A personal Puppy installation took time and effort to customise, and to start over again after just 3 or 4 weeks was too much for many.
To balance all this, the implicit agreement is that Puppy releases are now made once every 6 months, give or take.
And lastly - there are actually point releases (or bug fix releases). You probably are not aware of them because they are not announced in Barry's blog; or they are not announced as a separate thread in the forum - they are posted in the same thread that announced the original release, but those posts quickly get drowned by other forum traffic.
And that's what this blog is supposed to do - the author of the Puppy can announce his or her own release here, with links back to the forum for discussion. In a way, this blog is to play the same role that Barry's blog played in the past (now that his blog covers a wider range of topics).
Posted on 22 May 2016, 00:38 by darkcity
Posted on 26 Mar 2016, 11:36 by 01micko
Sure would have been a tough invitation to pass up, eh?
Seriously, thanks for accepting!
While pMusic 2 basically put more flesh to the bone, the 3. generation shipped the homemade internal dynamic db. That was very ambitious - maybe too ambitious. So the arguing flamed up again. Cpu-usage was now reduced to the half, but the db had become active and working on its own grabbing music information while playing. New valid arguments had come to the battle...
pMusic 4 focused on all the goodies Thunor gave us with his outstanding work on Gtkdialog. With all kinds of new features the dynamic db became even more active, and it showed its bottlenecks and weaknesses. - The criticism to it was still fair. The last year of pMusic 4, most effort went to stabilize the db-usage. It has become clearer to me why Amarok, Clementine and friend use an external db like Mysql or Mariadb. But when focus is on size and dependencies, that was never an option.
pMusic 4 became stable, but of course for a price. Introducing routines for queuing db pulls and continuously checking db status slowed down the general usage of the audioplayer. If it should fit the mantra of Puppy, it should work snappy also on older pc's. As mentioned, pMusic-code has been written since 2008, and I have learned some bits and pieces since then. There had to be a potential benefit of rewriting the code. The result is seen in pMusic 5, and the benefit is above my expectations. It seems that much of the stability from version 4.7.4 has survived, and it has become noticeable faster. - That means a lot faster. The cpu-usage has decreased, but more important, many functions are much more responsive. An overall snappier user-experience.
No comments posted yet.
At first I had considered Jekyll, which runs nicely at Github (see puppylinux.com) but the problem with that is that each post is subject to a "pull request". Nothing wrong with that except I want to trust the posters here and don't want to have to bother with moderating everything. (And there hasn't been great enthusiasm to post a page, edit some content or even proofread over at puppylinux.com). As it is I have to approve every poster and commenter but that is all. Once registered here you have free rein.
I also considered a couple of other options, including FlatPress, a php based platform which stores its database in flat files, similar to pplog and derivatives. However, I thought why not go with this? It's clean, simple yet elegant and with sc0ttman's enhancements quite modern. It was quite a bit of work though to add the multi-user functionality and make sure it was locked down.
Of course there are other big platforms like WordPress, Drupal and friends but they are big and cumbersome, require an sql database and more often than not are an enormous amount of work to customise and maintain. With WordPress, yes there are tons of themes and add ons but this creates more headaches. Whose code do you trust? Why can't I get such and such theme looking right? Drupal is the opposite in that there aren't all that many themes available and they are big work to customise.
I have forked the code for this blog as sjpplog_ng on GitHub. As many will know it is written in the perl scripting language which has a large presence in the open source community. Most web servers have perl already installed. If you are a perl coder, or even a dabbler (like me) then feel free to fork the project and offer your code. The original licence is GPLv3 so we have to stick with that.
It has been a long month of web developing getting the main puppy site transferred over to me and developing a nice site (many thanks of course to jamesb, mavrothal and BarryK) and now this blog which is the place for the latest in Puppy Linux news. Now back to real development!
Is there anything more Puppy than pplog?
No comments posted yet.
Fido has been a poor neglected pup.
For many years people have wondered why we use the root account for just about everything. After several complaints, Barry eventually created the fido account that served as the default non-root 'user' to appease those not comfortable with running as root. Much of this was based on Pizzasgood's work in Puppy 4.2.1. Unfortunately, fido hasn't received much love since then and has deteriorated in to an emaciated wreck.
I have decided to do some work on the fido account (rather than put him down) and the first thing I did was create a 'home' dir for fido in /home/fido so there will be no more conflicts with /root. Of course it didn't work too well. I got to a desktop fine, everything on the hardware side working, browsing, text editing worked but no terminal! urxvt, our default virtual terminal application just would not run, so out came the google foo. Turns out that permissions in /dev/ were scewed up, a lot of them; some ownerships too. Of course there will be a lot of other bugs that I didn't investigate but this one was huge, and probably the worst.
Anyway, I think I now have it sorted and will offer a package for testing in a pfix=ram environment soon.
You can follow development in this thread on the forum.
NB: The last poster there before my post of today was by Nooby, our lovable perpetual 'noob'. RIP Nooby.
No comments posted yet.