Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 :
> Even if they can not present an argument like I have,
> they will probably only notice it if it misbehaves in some way. If it
> misbehaves more than other software on their system, who is to say it
> isn't a poorly designed language and/or ecosystem?

I think that on a technical mailinglist you should convey your point
using technical arguments, not rhethorical ones. The reasoning is
errorneous. If your goal is not ultimate API stability, then Ruby's
design approach that focuses more on progress than on ultimate API
stability is not poor, but different. You can agree or disagree with the
goal, but you can't question the measures taken to implement it by first
stipulating a goal different from the one the measure was intended to
implement. Take a look at Ruby's versioning policy[1]; ultimate API
backward compatibility is not a design goal in minor versions of the
language. Ruby is simply not the right tool for the job if you want to
create for example an archive software that must run 20 years without
touching it.

Even though, the problem is not as dramatic as you seem to imply. I
stand by my point that using private C interfaces is the programmer's
fault and there is nothing to be standardised here. Real breaking
changes of documented behaviour like the Bignum/Fixnum one are rare, and
the effects are moderate. Most of the software written in Ruby will not
have a problem with running on newer versions.

Marvin

[1]: 
https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 :
> I think the takeaway from Alan's comment is that Python is unnaturally
> stable compared to other interpreted languages. One might be inclined
> to think Python developers consider their work to be a widely used
> tool as opposed to a toy to play with.

If you regard Ruby as a toy language, I'm inclined to say that quite a
number of (most often Rails) applications use it in for serious
projects.

> Then why does he have all three installed?

I cannot answer that. I lack the insight into the Gentoo Ruby deployment
process.

> These are all fairly major changes for a minor release. I'm not really
> sure any of this evidence supports the opinion that Ruby doesn't
> experience breaking changes more regularly than other languages.

I have not made the claim that Ruby is more stable than other languages,
especially did I never say that Ruby is as stable as Python. My
intention was the counter the statement that every Ruby minor release is
a "complete new language". The changes I listed are breaking, but not to
a degree that justifies the "complete new language" statement.

> Leading into my next point, I remember some conversations about people
> discussing the Ruby parser and how there was no BNF description of the
> language. Consequently (from memory) there was at least one
> implementation of Ruby were encountering regressions in the parser
> between versions that were undocumented and not detected until the
> releases had already been made. The result was that code was
> semantically different between some versions. Regrettably I'm having
> trouble citing this one.

It was JRuby as far as I know, but don't nail me on that. I don't have
it ready either, nor do I have the exact circumstances in memory.

> Situations like the above, and reliance on private C interfaces, are
> what makes it seem plausible to me that there are packages that
> require a version that has no listed breaking changes.

Using unsupported private C interfaces is going to make any package
break in any language over time. This is not Ruby's fault.

> This statement makes me think you haven't tried to understand the
> issue, as that ISO document - to the best of my knowledge, I can't
> actually view it without paying money - implements Ruby 1.8.1 and
> potentially some features from 1.9. Hearsay indicates it was started
> at the behest of the Japanese government so that they could use Ruby
> for internal projects as their rules seem to require standards
> documents for software. This is important, because it shows that there
> is no real effort by Ruby's lead developer or the Ruby community to
> produce a legitimate standards document.

I've not worked with the ISO document. You requested a formal standard,
and I replied that there's an ISO document, which I regard as a
standard. I didn't know that it describes such an ages old version of
Ruby (though I should have known better given the date). Since the 2.4.0
release post on ruby-lang.org justifies removal of Fixnum/Bignum with
the interpreter not being compliant with the ISO standard, I was under
the impression that it was still usable. If it isn't, I apologise.

> In practice one finds more references to something called RubySpec
> which is an executable implementation of what people like to call a
> specification. RubySpec appears to be discontinued[1], but even when
> it was in use there are three things that should be pointed out:

The RubySpec was started as a community effort indeed, but if you only
read the Rubinius view of it, you're going to see a lot of bias. The
Rubinius main maintainer retracted from the effort by his own
decision. Consequently, the RubySpec is now maintained by the core team
of the canonical Ruby implementation[1]. Thus, it is not true that the
core developers do not make use of RubySpec.

> If you look at the RubySpec code you will see that the "specification"
> consists of testcases that attempt to define the behavior of Ruby. As
> mentioned, these tests are written in Ruby, and are subject to bugs in
> Ruby that are made undetectable, or very hard to detect, by the
> self-referential relationship of the behavioral specification and the
> language.

