Tag Archives: IMHO

News, Politics, Government

Publicis-Omnicom: A PR Scorecard

Leave a comment

By Peter Himler, Contributor

Now that the dust has settled from the biggest ad industry merger announcement ever, let’s take a moment to reflect on the net takeaway from the news. First, I should say that the announcement, IMHO, was mischaracterized. It was universally described as the creation of the world’s biggest advertising company, when in fact, both Omnicom and Publicis have scores upon scores of non advertising services companies under their respective belts. It prompted this tweet: Curious how media mischaracterize $PUB – $OMC as “world’s largest ad agency.” http://t.co/zwF4kcrgUi #MarketingServicesFirm …read more

Source: FULL ARTICLE at Forbes Latest

Linux

Flavia Weisghizzi: Outreach report (part II)

Leave a comment

During the first part of my OPW, I spent much of my time in investigating the issues newcomers could encounter in approaching FOSS. Results of my work, are available here.
Starting form these results, I’ve spent some time in second part of my internship in studying how to apply what I’ve discovered in the GNOME environment.
I’ve tried to provide some answers to the questions I met: I share with you the result of my work.

Classification of newcomers.

I’ve try out that newcomers could be generally set in three type:

Type A: Enthusiastic

An Enthusiastic newcomer is a great passionate of GNOME, is a GNOME user and generally decides to use some of his time to give a hand.
He has not a well established idea about what he can do, but he wants to contribute.
Probably he’ll start to follow as much ML as he can, join IRC channel, proposing himself for every task.
What he really needs is a guide not only a Mentor, but someone who can address him to the right team,   supply some indication about guidelines and more important, give him some task to do, that could help him to perfectly feel himself as a part of community.

Risks and potentialities: An Enthusiastic newcomer is proud to serve the project he chose, is very participative, but his outburst risks to burn away and fall very quickly, if he doesn’t find the right way to  take part of community.

Type B: Passionate

A Passionate newcomer is a volunteer provided of some experience in GNOME world.
He could be a GNOME user, and very often he came from other FOSS projects.
He desires offer his capabilities and some amount of his time in developing some specific part of project.
What he really needs is to find well defined task to do and some people who could steer him in early days.

Risks and potentialities: A Passionate newcomer is usually a professional who has little time to spend, but can offer a significant know-how. Generally his contribute is not daily, but often very relevant and long-lasting.

Type C: Technician

A Technician newcomer approach a community bringing a great experience.
Usually he has a technical background and is a first class citizen in FOSS world.
Coder or not coder, he has a great familiarity with community tools.
What he really needs is to find well written documentation and guidelines, and some project in which he cans easily take part.

Risks and potentialities: whatever be the know-how brought by a Technichian newcomer, it will be valuable; the main risks involve only the capability of newcomer to integrate his knowledge to work-flow.

Howdy, newcomer!

A very relevant issue we should take in consideration, is how a newcomer joins GNOME.
My personal opinion is through IRC Channels.
A direct contact is always the best, IMHO, but IRC Channels can’t be enough to provide detailed info.
This should be the role of gnome.org/ gnome.org/get-involved/ pages.
I’ve been really pleased to notice that design renewal of the site occurred …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

HOWTO: analyze memory usage on AIX, aka svmon "101"

Leave a comment

By MichaelFelt

