I would like to share something that came to my knowledge through Facebook, and though I don’t know ‘tatica’ personally, I did traded a few emails with her in the past and know that her contributions are always awesome.

If you can help, please consider donating a few bucks to help this awesome FOSS contributor attending one of the major events in the field of her contributions!

To help ‘tatica’ please click on the image!

Original Text from the Campaign (source: http://pledgie.com/campaigns/16632):

“Maybe you know that girl here. You know she does a lot for FLOSS, using GIMP, Inkscape and Blender. Its not that she makes only graphics for Fedora and a lot of othere FLOSS-projects or events. She also give her knowledge always to others, giving talks and workshops on events or producing screencasts.

There is only one problem, flights from south america to europe are really expensive. From Caracas to Vienna is mostly between 1500 and 1700 $, why 2500 then. So maybe we can pay the hotel also? “

First install RVM and set it up:

sudo yum install rubygem-rvm
rvm-install

To include RVM into your bash shell, add following line to ~/.bashrc:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # This loads RVM into a shell session.

Now install JRuby and use it as default Ruby interpreter:

source ~/.bashrc
rvm install jruby-1.5.6
rvm use jruby-1.5.6

Setup Rails environment:

gem install rails
gem install bundler

Lets create a new Rails application:

rails new rails-app
cd rails-app
bundle install
rails g scaffold Person name:string
rake db:migrate
rails s

Now go to http://localhost:3000/people/
Yay! Your new Rails application is up and running, powered by JRuby ( setup using RVM ).

I setup rhev 3 and eucalyptus 2 last week. I’ll talk about rhev eventually but I have some initial thoughts on euca I want to get down.

1. install instructions are mostly good but need some work to make it clear what ELSE I need to setup
2. the overview docs are good but 10m spent talking to andy grimm cleared up everything A WHOLE LOT MORE.

Now let’s go onto my rant:
First I want to thank Greg Dekoenigsberg for getting the images list at eucalyptus setup. That helped point me in roughly the right direction. It was a big help. But lets be clear I will never use someone else’s image for my own servers. NEVER. Do you know why? B/c I do not trust other people to either a. not be morons or b. do something intentionally crappy. I’m happy the list exists b/c in addition to advertising existing images (which are quite helpful) it also promotes the discussion of how making images is stupidly difficult and under-documented.

So: Why is making images that frelling hard?
To make an image you more or less setup an installroot – blow the pkgs in there then you go screw with them some. Then perform a relatively complicated set of things to make it ‘work’ and then upload it to euca.

This is dumb.

1. installing to an install root is what the INSTALLER is for
2. the installer for rhel/fedora/centos/SL, etc, etc, etc is anaconda
3. the automated installer for these is kickstart
4. for a euca instance you have:
a. processor
b. memory
c. disk (sorta)
d. network

Last I checked that’s all you need to run anaconda (and kickstart).

I’ve been an admin for a long time now and I’ve been mass installing systems since LONG before many people understood why that was important. I’ve been using kickstart (practically the same basic kickstart) for about 12 yrs now. Why would I want a NEW tool for installing instances and setting up images? Especially a new, inferior, incompatible tool with a format that means I have to go screw with how I’ve been installing systems for OVER A DECADE? I would not. There is no reason. There is nothing that makes that make sense.

The anaconda developers have done a STELLAR job maintaining compatibility with the kickstart format to the point that the whole linux-using world has realized it. To the point that I can almost take my ks.cfg from rhl 7.2 and have it work on rhel 6. Even if I’m going to install and instance, take a snapshot and immediately use that as my clone for all new instances – it is still easier and better if the mechanism I use is the same as I would use on any other server. If only for consistency.

(The first person who says something about consistency and hobgoblins of little minds will:
a. get slapped and b. get reminded that the first line is a ‘foolish consistency’)

Moreover doing things from kickstart as the basis for the images means:
1. you’re not inheriting bizarre little things you forgot you modified in your image
2. you’re starting from known good (and gpg-verifiable) pkgs
3. you don’t need to change your established practices.

Let’s say, in an ideal world, all my instances are in my private cloud running on euca. That’s great, but the cloud controller and nodes that run euca aren’t able to use those images, – so I’m going to have to install (and reinstall) those. Which means I’m going to be using kickstart. So, yah any install tool must use kickstart at its base.

So, with that in mind I had lunch with Greg and Andy on Friday and we discussed this a good bit. Then after Andy and I talked about the problem space some he explained what the limiting factor was. He then mentioned someone working on Neuca at Renci and the patches they have to do something related (as in to modify the xml that is passed to libvirt to generate images) and after he mentioned his first name and that he was at duke I realized that he lives 2 blocks away from me and I’ve known him for over a decade. So I called him and we talked about whether or not the patches to neuca will do what I want (which is to let you kickstart to install an image). It’s not in the bag yet but it sure seems like the bag is open and all the pieces appear to be able to fit inside.

After talking with Victor friday evening I felt a good deal better. I couldn’t imagine why this hasn’t already been addressed therefore I thought I was missing something obvious, something that made this trivial and I just ignored it. No, in fact, I hadn’t missed anything – building images is stupidly difficult and obtuse and for no good reason.

There’s a lot more to go but I’m looking forward to tinkering with this when I get back from a little trip on wednesday.

I think this 4 words can resume pretty much what’s FOSS about. A couple of months ago I had a small shutdown from linux communities since *real life* was going on, and with some friends help, I tried to figure out *why* we do what we do. Talking and giving a meaning to every action we take on this online world this 4 words got to resume everything. Why?:

Learn:

There is NO WAY you can be on ANY FOSS community or group if you are not willing to learn. Life itself is a learning journey that will take you to unknown places where you might get amazed. Some people join FOSS communities thinking that know everything, but soon they realize that there is no way you can know everything, and you will always learn something new, just need to keep your mind open :)

