Slash Boxes

SoylentNews is people

posted by janrinok on Tuesday November 03 2015, @02:22PM   Printer-friendly
from the same-old-routine dept.

It looks like Microsoft hasn't reformed as some would like to think, but has moved its embrace, extend, extinguish policy to the mobile platform. In this article from , we see a company (responsible for Mono) with strong MS connections take over an open source project and close it.

LAST WEEK we wrote about Xamarin's disturbing takeover of RoboVM [1, 2], which was a threat to Microsoft's monopoly and domination of APIs (especially on the desktop). Xamarin, for the uninitiated, creates proprietary software that strives to spread Microsoft's .NET to mobile (including Android) devices.

It has only been less than a week and now we learn from Abel Avram that "RoboVM Is No Longer Open Source".

"Following RoboVM's acquisition by Xamarin," explains Avram, "the company has raised the price of their offering and has closed the source code."

Discussion of a fork is in the works:

It has gotten so bad that RoboVM might be forked. To quote Avram, "some developers consider that closing down the source code has to do with Xamarin's acquisition. And some are discussing forking the project, perhaps starting with the sources v. 1.8 which will be pushed to GitHub this week, according to Zechner. It remains to see how successful they are in their endeavor considering that RoboVM is not a trivial piece of software."

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday November 03 2015, @04:11PM

    by Anonymous Coward on Tuesday November 03 2015, @04:11PM (#257987)

    "Except by making a large number of vital projects dependent on systemd."

    What, the vital projects that RedHat themselves created, whose developers are on the RedHat payroll? Again, your problem is with your distribution's package maintainers.

    OpenBSD has the latest Gnome, does *not* have systemd, and I'd venture to say, works better on your laptop out of the box than whatever Linux you are using.

  • (Score: 3, Insightful) by khallow on Tuesday November 03 2015, @04:32PM

    by khallow (3766) Subscriber Badge on Tuesday November 03 2015, @04:32PM (#257993) Journal

    What, the vital projects that RedHat themselves created

    There are a number of projects that RedHat didn't create, but merely took over the maintenance for such as udev. Others they have maintained and transitioned to a dependency on systemd later such as D-Bus. And notice the use of the word, "dependent". These aren't projects that merely support systemd, but projects that require systemd in order to function.

  • (Score: 4, Informative) by khallow on Tuesday November 03 2015, @04:38PM

    by khallow (3766) Subscriber Badge on Tuesday November 03 2015, @04:38PM (#257995) Journal
    In other words, RedHat has created a large number of unnecessary systemd dependencies. Here's an interesting example [] of those dependencies in action:

    The reason I believe it is bad design is, that it makes the combination of projects more difficult to maintain, more complex to understand (because of the new cross-links), and it makes it more difficult to swap one of the component projects with a newer, better version that is not under the same umbrella. How am I going to use syslogd-ng or rsyslogd or [even better future syslogd], if everything under the systemd umbrella is rewritten to only log to libsystemd-journal0?

    An example: does your company ever need to print?
    cups depends on cups-daemon
    cups-daemon depends on libsystemd0 (apparently all those libs are now joined together into libsystemd0 (since version 215); I hadn't noticed that.

    cups-daemon also recommends on colord (recommends are often installed automatically)
    colord depends on libsystemd0
    colord depnds on libpolkit-gobject-1-0
    libpolkit-gobject-1-0 depends on libsystemd0

    cups-daemon also recommends (not depends) avahi-daemon
    avahi-daemon depends on dbus
    dbus depends on libsystemd0, do you know why? because it used to depend on libsystemd-journal0, do you know why? Because nifty binary logging, that's why.

    I can tell you from my own experience that it's already not trivial to *not* install systemd.

    • (Score: 5, Interesting) by Bot on Tuesday November 03 2015, @05:36PM

      by Bot (3902) on Tuesday November 03 2015, @05:36PM (#258014) Journal

      How to stress test a BS meter:

      - this is package A, it depends on package X and not on functionally equivalent packages Y, Z... that have been distributed since forever.
      *BS meter already pulsing an unsettling orange/brown*
      - uh, ok, it depends on it to perform what?
      - for logging purpos...
      *BS meter goes BLAM!*

      systemd is not at all surprising once you factor in that, by thriving on services and assistance, RH has no incentive in producing transparent, stable systems and opaque, unstable systems tend do be buggy.

      Account abandoned.