Support NeoGAF

[Vanillalite]

All you Gentoo whores can be happy!

Version 11 is now out though most of you who are hardcore enough to use Gentoo probably update shit as it comes anyways. Nice if you need a live iso though.

 

[zoku88]

So, apparently Ubuntu 11.10 is ...

Oneiric Ocelot..... kekekeke

+1 Dictionary word.

 

[itxaka]

So, apparently Ubuntu 11.10 is ...

Oneiric Ocelot..... kekekeke

+1 Dictionary word.

Oh my, I had to google it to know what it meant. I can't wait for the wallpaper, it's gonna be one of the best ones ever

 

[Vanillalite]

 

[dude]

Do they sit with an adjective dictionary and animal life guide and just open both at random for those things?

 

[Vanillalite]

Do they sit with an adjective dictionary and animal life guide and just open both at random for those things?

Sort of seems that way doesn't it. That being said they are going in alphabetical order, and both the adjective and the animal have to start with the same letter. Sounds easy, but I bet it is harder than we think.

 

[zoku88]

I can't think of any O adjectives that don't have a negative meaning...(the only one I can think of is onery, which is not so good..)

XD

 

[itxaka]

I can't think of any O adjectives that don't have a negative meaning...(the only one I can think of is onery, which is not so good..)

XD

Outstanding Ocelot!

Obedient Owl!

Onmipotent Ox!

Obscene Orangutan!

And my favourite, Oppressive Opossum!

 

[panda21]

this whole Ubuntu/Banshee thing is kind of interesting, seems like an incredibly stupid move on Ubuntu's part, since people have been complaining about Rhythmbox for ages, its not even being developed any more, and Banshee is really good.

now they switch to officially using banshee as the main music player in ubuntu and immediately fuck the banshee developers over. thats really going to help integrate it into Ubuntu.

their Unity decision seems kind of insane as well, I can't help but think 11.04 is going to be a massive trainwreck, 6 months to completely build and switch over to a new desktop UI is insane. I know they already had unity on netbooks but I get the impression they changed a lot for the desktop version, and it wasn't exactly good on netbooks in the first place.

 

[itxaka]

this whole Ubuntu/Banshee thing is kind of interesting, seems like an incredibly stupid move on Ubuntu's part, since people have been complaining about Rhythmbox for ages, its not even being developed any more, and Banshee is really good.

now they switch to officially using banshee as the main music player in ubuntu and immediately fuck the banshee developers over. thats really going to help integrate it into Ubuntu.

 

[Vanillalite]

this whole Ubuntu/Banshee thing is kind of interesting, seems like an incredibly stupid move on Ubuntu's part, since people have been complaining about Rhythmbox for ages, its not even being developed any more, and Banshee is really good.

now they switch to officially using banshee as the main music player in ubuntu and immediately fuck the banshee developers over. thats really going to help integrate it into Ubuntu.

their Unity decision seems kind of insane as well, I can't help but think 11.04 is going to be a massive trainwreck, 6 months to completely build and switch over to a new desktop UI is insane. I know they already had unity on netbooks but I get the impression they changed a lot for the desktop version, and it wasn't exactly good on netbooks in the first place.

To be fair it's not just 6 months as it's based off of the netbook remix so they had some stuff in place, and they also decided they are ONLY doing compiz enabled version this time around. The "2d" version isn't gonna be dealt with until the next cycle for people with meh or older hardware.

On the Banshee thing... *sigh* it points to one of the things that makes me stray away from Linux even now when it's more user friendly. I feel like the community still sucks, and have said as much in this thread. Heck the fact that we have this thread, it's sort of outside of the normal nix landscape, and everyone is so cool is one of the main reasons I've grown to love nix more.

Normally I find the community extra hardcore, non newb friendly, and despite being all on the nix side of things (verses say the windows/apple fanboys going at out) more bickering and infighting than I've ever seen tech wise. This is just another example. I finally read Mark Shuttleworth's blog entry on the Banshee thing, and I tried to read the comments on OMGUbuntu. Yet damn seemed like it was just one big pissing contest from all sides from an outsider even if it's probably really Canonical's fault.

HUGE HUGE HUGE turn off IMO.

PS: Android being google's thing and all and just the way it's preinstalled and handled seems to do well because most people don't even know it's linux based they just think google AND it because of the way it's handled it gets around all of the crap normally associated with the nix community IMO.

 

[cntr]

What's this about Ubuntu and Banshee?

 

[itxaka]

What's this about Ubuntu and Banshee?

Banshee is a music player. The have an amazon plugin which gives you access to the store and lets you buy things from inside the program. That way they earn money as affiliation for each purchase made directly.

The earnings were directly to the gnome foundation.

Now canonical wanted to move from the default rythmbox to Banshee as default for the new ubuntu.

So canonical got and told banshee developers that they wanted a 75% of the earnings, which they said no. They rather had the plugin disabled by default but with the 100% going to the gnome foundation.

Meanwhile, canonical created the plugin to the ubuntuone store and enabled it by default which reports them money.

Seems that word got out to the public about this talks and canonical decision so they backed off it, enabled the plugin and told them they they will give them a 25% of the earnings + a 25% of the earnings of the ubuntuone store.

This decision was made by Ubuntu directly.

Basically is a quick money grab by a for-profit organization, taking it from a non-profit one which has done most of the job.

Legally ok? Yes, that is the beauty of open source!
Morally ok? Hell no.

 

[Vanillalite]

To be fair Ubuntu is a for profit organization, but we aren't sure if they've ever actually made any profit yet. Mark is funding on his own, but stated he can't keep doing this forever, and that they needed to start making enough cash through their own means a few years down the road. This was a few years ago too.

 

[itxaka]

To be fair Ubuntu is a for profit organization, but we aren't sure if they've ever actually made any profit yet. Mark is funding on his own, but stated he can't keep doing this forever, and that they needed to start making enough cash through their own means a few years down the road. This was a few years ago too.