This sounds logical to me, and I agree. I'm not the correct person to
address this to, though. From the formal point of view, I surely cannot
compete with you. The spirit in the Ruby development appears to follow
not a formal, but a practical approach, which is always going to be
inferior.

> What I have read in this regard leads me to conclude that Ruby is not
> a language that I should use for my development, and it pains me to
> say this.

Use the tool that fits the job for you. I wonder if I was perceived as
using Ruby everythere; this isn't the case. Actually, I don't write much
Ruby code currently, but much more C/C++.

Marvin

[1]: https://github.com/ruby/spec

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
> Seeing as the OP is saying there are 3 versions queued for merge and
> he has not installed any of them by hand it looks like Alan is
> right. Perhaps the OP is using "old" Ruby based software, but software
> of that age in another language could work on new interpreters.

I took a moment and looked up the release announcements for the minor
version releases between the versions the OP has installed:

* https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/
* https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/

2.4.0 saw breaking changes, 2.3.0 not. In 2.4.0, the most notable
breaking change was the unification of Fixnum and Bignum into
Integer. Other breaking changes affected the standard library (stdlib):

* Tk was dropped from the stdlib.
* XMLRPC was dropped from the stdlib.
* Support for OpenSSL <= 0.9.7 was dropped from the stdlib.

For Tk specifically, the reason for the removal was that the maintainer
got demotivated by useless and even hostile feedback[1] and since nobody
wanted step up, the library was removed from the stdlib[2].

The exact judgement of how grave these changes are is subjective. Fixnum
and Bignum were not classes commonly used in Ruby code, so it may be
viewed as a detail. They saw a more frequent use in C extensions, which
may then be viewed more grave; the release announcement iself is pretty
clear on this topic:

Ruby 2.4.0 release announcment from 2016-12-25:
> All C extensions which touch the Fixnum or Bignum class need to be
> fixed.

I was not too happy with this either, but most software continued to
work.

I don't know the reason why the OP was left with three versions of
Ruby. Given the above release announcements, there are not too many
reasons why his software should not work with newer versions of
Ruby.

All this only applies to the core language. Some RubyGems packages
release very rigorously and some even make use of undocumented features
of (the C interface of) the Ruby language. That's however a different
problem.

Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
> One of the reasons I dislike Ruby is that there is no complete
> specification of the language available, making this statement
> (technically) untestable.

There *is* a formal complete ISO specification of the language available,
approved in 2012[3].

Marvin

[1]: Exact reasoning of the maintainer is here (in reply to me):
 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401
[2]: https://bugs.ruby-lang.org/issues/8539
[3]: https://www.iso.org/standard/59579.html

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 02. September 2017 um 22:57 Uhr +0200 schrieb Alan McKinnon 
:
> OK, so disclaimer up front. I detest Ruby. I hate it with a passion.

There is nothing one can do against that, but...

> Each new minor version of ruby is a whole new language and the devs
> are OK with large breaking changes between minor version numbers.

...this is factually incorrect. There are new features added quite
often, but minor versions are generally backwards-compatible. The one
exception was the 1.8->1.9 switch years ago. I have done quite a bit of
web developing with it and never had an API break problem with Ruby
itself, save the aforementioned 1.8/1.9 switch.

Granted, gems are quite different. RubyOnRails especially releases new
(breaking) versions way too fast for me; that's why I prefer to use
different libraries.

Marvin

Re: [gentoo-user] Recommended CDR-Burning-frontend without QT and without KDE?

[Marvin Gülker]

I find bashburn a fairly nice tool, but for reasons unknown to me it
always fails when burning DVDs. Otherwise it does fine.

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

Re: [gentoo-user] [Off-Topic] arch-openrc

[Marvin Gülker]

On Thu, Mar 09, 2017 at 07:57:19AM -0500, Rich Freeman wrote:
> Honestly, as somebody who monitors all the systemd bugs on Gentoo it
> isn't actually that much work, and I suspect that it wouldn't be that
> much work maintaining openrc scripts on Arch.  I doubt they rename the
> apache binary 3x per year, or move its location around the filesystem.