THE command on AIX for examining memory on AIX is svmon. Frequently, just the command
svmon with no arguments (defaults as
svmon -G ) is enough to get an indication of whether there is a chance of major memory problems.
(Note: the system I am displaying this from has 9G and has only been up for a few days, memory is not fully loaded. I will run the same commands from a smaller virtual system as well, to show differences between “ancient” systems such as my P615 – Power4, and “almost ancient” Power5

1. svmon -G

Code:
michael@x054:[/home/michael]svmon -G
size inuse free pin virtual mmode
memory 2359296 1778880 580416 631814 794262 Ded
pg space 131072 2372

work pers clnt other
pin 446779 0 0 185035
in use 794262 0 984618

A little hard to read – so a nice example for the man page is:

1b. svmon -G -O unit=auto,timestamp=on,pgsz=on,affinity=detail
This command output is much easier to read – sizes behind it! Notice also the small paging space. With AIX you should not need paging space. IMHO – regular (I define this as more than 3 i/o per second) paging to from paging space indicates an application and/or configuration error. In short, DO NOT page to/from paging space (paging to/from file space aka persistent storage is normal i/o).

Code:
michael@x054:[/home/michael]svmon -G -O unit=auto,timestamp=on,pgsz=on,affinity=detail
Unit: auto ...read more
Source: FULL ARTICLE at The UNIX and Linux Forums
Linux

Let's see how the community reacs

Leave a comment

Hi all, this is my first 2013 post.
My last post was 5 months ago because I did finish my studies (I’ll graduate on March) and I had to do some work so I had no time to blog about Arch or the KDE projects in which I’d like to join (stay tuned!).

Here we come to the reason of this post: I got a mail yesterday from Laszlo Papp:

Laszlo: Hi Andrea,

Qt5 was out a while ago. Do you have any estimation for producing Qt5
packages for Arch? Do you need any help with those?

His request is fully reasonable and expected. Laszlo, you are talking with a maintainer of a bleeding edge distro: I want the latest software before it’s released. Knowing that a qt5 package is already available on AUR, I replied quicly:

Andrea: There’s no real hurry about that.
KDE will not use qt5 until 2014 (ok, maybe some month before) so there’s no
hurry to put qt5 in [extra] IMHO.

The I got another mail from Laszlo:

Laszlo: Well, Qt5 is not just for KDE. Besides, it would help the development for
many developers.

I agree that it would help the development of the qt developers on Arch, but I didn’t reply for a matter of time. Then I got another mail:

Laszlo: I just got to another development arch machine where I have to build qt5
again from scratch.. sigh. Yay, 2 hours waiting.

Nothing surprising here. This is the means of “building from sources”. I didn’t reply.

So I got another mail this morning:

Laszlo: After talking to several Qt arch developers, they got a bit disappointed
about this feedback as me, so I opened a bugreport:

https://bugs.archlinux.org/task/33352

Well, the first rule of our bug tracker is: Do NOT report bugs when a package is just outdated, or it is in Unsupported.
The second rule is: REPEAT: Do NOT report bugs for outdated packages!. (Yes, it sounds like the Fight Club rules).
You can see that two Arch Linux maintainers closed that bug report with the same reason and they also suggested to share the package between the several machines.

But we continue with another mail from Laszlo that caused this post:

Laszlo: I hope you do realize I had to pospone my work last night because I am
still trying to get a damn binary?

Once, I am ready with all this, I will publish a blog about your
unwelcoming reply even after my “help offer”. If private mails do not help,
let us see how the community reacts.

Well, the last two lines sound like a threat for me.
I’ve nothing to hide (this is the whole story) and you should remember that I’m not paid for this.

Laszlo: I will of course publish the built binary for x86_64 as well to aid other
arch developers’ work.

Perhaps, a request will go to kde-packagers@kde.org as well soon from me.
It is not only an arch request after all.

IMHO this is the right thing to do and the first thing you should have done Laszlo: build a package and put it on dropbox/repo, share it between your machines and the community if you want.

Then I replied again:

Andrea: The package will hit [extra] when it’s ready (this means weeks or months). Meanwhile use the package from aur, you only need to build it once, not every day.

But still…

Laszlo: Just calculate 20 developers, but surely more are using Qt5: 20*4/5 hours =
80/100 hours… just by only building it “once, not every day”.

Thank you for letting me lose 40 minutes of my working day writing this post.
Note that you delayed the release of the qt5 package in [extra] (whatever date it will be released) by 40 minutes.

Source: FULL ARTICLE at Planet KDE

Linux

Joel Leclerc: shbuild – An alternative to GNU Make… using shell scripts

Leave a comment

I’ve been trying to find a make alternative or interface using more common languages, and so far, the only one I’ve found was waf (which, IMHO, wasn’t well documented and overly complex). Maybe I haven’t done enough research, but seriously, why do people have to reinvent the wheel for just a build system?

I spent around two days writing this (haven’t wrote shell scripts for a while), and I’m pleased of the result. Notice that this script is still in alpha stage, so I can’t guarantee that everything will work as expected. The main difference between this build system and others is that it works by commands (functions), which then runs the compilers, linkers, and whatever else is needed. Because of this design, it should (in theory) be more powerful and easier to code than a normal makefile. Here is an example of what I’m saying (sorry about the horrible formatting, wordpress breaks it):

Buildfile:

build() {
sources='file1.c file2.c file3.c file4.c file5.c file6.c main.c'
objects='file1.o file2.o file3.o file4.o file5.o file6.o main.o'
output="main"
runtargets $sources $objects 'gcc -c $target -o $output'
gcc $objects -o $output
}
addcmd build build Builds the project
default_command=build

Makefile:

all: main
file1.o: file1.c
gcc -c file1.c -o file1.o
file2.o: file2.c
gcc -c file2.c -o file2.o
(repeat this for each of the targets...)
main: file1.o file2.o file3.o file4.o file5.o file6.o main.o
gcc file1.o file2.o file3.o file4.o file5.o file6.o main.o -o main

For me, the buildfile technique seems much cleaner and easier, and anyways, it’s shell, so you can call functions within it to make your life even easier, etc…

The other thing that I spent a bit of time on was to add common utility functions so you don’t have to write them yourself. Some of them include:

  • Automatic uninstaller
  • printc for printing text in colors
  • Many array utilities
  • Help system (still a WIP)

No documentation is currently available, since I’m still polishing it, but I will add some soon. In the meantime, you can just browse through the source (honestly, it will only take you a couple of minutes, it’s currently very small). You can also check the buildfile for it, as it contains many of the functions you would probably use.

Source is located here: https://github.com/MiJyn/shbuild. You can easily build and install the source by using the “build.sh” script (it’s simply a wrapper to use the unbuilt version of shbuild), like so:

sudo ./build.sh install

Let me know what you think, anything constructive (bug reports, ideas, patches, things that were unclear in this post, etc…) is appreciated :)


Source: FULL ARTICLE at Planet Ubuntu