Wireless GUI: "Killer App" for FreeBSD?

[roddierod]

I'll have a look at this tonight, thanks. I remember DruidBSD for years back but never really looked into it much. Since this says it works with dialogand xdialogthis maybe something along the lines of what I was thinking.

 

[nanotek]

Re: "Killer App" for FreeBSD?

I install FreeBSD 10.0 Release on a Core2Duo Sony Vaio laptop that I borrowed from work last weekend just to play with the new release. During the install I chose the wireless network name and entered the network password and that was it. I didn't have to edit any files.

Now I did not play with switching networks or anything like that so maybe that is more complicated, although I suspect it has more to do with the wireless device of the laptop.

In my case, I had to accept an Intel licensing agreement by adding a line to loader.conf, which is why I couldn't take advantage of the simplistic bsdinstall dialog to configure WiFi. The subsequent inconvenience, however, is partly endured when/if connection to new networks is needed (i.e. wpa_supplicant.conf edits but no ifconfig/rc.conf configuration).

What does the installer use to configure wireless networks? And could this be adapted into something the average user can use?

This is a really good idea; a simple TUI dialog and no GUI, per se, would be more than enough to quell the frurore.

I would volunteer to work on a set of FreeBSD specific "user friendly" GUI tools (given that they are written in Python for now because my C is rusty) and I'd be more than happy to start with a wi-fi app.

Good on you! In all honesty, if I possessed the skills I would certainly contribute. In fact, when I finish my degree I will possess the skills and will contribute.

Arch LInux, prior to the migration to systemd, had a menu option. If the option was set in rc.conf the kernel would boot normally up to the point were the network connection was established. Then the process would pause and an ncurses menu would appear listing preconfigured menu options that were selectable. Select the desired network and finish booting with the "enter" key.
In Arch the network options were previously configured in an interfaces file.

This is also a good idea: The option to select which network and/or connection -- if both WiFi and ethernet is available -- at boot.

If you like the way the installer configures things, you might be interested in sysutils/bsdconfig,

Nice suggestion. Can't believe I never thought of that myself. Thanks, @jrm.

 

[kpedersen]

Re: "Killer App" for FreeBSD?

This is a really good idea; a simple TUI dialog and no GUI, per se, would be more than enough to quell the frurore.

I would personally find a TUI much more useful. We could use *curses too so to avoid messing around with maintaining GUI toolkits.

For those who really want a GUI window to appear can always set up the shortcut of `xterm -e tui_wifi`

