dmacvicar

It is used for the root filesystem, which gives you nice functionality, like the package manager or YaST automatically taking snapshots in between system changes, which means you can then audit changes and rollback.

It even allows you to boot the system into one of these previous snapshots.

(disclaimer: SUSE employee and user)

I get the impression that people using Debian and their derivatives seem to live under a rock regarding other distributions.

I would trust zypper dup hundred times over apt-get dist-upgrade. This gets amplified by the fact that openSUSE Tumbleweed (rolling distro), is much better auto-tested before being published every week, than my experience with sid was (tested by their end-users).

Today's Redhat dnf package manager is based on SUSE's dependency solver (https://github.com/openSUSE/libsolv), and both package managers provide a very nice user experience.

People seem to be still confused about SUSE "using YaST". YaST is just a front-end powered by libzypp (https://github.com/openSUSE/libzypp), like zypper is.

Deltachat is opensource for every platform it supports: https://github.com/deltachat

It also includes a core library in C: https://github.com/deltachat/deltachat-core

The spec is documented here: https://github.com/deltachat/spec/blob/master/spec.md

How is this different from https://delta.chat ?

You shouldn't compare rpm with apt. rpm is a different layer equivalent to dpkg in the Debian world.

As you point out, apt layer/functionality is provided by zypper, yum, dnf, etc. and the main difference is that it is not unified across the main rpm distributions. Still, Fedora/Redhat yum replacement, dnf, is built on SUSE/openSUSE zypper's solver library (libsolv).

btw, here is an article about the management UI:

https://www.suse.com/communities/blog/introducing-stratos-ui...

SUSE's Cloud Application Platform is already available to selected customers. It is based Cloud Foundry running on top of Kubernetes, all with a very slick UI. No VMs.

https://www.suse.com/products/cloud-application-platform/ https://www.suse.com/communities/blog/take-look-suse-cloud-a...

I tried it recently with an internal app, and the experience was very similar to Heroku. cf push and my app was running.

Disclosure: I work for SUSE, we contribute to Cloud Foundry and the containers ecosystem. Pivotal is a competitor.

A friend told me about this monopoly while I was admiring his Hawkers sunglasses, a spanish startup. Prices are 15-40€.

https://en.wikipedia.org/wiki/Hawkers_(company)

"In 2014 the company's revenue exceeded 15 million euros,increasing to 40 millions the following year, and in 2016 Hawkers projected 70 million euros in sales."

openSUSE community packages for the editor:

2.x

https://software.opensuse.org/download/package?project=games...

3.0 git (not released yet)

https://software.opensuse.org/download/package?project=games...

It is remarkable what this team achieved in terms of how lightweight it feels, the shape and portability of the code-base and how high quality and full featured it is, given the complexity of the domain.

IMHO, it deserves to be in the http://aosabook.org series as open-source code-bases you would read and learn from.

I don't see the contradiction between Flatpack/xdg-app and keeping packages downstream. http://openbuildservice.org/ could end building xdg-app images in addition to rpm, deb, Arch and images it already builds. Why not?

That would keep security, reviews & processes while stopping the nonsense of requiring root, global state & single versions rpm/deb enforce to the user.

People seem to forget that ncurses is very low level and more equivalent to the painting engine of a GUI toolkit than to the toolkit itself.

The YaST project has a library called libyui ( https://github.com/libyui , C++) that provides a widget library with multiple backends: Qt, Gtk and also Ncurses.

The ncurses implementation has internally a very powerful wrapper on top of curses that does layout and other things you would only find in GUI toolkits.

I have always dreamed of extracting this code from the ncurses backend and making it a generic library, hopefully with a C API to allow for easy binding but I never got to it.

Closes thing I have found is python specific: http://urwid.org and some Java stuff like http://bmsi.com/tuipeer .

Miguel de Icaza also wrote a very nice toolkit for .NET ( http://www.mono-project.com/docs/tools+libraries/libraries/m... ) and it is also one of the most useful libraries out there, but it is still nowhere as powerful as the YaST one in terms of automatic layouts.

The world needs a good ncurses toolkit. Usability is a camp dominated by graphic designers, but I have never seen users happier than my dad using Quattro Pro in text mode.

I fail to see the difference with http://sparkjava.com

We are using Spark four new code in our product and we are happy with it.

> Is there any other Docker registry web fronted and/or user and ACL tool besides this and cesanta/docker_auth?

In order to learn how the authentication worked I implemented a very simple one based on htpasswd files: https://github.com/dmacvicar/garita

Engineering manager of the awesome guys working on Portus here!

We are hiring:

https://attachmatehr.silkroad.com/epostings/index.cfm?fuseac...

Thanks!. Most of the work, like in lot of opensource projects, was the product of a big team of great people, from which I learned a lot and I owe them a big part of shaping my career.

Completely different world!. Instant Messaging is now done in big part from the smartphone, or from a webpage while visiting a social network or checking email.

At that time, various things:

* At that time, most apps where available in their "desktop" versions. So if you used Gnome you tended to use Gnome versions of the app.

(it was a silly world back then)

* I was starting with development at that time, and the Gnome "SDK" was something I found not appealing at all. It could not even be called a platform, but a random collection of libraries. KDE on the other side was very consistent and appealing for developing GUI apps.

(And you may remember the KDE hate about non-standard-C++ and QObject, from the same guys that brought you Vala and GObject later)

* I had back then this opinion of not looking at my contact list by IM system, but by person with multiple transports.

That followed by KDE addressbook integration, etc. I would guess nowadays Pidgin also has this, but that was new back then. Kopete was a testbed for all this ideas.

* GAIM was not very stable back then

I implemented a part of a similar Facebook HTTP-based chat protocol in 2009. May be the same one?

I had started in 2001 a KDE multi-protocol messenger client called Kopete. I went inactive later but in 2009 I was using Facebook a lot so I "revived" my Kopete checkout to implement this custom protocol. I got the basics working: send messages and presence.

https://github.com/dmacvicar/kopete-facebook

Ironically, I stopped because they added XMPP support and Kopete already supported XMPP.

I now realize they deprecated XMPP it in early 2014, which is probably the reason Pidgin is now implementing the HTTP protocol I was looking at in 2009.

Whoever told you that, it is incorrect information. There are remote workers at all levels of the organization.

You should not confuse that with "every position is open to be hired remote". There are teams that are setup for that, others that are not. Even for the same position, it depends a lot on the candidate.

About telecommuting, we call that home-office and has nothing to do with "remotes". It only applies to people working in office locations (obviously). You can work from home if you have a reason for it (something delivered, big cold but feeling well, sick child, etc.), but it is not like "I am not in the mood of going to the office today so I stay home".

I am not sure why would you say that. The company has a big chunk of people working from remote locations all over the world, not only developers but also managers.

The fact that the possibility to work remotely is evaluated based on the candidate experience, the location (eg. cost to the team to meet in person), timezone, and the location of the rest of the team, does not mean hiring locally is a policy. It is completely up to the team with very few exceptions.

It is not unicorns either.

* Transforming a collection means doing boring for loops instead of one-liners. * interfaces/duck typing is great. But hey, []interface{} does not fit into interface{}. * Structs with fields are encouraged, but there is no uniform Uniform access principle and that sucks. * etc

But definitely, my own "science" confirms that it turned to be out less of a problem (for my own usage) compared to better languages with more friction.

I was following Rust very entusiastically. But at some point the language was getting itself in the way of the problem I was solving.

I am not only talking about the strict compile checks. I am talking about that extra thinking in the ten ways you can design it and how it should be done in "proper" Rust.

And the friction is not only in the language, but also in the standard library. A language that comes with XML/json marshal/unmarshal plus a quite decent http client/server framework covers most of what I need to do.

I am sure if Rust had included in the standard package http/xml/json it would be far more popular. I understand the voices that say "It does not belong there", "the language is not targeted at that". Fine. But then I found myself having not much user for the language, even if I loved the idea/theory behind it, plus that I could not get comfortable thinking in it.

If you write Go code, you will realize you will actually not hit that problem often at all.

Right now the annoyance I hit more often is the inability to map a []Foo on an attribute .Name (string) to get a []string. I do that in ruby all the time, and with Golang it really sucks to do a for loop to collect stuff appending to a new array.

  people.map(&:name) => ["Joe", "John"]

vs

  a := make([]string, 0)
  for _, p := range people {
    a = append(a, p.Name)
  }

I had the same opinion as you until I started some code with it.

The true is that I had never been so productive writing code. The friction from what is in your head and the code is almost 0.

It is true that I ended writing a few functions that were there only because the lack of generics, the type system and other stuff being "built-in". But at the end, I think it was an order of magnitude less often than I was expecting it to. I was wrong.

SUSE is hiring for 66 different positions. 39 in Engineering. (REMOTE OK², CAN OFFER VISA, RELOCATION SPONSORSHIP)

  - Nuremberg, Germany, Prague
  - Czech Republic, Beijing, China
  - any SUSE location globally or home office

We have positions open for Docker developers, Kernel engineers, Java/Linux developers, Ruby hackers, Rails developers, OpenStack engineers, and QA engineers.

SUSE is a 20+ year old company providing a rock-solid enterprise Linux distribution. You can see where we lead here: https://www.suse.com/promo/suse-leadership.html

What do we offer:

  - Direct contact with representatives of free/open source software projects
  worldwide.
  - Regular hackathons (Hack Weeks) and workshops on the company, department,
  and team levels.
  - Five weeks vacation. (¹)
  - Contributions to pension insurance or capital life insurance. (¹)
  - Other common employee benefits (food coupons, health care, sports and cultural
  activities). (¹)
  - Free beverages. (¹)
  - We know how to party.
  - We celebrate success.

All job postings are available here: https://attachmatehr.silkroad.com/epostings/index.cfm?fuseac...

  ¹ Reference for the example benefits is the office in Germany.
  They may vary across hiring locations.
  ² Please note that not all positions are available for remote workers and
  still relocation may be preferred.

I don't think it makes sense. I am the hiring manager, but I only ~5 positions available where I am the hiring manager. My company has ~50 positions open for engineering.

Do you prefer to see 10 posts from my company, from each hiring manager with open positions?

Former libzypp/zypper developer here.

It was not mentioned in the post that dnf is based on the openSUSE dependency SAT solver (libsolv) that was created by Michael Schroeder years ago and that powers libzypp and zypper since openSUSE 11.0.

The dnf developers built a thin layer on top of it, called hawkey, and then build dnf in python on top of hawkey.

One of the biggest innovations of libsolv is not only the SAT based solver but also the .solv format which allows to store package metadata for big amounts of packages in an efficient way and operate the solver directly on it.

https://github.com/openSUSE/libsolv

dnf _is_ using openSUSE's sat-solver (libsolv). They reinvented the upper layers.

I see. Well, from the homepage, the developer sells the builds so I can understand he is not interested in making packaging and distribution easier.

It looks awesome.

First thing that looks like candidate for contributions is a build system. I tried to build a package out of it and it is a collection of Makefiles and shell scripts that for sure can be used to build the thing on a developer's machine, but not useful outside that context.