Sure, that is why I said that legally is ok. That is open source at it's core, freedom.

That doesn't mean is ok for them to do it morally, or that people have to agree with it just because they are for-profit.

Thing is, I doubt Ubuntu will turn into a profit...maybe ever. Red hat shows that you can run a business with open source at it's core, but you need to be focused on the enterprise where the money is.

Ubuntu is the linux of the crowd. It's easy. It works. It has a name. But it's name is associated to the desktop. You don't get any money from the desktop.

And meanwhile, it has gained a bad rep for their regression problems when updating and their sudden change on policies.

Look at the other server distros, Red Hat and Debian. They are incredibly stable. They don't fuck up when upgrading packages or the whole distro. They don't have the most up to date packages, because that is where erros, regressions and bugs are found!

Also, they are gaining quite some bad rep for their interaction with the rest of the open source community. Gnome, Debian, Banshee are the big ones. Look at red hat and centos. They are the same! The only thing red hat asked for centos is to remove the logos and names as they are copyrighted, the rest of it? They even collaborate on the centos mailing list to help centos developers!

If they expect to make money on the server side, they have focused in the wrong parts of it.

Of course all of this is my opinion. I could be wrong, I normally are

 

[Vanillalite]

That's the thing though. Is it so wrong to want to take Linux to the masses? We all know that isn't as a server solution either, but as a desktop solution for both general consumers and business. It's obviously what Shuttleworth would like Ubuntu to be, and is that such a bad goal?

I'll fully admit though at the present time I'm not sure no matter how good willed that lofty goal may seem, that it is economically viable.

 

[angelfly]

That's the thing though. Is it so wrong to want to take Linux to the masses? We all know that isn't as a server solution either, but as a desktop solution for both general consumers and business. It's obviously what Shuttleworth would like Ubuntu to be, and is that such a bad goal?

I'll fully admit though at the present time I'm not sure no matter how good willed that lofty goal may seem, that it is economically viable.

Nothing wrong with wanting to bring it to the masses but I think Canonical's handing of the distro is questionable. They cheer it on as a community distro yet not of the big decisions have any input from the users. Like the situation with moving the window buttons to the left. They simply make those sort of changes around the distro and force them on their users whether they like it or not. I'm not an Ubuntu user so my opinion really doesn't mean much but is saddening to watch where Ubuntu is headed. That is the problem though when you have a for-profit company running the show.

 

[zoku88]

Outstanding Ocelot!

Obedient Owl!

Onmipotent Ox!

Obscene Orangutan!

And my favourite, Oppressive Opossum!

Well, obviously I didn't think hard enough! >_<

I vote for Oppressive Opossum XD

 

[zoku88]

