Andromeda Computer - Blog
Ilich Blanco

Ilich Blanco

Entusiasta de la naturaleza y apasionado de la tecnología desde que puedo recordar, inversionista y fiel creyente de la tecnología blockchain y criptomonedas. Estoy seguro que los problemas de la sociedad y la humanidad en general no serán resueltos por economistas o sociólogos si no por la mente brillante de científicos.
Website URL: http://https://www.linkedin.com/in/ilichblanco Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Tuesday, 15 October 2019 16:36

Benefits of centralizing GNOME in GitLabs

The GNOME project's decision to centralize on GitLab is creating benefits across the community—even beyond the developers.

 gnomeandro.png

 

“What’s your GitLab?” is one of the first questions I was asked on my first day working for the GNOME Foundation—the nonprofit that supports GNOME projects, including the desktop environment, GTK, and GStreamer. The person was referring to my username on GNOME’s GitLab instance. In my time with GNOME, I’ve been asked for my GitLab a lot.

We use GitLab for basically everything. In a typical day, I get several issues and reference bug reports, and I occasionally need to modify a file. I don’t do this in the capacity of being a developer or a sysadmin. I’m involved with the Engagement and Inclusion & Diversity (I&D) teams. I write newsletters for Friends of GNOME and interview contributors to the project. I work on sponsorships for GNOME events. I don’t write code, and I use GitLab every day.

 

The GNOME project has been managed a lot of ways over the past two decades. Different parts of the project used different systems to track changes to code, collaborate, and share information both as a project and as a social space. However, the project made the decision that it needed to become more integrated and it took about a year from conception to completion. There were a number of reasons GNOME wanted to switch to a single tool for use across the community. External projects touch GNOME, and providing them an easier way to interact with resources was important for the project, both to support the community and to grow the ecosystem. We also wanted to better track metrics for GNOME—the number of contributors, the type and number of contributions, and the developmental progress of different parts of the project.

When it came time to pick a collaboration tool, we considered what we needed. One of the most important requirements was that it must be hosted by the GNOME community; being hosted by a third party didn’t feel like an option, so that discounted services like GitHub and Atlassian. And, of course, it had to be free software. It quickly became obvious that the only real contender was GitLab. We wanted to make sure contribution would be easy. GitLab has features like single sign-on, which allows people to use GitHub, Google, GitLab.com, and GNOME accounts.

We agreed that GitLab was the way to go, and we began to migrate from many tools to a single tool. GNOME board member Carlos Soriano led the charge. With lots of support from GitLab and the GNOME community, we completed the process in May 2018.

There was a lot of hope that moving to GitLab would help grow the community and make contributing easier. Because GNOME previously used so many different tools, including Bugzilla and CGit, it’s hard to quantitatively measure how the switch has impacted the number of contributions. We can more clearly track some statistics though, such as the nearly 10,000 issues closed and 7,085 merge requests merged between June and November 2018. People feel that the community has grown and become more welcoming and that contribution is, in fact, easier.

People come to free software from all sorts of different starting points, and it’s important to try to even out the playing field by providing better resources and extra support for people who need them. Git, as a tool, is widely used, and more people are coming to participate in free software with those skills ready to go. Self-hosting GitLab provides the perfect opportunity to combine the familiarity of Git with the feature-rich, user-friendly environment provided by GitLab.

It’s been a little over a year, and the change is really noticeable. Continuous integration (CI) has been a huge benefit for development, and it has been completely integrated into nearly every part of GNOME. Teams that aren’t doing code development have also switched to using the GitLab ecosystem for their work. Whether it’s using issue tracking to manage assigned tasks or version control to share and manage assets, even teams like Engagement and I&D have taken up using GitLab.

It can be hard for a community, even one developing free software, to adapt to a new technology or tool. It is especially hard in a case like GNOME, a project that recently turned 22. After more than two decades of building a project like GNOME, with so many parts used by so many people and organizations, the migration was an endeavor that was only possible thanks to the hard work of the GNOME community and generous assistance from GitLab.

I find a lot of convenience in working for a project that uses Git for version control. It’s a system that feels comfortable and is familiar—it’s a tool that is consistent across workplaces and hobby projects. As a new member of the GNOME community, it was great to be able to jump in and just use GitLab. As a community builder, it’s inspiring to see the results: more associated projects coming on board and entering the ecosystem; new contributors and community members making their first contributions to the project; and increased ability to measure the work we’re doing to know it’s effective and successful.

It’s great that so many teams doing completely different things (such as what they’re working on and what skills they’re using) agree to centralize on any tool—especially one that is considered a standard across open source. As a contributor to GNOME, I really appreciate that we’re using GitLab.

 BannerFinalGNULINUZROCKS

DevSecOps evolves DevOps to ensure security remains an essential part of the process.

devsecopsandro.jpg 

DevOps is well-understood in the IT world by now, but it's not flawless. Imagine you have implemented all of the DevOps engineering practices in modern application delivery for a project. You've reached the end of the development pipeline—but a penetration testing team (internal or external) has detected a security flaw and come up with a report. Now you have to re-initiate all of your processes and ask developers to fix the flaw.

