BionicDog (updated: 2018-06-04)

[wiak]

Hi Fred,

In converting cast2chrome to use gtkwialog and for use with bash, dash, or ash system shells, I discovered it has a serious bug. Would you kindly remove it from the repositories until I release version 0.0.3 in which I will fix my error.

Thanks in advance,

wiak

Cast2chrome version 0.0.3 now released, which fixes the issue. Compiled on XenialDog - works also on Bionic.

It's my first gtkwialog dependent app, which will run on top of dash, or ash, or bash systems.

http://www.murga-linux.com/puppy/viewto ... 012#991012

Depends on gtkwialog of course (running in -b mode).

wiak

[fredx181]

Hi wiak,

Thanks. Added Cast2chrome version 0.0.3 now to repos and removed v0.0.2 (as I think you'd prefer)
Hey ! First gtkwialog based program

BTW, I switch frequently from sh > bash to sh > dash (and back) to test things (like pfind just recently)
When I was updating the repositories just now I was surprised that it went much faster than I'm used to, and asked myself why, and noticed the sh > dash symlink (I didn't realize it was at that moment)
EDIT: To clarify, the speed has nothing to do with internet speed, just the process before uploading the files to github went faster (scanning the packages and creating packages list etc..)
So, what I'm saying is that this was sort of a blind test that proves for me that sh > dash would be a real improvement in speed (in at least some cases).

Fred

[fredx181]

*** New BionicDog release: 2018-06-04 ***

Changes:

