Earlier quoted context omitted.
We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable. And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.
I appreciate your butt-kicking energy! However, I must note: configuration idempotency tools that regard infrastructure as code are not new. I think you'll find that the inadequacy of cfengine, puppet & chef to the task is why they are not universally used. Devops is a very young discipline and these tools are the stepping stones toward a more coherent model of component deployment. I'm not saying they're crap, just…
OpenBSD removes Rails from the ports tree
61–70 of 73 posts
Re: OpenBSD removes Rails from the ports tree
#62Earlier quoted context omitted.
Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.
I don't mean you any offense, but your response is the kind that makes the entire Ruby community look very bad. It is perfectly normal for responsible software developers, system administrators and business leaders to get angry or upset by security vulnerabilities. The impact such vulnerabilities can have on an organization is staggering. When they're exploited, there can be huge sums of money lost. There can be seri…
Re: OpenBSD removes Rails from the ports tree
#63Earlier quoted context omitted.
I see your numerous FUD posts about Ruby, Javascript & others since a few weeks now, and I'm curious: What is your magical langage / technology that never had any security holes, nor any misconception ?
I've used a lot of different languages, libraries, frameworks, and whatnot over my career. They all have their own problems. Some, however, have far, far more problems (and more serious problems) than others. JavaScript, Ruby and PHP are three examples of very troubled languages. The languages themselves are filled with rather stupid flaws. Their communities are toxic, and in many cases ignorant. The software written…
Again in this comment you blame Ruby/PHP/Javascript without any detail:
> poor performance, poor security, poor maintainability, and various other issues.
Hum, well ok ... compared to what ? All these properties seems relative to me. And I really don't think that a langage / platform can combine all of them. Just like a database can't be CAP or like the project triangle[0]. Engineering is all about tradeoffs.
> Their communities are toxic, and in many cases ignorant.
Hum, even better... Even from Theo de Raadt this sentence would feel arrogant to me.
Just to be clear I have no problem with you having this opinion, and I don't really want to debate about it. I just wanted to know if you had some rational behind it. Now I have my idea...
[0] http://en.wikipedia.org/wiki/Project_management_triangle
Re: OpenBSD removes Rails from the ports tree
#64Earlier quoted context omitted.
I've been messing around with FreeBSD for a few days and it has RubyGems set up very conveniently. Root installed packages (like the ones from ports) would already be attended through the root installed RubyGem. Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up c…
I can tell you that deploying a Rails app needs to come from using rubygem and bundler, never the OS's package management. As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities. We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are o…
Non-OS installation is a huge barrier to new users of a Ruby application. I installed Gitlab recently. Take a look at the length of the installation guide [1]. There are seven numbered steps, some of which involve multiple commands.
Upgrading from 4.0 to 4.1 was about the same complexity.
Thanks to the thoroughness of its author, the guide largely worked as advertised. But being able to install and upgrade with apt-get would have saved me hours.
[1] https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install...
Re: OpenBSD removes Rails from the ports tree
#65Earlier quoted context omitted.
We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable. And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.
I appreciate your butt-kicking energy! However, I must note: configuration idempotency tools that regard infrastructure as code are not new. I think you'll find that the inadequacy of cfengine, puppet & chef to the task is why they are not universally used. Devops is a very young discipline and these tools are the stepping stones toward a more coherent model of component deployment. I'm not saying they're crap, just…
I'm not sure what you mean by clients though and how that relates to VM sprawl.
It's true that some developers are convinced that sys admin is something they can do themselves. However, it goes the other way around too, that sys admins think they know what is best for the app. It's better all around if devs actually gain an understanding at the issues with sys admin, and sys admins get some development skills.
As far as the server-side goes, once nice thing about using something like Chef or Puppet is that you can create a miniature version of the production environment on the developer's laptop. You won't run into the same kind of issues when you are scaling out, but you can at least make sure that you are running everything rather than always developing things in isolation.
Re: OpenBSD removes Rails from the ports tree
#66Earlier quoted context omitted.
Sure. We had a number of Rails apps running in our production environment. The recent weeks have been a very stressful time. A critical Rails or Ruby related vuln is discovered, and then we have to make emergency changes to try avoid the app or server getting compromised. Of course, given the large number of these critical issues, the business decided to pull and rewrite the apps based on input from the It Security t…
Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.
> Ruby sucks
Ruby actually does suck. I don't like it; that's my personal opinion.
But I can't say that. All the cool startups are using it, so Ruby has become one of HN's sacred cows: There are people on here, like the parent, who take offense when someone dares have anything but the highest praise for Ruby and Rails.
I've looked at Ruby. The syntax is ugly; the language is about as bad as Perl in this regard. I've deployed Ruby applications; it's complex (although, to be fair, this is endemic to Web development). Rails is a nightmare.
A lot of HN'ers seem to like it. That's fine. But we should listen to unpopular opinions; important truths aren't always immediately universally accepted as such.
Problem: Maybe Ruby is actually the best thing since sliced bread, but I don't understand its greatness because I haven't seen the right tutorial. Solution: Write a better tutorial, improve existing ones, or point out your favorite beginning Ruby tutorials on HN or your blog.
Problem: Maybe the syntax of Ruby is really what makes me uncomfortable. Solution: A Python-to-Ruby bridge would let people like me experience the goodness of Rails without the pain of learning Ruby's extensive syntactic "innovations."
Problem: The grandparent's employer was uncomfortable with the number of security vulnerabilities recently found in Rails. Solution: Maybe having a stable branch which didn't innovate quite as fast and focused on security would make enterprise users more comfortable with Rails. Or maybe the Rails community needs more thorough vetting of new features for potential security holes, perhaps through requiring separate reviews for security and functionality before patches are officially accepted.
But if we just dismiss anyone who criticizes Ruby as a troll, how are we supposed to recognize and respond to actual problems like these? The grandparent's issues were a legitimate criticism of Ruby, and should not have been downvoted.
Re: OpenBSD removes Rails from the ports tree
#67Earlier quoted context omitted.
"An old friend of mine also runs OpenBSD on his machine and I don't think he's restarted in 2 years" I regularly reach 6 months of uptime on my Debian desktop and I've got a Linux server which reaches 4-digits days of uptime. I only reboot when I need to physically move the machine or when a remote-exploit affecting my setup is discovered. OpenBSD takes this even further and more power to them. My "todo list" since a…
May I recommend PFSense rather than OpenBSD proper, all the power of PF wrapped up in a gui that lends itself directly to firewall configuration. I really enjoyed setting up CARP with it.
Re: OpenBSD removes Rails from the ports tree
#68Earlier quoted context omitted.
Rails is almost entirely a wrapper for these components like ActiveModel and Sprockets and such. You can use them apart from Rails but that's why they are all on the ports tree. It's probably the only thing that uses them.
> It's probably the only thing that uses them. This is very much not true for many of the components. I have a few gems that rely on ActiveSupport and ActiveModel, Sprockets has integration with other frameworks, etc. That said, you're right, the 'rails' gem is really a meta-gem that installs all the right versions of the other ones.
Re: OpenBSD removes Rails from the ports tree
#69Earlier quoted context omitted.
I can tell you that deploying a Rails app needs to come from using rubygem and bundler, never the OS's package management. As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities. We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are o…
> never the OS's package management Non-OS installation is a huge barrier to new users of a Ruby application. I installed Gitlab recently. Take a look at the length of the installation guide [1]. There are seven numbered steps, some of which involve multiple commands. Upgrading from 4.0 to 4.1 was about the same complexity. Thanks to the thoroughness of its author, the guide largely worked as advertised. But being ab…
Re: OpenBSD removes Rails from the ports tree
#70Earlier quoted context omitted.
Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.
As of this writing, the grandparent was downvoted; this post is a response to that situation. > Ruby sucks Ruby actually does suck. I don't like it; that's my personal opinion. But I can't say that. All the cool startups are using it, so Ruby has become one of HN's sacred cows: There are people on here, like the parent, who take offense when someone dares have anything but the highest praise for Ruby and Rails. I've…