This is not terribly tedious in a DevOps-based software development lifecycle (SDLC) system—but it does consume time and affects the delivery schedule. If security were integrated from the start of the SDLC, you might have tracked down the glitch and eliminated it on the go. But pushing security to the end of the development pipeline, as in the above scenario, leads to a longer development lifecycle.

This is the reason for introducing DevSecOps, which consolidates the overall software delivery cycle in an automated way.

In modern DevOps methodologies, where containers are widely used by organizations to host applications, we see greater use of Kubernetes and Istio. However, these tools have their own vulnerabilities. For example, the Cloud Native Computing Foundation (CNCF) recently completed a Kubernetes security audit that identified several issues. All tools used in the DevOps pipeline need to undergo security checks while running in the pipeline, and DevSecOps pushes admins to monitor the tools' repositories for upgrades and patches.

 

What Is DevSecOps?

Like DevOps, DevSecOps is a mindset or a culture that developers and IT operations teams follow while developing and deploying software applications. It integrates active and automated security audits and penetration testing into agile application development.

 

To utilize DevSecOps, you need to:

Introduce the concept of security right from the start of the SDLC to minimize vulnerabilities in software code. Ensure everyone (including developers and IT operations teams) shares responsibility for following security practices in their tasks. Integrate security controls, tools, and processes at the start of the DevOps workflow. These will enable automated security checks at each stage of software delivery. DevOps has always been about including security—as well as quality assurance (QA), database administration, and everyone else—in the dev and release process. However, DevSecOps is an evolution of that process to ensure security is never forgotten as an essential part of the process.

 

Understanding the DevSecOps pipeline

There are different stages in a typical DevOps pipeline; a typical SDLC process includes phases like Plan, Code, Build, Test, Release, and Deploy. In DevSecOps, specific security checks are applied in each phase.

 

Plan: Execute security analysis and create a test plan to determine scenarios for where, how, and when testing will be done.

Code: Deploy linting tools and Git controls to secure passwords and API keys.

Build: While building code for execution, incorporate static application security testing (SAST) tools to track down flaws in code before deploying to production. These tools are specific to programming languages.

Test: Use dynamic application security testing (DAST) tools to test your application while in runtime. These tools can detect errors associated with user authentication, authorization, SQL injection, and API-related endpoints.

Release: Just before releasing the application, employ security analysis tools to perform thorough penetration testing and vulnerability scanning.

Deploy: After completing the above tests in runtime, send a secure build to production for final deployment.

 

DevSecOps tools

Tools are available for every phase of the SDLC. Some are commercial products, but most are open source. In my next article, I will talk more about the tools to use in different stages of the pipeline.

DevSecOps will play a more crucial role as we continue to see an increase in the complexity of enterprise security threats built on modern IT infrastructure. However, the DevSecOps pipeline will need to improve over time, rather than simply relying on implementing all security changes simultaneously. This will eliminate the possibility of backtracking or the failure of application delivery.

 

 BannerFinalGNULINUZROCKS

Thursday, 10 October 2019 13:26

Fantastic Tattoos: HALLOWEEN

 

 

terorrfrondimage.png

 

The most amazing tattoos in honor of the scariest night of the year HALLOWEEN

 

 

 

che cloud.png

 

Eclipse Che offers Java developers an Eclipse IDE in a container-based cloud environment.

 

 

In the many, many technical interviews I've gone through in my professional career, I've noticed that I'm rarely asked questions that have definitive answers. Most of the time, I'm asked open-ended questions that do not have an absolutely correct answer but evaluate my prior experiences and how well I can explain things.

One interesting open-ended question that I've been asked several times is:

 

"As you start your first day on a project, what five tools do you install first and why?"

 

There is no single definitely correct answer to this question. But as a programmer who codes, I know the must-have tools that I cannot live without. And as a Java developer, I always include an interactive development environment (IDE)—and my two favorites are Eclipse IDE and IntelliJ IDEA.

 

 

My Java story

When I was a student at the University of Texas at Austin, most of my computer science courses were taught in Java. And as an enterprise developer working for different companies, I have mostly worked with Java to build various enterprise-level applications. So, I know Java, and most of the time I've developed with Eclipse. I have also used the Spring Tools Suite (STS), which is a variation of the Eclipse IDE that is installed with Spring Framework plugins, and IntelliJ, which is not exactly open source, since I prefer its paid edition, but some Java developers favor it due to its faster performance and other fancy features.

Regardless of which IDE you use, installing your own developer IDE presents one common, big problem: "It works on my computer, and I don't know why it doesn't work on your computer."

cohhdhdlin.jpg

 

Because a developer tool like Eclipse can be highly dependent on the runtime environment, library configuration, and operating system, the task of creating a unified sharing environment for everyone can be quite a challenge.

 

But there is a perfect solution to this. We are living in the age of cloud computing, and Eclipse Che provides an open source solution to running an Eclipse-based IDE in a container-based cloud environment.

 

From local development to a cloud environment