- Two different ISO's available now, one with all firmware included (e.g. for WiFi, 2018-06-04-firmware_all) and one without.
(but still kept download link for the separate firmware squashfs at first post)
- Booting with encrypted savefile works now (bugfix, previously didn't work)
- Kernel upgrade to latest 4.15.0-22-generic
- Upgraded all packages (apt-get upgrade)
- Other small changes, e.g. added "sound-card-selector", modified tint2 bottom panel (volume setting)

Info and download links at first post updated.

Fred

[heckthefeck]

thanks a lot!


I use bionic dog since yesterday, when I saw your post, and lxpuppy would not install. It would boot though, but installing some file would miss, so I thought: why not give your post a try! I am very happy!

[wiak]

New version 9.0.5 of Precord released. Same functionality as previous version but Precord now uses gtkwialog [-b] and hence works with system shell dash, or ash, or bash.

Find deb package here:

http://www.murga-linux.com/puppy/viewto ... 446#370446

Please remember to remove your old $HOME/.precord folder before first use.

wiak

[fredx181]

thanks a lot!


I use bionic dog since yesterday, when I saw your post, and lxpuppy would not install. It would boot though, but installing some file would miss, so I thought: why not give your post a try! I am very happy!

@heckthefeck, that's good to hear, thanks and welcome to the forum !

@wiak, thanks, will upload new Precord to repos soon.

Fred

[irishrm]

I am making good progress setting up bionic dog on my main computer.
I have one problem I would like to solve.

This computer has a broadcom wl wifi driver. I installed this package which includes my driver but don't know how to activate it.

dkms source for the Broadcom STA Wireless driver

Broadcom STA is a binary-only device driver to support the following IEEE
802.11a/b/g/n wireless network cards: BCM4311-, BCM4312-, BCM4313-,
BCM4321-, BCM4322-, BCM43142-, BCM43224-, BCM43225-, BCM43227-, BCM43228-,
BCM4331-, BCM4360-, and BCM4352-based hardware.d

This may be a long shot and not essential. I am using a USB dongle at the moment, which is working fine.

Any help would be appreciated.

irishrm.

[rcrsn51]

@irishrm: Before messing with the wl driver, you should see if an in-kernel driver like b43 may work. However, it needs firmware.

Code: Select all

apt-get update
apt-get install firmware-b43-installer

Reboot.

[anikin]

rcrsn51,

A quick question regarding peasyglue - are you planning to release a new, dash compatible version?

Thank you in advance.

[rcrsn51]

PeasyGlue contains some other bashisms in addition to the "export -f" issue. I am not much interested in this conversion project.

But you can contact wiak and see what he is doing.

[anikin]

If he makes changes to peasyglue - no objections on your part?

[irishrm]

Thanks rcrsn51 for the reply.
I did as you suggested and got the message that wlan0 was not active.
As I said I can manage fine without it so there is no need to waste your time on it if it presents any difficulty.
Thanks again.
irishrm.

[ITSMERSH]

Hi.

A fellow musician and a friend of mine made a nice gift to me - his old Samsung N150 Netbook.

I made several tests of different Puppy Linux Systems to check how and if they would work.

A first test was made using my LazY Puppy Art Studio based on Tahr 6.0.2, but this has used full capacity of both two cores of the processor, so not usable.

I went back to the earliest Puppy I got locally existing which is my original LazY Puppy based on Lucid Puppy. Everything went fine. Appr. 3% of capacity of both two cores of the processor.

My next try was L.A.S.S.I.E. a Precise based Puppy, which returned to use appr. 60% of capacity of both two cores of the processor.

To my absolutely surprise, BionicDog returned very well running on this Netbook. Currently playing music with Gnome MPlayer at 19% to 21% of capacity of both two cores of the processor.

Pretty good, well done that BionicDog!

[wiak]

PeasyGlue contains some other bashisms in addition to the "export -f" issue. I am not much interested in this conversion project.

But you can contact wiak and see what he is doing.

I wouldn't release any conversions without your explicit permission, Bill. I wouldn't like people messing with my own programs without a good reason either. But if you are happy for me to convert peasyglue for anikin and others who would like to run it (or possible others of your fine utilities) on dash-based systems I'd be fine with doing that for any of your programs - I am quite in practice at doing these conversions now, so wouldn't be a burden. Of course I cannot guarantee any of my work - I could mess up and users would have to accept that limitation in any conversions I ever do. However, doesn't matter either way - and I respect your own interests and rights to your own works either way. I'm more interested in my own programs being dash-compatible and for new util/apps I write (if any).

EDIT: at least a few of us would like to be able to run DebianDogs with dash as the shell, as an efficiency/speed/Debian-compatability measure, without losing lots of functionality. That's the only reason gtkwialog was created and to allow new apps to be written that will be compatible on Debian-based dash systems. That's really the only interest I have in the project myself. But I can easily do conversions for my own system anyway. Main problem for me is zigbert's Pburn - that's a big and very useful program(!) but a big job to ever make compatible with dash...

wiak

[rcrsn51]

I have given this some thought and decided the following: the most fail-safe way to run a gtkdialog app in a non-bash environment is to entirely remove the bashisms, not create an alternate method of running those bashisms.

To that end, I am posting a non-bash version of PeasyGlue for anikin to test.

[wiak]

I have given this some thought and decided the following: the most fail-safe way to run a gtkdialog app in a non-bash environment is to entirely remove the bashisms, not create an alternate method of running those bashisms.

No problem, anything you want to do with your own apps is fine and of no concern to me.

However i find your statement both entirely misleading to others (to the point of being false) and an attack on my work with gtkwialog. Bash was designed as a more powerful programmer's shell and it is no less safe to use than a simpler, less full-featured, shell such as original /bin/sh. As a longtime C programmer, in a professional capacity, I am well aware of what is 'safe' or not.

Your choice of wording (particulary the use of the term 'bashisms') imply that using gtkwialog via bash is somehow inherently less safe than using a program written in a simpler shell language - that is patently untrue.

"Bashisms" simply mean code written using the more powerful features of bash, which in no way makes a program prone to failure whether the shell used by the main system is some other shell or not - the problem was that legacy gtkdialog inflexibly forces commands to use /bin/sh, which certainly rendered its bash driven code failure prone. Gtkwialog, on the other hand, has no such restriction and can be safely used with bash scripts (including the powerful extended features bash offers the programmer) - no matter what the system shell is.

Obviously a poor programmer could render a program useless if they used bash code along with gtkwialog and then ran it through /bin/sh, but that is just poor coding and another matter altogether.

The term 'bashism' was simply invented to warn against writing a system script in bash if the user wanted to run that code via /bin/sh. Writing a user application, rather than a system script, could be done in any level of programming language be it bash, C, python, lua, whatever - none of these are more failure prone than ash or dash. Bashism isn't a religion either, despite the way some people use the word so misleadingly. Of course you can't run a bash program using ash or dash as the interpreter; gtkwialog doesn't force that situation on anyone.

EDIT:
I am very disappointed in your negative attitude, in which you purposively rewrite one program to discourage simple conversion of all, but that attitude can at least be disregarded. Your programs are easily, simply, and quickly converted to run perfectly well with gtkwialog as it happens, with perfect safety in the result - no re-write to Posix ever was necessary at all; but do what you like - some of us don't have time to rewrite programs with less powerful shell language. Nothing wrong with writing new programs using ash or dash or bash for that matter (or converting to Posix if so desired) - depends how much functionality a programmer wants from the coding language they use. Totally rubbish to suggest bash (or bash with gtkwialog) is somehow unsafe though. Comments like yours simply amount to conservative jealously against development progress you clearly see as a threat to yourself, which is a shame to others in the community who have to suffer as a result of such code-protectionism. This is open-source code so yes of course your code and mine and everyone elses could be forked if not satisfying some need. Having said that, I have no personal interest in your code - aside from Peasywifi, which works well for me in practice - but it is not essential to me either.

wiak

[fredx181]

Just thinking (but maybe it's me because my base language is not english) there's a difference in "fail-safe", maybe meant by rcrsn51 as "converting to using gtkwialog" can cause unexpected bugs and "safe" in the sense of "secure" (how wiak seems to interpret it)
Just my 2 cents.

Fred

[wiak]

gtkwialog appropriately written with bash is every bit as 'fail-safe' as gtkdialog appropriately written with simpler shell language. The comment to the contrary was entirely misleading, which is intolerable to me, being thus little more than a thinly-veiled attack on my development effort. If he wants to waste his time re-writing simple programs that are particularly easy to 'safely' convert, that's up to him of course. Re-writing a program of any complexity, is far more likely to introduce bugs; though some programs are easier to convert than others - but that is a different matter entirely.

William

[stemsee]

Concerning Wifi-TrayNet and Wifi-Scanner the previous post, as you would know by now, was buggy as hell on BionicDog, but not on Bionic puppy or fatdog. While gathering info for the deps I noticed that dhcpcd is not available only dhcpcd5, I then reworked the script to function with dhcpcd5 which differs somewhat from dhcpcd. Also the ifconfig and iwconfig results differ significantly from the other derivatives I use. The result is this rewritten version ... I wonder if Rcrsn51 went through similar for peasywifi on BD. Peasywifi uses dhcpcd (previously I though it was udhcpc), according to its properties, and states that dhcpcd5 is incompatible, so when Wifi-TrayNet (actually dhcpcd5) gets installed Peasywifi gets removed and vice versa. Which means there is NO conflict! I didn't realize that would be the result of using dhcpcd5. But apart from that small thing, if they were installed on the same system, I could only see autocon (peasy in /root/Startup and /home/puppy/Startup (still there after apt-get un-installed it ... auotcon for TrayNet is in /etc/xdg/Startup or if that does not exist then /root/Startup ($HOME/Startup actually). Whereas on occasion they both use wpa_supplicant.conf in tmp, TrayNet now creates all tmp files and pipes in /tmp/Wifi-TrayNet and likewise does scanner in /tmp/Wifi-Scanner, thus removing any potential interference. Add to that the fact that either app can select alternative interfaces to work on, there is even less chance of interference. Perhaps the one directory were interference may occur could be /var/tmp . Config files for peasy are in /etc/pwf while TrayNet and Scanner use /root/.wifi-connect/{profiles, geometry, static}(actually $HOME/.wifi-connect ... preserving multi-user, I think). The coding is very different I have my own , verbose un-tutored style, and I like a plethora of exotic features. So my flavour of app is not for everyone! But it is working if you want to try!

[rcrsn51]

Peasywifi uses dhcpcd (previously I though it was udhcpc)

I started using busybox udhcpc in Puppy PeasyWifi in 2016.

That version was ported to the Dogs last year and continues as such.