Sorry for the double post (maybe ok since it's been two hours.)

Any nice CLI or GTK apps that can monitor HDD usage?

Not like % usage, but reads/writes in MB/s, etc

 

[Vanillalite]

Does like the partion manager or system manager or whatever usually show that info with realtime updates? (GNOME here)

That's not an app though.

 

[zoku88]

Does like the partion manager or system manager or whatever usually show that info with realtime updates? (GNOME here)

That's not an app though.

You mean the gnome system manager?

No, not to my knowledge. Couldn't find the option in the preferences when I looked before anyway.

 

[Vanillalite]

You mean the gnome system manager?

No, not to my knowledge. Couldn't find the option in the preferences when I looked before anyway.

Yeah I'm booted into Win 7 right now and on steam so I couldn't look myself. LOL

 

[Flying_Phoenix]

Sure, that is why I said that legally is ok. That is open source at it's core, freedom.

That doesn't mean is ok for them to do it morally, or that people have to agree with it just because they are for-profit.

Thing is, I doubt Ubuntu will turn into a profit...maybe ever. Red hat shows that you can run a business with open source at it's core, but you need to be focused on the enterprise where the money is.

Ubuntu is the linux of the crowd. It's easy. It works. It has a name. But it's name is associated to the desktop. You don't get any money from the desktop.

And meanwhile, it has gained a bad rep for their regression problems when updating and their sudden change on policies.

Look at the other server distros, Red Hat and Debian. They are incredibly stable. They don't fuck up when upgrading packages or the whole distro. They don't have the most up to date packages, because that is where erros, regressions and bugs are found!

Also, they are gaining quite some bad rep for their interaction with the rest of the open source community. Gnome, Debian, Banshee are the big ones. Look at red hat and centos. They are the same! The only thing red hat asked for centos is to remove the logos and names as they are copyrighted, the rest of it? They even collaborate on the centos mailing list to help centos developers!

If they expect to make money on the server side, they have focused in the wrong parts of it.

Of course all of this is my opinion. I could be wrong, I normally are

Isn't their main focus from software support?

Nothing wrong with wanting to bring it to the masses but I think Canonical's handing of the distro is questionable. They cheer it on as a community distro yet not of the big decisions have any input from the users. Like the situation with moving the window buttons to the left. They simply make those sort of changes around the distro and force them on their users whether they like it or not. I'm not an Ubuntu user so my opinion really doesn't mean much but is saddening to watch where Ubuntu is headed. That is the problem though when you have a for-profit company running the show.

Anybody who doesn't want the windows buttons on the left side should die. DIE!

 

[itxaka]

Sorry for the double post (maybe ok since it's been two hours.)

Any nice CLI or GTK apps that can monitor HDD usage?

Not like % usage, but reads/writes in MB/s, etc

I used conky + diskio before:

diskio (device)
Displays current disk IO. Device is optional, and takes the form of sda for /dev/sda. Individual partitions are allowed.
diskio_read (device)
Displays current disk IO for reads. Device as in diskio.
diskio_write (device)
Displays current disk IO for writes. Device as in diskio.
diskiograph (device) (height),(width) (gradient colour 1) (gradient colour 2) (scale) (-t) (-l)
Disk IO graph, colours defined in hex, minus the #. If scale is non-zero, it becomes the scale for the graph. Uses a logarithmic scale (to see small numbers) when you use -l switch. Takes the switch '-t' to use a temperature gradient, which makes the gradient values change depending on the amplitude of a particular graph value (try it and see).
diskiograph_read (device) (height),(width) (gradient colour 1) (gradient colour 2) (scale) (-t) (-l)
Disk IO graph for reads, colours defined in hex, minus the #. If scale is non-zero, it becomes the scale for the graph. Device as in diskio. Uses a logarithmic scale (to see small numbers) when you use -l switch. Takes the switch '-t' to use a temperature gradient, which makes the gradient values change depending on the amplitude of a particular graph value (try it and see).
diskiograph_write (device) (height),(width) (gradient colour 1) (gradient colour 2) (scale) (-t) (-l)
Disk IO graph for writes, colours defined in hex, minus the #. If scale is non-zero, it becomes the scale for the graph. Device as in diskio. Uses a logarithmic scale (to see small numbers) when you use -l switch. Takes the switch '-t' to use a temperature gradient, which makes the gradient values change depending on the amplitude of a particular graph value (try it and see).

Isn't their main focus from software support?

But for enterprises, not end users. That is what the community is for.

 

[zoku88]

I used conky + diskio before:





But for enterprises, not end users. That is what the community is for.

Cool, I'll try it out.

 

[itxaka]

Cool, I'll try it out.

I guess you could also use screenlets, but I don't use them so I cannot tell if the have an IO screenlet, they should have one thought and it's probably easier to configure than conky

EDIT: More ammunition for the war!

GNOME vs Canonical, Freedesktop.org - A Neutral Observation & Summary
Posted: Thursday, March 10, 2011 by Sankar in Labels: community, controversy, fdo, gnome, kde, planets, suse 22

Few sensational things happened last week in one of the oldest debates of the Linux community, GNOME vs KDE, touching on the topic of freedesktop.org and joined this time by the new hot topic, "GNOME vs Canonical". The bulk of the actions happened in the comments section of two blog posts, one by Dave Neary (1) , well-known GNOME advocate and another post by Aaron Seigo (2) , well-known KDE Developer. I want to improve my writing skills and the ability to get information from a community discussion. So, below is a step in that direction.

Disclaimer: All opinions are personal and none of the views expressed represent my employer, NASA, WHO or anyone else for that matter. The following is the juice of the events of last week written from a (as honest as possible) neutral perspective. Read through this post if you don't want to read through all the comments in the mentioned blog posts.

GNOME 3 release is just days away. Canonical and the GNOME community have taken different routes with Unity and gnome-shell respectively. Dave Neary wrote(1) a blog post with an analytic title "Has GNOME rejected Canonical's Help ? " . Neary cited instances of Canonical exhibiting behavior that shows discomfort in the Canonical-GNOME relationship.

The main point of contention was: rejection of libappindicator (3) by the GNOME release team roughly an year ago. appindicator is an implementation by Canonical for the management of system tray icons. It was brought under a specification titled "status notifier" to the freedesktop.org. Dan Winship and Matthias Clasen from GNOME have faced some severe issues with the specification and deemed (4) it unfit. The rejection reasons cited by the GNOME release team for appindicator were:

it doesn’t integrate with gnome-shell
probably depends on GtkApplication, and would need integration in GTK+ itself
we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen
there’s nothing in GNOME needing it

Neary asked for proofs of libappindicator proposal for gnome-shell and any convincing/rejection discussions following the proposal, if any. The openness and accountability of the gnome-shell development process can be known by such proofs.

Aaron Seigo of KDE blogged(2) about the controversy and used the opportunity to vent out his frustrations with GNOME. His post with an inflammatory title of "Collaboration's Demise" seem to indicate that the KDE project has faced severe pushbacks from GNOME for the ideas/standards proposed by KDE. Seigo feels in the last 5-6 years of freedesktop.org operations, GNOME seem to reject ideas based on a (Not Invented Here) NIH syndrome.

As expected, there were comments from GNOME people on Seigo's blogpost, though with a disclaimer that they don't officially respond on behalf of GNOME and are personal opinions. The main counterpoints by GNOME people that I could catch are:

The idea of appindicators was proposed sometime in 2008. But was not discussed in open after that for a long time.
Roughly 2 years after that initial proposal and without any open-discussions on the design, a big code drop was requested for libappindicator and proposing it as a external dependency.
The libappindicator also needed copyright reassignments to Canonical for any contributions. A practice that is being widely frowned upon in GNOME and FOSS projects in the recent times.

The main complaint from Seigo on his blog is that GNOME is deviating from freedesktop.org standards consistently in the last few years and this is unhealthy for cross desktop applications. He feels that appindicators is yet another symptom of this problem. It remains to be seen if this is the personal opinion of Seigo or if the KDE Board/Project too feels the same.

In addressing the events of the past week, Mark Shuttleworth has posted a blog (5) and accused the GNOME leadership (probably referring to the release team and Board, which is unclear from his blog) that the environment in GNOME is not conducive for internal competition. He believes that internal groupism in GNOME is killing baby ideas from anyone outside the group. The tone of the post is harsh towards the GNOME leadership and is filled with advice. Towards the end of his post, Shuttleworth notes that strengthening the partnership with KDE and freedesktop.org is the way forward and is more fruitful than convincing GNOME.

It may be an eventful time in the next few days to see how the GNOME community reacts to this. There will be a blog post by Jeff Waugh for sure, atleast, it seems. As of now, RedHat the biggest investor in GNOME and we expect no change in their stance. Novell seem to be happy with the way things are going in upstream and will stay close to it, it seems. Canonical is toying around with the idea of creating new cross-desktop standards and make Unity more popular. They seem to have appealed to some people in the KDE camp atleast (like Seigo). But it remains to be seen if this newly forged friendship is exposing real problems with GNOME or it is just a temporary sensationalism that will subside soon.

During the next Desktop summit, the GNOME and KDE boards have a huge task of ironing out the difference of opinions between GNOME and KDE people regarding the freedesktop.org processes. I don't know if everyone in KDE camp feel that GNOME is blocking changes in fdo or it is a perception of a few people like Seigo only.

My Take:

+ Most of these problems could've been minimized if Canonical have done their work in GNOME git repositories instead of doing it in their own private space. Nobody likes huge code drops. Doing things in private and opening up later is not a correct behavior in any open source community. They should have learned from the past mistakes like: Novell's gnome-main-menu, Android's Wakelocks etc.

+ Involvement with the community should begin as early as possible. It is not okay to assume, "We are special and we will get our way through even if we involve community in the end."

+ As is said in every GUADEC, GNOME is People. If Shuttleworth is unhappy with the leadership of GNOME, the way to fix it is not by doing things in private or by working with KDE/freedesktop.org (which is good but won't solve perceived problems with GNOME), the right way is to get involved with GNOME. How many Canonical employees are part of the GNOME Release team ? How many Canonical employees have ever been part of the release team ? Employ more people to work in upstream so that you can influence GNOME decisions. Grab the steering if you want to drive, don't be a back-seat driver.

+ There may be serious problems with the way freedesktop.org is managed if the complaints by Seigo are shared by many people in the KDE community.

Links:
1 - http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/
2 - http://aseigo.blogspot.com/2011/03/collaborations-demise.html
3 - http://mail.gnome.org/archives/devel-announce-list/2010-June/msg00001.html
4 - http://aseigo.blogspot.com/2011/03/...howComment=1299623993569#c1004728938259200386
5 - http://www.markshuttleworth.com/archives/654

Some of my observations have been wrong. If so, it is just because of mistake and not because of bad intent. Please let me know and I will correct myself. Thanks.

 

[sasimirobot]

trying to install Ubuntu netbook remix today. Will update later

 

[itxaka]

And Mark answers, but cherry picking comments and not addresing the whole thing only the points he wants to discuss.

Competition is tough on the contestants, but it gets great results for everyone else. We like competitive markets, competitive technologies, competitive sports, because we feel the end result for consumers or the audience is as good as it possibly could be.

In larger organisations, you get an interesting effect. You get *internal* competition as well as external competition. And that’s healthy too. You get individuals competing for responsibility, and of course you want to make sure that the people who will make the wisest choices carry the responsibilities that demand wisdom, while those who have the most energy carry the responsibilities for which that’s most needed. You get teams competing with each other too – for resources, for attention, for support elsewhere, for moral authority, for publicity. And THAT’s the hardest kind of competition to manage, because it can be destructive to the organisation as a whole.

Even though it’s difficult to manage, internal competition is extremely important, and should not be avoided out of fear. The up side is that you get to keep the best ideas because you allowed them to compete internally. If you try and avoid it, you crowd out new ideas, and end up having to catch up to them. Usually, what goes wrong is that one group gets control of the organisation’s thinking, and takes the view that any ideas which do not come from within that group are a threat, and should be stopped. That’s very dangerous – it’s how great civilisations crash; they fail to embrace new ideas which are not generated at the core.

In Ubuntu, we have a lot of internal competition. Ubuntu and Kubuntu and Xubuntu and Edubuntu and *buntu-at-large have to collaborate and also, to a certain extent, compete. We handle that very well, I think, though occasionally some muppet calls Kubuntu the blue-headed-stepchild etc etc. It’s absolutely clear to everyone, though, that we have a shared interest in delivering ALL these experiences together with as much shared vision and commonality as possible. I consider the competition between these teams healthy and constructive and worth maintaining, even though it requires some fancy footwork and causes occasional strains.

The challenge for Gnome leadership

The sound and fury writ large in blog comments this week is all about how competition is managed.

Gnome is, or should be, bigger than any of the contributing individuals or companies. Gnome leadership should be in a position to harness competition effectively for the good of the project. That does, however, require very firm leadership, and very gutsy decisions. And it requires vigilance against inward thinking. For example, I’ve seen the meme reiterated multiple times that “one should not expect Gnome to embrace ideas which were not generated and hosted purely within Gnome”. That’s chronic inward thinking. Think of all the amazing bits of goodness in the free software stack which were NOT invented in Gnome but are a part of it today. Think how much better it is when goodness is adopted across multiple desktop environments, and how much harder it is to achieve that when something is branded “K” or “G”.

When we articulated our vision for Unity, we were very clear that we wanted to deliver it under the umbrella of Gnome. We picked Gnome-friendly technologies by and large, and where we felt we needed to do something different, that decision required substantial review. We described Unity as “a shell for Gnome” from the beginning, and we have been sincere in that view. We have worked successfully and happily with many, many Gnome projects to integrate Unity API’s into their codebase.

This is because we wanted to be sure that whatever competitive dynamics arose were *internal* to Gnome, and thus contributing to a better result overall in Gnome in the long term.

We’ve failed.

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

The key example of that is the rejection of Unity’s indicator API’s as external dependencies. That was the opportunity to say “let’s host this competition inside Gnome”. Even now, there’s a lack of clarity as to what was intended by that rejection, with some saying “it was just a reflection of the fact that the API’s were new and not used in any apps”. If that were the case, there would be no need for prior approval as an external dependency; the rejection was clearly an attempt to prevent Gnome applications from engaging around these API’s. It’s substantially failed, as many apps have happily done the work to blend in beautifully in the Unity environment, but there has been a clear attempt to prevent that by those who feel that Unity is a threat to Gnome rather than an opportunity for it.

Dave Neary has to his credit started to ask “what’s really going on here”?

In his blog post, he quoted the rationale given for the rejection of Canonical’s indicator API’s, which I’ll re-quote here and analyze in this light:

it doesn’t integrate with gnome-shell

That’s it – right there. Remember, this was a proposal for the indicator API’s to be an *external* dependency for Gnome. That means, Gnome apps can use those API’s *optionally* when they are being run on a platform where they are useful. It has NOTHING to do with the core Gnome vision. External API’s exist precisely BECAUSE it’s useful to encourage people to use Gnome apps on all sorts of platforms, including proprietary ones like Windows and MacOS and Solaris, and they should shine there too.

So the premier reason given for the rejection of these API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

Now, I can tell you that I was pretty disgusted with this result.

We had described the work we wanted to do (cleaning up the panel, turning panel icons into menus) to the Gnome Shell designers at the 2008 UX hackfest. McCann denies knowledge today, but it was a clear decision on our part to talk about this work with him at the time, it was reported to me that the conversation had happened, and that we’d received the assurance that such work would be “a valued contribution to the shell”. Clearly, by the time it was delivered, McCann had decided that such assurances were not binding, and that his interest in an alternative panel story trumped both that assurance and the now-extant FreeDesktop.org discussions and spec.

But that’s not the focus of this blog. My focus here is on the management of healthy competition. And external dependencies are the perfect way to do so: they signal that there is a core strategy (in this case whatever Jon McCann wants to do with the panel) and yet there are also other, valid approaches which Gnome apps can embrace. This decision failed to grab that opportunity with both hands. It said “we don’t want this competition WITHIN Gnome”. But the decision cannot remove the competitive force. What that means is that the balance was shifted to competition WITH Gnome.

probably depends on GtkApplication, and would need integration in GTK+ itself

Clearly, both of these positions are flawed. The architecture of the indicator work was designed both for backward compatibility with the systray at the time, and for easy adoption. We have lots of apps using the API’s without either of these points being the case.

we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

We made the proposal, it was rejected. I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”. But proposing an *external* dependency is not the same as trying to convince Shell to adopt something as the mainstream effort. It’s saying “hey, here’s a valid set of API’s apps might want to embrace, let’s let them do so”.

there’s nothing in GNOME needing it

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”. You’re either saying “we just rubber stamp stuff here, go ahead and use whatever you want”, or you’re being asinine.

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

And finally, it’s predicating this decision on the idea being “in Gnome” is the sole criterion of goodness. There is a cross-desktop specification which defines the appindicator work clearly. The fact that KDE apps Just Work on Unity is thanks to the work done to make this a standard. Gnome devs participated in the process, but appeared not to stick with it. Many or most of the issues they raised were either addressed in the spec or in the implementations of it. They say now that they were not taken seriously, but a reading of the mailing list threads suggests otherwise.

It’s my view that cross-desktop standards are really important. We host both Kubuntu and Ubuntu under our banner, and without such collaboration, that would be virtually impossible. I want Banshee to work as well under Kubuntu as Amarok can under Ubuntu.

What can be done?

This is a critical juncture for the leadership of Gnome. I’ll state plainly that I feel the long tail of good-hearted contributors to Gnome and Gnome applications are being let down by a decision-making process that has let competitive dynamics diminish the scope of Gnome itself. Ideas that are not generated “at the core” have to fight incredibly and unnecessarily hard to get oxygen. Ask the Zeitgeist team. Federico is a hero, but getting room for ideas to be explored should not feel like a frontal assault on a machine gun post.

This is no way to lead a project. This is a recipe for a project that loses great people to environments that are more open to different ways of seeing the world. Elementary. Unity.

Embracing those other ideas and allowing them to compete happily and healthily is the only way to keep the innovation they bring inside your brand. Otherwise, you’re doomed to watching them innovate and then having to “relayout” your own efforts to keep up, badmouthing them in the process.

We started this with a strong, clear statement: Unity is a shell for Gnome. Now Gnome leadership have to decide if they want the fruit or that competition to be an asset to Gnome, or not.

A blessing in disguise

Aaron’s blog post made me think that the right way forward might be to bolster and strengthen the forum for cross-desktop collaboration: FreeDesktop.org.

I have little optimism that the internal code dynamics of Gnome can be fixed – I have seen too many cases where a patch which implements something needed by Unity is dissed, then reimplemented differently, or simply left to rot, to believe that the maintainers in Gnome who have a competitive interest on one side or the other will provide a level playing field for this competition.

However, we have shown a good ability to collaborate around FD.o with KDE and other projects. Perhaps we could strengthen FreeDesktop.org and focus our efforts at collaboration around the definition of standards there. Gnome has failed to take that forum seriously, as evidenced by the frustrations expressed elsewhere. But perhaps if we had both Unity and KDE working well there, Gnome might take a different view. And that would be very good for the free software desktop.

 

[Vanillalite]

Bitches can't even get by arguing amongst themselves, and I've always felt the nix community felt they liked to triumph open source but you can only be involved if your in their little click. Then people wonder why nix has problems taking off against say MS or Apple. LOL

Who's right and who's wrong? They probably all are to a certain degree. It is sort of hilarious to watch though, and nice that we have this thread to comment on things outside of the normal nix channels where I'd never comment on such a thing.

 

[Vagabundo]

As long as they keep delivering excellent software they can blog-war all they like.

 

[Vanillalite]

OpenSuse Website!

Grats for all of the OpenSuse fans out there!

 

[zoku88]

I guess you could also use screenlets, but I don't use them so I cannot tell if the have an IO screenlet, they should have one thought and it's probably easier to configure than conky

how accurate is the diskio part of conky? I'm downloading a file at about ~50KB/s, but it doesn't seem to show up in the write section, maybe.

Unless transmission does something really strange, like buffer to RAM or something and does delayed writes to the HDD (which would explain, I guess, why I get seemingly random spikes on that HDD.)

 

[Elfforkusu]

I don't have a comment on Canonical vs GNOME in general, but this Banshee thing is an obvious dick move and Canonical are worse people for it. I hope they at least (internally) realize how much they're being assholes.

 

[itxaka]

how accurate is the diskio part of conky? I'm downloading a file at about ~50KB/s, but it doesn't seem to show up in the write section, maybe.

Unless transmission does something really strange, like buffer to RAM or something and does delayed writes to the HDD (which would explain, I guess, why I get seemingly random spikes on that HDD.)

No idea, but you can always launch a terminal with iostat* to see if it matches conky and find out if transmission does delayed writes to the hdd, which I suspect it does to maximize disk performance.


*http://www.cyberciti.biz/tips/linux-disk-performance-monitoring-howto.html
*http://linuxcommand.org/man_pages/iostat1.html

 

[zoku88]

No idea, but you can always launch a terminal with iostat* to see if it matches conky and find out if transmission does delayed writes to the hdd, which I suspect it does to maximize disk performance.


*http://www.cyberciti.biz/tips/linux-disk-performance-monitoring-howto.html
*http://linuxcommand.org/man_pages/iostat1.html

Haha, another sys-app that I should get.

I was really bad at install good apps for reporting various informations. XD

 

[itxaka]

Haha, another sys-app that I should get.

I was really bad at install good apps for reporting various informations. XD

Then another one which I believe is incredibly useful and really forgotten.

ntop

It monitors the network and set ups a localhost page with lots of info. Protocols used, clients connected, bandwith, times and days usage, etc...

It's one of the first tools I install on my distros.

And of course it's as easy as apt-get install ntop, pacman -S ntop, emerge ntop, yum install ntop, whatever ntop, ....

 

[zoku88]

Well, the information seems the same-ish, so I guess it was fine. I decided to add IO graphs and from the looks of it, the device transmission is writing to indeed does have periodic spikes. So I guess it must be buffering.

Of course, this is really just an excuse to fool around with the conky rc some. kekeke

Yea, one of my friends, I believe, gets a lot of use out of ntop on his VPS. (though, maybe not, since it looks graphical, which would be no good for something remote.)

 

[itxaka]

Well, the information seems the same-ish, so I guess it was fine. I decided to add IO graphs and from the looks of it, the device transmission is writing to indeed does have periodic spikes. So I guess it must be buffering.

Of course, this is really just an excuse to fool around with the conky rc some. kekeke

Yea, one of my friends, I believe, gets a lot of use out of ntop on his VPS. (though, maybe not, since it looks graphical, which would be no good for something remote.)

Maybe it's iftop?

Or IPtraff?

there is way too many tools in linux goddamm.

 

[itxaka]

And a new batch of gnome VS canonical starts.

Canonical is getting hit harder than expected. Even from one of the founding employees of Canonical.

http://bethesignal.org/blog/2011/03/12/the-libappindicator-story/ -> Great article, points out the exact dates of everything

http://blogs.gnome.org/bolsh/2011/03/11/lessons-learned/

http://nathaniel.themccallums.org/2011/03/10/i-hate-to-say-i-told-you-so/

 

[itxaka]

Triple posting FTW!

Quicklook at Opensuse 11.4 http://eyeonlinux.com/2011/03/10/quick-look-opensuse-11-4/3/

The default them still looks off. Yast has gotten better but it's not up to par with synaptic.

 

[zoku88]

Wow, i thought I had responded to the one about iftop.

Yea, I think iftop is a more likely candidate for what he uses.

I should really give Opensuse a go one of these days, but... from the screens.... does it use KDE? :-/

 

[Vanillalite]

Wow, i thought I had responded to the one about iftop.

Yea, I think iftop is a more likely candidate for what he uses.

I should really give Opensuse a go one of these days, but... from the screens.... does it use KDE? :-/

Looks like your gonna keep saying you should give it a try cause the suse be all about the kde up in there.

 

[Vanillalite]

On a side note Bodhi Linux shipped a 3rd RC over the weekend and they plan on going final by the end of march baring any ZOMGWTF bugs.

YAY I finally get to try out enlightenment!

 

[itxaka]

Hell yeah!

GNU Call announced, a project to substitute Skype.

http://planet.gnu.org/gnutelephony/?p=14

“Free as in freedom, and free as in no cost, too!”

GNU Free Call is a new project to develop and deploy secure self-organized communication services worldwide for private use and for public administration. We use the open standard SIP protocol and GNU SIP Witch to create secured peer-to-peer mesh calling networks, and we welcome all participation in our effort.

Who
Haakon Eriksen – Project Coordinator - haakon.eriksen@far.no

David Sugar – Project Architect - dyfet@gnu.org

What
Our goal is to make GNU Free Call ubiquitous in a manner and level of usability similar to Skype, that is, usable on all platforms, and directly by the general public for all manner of secure communication between known and anonymous parties, but without requiring a central service provider to register with, without using insecure source secret binary protocols that may have back-doors, and without having network control points of any kind that can be exploited or abused by external parties. By doing so as a self organizing meshed calling network, we further eliminate potential service control points such as through explicit routing peers even if networks are isolated in civil emergencies.

We do recognize this project has significant long term social and political implications. It also offers potentially essential utility in public service by enabling the continuation of emergency services without requiring existing communication infrastructure. There are many ordinary public service uses, such as the delivery of eHealth services, as well as medical, and legal communication, where it is essential to treat all with equal human dignity by maintaining privacy regardless of race, religion, or political affiliation. Equally important is the continuation of emergency medical services even when existing infrastructure is no longer available or has been deliberately disabled.

How
Initially we will extend sipwitch to become aware of peer nodes by supporting host caches, and then support publishing of routes to connected peers. This work builds upon the already existing routing foundation in sipwitch itself. The use of host caches is a mechanism used in older p2p networks, it is generally well understood, it would meet the initial goals of establishing a self organized mesh network, and it is rather easy to initially implement to fully demonstrate the potential of sipwitch as a mesh calling system. More advanced methodologies can then be added later on.

Related to this goal is having sipwitch operate as a SIP mediation service for desktops users and IP enabled cell phones such as Android. This introduces the needs for users to be able to “pilot” their local sipwitch instance through a desktop and cell phone gui, whether to see what calls are being placed through it, or to see the verification status of secure key exchange. There are today IPC interfaces in sipwitch to allow for desktop integration, but a specific GUI to use these interfaces and present server and call states in a manner for people to understand still needs to also be constructed, and hence this too is part of the plan of work for this project.

In addition we will be extending GNU SIP Witch to offer secure VoIP proxy. Much like what was done initially by Phil Zimmerman to develop ZRTP using zfone, this mode of operation will enable development of key elements of a secure infrastructure without having to also initially create new SIP user agent applications. By offering secure proxy through a SIP Witch instance running at the endpoint, any existing SIP standard compliant softphone or device will be able to establish a secure connection to another standard compliant SIP device or SIP peer that is using GNU SIP Witch at the destination.

This project’s definition of secure media is similar to Zimmermann’s work on ZRTP, in that we assure there is no forwarding knowledge by using uniquely generated keys for each communication session. Furthermore, we will use GNU Privacy Guard (GPG) to fully automate session validation. This will be done by extending the SIP protocol to exchange public keys for establishing secure media sessions that will be created by each instance of SIP Witch operating at the end points on behalf of local SIP user agents, and then verifying there is no man-in-the-middle by exchanging GPG signed hashes of the session keys that were visible at each end.

Why

1. Why GNU SIP Witch?
GNU SIP Witch is a destination router for the SIP protocol. This means it is primarily concern is not in making things interconnect “with” the SIP Witch Server, like say something like Asterisk does very well, but rather instead is designed to enable two (or more) endpoints to find and then directly connect with each other. By handing off media operations directly to communicating endpoints, GNU SIP Witch requires a minimum of system resources, making it very suitable even for low end embedded routers, as well as for freedom boxes, shared virtual server instances, desktop systems, and IP connected cell phones such as Android, rather than requiring a dedicated server.

2. Why on the desktop and cell phone?
Ultimately we want to be close to the user so that no third party or external service must be connected to before establishing secure sessions since we are using unmodified SIP clients. If an external party is required, the connection between the SIP client and that external service would of course be completely insecure. A user with their own local infrastructure can of course also run a single sipwitch server, such as on a freedom box or a virtual machine, to meet all their local connectivity needs rather than doing so on each machine or device. An organization can also run a sip witch server on a completely remote site, such as a public portal, when interconnecting existing security enabled SIP clients, such as SIP Communicator and Twinkle, which support the ZRTP protocol stack. Another side benefit of having SIP Witch on the desktop and cell phone is that as we develop SIPWitch NAT services, it can act as a single point of contact for mediating all SIP protocol services for a user, as well as offering a single place where NAT support and mobile re-connection will only need to be configured and implemented once, rather than in each SIP client separately.

3. How to get GNU SIP Witch?
GNU SIP Witch is formally distributed as a package that is part of the GNU Project. It is also packaged in a number of popular GNU/Linux distributions, including Ubuntu and Fedora, GNU SIP Witch can also be built on most BSD systems from source, including OS/X, and supports compilation on Microsoft Windows as well.

4. How to configure GNU SIP Witch?
In the past GNU SIP Witch has been difficult to configure, even for ordinary uses. To address this issue we are hoping to finally introduce a model public portal that anyone will also be able to download and use to construct and configure a SIP Witch site or private service. To address the needs of peer-to-peer calling, we are introducing a desktop and cell phone GUI interface.

5. Why do I need a local SIP account to use it?
Since GNU SIP Witch is a SIP service one needs a SIP identity to authenticate yourself to your own local SIP server. However, we wish to eliminate manually creating local SIP users by offering to automatically detect and generate a local user account with a matching SIP user agent configuration for you as a single click operation from the new GUI. Initial clients proposed for this include Android CSipSimple, which is also being extended with GNU ZRTP, the Twinkle Softphone, and perhaps SIP Communicator, which uses the GNU ZRTP4J stack. Other clients, like GNOME Empathy and Linphone, may also be supported in this way as well.

6. How can I participate?
We have a wiki site used for GNU Telephony as a whole (http://www.gnutelephony.org/), as well as a mailing list for sipwitch itself (sipwitch-devel@gnu.org). In addition, to discuss core architecture, privacy issues, and social consequences, we have another mailing list gnucomm-privacy@gnu.org.

About fucking time. I'm so pissed off at Skype. Half of the time it locks up when starting, does not really updates which contacts are connected or not until you force a call to them, the linux client is CRAP, the stupid bars it installs lock up the browsers. FUCK SKYPE BRING GNU CALL ASAP!

 

[Vanillalite]

Woah fucking balling. The bigger thing is beyond being a Skype like client that'll be open source and has to be better or more featured than what Skype has now for Linux, is the idea of what I read to be like personal nodes.

I could have read this wrong, but IDK I almost got a Diaspora like analogy in that this would be something where you sort of own your connection to the world. So your not beholden to some 3rd party for it to really work, and that will also help in terms of keeping it secure as well as anon if you want.

If the incorporate some way to incorporate public/private keys (maybe allow you to add a full key ring?) at least in terms of adding people to your lists that would be legit.

Hell just having a open source version with feature parity on Linux like Win and OSX would be nice since alot of programs that work on all platforms still give nix the shaft with a shitty version.

 

[zoku88]

SIP confuses me. I don't think I even understand which I just read XD

 

[panda21]

i just have to have a little rant about arch linux here. i've tried it before but didnt use it long, and it seemed ok. but i've just started using it again now and as much as it is cool that people are making distros like this there are some really annoying things about it.

the whole thing just feels very amateur, as if they mean well but don't really know what they are doing. it seems like whenever I am installing something missing dependencies are the rule rather than the exception, at least for the AUR. there was even a python program that didnt have python as a dependency. people seem to just try to make a list of the stuff they reckon they had to install to be able to build the software, rather than actually figuring out what the dependencies are, and frequently you will see 'oh yeah lol i didnt realise i had that installed too, i'll add it to the dependencies' from the package author in the comments (and then they dont add it to the dependencies). i guess since its the user repo that could be excused, except it seems there is way too much reliance on it, and things that really ought to be in the main repos are instead just poorly maintained in the AUR.

but that sloppiness seems to extend even to the main repositories, like for example yesterday all of a sudden you couldnt install xorg on a fresh system because they had updated it in a way that broke the packages because of a conflict. how does that even happen? do they not test packages in the official repositories before they update them? and the response on the forums was just to wait because it was a problem with xorg being changed upstream. well then maybe they shouldn't have updated the arch packages until the problem was fixed?!

maybe i've been spoilt with debian but i seem to remember something else really dumb happening with arch when they decided to update to python 3 as well, and my experiences recently have just lowered my opinion of arch even further.

 

[-KRS-]

i just have to have a little rant about arch linux here. i've tried it before but didnt use it long, and it seemed ok. but i've just started using it again now and as much as it is cool that people are making distros like this there are some really annoying things about it.

the whole thing just feels very amateur, as if they mean well but don't really know what they are doing. it seems like whenever I am installing something missing dependencies are the rule rather than the exception, at least for the AUR. there was even a python program that didnt have python as a dependency. people seem to just try to make a list of the stuff they reckon they had to install to be able to build the software, rather than actually figuring out what the dependencies are, and frequently you will see 'oh yeah lol i didnt realise i had that installed too, i'll add it to the dependencies' from the package author in the comments (and then they dont add it to the dependencies). i guess since its the user repo that could be excused, except it seems there is way too much reliance on it, and things that really ought to be in the main repos are instead just poorly maintained in the AUR.

but that sloppiness seems to extend even to the main repositories, like for example yesterday all of a sudden you couldnt install xorg on a fresh system because they had updated it in a way that broke the packages because of a conflict. how does that even happen? do they not test packages in the official repositories before they update them? and the response on the forums was just to wait because it was a problem with xorg being changed upstream. well then maybe they shouldn't have updated the arch packages until the problem was fixed?!

maybe i've been spoilt with debian but i seem to remember something else really dumb happening with arch when they decided to update to python 3 as well, and my experiences recently have just lowered my opinion of arch even further.

Are you using "yaourt" for AUR? It's a wrapper for pacman that downloads PKGBUILD files from AUR and compiles them for you. If there are any deps, they are installed first etc. I can't say that I've ever had issues with dependencies using arch linux. Most things are in the repos though, provided you uncommented them in the pacman.conf file so you actually use them. The community repo has a lot of stuff.

Yaourt: https://wiki.archlinux.org/index.php/Yaourt

Broken packages do happen, but they are very rare. I recently had issues with my wifi not working after an upgrade, and it had to do with consolekit. Once I downgraded consolekit to the previous version, it worked again. It still hasn't been fixed for some reason, and I agree that it seems very sloppy. Though the guy who was assigned the bug is also assigned to almost 2000 other bugs. So I understand it takes some time.
But they upgraded it because it does in fact work. Just not on some few computers for some reason. I've never had any issues with xorg or python3 though.

I hope you're not using the testing and community-testing repos, because then it's no wonder you have issues with broken stuff.

 

[itxaka]

i just have to have a little rant about arch linux here. i've tried it before but didnt use it long, and it seemed ok. but i've just started using it again now and as much as it is cool that people are making distros like this there are some really annoying things about it.

the whole thing just feels very amateur, as if they mean well but don't really know what they are doing. it seems like whenever I am installing something missing dependencies are the rule rather than the exception, at least for the AUR. there was even a python program that didnt have python as a dependency. people seem to just try to make a list of the stuff they reckon they had to install to be able to build the software, rather than actually figuring out what the dependencies are, and frequently you will see 'oh yeah lol i didnt realise i had that installed too, i'll add it to the dependencies' from the package author in the comments (and then they dont add it to the dependencies). i guess since its the user repo that could be excused, except it seems there is way too much reliance on it, and things that really ought to be in the main repos are instead just poorly maintained in the AUR.

but that sloppiness seems to extend even to the main repositories, like for example yesterday all of a sudden you couldnt install xorg on a fresh system because they had updated it in a way that broke the packages because of a conflict. how does that even happen? do they not test packages in the official repositories before they update them? and the response on the forums was just to wait because it was a problem with xorg being changed upstream. well then maybe they shouldn't have updated the arch packages until the problem was fixed?!

maybe i've been spoilt with debian but i seem to remember something else really dumb happening with arch when they decided to update to python 3 as well, and my experiences recently have just lowered my opinion of arch even further.

Totally agreed. But you have to consider that Arch is a "Rolling release" distro which means that some packages can be broken when they are just updated due to old mirrors or a overlook.

AUR is kind of hit or miss. It being maintained by the userbase means that normally there is some packages wrongly configured or with missing dependencies but oh well, it's the price to pay for having bleeding edge packets

 

[-KRS-]

Oh one other thing that broke for me yesterday actually was BIND on my server...
Yeah I didn't like that one bit. Apparently, the configuration for running a chrooted named daemon had changed. So it couldn't start the daemon as usual because of some error. But the error is not printed when you launch rc.d files. So I tried running it manually, but it didn't say anything at all. It looked as if it started, meaning there was nothing printed out at all, but then when checking with ps aux, it wasn't there.

It was basically a wild guess to check the Arch Wiki page for bind if something had changed. Had to start the named daemon as usual without chrooting, go to the arch wiki and look, saw that it was indeed different, then changed the /etc/rc.d/named-chroot file so it was up to date. After that it worked. But you'd think they would somehow inform you of this. I guess it's not easy to do in a good way though, other than updating the main site. But they didn't even do that...