Maybe not the apache binary, but who keeps track of things like sticking
the logrotate cronjob into systemd timer unit files (something I just
recently experienced on an Arch machine when I was looking for where
logrotate was called from and how often)? Changes to mount units? Other
things absorbed by systemd? It's not like going without systemd is just
about setting different compilation options on upstream software. Not to
mention upstream software that has a hard dependency on systemd, like
GNOME I have heard -- these are going to require patching. Things like
these are going to grow rather than shrink, so I expect much work to come
onto the no-systemd people.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

Re: [gentoo-user] [Off-Topic] arch-openrc

[Marvin Gülker]

On Wed, Mar 08, 2017 at 06:50:17PM +, Mick wrote:
> Well what do you know?!  Alternative to monolithic stack solutions now exist 
> as alternatives for other distros too:
> 
> https://sourceforge.net/projects/archopenrc/

The GitHub links on that page are broken (404).

I was an Arch user before, and switched to Gentoo due to its prime
support for OpenRC, where it is no second thought shoehorned ontop of a
distro focusing on systemd.

With Arch, it's different. The no-systemd people need to run after all
cahnges made by the Arch team, and then place their own changes on top
of that. This creates certainly a lot of work, and certainly requires a
lot of manpower, which I am not sure these people have available. This,
in consequence, leads me to security considerations. How quickly do
security problem fixes propagate to arch-openrc? Also, is there some
kind of non-IRC community like a mailinglist or a forum for them, so
that one can at least estimate its popularity? Do they even have a
website with RSS-subscribable announcements?

There is a wealth of Linux distros with one person behind it. I will not
use such Linux distros, because whenever something happens to this
person, all users are screwed (I have heard people referring to this
phenomenon cynically as the "truck factor" or "bus factor", a term which
I not necessarily like due to its fatality -- the person might also just
lose interest).

I will watch what happens around systemd-free ArchLinux, but for the
time being, I will stay with Gentoo happily on a well-maintained
OpenRC.

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

Re: [gentoo-user] Wrong SHA512 checksum for 20160630 amd64 minimal installation medium

[Marvin Gülker]

Am Tue, 5 Jul 2016 15:07:03 +0100
schrieb Stroller :
> This doesn't address the wider implications of this dodgy checksums,
> but I think most people on this list install using SystemRescueCD.

Okay, I’ll go that route then. Thank you again!

Greetings
Marvin

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

Re: [gentoo-user] Wrong SHA512 checksum for 20160630 amd64 minimal installation medium

[Marvin Gülker]

Am Tue, 5 Jul 2016 13:26:50 +0300
schrieb Andrew Savchenko :

> Checksums are indeed wrong, whirlpool one too. Thanks for noticing,
> I opened a bug for this:
> https://bugs.gentoo.org/show_bug.cgi?id=588062

Okay, thank you. This has been now marked as a duplicate of another
bug[1], which in turn links to a message on the gentoo-mirrors ML[2]
from about a month ago.

I am not sure I understand the implications. Are the amd64 images all
corrupt, and thus should not be used for installation? If so, they
should not be linked to on the main download site. If not, can someone
with access to the GPG signing key please publish the correct checksums
signed somewhere so we have an interim workaround?

> In future please file bugs for similar issues right ahead.

Noted.

Greetings
Marvin

[1]: https://bugs.gentoo.org/show_bug.cgi?id=581638
[2]:
https://archives.gentoo.org/gentoo-mirrors/message/a9fbc7213f832e9918784bb8d334628b

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

[gentoo-user] Wrong SHA512 checksum for 20160630 amd64 minimal installation medium

[Marvin Gülker]

Hi everyone,

I was wanting to give Gentoo a try today, but failed to verify the
current minimal installation medium for amd64[1]. The .iso file does
not match the SHA512 checksum provided in the .DIGESTS.ASC file[2]. The
wrong checksum was confirmed by a user in the #gentoo IRC channel on
freenode.net as well.

FYI, the wrong checksum is:

f04f987f5e94a1aa8c9ffc8a08c3bdbed0afd44f680342738d504b7149b9e6bbc49ee1fad851d7eef89103e43fefacaa57e6c7f768d164c3c4e77612e6847a35
install-amd64-minimal-20160630.iso

Can this please be fixed?
Thanks!

Marvin

[1]:
http://distfiles.gentoo.org/releases/amd64/autobuilds/current-install-amd64-minimal/install-amd64-minimal-20160630.iso
[2]:
http://distfiles.gentoo.org/releases/amd64/autobuilds/current-install-amd64-minimal/install-amd64-minimal-20160630.iso.DIGESTS.asc

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F