<havenwood>
Ruby 3.2 is in security maintenance mode, where bugs will *not* be fixed.
<havenwood>
Ruby 3.3 and later are stable and supported.
<havenwood>
nakilon: Ruby 2.7 has known, unpatched critical security vulnerabilities that will never be patched.
<havenwood>
nakilon: Apple may meticulously backport patches, but I'm highly suspect of your presumably unpatched 2.7.
<nakilon>
we are doing browser autotests, there is no such thing as vulnerability here
<havenwood>
That's terrifying.
<havenwood>
Oh, you mean like headless browser testing?
<nakilon>
yeah
<havenwood>
gotcha
<nakilon>
no web servers
<nakilon>
no user inout
<nakilon>
*input
<nakilon>
we just need things to work
<havenwood>
Ruby probably isn't the right fit if there's no maintenance budget to keep it updated.
<nakilon>
that's why I hate a very popular misunderstanding of gem maintainers that are bumping the ruby version in gemspec for no reason
<havenwood>
It gets harder and harder to move it forward, to the point that a rewrite is preferable even.
<nakilon>
like, dude, you are not doing ruby, you are doing a gem
<nakilon>
I don't care of you personal security reasons and what you host, etc,, we just use your gem on a Mars lander with no humans in 100000000 km around
<havenwood>
There are a few reasons though. Gem maintainers are constrained by all the missing or divergent features. We also want to encourage leaving unsupported Rubies.
<nakilon>
it's like my personal decision
<nakilon>
it's like encouraging politics
<nakilon>
one should bump the gem version only if there are features used that aren't available in old one
<nakilon>
like "..." in args
<nakilon>
that's the only reason for ferrum I saw to bump it
<nakilon>
and that feature is so decorative anyway
<nakilon>
I just want some fix in your gem and you say "I'll give you this fix only after you bump every other gem in your Gemfile due to new rubies", and what if another gem doesn't work on new ruby? that's stupid
<nakilon>
I'm pretty sure those people aren't even "encouraging" me, they just don't understand what they are doing
<nakilon>
most of them
<havenwood>
nakilon: For sure many open source maintainers explicitly choose when to drop support. It's quite common. It's usually intentional.
<nakilon>
I don't need web security vulnerability fixes on my Mars lander; it's like they are confusing ruby and rails
<havenwood>
Mainstream things like RubyGems and Minitest also drop support for older Rubies. They go a bit beyond supported stable, but have a line.
<nakilon>
I often see the gems I use support even 2.0
<nakilon>
they bump for no reason, just "because ruby is EOL"
<nakilon>
and that's not a reason for your gem to stop working
<havenwood>
I can't imagine supporting 2.0 when Ruby 3.3 is the latest stable. It's really, really not "no reason" since there are great reasons.
<nakilon>
it's like... do you deinstall the videogames via Steam from my PC if they were compiled in C++ that has a vulnerability?
<nakilon>
imagine the singleplayer games stopping working just because the developer decided it to
<havenwood>
It's a significant maintenance burden to make something work across versions where bug fixes are no longer provided. It can become super hard to make portable code, when nobody is doing any fixes for out-of-support versions.
<nakilon>
just for absolutely unrelated reason
<havenwood>
This isn't a game, it's a thing you need to keep updated.
<havenwood>
There are LTS-focused langs, but Ruby is not one.
<nakilon>
"since there are great reasons." -- what reasons? if the gems just works
<nakilon>
*gem
<havenwood>
nakilon: Gem authors receive PRs, typically using modern conventions and it becomes incredibly annoying to backport all contributed code. There's a cognitive overhead of making sure it works back way beyond any Rubies modern folk are using.
<havenwood>
Writing code that works for 2.0 and 3.5 can require silly branching for version differences that convolute your codebase.
<nakilon>
" it's a thing you need to keep updated" -- who said that? if I don't update the ruby on my Mars lander, it will crash? why?
<havenwood>
Enabling folk to be on Rubies that are broken and have vulnerabilities in ways users can't imagine is also considered harmful.
<havenwood>
nakilon: To be clear, no Mars lander uses Ruby or will. I've seen Ruby modeling in space and some Lunar landing mock code but it's not meant to run for years without updates.
<havenwood>
Use the right tool for the job.
<havenwood>
Please don't run Ruby 2.0 on Mars landers. Not great!
<havenwood>
One of the things you accept when using Ruby, typically, is that you'll need to keep updated. If you don't, from my experience, pain ensues.
<nakilon>
first they should provide a reason why they run 3.5 on their Mars lander; there might be none, and until then, there is no actual need to bump
<nakilon>
it's just a waste of time, resources
<havenwood>
nakilon: Nobody is running Ruby on a Mars lander. That's a nonstarter.
<havenwood>
It's fair that for some modeling jobs, the version can have known vulns and it's airgapped.
<nakilon>
bank I worked in works perfectly on the language from 1950s
Rounin has quit [Ping timeout: 245 seconds]
<havenwood>
The imperfection comes from orders of magnitude more maintenance burden.
<nakilon>
because there is literally no reason to upgrade; newer software for those needs does not even exist
<havenwood>
You *can* patch Rails 1 for every CVE. Or you can use Rails 8. Do the latter.
<havenwood>
It's far easier and makes for a much better codebase.
<nakilon>
where do you see Rails on Mar lander?
<havenwood>
The same place I see Ruby on a Mars lander. Absent.
<nakilon>
browser automation isn't a website
<nakilon>
it's kind of even an opposite thing
<havenwood>
I think it's a bad idea to use old tools that are meant to be updated. Seem lazy.
<havenwood>
The pain it brings is pain I don't want.
<havenwood>
If I'm going to use Ruby, I'm going to use modern, stable Ruby.
<nakilon>
I still see no argument
<havenwood>
As a gem maintainer, I won't support folk who disagree.
<havenwood>
It wastes my time and energy.
<nakilon>
I see no argument, why would we need 3.5 to command the browser to click links?
<havenwood>
You can use FORTRAN to click browser links. I wouldn't.
<nakilon>
there was none new ruby features relevant to our job
<nakilon>
there is no capybara on fortran
<nakilon>
we just need capybara and rspec working
<nakilon>
we don't build a website with rails and user input; we are just programming in ruby
<havenwood>
In my experience, staying religiously updated pays off and trying to somehow save by staying in the past is a path of pain.
<nakilon>
the only pain for 8 months I work here was due to the upgrade, not vice versa
<havenwood>
I'd rather just update, pay down that debt, and move forward. Granted, with super large codebases it can be nontrivial but on the other hand I see orders of magnitude more time spend on inferior attempts and old tech,.
<havenwood>
At some point, of course, your 2.7 will fail. Pay to update to Ruby 4+ or just throw away the code or continue to dig?
<havenwood>
If you upgrade when able, you have a path.
<nakilon>
oh, there was one catch -- the ':has()' syntax for CSS selectors, so older Alpine linux Chrome does not fully support it; but is there newer Chrome in newer docker image? that's another question
<havenwood>
If you stick to 2.7, it's a time bomb that exploded a couple years ago and will keep going off.
<nakilon>
we can just live with xpath, that selector was made only once in a hundred
<havenwood>
Fun fact, I bumped my sha3-pure-ruby Ruby version requirement (which I normally don't do) just to get Etherium gem to stop using my amateur crypto lib.
<havenwood>
I guess my fault for not saying "I am not the professional cryptographer which you seek" caveat.
<havenwood>
On the other hand, there's a thin line between "professional cryptographer" and "compromised by the NSA" so YMMV.
<havenwood>
For anything that matters, I prefer to encrypt with various approaches in order, so you'd have to break each to get back to the payload.
<havenwood>
In most my cases, there's no need to run on minimal resources and redundancy is prudent.
<nakilon>
we have a lot of work to do, a lot of funcionality to be tests covered; come and tell our investors that we have now just stop the tests coverage due to the "security vulnerabilities" that are not relevant to our software in any way
<havenwood>
I think there are far too few cases where there's redundant encryption.
<nakilon>
it just makes no sense
Rounin has joined #ruby
<nakilon>
who will continue writing tests and the library? you?
<havenwood>
No, I will explicitly call for your gems to discontinue support.
<havenwood>
Your Ruby is already unsupported.
<nakilon>
while I'm bumping versions and spend weeks on reporting bugs in dozens of used gems
<havenwood>
You're on a dying branch. I don't have to break it for it to be over.
<havenwood>
If you think you can stay on 2.7 indefinitely, you're mistaken.
<havenwood>
I suspect it'll be better to migrate away from Ruby at some point, if you can't manage to keep updated.
<nakilon>
you still provided no argument
<nakilon>
why do we need upgrade?
<nakilon>
what does not work for us?
<nakilon>
we don't do website
<havenwood>
You are on a Ruby with critical security vulnerabilities, the implications of which you may not understand. The gems you use have no interest in maintaining compatibility and will one by one fail. You are islanding yourself without a raft.
<havenwood>
Going from 2.7 to 4.0 is far, far harder than incrementally updating.
<nakilon>
I told you 10 times, there is no security vulnerabilities in our software, we are not doing websites
<havenwood>
Trying to skip versions, I've hit a lot of pain. Just upgrading as changes come along is smooth.
<havenwood>
nakilon: The idea that Ruby 2.7 just keeps working is folly. It already has critical security vulnerabilities and unpatched bugs. It only gets worse. It will only run on OSes that themselves are unsupported fairly soon.
<havenwood>
How is this your path forward?
<havenwood>
When your OS won't run 2.7, are you thinking to upgrade all at once to 4.2 or whatever is out?
<nakilon>
I don't understand what you don't understand in "we don't do websites"
<havenwood>
What's the plan?
<nakilon>
there is no way to utilize the vulnerabilities
<havenwood>
You need to run an OS to run Ruby, period.
<nakilon>
nor rare bugs
<havenwood>
You will fall out of support. Your Ruby is unsupported. No supported OS will build 2.7 soon.
<havenwood>
What's the plan?
<havenwood>
I assume switch to unsupported OS. Or already there?
<nakilon>
we use docker
<havenwood>
Do unsupported Docker with unsupported OS running unsupported Ruby soon?
<havenwood>
That *seems* bad.
<kjetilho>
it's not a good way to promote Ruby, though. doing arbitrary changes to the language which breaks old code for no good reason
<havenwood>
I guess you can probably keep Docker updated, but it doesn't change modern OSes being unable to build Ruby 2.7.
<kjetilho>
so... lesson learnt is to avoid Ruby in the future
<havenwood>
kjetilho: I'm not promoting Ruby. I'm promoting reality.
<kjetilho>
*shrug*
<nakilon>
ok, tell me why the minimal ruby version directive in gemspec isn't automatically adjusted by Time.now? why don't we make the whole software on the Earth globe stop working on the EOLed ruby? nice feature, heh?
<havenwood>
Ruby is great. Use a supported version.
<havenwood>
It's not rocket science to use a version that still supports security patches.
<kjetilho>
this is why I prefer Perl with its warts. at least they don't break existing code.
<havenwood>
kjetilho: I wouldn't run Perl on a Mars lander either.
<havenwood>
But I'd probably lean that way.
<havenwood>
Stability is a thing.
<nakilon>
why does not all ruby software automatically stop working depending on system datetime?
<havenwood>
nakilon: Huh?
<nakilon>
why does 2.7 run? let's delete all docker images from dockerhub and implement the "Thread.main.exit if Date.now.year > ..."
<nakilon>
by your logic
<nakilon>
by your logic things should just stop working
<nakilon>
that's insane
<nakilon>
and stop playing Half Life 2, it's compiled with old C++
<havenwood>
nakilon: When you use tools, use supported versions.
Sampersand has joined #ruby
<havenwood>
If you use unsupported versions, at least don't complain about lack of support.
<Sampersand>
what versions
<nakilon>
who does complain?
<havenwood>
Sampersand: Ruby 2.7.
<nakilon>
I literally tell you things are working fine for us on 2.7
<Sampersand>
oh, thats not too ancient... is it?
<havenwood>
Sampersand: Ruby 3.2 is past end of life, so not ideal. But yeah, at least not Ruby 2.0.
<Sampersand>
i mean ruby builtin to macs is 2.6, no?
<nakilon>
there is no single Ruby newer feature that we would need to automate browser "better" than with 2.7, we just call "find(:xpath, "...").click"
<havenwood>
The idea is to keep using Ruby 2.7 for headless browsing indefinably without updating. I'm saying that's folly.
<havenwood>
Sampersand: A patched version, yes.
<havenwood>
The 2.7 isn't patched but apparently is for internal headless browsing.
<havenwood>
Practically, it may be secure, but seems like a poor maintenance policy for moving forward sanely.
<havenwood>
Just pay down your update costs and stay in the now. That's what I'd recommend.
<havenwood>
Even for extremely large apps where it's painful, I think it's prudent.
<havenwood>
Sometimes you know your product is nearing EOL and you can stick on an old product that has limited span.
<nakilon>
do you stop listening to old music?
<nakilon>
Beatles, it's so unmaintained
<havenwood>
nakilon: Beatles have not reached end of life.
<nakilon>
things just work
<nakilon>
don't they? ..D
<havenwood>
Ringo, maybe.
<havenwood>
But "no" there's not an equivalence.
user71 has quit [Quit: Leaving]
<havenwood>
Don't use unsupported Rubies. It's a bad idea and if you do please don't ask for gem or Ruby support since it puts a burden on maintainers.
<havenwood>
Ruby has chosen to make few breaking changes but require updates.
<nakilon>
the only thing that has to be update in our job is Chrome, and it's soooo much about edge cases, that it is practical to not think about it; the whole software development science is about practical compromises and knowing the priorities
<havenwood>
If you'd like to use Ruby, it's best to abide. You can ignore it, but it gets either painful or impossible to continue at some point.
<havenwood>
nakilon: It may serve you for a year or two more, then *no* OS will be able to build your antiquated, unsupported tools.
<havenwood>
You can get to that point, but should you?
<nakilon>
the priorities should be set depending on reality, not the imaginary and detached from reality ideas; like "DO we write website? No -- ok, then we don't need this patch..."
<havenwood>
In my experience, it's folly. Updating is required, not optional. Do it incrementally rather than catastrophically breaking your stack when it comes to a head.
<nakilon>
"don't ask for gem or Ruby support " -- who does?
<havenwood>
nakilon: I recall you griping about lack of unsupported Ruby support in this channel, if I'm not mistaken.
<nakilon>
we only ask for opposite -- stop editing the gemspec, we have to fork it due to this pointless bump
<havenwood>
Unsupported Rubies are unsupported.
<havenwood>
I don't want to spend time on your attempts to keep the dead alive.
<havenwood>
I'd recommend other gem maintainers do the same.
<nakilon>
no one asks, only the opposite
R2robot has quit [Ping timeout: 276 seconds]
<havenwood>
They tend to, which granted causes you issues but they're self-imposed pains from choosing to stay on officially unsupported versions.
<havenwood>
We support supported Rubies.
<havenwood>
Use a supported Ruby for supported gems.
<nakilon>
my gem dhash-vips was broken due to upgrade, not degrade; the fact that musl isn't supported does literally prove that it is bad to update the ruby, not vise versa
<nakilon>
*vice
<havenwood>
You've learned the wrong lesson.
<nakilon>
btw some guy came and fixes the issue, I can't find time to review the puoll request
<nakilon>
"We support supported Rubies." -- no, you don't; the musl is abandoned since 2.4
<havenwood>
You can ignore stable, supported versions but in my experience it's path of pain. Nobody wants to help you stay in the past.
<nakilon>
and still no good docs on native extensions, they are just getting outdated
<nakilon>
AFAIK
R2robot has joined #ruby
<nakilon>
you literally misread me
<nakilon>
the gem is broken on NEWER versions
<nakilon>
not on older
<nakilon>
once they made ruby 2,4, the things broke
<nakilon>
and they didn't fix since then
<nakilon>
some new build chain or whatever was made, some new libraries, and literally zero docs and support
<nakilon>
it was some Bigint-related update
<havenwood>
nakilon: Unsupported gems not updating support doesn't seem compelling. I update in part to know what to move away from due to lack of ongoing support.
<nakilon>
but I'm not even sure it was the reason it broke
<nakilon>
the ruby version bump was equal to drop of support
<nakilon>
anyone pursuing newer ruby for whatever reason would just lose the native extension speed boost
denvermullets has joined #ruby
___nick___ has quit [Ping timeout: 252 seconds]
brokkoli_origin has quit [Ping timeout: 260 seconds]
Sampersand has quit [Quit: Client closed]
brokkoli_origin has joined #ruby
<havenwood>
nakilon: I agree stability has a real advantage. Then again, when in Ruby I update. YMMV.
<nakilon>
havenwood: 🤝
denvermullets has quit [Ping timeout: 268 seconds]
denvermullets has quit [Remote host closed the connection]
<o0x1eef>
Could be wrong on this one but updating Ruby has not been that much work in my experience and it is usually worth it.
<o0x1eef>
The longer you leave it, the more the odds are that it will be a challenge though.
<o0x1eef>
It is a culture issue. If you just never think about it it will eventually come to bite you in one way or the other IMO.
<kjetilho>
yes, it is a culture issue that developers break old code for no good reason.
<nakilon>
people who skipped 2.7 have avoided its bugs -- hanging bundler, glitchy irb
<o0x1eef>
And people who never moved on stuck with them?
<nakilon>
why would experiencing all the bugs of every version be a better idea
<kjetilho>
silly stuff like removing [].includes? - no one asked for that extra work
<nakilon>
you think being stuck with 4 bugs is better than with 2?
<o0x1eef>
Generally I don't experience these issues. I'm on Ruby 3.3 nowadays (upgraded from 3.2 a week or so ago) and there has been no noticeable issues. Granted I don't really depend on gems outside the stdlib.
<kjetilho>
(of course it would be best if the duplication was never added)
<nakilon>
it's an old "I'm on linux it has no issues" song
<o0x1eef>
It's just my nature in how I develop.
<nakilon>
just start 2.7 and do "bundle install" and tell me it has no issues
<nakilon>
it literally hangs for 30 seconds on any platform, because there is a bug causing dozens of millions of version comparisons to run for no reason
<o0x1eef>
At a certain point I probably won't be able to compile 2.7 anymore, and I will have to jump hoops to get new devs onboarded with it. I think it just contributes to the problem even more than actually solves anything, so you have to invest in staying up to date rather than keeping your head in the sand.
<nakilon>
I would literally avoid the 2.7 bugs if I skip it
<o0x1eef>
True, but some releases are bugger than others, to just resign yourself to a buggy version forever compounds the problem more - no ?
<nakilon>
how do you know the 2.7 is buggier than the next one?
<o0x1eef>
You don't, but you can have a strategy: ok, I'm going to spin up a branch. In this branch I will use Ruby 3.2. Let's try it for a week or two. Hmm, seems like an improvement. Let's make it mainline. Or, just stay with 2.7 and all of its problems til they drive you crazy
hwpplayer1 has quit [Quit: Take care friends]
<nakilon>
maybe that's the reason why macOS used only 2.0, 2.3, 2.6, because they say other versions are bad
<o0x1eef>
Plus ruby has a concept of EOL, end of security maintainence, these are also reasons to have an update mentality.
<nakilon>
we don't have spare weeks or two, we are doing business
<nakilon>
my team job is to save time, not waste on research
<nakilon>
we don't have security issues
<nakilon>
we don't solve imaginary problems
<o0x1eef>
Fair enough, although, I think this is the wrong approach with Ruby. It pays to stay ahead of the curve. If you never update, you're going to spend that much more time when you *have to* update, and the experience will be even harder.
<nakilon>
the only problem was unusable previous framework that I'm replacing
jmcantrell is now known as Guest2956
Guest2956 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
__jmcantrell__ is now known as jmcantrell
jmcantrell_ has joined #ruby
<nakilon>
coding in ruby since 2009, never experienced this what you guys talk about
<nakilon>
but saw how others struggle so much
<nakilon>
because of their pursuit for version bump
<o0x1eef>
I look at it as a little pain vs a lot of pain. Updating from Ruby 3.2 to Ruby 3.3 will not cover as many changes. Updating from 2.7 to 3.3 could have a lot of of changes to consider or handle. I truly believe it is tied to the culture at any given company. Some people make the effort to stay updated, and others prioritize product work, etc.
<nakilon>
also I remember the reversed backtraces in ruby 2.5
<nakilon>
and the only reason to upgrade from 2.3 to 2.4 was unicode, right?
<nakilon>
so 2.4 for unicode and 2.6 for Object#then -- the only reasonable reasons
<o0x1eef>
My mentality is just different. I stuck with 3.2 for about 6 months I guess, maybe a little longer. Now I'm on 3.3. Once I build 3.4 here locally, I will be moving onto it. So I'm making an effort so stay ahead of the curve every 6 months, year at most.
Exa has quit [Quit: see ya!]
Exa has joined #ruby
ruby[bot] has quit [Remote host closed the connection]
ruby[bot] has joined #ruby
GreenResponse has quit [Quit: Leaving]
STASIdownunder has quit [Read error: Connection reset by peer]
STASIdownunder has joined #ruby
STASIdownunder has quit [Read error: Connection reset by peer]