Invisible beta (or, a 'bug' in many versions of puppy)
Posted: Fri 17 Nov 2006, 10:38
the following may make barryk think i'm a complete jerk... (in fact, there's always the possibility that i am) but, he should know (as i'm saying it right now) that puppy is in my opinion, the best linux, ever. others may have their own favorites, they may even have allegedly better reasons than i do, but puppy is mine.
it goes without saying that barryk can do whatever he wants to with puppy, he's BDFL, he does a fantastic job with his own distro, and indeed, if he changed nothing there would still be options. still, i thought i'd say what i'm about to, and i'm not the only one that's said it, so i'll try to say it for them too (and let them remain nameless)
so, eh? "invisible beta." (i admit i just made it up.) this is when something goes through a beta stage that is imperceptible in some way, in this case, because it happens so fast you could easily miss it. regardless of how many people are actively beta testing, usually a beta stage lasts long enough for people to hear about it.
not always the case with puppy. in what's becoming a tradition of sorts, puppy 2.12 beta2 is going through a Three-Day beta stage.
i mentioned in the irc channel, that it would be really excellent to focus on just two things, and get them working above reproach if can be: wireless support and disc-at-once writing, or at least "track-at-once" writing that burns iso's reliably across different systems. "across different systems?" this is one thing that a non-invisible beta lets you know more about, although it's good that we have many testers. it's a pity they only get three days to work it out. hopefully a weekend was chosen- (i didn't check on that, but it is now friday.)
another thing that a non-invisible beta allows is time to really fix what bugs you've found. having seen some of barryk's work, i suppose it's actually possible that he can fix all the bugs he finds in such a short period of time. still, it doesn't allow for beta testers to test those bug-fixes before the next release, being "final." at least it's "beta2" and not just "beta..."
but what can be done about this? for one, you could try to persuade the lead developer. geniuses (we probably can't argue that point, and i wouldn't) are often temperamental and stubborn, and this avenue might be pointless to explore. he will ultimately do this the way he wants to, and certainly, what comes out of doing it his way is really incredible. i almost can't imagine using another linux, despite puppy not being the only good one.
another thing that can be done is to simply slow down our upgrading on the user end. this is not to sway anyone, but it's what i do and some others do, for ourselves. i don't upgrade unless i have a few specific reasons to. among my reasons for exploring 2.11 were my interest in puppybasic 2.5, and and that i had a machine that couldn't boot the (somewhat faster, not to be sneezed at) puppy 1.07, which i now dual boot but don't use very often. i was rewarded for upgrading by being able to add another machine to the "works with puppy" list. all my machines work with 2.11, all but one work with 1.07. 1.07 was much, much faster on my pentium with 64mb of ram. i'm told i can make a swap file (which 1.07 did not create or need on my machines.) still, there are older versions worth embracing long term, i believe- certainly for use on the lower-end pentiums.
(and a note to jady: please, please do not discard your wonderful 1.07+dos grub package when you create a more up to date version.)
when a version has been around for a while, we will then have a "virtual beta" stage where something has indeed been tested as much as you prefer. bugs aren't necessarily repaired following this stage, sadly, but i've found even windows98 is a lot more tolerable after you've had about a decade to find half the bugs and compensate for them. it's not an ideal model, but there must be some reason it's becoming more popular. we can hope.
as for another way to compensate, more than any other distro (okay, i just don't know any others that lend themselves to this, but that could be plain lack of experience) puppy lends itself to making a custom "distro" of your own. note the almost countless varieties that have come from puppy. in this sense, puppy is acting as a sort of "diy-kit" or seed for people making their own distros, and they can use it to make their own, at their own pace. "if you want a version that takes a while to be developed, make it yourself..."
that of course brings me to the official "ce" versions, which may not (if the community wishes) come out quite as often as the versions barryk puts out. personally, i will probably continue to just upgrade less often, and look to "ce" when the wand has truly been passed.
those of us that are a bit uneasy with the "3 day beta" model have plenty of options, and there's always the nominal chance that our hero of distro creators will calm down and release at a less hectic pace, even prior to moving on to another project (which no one really wants him to do.) i can relate to the desire to put the latest version up the minute it's compiled, i almost do that with my tiny collection of utilities. of course, i have never named one "final." i tend to call them all "beta" and in fact, "alpha" may even be a better term. like barryk, i'd rather play with the code and the program, than worry about the formalities of "blah, blah, blah." it's all understandable. i simply hope that "beta" will never become the better term for puppy, overall.
it goes without saying that barryk can do whatever he wants to with puppy, he's BDFL, he does a fantastic job with his own distro, and indeed, if he changed nothing there would still be options. still, i thought i'd say what i'm about to, and i'm not the only one that's said it, so i'll try to say it for them too (and let them remain nameless)
so, eh? "invisible beta." (i admit i just made it up.) this is when something goes through a beta stage that is imperceptible in some way, in this case, because it happens so fast you could easily miss it. regardless of how many people are actively beta testing, usually a beta stage lasts long enough for people to hear about it.
not always the case with puppy. in what's becoming a tradition of sorts, puppy 2.12 beta2 is going through a Three-Day beta stage.
i mentioned in the irc channel, that it would be really excellent to focus on just two things, and get them working above reproach if can be: wireless support and disc-at-once writing, or at least "track-at-once" writing that burns iso's reliably across different systems. "across different systems?" this is one thing that a non-invisible beta lets you know more about, although it's good that we have many testers. it's a pity they only get three days to work it out. hopefully a weekend was chosen- (i didn't check on that, but it is now friday.)
another thing that a non-invisible beta allows is time to really fix what bugs you've found. having seen some of barryk's work, i suppose it's actually possible that he can fix all the bugs he finds in such a short period of time. still, it doesn't allow for beta testers to test those bug-fixes before the next release, being "final." at least it's "beta2" and not just "beta..."
but what can be done about this? for one, you could try to persuade the lead developer. geniuses (we probably can't argue that point, and i wouldn't) are often temperamental and stubborn, and this avenue might be pointless to explore. he will ultimately do this the way he wants to, and certainly, what comes out of doing it his way is really incredible. i almost can't imagine using another linux, despite puppy not being the only good one.
another thing that can be done is to simply slow down our upgrading on the user end. this is not to sway anyone, but it's what i do and some others do, for ourselves. i don't upgrade unless i have a few specific reasons to. among my reasons for exploring 2.11 were my interest in puppybasic 2.5, and and that i had a machine that couldn't boot the (somewhat faster, not to be sneezed at) puppy 1.07, which i now dual boot but don't use very often. i was rewarded for upgrading by being able to add another machine to the "works with puppy" list. all my machines work with 2.11, all but one work with 1.07. 1.07 was much, much faster on my pentium with 64mb of ram. i'm told i can make a swap file (which 1.07 did not create or need on my machines.) still, there are older versions worth embracing long term, i believe- certainly for use on the lower-end pentiums.
(and a note to jady: please, please do not discard your wonderful 1.07+dos grub package when you create a more up to date version.)
when a version has been around for a while, we will then have a "virtual beta" stage where something has indeed been tested as much as you prefer. bugs aren't necessarily repaired following this stage, sadly, but i've found even windows98 is a lot more tolerable after you've had about a decade to find half the bugs and compensate for them. it's not an ideal model, but there must be some reason it's becoming more popular. we can hope.
as for another way to compensate, more than any other distro (okay, i just don't know any others that lend themselves to this, but that could be plain lack of experience) puppy lends itself to making a custom "distro" of your own. note the almost countless varieties that have come from puppy. in this sense, puppy is acting as a sort of "diy-kit" or seed for people making their own distros, and they can use it to make their own, at their own pace. "if you want a version that takes a while to be developed, make it yourself..."
that of course brings me to the official "ce" versions, which may not (if the community wishes) come out quite as often as the versions barryk puts out. personally, i will probably continue to just upgrade less often, and look to "ce" when the wand has truly been passed.
those of us that are a bit uneasy with the "3 day beta" model have plenty of options, and there's always the nominal chance that our hero of distro creators will calm down and release at a less hectic pace, even prior to moving on to another project (which no one really wants him to do.) i can relate to the desire to put the latest version up the minute it's compiled, i almost do that with my tiny collection of utilities. of course, i have never named one "final." i tend to call them all "beta" and in fact, "alpha" may even be a better term. like barryk, i'd rather play with the code and the program, than worry about the formalities of "blah, blah, blah." it's all understandable. i simply hope that "beta" will never become the better term for puppy, overall.