Teach:

Be a FOSS contributor is be a student and a teacher. Open Source way teach us that what we learn must be teach because you don’t know where is that next contributor that might change the source code of your world. Teach however isn’t easy. You must be patient, perseverant and if non of those work… friendly to send them to other teacher. We never say no, there is always an answer for everything.

Help:

Help people is what we do. We get up everyday and turn on our pc (some just never go off) and try to make someone life easier, either with code, design or translations, each one of us help everyday to make Open Source better. If you’re not a *people person* you can always help doing something else. I’m sure people will apreciate.

Enjoy:

At the end.. you will make friends, will find people to chat every single day, you will be able to learn different languages and maybe travel to other countries. You will find a new image that bring a smile to your face or a code line that will make you breath. Every day FOSS makes people life easier and our goal as contributors is enjoy this process. Is everything perfect? In, but like life, every single day counts.

What are you waiting to join a FOSS community? There are a lot of places where you can make a difference… just give yourself a chance :) Now… help me to spread some love! (click on each to get a full size or multiple sizes.)

and some banners :) (right click to save banner images.)

The Anaconda team has been working on a redesign for a while now. While the installation actually happens, there are going to be banners that tell you things while you install. We’ve got a couple of them made, but we’re plumb out of ideas. If you have any, send me an email at ctbeiser(at symbol)gmail.com.

Sigul setup instructions form Open Source @ Seneca Centre for Development of Open Technology

Fedora Project pages on how to use Sigul

Sigul uses a CA to generate SSL certs for the server, bridge, and clients to authenticate and encrypt communications. The server itself provides GPG keys for signing packages. In this case, I am going to setup a separate CA for sigul with respect to the CA we use for koji. The reasoning here is that koji's CA is used often, to create end user certs for access into koji. That means it's exposed often to an admin, either directly via the cli or indirectly via a webapp or other utility, when user certs are created.

The sigul CA should be kept fairly isolated in my opinion, since it's only used to add new server, bridge, and client instances. These additions should be fairly rare. Exposing the sigul CA often, as when a new end user cert is being created, opens up opportunities to create new certs that could be used to get rogue sigul clients the ability to get unauthorized rpms signed with our keys.

The bridge setup is pretty much spot on from the Seneca Sigul Setup link above. One thing you may have to do is change the sigul user's default shell in order to create the db as the sigul user using the defaults from the Fedora install of the packages.

usermod -s /bin/bash sigul