I want the benefits of a cloud-based development environment with the familiarity of my local system. That's a difficult balance to find.

When I first heard about Eclipse Che, it looked like the cloud-based development environment I'd been looking for, but I got busy with technology I needed to learn and didn't follow up with it. Then a new project came up that required a remote environment, and I had the perfect excuse to use Che. Although I couldn't fully switch to the cloud-based IDE for my daily work, I saw it as a chance to get more familiar with it.

0_banner.jpg

 

 

Eclipse Che IDE has a lot of excellent features, but what I like most is that it is an open source framework that offers exactly what I want to achieve:

  • Scalable workspaces leveraging the power of cloud
  • Extensible and customizable plugins for different runtimes
  • A seamless onboarding experience to enable smooth collaboration between members

 

Getting started with Eclipse Che

Eclipse Che can be installed on any container-based environment. I run both Code Ready Workspace 1.2 and Eclipse Che 7 on OpenShift, but I've also tried it on top of Minikube and Minishift.

opeenenen.jpg

 

You can also run Che on any container-based environment like OKD, Kubernetes, or Docker. Read the requirement guides to ensure your runtime is compatible with Che:

 

 

For instance, you can quickly install Eclipse Che if you launch OKD locally through Minishift, but make sure to have at least 5GB RAM to have a smooth experience.

There are various ways to install Eclipse Che; I recommend leveraging the Che command-line interface, chectl. Although it is still in an incubator stage, it is my preferred way because it gives multiple configuration and management options. You can also run the installation as an Operator. I decided to go with chectl since I did not want to take on both concepts at the same time. Che's quick-start provides installation steps for many scenarios.

 

Why cloud works best for me

 

Although the local installation of Eclipse Che works, I found the most painless way is to install it on one of the common public cloud vendors.

I like to collaborate with others in my IDE; working collaboratively is essential if you want your application to be something more than a hobby project. And when you are working at a company, there will be enterprise considerations around the application lifecycle of develop, test, and deploy for your application.

Eclipse Che's multi-user capability means each person owns an isolated workspace that does not interfere with others' workspaces, yet team members can still collaborate on application development by working in the same cluster. And if you are considering moving to Eclipse Che for something more than a hobby or testing, the cloud environment's multi-user features will enable a faster development cycle. This includes resource management to ensure resources are allocated to each environment, as well as security considerations like authentication and authorization (or specific needs like OpenID) that are important to maintaining the environment.

Therefore, moving Eclipse Che to the cloud early will be a good choice if your development experience is like mine. By moving to the cloud, you can take advantage of cloud-based scalability and resource flexibility while on the road.

 

Use Che and give back

I really enjoy this new development configuration that enables me to regularly code in the cloud. Open source enables me to do so in an easy way, so it's important for me to consider how to give back. All of Che's components are open source under the Eclipse Public License 2.0 and available on GitHub at the following links:

Consider using Che and giving back—either as a user by filing bug reports or as a developer to help enhance the project.

 

 

 BANNERLINUXFINALESPAOL

 

 

 

 

 

Wednesday, 02 October 2019 13:19

FanArt: Claymore

The best claymore illustrations made by fans

 

thumb-1920-82003.jpg

 

Hello again to all lovers of illustration and anime, in this occasion I bring you a compilation of fanart about claymore, an anime that was really great, a little gore with a captivating and exciting story, epic battles and emotional moments. I hope you enjoy the post!

 

 

Claymores are the titular characters of the series. Named after the Great swords they wield, they are half-human, half-Yoma hybrid warriors of the Organization. Normally, Claymores don't call each other by the name "Claymore"; instead, the humans gave them this name, alternatively referring to them as "silver-eyed witches/slayers

 

 

“From the moment I first saw you, you've looked so sad. Your face shows so much pain. Your eyes were like mine. They looked so sad, so hurt, so lonely…as if you couldn't stand it.” - Clare

  

“This little girl, who's not even half my size...taught me that tears can flow even from these silver eyes.” - Teresa

 

 

“It’s hardly profound. The reason is very simple: I’ve found a reason to live. From now on, I’m going to live for the girl.” - Teresa

 

 

“Number Forty-Seven in the organization, Clare, the successor of Teresa's flesh and blood, the bearer of Ilena's right arm, and the one who will hunt down the head of the one-horned monster, Priscilla.” - Clare

 

 

“Don’t be so quick to throw away your life. No matter how disgraceful or embarrassing it may be, you need to keep struggling to find your way out until the very end.” - Clare

 

“You said I should have forgotten everything and lived as a human, but...there's no way.” - Clare

 

“Everyone around her respected her, yet feared her. You loved her as she was, and she accepted it.” - Ilena

 

“Live, Clare! Your staying alive is the only proof that Teresa ever existed." - Ilena

 

“I promise you. I will not die. I will survive this day and meet you again. So, you can't die either, Raki. I will find you. You need to survive until then.” - Clare

 

 

banner ingles anime

 

Page 1 of 12
DMC Firewall is developed by Dean Marshall Consultancy Ltd