nubae's Habari | Linux and Education

Fine, so sharing multiple formats that include reverse engineered file systems that are/were proprietary to creating new ones which are supposed to be just plug and play, is close to rocket science.

Well it would be if it worked in most cases. I'll give you a brief example:

This morning I decided I would take all my pc equipment, my drives, my CD drives, DVD drives, usb sticks, etc etc and on and. I would then try and make an efficient (efficient as can be with multiple Oses and multiple hubs, network cards running at various speeds, and a host of external hotpluggable hard drives, both SATA and IDE to test and see what was on them after the years and years of collecting.

In fact, I'm currently staring at a pile of about 8 SATA drives totaling about 3.5 TBs, and a stack of 12 IDES which god knows might even hit the 1.5 TB mark. NOw... having all of that working together in a more or less redundant method across the network (I figure its the perfect opportunity to brush up on my bash shell coding skills to do a plethora of things from managing all that data, checking how corrupt the disks are and somehow forecasting when its time to get rid of the problem kids, setting up a nifty search system that fits MY naming conventions, not some complex XMBC like system that tries to do everything, moves stuff around and then leaves you more lost than when u started)

Anyway, as always, I digress. This entry was really to complain about the STILL dire problems that the average user will have to share a set of files. First, of course, me being old school, I go to the terminal, set up my smbpasswd -u and set up his password. Perfect...

Then I open the file/s or directory/ies that I'd like to share, but of of course only Root can do that, so here comes problem number one... Do I know the name of the sharing program so I could run it using gksudo from terminal? Nope... bet you don't either.... hint: It's not nautilus.

Ok... Then I think, ah but wait, I can open it from the control panel, so I go to preferences -> Personal File Sharing and repeat the operation... Suddenly I'm bombarded with questions to do with blue tooth sharing, which is really not what I was after... I just wanted regular old samba to allow me to move files to and from my Oses with too many questions. But If go ahead and fill in all the questions, where there is no mention of sharing via samba or nfs or anything.

I right click on the directory I've now been trying to share for 10 minutes and the shre this folder tick box is ticked, and there 2 other options which I choose not to touch in case they influence the final outcome. I then click 'add share' and get the following message:
'net usershare' returned error 255: net usershare add: share name 'myname' is already a valid system user name'

So I think to myself, OK, so there is a conflict because I tried to speed up the process manually of creating a smb user and password which the system seems to be unable to parse (why? heaven knows... Has ubuntu decided to change the way samba details are stored too?"

Fine, I think to myself, let me use a different share name, say share, I then hit create share with a new name aptly named share and get an even more complex explanation on how to get this working. By this time I am starting to get amused (as I tend too, having been involved in the Unix/Linux/OSX worlds far longer than the MS world, you can see me slowly admitting to the n.1 argument that regular folks mention when using a Linux based machine for anything that slides over into a little bit of systems administration work.

I know, that, had a client been with me at this point it would be extremely difficult to convince them that Linux is in fact a better, more efficient and easier solution to set up than a multiple windows based system.

But 'not being one to give up easily, I continue the journey. This time I have the following sprawled across the screen:

'net usershare' returned error 255: net usershare add: cannot share path /home/nubae as we are restricted to only sharing directories we own.
Ask the administrator to add the line "usershare owner only = false"
to the [global] section of the smb.conf to allow this.

Sooo.... away we go again, to command line and try adding that, hoping this will finally allow me to share the ONE directory. I restart the smbd service from the command line with service smbd restart (though admittedly, I'm still more used to doing a /etc/init.d/command restart.)

Trying to change any of the other tick boxes (allow others to create and delete files, or allow guest access) fails on the premise that permissions could not be changed for the directory nubae.

I decide to start from the very beginning, deleting the nubae directory, removing samba completely with --purge and giving a go from scratch in case I've missed something, but so far, you can imagine I'm grinning out of frustration more than out of anything else. I delete the whole user account from within the user setting visual GUI, to make sure there are no lingering side effects. And start again by creating the user through the GUI.

Vy recreating the account through the user settings control panel, I suddenly have no problems, even when it comes to sharing the account. It simply asks me if I want to install Samba and away it goes.

Now... if it had been obvious from the start that one can no longer touch the terminal without causing serious damage I wouldn't be so annoyed by this. But it seems like more and more, anyone with a terminal based systems administration background is being left in the dark, while Ubuntu developers and Canonical decide upon their own best practices.

This is not very different from what windows forces its users to go through, and it is yet another reason I am become more and more alienated by those who promise to stick to standards while secretly doing whatever they want without letting people know what is really going on.

I state this not as a newbie, but as someone that's been involved in development through countless areas of Linux, and never have I seen so much secrecy surrounding the introduction of new ways of doing absolutely fundamental things (adding users) without being told that if you use the terminal, you can screw up everything.

This is unacceptable. Either make things backwards compatible, or give an explanation somewhere on the new/right way of doing things. Making users jump through hoops is no way to get a larger user base, in fact, in my case, its made me actually start running XP along side Ubuntu... something I thought I'd never do....

sigh.... There is of course always OS X, which if I really have to be honest about... its the system of choice, if one has the money. Everything just works, it has a unix core so you dont have to feel like you are in unfamiliar territory, and it looks damn cool.

So the moral of this story is... Developers... please... work united to give people a unified experience that they can manipulate either in a format that has been charted out for them (we L(i)(u)nix people don't like that at all) or let us once more be free, and make the gui stuff work along side the true tried and tested command line environment configuration files. Its not that hard...

Any developer worth their salt will tell you that editing existing config files and making a gui that does the same is JUST as easy as doing some proprietary...

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5

Starting the session was a little chaotic, as this was the first time we've tried a group collaborative session, and there were no specific goals we had in mind. The idea was generally to see how collaboration worked in a mixed environment (0.82, 0.84, different distros, different network connections, etc)

The good news is, that for the most part, getting connected worked, and once in a collaborative session response times were quite good. This means that the underlying sharing mechanism works, it just doesn't respond very quickly. The bad news is that the server load is much worse than originally thought and expected.

From our initial experiences, it was clear that the sugar-presence framework had some huge problems in terms of visually representing who was connected, which activities were being shared, and who was sharing these activities. It was not clear where the major bottleneck was in terms of reaction and response, but suspicions lie at the ejabberd end of things. In future sessions we will have to restrict connections and individual details to the point that we can make proper measurements, and thereby find out what is going wrong, and at what point it is going wrong. Suspicions are that the jabber server in question (jabber.sugarlabs.org) didn't have gadget enabled, and was therefore broadcasting the list of all registered users continously, which would burden the server severely. The lag and server load also affected the visual clustering of users around specific activities

Though reaction times were very slow, the underlying sharing framework clearly works very well. Once users were connected, their connections were stable, and within specific activites, reaction times were fast and reliable. We were able to test a fair set of activities, some of which had better implementation of collaboration than others, and some of which didn't seem to have collaboration enabled at all.

We started off with the chat activity, which took a good 10 minutes before people started being able to connect to the initial shared session. Once connected, reaction times were pretty decent, and the frame showed all the connected users. There was a large variance between the shared buddies shown. Some users reported seeing 5 buddies, some 3, some 7, and some even saw buddies with a ??? as their handle. The screenshot below shows how it looked:

Speak was another interesting activity to share, as it allowed multiple people to join a session where the computer speaks out what's typed in the accent of the user's choosing. The choice of accent is used for the proper pronounciation in different languages normally, though there was much fun to be had speaking English words in the various accents. Below is a screen shot:

Reaction times were again very good once users had joined the activity. Buddies connected was highly variable from user to user again, and though clustering around activites did take for ever, it did eventually start to happen, as can be seen from the screenshot below:

Etoys was a surprisingly good collaborator. Once users were connected they were able to create various items, even animated and custom coded, and then send them through to the connected buddies. We just scratched the surface of this activity, and it was clear that some really interesting things are possible with collaborative etoys:

Other activities that worked quite well were Cartoon builder, connect, Maze, Colors, and Tam Tam. We were unable to get write or paint to collaborate, and are unsure as to why. Talking with the authors of these programs seems appropriate, though it has been verified that write, at least, does collaborate. Below is a screenshot of what it looked like when multiple activites were being shared:

Rate It! (Average 0, 0 votes)

• 1
• 2
• 3
• 4
• 5