# sigul_server_create_db
Traceback (most recent call last):
  File "/usr/share/sigul/server_create_db.py", line 21, in ?
    import server_common
  File "/usr/share/sigul/server_common.py", line 107, in ?
    sa.Column('name', sa.Text, nullable=False,
AttributeError: 'module' object has no attribute 'Text'

To be continued...

In the spirit of giving credit where it is due, I had my first foray into systemd last week. It is well designed, implemented and documented. Kudos! If I have one complaint, its that in the documentation many subject matters that are related are divided into different areas (for example systemd.socket, systemd.service and systemd.exec). I’d love to see a single page version of this documentation so you can search through it for relevant things.

• If you sell anything via eBay using Paypal, send it recorded, and keep the receipt.
• If you bought a MacBook Air first generation with the serial W88500DJ12G, it's stolen, send me an e-mail.

The package of gnupg extension for PHP, a wrapper over gpgme, is available in remi repository for fedora and EL-5.

Extension documentation : GNU Privacy Guard Installation, as always: yum --enablerepo=remi install php-pecl-gnupgQuite a lot of work to have a working extension, all issues have been reported upstream, with patch attached: Bug #60913 : missing file in test suite Bug #60914 : version 1.3.2 reports as 1.3.2-dev Bug #60915 : PHP 5.4 build fails... Lire php-pecl-gnupg-1.3.2

[ianweller@hovercraft fedora-business-cards]$ git diff --stat 0afed4e HEAD
 INSTALL                                      |    4 +-
 MANIFEST.in                                  |    2 +-
 README                                       |   15 +-
 config.ini                                   |    4 -
 fedora-business-cards.spec                   |   28 +--
 fedora_business_cards/__init__.py            |   13 +-
 fedora_business_cards/common.py              |  104 ++++++++++
 fedora_business_cards/config.py              |   66 ------
 fedora_business_cards/exceptions.py          |   37 ----
 fedora_business_cards/export.py              |  144 ++++++++-----
 fedora_business_cards/frontend/__init__.py   |   26 +++
 fedora_business_cards/frontend/cmdline.py    |  236 +++++++++++------------
 fedora_business_cards/generate.py            |   60 ------
 fedora_business_cards/generators/__init__.py |   61 ++++++
 fedora_business_cards/generators/fedora.py   |  278 ++++++++++++++++++++++++++
 fedora_business_cards/information.py         |   64 ------
 pavement.py                                  |   45 +----
 templates/back-europe.svg                    |   76 -------
 templates/back-northamerica.svg              |   75 -------
 templates/back-overnightprints.svg           |   76 -------
 templates/front-europe.svg                   |  160 ---------------
 templates/front-northamerica.svg             |  152 --------------
 templates/front-overnightprints.svg          |  152 --------------
 templates/templates.ini                      |   17 --
 24 files changed, 694 insertions(+), 1201 deletions(-)

What changed?

• Removed the Fedora Talk number (long overdue).
• Removed fill-in-the-blank templates and added code to generate the SVG dynamically in Python. (This now lets us support any given business card size, with any given margin for professional printing.)
• Changed the fonts to Cantarell and Comfortaa.
• Made the business card generation modular so that you can create a non-Fedora business card with the same code that makes dynamic sizes and conversion to CMYK and PDF somewhat easier than doing it from scratch. (Feature request by Mel Chua, who told me she will write a Beefy Miracle module to test the new modularization support.)
• Made palette-based RGB to CMYK conversion actually sane.
• Various fixes.

Okay, so 1 visible change. I lied :)

What’s next?

• Potentially moving things around on the Fedora card layout
• Possibly renaming fedora-business-cards to something more generic due to its modularization
• Actually making a new release so that people stop accidentally printing Fedora Talk information on their cards

The thesis that underlies my project to translate the Emacs C code to Common Lisp is that Emacs Lisp is close enough to Common Lisp that the parts of the Emacs C code that implement Lisp can be dropped in favor of the generally superior CL implementation.  This is generally true, but there are a few difficult bits.

Symbols

The primary problem is the translation of symbols when used as variable references.  Consider this code:

