sorted by: recent | see :
popular
Content Tagged Ubuntu
Sebastian Kügler: Are we breathing in the same rhythm?
Tom and
Aaron
discuss timing and release schedules, and development cycles. Aaron talks
about trunk/ and freezes therein should follow a natural lifecycle. This assumes that
the whole KDE community lives and breathes as one individual, synchronised and all.
So a development-and-release-cycle forces all developers into one rhythm. Everyone
has to follow this one release rhythm. It's a good idea, but I think we should also
make the lives of those that choose another breathing ryhthm.
There are a couple of things to consider here. The most obvious being that we need this
flexibility anyway. We rely on certain release mechanisms and interface stability
policies in other projects as well. (We partly solve this problem by providing abstraction
layer, think phonon and solid). Now the interesting case is that Phonon, which is new in
Qt's 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle
in Qt, and a 6 months one in KDE. So one could argue that it's a smart idea to breathe
in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
This does not solve the initial problem I think, which I think is "different parts of KDE breathe have different heartbeats". Neither Tom nor Aaron have really questioned the way we currently deal with SVN before releases, so I'll put on my shiny pink asbestos suit and do it. What if we never froze trunk? Others (such as, incidentally Qt) have no freezes in trunk/ and it seems to be a popular and well-working development style for some. When a release enters a freeze, a branch is created that will be stabilised towards the release. trunk/ at the same time stays open for feature additions. The Golden Rule is "You don't break trunk/ (this is what branches are for)". (For those not too intimate with development schedules of KDE: trunk/ is frozen roughly 2 months in advance of a release (supposedly every 6 months). After the actual release, trunk/ is opened again for new features. Features that take longer than the allotted time be developed in a branch and moved into trunk/ "when they're ready, but not during freeze".)
The obvious downside of this "It's always summer in trunk" is that you need to
spend extra efforts to get people
to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more
discipline, and probably puts some extra weight on the shoulders of those who simply
care about good KDE releases. But as we all agree,
SVN sucks for branching and merging. So right now we make it hard for people to work
with different branches (stable/ and trunk/).
It would allow those that need more time to
do their thing to stay in sync with latest features. Basically, it would allow for
different rhythms in the community. As this community grows and becomes more diverse
this might pay off in the end.
New tools are on the horizon as well. Distributed version control systems allow
for a more flexible way of sharing code between peers.
Ubuntu Linux fête le lancement de sa version 8.4
logiquelibre posted a photo:
Ubuntu-QC invite tous ceux qui attendent avec impatience la sortie de la nouvelle version (8.04) de la célèbre distribution Linux Ubuntu à venir fraterniser, le jeudi 24 avril prochain, à partir de 18h, au Bar Le St-Sulpice, rue St-Denis à Montréal. Ces rencontres sont devenues une tradition au sein de l'univers des utilisateurs d'Ubuntu, qui saluent ainsi entre amis et utilisateurs l'arrivée des nouvelles versions. D'autres rencontres s'organisent ailleurs au Québec.
Ubuntu QA blog: Ubuntu Brainstorm keeps growing
Hello everybody,
In less than two weeks, the Ubuntu Developer Summit will take place, and the best ideas out there will be reviewed (See the previous post)! Meanwhile, we just upgraded Ubuntu Brainstorm:
|
Developer comments
For a better visibility, developer comments now appear on the idea list pages. You can now quickly check the developers feedback on ideas. Expect some updates during the Ubuntu Developer Summit!
|  |
|
Bookmarks
As requested by frandavid100 and many others, it is now possible to bookmark ideas. Just click on the star, and it's bookmarked. You can now easily follow the development of ideas that matters to you!
|  |
|
User infos and stats
The user page has been reworked to provide you much more infos and stats. You can now see the ideas a user posted, which ideas he voted down or up, the latest reactions to ideas he commented, his bookmarks, and some nice stats. And the best idea contributor so far is ... Ubuwu!!
|  |
|
New categories lists
Categories ideas can now be browsed in two more differents ways: latest ideas and most popular this month.
|  |
|
Get rid of bug submissions
Finally, idea can now be marked as "Not an idea" by moderators.This will hopefully prevent further non-ideas, generally bugs, to be submitted on Ubuntu Brainstorm. Please remember that Brainstorm is a place to post ideas only! Any bugreports posted here won't be looked at. To report a bug, please use the Ubuntu bug tracker.
|  |
Jordan Mantha: bzr, git, and hg performance on the Linux tree
OK, so I just did a historical comparison of git and bzr performance using the Linux source tree. One of the comments I got was “what about Mercurial?” Fair enough. I’ve really never done much with Mercurial because Ubuntu primarily uses bzr and git is what most of the other people I know using a DVCS use. However, there are a lot of projects using Mercurial, Mozilla being probably the most notable one. So, here’s a comparison of bzr and hg. You may want to read my previous post for details on the steps I’m doing.
Repo Initialization:
git              bzr            hg
0m0.086s    0m0.334s    0m0.137s
1Â Â Â Â Â Â Â :Â Â Â Â Â Â Â 3.88Â Â Â Â Â :Â Â Â Â 1.59
Add 2.6.0 Linux tree:
git             bzr            hg
0m14.269s   0m4.852s    0m2.526s
5.65Â Â Â Â :Â Â Â Â 1.92Â Â Â Â Â : Â Â Â 1
Commit 2.6.0 Linux tree:
git           bzr            hg
0m10.263s  0m43.968s   0m30.890s
1Â Â Â Â Â Â :Â Â Â Â Â 4.28Â Â Â Â :Â Â Â Â 3.01
Diff after copying in 2.6.25.2 Linux tree:
git             bzr            hg
0m24.425s  0m51.158s   0m37.846s
1Â Â Â Â Â Â Â :Â Â Â Â Â Â 2.09Â Â Â Â Â : Â Â Â 1.55
Committing large changes:
git             bzr            hg
0m28.468s  1m8.627s    0m47.948s
1 Â Â Â Â : Â Â Â Â Â Â 2.41Â Â Â Â : Â Â Â Â 1.68
Diff after no changes:
git             bzr            hg
0m0.343s   0m47.448s   0m1.340s
1Â Â Â Â Â Â Â : Â Â Â Â 138Â Â Â Â Â :Â Â Â Â 3.91
Getting repo status after no changes:
git             bzr            hg
0m1.230s    0m4.027s    0m1.077s
1.14Â Â Â Â Â :Â Â Â Â 3.74Â Â Â Â Â : Â Â 1
Committing a trivial change:
git             bzr            hg
0m0.397s   0m9.010s     0m1.913s
1Â Â Â Â Â :Â Â Â Â Â Â 22.7Â Â Â Â Â Â : Â Â Â 4.82
Repository size (just VCS control directory):
git (gc) Â Â Â Â bzr (pack)Â Â Â Â Â hg
92 MBÂ Â Â Â Â Â Â Â 112 MBÂ Â Â Â Â Â Â Â Â 179 MB
So, Mercurial performs quite well. It generally sits somewhere between git and bzr. Hg runs somewhere around 2.75 times slower than git in the tested operations. Bzr runs around 5 times slower with the notable exception that bzr diff when there are no changes is 138 times slower than git and 35 times slower than Hg.
Tiago Faria: Choose how to read our Planets (Update: Screenshot)
Can you tell I’m bored and unemployed?!
Yesterday I blogged about the Jabber bot, which, by the way, has more available feeds, including Planet Gnome and Planet Debian (rss-list to get a complete list). Today I decided to keep playing with the Planets and decided to implement an idea Joey had for Planet Debian.
I installed and configured rss2email and set up two different mailing lists; one for Planet Ubuntu and another one for Planet Ubuntu Users.
You can subscribe using the web-based form at: rss2email.ubuntuweblogs.org
Even though messages can be in HTML format, I decided to go with plain text. I would really like to hear someone else’s opinion on which format to use.
If you have any recommendations, please, let me know. Comments are open again, but only if people start behaving. If you’re going to say something stupid please don’t write anything at all.
P.S.: Stephan Hermann, thanks buddy! ;)
Copyright © 2008 Tiago 'gouki' Faria
This feed is for personal, non-commercial use only.
Ubuntu Remote Desktop
bodycoach2 posted a photo:
The "Terminal Server Client" in Ubuntu is like Remote Desktop Connection in Windows. This shows me remoting into my work computer, and transferring a file to my local (laptop) computer.
Christer Edwards: A Root Shell On Ubuntu : The Right Way
Just the other day we were having a discussion on using the root shell in Ubuntu. Now, remember, the root user account is disabled with no assigned password on a default Ubuntu system so administrative tasks need to be done using the sudo command. For nearly all of the administration you would need sudo will be adequate. There are occasionally those fringe cases where you might require a root shell. Below I have a few alternatives and then, if you must, the correct way of opening a root shell.
For more information please see the RootSudo page on the Ubuntu Community Wiki.
Alternatives To A Root Shell
One of the most common reasons that a user might need a root shell is due to output redirection not working as expecting while using sudo. This can be bypassed fairly easily. Let me outline an example:
sudo echo “foo” >Â /root/somefile
The above example will not work because the normal user does not have access to write to the root user home directory, and combining the redirection in the command we’ve lost sudo access.
An alternative that will work would look something like this:
echo "foo" | sudo tee /root/somefile
This will echo the output on the console but the tee command ('man tee‘ for more information) will also take that output and write it to the file as expected. Also note that 'tee -a' will work in the same fashion as >>, appending the data to the current file vs overwriting.
The Proper Way To A Root Shell
If you still need a root shell (perhaps you’ve come across a different scenario? perhaps you’re just lazy? perhaps you’re coming from another distribution?) let me outline the proper way to gain a root shell.
DISCLAIMER: This should be avoided if at all possible. It is not suggested to run a root shell on an Ubuntu system. Use at your own risk. See examples above, etc.
sudo -i
The command sudo -i is the equivalent to the 'su -' command. This will properly change to the root user, switch to the root user’s home directory, use his (her?) environment values, etc.
sudo -s
The command sudo -s is the equivalent to the 'su' command. This will change to the root user but will not properly use his (her?) environment values, etc.
The WRONG Way To A Root Shell
Please DO NOT use the following methods to gain root access:
sudo bash, sudo sh, sudo su -, sudo su, sudo -i -u root
If you currently do use these methods this post was written for you!
UPDATE: Based on the feedback in the comments for this post I’ll try to expand the reasoning on *why* the right way is the preferred way.
First of all we need to understand some background information. When a user creates a session there are a number of environment values that are set. To have a look at some of these try this command:
env
This will output a number of details about the current working environment. These environment values may be different for different users. Some of the values are generated by way of the .bashrc file (assuming a bash shell, of course), the .bash_profile, etc. Take a look at the .bashrc in your users home directory and compare it with the .bashrc in root’s home directory.
diff -u ~/.bashrc /root/.bashrc
You should see some differences, and this is just from one of the multiple files that are read during a proper login.
When creating a root shell by using ‘sudo bash‘ you are not incorporating the root environment properly. You are creating a shell with root privileges but the env output is still that of your user. Each user, whether unprivileged or root, should have unique environment settings to truly be that user. This will be the case for ‘sudo bash‘, ‘sudo su‘ and ‘sudo sh‘.