The official python curses api looks really simple too (http://docs.python.org/2/howto/curses.html). It pretty much exactly mimicks the C API that we all know and love.

 

[Deleted member 13721]

Re: "Killer App" for FreeBSD?

This is a really good idea; a simple TUI dialog and no GUI, per se, would be more than enough to quell the frurore.

I would personally find a TUI much more useful. We could use *curses too so to avoid messing around with maintaining GUI toolkits.

For those who really want a GUI window to appear can always set up the shortcut of `xterm -e tui_wifi`

The official python curses api looks really simple too (http://docs.python.org/2/howto/curses.html). It pretty much exactly mimicks the C API that we all know and love.

I agree, big fan of *curses too. Though I like the pure command line more.

 

[SaltyNoob]

I'm using an ArchBang as base with VirtualBox to run FreeBSD. Once I figure stuff out, I have 90GB SSD reserved for FreeBSD. The only reason for this set up is so the FreeBSD VM can can go on-line, by using the ArchBang host's Sprint Mobile Broadband connection. I'm willing to donate $80 to $100 US dollars towards a kick-starter, or any other crowd funding effort to get Mobile Broadband working as similar and simple as it works for Linux.

Just constructive criticism from a BSD noob and forum lurker. Sometimes I get the same opinion of an earlier comment. There does seem to be a sense of pride doing things the hard way, among the FreeBSD veterans. I guess I can consider myself an intermediate level Linux user. So I know the feeling when a Linux noob ask question that can be easily solved by command line, but they insist on solving their issue with the GUI. I also realize one aspect of Linux growth is less reliance on the command line. Maybe a set of automatic scripts for command line networking task. Example:

If you have read the documentation and still have trouble, welcome to the FreeBSD's Beginner Networking Script.
Please type networkinghelp.py (made up name) and press return. (Script starts)
If you have an Ethernet cable press 1
If you want to start WiFi press 2
if you want to start Mobile broadband press 3 (OP's original wish)

Once you user presses what they want the script walks them through step by step. Pretty much the same instructions from the docs but in a script format. (I have no no clue how hard this would be)

This script would need to be tested on people who use computers as appliances, you know the normal people. Not nerds, geeks, or techies like us.

If the one of the goals of FreeBSD is adoption, than I think this would be a big help.

 

[kpedersen]

There does seem to be a sense of pride doing things the hard way, among the FreeBSD veterans.

People make the assumption that FreeBSD/Linux veterans find the command line harder than a constantly evolving GUI application. This assumption is wrong. FreeBSD is also the wrong operating system to turn into a beautifully interactive consumer experience (Ubuntu or Mac OS X would be much better starting points for that project).

This is kind of similar to why nvi or editors/vim are so popular. Do people really think that these tools are still around just because we like "doing things the hard way"?

This is especially frustrating when we have a perfectly good "GUI" version of FreeBSD already with PC-BSD. Can this just not be used? If they don't like KDE, then perhaps they are the perfect candidate to come over to our command-line / window manager side

 

[nanotek]

Sometimes I get the same opinion of an earlier comment. There does seem to be a sense of pride doing things the hard way, among the FreeBSD veterans.

This is an accurate observation. It's not unique to FreeBSD or even computer demographics, though; it's a classic tribal instinct and elitist mindset inherent in all males (and females). Once you identify with a particular subset of your species, you develop xenophobic tendencies and a propensity to defend that which you believe personifies you. In this case, FreeBSD possesses qualities that resemble those of its tribesmen, traits that separate them from other tribes. Allowing changes to occur, that seemingly homogenize their kind, is undesirable and must be opposed at all costs.

It is not a matter of preserving that which works for them -- as can be demonstrably proven by the fact that additional features need not replace existing ones (e.g. providing GUI functionality does not remove the CLI) -- but of preserving that which they identify with: FreeBSD users enjoy being perceived as FreeBSD users, not Linux users. Adaptations to FreeBSD that resemble that of Linux, for example, erode that perception.

It's human nature.

 

[kpedersen]

It's human nature.

And also why we have a ports collection. To take the full impact of GUI "apps" and to keep base clean from clutter

If you must, think of FreeBSD as having a politically correct outer shell with a chewy xenophobic core haha

 

[SaltyNoob]

My comment about having pride doing the things hard way is not meant to be a negative. Just different. So please, no bashing of developers or long time veterans.
I could remember the first time I got Arch and few weeks later Gentoo installed. I can see the benefit in the way those two distros do things, but during the learning process I always felt that some aspect could be made simpler.

I think my crazy suggestion of a command line instructional script for getting your network up (especially mobile broadband) instead of a gui is a happy medium.

 

[jrm@]

FreeBSD users enjoy being perceived as FreeBSD users, not Linux users. Adaptations to FreeBSD that resemble that of Linux, for example, erode that perception. It's human nature.

It also seems to be human nature to compartmentalize. I think you will find many diverse opinions among FreeBSD users. Please remember, just because a FreeBSD user wrote it on the forums doesn't mean he/she speaks for everyone. Having said that, a consistent theme has been keeping things simple, whether it's the license, the code, the filesystem hierarchy, etc. I don't think it's about being different, but about focusing on what developers feel is most important.

 

[tzoi516]

FreeBSD can stay the way it is core-wise. That being said, while working in a GUI that isn't Gnome or KDE it would be nice to have a GUI-based utility. Yes, some people can write their own utility and share, but not everyone is a programmer or would know where to begin to manipulate hardware after installing (yes, there's the handbook, but it's not completely up-to-date - who would refer their children to a 50's book on the birds and the bees today?).

Note: none of the above is a slam on developers - I appreciate everything porters/developers have done. I just think people shouldn't fear the GUI and try to talk people who want a GUI into using the terminal.

 

[Deleted member 13721]

It's human nature.

And also why we have a ports collection. To take the full impact of GUI "apps" and to keep base clean from clutter

If you must, think of FreeBSD as having a politically correct outer shell with a chewy xenophobic core haha

Also since the FreeBSD foundation is involved in funding PC-BSD which was built for primarily for the purpose of being a FreeBSD desktop, it is not right to expect them to duplicate their efforts. PC-BSD doesn't exist just for the hell of it.

 

[wblock@]

ixSystems is the company behind PC-BSD. The Foundation has funded some projects that benefit both FreeBSD and PC-BSD.

 

[nanotek]

It's human nature.

And also why we have a ports collection. To take the full impact of GUI "apps" and to keep base clean from clutter

If you must, think of FreeBSD as having a politically correct outer shell with a chewy xenophobic core haha

I highly value the distinction between the base system and ports, I wouldn't like it to change.

I think my crazy suggestion of a command line instructional script for getting your network up (especially mobile broadband) instead of a gui is a happy medium.

It's not a bad idea at all. I prefer the TUI dialog WiFi suggestion, but a script could be educational and functional, which is great.

It also seems to be human nature to compartmentalize. I think you will find a many diverse opinions among FreeBSD users. Please remember, just because a FreeBSD user wrote it on the forums doesn't mean he/she speaks for everyone.

This is a valid point; I nearly made the same comment in my previous post. There are many opinions and some speculative assertions made regarding the FreeBSD developers (in this thread alone) and the FreeBSD userbase, but how many developers actually posted in here?

Having said that, a consistent theme has been keeping things simple, whether it's the license, the code, the filesystem hierarchy, etc. I don't think it's about being different, but about focusing on what developers feel is most important.

I agree entirely. However, I don't really see the addition of improved WiFi/mobile functionality as straying from the KISS principle. Not to say a GUI app should be included in the base system -- this makes no sense considering there is no DE in the base system -- but improved TUI/CLI functionality could be considered.

FreeBSD can stay the way it is core-wise. That being said, while working in a GUI that isn't Gnome or KDE it would be nice to have a GUI-based utility. Yes, some people can write their own utility and share, but not everyone is a programmer or would know where to begin to manipulate hardware after installing (yes, there's the handbook, but it's not completely up-to-date - who would refer their children to a 50's book on the birds and the bees today?).

Currently, none of my FreeBSD systems are running a DE but I, too, think there should be some consideration for those who do operate a GUI. I actually think the Handbook is one of FreeBSD's greatest achievements, though; it's extremely comprehensive and I can't think of any other OS that comes close to FreeBSD in this department.

Also since the FreeBSD foundation is involved in funding PC-BSD which was built for primarily for the purpose of being a FreeBSD desktop, it is not right to expect them to duplicate their efforts. PC-BSD doesn't exist just for the hell of it.

Efforts can be shared instead of duplicated; nevertheless, I don't think calls for a TUI dialog, script, or WiFi GUI port conflates to a duplication of efforts between the BSDs. Further, there is nothing in the literature that states FreeBSD is exclusively for servers and should not be used for anything else.

 

[ronaldlees]

One of the things I really like about FreeBSD is the emphasis it puts on "base/core only" installations. My use of the "minimal" installation option in the installer probably outnumbers my use of anything more complicated by several times over. A lot of FreeBSD installations are geared towards servers and the assumed level of security associated with that kind of environment. In such a case, security+=minimalism.

It's been a long time since I've had any delusions about personally vetting all the pieces and parts of Gnome. I'm not sure I can do that even for Xorg. So, around here, we use the smallest subset of the ports system that gets the job done, and absolutely no more than that. I have occasionally set up the wpa_gui for a friends (non-techie) machine, and it works pretty well. The wpa_supplicant setup on FreeBSD is so simple though, such that the gui's only needed in the scenario just described.

I don't ever expect FreeBSD to be available in the form of a flashy interface loaded with "every hip app known" on a bloated and consumerized slick GUI. We're talking about two groups of people - living on different continents, in different centuries. I don't particularly trust the super consumer GUIs available in the Linux world, but they may be fine. Maybe the security on those platforms is perfect, in spite of the inclusion of copious quantities of user software. Yet, I'll stick with my dogma-belief that too many pieces and parts cause trouble.

There is a disclaimer in the ports system, advising that some pieces and parts may not play nice. It's there for a reason!

 

[wblock@]

This finally prompted me to try net/wpa_gui. It seems to do pretty much what people want. I have minor complaints:

• It does not let you switch to a wired interface
• Networks should be color-coded for security (WPA should be green, WEP yellow, no encryption red)
• The sorting in the scan list is by string on signal strength when it should be by numeric value

The second two are probably not hard to fix, certainly easier than starting from scratch. The first is out of scope for this program, but would still be very useful.

To test it, remember that the two entries for ctrl_interface in /etc/wpa_supplicant.conf are needed:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

 

[sossego]

 

[sulman]

It's actually quite a difficult area, and I understand why FreeBSD developers are unwilling to jump into it.

For open wifi hotspots and simple consumer WPA connections, the GUI tools in Linux are great; but they can struggle with enterprise configurations, especially where credentials or certificates are involved. NetworkManager, by the way, can be very buggy - a few distros recommend ditching it for WICD as soon as possible.

This means one has to dig into configuration files. Now, once you've done that you realise the config files are not that scary, and it's often just as easy for a naked ifconfig + wpa_supplicant setup anyway. Arch Linux has a good intermediary called netctl - it's essentially a script - but it does the job pretty well.

 

[beatgammit]

This means one has to dig into configuration files. Now, once you've done that you realise the config files are not that scary, and it's often just as easy for a naked ifconfig + wpa_supplicant setup anyway. Arch Linux has a good intermediary called netctl - it's essentially a script - but it does the job pretty well.

And wifi-menu is nice to get you bootstrapped on a new network if you're travelling between access points.

 

[robspop]

A final postscript from me as OP.

Thanks to all those who contributed, and particularly to those who made positive suggestions and even volunteered to contribute something: I wish you good luck with this.

To those who got all hot and bothered with the suggestion that a GUI tool might be useful, all I can say is: if you are reading this on a browser like Firefox or Chrome, then shame on you: what is wrong with lynx?

Lots of people who have commented seem to have willfully either misunderstood, or be misinformed. Relatively few people have commented on the mobile broadband issue, yet I have said a couple of times that this is the thing that is particularly difficult in FreeBSD: there is no point commending tools like wpa_supplicant for this as they do not do that job (and are not intended to).

I have given up and gone back to Debian. I can tell you that I do *not* have either Gnome or KDE installed, I am still using FVWM, but I do have nm-applet and it works: I can connect to mobile boadband with a few clicks and then get on with the things I actually want to work on. For all I know it might be troublesome in a large corporate environment, but I would not use it there anyway. For connecting a laptop to a mobile broadband service on a train passing through areas of good and bad connectivity, it works beautifully.

 

[jb_fvwm2]

I see it not as a misinformation, rather a misunderstanding. It took me two weeks to "install" ppp on windows98, and two weeks to tweak wpa-stuff to get an Edimax dongle driver working well enough, and one week to get a onboard-laptop dirver working well enough, with the unexpected benefit that the Edimax this past few weeks served as a near-DSL dropin for a two week DSL outage (bad colocation card). I've scripted the ethernet > dongle > ethernet reboot in two shell scripts (an hour or so total...)...
So it appears from here to be a lack of persons with time enough to setup/test a front end to all that at the operating system level, as almost all are working unpaid, etc. (VS Linux, Microsoft, etc...). Perhaps the OP with more experience with replies to similar questions would have been able to phrase the question differently, eliciting a more helpful series of replies.

All in defense of the criticism of the replies... not meant as a criticism of the question necessarily. (I've asked similar ones... )

 

[robspop]

Time I got a life and stopped posting on this thread, but:

not as a misinformation, rather a misunderstanding

There have been several replies that have stated that you can only use the Linux GUI application with Gnome or KDE, and a few others that have talked about bloat, and these are simply plain wrong: you do not need either of these to run nm-applet and, if you already have some sort of X environment running, it adds very little.

But, fine, nobody is interested, ok: it was only on off-topic discussion suggestion.

 

[CreativeGPX]

As a disclaimer, I'm talking about the broad point here, since I haven't come across this specific problem.

First, I do think usability issues like this do need more attention. The real issue is a lack of abstraction not necessarily lack of GUI. There is a set of consistently repeated micro-tasks that a user must perform to achieve a "common" mega-task. The micro-task philosophy is one focused on "what does the machine need to do" while the mega-task philosophy is one focused on "what does the user want to do". Whether it's being done through GUI or command line, all of the most popular general operating systems (Windows, Mac and many of the more popular Linux distributions) achieve their popularity by putting an emphasis on this layer that abstracts what needs to get done from what a user wants to happen. It could be GUI based or it could be command line based. It just has to focus on what they user wants, rather than what the machine must carry out in files and settings to make that happen. Understanding the micro-tasks can be overwhelming in the beginning because by their nature they require a more systemic understanding of FreeBSD. Every manual step also can result in a lot of wasted effort and more points for user error. Any time somebody can hand you a concrete set of steps to carry out to achieve something, it's irresponsible for a programmer not to automate it. The Handbook is full of concrete sets of steps to achieve high level goals yet most of it is still an entirely manual process. Either way, coming up with these (perhaps prompt-driven) mega-tasks is compatible with command-line lovers yet largely fixes the usability problem. If they were scripts full of inline documentation they could (1) be full customizable to the power user, (2) be manually runnable, (3) be ignorable, (4) serve as educational material such as the contents of the handbook and (4) work for command line users. I think that's the way to go in time.

Now for the other side: Saying you don't know how to program/script so you can't make a solution isn't an attitude that got anything in FreeBSD to any pleasing state ever. Like most programmers, I didn't learn to program to get a job or for pure curiosity. I learned to program because there were things that didn't work they way I wanted them to. The nature of a volunteer project like FreeBSD is that things get done when people get fed up to the point of doing something about it. The more people that get fed up about an issue, the more likely it is that one of them will actually decide to fix it. Since your issue is less common, there are less people to get fed up and therefore less of a chance somebody will fix it. Saying that you can't create a simple solution you are proposing because you can't code is saying that it's impossible to learn to code which isn't true. It's easy. It's so easy that I was able to teach myself over the internet when I didn't know anything beyond basic math. Pick up a book on shell scripting, python or perl and you'll be on your way to automating the pain of yourself and others into a simple, easy process. You'll be able to get something simple together. If it's not perfect, that's fine. People will be more able to lend a hand to refine or fix a FreeBSD feature than to build one from scratch. Maybe somebody will even get fed up with YOUR solution and then make an even better one. Solve the problem for your own good. Solve it for the next person who comes along and has that problem. Solve it for the mere sake that your experience figuring it out wasn't wasted. At the very very least, if you aren't willing to take to scripting, write what you did in a tutorial for others. That helps people too and it gives coders a systematic reference for what actions they should code if they wanted to. FreeBSD needs your help just as much as you need theirs.

 

[robspop]

Saying you don't know how to program/script so you can't make a solution isn't an attitude that got anything in FreeBSD to any pleasing state ever

Fair point; in fact I can program in C moderately well and Perl to an extent, but I don't have time. I buy BSD goodies from time to time and donated something to last year's appeal so I have tried to do my bit that way.

I accept that it is an obscure problem, but in a way, that comes right back to my original point: if there was a bigger user base maybe there would be more solutions being produced, and maybe there would be a bigger user base if the response to this sort of suggestion didn't have such a large element of "GUI's, whatever next? He'll be wanting a screen next - what's wrong with octal output?"

It might be an obscure problem in FreeBSD but it's not actually a new one, and even OpenSolaris managed to solve it a few years ago.

Maybe everyone will move to "mifi" and it will simply go away.

 

[CreativeGPX]

To make the OS more widely appealing requires more volunteer-hours than the community has. To get more volunteer-hours for the community requires the OS being more widely appealing. It's a circular problem which is broken when some new developer comes along and starts a usability team.

While these usability features definitely should exist, it's not relevant whether they are included with FreeBSD by default. That's why distributions were invented! As long as the tools get added into Ports, then FreeBSD could just have a few untainted distributions where the sole difference between them and FreeBSD is the pre-installation and configuration of a scenario-based set of ports. There could be one for mobile computing for what you are talking about. This gets around your concerns about PC-BSD being too bloated or impure and the concerns of others regarding polluting the core.