(defvar global 73)
(defun function (argument)
  (let ((local (something-else))
    (+ local argument global)))

More is going on here than meets the eye.

First, Emacs Lisp uses dynamic binding by default (optional lexical binding is a new feature in Emacs 24).  This applies to function arguments as well as other bindings.  So, you might think you could translate this straightforwardly to:

(defvar global 73)
(declare (special global))
(defun function (argument)
  (declare (special argument))
  (let ((local (something-else))
    (declare (special local))
    (+ local argument global)))

This was the approach taken by elisp.lisp; it defined macros for let and let* (but forgot defun) to do the dirty work:

(defmacro el::let* ((&rest vars) &rest forms)
  "Emacs-Lisp version of `let*' (everything special)."
  `(let* ,vars (declare (special ,@(mapcar #'from-list vars))) ,@forms))

But not so fast!  Emacs also has buffer-local variables.  These are variables where the value is associated with the current buffer; switching buffers makes a different binding visible to Lisp.  These require no special syntax, and a variable can be made buffer-local at any time.  So, we can break the above translation simply by evaluating:

(make-local-variable 'global)
(setq global 0)

Whoops!  Now the function will return the wrong result — the translation will have no way to know that is should refer to the buffer-local value.  (Well, ok, pretend that the setq magically worked somehow…)

My idea for implementing this is pretty convoluted.  Actually I have two ideas, one “user” and one “kernel”:

User

I think it is possible to use define-symbol-macro on all symbols that come from Elisp, so that we can tell the CL compiler about the real implementation.  However, a symbol can either be treated as a variable, or it can be treated as a symbol-macro — not both at the same time.  So, we will need a second location of some kind to store the real value.  Right now I’m thinking a symbol in another package, but maybe a cons or some other object would work better. In either case, we’d need a macro, a setf method for its expansion, and some extra-tricky redefinitions of let and defun to account for this change.

This would look something like:

(define-symbol-macro global (elisp:get-elisp-value 'global))
(defsetf elisp:get-elisp-value elisp:set-elisp-value))
;; Details left as an exercise for the reader.

This solution then has to be applied to buffer-, keyboard-, and frame-local variables.

Kernel

The kernel method is a lot simpler to explain: hack a Common Lisp implementation to directly know about buffer-locals.  SMOP!  But on the whole I think this approach is to be less preferred.

Other Problems

Emacs Lisp also freely extends other typical data types with custom attributes.  I consider this part of the genius of Emacs; a more ordinary program would work within the strictures of some defined, external language, but Emacs is not so cautious or constrained.  (Emacs is sort of a case study in breaking generally accepted rules of programming; which makes one wonder whether those rules are any good at all.)

So, for example, strings in Emacs have properties as a built-in component.  The solution here is simple — we will just translate the Emacs string data type as a whole, something we probably have to do anyway, because Emacs also has its own idiosyncratic approach to different encodings.

In elisp, aref can be used to access elements of other vector-like objects, not just arrays; there are some other odd little cases like this.  This is also easily handled; but it left me wondering why things like aref aren’t generic methods in CL. It often seems to me that a simpler, more orthogonal language lies inside of CL, struggling to get free. I try not to think these thoughts, though, as that way lies Scheme and the ridiculous fragmentation that has left Lisp unpopular.

Howdy there! Let’s see what’s the news this week!

-Nicolas Ferre has at91 updates for -rc2, Rafael
J. Wysocki has PM fixes for 3.3, Taakshi Iwai has
sound fixes, Arnaldo Carvalho de Melo has perf/core
improvements and fixes and David Miller has a networking
pull request:

1) Fix JIT code generation on x86-64 for divide by zero, from Eric Dumazet.

2) tg3 header length computation correction from Eric Dumazet.

3) More build and reference counting fixes for socket memory cgroup
code from Glauber Costa.

4) module.h snuck back into a core header after all the hard work we
did to remove that, from Paul Gortmaker and Jesper Dangaard Brouer.

5) Fix PHY naming regression and add some new PCI IDs in stmmac, from
Alessandro Rubini.

6) Netlink message generation fix in new team driver, should only advertise
the entries that changed during events, from Jiri Pirko.

7) SRIOV VF registration and unregistration fixes, and also add a
missing PCI ID, from Roopa Prabhu.

8) Fix infinite loop in tx queue flush code of brcmsmac, from Stanislaw Gruszka.

9) ftgmac100/ftmac100 build fix, missing interrupt.h include.

10) Memory leak fix in net/hyperv do_set_mutlicast() handling, from Wei Yongjun.

11) Off by one fix in netem packet scheduler, from Vijay Subramanian.

12) TCP loss detection fix from Yuchung Cheng.

13) TCP reset packet MD5 calculation uses wrong address, fix from Shawn Lu.

14) skge carrier assertion and DMA mapping fixes from Stephen Hemminger.

15) Congestion recovery undo performed at the wrong spot in BIC and CUBIC
congestion control modules, fix from Neal Cardwell.

16) Ethtool ETHTOOL_GSSET_INFO is unnecessarily restrictive, from Michał Mirosław.

17) Fix triggerable race in ipv6 sysctl handling, from Francesco Ruggeri.

18) Statistics bug fixes in mlx4 from Eugenia Emantayev.

19) rds locking bug fix during info dumps, from your’s truly.

Please pull, thanks a lot.

-Benjamin Herrenschmidt has some powerpc fixes, Keith Packard has
fixes for drm-intel (“A bunch of patches which fix IVB-specific troubles:

* A selection of code which was labeled for SNB, but needs to be run on
IVB as well.

* A replacement for the quick-hack IVB lost-IRQ issue. This appears to
help on SNB as well, but for now it’s only enabled on IVB in case we
discover problems with it.

* Fix some 3-pipe issues

And, a couple of minor mode setting fixes.”) and Tyler Hicks has some ecryptfs
fixes for -rc2 :

Tim’s logging message update will be really helpful to users when
they’re trying to locate a problematic file in the lower filesystem with
filename encryption enabled.

You’ll recognize the fix from Li, as you commented on that.

You should also be familiar with my setattr/truncate improvements, since
you were the one that pointed them out to us (thanks again!). Andrew
noted the /dev/ecryptfs write count sanitization needed to be improved,
so I’ve got a fix in there for that along with some other less important
cleanups of the /dev/ecryptfs read/write code.

They’ve all sat in -next for at least a day, while some have been there
around a week, I believe.

I’ll get signed tags going for the next pull request I send. That was my
intention this time, but it just hit me that I forgot to do it.

-Greg KH announces the release of 2.6.32.55, 3.2.2 and 3.0.18, Dave Airlie
has some drm fixes, mostly radeon-related, Geert Uytterhoeven has m68k updates
for 3.3 and Ingo Molnar has core, perf and x86 fixes.

-Olof Johansson has arm-soc fixes for -rc, and this concludes this week’s news.

• anaconda-runtime
• pungi,
• pykickstart,
• system-config-kickstart
• anaconda

$ su -c 'yum -y install pungi anaconda-runtime pykickstart system-config-kickstart anaconda'

$ su -c 'yum -y install pygtk2 pygtk2-libglade yum comps-extras system-config-kickstart gnome-python2-gconf notify-python pungi livecd-tools usermode pam db4'

$ su -c 'yum -y install cobbler koan deltarpm python-virtinst jigdo'

$ su -c 'ln -s /usr/lib64/anaconda/ /usr/lib/anaconda-runtime'

$ su -c 'yum -y install revisor revisor-gui'

$ su -c 'yum -y install revisor revisor-gui revisor-unity revisor-scripts revisor-cli revisor-isolinux revisor-mock revisor-reuseinstaller revisor-cobbler

Spulciando le analisi dei siti web che ospito sul mio server condiviso, mi sono accorto di una cosa interessante.
Se il sito web parla di informatica o tecnologia (come il mio blog) i visitatori usano per lo più browser come Firefox, Chrome, Safari; se invece é un sito che tratta argomenti diversi il browser che vince in assoluto é internet explorer (esempio www.labusciona.com).

Fortunatamente sono pochissimi quelli che usano ancora Internet Explorer 6, ma ce ne sono ancora!!

Es cierto que ya casi para todo, existe un equivalente de programa windows en Linux/GNU. Sin embargo, muchas veces nos hemos visto en la necesidad de tener una partición de la famosa ventana en nuestro ordenador, ya sea por x motivo.

Pues, muchos de los problemas que surgen cuando uno empieza en Linux/GNU es la manipulación de conceptos informáticos, especialmente cuando uno no es precisamente un técnico. En muchos casos, con un poco de conocimiento se puede tener un sistema operativo Linux/GNU y Windows en el mismo disco duro, pero para lograrlo es necesario tomar en cuenta algunos consejos: por ejemplo, instalar Windows y luego la distribución de Linux/GNU que más se adapte a tus necesidades, esto es para que el GRUB (Grand Unified Bootloader) de Fedora nos permita elegir   cuál sistema operativo arrancar una vez iniciado el encendido de la máquina.